Internet DRAFT - draft-nadeau-sdn-problem-statement
draft-nadeau-sdn-problem-statement
Network Working Group T. Nadeau, Ed.
Internet-Draft CA Technologies, Inc.
Intended status: Informational
Expires: April 31, 2012 P. Pan, Ed.
Infinera
October 31, 2011
Software Driven Networks Problem Statement
draft-nadeau-sdn-problem-statement-01
Abstract
Software Driven Networks (SDN) is an approach to networks that
enables applications to converse with and manipulate the control
software of network devices and resources. SDNs are comprised of
applications, control software, and interfaces to services that
are hosted in an overlay or logical/virtual network as well as
those possibly same components that comprise the underlying
physical network. Modern applications require the ability
to easily interact and manipulate these resources. Applications can
benefit from knowing the available resources and from requesting
that the network makes the resources available in specific ways.
To this end, there is a requirement to couple applications more
closely to the underlying resources on which they depend, consume
and interact with.
SDN infrastructure and components exist in most deployed networks
today. Some of these components are being standardized by various
organizations, as as well some being already standardized by the
IETF. However, no standards or open specifications currently exist
to facilitate end-to-end operation of a software defined network,
specificlly one that provides open APIs for applications to control
the network services and functions offered by device control planes
or other "controlling" software. The goal of this document is to
outline the problem area of SDN for the IETF.
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.
Nadeau Expires April 30, 2012 [Page 1]
SDN Problem Statement October 31, 2011
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 30, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . .. . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . .. . 5
1.2. SDN Background . . . . . . . . . . . . . . . . . . . .. . 9
2. SDN Interconnect Use Cases . . . . . . . . . . . . . . . .. . 9
3. SDN Interconnect Model & Problem Area for IETF . . . . . .. . 11
3.1. Candidate SDN Problem Area for IETF . . . . . . . . . . . 13
4. Design Approach for Realizing the SDN APIs . . . . . . . . . 15
4.1. Relationship to the OSI network model . . . . . . . .. . 15
4.2. "Reuse Instead of Reinvent" Principle . . . . . . . .. . 16
4.3. Application to SDN Orchestrator Interface . . . . . . . . 16
4.4. SDN Orchestrator to Plug-In Interface . . . . . . . . . . 18
4.5. SDN Logging Interface . . . . . . . . . . . . . . . . . . 19
4.6. SDN Orchestrator to Location Services Interface . . . . . 20
4.7. SDN Orchestrator to Policy Database Interface . . . . . . 20
4.8. SDN Orchestrator to SDN Orchestrator Interface. . . . . . 20
5. Gap Analysis of relevant Standardization and Research
Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Nadeau Expires April 30, 2012 [Page 2]
SDN Problem Statement October 31, 2011
5.1. Open Network Forum . . . . . . . . . . . . . . . . . . . . 21
6. Relationship to relevant IETF Working Groups . . . . . . . . . 23
6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Additional Material . . . . . . . . . . . . . . . . . 29
A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 29
A.2. Prioritizing the SDN Work . . . . . . . . . . . . . . . . 30
A.3. Related standardization activities . . . . . . . . . . . . 31
A.4. Related Research Projects . . . . . . . . . . . . . . . . 35
A.4.1. IRTF Cross Stratum Optimizaiton Research Group . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
Software Driven Networks (SDN) is an approach to networks that
enables applications to converse with and manipulate the control
software of network devices and resources. Modern applications
require the ability to easily interact and manipulate resources
provisioned and controlled by networks. Applications can benefit
from knowing the available resources and from requesting that the
network makes the resources available in specific ways.
To this end, there is a requirement to couple applications more
closely to the underlying resources on which they depend, consume
and interact with. In particular, modern applications require
interaction with and the manipulation of both physical and virtual
compute, storage and connectivity resources and abstract interfaces
to these things. These abstractions must also allow applications to
manipulate resources at varying levels of granularity, policy and
security. It is also worth noting that modern Software Driven
Networks (SDNs) are comprised of applications, control
software, and interfaces to services that are hosted in an overlay
or logical/virtual network as well as those possibly same
components that comprise the underlying physical network.
These services include path computation, topology discovery,
firewall services, domain name services, network address
translation services, virtual private networks and the like. These
services and elements may be physical or virtual.
One requirement is to create a means by which applications can
Nadeau Expires April 30, 2012 [Page 3]
SDN Problem Statement October 31, 2011
communicate with the control planes of the underlying network
devices or entities which control and own network resources on
which they depend. Note that the "control planes" of network
devices will be referred to as "controlling software" to abstract
away the concept of the software that controls a device's data
plane. The control planes of devices, whether physically co-located
with a device and its data plane, or externally located for
example in the case of an OpenFlow "controller", provide coherent
control of the network apparatus. However, the "controlling
software" of a virtual machine might be a hypervisor. There is a
desire by network operators and service providers to control,
configure, mange or set policy on controlling software and do so
using applications for different network control and manipulation
options.
Software Defined Networks infrastructure exists in most deployed
networks today. Some of these components are being standardized by
various organizations, as as well some being already standardized
by the IETF. However, no standards or open specifications
currently exist to facilitate end-to-end operation of a software
defined network, specificlly one that provides open APIs
for applications to control the network services and functions
offered by device control planes or other "controlling" software.
The goal of this document is to outline the problem area of SDN for
the IETF.
Section 2 discusses the use cases for SDN. Section 3
presents the SDN model and problem area to be considered by the
IETF. Section 4 discusses how existing protocols can be reused to
define the SDN interfaces, service discovery and object models.
1.1. Terminology
This document uses the following terms:
Control Plane: In a router or switch, the control plane is the
part of the router firmware/software architecture that is in charge
of the logic behind things such as constructing a map of the network
topology, running network protocols or management functions and
then ultimately instructing the device's data plane to realize
any forwarding or switching actions that must be enabled. While
conceptually separate in a logical sense, the control plane is
often physically separated from the data plane of a device either
by running on a processor dedicated to this function, or even run
externally from the device on another device or process (i.e.:
in the case of OpenFlow, centralized routing, etc...).
Data Plane: This is the part of a network device that is responsible
Nadeau Expires April 30, 2012 [Page 4]
SDN Problem Statement October 31, 2011
for the actual (i.e.: physical) forwarding and manipulation of
data that comes into and is transmitted out of a device. The
data plane of a device is typically very tightly bound to the
specific nature of the hardware of that particular forwarding
component of a device, and as such is often kept seperated from
the more generic control plane. An example of a data plane
would be the switching fabric and port processors of a router.
Controlling Software: In the case of network devices, this is
analagous to the control plane. However, in the case of
virtualization technologies, this may be present in the form of
a hypervisor, for example.
Application Programming Interface (API): is a particular set
of rules and specifications that software programs can follow
to communicate with each other. It serves as an interface between
different software programs and facilitates their interaction,
similar to the way the user interface facilitates interaction
between humans and computers.
Software As a Service (SaaS): Sometimes referred to as
"on-demand software," is a software delivery model in which
software and its associated data are hosted by a service provider
and connected back to the customer via The Internet. These
are sometimes referred to as "cloud services" as well.
Managed Network Service Provider (MSP): Provides network-based
connectivity and services to End Users, as well a managed
service. For example, one popular MSP might offer virtualized
machines (VMs) and a virtual private network (VPN) connectivity
between these VMs with external connectivity to this VPN
of machines via a managed business grade metro ethernet link
to the customer's premise.
Communications Service Provider (CSP): A traditional "telco"
service provider that offers data connectivity as a service
to its customers.
1.2. SDN Background
Readers are assumed to be familiar with the architecture, features
and operation of SDNs. For readers less familiar with the operation
of SDNs, the following resources may be useful:
[Provide references TBD]
Nadeau Expires April 30, 2012 [Page 5]
SDN Problem Statement October 31, 2011
2. SDN Use Cases
An increasing number of MSPs are deploying SDNs in order to
both offer more cost-effective service offerings, but also
to reduce internal costs of managing and operating those
services.
Since SDNs allow for a more consistent and shorter time-to-market
model of developing management software for various network-based
services, service providers are moving towards using various
proprietary schemes for this. SDNs are being used to deliver
various types of services that provide externally consumable
SaaS offerings, as well as those used internally to manage and
manipulate their network infrastructure.
Some MSPs operate over multiple geographies and couple infrastructure
from different MSPs, SPs and possibly SaaS offerings. In these
cases, it is important to provide the MSP that offers the ultimate
service to the customer with a clean, consistent and effient
interface to all of the infrastructure it relies on. Furthermore,
from their perspective, being able to unwind the "russian doll"
of nested infrastructure and services that might be rolled together
for their service offering in cases where trouble shooting is
required for example, is paramount.
In the simplest of cases it may not seem obvious that the use of
a standardized SDN infrastructure would be necessary; however,
in typical medium and large data center offerings that are quite
common today, the management of the physical elements is a small
part of the larger puzzle for the MSP or CSP. When network elements
become virtualized and are then used to construct components of
services being offered, an operator can quickly multiply the number
of management "devices" or more commonly "elements", by many orders
of magnitude. It is here that the problem of lack of open interfaces
for SDN component interconnection and discovery becomes clear.
Again, for this requirement, SDN operators
(over-the-top SDN operators or NSPs) are faced with a lack of open
specifications and best practices.
Use cases for SDN Interconnection are further discussed in <TBD>
3. SDN Model & Problem Area for The IETF
Managing a network of deployed SDN components involves interactions
among multiple different functions and components that exist within
the network. Some of these components are virtual and some of these
Nadeau Expires April 30, 2012 [Page 6]
SDN Problem Statement October 31, 2011
components are real; all should be made available to be managed and
manipulated, given the appropriate access, authentication, and policy
hurdles have been crossed. Only some of those
require standardization. The SDN model and problem area proposed
for IETF work is illustrated in Figure 1. The candidate problem area
(and respectively the non-goals) for IETF work are shown in Figure 2.
|--------Application
v ^
+----------+ |
| Location | | <--- Application-to-
| Services | | Ochestrator protocol
+----------+ v
^ ReST API
| +-------------------+ +------------------+
|----| Orchestrator_0..N + -----> | Policy Data Base |
+-------------------+ +------------------+
^
| <--- Orchestrator-to-Plug-In Protocol
|
V
+----------+
| Plug-In |
| ReST API |
+----------+
^
*
V
+******************+
* Control Software *
* For Device_0..M *
+******************+
^
=
V
+=================+
= Data Plane =
= For Device_0..M =
+=================+
<--> interfaces and objects inside the scope of SDN
+--+
<**> interfaces and objects may be within the scope of SDN
+**+ insofar as modifcations are needed to support SDN
Nadeau Expires April 30, 2012 [Page 7]
SDN Problem Statement October 31, 2011
<==> interfaces and objects outside the scope of SDN
+==+
Figure 1: SDN Problem Area
3.1. Candidate SDN Problem Area for IETF
Listed below are the the interfaces required to connect
an application with the SDN components and protocols in a network.
This constitutes the problem space that is proposed to be
addressed by a potential SDN working group in the IETF. The use of
the term "interface" is meant to encompass the protocol over which
SDN data representations (e.g. SDN Metadata records) are exchanged
as well as the specification of the data representations themselves
(i.e. what properties/fields each record contains, its structure,
etc.).
o SDN Orchestrator-to-Application Interface: This interface allows
the SDN Orchestrator or "controller" system to be interconnected
with applications. This interface may support the following:
* Allow bootstrapping of the interface between the Orchestrator
and interested applications.
* Allow the applications to authenticate.
* Allow applications to learn of which objects they have
authorization to manipulate, or to interact with objects
beloning to controlling software.
o SDN Orchestratort-to-Plug-In Interface: This interface allows
the SDN Orchestrator to interconnect with the controlling software
of devices.
o SDN Orchestratort-to-Policy Database Interface: This interface
allows the SDN Orchestrator to interconnect with policy,
authentication and authorization databases.
o SDN Orchestratort-to-location services Interface: This interface
allows the SDN Orchestrator to interconnect with location
services in order to:
* Register itself as a local Orchestrator.
* Allow other Orchestrators and applications to find it.
o SDN Orchestrator-to-SDN Orchestrator Interface: This interface
allows one SDN Orchestrator to interconnect with one or more
Orchestrators
in order to:
* Form a failover/high-availability relationship
* distribute mappings of controlling software-to-Orchestrator
Nadeau Expires April 30, 2012 [Page 8]
SDN Problem Statement October 31, 2011
* bootstrapping of the other SDN Orchestrators.
* configuration of the other SDN Orchestrators.
o SDN Logging interface: This interface allows the Logging system
in interconnected SDN Orchestrators to communicate the relevant
activity logs in order to allow log consuming applications to
operate in multi-SDN Orchestrator environments. For example,
this interface can be used to collect logs from SDN
Orchestrators to provide reporting and monitoring to the M/CSP
of SDN activities.
As part of the development of the SDN interfaces and solutions it
will also be necessary to develop and agree on common mechanisms
for how to define the object schemas used to query object model
stores of each controlling software element.
4. Design Approach for Realizing the SDN APIs
This section expands on how SDN interfaces can reuse and leverage
existing protocols. First the "reuse instead of reinvent" design
principle is restated, then each inetrface is discussed individually
with example candidate protocols that can be considered for reuse or
leverage. This discussion is not intended to pre-empt any WG
decision as to the most appropriate protocols, technologies and
solutions to select to solve SDN but is intended as an illustration
of the fact that the SDN interfaces need not be created in a vacuum
and that reuse or leverage of existing protocols is likely possible.
4.1. Relationship to the OSI network model
The SDN interfaces called out above in Section 3.1 within the SDN
problem area all operate at the application layer (Layer 7 in the
OSI network model). Since it is not expected that these interfaces
would exhibit unique session, transport or network requirements as
compared to the many other existing applications in the Internet, it
is expected that the SDN interfaces will be defined on top of
existing session, transport and network protocols.
4.2. "Reuse Instead of Reinvent" Principle
Although a new application protocol could be designed specifically
for SDN we assume that this is unnecessary and it is recommended
that existing application protocols be reused or leveraged such
as HTTP[RFC2616] to devine the SDN interfaces.
4.3. Application to SDN Orchestrator Interface
4.4. SDN Orchestrator to Plug-In Interface
Nadeau Expires April 30, 2012 [Page 9]
SDN Problem Statement October 31, 2011
4.5. SDN Logging Interface
The SDN Logging interface enables details of logs or events to be
exchanged between interconnected SDN Orchestrators, where events
could be:
o Log lines related to the connection of a new Orchestrator, or
disconnection of an existing one.
o A fail-over, switch-over event. Similarly, high-availability
synchronication messaging.
o Real-time or near-real time events before, during or after
SDN Orchestrator commands noting which application instructed
it to perform the operation.
o Operations and diagnostic messages.
Several protocols already exist that could potentially be used to
exchange SDN Orchestrator logs including SNMP Traps or Informs,
syslog, s/ftp, HTTP POST, or ReST, etc. although it is likely that
some of the candidate protocols may not be well suited to meet all
the requirements of SDN. For example SNMP Traps pose scalability
concerns, and syslog may have potential compatability issues.
Although it is not necessary to define a new protocol for exchanging
logs across the SDN Logging interface, a SDN WG would still need to
specify:
o The recommended protocol to use.
o A default set of log fields and their syntax & semantics. Today
there is no standard set of common log fields across different
content delivery protocols and in some cases there is not even a
standard set of log field names and values for different
implementations of the same delivery protocol.
o A default set of events that trigger logs to be generated.
4.6. SDN Orchestrator to Location Services Interface
4.7 SDN Orchestrator to Policy Database Interface
4.8 SDN Orchestrator to SDN Orchestrator Interface
5. Gap Analysis of relevant Standardization and Research Activities
There are a number of other standards bodies and industry forums that
are working in areas related to SDNs, and in some cases related to
SDN. This section outlines any potential overlap with the work of
the SDN WG and any component that could potentially be reused by
Nadeau Expires April 30, 2012 [Page 10]
SDN Problem Statement October 31, 2011
SDN.
A number of standards bodies have produced specifications related to
SDNs, namely:
o Open Network Forum has a dedicated specification called Open Flow
which specifies a relationship to an external "control plane"
interfacing to a Hardware Abstraction Layer (HAL) that is
implemented on Open Flow-capable hardware.
6. Relationship to relevant IETF Working Groups
6.1. ALTO
As stated in the ALTO Working Group charter [ALTO-Charter]:
"The Working Group will design and specify an Application-Layer
Traffic Optimization (ALTO) service that will provide applications
with information to perform better-than-random initial peer
selection. ALTO services may take different approaches at balancing
factors such as maximum bandwidth, minimum cross-domain traffic,
lowest cost to the user, etc. The WG will consider the needs of
BitTorrent, tracker-less P2P, and other applications, such as content
delivery networks (SDN) and mirror selection."
In particular, the ALTO service can be used by an SDN-aware
application to improve its selection of an SDN Orchestrator. For
example, an application wishing to provision MPLS L3 VPNs on behalf
of some virtual machines in a local data center cluster may with
to take advantage of the ALTO service in its decision for
selecting a relatively close SDN Orchestrator to complete its
operations.
However, the work of ALTO is complementary to and does not overlap
with the work proposed in this document because the integration
between ALTO and a SDN would fall under the category of using
an existing protocol. One area for further study is whether
additional information should be provided by an ALTO service
to facilitate SDN Orchestrator selection. For example, loading
or fail-over characterists could be one consideration.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Nadeau Expires April 30, 2012 [Page 11]
SDN Problem Statement October 31, 2011
8. Security Considerations
SDNs comes with a range of security considerations such as how to
enforce control of and access to objects managed by the SDN
Orchestrators and making sure that in line with the M/CSP policy.
9. Acknowledgements
The authors would like to thank David Meyer, Ping Pan, Lyndon Ong,
Danny McPhereson for their review comments and contributions to the
text.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[ALTO-Charter]
"IETF ALTO WG Charter
(http://datatracker.ietf.org/wg/alto/charter/)".
[Draft-Lee] L. Young, Bernstein, G., Kim, T., Shiomoto, K., and
Dios, O.,
"Research Proposal for Cross Stratum Optimization (CSO)
between Data Centers and Networks",
draft-lee-cross-stratum-optimization-datacenter-00.txt
Appendix A. Additional Material
Note to RFC Editor: This appendix is to be removed on publication as
an RFC.
A.1. Non-Goals for IETF
Listed below are aspects of content delivery that the authors propose
be kept outside of the scope of a potential SDN working group:
o The interface between Controlling Software (i.e.: control plane)
and the device's data plane.
o Definition of any hardware abstraction layer (HAL)
Nadeau Expires April 30, 2012 [Page 12]
SDN Problem Statement October 31, 2011
A.2. Prioritizing the SDN Work
A.3. Related standardization activities
OpenFlow has pioneered the concept of software-defined
network via a concept called a FlowVisor. It has introduced
a new packet forwarding methodology to be applied on hardware
or software L2 switches. OpenFlow Version 1.0 and 1.1 have
been in research trials and testing in virtualized environments.
The new versions will address issues such as extendibility,
modularity and carrier-grade. Currently, OpenFlow does not
support a mechanism to interface with network devices
through the existing IP/MPLS control-plane protocols, although
some work has begun to investigate this.
NETCONF/YANG provides a XML-based solution for network device
configuration. It has been in wide-deployment. By definition,
it supports client-to-server configuration, and server-to-client
alarms or feedback (The servers are the devices/systems to be
configured, the clients are the network configuration/management
systems). NETCONF provides support for executing configuration
change transactions over multiple devices.
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.
DMTF is a cloud computing standardization organization, which
have defined many virtualization management interfaces using
Restful API. However, it does not include any interface to the
underlying networks.
A.4. Related Research Projects
A.4.1. IRTF Cross Stratum Optimizaiton Research Group
Some information on SDN motivations and technical motivations
in the IRTF's Cross Stratum Optimization Group [Draft-Lee].
Nadeau Expires April 30, 2012 [Page 13]
SDN Problem Statement October 31, 2011
Authors' Addresses
Thomas D. Nadeau (editor)
CA Technologies, Inc.
273 Corporate Drive
Portsmouth, NH 03801
Email: thomas.nadeau@ca.com
Ping Pan
Infinera Corporation
169 Java Drive
Sunnyvale, CA 94089
Phone: (408) 572-5200
Email: ppan@infinera.com
Nadeau Expires April 30, 2012 [Page 14]
