idnits 2.17.1 draft-leeking-actn-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 date (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-01 == Outdated reference: A later version (-05) exists of draft-boucadair-network-automation-requirements-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Lee 2 Internet Draft Huawei 3 Intended status: Informational D. King 4 Expires: August, 2014. Lancaster University 5 M. Boucadair 6 France Telecom 7 R. Jing 8 China Telecom 9 February 14, 2014 11 Problem Statement for Abstraction and Control of Transport Networks 13 draft-leeking-actn-problem-statement-01.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 5, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 Previously transport networks were typically static, lacked 56 flexibility, and required long planning times when deploying new 57 services. Network Providers and Service Providers have embraced 58 technologies that allow separation of data plane and control plane, 59 distributed signaling for path setup and protection, and centralized 60 path computation for service planning and traffic engineering. 61 Although these technologies provide significant benefits, they do 62 not meet the growing need for network programmability, automation, 63 resource sharing, and service elasticity necessary for meeting 64 customer demands and evolving Internet applications 66 By combining the aforementioned capabilities with network resource 67 virtualization and abstraction mechanisms, available via well- 68 defined customer interfaces, providing significant operational 69 benefits to meet the growing demands from customers and 70 applications. The work effort investigating this problem space is 71 known as Abstraction and Control of Transport Networks (ACTN). 73 This document provides an ACTN problem description, scope of work, 74 and outlines the core requirements to facilitate network resource 75 virtualization and resource slicing for customers and applications, 76 across Service Provider and Network Provider transport network 77 infrastructure. 79 Table of Contents 81 1. Introduction...................................................3 82 1.1. Terminology...............................................4 83 2. Relationship with Existing Technologies........................5 84 2.1. Virtual Private Networks..................................5 85 2.2. Overlay Networks..........................................6 86 3. Motivations for Additional Functionality.......................6 87 3.1. Business Objectives.......................................6 88 3.2. Network Resource Recursiveness............................7 89 3.3. Customer-Initiated Programmability........................8 90 3.4. Resource Partitioning.....................................8 91 3.5. Service Orchestration.....................................8 92 4. ACTN Objectives and Requirements...............................8 93 4.1. Capability and Resource Discovery.........................9 94 4.2. Network Programmability...................................9 95 4.3. Common Data Models........................................9 96 4.4. Scheduling and Allocation.................................10 97 4.5. Adaptability..............................................11 98 4.6. Slicing...................................................11 99 4.7. Isolation.................................................11 100 4.8. Manageability.............................................11 101 4.9. Resilience................................................11 102 4.10. Security.................................................12 103 4.11. Policy...................................................12 104 4.12. Technology Independence..................................12 105 4.13. Architecture Principles..................................12 106 4.13.1. Network Partitioning.................................12 107 4.13.2. Orchestration........................................12 108 4.13.3. Recursion............................................12 109 4.13.4. Legacy Support.......................................12 110 4.14. Other Work...............................................12 111 4.14.1 Requirements for Automated (Configuration) Management.13 112 4.14.2 Connectivity Provisioning Negotiation Protocol (CPNP).13 113 5. References.....................................................13 114 5.1. Informative References....................................13 115 6. Contributors...................................................14 116 7. IANA Considerations............................................14 117 Authors' Addresses................................................14 118 Intellectual Property Statement...................................15 119 Disclaimer of Validity............................................15 121 1. Introduction 123 Customers continue to demand new services that are time scheduled, 124 dynamic, and underpinned by a Pay As You Go billing model. These 125 services are provided to customers by Network Providers and Service 126 Providers and give rise to a variety of applications for office 127 automation, data backup and retrieval, distributed computing, and 128 high-quality media broadcasting. They offer Network and Service 129 Providers new revenue generation opportunities, and these services 130 typically have different traffic characteristics from established 131 network services such as file hosting, web, and email. Deploying and 132 operating these new applications and services using traditional 133 network architectures limits network efficiency, scalability, and 134 elasticity (i.e., capable of adapting to customer and application 135 demands). 137 Network virtualization has been a significant innovation towards 138 meeting customer demands, and enabling new applications and 139 services. Separating network resources, and representing resources 140 and topologies via abstracted concepts, facilitate effective 141 sharing, or slicing, of physical infrastructure into virtual network 142 service instances corresponding to multiple virtual network 143 topologies that may be used by specific applications and services. 144 Further development is required to allow customers to create, 145 modify, and delete virtual network services dynamically. 147 Abstraction and Control of Transport Networks (ACTN) defines new 148 methods and capabilities for the deployment and operation of 149 transport network resource. These are summarized as: 151 o Abstraction of underlying network resources to higher-layer 152 applications and customers; 154 o Slicing of network resources to meet specific application and 155 customer requirements; 157 o Provision of a computation scheme and virtual control 158 capability, via an data model, to customers who request virtual 159 network services; 161 o Coordination of underlying transport layers and presentation as 162 an abstracted topology to the customer. 164 This document provides an ACTN problem description and scope of 165 work, and outlines the core requirements to facilitate network 166 resource virtualization and resource slicing for Network Providers, 167 Service Providers, Customers, and applications. 169 1.1. Terminology 171 This document uses the terminology defined in [RFC4655], and 172 [RFC5440]. Additional terms are defined below. 174 o Customers: 176 Customers are users of virtual network services. They are provided 177 with an abstract resource view of the network resource (known as "a 178 slice") to support their users and applications. In some cases, 179 customers may have to support multiple virtual network services with 180 different service objectives and QoS requirements to support 181 multiple types of users and applications. 183 o Service Providers (also Virtual Network Service Provider): 185 Service Providers are the providers of virtual network services to 186 their customers. Service Providers typically lease resources from 187 single or multiple Network Providers' facilities to create virtual 188 network services and offer end-to-end services to their customers. 189 A Virtual Network Service Provider is a type of Service Provider, 190 except that they own no physical equipment or infrastructure, and 191 only provide services built upon virtual network infrastructure. In 192 general, this document does not distinguish between a Virtual 193 Network Service Provider and Service Provider. 195 o Network Providers: 197 Network Providers are the infrastructure providers that own the 198 physical network resources and provide transport network resources 199 to their customers. Service Providers can be the customers of 200 Network Providers or can be the Network Providers themselves. 202 o Network Virtualization: 204 Network virtualization, refers to allowing the customers to utilize 205 a certain network resources as if they own them and thus allows them 206 to control their allocated resources in a way most optimal with 207 higher layer or application processes. This customer control 208 facilitates the introduction of new applications (on top of 209 available services) as the customers are given programmable 210 interfaces to create, modify, and delete their virtual network 211 services. 213 o Transport Networks 215 Transport networks are defined as network infrastructure that 216 provides connectivity and bandwidth for customer services. They are 217 characterized by their ability to support server layer provisioning 218 and traffic engineering for client layer services, such that 219 resource guarantees may be provided to their customers. Transport 220 networks in this document refer to a set of different type of 221 connection-oriented networks, which include Connection-Oriented 222 Circuit Switched (CO-CS) networks and Connection-Oriented Packet 223 Switched (CO-PS) networks. This implies that at least the following 224 transport networks are in scope of the discussion of this draft: 225 Layer 1 (L1) optical networks (e.g., Optical Transport Networks 226 (OTN) and Wavelength Switched Optical Networks (WSON)), MPLS-TP, 227 MPLS-TE, as well as other emerging network technologies with 228 connection-oriented behavior. 230 2. Relationship with Existing Technologies 232 2.1. Virtual Private Networks 234 A Virtual Private Network (VPN) is a well-known concept [RFC4110], 235 [RFC4664] and [RFC4847], and may be used to connect multiple 236 distributed sites via a variety of transport technologies, sometimes 237 over shared network infrastructure. 239 Typically VPNs are managed and provisioned directly by the Network 240 Provider or a VPN Service Provider. VPN systems may be classified 241 by: 243 o Protocol mechanisms used to tunnel the traffic; 244 o Tunnel termination point and/or location; 246 o Type of connectivity, site-to-site or remote-access; 248 o Quality of Service (QoS) capabilities; 250 o Level of security provided; 252 o Emulated service connectivity layer (layer 1, layer 2, 253 layer 3); 255 Existing VPN solutions are largely technology specific and offer 256 limited elasticity, although some technologies offer greater 257 flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs 258 [RFC4110]) when compared with layer 1 VPNs [RFC4847], all 259 technologies are often deployed using pre-defined configurations. 260 The transport layer is achieved by utilizing a variety of 261 technology-specific interfaces - e.g. Gigabit Ethernet (GE), 262 Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer Mode 263 (ATM) for wireless back-hauling, or optical networks OTN and WSON). 265 VPNs offer a scalable tunnel solution for customer traffic; however 266 they are wholly dependent on the Service Provider to setup and 267 manage the VPNs, lacking customer-initiated service programmability: 268 creation, resizing, and deletion. 270 2.2. Overlay Networks 272 An overlay network [RFC4208] provides an enhanced network 273 virtualization technique, with the overlay network providing a 274 topology comprised of virtual or logical links and nodes, which are 275 built on top of physical nodes and links, providing a topology in 276 which some of the links and nodes are virtual or logical and are 277 built from multiple nodes or links in a server network. 279 Overlay networks are typically used in the multi-layer context, in 280 which the packet layer is a client to the server transport layer. 281 The scope of network virtualization in overlay networks is somewhat 282 limited. Customers and applications which need visibility or 283 programmability, and the ability to resize or add resources, may 284 find that overlay network technologies do meet their requirements. 286 3. Motivations for Additional Functionality 288 3.1. Business Objectives 290 The traditional VPN and overlay network (ON) models are built on the 291 premise that one single Network Provider provides all virtual 292 private or overlay networks to its customers. This model is simple 293 to operate but has some disadvantages in accommodating the 294 increasing need for flexible and dynamic network virtualization 295 capabilities. 297 A Network Provider may provide traditional end-to-end services and 298 content (i.e., web and email) to its customers. Emerging services, 299 applications and content are typically provided via Service 300 Providers and Over the Top (OTT) (i.e., Video-on-demand, Social 301 Media) providers. We can further categorize Service Providers as: 303 o A fixed or mobile Internet Service Providers (ISPs) which provide 304 Internet connectivity and bandwidth to uses; 306 o A service provider that leases network resources from one or more 307 network providers to create virtual network services between ISPs 308 and the core Internet. 310 o Data Center (DC)/content Network Provider and Service Providers 311 who provide connectivity and bandwidth to content servers and 312 application servers. 314 Network Providers and Service Providers of every type, all share the 315 common business and revenue objectives: 317 o Minimize time to plan and deploy new services; 319 o Reduce the reliance on highly skilled personnel to operate their 320 network; 322 o Reduce time to react to changing business demands and customer 323 applications; 325 o Offer new, much more flexible services to their customers; 327 o Maximize network resource usage and efficiency. 329 All aforementioned objectives have the capability to significant 330 increase revenue and reduce operational costs. 332 Network and Service Providers require capabilities that extend the 333 current landscape of network virtualization capabilities and overall 334 business objectives of the Network Provider, Service Provider, and 335 ultimately the Customer and their Applications. 337 3.2. Network Resource Recursiveness 339 A newly emerged network virtualization environment is a collection 340 of heterogeneous network architectures from different players. VPNs 341 and overlay networks are somewhat limited in addressing programmable 342 interfaces for application or customer layers as well as for the 343 service layer. The model must be extended to address a recursive 344 nature of layer interactions in network virtualization across 345 transport networks, service networks, and customers/applications. 347 3.3. Customer-Initiated Programmability 349 Network-driven technologies such as VPNs and overlay networks 350 provide customers with a set of pre-defined programmatic parameters 351 to enable virtual networks. However, this model is limited to only 352 allow programmable interfaces in which customers initiate and define 353 virtual network services. This model must be extended to allow 354 customer-initiated network programmability. 356 3.4. Resource Partitioning 358 The ability to slice and allocate transport resources for Service 359 Providers would be beneficial. It would improve transport network 360 resource efficiency and provide a method for the transport Network 361 Provider to offer resource flexibility and control to Service 362 Providers and users. 364 3.5. Service Orchestration 366 Another dimension is diversity on the customer side. Customers in 367 this newly emerged network virtualization environment bring 368 different dynamics than the traditional VPNs or Overlay Networks. 369 There may be a multiple virtual slices that need to be created, 370 managed and deleted, each interfacing to a number of Service 371 Providers and Network Providers as the end-points of the clients 372 span across multiple network domains. Thus, multiple components will 373 require automated co-ordination and management, this is known as 374 service orchestration and is therefore one of the key capabilities 375 that should be provided. 377 4. ACTN Objectives and Requirements 379 The overall goal of enabling network abstraction and multiple 380 concurrent virtual networks to coexist together on a shared physical 381 infrastructure, comprised on multiple physical layers, and may be 382 subdivided into several smaller objectives. These are outlined below 383 and are required in order to fulfill the design goals of ACTN. 385 The ACTN effort should utilize existing physical layer monitoring 386 capabilities, algorithmic representation and modelling of physical 387 layer resources to consider transport appropriate metrics and 388 constraints. Moreover, the model may want to support dynamic 389 collection of the statistics (i.e., status and availability) of the 390 underlying transport network infrastructure. 392 4.1. Capability and Resource Discovery 394 It may be necessary for the application or Customer to discover 395 available capabilities and available network resources, for example, 396 abstracted resource view and control. Furthermore, capabilities and 397 resources will also include: 399 o Peering Points (may be based on business SLAs or policies); 401 o Transport Topology (i.e., transport switching type, topology and 402 connection points); 404 o Transport Capacity (i.e., current bandwidth and maximum 405 bandwidth). 407 o Policy Management (i.e., what resources and capabilities are 408 available, and what may be requested and by whom. 410 4.2. Network Programmability 412 A programmable interface should provide customers with the 413 capabilities to dynamically create, deploy, and operate services in 414 response to customer and application demands. To enable the on- 415 demand services, the separation of control and forwarding is a 416 fundamental requirement. Once this separation is achieved the 417 network layer may be programmed irrespective of the underlying 418 forwarding mechanism. 420 The creation of a programmable abstraction layer for physical 421 network devices would provide distributed computing objects which 422 would allow operators to manipulate the network resources. By 423 utilizing open programmable north-bound network interfaces, it would 424 enable access to virtual control layer by customer interfaces and 425 applications. 427 4.3. Common Data Models 429 The abstraction of the underlay transport, and resource information 430 representation model should describe each technology type within the 431 ACTN framework; they will all follow a uniform structure, which is 432 extensible to support any future technologies. 434 Such models will represent the physical resources as a set of 435 attributes, characteristics and functionality, while adaptively 436 capturing the true real-time and dynamic (real-time) properties of 437 underlying physical resources. 439 For future discussion, abstraction and the technology agnostic 440 virtualization requirements may benefit from being split into new 441 sub-sections, suggested below: 443 o Attributes 445 o Metrics 447 o Control Actions 449 o Semantics 451 Resources will be described with semantic methods so that the 452 resource description models can be exposed in a uniformly structured 453 manner to the upper layers. 455 Virtual infrastructure requests from ACTN customers will be 456 translated into network parameters according to aforementioned 457 network abstraction model. Utilizing this mechanism, a request is 458 translated into topology and multi-dimensional nodes, interfaces and 459 spectrum space with specific attributes such as bandwidth, QoS, and 460 node capability. 462 4.4. Scheduling and Allocation 464 When requesting network slices it should be possible to request an 465 immediate or scheduled service. When establishing a network slice, a 466 customer may require specific guarantees for the virtual node and 467 link attributes. This might include a request that guarantees 468 minimum packet processing on a virtual node, and fixed loss and 469 delay characteristics on the virtual links. 471 To provide such guarantees and to create an illusion of an isolated 472 and dedicated network slice to each customer, Network Providers must 473 employ appropriate scheduling algorithms in all of the network 474 elements. 476 4.5. Adaptability 478 Adaptability of services would allow the Service Provider, user, and 479 application to request modification of exist network resource that 480 has been assigned. This may include resizing of bandwidth, 481 modification of the topology, and adding/removing connectivity 482 points. 484 4.6. Slicing 486 It should be possible for transport network infrastructure to be 487 partitioned into multiple independent virtual networks known as 488 "slicing", based on provider service types, customers and 489 application requirements. 491 4.7. Isolation 492 Isolation, both of physical underlay infrastructure and of co- 493 existing virtual networks, and ensure no leakage of traffic. 494 Furthermore, there must be mechanisms that ensure that once network 495 slices are assigned Customer and Application services are not 496 competing for independent transport resources. 498 Each customer or application should be able to use arbitrary network 499 topology, routing, or forwarding functions as well as customized 500 control mechanisms independent of the underlying physical network 501 and other coexisting virtual networks. 503 It must also be possible for many virtual networks to share the 504 underlying infrastructure, without significantly impacting the 505 performance of applications utilizing the virtual networks. 507 4.8. Manageability 509 A broad range of capabilities, including: request, control, 510 provisioning, monitoring, resilience, adaptation and re-optimisation 511 of end-to-end services will need to be provided through a set of 512 well-defined interfaces, specifically it should be possible to 513 provide: 515 o Control of virtual network resources, capable of delivering end- 516 to-en services optimisation of connectivity and virtual 517 infrastructure based on client interface and application 518 demands, technology constraints (bandwidth, latency, jitter, 519 function, etc.) and commercial constraints (energy, customer 520 SLA, etc.). 522 o Automation of virtual service and function requests and 523 objectives, and providing on-demand and self-service network 524 slicing. 526 o Infrastructure elasticity to allow rapid provisioning, automatic 527 scaling out, or in, of virtual resources. 529 o Virtual resource monitoring [Editor's Note: Control of 530 bandwidth, energy consumption and quality of service/packet 531 scheduling.] 533 [Editor's Note: The requirements on the technology driver from both 534 sides need to be analysed, e.g. the information update frequency.] 536 4.9. Resilience 538 [To be discussed.] 540 4.10. Security 542 Network programmability may introduce new security and 543 misconfiguration vulnerabilities. These must be investigated and 544 discussed, and then solved with suitable solutions. ACTN-based 545 networks must be resilient to existing, and new, faults and attacks. 546 Failure or security breach in one ACTN slice should not impact 547 another virtual network. It must also be possible for separation of 548 untrusted services and applications, along with confidential 549 services and applications that must be secured. 551 4.11. Policy 553 [To be discussed.] 555 4.12. Technology Independence 557 ACTN must support a variety of underlay transport technologies, 558 providing the flexibility to manage a variety of heterogeneous 559 network technologies. 561 4.13. Architecture Principles 563 4.13.1. Network Partitioning 565 Coexistence of multiple network slices will need to be supported. It 566 should also be possible for multiple network slices used by 567 different customers to coexist together, spanning over part or full 568 of the underlying physical networks. 570 4.13.2. Orchestration 572 ACTN should allow orchestration (automated co-ordination of 573 functions) for managing and controlling virtual network services 574 that may span multiple Service Providers and Network Providers. 576 4.13.3. Recursion 578 It should be possible for a network slice to be segmented to allow a 579 slicing hierarchy with parent child relationships. Allowing a 580 customer to become a virtual provider, this is known as recursion as 581 well as nesting of network slices. 583 4.13.4. Legacy Support 585 Capability to deploy ACTN should be transparent to existing physical 586 network control and management mechanisms and protocols. 588 4.14. Other Work 589 4.14.1 Requirements for Automated (Configuration) Management 591 Given the ever-increasing complexity of the configuration tasks 592 required for the dynamic provisioning of IP networks and services, 593 [I-D.boucadair-network-automation-requirements] aims at 594 listing the requirements to drive the specification of an automated 595 configuration management framework, including the requirements for 596 a protocol to convey configuration information towards the managed 597 entities. 599 4.14.2 Connectivity Provisioning Negotiation Protocol (CPNP) 601 [I-D.boucadair-connectivity-provisioning-protocol] specifies 602 the Connectivity Provisioning Negotiation Protocol (CPNP) which is 603 used to facilitate the dynamic negotiation of service parameters 604 between a Customer and a Provider. As such, CPNP is a generic 605 protocol that can be used for various negotiation purposes that 606 include (but are not necessarily limited to) connectivity 607 provisioning services, storage facilities, CDN (Content 608 Delivery Networks) footprint, etc. 610 The generic CPP template allows for: 612 o Automating the process of service negotiation and activation, thus 613 accelerating service provisioning; 615 o Setting the (traffic) objectives of Traffic Engineering functions 616 and service management functions. 618 o Enriching service and network management systems with 'decision- 619 making' capabilities based on negotiated/offered CPPs. 621 5. References 623 5.1. Informative References 625 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 626 "Generalized Multiprotocol Label Switching (GMPLS) User- 627 Network Interface (UNI): Resource ReserVation Protocol- 628 Traffic Engineering (RSVP-TE) Support for the Overlay 629 Model", RFC 4208, October 2005. 631 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 632 Provider-Provisioned Virtual Private Networks (PPVPNs)", 633 RFC 4110, July 2005. 635 [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1 636 Virtual Private Networks", RFC 4847, April 2007. 638 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 639 Element (PCE)-Based Architecture", RFC 4655, August 2006. 641 [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 2 642 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006. 644 [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation 645 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 646 March 2009. 648 [I-D.boucadair-connectivity-provisioning-protocol] 649 Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 650 Negotiation Protocol (CPNP)", draft-boucadair- 651 connectivity-provisioning-protocol-01 (work in progress), 652 October 2013. 654 [I-D.boucadair-network-automation-requirements] 655 Boucadair, M. and C. Jacquenet, "Requirements for 656 Automated (Configuration) Management", draft-boucadair- 657 network-automation-requirements-02 (work in progress), 658 June 2013. 660 6. Acknowledgements 662 The authors wish to thank the contributions on the IETF ACTN mailing 663 list. 665 7. IANA Considerations 667 Authors' Addresses 669 Young Lee 670 Huawei Technologies 671 5340 Legacy Drive 672 Plano, TX 75023, USA 673 Phone: (469)277-5838 674 Email: leeyoung@huawei.com 676 Daniel King 677 Lancaster University 678 Email: d.king@lancaster.ac.uk 680 Mohamed Boucadair 681 France Telecom 682 Rennes 35000 683 France 684 Email: mohamed.boucadair@orange.com 685 Ruiquan Jing, 686 China Telecom Corporation Limited, 687 No. 118, Xizhimenneidajie, Xicheng District, Beijing, China 688 Email: jingrq@ctbri.com.cn 690 Intellectual Property Statement 692 The IETF Trust takes no position regarding the validity or scope of 693 any Intellectual Property Rights or other rights that might be 694 claimed to pertain to the implementation or use of the technology 695 described in any IETF Document or the extent to which any license 696 under such rights might or might not be available; nor does it 697 represent that it has made any independent effort to identify any 698 such rights. 700 Copies of Intellectual Property disclosures made to the IETF 701 Secretariat and any assurances of licenses to be made available, or 702 the result of an attempt made to obtain a general license or 703 permission for the use of such proprietary rights by implementers or 704 users of this specification can be obtained from the IETF on-line 705 IPR repository at http://www.ietf.org/ipr 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights that may cover technology that may be required to implement 710 any standard or specification contained in an IETF Document. Please 711 address the information to the IETF at ietf-ipr@ietf.org. 713 Disclaimer of Validity 715 All IETF Documents and the information contained therein are 716 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 717 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 718 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 719 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 720 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 721 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 722 FOR A PARTICULAR PURPOSE. 724 Acknowledgment 726 Funding for the RFC Editor function is currently provided by the 727 Internet Society.