One document matched: draft-irtf-sdnrg-layer-terminology-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC3654 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3654.xml">
<!ENTITY RFC3746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3746.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I2RSArch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-architecture-05.xml">
<!ENTITY I2RSInfo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-rib-info-model-03.xml">
<!ENTITY I2RSProb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-problem-statement-04.xml">
<!ENTITY RFC7149 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7149.xml">
<!ENTITY RFC7047 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7047.xml">
<!ENTITY RFC5812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5812.xml">
<!ENTITY RFC5810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5810.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC6632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6632.xml">
<!ENTITY RFC5706 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5706.xml">
<!ENTITY RFC3535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3535.xml">
<!ENTITY RFC5880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5743 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5743.xml">
<!ENTITY RFC0826 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0826.xml">
<!ENTITY RFC1953 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1953.xml">
<!ENTITY RFC2297 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2297.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5531 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5531.xml">
<!ENTITY RFC2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY RFC3417 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3417.xml">
<!ENTITY RFC3412 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3412.xml">
<!ENTITY RFC3414 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3414.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no"?>
<!-- Start each main section on a new page -->
<?rfc subcompact="no"?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-irtf-sdnrg-layer-terminology-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>SDN Layers and Architecture Terminology</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Evangelos Haleplidis" initials="E.H." surname="Haleplidis" role="editor">
<organization>University of Patras</organization>
<address>
<postal>
<street>Department of Electrical and Computer Engineering</street>
<!-- Reorder these if your country does things differently -->
<city>Patras</city>
<region/>
<code>26500</code>
<country>Greece</country>
</postal>
<email>ehalep@ece.upatras.gr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Kostas Pentikousis" initials="K.P." surname="Pentikousis" role="editor">
<organization abbrev="EICT">EICT GmbH</organization>
<address>
<postal>
<street>Torgauer Strasse 12-15</street>
<city>10829 Berlin</city>
<country>Germany</country>
</postal>
<email>k.pentikousis@eict.de</email>
</address>
</author>
<author fullname="Spyros Denazis" initials="S.D." surname="Denazis">
<organization>University of Patras</organization>
<address>
<postal>
<street>Department of Electrical and Computer Engineering</street>
<!-- Reorder these if your country does things differently -->
<city>Patras</city>
<region/>
<code>26500</code>
<country>Greece</country>
</postal>
<email>sdena@upatras.gr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jamal Hadi Salim" initials="J.H.S" surname="Hadi Salim">
<organization>Mojatatu Networks</organization>
<address>
<postal>
<street>Suite 400, 303 Moodie Dr.</street>
<city>Ottawa, Ontario</city>
<code>K2H 9R4</code>
<country>Canada</country>
</postal>
<email>hadi@mojatatu.com</email>
</address>
</author>
<author fullname="David Meyer" initials="D.M." surname="Meyer">
<organization>Brocade</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
</postal>
<email>dmm@1-4-5.net</email>
</address>
</author>
<author fullname="Odysseas Koufopavlou" initials="O.K." surname="Koufopavlou">
<organization>University of Patras</organization>
<address>
<postal>
<street>Department of Electrical and Computer Engineering</street>
<!-- Reorder these if your country does things differently -->
<city>Patras</city>
<region/>
<code>26500</code>
<country>Greece</country>
</postal>
<email>odysseas@ece.upatras.gr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2014" />
<area>Routing</area>
<workgroup>SDNRG</workgroup>
<keyword>Software-defined Networking</keyword>
<keyword>SDN</keyword>
<keyword>Programmable Networks</keyword>
<keyword>Architecture</keyword>
<keyword>Layer</keyword>
<keyword>Terminology</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Software-Defined Networking (SDN) can be defined as a new approach for network programmability. Network programmability in this context refers to the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces as opposed to relying on closed-box solutions and their associated proprietary interfaces. SDN emphasizes the role of software in running networks through the introduction of 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 addresses these questions and provides a concise reference for SDNRG and the wider SDN community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.</t>
<t>This document is a product of the IRTF Software-Defined Networking Research Group (SDNRG)</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Software-Defined Networking (SDN) is a term of the programmable networks paradigm <xref target="PNSurvey99"/><xref target="OF08"/>. In short, SDN refers to the ability of software applications to program individual network devices dynamically and therefore control the behavior of the network as a whole <xref target="NV09"/>. Boucadair and Jacquenet <xref target="RFC7149"/> point out that SDN is a set of techniques used to facilitate the design, delivery and operation of network services in a deterministic, dynamic, and scalable manner.</t>
<t>A key element in SDN is the introduction of an abstraction between the (traditional) forwarding and control planes in order to separate them and provide applications with the means necessary to programmatically control the network. The goal is to leverage this separation, and the associated programmability, in order to reduce complexity and enable faster innovation at both planes <xref target="A4D05"/>.</t>
<t>The historical evolution of the programmable networks R&D area is reviewed in detail in <xref target="SDNHistory"></xref><xref target="SDNSurvey"></xref>, starting with efforts dating back to the 1980s. As Feamster et al. document <xref target="SDNHistory"></xref>, many of the ideas, concepts and concerns are applicable to the latest R&D in SDN, and SDN standardization we may add, and have been under extensive investigation and discussion in the research community for quite some time. For example, Rooney et al. <xref target="Tempest"></xref> discuss how to allow third-party access to the network without jeopardizing network integrity, or how to accommodate legacy networking solutions in their (then new) programmable environment. Further, the concept of separating the control and data planes, which is prominent in SDN, has been extensively discussed even prior to 1998 <xref target="Tempest"/><xref target="P1520"/>, in SS7 networks <xref target="ITUSS7"/>, Ipsilon Flow Switching <xref target="RFC1953"/><xref target="RFC2297"/> and <xref target="ITUATM">ATM</xref>.</t>
<t>SDN research often focuses on varying aspects of programmability, and we are frequently 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 correlate well with each other. For example, both <xref target="OpenFlow">OpenFlow</xref> and <xref target="RFC6241">NETCONF</xref> have been characterized as SDN interfaces, but they refer to control and management respectively.</t>
<t>This motivates us to consolidate the definitions of SDN in the literature and correlate them with earlier work at the IETF and the research community. Of particular interest is, for example, to determine which layers comprise the SDN architecture and which interfaces and their corresponding attributes are best suitable to be used between them. As such, the aim of this document is not to standardize any particular layer or interface but rather to provide a concise reference which reflects current approaches regarding the SDN layers architecture. We expect that this document would be useful to upcoming work in SDNRG as well as future discussions within the SDN community as a whole.</t>
<t>This document addresses the work item in the SDNRG charter entitled "Survey of SDN approaches and Taxonomies", fostering better understanding of prominent SDN technologies in a technology-impartial and business-agnostic manner but does not constitute a new IETF standard. It is meant as a common base for further discussion. As such, we do not make any value statements nor discuss the applicability of any of the frameworks examined in this draft for any particular purpose. Instead, we document their characteristics and attributes and classify them, thus providing a taxonomy. This document does not intend to provide an exhaustive list of SDN research issues; interested readers should consider reviewing <xref target="SLTSDN"></xref> and <xref target="SDNACS"></xref>. In particular, <xref target="SLTSDN"></xref> overviews SDN-related research topics, e.g. control partitioning, which is related to the <xref target="CAPTheorem">CAP theorem</xref> discussed later in this document.</t>
<t>The first version of this document was published in July 2013. Subsequently, updated versions were presented during the SDNRG meetings at IETF 88, IETF 89, and IETF 90 and have been reviewed, commented, and discussed extensively for more than one year by the vast majority of SDNRG members, which certainly exceeds 100 individuals. It is the consensus of SDNRG that this document should be published in the IRTF Stream RFC Series <xref target="RFC5743"/>.</t>
<t>The remainder of this document is organized as follows. <xref target="Terminology"/> explains the terminology used in this document. <xref target="SDNLayersSection"/> introduces a high-level overview of current SDN architecture abstractions. Finally, <xref target="SDNView"/> discusses how the SDN Layer Architecture relates with prominent SDN-enabling technologies.</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>This document uses the following terms:
<list style="hanging">
<t>Software-Defined Networking (SDN) - A programmable networks approach that supports the separation of control and forwarding planes via standardized interfaces.</t>
<t>Resource - A physical or virtual component available within a system. Resources can be very simple or fine-grained, e.g. a port or a queue, or complex, comprised of multiple resources, e.g. a network device.</t>
<t>Network Device - A device that performs one or more network operations related to packet manipulation and forwarding. This reference model makes no distinction whether a network device is physical or virtual. A device can also be considered as a container for resources and can be a resource in itself.</t>
<t>Interface - A point of interaction between two entities. When the entities are placed at different locations, the interface is usually implemented through a network protocol. If the entities are collocated in the same physical location the interface can be implemented using a software application programming interface (API), inter-process communication (IPC), or a network protocol.</t>
<t>Application (App) - An application in the context of SDN is a piece of software that utilizes underlying services to perform a function. Application operation can be parametrized, for example by passing certain arguments at call time, but it is meant to be a standalone piece of software: an App does not offer any interfaces to other applications or services.</t>
<t>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 combined with other services, or called in a certain serialized manner, to create a new service.</t>
<t>Forwarding Plane (FP) - The collection of resources across all network devices responsible for forwarding traffic.</t>
<t>Operational Plane (OP) - The collection of resources responsible for managing the overall operation of individual network devices.</t>
<t>Control plane (CP): The collection of functions responsible for controlling one or more network devices. CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and to a lesser extent with the operational plane.</t>
<t>Management plane (MP): The collection of functions responsible for monitoring, configuring and maintaining one or more network devices or parts of network devices. The management plane is mostly related with the operational plane and less with the forwarding plane.</t>
<t>Application Plane - The collection of applications and services which program network behavior.</t>
<t>Device and resource Abstraction Layer (DAL) - The device's resource 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's forwarding and operational plane resources.</t>
<t>Control Abstraction Layer (CAL) - The control plane's abstraction layer. CAL provides access to the control plane southbound interface.</t>
<t>Management Abstraction Layer (MAL) - The management plane's abstraction layer. MAL provides access to the management plane southbound interface.</t>
<t>Network Services Abstraction Layer (NSAL) - Provides service abstractions that can be used by applications and services.</t>
</list></t>
</section>
<section anchor="SDNLayersSection" title="SDN Layers and Architecture">
<t><xref target="SDNLayers" /> summarizes in the form of a detailed high-level schematic the SDN architecture abstractions. Note that in a particular implementation planes can be collocated with other planes or can be physically separated, as we discuss below.</t>
<t>SDN is based on the concept of separation between a controlled entity and a controller entity. The controller manipulates the controlled entity via an Interface. Interfaces, when local, are mostly API calls through some library or system call. However, such interfaces may be extended via some protocol definition, which may use local inter-process communication (IPC) or a protocol that could also act remotely; the protocol may be defined as an open standard or in a proprietary manner.</t>
<t>Day <xref target="PiNA"></xref> explores the use of IPC as the mainstay for the definition of recursive network architectures with varying degrees of scope and range of operation. <xref target="RINA">RINA</xref> outlines a recursive network architecture based on IPC which capitalizes on repeating patterns and structures. This document does not propose a new architecture--we simply document previous work through a taxonomy. Although recursion is out of scope for this work, <xref target="SDNLayers" /> illustrates a hierarchical model in which layers can be stacked on top of each other and employed recursively as needed.</t>
<figure title="SDN Layer Architecture" anchor="SDNLayers"> <artwork align="center"><![CDATA[
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------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 and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
]]></artwork></figure>
<section title="Overview">
<t>This document follows a network device centric approach: Control mostly refers to the device packet handling capability, while management tends to refer to the overall device operation aspects. We view a network device as a complex resource which contains and is part of multiple resources similar to <xref target="DIOPR"/>. Resources can be simple, single components of a network device, for example a port or a queue of the device, and can also be aggregated into complex resources, for example a network card or a complete network device.</t>
<t>The reader should keep in mind throughout this document that we make no distinction between "physical" and "virtual" resources or "hardware" and "software" realizations, as we do not delve into implementation or performance aspects. In other words, a resource can be implemented fully in hardware, fully in software, or any hybrid combination in between. Further, we do not distinguish on whether a resource is implemented as an overlay or as a part/component of some other device. In general, network device software can run on so-called "bare metal" or on a virtualized substrate. Finally, this document does not discuss how resources are allocated, orchestrated, and released. Indeed, orchestration is out of scope for this document.</t>
<t>SDN spans multiple planes as illustrated in <xref target="SDNLayers" />. Starting from the bottom part of the figure and moving towards the upper part, we identify the following planes:
<list style="symbols">
<t>Forwarding Plane - Responsible for handling packets in the datapath based on the instructions received from the control plane. 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. The forwarding plane can contain forwarding resources such as classifiers.</t>
<t>Operational Plane - Responsible for managing the operational state of the network device, e.g. whether the device is active or inactive, the number of ports available, the status of each port, and so on. The operational plane is usually the termination point for management plane services and applications. The operational plane relates to (operational aspects of) network device resources such as ports, memory, and so on. We note that some participants of the IRTF SDNRG have a different opinion in regards to the definition of the operational plane. That is, one can argue that the operational plane does not constitute a "plane" per se, but it is in practice an amalgamation of functions on the forwarding plane. For others, however, a "plane" allows to distinguish between different areas of operations and therefore the operational plane should be included as a "plane" in <xref target="SDNLayers" />. We have adopted this latter view in this document.</t>
<t>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 for execution. The control plane usually focuses mostly on the forwarding plane and less on the operational plane of the device. The control plane may be interested in operational plane information which could include, for instance, the current state of a particular port or its capabilities. The control plane's main job is to fine-tune the forwarding tables that reside in the forwarding plane, based on the network topology or external service requests.</t>
<t>Management Plane - Responsible for monitoring, configuring and maintaining network devices, e.g. taking decisions regarding the state of a network device. The management plane usually focuses mostly on the operational plane of the device and less on the forwarding plane. The management plane may be used to configure the forwarding plane, but it does so infrequently and through a more wholesale approach than the control plane. For instance, the management plane may set up all or part of the forwarding rules at once, although such action would be expected to be taken sparingly.</t>
<t>Application Plane - The plane where applications and services that define network behavior reside. Applications that directly (or primarily) support the operation of the forwarding plane (such as routing processes within the control plane) are not considered part of the application plane. Note that applications may be implemented in a modular and distributed fashion and, therefore, can often span multiple planes in <xref target="SDNLayers" />.</t>
</list></t>
<t>All planes mentioned above are connected via interfaces (as indicated with "Y" in <xref target="SDNLayers" />. An interface may take multiple roles depending on whether the 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 be implemented via an open/proprietary protocol, an open/proprietary software inter-process communication API, or operating system kernel system calls.</t>
<t>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. For instance, applications or services can span both the control and management plane and, thus, be able to use both the Control Plane Southbound Interface (CPSI) and Management Plane Southbound Interface (MPSI), although this is only implicitly illustrated in <xref target="SDNLayers" />. An example of such a case would be an application that uses both <xref target="OpenFlow"></xref> and <xref target="OF-CONFIG"></xref>.</t>
<t>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.</t>
<t>While not shown explicitly in <xref target="SDNLayers" />, services, applications and entire planes, can be placed in a recursive manner thus providing overlay semantics to the model. For example, application plane services can provide through NSAL services to other applications or services. Additional examples include virtual resources that are realized on top of a physical resources and hierarchical control plane controllers <xref target="KANDOO"/>.</t>
<t>It must be noted, however, that in <xref target="SDNLayers" /> we present an abstract view of the various planes, which is devoid of implementation details. Many implementations in the past have opted for placing the management plane on top of the control plane. This can be interpreted as having the control plane acting as a service to the management plane. Further, traditionally, the control plane was tightly coupled with the network device. When taken as whole, the control plane was distributed network-wide. On the other hand, the management plane has been traditionally centralized and was responsible for managing the control plane and the devices. However, with the adoption of SDN principles, this distinction is no longer so clear-cut.</t>
<t>Additionally, this document considers four abstraction layers:
<list style="hanging">
<t>The Device and resource Abstraction Layer (DAL) abstracts the device's forwarding and operational plane resources to the control and management plane. Variations of DAL may abstract both planes or either of the two and may abstract any plane of the device to either the control or management plane.</t>
<t>The Control Abstraction Layer (CAL) abstracts the CP southbound interface and the DAL from the applications and services of the control plane.</t>
<t>The Management Abstraction Layer (MAL) abstracts the MP southbound interface and the DAL from the applications and services of the management plane.</t>
<t>The Network Services Abstraction Layer (NSAL) provides service abstractions for use by applications and other services.</t>
</list></t>
<t>After the last call at the SDNRG level we note that that the views presented in <xref target="ONFArch"/> and <xref target="ITUY3300"></xref> are well aligned with this document.</t>
<t>At the time of this writing, SDN-related activities have begun in other SDOs. For example, at the ITU work on architectural <xref target="ITUSG13"/> and signaling requirements and protocols <xref target="ITUSG11"></xref> has commenced, but the respective study groups have yet to publish their documents with the exception of <xref target="ITUY3300"></xref>. In addition, ITU has started a Joint Collaboration Activity (JCA) in regards to SDN.</t>
</section>
<section title="Network Devices" anchor="ND">
<t>A Network Device is an entity that receives packets on its ports and performs one or more network functions on them. For example, the network device could forward a received packet, drop it, alter the packet header (or payload) and forward the packet, and so on. A Network Device is an aggregation of multiple resources such as ports, CPU, memory and queues. Resources are either simple or can be aggregated to form complex resources that can be viewed as one resource. The Network Device is in itself a complex resource. 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 or even Layer 1 devices such as optical or microwave network elements.</t>
<t>Network devices can be implemented in hardware or software and can be either physical or virtual. As has already been mentioned before, this document makes no such distinction. Each network device has both a Forwarding Plane and an Operational Plane.</t>
<t>The Forwarding Plane, commonly referred to as the "data path", is responsible for handling and forwarding packets. The Forwarding Plane provides switching, routing, packet transformation and filtering functions. Resources of the forwarding plane include but are not limited to filters, meters, markers and classifiers.</t>
<t>The Operational Plane is responsible for the operational state of the network device, for instance, with respect to status of network ports and interfaces. Operational plane resources include, but are not limited to, memory, CPU, ports, interfaces and queues.</t>
<t>The Forwarding and the Operational Planes are exposed via the Device and resource Abstraction Layer (DAL), which may be expressed by one or more abstraction models. Examples of Forwarding Plane abstraction models are <xref target="RFC5812">ForCES</xref> and <xref target="OpenFlow">OpenFlow</xref>. Examples of the Operational Plane abstraction model include the <xref target="RFC5812">ForCES model</xref>, the <xref target="RFC6020">YANG model</xref>, and <xref target="RFC3418">SNMP MIBs</xref>.</t>
<t>Note that applications can also reside in a network device. Examples of such applications include event monitoring, and handling (offloading) topology discovery or <xref target="RFC0826">ARP</xref> in the device itself instead of forwarding such traffic to the control plane.</t>
</section>
<section title="Control Plane" anchor="CP">
<t>The control plane is usually distributed and is responsible mainly for the configuration of the forwarding plane using a Control Plane Southbound Interface (CPSI) with DAL as a point of reference. CP is responsible for instructing FP about how to handle network packets.</t>
<t>Communication between control planes, colloquially referred to as the "east-west" interface, is usually implemented through gateway protocols such as BGP <xref target="RFC4271"/> or other protocols such as <xref target="RFC5440"></xref>. However, the corresponding protocol messages are in fact exchanged in-band and subsequently redirected by the forwarding plane to the control plane for further processing. Examples in this category include <xref target="RCP"/>, <xref target="SoftRouter"/> and <xref target="RouteFlow"/>.</t>
<t>Control Plane functionalities usually include:
<list style="symbols">
<t>Topology discovery and maintenance</t>
<t>Packet route selection and instantiation</t>
<t>Path failover mechanisms</t>
</list></t>
<t>The CPSI is usually defined with the following characteristics:
<list style="symbols">
<t>time-critical interface which requires low latency and sometimes high bandwidth in order to perform many operations in short order.</t>
<t>oriented towards wire efficiency and device representation instead of human readability</t>
</list></t>
<t>Examples include fast- and high-frequency of flow or table updates, high throughput and robustness for packet handling and events.</t>
<t>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 <xref target="RFC5810">ForCES</xref> and the <xref target="OpenFlow">Openflow protocol</xref>.</t>
<t>The Control Abstraction Layer (CAL) provides access to control applications and services to various CPSIs. The Control Plane may support more than one CPSIs.</t>
<t>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, IS-IS, and BGP.</t>
<t>Control Plane service examples include a virtual private LAN service, service tunnels, topology services, etc.</t>
</section>
<section title="Management Plane" anchor="MP">
<t>The Management Plane is usually centralized and aims to ensure that the network as a whole is running optimally by communicating with the network devices' Operational Plane using a Management Plane Southbound Interface (MPSI) with DAL as a point of reference.</t>
<t>Management plane functionalities are typically initiated, based on an overall network view, and traditionally have been human-centric. However, lately algorithms are replacing most human intervention. Management plane functionalities <xref target="FCAPS"/> <xref target="RFC3535"/> usually include:
<list style="symbols">
<t>Fault and Monitoring management</t>
<t>Configuration management</t>
</list></t>
<t>In addition, management plane functionalities may also include entities such as orchestrators, Virtual Function Managers (VNF manager) and Virtualised Infrastructure Managers, as described in <xref target="NFVArch"/>. Such entities can use management interfaces to operational plane resources to request and provision resources for virtual functions, as well as instruct the instantiation of virtual forwarding functions on top of physical forwarding functions. The possibility of a common abstraction model for both SDN and NFV is explored in <xref target="SDNNFV"/>. Note, however, that these are only examples of applications and services in the management plane and not formal definitions of entities in this document. As has been noted above, orchestration and therefore the definition of any associated entities is out of scope for this document.</t>
<t>The MPSI, in contrast to the CPSI, is usually not a time-critical interface and does not share the CPSI requirements.</t>
<t>MPSI is <xref target="RFC3535"></xref> typically closer to human interaction than CPSI and, therefore, MPSI usually has the following characteristics:
<list style="symbols">
<t>It is oriented more towards usability, with optimal wire performance being a secondary concern.</t>
<t>Messages tend to be less frequent than in the CPSI</t>
</list></t>
<t>As an example of usability versus performance, we refer to the consensus of the 2002 IAB Workshop <xref target="RFC3535"/>, as per <xref target="RFC6632"/>, where textual configuration files should be able to contain international characters. Human-readable strings should utilize UTF-8, and protocol elements should be in case-insensitive ASCII which require more processing capabilities to parse.</t>
<t>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 MPSI is certainly a protocol. Examples of MPSIs are <xref target="RFC5810">ForCES</xref>, <xref target="RFC6241">NETCONF</xref>, <xref target="RFC7047">OVSDB</xref> and <xref target="RFC3411">SNMP</xref>.</t>
<t>The Management Abstraction Layer (MAL) provides access to management applications and services to various MPSIs. The Management Plane may support more than one MPSI.</t>
<t>Management Applications can use MAL to manage the network device without providing any service to upper layers. Examples of management applications include network monitoring, fault detection and recovery applications.</t>
<t>Management Plane Services provide access to other services or applications above the Management Plane. </t>
</section>
<section title="The Control vs. Management Plane Debate">
<t>During the IETF 88 and 89 SDNRG meetings as well as on the corresponding mailing list, one of the most commonly discussed topics, in regards to this document, was the definition of clear distinction between control and management. Earlier we have observed that the role of the management plane has been largely ignored or specified as out-of-scope for the SDN ecosystem. We argue that it is important to characterize and distinguish these two planes in order to have a clear understanding of the mechanics, capabilities and needs of the each respective interface.</t>
<t>In the remainder of this subsection we summarize the characteristics that differentiate the two planes as per the discussions mentioned above.</t>
<section title="Timescale">
<t>A point has been raised regarding the reference timescales for the control and management planes. That is, how fast is the respective plane required to react, or needs to manipulate, the forwarding or operational plane of the device. In general, the control plane needs to send updates "often", which translates roughly to a range of milliseconds; that requires high-bandwidth and low-latency links. In contrast, the management plane reacts generally at longer time frames, i.e. minutes, hours or even days, and thus wire-efficiency is not always a critical concern. A good example of this is the case of changing the configuration state of the device.</t>
</section>
<section title="Persistence">
<t>Another distinction between the control and management planes relates to state persistence. A state is considered ephemeral if it has a very limited lifespan. A good example is determining routing, which is usually associated with the control plane. On the other hand, a persistent state has an extended lifespan which may range from hours to days and months and is usually associated with the management plane. Persistent state is also usually associated with data store of the state.</t>
</section>
<section title="Locality">
<t>As mentioned earlier, traditionally the control plane has been executed locally on the network device and is distributed in nature whilst the management plane is usually executed in a centralized manner, remotely from the device. However, with the advent of SDN centralizing, or "locally centralizing" the controller tends to muddle the distinction of the control and management plane based on locality.</t>
</section>
<section title="CAP Theorem Insights" anchor="CAPTheorem">
<t>An additional distinction was introduced at IETF 89 with a reference to the CAP theorem. The CAP theorem views a distributed computing system as composed of multiple computational resources (i.e., CPU, memory, storage) that are connected via a communications network and together perform a task. The theorem (or conjecture by some) identifies three characteristics of distributed systems that are universally desirable:</t>
<t><list style="sumbols">
<t>Consistency, meaning that the system responds identically to a query no matter which node receives the request (or does not respond at all)</t>
<t>Availability, i.e. that the system always responds to a request (although the response may not be consistent or correct)</t>
<t>Partition tolerance, namely that the system continues to function even when specific nodes or the communications network fail.</t>
</list></t>
<t>In 2000 <xref target="CAPBR">Eric Brewer</xref> conjectured that a distributed system can satisfy any two of these guarantees at the same time, but not all three. This conjecture was later proven by <xref target="CAPGL">Gilbert and Lynch</xref> and is now usually referred to as the CAP theorem <xref target="CAPFN"></xref>.</t>
<t>Forwarding a packet through a network correctly is a computational problem. One of the major abstractions that SDN posits is that all network elements are computational resources that perform the simple computational task of inspecting fields in an incoming packet and deciding how to forward it. Since the task of forwarding a packet from network ingress to network egress is obviously carried out by a large number of forwarding elements, the network of forwarding devices is a distributed computational system. Hence, the CAP theorem applies to forwarding of packets.</t>
<t>In the context of the CAP theorem, if one considers partition tolerance of paramount importance, traditional control plane operations are usually local and fast (available), while management plane operations are usually centralized (consistent) and may be slow.</t>
<t>The CAP theorem also provides insights into SDN architectures. For example a centralized SDN controller acts as a consistent global database, and specific SDN mechanisms ensure that a packet entering the network is handled consistently by all SDN switches. The issue of tolerance to loss of connectivity to the controller is not addressed by the basic SDN model. When an SDN switch cannot reach its controller, the flow will be unavailable until the connection is restored. The use of multiple non-collocated SDN controllers has been proposed (e.g., by configuring the SDN switch with a list of controllers); this may improve partition tolerance, but at the cost of loss of absolute consistency. Panda et al. <xref target="CAPFN"></xref> provide a first exploration of how the CAP theorem applies to SDN.</t>
</section>
</section>
<section title="Network Services Abstraction Layer" anchor="NSAL">
<t>The Network Services Abstraction Layer (NSAL) provides access from services of the control, management and application planes to other services and applications. We note that the term SAL is overloaded, as it is often used in several contexts ranging from system design to service-oriented architectures, therefore we explicitly add "Network" to the title of this layer to emphasize that this term relates to <xref target="SDNLayers" /> and we map it accordingly in <xref target="SDNView"/> to prominent SDN approaches.</t>
<t>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 communication, CORBA interfaces, and so on. The two leading approaches for service interfaces are RESTful interfaces and RPC interfaces. Both follow a client-server architecture and use XML or JSON to pass messages but each has some slightly different characteristics.</t>
<t>RESTful interfaces, designed according to the representational state transfer design paradigm <xref target="REST"/>, have the following characteristics:
<list>
<t>Resource identification - individual resources are identified using a resource identifier, for example a URI.</t>
<t>Manipulation of resources through representations - Resources are represented in a format like JSON, XML or HTML.</t>
<t>Self-descriptive messages - Each message has enough information to describe how the message is to be processed.</t>
<t>Hypermedia as the engine of application state - a client needs no prior knowledge of how to interact with a server, not through a fixed interface.</t></list></t>
<t>Remote procedure calls (RPC), e.g. <xref target="RFC5531"/>, XML-RPC and the like., have the following characteristics:
<list>
<t>Individual procedures are identified using an identifier</t>
<t>A client needs to know the procedure name and the associated parameters</t>
</list>
</t>
</section>
<section title="Application Plane" anchor="AP">
<t>Applications and services that use services from the control and/or management plane form the Application Plane.</t>
<t>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.</t>
<t>Examples of applications include network topology discovery, network provisioning, path reservation, etc.</t>
</section>
</section>
<section anchor="SDNView" title="SDN Model View" >
<t>We advocate that the SDN southbound interface should encompass both CSPI and MPSI.</t>
<t>The SDN northbound interface is implemented in the Network Services Abstraction Layer of <xref target="SDNLayers" />.</t>
<t>The above model can be used to describe in a concise manner all prominent SDN-enabling technologies, as we explain in the following subsections.</t>
<section title="ForCES">
<t>The IETF-standardized Forwarding and Control Element Separation (<xref target="RFC5810">ForCES</xref>) framework consists of one model and two protocols. ForCES separates the Forwarding from the Control Plane via an open interface, namely the ForCES protocol which operates on entities of the forwarding plane that have been modeled using the ForCES model.</t>
<t>The ForCES model is based on the fact that a network element is composed of numerous logically separate entities that cooperate to provide a given functionality -such as routing or IP switching- and yet appear as a normal integrated network element to external entities and secondly with a protocol to transport information. </t>
<t>ForCES models the Forwarding Plane using Logical Functional Blocks (LFBs) which are connected in a graph, composing the Forwarding Element (FE). LFBs are described in an XML language, based on an XML schema.</t>
<t>LFB definitions include:
<list style="symbols">
<t>Base and custom-defined datatypes</t>
<t>Metadata definitions</t>
<t>Input and Output ports</t>
<t>Operational parameters, or components</t>
<t>Capabilities</t>
<t>Event definitions</t>
</list>
</t>
<t>The ForCES model can be used to define LFBs from fine- to coarse-grained as needed, irrespective of whether they are physical or virtual.</t>
<t>The ForCES protocol is agnostic to the model and can be used to monitor, configure and control any ForCES-modeled element. The protocol has very simple commands: Set, Get and Del(ete). The ForCES protocol has been designed for high throughput and fast updates.</t>
<t><xref target="RFC5810">ForCES</xref> can be mapped to the framework illustrated in <xref target="SDNLayers" /> as follows:
<list style="symbols">
<t>The ForCES model can be used to describe DAL, both for the Operational and the Forwarding Plane, using LFBs .</t>
<t>The ForCES protocol can then be both the CPSI and the MPSI. ForCES is inherently specified for the CPSI and satisfies its requirements, however it can also be utilized for the MPSI.</t>
<t>CAL and MAL must be able to utilize the ForCES protocol.</t>
</list></t>
</section>
<section title="NETCONF">
<t>The Network Configuration Protocol (<xref target="RFC6241">NETCONF</xref>), is an IETF-standardized network management protocol <xref target="RFC6632"></xref>. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices.</t>
<t>NETCONF protocol operations are realized as remote procedure calls (RPCs). The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. Recent studies, such as <xref target="ESNet"/> and <xref target="PENet"></xref>, have shown that NETCONF performs better than SNMP <xref target="RFC3411"></xref>.</t>
<t>Additionally, the YANG data modeling language <xref target="RFC6020"/> has been developed for specifying NETCONF data models and protocol operations. YANG is a data modeling language used to model configuration and state data manipulated by NETCONF, NETCONF remote procedure calls, and NETCONF notifications.</t>
<t>YANG models the hierarchical organization of data as a tree, in which each node has either a value or a set of child nodes. Additionally, YANG structures data models into modules and submodules allowing reusability and augmentation. YANG models can describe constraints to be enforced on the data. Additionally YANG has a set of base datatype and allows custom defined datatypes as well.</t>
<t>YANG allows the definition of NETCONF RPCs allowing the protocol to have an extensible number of commands. For RPC definition, the operations names, input parameters, and output parameters are defined using YANG data definition statements.</t>
<t>NETCONF can be mapped to the framework illustrated in <xref target="SDNLayers" /> as follows:
<list style="symbols">
<t>The <xref target="RFC6020">YANG model</xref> is suitable for specifying DAL for the operational plane and <xref target="RFC6241">NETCONF</xref> for the MPSI.</t>
<t>Technically, the <xref target="RFC6020">YANG model</xref> can be used to specify DAL for the Forwarding plane as well. That said, in principle, <xref target="RFC6241">NETCONF</xref> is a management protocol which was not (originally) designed for fast CP updates, and it might not be suitable for addressing the requirements of CPSI.</t>
</list></t>
</section>
<section title="OpenFlow">
<t><xref target="OpenFlow"></xref> is a framework originally developed by Stanford, and currently under active standards development through the Open Networking Foundation (ONF). Initially, the goal was to provide a way for researchers to run experimental protocols in a production network <xref target="OFSIGC"/>. OpenFlow provides a protocol with which a controller may manage a static model of an OpenFlow switch.</t>
<t>An OpenFlow switch consists of one or more flow tables which perform packet lookups, actions on a success packet lookup and forwarding, a group table and an OpenFlow channel to an external controller. The switch communicates with the controller which manages the switch via the OpenFlow protocol.</t>
<t>OpenFlow has undergone many revisions. The current version is 1.4 <xref target="OpenFlow"></xref> and supports amongst others, multiple controllers for high availability and extensible flow match field protocol messages to support arbitrary match fields. Efforts to define OpenFlow 2.0 <xref target="PPIPP"/> are already underway aiming to provide an abstract forwarding model to provide protocol independence and device programmability.</t>
<t>OpenFlow can be mapped to the framework illustrated in <xref target="SDNLayers" /> as follows:
<list style="symbols">
<t>The <xref target="OpenFlow">Openflow switch specifications</xref> covers DAL for the Forwarding Plane and provides the specification for CPSI.</t>
<t>The <xref target="OF-CONFIG">OF-CONFIG protocol</xref> based on the <xref target="RFC6020">YANG model</xref>, provides DAL for the Operational Plane and specifies <xref target="RFC6241">NETCONF</xref> as the MPSI. OF-CONFIG overlaps with the OpenFlow DAL, but with <xref target="RFC6241">NETCONF</xref> as the transport protocol it shares the limitations described in the previous section.</t>
<t>CAL must be able to utilize the OpenFlow protocol.</t>
<t>MAL must be able to utilize the NETCONF protocol.</t>
</list></t>
</section>
<section title="I2RS">
<t>I2RS is currently developed by a recently-established IETF working group. The intention is to provide a standard interface to the routing system for real-time or event-driven interaction through a collection of protocol-based control or management interfaces. Essentially, I2RS aims to make the routing information base (RIB) programmable thus enabling new kinds of network provisioning and operation.</t>
<t>I2RS does not initially intend to create new interfaces, but rather leverage or extend existing ones and define informational models for the routing system. For example, the latest <xref target="I-D.ietf-i2rs-problem-statement">I2RS problem statement</xref> discusses previously-defined IETF protocols such as <xref target="RFC5810">ForCES</xref>, <xref target="RFC6241">NETCONF</xref>, and <xref target="RFC3417">SNMP</xref>. Regarding the definition of informational and data models, the I2RS working group has opted to use the <xref target="RFC6020">YANG</xref> modelling language.</t>
<t>Currently the I2RS working group is developing an <xref target="I-D.ietf-i2rs-rib-info-model">Information Model</xref> in regards to the Network Services Abstraction Layer for the I2RS agent.</t>
<t>I2RS can be mapped to the framework illustrated in <xref target="SDNLayers" /> as follows:
<list style="symbols">
<t>The <xref target="I-D.ietf-i2rs-architecture">I2RS architecture</xref> encompasses the Control and Application Planes and uses any CPSI and DAL that is available, whether that may be <xref target="RFC5810">ForCES</xref>, <xref target="OpenFlow">OpenFlow</xref> or another interface.</t>
<t>The I2RS agent is a Control Plane Service. All services or applications on top of that belong to either the Control, Management or the Application plane. In the I2RS documents, management access to the agent may be provided by management protocols like SNMP and NETCONF. The I2RS protocol may also be mapped to the Service Interface as it will provide access even to other than control applications.</t>
</list></t>
</section>
<section title="SNMP">
<t>The Simple Network Management Protocol (SNMP) is an IETF-standardized management protocol and is currently at its third revision (SNMPv3) <xref target="RFC3417">RFC 3417</xref>, <xref target="RFC3412">RFC 3412</xref> and <xref target="RFC3414">RFC 3414</xref>. It consists of a set of standards for network management, including an application layer protocol, a database schema, and a set of data objects. SNMP exposes management data (managed objects) in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried and set by managing applications.</t>
<t>SNMP uses an extensible design for describing data, defined by management information bases (MIBs). MIBs describe the structure of the management data of a device subsystem. MIBs use a hierarchical namespace containing object identifiers (OID). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by Structure of Management Information Version 2 <xref target="RFC2578">SMIv2</xref></t>
<t>SNMP could be mapped to the framework illustrated in <xref target="SDNLayers" /> as follows:
<list style="numbers">
<t>SNMP MIBs can be used to describe DAL for the Operational Plane. Similar to YANG, SNMP MIBs are able to describe DAL for the Forwarding Plane.</t>
<t>SNMP is suited for the MPSI.</t>
</list></t>
</section>
<section title="PCEP">
<t>The Path Computation Element <xref target="RFC4655">(PCE)</xref> architecture describes the PCE, an entity capable of computing paths for a single or set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for a variety of path computation problems and switching technologies. The PCE Communication Protocol (PCEP) <xref target="RFC5440">(PCEP)</xref> is an IETF protocol for communication between a Path Computation Client (PCC) and a PCE, or between multiple PCEs. </t>
<t>The PCE represents a vision of networks that separates path computation for services, the signaling of end-to-end connections and actual packet forwarding. The definition of online and offline path computation is dependent on the reachability of the PCE from network and NMS nodes, and the type of optimization request which may significantly impact the optimization response time from the PCE to the PCC. </t>
<t>The PCEP messaging mechanism facilitates the specification of computation endpoints (source and destination node addresses) and objective functions (requested algorithm and optimization criteria), and the associated constraints such as traffic parameters (e.g. requested bandwidth), the switching capability, and encoding type.</t>
<t>The PCE is a control plane service that provides services for control plane applications.</t>
<t>PCEP may be used as an east-west interface between PCEs which may act as domain control entities (services and applications).</t>
</section>
<section title="BFD">
<t>Bidirectional Forwarding Detection <xref target="RFC5880">(BFD)</xref>, is an IETF-standardized network protocol designed for detecting communication failures between two adjacent forwarding elements. It is intended to be implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated. BFD provides a low-overhead solution for (end-to-end) detection of failures, even over technologies that have no or limited support to do so, such as virtual circuits, various L3/L4 tunnels and MPLS LSPs.</t>
<t>BFD could be mapped to the framework illustrated in <xref target="SDNLayers" /> either as:
<list style="numbers">
<t>A control plane service or application that would use the CPSI towards the forwarding plane to send/receive BFD packets.</t>
<t>Or, better, as it was intended for, i.e. as an application that runs on the device itself and uses the forwarding plane to send/receive BFD packets and update the operational plane resources accordingly.</t>
</list></t>
</section>
</section>
<section anchor="Contributors" title="Contributors">
<t>The authors would like to acknowledge (in alphabetical order) the following persons as contributors to this document. They all provided text, pointers and comments that made this document more complete:</t>
<t>Daniel King for providing text related to PCEP.</t>
<t>Scott Mansfield for information regarding current ITU work on SDN.</t>
<t>Yaakov Stein for providing text related to the CAP theorem and SDO-related information.</t>
<t>Russ White for text suggestions on the definitions on control, management and application.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to acknowledge Salvatore Loreto and Sudhir Modali for their contributions in the initial discussion on the SDNRG mailing list as well as their draft-specific comments; they helped put this document in a better shape.</t>
<t>Additionally we would like to thank (in alphabetical order) Shivleela Arlimatti, Roland Bless, Scott Brim, Alan Clark, Luis Miguel Contreras Murillo, Tim Copley, Linda Dunbar, Ken Gray, Deniz Gurkan, Dave Hood, Georgios Karagiannis, Bhumip Khasnabish, Sriganesh Kini, Ramki Krishnan, Dirk Kutscher, Diego Lopez, Scott Mansfield, Pedro Martinez-Julia, David E Mcdysan, Erik Nordmark, Carlos Pignataro, Robert Raszuk, Bless Roland, Francisco Javier Ros Munoz, Yaakov Stein, Dimitri Staessens, Eve Varma, Stuart Venters, Russ White and Lee Young for their critical comments and discussions at the IETF 88, IETF 89 and IETF 90 meetings and the SDNRG mailing list, which we took into consideration while revising this document.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo makes no requests to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not propose a new network architecture or protocol and therefore does not have any impact on the security of the Internet. That said, security is paramount in networking and thus it should be given full consideration when designing a network architecture or operational deployment. Security in SDN is discussed in the literature, for example in <xref target="SDNSecurity"/><xref target="SDNSecServ"/> and <xref target="SDNSecOF"/>. Security considerations regarding specific interfaces, such as, for example, ForCES, I2RS, SNMP, or NETCONF are addressed in their respective documents as well as <xref target="RFC7149"/>.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Informative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC5810;
&RFC5812;
&RFC6241;
&RFC6020;
&RFC3418;
&RFC3411;
&RFC7047;
&RFC7149;
&I2RSArch;
&I2RSInfo;
&I2RSProb;
&RFC6632;
&RFC3535;
&RFC5880;
&RFC5743;
&RFC0826;
&RFC1953;
&RFC2297;
&RFC4271;
&RFC5531;
&RFC2578;
&RFC3417;
&RFC3412;
&RFC3414;
&RFC5440;
&RFC4655;
<reference anchor="FCAPS" target="http://www.itu.int/rec/T-REC-X.700-199209-I/en">
<front>
<title>X.700: Management Framework For Open Systems Interconnection (OSI) For CCITT Applications</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="September" year="1992"></date>
</front>
</reference>
<reference anchor="PNSurvey99">
<front>
<title>A survey of programmable networks</title>
<author>
<organization>Campbell, Andrew T., et al</organization>
</author>
<date month="September" year="1992"></date>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review 29.2 (1999): 7-23" value=""></seriesInfo>
</reference>
<reference anchor="SDNHistory">
<front>
<title>The Road to SDN</title>
<author>
<organization>Feamster, Nick, Jennifer Rexford, and Ellen Zegura.</organization>
</author>
<date year="2013"></date>
</front>
<seriesInfo name="ACM Queue11, no. 12 (2013): 20." value=""></seriesInfo>
</reference>
<reference anchor="OF08">
<front>
<title>OpenFlow: enabling innovation in campus networks</title>
<author>
<organization>McKeown, Nick, et al.</organization>
</author>
<date year="2008"></date>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review 38.2 (2008): 69-74" value=""></seriesInfo>
</reference>
<reference anchor="P1520">
<front>
<title>The IEEE P1520 standards initiative for programmable network interfaces.</title>
<author>
<organization>Biswas, Jit, Aurel A. Lazar, J-F. Huard, Koonseng Lim, Semir Mahjoub, L-F. Pau, Masaaki Suzuki, Soren Torstensson, Weiguo Wang, and Stephen Weinstein.</organization>
</author>
<date year="1998"></date>
</front>
<seriesInfo name="Communications Magazine, IEEE 36, no. 10 (1998): 64-70." value=""></seriesInfo>
</reference>
<reference anchor="NV09">
<front>
<title>Network virtualization: state of the art and research challenges</title>
<author>
<organization>Chowdhury, NM Mosharaf Kabir, and Raouf Boutaba</organization>
</author>
<date year="2009"></date>
</front>
<seriesInfo name="Communications Magazine, IEEE 47.7 (2009): 20-26" value=""></seriesInfo>
</reference>
<reference anchor="A4D05">
<front>
<title>A clean slate 4D approach to network control and management</title>
<author>
<organization>Greenberg, Albert, et al. </organization>
</author>
<date year="2005"></date>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review 35.5 (2005): 41-54" value=""></seriesInfo>
</reference>
<reference anchor="RCP">
<front>
<title>Design and implementation of a routing control platform.</title>
<author>
<organization>Caesar, Matthew, Donald Caldwell, Nick Feamster, Jennifer Rexford, Aman Shaikh, and Jacobus van der Merwe.</organization>
</author>
<date year="2005"></date>
</front>
<seriesInfo name="In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation-Volume 2, pp. 15-28. USENIX Association, 2005." value=""></seriesInfo>
</reference>
<reference anchor="PPIPP">
<front>
<title>Programming Protocol-Independent Packet Processors.</title>
<author>
<organization>Bosshart, Pat, Dan Daly, Martin Izzard, Nick McKeown, Jennifer Rexford, Dan Talayco, Amin Vahdat, George Varghese, and David Walker.</organization>
</author>
<date year="2013"></date>
</front>
<seriesInfo name="arXiv preprint arXiv:1312.1719 (2013)." value=""></seriesInfo>
</reference>
<reference anchor="RouteFlow">
<front>
<title>Virtual routers as a service: the routeflow approach leveraging software-defined networks.</title>
<author>
<organization>Nascimento, Marcelo R., Christian E. Rothenberg, Marcos R. Salvador, Carlos NA Correa, Sidney C. de Lucena, and Mauricio F. Magalhaes.</organization>
</author>
<date year="2011"></date>
</front>
<seriesInfo name="In Proceedings of the 6th International Conference on Future Internet Technologies, pp. 34-37. ACM, 2011." value=""></seriesInfo>
</reference>
<reference anchor="SoftRouter">
<front>
<title>The softrouter architecture.</title>
<author>
<organization>Lakshman, T. V., T. Nandagopal, R. Ramjee, K. Sabnani, and T. Woo.</organization>
</author>
<date year="2004"></date>
</front>
<seriesInfo name=" In Proc. ACM SIGCOMM Workshop on Hot Topics in Networking. 2004." value=""></seriesInfo>
</reference>
<reference anchor="PENet">
<front>
<title>Protocol Efficiencies of NETCONF versus SNMP for Configuration Management Functions</title>
<author>
<organization>Hedstrom, Brian, Akshay Watwe, and Siddharth Sakthidharan</organization>
</author>
<date year="2011"></date>
</front>
<seriesInfo name="PhD dissertation, Master's thesis, University of Colorado, 2011" value=""></seriesInfo>
</reference>
<reference anchor="ESNet">
<front>
<title>An empirical study of the NETCONF protocol.</title>
<author>
<organization>Yu, James, and Imad Al Ajarmeh.</organization>
</author>
<date year="2010"></date>
</front>
<seriesInfo name="In Networking and Services (ICNS), 2010 Sixth International Conference on, pp. 253-258. IEEE, 2010." value=""></seriesInfo>
</reference>
<reference anchor="Tempest">
<front>
<title>The Tempest: a framework for safe, resource assured, programmable networks.</title>
<author>
<organization>Rooney, Sean, Jacobus E. van der Merwe, Simon A. Crosby, and Ian M. Leslie.</organization>
</author>
<date year="1998"></date>
</front>
<seriesInfo name="Communications Magazine, IEEE 36, no. 10 (1998): 42-53" value=""></seriesInfo>
</reference>
<reference anchor="DIOPR">
<front>
<title>Designing interfaces for open programmable routers.</title>
<author>
<organization>Denazis, Spyros, Kazuho Miki, John Vicente, and Andrew Campbell.</organization>
</author>
<date year="1999"></date>
</front>
<seriesInfo name="In Active Networks, pp. 13-24. Springer Berlin Heidelberg, 1999" value=""></seriesInfo>
</reference>
<reference anchor="OFSIGC">
<front>
<title>OpenFlow: enabling innovation in campus networks.</title>
<author>
<organization>McKeown, Nick, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner.</organization>
</author>
<date year="1998"></date>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review 38, no. 2 (2008): 69-74." value=""></seriesInfo>
</reference>
<reference anchor="KANDOO">
<front>
<title>Kandoo: a framework for efficient and scalable offloading of control applications.</title>
<author>
<organization>Hassas Yeganeh, Soheil, and Yashar Ganjali.</organization>
</author>
<date year="2012"></date>
</front>
<seriesInfo name="In Proceedings of the first workshop on Hot topics in software defined networks, pp. 19-24. ACM SIGCOMM, 2012." value=""></seriesInfo>
</reference>
<reference anchor="SDNNFV">
<front>
<title>Towards a Network Abstraction Model for SDN.</title>
<author>
<organization>Haleplidis, Evangelos, Jamal Hadi Salim, Spyros Denazis, and Odysseas Koufopavlou.</organization>
</author>
<date year="2014"></date>
</front>
<seriesInfo name="Journal of Network and Systems Management (2014): 1-19. Special Issue on Management of Software Defined Networks, Springer" value=""></seriesInfo>
</reference>
<reference anchor="OpenFlow" target="https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf">
<front>
<title>The OpenFlow 1.4 Specification.</title>
<author>
<organization>Open Networking Foundation</organization>
</author>
<date day="15" month="October" year="2013"></date>
</front>
</reference>
<reference anchor="REST">
<front>
<title>Fielding Dissertation: Chapter 5: Representational State Transfer (REST).</title>
<author>
<organization>Fielding, Roy</organization>
</author>
<date year="2000"></date>
</front>
</reference>
<!-- ITU -->
<reference anchor="ITUATM">
<front>
<title>CCITT Recommendation 1.361, B-ISDN ATM Layer Specification</title>
<author>
<organization>CCITT, Geneva, Switzerland</organization>
</author>
<date year="1990"></date>
</front>
</reference>
<reference anchor="ITUSS7">
<front>
<title>ITU, Q.700 : Introduction to CCITT Signalling System No. 7</title>
<author>
<organization>Telecommunication Standardization sector of ITU</organization>
</author>
<date year="1993"></date>
</front>
</reference>
<reference anchor="ITUSG13" target="http://www.itu.int/en/ITU-T/studygroups/2013-2016/13/Pages/default.aspx">
<front>
<title>ITU, Study group 13</title>
<author>
<organization>Telecommunication Standardization sector of ITU</organization>
</author>
<date year="2013"></date>
</front>
</reference>
<reference anchor="ITUSG11" target="http://www.itu.int/en/ITU-T/studygroups/2013-2016/11/Pages/default.aspx">
<front>
<title>ITU, Study group 11</title>
<author>
<organization>Telecommunication Standardization sector of ITU</organization>
</author>
<date year="2013"></date>
</front>
</reference>
<reference anchor="ITUY3300" target="http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12168">
<front>
<title>Y.3300, Framework of software-defined networking</title>
<author>
<organization>ITU-T Study Group 13</organization>
</author>
<date day="6" month="June" year="2014"></date>
</front>
</reference>
<!-- ONF -->
<reference anchor="ONFArch" target="https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf">
<front>
<title>SDN Architecture, Issue 1</title>
<author>
<organization>Open Networking Foundation</organization>
</author>
<date month="June" year="2014"></date>
</front>
</reference>
<reference anchor="OF-CONFIG" target="https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1-1-1.pdf">
<front>
<title>OpenFlow Management and Configuration Protocol 1.1.1</title>
<author>
<organization>Open Networking Foundation</organization>
</author>
<date day="23" month="March" year="2013"></date>
</front>
</reference>
<!-- SDN Surveys -->
<reference anchor="SLTSDN">
<front>
<title>A Survey and a Layered Taxonomy of Software-Defined Networking</title>
<author>
<organization>Yosr Jarraya, Taous Madi, and Mourad Debbabi</organization>
</author>
<date year="2014"></date>
</front>
<seriesInfo name="To be published in Communications Surveys and Tutorials, IEEE Issue: 99" value=""></seriesInfo>
</reference>
<reference anchor="SDNACS">
<front>
<title>Software-Defined Networking: A Comprehensive Survey.</title>
<author>
<organization>Diego Kreutz, Fernando M. V. Ramos, Paulo Verissimo, Christian Esteve Rothenberg, Siamak Azodolmolky, Steve Uhlig</organization>
</author>
<date year="2014"></date>
</front>
<seriesInfo name="arXiv preprint arXiv:1406.0440" value=""></seriesInfo>
</reference>
<reference anchor="SDNSurvey">
<front>
<title>A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks</title>
<author>
<organization>Bruno Astuto A. Nunes, Marc Mendonca, Xuan-Nam Nguyen, Katia Obraczka, and Thierry Turletti</organization>
</author>
<date year="2014"></date>
</front>
<seriesInfo name="IEEE Communications Surveys and Tutorials DOI:10.1109/SURV.2014.012214.00180" value=""></seriesInfo>
</reference>
<!-- Security -->
<reference anchor="SDNSecurity">
<front>
<title>Towards secure and dependable software-defined networks.</title>
<author>
<organization>Diego Kreutz, Fernando Ramos, and Paulo Verissimo. </organization>
</author>
<date year="2013"></date>
</front>
<seriesInfo name="In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking, pp. 55-60. ACM, 2013." value=""></seriesInfo>
</reference>
<reference anchor="SDNSecServ">
<front>
<title>SDN security: A survey.</title>
<author>
<organization>Sandra Scott-Hayward, Gemma O'Callaghan, and Sakir Sezer.</organization>
</author>
<date year="2013"></date>
</front>
<seriesInfo name="In Future Networks and Services (SDN4FNS), 2013 IEEE SDN for, pp. 1-7. IEEE, 2013." value=""></seriesInfo>
</reference>
<reference anchor="SDNSecOF" target="http://www.csg.ethz.ch/people/vkotroni/openflow_sec">
<front>
<title>Openflow: A security analysis.</title>
<author>
<organization>Kloti, Rowan, Vasileios Kotronis, and Paul Smith.</organization>
</author>
<date year="2013"></date>
</front>
<seriesInfo name="Proceedings Workshop on Secure Network Protocols (NPSec). IEEE (2013)." value=""></seriesInfo>
</reference>
<!-- CAP Theorem -->
<reference anchor="CAPGL">
<front>
<title>Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services</title>
<author>
<organization>Seth Gilbert, and Nancy Ann Lynch. </organization>
</author>
<date year="2002"></date>
</front>
<seriesInfo name="ACM SIGACT News 33.2 (2002): 51-59." value=""></seriesInfo>
</reference>
<reference anchor="CAPBR">
<front>
<title>Towards robust distributed systems.</title>
<author>
<organization>Eric A. Brewer</organization>
</author>
<date year="2000"></date>
</front>
<seriesInfo name=" Symposium on Principles of Distributed Computing (PODC). 2000" value=""></seriesInfo>
</reference>
<reference anchor="CAPFN">
<front>
<title>CAP for Networks.</title>
<author>
<organization>Panda, Aurojit, Colin Scott, Ali Ghodsi, Teemu Koponen, and Scott Shenker. </organization>
</author>
<date year="2013"></date>
</front>
<seriesInfo name="In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking, pp. 91-96. ACM, 2013." value=""></seriesInfo>
</reference>
<!-- NFV -->
<reference anchor="NFVArch" target="http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf">
<front>
<title>Network Functions Virtualisation (NFV): Architectural Framework; White paper, ETSI GS 9 NFV 002, 2013</title>
<author>
<organization>European Telecommunication Standards Institute</organization>
</author>
<date day="12" month="December" year="2013"></date>
</front>
</reference>
<!-- RINA -->
<reference anchor="RINA">
<front>
<title>Networking is IPC: a guiding principle to a better internet.</title>
<author>
<organization>John Day, Ibrahim Matta, and Karim Mattar. </organization>
</author>
<date year="2008"></date>
</front>
<seriesInfo name="In Proceedings of the 2008 ACM CoNEXT Conference, p. 67. ACM, 2008." value=""></seriesInfo>
</reference>
<reference anchor="PiNA">
<front>
<title>Patterns in network architecture: a return to fundamentals.</title>
<author>
<organization>John Day</organization>
</author>
<date year="2007"></date>
</front>
<seriesInfo name="Prentice Hall (ISBN 0132252422)." value=""></seriesInfo>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:28:24 |