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

Versions: 00 01

Network Working Group                                     T. Nadeau, Ed.
Internet-Draft                                     CA Technologies, Inc.
Intended status: Informational
Expires: April 3, 2012                                       P. Pan, Ed.
                                                          Infinera, Inc.
                                                         October 3, 2011


                   Framework for Software Defined Networks
                     draft-nadeau-sdn-framework-00

Abstract

   This document presents a framework for Software Defined Networks
   (SDN).  The purpose of the framework is to provide
   an overall picture of the problem space of SDN and to describe the
   relationships among the various components necessary to manipulate
   the components that comprise SDNs.  SDN requires the specification
   of several key components including an "orchestrator" and various
   "plug-ins" between the orchestrator function and network resources.
   In addition to this, an orchestrator will require interconnection
   with standard policy bases, as well as other orchestrators in
   distributed environments or insofar as to support high-availability
   and fault-tolerance capabilities. To this end, several interfaces
   and mechanisms to address issues such as enabling the orchestrator
   to manipulate and interact with the control planes of devices such
   as routers and switches, as well as a discourse between different
   orchestrators will be described.  The intent of this document is
   to outline what each interface needs to accomplish, and to describe
   how these interfaces and mechanisms fit together, while leaving
   their detailed specification to other documents.

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 RFC 2119 [RFC2119].

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



Nadeau & Pan              Expires April 3, 2012              [Page 1]


                     SDN Framework                    October 3, 2011




   This Internet-Draft will expire on April 30, 2012.

Copyright Notice

   Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Reference Model  . . . . . . . . . . . . . . . . . . . . .  4
   2.  Building Blocks  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1. SDN Orchestrator  . . . . . . . . . . . . . . . . . . . . .  6
     2.1. SDN Plug-In   . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview of SDN Operation  . . . . . . . . . . . . . . . . . .  7
   4.  Main Interfaces  . . . . . . . . . . . . . . . . . . . . . . . 32
     4.1.  SDN Orchestrator to Application Interface. . . . . . . . . 32
     4.2.  SDN Orchestrator Policy Base Interface . . . . . . . . . . 33
     4.3.  SDN Orchestrator to Plug-In Interface. . . . . . . . . . . 34
     4.4.  SDN Orchestrator to Orchestrator Interface . . . . . . . . 36
     4.5.  SDN Orchestrator Logging interface . . . . . . . . . . . . 36
     4.6   SDN Control Interface  . . . . . . . . . . . . . . . . . . 36
   5.  Deployment Models  . . . . . . . . . . . . . . . . . . . . . . 37
   6.  Trust Model  . . . . . . . . . . . . . . . . . . . . . . . . . 43
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 44
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 44
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 46
     11.2. Informative References . . . . . . . . . . . . . . . . . . 46
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47

1.  Introduction




Nadeau & Pan              Expires April 3, 2012              [Page 2]


                     SDN Framework                    October 3, 2011



   The Software Driven Network (SDN) is motivated by several use cases,
   such as those described in <insert use case draft reference here>.
   The overall problem space for SDN is described in
   [I-D.nadeau-sdn-problem-statement] with requirements for
   solutions found in [I-D.pan-sdn-requirements]. The purpose of this
   document is to provide an overview of the various components
   necessary to create SDNs.  SDNs require the specification of
   several interfaces and mechanisms to address issues such as an
   orchestration point (logical or physical) and interfaces between
   itself, applications that wish to consume or manipulate network
   resorces, network resources such as router control planes, and
   policy and security engines. Furthermore, high availability and
   resilliency mechanisms also need to be defined. The intent of
   this document is to describe how these interfaces and mechanisms
   fit together, leaving their detailed specification to other
   documents.

1.1.  Terminology

   This document draws freely on the terminology defined in
   [I-D.nadeau-sdn-problem-statement].

   We also introduce the following terms:

   SDN Orchestrator: The entity which is the controller of
   control planes.

   Policy Engine or Database: The repository of policy information
   stored within a network domain.

   Location Services: A network service used for locating
   network elements. Examples include ALTO and The Domain
   Name System (DNS).

   SDN Domain: a host name (FQDN) at the beginning of a URL,
   representing a set of content that is served by a given CDN.  For
   example, in the URL

   http://sdn.example.(com|org|net)/...rest of url...

   the SDN domain is sdn.example.(com|org|net).

   Application Programming Interface (API): is a particular set
   of rules and specifications that software programs can follow
   to communicate with each other. It serves as an interface between
   different software programs and facilitates their interaction,
   similar to the way the user interface facilitates interaction
   between humans and computers.



Nadeau & Pan              Expires April 3, 2012              [Page 3]


                     SDN Framework                    October 3, 2011




   SDN Plug-In: An API that abstracts a device and its object
   model that an SDN Orchestrator can use to communicate with
   that device.

1.2.  Reference Model

   Figure 1 (reproduced from [I-D.nadeau-sdn-problem-statement])
   illustrates the basic model of operation with which this document is
   concerned.

     |--------Application
     v             ^
+----------+       |
| Location |       |  <--- Application-to-
| Services |       |       Ochestrator protocol
+----------+       v
     ^          ReST API
     |    +-------------------+        +------------------+
     |----| Orchestrator_0..N + -----> | Policy Data Base |
          +-------------------+        +------------------+
                   ^
                   |   <--- Orchestrator-to-Plug-In Protocol
                   |
                   V
              +----------+
              | Plug-In  |
              | ReST API |
              +----------+
                   ^
                   *
                   V
          +******************+
          * Control Software *
          * For Device_0..M  *
          +******************+
                   ^
                   =
                   V
          +=================+
          =   Data Plane    =
          = For Device_0..M =
          +=================+

  <-->  interfaces and objects inside the scope of SDN
  +--+

  <**>  interfaces and objects may be within the scope of SDN



Nadeau & Pan              Expires April 3, 2012              [Page 4]


                     SDN Framework                    October 3, 2011



  +**+  insofar as modifcations are needed to support SDN


           Figure 1: Model of Operation for SDN

   Note that while some interfaces are considered out of scope for
   SDN, and these are noted above. The overview of operation
   described below will show how those interfaces are used as part of
   an overall solution and where new protocols will be defined as well.


2.  Building Blocks

2.1.  SDN Orchesetrator

        The controler of control planes, known as the SDN Orchestrator,
must be capable of requesting object models from each of the
controlling software it is responsible for managing, and therefore
each controlling software element must be capable of producing a
self-describing object model with which the Orchestrator can use when
issuing instructions to manipulate it. Furthermore, communications
between the Orchestrator and the control planes must also be
rationalized. To this end, the working group will define SDN
"plug-ins" which are the abstracted interface to each type of control
plane. The working group will also define a protocol that is used for
communcations bewteen the Orchestrator and the plug-in.

        It should be noted that the SDN Orchestrator function is
conceptually centralized in that applications SHOULD have a
centralized means of locating the Orchestrator within its network.
However, in reality the Orchstrator will be designed and architected
so as to exist in a distributed manner if so desired operationally.
Furthermore, resilliency of a SDN infrastructure and network of
components is required as these elements and functional controls are
to be used in highly available production environments; therefore,
the working group will define mechanisms by which the SDN Orchestrator
will operate in this manner as a minimum requirement.

2.2.  SDN Plug-In

      (TBD)

3.  Overview of SDN Operation

   To provide a big-picture overview of the various components of SDN,
   let us walk through how a typical SDN Orchestrator would be deployed
   within a network, and then how applications would use it to interact
   with network resources.



Nadeau & Pan              Expires April 3, 2012              [Page 5]


                     SDN Framework                    October 3, 2011




   Include 1 use case here... (TBD)


4. Main Interfaces

   This section describes the main interfaces between different
components of SDN.

4.1 SDN Orchestrator to Application Interface

      This interface allows the SDN Orchestrator or "controller"
      system to be interconnected with applications. This interface is
      sometimes referred to as a "north-bound" interface, because it
      points "northward" in architectural diagrams. This interface
      allow bootstrapping of the interface between the Orchestrator
      and interested applications. It will allow the applications to
      authenticate using one or more methods. This interface will
      allow applications to learn of which objects they have
      authorization to manipulate, or to interact with objects
      beloning to controlling software.

4.2 SDN Orchestrator Policy Base Interface

      This interface allows the SDN Orchestrator to interconnect with
      policy, authentication and authorization databases.

4.3 SDN Orchestrator to Plug-In Interface

      This interface allows the SDN Orchestrator to interconnect with
the controlling software of devices.

4.4 SDN Orchestrator to Orchestrator Interface

      This interface allows the SDN Orchestrator to interconnect
      and interact with other SDN Orchestrators that exist
      within its SDN Domain.

4.5 SDN Orchestrator Logging interface

      This interface allows the Logging system in interconnected SDN
      Orchestrators to communicate the relevant activity logs in
      order to allow log consuming applications to operate in
      multi-SDN Orchestrator environments. For example, this
      interface can be used to collect logs from SDN Orchestrators
      to provide reporting and monitoring to the M/CSP of SDN
      activities.




Nadeau & Pan              Expires April 3, 2012              [Page 6]


                     SDN Framework                    October 3, 2011



      SDN Orchestrator logs are easily exchanged off-line as a flat text
      file, for example, and could include the following information.

      o  SDN Domain - the full domain name of the origin server

      o  IP address - the IPv4 (and IPv6 if available) address of the
         client application or SDN Orchestrator making the request

      o  Transaction Time - the ending time of the transfer

      o  Time zone - any time zone modifier for the end time


4.6 SDN Control Interface

   The protocol used between the Orchestrator and another entity
   such as an application, Policy Database, Location Services or
   Plug-In, or another Orchestrator in order to send commands,
   receive replies or emit notifications is the role of the
   SDN Control Interface.

   As noted above and in [I-D.nadeau-sdn-problem-statement], the
   control interface may also be used for the bootstrapping of other
   interfaces such as the SDN Orchestrator to SDN Orchestrator
   interface.


5.  Deployment Models

    Describe deployment models here. This should include a single
    domain of Orchestrators and applications, and other components.
    (TBD)

6.  Trust Model

   There are a number of trust issues that need to be addressed by a
   SDN solution.  In a standard SDN environment with a single
   Orchestrator, one policy database, one location services
   engine (i.e.: DNS/ALTO) and one router associated with the
   Orchestrator, there are a number of points of trust to consider.
   First, any of the interfaces bewteen the SDN elements expose
   trust points. Further, since the SDN Orchestrator-to-Orchestrator
   allows for an Orchestrator to bootstrap itself from another's
   active configuration, the operator must ensure that authorization
   is configured correctly.

   We expect that the detailed designs for the specific interfaces for
   SDN will need to take these trust issues into account.



Nadeau & Pan              Expires April 3, 2012              [Page 7]


                     SDN Framework                    October 3, 2011





7.  IANA Considerations

   This memo includes no request to IANA.


8.  Security Considerations

   (Note: this section to be extended in future revision.)


9.  Contributors

   The following individuals contributed to this document:

   o


10.  Acknowledgements

   We thank ... for helpful comments on the draft.


11.  References

11.1.  Normative References

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

11.2.  Informative References

   [I-D.nadeau-sdn-problem-statement]
              Nadeau, T., and P. Pan, "
              Software Defined Network (SDN) Problem
              Statement", draft-nadeau-sdn-problem-statement-00 (work
              in progress), September 2011.

   [I-D.pan-sdn-requirements]
              Pan, P., and T. Nadeau,
              "Software Defined Networks (SDN) Requirements",
              draft-pan-sdn-requirements-00 (work
              in progress), September 2011.

Authors' Addresses





Nadeau & Pan              Expires April 3, 2012              [Page 8]


                     SDN Framework                    October 3, 2011




   Thomas D. Nadeau
   CA Technologies, Inc.
   273 Corporate Drive
   Portsmouth, NH 03801

   Email: thomas.nadeau@ca.com


   Ping Pan
   Infinera Corporation
   169 Java Drive
   Sunnyvale, CA 94089
   Phone: (408) 572-5200

   Email: ping@pingpan.org



































Nadeau & Pan              Expires April 3, 2012              [Page 9]


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