idnits 2.17.1 draft-sin-sdnrg-sdn-approach-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 date (April 10, 2013) is 4033 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-boucadair-connectivity-provisioning-profile-02 == Outdated reference: A later version (-05) exists of draft-boucadair-network-automation-requirements-00 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-02 == Outdated reference: A later version (-13) exists of draft-ietf-idr-sla-exchange-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Informational France Telecom 5 Expires: October 12, 2013 April 10, 2013 7 Software-Defined Networking: A Service Provider's Perspective 8 draft-sin-sdnrg-sdn-approach-02 10 Abstract 12 Software-Defined Networking (SDN) has been one of the major buzz 13 words of the networking industry for the past couple of years. And 14 yet, no clear definition of what SDN actually covers has been broadly 15 admitted so far. This document aims at contributing to the 16 clarification of the SDN landscape. 18 It is not meant to endlessly discuss what SDN truly means, but rather 19 to suggest a functional taxonomy of the techniques that can be used 20 under a SDN umbrella and to elaborate on the various pending issues 21 the combined activation of such techniques inevitably raises. As 22 such, a definition of SDN is only mentioned for the sake of 23 clarification. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 12, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. What is In and What is Out? . . . . . . . . . . . . . . . . . 4 63 2.1. Remember the Past . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Be Pragmatic . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Measure Experience Against Expectations . . . . . . . . . 5 66 2.4. Design Carefully . . . . . . . . . . . . . . . . . . . . 6 67 2.5. There is Life Beyond OpenFlow . . . . . . . . . . . . . . 6 68 2.6. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. A Definition of Software-Defined Networking . . . . . . . . . 7 70 3.1. A Tautology . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.2. On Flexibility . . . . . . . . . . . . . . . . . . . . . 8 72 3.3. A Tentative Definition . . . . . . . . . . . . . . . . . 8 73 3.4. Functional Meta-Domains . . . . . . . . . . . . . . . . . 9 74 4. Disscussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Full Automation: a Viable Objective? . . . . . . . . . . 9 76 4.2. The Intelligence resides in the PDP . . . . . . . . . . . 10 77 4.3. Simplicity and Adaptability vs. Complexity . . . . . . . 11 78 4.4. Performance & Scalability . . . . . . . . . . . . . . . . 11 79 4.5. Risk Assessement . . . . . . . . . . . . . . . . . . . . 12 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Informative References . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 1.1. Context 90 The Internet has become the federative network that supports a wide 91 range of service offerings. The delivery of network services such as 92 IP VPNs assumes the combined activation of various capabilities that 93 include (but are not necessarily limited to) forwarding and routing 94 capabilities (e.g., customer-specific addressing scheme management, 95 dynamic path computation to reach a set of destination prefixes, 96 dynamic establishment of tunnels, etc.), quality of service 97 capabilities (e.g., traffic classification and marking, traffic 98 conditioning and scheduling), security capabilities (e.g., filters to 99 protect customer premises from network-originated attacks, to avoid 100 malformed route announcements, etc.) and management capabilities 101 (e.g., detection and processing of faults). 103 As these services not only grow in variety but also in complexity, 104 their design, delivery and operation have become a complex alchemy 105 that often requires various levels of expertise. This situation is 106 further aggravated by the wide variety of (network) protocols and 107 tools, as well as recent Any Time Any-Where Any Device 108 (ATAWAD)-driven convergence trends that are meant to make sure an 109 end-user can access the whole range of services he/she has subscribed 110 to, whatever the access and device technologies, wherever the end- 111 user is connected to the network, and whether this end-user is in 112 motion or not. 114 Yet, most of these services have been deployed for the past decade, 115 based solely on often static service production procedures that are 116 more and more exposed to the risk of malformed configuration 117 commands. In addition, most of these services do not assume any 118 specific negotiation between the customer and the service provider or 119 between service providers besides the typical financial terms. 121 At best, five-year master plans are referred to as the network 122 planning policy that will be enforced by the service provider, given 123 the foreseen business development perspectives, manually-computed 124 traffic forecasts and the market coverage (fixed/mobile, residential/ 125 corporate). This so-called network planning policy may very well 126 affect the way resources are allocated in a network, but clearly 127 fails to be adequately responsive to highly dynamic customer 128 requirements in an "always-on" fashion. These needs are more 129 critical for corporate customers. 131 In addition, various tools are used for different, sometimes service- 132 centric, management purposes but their usage is not necessarily 133 coordinated for the sake of event aggregation, correlation and 134 processing. At the cost of extra complexity and possible customer's 135 Quality of Experience degradation. 137 Multi-service, multi-protocol, multi-technology convergent and 138 dynamically-adaptive networking environments of the near future have 139 therefore become one of the major challenges faced by service 140 providers. 142 1.2. Scope 144 This document is a contribution to clarify the SDN landscape: 146 o Section 2 clarifies items which are considered as viable goals and 147 exclude others from the scope. 148 o Section 3 provides a tentative definition from a service provider 149 perspective. 150 o Section 3 discusses several issues and identifies some 151 requirements. 153 2. What is In and What is Out? 155 The networking ecosystem has become awfully complex and highly 156 demanding in terms of robustness, performance, scalability, 157 flexibility, agility, etc. This means in particular that service 158 providers and network operators must deal with such complexity and 159 operate networking infrastructures that can evolve easily, remain 160 scalable, guarantee robustness and availability, and are resilient 161 against denial-of-service attacks. 163 The introduction of new SDN-based networking features should 164 obviously take into account this context, especially from a cost 165 impact assessment perspective. 167 2.1. Remember the Past 169 SDN techniques cannot be seen as a brand new solution but rather as 170 some kind of rebranding of proposals that have been investigated for 171 several years, like Active or Programmable Networks. As a matter of 172 fact, some of the claimed "new" SDN features have been already 173 implemented (e.g., NMS (Network Management System), PCE (Path 174 Computation Element, [RFC4655])), and supported by vendors for quite 175 some time (references can be added if needed). 177 Some of these features have also been standardized (e.g., DNS-based 178 routing [RFC1383] that can be seen as an illustration of separated 179 control and forwarding planes or ForCES ([RFC5810][RFC5812])). 181 2.2. Be Pragmatic 183 SDN approaches should be holistic. This means that it must be 184 global, network-wise. It is not a matter of configuring devices one 185 by one to enforce a specific forwarding policy. It is about 186 configuring and operating a whole range of devices at the scale of 187 the network for the sake of automated service delivery 188 ([I-D.boucadair-network-automation-requirements]), from service 189 negotiation and creation (e.g., [I-D.ietf-idr-sla-exchange]) to 190 assurance and fulfillment. 192 Because the complexity of activating SDN capabilities is hidden (to 193 the user) and pushed to software, a clear understanding of the 194 overall ecosystem is needed to figure out how to manage this 195 complexity and to what extent this hidden complexity does not have 196 side effects on network operation. 198 As an example, SDN designs that assume a central decision-making 199 entity must avoid single points of failure. They must not affect 200 packet forwarding performances either (e.g., transit delays must not 201 be impacted). 203 SDN techniques are not necessary to develop new network services per 204 se. The basic service remains (IP) connectivity that solicits 205 resources located in the network. 207 SDN techniques can thus be seen as another means to interact with 208 network service modules and invoke both connectivity and storage 209 resources accordingly in order to meet service-specific requirements. 211 By definition, SDN techniques remain limited to what is supported by 212 embedded software and hardware. One cannot expect SDN techniques to 213 support unlimited customizable features. 215 Policy-based management framework[RFC2753] was designed to 216 orchestrate available resources, by means of a typical Policy 217 Decision Point (PDP) which masters advanced offline traffic 218 engineering capabilities. As such, this framework has the ability to 219 interact with in-band software modules embedded in controlled devices 220 (or not). 222 SDN techniques as a whole are an instantiation of the policy-based 223 network management framework. Within this context, SDN techniques 224 can be used to activate capabilities on demand, to dynamically invoke 225 network and storage resources and to operate dynamically-adaptive 226 networks according to events (e.g., alteration of the network 227 topology) and triggers (e.g., dynamic notification of a link 228 failure), etc. 230 2.3. Measure Experience Against Expectations 232 Because several software modules may be controlled by external 233 entities, means to ensure the experienced outcome complies with the 234 expected outcome belong to the set of SDN techniques. 236 These techniques, as an instantiation of Policy-Based Management, 237 should interact with Service Structuring engines and the network to 238 continuously assess whether the experienced network behavior is 239 compliant with the objectives set by the Service Structuring engine, 240 and which may have been dynamically negotiated with the customer 241 (e.g., captured in a CPP 243 [I-D.boucadair-connectivity-provisioning-profile]). This requirement 244 applies to several regions of a network: 246 1. At the interface between two adjacent IP network providers. 247 2. At the access interface between a service provider and an IP 248 network provider. 249 3. At the interface between a customer and the IP network provider. 251 Ideally, a fully automated service delivery procedure from 252 negotiation and ordering, through order processing, to delivery, 253 assurance and fulfillment, should be supported. This approach 254 assumes widely adopted standard data and information models, let 255 alone interfaces. 257 2.4. Design Carefully 259 Exposing open and programmable interfaces has a cost, from both a 260 scalability and performance standpoints. 262 Maintaining hard-coded performance optimization techniques is 263 encouraged. So is the use of interfaces that allow the direct 264 control of some engines (e.g., routing, forwarding) without requiring 265 any in-between adaptation layer (generic objects to vendor-specific 266 CLI commands for instance). 268 SDN techniques will have to accommodate vendor-specific components 269 anyway. Indeed, these vendor-specific features will not cease to 270 exist mainly because of the harsh competition. 272 The introduction of new functions or devices that may jeopardize 273 network flexibility should be avoided, or at least carefully 274 considered in light of possible performance and scalability impacts. 275 SDN-enabled devices will have to coexist with legacy systems. 277 One single SDN, network-wise deployment is unlikely. 279 Instead, multiple instantiations of SDN techniques will be 280 progressively deployed and adapted to various network and service 281 segments. 283 2.5. There is Life Beyond OpenFlow 285 Empowering networking with in-band controllable modules does not 286 necessarily mean the use of the OpenFlow protocol, which is only a 287 protocol that helps devices populate their forwarding tables 288 according to a set of instructions. 290 OpenFlow is clearly not the "next big thing": there are many, many 291 other protocols that have been standardized (think Routing Policy 292 Specification Language (RPSL, [RFC2622]), for one) - or not - and 293 which have been massively deployed. 295 The forwarding of the configuration information can currently rely 296 upon a variety of protocols that include (but is not necessarily 297 limited to) PCEP [RFC5440], NETCONF [RFC6241], COPS-PR [RFC3084], 298 etc. 300 There is no 1:1 relationship between OpenFlow and SDN. Rather, 301 OpenFlow is one of the candidate protocols to convey specific 302 configuration information towards devices. As such, OpenFlow is one 303 possible component of the global SDN toolkit. 305 2.6. Non Goals 307 There are inevitable trade-offs between the current networking 308 ecosystem and the proposed SDN paradigm. Operators do not have to 309 choose between the two as both models may be needed. 311 In particular, the following considerations can be seen as a non-goal 312 to justify the deployment of SDN techniques: 314 o Fully flexible software implementations, whereas the claimed 315 flexibility will be limited by respective software and hardware 316 limitations, anyway. 317 o Fully modular implementations are difficult to achieve (because of 318 the implicit complexity) and may introduce extra effort for 319 testing, validation and troubleshooting. 320 o Fully centralized control systems that raise some scalability 321 issues. Distributed protocols and their ability to react to some 322 events (e.g., link failure) in a timely manner remains a key to 323 scalable networks. This means that SDN designs can rely upon a 324 logical representation of centralized features (an abstraction 325 layer that would support inter-PDP communications, for example). 327 3. A Definition of Software-Defined Networking 329 3.1. A Tautology 331 The separation of the forwarding and control planes (beyond 332 implementation considerations) have almost become a gimmick to 333 promote flexibility as a key feature of the SDN approach. 334 Technically, most of current router implementations have been 335 assuming this separation for years if not decades. Routing processes 336 (such as IGP and BGP route computation) have often been software- 337 based, while forwarding capabilities are hardware-encoded. 339 As such, the current state-of-the-art tends to confirm the said 340 separation, which rather falls under a tautology. 342 But a somewhat centralized, "controller-embedded", control plane for 343 the sake of route computation before FIB population is certainly 344 another story. 346 3.2. On Flexibility 348 This "flexibility argument" that has been put forward by SDN 349 promoters is undoubtedly one of the key objectives that must be 350 achieved by service providers. This is because the ability to 351 dynamically adapt to a wide range of customer's requests for the sake 352 of flexible network service delivery is an important competitive 353 advantage. But flexibility is much, much more than separating the 354 control and forwarding planes to facilitate forwarding decision- 355 making processes. Note: 357 o The exact characterization of what flexibility actually means is 358 still required. 359 o The exposure of programmable interfaces is not a goal per se, 360 rather a means to facilitate configuration procedures. 362 3.3. A Tentative Definition 364 We define Software-Defined Networking as the set of techniques used 365 to facilitate the design, the delivery and the operation of network 366 services in a deterministic, dynamic, and scalable manner. 368 Such a definition assumes the introduction of a high level of 369 automation in the overall service delivery and operation procedures. 371 Because networking is by essence software-driven, the above 372 definition does not emphasize the claimed "Softwire-Defined" property 373 of SDN-labeled solutions. 375 Having a predictable network behavior is important to consider. This 376 argues in favor of investigating advanced network emulation engines 377 which would assess the impact of enforcing a new policy. Network 378 emulation function would be a helper for operators. A network 379 emulation engine can be fed with information collected using for 380 instance [I-D.ietf-idr-ls-distribution]. 382 3.4. Functional Meta-Domains 384 SDN techniques can be classified into the following functional meta- 385 domains: 387 o Techniques for the dynamic discovery of network topology, devices 388 and capabilities, along with relevant information models that are 389 meant to precisely document such topology, devices and 390 capabilities. 391 o Techniques for exposing network services (and their 392 characteristics; e.g., 393 [I-D.boucadair-connectivity-provisioning-profile]) and for dynamic 394 negotiation of the set of corresponding parameters that will be 395 used to measure the level of quality associated to the delivery of 396 a given service or a combination thereof. 397 o Techniques used by service requirements-derived dynamic resource 398 allocation and policy enforcement schemes, so that networks can be 399 programmed accordingly. 400 o Dynamic feedback mechanisms that are meant to assess how 401 efficiently a given policy (or a set thereof) is enforced from a 402 service fulfillment and assurance perspective. 404 4. Disscussion 406 4.1. Full Automation: a Viable Objective? 408 The path towards full automation is paved with numerous challenges 409 and requirements, including: 411 o Simplify and foster service delivery, assurance and fulfillment, 412 as well as network failure detection, diagnosis and root cause 413 analysis: 415 * This can be achieved thanks to automation, possibly based upon 416 a logically centralized view of the network infrastructure (or 417 a portion thereof), yielding the need for highly automated 418 topology, device and capabilities discovery as well as 419 operational procedures. 420 * The main intelligence resides in the PDP, which suggests that 421 an important part of the investigation effort should focus on a 422 detailed specification of the PDP function, including 423 algorithms and behavioral details, based upon a complete set of 424 standardized data and information models. 425 o Need for abstraction layers: clear interfaces between business 426 actors, clear interaction between layers, cross-layer 427 considerations, etc. 429 * Ability to build and package differentiated (network) services. 431 * Need for IP connectivity service exposure to customers, peers, 432 applications, content/service providers, etc. (e.g., 433 [I-D.boucadair-connectivity-provisioning-profile]). 434 * Need for a solution to map IP connectivity service requirements 435 with network engineering objectives. 436 * Need for dynamically-adaptive objectives based on current 437 resource usage and demand, for the sake of highly responsive 438 dynamic resource allocation and policy enforcement schemes. 439 o Better accommodate technologically heterogeneous networking 440 environments: 442 * Need for vendor-independent configuration procedures, based 443 upon the enforcement of vendor-agnostic generic policies 444 instead of vendor-specific languages. 445 * Need for tools to aid manageability and orchestrate resources. 446 * Avoid proxies and privileged direct interaction with engines 447 (e.g., routing, forwarding). 449 4.2. The Intelligence resides in the PDP 451 The proposed SDN definition in Section 3.3 assumes an intelligence 452 that may reside in the control or management planes (or both). This 453 intelligence is typically represented by a Policy Decision Point, 454 which is one of the key functional components of Policy-Based 455 Management architectures [RFC2753]. 457 The Policy Decision Point (PDP) is where policy decisions are made. 458 PDPs use a directory service for policy repository purposes. The 459 policy repository stores the policy information that can be retrieved 460 and updated by the PDP. The PDP delivers policy rules to the Policy 461 Enforcement Point (PEP) in the form of policy-provisioning 462 information that includes configuration information. 464 The Policy Enforcement Point (PEP) is where policy decisions are 465 applied. PEPs are embedded in (network) devices, which are 466 dynamically configured based upon the policy-formatted information 467 that has been processed by the PEP. PEPs request configuration from 468 the PDP, store the configuration information in the Policy 469 Information Base (PIB), and delegate any policy decision to the PDP. 471 SDN networking therefore relies upon PDP functions that are capable 472 of processing various input data (traffic forecasts, outcomes of 473 negotiation between customers and service providers, resource status 474 (as depicted in appropriate information models instantiated in the 475 PIB, etc.) to make appropriate decisions. 477 The design and the operation of such PDP-based intelligence in a 478 scalable manner remains of the major areas that needs to be 479 investigated within SDN environments. 481 To avoid centralized design schemes, inter-PDP communication means 482 should be considered. 484 Several PDP instances may be activated in a given domain. Because 485 each of these PDP instances may be in charge of a given functional 486 perimeter, an inter-PDP communication may be required to ease 487 collaboration between these PDPs to provision a network service. 489 Inter-domain PDP exchanges may be needed for some specific usages. 490 Examples of such exchanges are: (1) During the network attachment 491 phase of a node to a visited network, the PDP belonging to the the 492 visited network can contact the home PDP to retrieve the policies to 493 be enforced for that node. (2) Various PDPs can collaborate together 494 in order to compute inter-domain paths which satisfy a set of traffic 495 performance guarantees. 497 4.3. Simplicity and Adaptability vs. Complexity 499 The above meta functional domains assume the introduction of a high 500 level of automation, from service negotiation to delivery and 501 operation. 503 Automation is the key to simplicity, but must not be seen as a magic 504 button that would be hit by a network administrator whenever a 505 customer request has to be processed or additional resources need to 506 be allocated. 508 The need for simplicity and adaptability thanks to automated 509 procedures generally assumes some complexity that lies beneath 510 automation. 512 4.4. Performance & Scalability 514 The combination of flexibility with software inevitably raises 515 performance and scalability issues as a function of the number and 516 the nature of the services to be delivered and their associated 517 dynamics. 519 While the deployment of a network solely composed of OpenFlow 520 switches within a data center environment is unlikely to raise FIB 521 scalability issues given the current state-of-the-art, data center 522 networking that relies upon complex, possibly IP-based, QoS-inferred, 523 interconnect design schemes meant to dynamically manage the mobility 524 of Virtual Machines between sites is certainly another scale. 526 The claimed flexibility of SDN networking in the latter context will 527 have to be carefully investigated by operators. 529 4.5. Risk Assessement 531 Various risks are to be assessed such as: 533 o Evaluating the risk of depending on a controller technology rather 534 than a device technology. 535 o Evaluating the risk of operating frozen architectures because of 536 potential interoperability issues between a controller and a 537 controlled device. 538 o Assessing whether SDN-labeled solutions are likely to obsolete 539 existing technologies because of hardware limitations. 540 o Etc. 542 5. IANA Considerations 544 This document does not require any action from IANA. 546 6. Security Considerations 548 This document does not define any protocol nor architecture. 550 7. Acknowledgements 552 Many thanks to J. Halpern and T. Tsou for their feedback. 554 Special thanks to P. Georgatos for the interesting discussion; 555 particularly the discussion on SDNi (SDN Interconnection). 557 8. Informative References 559 [I-D.boucadair-connectivity-provisioning-profile] 560 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 561 Connectivity Provisioning Profile", draft-boucadair- 562 connectivity-provisioning-profile-02 (work in progress), 563 September 2012. 565 [I-D.boucadair-network-automation-requirements] 566 Boucadair, M. and C. Jacquenet, "Requirements for 567 Automated (Configuration) Management", draft-boucadair- 568 network-automation-requirements-00 (work in progress), 569 December 2012. 571 [I-D.ietf-idr-ls-distribution] 572 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 573 Ray, "North-Bound Distribution of Link-State and TE 574 Information using BGP", draft-ietf-idr-ls-distribution-02 575 (work in progress), February 2013. 577 [I-D.ietf-idr-sla-exchange] 578 Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. 579 Boucadair, "Inter-domain SLA Exchange", draft-ietf-idr- 580 sla-exchange-00 (work in progress), January 2013. 582 [RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 583 1383, December 1992. 585 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 586 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 587 "Routing Policy Specification Language (RPSL)", RFC 2622, 588 June 1999. 590 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 591 for Policy-based Admission Control", RFC 2753, January 592 2000. 594 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 595 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 596 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 597 3084, March 2001. 599 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 600 Computation Element (PCE)-Based Architecture", RFC 4655, 601 August 2006. 603 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 604 (PCE) Communication Protocol (PCEP)", RFC 5440, March 605 2009. 607 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 608 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 609 Control Element Separation (ForCES) Protocol 610 Specification", RFC 5810, March 2010. 612 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 613 Element Separation (ForCES) Forwarding Element Model", RFC 614 5812, March 2010. 616 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 617 Bierman, "Network Configuration Protocol (NETCONF)", RFC 618 6241, June 2011. 620 Authors' Addresses 621 Mohamed Boucadair 622 France Telecom 623 Rennes 35000 624 France 626 Email: mohamed.boucadair@orange.com 628 Christian Jacquenet 629 France Telecom 630 Rennes 631 France 633 Email: christian.jacquenet@orange.com