OSPF Synchronization Group
draft-yan-ospf-sync-group-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Gang Yan , Yuanjiao Liu , Xudong Zhang | ||
| Last updated | 2014-07-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yan-ospf-sync-group-00
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]