Internet Research Task Force H. Yin Internet-Draft H. Xie Intended status: Informational T. Tsou Expires: December 29, 2012 Huawei Technologies D. Lopez P. Aranda Telefonica I+D R. Sidi ConteXtream June 27, 2012 SDNi: A Message Exchange Protocol for Software Defined Networks (SDNS) across Multiple Domains draft-yin-sdn-sdni-00.txt Abstract This draft proposes a protocol SDNi for the interface between Software Defined Networking (SDN) domains to exchange information between the domain SDN Controllers. It defines the concept of a SDN domain; its need, what are its components and how SDNi helps in inter domain communication. 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 December 29, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Yin, et al. Expires December 29, 2012 [Page 1] Internet-Draft SDNi protocol June 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation Behind SDN . . . . . . . . . . . . . . . . . . . . 5 3. SDN Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 4. SDN Functionality . . . . . . . . . . . . . . . . . . . . . . 8 5. SDN Domains . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. SDNi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. SDNi Message . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. SDNi Protocol . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Practical Considerations . . . . . . . . . . . . . . . . . 11 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Yin, et al. Expires December 29, 2012 [Page 2] Internet-Draft SDNi protocol June 2012 1. Introduction Software Defined/Driven Networking (SDN) is generally defined as an emerging network architecture where network control is decoupled from forwarding and is directly programmable. This migration of control, formerly tightly bound in individual network devices, into accessible computing devices enables the underlying infrastructure to be abstracted for applications and network services, which can treat the network as a logical or virtual entity. SDN focuses on four key features: o Separation of the control plane from the data plane. o A centralized controller and view of the network. o Open interfaces between the devices in the control plane(controllers) and those in the data plane. o Programmability of the network by external applications. The centralized view and the separation of the control plane and the data plane means that the SDN controller can create a physical topology of how nodes are connected and, based on some combination of algorithms, create paths through the network. Finally, the paths are programmed into the devices' forwarding engines. That allows the SDN controller to better manage traffic flows across the entire network and react to changes quicker and more intelligently. How well the controller defines those paths is, of course, critical to the operation of an SDN. The controller is akin to a computer's operating system (a network- control operating system, if you will) on which applications are written. It communicates with the underlying network hardware (switches and routers) through a protocol such as OpenFlow. Different types of SDN controller software, then, are analogous, in certain respects, to Windows, Linux, and Mac OS X. What's more, just like those computer-based operating systems, today's controller software is not interoperable. As much as OpenFlow and SDN have been conflated and intertwined in the minds of many, we need to understand that SDN controllers are at higher layer of network abstraction, providing a platform for network applications and a foundation for networking programmability. OpenFlow is just an underlying protocol that facilitates interaction between the controller and data-forwarding tables on switches. Due to the great potentials of SDN and the unique requirements of Yin, et al. Expires December 29, 2012 [Page 3] Internet-Draft SDNi protocol June 2012 Data Center Networks (DCNs), Data Centers are likely to become a first place where SDN could be deployed. We envision that SDN could be gradually adopted by enterprise networks and then by carrier networks due to its unique, attractive features. When deploying SDN in large- scale distributed networks, we expect to see a collection of deployments limited to portions of a bigger network (referred to as SDN domains). In other words, the operator of a large-scale enterprise / carrier network should divide the whole networks into multiple connected SDN domains, where each of such domains corresponds to a relatively small portion of the whole network. Such a divide-and- conquer methodology not only allows gradual deployment and continuous evolution, but also enables flexible provisioning of the network. With the deployment of multiple SDN domains comes the issue of exchanging information between these domains. This draft defines the concept of an SDN domain and proposes a protocol SDNi as a protocol for interface between inter SDN domains. 1.1. Terminology While the definition of software define/driven networks is still "nebulous" to some extent, we refer to as SDN the networks that implement the separation of the control and data/forwarding planes and software defined/driven interactions between these two separated planes. SDN provides capability of network openness in that applications can program networking devices via APIs. The software defined/driven interactions could be similar to OpenFlow or the like. However, how the two separated planes interact is not a focus of this draft. Networking devices: networking devices are hardware devices or software elements capable of forwarding data packets and communicating with Network Operating System (NOS). Network Operating System (NOS): NOS is software responsible for monitoring and controlling a network system. It has whole knowledge of the underlying network topology and resources. NOS provides a programmatic platform based on the abstraction of the underlying network devices to applications by means of appropriate virtual elements, controlled by APIs that provide access to network functions and common functionalities. It facilitates network access and control to applications by translating their requests to actions on networking devices. The traditional device control plane can be built within NOS or above NOS. SDN controller: SDN controller represents a SDN open platform, and responsible for managing the platform. With or without NOS, SDN Yin, et al. Expires December 29, 2012 [Page 4] Internet-Draft SDNi protocol June 2012 controller implements SDN's functionality. A general SDN controller is a software entity that opens SDN APIs to applications, and translates application's request to actions on network devices using proprietary protocol or OpenFlow -like protocol with or without NOS's supports. The SDN controller can reside in an NOS or run separately on a server in network. SDN controller-based applications: Applications interacting with underlying networks via SDN controller. They can run inside the controller or they can be (virtual) appliances distributed throughout the network and serve some (specific) high-function and have the controller configure the network devices to steer traffic through those elements selectively according to SDN policy. Some controllers leverage OpenFlow exclusively, and others are (or will be) capable of accommodating other protocols and mechanisms to achieve the same practical result. A normal OpenFlow controller can be integrated within NOS or run within SDN controller depending on implementation. SDN-capable devices: networking devices are capable of communicating with NOS/SDN controller using proprietary protocol or standard protocol, like OpenFlow. The devices which do not support the proprietary protocol or OpenFlow are normal devices. An SDN domain is a portion of a network infrastructure, consisting of numerous connected networking devices that are SDN-capable and NOS that supports proprietary protocol or OpenFlow. A SDN domain controller (SDN controller) can cover multiple NOSs, means it can communicating with multiple NOSs via some proprietary protocol or NOS APIs, or it can communicates with OpenFlow-enabled devices directly if OpenFlow protocol is supported in the controller. An SDN domain can be as small as a sub-network of a dozen devices or as large as a medium/large data center network. An network can consist of one or many SDN domains. Hence an inter-SDN domain protocol is needed. 2. Motivation Behind SDN There has been a great deal of innovation in networking software but not that much in networking. Networks are still stuck in the past with routing algorithms that change very slowly or with primitive network management. Computation and storage have been virtualized, creating a more flexible and manageable infrastructure, but networks are still hard to manage. Networking is built with limited view of application needs. Networks used to be simple: basic Ethernet/IP straightforward, easy to manage but new application requirements have led to control plane complexities. Each control requirement leads to Yin, et al. Expires December 29, 2012 [Page 5] Internet-Draft SDNi protocol June 2012 new mechanisms and so networks continue to grow more complex. By simplifying network's structures and allowing applications to take part in the control of networks, SDN provides innovative principles of networking system construction. With the trends of the network development that moving from networks to more and more services and applications, applications are taking more roles in network routing decisions and affecting the traditional network functionalities and behaviors. As an interaction and control point between applications/ services and underlying networks, SDN controller is a key point in SDN networks and clearly a SDNi protocol among controllers is clearly a necessity in our opinion. 3. SDN Architecture As software-defined networking gains traction, vendors and enterprises will generally adopt a three-tiered architecture as seen in Figure 1. Yin, et al. Expires December 29, 2012 [Page 6] Internet-Draft SDNi protocol June 2012 +-----+ +-----+ | App | | App | +-----+ +-----+ | | | RESTFUL APIs | | | +--------------------------+ SDNi +-----------------+ | | protocol | | | SDN Controller |<---------->| SDN Controller | | | | | +--------------------------+ +--------------- -+ / \ \ /<-----+ \ ----- / | \ \ / | \ \ +-----------+ | +-----------+\ | | proprietary | | \ | NOS | protocol/API | NOS | \ | | | | | \ +-----------+ | +-----------+ \ / | \ | / \ \ / | \<---+ / \ \ ..... / | \ / \ \ .... : / | \ / \ \ : : +----+ +----+ +----+ +----+ +----+ +-------+ : : | ND | | ND | | ND | | ND | | ND | | OF SW | : : +----+ +----+ +----+ +----+ +----+ +-------+ : : : : : : SDN Domain : : ND: Networking Device : : OF SW: OpenFlow-enabled switch : :.................................................................: Figure 1: An Architecture For SDN The architecture's first tier will involve the physical network equipment, including Ethernet switches and routers. This forms the dataplane. The middle tier consists of the controllers that facilitate setting up and tearing down flows and paths in the network leveraging information about capacity and demand obtained from the networking gear through which the traffic flows. This forms the control plane, NOS and SDN controller/platform over it. The top tier will involve applications to direct security, management and other specific functions through the controller. However, instead of relying on proprietary software running on each switch to control its forwarding behavior, switches in a SDN architecture are controlled by Yin, et al. Expires December 29, 2012 [Page 7] Internet-Draft SDNi protocol June 2012 a Network OS (NOS) that collects information and manipulates their low-level forwarding plane, providing an abstract model of the network topology to the SDN controller hosting the applications. Applications can adapt the network behavior to suit specialized requirements, for example, providing network virtualization services that allow multiple logical networks to share a single physical network - similar to the way in which a hypervisor allows multiple virtual machines to share a single physical machine. These controller-based applications will serve the same roles that physical appliances play in the network today. For example, network architects who are building software-defined networks could deploy applications like a virtual load balancer, a virtual intrusion detection system (IDS), or a virtual firewall on a controller. The application could tap into information the controller possesses about traffic patterns, application data and capacity. Cloud computing applications could be a big beneficiary of software-defined networking and OpenFlow because these technologies make provisioning in a multi-vendor virtual environment much simpler. For instance a controller-based load balancing application could automate the movement of workloads among virtual machines by using the controller's view of the capacity of individual network devices. SDN controller is a software module in a SDN domain; logically it represents the highest control point in a SDN domain network, and physically it can reside in NOS or run independently at a separate server. SDN controller provides north- bound APIs to user applications, and interacts with NOS to collect network information for applications. 4. SDN Functionality This section provides a detailed explanation of the role of SDN controller in SDN. SDN is constructed through the separation of control plane and forwarding plane of networking devices. The decoupling is achieved by turning the network control problem into a state management problem, and only exposing the state to be managed to the application, and not the mechanisms by which it arrived. Applications operate over control traffic, flow table state, configuration state, port state, counters, etc. However, how this data is pulled into the controller, and how any changes are pushed back down to the switch is not the application's concern. It can just use the controller API to modify network state which in turn will be translated to necessary commands on the relevant devices to have the new state correctly applied on the network. Yin, et al. Expires December 29, 2012 [Page 8] Internet-Draft SDNi protocol June 2012 SDN controller should provide following functionality: o Provide northbound APIs for applications so they can program underlying network properties such as bandwidth assignments, network isolation, routing properties, redundancy properties, or security requirements. o Provide covered SDN domain network topology view to applications so that applications can define data flow and flow path within the view. o Respond and adapt to the network conditions and provide event- handling mechanisms for applications so that they can receive feedback and adapt accordingly. o Have covered SDN domain network services and resources views so that the controller can coordinate application's requests. o Work with NOS/control plane to collect underlying device information and translate application's request to actions on network devices and feed into NOS/control plane. o Act as the controller of physical devices, such as the OpenFlow control mechanism if such mechanism is not implemented in NOS[1]. 5. SDN Domains An SDN domain is a portion of the network determined by the network operator. It has a SDN controller to control the domain, it can cover multiple NOS or communicate with some SDN-capable devices directly. Each NOS typically consists of numerous inter-connected SDN-capable devices. An example of such NOS is illustrated in [ONIX]. The SDN controller aggregates network topology views from multiple NOS and maintain a global network view of networks covered by the domain. The controller is responsible for dispatching and disseminating application's request to corresponding NOS. Two SDN domains are adjacent if there is a physical link between two underlying networks. Inside each SDN domain, its controller may define domain-specific policies on information importing from devices, aggregating, and exporting to external entities. Such policies may not be made public; therefore, other domain controllers may not know the existence of such policies for any given SDN domain. When receiving an application request for certain network resources, the SDN controller should decide if the request can be satisfied. If Yin, et al. Expires December 29, 2012 [Page 9] Internet-Draft SDNi protocol June 2012 it can be satisfied, the controller should instruct the devices in its domain by updating them with a set of data/forwarding rules so that the devices could implement such rules and fulfill the request. 6. SDNi SDNi is a protocol for interfacing SDN domains. It is responsible for coordinating behaviors between SDN controllers and exchange control and application information across multiple SDN domains. SDNi is an "east-west" protocol between SDN controllers, as an analogy to OpenFlow being a "north-south" protocol between NOS and Network devices. As such, SDNi should be a protocol implemented by the NOS (the same as OpenFlow or any other control protocols as mentioned above) and how the applications/SDN controllers that run in the NOS use this protocol (i.e. what is the API to use it) is out of scope of this document. SDNi protocol should be able to o Coordinate flow setup originated by applications, containing information such as path requirement, QoS, SLA etc. across multiple SDN domains. o Exchange reachability information to facilitate inter-SDN routing. This will allow a single flow to traverse multiple SDNs and have each controller select the most appropriate path when multiple such paths are available. SDNi depends on the types of available resources and capabilities available and managed by the different controllers in each domain. Hence it is important to implement SDNi in a descriptive and open manner so that new capabilities offered by different types of controllers will be supported. Since SDN in essence allows for innovation, it is important that data exchanged between controllers will be dynamic in nature, i.e. there should be some meta-data exchange that will allow SDNi to exchange information about unknown capabilities. 6.1. SDNi Message The types of messages exchanged via SDNi can be: o Reachability update o Flow setup/tear-down/update request (including application capability requirement such as QoS, BW, latency etc.) Yin, et al. Expires December 29, 2012 [Page 10] Internet-Draft SDNi protocol June 2012 o Capability update (including network related capabilities such as BW, QoS etc. and system and software capabilities available inside the domain). 6.2. SDNi Protocol SDNi is used to exchange information between SDN domains that are under the control of a single network operator or collaborating operators. One way to implement SDNi is to use extension of BGP and SIP over SCTP protocols to exchange information. 6.3. Practical Considerations SDN domains are built by network operator for flexible administration purpose. It depends on the scale of underlying network that the operator decides how to divide whole network into SDN domains. For some small-scale data centers, only one SDN domain may be enough. For a Service Provider with large carrier network, it is most likely better to divide the network into SDN domains as centralizing the control onto a single NOS/controller will create a bottleneck. For example, Operator can divide its network into different SDN domains based on physical locations. It can lease such part of its network to local content provider, etc. Such deployment scenario requires an SDN controller providing powerful network service capability to applications. Also defining domains and interconnections between them involves more than simple connections between SDN boxes; it requires to consider various aspects such as to work out how their network topologies connect together, which neighbor controller boxes to talk to and how to get their addresses, what rights and policies control the conversation etc. Other aspects to be considered are who is allowed to deploy 'programs' on the SDN infrastructure what actions can a 'program' execute depending on who deployed them: the SDN network manager is likely in control to deploy 'programs' on the SDN infrastructure. The focus then is on how the deployed programs might affect other domains and what mechanism we want to use to communicate this effect to the other domains. 7. Conclusions Add any conclusions Yin, et al. Expires December 29, 2012 [Page 11] Internet-Draft SDNi protocol June 2012 8. Acknowlegements The authors would like to thank Aditi Vira for editing the draft. 9. Security Considerations o What actions are 'applications' allowed to execute? o How is the security policy propagated to other SDN domains. o An application should not be able to do a DoS attack (either willingly or unwillingly) 10. IANA Considerations This document makes no specific request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 11. Informative References [1] Xie, H., Yin, H., Tsou, T., and V. Hilt, "draft-xie-alto-sdn-use-cases-00.txt", June 2012. Authors' Addresses Hongtao Yin Huawei (USA) 2330 Central Expy Santa Clara, CA 95050 USA Phone: Email: Hongtao.yin@huawei.com Yin, et al. Expires December 29, 2012 [Page 12] Internet-Draft SDNi protocol June 2012 Haiyong Xie Huawei & USTC 2330 Central Expy Santa Clara, CA 95050 USA Phone: Email: Haiyong.xie@huawei.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: Email: Tina.Tsou.Zouting@huawei.com Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 84 Madrid, 28006 Spain Phone: Email: diego@tid.es Pedro Andres Aranda Telefonica I+D Don Ramon de la Cruz, 84 Madrid, 28006 Spain Phone: Email: pedro.aranda@tid.es Yin, et al. Expires December 29, 2012 [Page 13] Internet-Draft SDNi protocol June 2012 Ron Sidi ConteXtream 3600 West Bayshore Rd. Palo Alto, CA 94303 USA Phone: Email: ron@contextream.com Yin, et al. Expires December 29, 2012 [Page 14]