Network Working Group T. Nadeau, Ed. Internet-Draft CA Technologies, Inc. Intended status: Informational Expires: April 31, 2012 P. Pan, Ed. Infinera October 31, 2011 Software Driven Networks Problem Statement draft-nadeau-sdn-problem-statement-01 Abstract Software Driven Networks (SDN) is an approach to networks that enables applications to converse with and manipulate the control software of network devices and resources. SDNs are comprised of applications, control software, and interfaces to services that are hosted in an overlay or logical/virtual network as well as those possibly same components that comprise the underlying physical network. Modern applications require the ability to easily interact and manipulate these resources. Applications can benefit from knowing the available resources and from requesting that the network makes the resources available in specific ways. To this end, there is a requirement to couple applications more closely to the underlying resources on which they depend, consume and interact with. SDN infrastructure and components exist in most deployed networks today. Some of these components are being standardized by various organizations, as as well some being already standardized by the IETF. However, no standards or open specifications currently exist to facilitate end-to-end operation of a software defined network, specificlly one that provides open APIs for applications to control the network services and functions offered by device control planes or other "controlling" software. The goal of this document is to outline the problem area of SDN for the IETF. 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. Nadeau Expires April 30, 2012 [Page 1] SDN Problem Statement October 31, 2011 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 September 30, 2012. Copyright Notice Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . .. . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . .. . 5 1.2. SDN Background . . . . . . . . . . . . . . . . . . . .. . 9 2. SDN Interconnect Use Cases . . . . . . . . . . . . . . . .. . 9 3. SDN Interconnect Model & Problem Area for IETF . . . . . .. . 11 3.1. Candidate SDN Problem Area for IETF . . . . . . . . . . . 13 4. Design Approach for Realizing the SDN APIs . . . . . . . . . 15 4.1. Relationship to the OSI network model . . . . . . . .. . 15 4.2. "Reuse Instead of Reinvent" Principle . . . . . . . .. . 16 4.3. Application to SDN Orchestrator Interface . . . . . . . . 16 4.4. SDN Orchestrator to Plug-In Interface . . . . . . . . . . 18 4.5. SDN Logging Interface . . . . . . . . . . . . . . . . . . 19 4.6. SDN Orchestrator to Location Services Interface . . . . . 20 4.7. SDN Orchestrator to Policy Database Interface . . . . . . 20 4.8. SDN Orchestrator to SDN Orchestrator Interface. . . . . . 20 5. Gap Analysis of relevant Standardization and Research Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Nadeau Expires April 30, 2012 [Page 2] SDN Problem Statement October 31, 2011 5.1. Open Network Forum . . . . . . . . . . . . . . . . . . . . 21 6. Relationship to relevant IETF Working Groups . . . . . . . . . 23 6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 29 A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 29 A.2. Prioritizing the SDN Work . . . . . . . . . . . . . . . . 30 A.3. Related standardization activities . . . . . . . . . . . . 31 A.4. Related Research Projects . . . . . . . . . . . . . . . . 35 A.4.1. IRTF Cross Stratum Optimizaiton Research Group . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction Software Driven Networks (SDN) is an approach to networks that enables applications to converse with and manipulate the control software of network devices and resources. Modern applications require the ability to easily interact and manipulate resources provisioned and controlled by networks. Applications can benefit from knowing the available resources and from requesting that the network makes the resources available in specific ways. To this end, there is a requirement to couple applications more closely to the underlying resources on which they depend, consume and interact with. In particular, modern applications require interaction with and the manipulation of both physical and virtual compute, storage and connectivity resources and abstract interfaces to these things. These abstractions must also allow applications to manipulate resources at varying levels of granularity, policy and security. It is also worth noting that modern Software Driven Networks (SDNs) are comprised of applications, control software, and interfaces to services that are hosted in an overlay or logical/virtual network as well as those possibly same components that comprise the underlying physical network. These services include path computation, topology discovery, firewall services, domain name services, network address translation services, virtual private networks and the like. These services and elements may be physical or virtual. One requirement is to create a means by which applications can Nadeau Expires April 30, 2012 [Page 3] SDN Problem Statement October 31, 2011 communicate with the control planes of the underlying network devices or entities which control and own network resources on which they depend. Note that the "control planes" of network devices will be referred to as "controlling software" to abstract away the concept of the software that controls a device's data plane. The control planes of devices, whether physically co-located with a device and its data plane, or externally located for example in the case of an OpenFlow "controller", provide coherent control of the network apparatus. However, the "controlling software" of a virtual machine might be a hypervisor. There is a desire by network operators and service providers to control, configure, mange or set policy on controlling software and do so using applications for different network control and manipulation options. Software Defined Networks infrastructure exists in most deployed networks today. Some of these components are being standardized by various organizations, as as well some being already standardized by the IETF. However, no standards or open specifications currently exist to facilitate end-to-end operation of a software defined network, specificlly one that provides open APIs for applications to control the network services and functions offered by device control planes or other "controlling" software. The goal of this document is to outline the problem area of SDN for the IETF. Section 2 discusses the use cases for SDN. Section 3 presents the SDN model and problem area to be considered by the IETF. Section 4 discusses how existing protocols can be reused to define the SDN interfaces, service discovery and object models. 1.1. Terminology This document uses the following terms: Control Plane: In a router or switch, the control plane is the part of the router firmware/software architecture that is in charge of the logic behind things such as constructing a map of the network topology, running network protocols or management functions and then ultimately instructing the device's data plane to realize any forwarding or switching actions that must be enabled. While conceptually separate in a logical sense, the control plane is often physically separated from the data plane of a device either by running on a processor dedicated to this function, or even run externally from the device on another device or process (i.e.: in the case of OpenFlow, centralized routing, etc...). Data Plane: This is the part of a network device that is responsible Nadeau Expires April 30, 2012 [Page 4] SDN Problem Statement October 31, 2011 for the actual (i.e.: physical) forwarding and manipulation of data that comes into and is transmitted out of a device. The data plane of a device is typically very tightly bound to the specific nature of the hardware of that particular forwarding component of a device, and as such is often kept seperated from the more generic control plane. An example of a data plane would be the switching fabric and port processors of a router. Controlling Software: In the case of network devices, this is analagous to the control plane. However, in the case of virtualization technologies, this may be present in the form of a hypervisor, for example. Application Programming Interface (API): is a particular set of rules and specifications that software programs can follow to communicate with each other. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers. Software As a Service (SaaS): Sometimes referred to as "on-demand software," is a software delivery model in which software and its associated data are hosted by a service provider and connected back to the customer via The Internet. These are sometimes referred to as "cloud services" as well. Managed Network Service Provider (MSP): Provides network-based connectivity and services to End Users, as well a managed service. For example, one popular MSP might offer virtualized machines (VMs) and a virtual private network (VPN) connectivity between these VMs with external connectivity to this VPN of machines via a managed business grade metro ethernet link to the customer's premise. Communications Service Provider (CSP): A traditional "telco" service provider that offers data connectivity as a service to its customers. 1.2. SDN Background Readers are assumed to be familiar with the architecture, features and operation of SDNs. For readers less familiar with the operation of SDNs, the following resources may be useful: [Provide references TBD] Nadeau Expires April 30, 2012 [Page 5] SDN Problem Statement October 31, 2011 2. SDN Use Cases An increasing number of MSPs are deploying SDNs in order to both offer more cost-effective service offerings, but also to reduce internal costs of managing and operating those services. Since SDNs allow for a more consistent and shorter time-to-market model of developing management software for various network-based services, service providers are moving towards using various proprietary schemes for this. SDNs are being used to deliver various types of services that provide externally consumable SaaS offerings, as well as those used internally to manage and manipulate their network infrastructure. Some MSPs operate over multiple geographies and couple infrastructure from different MSPs, SPs and possibly SaaS offerings. In these cases, it is important to provide the MSP that offers the ultimate service to the customer with a clean, consistent and effient interface to all of the infrastructure it relies on. Furthermore, from their perspective, being able to unwind the "russian doll" of nested infrastructure and services that might be rolled together for their service offering in cases where trouble shooting is required for example, is paramount. In the simplest of cases it may not seem obvious that the use of a standardized SDN infrastructure would be necessary; however, in typical medium and large data center offerings that are quite common today, the management of the physical elements is a small part of the larger puzzle for the MSP or CSP. When network elements become virtualized and are then used to construct components of services being offered, an operator can quickly multiply the number of management "devices" or more commonly "elements", by many orders of magnitude. It is here that the problem of lack of open interfaces for SDN component interconnection and discovery becomes clear. Again, for this requirement, SDN operators (over-the-top SDN operators or NSPs) are faced with a lack of open specifications and best practices. Use cases for SDN Interconnection are further discussed in 3. SDN Model & Problem Area for The IETF Managing a network of deployed SDN components involves interactions among multiple different functions and components that exist within the network. Some of these components are virtual and some of these Nadeau Expires April 30, 2012 [Page 6] SDN Problem Statement October 31, 2011 components are real; all should be made available to be managed and manipulated, given the appropriate access, authentication, and policy hurdles have been crossed. Only some of those require standardization. The SDN model and problem area proposed for IETF work is illustrated in Figure 1. The candidate problem area (and respectively the non-goals) for IETF work are shown in Figure 2. |--------Application v ^ +----------+ | | Location | | <--- Application-to- | Services | | Ochestrator protocol +----------+ v ^ ReST API | +-------------------+ +------------------+ |----| Orchestrator_0..N + -----> | Policy Data Base | +-------------------+ +------------------+ ^ | <--- Orchestrator-to-Plug-In Protocol | V +----------+ | Plug-In | | ReST API | +----------+ ^ * V +******************+ * Control Software * * For Device_0..M * +******************+ ^ = V +=================+ = Data Plane = = For Device_0..M = +=================+ <--> interfaces and objects inside the scope of SDN +--+ <**> interfaces and objects may be within the scope of SDN +**+ insofar as modifcations are needed to support SDN Nadeau Expires April 30, 2012 [Page 7] SDN Problem Statement October 31, 2011 <==> interfaces and objects outside the scope of SDN +==+ Figure 1: SDN Problem Area 3.1. Candidate SDN Problem Area for IETF Listed below are the the interfaces required to connect an application with the SDN components and protocols in a network. This constitutes the problem space that is proposed to be addressed by a potential SDN working group in the IETF. The use of the term "interface" is meant to encompass the protocol over which SDN data representations (e.g. SDN Metadata records) are exchanged as well as the specification of the data representations themselves (i.e. what properties/fields each record contains, its structure, etc.). o SDN Orchestrator-to-Application Interface: This interface allows the SDN Orchestrator or "controller" system to be interconnected with applications. This interface may support the following: * Allow bootstrapping of the interface between the Orchestrator and interested applications. * Allow the applications to authenticate. * Allow applications to learn of which objects they have authorization to manipulate, or to interact with objects beloning to controlling software. o SDN Orchestratort-to-Plug-In Interface: This interface allows the SDN Orchestrator to interconnect with the controlling software of devices. o SDN Orchestratort-to-Policy Database Interface: This interface allows the SDN Orchestrator to interconnect with policy, authentication and authorization databases. o SDN Orchestratort-to-location services Interface: This interface allows the SDN Orchestrator to interconnect with location services in order to: * Register itself as a local Orchestrator. * Allow other Orchestrators and applications to find it. o SDN Orchestrator-to-SDN Orchestrator Interface: This interface allows one SDN Orchestrator to interconnect with one or more Orchestrators in order to: * Form a failover/high-availability relationship * distribute mappings of controlling software-to-Orchestrator Nadeau Expires April 30, 2012 [Page 8] SDN Problem Statement October 31, 2011 * bootstrapping of the other SDN Orchestrators. * configuration of the other SDN Orchestrators. o SDN Logging interface: This interface allows the Logging system in interconnected SDN Orchestrators to communicate the relevant activity logs in order to allow log consuming applications to operate in multi-SDN Orchestrator environments. For example, this interface can be used to collect logs from SDN Orchestrators to provide reporting and monitoring to the M/CSP of SDN activities. As part of the development of the SDN interfaces and solutions it will also be necessary to develop and agree on common mechanisms for how to define the object schemas used to query object model stores of each controlling software element. 4. Design Approach for Realizing the SDN APIs This section expands on how SDN interfaces can reuse and leverage existing protocols. First the "reuse instead of reinvent" design principle is restated, then each inetrface is discussed individually with example candidate protocols that can be considered for reuse or leverage. This discussion is not intended to pre-empt any WG decision as to the most appropriate protocols, technologies and solutions to select to solve SDN but is intended as an illustration of the fact that the SDN interfaces need not be created in a vacuum and that reuse or leverage of existing protocols is likely possible. 4.1. Relationship to the OSI network model The SDN interfaces called out above in Section 3.1 within the SDN problem area all operate at the application layer (Layer 7 in the OSI network model). Since it is not expected that these interfaces would exhibit unique session, transport or network requirements as compared to the many other existing applications in the Internet, it is expected that the SDN interfaces will be defined on top of existing session, transport and network protocols. 4.2. "Reuse Instead of Reinvent" Principle Although a new application protocol could be designed specifically for SDN we assume that this is unnecessary and it is recommended that existing application protocols be reused or leveraged such as HTTP[RFC2616] to devine the SDN interfaces. 4.3. Application to SDN Orchestrator Interface 4.4. SDN Orchestrator to Plug-In Interface Nadeau Expires April 30, 2012 [Page 9] SDN Problem Statement October 31, 2011 4.5. SDN Logging Interface The SDN Logging interface enables details of logs or events to be exchanged between interconnected SDN Orchestrators, where events could be: o Log lines related to the connection of a new Orchestrator, or disconnection of an existing one. o A fail-over, switch-over event. Similarly, high-availability synchronication messaging. o Real-time or near-real time events before, during or after SDN Orchestrator commands noting which application instructed it to perform the operation. o Operations and diagnostic messages. Several protocols already exist that could potentially be used to exchange SDN Orchestrator logs including SNMP Traps or Informs, syslog, s/ftp, HTTP POST, or ReST, etc. although it is likely that some of the candidate protocols may not be well suited to meet all the requirements of SDN. For example SNMP Traps pose scalability concerns, and syslog may have potential compatability issues. Although it is not necessary to define a new protocol for exchanging logs across the SDN Logging interface, a SDN WG would still need to specify: o The recommended protocol to use. o A default set of log fields and their syntax & semantics. Today there is no standard set of common log fields across different content delivery protocols and in some cases there is not even a standard set of log field names and values for different implementations of the same delivery protocol. o A default set of events that trigger logs to be generated. 4.6. SDN Orchestrator to Location Services Interface 4.7 SDN Orchestrator to Policy Database Interface 4.8 SDN Orchestrator to SDN Orchestrator Interface 5. Gap Analysis of relevant Standardization and Research Activities There are a number of other standards bodies and industry forums that are working in areas related to SDNs, and in some cases related to SDN. This section outlines any potential overlap with the work of the SDN WG and any component that could potentially be reused by Nadeau Expires April 30, 2012 [Page 10] SDN Problem Statement October 31, 2011 SDN. A number of standards bodies have produced specifications related to SDNs, namely: o Open Network Forum has a dedicated specification called Open Flow which specifies a relationship to an external "control plane" interfacing to a Hardware Abstraction Layer (HAL) that is implemented on Open Flow-capable hardware. 6. Relationship to relevant IETF Working Groups 6.1. ALTO As stated in the ALTO Working Group charter [ALTO-Charter]: "The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (SDN) and mirror selection." In particular, the ALTO service can be used by an SDN-aware application to improve its selection of an SDN Orchestrator. For example, an application wishing to provision MPLS L3 VPNs on behalf of some virtual machines in a local data center cluster may with to take advantage of the ALTO service in its decision for selecting a relatively close SDN Orchestrator to complete its operations. However, the work of ALTO is complementary to and does not overlap with the work proposed in this document because the integration between ALTO and a SDN would fall under the category of using an existing protocol. One area for further study is whether additional information should be provided by an ALTO service to facilitate SDN Orchestrator selection. For example, loading or fail-over characterists could be one consideration. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Nadeau Expires April 30, 2012 [Page 11] SDN Problem Statement October 31, 2011 8. Security Considerations SDNs comes with a range of security considerations such as how to enforce control of and access to objects managed by the SDN Orchestrators and making sure that in line with the M/CSP policy. 9. Acknowledgements The authors would like to thank David Meyer, Ping Pan, Lyndon Ong, Danny McPhereson for their review comments and contributions to the text. 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. 10.2. Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [ALTO-Charter] "IETF ALTO WG Charter (http://datatracker.ietf.org/wg/alto/charter/)". [Draft-Lee] L. Young, Bernstein, G., Kim, T., Shiomoto, K., and Dios, O., "Research Proposal for Cross Stratum Optimization (CSO) between Data Centers and Networks", draft-lee-cross-stratum-optimization-datacenter-00.txt Appendix A. Additional Material Note to RFC Editor: This appendix is to be removed on publication as an RFC. A.1. Non-Goals for IETF Listed below are aspects of content delivery that the authors propose be kept outside of the scope of a potential SDN working group: o The interface between Controlling Software (i.e.: control plane) and the device's data plane. o Definition of any hardware abstraction layer (HAL) Nadeau Expires April 30, 2012 [Page 12] SDN Problem Statement October 31, 2011 A.2. Prioritizing the SDN Work A.3. Related standardization activities OpenFlow has pioneered the concept of software-defined network via a concept called a FlowVisor. It has introduced a new packet forwarding methodology to be applied on hardware or software L2 switches. OpenFlow Version 1.0 and 1.1 have been in research trials and testing in virtualized environments. The new versions will address issues such as extendibility, modularity and carrier-grade. Currently, OpenFlow does not support a mechanism to interface with network devices through the existing IP/MPLS control-plane protocols, although some work has begun to investigate this. NETCONF/YANG provides a XML-based solution for network device configuration. It has been in wide-deployment. By definition, it supports client-to-server configuration, and server-to-client alarms or feedback (The servers are the devices/systems to be configured, the clients are the network configuration/management systems). NETCONF provides support for executing configuration change transactions over multiple devices. ALTO is a server solution designed to gather network abstraction information and interface with applications (such as P2P) for more efficient traffic distribution. It does not require configuring the underlying network devices. PCE is a client-server protocol that operates in MPLS networks that enables the network operators to compute and potentially provision optimal point-to-point and point-to-multipoint connections. However, PCE does not interface with applications to optimize traffic from user applications. DMTF is a cloud computing standardization organization, which have defined many virtualization management interfaces using Restful API. However, it does not include any interface to the underlying networks. A.4. Related Research Projects A.4.1. IRTF Cross Stratum Optimizaiton Research Group Some information on SDN motivations and technical motivations in the IRTF's Cross Stratum Optimization Group [Draft-Lee]. Nadeau Expires April 30, 2012 [Page 13] SDN Problem Statement October 31, 2011 Authors' Addresses Thomas D. Nadeau (editor) CA Technologies, Inc. 273 Corporate Drive Portsmouth, NH 03801 Email: thomas.nadeau@ca.com Ping Pan Infinera Corporation 169 Java Drive Sunnyvale, CA 94089 Phone: (408) 572-5200 Email: ppan@infinera.com Nadeau Expires April 30, 2012 [Page 14]