idnits 2.17.1 draft-nadeau-sdn-problem-statement-00.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 (September 30, 2011) is 4593 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Nadeau 3 Internet-Draft CA Technologies, Inc. 4 Intended status: Informational 5 Expires: March 12, 2012 7 September 30, 2011 9 Software Driven Networks Problem Statement 10 draft-nadeau-sdn-problem-statement-00 12 Abstract 14 Software Driven Networks (SDN) is an approach to networks that 15 enables applications to converse with and manipulate the control 16 software of network devices and resources. SDNs are comprised of 17 applications, control software, and interfaces to services that 18 are hosted in an overlay or logical/virtual network as well as 19 those possibly same components that comprise the underlying 20 physical network. Modern applications require the ability 21 to easily interact and manipulate these resources. Applications can 22 benefit from knowing the available resources and from requesting 23 that the network makes the resources available in specific ways. 24 To this end, there is a requirement to couple applications more 25 closely to the underlying resources on which they depend, consume 26 and interact with. 28 SDN infrastructure and components exist in most deployed networks 29 today. Some of these components are being standardized by various 30 organizations, as as well some being already standardized by the 31 IETF. However, no standards or open specifications currently exist 32 to facilitate end-to-end operation of a software defined network, 33 specificlly one that provides open APIs for applications to control 34 the network services and functions offered by device control planes 35 or other "controlling" software. The goal of this document is to 36 outline the problem area of SDN for the IETF. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of this Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 SDN Problem Statement September 30, 2011 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 30, 2012. 63 Copyright Notice 65 Copyright (c) 2011 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . .. . 5 81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . .. . 5 82 1.2. SDN Background . . . . . . . . . . . . . . . . . . . .. . 9 83 2. SDN Interconnect Use Cases . . . . . . . . . . . . . . . .. . 9 84 3. SDN Interconnect Model & Problem Area for IETF . . . . . .. . 11 85 3.1. Candidate SDN Problem Area for IETF . . . . . . . . . . . 13 86 4. Design Approach for Realizing the SDN APIs . . . . . . . . . 15 87 4.1. Relationship to the OSI network model . . . . . . . .. . 15 88 4.2. "Reuse Instead of Reinvent" Principle . . . . . . . .. . 16 89 4.3. Application to SDN Orchestrator Interface . . . . . . . . 16 90 4.4. SDN Orchestrator to Plug-In Interface . . . . . . . . . . 18 91 4.5. SDN Logging Interface . . . . . . . . . . . . . . . . . . 19 92 4.6. SDN Orchestrator to Location Services Interface . . . . . 20 93 4.7. SDN Orchestrator to Policy Database Interface . . . . . . 20 94 4.8. SDN Orchestrator to SDN Orchestrator Interface. . . . . . 20 96 5. Gap Analysis of relevant Standardization and Research 97 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 SDN Problem Statement September 30, 2011 100 5.1. Open Network Forum . . . . . . . . . . . . . . . . . . . . 21 102 6. Relationship to relevant IETF Working Groups . . . . . . . . . 23 103 6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 109 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 110 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 29 111 A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 29 112 A.2. Prioritizing the SDN Work . . . . . . . . . . . . . . . . 30 113 A.3. Related standardization activities . . . . . . . . . . . . 31 114 A.4. Related Research Projects . . . . . . . . . . . . . . . . 35 115 A.4.1. IRTF Cross Stratum Optimizaiton Research Group . . . . 35 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 118 1. Introduction 120 Software Driven Networks (SDN) is an approach to networks that 121 enables applications to converse with and manipulate the control 122 software of network devices and resources. Modern applications 123 require the ability to easily interact and manipulate resources 124 provisioned and controlled by networks. Applications can benefit 125 from knowing the available resources and from requesting that the 126 network makes the resources available in specific ways. 128 To this end, there is a requirement to couple applications more 129 closely to the underlying resources on which they depend, consume 130 and interact with. In particular, modern applications require 131 interaction with and the manipulation of both physical and virtual 132 compute, storage and connectivity resources and abstract interfaces 133 to these things. These abstractions must also allow applications to 134 manipulate resources at varying levels of granularity, policy and 135 security. It is also worth noting that modern Software Driven 136 Networks (SDNs) are comprised of applications, control 137 software, and interfaces to services that are hosted in an overlay 138 or logical/virtual network as well as those possibly same 139 components that comprise the underlying physical network. 141 These services include path computation, topology discovery, 142 firewall services, domain name services, network address 143 translation services, virtual private networks and the like. These 144 services and elements may be physical or virtual. 146 One requirement is to create a means by which applications can 147 SDN Problem Statement September 30, 2011 149 communicate with the control planes of the underlying network 150 devices or entities which control and own network resources on 151 which they depend. Note that the "control planes" of network 152 devices will be referred to as "controlling software" to abstract 153 away the concept of the software that controls a device's data 154 plane. The control planes of devices, whether physically co-located 155 with a device and its data plane, or externally located for 156 example in the case of an OpenFlow "controller", provide coherent 157 control of the network apparatus. However, the "controlling 158 software" of a virtual machine might be a hypervisor. There is a 159 desire by network operators and service providers to control, 160 configure, mange or set policy on controlling software and do so 161 using applications for different network control and manipulation 162 options. 164 Software Defined Networks infrastructure exists in most deployed 165 networks today. Some of these components are being standardized by 166 various organizations, as as well some being already standardized 167 by the IETF. However, no standards or open specifications 168 currently exist to facilitate end-to-end operation of a software 169 defined network, specificlly one that provides open APIs 170 for applications to control the network services and functions 171 offered by device control planes or other "controlling" software. 172 The goal of this document is to outline the problem area of SDN for 173 the IETF. 175 Section 2 discusses the use cases for SDN. Section 3 176 presents the SDN model and problem area to be considered by the 177 IETF. Section 4 discusses how existing protocols can be reused to 178 define the SDN interfaces, service discovery and object models. 180 1.1. Terminology 182 This document uses the following terms: 184 Control Plane: In a router or switch, the control plane is the 185 part of the router firmware/software architecture that is in charge 186 of the logic behind things such as constructing a map of the network 187 topology, running network protocols or management functions and 188 then ultimately instructing the device's data plane to realize 189 any forwarding or switching actions that must be enabled. While 190 conceptually separate in a logical sense, the control plane is 191 often physically separated from the data plane of a device either 192 by running on a processor dedicated to this function, or even run 193 externally from the device on another device or process (i.e.: 194 in the case of OpenFlow, centralized routing, etc...). 196 Data Plane: This is the part of a network device that is responsible 197 SDN Problem Statement September 30, 2011 199 for the actual (i.e.: physical) forwarding and manipulation of 200 data that comes into and is transmitted out of a device. The 201 data plane of a device is typically very tightly bound to the 202 specific nature of the hardware of that particular forwarding 203 component of a device, and as such is often kept seperated from 204 the more generic control plane. An example of a data plane 205 would be the switching fabric and port processors of a router. 207 Controlling Software: In the case of network devices, this is 208 analagous to the control plane. However, in the case of 209 virtualization technologies, this may be present in the form of 210 a hypervisor, for example. 212 Application Programming Interface (API): is a particular set 213 of rules and specifications that software programs can follow 214 to communicate with each other. It serves as an interface between 215 different software programs and facilitates their interaction, 216 similar to the way the user interface facilitates interaction 217 between humans and computers. 219 Software As a Service (SaaS): Sometimes referred to as 220 "on-demand software," is a software delivery model in which 221 software and its associated data are hosted by a service provider 222 and connected back to the customer via The Internet. These 223 are sometimes referred to as "cloud services" as well. 225 Managed Network Service Provider (MSP): Provides network-based 226 connectivity and services to End Users, as well a managed 227 service. For example, one popular MSP might offer virtualized 228 machines (VMs) and a virtual private network (VPN) connectivity 229 between these VMs with external connectivity to this VPN 230 of machines via a managed business grade metro ethernet link 231 to the customer's premise. 233 Communications Service Provider (CSP): A traditional "telco" 234 service provider that offers data connectivity as a service 235 to its customers. 237 1.2. SDN Background 239 Readers are assumed to be familiar with the architecture, features 240 and operation of SDNs. For readers less familiar with the operation 241 of SDNs, the following resources may be useful: 243 [Provide references TBD] 244 SDN Problem Statement September 30, 2011 246 2. SDN Use Cases 248 An increasing number of MSPs are deploying SDNs in order to 249 both offer more cost-effective service offerings, but also 250 to reduce internal costs of managing and operating those 251 services. 253 Since SDNs allow for a more consistent and shorter time-to-market 254 model of developing management software for various network-based 255 services, service providers are moving towards using various 256 proprietary schemes for this. SDNs are being used to deliver 257 various types of services that provide externally consumable 258 SaaS offerings, as well as those used internally to manage and 259 manipulate their network infrastructure. 261 Some MSPs operate over multiple geographies and couple infrastructure 262 from different MSPs, SPs and possibly SaaS offerings. In these 263 cases, it is important to provide the MSP that offers the ultimate 264 service to the customer with a clean, consistent and effient 265 interface to all of the infrastructure it relies on. Furthermore, 266 from their perspective, being able to unwind the "russian doll" 267 of nested infrastructure and services that might be rolled together 268 for their service offering in cases where trouble shooting is 269 required for example, is paramount. 271 In the simplest of cases it may not seem obvious that the use of 272 a standardized SDN infrastructure would be necessary; however, 273 in typical medium and large data center offerings that are quite 274 common today, the management of the physical elements is a small 275 part of the larger puzzle for the MSP or CSP. When network elements 276 become virtualized and are then used to construct components of 277 services being offered, an operator can quickly multiply the number 278 of management "devices" or more commonly "elements", by many orders 279 of magnitude. It is here that the problem of lack of open interfaces 280 for SDN component interconnection and discovery becomes clear. 282 Again, for this requirement, SDN operators 283 (over-the-top SDN operators or NSPs) are faced with a lack of open 284 specifications and best practices. 286 Use cases for SDN Interconnection are further discussed in 288 3. SDN Model & Problem Area for The IETF 290 Managing a network of deployed SDN components involves interactions 291 among multiple different functions and components that exist within 292 the network. Some of these components are virtual and some of these 293 SDN Problem Statement September 30, 2011 295 components are real; all should be made available to be managed and 296 manipulated, given the appropriate access, authentication, and policy 297 hurdles have been crossed. Only some of those 298 require standardization. The SDN model and problem area proposed 299 for IETF work is illustrated in Figure 1. The candidate problem area 300 (and respectively the non-goals) for IETF work are shown in Figure 2. 302 |--------Application 303 v ^ 304 +----------+ | 305 | Location | | <--- Application-to- 306 | Services | | Ochestrator protocol 307 +----------+ v 308 ^ ReST API 309 | +-------------------+ +------------------+ 310 |----| Orchestrator_0..N + -----> | Policy Data Base | 311 +-------------------+ +------------------+ 312 ^ 313 | <--- Orchestrator-to-Plug-In Protocol 314 | 315 V 316 +----------+ 317 | Plug-In | 318 | ReST API | 319 +----------+ 320 ^ 321 * 322 V 323 +******************+ 324 * Control Software * 325 * For Device_0..M * 326 +******************+ 327 ^ 328 = 329 V 330 +=================+ 331 = Data Plane = 332 = For Device_0..M = 333 +=================+ 335 <--> interfaces and objects inside the scope of SDN 336 +--+ 338 <**> interfaces and objects may be within the scope of SDN 339 +**+ insofar as modifcations are needed to support SDN 340 SDN Problem Statement September 30, 2011 342 <==> interfaces and objects outside the scope of SDN 343 +==+ 345 Figure 1: SDN Problem Area 347 3.1. Candidate SDN Problem Area for IETF 349 Listed below are the the interfaces required to connect 350 an application with the SDN components and protocols in a network. 351 This constitutes the problem space that is proposed to be 352 addressed by a potential SDN working group in the IETF. The use of 353 the term "interface" is meant to encompass the protocol over which 354 SDN data representations (e.g. SDN Metadata records) are exchanged 355 as well as the specification of the data representations themselves 356 (i.e. what properties/fields each record contains, its structure, 357 etc.). 359 o SDN Orchestrator-to-Application Interface: This interface allows 360 the SDN Orchestrator or "controller" system to be interconnected 361 with applications. This interface may support the following: 362 * Allow bootstrapping of the interface between the Orchestrator 363 and interested applications. 364 * Allow the applications to authenticate. 365 * Allow applications to learn of which objects they have 366 authorization to manipulate, or to interact with objects 367 beloning to controlling software. 369 o SDN Orchestratort-to-Plug-In Interface: This interface allows 370 the SDN Orchestrator to interconnect with the controlling software 371 of devices. 373 o SDN Orchestratort-to-Policy Database Interface: This interface 374 allows the SDN Orchestrator to interconnect with policy, 375 authentication and authorization databases. 377 o SDN Orchestratort-to-location services Interface: This interface 378 allows the SDN Orchestrator to interconnect with location 379 services in order to: 380 * Register itself as a local Orchestrator. 381 * Allow other Orchestrators and applications to find it. 383 o SDN Orchestrator-to-SDN Orchestrator Interface: This interface 384 allows one SDN Orchestrator to interconnect with one or more 385 Orchestrators 386 in order to: 387 * Form a failover/high-availability relationship 388 * distribute mappings of controlling software-to-Orchestrator 389 SDN Problem Statement September 30, 2011 391 * bootstrapping of the other SDN Orchestrators. 392 * configuration of the other SDN Orchestrators. 394 o SDN Logging interface: This interface allows the Logging system 395 in interconnected SDN Orchestrators to communicate the relevant 396 activity logs in order to allow log consuming applications to 397 operate in multi-SDN Orchestrator environments. For example, 398 this interface can be used to collect logs from SDN 399 Orchestrators to provide reporting and monitoring to the M/CSP 400 of SDN activities. 402 As part of the development of the SDN interfaces and solutions it 403 will also be necessary to develop and agree on common mechanisms 404 for how to define the object schemas used to query object model 405 stores of each controlling software element. 407 4. Design Approach for Realizing the SDN APIs 409 This section expands on how SDN interfaces can reuse and leverage 410 existing protocols. First the "reuse instead of reinvent" design 411 principle is restated, then each inetrface is discussed individually 412 with example candidate protocols that can be considered for reuse or 413 leverage. This discussion is not intended to pre-empt any WG 414 decision as to the most appropriate protocols, technologies and 415 solutions to select to solve SDN but is intended as an illustration 416 of the fact that the SDN interfaces need not be created in a vacuum 417 and that reuse or leverage of existing protocols is likely possible. 419 4.1. Relationship to the OSI network model 421 The SDN interfaces called out above in Section 3.1 within the SDN 422 problem area all operate at the application layer (Layer 7 in the 423 OSI network model). Since it is not expected that these interfaces 424 would exhibit unique session, transport or network requirements as 425 compared to the many other existing applications in the Internet, it 426 is expected that the SDN interfaces will be defined on top of 427 existing session, transport and network protocols. 429 4.2. "Reuse Instead of Reinvent" Principle 431 Although a new application protocol could be designed specifically 432 for SDN we assume that this is unnecessary and it is recommended 433 that existing application protocols be reused or leveraged such 434 as HTTP[RFC2616] to devine the SDN interfaces. 436 4.3. Application to SDN Orchestrator Interface 438 4.4. SDN Orchestrator to Plug-In Interface 439 SDN Problem Statement September 30, 2011 441 4.5. SDN Logging Interface 443 The SDN Logging interface enables details of logs or events to be 444 exchanged between interconnected SDN Orchestrators, where events 445 could be: 447 o Log lines related to the connection of a new Orchestrator, or 448 disconnection of an existing one. 449 o A fail-over, switch-over event. Similarly, high-availability 450 synchronication messaging. 451 o Real-time or near-real time events before, during or after 452 SDN Orchestrator commands noting which application instructed 453 it to perform the operation. 454 o Operations and diagnostic messages. 456 Several protocols already exist that could potentially be used to 457 exchange SDN Orchestrator logs including SNMP Traps or Informs, 458 syslog, s/ftp, HTTP POST, or ReST, etc. although it is likely that 459 some of the candidate protocols may not be well suited to meet all 460 the requirements of SDN. For example SNMP Traps pose scalability 461 concerns, and syslog may have potential compatability issues. 463 Although it is not necessary to define a new protocol for exchanging 464 logs across the SDN Logging interface, a SDN WG would still need to 465 specify: 467 o The recommended protocol to use. 468 o A default set of log fields and their syntax & semantics. Today 469 there is no standard set of common log fields across different 470 content delivery protocols and in some cases there is not even a 471 standard set of log field names and values for different 472 implementations of the same delivery protocol. 473 o A default set of events that trigger logs to be generated. 475 4.6. SDN Orchestrator to Location Services Interface 477 4.7 SDN Orchestrator to Policy Database Interface 479 4.8 SDN Orchestrator to SDN Orchestrator Interface 481 5. Gap Analysis of relevant Standardization and Research Activities 483 There are a number of other standards bodies and industry forums that 484 are working in areas related to SDNs, and in some cases related to 485 SDN. This section outlines any potential overlap with the work of 486 the SDN WG and any component that could potentially be reused by 487 SDN Problem Statement September 30, 2011 489 SDN. 491 A number of standards bodies have produced specifications related to 492 SDNs, namely: 494 o Open Network Forum has a dedicated specification called Open Flow 495 which specifies a relationship to an external "control plane" 496 interfacing to a Hardware Abstraction Layer (HAL) that is 497 implemented on Open Flow-capable hardware. 499 6. Relationship to relevant IETF Working Groups 501 6.1. ALTO 503 As stated in the ALTO Working Group charter [ALTO-Charter]: 505 "The Working Group will design and specify an Application-Layer 506 Traffic Optimization (ALTO) service that will provide applications 507 with information to perform better-than-random initial peer 508 selection. ALTO services may take different approaches at balancing 509 factors such as maximum bandwidth, minimum cross-domain traffic, 510 lowest cost to the user, etc. The WG will consider the needs of 511 BitTorrent, tracker-less P2P, and other applications, such as content 512 delivery networks (SDN) and mirror selection." 514 In particular, the ALTO service can be used by an SDN-aware 515 application to improve its selection of an SDN Orchestrator. For 516 example, an application wishing to provision MPLS L3 VPNs on behalf 517 of some virtual machines in a local data center cluster may with 518 to take advantage of the ALTO service in its decision for 519 selecting a relatively close SDN Orchestrator to complete its 520 operations. 522 However, the work of ALTO is complementary to and does not overlap 523 with the work proposed in this document because the integration 524 between ALTO and a SDN would fall under the category of using 525 an existing protocol. One area for further study is whether 526 additional information should be provided by an ALTO service 527 to facilitate SDN Orchestrator selection. For example, loading 528 or fail-over characterists could be one consideration. 530 7. IANA Considerations 532 This document makes no request of IANA. 534 Note to RFC Editor: this section may be removed on publication as an 535 RFC. 537 SDN Problem Statement September 30, 2011 539 8. Security Considerations 541 SDNs comes with a range of security considerations such as how to 542 enforce control of and access to objects managed by the SDN 543 Orchestrators and making sure that in line with the M/CSP policy. 545 9. Acknowledgements 547 The authors would like to thank David Meyer, Ping Pan, Lyndon Ong, 548 Danny McPhereson for their review comments and contributions to the 549 text. 551 10. References 553 10.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 10.2. Informative References 560 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 561 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 562 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 564 [ALTO-Charter] 565 "IETF ALTO WG Charter 566 (http://datatracker.ietf.org/wg/alto/charter/)". 568 [Draft-Lee] L. Young, Bernstein, G., Kim, T., Shiomoto, K., and 569 Dios, O., 570 "Research Proposal for Cross Stratum Optimization (CSO) 571 between Data Centers and Networks", 572 draft-lee-cross-stratum-optimization-datacenter-00.txt 574 Appendix A. Additional Material 576 Note to RFC Editor: This appendix is to be removed on publication as 577 an RFC. 579 A.1. Non-Goals for IETF 581 Listed below are aspects of content delivery that the authors propose 582 be kept outside of the scope of a potential SDN working group: 583 o The interface between Controlling Software (i.e.: control plane) 584 and the device's data plane. 585 o Definition of any hardware abstraction layer (HAL) 586 SDN Problem Statement September 30, 2011 588 A.2. Prioritizing the SDN Work 590 A.3. Related standardization activities 592 A.4. Related Research Projects 594 A.4.1. IRTF Cross Stratum Optimizaiton Research Group 596 Some information on SDN motivations and technical motivations 597 in the IRTF's Cross Stratum Optimization Group [Draft-Lee]. 599 Authors' Addresses 601 Thomas D. Nadeau (editor) 602 CA Technologies, Inc. 603 273 Corporate Drive 604 Portsmouth, NH 03801 605 Email: thomas.nadeau@ca.com