Network Working Group                                            Y. Lee
Internet Draft                                                   Huawei
Intended status: Informational                                  D. King
Expires: August, 2014.                             Lancaster University
                                                           M. Boucadair
                                                         France Telecom
                                                                R. Jing
                                                          China Telecom
                                                      February 14, 2014


  Problem Statement for Abstraction and Control of Transport Networks

             draft-leeking-actn-problem-statement-01.txt



Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 5, 2014.

   Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of




Lee and King              Expires August, 2014                [Page 1]


Internet-Draft          ACTN Problem Statement            February 2014


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

   Abstract

   Previously transport networks were typically static, lacked
   flexibility, and required long planning times when deploying new
   services. Network Providers and Service Providers have embraced
   technologies that allow separation of data plane and control plane,
   distributed signaling for path setup and protection, and centralized
   path computation for service planning and traffic engineering.
   Although these technologies provide significant benefits, they do
   not meet the growing need for network programmability, automation,
   resource sharing, and service elasticity necessary for meeting
   customer demands and evolving Internet applications

   By combining the aforementioned capabilities with network resource
   virtualization and abstraction mechanisms, available via well-
   defined customer interfaces, providing significant operational
   benefits to meet the growing demands from customers and
   applications. The work effort investigating this problem space is
   known as Abstraction and Control of Transport Networks (ACTN).

   This document provides an ACTN problem description, scope of work,
   and outlines the core requirements to facilitate network resource
   virtualization and resource slicing for customers and applications,
   across Service Provider and Network Provider transport network
   infrastructure.


Table of Contents

   1. Introduction...................................................3
      1.1. Terminology...............................................4
   2. Relationship with Existing Technologies........................5
      2.1. Virtual Private Networks..................................5
      2.2. Overlay Networks..........................................6
   3. Motivations for Additional Functionality.......................6
      3.1. Business Objectives.......................................6
      3.2. Network Resource Recursiveness............................7
      3.3. Customer-Initiated Programmability........................8
      3.4. Resource Partitioning.....................................8
      3.5. Service Orchestration.....................................8
   4. ACTN Objectives and Requirements...............................8


Lee and King              Expires August, 2014                [Page 2]


Internet-Draft          ACTN Problem Statement            February 2014


      4.1. Capability and Resource Discovery.........................9
      4.2. Network Programmability...................................9
      4.3. Common Data Models........................................9
      4.4. Scheduling and Allocation.................................10
      4.5. Adaptability..............................................11
      4.6. Slicing...................................................11
      4.7. Isolation.................................................11
      4.8. Manageability.............................................11
      4.9. Resilience................................................11
      4.10. Security.................................................12
      4.11. Policy...................................................12
      4.12. Technology Independence..................................12
      4.13. Architecture Principles..................................12
        4.13.1. Network Partitioning.................................12
        4.13.2. Orchestration........................................12
        4.13.3. Recursion............................................12
        4.13.4. Legacy Support.......................................12
      4.14. Other Work...............................................12
        4.14.1 Requirements for Automated (Configuration) Management.13
        4.14.2 Connectivity Provisioning Negotiation Protocol (CPNP).13
   5. References.....................................................13
      5.1. Informative References....................................13
   6. Contributors...................................................14
   7. IANA Considerations............................................14
   Authors' Addresses................................................14
   Intellectual Property Statement...................................15
   Disclaimer of Validity............................................15

1. Introduction

   Customers continue to demand new services that are time scheduled,
   dynamic, and underpinned by a Pay As You Go billing model.  These
   services are provided to customers by Network Providers and Service
   Providers and give rise to a variety of applications for office
   automation, data backup and retrieval, distributed computing, and
   high-quality media broadcasting. They offer Network and Service
   Providers new revenue generation opportunities, and these services
   typically have different traffic characteristics from established
   network services such as file hosting, web, and email. Deploying and
   operating these new applications and services using traditional
   network architectures limits network efficiency, scalability, and
   elasticity (i.e., capable of adapting to customer and application
   demands).

   Network virtualization has been a significant innovation towards
   meeting customer demands, and enabling new applications and
   services. Separating network resources, and representing resources
   and topologies via abstracted concepts, facilitate effective
   sharing, or slicing, of physical infrastructure into virtual network
   service instances corresponding to multiple virtual network
   topologies that may be used by specific applications and services.
   Further development is required to allow customers to create,
   modify, and delete virtual network services dynamically.

Lee and King              Expires August, 2014                [Page 3]


Internet-Draft          ACTN Problem Statement            February 2014


   Abstraction and Control of Transport Networks (ACTN) defines new
   methods and capabilities for the deployment and operation of
   transport network resource. These are summarized as:


     o Abstraction of underlying network resources to higher-layer
       applications and customers;

     o Slicing of network resources to meet specific application and
       customer requirements;

     o Provision of a computation scheme and virtual control
       capability, via an data model, to customers who request virtual
       network services;

     o Coordination of underlying transport layers and presentation as
       an abstracted topology to the customer.

   This document provides an ACTN problem description and scope of
   work, and outlines the core requirements to facilitate network
   resource virtualization and resource slicing for Network Providers,
   Service Providers, Customers, and applications.

1.1. Terminology

   This document uses the terminology defined in [RFC4655], and
   [RFC5440]. Additional terms are defined below.

     o Customers:

   Customers are users of virtual network services. They are provided
   with an abstract resource view of the network resource (known as "a
   slice") to support their users and applications. In some cases,
   customers may have to support multiple virtual network services with
   different service objectives and QoS requirements to support
   multiple types of users and applications.

     o Service Providers (also Virtual Network Service Provider):

   Service Providers are the providers of virtual network services to
   their customers. Service Providers typically lease resources from
   single or multiple Network Providers' facilities to create virtual
   network services and offer end-to-end services to their customers.
   A Virtual Network Service Provider is a type of Service Provider,
   except that they own no physical equipment or infrastructure, and
   only provide services built upon virtual network infrastructure. In
   general, this document does not distinguish between a Virtual
   Network Service Provider and Service Provider.


Lee and King              Expires August, 2014                [Page 4]


Internet-Draft          ACTN Problem Statement            February 2014


     o Network Providers:

   Network Providers are the infrastructure providers that own the
   physical network resources and provide transport network resources
   to their customers. Service Providers can be the customers of
   Network Providers or can be the Network Providers themselves.

     o Network Virtualization:

   Network virtualization, refers to allowing the customers to utilize
   a certain network resources as if they own them and thus allows them
   to control their allocated resources in a way most optimal with
   higher layer or application processes. This customer control
   facilitates the introduction of new applications (on top of
   available services) as the customers are given programmable
   interfaces to create, modify, and delete their virtual network
   services.

     o Transport Networks

   Transport networks are defined as network infrastructure that
   provides connectivity and bandwidth for customer services. They are
   characterized by their ability to support server layer provisioning
   and traffic engineering for client layer services, such that
   resource guarantees may be provided to their customers. Transport
   networks in this document refer to a set of different type of
   connection-oriented networks, which include Connection-Oriented
   Circuit Switched (CO-CS) networks and Connection-Oriented Packet
   Switched (CO-PS) networks. This implies that at least the following
   transport networks are in scope of the discussion of this draft:
   Layer 1 (L1) optical networks (e.g., Optical Transport Networks
   (OTN) and Wavelength Switched Optical Networks (WSON)), MPLS-TP,
   MPLS-TE, as well as other emerging network technologies with
   connection-oriented behavior.


2. Relationship with Existing Technologies

2.1. Virtual Private Networks

   A Virtual Private Network (VPN) is a well-known concept [RFC4110],
   [RFC4664] and [RFC4847], and may be used to connect multiple
   distributed sites via a variety of transport technologies, sometimes
   over shared network infrastructure.

   Typically VPNs are managed and provisioned directly by the Network
   Provider or a VPN Service Provider. VPN systems may be classified
   by:

      o Protocol mechanisms used to tunnel the traffic;

Lee and King              Expires August, 2014                [Page 5]


Internet-Draft          ACTN Problem Statement            February 2014


      o Tunnel termination point and/or location;

      o Type of connectivity, site-to-site or remote-access;

      o Quality of Service (QoS) capabilities;

      o Level of security provided;

      o Emulated service connectivity layer  (layer 1, layer 2,
        layer 3);

   Existing VPN solutions are largely technology specific and offer
   limited elasticity, although some technologies offer greater
   flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs
   [RFC4110]) when compared with layer 1 VPNs [RFC4847], all
   technologies are often deployed using pre-defined configurations.
   The transport layer is achieved by utilizing a variety of
   technology-specific interfaces - e.g. Gigabit Ethernet (GE),
   Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer Mode
   (ATM) for wireless back-hauling, or optical networks OTN and WSON).

   VPNs offer a scalable tunnel solution for customer traffic; however
   they are wholly dependent on the Service Provider to setup and
   manage the VPNs, lacking customer-initiated service programmability:
   creation, resizing, and deletion.

2.2. Overlay Networks

   An overlay network [RFC4208] provides an enhanced network
   virtualization technique, with the overlay network providing a
   topology comprised of virtual or logical links and nodes, which are
   built on top of physical nodes and links, providing a topology in
   which some of the links and nodes are virtual or logical and are
   built from multiple nodes or links in a server network.

   Overlay networks are typically used in the multi-layer context, in
   which the packet layer is a client to the server transport layer.
   The scope of network virtualization in overlay networks is somewhat
   limited. Customers and applications which need visibility or
   programmability, and the ability to resize or add resources, may
   find that overlay network technologies do meet their requirements.

3. Motivations for Additional Functionality

  3.1. Business Objectives

   The traditional VPN and overlay network (ON) models are built on the
   premise that one single Network Provider provides all virtual



Lee and King              Expires August, 2014                [Page 6]


Internet-Draft          ACTN Problem Statement            February 2014

   private or overlay networks to its customers. This model is simple
   to operate but has some disadvantages in accommodating the
   increasing need for flexible and dynamic network virtualization
   capabilities.

   A Network Provider may provide traditional end-to-end services and
   content (i.e., web and email) to its customers. Emerging services,
   applications and content are typically provided via Service
   Providers and Over the Top (OTT) (i.e., Video-on-demand, Social
   Media) providers. We can further categorize Service Providers as:

   o A fixed or mobile Internet Service Providers (ISPs) which provide
   Internet connectivity and bandwidth to uses;

   o A service provider that leases network resources from one or more
   network providers to create virtual network services between ISPs
   and the core Internet.

   o Data Center (DC)/content Network Provider and Service Providers
   who provide connectivity and bandwidth to content servers and
   application servers.

   Network Providers and Service Providers of every type, all share the
   common business and revenue objectives:

   o Minimize time to plan and deploy new services;

   o Reduce the reliance on highly skilled personnel to operate their
   network;

   o Reduce time to react to changing business demands and customer
   applications;

   o Offer new, much more flexible services to their customers;

   o Maximize network resource usage and efficiency.

   All aforementioned objectives have the capability to significant
   increase revenue and reduce operational costs.

   Network and Service Providers require capabilities that extend the
   current landscape of network virtualization capabilities and overall
   business objectives of the Network Provider, Service Provider, and
   ultimately the Customer and their Applications.

3.2. Network Resource Recursiveness

   A newly emerged network virtualization environment is a collection
   of heterogeneous network architectures from different players. VPNs
   and overlay networks are somewhat limited in addressing programmable


Lee and King              Expires August, 2014                [Page 7]


Internet-Draft          ACTN Problem Statement            February 2014


   interfaces for application or customer layers as well as for the
   service layer. The model must be extended to address a recursive
   nature of layer interactions in network virtualization across
   transport networks, service networks, and customers/applications.

3.3. Customer-Initiated Programmability

   Network-driven technologies such as VPNs and overlay networks
   provide customers with a set of pre-defined programmatic parameters
   to enable virtual networks. However, this model is limited to only
   allow programmable interfaces in which customers initiate and define
   virtual network services. This model must be extended to allow
   customer-initiated network programmability.

3.4. Resource Partitioning

   The ability to slice and allocate transport resources for Service
   Providers would be beneficial. It would improve transport network
   resource efficiency and provide a method for the transport Network
   Provider to offer resource flexibility and control to Service
   Providers and users.

3.5. Service Orchestration

   Another dimension is diversity on the customer side. Customers in
   this newly emerged network virtualization environment bring
   different dynamics than the traditional VPNs or Overlay Networks.
   There may be a multiple virtual slices that need to be created,
   managed and deleted, each interfacing to a number of Service
   Providers and Network Providers as the end-points of the clients
   span across multiple network domains. Thus, multiple components will
   require automated co-ordination and management, this is known as
   service orchestration and is therefore one of the key capabilities
   that should be provided.

4. ACTN Objectives and Requirements

   The overall goal of enabling network abstraction and multiple
   concurrent virtual networks to coexist together on a shared physical
   infrastructure, comprised on multiple physical layers, and may be
   subdivided into several smaller objectives. These are outlined below
   and are required in order to fulfill the design goals of ACTN.

   The ACTN effort should utilize existing physical layer monitoring
   capabilities, algorithmic representation and modelling of physical
   layer resources to consider transport appropriate metrics and
   constraints. Moreover, the model may want to support dynamic
   collection of the statistics (i.e., status and availability) of the
   underlying transport network infrastructure.


Lee and King              Expires August, 2014                [Page 8]


Internet-Draft          ACTN Problem Statement            February 2014


4.1. Capability and Resource Discovery

   It may be necessary for the application or Customer to discover
   available capabilities and available network resources, for example,
   abstracted resource view and control. Furthermore, capabilities and
   resources will also include:

   o Peering Points (may be based on business SLAs or policies);

   o Transport Topology (i.e., transport switching type, topology and
   connection points);

   o Transport Capacity (i.e., current bandwidth and maximum
   bandwidth).

   o Policy Management (i.e., what resources and capabilities are
   available, and what may be requested and by whom.

4.2. Network Programmability

    A programmable interface should provide customers with the
   capabilities to dynamically create, deploy, and operate services in
   response to customer and application demands. To enable the on-
   demand services, the separation of control and forwarding is a
   fundamental requirement. Once this separation is achieved the
   network layer may be programmed irrespective of the underlying
   forwarding mechanism.

   The creation of a programmable abstraction layer for physical
   network devices would provide distributed computing objects which
   would allow operators to manipulate the network resources. By
   utilizing open programmable north-bound network interfaces, it would
   enable access to virtual control layer by customer interfaces and
   applications.

4.3. Common Data Models

   The abstraction of the underlay transport, and resource information
   representation model should describe each technology type within the
   ACTN framework; they will all follow a uniform structure, which is
   extensible to support any future technologies.

   Such models will represent the physical resources as a set of
   attributes, characteristics and functionality, while adaptively
   capturing the true real-time and dynamic (real-time) properties of
   underlying physical resources.

   For future discussion, abstraction and the technology agnostic
   virtualization requirements may benefit from being split into new
   sub-sections, suggested below:

Lee and King              Expires August, 2014                [Page 9]


Internet-Draft          ACTN Problem Statement            February 2014


      o Attributes

      o Metrics

      o Control Actions

      o Semantics

   Resources will be described with semantic methods so that the
   resource description models can be exposed in a uniformly structured
   manner to the upper layers.

   Virtual infrastructure requests from ACTN customers will be
   translated into network parameters according to aforementioned
   network abstraction model. Utilizing this mechanism, a request is
   translated into topology and multi-dimensional nodes, interfaces and
   spectrum space with specific attributes such as bandwidth, QoS, and
   node capability.

4.4. Scheduling and Allocation

   When requesting network slices it should be possible to request an
   immediate or scheduled service. When establishing a network slice, a
   customer may require specific guarantees for the virtual node and
   link attributes. This might include a request that guarantees
   minimum packet processing on a virtual node, and fixed loss and
   delay characteristics on the virtual links.

   To provide such guarantees and to create an illusion of an isolated
   and dedicated network slice to each customer, Network Providers must
   employ appropriate scheduling algorithms in all of the network
   elements.

4.5. Adaptability

   Adaptability of services would allow the Service Provider, user, and
   application to request modification of exist network resource that
   has been assigned. This may include resizing of bandwidth,
   modification of the topology, and adding/removing connectivity
   points.

4.6. Slicing

   It should be possible for transport network infrastructure to be
   partitioned into multiple independent virtual networks known as
   "slicing", based on provider service types, customers and
   application requirements.

4.7. Isolation


Lee and King              Expires August, 2014                [Page 10]


Internet-Draft          ACTN Problem Statement            February 2014


   Isolation, both of physical underlay infrastructure and of co-
   existing virtual networks, and ensure no leakage of traffic.
   Furthermore, there must be mechanisms that ensure that once network
   slices are assigned Customer and Application services are not
   competing for independent transport resources.

   Each customer or application should be able to use arbitrary network
   topology, routing, or forwarding functions as well as customized
   control mechanisms independent of the underlying physical network
   and other coexisting virtual networks.

   It must also be possible for many virtual networks to share the
   underlying infrastructure, without significantly impacting the
   performance of applications utilizing the virtual networks.

4.8. Manageability

   A broad range of capabilities, including: request, control,
   provisioning, monitoring, resilience, adaptation and re-optimisation
   of end-to-end services will need to be provided through a set of
   well-defined interfaces, specifically it should be possible to
   provide:

     o Control of virtual network resources, capable of delivering end-
       to-en services optimisation of connectivity and virtual
       infrastructure based on client interface and application
       demands, technology constraints (bandwidth, latency, jitter,
       function, etc.) and commercial constraints (energy, customer
       SLA, etc.).

     o Automation of virtual service and function requests and
       objectives, and providing on-demand and self-service network
       slicing.

     o Infrastructure elasticity to allow rapid provisioning, automatic
       scaling out, or in, of virtual resources.

     o Virtual resource monitoring [Editor's Note: Control of
       bandwidth, energy consumption and quality of service/packet
       scheduling.]

   [Editor's Note: The requirements on the technology driver from both
   sides need to be analysed, e.g. the information update frequency.]

4.9. Resilience

   [To be discussed.]



Lee & King               Expires August, 2014                 [Page 11]


Internet-Draft          ACTN Problem Statement            February 2014


4.10. Security

   Network programmability may introduce new security and
   misconfiguration vulnerabilities. These must be investigated and
   discussed, and then solved with suitable solutions. ACTN-based
   networks must be resilient to existing, and new, faults and attacks.
   Failure or security breach in one ACTN slice should not impact
   another virtual network. It must also be possible for separation of
   untrusted services and applications, along with confidential
   services and applications that must be secured.

4.11.  Policy

   [To be discussed.]

4.12. Technology Independence

   ACTN must support a variety of underlay transport technologies,
   providing the flexibility to manage a variety of heterogeneous
   network technologies.

4.13. Architecture Principles

4.13.1. Network Partitioning

   Coexistence of multiple network slices will need to be supported. It
   should also be possible for multiple network slices used by
   different customers to coexist together, spanning over part or full
   of the underlying physical networks.

4.13.2. Orchestration

   ACTN should allow orchestration (automated co-ordination of
   functions) for managing and controlling virtual network services
   that may span multiple Service Providers and Network Providers.

4.13.3. Recursion

   It should be possible for a network slice to be segmented to allow a
   slicing hierarchy with parent child relationships. Allowing a
   customer to become a virtual provider, this is known as recursion as
   well as nesting of network slices.

4.13.4. Legacy Support

   Capability to deploy ACTN should be transparent to existing physical
   network control and management mechanisms and protocols.

4.14. Other Work



Lee & King               Expires August, 2014                 [Page 12]


Internet-Draft          ACTN Problem Statement            February 2014


4.14.1 Requirements for Automated (Configuration) Management

   Given the ever-increasing complexity of the configuration tasks
   required for the dynamic provisioning of IP networks and services,
   [I-D.boucadair-network-automation-requirements] aims at
   listing the requirements to drive the specification of an automated
   configuration management framework, including the requirements for
   a protocol to convey configuration information towards the managed
   entities.

4.14.2 Connectivity Provisioning Negotiation Protocol (CPNP)

   [I-D.boucadair-connectivity-provisioning-protocol] specifies
   the Connectivity Provisioning Negotiation Protocol (CPNP) which is
   used to facilitate the dynamic negotiation of service parameters
   between a Customer and a Provider.  As such, CPNP is a generic
   protocol that can be used for various negotiation purposes that
   include (but are not necessarily limited to) connectivity
   provisioning services, storage facilities, CDN (Content
   Delivery Networks) footprint, etc.

   The generic CPP template allows for:

   o  Automating the process of service negotiation and activation, thus
      accelerating service provisioning;

   o  Setting the (traffic) objectives of Traffic Engineering functions
      and service management functions.

   o  Enriching service and network management systems with 'decision-
      making' capabilities based on negotiated/offered CPPs.


5. References

5.1. Informative References

   [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
             "Generalized Multiprotocol Label Switching (GMPLS) User-
             Network Interface (UNI): Resource ReserVation Protocol-
             Traffic Engineering (RSVP-TE) Support for the Overlay
             Model", RFC 4208, October 2005.

   [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
             Provider-Provisioned Virtual Private Networks (PPVPNs)",
             RFC 4110, July 2005.

   [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1
             Virtual Private Networks", RFC 4847, April 2007.


Lee & King               Expires August, 2014                 [Page 13]


Internet-Draft          ACTN Problem Statement            February 2014


   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 2
             Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006.

   [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation
             Element (PCE) Communication Protocol (PCEP)", RFC 5440,
             March 2009.

   [I-D.boucadair-connectivity-provisioning-protocol]
              Boucadair, M. and C. Jacquenet, "Connectivity Provisioning
              Negotiation Protocol (CPNP)", draft-boucadair-
              connectivity-provisioning-protocol-01 (work in progress),
              October 2013.

   [I-D.boucadair-network-automation-requirements]
              Boucadair, M. and C. Jacquenet, "Requirements for
              Automated (Configuration) Management", draft-boucadair-
              network-automation-requirements-02 (work in progress),
              June 2013.


6. Acknowledgements

   The authors wish to thank the contributions on the IETF ACTN mailing
   list.

7. IANA Considerations


Authors' Addresses

   Young Lee
   Huawei Technologies
   5340 Legacy Drive
   Plano, TX 75023, USA
   Phone: (469)277-5838
   Email: leeyoung@huawei.com

   Daniel King
   Lancaster University
   Email: d.king@lancaster.ac.uk

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France
   Email: mohamed.boucadair@orange.com

Lee & King               Expires August, 2014                 [Page 14]


Internet-Draft          ACTN Problem Statement            February 2014


   Ruiquan Jing,
   China Telecom Corporation Limited,
   No. 118, Xizhimenneidajie, Xicheng District, Beijing, China
   Email: jingrq@ctbri.com.cn



Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line
   IPR repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

   All IETF Documents and the information contained therein are
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
   HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
   THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.






Lee & King               Expires August, 2014                 [Page 15]

Internet-Draft          ACTN Problem Statement            February 2014