Skip to main content

SDN Layers and Architecture Terminology
draft-haleplidis-sdnrg-layer-terminology-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Evangelos Haleplidis , Spyros Denazis , Kostas Pentikousis , Jamal Hadi Salim , Odysseas Koufopavlou
Last updated 2013-11-04
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-haleplidis-sdnrg-layer-terminology-02
SDNRG                                                      E. Haleplidis
Internet-Draft                                                S. Denazis
Intended status: Informational                      University of Patras
Expires: May 09, 2014                                     K. Pentikousis
                                                                    EICT
                                                           J. Hadi Salim
                                                       Mojatatu Networks
                                                          O. Koufopavlou
                                                    University of Patras
                                                       November 05, 2013

                SDN Layers and Architecture Terminology
              draft-haleplidis-sdnrg-layer-terminology-02

Abstract

   Software-Defined Networking (SDN) is a new approach for network
   programmability.  Network programmability refers to the ability to
   control, change, and manage network behavior dynamically through
   software via open interfaces as opposed to relying on closed boxes
   and propietary defined interfaces.  SDN introduces an abstraction for
   the data forwarding plane and, by doing so, separates it from the
   control plane.  This separation allows faster innovation cycles at
   both planes as experience has already shown.  However, there is
   increasing confusion as to what exactly SDN is, what is the layer
   structure in an SDN architecture and how do layers interface with
   each other.  This document does not aim to standardize any layers or
   interfaces but rather aims to answer these questions and provide a
   concise reference document for SDNRG in particular, and the SDN
   community in general.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 09, 2014.

Haleplidis, et al.        Expires May 09, 2014                  [Page 1]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  SDN Layers and Architecture . . . . . . . . . . . . . . . . .   4
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Network Devices . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Control Plane . . . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Management Plane  . . . . . . . . . . . . . . . . . . . .   8
     2.5.  Service Abstraction Layer . . . . . . . . . . . . . . . .   8
     2.6.  Application Plane . . . . . . . . . . . . . . . . . . . .   9
   3.  SDN Model View  . . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  ForCES  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  NETCONF . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  OpenFlow  . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.4.  I2RS  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Software-Defined Networking (SDN) is a relevant new term for the
   programmable networks paradigm.  In short, SDN refers to the ability
   to use software to program individual network devices dynamically and
   therefore control the behavior of the network as a whole.  A key
   element in SDN is the introduction of an abstraction between the
   (traditional) Forwarding and the Control planes in order to separate
   them and provide applications with the necessary application
   programming interfaces (APIs) to programmatically control the
   network.  The goal is to leverage on this separation, and the

Haleplidis, et al.        Expires May 09, 2014                  [Page 2]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   associated programmability, to enable faster innovation at both
   planes.

   Current and earlier research in SDN 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 corelate well with each other.  For
   example, both OpenFlow [OpenFlow] and NETCONF [RFC6241] have been
   characterized as SDN, but they refer to control and management
   respectively.

   This motivates us to consolidate the defitions of SDN in the
   literature and correlate them with earlier work in IETF and the
   research community.  Of particular interest, for example, is to
   determine which layers comprise the SDN architecture and which
   interfaces are 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 document regarding the SDN
   layers architecture, which would be useful to upcoming work in SDNRG
   as well as future discussions within the SDN community as a whole.

1.1.  Terminology

   This document uses the following terms:

      Software-Defined Networking (SDN) - A programmable networks
      approach that supports the separation of Control and Forwarding
      Planes via standardized interfaces.

      Network Device - A device that performs one or more network
      operations related to packet manipulation and forwarding.  A
      network device can be physical or virtual.

      Forwarding Plane (FP) - The network device part responsible for
      forwarding traffic.

      Operational Plane (OP) - The network device part responsible for
      managing device operation.

      Management Plane (MP) - Network functionality responsible for
      monitoring and maintaining network devices.

      Control Plane (CP) - Part of the network that is assigned to
      control one or more network devices.  CP instructs network devices
      on how to treat and forward packets.

Haleplidis, et al.        Expires May 09, 2014                  [Page 3]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

      Device Abstraction Layer (DAL) - The device's 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.

      Control Abstraction Layer (CAL) - The control plane's abstraction
      layer.  CAL provides access to the control plane southbound
      interface.

      Management Abstraction Layer (MAL) - The management plane's
      abstraction layer.  MAL provides access to the management plane
      southbound interface.

      Interface - A point of interaction between two parts.  In case
      these parts are not in the same physical location, the interface
      is usually implemented as a network protocol.  In case these parts
      are collocated in the same physical location the interface can be
      a protocol or an open/proprietary software inter-process
      communication API.

      Application (App) - A piece of software that utilizes underlying
      services to perform a function.  Application operation can be
      parametrized, typically by passing certain arguments at call time,
      but it is meant to be a standalone piece of software as it does
      not offer any interfaces to other applications or services.

      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 aggregated with
      other services or called in a certain serialized manner to create
      a new service.

2.  SDN Layers and Architecture

   Figure 1 provides a detailed high-level overview of the current SDN
   architecture abstractions.  Note that planes can be collocated with
   other planes or can be physically separated, as we discuss below.

                 o--------------------------------o
                 |                                |
                 | +-------------+   +----------+ |
                 | | Application |   |  Service | |
                 | +-------------+   +----------+ |
                 |       Application Plane        |
                 o---------------Y----------------o
                                 |
   *-----------------------------Y---------------------------------*

Haleplidis, et al.        Expires May 09, 2014                  [Page 4]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   |               Service Abstraction Layer (SAL)                 |
   *------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 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

2.1.  Overview

   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
      datapath.  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.

   o  Operational Plane - Responsible for managing the operational state
      of the Network Device, e.g. active/inactive, number of ports, port

Haleplidis, et al.        Expires May 09, 2014                  [Page 5]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

      status, etc.  The Operational Plane is usually the termination
      point for management plane services and applications.

   o  Control Plane - Responsible for taking decisions on how packets
      should be forwarded by one or more Network Devices and pushing
      such decisions down to the Network Devices to be executed.

   o  Management Plane - Responsible for managing devices, e.g. taking
      decisions on Network Device states.

   o  Application Plane - The plane where applications and services
      reside; applications may be implemented in a modular fashion and
      therefore span multiple planes.

   All planes mentioned above are connected via Interfaces (as indicated
   with "Y" in Figure 1.  The Interface may take multiple roles
   depending on whether connected planes reside on the same (physical or
   virtual) device.  If the respective planes are designed so that they
   do not have to reside in the same device, then the Interface can only
   take the form of a protocol.  If the planes are co-located on the
   same device, then the Interface could either be an open/proprietary
   protocol, an open/proprietary software inter-process communication
   API, or 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.

   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.

   This document considers four abstraction layers:

      The Device Abstraction Layer (DAL) abstracts the device forwarding
      and operational plane to the control and management plane,
      respectively.  Variations of DAL may abstract both planes or
      either of the two.

      The Control Abstraction Layer (CAL) abstracts the CP southbound
      interface and the DAL from the applications and services of the
      Control Plane.

      The Management Abstraction Layer (MAL) abstracts the MP southbound
      interface and the DAL from the applications and services of the
      Management Plane.

Haleplidis, et al.        Expires May 09, 2014                  [Page 6]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

      The Service Abstraction Layer (SAL) provides service abstractions
      for use by applications and other services.

2.2.  Network Devices

   A Network Device is any device on a network that performs a function
   over a packet that it receives via its input port.  The network
   device could, for example, forward the packet, drop the packet,
   change and forward the packet, etc.  NDs can be implemented in
   hardware or software and can be either a physical or virtual network
   element.  Each network network device has both a Forwarding Plane and
   an Operational Plane.  The Forwarding Plane, commonly referred to as
   the "data path", is responsible for handling and forwarding packets.
   The Operational Plane is responsible for operational state of the ND,
   for example, with respect to status of network ports and interfaces.

   The Forwarding and the Operational Planes can be exposed via a Device
   Abstraction Layer (DAL), which may be comprised of one or more
   abstraction models.  Examples of Forwarding Plane abstraction models
   are the ForCES model [RFC5812] and the OpenFlow switch model
   [OpenFlow].  Examples of the Operational Plane abstraction model
   include the ForCES model [RFC5812], the YANG model [RFC6020] and SNMP
   MIBs [RFC3418].

   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.

   Note that applications can also reside in a network device.  Examples
   of such applications include event monitoring, and handling
   (offloading) topology discovery or ARP in the device itself instead
   of forwarding such traffic to the control plane.

2.3.  Control Plane

   The Control Plane communicates with the Forwarding Plane of devices
   using a Control Plane Southbound Interface (CPSI) with DAL as a point
   of reference.  The Control Plane is responsible for instructing the
   Forwarding Plane about how to handle network packets.

   Normally the CPSI is a time-critical interface and requires low
   latency and sometimes high bandwidth in order to perform many
   operations in short order.  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 interprocess
   communication.  If the Control Plane and the Network Device are not

Haleplidis, et al.        Expires May 09, 2014                  [Page 7]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   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 CPSIs.

   Control applications can use CAL to control a network device without
   providing any service to upper layers.  Examples include applications
   that perform control functions, such as OSPF, BGP, etc.

   Control Plane Services provide access to other Services or
   Applications above the control plane.  Examples include a virtual
   private LAN service, service tunnels, etc.

2.4.  Management Plane

   The Management Plane communicates with the network device Operational
   Plane using a Management Plane Southbound Interface (MPSI) with DAL
   as a point of reference.

   Normally MSPI, in contrast to the CPSI, is not a time-critical
   interface and does not share the CPSI's requirements.  The management
   plane is typically closer to human interaction than the control plane
   and therefore the MSPI is usually based more on usability than
   performance.  Messages tend to be less frequent than in the CPSI.

   The MPSI can range from a protocol, to an API or even interprocess
   communication.  If the Management Plane is not embedded in the
   network device, the MSPI is certainly a protocol.  Examples of MPSIs
   are ForCES [RFC5810], NETCONF [RFC6241], OVSDB
   [I-D.pfaff-ovsdb-proto] and SNMP [RFC3411].

   The Management Abstraction Layer (MAL) provides access to management
   applications and services to various MPSIs.  The Management Plane may
   support more than one MPSI.

   Management Applications can use MAL to manage the network device
   without providing any service to upper layers.  Examples of
   management applications include network monitoring applications.

   Management Plane Services provide access to other services or
   applications above the Management Plane.

2.5.  Service Abstraction Layer

Haleplidis, et al.        Expires May 09, 2014                  [Page 8]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   The Service Abstraction Layer (SAL) provides access from services of
   the control, management and application planes to services and
   applications of the application plane.

   Service Interfaces can take many forms pertaining to their specific
   requirements.  Examples of service interfaces include but are not
   limited to, RESTful APIs, open or proprietary protocols such as
   NETCONF, inter-process communications, CORBA interfaces, etc.

2.6.  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.

3.  SDN Model View

   We advocate that the SDN southbound interface should encompass both
   CSPI and MSPI.

   The SDN northbound interface is implemented in the Service
   Abstraction Layer.

   The above model can be used to describe in a concise manner all
   prominent SDN-enabling technologies, as we explain in the following
   subsections.

3.1.  ForCES

   The Forwarding and Control Element Separation (ForCES [RFC5810]) is
   an IETF framework consisting of a model and two protocols.  ForCES
   separates the Forwarding from the Control Plane via an open
   interface, namely the ForCES protocol which operates on entities of
   the forwarding plane that have been modeled using the ForCES model.

   The ForCES model is based on the fact that a network element is
   composed of numerous logically separate entities that cooperate to
   provide a given functionality -such as routing or IP switching- and
   yet appear as a normal integrated network element to external
   entities and secondly with a protocol to transport information.

Haleplidis, et al.        Expires May 09, 2014                  [Page 9]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   ForCES models the Forwarding Plane using Logical Functional Blocks
   (LFBs) which are connected in a graph, consisting the Forwarding
   Element (FE).  LFBs are described in an XML language, based on an XML
   schema.

   LFB definitions include:

   o  Base and custom-defined datatypes

   o  Metadata definitions

   o  Input and Output ports

   o  Operational parameters, or components

   o  Capabilities

   o  Event definitions

   The ForCES model can be used to define LFBs from fine- to coarse-
   grained as needed.

   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. ForCES is a
   protocol designed for high throughput and fast updates.

   ForCES [RFC5810] can be mapped to the framework illustrated in Figure
   1 as follows:

   o  The ForCES model can be used to describe the DAL, both for the
      Operational and the Forwarding Plane, using LFBs.

   o  The ForCES protocol can then be both the CPSI and the MPSI.
      ForCES is inherently specified for the CPSI and satisfies its
      requirements, however it can also be utilized for the MPSI.

   o  CAL and MAL must be able to utilize the ForCES protocol.

3.2.  NETCONF

   The Network Configuration Protocol (NETCONF [RFC6241]), is an IETF-
   standardized network management protocol.  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 an Extensible Markup Language

Haleplidis, et al.        Expires May 09, 2014                 [Page 10]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   (XML) based data encoding for the configuration data as well as the
   protocol messages.

   Additonally, the YANG data modeling language has been developed for
   specifying NETCONF data models and protocol operations.  YANG is a
   data modeling language used to model configuration and state data
   manipulated by NETCONF, NETCONF remote procedure calls, and NETCONF
   notifications.

   YANG models the hierarchical organization of data as a tree, in which
   each node has either a value or a set of child nodes.  Additionally,
   YANG structures data models into modules and submodules allowing
   reusability and augmentation.  YANG models can describe constraints
   to be enforced on the data.  Additionally YANG has a set of base
   datatype and allows custom defined datatypes as well.

   YANG allows the definition of NETCONF RPCs allowing the protocol to
   have an extensible number of commands.  For RPC definition, the
   operations names, input parameters, and output parameters are defined
   using YANG data definition statements.

   NETCONF can be mapped to the framework illustrated in Figure 1 as
   follows:

   o  The YANG model [RFC6020] is suitable for specifying DAL for the
      operational plane and NETCONF [RFC6241] for the MPSI.

   o  Technically, the YANG model [RFC6020] can be used to specify DAL
      for the Forwarding plane as well, but NETCONF [RFC6241] being a
      protocol not designed for fast updates is likely not suitable for
      the requirements of CPSI.

3.3.  OpenFlow

   OpenFlow is a framework developed by Standford, currently run by the
   Open Networking Foundation, initially to provide a way for
   researchers to run experimental protocols in the network.  OpenFlow
   provides a protocol with which a controller may manage a static model
   of an OpenFlow switch.

   An OpenFlow Switch consists of one or more flow tables which perform
   packet lookups and forwarding, a group table and an OpenFlow channel
   to an external controller.  The switch communicates with the
   controller which manages the switch via the OpenFlow protocol.

   OpenFlow can be mapped to the framework illustrated in Figure 1 as
   follows:

Haleplidis, et al.        Expires May 09, 2014                 [Page 11]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   o  The Openflow switch specifications [OpenFlow] covers DAL for the
      Forwarding Plane and provides the specification for CPSI.

   o  The OF-CONFIG protocol [OF-CONFIG] based on the YANG model
      [RFC6020], provides DAL for the Operational Plane 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.

   o  CAL must be able to utilize the OpenFlow protocol.

   o  MAL must be able to utilize the NETCONF protocol.

3.4.  I2RS

   I2RS, although still work in progress at the IETF, can be mapped to
   the framework illustrated in Figure 1 as follows:

   o  The I2RS architecture [I-D.liu-i2rs-architecture] is concerned
      with the Control and Application Planes and uses whatever CPSI and
      DAL are available, whether that is ForCES, OpenFlow or another
      Interface.

   o  The I2RS agent is a Control Plane Service.  All services or
      applications on top of that belong to either the Control or the
      Application plane.

   o  Currently the I2RS working group if developing an Information
      Model [I-D.nitinb-i2rs-rib-info-model] in regards to the Service
      Abstraction Layer for the I2RS agent.

4.  Acknowledgements

   The authors would like to acknowledge David Meyer, Salvatore Loreto
   and Sudhir Modali for their discussion and comments that helped put
   this document in a better shape.

5.  IANA Considerations

   This memo makes no requests to IANA.

6.  Security Considerations

   TBD

7.  Informative References

   [I-D.liu-i2rs-architecture]

Haleplidis, et al.        Expires May 09, 2014                 [Page 12]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

              Liu, D., Khasnabish, B., and H. Deng, "Architecture
              Discussion of I2RS", draft-liu-i2rs-architecture-02 (work
              in progress), July 2013.

   [I-D.nitinb-i2rs-rib-info-model]
              Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
              Information Base Info Model", draft-nitinb-i2rs-rib-info-
              model-02 (work in progress), August 2013.

   [I-D.pfaff-ovsdb-proto]
              Pfaff, B. and B. Davie, "The Open vSwitch Database
              Management Protocol", draft-pfaff-ovsdb-proto-03 (work in
              progress), September 2013.

   [OF-CONFIG]
              Open Networking Foundation, "OpenFlow Management and
              Configuration Protocol 1.1", , <https://
              www.opennetworking.org/images/stories/downloads/sdn-
              resources/onf-specifications/openflow-config/of-
              config-1.1.pdf>.

   [OpenFlow]
              Open Networking Foundation, "The OpenFlow 1.3
              Specification.", , <https://www.opennetworking.org/images/
              stories/downloads/sdn-resources/onf-specifications/
              openflow/openflow-spec-v1.3.1.pdf>.

   [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.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62, RFC
              3418, December 2002.

   [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.

   [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
              Element Separation (ForCES) Forwarding Element Model", RFC
              5812, March 2010.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

Haleplidis, et al.        Expires May 09, 2014                 [Page 13]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

Authors' Addresses

   Evangelos Haleplidis
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500
   Greece

   Email: ehalep@ece.upatras.gr

   Spyros Denazis
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500
   Greece

   Email: sdena@upatras.gr

   Kostas Pentikousis
   EICT GmbH
   Torgauer Strasse 12-15
   10829 Berlin
   Germany

   Email: k.pentikousis@eict.de

   Jamal Hadi Salim
   Mojatatu Networks
   Suite 400, 303 Moodie Dr.
   Ottawa, Ontario  K2H 9R4
   Canada

   Email: hadi@mojatatu.com

Haleplidis, et al.        Expires May 09, 2014                 [Page 14]
Internet-Draft   SDN Layers and Architecture Terminology   November 2013

   Odysseas Koufopavlou
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500
   Greece

   Email: odysseas@ece.upatras.gr

Haleplidis, et al.        Expires May 09, 2014                 [Page 15]