Network Working Group G. Yan Internet-Draft Y. Liu Intended status: Standards Track X. Zhang Expires: January 16, 2015 Huawei Technologies July 15, 2014 OSPF Synchronization Group draft-yan-ospf-sync-group-00 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 the network. As modern networks become larger and more complex, lots of nodes and adjacencies are involved into it. As a result, massive link-state information are generated and synchronized which is becoming an overhead of the network nowadays. This document proposes a new design of OSPF database synchronization which 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 forbidding synchronization across the group border. Since less burden from synchronization, it is possible to accommodate more OSPF routers and adjacencies in the 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 January 16, 2015 [Page 1] Internet-Draft OSPF Synchronization Group July 2014 This Internet-Draft will expire on January 16, 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 Synchronization Group . . . . . . . . . . . . 4 4.2. Adjacency of Synchronization Group . . . . . . . . . . . 5 4.3. LSA Synchronization in Group . . . . . . . . . . . . . . 5 4.4. Multi-homed Group . . . . . . . . . . . . . . . . . . . . 5 5. Changes to the protocol . . . . . . . . . . . . . . . . . . . 6 5.1. Changes to the Flooding mechanism . . . . . . . . . . . . 6 5.2. Route Calculation . . . . . . . . . . . . . . . . . . . . 7 5.3. Protocol Extension . . . . . . . . . . . . . . . . . . . 7 5.4. Protocol Process . . . . . . . . . . . . . . . . . . . . 7 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 the network. As modern networks become larger and more complex, lots of nodes and adjacencies are involved into it. As a result, massive link-state information are Yan, et al. Expires January 16, 2015 [Page 2] Internet-Draft OSPF Synchronization Group July 2014 generated and synchronized which is becoming an overhead of the network nowadays. This document proposes a new design of OSPF database synchronization which is slightly different from the one stated in OSPF [RFC2328]. This new design can help to alleviate the overhead by dividing OSPF routers into independent synchronization groups and forbidding synchronization across the group border. Since less burden from synchronization, it is possible to accommodate more OSPF routers and adjacencies in the 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 OSPF[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 reached. There are some devices for which it is difficult to host the whole link-state database since they may possess limited CPU or Yan, et al. Expires January 16, 2015 [Page 3] Internet-Draft OSPF Synchronization Group July 2014 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, Hub established OSPF adjacencies with many Spokes 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 either devices with limited resources or 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. 4.1. Overview of 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 (SGD). The SGID of SGD SHOULD be set to zero while the SGID of SGM MUST be non-zero. The interfaces SGM and SGD used to form Yan, et al. Expires January 16, 2015 [Page 4] Internet-Draft OSPF Synchronization Group July 2014 adjacencies are inherently called SGMI and SGDI. A SGMI or SGDI MUST belong to a single SG. 4.2. Adjacency of Synchronization Group SDMs from different SGs MUST NOT establish OSPF adjacencies among them. SG SHOULD NOT take effect if one of SGM's neighbors does not support this feature. As a result standardized OSPF adjacencies SHOULD be established in the SG. SGD can establish OSPF adjacencies with SGMs from different SGs only if these SGMs do not involved into the same network segment. Otherwise standardized OSPF adjacencies SHOULD be established in the SG. Standardized OSPF adjacency SHOULD be established between SGD and the specified neighbor which does not support SG. SGD can establish standardized adjacencies among themselves if no SGM is involved. 4.3. LSA Synchronization in Group SGMs MUST synchronize their link-state database in the SG scope if SG feature is effective. Only those LSAs originated by SGMs in the same SG SHOULD be held. SGD can maintain link-state database from multiple SGs which are supported by itself simultaneously. SGD SHOULD prevent database from different SGs to leak into each other. Each SGM SHOULD generate a default route with the nearest SGD as the nexthop after SG roles have been identified and adjacencies have been established. 4.4. Multi-homed Group 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 January 16, 2015 [Page 5] Internet-Draft OSPF Synchronization Group July 2014 +----+ +----+ |SGD1|***********|SGD2| +----+\\ ---+----+\ -- \\---- \\ 10 10 -- ----\\ \ -- ---- \\10 \ +----+-- 10 \ +----+ 100 +----+ |SG1A| |SG2A|-----|SG2B| +----+ +----+ +----+ | \\ // |10 10 \ / 10 +----+ +----+ |SG1B| |SG2C| +----+ +----+ Figure 2 Multi-homed SG scenario As showed above, let's assume the traffic from SG2B is guided to SGD2 by default route. After the link between SGD2 and SG1A broke, this traffic has to be diverted to the path through SG2A then to SGD1 in the eye of SGD2. However SG2B still depends on the default route advertised by SGD2 to guide traffic. As a result one forwarding loop may happen here. As the solution described, one tunnel is required from SGD2 to SGD1 with lower metric so that the loop can be avoided. In the example above, the metric of this tunnel need to be less than 120.(The sum of SGD2->SG2B->SG2A->SDG1). The specific tunnel type and standard process of establishment of tunnel is out of the scope of this document and left for future study. 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 carried in Hello packet. 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 which does not support SG, it SHOULD be processed as standardized since SG feature is ineffective. If a LSA is received from a neighbor which belongs to a different SG, it MUST be discarded since no adjacency SHOULD be established with this neighbor. Otherwise LSAs from the same SG SHOULD be synchronized among adjacencies all over the SG. Yan, et al. Expires January 16, 2015 [Page 6] Internet-Draft OSPF Synchronization Group July 2014 5.2. Route Calculation No change introduced for route calculation in this document. 5.3. Protocol Extension A new TLV called Synchronization Group TLV is defined to be included in LLS. Every router that support SG feature MUST contain this TLV in its LLS data block carried in Hello packet. SGID and role of SGM or SGD can be learnt by parsing this TLV and act accordingly. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 4 octets Synchronization Group ID: ID of this SG. Set zero if SGD. Flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |D| +-+-+-+-+-+-+-+-+ Bit-D: Set if Synchronization Group Director. Figure 3 Synchronization Group TLV in LLS 5.4. Protocol Process Synchronization Group TLV MUST be carried in the LLS data block of Hello packet if the originator support SG feature. It SHOULD be regarded as not supporting SG feature If this TLV or LLS is not carried. SGM MUST send this TLV with corresponding SGID set and with Bit-D reset. SGD MUST send this TLV with SGID set to zero and with Bit-D set. If there are more than one Synchronization Group TLVs carried in LLS then the first one will be selected while others will be ignored. This TLV SHOULD be regarded as illegal and discarded if both SGID and Bit-D are set to zero. Similarly this TLV SHOULD be regarded as illegal and discarded if SGID is not zero but Bit-D is set. Yan, et al. Expires January 16, 2015 [Page 7] Internet-Draft OSPF Synchronization Group July 2014 6. 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. 7. 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". 8. Security Considerations This document does not introduce any new security concerns to OSPF or any other specifications referenced in this document. 9. Acknowledgement The authors would like to thank Eric Wu for his valuable comments on this draft. 10. References 10.1. Normative References [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. 10.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 Yan, et al. Expires January 16, 2015 [Page 8] Internet-Draft OSPF Synchronization Group July 2014 Gang Yan Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: yangang@huawei.com Yuanjiao Liu Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: liuyuanjiao@huawei.com Xudong Zhang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhangxudong@huawei.com Yan, et al. Expires January 16, 2015 [Page 9]