idnits 2.17.1 draft-nadeau-sdn-problem-statement-01.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 (October 31, 2011) is 4523 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, Ed. 3 Internet-Draft CA Technologies, Inc. 4 Intended status: Informational 5 Expires: April 31, 2012 P. Pan, Ed. 6 Infinera 8 October 31, 2011 10 Software Driven Networks Problem Statement 11 draft-nadeau-sdn-problem-statement-01 13 Abstract 15 Software Driven Networks (SDN) is an approach to networks that 16 enables applications to converse with and manipulate the control 17 software of network devices and resources. SDNs are comprised of 18 applications, control software, and interfaces to services that 19 are hosted in an overlay or logical/virtual network as well as 20 those possibly same components that comprise the underlying 21 physical network. Modern applications require the ability 22 to easily interact and manipulate these resources. Applications can 23 benefit from knowing the available resources and from requesting 24 that the network makes the resources available in specific ways. 25 To this end, there is a requirement to couple applications more 26 closely to the underlying resources on which they depend, consume 27 and interact with. 29 SDN infrastructure and components exist in most deployed networks 30 today. Some of these components are being standardized by various 31 organizations, as as well some being already standardized by the 32 IETF. However, no standards or open specifications currently exist 33 to facilitate end-to-end operation of a software defined network, 34 specificlly one that provides open APIs for applications to control 35 the network services and functions offered by device control planes 36 or other "controlling" software. The goal of this document is to 37 outline the problem area of SDN for the IETF. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 Status of this Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 SDN Problem Statement October 31, 2011 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on September 30, 2012. 64 Copyright Notice 66 Copyright (c) 2011 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . .. . 5 82 1.1. Terminology . . . . . . . . . . . . . . . . . . . . .. . 5 83 1.2. SDN Background . . . . . . . . . . . . . . . . . . . .. . 9 84 2. SDN Interconnect Use Cases . . . . . . . . . . . . . . . .. . 9 85 3. SDN Interconnect Model & Problem Area for IETF . . . . . .. . 11 86 3.1. Candidate SDN Problem Area for IETF . . . . . . . . . . . 13 87 4. Design Approach for Realizing the SDN APIs . . . . . . . . . 15 88 4.1. Relationship to the OSI network model . . . . . . . .. . 15 89 4.2. "Reuse Instead of Reinvent" Principle . . . . . . . .. . 16 90 4.3. Application to SDN Orchestrator Interface . . . . . . . . 16 91 4.4. SDN Orchestrator to Plug-In Interface . . . . . . . . . . 18 92 4.5. SDN Logging Interface . . . . . . . . . . . . . . . . . . 19 93 4.6. SDN Orchestrator to Location Services Interface . . . . . 20 94 4.7. SDN Orchestrator to Policy Database Interface . . . . . . 20 95 4.8. SDN Orchestrator to SDN Orchestrator Interface. . . . . . 20 97 5. Gap Analysis of relevant Standardization and Research 98 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 SDN Problem Statement October 31, 2011 101 5.1. Open Network Forum . . . . . . . . . . . . . . . . . . . . 21 103 6. Relationship to relevant IETF Working Groups . . . . . . . . . 23 104 6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 107 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 109 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 110 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 111 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 29 112 A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 29 113 A.2. Prioritizing the SDN Work . . . . . . . . . . . . . . . . 30 114 A.3. Related standardization activities . . . . . . . . . . . . 31 115 A.4. Related Research Projects . . . . . . . . . . . . . . . . 35 116 A.4.1. IRTF Cross Stratum Optimizaiton Research Group . . . . 35 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 119 1. Introduction 121 Software Driven Networks (SDN) is an approach to networks that 122 enables applications to converse with and manipulate the control 123 software of network devices and resources. Modern applications 124 require the ability to easily interact and manipulate resources 125 provisioned and controlled by networks. Applications can benefit 126 from knowing the available resources and from requesting that the 127 network makes the resources available in specific ways. 129 To this end, there is a requirement to couple applications more 130 closely to the underlying resources on which they depend, consume 131 and interact with. In particular, modern applications require 132 interaction with and the manipulation of both physical and virtual 133 compute, storage and connectivity resources and abstract interfaces 134 to these things. These abstractions must also allow applications to 135 manipulate resources at varying levels of granularity, policy and 136 security. It is also worth noting that modern Software Driven 137 Networks (SDNs) are comprised of applications, control 138 software, and interfaces to services that are hosted in an overlay 139 or logical/virtual network as well as those possibly same 140 components that comprise the underlying physical network. 142 These services include path computation, topology discovery, 143 firewall services, domain name services, network address 144 translation services, virtual private networks and the like. These 145 services and elements may be physical or virtual. 147 One requirement is to create a means by which applications can 148 SDN Problem Statement October 31, 2011 150 communicate with the control planes of the underlying network 151 devices or entities which control and own network resources on 152 which they depend. Note that the "control planes" of network 153 devices will be referred to as "controlling software" to abstract 154 away the concept of the software that controls a device's data 155 plane. The control planes of devices, whether physically co-located 156 with a device and its data plane, or externally located for 157 example in the case of an OpenFlow "controller", provide coherent 158 control of the network apparatus. However, the "controlling 159 software" of a virtual machine might be a hypervisor. There is a 160 desire by network operators and service providers to control, 161 configure, mange or set policy on controlling software and do so 162 using applications for different network control and manipulation 163 options. 165 Software Defined Networks infrastructure exists in most deployed 166 networks today. Some of these components are being standardized by 167 various organizations, as as well some being already standardized 168 by the IETF. However, no standards or open specifications 169 currently exist to facilitate end-to-end operation of a software 170 defined network, specificlly one that provides open APIs 171 for applications to control the network services and functions 172 offered by device control planes or other "controlling" software. 173 The goal of this document is to outline the problem area of SDN for 174 the IETF. 176 Section 2 discusses the use cases for SDN. Section 3 177 presents the SDN model and problem area to be considered by the 178 IETF. Section 4 discusses how existing protocols can be reused to 179 define the SDN interfaces, service discovery and object models. 181 1.1. Terminology 183 This document uses the following terms: 185 Control Plane: In a router or switch, the control plane is the 186 part of the router firmware/software architecture that is in charge 187 of the logic behind things such as constructing a map of the network 188 topology, running network protocols or management functions and 189 then ultimately instructing the device's data plane to realize 190 any forwarding or switching actions that must be enabled. While 191 conceptually separate in a logical sense, the control plane is 192 often physically separated from the data plane of a device either 193 by running on a processor dedicated to this function, or even run 194 externally from the device on another device or process (i.e.: 195 in the case of OpenFlow, centralized routing, etc...). 197 Data Plane: This is the part of a network device that is responsible 198 SDN Problem Statement October 31, 2011 200 for the actual (i.e.: physical) forwarding and manipulation of 201 data that comes into and is transmitted out of a device. The 202 data plane of a device is typically very tightly bound to the 203 specific nature of the hardware of that particular forwarding 204 component of a device, and as such is often kept seperated from 205 the more generic control plane. An example of a data plane 206 would be the switching fabric and port processors of a router. 208 Controlling Software: In the case of network devices, this is 209 analagous to the control plane. However, in the case of 210 virtualization technologies, this may be present in the form of 211 a hypervisor, for example. 213 Application Programming Interface (API): is a particular set 214 of rules and specifications that software programs can follow 215 to communicate with each other. It serves as an interface between 216 different software programs and facilitates their interaction, 217 similar to the way the user interface facilitates interaction 218 between humans and computers. 220 Software As a Service (SaaS): Sometimes referred to as 221 "on-demand software," is a software delivery model in which 222 software and its associated data are hosted by a service provider 223 and connected back to the customer via The Internet. These 224 are sometimes referred to as "cloud services" as well. 226 Managed Network Service Provider (MSP): Provides network-based 227 connectivity and services to End Users, as well a managed 228 service. For example, one popular MSP might offer virtualized 229 machines (VMs) and a virtual private network (VPN) connectivity 230 between these VMs with external connectivity to this VPN 231 of machines via a managed business grade metro ethernet link 232 to the customer's premise. 234 Communications Service Provider (CSP): A traditional "telco" 235 service provider that offers data connectivity as a service 236 to its customers. 238 1.2. SDN Background 240 Readers are assumed to be familiar with the architecture, features 241 and operation of SDNs. For readers less familiar with the operation 242 of SDNs, the following resources may be useful: 244 [Provide references TBD] 245 SDN Problem Statement October 31, 2011 247 2. SDN Use Cases 249 An increasing number of MSPs are deploying SDNs in order to 250 both offer more cost-effective service offerings, but also 251 to reduce internal costs of managing and operating those 252 services. 254 Since SDNs allow for a more consistent and shorter time-to-market 255 model of developing management software for various network-based 256 services, service providers are moving towards using various 257 proprietary schemes for this. SDNs are being used to deliver 258 various types of services that provide externally consumable 259 SaaS offerings, as well as those used internally to manage and 260 manipulate their network infrastructure. 262 Some MSPs operate over multiple geographies and couple infrastructure 263 from different MSPs, SPs and possibly SaaS offerings. In these 264 cases, it is important to provide the MSP that offers the ultimate 265 service to the customer with a clean, consistent and effient 266 interface to all of the infrastructure it relies on. Furthermore, 267 from their perspective, being able to unwind the "russian doll" 268 of nested infrastructure and services that might be rolled together 269 for their service offering in cases where trouble shooting is 270 required for example, is paramount. 272 In the simplest of cases it may not seem obvious that the use of 273 a standardized SDN infrastructure would be necessary; however, 274 in typical medium and large data center offerings that are quite 275 common today, the management of the physical elements is a small 276 part of the larger puzzle for the MSP or CSP. When network elements 277 become virtualized and are then used to construct components of 278 services being offered, an operator can quickly multiply the number 279 of management "devices" or more commonly "elements", by many orders 280 of magnitude. It is here that the problem of lack of open interfaces 281 for SDN component interconnection and discovery becomes clear. 283 Again, for this requirement, SDN operators 284 (over-the-top SDN operators or NSPs) are faced with a lack of open 285 specifications and best practices. 287 Use cases for SDN Interconnection are further discussed in 289 3. SDN Model & Problem Area for The IETF 291 Managing a network of deployed SDN components involves interactions 292 among multiple different functions and components that exist within 293 the network. Some of these components are virtual and some of these 294 SDN Problem Statement October 31, 2011 296 components are real; all should be made available to be managed and 297 manipulated, given the appropriate access, authentication, and policy 298 hurdles have been crossed. Only some of those 299 require standardization. The SDN model and problem area proposed 300 for IETF work is illustrated in Figure 1. The candidate problem area 301 (and respectively the non-goals) for IETF work are shown in Figure 2. 303 |--------Application 304 v ^ 305 +----------+ | 306 | Location | | <--- Application-to- 307 | Services | | Ochestrator protocol 308 +----------+ v 309 ^ ReST API 310 | +-------------------+ +------------------+ 311 |----| Orchestrator_0..N + -----> | Policy Data Base | 312 +-------------------+ +------------------+ 313 ^ 314 | <--- Orchestrator-to-Plug-In Protocol 315 | 316 V 317 +----------+ 318 | Plug-In | 319 | ReST API | 320 +----------+ 321 ^ 322 * 323 V 324 +******************+ 325 * Control Software * 326 * For Device_0..M * 327 +******************+ 328 ^ 329 = 330 V 331 +=================+ 332 = Data Plane = 333 = For Device_0..M = 334 +=================+ 336 <--> interfaces and objects inside the scope of SDN 337 +--+ 339 <**> interfaces and objects may be within the scope of SDN 340 +**+ insofar as modifcations are needed to support SDN 341 SDN Problem Statement October 31, 2011 343 <==> interfaces and objects outside the scope of SDN 344 +==+ 346 Figure 1: SDN Problem Area 348 3.1. Candidate SDN Problem Area for IETF 350 Listed below are the the interfaces required to connect 351 an application with the SDN components and protocols in a network. 352 This constitutes the problem space that is proposed to be 353 addressed by a potential SDN working group in the IETF. The use of 354 the term "interface" is meant to encompass the protocol over which 355 SDN data representations (e.g. SDN Metadata records) are exchanged 356 as well as the specification of the data representations themselves 357 (i.e. what properties/fields each record contains, its structure, 358 etc.). 360 o SDN Orchestrator-to-Application Interface: This interface allows 361 the SDN Orchestrator or "controller" system to be interconnected 362 with applications. This interface may support the following: 363 * Allow bootstrapping of the interface between the Orchestrator 364 and interested applications. 365 * Allow the applications to authenticate. 366 * Allow applications to learn of which objects they have 367 authorization to manipulate, or to interact with objects 368 beloning to controlling software. 370 o SDN Orchestratort-to-Plug-In Interface: This interface allows 371 the SDN Orchestrator to interconnect with the controlling software 372 of devices. 374 o SDN Orchestratort-to-Policy Database Interface: This interface 375 allows the SDN Orchestrator to interconnect with policy, 376 authentication and authorization databases. 378 o SDN Orchestratort-to-location services Interface: This interface 379 allows the SDN Orchestrator to interconnect with location 380 services in order to: 381 * Register itself as a local Orchestrator. 382 * Allow other Orchestrators and applications to find it. 384 o SDN Orchestrator-to-SDN Orchestrator Interface: This interface 385 allows one SDN Orchestrator to interconnect with one or more 386 Orchestrators 387 in order to: 388 * Form a failover/high-availability relationship 389 * distribute mappings of controlling software-to-Orchestrator 390 SDN Problem Statement October 31, 2011 392 * bootstrapping of the other SDN Orchestrators. 393 * configuration of the other SDN Orchestrators. 395 o SDN Logging interface: This interface allows the Logging system 396 in interconnected SDN Orchestrators to communicate the relevant 397 activity logs in order to allow log consuming applications to 398 operate in multi-SDN Orchestrator environments. For example, 399 this interface can be used to collect logs from SDN 400 Orchestrators to provide reporting and monitoring to the M/CSP 401 of SDN activities. 403 As part of the development of the SDN interfaces and solutions it 404 will also be necessary to develop and agree on common mechanisms 405 for how to define the object schemas used to query object model 406 stores of each controlling software element. 408 4. Design Approach for Realizing the SDN APIs 410 This section expands on how SDN interfaces can reuse and leverage 411 existing protocols. First the "reuse instead of reinvent" design 412 principle is restated, then each inetrface is discussed individually 413 with example candidate protocols that can be considered for reuse or 414 leverage. This discussion is not intended to pre-empt any WG 415 decision as to the most appropriate protocols, technologies and 416 solutions to select to solve SDN but is intended as an illustration 417 of the fact that the SDN interfaces need not be created in a vacuum 418 and that reuse or leverage of existing protocols is likely possible. 420 4.1. Relationship to the OSI network model 422 The SDN interfaces called out above in Section 3.1 within the SDN 423 problem area all operate at the application layer (Layer 7 in the 424 OSI network model). Since it is not expected that these interfaces 425 would exhibit unique session, transport or network requirements as 426 compared to the many other existing applications in the Internet, it 427 is expected that the SDN interfaces will be defined on top of 428 existing session, transport and network protocols. 430 4.2. "Reuse Instead of Reinvent" Principle 432 Although a new application protocol could be designed specifically 433 for SDN we assume that this is unnecessary and it is recommended 434 that existing application protocols be reused or leveraged such 435 as HTTP[RFC2616] to devine the SDN interfaces. 437 4.3. Application to SDN Orchestrator Interface 439 4.4. SDN Orchestrator to Plug-In Interface 440 SDN Problem Statement October 31, 2011 442 4.5. SDN Logging Interface 444 The SDN Logging interface enables details of logs or events to be 445 exchanged between interconnected SDN Orchestrators, where events 446 could be: 448 o Log lines related to the connection of a new Orchestrator, or 449 disconnection of an existing one. 450 o A fail-over, switch-over event. Similarly, high-availability 451 synchronication messaging. 452 o Real-time or near-real time events before, during or after 453 SDN Orchestrator commands noting which application instructed 454 it to perform the operation. 455 o Operations and diagnostic messages. 457 Several protocols already exist that could potentially be used to 458 exchange SDN Orchestrator logs including SNMP Traps or Informs, 459 syslog, s/ftp, HTTP POST, or ReST, etc. although it is likely that 460 some of the candidate protocols may not be well suited to meet all 461 the requirements of SDN. For example SNMP Traps pose scalability 462 concerns, and syslog may have potential compatability issues. 464 Although it is not necessary to define a new protocol for exchanging 465 logs across the SDN Logging interface, a SDN WG would still need to 466 specify: 468 o The recommended protocol to use. 469 o A default set of log fields and their syntax & semantics. Today 470 there is no standard set of common log fields across different 471 content delivery protocols and in some cases there is not even a 472 standard set of log field names and values for different 473 implementations of the same delivery protocol. 474 o A default set of events that trigger logs to be generated. 476 4.6. SDN Orchestrator to Location Services Interface 478 4.7 SDN Orchestrator to Policy Database Interface 480 4.8 SDN Orchestrator to SDN Orchestrator Interface 482 5. Gap Analysis of relevant Standardization and Research Activities 484 There are a number of other standards bodies and industry forums that 485 are working in areas related to SDNs, and in some cases related to 486 SDN. This section outlines any potential overlap with the work of 487 the SDN WG and any component that could potentially be reused by 488 SDN Problem Statement October 31, 2011 490 SDN. 492 A number of standards bodies have produced specifications related to 493 SDNs, namely: 495 o Open Network Forum has a dedicated specification called Open Flow 496 which specifies a relationship to an external "control plane" 497 interfacing to a Hardware Abstraction Layer (HAL) that is 498 implemented on Open Flow-capable hardware. 500 6. Relationship to relevant IETF Working Groups 502 6.1. ALTO 504 As stated in the ALTO Working Group charter [ALTO-Charter]: 506 "The Working Group will design and specify an Application-Layer 507 Traffic Optimization (ALTO) service that will provide applications 508 with information to perform better-than-random initial peer 509 selection. ALTO services may take different approaches at balancing 510 factors such as maximum bandwidth, minimum cross-domain traffic, 511 lowest cost to the user, etc. The WG will consider the needs of 512 BitTorrent, tracker-less P2P, and other applications, such as content 513 delivery networks (SDN) and mirror selection." 515 In particular, the ALTO service can be used by an SDN-aware 516 application to improve its selection of an SDN Orchestrator. For 517 example, an application wishing to provision MPLS L3 VPNs on behalf 518 of some virtual machines in a local data center cluster may with 519 to take advantage of the ALTO service in its decision for 520 selecting a relatively close SDN Orchestrator to complete its 521 operations. 523 However, the work of ALTO is complementary to and does not overlap 524 with the work proposed in this document because the integration 525 between ALTO and a SDN would fall under the category of using 526 an existing protocol. One area for further study is whether 527 additional information should be provided by an ALTO service 528 to facilitate SDN Orchestrator selection. For example, loading 529 or fail-over characterists could be one consideration. 531 7. IANA Considerations 533 This document makes no request of IANA. 535 Note to RFC Editor: this section may be removed on publication as an 536 RFC. 538 SDN Problem Statement October 31, 2011 540 8. Security Considerations 542 SDNs comes with a range of security considerations such as how to 543 enforce control of and access to objects managed by the SDN 544 Orchestrators and making sure that in line with the M/CSP policy. 546 9. Acknowledgements 548 The authors would like to thank David Meyer, Ping Pan, Lyndon Ong, 549 Danny McPhereson for their review comments and contributions to the 550 text. 552 10. References 554 10.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 10.2. Informative References 561 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 562 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 563 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 565 [ALTO-Charter] 566 "IETF ALTO WG Charter 567 (http://datatracker.ietf.org/wg/alto/charter/)". 569 [Draft-Lee] L. Young, Bernstein, G., Kim, T., Shiomoto, K., and 570 Dios, O., 571 "Research Proposal for Cross Stratum Optimization (CSO) 572 between Data Centers and Networks", 573 draft-lee-cross-stratum-optimization-datacenter-00.txt 575 Appendix A. Additional Material 577 Note to RFC Editor: This appendix is to be removed on publication as 578 an RFC. 580 A.1. Non-Goals for IETF 582 Listed below are aspects of content delivery that the authors propose 583 be kept outside of the scope of a potential SDN working group: 584 o The interface between Controlling Software (i.e.: control plane) 585 and the device's data plane. 586 o Definition of any hardware abstraction layer (HAL) 587 SDN Problem Statement October 31, 2011 589 A.2. Prioritizing the SDN Work 591 A.3. Related standardization activities 593 OpenFlow has pioneered the concept of software-defined 594 network via a concept called a FlowVisor. It has introduced 595 a new packet forwarding methodology to be applied on hardware 596 or software L2 switches. OpenFlow Version 1.0 and 1.1 have 597 been in research trials and testing in virtualized environments. 598 The new versions will address issues such as extendibility, 599 modularity and carrier-grade. Currently, OpenFlow does not 600 support a mechanism to interface with network devices 601 through the existing IP/MPLS control-plane protocols, although 602 some work has begun to investigate this. 604 NETCONF/YANG provides a XML-based solution for network device 605 configuration. It has been in wide-deployment. By definition, 606 it supports client-to-server configuration, and server-to-client 607 alarms or feedback (The servers are the devices/systems to be 608 configured, the clients are the network configuration/management 609 systems). NETCONF provides support for executing configuration 610 change transactions over multiple devices. 612 ALTO is a server solution designed to gather network abstraction 613 information and interface with applications (such as P2P) for 614 more efficient traffic distribution. It does not require 615 configuring the underlying network devices. 617 PCE is a client-server protocol that operates in MPLS networks 618 that enables the network operators to compute and potentially 619 provision optimal point-to-point and point-to-multipoint 620 connections. However, PCE does not interface with applications 621 to optimize traffic from user applications. 623 DMTF is a cloud computing standardization organization, which 624 have defined many virtualization management interfaces using 625 Restful API. However, it does not include any interface to the 626 underlying networks. 628 A.4. Related Research Projects 630 A.4.1. IRTF Cross Stratum Optimizaiton Research Group 632 Some information on SDN motivations and technical motivations 633 in the IRTF's Cross Stratum Optimization Group [Draft-Lee]. 635 SDN Problem Statement October 31, 2011 637 Authors' Addresses 639 Thomas D. Nadeau (editor) 640 CA Technologies, Inc. 641 273 Corporate Drive 642 Portsmouth, NH 03801 643 Email: thomas.nadeau@ca.com 645 Ping Pan 646 Infinera Corporation 647 169 Java Drive 648 Sunnyvale, CA 94089 649 Phone: (408) 572-5200 650 Email: ppan@infinera.com