| 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
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.
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].
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 January 16, 2015.
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.
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 [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.
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.
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 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.
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.
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 adjacencies are inherently called SGMI and SGDI. A SGMI or SGDI MUST belong to a single SG.
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.
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.
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.
+----+ +----+
|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.
This document introduced some changes to OSPF[RFC2328] which is necessary to support SG.
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.
No change introduced for route calculation in this document.
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
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.
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.
This document requests that IANA allocate from the OSPF TLV Codepoints Registry for a new TLV, referred to as the "Synchronization Group TLV".
This document does not introduce any new security concerns to OSPF or any other specifications referenced in this document.
The authors would like to thank Eric Wu for his valuable comments on this draft.
| [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. |
| [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. |