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]