GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7426

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7426.txt · Last modified: 2015/01/07 22:42 (external edit)