Internet DRAFT - draft-li-rtgwg-cc-igp-arch
draft-li-rtgwg-cc-igp-arch
Network Working Group Z. Li
Internet-Draft H. Chen
Intended status: Informational G. Yan
Expires: April 24, 2014 Huawei Technologies
October 21, 2013
An Architecture of Central Controlled Interior Gateway Protocol (IGP)
draft-li-rtgwg-cc-igp-arch-00
Abstract
As the Software Defined Networks (SDN) solution develops, IGP will be
extended to support central control. This document introduces an
architecture of using IGP for central controlling. Some use cases
under this new framework are also discussed. For specific use cases,
making necessary extensions in IGP are required.
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 24, 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
Li, et al. Expires April 24, 2014 [Page 1]
Internet-Draft An Architecture of CC IGP 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 3
3.2. Deployment Mode . . . . . . . . . . . . . . . . . . . . . 4
3.3. Requirement of IGP Extensions . . . . . . . . . . . . . . 4
3.3.1. Building Connectivity . . . . . . . . . . . . . . . . 4
3.3.2. Roles Auto-Discovery . . . . . . . . . . . . . . . . 5
3.3.3. Choosing Controller . . . . . . . . . . . . . . . . . 5
3.3.4. High Availability . . . . . . . . . . . . . . . . . . 5
3.3.5. Security . . . . . . . . . . . . . . . . . . . . . . 6
4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Network Topology Acquirement . . . . . . . . . . . . . . 6
4.2. Automated Dividing Multiple Domains . . . . . . . . . . . 6
4.3. Centralized MPLS TE . . . . . . . . . . . . . . . . . . . 7
4.4. MPLS Global Label Allocation . . . . . . . . . . . . . . 8
4.5. Virtual Link . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Interior Gateway Protocol (IGP) is a protocol for exchanging routing
information between gateways (hosts with routers) within an
autonomous network (for example, a system of corporate local area
networks). The routing information can then be used by the Internet
Protocol (IP) or other network protocols to specify how to route
transmissions.
The internet is the most popular network, it is a distributed system.
Depending on its configuration, each network device communicates with
its neighbor, generates the FIB, and forwards the packet hop by hop.
As the rise of SDN, central controlled IGP is becoming more important
and new requirements for IGP are proposed as follows:
Li, et al. Expires April 24, 2014 [Page 2]
Internet-Draft An Architecture of CC IGP October 2013
1. Build the central control architecture between the controller and
the client. It includes building connectivity, collecting the
topology, and dividing multiple areas automatically, etc.
2. Many new applications are emerging under the central controlled
framework, such as network virtualization, centralized MPLS TE
calculation, segment routing, etc. These new applications bring
extension requirement to IGP.
This document defines an IGP-Based Central Control architecture and
then use cases and corresponding IGP extensions under this
architecture are described.
2. Terminology
BGP: Border Gateway Protocol
IGP: Interior Gateway Protocol
IS-IS: Intermediate System-Intermediate System
OSPF: Open Shortest Path First
SDN: Software Defined Network
3. Architecture
3.1. Reference Model
The following figure depicts a typical architecture of central
controlled IGP. It consists of two essential network elements: IGP
Controller and IGP Client. IGP Controller controls all the IGP
Clients within its administrative domain by communicating with them.
And the controller will also exchange the information each other
through some protocol extensions which is out of scope of this
document.
Li, et al. Expires April 24, 2014 [Page 3]
Internet-Draft An Architecture of CC IGP October 2013
+------------------------------+ +------------------------------+
| Central Control Domain 1 | | Central Control Domain 2 |
| +----------+ | | +----------+ |
| | | | | | | |
| | IGP |------------------------| IGP | |
| |Controller| | | |Controller| |
| | | | | | | |
| +----------+ | | +----------+ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| +--------+ +--------+ | | +--------+ +--------+ |
| | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | |
| | | ...... | | | | | | ...... | | |
| | IGP | | IGP | | | | IGP | | IGP | |
| | CLIENT | | CLIENT | | | | CLIENT | | CLIENT | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Figure 1: An Architecture of Central Controlled IGP
3.2. Deployment Mode
IGP Controller can run on a general-purpose server or a network
device. If IGP Controller runs on a network device, it supports both
central-controlled functionality and forwarding functionality. In
this scenario, besides the control central point, the IGP controller
can also work as a forwarding central point to receive traffic from
one node and forward to other nodes. The forwarding model in this
scenario is just like hub-spoke forwarding model. If IGP Controller
runs on a server, it will not involve in the actual forwarding. It
only works as the control central point to control the forwarding
behaviors of the nodes. In this scenario the traffic will be
distributed in the controlled nodes.
More than one controller can be deployed in a central control domain.
These controllers can work on master-slave mode or load-sharing mode.
3.3. Requirement of IGP Extensions
Building a IGP-based Central Controlled Framework needs extensions to
IGP, I2RS etc.
3.3.1. Building Connectivity
Li, et al. Expires April 24, 2014 [Page 4]
Internet-Draft An Architecture of CC IGP October 2013
IGP protocol is very important to establish connective in the central
control domain. When a new device connects to the this domain, the
connectivity with the other node and the controller should be built
at first. The procedures should be automated since the number of
devices in this domain can be huge. Base on this initialization
process, the controller can download the necessary configuration to
this new node to drive it to set up adjacency with its neighbors and
the controller. Then the topology information can be synchronized in
the central control domain and the connectivity can be built.
3.3.2. Roles Auto-Discovery
In the central control domain, there are two basic roles: IGP
controller and IGP client. The controller can centrally configure
the client role through I2RS interface. The role information should
be flooded through IGP extensions to support the auto discovery
functionality.
3.3.3. Choosing Controller
After the roles of the elements are discovered, if there are multiple
controllers in the domain, the client can determine which controller
to join by its own, or the controllers can determine which controller
the clients should join and set the configuration on the nodes
through I2RS interface. When determine the controller to be joined,
the work mode (master-slave, load-sharing, etc.) of multiple
controllers, service type and some other constraints needs to be
taken into account.
3.3.4. High Availability
In the IGP-based Central Controlled framework, IGP Controller plays a
key role. To avoid one-point-failure of IGP Controller, it is
possible to run redundant IGP Controllers for high availability.
Information should be synchronized between the controllers through
necessary mechanisms or protocol extensions other than IGP. When the
Primary IGP Controller failed, the Backup IGP Controllers will take
over the work of the Primary IGP Controller.
To ensure IGP route persistence in case of occurrence of IGP
Controller failure, the new Primary IGP Controller SHOULD perform
resynchronization with IGP Clients.
When IGP Client loses connection with Primary IGP Controller, it
SHOULD following IGP Graceful Restart routine.
Li, et al. Expires April 24, 2014 [Page 5]
Internet-Draft An Architecture of CC IGP October 2013
3.3.5. Security
In IGP-based Central Controlled framework, it SHOULD be ensured that
communications between IGP Controllers and IGP Clients conform to
network security policy. The communication key used on IGP Client
can be configured through I2RS or other way.
4. Usecases
In IGP-based Central Controlled framework, new use cases which are
difficult to be supported in traditional networks are emerging. In
some specific use cases, extension and enhancement of IGP protocol
are necessary.
4.1. Network Topology Acquirement
In traditional network, it is very difficult for the application to
get and use the topology. The application has to depend multiple
protocols such as OSPF, ISIS, LLDP, etc. In some scenarios, the
application has to communicate with these protocols directly. In the
IGP-based central controlled framework, the topology acquirement
procedures SHOULD be simplified. All topology related information
SHOULD be able to be collected by IGP. Thus the complexity of
network operation and management can be reduced. In the IGP-base
central controlled framework, the controller can get the whole
topology information of the central control domain which can be
easily provided for applications through public interface.
4.2. Automated Dividing Multiple Domains
When there are mass devices in the network, not only LSDB
synchronization, but also route convergence, will be big pressure for
any device, so the network has to be divided into multiple domains.
In the IGP-based central controlled the framework, the division can
be done automatically by the controller which can calculate
reasonable scale for IGP domains based on the whole network
information and the possible constraints. IGP adjacency is only set
up between nodes in the same IGP domain. The adjacency SHOULD not
set up between nodes in different IGP domains. Thus the pressure on
the nodes for LSDB synchronization can be reduced and route
convergence performance can be improved. The configuration about
domain division can be set through I2RS interfaces from the
controller to the clients. The architecute for dividing multiple
domains with the central controller is shown in the figure 2.
Li, et al. Expires April 24, 2014 [Page 6]
Internet-Draft An Architecture of CC IGP October 2013
+---------------------------------------------------------+
| |
| IGP Controller |
| |
+---------------------------------------------------------+
| | | |
| | | |
+-----|-----------------|------+ +-----|-----------------|------+
| | IGP Domain 1 | | | | IGP Domain 2 | |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | |
| | | ...... | | | | | | ...... | | |
| | IGP | | IGP | | | | IGP | | IGP | |
| | CLIENT | | CLIENT | | | | CLIENT | | CLIENT | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Figure 2: Automatic Division of Multiple IGP Domains
4.3. Centralized MPLS TE
In the IGP-based Central Controlled framework, the controller can
implement better traffic engineering functionality because it can
calculate more reasonable path based on complete topology information
and state information of the whole network. Centralized MPLS TE
calculation can avoid the flaw of non-best path proposed by the
existing distributed MPLS TE calculation.
In order to support centralized MPLS TE path calculation, IGP SHOULD
be able to collect more information from the network. There are two
types of information for IGP to collect:
1. Static configuration: In traditional network, MPLS TE attributes
should be configured on the link such as maximum reservable
bandwidth, color, TE metric, etc. These information will be flooded
in the work for MPLS TE path calculation. In the IGP-based Central
Controlled framework, these configuration can be set by the
controller. This means it is not necessary for the controller to get
the TE link information through IGP flooding process. For the reason
of compatibility, the IGP flooding process of MPLS TE link
information can be kept in the central controlled framework. On the
other hand, it provides a possible way for the inconsistency check on
the configuration.
Li, et al. Expires April 24, 2014 [Page 7]
Internet-Draft An Architecture of CC IGP October 2013
2. Running information: Some dynamic state information such as real
traffic bandwidth, packet loss rate, delay, power consumption, etc.
can be flooded through IGP extensions from the nodes to the
controller. The running information can help the controller to
calculate more reasonable path and calculate path for more
constraints defined by applications.
4.4. MPLS Global Label Allocation
MPLS Global Label should be allocated centrally to guarantee all
distributed network nodes can understand meaning of a specific global
label in same. The IGP-based Central Controlled framework is
particularly suitable to allocate MPLS Global Label through some
necessary IGP extensions rather than traditional MPLS protocols(e.g.
LDP, RSVP-TE etc.).
MPLS Global Label is defined in [I-D.li-mpls-global-label-framework]
and related use cases are defined in [I-D.li-mpls-global-label-
usecases].
The MPLS global label should be assigned centrally; each node in
network should have same understanding about these labels. In the
central control network, the global label will be handled by
controller, and IGP protocol will flood these labels.
The extensions of IGP for MPLS global label include:
1. Collect the label capability of each node. The label capability
is the global label space.
2. IGP Controller determines the COMMON label space for all its IGP
Clients.
3. The controller will assign the global label for different
services, and these label bindings will be flooded through IGP
protocol to IGP clients.
4. IGP Client receives the MPLS Global Labels, and generates
corresponding MPLS forwarding entries.
IGP is suitable for the use cases of MPLS global label in the intra-
domain scenario. These use cases include MPLS virtual network and
segment routing as defined in [I-D.li-mpls-global-label-usecases].
4.5. Virtual Link
When the IGP-based Central Controlled framework is applied, one
possible scenario is partial deployment. That is, part of the
Li, et al. Expires April 24, 2014 [Page 8]
Internet-Draft An Architecture of CC IGP October 2013
existing network will be converted to be controlled in the central
control mode. The application scenario is shown in the following
figure:
+------------------------------+
| Central Control Domain |
| +----------+ |
| | | |
| | IGP | |
| |Controller| |
| | | |
| +----------+ |
| / \ |
| / \ |
| / \ |
+-----------+ | +--------+ +--------+ | +-----------+
|Traditional| | | NODE 1 | | NODE n | | |Traditional|
| | | | | ...... | | | | |
| NODE |----| IGP | | IGP |----| NODE |
| | | | CLIENT | | CLIENT | | | |
+-----------+ | +--------+ +--------+ | +-----------+
| |
+------------------------------+
Figure 3: Partial Deployment of Central Controlled IGP
In this scenario, it is not necessary for the traditional nodes to
learn the detailed topology information of the central control
domain. The information flooded between the central control domain
and the traditional nodes can be reduced. The central control domain
can only advertise virtual links which connect the edge nodes in the
domain that the traditional node can be aware of. The process can
reduce the pressure of the traditional node for flooding and improve
convergence performance.
In the central control domain, the controller can apply the policy
defined by the applications to control whether the virtual link will
be advertised to the outside and what metric is advertised to affect
the route calculation of the outside network.
5. IANA Considerations
TBD.
6. Security Considerations
TBD.
Li, et al. Expires April 24, 2014 [Page 9]
Internet-Draft An Architecture of CC IGP October 2013
7. References
7.1. Normative References
[ISO/IEC 10589]
ISO, "Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)," ISO/IEC 10589:1992.
[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.
7.2. Informative References
[I-D.chen-ospf-ttz]
Chen, H., Li, R., Cauchie, G., Retana, A., Ning, S., Toy,
M., and L. Liu, "OSPF Topology-Transparent Zone", draft-
chen-ospf-ttz-06 (work in progress), July 2013.
[I-D.ietf-ospf-te-metric-extensions]
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", draft-ietf-ospf-te-metric-extensions-04 (work
in progress), June 2013.
[I-D.li-mpls-global-label-framework]
Li, Z., Zhao, Q., and T. Yang, "A Framework of MPLS Global
Label", draft-li-mpls-global-label-framework-00 (work in
progress), July 2013.
[I-D.li-mpls-global-label-usecases]
Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global
Label", draft-li-mpls-global-label-usecases-00 (work in
progress), July 2013.
[I-D.li-ospf-ext-green-te]
Yan, G., Yang, J., and Z. Li, "OSPF Extensions for MPLS
Green Traffic Engineering", draft-li-ospf-ext-green-te-01
(work in progress), October 2013.
[I-D.ylz-ospf-lsdb-sync-group]
Yan, G., Liu, Y., and X. Zhang, "OSPF Extensions for Link
State Database Synchronization Group", draft-ylz-ospf-
lsdb-sync-group-01 (work in progress), October 2013.
Li, et al. Expires April 24, 2014 [Page 10]
Internet-Draft An Architecture of CC IGP October 2013
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Huaimo Chen
Huawei Technologies
Boston, MA
USA
Email: huaimo.chen@huawei.com
Gang Yan
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: yangang@huawei.com
Li, et al. Expires April 24, 2014 [Page 11]
