| Network Working Group | P. Pan |
| Internet-Draft | (Infinera) |
| Intended status: Standards Track | T. Nadeau |
| Expires: September 10, 2012 | (CA) |
| 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
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.
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].
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 10, 2012.
Copyright (c) 2012 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.
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 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:
In this document, we will articulate the issues and present a general architecture in SDN through a number of user cases.
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 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.
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.
+-------------+ +-------------+ +-------------+
| Application | | Application | | Application |
| #1 | | #2 | | #3 |
+-------------+ +-------------+ +-------------+
| | |
| | |
+---------------------------------------------------+
| Physical Network |
+---------------------------------------------------+
Figure 1: Application to network relationship today
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.
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.
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.
+-------------+ +-------------+ +-------------+
| Application | | Application | | Application |
| #1 | | #2 | | #3 |
+-------------+ +-------------+ +-------------+
| | |
| | |
+---------------------------------------------------+
| SDN Layer |
| (Network virtualization, programmability |
| and Monitoring) |
+---------------------------------------------------+
| | |
| | |
+---------------------------------------------------+
| Physical Network |
+---------------------------------------------------+
Figure 2: SDN-enabled network
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.
In summary, SDN is to provide the applications with the following capabilities:
+---------------------------+
| Applications and Services |
+---------------------------+
|
|
+----------------------+ +---------------------+
| SDN Service Mediator |<------>| Network Topology |
+----------------------+ | & Resource Database |
^ | ^ +---------------------+
| | |
+----------+ | +-------------+
| | |
| \|/ |
+-----------+ +--------------+ +------------+
| Discovery | | Network | | Monitoring |
+-----------+ | Provisioning | +------------+
+--------------+
Figure 3: Proposed SDN Architecture
Specifically, the SDN architecture may be constructed as the following:
In the remaining of the document, we will outline a number of potential SDN applications that can be implemented with the architecture outlined above.
+---------------------------+
| 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
In this use case, we show the relevant SDN components for clarity, and suggest some of the possible implementation approaches.
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 number of virtual machines, it needs to be notified in event of network failure.
Here could be the sequence of events:
There are a number of variations here>:
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).
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.
+---------------------------+
| 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
In Figure 5, we will illustrate a simple use case:
This use case is very similar to that of Bandwidth-on-Demand. The general operation sequence would be:
This application is new, and much new signaling protocols have been proposed and studied.
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.
+---------------------------+
| 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
Here, we introduce a method in supporting L3 virtualization using SDN:
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.
This work is based on the interaction with many people. Thanks Pedro, Lyndon, Shane and Matt.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. |