Internet DRAFT - draft-pan-sdn-dc-problem-statement-and-use-cases
draft-pan-sdn-dc-problem-statement-and-use-cases
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]
