IETF Ping Pan Internet Draft (Infinera) Thomas Nadeau (CA) Expires: January 3, 2012 October 3, 2011 Software-Defined Network (SDN) Problem Statement and Use Cases for Data Center Applications draft-pan-sdn-dc-problem-statement-and-use-cases-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that Pan et.al Expires January 3, 2012 [Page 1] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 3, 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. Abstract Service providers and enterprises are increasingly offering services and applications from data centers. Subsequently, data centers originate significant amount of network traffic. Without proper network provisioning, user applications and services are subject to congestion and delay. In this document, we argue the necessity in providing network information to the applications, and thereby enabling the applications to directly provision network edge devices and relevant applications. Table of Contents 1. Introduction...................................................3 Pan et.al Expires January 3, 2012 [Page 2] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 2.................................................................3 3. Related Work...................................................3 4. Problem Definition.............................................4 5. The Role of SDN Layer..........................................6 6. Use Cases......................................................7 6.1. Data Center Network Interface.............................7 6.2. Inter-data center transport..............................10 6.3. VPN......................................................11 7. Security Consideration........................................11 8. IANA Considerations...........................................11 9. Normative References..........................................11 10. Acknowledgments..............................................12 1. Introduction Service providers and enterprises are increasingly offering services and applications from data centers. Subsequently, data centers originate significant amount of network traffic. On contrast to end- to-end user applications, much of the inter-data center traffic is aggregated over a finite number of links over the backbone network. As such, without proper network provisioning, user applications and services are subject to congestion and delay. Further, many web applications would require the interaction between multiple servers in the networks. Without adequate level of monitoring and provisioning on the network, the users may experience unacceptable services. In this document, we argue the necessity in providing network information to the applications, and thereby enabling the applications to provision the underlying network edge devices and relevant applications directly. Here are some of the conventions used in this document. 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]. 2. 3. Related Work There has been much work in this area in recent years. Pan et.al Expires January 3, 2012 [Page 3] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 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 and 1.1 have been in deployment in VM hypervisor environment. 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. 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. 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. 4. Problem Definition 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. Pan et.al Expires January 3, 2012 [Page 4] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 +-------------+ +-------------+ +-------------+ | 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 too 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. Pan et.al Expires January 3, 2012 [Page 5] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 5. The Role of SDN Layer To solve the above problem, one simple way is to introduce a software-define network (SDN) layer (as shown in Figure 2), that is responsible for network virtualization, programmability and monitoring, between applications and network. +-------------+ +-------------+ +-------------+ | Application | | Application | | Application | | #1 | | #2 | | #3 | +-------------+ +-------------+ +-------------+ | | | | | | +---------------------------------------------------+ | SDN Layer | | (Network virtualization, programmability | | and Monitoring) | +---------------------------------------------------+ | | | | | | +---------------------------------------------------+ | Physical Network | +---------------------------------------------------+ Figure 2: Application to network relationship today The purpose of the SDN Layer 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. There are multiple ways in implementing the SDN Layer. There have been multiple proprietary solutions in the area of interfacing Virtual Machines (VM) to the underlying network interfaces. In particular, solutions such as OpenFlow support such vision by directly programming the underlying network interface via a new protocol. The implementation of SDN Layer involves the interfacing among applications, storage and network devices, which implies that there is a need for having a standardized interface. Pan et.al Expires January 3, 2012 [Page 6] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 Further, we recommend of utilizing the existing technologies and protocols to provision, manage and monitor network connections. The focus in realizing the SDN Layer is in optimizing the application- to-network workflow. The associated SDN protocols need to be modular, scalable and simple in design. 6. Use Cases 6.1. Data Center Network Interface Figure 3 illustrates the data flow in data centers. Pan et.al Expires January 3, 2012 [Page 7] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 +--------------------+ | User Applications | +--------------------+ | \|/ +------------------------------------------------------+ | | Data | | +--------------------------+ Centers | | | Application Interface | | | +--------------------------+ | | | | | \|/ | | +-------+ | | | Tasks | | | +-------+ | | / \ | | / \ | | +--------+ +--------+ | | | Server | | Server | +-------+ | | | #1 | ... | #N |<----->| SDN | | | +--------+ +--------+ |Control| | | | | +-------+ | | \|/ \|/ ^ | | +-------------------------------+ | | | | Network Interface |<------+ | | +-------------------------------+ | | | | +------------------------------------------------------+ | \|/ +--------------------+ | User Applications | +--------------------+ Figure 3: Data Center Traffic Flow The data centers are designed to scale up to handle a large volume of user requests. To handle the user requests, the application interface would process and bundle the requests to different servers. Depending on the application, the data may flow between the servers or be forwarded to the users through network interface. Pan et.al Expires January 3, 2012 [Page 8] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 Note that when the servers transmit data, they typically do not have the knowledge on network connection bandwidth, delay and distance information. For intra-data center communication, this can be compensated by over-provisioning local networks. However, for transferring data between two remotely located data centers, the applications have no control of the data transmission. Further, today, when setting up VM's over different servers, extensive manual configuration may be required. For example, all the traffic belongs to the same group/enterprise must share the same VLAN over all involved servers. This can potentially handicap the usability of the applications. In this case, it would be desirable to have a standardized SDP protocol that can be used by the applications to interface with the networks. Through this protocol, the applications should be able to assign VLAN values to the appropriate VM sessions over all servers, and interface with the connected networks to balance the traffic load if necessary. Pan et.al Expires January 3, 2012 [Page 9] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 6.2. Inter-data center transport +------------+ +----------------------| |-----------------------+ | +-------------| |-------------+ | | | +-----| SDN |----+ | | | | | | Controller | | | | | | | +------------+ | | | | | | | | | | | | ^^^^^^ | | | | | | ( ) | | | +------+ +---+ +----+ ( ) +----+ +---+ +------+ |Server|---|TOR|---|Core|---( Backbone )---|Core|---|TOR|---|Server| +------+ +---+ +----+ ( ) +----+ +---+ +------+ ( ) Data Center vvvvvv Data Center #1 #2 Figure 4: Inter-data center transport When transporting data between data centers, the packets will be encapsulated into one or multiple tunnels before sending over the Internet. Traffic engineering is typically applied at tunnel-level. For instance, user IP packets at servers may be encapsulated first into a VLAN tunnel, and then aggregated into MPLS LSP's at the core node. In this case, it would be desirable of having a SDN controller to coordinate the aggregation procedure. The controller is responsible for determining the mapping of the VLAN's to the MPLS LSP's. Further, it is possible that the controller can interface with the core node to adjust the LSP bandwidth. Pan et.al Expires January 3, 2012 [Page 10] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 6.3. VPN Another use case is VPN, as shown in Figure 5. +----------+ +------+ | SDN | |Office| +--|Controller|-------+ | A |----+ | +----------+ | +------+ | ^^^^^^^^ | | | +----+ ( ) +----+ +------+ +-------+ | CE |---( Backbone )---| PE |----|Switch|---|Servers| +----+ ( ) +----+ +------+ +-------+ +------+ | vvvvvvvv |Office| | Data Center X | B |----+ +------+ Figure 5: VM Groups to MPLS VPN Mapping At application level, the service providers may initiate a set of VM's for a specific enterprise. For service guarantee, it requires all the VM's that may be distributed on various servers and data centers to be mapped to the same MPLS (L2)VPN. There are multiple ways in achieving this goal. One is to utilize a centralized SDN Controller to coordinate the mapping. 7. Security Consideration 8. IANA Considerations This document has no actions for IANA. 9. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. Pan et.al Expires January 3, 2012 [Page 11] Internet-Draft SDN Data Center Problem and Use Cases October 3, 2011 10. Acknowledgments This work is based on the conversation with many people, including Thomas Nadeau, Lydon Ong and Benson Schliesser. Authors Addresses Ping Pan Email: ppan@infinera.com Thomas Nadeau Email: thomas.nadeau@ca.com Pan et.al Expires January 3, 2012 [Page 12]