tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7426

Informational
Pages: 35
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Software-Defined Networking (SDN): Layers and Architecture Terminology

Part 1 of 2, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
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

Top      ToC       Page 5 
   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).

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
                   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

Top      ToC       Page 9 
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

Top      ToC       Page 10 
      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

Top      ToC       Page 11 
   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.

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
   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

Top      ToC       Page 14 
   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

Top      ToC       Page 15 
   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.

Top      ToC       Page 16 
   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.

Top      ToC       Page 17 
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

Top      ToC       Page 18 
   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.

Top      ToC       Page 19 
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.



(page 19 continued on part 2)

Next RFC Part