Network Working Group T. Nadeau, Ed. Internet-Draft CA Technologies, Inc. Intended status: Informational Expires: April 3, 2012 P. Pan, Ed. Infinera, Inc. October 31, 2011 Framework for Software Defined Networks draft-nadeau-sdn-framework-01 Abstract This document presents a framework for Software Defined Networks (SDN). The purpose of the framework is to provide an overall picture of the problem space of SDN and to describe the relationships among the various components necessary to manipulate the components that comprise SDNs. SDN requires the specification of several key components including an "orchestrator" and various "plug-ins" between the orchestrator function and network resources. In addition to this, an orchestrator will require interconnection with standard policy bases, as well as other orchestrators in distributed environments or insofar as to support high-availability and fault-tolerance capabilities. To this end, several interfaces and mechanisms to address issues such as enabling the orchestrator to manipulate and interact with the control planes of devices such as routers and switches, as well as a discourse between different orchestrators will be described. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. 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." Nadeau & Pan Expires April 3, 2012 [Page 1] SDN Framework October 31, 2011 This Internet-Draft will expire on April 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. SDN Orchestrator . . . . . . . . . . . . . . . . . . . . . 6 2.1. SDN Plug-In . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview of SDN Operation . . . . . . . . . . . . . . . . . . 7 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 32 4.1. SDN Orchestrator to Application Interface. . . . . . . . . 32 4.2. SDN Orchestrator Policy Base Interface . . . . . . . . . . 33 4.3. SDN Orchestrator to Plug-In Interface. . . . . . . . . . . 34 4.4. SDN Orchestrator to Orchestrator Interface . . . . . . . . 36 4.5. SDN Orchestrator Logging interface . . . . . . . . . . . . 36 4.6 SDN Control Interface . . . . . . . . . . . . . . . . . . 36 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 37 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 11.1. Normative References . . . . . . . . . . . . . . . . . . . 46 11.2. Informative References . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction Nadeau & Pan Expires April 3, 2012 [Page 2] SDN Framework October 31, 2011 The Software Driven Network (SDN) is motivated by several use cases, such as those described in . The overall problem space for SDN is described in [I-D.nadeau-sdn-problem-statement] with requirements for solutions found in [I-D.pan-sdn-requirements]. The purpose of this document is to provide an overview of the various components necessary to create SDNs. SDNs require the specification of several interfaces and mechanisms to address issues such as an orchestration point (logical or physical) and interfaces between itself, applications that wish to consume or manipulate network resorces, network resources such as router control planes, and policy and security engines. Furthermore, high availability and resilliency mechanisms also need to be defined. The intent of this document is to describe how these interfaces and mechanisms fit together, leaving their detailed specification to other documents. 1.1. Terminology This document draws freely on the terminology defined in [I-D.nadeau-sdn-problem-statement]. We also introduce the following terms: SDN Orchestrator: The entity which is the controller of control planes. Policy Engine or Database: The repository of policy information stored within a network domain. Location Services: A network service used for locating network elements. Examples include ALTO and The Domain Name System (DNS). SDN Domain: a host name (FQDN) at the beginning of a URL, representing a set of content that is served by a given CDN. For example, in the URL http://sdn.example.(com|org|net)/...rest of url... the SDN domain is sdn.example.(com|org|net). 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. Nadeau & Pan Expires April 3, 2012 [Page 3] SDN Framework October 31, 2011 SDN Plug-In: An API that abstracts a device and its object model that an SDN Orchestrator can use to communicate with that device. 1.2. Reference Model Figure 1 (reproduced from [I-D.nadeau-sdn-problem-statement]) illustrates the basic model of operation with which this document is concerned. |--------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 Nadeau & Pan Expires April 3, 2012 [Page 4] SDN Framework October 31, 2011 +**+ insofar as modifcations are needed to support SDN Figure 1: Model of Operation for SDN Note that while some interfaces are considered out of scope for SDN, and these are noted above. The overview of operation described below will show how those interfaces are used as part of an overall solution and where new protocols will be defined as well. 2. Building Blocks 2.1. SDN Orchesetrator The controler of control planes, known as the SDN Orchestrator, must be capable of requesting object models from each of the controlling software it is responsible for managing, and therefore each controlling software element must be capable of producing a self-describing object model with which the Orchestrator can use when issuing instructions to manipulate it. Furthermore, communications between the Orchestrator and the control planes must also be rationalized. To this end, the working group will define SDN "plug-ins" which are the abstracted interface to each type of control plane. The working group will also define a protocol that is used for communcations bewteen the Orchestrator and the plug-in. It should be noted that the SDN Orchestrator function is conceptually centralized in that applications SHOULD have a centralized means of locating the Orchestrator within its network. However, in reality the Orchstrator will be designed and architected so as to exist in a distributed manner if so desired operationally. Furthermore, resilliency of a SDN infrastructure and network of components is required as these elements and functional controls are to be used in highly available production environments; therefore, the working group will define mechanisms by which the SDN Orchestrator will operate in this manner as a minimum requirement. 2.2. SDN Plug-In The SDN Plug-In as shown in the figure above, is an abstraction between the SDN Orchestrator and the network resource or device control plane or "controlling software" to which it is interfacing. The purpose of this interface is as a means of abstracting the controling software from the device itself. The plug-in is also a means by which the device can negotiate its capabilities with the controller as well as exchange revision information (i.e.: SDN protocol revision identifiers). Nadeau & Pan Expires April 3, 2012 [Page 5] SDN Framework October 31, 2011 3. Overview of SDN Operation To provide a big-picture overview of the various components of SDN, let us walk through how a typical SDN Orchestrator would be deployed within a network, and then how applications would use it to interact with network resources. Include 1 use case here... (TBD) 4. Main Interfaces This section describes the main interfaces between different components of SDN. 4.1 SDN Orchestrator to Application Interface This interface allows the SDN Orchestrator or "controller" system to be interconnected with applications. This interface is sometimes referred to as a "north-bound" interface, because it points "northward" in architectural diagrams. This interface allow bootstrapping of the interface between the Orchestrator and interested applications. It will allow the applications to authenticate using one or more methods. This interface will allow applications to learn of which objects they have authorization to manipulate, or to interact with objects beloning to controlling software. 4.2 SDN Orchestrator Policy Base Interface This interface allows the SDN Orchestrator to interconnect with policy, authentication and authorization databases. 4.3 SDN Orchestrator to Plug-In Interface This interface allows the SDN Orchestrator to interconnect with the controlling software of devices. 4.4 SDN Orchestrator to Orchestrator Interface This interface allows the SDN Orchestrator to interconnect and interact with other SDN Orchestrators that exist within its SDN Domain. 4.5 SDN Orchestrator Logging interface This interface allows the Logging system in interconnected SDN Nadeau & Pan Expires April 3, 2012 [Page 6] SDN Framework October 31, 2011 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. SDN Orchestrator logs are easily exchanged off-line as a flat text file, for example, and could include the following information. o SDN Domain - the full domain name of the origin server o IP address - the IPv4 (and IPv6 if available) address of the client application or SDN Orchestrator making the request o Transaction Time - the ending time of the transfer o Time zone - any time zone modifier for the end time 4.6 SDN Control Interface The protocol used between the Orchestrator and another entity such as an application, Policy Database, Location Services or Plug-In, or another Orchestrator in order to send commands, receive replies or emit notifications is the role of the SDN Control Interface. As noted above and in [I-D.nadeau-sdn-problem-statement], the control interface may also be used for the bootstrapping of other interfaces such as the SDN Orchestrator to SDN Orchestrator interface. 5. Deployment Models Describe deployment models here. This should include a single domain of Orchestrators and applications, and other components. (TBD) 6. Trust Model There are a number of trust issues that need to be addressed by a SDN solution. In a standard SDN environment with a single Orchestrator, one policy database, one location services engine (i.e.: DNS/ALTO) and one router associated with the Orchestrator, there are a number of points of trust to consider. First, any of the interfaces bewteen the SDN elements expose Nadeau & Pan Expires April 3, 2012 [Page 7] SDN Framework October 31, 2011 trust points. Further, since the SDN Orchestrator-to-Orchestrator allows for an Orchestrator to bootstrap itself from another's active configuration, the operator must ensure that authorization is configured correctly. We expect that the detailed designs for the specific interfaces for SDN will need to take these trust issues into account. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations (Note: this section to be extended in future revision.) 9. Contributors The following individuals contributed to this document: o 10. Acknowledgements We thank ... for helpful comments on the draft. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [I-D.nadeau-sdn-problem-statement] Nadeau, T., and P. Pan, " Software Defined Network (SDN) Problem Statement", draft-nadeau-sdn-problem-statement-00 (work in progress), September 2011. [I-D.pan-sdn-requirements] Pan, P., and T. Nadeau, Nadeau & Pan Expires April 3, 2012 [Page 8] SDN Framework October 31, 2011 "Software Defined Networks (SDN) Requirements", draft-pan-sdn-requirements-00 (work in progress), September 2011. Authors' Addresses Thomas D. Nadeau 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: ping@pingpan.org Nadeau & Pan Expires April 3, 2012 [Page 9]