[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                       D.Stiliadis
Internet Draft                                                  F.Balus
Intended status: Information                              W. Henderickx
Expires: April 2012                                      Alcatel-Lucent

                                                               N. Bitar

                                                          Mircea Pisica

                                                     October 31, 2011

             Software Driven Networks: Use Cases and Framework


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

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

Copyright Notice

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

Stiliadis et.al.        Expires April 31, 2012                 [Page 1]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   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.


This document presents an application framework and associated use
cases to help define the scope of the SDNP working group. The use cases
start with an abstract representation of a multi-tier application and
illustrate the composition of a network service that can meet the
requirements of the particular application. The service composition
process is split into several steps, including application requirement
specification, network mapping, service binding, and policy control. We
also provide examples of interactions between an SDNP controller and L2
and L3 control layer protocols in order to deliver the end-to-end
service. Finally, as a derivate of that, an architecture framework for
SDNP that meets these requirements is proposed.

Table of Contents

   1. Introduction...................................................3
   2. General Terminology............................................4
   3. Framework......................................................4
      3.1. Application Definition....................................5
      3.2. Network Mapping...........................................7
      3.3. Network Service Binding...................................8
      3.4. Policy Definition.........................................9
   4. Examples of Service Binding...................................10
      4.1. Example: An end-to-end data center service...............10
         4.1.1. LAN Configuration...................................11
         4.1.2. IPVPN Configuration.................................12
      4.2. Configuration Alternatives...............................12
         4.2.1. Network Element based Configuration.................12
         4.2.2. Network Management based Configuration..............13
   5. SDN Model and Reference Architecture..........................13
      5.1. Scope and Approach.......................................15
   6. Security Considerations.......................................15
   7. IANA Considerations...........................................15
   8. Conclusions...................................................16
   9. References....................................................16
      9.1. Normative References.....................................16
      9.2. Informative References...................................16
   10. Acknowledgments..............................................16

Stiliadis et.al.        Expires April 31, 2012                 [Page 2]

Internet-Draft   Software Defined Networks Use Cases       October 2011

1. Introduction

   In order to define the scope of the proposed SDNP working group, we
   present a generic application use case and a sequence of steps
   needed for mapping the application requirements to a deployable
   network service. We also present a generic architecture framework
   that can meet such requirements.

   The goal of SDNP is to define a method where applications can
   request services from the network and these services can be
   automatically deployed. We view technologies such as FoRCES and
   OpenFlow as complementary and orthogonal to SDNP. Unlike Openflow,
   where the goal is to introduce a disaggregated control layer, the
   goal of SDNP is to enable existing control planes to become more
   adaptable to application requirements and to allow rapid and
   reliable configuration changes by introducing a framework for
   communication between applications and network control planes.  More
   importantly, the framework should be applicable to communicating
   application requirements even when a variety of network technologies
   is used to provide the required services. In this context, SDNP is
   also useful to OpenFlow type networks, since it provides the
   interface between applications and control planes implemented in an
   Openflow controller.

   In order to achieve these goals, applications should be able to
   specify their requirements in a generic way and these requirements
   must be translated in an actual network service. In general,
   application developers do not know in advance the type of networks
   that will be used and they would require an abstract and flexible
   framework for defining their requirements.

   Often times a service spans multiple administrative domains where
   given application requirements are met by different networking
   technologies. For example, providing network isolation for the
   application servers can be achieved by VLANs, MPLS or other
   underlying L2 or L3 technologies. It is possible that an application
   that is distributed between multiple data centers and networks be
   deployed through VLAN isolation in one domain and MPLS isolation in
   another domain, and an IP VPN in between. The application does not
   care as to which underlying technology is used to implement the
   isolation, as long as the properties of the isolation are

   In most instances the types of network technologies that should be
   used to deliver a given application will depend on policies either
   set by the network service provider, cloud service provider, another

Stiliadis et.al.        Expires April 31, 2012                 [Page 3]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   administrative authority, and/or the application itself. In multi-
   tenant environments there can be a hierarchy of policy objectives
   set by different organizations and the implementation of the network
   service must take into account all policy restrictions. For example,
   an enterprise IT organization can define that any application
   deployed by their employees must adhere to specific security
   requirements, such as encrypted tunnels between application servers.
   At the same time, because of an SLA contract, the service provider
   requires that the service is always deployed over redundant paths.
   In these cases, the requirements imposed by the application will be
   mapped in such a way that they comply with both policies. If for
   example a user within that organization tries to deploy an
   application with guaranteed bandwidth between servers, because of
   the policies defined above, the service instantiation will be over
   an encrypted and redundant path that satisfies the bandwidth
   constraint. In the next sections we provide an overview of this
   application driven framework and illustrate with specific examples
   how an SDNP controller can interact with control layer protocols.

2. General Terminology

   Network Spec: The definition of the network service requirements by
   an application.

   Network Mapping: The transformation of application requirements to a
   network service on specific network technologies.

   Binding: The binding of a network service to specific network

   SDNP Controller: The software controller that allows the
   specification of an application Network Spec, and implements the
   network mapping and binding functions. In binding the network
   mapping to a network element, the SDN control may talk to the
   network element directly or via another controller such as an
   Element Management System (EMS) or an open flow controller.

3. Framework

   First we illustrate a generic framework for mapping application
   requirements to network services and then we illustrate in more
   detail the functionality of each component. Note that this framework
   is just for illustration purposes and specific implementations can
   combine multiple functional blocks in a variety of ways.

   The basic blocks are illustrated in the next Figure:

Stiliadis et.al.        Expires April 31, 2012                 [Page 4]

Internet-Draft   Software Defined Networks Use Cases       October 2011

         +------+  +--------------+
         |      |  |Application   |
         |  P   |  |Definition    |
         |  O   |  +------|-------+
         |  L   |         |
         |  I   |  +------|-------+
         |  C   |  |Network       |
         |  I   |  |Mapping       |
         |  E   |  +------|-------+
         |  S   |         |
         |      |  +------|-------+
         |      |  |Network       |
         |      |  |Binding       |
         +------+  +--------------+

                        Figure 1 Generic Framework

     o Application Definition: This is a generic representation of the
        requirements of an application without specifying the
        underlying technology.
     o Network Mapping: This function translates the requirements of
        the application to an actual network service that can be
        implemented by a specific network technology.
     o Binding: This function maps the abstract network service on
        control planes and specific network elements.
     o Policies: Provides the repository of policies that will drive
        the translation between generic requirements and network
        technologies as well as the binding to specific elements.

3.1. Application Definition

   An example of multi-tier application definition is shown in the next

                  +------+                   +------+
               ---|Server|--|             ---|Server|--|
               |  +------+  |             |  +------+  |
   +--------+  |            |  +-------+  |            |  +-------+
   |Network |  |            |  |Network|  |            |  |Network|
   |Spec    |--|            |--|Spec   |--|            |--|Spec   |
   |Load    |  |            |  |(LAN)  |  |            |  |(WAN)  |
   |Balancer|  |            |  |       |  |            |  |       |
   +-------+   |  +------+  |  +-------+  |  +------+  |  +-------+_
               |--|Server|--|             ---|Server|--|
                  +------+                   +------+
                   Tier 1                     Tier 2
                Figure 2 Multi-tier application description

Stiliadis et.al.        Expires April 31, 2012                 [Page 5]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   From the application perspective, the definition consists of a set
   of compute and storage tiers interconnected by a network segment
   that meets specific requirements. The application does not care
   about the type of underlying technology, but rather about the
   properties of the network segment. Generic application requirements
   can include isolation, bandwidth, communication based on criteria
   other than shortest path, network redundancy, access control, etc.

   In the Example of Figure 2, the application might require that a
   load balancer distribute load among all the Tier 1 servers. The
   application does not care about how the load balancer is
   instantiated or how it is configured, or whether it is a physical or
   virtual machine. If the first Tier represents a set of Web servers
   and the second Tier a set of Business Logic servers, the network
   spec between the Tiers only defines that web-servers communicate
   with business logic servers over a specific protocol and port and
   require isolation. It does not define how this isolation is
   achieved. The network mapping function, depending on the technology
   chosen will implicitly identify the need for access lists or
   firewall rules between the Tiers that will prevent any unauthorized

   A different network spec will define the back-end connectivity
   requirements between the business logic tier and other enterprise
   services. For example, it might require that the Business Logic Tier
   must communicate with the enterprise Data Center over a secure
   connection, since critical data must be physically protected and
   stored within the enterprise premises. The application developer
   does not necessarily need to know whether the application is
   deployed across one or multiple DCs or what is the level of security
   required. However, the IT policies that have been supplied to the
   cloud provider should describe the necessary security mechanisms
   that must be deployed in order to comply with legal compliance rules
   or other policies. The policy will define for example that all
   access to data base Tiers must be encrypted, and the encryption
   strength that must be used.

   Another type of network spec might define that all servers in a
   given Tier belong to the same LAN, since the service will rely on
   virtual machine motion for balancing the load or achieving
   reliability. In another example, machines within a Tier need to form
   a cluster that must support fencing that is achieved by a majority
   protocol between the servers. In this case, healthy servers can
   shutdown network connectivity to failing servers and the network
   must provide the necessary APIs to achieve that. At the same time,
   the network APIs must prevent an application belonging to one

Stiliadis et.al.        Expires April 31, 2012                 [Page 6]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   customer to affect network connectivity of another customer or
   another application.

   In all the above examples, the application spec defines the
   properties and attributes of communication between components
   without necessarily defining the mechanism for achieving this

3.2. Network Mapping

   The first transformation needed is to map the application
   requirements to a set of network technologies that are supported by
   the underlying physical network. Different service providers and
   networks can choose different technologies for this implementation.

   For example, if the underlying network utilizes VLANs and VPLS, then
   it could map each of the individual networks in a different VLAN,
   and it could utilize VPLS for interconnecting data center VLANs with
   enterprise VLANs. Alternatively, if the service provider utilizes
   some L2 over L3 technology such as proposed in VXLAN [DRAFT-VXLAN]
   or PBB tunneling over IP, and IPVPN, it could use a combination of
   these technologies to map the application requirements to a set of
   network primitives.

   This transformation function takes as input the application
   requirements, the available network services, and the policy
   definitions, and creates a design of a composite network service
   that meets the application requirements. For the example
   instantiation of the 2-tier application using VLANs, the resulting
   network service is shown in Figure 3.

                        VLAN B
                     |     |          |         |     |
                     |     | Web Servers        |     |
                    +--+  +--+       +--+      +--+  +--+
                    |  |  |  |       |  |      |  |  |  |
                    +--+  +--+       +--+      +--+  +--+
                     |      |          |        |     |   Business
                                                         Logic Servers
        +-------+    |      |          |        |     |         +-----+
   WAN--|Load   |------------------------      -----------------| PE  |
        |Balance|      VLAN A                      VLAN C       +-----+
           Figure 3 Implementation of 2-tier service with VLANs

Stiliadis et.al.        Expires April 31, 2012                 [Page 7]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   In this network mapping, the DC/cloud service provider has chosen to
   implement the load balancer as a virtual machine, and has chosen to
   interconnect application Tiers through VLANs. It has chosen an IPVPN
   connectivity to the enterprise back-end. At this stage, although the
   network service has been defined, the exact VLAN numbers or nodes
   implementing the services have not been identified yet.

   Note, that when a service spans multiple administrative domains, it
   is possible that different technologies are used in each domain to
   meet the same application requirements. For example, an application
   that is split between a service provider data center and an
   enterprise data center might rely on IEEE SPB for layer-2 isolation
   within the service provider DC and VLAN based isolation within the
   enterprise data center. In another example, a WAN request for a
   guaranteed bandwidth path between data centers in different domains
   can be implemented as a wavelength service in one domain and as an
   MPLS service in another domain. Therefore, the service mapping must
   not only define how the network service is provided in each of the
   domains, but it must also identify the necessary mechanisms needed
   for stitching services between domains. Obviously, this might
   introduce a very large number of permutations, and therefore the
   SDNP work must concentrate on frameworks and specific use cases to
   limit the scope.

   Note also that in multi-domain implementations, there is no single
   master SDN controller. Each administrative domain will have its own
   SDN controller. In these cases, communication between SDN
   controllers must be done at the abstract level of service
   requirements rather than by defining explicit network technologies.
   In this way, different administrative domains can seamlessly
   interface to serve such applications, even when they rely on
   different network technologies.

   The next step in the process is the binding of the network service
   to specific network elements.

3.3. Network Service Binding

   During this step of the operation, the composite network service
   must be mapped to particular network elements and topologies. At
   this level, the necessary resources (servers, virtual load
   balancers, virtual firewalls, etc.) are mapped to specific physical
   resources. The network service interconnecting these resources must
   be instantiated through a sequence of programming steps between the
   SDN controller and the individual physical or virtual network
   elements or network management systems.

Stiliadis et.al.        Expires April 31, 2012                 [Page 8]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   There are several different methods that can be used to implement
   the binding process and a set of different protocols that can be
   used for communicating with the individual network elements or
   network management systems. Existing protocols include SNMP,
   Netconf, and even Command Line Interface (CLI). Alternative
   solutions might rely on network management tools and specific APIs
   that they expose. As Openflow matures, an SDNP controller could also
   program services in networks that utilize Openflow by communicating
   with the Openflow controller.

   The binding process will usually require a series of steps that can

     o L2 and L3 topology discovery,
     o Path selection for each service
     o Traffic engineering for providing some form of SLAs.
     o Configuration of network elements for L2 and L3 services

   Depending on the underlying technologies, some of the above steps
   can be omitted and can be performed with distributed control planes.
   For example establishing an MPLS path for communicating between data
   centers can utilize LDP or RSVP-TE and does not need explicit
   knowledge of the network topology or configuring every element in
   the path. On the other configuring VLANs on an Ethernet network
   might require explicit configuration of network elements.

   Nevertheless, the important characteristic of the binding process is
   that it requires a method for interacting with control layer
   protocols or network and element management systems. Even though a
   set of such mechanisms could be available in networks today, it is
   unclear that the interfaces are powerful or generic enough to allow
   such dynamic programming and this is the main focus of the SDNP
   work. Bridging the gap between the controlled environment of today's
   networks and an application driven network configuration will
   require a set of access control mechanisms that will protect the
   underlying infrastructure.

3.4. Policy Definition

   Every transformation step in the above description must be driven by
   policies that are administered either by the service provider, the
   IT organization requesting the service or the applications

   It is such policies that will determine how network requirements are
   mapped to network design and how services are bound to specific
   network elements. The policy complexity will depend on the service

Stiliadis et.al.        Expires April 31, 2012                 [Page 9]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   offered by a provider and can include security, billing, compliance,
   performance related policies, etc.

4. Examples of Service Binding

   As it is evident by the above description a complete framework for
   application-driven network programming offers several layers of
   abstraction and the work around SDNP must carefully choose the layer
   of scope in order to solve specific problems. Addressing the whole
   architecture might prove a huge and challenging task that will limit
   the usefulness or impact timely completion of the work.

   Clearly SDNP work must address the binding step that will enable
   configuration of network elements and control layer protocols in
   order to deliver the service. SDNP will also need to develop the
   interfaces between different administrative domains for services
   that span multiple domains. In the next Section we present such a
   control protocol configuration that will illustrate the scope of
   control plane programmability of SDNP.

4.1. Example: An end-to-end data center service

   We consider the example presented in the previous Sections. We
   assume that the implementation is done over an IEEE 802.1aq SPBM
   network within the data center and an IPVPN service will connect the
   DC servers with other enterprise resources. The SDNP controller will
   utilize two different mechanisms to program the DC LAN and IPVPN
   services. The logical service mapping is illustrated in the
   following Figure 4, and it is similar to that of Figure 3, where
   each VLAN is now replaced by a different service ID (ISID):

                   ISID A
                |     |          |         |     |  Business Logic
                |     | Web Servers        |     |  Servers
               +--+  +--+       +--+      +--+  +--+
               |  |  |  |       |  |      |  |  |  |
               +--+  +--+       +--+      +--+  +--+
                |      |          |        |     |
   +--------+   |      |          |        |     |         +---------+
   |Load    |-----------------------      -----------------| PE      |
   |Balancer|      ISID B                      ISID C      | +---+   |
   +--------+                                              | |VRF|   |
                                                           | +---+   |

               Figure 4 Service instantiation based on SPBM

Stiliadis et.al.        Expires April 31, 2012                [Page 10]

Internet-Draft   Software Defined Networks Use Cases       October 2011

4.1.1. LAN Configuration

                   +-------+     +-------+
                   |       |     |       |
                   |B-BEB  `------B-BEB  |
                   |       |     |       |
                   .-'--|--+     +--|--`-.
                .-'     |           \     `.
              .'        /            \      `-.
           .-'         |              |        `.
     +--.-'--+     +---/---+     +----\--+    +--`-.--+
     |       |     |       |     |       |    |       |
     |I-BEB 1|     |I-BEB 2|     |I-BEB 3|    |I-BEB 4|
     |       |     |       |     |       |    |       |
     +---|---+     +-------+     +-------+    +-------+
         |             |             |             |
     +---|---+     +---|---+     +---|---+     +---|---+
     |       |     |       |     |       |     |       |
     |       |     |       |     |       |     |       |
     |Servers|     |Servers|     |Servers|     |Servers|
     |       |     |       |     |       |     |       |
     |  T1   |     |  T1   |     |  T2   |     |  T2   |
     +-------+     +-------+     +-------+     +-------+

                      Figure 5 SPBM based DC networks

   We consider a DC network based on SPBM [IEEE802.1aq] (see Figure 5).
   Within the DC LAN, network isolation is provided by assigning
   virtual machines or servers of a given data center tenant to
   different Service IDs (ISIDs). A set of edge bridges (I-BEBs)
   encapsulate Ethernet frames using PBB encapsulation. The I-BEB
   function can be implemented either at the Top-of-Rack switch or at
   the hypervisor virtual switch. A set of B-Component bridges (B-BEB)
   interconnect the edge bridges. The I-BEBs will map traffic from each
   tenant to a particular service instance (I-SID/B-VID) depending on
   the service requirements. In the example of Figure 5, application
   tier T1 is associated with I-BEBs 1 and 2 and application tier T2 is
   associated with I-BEBs 3 and 4. The SPBM protocol provides the
   mechanisms for shortest path forwarding and learning in the backbone
   space without the need of deploying spanning trees or MAC learning.
   SPBM also provides the mechanisms for service auto-discovery and
   flood containment when a service covers a subset of service nodes.
   For example, if servers of a given Tier are associated with a subset
   of the I-BEBs, SPBM will create the multicast tree for flooding that
   will be associated with only this subset of I-BEBs. In order to
   instantiate a VM in a new node, the corresponding I-BEB needs to be
   provisioned, and once this provisioning is complete SPBM will expand

Stiliadis et.al.        Expires April 31, 2012                [Page 11]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   the multicast tree and include this I-BEB in the multicast
   distribution automatically. In the example of Figure 5, if a new VM
   from tier T1 is associated with I-BEB 4, the multicast tree
   associated with this I-SID/B-VID will be expanded to cover I-BEB4.

4.1.2. IPVPN Configuration

   As shown in Figure 4, the enterprise service in the DC is connected
   to other enterprise data centers and services through an IPVPN [RFC
   4364]. The first time that a business logic tier server is
   instantiated and ISID C is created, the SDNP controller must also
   provision the PE with the corresponding VRF. The SDNP controller
   provides the necessary information to the PE (incoming interface,
   ISID/B-VID pair, route targets and route distinguishers), and
   instructs the PE to instantiate the VRF. Once the VRF is
   instantiated, the existing routing protocol mechanisms (MP-BGP) will
   be used to propagate the routes to the other VRFs of the same IPVPN.
   Note, that in this case the SDNP controller does not define
   forwarding behavior, but it rather instantiates part of the control

   The scope of the SDNP configuration is limited to the edge PE and
   does not include any other provisioning or configuration in other
   routers in the network. This provides a simple interaction between
   the DC management system and network protocols, since it does not
   impose the requirement for the DC management system to understand
   the full network topology.

   In more complex environments with separate DC and WAN PEs, this
   configuration might apply only to the DC PE, and the inter-
   connection between DC and WAN PEs can be done using any of the
   options of [RFC 4364].

4.2. Configuration Alternatives

   The SDNP Controller can choose one of two methods for provisioning
   the necessary network functions.

4.2.1. Network Element based Configuration

   In the above examples, the function of the SDNP controller is
   limited to provisioning the "edge" elements (I-BEB, PE) and a layer-
   2 or layer-3 protocol propagates the necessary information through
   the network (SPBM or MP-B respectively). In both cases, the SDNP
   controller has the ability to directly program functions in the
   corresponding network elements and does not need access to all
   network elements.

Stiliadis et.al.        Expires April 31, 2012                [Page 12]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   In addition to the programming interface, the SDNP controller must
   have an exact representation of the physical topology so that it can
   identify which I-BEB and PE  must be provisioned (i.e. it is aware
   of the physical connectivity between I-BEBs and servers, L2 topology
   and PEs). The controller can discover this information by polling
   the I-BEBs and/or using LLDP between I-BEBs and servers. The
   controller can also listen to the SPBM protocol to capture topology
   information. Alternatively I-BEBs can proactively notify the SDNP
   controller about topology changes and the activation of new physical
   or virtual servers.

4.2.2. Network Management based Configuration

   In an alternative implementation, the SDNP controller does not
   directly provision network elements, but it utilizes a network
   management tool that is already deployed in the network. Note, that
   in several cases, cloud and network operators have deployed network
   management and OSS systems and would want all operations to be
   driven by the these systems.

   In this instance, the SDNP controller does not need to maintain
   detailed topology information, and it just talks to the
   corresponding network management system to issue the requests for I-
   BEB and PE provisioning.

5. SDN Model and Reference Architecture

   Based on the discussion above, and using the simple example of
   Section 4 as guidance, we can develop the SDN reference architecture
   that can capture these requirements. Figure 6 outlines this

   In this model, SDN Controllers expose an abstract API to
   applications, where they can request specific network properties
   such as bandwidth assignments, network isolation, routing
   properties, redundancy properties, security requirements, etc.
   Communication between different SDN Controllers enables these
   entities to provide services across network administrative domains
   without being constrained by underlying technologies. The interface
   is limited to communicating the requirements of the application.
   Each SDN Controller can translate application requirements to
   different technologies based on the underlying network
   implementations. This approach provides the maximum portability for
   applications and does not burden application developers with network
   technology specifics.

Stiliadis et.al.        Expires April 31, 2012                [Page 13]

Internet-Draft   Software Defined Networks Use Cases       October 2011

                  | Application API            |

                  |           Spec             |
         +------------------+ API     ------------------+    +------+
         |SDN Controller 1  |--------|SDN Controller N  |    |  P   |
         |                  |        |                  |    |  O   |
         +------------------+        +------------------+    |  L   |
                 | Service API                 |             |  I   |
                 |                             |             |  C   |
         +------------------+ Intf   +------------------+    |  Y   |
         |Network Specific  | API    |Network Specific  |    |      |
         |Module            |--------|Module            |    |      |
         +------------------+        +------------------+    +------+
                 | Network API                 |
                 |                             |
             +----------+                  +---------+
             |Plug-in   |                  |Plug-in  |
             |Rest API  |                  |Rest API |
             +----------+                  +---------+
                 |                            |
                 |                            |
         +-------+----------+                 |
         |Network Management|                 |
         |                  |                 |
         +-------+----------+                 |
                 |                            |
                 |                            |
         +-------+----------+        +--------+---------+
         |Network           |        |Network           |
         |Control Plane     |        |Control Plane     |
         +------------------+        +------------------+
                   Figure 6 SNDP reference architecture

   As it relates to the framework of Figure 1, the SDN controller
   implements the Network Mapping function and it includes the policy
   specification functions. The SDN controllers utilize a service API
   to communicate these requests with a network technology specific
   module that will be responsible for the translation of the
   requirements to specific technology primitives. An Interface API
   will enable network specific modules to stitch services together.
   This is a technology dependent API and it will enable functions such
   as mapping a VLAN to VPLS domain, or mapping an LSP to a wavelength
   and so on.
   The network specific module is essentially implementing the network
   binding function of Figure 1. For every network technology, there is

Stiliadis et.al.        Expires April 31, 2012                [Page 14]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   a specific API to the control plane of network elements that will
   allow the binding and instantiation of the network service. Note,
   that in several environments it is possible that the network mapping
   is communicated with a pre-existing network management system and
   not directly with the control plane of network elements. This not
   only allows the evolution from current operational models, but it
   also enables the concurrent support of existing and future
   operational models. If for example an OSS is currently driving the
   deployment of network services through a network management system,
   such an approach would allow new applications to utilize the same
   infrastructure and provide an evolutionary path to a software
   defined network.

   Note, that the network specific module might also include
   functionality related to topology discovery. The type of topology
   information required will depend on the underlying technology and it
   can range from a full network map in an Openflow environment to a
   limited resource view when the final binding operation is performed
   by a network management system.

5.1. Scope and Approach

   Given the number of different networking technologies and
   implementations, defining all possible APIs within the scope of a
   single working group will be hard to tackle. The SDNP work should
   therefore concentrate on designing the framework, application
   network requirements schema, and API control and communication
   architecture, as well as defining the reference schema and API
   around a single networking technology as an example use case. Once
   the framework is in place, the technology dependent functions can
   utilize it to develop their own specific APIs and this can be done
   across multiple working groups.

6. Security Considerations

   The SDNP controller security aspects must be addressed, including
   functions such as role based authentication and security of intra-
   SDNP controller communications.

7. IANA Considerations

   IANA does not need to take any action for this draft.

Stiliadis et.al.        Expires April 31, 2012                [Page 15]

Internet-Draft   Software Defined Networks Use Cases       October 2011

8. Conclusions

   This document has introduced a generic framework for mapping
   application requirements to specific network services within the
   context of Software Driven Networks. The document also outlined a
   reference framework as input to the definition of the scope of the
   SDNP work.

9. References

9.1. Normative References

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

9.2. Informative References

   [IEEE802.1aq] IEEE 802.1aq Shortest Path Bridging

   [RFC 4364] E. Rosen et.al, BGP/MPLS IP Virtual Private Networks, RFC
   4364, February 2006.

   [DRAFT-VXLAN] Mhalingham et.al., "VXLAN: A framework for Overlaying
   Virtualized Layer 2 Networks over Layer 3 Networks,", draft-
   mahalingham-dutt-dcops-vxlan-00.txt, September 2011.

10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot. We also
   want to thank T. Sridhar for early comments on the draft.

Authors' Addresses

   Dimitri Stiliadis
   777 E. Middlefield Rd
   Mountain View, CA 94043

   Email: dimitri.stiliadis@alcatel-lucent.com

Stiliadis et.al.        Expires April 31, 2012                [Page 16]

Internet-Draft   Software Defined Networks Use Cases       October 2011

   Florin Balus
   777 E. Middlefield Rd
   Mountain View, CA 94043

   Email: florin.balus@alcatel-lucent.com

   Wim Henderickx
   Copernicuslaan 50
   2018 Antwerp, Belgium

   Email: wim.henderickx@alcatel-lucent.be

   Nabil Bitar
   40 Sylvan Road
   Waltham, MA 02145

   E-mail: nabil.bitar@verizon.com

   Mircea Pisica
   Telecomlaan 9
   Brussels 1831, Belgium

   Email: mircea.pisica@bt.com

Stiliadis et.al.        Expires April 31, 2012                [Page 17]