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

Versions: 00

Internet Research Task Force                                      H. Yin
Internet-Draft                                                    H. Xie
Intended status: Informational                                   T. Tsou
Expires: December 29, 2012                           Huawei Technologies
                                                                D. Lopez
                                                               P. Aranda
                                                          Telefonica I+D
                                                                 R. Sidi
                                                             ConteXtream
                                                           June 27, 2012



 SDNi: A Message Exchange Protocol for Software Defined Networks (SDNS)
                        across Multiple Domains
                       draft-yin-sdn-sdni-00.txt

Abstract

   This draft proposes a protocol SDNi for the interface between
   Software Defined Networking (SDN) domains to exchange information
   between the domain SDN Controllers.  It defines the concept of a SDN
   domain; its need, what are its components and how SDNi helps in inter
   domain communication.

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 December 29, 2012.

Copyright Notice

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




Yin, et al.             Expires December 29, 2012               [Page 1]


Internet-Draft                SDNi protocol                    June 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
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Motivation Behind SDN  . . . . . . . . . . . . . . . . . . . .  5
   3.  SDN Architecture . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  SDN Functionality  . . . . . . . . . . . . . . . . . . . . . .  8
   5.  SDN Domains  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  SDNi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  SDNi Message . . . . . . . . . . . . . . . . . . . . . . . 10
     6.2.  SDNi Protocol  . . . . . . . . . . . . . . . . . . . . . . 11
     6.3.  Practical Considerations . . . . . . . . . . . . . . . . . 11
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowlegements  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   11. Informative References . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12






















Yin, et al.             Expires December 29, 2012               [Page 2]


Internet-Draft                SDNi protocol                    June 2012


1.  Introduction

   Software Defined/Driven Networking (SDN) is generally defined as an
   emerging network architecture where network control is decoupled from
   forwarding and is directly programmable.  This migration of control,
   formerly tightly bound in individual network devices, into accessible
   computing devices enables the underlying infrastructure to be
   abstracted for applications and network services, which can treat the
   network as a logical or virtual entity.

   SDN focuses on four key features:

   o  Separation of the control plane from the data plane.

   o  A centralized controller and view of the network.

   o  Open interfaces between the devices in the control
      plane(controllers) and those in the data plane.

   o  Programmability of the network by external applications.

   The centralized view and the separation of the control plane and the
   data plane means that the SDN controller can create a physical
   topology of how nodes are connected and, based on some combination of
   algorithms, create paths through the network.  Finally, the paths are
   programmed into the devices' forwarding engines.  That allows the SDN
   controller to better manage traffic flows across the entire network
   and react to changes quicker and more intelligently.  How well the
   controller defines those paths is, of course, critical to the
   operation of an SDN.

   The controller is akin to a computer's operating system (a network-
   control operating system, if you will) on which applications are
   written.  It communicates with the underlying network hardware
   (switches and routers) through a protocol such as OpenFlow.
   Different types of SDN controller software, then, are analogous, in
   certain respects, to Windows, Linux, and Mac OS X. What's more, just
   like those computer-based operating systems, today's controller
   software is not interoperable.

   As much as OpenFlow and SDN have been conflated and intertwined in
   the minds of many, we need to understand that SDN controllers are at
   higher layer of network abstraction, providing a platform for network
   applications and a foundation for networking programmability.
   OpenFlow is just an underlying protocol that facilitates interaction
   between the controller and data-forwarding tables on switches.

   Due to the great potentials of SDN and the unique requirements of



Yin, et al.             Expires December 29, 2012               [Page 3]


Internet-Draft                SDNi protocol                    June 2012


   Data Center Networks (DCNs), Data Centers are likely to become a
   first place where SDN could be deployed.  We envision that SDN could
   be gradually adopted by enterprise networks and then by carrier
   networks due to its unique, attractive features.  When deploying SDN
   in large- scale distributed networks, we expect to see a collection
   of deployments limited to portions of a bigger network (referred to
   as SDN domains).  In other words, the operator of a large-scale
   enterprise / carrier network should divide the whole networks into
   multiple connected SDN domains, where each of such domains
   corresponds to a relatively small portion of the whole network.  Such
   a divide-and- conquer methodology not only allows gradual deployment
   and continuous evolution, but also enables flexible provisioning of
   the network.

   With the deployment of multiple SDN domains comes the issue of
   exchanging information between these domains.  This draft defines the
   concept of an SDN domain and proposes a protocol SDNi as a protocol
   for interface between inter SDN domains.

1.1.  Terminology

   While the definition of software define/driven networks is still
   "nebulous" to some extent, we refer to as SDN the networks that
   implement the separation of the control and data/forwarding planes
   and software defined/driven interactions between these two separated
   planes.  SDN provides capability of network openness in that
   applications can program networking devices via APIs.  The software
   defined/driven interactions could be similar to OpenFlow or the like.
   However, how the two separated planes interact is not a focus of this
   draft.

   Networking devices: networking devices are hardware devices or
   software elements capable of forwarding data packets and
   communicating with Network Operating System (NOS).

   Network Operating System (NOS): NOS is software responsible for
   monitoring and controlling a network system.  It has whole knowledge
   of the underlying network topology and resources.  NOS provides a
   programmatic platform based on the abstraction of the underlying
   network devices to applications by means of appropriate virtual
   elements, controlled by APIs that provide access to network functions
   and common functionalities.  It facilitates network access and
   control to applications by translating their requests to actions on
   networking devices.  The traditional device control plane can be
   built within NOS or above NOS.

   SDN controller: SDN controller represents a SDN open platform, and
   responsible for managing the platform.  With or without NOS, SDN



Yin, et al.             Expires December 29, 2012               [Page 4]


Internet-Draft                SDNi protocol                    June 2012


   controller implements SDN's functionality.  A general SDN controller
   is a software entity that opens SDN APIs to applications, and
   translates application's request to actions on network devices using
   proprietary protocol or OpenFlow -like protocol with or without NOS's
   supports.  The SDN controller can reside in an NOS or run separately
   on a server in network.

   SDN controller-based applications: Applications interacting with
   underlying networks via SDN controller.  They can run inside the
   controller or they can be (virtual) appliances distributed throughout
   the network and serve some (specific) high-function and have the
   controller configure the network devices to steer traffic through
   those elements selectively according to SDN policy.

   Some controllers leverage OpenFlow exclusively, and others are (or
   will be) capable of accommodating other protocols and mechanisms to
   achieve the same practical result.  A normal OpenFlow controller can
   be integrated within NOS or run within SDN controller depending on
   implementation.

   SDN-capable devices: networking devices are capable of communicating
   with NOS/SDN controller using proprietary protocol or standard
   protocol, like OpenFlow.  The devices which do not support the
   proprietary protocol or OpenFlow are normal devices.

   An SDN domain is a portion of a network infrastructure, consisting of
   numerous connected networking devices that are SDN-capable and NOS
   that supports proprietary protocol or OpenFlow.  A SDN domain
   controller (SDN controller) can cover multiple NOSs, means it can
   communicating with multiple NOSs via some proprietary protocol or NOS
   APIs, or it can communicates with OpenFlow-enabled devices directly
   if OpenFlow protocol is supported in the controller.  An SDN domain
   can be as small as a sub-network of a dozen devices or as large as a
   medium/large data center network.  An network can consist of one or
   many SDN domains.  Hence an inter-SDN domain protocol is needed.


2.  Motivation Behind SDN

   There has been a great deal of innovation in networking software but
   not that much in networking.  Networks are still stuck in the past
   with routing algorithms that change very slowly or with primitive
   network management.  Computation and storage have been virtualized,
   creating a more flexible and manageable infrastructure, but networks
   are still hard to manage.  Networking is built with limited view of
   application needs.  Networks used to be simple: basic Ethernet/IP
   straightforward, easy to manage but new application requirements have
   led to control plane complexities.  Each control requirement leads to



Yin, et al.             Expires December 29, 2012               [Page 5]


Internet-Draft                SDNi protocol                    June 2012


   new mechanisms and so networks continue to grow more complex.

   By simplifying network's structures and allowing applications to take
   part in the control of networks, SDN provides innovative principles
   of networking system construction.  With the trends of the network
   development that moving from networks to more and more services and
   applications, applications are taking more roles in network routing
   decisions and affecting the traditional network functionalities and
   behaviors.  As an interaction and control point between applications/
   services and underlying networks, SDN controller is a key point in
   SDN networks and clearly a SDNi protocol among controllers is clearly
   a necessity in our opinion.


3.  SDN Architecture

   As software-defined networking gains traction, vendors and
   enterprises will generally adopt a three-tiered architecture as seen
   in Figure 1.
































Yin, et al.             Expires December 29, 2012               [Page 6]


Internet-Draft                SDNi protocol                    June 2012


                  +-----+          +-----+
                  | App |          | App |
                  +-----+          +-----+
                     |                |
                     |  RESTFUL APIs  |
                     |                |
             +--------------------------+    SDNi    +-----------------+
             |                          |  protocol  |                 |
             |     SDN Controller       |<---------->| SDN Controller  |
             |                          |            |                 |
             +--------------------------+            +--------------- -+
                    /             \     \
                   /<-----+        \     -----
                  /       |         \         \
                 /        |          \         \
        +-----------+     |        +-----------+\
        |           | proprietary  |           | \
        |    NOS    | protocol/API |    NOS    |  \
        |           |     |        |           |   \
        +-----------+     |        +-----------+    \
          /    |    \     |         /        \       \
         /     |     \<---+        /          \       \
.....   /      |      \           /            \       \       ....
:      /       |       \         /              \       \         :
:   +----+  +----+  +----+   +----+         +----+  +-------+     :
:   | ND |  | ND |  | ND |   | ND |         | ND |  | OF SW |     :
:   +----+  +----+  +----+   +----+         +----+  +-------+     :
:                                                                 :
:                                                                 :
:                       SDN Domain                                :
:                                  ND: Networking Device          :
:                                  OF SW: OpenFlow-enabled switch :
:.................................................................:


                     Figure 1: An Architecture For SDN

   The architecture's first tier will involve the physical network
   equipment, including Ethernet switches and routers.  This forms the
   dataplane.  The middle tier consists of the controllers that
   facilitate setting up and tearing down flows and paths in the network
   leveraging information about capacity and demand obtained from the
   networking gear through which the traffic flows.  This forms the
   control plane, NOS and SDN controller/platform over it.  The top tier
   will involve applications to direct security, management and other
   specific functions through the controller.  However, instead of
   relying on proprietary software running on each switch to control its
   forwarding behavior, switches in a SDN architecture are controlled by



Yin, et al.             Expires December 29, 2012               [Page 7]


Internet-Draft                SDNi protocol                    June 2012


   a Network OS (NOS) that collects information and manipulates their
   low-level forwarding plane, providing an abstract model of the
   network topology to the SDN controller hosting the applications.
   Applications can adapt the network behavior to suit specialized
   requirements, for example, providing network virtualization services
   that allow multiple logical networks to share a single physical
   network - similar to the way in which a hypervisor allows multiple
   virtual machines to share a single physical machine.

   These controller-based applications will serve the same roles that
   physical appliances play in the network today.  For example, network
   architects who are building software-defined networks could deploy
   applications like a virtual load balancer, a virtual intrusion
   detection system (IDS), or a virtual firewall on a controller.  The
   application could tap into information the controller possesses about
   traffic patterns, application data and capacity.  Cloud computing
   applications could be a big beneficiary of software-defined
   networking and OpenFlow because these technologies make provisioning
   in a multi-vendor virtual environment much simpler.  For instance a
   controller-based load balancing application could automate the
   movement of workloads among virtual machines by using the
   controller's view of the capacity of individual network devices.

   SDN controller is a software module in a SDN domain; logically it
   represents the highest control point in a SDN domain network, and
   physically it can reside in NOS or run independently at a separate
   server.  SDN controller provides north- bound APIs to user
   applications, and interacts with NOS to collect network information
   for applications.


4.  SDN Functionality

   This section provides a detailed explanation of the role of SDN
   controller in SDN.

   SDN is constructed through the separation of control plane and
   forwarding plane of networking devices.  The decoupling is achieved
   by turning the network control problem into a state management
   problem, and only exposing the state to be managed to the
   application, and not the mechanisms by which it arrived.
   Applications operate over control traffic, flow table state,
   configuration state, port state, counters, etc.  However, how this
   data is pulled into the controller, and how any changes are pushed
   back down to the switch is not the application's concern.  It can
   just use the controller API to modify network state which in turn
   will be translated to necessary commands on the relevant devices to
   have the new state correctly applied on the network.



Yin, et al.             Expires December 29, 2012               [Page 8]


Internet-Draft                SDNi protocol                    June 2012


   SDN controller should provide following functionality:

   o  Provide northbound APIs for applications so they can program
      underlying network properties such as bandwidth assignments,
      network isolation, routing properties, redundancy properties, or
      security requirements.

   o  Provide covered SDN domain network topology view to applications
      so that applications can define data flow and flow path within the
      view.

   o  Respond and adapt to the network conditions and provide event-
      handling mechanisms for applications so that they can receive
      feedback and adapt accordingly.

   o  Have covered SDN domain network services and resources views so
      that the controller can coordinate application's requests.

   o  Work with NOS/control plane to collect underlying device
      information and translate application's request to actions on
      network devices and feed into NOS/control plane.

   o  Act as the controller of physical devices, such as the OpenFlow
      control mechanism if such mechanism is not implemented in NOS[1].


5.  SDN Domains

   An SDN domain is a portion of the network determined by the network
   operator.  It has a SDN controller to control the domain, it can
   cover multiple NOS or communicate with some SDN-capable devices
   directly.  Each NOS typically consists of numerous inter-connected
   SDN-capable devices.  An example of such NOS is illustrated in
   [ONIX].  The SDN controller aggregates network topology views from
   multiple NOS and maintain a global network view of networks covered
   by the domain.  The controller is responsible for dispatching and
   disseminating application's request to corresponding NOS.  Two SDN
   domains are adjacent if there is a physical link between two
   underlying networks.

   Inside each SDN domain, its controller may define domain-specific
   policies on information importing from devices, aggregating, and
   exporting to external entities.  Such policies may not be made
   public; therefore, other domain controllers may not know the
   existence of such policies for any given SDN domain.

   When receiving an application request for certain network resources,
   the SDN controller should decide if the request can be satisfied.  If



Yin, et al.             Expires December 29, 2012               [Page 9]


Internet-Draft                SDNi protocol                    June 2012


   it can be satisfied, the controller should instruct the devices in
   its domain by updating them with a set of data/forwarding rules so
   that the devices could implement such rules and fulfill the request.


6.  SDNi

   SDNi is a protocol for interfacing SDN domains.  It is responsible
   for coordinating behaviors between SDN controllers and exchange
   control and application information across multiple SDN domains.
   SDNi is an "east-west" protocol between SDN controllers, as an
   analogy to OpenFlow being a "north-south" protocol between NOS and
   Network devices.  As such, SDNi should be a protocol implemented by
   the NOS (the same as OpenFlow or any other control protocols as
   mentioned above) and how the applications/SDN controllers that run in
   the NOS use this protocol (i.e. what is the API to use it) is out of
   scope of this document.

   SDNi protocol should be able to

   o  Coordinate flow setup originated by applications, containing
      information such as path requirement, QoS, SLA etc. across
      multiple SDN domains.

   o  Exchange reachability information to facilitate inter-SDN routing.
      This will allow a single flow to traverse multiple SDNs and have
      each controller select the most appropriate path when multiple
      such paths are available.

   SDNi depends on the types of available resources and capabilities
   available and managed by the different controllers in each domain.
   Hence it is important to implement SDNi in a descriptive and open
   manner so that new capabilities offered by different types of
   controllers will be supported.

   Since SDN in essence allows for innovation, it is important that data
   exchanged between controllers will be dynamic in nature, i.e. there
   should be some meta-data exchange that will allow SDNi to exchange
   information about unknown capabilities.

6.1.  SDNi Message

   The types of messages exchanged via SDNi can be:

   o  Reachability update

   o  Flow setup/tear-down/update request (including application
      capability requirement such as QoS, BW, latency etc.)



Yin, et al.             Expires December 29, 2012              [Page 10]


Internet-Draft                SDNi protocol                    June 2012


   o  Capability update (including network related capabilities such as
      BW, QoS etc. and system and software capabilities available inside
      the domain).

6.2.  SDNi Protocol

   SDNi is used to exchange information between SDN domains that are
   under the control of a single network operator or collaborating
   operators.  One way to implement SDNi is to use extension of BGP and
   SIP over SCTP protocols to exchange information.

6.3.  Practical Considerations

   SDN domains are built by network operator for flexible administration
   purpose.  It depends on the scale of underlying network that the
   operator decides how to divide whole network into SDN domains.  For
   some small-scale data centers, only one SDN domain may be enough.
   For a Service Provider with large carrier network, it is most likely
   better to divide the network into SDN domains as centralizing the
   control onto a single NOS/controller will create a bottleneck.  For
   example, Operator can divide its network into different SDN domains
   based on physical locations.  It can lease such part of its network
   to local content provider, etc.  Such deployment scenario requires an
   SDN controller providing powerful network service capability to
   applications.

   Also defining domains and interconnections between them involves more
   than simple connections between SDN boxes; it requires to consider
   various aspects such as to work out how their network topologies
   connect together, which neighbor controller boxes to talk to and how
   to get their addresses, what rights and policies control the
   conversation etc.

   Other aspects to be considered are who is allowed to deploy
   'programs' on the SDN infrastructure what actions can a 'program'
   execute depending on who deployed them: the SDN network manager is
   likely in control to deploy 'programs' on the SDN infrastructure.
   The focus then is on how the deployed programs might affect other
   domains and what mechanism we want to use to communicate this effect
   to the other domains.


7.  Conclusions

   Add any conclusions






Yin, et al.             Expires December 29, 2012              [Page 11]


Internet-Draft                SDNi protocol                    June 2012


8.  Acknowlegements

   The authors would like to thank Aditi Vira for editing the draft.


9.  Security Considerations

   o  What actions are 'applications' allowed to execute?

   o  How is the security policy propagated to other SDN domains.

   o  An application should not be able to do a DoS attack (either
      willingly or unwillingly)


10.  IANA Considerations

   This document makes no specific request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


11.  Informative References

   [1]  Xie, H., Yin, H., Tsou, T., and V. Hilt,
        "draft-xie-alto-sdn-use-cases-00.txt", June 2012.


Authors' Addresses

   Hongtao Yin
   Huawei (USA)
   2330 Central Expy
   Santa Clara, CA  95050
   USA

   Phone:
   Email: Hongtao.yin@huawei.com












Yin, et al.             Expires December 29, 2012              [Page 12]


Internet-Draft                SDNi protocol                    June 2012


   Haiyong Xie
   Huawei & USTC
   2330 Central Expy
   Santa Clara, CA  95050
   USA

   Phone:
   Email: Haiyong.xie@huawei.com


   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone:
   Email: Tina.Tsou.Zouting@huawei.com


   Diego R. Lopez
   Telefonica I+D
   Don Ramon de la Cruz, 84
   Madrid,   28006
   Spain

   Phone:
   Email: diego@tid.es


   Pedro Andres Aranda
   Telefonica I+D
   Don Ramon de la Cruz, 84
   Madrid,   28006
   Spain

   Phone:
   Email: pedro.aranda@tid.es













Yin, et al.             Expires December 29, 2012              [Page 13]


Internet-Draft                SDNi protocol                    June 2012


   Ron Sidi
   ConteXtream
   3600 West Bayshore Rd.
   Palo Alto, CA  94303
   USA

   Phone:
   Email: ron@contextream.com











































Yin, et al.             Expires December 29, 2012              [Page 14]


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