Internet DRAFT - draft-li-rtgwg-igp-cc-reqs
draft-li-rtgwg-igp-cc-reqs
Network Working Group Z. Li
Internet-Draft N. Wu
Intended status: Informational Huawei Technologies
Expires: January 5, 2015 July 4, 2014
Requirements of Interior Gateway Protocol (IGP) for Central Control
draft-li-rtgwg-igp-cc-reqs-00
Abstract
Interior Gateway Protocol(IGP) such as IS-IS or OSPF is a fundamental
building block for traditional routing system which is based on
distributed computation model. Routing in networks based on
centralized computation model such as Software Defined Network(SDN)
may require special IGP extension to facilitate its operation in
multi-domain, multi-region, or multi-layer networks.
This document introduces an architecture of deploying IGP for
central-controlled network, but it does not aim to provide a detailed
description of all the architectural components. It also specifies a
set of functional requirements which can be fulfilled by IGP with
proper extension for the central-controlled 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 January 5, 2015.
Li & Wu Expires January 5, 2015 [Page 1]
Internet-Draft Requirements of IGP for Central Control July 2014
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. Overview of Central Control Architecture . . . . . . . . . . 3
3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 3
3.2. Deployment Mode . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements of IGP for Central Control . . . . . . . . . . . 4
4.1. Building Connectivity . . . . . . . . . . . . . . . . . . 4
4.2. Roles Auto-Discovery . . . . . . . . . . . . . . . . . . 5
4.3. Capability Advertisement . . . . . . . . . . . . . . . . 5
4.4. Network Topology Acquirement . . . . . . . . . . . . . . 5
4.5. Application Specific Requirement . . . . . . . . . . . . 6
4.6. Summary of IGP Extension Requirements . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Interior Gateway Protocol(IGP) such as IS-IS[ISO.10589.1992] or
OSPF[RFC2328] is a fundamental building block for traditional routing
system which is based on distributed computation model. Routing in
networks based on centralized computation model such as Software
Defined Network(SDN) may require special IGP extension to facilitate
its operation in multi-domain, multi-region, or multi-layer networks.
This document introduces an architecture of deploying IGP for
central-controlled network, but it does not aim to provide a detailed
description of all the architectural components. It also specifies a
Li & Wu Expires January 5, 2015 [Page 2]
Internet-Draft Requirements of IGP for Central Control July 2014
set of functional requirements which can be fulfilled by IGP with
proper extension for the central-controlled network.
The internet is the most popular network which is based on
distributed computation model. The architecture and requirements
this document proposes here are not going to be used to contradict or
replace current internet model but rather can be used to augment
functionality in the scenarios where the Internet model can not
supply adequate solutions.
2. Terminology
SDN: Software Defined Network
IGP: Interior Gateway Protocol
IS-IS: Intermediate System-Intermediate System
OSPF: Open Shortest Path First
BGP: Border Gateway Protocol
3. Overview of Central Control Architecture
This section gives an overview of the architecture of IGP-based
central control. It can help to get a good understanding when
reading the detailed requirements in next section. As stated above,
this section does not aim to provide a detailed explanation for each
building block of the architecture.
3.1. Reference Model
The following figure depicts a typical architecture of IGP-based
central control. It consists of two essential network elements:
controller and client. The controller controls all the clients
within its administrative domain by communicating with them using IGP
protocols such as IS-IS or OSPF. And the controllers will also
exchange the information between each other through some protocol
extensions which is out of scope of this document.
Li & Wu Expires January 5, 2015 [Page 3]
Internet-Draft Requirements of IGP for Central Control July 2014
+------------------------------+ +------------------------------+
| Central Control Domain 1 | | Central Control Domain 2 |
| +----------+ | | +----------+ |
| | | | | | | |
| | Central |------------------------| Central | |
| |Controller| | | |Controller| |
| | | | | | | |
| +----------+ | | +----------+ |
| / \ | | / \ |
| IGP IGP | | IGP IGP |
| / \ | | / \ |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | | | | | |
| | CLIENT | ..IGP..| CLIENT | | | | CLIENT | ..IGP..| CLIENT | |
| | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | |
| | | | | | | | | | | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Figure 1: An Architecture of IGP-based Central Control
3.2. Deployment Mode
The controller can run on a general-purpose server or a network
device. If the controller runs on a network device, it supports both
central-controlled functionality and forwarding functionality. In
this scenario, besides the centralized point of controlling, the
controller can also work as a centralized point of forwarding to
receive traffic from one node to others. The forwarding model in
this scenario is just like hub-spoke forwarding model. If the
controller runs on a server, it will not be involved in the actual
forwarding. It only works as the centralized point of control to
manage 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.
4. Requirements of IGP for Central Control
4.1. Building Connectivity
IGP protocol is essential to establish connectivity in the central
control domain. When a new device connects to the this domain, the
connectivity with the other nodes and the controller should be built
at first. The connectivity SHOULD be achieved through Plug and Play
way since the number of devices in this domain can be huge. Base on
Li & Wu Expires January 5, 2015 [Page 4]
Internet-Draft Requirements of IGP for Central Control July 2014
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.
REQ 01: IGP extensions SHOULD be provided to building the
connectivity between the central controller and client nodes for the
purpose of operation and management.
4.2. Roles Auto-Discovery
As stated in the architecture, there are two basic roles in the
central control domain: controllers and clients. Both controllers
and clients MUST advertise their own roles in proper IGP protocol
extensions through IGP flooding mechanism. Through the role
information flooded in the network, if there are multiple central
controllers in the network, the controller can determine which client
nodes should be under its control or the client nodes can decide
which controller to join in.
REQ 02: IGP extensions SHOULD be provided to advertise controller and
client role information to determine the control domain of the
central controller.
4.3. Capability Advertisement
Along with the role information, the capability information of the
controller and clients nodes can also be advertised for the purpose
of capability negotiation. For example, if the controller has the
capability to control the edge client nodes of the network, after the
capability information is advertised, the edge client nodes can set
up BGP sessions with the central controller.
REQ 03: IGP extensions SHOULD be provided to advertise the capability
information of the central controller and client nodes.
4.4. Network Topology Acquirement
In traditional network, it is very difficult for the application to
get and use the topology information. The topology information is
only contained and expressed in protocols' specific link-state
messages which are obscure and difficult to fetch in application's
defend. In some scenarios, the application has to communicate with
these protocols directly to get the necessary information. In the
IGP-based central controlled network, the topology acquirement
procedures SHOULD be simplified. All topology related information
SHOULD be able to be collected by IGP. Thus the complexity of
Li & Wu Expires January 5, 2015 [Page 5]
Internet-Draft Requirements of IGP for Central Control July 2014
network operation and management can be reduced. In the IGP-base
central controlled network, the controller can get the whole topology
information of the central control domain which can be easily
provided to applications through public interface.
REQ 04: IGP extensions SHOULD be provided to unify the topology
information acquirement.
4.5. Application Specific Requirement
Based on the central control architecture, new application can be
proposed such as:
-- Centralized MPLS TE: In the IGP-based Central Controlled network,
the controller can implement better traffic engineering functionality
based on complete topology information and state information of the
whole network.
-- Applications based on global label allocated by IGP:
[I-D.li-mpls-global-label-usecases] proposes possible use cases based
on MPLS global label. IGP extensions can be introduced to allocate
global labels by the central controller to client nodes to support
corresponding applications.
These IGP extensions are application-specific and out of scope of
this document.
4.6. Summary of IGP Extension Requirements
REQ 01: IGP extensions SHOULD be provided to building the
connectivity between the central controller and client nodes for the
purpose of operation and management.
REQ 02: IGP extensions SHOULD be provided to advertise controller and
client role information to determine the control domain of the
central controller.
REQ 03: IGP extensions SHOULD be provided to advertise the capability
information of the central controller and client nodes.
REQ 04: IGP extensions SHOULD be provided to unify the topology
information acquirement.
5. IANA Considerations
TBD.
Li & Wu Expires January 5, 2015 [Page 6]
Internet-Draft Requirements of IGP for Central Control July 2014
6. Security Considerations
TBD.
7. References
7.1. Normative References
[ISO.10589.1992]
International Organization for Standardization,
"Intermediate system to intermediate system intra-domain-
routing routine information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO
Standard 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.li-mpls-global-label-usecases]
Li, Z., Zhao, Q., Yang, T., and R. Raszuk, "Use Cases of
MPLS Global Label", draft-li-mpls-global-label-usecases-02
(work in progress), July 2014.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Nan Wu
Huawei Technologies
Boston, MA
USA
Email: huaimo.chen@huawei.com
Li & Wu Expires January 5, 2015 [Page 7]
