idnits 2.17.1 draft-leeking-actn-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2014) is 3732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4655' is mentioned on line 165, but not defined == Unused Reference: 'RFC4665' is defined on line 604, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Young Lee 2 Internet Draft Huawei 3 Daniel King 4 Intended status: Informational Lancaster University 5 Expires: August 5,2014 7 February 5, 2014 9 Problem Statement for Abstraction and Control of Transport Networks 11 draft-leeking-actn-problem-statement-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 5, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 Previously transport networks were typically static, lacked 54 flexibility, and required long planning times when deploying new 55 services. Network Providers and Service Providers have embraced 56 technologies that allow separation of data plane and control plane, 57 distributed signaling for path setup and protection, and centralized 58 path computation for service planning and traffic engineering. 59 Although these technologies provide significant benefits, they do 60 not meet the growing need for network programmability, automation, 61 resource sharing, and service elasticity necessary for meeting 62 customer demands and evolving Internet applications 64 By combining the aforementioned capabilities with network resource 65 virtualization and abstraction mechanisms, available via well- 66 defined customer interfaces, providing significant operational 67 benefits to meet the growing demands from customers and 68 applications. The work effort investigating this problem space is 69 known as Abstraction and Control of Transport Networks (ACTN). 71 This document provides an ACTN problem description, scope of work, 72 and outlines the core requirements to facilitate network resource 73 virtualization and resource slicing for customers and applications, 74 across Service Provider and Network Provider transport network 75 infrastructure. 77 Table of Contents 79 1. Introduction...................................................3 80 1.1. Terminology...............................................4 81 2. Relationship with Existing Technologies........................6 82 2.1. Virtual Private Networks..................................6 83 2.2. Overlay Networks..........................................7 84 3. Motivations for Additional Functionality.......................7 85 3.1. Business Objectives.......................................7 86 3.2. Network Resource Recursiveness............................8 87 3.3. Customer-Initiated Programmability........................8 88 3.4. Resource Partitioning.....................................8 89 3.5. Service Orchestration.....................................9 90 4. ACTN Objectives and Requirements...............................9 91 4.1. Capability and Resource Discovery.........................9 92 4.2. Network Programmability..................................10 93 4.3. Common Data Models.......................................10 94 4.4. Scheduling and Allocation................................11 95 4.5. Adaptability.............................................11 96 4.6. Slicing..................................................11 97 4.7. Isolation................................................11 98 4.8. Manageability............................................12 99 4.9. Resilience...............................................12 100 4.10. Security................................................13 101 4.11. Policy..................................................13 102 4.12. Technology Independence.................................13 103 4.13. Architecture Principles.................................13 104 4.13.1. Network Partitioning...............................13 105 4.13.2. Orchestration......................................13 106 4.13.3. Recursion..........................................13 107 4.13.4. Legacy Support.....................................14 108 5. References....................................................14 109 5.1. Informative References...................................14 110 6. Contributors........................Error! Bookmark not defined. 111 Authors' Addresses...............................................15 112 Intellectual Property Statement..................................15 113 Disclaimer of Validity...........................................15 115 1. Introduction 117 Customers continue to demand new services that are time scheduled, 118 dynamic, and underpinned by a Pay As You Go billing model. These 119 services are provided to customers by Network Providers and Service 120 Providers and give rise to a variety of applications for office 121 automation, data backup and retrieval, distributed computing, and 122 high-quality media broadcasting. They offer Network and Service 123 Providers new revenue generation opportunities, and these services 124 typically have different traffic characteristics from established 125 network services such as file hosting, web, and email. Deploying and 126 operating these new applications and services using traditional 127 network architectures limits network efficiency, scalability, and 128 elasticity (i.e., capable of adapting to customer and application 129 demands). 131 Network virtualization has been a significant innovation towards 132 meeting customer demands, and enabling new applications and 133 services. Separating network resources, and representing resources 134 and topologies via abstracted concepts, facilitate effective 135 sharing, or slicing, of physical infrastructure into virtual network 136 service instances corresponding to multiple virtual network 137 topologies that may be used by specific applications and services. 138 Further development is required to allow customers to create, 139 modify, and delete virtual network services dynamically. 141 Abstraction and Control of Transport Networks (ACTN) defines new 142 methods and capabilities for the deployment and operation of 143 transport network resource. These are summarized as: 145 o Abstraction of underlying network resources to higher-layer 146 applications and customers; 148 o Slicing of network resources to meet specific application and 149 customer requirements; 151 o Provision of a computation scheme and virtual control 152 capability, via an data model, to customers who request virtual 153 network services; 155 o Coordination of underlying transport layers and presentation as 156 an abstracted topology to the customer. 158 This document provides an ACTN problem description and scope of 159 work, and outlines the core requirements to facilitate network 160 resource virtualization and resource slicing for Network Providers, 161 Service Providers, Customers, and applications. 163 1.1. Terminology 165 This document uses the terminology defined in [RFC4655], and 166 [RFC5440]. Additional terms are defined below. 168 o Customers: 170 Customers are users of virtual network services. They are provided 171 with an abstract resource view of the network resource (known as "a 172 slice") to support their users and applications. In some cases, 173 customers may have to support multiple virtual network services with 174 different service objectives and QoS requirements to support 175 multiple types of users and applications. 177 o Service Providers (also Virtual Network Service Provider): 179 Service Providers are the providers of virtual network services to 180 their customers. Service Providers typically lease resources from 181 single or multiple Network Providers' facilities to create virtual 182 network services and offer end-to-end services to their customers. 183 A Virtual Network Service Provider is a type of Service Provider, 184 except that they own no physical equipment or infrastructure, and 185 only provide services built upon virtual network infrastructure. In 186 general, this document does not distinguish between a Virtual 187 Network Service Provider and Service Provider. 189 o Network Providers: 191 Network Providers are the infrastructure providers that own the 192 physical network resources and provide transport network resources 193 to their customers. Service Providers can be the customers of 194 Network Providers or can be the Network Providers themselves. 196 o Network Virtualization: 198 Network virtualization, refers to allowing the customers to utilize 199 a certain network resources as if they own them and thus allows them 200 to control their allocated resources in a way most optimal with 201 higher layer or application processes. This customer control 202 facilitates the introduction of new applications (on top of 203 available services) as the customers are given programmable 204 interfaces to create, modify, and delete their virtual network 205 services. 207 o Transport Networks 209 Transport networks are defined as network infrastructure that 210 provides connectivity and bandwidth for customer services. They are 211 characterized by their ability to support server layer provisioning 212 and traffic engineering for client layer services, such that 213 resource guarantees may be provided to their customers. Transport 214 networks in this document refer to a set of different type of 215 connection-oriented networks, which include Connection-Oriented 216 Circuit Switched (CO-CS) networks and Connection-Oriented Packet 217 Switched (CO-PS) networks. This implies that at least the following 218 transport networks are in scope of the discussion of this draft: 219 Layer 1 (L1) optical networks (e.g., Optical Transport Networks 220 (OTN) and Wavelength Switched Optical Networks (WSON)), MPLS-TP, 221 MPLS-TE, as well as other emerging network technologies with 222 connection-oriented behavior. 224 2. Relationship with Existing Technologies 226 2.1. Virtual Private Networks 228 A Virtual Private Network (VPN) is a well-known concept [RFC4110], 229 [RFC4664] and [RFC4847], and may be used to connect multiple 230 distributed sites via a variety of transport technologies, sometimes 231 over shared network infrastructure. 233 Typically VPNs are managed and provisioned directly by the Network 234 Provider or a VPN Service Provider. VPN systems may be classified 235 by: 237 o Protocol mechanisms used to tunnel the traffic; 239 o Tunnel termination point and/or location; 241 o Type of connectivity, site-to-site or remote-access; 243 o Quality of Service (QoS) capabilities; 245 o Level of security provided; 247 o Emulated service connectivity layer (layer 1, layer 2, layer 248 3); 250 Existing VPN solutions are largely technology specific and offer 251 limited elasticity, although some technologies offer greater 252 flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs 253 [RFC4110]) when compared with layer 1 VPNs [RFC4847], all 254 technologies are often deployed using pre-defined configurations. 255 The transport layer is achieved by utilizing a variety of 256 technology-specific interfaces - e.g. Gigabit Ethernet (GE), 257 Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer Mode 258 (ATM) for wireless back-hauling, or optical networks OTN and WSON). 260 VPNs offer a scalable tunnel solution for customer traffic; however 261 they are wholly dependent on the Service Provider to setup and 262 manage the VPNs, lacking customer-initiated service programmability: 263 creation, resizing, and deletion. 265 2.2. Overlay Networks 267 An overlay network [RFC4208] provides an enhanced network 268 virtualization technique, with the overlay network providing a 269 topology comprised of virtual or logical links and nodes, which are 270 built on top of physical nodes and links, providing a topology in 271 which some of the links and nodes are virtual or logical and are 272 built from multiple nodes or links in a server network. 274 Overlay networks are typically used in the multi-layer context, in 275 which the packet layer is a client to the server transport layer. 276 The scope of network virtualization in overlay networks is somewhat 277 limited. Customers and applications which need visibility or 278 programmability, and the ability to resize or add resources, may 279 find that overlay network technologies do meet their requirements. 281 3. Motivations for Additional Functionality 283 3.1. Business Objectives 285 The traditional VPN and overlay network (ON) models are built on the 286 premise that one single Network Provider provides all virtual 287 private or overlay networks to its customers. This model is simple 288 to operate but has some disadvantages in accommodating the 289 increasing need for flexible and dynamic network virtualization 290 capabilities. 292 A Network Provider may provide traditional end-to-end services and 293 content (i.e., web and email) to its customers. Emerging services, 294 applications and content are typically provided via Service 295 Providers and Over the Top (OTT) (i.e., Video-on-demand, Social 296 Media) providers. We can further categorize Service Providers as: 298 o A fixed or mobile Internet Service Providers (ISPs) which provide 299 Internet connectivity and bandwidth to uses; 301 o A service provider that leases network resources from one or more 302 network providers to create virtual network services between ISPs 303 and the core Internet. 305 o Data Center (DC)/content Network Provider and Service Providers 306 who provide connectivity and bandwidth to content servers and 307 application servers. 309 Network Providers and Service Providers of every type, all share the 310 common business and revenue objectives: 312 o Minimize time to plan and deploy new services; 314 o Reduce the reliance on highly skilled personnel to operate their 315 network; 317 o Reduce time to react to changing business demands and customer 318 applications; 320 o Offer new, much more flexible services to their customers; 322 o Maximize network resource usage and efficiency. 324 All aforementioned objectives have the capability to significant 325 increase revenue and reduce operational costs. 327 Network and Service Providers require capabilities that extend the 328 current landscape of network virtualization capabilities and overall 329 business objectives of the Network Provider, Service Provider, and 330 ultimately the Customer and their Applications. 332 3.2. Network Resource Recursiveness 334 A newly emerged network virtualization environment is a collection 335 of heterogeneous network architectures from different players. VPNs 336 and overlay networks are somewhat limited in addressing programmable 337 interfaces for application or customer layers as well as for the 338 service layer. The model must be extended to address a recursive 339 nature of layer interactions in network virtualization across 340 transport networks, service networks, and customers/applications. 342 3.3. Customer-Initiated Programmability 344 Network-driven technologies such as VPNs and overlay networks 345 provide customers with a set of pre-defined programmatic parameters 346 to enable virtual networks. However, this model is limited to only 347 allow programmable interfaces in which customers initiate and define 348 virtual network services. This model must be extended to allow 349 customer-initiated network programmability. 351 3.4. Resource Partitioning 353 The ability to slice and allocate transport resources for Service 354 Providers would be beneficial. It would improve transport network 355 resource efficiency and provide a method for the transport Network 356 Provider to offer resource flexibility and control to Service 357 Providers and users. 359 3.5. Service Orchestration 361 Another dimension is diversity on the customer side. Customers in 362 this newly emerged network virtualization environment bring 363 different dynamics than the traditional VPNs or Overlay Networks. 364 There may be a multiple virtual slices that need to be created, 365 managed and deleted, each interfacing to a number of Service 366 Providers and Network Providers as the end-points of the clients 367 span across multiple network domains. Thus, multiple components will 368 require automated co-ordination and management, this is known as 369 service orchestration and is therefore one of the key capabilities 370 that should be provided. 372 4. ACTN Objectives and Requirements 374 The overall goal of enabling network abstraction and multiple 375 concurrent virtual networks to coexist together on a shared physical 376 infrastructure, comprised on multiple physical layers, and may be 377 subdivided into several smaller objectives. These are outlined below 378 and are required in order to fulfill the design goals of ACTN. 380 The ACTN effort should utilize existing physical layer monitoring 381 capabilities, algorithmic representation and modelling of physical 382 layer resources to consider transport appropriate metrics and 383 constraints. Moreover, the model may want to support dynamic 384 collection of the statistics (i.e., status and availability) of the 385 underlying transport network infrastructure. 387 4.1. Capability and Resource Discovery 389 It may be necessary for the application or Customer to discover 390 available capabilities and available network resources, for example, 391 abstracted resource view and control. Furthermore, capabilities and 392 resources will also include: 394 o Peering Points (may be based on business SLAs or policies); 396 o Transport Topology (i.e., transport switching type, topology and 397 connection points); 399 o Transport Capacity (i.e., current bandwidth and maximum 400 bandwidth). 402 o Policy Management (i.e., what resources and capabilities are 403 available, and what may be requested and by whom. 405 4.2. Network Programmability 407 A programmable interface should provide customers with the 408 capabilities to dynamically create, deploy, and operate services in 409 response to customer and application demands. To enable the on- 410 demand services, the separation of control and forwarding is a 411 fundamental requirement. Once this separation is achieved the 412 network layer may be programmed irrespective of the underlying 413 forwarding mechanism. 415 The creation of a programmable abstraction layer for physical 416 network devices would provide distributed computing objects which 417 would allow operators to manipulate the network resources. By 418 utilizing open programmable north-bound network interfaces, it would 419 enable access to virtual control layer by customer interfaces and 420 applications. 422 4.3. Common Data Models 424 The abstraction of the underlay transport, and resource information 425 representation model should describe each technology type within the 426 ACTN framework; they will all follow a uniform structure, which is 427 extensible to support any future technologies. 429 Such models will represent the physical resources as a set of 430 attributes, characteristics and functionality, while adaptively 431 capturing the true real-time and dynamic (real-time) properties of 432 underlying physical resources. 434 For future discussion, abstraction and the technology agnostic 435 virtualization requirements may benefit from being split into new 436 sub-sections, suggested below: 438 o Attributes 440 o Metrics 442 o Control Actions 444 o Semantics 446 Resources will be described with semantic methods so that the 447 resource description models can be exposed in a uniformly structured 448 manner to the upper layers. 450 Virtual infrastructure requests from ACTN customers will be 451 translated into network parameters according to aforementioned 452 network abstraction model. Utilizing this mechanism, a request is 453 translated into topology and multi-dimensional nodes, interfaces and 454 spectrum space with specific attributes such as bandwidth, QoS, and 455 node capability. 457 4.4. Scheduling and Allocation 459 When requesting network slices it should be possible to request an 460 immediate or scheduled service. When establishing a network slice, a 461 customer may require specific guarantees for the virtual node and 462 link attributes. This might include a request that guarantees 463 minimum packet processing on a virtual node, and fixed loss and 464 delay characteristics on the virtual links. 466 To provide such guarantees and to create an illusion of an isolated 467 and dedicated network slice to each customer, Network Providers must 468 employ appropriate scheduling algorithms in all of the network 469 elements. 471 4.5. Adaptability 473 Adaptability of services would allow the Service Provider, user, and 474 application to request modification of exist network resource that 475 has been assigned. This may include resizing of bandwidth, 476 modification of the topology, and adding/removing connectivity 477 points. 479 4.6. Slicing 481 It should be possible for transport network infrastructure to be 482 partitioned into multiple independent virtual networks known as 483 "slicing", based on provider service types, customers and 484 application requirements. 486 4.7. Isolation 488 Isolation, both of physical underlay infrastructure and of co- 489 existing virtual networks, and ensure no leakage of traffic. 490 Furthermore, there must be mechanisms that ensure that once network 491 slices are assigned Customer and Application services are not 492 competing for independent transport resources. 494 Each customer or application should be able to use arbitrary network 495 topology, routing, or forwarding functions as well as customized 496 control mechanisms independent of the underlying physical network 497 and other coexisting virtual networks. 499 It must also be possible for many virtual networks to share the 500 underlying infrastructure, without significantly impacting the 501 performance of applications utilizing the virtual networks. 503 4.8. Manageability 505 A broad range of capabilities, including: request, control, 506 provisioning, monitoring, resilience, adaptation and re-optimisation 507 of end-to-end services will need to be provided through a set of 508 well-defined interfaces, specifically it should be possible to 509 provide: 511 o Control of virtual network resources, capable of delivering end- 512 to-en services optimisation of connectivity and virtual 513 infrastructure based on client interface and application 514 demands, technology constraints (bandwidth, latency, jitter, 515 function, etc.) and commercial constraints (energy, customer 516 SLA, etc.). 518 o Automation of virtual service and function requests and 519 objectives, and providing on-demand and self-service network 520 slicing. 522 o Infrastructure elasticity to allow rapid provisioning, automatic 523 scaling out, or in, of virtual resources. 525 o Virtual resource monitoring [Editor's Note: Control of 526 bandwidth, energy consumption and quality of service/packet 527 scheduling.] 529 [Editor's Note: The requirements on the technology driver from both 530 sides need to be analysed, e.g. the information update frequency.] 532 4.9. Resilience 534 [To be discussed.] 536 4.10. Security 538 Network programmability may introduce new security and 539 misconfiguration vulnerabilities. These must be investigated and 540 discussed, and then solved with suitable solutions. ACTN-based 541 networks must be resilient to existing, and new, faults and attacks. 542 Failure or security breach in one ACTN slice should not impact 543 another virtual network. It must also be possible for separation of 544 untrusted services and applications, along with confidential 545 services and applications that must be secured. 547 4.11. Policy 549 [To be discussed.] 551 4.12. Technology Independence 553 ACTN must support a variety of underlay transport technologies, 554 providing the flexibility to manage a variety of heterogeneous 555 network technologies. 557 4.13. Architecture Principles 559 4.13.1. Network Partitioning 561 Coexistence of multiple network slices will need to be supported. It 562 should also be possible for multiple network slices used by 563 different customers to coexist together, spanning over part or full 564 of the underlying physical networks. 566 4.13.2. Orchestration 568 ACTN should allow orchestration (automated co-ordination of 569 functions) for managing and controlling virtual network services 570 that may span multiple Service Providers and Network Providers. 572 4.13.3. Recursion 574 It should be possible for a network slice to be segmented to allow a 575 slicing hierarchy with parent child relationships. Allowing a 576 customer to become a virtual provider, this is known as recursion as 577 well as nesting of network slices. 579 4.13.4. Legacy Support 581 Capability to deploy ACTN should be transparent to existing physical 582 network control and management mechanisms and protocols. 584 5. References 586 5.1. Informative References 588 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 589 "Generalized Multiprotocol Label Switching (GMPLS) User- 590 Network Interface (UNI): Resource ReserVation Protocol- 591 Traffic Engineering (RSVP-TE) Support for the Overlay 592 Model", RFC 4208, October 2005. 594 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 595 Provider-Provisioned Virtual Private Networks (PPVPNs)", 596 RFC 4110, July 2005. 598 [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1 599 Virtual Private Networks", RFC 4847, April 2007. 601 [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 2 602 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006. 604 [RFC4665] W. Augustyn, Ed. and Y. Serbest, Ed., "Service 605 Requirements for Layer 2 Provider-Provisioned Virtual 606 Private Networks", RFC 4665, September 2006. 608 [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation 609 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 610 March 2009. 612 6. Acknowledgements 614 The authors wish to thank the contributions on the IETF ACTN mailing 615 list. 617 Authors' Addresses 619 Young Lee 620 Huawei Technologies 621 5340 Legacy Drive 622 Plano, TX 75023, USA 623 Phone: (469)277-5838 624 Email: leeyoung@huawei.com 626 Daniel King 627 Lancaster University 628 Email: d.king@lancaster.ac.uk 630 Intellectual Property Statement 632 The IETF Trust takes no position regarding the validity or scope of 633 any Intellectual Property Rights or other rights that might be 634 claimed to pertain to the implementation or use of the technology 635 described in any IETF Document or the extent to which any license 636 under such rights might or might not be available; nor does it 637 represent that it has made any independent effort to identify any 638 such rights. 640 Copies of Intellectual Property disclosures made to the IETF 641 Secretariat and any assurances of licenses to be made available, or 642 the result of an attempt made to obtain a general license or 643 permission for the use of such proprietary rights by implementers or 644 users of this specification can be obtained from the IETF on-line 645 IPR repository at http://www.ietf.org/ipr 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 any standard or specification contained in an IETF Document. Please 651 address the information to the IETF at ietf-ipr@ietf.org. 653 Disclaimer of Validity 655 All IETF Documents and the information contained therein are 656 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 657 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 658 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 659 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 660 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 661 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 662 FOR A PARTICULAR PURPOSE. 664 Acknowledgment 666 Funding for the RFC Editor function is currently provided by the 667 Internet Society.