idnits 2.17.1 draft-pan-sdn-dc-problem-statement-and-use-cases-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2012) is 4426 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) == Unused Reference: 'RFC2234' is defined on line 586, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pan 3 Internet-Draft 4 Intended status: Standards Track T. Nadeau 5 Expires: September 12, 2012 6 March 11, 2012 8 Software-Defined Network (SDN) Problem Statement and Use Cases for Data 9 Center Applications 10 draft-pan-sdn-dc-problem-statement-and-use-cases-02.txt 12 Abstract 14 Software Defined Network (SDN) is an overlay architecture that 15 presents the underlying transport network to the applications and 16 services for monitoring, and provisioning at abstraction level. 18 In this memo, we outline some of the problems, and present an 19 architecture outline. We will present a few applications to validate 20 the problems and the architecture framework. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. The Problem Definition . . . . . . . . . . . . . . . . . . . . 5 65 3.1. The Architecture . . . . . . . . . . . . . . . . . . . . . 7 66 3.2. Use Case Summary . . . . . . . . . . . . . . . . . . . . . 8 67 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. Bandwidth on Demand . . . . . . . . . . . . . . . . . . . 9 69 4.2. Virtual Data Center . . . . . . . . . . . . . . . . . . . 10 70 4.3. Virtual Data Center . . . . . . . . . . . . . . . . . . . 12 71 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 Service providers and enterprises are increasingly offering services 80 and applications from data centers. When the applications and 81 services are offered from a group of data centers, they would require 82 extensive support from the underlying IP networks. 84 Software Defined Network (SDN) is an overlay architecture that 85 presents the underlying transport network to the applications and 86 services for monitoring, and provisioning at abstraction level. 88 The concept of SDN has been controversial: some envision that the 89 deployment of SDN would simplify network operation and system 90 requirements, and thereby reduce overall networking cost. On the 91 other hand, some argue that SDN is adding nothing new in terms of 92 network operation, as SNMP, NetConf and many existing protocols could 93 be equally effective. 95 We argue that the value in SDN is above and beyond network operation 96 and equipment cost reduction. SDN is a part of network service 97 evolution. 99 Traditionally, telephone companies have retained the control of 100 voice, video and leased line services. With the emergence of the 101 Internet, the ISPs can trump all those services by leveraging the 102 technology advancement in Ethernet, packet switching and IP routing, 103 and offer VoIP, CDN and VPN services to the end-users at much reduced 104 cost. 106 The emergence of cloud-based computing has once again changed the 107 networking service models. Essentially, cloud computing is to 108 utilize centralized processing, storage and computing to create a new 109 service layer on top of the network. The services can be modeled as 110 IaaS, PaaS and SaaS etc. Interactive services (which combines voice, 111 video and data) could replace separated voice (e.g. phone) and video 112 (e.g. TV) services. Enterprise services through private cloud may 113 replace the traditional ISP-initiated VPN's. Much of the mobile 114 services, which have traditionally been run by the network service 115 providers, could be realized by application providers over IP/LTE 116 networks. This change has been validated by service offerings from 117 Google, Amazon and Apple in recent years, and likely will continue to 118 proliferate in years to come. 120 Consequently, the cloud-based services are driving the networking 121 traffic demand. It requires the networking resources to be available 122 in anywhere and anytime. As far as the cloud service providers are 123 concerned, networking is an an utility business. It makes no 124 difference on network types (circuit or packet) and networking 125 technologies (Ethernet, IP or MPLS), as long as the network can 126 reliably transport user data at competitive price. 128 Within this framework, SDN plays the role of enabling cloud service 129 providers to have an uniformed application interface to the 130 underlying networks, so that they can optimize the use of the 131 networking resources. 133 Note that, SDN does not imply the following: 135 1. Data center management: There has been multiple approaches in 136 constructing data centers network fabric (e.g. Q-Fabric, PBB 137 E-VPN, etc.). SDN does not define and dictate the data center 138 interior architecture and management. Instead, SDN is to 139 interface with the data centers to make the use of the network 140 resources. 142 2. Storage and computing management: Cloud services can be roughly 143 divided in storage, computing and networking. SDN is only 144 responsible for the networking portion. 146 3. Direct network operation: SDN is a technical solution that 147 enables the cloud service providers to provision network 148 resources from the application layer. The operation itself must 149 subject to proper business arrangement between data center and 150 network service providers. The SDN resource programming can only 151 take place on abstract level. 153 In this document, we will articulate the issues and present a general 154 architecture in SDN through a number of user cases. 156 2. Related Work 158 There has been much work in this area over the years. 160 OpenFlow has pioneered the concept of software-defined network via 161 FlowVisor. It has introduced a new packet forwarding methodology to 162 be applied on hardware or software L2 switches. OpenFlow Version 1.0 163 have been in deployment in VM hypervisor environment. OpenFlow 164 Version 1.2 has been recently released where it has introduced the 165 concept of "virtual interface" for aggregating multiple packet flows. 166 The subsequent new versions will address issues such as 167 extendibility, modularity and carrier-grade. 169 NETCONF/YANG provides a XML-based solution for network device 170 configuration. It has been in wide-deployment. By definition, it 171 supports server-to-client configuration, but not client-to-server 172 alarms or feedback. 174 ALTO is a server solution designed to gather network abstraction 175 information and interface with applications (such as P2P) for more 176 efficient traffic distribution. It does not require configuring the 177 underlying network devices. 179 PCE is a client-server protocol that operates in MPLS networks that 180 enables the network operators to compute and potentially provision 181 optimal point-to-point and point-to-multipoint connections. However, 182 PCE does not interface with applications to optimize traffic from 183 user applications. 185 3. The Problem Definition 187 As mentioned before, SDN is an overlay architecture that presents the 188 underlying transport network to the applications and services for 189 monitoring, and provisioning at abstraction level. 191 The the existing network does not have a clean interface to the 192 applications. Figure 1 illustrates the relationship between 193 application and network today, where the applications have little or 194 fragmented knowledge, control of or visibility of underlying networks 195 and resources. 197 +-------------+ +-------------+ +-------------+ 198 | Application | | Application | | Application | 199 | #1 | | #2 | | #3 | 200 +-------------+ +-------------+ +-------------+ 201 | | | 202 | | | 203 +---------------------------------------------------+ 204 | Physical Network | 205 +---------------------------------------------------+ 207 Figure 1: Application to network relationship today 209 This presents a number of challenges and problems. 211 First, due to the lack of correlation, it becomes difficult to 212 provide service guarantees at network-level (in particular, delay) to 213 the applications. The operators may over-provision network links to 214 overcome to potential network congestion and packet drop within data 215 centers. However, such practice may become unpredictable and costly 216 in many networking scenarios. 218 Second, many services require the interface and interaction with 3rd 219 party back-end applications that may operate from remote locations 220 (such as ads networks). This requires the service operators to 221 constantly monitor the SLA conditions with remote applications, and 222 adjust the network resources if necessary. 224 Third, many data center applications (such as VM) require massive 225 user data replication on different sites for performance and 226 redundancy purposes. Also, due to the limitation in routing and load 227 balancing, much user traffic may be routed between data centers. As 228 such, the inter-data center data transport need to be efficient, 229 which requires the proper interface between applications and network. 231 Finally, to scale up enterprise applications on data centers, the 232 VM's may locate on different data centers, and mirage between data 233 centers depending on capacity and other constraints. This requires 234 the collaboration between VM applications and the underlying 235 networks. 237 SDN is to solve the above inefficiency, as envisioned in Figure 2. 238 It is to enable the applications to visualize the traffic flows at IP 239 network layer, and manage the mapping or binding between user traffic 240 flows to the network connections from the edge of the networks. 242 +-------------+ +-------------+ +-------------+ 243 | Application | | Application | | Application | 244 | #1 | | #2 | | #3 | 245 +-------------+ +-------------+ +-------------+ 246 | | | 247 | | | 248 +---------------------------------------------------+ 249 | SDN Layer | 250 | (Network virtualization, programmability | 251 | and Monitoring) | 252 +---------------------------------------------------+ 253 | | | 254 | | | 255 +---------------------------------------------------+ 256 | Physical Network | 257 +---------------------------------------------------+ 259 Figure 2: SDN-enabled network 261 In summary, SDN is to provide the applications with the following 262 capabilities: 264 1. The ability to retrieve the underlying topology. 266 2. The ability to monitor underlying network conditions, such as 267 failure etc. 269 3. The ability to initiate and adjust network connections/tunnels. 271 4. The ability for the applications to create services on top of the 272 provisioned network connections directly 274 3.1. The Architecture 276 Specifically, the SDN architecture may be constructed as the 277 following: 279 +---------------------------+ 280 | Applications and Services | 281 +---------------------------+ 282 | 283 | 284 +----------------------+ +---------------------+ 285 | SDN Service Mediator |<------>| Network Topology | 286 +----------------------+ | & Resource Database | 287 ^ | ^ +---------------------+ 288 | | | 289 +----------+ | +-------------+ 290 | | | 291 | \|/ | 292 +-----------+ +--------------+ +------------+ 293 | Discovery | | Network | | Monitoring | 294 +-----------+ | Provisioning | +------------+ 295 +--------------+ 297 Figure 3: Proposed SDN Architecture 299 o SDN Service Mediator: This is a logical server that coordinates 300 applications and networks. It may expand into multiple physical 301 servers in different locations. One may imagine the Service 302 Mediator as an Apache-based web servers, with task scheduling and 303 redundancy functions. The Service Mediator may be owned by the 304 network service providers to serve application providers. Or the 305 application providers may deploy Service Mediator to control 306 traffic over multiple networks. 308 o Discovery: This is a process controlled by Service Mediator, but 309 deployed to users or devices, in the form of applications or VM's. 311 It enables the SDN users to discover and register to the Service 312 Mediator. As a part of the discovery process, the SDN users may 313 negotiate capabilities with the service mediator. Some of the 314 common discovery mechanisms could be a DNS extension (in which 315 case, Service Mediator is simply a url for the users to contact), 316 or as simple as IMPP messages. 318 o Network Provisioning: This the process that allows the Service 319 Mediator to provision the underlying network resources. There are 320 many ways to provision the networks, depending on the 321 applications. For simple VLAN switching and aggregation, OpenFlow 322 1.2 may be sufficient. But for more sophisticated networking 323 technologies, such as MPLS and GMPLS, the Service Mediator needs 324 to input a range of attributes to the network (edge) devices in 325 the form of NetConf or other protocols to create or adjust traffic 326 engineering connections. 328 o Monitoring: This is an important function in SDN. This allows the 329 Service Mediator to interface with the underlying network to 330 gather network topology information at abstract level, and detect 331 the network failures that may impact the applications and 332 services. 334 o Network Topology Database: This is a part of the inventory 335 management that service/application providers maintain. This is 336 an important part of the SDN-enabled network operation. 338 o SDN North-Bound Interface: SDN Service Mediator is to provide the 339 RESTful API's to the applications/services. The API interface 340 should be at abstract level and application-friendly. 342 3.2. Use Case Summary 344 In the remaining of the document, we will outline a number of 345 potential SDN applications that can be implemented with the 346 architecture outlined above. 348 1. Bandwidth on Demand: In this application, the applications will 349 provision one or multiple physical links, and construct an 350 overlay network for one or a group of users. The provisioning 351 sequence requires the setup, change or deletion of network 352 connections/tunnels on network devices. This application is also 353 known as 'network slicing'. 355 2. Virtual Data Center: The data center servers may virtualize 356 applications, processors and devices for the end users. The 357 virtual machines may be located on multiple data centers over IP 358 networks. For performance and reliability reasons, the traffic 359 from the virtual machines need to be inter-connected or 360 aggregated over the network connections/tunnels that have been 361 discovered and provisioned through SDN. 363 3. L3 Virtualization: L2 virtualization does not scale. Through the 364 coordination of SDN Service Mediator, the virtual machines may 365 interconnect each other through IP routing protocols directly. 367 4. Use Cases 369 4.1. Bandwidth on Demand 371 In this use case, we show the relevant SDN components for clarity, 372 and suggest some of the possible implementation approaches. 374 +---------------------------+ 375 | Applications and Services | 376 +---------------------------+ 377 | 378 (1) | 379 +----------------------+ (2) +---------------------+ 380 | SDN Service Mediator |<------>| Network Topology | 381 +----------------------+ | & Resource Database | 382 | ^ +---------------------+ 383 | | 384 (3) | +-------------+ 385 | | (7) 386 \|/ | 387 +--------------+ +------------+ 388 | Network | | Monitoring | 389 | Provisioning | +------------+ 390 +--------------+ ^ 391 | (6) | 392 (4)| +-----------------+ 393 | | 394 +--------------+ 395 | Router or | (5) 396 | Switch |=========( IP Networks ) 397 +--------------+ 399 Figure 4: Support of Bandwidth-on-Demand 401 As an illustration, shown in Figure 4, the application needs to 402 create a MPLS connection with certain bandwidth on one of the inter- 403 data center links. Since it is aggregating traffic from a large 404 number of virtual machines, it needs to be notified in event of 405 network failure. 407 Here could be the sequence of events: 409 1. Through the RESTful API interface, the Service Mediator receives 410 the request from applications. 412 2. The Service Mediator will query the network inventory database to 413 select the proper link and network device for provisioning. For 414 argument sake, the Service Mediator could act as a PCE server, 415 and compute the proper MPLS-TE ERO for the connection. 417 3. Upon the completion of the path computation, the Service Mediator 418 will initiate the provisioning commands to the Provisioning 419 Engine. 421 4. Through provisioning protocols (such as, PCE or NetConf or 422 OpenFlow), the Provisioning Engine propagates the commands to the 423 actual switches and routers. 425 5. The routers (or switches) will utilize the MPLS control-plane 426 protocols to interface with other nodes in the network and 427 complete the connection setup. 429 6. At some point, a unrecoverable failure has occurred in the 430 network. The Monitoring Engine will pick up the failure 431 condition and compress the alarms. 433 7. The Monitoring Engine will notify the Service Mediator, which in 434 turn will inform the corresponding applications and services. 436 There are a number of variations here>: 438 o The underlying network could be an optical network running GMPLS. 439 The same sequence would apply for setting up large inter-data 440 center links. 442 o The enterprise network may not use IP routers. A similar sequence 443 could apply on multiple network nodes to perform manual VLAN 444 cross-connects. The provisioning protocol could be OpenFlow. 446 4.2. Virtual Data Center 448 The idea here is to construct an overlay network for a group of 449 users. Each user is represented by an individual virtual machine. 450 All users in the same group will share a common network 451 identification (such as VLAN). 453 When the users communicate among each other, they should not be aware 454 of the underlying networks. This requires the SDN to aggregate the 455 user traffic over a selected set of network connections, which should 456 provide adequate delay and bandwidth guarantees. 458 In Figure 5, we will illustrate a simple use case: 460 +---------------------------+ 461 | Applications and Services | 462 +---------------------------+ 463 | 464 | 465 +----------------------+ +---------------------+ 466 | SDN Service Mediator |<------>| Network Topology | 467 +----------------------+ | & Resource Database | 468 ^ | ^ +---------------------+ 469 | | | 470 +----------+ | +-------------+ 471 | | | 472 | \|/ | 473 +-----------+ +--------------+ +------------+ 474 | Discovery | | Network | | Monitoring | 475 +-----------+ | Provisioning | +------------+ 476 +--------------+ 477 | | | | 478 +----+ | | +----------------------------+ 479 | | +---------------------+ | 480 | | ^^^^^^ | | 481 | | ( ) | | 482 +------+ +---+ +----+ ( ) +----+ +---+ +------+ 483 |Server|---|TOR|---|Core|---( Backbone )---|Core|---|TOR|---|Server| 484 +------+ +---+ +----+ ( ) +----+ +---+ +------+ 485 ( ) 486 Data Center vvvvvv Data Center 487 #1 #2 489 Figure 5: Support of Virtual Data Center 491 This use case is very similar to that of Bandwidth-on-Demand. The 492 general operation sequence would be: 494 o The Service Mediator interfaces with network edge nodes, and 495 provisions the network tunnels. 497 o When the application is to setup a logical connection between two 498 virtual machines, the Service Mediator will identify the user 499 network identification (e.g. VLAN or VXLAN), select the network 500 tunnel to use. 502 o Fianlly, through Service Mediator, the application is to program 503 the ToR switches and initiate the logical connections. All 504 virtual machine traffic will be aggregated through selected 505 network connections for latency and bandwidth guarantees. 507 This application is new, and much new signaling protocols have been 508 proposed and studied. 510 4.3. Virtual Data Center 512 Due to historic reasons, much of the networking virtualization is 513 through the use of L2 technology. Consequently, the applications are 514 experiencing sever scalability problems. Many recent proposals have 515 been focused in making the L2 technology more scalable, including 516 extending the VLAN range. Many hypervisors are positioned to run L3- 517 over-L2-over-L3. 519 We argue that to solve the virtual machine scaling problems, we 520 should introduce L3 virtualization. 522 Here, we introduce a method in supporting L3 virtualization using 523 SDN: 525 +---------------------------+ 526 | Applications and Services | 527 +---------------------------+ 528 | 529 | 530 +----------------------+ 531 | SDN Service Mediator | 532 +----------------------+ 533 ^ | ^ 534 | | | 535 +----------+ | +-------------+ 536 | | | 537 | \|/ | 538 +-----------+ +-------------+ +------------+ 539 | BGP | | BGP | | BGP | 540 | Signaling | | Signaling | | Signaling | 541 | GW | | GW | | GW | 542 +-----------+ +-------------+ +------------+ 543 | | | | | | 544 | +---+ | | +---+ | 545 | | | | | | 546 +----+ +----+ +----+ +----+ +----+ +----+ 547 | VM | | VM | | VM | | VM | | VM | | VM | 548 +----+ +----+ +----+ +----+ +----+ +----+ 550 Figure 6: Support of L3 Virtualization 552 The idea is that the users (in VMs) may trigger the discovery 553 process, and connect to BGP gateways when connecting to other users. 554 The SDN Service Mediator is to correlate the routing information 555 among BGP GW's. 557 Much of the processing details can be found in 'BGP-signaled end- 558 system IP/VPNs' 559 (http://www.ietf.org/id/draft-marques-l3vpn-end-system-05.txt) 561 There are a number of key advantages in this approach. 563 1. It scales: compare with the existing L2 solutions, this runs at 564 IP layer. 566 2. Reuse much of the existing and proven routing techniques. The 567 underlying solution is identical to that of MPLS VPN that has 568 been in wide deployment for years. 570 3. Application-friendly interface through SDN 572 5. Security Consideration 574 6. IANA Considerations 576 7. Acknowledgments 578 This work is based on the interaction with many people. Thanks 579 Pedro, Lyndon, Shane and Matt. 581 8. Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 587 Specifications: ABNF", RFC 2234, November 1997. 589 Authors' Addresses 591 Ping Pan 592 (Infinera) 594 Email: ppan@infinera.com 596 Thomas Nadeau 597 (CA) 599 Email: thomas.nadeau@ca.com