summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7426.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7426.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7426.txt')
-rw-r--r--doc/rfc/rfc7426.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc7426.txt b/doc/rfc/rfc7426.txt
new file mode 100644
index 0000000..15312c3
--- /dev/null
+++ b/doc/rfc/rfc7426.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF) E. Haleplidis, Ed.
+Request for Comments: 7426 University of Patras
+Category: Informational K. Pentikousis, Ed.
+ISSN: 2070-1721 EICT
+ S. Denazis
+ University of Patras
+ J. Hadi Salim
+ Mojatatu Networks
+ D. Meyer
+ Brocade
+ O. Koufopavlou
+ University of Patras
+ January 2015
+
+
+ Software-Defined Networking (SDN): Layers and Architecture Terminology
+
+Abstract
+
+ Software-Defined Networking (SDN) refers to a new approach for
+ network programmability, that is, the capacity to initialize,
+ control, change, and manage network behavior dynamically via open
+ 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 the layer structure is in an SDN
+ architecture, and how layers interface with each other. This
+ document, a product of the IRTF Software-Defined Networking Research
+ Group (SDNRG), addresses these questions and provides a concise
+ reference for the SDN research community based on relevant peer-
+ reviewed literature, the RFC series, and relevant documents by other
+ standards organizations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 1]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Research Task Force
+ (IRTF). The IRTF publishes the results of Internet-related research
+ and development activities. These results might not be suitable for
+ deployment. This RFC represents the consensus of the Software-
+ Defined Networking Research Group of the Internet Research Task Force
+ (IRTF). Documents approved for publication by the IRSG are not a
+ candidate for any level of Internet Standard; see Section 2 of RFC
+ 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7426.
+
+Copyright Notice
+
+ Copyright (c) 2015 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 2]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................5
+ 3. SDN Layers and Architecture .....................................7
+ 3.1. Overview ...................................................9
+ 3.2. Network Devices ...........................................12
+ 3.3. Control Plane .............................................13
+ 3.4. Management Plane ..........................................14
+ 3.5. Discussion of Control and Management Planes ...............16
+ 3.5.1. Timescale ..........................................16
+ 3.5.2. Persistence ........................................16
+ 3.5.3. Locality ...........................................16
+ 3.5.4. CAP Theorem Insights ...............................17
+ 3.6. Network Services Abstraction Layer ........................18
+ 3.7. Application Plane .........................................19
+ 4. SDN Model View .................................................19
+ 4.1. ForCES ....................................................19
+ 4.2. NETCONF/YANG ..............................................20
+ 4.3. OpenFlow ..................................................21
+ 4.4. Interface to the Routing System ...........................21
+ 4.5. SNMP ......................................................22
+ 4.6. PCEP ......................................................23
+ 4.7. BFD .......................................................23
+ 5. Summary ........................................................24
+ 6. Security Considerations ........................................24
+ 7. Informative References .........................................25
+ Acknowledgements ..................................................33
+ Contributors ......................................................34
+ Authors' Addresses ................................................34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 3]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+1. Introduction
+
+ "Software-Defined Networking (SDN)" is a term of the programmable
+ networks paradigm [PNSurvey99] [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 [NV09]. Boucadair and Jacquenet [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.
+
+ 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 [A4D05].
+
+ The historical evolution of the research and development area of
+ programmable networks is reviewed in detail in [SDNHistory]
+ [SDNSurvey], starting with efforts dating back to the 1980s. As
+ documented in [SDNHistory], many of the ideas, concepts, and concerns
+ are applicable to the latest research and development in SDN (and SDN
+ standardization) and have been under extensive investigation and
+ discussion in the research community for quite some time. For
+ example, Rooney, et al. [Tempest] 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 forwarding planes, which is prominent in SDN, has been
+ extensively discussed even prior to 1998 [Tempest] [P1520] in SS7
+ networks [ITUSS7], Ipsilon Flow Switching [RFC1953] [RFC2297], and
+ ATM [ITUATM].
+
+ 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
+ OpenFlow [OpenFlow] and the Network Configuration Protocol (NETCONF)
+ [RFC6241] have been characterized as SDN interfaces, but they refer
+ to control and management, respectively.
+
+ 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
+
+
+
+Haleplidis, et al. Informational [Page 4]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ interfaces and their corresponding attributes are best suited 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 that reflects current approaches regarding the SDN
+ layer 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.
+
+ This document addresses the work item in the SDNRG charter titled
+ "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 document 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
+ [SLTSDN] and [SDNACS]. In particular, Jarraya, et al. [SLTSDN]
+ provide an overview of SDN-related research topics, e.g., control
+ partitioning, which is related to the Consistency, Availability and
+ Partitioning (CAP) theorem discussed in Section 3.5.4.
+
+ This document has been extensively reviewed, discussed, and commented
+ by the vast majority of SDNRG members, a community that certainly
+ exceeds 100 individuals. It is the consensus of SDNRG that this
+ document should be published in the IRTF stream of the RFC series
+ [RFC5743].
+
+ The remainder of this document is organized as follows. Section 2
+ explains the terminology used in this document. Section 3 introduces
+ a high-level overview of current SDN architecture abstractions.
+ Finally, Section 4 discusses how the SDN layer architecture relates
+ to prominent SDN-enabling technologies.
+
+2. Terminology
+
+ This document uses the following terms:
+
+ o Software-Defined Networking (SDN) - A programmable networks
+ approach that supports the separation of control and forwarding
+ planes via standardized interfaces.
+
+ o 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).
+
+
+
+Haleplidis, et al. Informational [Page 5]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ o 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.
+
+ o 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.
+
+ o 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 parameterized, 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.
+
+ o 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.
+
+ o Forwarding Plane (FP) - The collection of resources across all
+ network devices responsible for forwarding traffic.
+
+ o Operational Plane (OP) - The collection of resources responsible
+ for managing the overall operation of individual network devices.
+
+ o 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.
+
+ o 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 to the operational plane (it is related less to the
+ forwarding plane).
+
+ o Application Plane - The collection of applications and services
+ that program network behavior.
+
+
+
+
+Haleplidis, et al. Informational [Page 6]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ o 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.
+
+ o Control Abstraction Layer (CAL) - The control plane's abstraction
+ layer. CAL provides access to the Control-Plane Southbound
+ Interface.
+
+ o Management Abstraction Layer (MAL) - The management plane's
+ abstraction layer. MAL provides access to the Management-Plane
+ Southbound Interface.
+
+ o Network Services Abstraction Layer (NSAL) - Provides service
+ abstractions that can be used by applications and services.
+
+3. SDN Layers and Architecture
+
+ Figure 1 summarizes the SDN architecture abstractions in the form of
+ a detailed, high-level schematic. Note that in a particular
+ implementation, planes can be collocated with other planes or can be
+ physically separated, as we discuss below.
+
+ 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
+ invocations 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.
+
+ Day [PiNA] explores the use of IPC as the mainstay for the definition
+ of recursive network architectures with varying degrees of scope and
+ range of operation. The Recursive InterNetwork Architecture [RINA]
+ outlines a recursive network architecture based on IPC that
+ 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 the scope of this
+ work, Figure 1 illustrates a hierarchical model in which layers can
+ be stacked on top of each other and employed recursively as needed.
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 7]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ 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 |
+ +---------------------------------------------------------------+
+
+ Figure 1: SDN Layer Architecture
+
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 8]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+3.1. Overview
+
+ This document follows a network-device-centric approach: control
+ mostly refers to the device packet-handling capability, while
+ management typically refers to aspects of the overall device
+ operation. We view a network device as a complex resource that
+ contains and is part of multiple resources similar to [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.
+
+ The reader should keep in mind that we make no distinction between
+ "physical" and "virtual" resources or "hardware" and "software"
+ realizations in this document, 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 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 the scope of this
+ document.
+
+ 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 data
+ path 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. The forwarding plane is also
+ widely referred to as the "data plane" or the "data path".
+
+ o 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 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
+
+
+
+Haleplidis, et al. Informational [Page 9]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ practice, an amalgamation of functions on the forwarding plane.
+ For others, however, a "plane" allows one to distinguish between
+ different areas of operations; therefore, the operational plane is
+ included as a "plane" in Figure 1. We have adopted this latter
+ view in this document.
+
+ o Control Plane - Responsible for making 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.
+
+ o Management Plane - Responsible for monitoring, configuring, and
+ maintaining network devices, e.g., making 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.
+
+ o 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 Figure 1.
+
+ [RFC7276] has defined the data, control, and management planes in
+ terms of Operations, Administration, and Maintenance (OAM). This
+ document attempts to broaden the terms defined in [RFC7276] in order
+ to reflect all aspects of an SDN architecture.
+
+ All planes mentioned above are connected via interfaces (indicated
+ with "Y" in Figure 1. 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 collocated on the
+
+
+
+
+Haleplidis, et al. Informational [Page 10]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ 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.
+
+ 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 planes 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 Figure 1. An example of such a case would be an
+ application that uses both [OpenFlow] and [OF-CONFIG].
+
+ 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.
+
+ While not shown explicitly in Figure 1, 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 be provided to other applications or services through
+ NSAL. Additional examples include virtual resources that are
+ realized on top of a physical resources and hierarchical control-
+ plane controllers [KANDOO].
+
+ Note that the focus in this document is, of course, on the north/
+ south communication between entities in different planes. But this,
+ clearly, does not exclude entity communication within any one plane.
+
+ It must be noted, however, that in Figure 1, 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, in many networks, especially in Internet
+ routers and Ethernet switches, the control plane has been usually
+ implemented as tightly coupled with the network device. When taken
+ as a whole, the control plane has been distributed network-wide. On
+ the other hand, the management plane has been traditionally
+ centralized and has been responsible for managing the control plane
+ and the devices. However, with the adoption of SDN principles, this
+ distinction is no longer so clear-cut.
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 11]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ Additionally, this document considers four abstraction layers:
+
+ o The Device and resource Abstraction Layer (DAL) abstracts the
+ resources of the device's forwarding and operational planes to the
+ control and management planes. 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.
+
+ o The Control Abstraction Layer (CAL) abstracts the Control-Plane
+ Southbound Interface and the DAL from the applications and
+ services of the control plane.
+
+ o The Management Abstraction Layer (MAL) abstracts the Management-
+ Plane Southbound Interface and the DAL from the applications and
+ services of the management plane.
+
+ o The Network Services Abstraction Layer (NSAL) provides service
+ abstractions for use by applications and other services.
+
+ At the time of this writing, SDN-related activities have begun in
+ other SDOs. For example, at the ITU, work on architectural [ITUSG13]
+ and signaling requirements and protocols [ITUSG11] has commenced, but
+ the respective study groups have yet to publish their documents, with
+ the exception of [ITUY3300]. The views presented in [ITUY3300] as
+ well as in [ONFArch] are well aligned with this document.
+
+3.2. Network Devices
+
+ 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), 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 below IP (such
+ as Layer 2 switches and optical or microwave network elements).
+
+ 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 a
+ presence in a forwarding plane and an operational plane.
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 12]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ 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.
+
+ 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.
+
+ 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 Forwarding and Control Element Separation (ForCES)
+ [RFC5812], OpenFlow [OpenFlow], YANG model [RFC6020], and SNMP MIBs
+ [RFC3418]. Examples of the operational-plane abstraction model
+ include the ForCES model [RFC5812], the YANG model [RFC6020], and
+ SNMP MIBs [RFC3418].
+
+ Note that applications can also reside in a network device. Examples
+ of such applications include event monitoring and handling
+ (offloading) topology discovery or ARP [RFC0826] in the device itself
+ instead of forwarding such traffic to the control plane.
+
+3.3. Control Plane
+
+ 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.
+
+ Communication between control-plane entities, colloquially referred
+ to as the "east-west" interface, is usually implemented through
+ gateway protocols such as BGP [RFC4271] or other protocols such as
+ the Path Computation Element (PCE) Communication Protocol (PCEP)
+ [RFC5440]. These corresponding protocol messages are usually
+ exchanged in-band and subsequently redirected by the forwarding plane
+ to the control plane for further processing. Examples in this
+ category include [RCP], [SoftRouter], and [RouteFlow].
+
+ Control-plane functionalities usually include:
+
+ o Topology discovery and maintenance
+
+ o Packet route selection and instantiation
+
+ o Path failover mechanisms
+
+
+
+Haleplidis, et al. Informational [Page 13]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ The CPSI is usually defined with the following characteristics:
+
+ o time-critical interface that requires low latency and sometimes
+ high bandwidth in order to perform many operations in short order
+
+ o oriented towards wire efficiency and device representation instead
+ of human readability
+
+ 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 inter-
+ process 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
+ [OpenFlow].
+
+ The Control Abstraction Layer (CAL) provides access to control
+ applications and services to various CPSIs. The control plane may
+ support more than one CPSI.
+
+ 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.
+
+ Control-plane service examples include a virtual private LAN service,
+ service tunnels, topology services, etc.
+
+3.4. Management Plane
+
+ 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.
+
+ 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 [FCAPS] typically include:
+
+ o Fault and monitoring management
+
+ o Configuration management
+
+ In addition, management-plane functionalities may also include
+ entities such as orchestrators, Virtual Network Function Managers
+ (VNF Managers) and Virtualised Infrastructure Managers, as described
+ in [NFVArch]. Such entities can use management interfaces to
+
+
+
+Haleplidis, et al. Informational [Page 14]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ 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 Network
+ Function Virtualization (NFV) is explored in [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 the scope of this
+ document.
+
+ The MPSI, in contrast to the CPSI, is usually not a time-critical
+ interface and does not share the CPSI requirements.
+
+ MPSI is typically closer to human interaction than CPSI (cf.
+ [RFC3535]); therefore, MPSI usually has the following
+ characteristics:
+
+ o It is oriented more towards usability, with optimal wire
+ performance being a secondary concern.
+
+ o Messages tend to be less frequent than in the CPSI.
+
+ As an example of usability versus performance, we refer to the
+ consensus of the 2002 IAB Workshop [RFC3535]: the key requirement for
+ a network management technology is ease of use, not performance. As
+ per [RFC6632], 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 requires more processing capabilities to parse.
+
+ MPSI can range from a protocol, to an API or even inter-process
+ communication. If the management plane is not embedded in the
+ network device, the MPSI is certainly a protocol. Examples of MPSIs
+ are ForCES [RFC5810], NETCONF [RFC6241], IP Flow Information Export
+ (IPFIX) [RFC7011], Syslog [RFC5424], Open vSwitch Database (OVSDB)
+ [RFC7047], 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, fault detection,
+ and recovery applications.
+
+
+
+
+
+Haleplidis, et al. Informational [Page 15]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ Management-plane services provide access to other services or
+ applications above the management plane.
+
+3.5. Discussion of Control and Management Planes
+
+ The definition of a clear distinction between "control" and
+ "management" in the context of SDN received significant community
+ attention during the preparation of this document. We observed that
+ the role of the management plane has been earlier largely ignored or
+ specified as out-of-scope for the SDN ecosystem. In the remainder of
+ this subsection, we summarize the characteristics that differentiate
+ the two planes in order to have a clear understanding of the
+ mechanics, capabilities, and needs of each respective interface.
+
+3.5.1. Timescale
+
+ A point has been raised regarding the reference timescales for the
+ control and management planes regarding how fast the respective plane
+ is required to react to, or how fast it 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; 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.
+
+3.5.2. Persistence
+
+ Another distinction between the control and management planes relates
+ to state persistence. A state is considered ephemeral if it has a
+ very limited lifespan and is not deemed necessary to be stored on
+ non-volatile memory. 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 that may range from hours
+ to days and months, is meant to be used beyond the lifetime of the
+ process that created it, and is thus used across device reboots.
+ Persistent state is usually associated with the management plane.
+
+3.5.3. Locality
+
+ 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 "logically centralizing", the controller tends to
+ muddle the distinction of the control and management plane based on
+ locality.
+
+
+
+Haleplidis, et al. Informational [Page 16]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+3.5.4. CAP Theorem Insights
+
+ 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:
+
+ o Consistency, meaning that the system responds identically to a
+ query no matter which node receives the request (or does not
+ respond at all).
+
+ o Availability, i.e., that the system always responds to a request
+ (although the response may not be consistent or correct).
+
+ o Partition tolerance, namely that the system continues to function
+ even when specific nodes or the communications network fail.
+
+ In 2000, Eric Brewer [CAPBR] 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 Gilbert and Lynch [CAPGL]
+ and is now usually referred to as the CAP theorem [CAPFN].
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Haleplidis, et al. Informational [Page 17]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ 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. [CAPFN] provide a first
+ exploration of how the CAP theorem applies to SDN.
+
+3.6. Network Services Abstraction Layer
+
+ 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 Figure 1, and we map it accordingly in Section 4
+ to prominent SDN approaches.
+
+ Service interfaces can take many forms pertaining to their specific
+ requirements. Examples of service interfaces include, but are not
+ limited to, RESTful APIs, open protocols such as NETCONF, inter-
+ process communication, CORBA [CORBA] interfaces, and so on. The two
+ leading approaches for service interfaces are RESTful interfaces and
+ Remote Procedure Call (RPC) interfaces. Both follow a client-server
+ architecture and use XML or JSON to pass messages, but each has some
+ slightly different characteristics.
+
+ RESTful interfaces, designed according to the representational state
+ transfer design paradigm [REST], have the following characteristics:
+
+ o Resource identification - Individual resources are identified
+ using a resource identifier, for example, a URI.
+
+ o Manipulation of resources through representations - Resources are
+ represented in a format like JSON, XML, or HTML.
+
+ o Self-descriptive messages - Each message has enough information to
+ describe how the message is to be processed.
+
+ o Hypermedia as the engine of application state - A client needs no
+ prior knowledge of how to interact with a server, as the API is
+ not fixed but dynamically provided by the server.
+
+ Remote procedure calls (RPCs) [RFC5531], e.g., XML-RPC and the like,
+ have the following characteristics:
+
+ o Individual procedures are identified using an identifier.
+
+ o A client needs to know the procedure name and the associated
+ parameters.
+
+
+
+Haleplidis, et al. Informational [Page 18]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+3.7. 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.
+
+4. SDN Model View
+
+ We advocate that the SDN southbound interface should encompass both
+ CPSI and MPSI.
+
+ SDN controllers such as [NOX] and [Beacon] are a collection of
+ control-plane applications and services that implement a CPSI ([NOX]
+ and [Beacon] both use OpenFlow) and provide a northbound interface
+ for applications. The SDN northbound interface for controllers is
+ implemented in the Network Services Abstraction Layer (NSAL) of
+ Figure 1.
+
+ The above model can be used to describe all prominent SDN-enabling
+ technologies in a concise manner, as we explain in the following
+ subsections.
+
+4.1. ForCES
+
+ The IETF Forwarding and Control Element Separation (ForCES) framework
+ [RFC3746] consists of one model and two protocols. ForCES separates
+ the forwarding plane from the control plane via an open interface,
+ namely the ForCES protocol [RFC5810], which operates on entities of
+ the forwarding plane that have been modeled using the ForCES model
+ [RFC5812].
+
+ The ForCES model [RFC5812] 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.
+
+ ForCES models the forwarding plane using Logical Functional Blocks
+ (LFBs), which, when connected in a graph, compose the Forwarding
+ Element (FE). LFBs are described in XML, based on an XML schema.
+
+
+
+
+
+Haleplidis, et al. Informational [Page 19]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ LFB definitions include base and custom-defined datatypes; metadata
+ definitions; input and output ports; operational parameters or
+ components; and capabilities and event definitions.
+
+ The ForCES model can be used to define LFBs from fine- to coarse-
+ grained as needed, irrespective of whether they are physical or
+ virtual.
+
+ 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.
+
+ With respect to Figure 1, the ForCES model [RFC5812] is suitable for
+ the DAL, both for the operational and the forwarding plane, using
+ LFBs. The ForCES protocol [RFC5810] has been designed and is
+ suitable for the CPSI, although it could also be utilized for the
+ MPSI.
+
+4.2. NETCONF/YANG
+
+ The Network Configuration Protocol (NETCONF) [RFC6241] is an IETF
+ network management protocol [RFC6632]. NETCONF provides mechanisms
+ to install, manipulate, and delete the configuration of network
+ devices.
+
+ NETCONF protocol operations are realized as remote procedure calls
+ (RPCs). The NETCONF protocol uses XML-based data encoding for the
+ configuration data as well as the protocol messages. Recent studies,
+ such as [ESNet] and [PENet], have shown that NETCONF performs better
+ than SNMP [RFC3411].
+
+ Additionally, the YANG data modeling language [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 the NETCONF protocol, NETCONF remote
+ procedure calls, and NETCONF notifications.
+
+ 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
+ datatypes and allows custom-defined datatypes as well.
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 20]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ YANG allows the definition of NETCONF RPCs, which allows the protocol
+ to have an extensible number of commands. For RPC definitions, the
+ operations names, input parameters, and output parameters are defined
+ using YANG data definition statements.
+
+ With respect to Figure 1, the YANG model [RFC6020] is suitable for
+ specifying DAL for the forwarding and operational planes. NETCONF
+ [RFC6241] is suitable for the MPSI. NETCONF is a management protocol
+ [RFC6632], which was not (originally) designed for fast CP updates,
+ and it might not be suitable for addressing the requirements of CPSI.
+
+4.3. OpenFlow
+
+ OpenFlow is a framework originally developed at Stanford University
+ and currently under active standards development [OpenFlow] through
+ the Open Networking Foundation (ONF). Initially, the goal was to
+ provide a way for researchers to run experimental protocols in a
+ production network [OF08]. OpenFlow has undergone many revisions,
+ and additional revisions are likely. The following description
+ reflects version 1.4 [OpenFlow]. In short, OpenFlow defines a
+ protocol through which a logically centralized controller can control
+ an OpenFlow switch. Each OpenFlow-compliant switch maintains one or
+ more flow tables, which are used to perform packet lookups. Distinct
+ actions are to be taken regarding packet lookup and forwarding. A
+ group table and an OpenFlow channel to external controllers are also
+ part of the switch specification.
+
+ With respect to Figure 1, the OpenFlow switch specifications
+ [OpenFlow] define a DAL for the forwarding plane as well as for CPSI.
+ The OF-CONFIG protocol [OF-CONFIG], based on the YANG model
+ [RFC6020], provides a DAL for the forwarding and operational planes
+ of an OpenFlow switch and specifies NETCONF [RFC6241] as the MPSI.
+ OF-CONFIG overlaps with the OpenFlow DAL, but with NETCONF [RFC6241]
+ as the transport protocol, it shares the limitations described in the
+ previous section.
+
+4.4. Interface to the Routing System
+
+ Interface to the Routing System (I2RS) provides 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, one of the main goals of I2RS, is to make
+ the Routing Information Base (RIB) programmable, thus enabling new
+ kinds of network provisioning and operation.
+
+ I2RS did 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 I2RS problem statement
+
+
+
+Haleplidis, et al. Informational [Page 21]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [I2RSProb] discusses previously defined IETF protocols such as ForCES
+ [RFC5810], NETCONF [RFC6241], and SNMP [RFC3417]. Regarding the
+ definition of informational and data models, the I2RS working group
+ has opted to use the YANG [RFC6020] modeling language.
+
+ Currently the I2RS working group is developing an Information Model
+ [I2RSInfo] in regards to the Network Services Abstraction Layer for
+ the I2RS agent.
+
+ With respect to Figure 1, the I2RS architecture [I2RSArch]
+ encompasses the control and application planes and uses any CPSI and
+ DAL that is available, whether that may be ForCES [RFC5810], OpenFlow
+ [OpenFlow], or another interface. In addition, the I2RS agent is a
+ control-plane service. All services or applications on top of that
+ belong to either the Control, Management, or 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 even provide
+ access to services and applications other than control-plane services
+ and applications.
+
+4.5. SNMP
+
+ The Simple Network Management Protocol (SNMP) is an IETF-standardized
+ management protocol and is currently at its third revision (SNMPv3)
+ [RFC3417] [RFC3412] [RFC3414]. 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.
+
+ 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 (OIDs). 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 [RFC2578].
+
+ An early example of SNMP in the context of SDN is discussed in
+ [Peregrine].
+
+ With respect to Figure 1, SNMP MIBs can be used to describe DAL for
+ the forwarding and operational planes. Similar to YANG, SNMP MIBs
+ are able to describe DAL for the forwarding plane. SNMP, similar to
+ NETCONF, is suited for the MPSI.
+
+
+
+
+
+Haleplidis, et al. Informational [Page 22]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+4.6. PCEP
+
+ The Path Computation Element (PCE) [RFC4655] architecture defines an
+ entity capable of computing paths for a single service or a 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) [RFC5440] is used between a Path
+ Computation Client (PCC) and a PCE, or between multiple PCEs.
+
+ The PCE architecture 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 Network Management System (NMS) nodes and the
+ type of optimization request that may significantly impact the
+ optimization response time from the PCE to the PCC.
+
+ The PCEP messaging mechanism facilitates the specification of
+ computation endpoints (source and destination node addresses),
+ 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.
+
+ With respect to Figure 1, PCE is a control-plane service that
+ provides services for control-plane applications. PCEP may be used
+ as an east-west interface between PCEs that may act as domain control
+ entities (services and applications). The PCE working group is
+ specifying extensions [PCEActive] that allow an active PCE to
+ control, using PCEP, MPLS or GMPLS Label Switched Paths (LSPs), thus
+ making it applicable for the CPSI for MPLS and GMPLS switches.
+
+4.7. BFD
+
+ Bidirectional Forwarding Detection (BFD) [RFC5880] is an IETF-
+ standardized network protocol designed for detecting path failures
+ between two forwarding elements, including physical interfaces,
+ subinterfaces, data link(s), and, to the extent possible, the
+ forwarding engines themselves, with potentially very low latency.
+ BFD can provide low-overhead failure detection on any kind of path
+ between systems, including direct physical links, virtual circuits,
+ tunnels, MPLS LSPs, multihop routed paths, and unidirectional links
+ where there exists a return path as well. It is often implemented in
+ some component of the forwarding engine of a system, in cases where
+ the forwarding and control engines are separated.
+
+
+
+
+
+Haleplidis, et al. Informational [Page 23]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ With respect to Figure 1, a BFD agent can be implemented as a
+ control-plane service or application that would use the CPSI towards
+ the forwarding plane to send/receive BFD packets. However, a BFD
+ agent is usually implemented as an application on the device and uses
+ the forwarding plane to send/receive BFD packets and update the
+ operational-plane resources accordingly. Services and applications
+ of the control and management planes that monitor or have subscribed
+ to changes of resources can learn about these changes through their
+ respective interfaces and take any actions as necessary.
+
+5. Summary
+
+ This document has been developed after a thorough and detailed
+ analysis of related peer-reviewed literature, the RFC series, and
+ documents produced by other relevant standards organizations. It has
+ been reviewed publicly by the wider SDN community, and we hope that
+ it can serve as a handy tool for network researchers, engineers, and
+ practitioners in the years to come.
+
+ We conclude this document with a brief summary of the terminology of
+ the SDN layer architecture. In general, we consider a network
+ element as a composition of resources. Each network element has a
+ forwarding plane (FP) that is responsible for handling packets in the
+ data path and an operational plane (OP) that is responsible for
+ managing the operational state of the device. Resources in the
+ network element are abstracted by the Device and resource Abstraction
+ Layer (DAL) to be controlled and managed by services or applications
+ that belong to the control or management plane. The control plane
+ (CP) is responsible for making decisions on how packets should be
+ forwarded. The management plane (MP) is responsible for monitoring,
+ configuring, and maintaining network devices. Service interfaces are
+ abstracted by the Network Services Abstraction Layer (NSAL), where
+ other network applications or services may use them. The taxonomy
+ introduced in this document defines distinct SDN planes, abstraction
+ layers, and interfaces; it aims to clarify SDN terminology and
+ establish commonly accepted reference definitions across the SDN
+ community, irrespective of specific implementation choices.
+
+6. Security Considerations
+
+ 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; 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 [SDNSecurity], [SDNSecServ], and
+
+
+
+
+
+Haleplidis, et al. Informational [Page 24]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [SDNSecOF]. Security considerations regarding specific interfaces
+ (such as, for example, ForCES, I2RS, SNMP, or NETCONF) are addressed
+ in their respective documents as well as in [RFC7149].
+
+7. Informative References
+
+ [A4D05] Greenberg, A., Hjalmtysson, G., Maltz, D., Myers, A.,
+ Rexford, J., Xie, G., Yan, H., Zhan, J., and H. Zhang,
+ "A Clean Slate 4D Approach to Network Control and
+ Management", ACM SIGCOMM Computer Communication Review,
+ Volume 35, Issue 5, pp. 41-54, 2005.
+
+ [ALIEN] Parniewicz, D., Corin, R., Ogrodowczyk, L., Fard, M.,
+ Matias, J., Gerola, M., Fuentes, V., Toseef, U.,
+ Zaalouk, A., Belter, B., Jacob, E., and K. Pentikousis,
+ "Design and Implementation of an OpenFlow Hardware
+ Abstraction Layer", In Proceedings of the ACM SIGCOMM
+ Workshop on Distributed Cloud Computing (DCC), Chicago,
+ Illinois, USA, pp. 71-76, doi 10.1145/2627566.2627577,
+ August 2014.
+
+ [Beacon] Erickson, D., "The Beacon OpenFlow Controller", In
+ Proceedings of the second ACM SIGCOMM workshop on Hot
+ Topics in Software Defined Networking, pp. 13-18, 2013.
+
+ [CAPBR] Brewer, E., "Towards Robust Distributed Systems", In
+ Proceedings of the Symposium on Principles of
+ Distributed Computing (PODC), 2000.
+
+ [CAPFN] Panda, A., Scott, C., Ghodsi, A., Koponen, T., and S.
+ Shenker, "CAP for Networks", In Proceedings of the
+ second ACM SIGCOMM workshop on Hot Topics in Software
+ Defined Networking, pp. 91-96, 2013.
+
+ [CAPGL] Gilbert, S. and N. Lynch, "Brewer's Conjecture and the
+ Feasibility of Consistent, Available,
+ Partition-Tolerant Web Services", ACM SIGACT News,
+ Volume 33, Issue 2, pp. 51-59, 2002.
+
+ [CORBA] Object Management Group, "CORBA Version 3.3", November
+ 2012, <http://www.omg.org/spec/CORBA/3.3/>.
+
+ [DIOPR] Denazis, S., Miki, K., Vicente, J., and A. Campbell,
+ "Designing Interfaces for Open Programmable Routers",
+ In "Active Networks", Springer Berlin Heidelberg,
+ pp. 13-24, 1999.
+
+
+
+
+
+Haleplidis, et al. Informational [Page 25]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [ESNet] Yu, J. and I. Al Ajarmeh, "An Empirical Study of the
+ NETCONF Protocol", Sixth International Conference on
+ Networking and Services, pp. 253-258, 2010.
+
+ [FCAPS] ITU, "Management Framework For Open Systems
+ Interconnection (OSI) For CCITT Applications", ITU
+ Recommendation X.700, September 1992,
+ <http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
+
+ [I2RSArch] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
+ Nadeau, "An Architecture for the Interface to the
+ Routing System", Work in Progress,
+ draft-ietf-i2rs-architecture-07, December 2014.
+
+ [I2RSInfo] Bahadur, N., Folkes, R., Kini, S., and J. Medved,
+ "Routing Information Base Info Model", Work in
+ Progress, draft-ietf-i2rs-rib-info-model-04, December
+ 2014.
+
+ [I2RSProb] Atlas, A., Nadeau, T., and D. Ward, "Interface to the
+ Routing System Problem Statement", Work in Progress,
+ draft-ietf-i2rs-problem-statement-05, January 2015.
+
+ [ITUATM] ITU, "B-ISDN ATM Layer Specification", ITU
+ Recommendation I.361, 1990,
+ <http://www.itu.int/rec/T-REC-I.361-199902-I/en>.
+
+ [ITUSG11] ITU, "ITU-T Study Group 11: Protocols and test
+ specifications", <http://www.itu.int/en/ITU-T/
+ studygroups/2013-2016/11/Pages/default.aspx>.
+
+ [ITUSG13] ITU, "ITU-T Study Group 13: Future networks including
+ cloud computing, mobile and next-generation networks",
+ <http://www.itu.int/en/ITU-T/studygroups/
+ 2013-2016/13/Pages/default.aspx>.
+
+ [ITUSS7] ITU, "Introduction to CCITT Signalling System No. 7",
+ ITU Recommendation Q.700, 1993,
+ <http://www.itu.int/rec/T-REC-Q.700-199303-I/e>.
+
+ [ITUY3300] ITU, "Framework of software-defined networking", ITU
+ Recommendation Y.3300, June 2014,
+ <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 26]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [KANDOO] Yeganeh, S. and Y. Ganjali, "Kandoo: A Framework for
+ Efficient and Scalable Offloading of Control
+ Applications", In Proceedings of the first ACM SIGCOMM
+ workshop on Hot Topics in Software Defined Networks,
+ pp. 19-24, 2012.
+
+ [NFVArch] ETSI, "Network Functions Virtualisation (NFV):
+ Architectural Framework", ETSI GS NFV 002, October
+ 2013, <http://www.etsi.org/deliver/etsi_gs/
+ nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf>.
+
+ [NOX] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado,
+ M., McKeown, N., and S. Shenker, "NOX: Towards an
+ Operating System for Networks", ACM SIGCOMM Computer
+ Communication Review, Volume 38, Issue 3, pp. 105-110,
+ July 2008.
+
+ [NV09] Chowdhury, N. and R. Boutaba, "Network Virtualization:
+ State of the Art and Research Challenges",
+ Communications Magazine, IEEE, Volume 47, Issue 7,
+ pp. 20-26, 2009.
+
+ [OF-CONFIG] Open Networking Foundation, "OpenFlow Management and
+ Configuration Protocol (OF-Config 1.1.1)", March 2013,
+ <https://www.opennetworking.org/images/stories/
+ downloads/sdn-resources/onf-specifications/
+ openflow-config/of-config-1-1-1.pdf>.
+
+ [OF08] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar,
+ G., Peterson, L., Rexford, J., Shenker, S., and J.
+ Turner, "OpenFlow: Enabling Innovation in Campus
+ Networks", ACM SIGCOMM Computer Communication Review,
+ Volume 38, Issue 2, pp. 69-74, 2008.
+
+ [ONFArch] Open Networking Foundation, "SDN Architecture, Version
+ 1", June 2014,
+ <https://www.opennetworking.org/images/stories/
+ downloads/sdn-resources/technical-reports/
+ TR_SDN_ARCH_1.0_06062014.pdf>.
+
+ [OpenFlow] Open Networking Foundation, "The OpenFlow Switch
+ Specification, Version 1.4.0", October 2013,
+ <https://www.opennetworking.org/images/stories/
+ downloads/sdn-resources/onf-specifications/openflow/
+ openflow-spec-v1.4.0.pdf>.
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 27]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [P1520] Biswas, J., Lazar, A., Huard, J., Lim, K., Mahjoub, S.,
+ Pau, L., Suzuki, M., Torstensson, S., Wang, W., and S.
+ Weinstein, "The IEEE P1520 standards initiative for
+ programmable network interfaces", IEEE Communications
+ Magazine, Volume 36, Issue 10, pp. 64-70, 1998.
+
+ [PCEActive] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
+ Extensions for Stateful PCE", Work in Progress,
+ draft-ietf-pce-stateful-pce-10, October 2014.
+
+ [PENet] Hedstrom, B., Watwe, A., and S. Sakthidharan, "Protocol
+ Efficiencies of NETCONF versus SNMP for Configuration
+ Management Functions", Master's thesis, University of
+ Colorado, 2011.
+
+ [PNSurvey99] Campbell, A., De Meer, H., Kounavis, M., Miki, K.,
+ Vicente, J., and D. Villela, "A Survey of Programmable
+ Networks", ACM SIGCOMM Computer Communication Review,
+ Volume 29, Issue 2, pp. 7-23, September 1992.
+
+ [Peregrine] Chiueh, D., Tu, C., Wang, Y., Wang, P., Li, K., and Y.
+ Huang, "Peregrine: An All-Layer-2 Container Computer
+ Network", In Proceedings of the 2012 IEEE 5th
+ International Conference on Cloud Computing,
+ pp. 686-693, 2012.
+
+ [PiNA] Day, J., "Patterns in Network Architecture: A Return to
+ Fundamentals", Prentice Hall, ISBN 0132252422, 2008.
+
+ [RCP] Caesar, M., Caldwell, D., Feamster, N., Rexford, J.,
+ Shaikh, A., and J. van der Merwe, "Design and
+ Implementation of a Routing Control Platform", In
+ Proceedings of the 2nd conference on Symposium on
+ Networked Systems Design & Implementation Volume 2,
+ pp. 15-28, 2005.
+
+ [REST] Fielding, Roy, "Chapter 5: Representational State
+ Transfer (REST)", in Disseration "Architectural Styles
+ and the Design of Network-based Software
+ Architectures", 2000.
+
+ [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
+ converting network protocol addresses to 48.bit
+ Ethernet address for transmission on Ethernet
+ hardware", STD 37, RFC 826, November 1982,
+ <http://www.rfc-editor.org/info/rfc826>.
+
+
+
+
+
+Haleplidis, et al. Informational [Page 28]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [RFC1953] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching
+ Liaw, F., Lyon, T., and G. Minshall, "Ipsilon Flow
+ Management Protocol Specification for IPv4 Version
+ 1.0", RFC 1953, May 1996,
+ <http://www.rfc-editor.org/info/rfc1953>.
+
+ [RFC2297] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Liaw,
+ F., Lyon, T., and G. Minshall, "Ipsilon's General
+ Switch Management Protocol Specification Version 2.0",
+ RFC 2297, March 1998,
+ <http://www.rfc-editor.org/info/rfc2297>.
+
+ [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Structure of Management
+ Information Version 2 (SMIv2)", STD 58, RFC 2578, April
+ 1999, <http://www.rfc-editor.org/info/rfc2578>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc3411>.
+
+ [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
+ "Message Processing and Dispatching for the Simple
+ Network Management Protocol (SNMP)", STD 62, RFC 3412,
+ December 2002,
+ <http://www.rfc-editor.org/info/rfc3412>.
+
+ [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security
+ Model (USM) for version 3 of the Simple Network
+ Management Protocol (SNMPv3)", STD 62, RFC 3414,
+ December 2002,
+ <http://www.rfc-editor.org/info/rfc3414>.
+
+ [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
+ Management Protocol (SNMP)", STD 62, RFC 3417, December
+ 2002, <http://www.rfc-editor.org/info/rfc3417>.
+
+ [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
+ Simple Network Management Protocol (SNMP)", STD 62, RFC
+ 3418, December 2002,
+ <http://www.rfc-editor.org/info/rfc3418>.
+
+ [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
+ Management Workshop", RFC 3535, May 2003,
+ <http://www.rfc-editor.org/info/rfc3535>.
+
+
+
+
+Haleplidis, et al. Informational [Page 29]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
+ "Forwarding and Control Element Separation (ForCES)
+ Framework", RFC 3746, April 2004,
+ <http://www.rfc-editor.org/info/rfc3746>.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+ Protocol 4 (BGP-4)", RFC 4271, January 2006,
+ <http://www.rfc-editor.org/info/rfc4271>.
+
+ [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture", RFC
+ 4655, August 2006,
+ <http://www.rfc-editor.org/info/rfc4655>.
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March
+ 2009, <http://www.rfc-editor.org/info/rfc5424>.
+
+ [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
+ (PCE) Communication Protocol (PCEP)", RFC 5440, March
+ 2009, <http://www.rfc-editor.org/info/rfc5440>.
+
+ [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
+ Specification Version 2", RFC 5531, May 2009,
+ <http://www.rfc-editor.org/info/rfc5531>.
+
+ [RFC5743] Falk, A., "Definition of an Internet Research Task
+ Force (IRTF) Document Stream", RFC 5743, December 2009,
+ <http://www.rfc-editor.org/info/rfc5743>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc5810>.
+
+ [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
+ Element Separation (ForCES) Forwarding Element Model",
+ RFC 5812, March 2010,
+ <http://www.rfc-editor.org/info/rfc5812>.
+
+ [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding
+ Detection (BFD)", RFC 5880, June 2010,
+ <http://www.rfc-editor.org/info/rfc5880>.
+
+ [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
+ Network Configuration Protocol (NETCONF)", RFC 6020,
+ October 2010, <http://www.rfc-editor.org/info/rfc6020>.
+
+
+
+
+Haleplidis, et al. Informational [Page 30]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
+ Bierman, "Network Configuration Protocol (NETCONF)",
+ RFC 6241, June 2011,
+ <http://www.rfc-editor.org/info/rfc6241>.
+
+ [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF
+ Network Management Standards", RFC 6632, June 2012,
+ <http://www.rfc-editor.org/info/rfc6632>.
+
+ [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification
+ of the IP Flow Information Export (IPFIX) Protocol for
+ the Exchange of Flow Information", STD 77, RFC 7011,
+ September 2013,
+ <http://www.rfc-editor.org/info/rfc7011>.
+
+ [RFC7047] Pfaff, B. and B. Davie, "The Open vSwitch Database
+ Management Protocol", RFC 7047, December 2013,
+ <http://www.rfc-editor.org/info/rfc7047>.
+
+ [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
+ Networking: A Perspective from within a Service
+ Provider Environment", RFC 7149, March 2014,
+ <http://www.rfc-editor.org/info/rfc7149>.
+
+ [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
+ Weingarten, "An Overview of Operations, Administration,
+ and Maintenance (OAM) Tools", RFC 7276, June 2014,
+ <http://www.rfc-editor.org/info/rfc7276>.
+
+ [RINA] Day, J., Matta, I., and K. Mattar, "Networking is IPC:
+ A Guiding Principle to a Better Internet", In
+ Proceedings of the 2008 ACM CoNEXT Conference, Article
+ No. 67, 2008.
+
+ [RouteFlow] Nascimento, M., Rothenberg, C., Salvador, M., Correa,
+ C., de Lucena, S., and M. Magalhaes, "Virtual Routers
+ as a Service: The RouteFlow Approach Leveraging
+ Software-Defined Networks", In Proceedings of the 6th
+ International Conference on Future Internet
+ Technologies, pp. 34-37, 2011.
+
+ [SDNACS] Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C.,
+ Azodolmolky, S., and S. Uhlig, "Software-Defined
+ Networking: A Comprehensive Survey", Networking and
+ Internet Architecture (cs.NI), arXiv:1406.0440, 2014.
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 31]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ [SDNHistory] Feamster, N., Rexford, J., and E. Zegura, "The Road to
+ SDN: An Intellectual History of Programmable Networks",
+ ACM Queue, Volume 11, Issue 12, 2013.
+
+ [SDNNFV] Haleplidis, E., Hadi Salim, J., Denazis, S., and O.
+ Koufopavlou, "Towards a Network Abstraction Model for
+ SDN", Journal of Network and Systems Management:
+ Special Issue on Management of Software Defined
+ Networks, pp. 1-19, 2014.
+
+ [SDNSecOF] Kloti, R., Kotronis, V., and P. Smith, "OpenFlow: A
+ Security Analysis", 21st IEEE International Conference
+ on Network Protocols (ICNP) pp. 1-6, October 2013.
+
+ [SDNSecServ] Scott-Hayward, S., O'Callaghan, G., and S. Sezer, "SDN
+ Security: A Survey", In IEEE SDN for Future Networks
+ and Services (SDN4FNS), pp. 1-7, 2013.
+
+ [SDNSecurity] Kreutz, D., Ramos, F., and P. Verissimo, "Towards
+ Secure and Dependable Software-Defined Networks", In
+ Proceedings of the second ACM SIGCOMM workshop on Hot
+ Topics in Software Defined Networking, pp. 55-60, 2013.
+
+ [SDNSurvey] Nunes, B., Mendonca, M., Nguyen, X., Obraczka, K., and
+ T. Turletti, "A Survey of Software-Defined Networking:
+ Past, Present, and Future of Programmable Networks",
+ IEEE Communications Surveys and Tutorials,
+ DOI:10.1109/SURV.2014.012214.00180, 2014.
+
+ [SLTSDN] Jarraya, Y., Madi, T., and M. Debbabi, "A Survey and a
+ Layered Taxonomy of Software-Defined Networking", IEEE
+ Communications Surveys and Tutorials, Volume 16, Issue
+ 4, pp. 1955-1980, 2014.
+
+ [SoftRouter] Lakshman, T., Nandagopal, T., Ramjee, R., Sabnani, K.,
+ and T. Woo, "The SoftRouter Architecture", In
+ Proceedings of the ACM SIGCOMM Workshop on Hot Topics
+ in Networking, 2004.
+
+ [Tempest] Rooney, S., van der Merwe, J., Crosby, S., and I.
+ Leslie, "The Tempest: A Framework for Safe, Resource
+ Assured, Programmable Networks", Communications
+ Magazine, IEEE, Volume 36, Issue 10, pp. 42-53, 1998.
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 32]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+Acknowledgements
+
+ 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 document-specific comments; they helped
+ put this document in a better shape.
+
+ 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,
+ Dimitri Staessens, Yaakov Stein, Eve Varma, Stuart Venters, Russ
+ White, and Lee Young for their critical comments and discussions at
+ IETF 88, IETF 89, and IETF 90 and on the SDNRG mailing list, which we
+ took into consideration while revising this document.
+
+ We would also like to thank (in alphabetical order) Spencer Dawkins
+ and Eliot Lear for their IRSG reviews, which further refined this
+ document.
+
+ Finally, we thank Nobo Akiya for his review of the section on BFD,
+ Julien Meuric for his review of the section on PCE, and Adrian Farrel
+ and Benoit Claise for their IESG reviews of this document.
+
+ Kostas Pentikousis is supported by [ALIEN], a research project
+ partially funded by the European Community under the Seventh
+ Framework Program (grant agreement no. 317880). The views expressed
+ here are those of the author only. The European Commission is not
+ liable for any use that may be made of the information in this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 33]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+Contributors
+
+ 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:
+
+ o Daniel King for providing text related to PCEP.
+
+ o Scott Mansfield for information regarding current ITU work on SDN.
+
+ o Yaakov Stein for providing text related to the CAP theorem and
+ SDO-related information.
+
+ o Russ White for text suggestions on the definitions of control,
+ management, and application.
+
+Authors' Addresses
+
+ Evangelos Haleplidis (editor)
+ University of Patras
+ Department of Electrical and Computer Engineering
+ Patras 26500
+ Greece
+
+ EMail: ehalep@ece.upatras.gr
+
+
+ Kostas Pentikousis (editor)
+ EICT GmbH
+ Torgauer Strasse 12-15
+ 10829 Berlin
+ Germany
+
+ EMail: k.pentikousis@eict.de
+
+
+ Spyros Denazis
+ University of Patras
+ Department of Electrical and Computer Engineering
+ Patras 26500
+ Greece
+
+ EMail: sdena@upatras.gr
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 34]
+
+RFC 7426 SDN: Layers and Architecture Terminology January 2015
+
+
+ Jamal Hadi Salim
+ Mojatatu Networks
+ Suite 400, 303 Moodie Dr.
+ Ottawa, Ontario K2H 9R4
+ Canada
+
+ EMail: hadi@mojatatu.com
+
+
+ David Meyer
+ Brocade
+
+ EMail: dmm@1-4-5.net
+
+ Odysseas Koufopavlou
+ University of Patras
+ Department of Electrical and Computer Engineering
+ Patras 26500
+ Greece
+
+ EMail: odysseas@ece.upatras.gr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haleplidis, et al. Informational [Page 35]
+