Network Working Group G. Yan Internet-Draft Y. Liu Intended status: Standards Track X. Zhang Expires: April 17, 2014 Huawei Technologies October 14, 2013 OSPF Extensions for Link State Database Synchronization Group draft-ylz-ospf-lsdb-sync-group-01 Abstract This document describes a special scheme of OSPF Database synchronization by dividing OSPF Routers into different groups and preventing OSPF Routers from different groups to synchronize, this scheme can help to enhance the number of OSPF adjacencies and the capability of deploying OSPF on large 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." This Internet-Draft will expire on April 17, 2014. Copyright Notice Copyright (c) 2013 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 Yan, et al. Expires April 17, 2014 [Page 1] Internet-Draft OSPF SYNC GROUP October 2013 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Hub and Spoke Scenario . . . . . . . . . . . . . . . . . 3 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Synchronization Group . . . . . . . . . . . . . . . . . . 4 4.2. Synchronization Group Adjacency . . . . . . . . . . . . . 4 4.3. LSA Synchronization by Group . . . . . . . . . . . . . . 5 4.4. Route Calculation . . . . . . . . . . . . . . . . . . . . 6 4.5. Change of Group Member's Group ID . . . . . . . . . . . . 6 5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Process . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The OSPF routing protocol has been used more and more widely in IP radio access networks and enterprise networks. The routers in these networks are usually small devices which have limited memory and CPU, and can not be deployed on large network or large number of adjacencies. This document describes a new mechanism for improving this issue. 2. Terminology Synchronization Group: Subset of one area in which the OSPF Routers can exchange LSAs with each other. The OSPF Routers from different Synchronization Groups MUST NOT exchange LSAs with each other. Synchronization Group ID: Identity of Synchronization Group. Group Member: One role of OSPF in Synchronization Group which has a unique Synchronization Group ID carried in its LSA. Only those Yan, et al. Expires April 17, 2014 [Page 2] Internet-Draft OSPF SYNC GROUP October 2013 members who are carrying the same Synchronization Group ID SHOULD establish adjacency. Otherwise no adjacency SHOULD be established. The interface of Group Member is called Group Member interface. Group Master: One role of OSPF in Synchronization Group which should establish adjacencies with any other OSPF Routers ignoring Group IDs. The interface of Group Master is called Group Master interface. 3. Requirement The OSPF routing protocol [RFC2328]has an mechanism to make sure the LSA database to synchronize. If the LSA database is not synchronized, There may be loop of routes or black hole of routes. One OSPF in network must exchange link status information with its adjacencies. In some scenarios that there are thousands of LSAs and more than one thousand adjacencies in the network, lots of LSAs need to be transferred on all adjacencies for synchronization. The physical device resources including memory/CPU/ line card are the critical factor to extend the size of network. 3.1. Hub and Spoke Scenario Hub A / | : | \ / | : | \ / | : | \ p1 ... pn Figure 1 Hub and Spoke Network Suppose Hub A establish n adjacencies and there are m LSAs in the network. Hub A will transfer (including receiving and sending) these LSAs on its n interfaces. The total LSAs to transfer is O(n*m) without considering the number of LSAs which need to be retransmitted. The time to synchronize LSAs to n adjacencies for Hub A is critical for route convergence. Hub A need support high performance of transferring packets. In some scenarios, hub and spoke devices are poor hardware condition with limited memory and CPU, especially the spoke devices can not store all LSAs in the network because of less memory. In such case, there are some special requirements: 1) The spoke devices are not necessary to learn routes with each other. 2) The spoke devices learn default route or gate way route from hub device. Yan, et al. Expires April 17, 2014 [Page 3] Internet-Draft OSPF SYNC GROUP October 2013 4. Solution This document introduces a new mechanism which supports LSAs to synchronize in part of one area. 4.1. Synchronization Group One area is divided into several parts called Synchronization Groups which are identified by unique ID (Synchronization Group ID). Two roles of OSPF Routers are defined here: Group Member OSPF Router and Group Master OSPF Router. Group Member OSPF Routers from the same Synchronization Group SHOULD establish adjacencies and exchange LSAs; Group Member OSPF Routers from different Synchronization Group MUST NOT establish adjacencies and MUST NOT exchange LSAs with each other. The interface of Group Member OSPF Router is defined as Group Member Interface; The interface of Group Master OSPF Router is defined as Group Master Interface. 4.2. Synchronization Group Adjacency The procedure of establishing Synchronization Group Adjacency: 1) A new TLV called Synchronization Group sub-TLV (see section 5) can be carried in Router Information Opaque LSA [RFC4970]and Link-Local Signaling (LLS for short) [RFC4813]. Group Member Interface sends Router Information Opaque LSA including Synchronization Group TLV with its related Synchronization Group ID and M bit set to 0; Group Master Interface sends Router Information Opaque LSA including Synchronization Group TLV with its Synchronization Group ID set to 0 and M bit set to 1. (Note: Group Member Routers/Interface SHOULD set Synchronization Group ID as configured value which is not 0. Group Master Routers/Interface SHOULD set Synchronization Group ID as 0.) 2) For Group Member whose Synchronization Group ID is not 0, a) If Group Member OSPF Router has one or more neighbors of Group Member, none of them don't support Synchronization Group feature, they MUST NOT form normal adjacency/adjacencies. b) If Group Member OSPF Router has one or more neighbors of Group Member which have the same Synchronization Group ID, they SHOULD form Synchronization Group adjacency/adjacencies; otherwise, they MUST NOT form normal adjacency/adjacencies. Yan, et al. Expires April 17, 2014 [Page 4] Internet-Draft OSPF SYNC GROUP October 2013 3) For Group Master OSPF Router whose Synchronization Group ID is 0, a) If Group Master OSPF Router has one or more neighbors of OSPF Routers, but none of them supports Synchronization Group feature, then they can form normal adjacency/adjacencies. b) If Group Master OSPF Router has one or more neighbors of Group Member OSPF Routers which have the same Synchronization Group ID, they can form Synchronization Group adjacency/adjacencies. If some neighbors have different Synchronization Group IDs, they MUST NOT form normal adjacency/adjacencies. c) If Group Master OSPF Router has more than one neighbor of OSPF Routers and some of them support Synchronization Group feature while others don't, then they MUST NOT form normal adjacency/adjacencies. d) Group Master OSPF Routers SHOULD form normal adjacencies with each other on the LAN where no Group Member OSPF exists. e) If a common LAN is shared by two or more Group Master OSPF Routers and some Group Member OSPF Routers whose Synchronization Group ID are the same, they can form Synchronization Group adjacency/adjacencies. f) If a common LAN is shared by two or more Group Master OSPF Routers and some Group Member OSPF Routers whose Synchronization Group ID are not the same, they MUST NOT form adjacency/adjacencies. Synchronization Group Adjacency SHOULD be advertised as normal adjacency. 4.3. LSA Synchronization by Group Group Member OSPF MUST carry Synchronization Group TLV (see section 5) in Router Information Opaque LSA and LLS. Group Member OSPF Router just holds the LSAs which are generated by OSPF Routers which in the same Synchronization Group, or by Group Master OSPF Routers, or by OSPF Routers which don't support Synchronization Group feature. The procedure of packets: 1) Group Member Interface and Group Master Interface which has Synchronization Group Adjacency SHOULD send/receive special LSA packets which just contain the entries of the same group and non- group LSAs. 2) When Group Member Interface receives some LSAs from packet which is not belong the same group, Yan, et al. Expires April 17, 2014 [Page 5] Internet-Draft OSPF SYNC GROUP October 2013 a) If the LSA entry with non-maxage, the LSA entry SHOULD be discard. b) If the LSA entry with maxage, the LSA entry SHOULD be processed as described in OSPF [RFC2328]. The procedure of LSA, When Group Member OSPF A receives OSPF B's LSA x: 1) if x is maxage LSA, A SHOULD synchronize LSA x to adjacencies of Group Member. maxage LSA SHOULD be synchronized as described in OSPF [RFC2328]. 2) if x is not maxage LSA and A does not receive the Synchronization Group sub-TLV of Router Information Opaque LSA of B before, LSA x cannot make sure which group it belongs to, so LSA x SHOULD not be sent to adjacencies of Group Member. 3) if x is not maxage LSA and A has received the Router Information Opaque LSA of B, a) If B does not support Synchronization Group feature, LSA x SHOULD be synchronized to all adjacencies of A. b) If B supports Synchronization Group feature and has the same Synchronization Group ID, LSA x SHOULD be synchronized to all adjacencies of A; otherwise, LSA x SHOULD NOT be sent to adjacencies of Group Member. 4.4. Route Calculation OSPF calculates routes based on its LSA database. No change in this document. 4.5. Change of Group Member's Group ID When a Group Member OSPF wants to change its group ID to another one, it is RECOMMENDED to change system ID of OSPF for a new one at the same time. Group member will generate new LSAs and be synchronized in a new group. The old LSAs will remain in the old group, but it will not be used in route calculation. The remain life of the old LSAs will be reduced until LSAs reach Maxage to flush. 5. Protocol Extension A new TLV called Synchronization Group TLV is defined to be included in Router Information Opaque LSA and LLS. The Opaque LSA transmitted by a interface that belongs to one Synchronization Group MUST include this TLV. Yan, et al. Expires April 17, 2014 [Page 6] Internet-Draft OSPF SYNC GROUP October 2013 Type TBD Length # of octets in the value field (2 octets) Value 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type(*) | Sub-TLV Length(*) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV values(*) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * - if present Flags (1 octet): 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |S|M| +-+-+-+-+-+-+-+-+ M - Group Master/Member Role bit S - subtlv present bit (Note: Group Master sets M bit to 1 and Group Member sets M bit to 0) Synchronization Group ID (2 octets): The range of value of Synchronization Group ID is from 0 to 65535. The value of 0 SHALL be used by Group Master only. Synchronization Group ID of Group Member MUST NOT be 0. Sub-TLV is not defined in this document which could be extended in future. Yan, et al. Expires April 17, 2014 [Page 7] Internet-Draft OSPF SYNC GROUP October 2013 6. Protocol Process Synchronization Group TLV is introduced to indicate whether support Synchronization Group feature or not. 6.1. Sending Synchronization Group TLV MUST be carried in the Router Information Opaque LSA and LLS, and MUST encode just one time in LSA; This TLV is optional to carry for Group Master OSPF Router. Group Member Interface MUST carry this TLV in its Router Information Opaque LSA and LLS with its related Synchronization Group ID and M bit set to 0; Group Master Interface sends Router Information Opaque LSA and LLS including synchronization Group TLV with its Synchronization Group ID set to 0 and M bit set to 1. 6.2. Receiving If there are more than one Synchronization Group TLVs in Router Information Opaque LSA, the first one is selected, others are ignored. if Synchronization Group ID and M bit are both set to 0 in TLV, the TLV is illegal and SHOULD be ignored. if Synchronization Group ID is not 0 and M bit is set to 1 in TLV, the TLV is illegal and SHOULD be ignored. 7. IANA Considerations This document requests that IANA allocate from the OSPF TLV Codepoints Registry 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. 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. Yan, et al. Expires April 17, 2014 [Page 8] Internet-Draft OSPF SYNC GROUP October 2013 [RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. Authors' Addresses 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 April 17, 2014 [Page 9]