Network Working Group G. Yan Internet-Draft Y. Liu Intended status: Standards Track X. Zhang Expires: May 15, 2015 Huawei November 9, 2014 OSPF Synchronization Group draft-yan-ospf-sync-group-01 Abstract OSPF is a fundamental component for a routing system. It depends on the flooding mechanism to advertise and synchronize link-state database among distributed nodes in a network. As modern networks become larger and more complex, more and more nodes and adjacencies are involved. As a result, massive link-state information are generated and synchronized which are becoming an overhead of networks nowadays. This document proposes a new design of OSPF database synchronization that is slightly different from the one stated in OSPF. This new design can help to alleviate the overhead by dividing OSPF routers into independent synchronization groups and limiting synchronization across the group border. Since less burden from synchronization, it is possible to accommodate more OSPF routers and adjacencies in a network. Requirements Language 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 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Yan, et al. Expires May 14, 2015 [Page 1] Internet-Draft OSPF Synchronization Group November 2014 This Internet-Draft will expire on May 14, 2015. Copyright Notice Copyright (c) 2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Overview of a Synchronization Group . . . . . . . . . . . 4 4.2. LSA Synchronization in a Group . . . . . . . . . . . . . 5 5. Changes to the protocol . . . . . . . . . . . . . . . . . . . 5 5.1. Changes to the Flooding mechanism . . . . . . . . . . . . 5 5.2. Route Calculation . . . . . . . . . . . . . . . . . . . . 6 5.3. Protocol Extension . . . . . . . . . . . . . . . . . . . 6 5.4. Protocol Process . . . . . . . . . . . . . . . . . . . . 8 6. Multi-homed SG consideration . . . . . . . . . . . . . . . . 8 6.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 6.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 9 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction OSPF is a fundamental component for a routing system. It depends on the flooding mechanism to advertise and synchronize link-state database among distributed nodes in a network. As modern networks become larger and more complex, more and more nodes and adjacencies Yan, et al. Expires May 14, 2015 [Page 2] Internet-Draft OSPF Synchronization Group November 2014 are involved. As a result, massive link-state information are generated and synchronized which are becoming an overhead of networks nowadays. This document proposes a new design of OSPF database synchronization that is slightly different from the one stated in [RFC2328]. This new design can help to alleviate the overhead by dividing OSPF routers into independent synchronization groups and limiting synchronization across the group border. Since less burden from synchronization, it is possible to accommodate more OSPF routers and adjacencies in a network. In some scenarios, the routers in those networks suffer from limited CPU or storage resource which make them unqualified for large networks. With the help from this new design the situation can be improved. 2. Terminology Synchronization Group (SG) : A sub-domain of one OSPF area in which the link-state database synchronization only happened among those routers in the same group. Synchronization Group ID (SGID) : The identity of a Synchronization Group which MUST be unique in one OSPF network. Synchronization Group Member (SGM) : One role of OSPF router which belongs to an unique Synchronization Group by carrying the SGID in its Hello packet. Adjacencies MUST NOT be established among SGMs from different SGs. Synchronization Group Member Interface (SGMI) : The interface of a Synchronization Group Member. Synchronization Group Director (SGD) : One role of OSPF router whose adjacencies MUST follow the standard procedure instead of affected by SGIDs. Synchronization Group Director Interface (SGDI) : The interface of a Synchronization Group Director. 3. Problem Statement As stated in [RFC2328], the flooding procedure supplied a reliable advertisement mechanism through which the link-state database is synchronized in an OSPF network. Forwarding loops or routing black- hole can be introduced if synchronization status is not achieved. There are some devices for which it is difficult to host the whole Yan, et al. Expires May 14, 2015 [Page 3] Internet-Draft OSPF Synchronization Group November 2014 link-state database since they may possess limited CPU or storage resource. Even for those devices which have enough resource, it is still an unneglectable overhead in a periodical manner. +----+ +----+ | S1 | *** *** *** | Si | +----+--- ---+----+ * ---- ---- * * ---- ---- * * --+----+-- * |Hub | * --+----+-- * * ---- ---- * * ---- ---- * +----+--- ---+----+ | Sj | *** *** *** | Sn | +----+ +----+ Figure 1 Hub and Spoke scenario As showed in Figure 1, the hub sub-network established OSPF adjacencies with many spoke sub-networks indexed from S1 to Sn separately. Every LSAs generated by a single spoke have to be flooded to the rest of spokes through hub and vice versa. Let's assume there are m LSAs originated by each spoke then the total number of LSAs advertised among hub and spokes can be roughly counted as m * n, excluding the number of retransmission. What is worse, these LSA copies have to be refreshed every LSRefreshTime. This advertisement is indeed an unnecessary burden for devices with limited resources and even those devices with enough resources since all routes in one spoke share the same next hop which is the hub. 4. Proposed Solution This document introduces a new mechanism which can solve the issue stated above through limiting synchronization scope inside a Synchronization Group instead of an area. The solution metioned here should be effective primarily in the hub-and-spoke scenario. 4.1. Overview of a Synchronization Group A Synchronization Group (SG) is a sub-domain of one OSPF area in which the link-state database synchronization only happened among those routers in the same group. Each SG is identified uniquely by an identification number which is called SGID. There are two roles involved into one Synchronization Group: Synchronization Group Member (SGM) and Synchronization Group Director Yan, et al. Expires May 14, 2015 [Page 4] Internet-Draft OSPF Synchronization Group November 2014 (SGD). The same SGD may be involved into several SGs simultaneously. Different SGDs are REQUIRED to interconnect with each other without passing through SGMs. The interfaces SGM and SGD used to form adjacencies are inherently called SGMI and SGDI. A SGMI or SGDI MUST belong to a single SG. 4.2. LSA Synchronization in a Group Link-state database synchronization among SGDs follows the same procedure stated in [RFC2328]. They maintain the complete database of the area they belong to. This database is used to advertise among SGDs and consumed in the SPF calculation. On the other side, SGMs only possess those LSAs that are learned from other SDMs and several LSAs leaked by their corresponding SGDs. SGMs advertise and use their LSDB in the manner as the standard document specified. When OSPF adjacencies built between a SGD and a SGM, the synchronization between them SHOULD follow the specification defined in this document. In order to decrease the size of SGM's LSDB, a SGD only advertise necessary LSAs to its adjacent SGMs. Those LSAs in necessity include the Router-LSAs of SGDs in the same SG, the Network-LSAs if some of SGDs are DR for their corresponding networks and some Extended Prefix Opaque LSAs[I-D.ietf-ospf-prefix-link-attr] originated by SGDs to serve for limited reachability for SGMs. 5. Changes to the protocol This document introduced some changes to OSPF[RFC2328] which is necessary to support SG. 5.1. Changes to the Flooding mechanism SGDI and SGMI SHOULD be used to send and receive the LSAs updating in one SG. The LSA's SG belonging is identified by its originator's SGID. If MaxAge LSA is received, it SHOULD be processed as described in section 13 of OSPF[RFC2328]. If a LSA is received from a neighbor that does not support SG, it SHOULD be processed as standardized since SG feature is ineffective between them. When LSDB synchronization happened between SGDs and SGMs, only limited LSDB SHOULD be flooded from SGDs to SGMs. As stated above, instead of flooding all LSAs to SGMs, only Router-LSAs and Network- LSAs in the same Group SHOULD be flooded to SGMs. On the contrary, SGMs SHOULD synchronize their whole LSDB to SGDs as standandized. Yan, et al. Expires May 14, 2015 [Page 5] Internet-Draft OSPF Synchronization Group November 2014 5.2. Route Calculation No change introduced for route calculation in this document. 5.3. Protocol Extension One new bit is introduced into Router Informational Capabilities TLV to indicate its originator supporting SG capability or not. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Informational Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit TBD: OSPF Synchronization Group capable Figure 2 SG-bit in Informational Capabilities TLV A new TLV called Synchronization Group TLV is defined to be included in Router Information Opaque LSA[RFC4970]. Every router that support SG feature MUST contain this TLV in its RI Opaque-LSA. SGID and role of SGM or SGD can be learnt by parsing this TLV and act accordingly. Yan, et al. Expires May 14, 2015 [Page 6] Internet-Draft OSPF Synchronization Group November 2014 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Synchronization Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ... ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Synchronization Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 2 octets Synchronization Group ID: ID of this SG. Flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |E|D| +-+-+-+-+-+-+-+-+ Bit-D: Set if Synchronization Group Director. Bit-E: Set if Synchronization Group Director is elected as Designated SGD for this SG. Figure 3 Synchronization Group TLV Extended Prefix TLV SHOULD be used by SGDs to advertise default route or necessary aggregated prefixes to SGMs. New sub-TLV is introduced to identify metrics for corresponding prefixes. The metric used in the sub-TLV SHOULD be the actual number from SGDs to the destination of the prefix. Yan, et al. Expires May 14, 2015 [Page 7] Internet-Draft OSPF Synchronization Group November 2014 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Type | Prefix Length | AF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | OSPFv2 Extended Prefix TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric of the prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 2 octets Metric of the prefix: The actual metric for corresponding prefix. Figure 4 Sub-TLV used to express prefix metric 5.4. Protocol Process Synchronization Group TLV MUST be carried in the RI Opaque-LSA with SG-bit set if the originator support SG feature. It SHOULD be regarded as not supporting SG feature If this TLV is not carried or SG-bit is clear. SGDs and SGMs MUST send this TLV with corresponding SGIDs set and with correct Bit-D status. If there are more than one Synchronization Group TLVs carried in RI Opaque-LSAs then the originator SHOULD be regarded as supporing all those carried SGs. 6. Multi-homed SG consideration 6.1. Problem Statement In certain scenario, one SG may multi-homed to two or more SGDs. Forwarding loops may be observed when topology changed since the link-state database of SGD and SGM can be different. In order to solve this issue, one tunnel is REQUIRED to be established among SGDs with the metric lower than the path through SG. Yan, et al. Expires May 14, 2015 [Page 8] Internet-Draft OSPF Synchronization Group November 2014 As shown below, when link between SGD2 and SG1A failed, the best path to reach SG1A is SGD2->SGD4->SG2A->SGD3->SGD1->SG1A. Since SG2A only have default route originated by its SGDs, saying SGD3 and SGD4, forwarding loops can be observed. Even special handling was taken on SGD4, such as avoiding traveling through SDMs, traffic black hole could happen on SGD4 since SGD2 will insist on its choice. What is worse, assuming SGD2 generated the same prefix as SG1A did but with shorter prefix length, since SGD4 should ignore the link between SGD4 and SG2A that will cause transversal traffic, this shorter prefix will be the best match for the original destination, so forwarding loop can be observed between SGD2 and SGD4. +----+ +----+ |SGD1| |SGD2| +----+\\ ---+----+\ 100 -- \\---- \\ 10 -- 100 ----\\ 10 \ -- ---- **\\*************\********* +----+-- * \ +----+ +----+ * |SG1A| * |SGD3| |SGD4| * +----+ * +----+ +----+ * | * \\ // * |10 * 10 \ / 10 * +----+ * +----+ * |SG1B| * |SG2A| * +----+ * +----+ * *************************** Figure 5 Multi-homed SG scenario 6.2. Proposed Solution The root cause for the issue above is the inconsistent status of LSDB between SGDs and SGMs. In order to solve this flaw, we may simply add one restriction to SGDs that SG sub-networks can't be passed through to reach another SGD. With this restriction, inconsistent routing-table can be observed between SGDs and the rest of networks in the same area, like SGD2 and SGD4 did above. Two solutions proposed here. Solution I: SGDs in the same SG are REQUIRED to automatically interconnect with each other using certain tunnels. The tunnel can be created when the SGD Router-LSA in the same SG is received. The traffic SHOULD be redirected into tunnels when the SGD finds the next hop points to one SGM. The exact tunnel type used here is out of the scope of this document. Yan, et al. Expires May 14, 2015 [Page 9] Internet-Draft OSPF Synchronization Group November 2014 Solution II: When a SG is multi-homed to multiple SGDs, SGDs and SGMs in the same SG SHOULD elect one Designated SGD (DSGD) from those candidate SGDs. Adjacencies SHOULD NOT be built between the non- designated SGDs and SDMs. A new DSGD SHOULD be elected among left candidates when the current DSGD failed. With one of the solutions above, forwarding loops and traffic black hole are believed to be prevented. 7. Backward Compatibility It is RECOMMENDED that SG feature is deployed all over the network at the same time. Otherwise It will work in the standardized manner without harm introduced into current network if partial deployment is used. 8. IANA Considerations This document requests that IANA allocate from the OSPF TLV Codepoints Registry for a new TLV, referred to as the "Synchronization Group TLV". 9. Security Considerations This document does not introduce any new security concerns to OSPF or any other specifications referenced in this document. 10. Acknowledgement The authors would like to thank Eric Wu for his valuable suggestion on this draft. 11. References 11.1. Normative References [I-D.ietf-ospf-prefix-link-attr] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", draft-ietf-ospf-prefix-link-attr-01 (work in progress), September 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. Yan, et al. Expires May 14, 2015 [Page 10] Internet-Draft OSPF Synchronization Group November 2014 11.2. Informative References [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. Authors' Addresses Gang Yan Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: yangang@huawei.com Yuanjiao Liu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: liuyuanjiao@huawei.com Xudong Zhang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhangxudong@huawei.com Yan, et al. Expires May 14, 2015 [Page 11]