[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

SDNRG                                                      E. Haleplidis
Internet-Draft                                                S. Denazis
Intended status: Informational                            O. Koufopavlou
Expires: January 16, 2014                           University of Patras
                                                          K. Pentikousis
                                                     Huawei Technologies
                                                           J. Hadi Salim
                                                       Mojatatu Networks
                                                           July 15, 2013


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

Abstract

   Software-Defined Networking introduces an abstraction layer and by
   doing so separates the Forwarding from the Control layer.  This
   separation can allow faster innovation cycles at both layers as
   experience has already shown.  However, there is increasing confusion
   as to what exactly SDN is, what is the layer stucture in an SDN
   architecture and how do layers interface with each other.  This
   document aims to provide a concise reference for future discussions
   in SDNRG.

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 January 16, 2014.

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



Haleplidis, et al.      Expires January 16, 2014                [Page 1]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  SDN Layers and Architecture  . . . . . . . . . . . . . . . . .  5
     2.1.  Network Devices  . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Control Plane  . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Management Plane . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Service Abstraction Layer  . . . . . . . . . . . . . . . .  7
     2.5.  Application Plane  . . . . . . . . . . . . . . . . . . . .  7
   3.  SDN Model View . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  ForCES . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Openflow . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  NETCONF  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13





















Haleplidis, et al.      Expires January 16, 2014                [Page 2]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


1.  Introduction

   Software-Defined Networking introduces an abstraction layer between
   the Forwarding and the Control layer in order to separate them.  This
   separation allows faster innovation for both layers as experience has
   already shown.  However, there is increasing confusion as to what
   exactly SDN is, what layers comprise the SDN architecture and what
   are the interfaces.  This draft attempts to provide a concise
   reference document for future discussions on SDN.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   This document introduces the following terms:

      Software-Defined Networking (SDN) - A framework 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 funtionality 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
      how to treat and forward packets.

      Application (App) - A piece of software that utilizes underlying
      services to perform a function.

      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 provide said functions.  Services
      can be aggregated with other services to create a new service.



Haleplidis, et al.      Expires January 16, 2014                [Page 3]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


      Interface (Int) - A point of interaction between two parts.  In
      case these parts are not in the same physical location, the
      interface is usually implemented as 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.

      Device Abstraction Layer (DAL) - The device's abstraction layer
      based on one or more models.  If it is a physical device it may be
      refered 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.
































Haleplidis, et al.      Expires January 16, 2014                [Page 4]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


2.  SDN Layers and Architecture

   Figure 1 provides a detailed abstraction overview of the current SDN
   architecture.  Planes can be collocated with other planes or can be
   physically separated, as we discuss below.

                 +--------------------------------+
                 |                                |
                 | +-------------+   +----------+ |
                 | | Application |   |  Service | |
                 | +-------------+   +----------+ |
                 |       Application Plane        |
                 +---------------Y----------------+
                                 |
   +-----------------------------Y---------------------------------+
   |               Service Abstraction Layer (SAL)                 |
   +------Y------------------------------------------------Y-------+
          |                                                |
          |               Service Interface                |
          |                                                |
   +------Y------------------+       +---------------------Y------+
   |      |    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-------------+ |
   |            |            |       |            |               |
   +------------|------------+       +------------|---------------+
                |                                 |
                | Control Plane                   | Management Plane
                | Southbound Interface            | Southbound Interface
                |                                 |
   +------------Y---------------------------------Y----------------+
   |               Device Abstraction Layer (DAL)                  |
   +------------Y---------------------------------Y----------------+
   |            |                                 |                |
   |    +-------Y----------+   +-----+  +---------Y---------+      |
   |    | Forwarding Plane |   | App |  | Operational Plane |      |
   |    +------------------+   +-----+  +-------------------+      |
   |                       Network Device                          |
   +---------------------------------------------------------------+

                     Figure 1: SDN Layer Architecture




Haleplidis, et al.      Expires January 16, 2014                [Page 5]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


2.1.  Network Devices

   A Network Device, implemented in hardware or in software, physical or
   virtual, 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 of packets.  The Operational
   Plane represents the operational state of the device, for example,
   with respect to network ports and interfaces.

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

   Applications can also reside in the network device.  Examples of such
   applications are event monitoring, and offloading topology discovery
   or ARP in the device itself instead of forwarding such traffic to the
   control plane.

2.2.  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 and is responsible for instructing the Forwarding Plane
   on how to handle network packets.  CPSI can be implemented using a
   protocol, an API or even interprocess communication.  If the Control
   Plane and the Network Device are not collocated, then this interface
   is certainly a protocol.  Examples of CPSIs are ForCES [RFC5810] and
   the Openflow protocol [OpenFlow1.3.1].

   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
   Application above the control plane.  Examples include a virtual
   private LAN service, service tunnels, etc.







Haleplidis, et al.      Expires January 16, 2014                [Page 6]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


2.3.  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.  This interface can range from a protocol,
   to an API or even interprocess communication.  If the Management
   Plane is not embedded in the network device, this interface 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
   application above the Management Plane.

2.4.  Service Abstraction Layer

   The Service Abstraction Layer (SAL) provides access from services of
   the control, management and applciation plane to services and
   applications of the application plane.  Examples of service
   interfaces are REST APIs.

2.5.  Application Plane

   Applications and services that use services from the control and/or
   management plane form the Application Plane.

   Addditionally, 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.












Haleplidis, et al.      Expires January 16, 2014                [Page 7]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


3.  SDN Model View

   We advocate that the SDN southbound interface should encompass both
   the CSPI and the 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

   ForCES can be mapped on the above framework as follows:

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

   o  The ForCES protocol can then be the CPSI and the MPSI.

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

3.2.  Openflow

   Openflow can be mapped on the above framework as follows:

   o  The Openflow switch specifications [OpenFlow1.3.1] covers DAL for
      the Forwarding Plane and provides the specifications for CAL and
      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.

   o  CAL must be able to utilize the Openflow protocol.

   o  MAL must be able to utilize the NETCONF protocol.

3.3.  NETCONF

   NETCONF can be mapped on the above framework as follows:

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






Haleplidis, et al.      Expires January 16, 2014                [Page 8]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


4.  Acknowledgements

   TBD
















































Haleplidis, et al.      Expires January 16, 2014                [Page 9]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


5.  IANA Considerations

   This memo makes no requests to IANA.
















































Haleplidis, et al.      Expires January 16, 2014               [Page 10]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


6.  Security Considerations

   TBD
















































Haleplidis, et al.      Expires January 16, 2014               [Page 11]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


7.  Informative References

   [I-D.pfaff-ovsdb-proto]
              Pfaff, B. and B. Davie, "The Open vSwitch Database
              Management Protocol", draft-pfaff-ovsdb-proto-02 (work in
              progress), March 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>.

   [OpenFlow1.3.1]
              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>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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



Haleplidis, et al.      Expires January 16, 2014               [Page 12]


Internet-Draft   SDN Layers and Architecture Terminology       July 2013


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


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

   Email: odysseas@ece.upatras.gr


   Kostas Pentikousis
   Huawei Technologies
   Carnotstrasse 4
   10587 Berlin
   Germany

   Email: k.pentikousis@huawei.com


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

   Email: hadi@mojatatu.com






Haleplidis, et al.      Expires January 16, 2014               [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/