idnits 2.17.1 draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2011) is 4560 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 122 -- Looks like a reference, but probably isn't: 'OpenFlow' on line 128 == Unused Reference: '1' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 418, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Ping Pan 2 Internet Draft (Infinera) 3 Thomas Nadeau 4 (CA) 6 Expires: January 31, 2012 October 31, 2011 8 Software-Defined Network (SDN) Problem Statement and Use Cases for 9 Data Center Applications 11 draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, and it may not be 21 published except as an Internet-Draft. 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, except to publish it 26 as an RFC and to translate it into languages other than English. 28 This document may contain material from IETF Documents or IETF 29 Contributions published or made publicly available before November 30 10, 2008. The person(s) controlling the copyright in some of this 31 material may not have granted the IETF Trust the right to allow 32 modifications of such material outside the IETF Standards Process. 33 Without obtaining an adequate license from the person(s) controlling 34 the copyright in such materials, this document may not be modified 35 outside the IETF Standards Process, and derivative works of it may 36 not be created outside the IETF Standards Process, except to format 37 it for publication as an RFC or to translate it into languages other 38 than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on January 31, 2012. 58 Copyright Notice 60 Copyright (c) 2011 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with 68 respect to this document. 70 Abstract 72 Service providers and enterprises are increasingly offering services 73 and applications from data centers. Subsequently, data centers 74 originate significant amount of network traffic. Without proper 75 network provisioning, user applications and services are subject to 76 congestion and delay. 78 In this document, we argue the necessity in providing network 79 information to the applications, and thereby enabling the 80 applications to directly provision network edge devices and relevant 81 applications. 83 Table of Contents 85 1. Introduction...................................................3 86 2. Related Work...................................................3 87 3. Problem Definition.............................................4 88 4. The Role of SDN Layer..........................................6 89 5. Use Cases......................................................7 90 5.1. Data Center Network Interface.............................7 91 5.2. Inter-data center transport..............................10 92 5.3. VPN......................................................11 93 5.4. VM Mobility..............................................11 94 6. Security Consideration........................................12 95 7. IANA Considerations...........................................12 96 8. Normative References..........................................12 97 9. Acknowledgments...............................................12 99 1. Introduction 101 Service providers and enterprises are increasingly offering services 102 and applications from data centers. Subsequently, data centers 103 originate significant amount of network traffic. On contrast to end- 104 to-end user applications, much of the inter-data center traffic is 105 aggregated over a finite number of links over the backbone network. 106 As such, without proper network provisioning, user applications and 107 services are subject to congestion and delay. 109 Further, many web applications would require the interaction between 110 multiple servers in the networks. Without adequate level of 111 monitoring and provisioning on the network, the users may experience 112 unacceptable services. 114 In this document, we argue the necessity in providing network 115 information to the applications, and thereby enabling the 116 applications to provision the underlying network edge devices and 117 relevant applications directly. 119 Here are some of the conventions used in this document. The key 120 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC-2119 [RFC2119]. 124 2. Related Work 126 There has been much work in this area in recent years. 128 OpenFlow [OpenFlow] has pioneered the concept of software-defined 129 network via FlowVisor. It has introduced a new packet forwarding 130 methodology to be applied on hardware or software L2 switches. 131 OpenFlow Version 1.0 and 1.1 have been in deployment in VM 132 hypervisor environment. The new versions will address issues such as 133 extendibility, modularity and carrier-grade. Currently, OpenFlow 134 does not support a mechanism to interface with network devices 135 through the existing IP/MPLS control-plane protocols. 137 NETCONF/YANG provides a XML-based solution for network device 138 configuration. It has been in wide-deployment. By definition, it 139 supports client-to-server configuration, and server-to-client 140 alarms or feedback (The servers are the devices/systems to be 141 configured; the clients are the network configuration/management 142 systems). NETCONF provides support for executing configuration 143 change transactions over multiple devices. 145 ALTO is a server solution designed to gather network abstraction 146 information and interface with applications (such as P2P) for more 147 efficient traffic distribution. It does not require configuring the 148 underlying network devices. 150 PCE is a client-server protocol that operates in MPLS networks that 151 enables the network operators to compute and potentially provision 152 optimal point-to-point and point-to-multipoint connections. However, 153 PCE does not interface with applications to optimize traffic from 154 user applications. 156 DMTF is a cloud computing standardization organization, which have 157 defined many virtualization management interfaces using Restful API. 158 However, it does not include any interface to the underlying 159 networks. 161 3. Problem Definition 163 Figure 1 illustrates the relationship between application and 164 network today, where the applications have little or fragmented 165 knowledge, control of or visibility of underlying networks and 166 resources. 168 +-------------+ +-------------+ +-------------+ 169 | Application | | Application | | Application | 170 | #1 | | #2 | | #3 | 171 +-------------+ +-------------+ +-------------+ 172 | | | 173 | | | 174 +---------------------------------------------------+ 175 | Physical Network | 176 +---------------------------------------------------+ 178 Figure 1: Application to network relationship today 180 This presents a number of challenges and problems. 182 First, due to the lack of correlation, it becomes difficult to 183 provide service guarantees at network-level (in particular, delay) 184 to the applications. The operators may over-provision network links 185 to overcome to potential network congestion and packet drop within 186 data centers. However, such practice may become too costly in many 187 networking scenarios. 189 Second, many services require the interface and interaction with 3rd 190 party back-end applications that may operate from remote locations 191 (such as ads networks). This requires the service operators to 192 constantly monitor the SLA conditions with remote applications, and 193 adjust the network resources if necessary. 195 Third, many data center applications (such as VM) require massive 196 user data replication on different sites for performance and 197 redundancy purposes. Also, due to the limitation in routing and load 198 balancing, much user traffic may be routed between data centers. As 199 such, the inter-data center data transport need to be efficient, 200 which requires the proper interface between applications and 201 network. 203 Finally, to scale up enterprise applications on data centers, the 204 VM's may locate on different data centers, and mirage between data 205 centers depending on capacity and other constraints. This requires 206 the collaboration between VM applications and the underlying 207 networks. 209 4. The Role of SDN Layer 211 To solve the above problem, one simple way is to introduce a 212 software-define network (SDN) layer (as shown in Figure 2), that is 213 responsible for network virtualization, programmability and 214 monitoring, between applications and network. 216 +-------------+ +-------------+ +-------------+ 217 | Application | | Application | | Application | 218 | #1 | | #2 | | #3 | 219 +-------------+ +-------------+ +-------------+ 220 | | | 221 | | | 222 +---------------------------------------------------+ 223 | SDN Layer | 224 | (Network virtualization, programmability | 225 | and Monitoring) | 226 +---------------------------------------------------+ 227 | | | 228 | | | 229 +---------------------------------------------------+ 230 | Physical Network | 231 +---------------------------------------------------+ 233 Figure 2: Application to network relationship today 235 The purpose of the SDN Layer is to enable the applications to 236 visualize the traffic flows at IP network layer, and manage the 237 mapping or binding between user traffic flows to the network 238 connections from the edge of the networks. 240 There are multiple ways in implementing the SDN Layer. There have 241 been multiple proprietary solutions in the area of interfacing 242 Virtual Machines (VM) to the underlying network interfaces. In 243 particular, solutions such as OpenFlow support such vision by 244 directly programming the underlying network interface via a new 245 protocol. 247 The implementation of SDN Layer involves the interfacing among 248 applications, storage and network devices, which implies that there 249 is a need for having a standardized interface. 251 Further, we recommend of utilizing the existing technologies and 252 protocols to provision, manage and monitor network connections. The 253 focus in realizing the SDN Layer is in optimizing the application- 254 to-network workflow. The associated SDN protocols need to be 255 modular, scalable and simple in design. 257 5. Use Cases 259 5.1. Data Center Network Interface 261 Figure 3 illustrates the data flow in data centers. 263 +--------------------+ 264 | User Applications | 265 +--------------------+ 266 | 267 \|/ 268 +------------------------------------------------------+ 269 | | Data | 270 | +--------------------------+ Centers | 271 | | Application Interface | | 272 | +--------------------------+ | 273 | | | 274 | \|/ | 275 | +-------+ | 276 | | Tasks | | 277 | +-------+ | 278 | / \ | 279 | / \ | 280 | +--------+ +--------+ | 281 | | Server | | Server | +-------+ | 282 | | #1 | ... | #N |<----->| SDN | | 283 | +--------+ +--------+ |Control| | 284 | | | +-------+ | 285 | \|/ \|/ ^ | 286 | +-------------------------------+ | | 287 | | Network Interface |<------+ | 288 | +-------------------------------+ | 289 | | | 290 +------------------------------------------------------+ 291 | 292 \|/ 293 +--------------------+ 294 | User Applications | 295 +--------------------+ 297 Figure 3: Data Center Traffic Flow 299 The data centers are designed to scale up to handle a large volume 300 of user requests. To handle the user requests, the application 301 interface would process and bundle the requests to different 302 servers. Depending on the application, the data may flow between the 303 servers or be forwarded to the users through network interface. 305 Note that when the servers transmit data, they typically do not have 306 the knowledge on network connection bandwidth, delay and distance 307 information. For intra-data center communication, this can be 308 compensated by over-provisioning local networks. However, for 309 transferring data between two remotely located data centers, the 310 applications have no control of the data transmission. 312 Further, today, when setting up VM's over different servers, 313 extensive manual configuration may be required. For example, all the 314 traffic belongs to the same group/enterprise must share the same 315 VLAN over all involved servers. This can potentially handicap the 316 usability of the applications. 318 In this case, it would be desirable to have a standardized SDP 319 protocol that can be used by the applications to interface with the 320 networks. Through this protocol, the applications should be able to 321 assign VLAN values to the appropriate VM sessions over all servers, 322 and interface with the connected networks to balance the traffic 323 load if necessary. 325 5.2. Inter-data center transport 327 +------------+ 328 +----------------------| |-----------------------+ 329 | +-------------| |-------------+ | 330 | | +-----| SDN |----+ | | 331 | | | | Controller | | | | 332 | | | +------------+ | | | 333 | | | | | | 334 | | | ^^^^^^ | | | 335 | | | ( ) | | | 336 +------+ +---+ +----+ ( ) +----+ +---+ +------ 337 + 338 |Server|---|TOR|---|Core|---( Backbone )---|Core|---|TOR|--- 339 |Server| 340 +------+ +---+ +----+ ( ) +----+ +---+ +------ 341 + 342 ( ) 343 Data Center vvvvvv Data Center 344 #1 #2 346 Figure 4: Inter-data center transport 348 When transporting data between data centers, the packets will be 349 encapsulated into one or multiple tunnels before sending over the 350 Internet. Traffic engineering is typically applied at tunnel-level. 351 For instance, user IP packets at servers may be encapsulated first 352 into a VLAN tunnel, and then aggregated into MPLS LSP's at the core 353 node. 355 In this case, it would be desirable of having a SDN controller to 356 coordinate the aggregation procedure. The controller is responsible 357 for determining the mapping of the VLAN's to the MPLS LSP's. 358 Further, it is possible that the controller can interface with the 359 core node to adjust the LSP bandwidth. 361 5.3. VPN 363 Another use case is VPN, as shown in Figure 5. 365 +----------+ 366 +------+ | SDN | 367 |Office| +--|Controller|-------+ 368 | A |----+ | +----------+ | 369 +------+ | ^^^^^^^^ | | | 370 +----+ ( ) +----+ +------+ +-------+ 371 | CE |---( Backbone )---| PE |----|Switch|---|Servers| 372 +----+ ( ) +----+ +------+ +-------+ 373 +------+ | vvvvvvvv 374 |Office| | Data Center X 375 | B |----+ 376 +------+ 378 Figure 5: VM Groups to MPLS VPN Mapping 380 At application level, the service providers may initiate a set of 381 VM's for a specific enterprise. For service guarantee, it requires 382 all the VM's that may be distributed on various servers and data 383 centers to be mapped to the same MPLS (L2)VPN. 385 There are multiple ways in achieving this goal. One is to utilize a 386 centralized SDN Controller to coordinate the mapping. 388 5.4. VM Mobility 390 VM mobility is to move one or multiple VM instances from one data 391 centers to another without disturbing the user existing setting and 392 applications. Once again, there are many ways to achieve such 393 objective. 395 Traditionally, the operators may create network tunnels between 396 routers/switches in the data centers, and switch VM traffic over the 397 tunnels. However, a more effective solution is to create a logical 398 controller between hypervisors to perform the VM mobility operator. 400 In the context of SDN, SDN controller can be used to coordinate the 401 hypervisors and the underlying network. It can provide the 402 efficiency in managing the VM's, while making the best use of the 403 underlying network resources. 405 6. Security Consideration 407 TBD 409 7. IANA Considerations 411 This document has no actions for IANA. 413 8. Normative References 415 [1] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 419 Syntax Specifications: ABNF", RFC 2234, Internet Mail 420 Consortium and Demon Internet Ltd., November 1997. 422 9. Acknowledgments 424 This work is based on the conversation with many people, including 425 Thomas Nadeau, Lydon Ong and Benson Schliesser. 427 Authors' Addresses 429 Ping Pan 430 Email: ppan@infinera.com 432 Thomas Nadeau 433 Email: Thomas.nadeau@ca.com