SDNRG E. Haleplidis Internet-Draft S. Denazis Intended status: Informational University of Patras Expires: April 03, 2014 K. Pentikousis EICT J. Hadi Salim Mojatatu Networks O. Koufopavlou University of Patras September 30, 2013 SDN Layers and Architecture Terminology draft-haleplidis-sdnrg-layer-terminology-01 Abstract Software-Defined Networking (SDN) is a new approach for network programmability. Network programmability refers to the ability to control, change, and manage network behavior dynamically through software via open interfaces as opposed to relying on closed boxes and propietary defined interfaces. SDN introduces an abstraction for the data forwarding plane and by doing so separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what is the layer structure in an SDN architecture and how do layers interface with each other. This document does not aim to standardize any layers or interfaces but rather aims to answer these questions and provide a concise reference document for SDNRG in particular and the SDN community in general. 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 April 03, 2014. Haleplidis, et al. Expires April 03, 2014 [Page 1] Internet-Draft SDN Layers and Architecture Terminology September 2013 Copyright Notice Copyright (c) 2013 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. SDN Layers and Architecture . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Network Devices . . . . . . . . . . . . . . . . . . . . . 7 2.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Management Plane . . . . . . . . . . . . . . . . . . . . 8 2.5. Service Abstraction Layer . . . . . . . . . . . . . . . . 8 2.6. Application Plane . . . . . . . . . . . . . . . . . . . . 9 3. SDN Model View . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. ForCES . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. I2RS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Software-Defined Networking (SDN) is a relevant new term for the programmable networks paradigm. In short, SDN refers to the ability to use software to program individual network devices dynamically and therefore control the behavior of the network as a whole. A key element in SDN is the introduction of an abstraction between the (traditional) Forwarding and the Control planes in order to separate them and provide applications with the necessary application programming interfaces (APIs) to programmatically control the network. The goal is to leverage on this separation and the Haleplidis, et al. Expires April 03, 2014 [Page 2] Internet-Draft SDN Layers and Architecture Terminology September 2013 associated programmability to enable faster innovation at both planes. Current and earlier research in SDN often focuses on varying aspects of programmability, and we are often confronted with conflicting points of view regarding what exactly SDN is. For instance, we find that for various reasons (e.g. work focusing on one domain and therefore not necessarily applicable as-is to other domains), certain well-accepted definitions do not corelate well with each other. For example OpenFlow [OpenFlow] and NETCONF [RFC6241] has been characterized as SDN, but they refer to control and management respectively. This motivates us to consolidate the defitions of SDN in the literature and correlate them with earlier work in IETF and the research community. Of particular interest, for example, is to determine which layers comprise the SDN architecture and which interfaces are to be used between them. As such, the aim of this document is not to standardize any layer or interface but rather to attempt to provide a concise reference document regarding the SDN layers architecture, which would be useful to upcoming work in SDNRG as well as future discussions within the SDN community. 1.1. Terminology This document uses the following terms: Software-Defined Networking (SDN) - A programmable networks approach that supports the separation of Control and Forwarding Planes via standardized interfaces. Network Device - A device that performs one or more network operations related to packet manipulation and forwarding. A network device can be physical or virtual. Forwarding Plane (FP) - The network device part responsible for forwarding traffic. Operational Plane (OP) - The network device part responsible for managing device operation. Management Plane (MP) - Network functionality responsible for monitoring and maintaining network devices. Control Plane (CP) - Part of the network that is assigned to control one or more network devices. CP instructs network devices on how to treat and forward packets. Haleplidis, et al. Expires April 03, 2014 [Page 3] Internet-Draft SDN Layers and Architecture Terminology September 2013 Device Abstraction Layer (DAL) - The device's abstraction layer based on one or more models. If it is a physical device it may be referred to as the Hardware Abstraction Layer (HAL). DAL provides a uniform point of reference for the device. Control Abstraction Layer (CAL) - The control plane's abstraction layer. CAL provides access to the control plane southbound interface. Management Abstraction Layer (MAL) - The management plane's abstraction layer. MAL provides access to the management plane southbound interface. Interface - A point of interaction between two parts. In case these parts are not in the same physical location, the interface is usually implemented as network protocol. In case these parts are collocated in the same physical location the interface can be a protocol or an open/proprietary software inter-process communication API. Application (App) - A piece of software that utilizes underlying services to perform a function. Application operation can be parametrized, typically by passing certain arguments at call time, but it is meant to be a standalone piece of software as it does not offer any interfaces to other applications or services. Service - A piece of software that performs one or more functions and provides one or more APIs to applications or other services of the same or different layers to make use of said functions and returns one or more results. Services can be aggregated with other services or called in a certain serialized manner to create a new service. 2. SDN Layers and Architecture Figure 1 provides a detailed high-level overview of the current SDN architecture abstractions. Note that planes can be collocated with other planes or can be physically separated, as we discuss below. o--------------------------------o | | | +-------------+ +----------+ | | | Application | | Service | | | +-------------+ +----------+ | | Application Plane | o---------------Y----------------o | *-----------------------------Y---------------------------------* Haleplidis, et al. Expires April 03, 2014 [Page 4] Internet-Draft SDN Layers and Architecture Terminology September 2013 | Service Abstraction Layer (SAL) | *------Y------------------------------------------------Y-------* | | | Service Interface | | | o------Y------------------o o---------------------Y------o | | Control Plane | | Management Plane | | | +----Y----+ +-----+ | | +-----+ +----Y----+ | | | Service | | App | | | | App | | Service | | | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | | | | | | | | | | *----Y-----------Y----* | | *---Y---------------Y----* | | | Control Abstraction | | | | Management Abstraction | | | | Layer (CAL) | | | | Layer (MAL) | | | *----------Y----------* | | *----------Y-------------* | | | | | | | o------------|------------o o------------|---------------o | | | CP | MP | Southbound | Southbound | Interface | Interface | | *------------Y---------------------------------Y----------------* | Device Abstraction Layer (DAL) | *------------Y---------------------------------Y----------------* | | | | | o-------Y----------o +-----+ o---------Y---------o | | | Forwarding Plane | | App | | Operational Plane | | | o------------------o +-----+ o-------------------o | | Network Device | +---------------------------------------------------------------+ Figure 1: SDN Layer Architecture 2.1. Overview SDN spans multiple planes as illustrated in Figure 1. Starting from the bottom part of the figure and moving towards the upper part, we identify the following planes: o Forwarding Plane - Responsible for handling packets in the datapath. Actions of the forwarding plane include, but are not limited to, forwarding, dropping and changing packets. The Forwarding Plane is usually the termination point for control plane services and applications. o Operational Plane - Responsible for managing the operational state of the Network Device, e.g. active/inactive, number of ports, port Haleplidis, et al. Expires April 03, 2014 [Page 5] Internet-Draft SDN Layers and Architecture Terminology September 2013 status, etc. The Operational Plane is usually the termination point for management plane services and applications. o Control Plane - Responsible for taking decisions on how packets should be forwarded by one or more Network Devices and pushing such decisions down to the Network Devices to be executed. o Management Plane - Responsible for managing devices, e.g. taking decisions on Network Device states. o Application Plane - The plane where applications and services reside; applications may be implemented in a modular fashion and therefore span multiple planes. All planes mentioned above are connected via Interfaces (as indicated with "Y" in Figure 1. The Interface may take multiple roles depending on whether connected planes reside on the same (physical or virtual) device. If the respective planes are designed so that they do not have to reside in the same device, then the Interface can only take the form of a protocol. If the planes are co-located on the same device, then the Interface could either be an open/proprietary protocol, an open/proprietary software inter-process communication API, or Kernel system calls. Applications, i.e. software programs that perform specific computations that consume services without providing access to other applications, can be implemented natively inside a plane or can span multiple planes. Services, i.e. software programs that provide APIs to other applications or services, can also be natively implemented in specific planes. Services that span multiple planes belong to the application plane as well. This document considers four abstraction layers: The Device Abstraction Layer (DAL) abstracts the device forwarding and operational plane to the control and management plane, respectively. Variations of DAL may abstract both planes or either of the two. The Control Abstraction Layer (CAL) abstracts the CP southbound interface and the DAL from the applications and services of the Control Plane. The Management Abstraction Layer (MAL) abstracts the MP southbound interface and the DAL from the applications and services of the Management Plane. Haleplidis, et al. Expires April 03, 2014 [Page 6] Internet-Draft SDN Layers and Architecture Terminology September 2013 The Service Abstraction Layer (SAL) provides service abstractions for use by applications and other services. 2.2. Network Devices A Network Device is any device on a network that performs a function over a packet that it receives via its input port. The network device could, for example, forward the packet, drop the packet, change and forward the packet, etc. NDs can be implemented in hardware or software and can be either a physical or virtual network element. Each network network device has both a Forwarding Plane and an Operational Plane. The Forwarding Plane, commonly referred to as the "data path", is responsible for handling and forwarding packets. The Operational Plane is responsible for operational state of the ND, for example, with respect to status of network ports and interfaces. The Forwarding and the Operational Planes can be exposed via a Device Abstraction Layer (DAL), which may be comprised of one or more abstraction models. Examples of Forwarding Plane abstraction models are the ForCES model [RFC5812] and the OpenFlow switch model [OpenFlow]. Examples of the Operational Plane abstraction model include the ForCES model [RFC5812], the YANG model [RFC6020] and SNMP MIBs [RFC3418]. Examples of Network Devices include switches and routers. Additional examples include network elements that may operate at a layer above IP, such as firewalls, load balancers and video transcoders. Note that applications can also reside in a network device. Examples of such applications include event monitoring, and handling (offloading) topology discovery or ARP in the device itself instead of forwarding such traffic to the control plane. 2.3. Control Plane The Control Plane communicates with the Forwarding Plane of devices using a Control Plane Southbound Interface (CPSI) with DAL as a point of reference. The Control Plane is responsible for instructing the Forwarding Plane about how to handle network packets. Normally the CPSI is a time-critical interface and requires low latency and sometimes high bandwidth in order to perform many operations in short order. Examples include fast and high frequency of flow or table updates, high throughput and robustness for packet handling and events. CPSI can be implemented using a protocol, an API or even interprocess communication. If the Control Plane and the Network Device are not Haleplidis, et al. Expires April 03, 2014 [Page 7] Internet-Draft SDN Layers and Architecture Terminology September 2013 collocated, then this interface is certainly a protocol. Examples of CPSIs are ForCES [RFC5810] and the Openflow protocol [OpenFlow]. The Control Abstraction Layer (CAL) provides access to control applications and services to various CPSIs. The Control Plane may support more than one CPSIs. Control applications can use CAL to control a network device without providing any service to upper layers. Examples include applications that perform control functions, such as OSPF, BGP, etc. Control Plane Services provide access to other Services or Applications above the control plane. Examples include a virtual private LAN service, service tunnels, etc. 2.4. Management Plane The Management Plane communicates with the network device Operational Plane using a Management Plane Southbound Interface (MPSI) with DAL as a point of reference. Normally MSPI, in contrast to the CPSI, is not a time-critical interface and does not share the CPSI's requirements. The management plane is typically closer to human interaction than the control plane and therefore the MSPI is usually based more on usability than performance. Messages tend to be less frequent than in the CPSI. The MPSI can range from a protocol, to an API or even interprocess communication. If the Management Plane is not embedded in the network device, the MSPI is certainly a protocol. Examples of MPSIs are ForCES [RFC5810], NETCONF [RFC6241], OVSDB [I-D.pfaff-ovsdb-proto] and SNMP [RFC3411]. The Management Abstraction Layer (MAL) provides access to management applications and services to various MPSIs. The Management Plane may support more than one MPSI. Management Applications can use MAL to manage the network device without providing any service to upper layers. Examples of management applications include network monitoring applications. Management Plane Services provide access to other services or applications above the Management Plane. 2.5. Service Abstraction Layer Haleplidis, et al. Expires April 03, 2014 [Page 8] Internet-Draft SDN Layers and Architecture Terminology September 2013 The Service Abstraction Layer (SAL) provides access from services of the control, management and application plane to services and applications of the application plane. Service Interfaces can take many forms pertaining to their specific requirements. Examples of service interfaces include but are not limited to, RESTful APIs, open or proprietary protocols such as NETCONF, inter-process communications, CORBA interfaces, etc. 2.6. Application Plane Applications and services that use services from the control and/or management plane form the Application Plane. Additionally, services residing in the Application Plane may provide services to other services and applications that reside in the application plane via the service interface. Examples of applications include network topology discovery, network provisioning, path reservation, etc. 3. SDN Model View We advocate that the SDN southbound interface should encompass both the CSPI and the MSPI. The SDN northbound interface is implemented in the Service Abstraction Layer. The above model can be used to describe in a concise manner all prominent SDN-enabling technologies, as we explain in the following subsections. 3.1. ForCES ForCES [RFC5810] can be mapped to the framework illustrated in Figure 1 as follows: o The ForCES model can be used to describe the DAL, both for the Operational and the Forwarding Plane. o The ForCES protocol can then be both the CPSI and the MPSI. o CAL and MAL must be able to utilize the ForCES protocol 3.2. NETCONF Haleplidis, et al. Expires April 03, 2014 [Page 9] Internet-Draft SDN Layers and Architecture Terminology September 2013 NETCONF can be mapped to the framework illustrated in Figure 1 as follows: o The YANG model [RFC6020] is suitable for specifying DAL for the Operational plane and NETCONF [RFC6241] for the MPSI. o Technically the YANG model [RFC6020] can be used to specify the DAL for the Forwarding plane as well, but NETCONF [RFC6241] being an ASCII transfer protocol is not suitable for the requirements of CPSI. 3.3. OpenFlow OpenFlow can be mapped to the framework illustrated in Figure 1 as follows: o The Openflow switch specifications [OpenFlow] covers DAL for the Forwarding Plane and provides the specifications for CPSI. o The OF-CONFIG protocol [OF-CONFIG] based on the YANG model [RFC6020], provides DAL for the Operational Plane and specifies NETCONF [RFC6241] as the MPSI. OF-CONFIG overlaps with the OpenFlow DAL, but with NETCONF [RFC6241] as the transport protocol it shares its limitations described in the previous section. o CAL must be able to utilize the OpenFlow protocol. o MAL must be able to utilize the NETCONF protocol. 3.4. I2RS I2RS can be mapped to the framework illustrated in Figure 1 as follows: o The I2RS architecture [I-D.liu-i2rs-architecture] is concerned with the Control and Application Planes and uses whatever CPSI and DAL are available, whether that is ForCES, OpenFlow or another Interface. o The I2RS agent is a Control Plane Service. All services or applications on top of that belong to either the Control or the Application plane. o Currently the I2RS working group if developing an Information Model [I-D.nitinb-i2rs-rib-info-model] in regards to the Service Abstraction Layer for the I2RS agent. Haleplidis, et al. Expires April 03, 2014 [Page 10] Internet-Draft SDN Layers and Architecture Terminology September 2013 4. Acknowledgements The authors would like to acknowledge David Meyer, Salvatore Loreto and Sudhir Modali for their discussion and comments that helped put this document in a better shape. 5. IANA Considerations This memo makes no requests to IANA. 6. Security Considerations TBD 7. Informative References [I-D.liu-i2rs-architecture] Liu, D., Khasnabish, B., and H. Deng, "Architecture Discussion of I2RS", draft-liu-i2rs-architecture-02 (work in progress), July 2013. [I-D.nitinb-i2rs-rib-info-model] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", draft-nitinb-i2rs-rib-info- model-02 (work in progress), August 2013. [I-D.pfaff-ovsdb-proto] Pfaff, B. and B. Davie, "The Open vSwitch Database Management Protocol", draft-pfaff-ovsdb-proto-03 (work in progress), September 2013. [OF-CONFIG] Open Networking Foundation, "OpenFlow Management and Configuration Protocol 1.1", , . [OpenFlow] Open Networking Foundation, "The OpenFlow 1.3 Specification.", , . [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Haleplidis, et al. Expires April 03, 2014 [Page 11] Internet-Draft SDN Layers and Architecture Terminology September 2013 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. Authors' Addresses Evangelos Haleplidis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece Email: ehalep@ece.upatras.gr Spyros Denazis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece Email: sdena@upatras.gr Kostas Pentikousis EICT GmbH Torgauer Strasse 12-15 10829 Berlin Germany Email: k.pentikousis@eict.de Haleplidis, et al. Expires April 03, 2014 [Page 12] Internet-Draft SDN Layers and Architecture Terminology September 2013 Jamal Hadi Salim Mojatatu Networks Suite 400, 303 Moodie Dr. Ottawa, Ontario K2H 9R4 Canada Email: hadi@mojatatu.com Odysseas Koufopavlou University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece Email: odysseas@ece.upatras.gr Haleplidis, et al. Expires April 03, 2014 [Page 13]