| SDNRG | E.H. Haleplidis |
| Internet-Draft | S.D. Denazis |
| Intended status: Informational | O.K. Koufopavlou |
| Expires: January 16, 2014 | University of Patras |
| K.P. Pentikousis | |
| Huawei Technologies | |
| J. Hadi Salim | |
| Mojatatu Networks | |
| July 15, 2013 |
SDN Layers and Architecture Terminology
draft-haleplidis-sdnrg-layer-terminology-00
Software-Defined Networking introduces an abstraction layer and by doing so separates the Forwarding from the Control layer. This separation can allow faster innovation cycles at both layers as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what is the layer stucture in an SDN architecture and how do layers interface with each other. This document aims to provide a concise reference for future discussions in SDNRG.
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 16, 2014.
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.
Software-Defined Networking introduces an abstraction layer between the Forwarding and the Control layer in order to separate them. This separation allows faster innovation for both layers as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what layers comprise the SDN architecture and what are the interfaces. This draft attempts to provide a concise reference document for future discussions on SDN.
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 [RFC2119].
This document introduces the following terms:
Figure 1 provides a detailed abstraction overview of the current SDN architecture. Planes can be collocated with other planes or can be physically separated, as we discuss below.
+--------------------------------+
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
+---------------Y----------------+
|
+-----------------------------Y---------------------------------+
| Service Abstraction Layer (SAL) |
+------Y------------------------------------------------Y-------+
| |
| Service Interface |
| |
+------Y------------------+ +---------------------Y------+
| | 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-------------+ |
| | | | | |
+------------|------------+ +------------|---------------+
| |
| Control Plane | Management Plane
| Southbound Interface | Southbound Interface
| |
+------------Y---------------------------------Y----------------+
| Device Abstraction Layer (DAL) |
+------------Y---------------------------------Y----------------+
| | | |
| +-------Y----------+ +-----+ +---------Y---------+ |
| | Forwarding Plane | | App | | Operational Plane | |
| +------------------+ +-----+ +-------------------+ |
| Network Device |
+---------------------------------------------------------------+
Figure 1: SDN Layer Architecture
A Network Device, implemented in hardware or in software, physical or virtual, 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 of packets. The Operational Plane represents the operational state of the device, for example, with respect to network ports and interfaces.
The Forwarding and the Operational Planes can be exposed using a Device Abstraction Layer (DAL), which may comprise one or more abstraction models. Examples of Forwarding Plane abstraction models are the ForCES model [RFC5812] and the OpenFlow switch model [OpenFlow1.3.1]. Examples of the Operational Plane abstraction model include the ForCES model [RFC5812], the YANG model [RFC6020] and SNMP MIBs [RFC3418].
Applications can also reside in the network device. Examples of such applications are event monitoring, and offloading topology discovery or ARP in the device itself instead of forwarding such traffic to the 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 and is responsible for instructing the Forwarding Plane on how to handle network packets. CPSI can be implemented using a protocol, an API or even interprocess communication. If the Control Plane and the Network Device are not collocated, then this interface is certainly a protocol. Examples of CPSIs are ForCES [RFC5810] and the Openflow protocol [OpenFlow1.3.1].
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 Application above the control plane. Examples include a virtual private LAN service, service tunnels, etc.
The Management Plane communicates with the network device Operational Plane using a Management Plane Southbound Interface (MPSI) with DAL as a point of reference. This interface can range from a protocol, to an API or even interprocess communication. If the Management Plane is not embedded in the network device, this interface 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 application above the Management Plane.
The Service Abstraction Layer (SAL) provides access from services of the control, management and applciation plane to services and applications of the application plane. Examples of service interfaces are REST APIs.
Applications and services that use services from the control and/or management plane form the Application Plane.
Addditionally, 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.
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.
ForCES can be mapped on the above framework as follows:
Openflow can be mapped on the above framework as follows:
NETCONF can be mapped on the above framework as follows:
TBD
This memo makes no requests to IANA.
TBD