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

Versions: 00 01 02

Network Working Group                                             P. Pan
Internet-Draft
Intended status: Standards Track                               T. Nadeau
Expires: September 12, 2012
                                                          March 11, 2012


Software-Defined Network (SDN) Problem Statement and Use Cases for Data
                          Center Applications
        draft-pan-sdn-dc-problem-statement-and-use-cases-02.txt

Abstract

   Software Defined Network (SDN) is an overlay architecture that
   presents the underlying transport network to the applications and
   services for monitoring, and provisioning at abstraction level.

   In this memo, we outline some of the problems, and present an
   architecture outline.  We will present a few applications to validate
   the problems and the architecture framework.

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

   This Internet-Draft will expire on September 12, 2012.

Copyright Notice

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



Pan & Nadeau           Expires September 12, 2012               [Page 1]

Internet-Draft            SDN for Data Centers                March 2012


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Problem Definition . . . . . . . . . . . . . . . . . . . .  5
     3.1.  The Architecture . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Use Case Summary . . . . . . . . . . . . . . . . . . . . .  8
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Bandwidth on Demand  . . . . . . . . . . . . . . . . . . .  9
     4.2.  Virtual Data Center  . . . . . . . . . . . . . . . . . . . 10
     4.3.  Virtual Data Center  . . . . . . . . . . . . . . . . . . . 12
   5.  Security Consideration . . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
























Pan & Nadeau           Expires September 12, 2012               [Page 2]

Internet-Draft            SDN for Data Centers                March 2012


1.  Introduction

   Service providers and enterprises are increasingly offering services
   and applications from data centers.  When the applications and
   services are offered from a group of data centers, they would require
   extensive support from the underlying IP networks.

   Software Defined Network (SDN) is an overlay architecture that
   presents the underlying transport network to the applications and
   services for monitoring, and provisioning at abstraction level.

   The concept of SDN has been controversial: some envision that the
   deployment of SDN would simplify network operation and system
   requirements, and thereby reduce overall networking cost.  On the
   other hand, some argue that SDN is adding nothing new in terms of
   network operation, as SNMP, NetConf and many existing protocols could
   be equally effective.

   We argue that the value in SDN is above and beyond network operation
   and equipment cost reduction.  SDN is a part of network service
   evolution.

   Traditionally, telephone companies have retained the control of
   voice, video and leased line services.  With the emergence of the
   Internet, the ISPs can trump all those services by leveraging the
   technology advancement in Ethernet, packet switching and IP routing,
   and offer VoIP, CDN and VPN services to the end-users at much reduced
   cost.

   The emergence of cloud-based computing has once again changed the
   networking service models.  Essentially, cloud computing is to
   utilize centralized processing, storage and computing to create a new
   service layer on top of the network.  The services can be modeled as
   IaaS, PaaS and SaaS etc.  Interactive services (which combines voice,
   video and data) could replace separated voice (e.g. phone) and video
   (e.g.  TV) services.  Enterprise services through private cloud may
   replace the traditional ISP-initiated VPN's.  Much of the mobile
   services, which have traditionally been run by the network service
   providers, could be realized by application providers over IP/LTE
   networks.  This change has been validated by service offerings from
   Google, Amazon and Apple in recent years, and likely will continue to
   proliferate in years to come.

   Consequently, the cloud-based services are driving the networking
   traffic demand.  It requires the networking resources to be available
   in anywhere and anytime.  As far as the cloud service providers are
   concerned, networking is an an utility business.  It makes no
   difference on network types (circuit or packet) and networking



Pan & Nadeau           Expires September 12, 2012               [Page 3]

Internet-Draft            SDN for Data Centers                March 2012


   technologies (Ethernet, IP or MPLS), as long as the network can
   reliably transport user data at competitive price.

   Within this framework, SDN plays the role of enabling cloud service
   providers to have an uniformed application interface to the
   underlying networks, so that they can optimize the use of the
   networking resources.

   Note that, SDN does not imply the following:

   1.  Data center management: There has been multiple approaches in
       constructing data centers network fabric (e.g.  Q-Fabric, PBB
       E-VPN, etc.).  SDN does not define and dictate the data center
       interior architecture and management.  Instead, SDN is to
       interface with the data centers to make the use of the network
       resources.

   2.  Storage and computing management: Cloud services can be roughly
       divided in storage, computing and networking.  SDN is only
       responsible for the networking portion.

   3.  Direct network operation: SDN is a technical solution that
       enables the cloud service providers to provision network
       resources from the application layer.  The operation itself must
       subject to proper business arrangement between data center and
       network service providers.  The SDN resource programming can only
       take place on abstract level.

   In this document, we will articulate the issues and present a general
   architecture in SDN through a number of user cases.


2.  Related Work

   There has been much work in this area over the years.

   OpenFlow has pioneered the concept of software-defined network via
   FlowVisor.  It has introduced a new packet forwarding methodology to
   be applied on hardware or software L2 switches.  OpenFlow Version 1.0
   have been in deployment in VM hypervisor environment.  OpenFlow
   Version 1.2 has been recently released where it has introduced the
   concept of "virtual interface" for aggregating multiple packet flows.
   The subsequent new versions will address issues such as
   extendibility, modularity and carrier-grade.

   NETCONF/YANG provides a XML-based solution for network device
   configuration.  It has been in wide-deployment.  By definition, it
   supports server-to-client configuration, but not client-to-server



Pan & Nadeau           Expires September 12, 2012               [Page 4]

Internet-Draft            SDN for Data Centers                March 2012


   alarms or feedback.

   ALTO is a server solution designed to gather network abstraction
   information and interface with applications (such as P2P) for more
   efficient traffic distribution.  It does not require configuring the
   underlying network devices.

   PCE is a client-server protocol that operates in MPLS networks that
   enables the network operators to compute and potentially provision
   optimal point-to-point and point-to-multipoint connections.  However,
   PCE does not interface with applications to optimize traffic from
   user applications.


3.  The Problem Definition

   As mentioned before, SDN is an overlay architecture that presents the
   underlying transport network to the applications and services for
   monitoring, and provisioning at abstraction level.

   The the existing network does not have a clean interface to the
   applications.  Figure 1 illustrates the relationship between
   application and network today, where the applications have little or
   fragmented knowledge, control of or visibility of underlying networks
   and resources.


         +-------------+    +-------------+    +-------------+
         | Application |    | Application |    | Application |
         |      #1     |    |      #2     |    |      #3     |
         +-------------+    +-------------+    +-------------+
                |                  |                  |
                |                  |                  |
         +---------------------------------------------------+
         |                   Physical Network                |
         +---------------------------------------------------+

          Figure 1: Application to network relationship today


   This presents a number of challenges and problems.

   First, due to the lack of correlation, it becomes difficult to
   provide service guarantees at network-level (in particular, delay) to
   the applications.  The operators may over-provision network links to
   overcome to potential network congestion and packet drop within data
   centers.  However, such practice may become unpredictable and costly
   in many networking scenarios.



Pan & Nadeau           Expires September 12, 2012               [Page 5]

Internet-Draft            SDN for Data Centers                March 2012


   Second, many services require the interface and interaction with 3rd
   party back-end applications that may operate from remote locations
   (such as ads networks).  This requires the service operators to
   constantly monitor the SLA conditions with remote applications, and
   adjust the network resources if necessary.

   Third, many data center applications (such as VM) require massive
   user data replication on different sites for performance and
   redundancy purposes.  Also, due to the limitation in routing and load
   balancing, much user traffic may be routed between data centers.  As
   such, the inter-data center data transport need to be efficient,
   which requires the proper interface between applications and network.

   Finally, to scale up enterprise applications on data centers, the
   VM's may locate on different data centers, and mirage between data
   centers depending on capacity and other constraints.  This requires
   the collaboration between VM applications and the underlying
   networks.

   SDN is to solve the above inefficiency, as envisioned in Figure 2.
   It is to enable the applications to visualize the traffic flows at IP
   network layer, and manage the mapping or binding between user traffic
   flows to the network connections from the edge of the networks.


         +-------------+    +-------------+    +-------------+
         | Application |    | Application |    | Application |
         |      #1     |    |      #2     |    |      #3     |
         +-------------+    +-------------+    +-------------+
                |                  |                  |
                |                  |                  |
         +---------------------------------------------------+
         |                      SDN Layer                    |
         |     (Network virtualization, programmability      |
         |                  and Monitoring)                  |
         +---------------------------------------------------+
                |                  |                  |
                |                  |                  |
         +---------------------------------------------------+
         |                   Physical Network                |
         +---------------------------------------------------+

          Figure 2: SDN-enabled network


   In summary, SDN is to provide the applications with the following
   capabilities:




Pan & Nadeau           Expires September 12, 2012               [Page 6]

Internet-Draft            SDN for Data Centers                March 2012


   1.  The ability to retrieve the underlying topology.

   2.  The ability to monitor underlying network conditions, such as
       failure etc.

   3.  The ability to initiate and adjust network connections/tunnels.

   4.  The ability for the applications to create services on top of the
       provisioned network connections directly

3.1.  The Architecture

   Specifically, the SDN architecture may be constructed as the
   following:


              +---------------------------+
              | Applications and Services |
              +---------------------------+
                            |
                            |
                 +----------------------+        +---------------------+
                 | SDN Service Mediator |<------>|   Network Topology  |
                 +----------------------+        | & Resource Database |
                   ^        |      ^             +---------------------+
                   |        |      |
        +----------+        |      +-------------+
        |                   |                    |
        |                  \|/                   |
   +-----------+      +--------------+      +------------+
   | Discovery |      |   Network    |      | Monitoring |
   +-----------+      | Provisioning |      +------------+
                      +--------------+

        Figure 3: Proposed SDN Architecture


   o  SDN Service Mediator: This is a logical server that coordinates
      applications and networks.  It may expand into multiple physical
      servers in different locations.  One may imagine the Service
      Mediator as an Apache-based web servers, with task scheduling and
      redundancy functions.  The Service Mediator may be owned by the
      network service providers to serve application providers.  Or the
      application providers may deploy Service Mediator to control
      traffic over multiple networks.

   o  Discovery: This is a process controlled by Service Mediator, but
      deployed to users or devices, in the form of applications or VM's.



Pan & Nadeau           Expires September 12, 2012               [Page 7]

Internet-Draft            SDN for Data Centers                March 2012


      It enables the SDN users to discover and register to the Service
      Mediator.  As a part of the discovery process, the SDN users may
      negotiate capabilities with the service mediator.  Some of the
      common discovery mechanisms could be a DNS extension (in which
      case, Service Mediator is simply a url for the users to contact),
      or as simple as IMPP messages.

   o  Network Provisioning: This the process that allows the Service
      Mediator to provision the underlying network resources.  There are
      many ways to provision the networks, depending on the
      applications.  For simple VLAN switching and aggregation, OpenFlow
      1.2 may be sufficient.  But for more sophisticated networking
      technologies, such as MPLS and GMPLS, the Service Mediator needs
      to input a range of attributes to the network (edge) devices in
      the form of NetConf or other protocols to create or adjust traffic
      engineering connections.

   o  Monitoring: This is an important function in SDN.  This allows the
      Service Mediator to interface with the underlying network to
      gather network topology information at abstract level, and detect
      the network failures that may impact the applications and
      services.

   o  Network Topology Database: This is a part of the inventory
      management that service/application providers maintain.  This is
      an important part of the SDN-enabled network operation.

   o  SDN North-Bound Interface: SDN Service Mediator is to provide the
      RESTful API's to the applications/services.  The API interface
      should be at abstract level and application-friendly.

3.2.  Use Case Summary

   In the remaining of the document, we will outline a number of
   potential SDN applications that can be implemented with the
   architecture outlined above.

   1.  Bandwidth on Demand: In this application, the applications will
       provision one or multiple physical links, and construct an
       overlay network for one or a group of users.  The provisioning
       sequence requires the setup, change or deletion of network
       connections/tunnels on network devices.  This application is also
       known as 'network slicing'.

   2.  Virtual Data Center: The data center servers may virtualize
       applications, processors and devices for the end users.  The
       virtual machines may be located on multiple data centers over IP
       networks.  For performance and reliability reasons, the traffic



Pan & Nadeau           Expires September 12, 2012               [Page 8]

Internet-Draft            SDN for Data Centers                March 2012


       from the virtual machines need to be inter-connected or
       aggregated over the network connections/tunnels that have been
       discovered and provisioned through SDN.

   3.  L3 Virtualization: L2 virtualization does not scale.  Through the
       coordination of SDN Service Mediator, the virtual machines may
       interconnect each other through IP routing protocols directly.


4.  Use Cases

4.1.  Bandwidth on Demand

   In this use case, we show the relevant SDN components for clarity,
   and suggest some of the possible implementation approaches.


              +---------------------------+
              | Applications and Services |
              +---------------------------+
                            |
                        (1) |
                 +----------------------+  (2)   +---------------------+
                 | SDN Service Mediator |<------>|   Network Topology  |
                 +----------------------+        | & Resource Database |
                            |      ^             +---------------------+
                            |      |
                        (3) |      +-------------+
                            |                    | (7)
                           \|/                   |
                      +--------------+      +------------+
                      |   Network    |      | Monitoring |
                      | Provisioning |      +------------+
                      +--------------+            ^
                            |           (6)       |
                         (4)|   +-----------------+
                            |   |
                      +--------------+
                      |  Router or   |   (5)
                      |   Switch     |=========( IP Networks )
                      +--------------+

           Figure 4: Support of Bandwidth-on-Demand


   As an illustration, shown in Figure 4, the application needs to
   create a MPLS connection with certain bandwidth on one of the inter-
   data center links.  Since it is aggregating traffic from a large



Pan & Nadeau           Expires September 12, 2012               [Page 9]

Internet-Draft            SDN for Data Centers                March 2012


   number of virtual machines, it needs to be notified in event of
   network failure.

   Here could be the sequence of events:

   1.  Through the RESTful API interface, the Service Mediator receives
       the request from applications.

   2.  The Service Mediator will query the network inventory database to
       select the proper link and network device for provisioning.  For
       argument sake, the Service Mediator could act as a PCE server,
       and compute the proper MPLS-TE ERO for the connection.

   3.  Upon the completion of the path computation, the Service Mediator
       will initiate the provisioning commands to the Provisioning
       Engine.

   4.  Through provisioning protocols (such as, PCE or NetConf or
       OpenFlow), the Provisioning Engine propagates the commands to the
       actual switches and routers.

   5.  The routers (or switches) will utilize the MPLS control-plane
       protocols to interface with other nodes in the network and
       complete the connection setup.

   6.  At some point, a unrecoverable failure has occurred in the
       network.  The Monitoring Engine will pick up the failure
       condition and compress the alarms.

   7.  The Monitoring Engine will notify the Service Mediator, which in
       turn will inform the corresponding applications and services.

   There are a number of variations here>:

   o  The underlying network could be an optical network running GMPLS.
      The same sequence would apply for setting up large inter-data
      center links.

   o  The enterprise network may not use IP routers.  A similar sequence
      could apply on multiple network nodes to perform manual VLAN
      cross-connects.  The provisioning protocol could be OpenFlow.

4.2.  Virtual Data Center

   The idea here is to construct an overlay network for a group of
   users.  Each user is represented by an individual virtual machine.
   All users in the same group will share a common network
   identification (such as VLAN).



Pan & Nadeau           Expires September 12, 2012              [Page 10]

Internet-Draft            SDN for Data Centers                March 2012


   When the users communicate among each other, they should not be aware
   of the underlying networks.  This requires the SDN to aggregate the
   user traffic over a selected set of network connections, which should
   provide adequate delay and bandwidth guarantees.

   In Figure 5, we will illustrate a simple use case:


             +---------------------------+
             | Applications and Services |
             +---------------------------+
                           |
                           |
                +----------------------+        +---------------------+
                | SDN Service Mediator |<------>|   Network Topology  |
                +----------------------+        | & Resource Database |
                  ^        |      ^             +---------------------+
                  |        |      |
       +----------+        |      +-------------+
       |                   |                    |
       |                  \|/                   |
  +-----------+      +--------------+      +------------+
  | Discovery |      |   Network    |      | Monitoring |
  +-----------+      | Provisioning |      +------------+
                     +--------------+
                      |  | | |
                 +----+  | | +----------------------------+
                 |       | +---------------------+        |
                 |       |         ^^^^^^        |        |
                 |       |        (      )       |        |
    +------+   +---+   +----+    (        )    +----+   +---+   +------+
    |Server|---|TOR|---|Core|---( Backbone )---|Core|---|TOR|---|Server|
    +------+   +---+   +----+    (        )    +----+   +---+   +------+
                                  (      )
             Data Center           vvvvvv             Data Center
                 #1                                         #2

    Figure 5: Support of Virtual Data Center


   This use case is very similar to that of Bandwidth-on-Demand.  The
   general operation sequence would be:

   o  The Service Mediator interfaces with network edge nodes, and
      provisions the network tunnels.

   o  When the application is to setup a logical connection between two
      virtual machines, the Service Mediator will identify the user



Pan & Nadeau           Expires September 12, 2012              [Page 11]

Internet-Draft            SDN for Data Centers                March 2012


      network identification (e.g.  VLAN or VXLAN), select the network
      tunnel to use.

   o  Fianlly, through Service Mediator, the application is to program
      the ToR switches and initiate the logical connections.  All
      virtual machine traffic will be aggregated through selected
      network connections for latency and bandwidth guarantees.

   This application is new, and much new signaling protocols have been
   proposed and studied.

4.3.  Virtual Data Center

   Due to historic reasons, much of the networking virtualization is
   through the use of L2 technology.  Consequently, the applications are
   experiencing sever scalability problems.  Many recent proposals have
   been focused in making the L2 technology more scalable, including
   extending the VLAN range.  Many hypervisors are positioned to run L3-
   over-L2-over-L3.

   We argue that to solve the virtual machine scaling problems, we
   should introduce L3 virtualization.

   Here, we introduce a method in supporting L3 virtualization using
   SDN:


























Pan & Nadeau           Expires September 12, 2012              [Page 12]

Internet-Draft            SDN for Data Centers                March 2012


                   +---------------------------+
                   | Applications and Services |
                   +---------------------------+
                                 |
                                 |
                      +----------------------+
                      | SDN Service Mediator |
                      +----------------------+
                          ^        |      ^
                          |        |      |
               +----------+        |      +-------------+
               |                   |                    |
               |                  \|/                   |
         +-----------+      +-------------+      +------------+
         |   BGP     |      |   BGP       |      |     BGP    |
         | Signaling |      |  Signaling  |      | Signaling  |
         |   GW      |      |    GW       |      |    GW      |
         +-----------+      +-------------+      +------------+
             |    |            |       |            |    |
             |    +---+        |       |        +---+    |
             |        |        |       |        |        |
           +----+   +----+   +----+  +----+   +----+   +----+
           | VM |   | VM |   | VM |  | VM |   | VM |   | VM |
           +----+   +----+   +----+  +----+   +----+   +----+

           Figure 6: Support of L3 Virtualization


   The idea is that the users (in VMs) may trigger the discovery
   process, and connect to BGP gateways when connecting to other users.
   The SDN Service Mediator is to correlate the routing information
   among BGP GW's.

   Much of the processing details can be found in 'BGP-signaled end-
   system IP/VPNs'
   (http://www.ietf.org/id/draft-marques-l3vpn-end-system-05.txt)

   There are a number of key advantages in this approach.

   1.  It scales: compare with the existing L2 solutions, this runs at
       IP layer.

   2.  Reuse much of the existing and proven routing techniques.  The
       underlying solution is identical to that of MPLS VPN that has
       been in wide deployment for years.

   3.  Application-friendly interface through SDN




Pan & Nadeau           Expires September 12, 2012              [Page 13]

Internet-Draft            SDN for Data Centers                March 2012


5.  Security Consideration


6.  IANA Considerations


7.  Acknowledgments

   This work is based on the interaction with many people.  Thanks
   Pedro, Lyndon, Shane and Matt.


8.  Normative References

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

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.


Authors' Addresses

   Ping Pan
   (Infinera)


   Email: ppan@infinera.com


   Thomas Nadeau
   (CA)


   Email: thomas.nadeau@ca.com
















Pan & Nadeau           Expires September 12, 2012              [Page 14]


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