TEAS WG Young Lee Xian Zhang Internet Draft Huawei Intended status: Informational Daniel Ceccarrelli Expires: February 2017 Ericsson Bin Yeong Yoon ETRI Oscar Gonzalez de Dios Telefonica October 4, 2016 Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks draft-zhang-teas-actn-yang-01 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 January 4, 2017. Zhang, et al. Expires January 4, 2017 [Page 1] Internet-Draft ACTN YANG October 2016 Copyright Notice Copyright (c) 2016 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 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 Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network operations needed to orchestrate, control and manage large-scale multi-domain TE networks, so as to facilitate network programmability, automation, efficient resource sharing, and end-to- end virtual service aware connectivity and network function virtualization services. This document explains how the different types of YANG models defined in the Operations and Management Area and in the Routing Area are applicable to the ACTN framework. This document also shows how the ACTN architecture can be satisfied using classes of data model that have already been defined, and discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. Table of Contents 1. Introduction...................................................3 2. Abstraction and Control of TE Networks (ACTN) Architecture.....3 3. Service Models.................................................5 4. Service Model Mapping to ACTN..................................6 4.1. Customer Service Models in the ACTN Architecture (CMI)....9 4.2. Service Delivery Models in ACTN Architecture..............9 4.3. Network Configuration Models in ACTN Architecture (MPI)...9 4.4. Device Models in ACTN Architecture (SBI).................10 4.5. Advanced Models..........................................11 Zhang, et al. Expires January 4, 2017 [Page 2] Internet-Draft ACTN YANG October 2016 5. Examples of Using Different Types of YANG Models..............11 5.1. Simple Connectivity Examples.............................11 5.2. VN service example.......................................12 5.3. Data Center-Interconnection Example......................13 5.3.1. CMI (CNC-MDSC Interface)............................15 5.3.2. MPI (MDSC-PNC Interface)............................15 5.3.3. PDI (PNC-Device interface)..........................15 6. Security......................................................16 7. Acknowledgements..............................................16 8. References....................................................16 8.1. Informative References...................................16 9. Contributors..................................................18 Authors' Addresses...............................................19 1. Introduction Abstraction and Control of TE Networks (ACTN) describes a method for operating a Traffic Engineered (TE) network (such as an MPLS-TE network or a layer 1 transport network) to provide connectivity and virtual network services for customers of the TE network. The services provided can be tuned to meet the requirements (such as traffic patterns, quality, and reliability) of the applications hosted by the customers. More details about ACTN can be found in Section 2. Data models are a representation of objects that can be configured or monitored within a system. Within the IETF, YANG [RFC6020] is the language of choice for documenting data models, and YANG models have been produced to allow configuration or modelling of a variety of network devices, protocol instances, and network services. YANG data models have been classified in [Netmod-Yang-Model-Classification] and [Service-YANG]. This document shows how the ACTN architecture can be satisfied using classes of data model that have already been defined, and discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. 2. Abstraction and Control of TE Networks (ACTN) Architecture [ACTN-Requirements] describes the high-level ACTN requirements. [ACTN-Frame] describes the architecture model for ACTN including the entities (Customer Network Controller (CNC), Multi-domain Service Coordinator (MDSC), and Physical Network Controller (PNC)) and their interfaces. Zhang, et al. Expires January 4, 2017 [Page 3] Internet-Draft ACTN YANG October 2016 Figure 1 depicts a high-level control and interface architecture for ACTN and is a reproduction of Figure 7 from [ACTN-Frame]. A number of key ACTN interfaces exist for deployment and operation of ACTN- based networks. These are highlighted in Figure 1 (ACTN Interfaces) below: .-------------- ------------- | | Application |-- ------------- ^ | I/F A -------- v ( ) -------------- - - | Customer | ( Customer ) | Network |--------->( Network ) | Controller | ( ) -------------- - - ^ ( ) | I/F B -------- v -------------- | MultiDomain | | Service | | Coordinator| -------- -------------- ( ) ^ - - | I/F C ( Physical ) v ( Network ) --------------- ( ) -------- | |<----> - - ( ) -------------- | ( ) - - | Physical |-- -------- ( Physical ) | Network |<---------------------->( Network ) | Controller | I/F D ( ) -------------- - - ( ) -------- Figure 1 : ACTN Interfaces The interfaces and functions are described below (without modifying the definitions) in [ACTN-Frame]: . Interface A: This is out of scope of this draft. Zhang, et al. Expires January 4, 2017 [Page 4] Internet-Draft ACTN YANG October 2016 . Interface B: The CNC-MDSC Interface (CMI) is an interface between a Customer Network Controller and a Multi Domain Service Controller. The interface will communicate the service request or application demand. A request will include specific service properties, including: services, bandwidth and constraint information. The CNC can also request the creation of the virtual network based on underlying physical resources to provide network services for the applications. The CNC can provide the end-point information/characteristics, traffic matrix specifying specific customer constraints. The MDSC may also report potential network topology availability if queried for current capability from the Customer Network Controller. . Interface C: The MDSC-PNC Interface (MPI) is an interface between a Multi Domain Service Coordinator and a Physical Network Controller. It allows the MDSC to communicate requests to create connectivity or to modify bandwidth reservations in the physical network. In multi-domain environments, each PNC is responsible for a separate domain and so the MDSC needs to establish multiple MPIs, one for each PNC and perform coordination between them. . Interface D: The provisioning interface for creating forwarding state in the physical network, requested via the Physical Network Controller. Interface D is not in the scope of ACTN, however, it is included in this document so that it can be compared to models in [Service-Yang]. 3. Service Models [Service-YANG] introduces a reference architecture to explain the nature and usage of service YANG models in the context of service orchestration. Figure 2 below depicts this relationship and is a reproduction of Figure 2 from [Service-YANG]. Four models depicted in Figure 2 are defined as follows: . Customer Service Model: A customer service model is used to describe a service as offer or delivered to a customer by a network operator. . Service Delivery Model: A service delivery model is used by a network operator to define and configure how a service is provided by the network. . Network Configuration Model: A network configuration model is used by a network orchestrator to provide network-level configuration model to a controller. Zhang, et al. Expires January 4, 2017 [Page 5] Internet-Draft ACTN YANG October 2016 . Device Configuration Model: A device configuration model is used by a controller to configure physical network elements. Customer ------------------ Service ---------- | | Model | | | Service |<-------->| Customer | | Orchestrator | | | | | ---------- ------------------ . . ----------- . . ......|Application| . . : | BSS/OSS | . . : ----------- . Service Delivery . : . Model . : ------------------ ------------------ | | | | | Network | | Network | | Orchestrator | | Orchestrator | | | | | .------------------ ------------------. . : : . . : Network Configuration : . . : Model : . ------------ ------------ ------------ ------------ | | | | | | | | | Controller | | Controller | | Controller | | Controller | | | | | | | | | ------------ ------------ ------------ ------------ : . . : : : . . Device : : : . . Configuration : : : . . Model : : --------- --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | | Element | --------- --------- --------- --------- --------- Figure 2: An SDN Architecture with a Service Orchestrator 4. Service Model Mapping to ACTN YANG models coupled with the RESTCONF/NETCONF protocol [Netconf][Restconf] are solutions for the ACTN framework. This section explains which types of YANG models apply to each of the ACTN interfaces. Zhang, et al. Expires January 4, 2017 [Page 6] Internet-Draft ACTN YANG October 2016 +-------------------------------------------------------------+ | | | +-----------+ +-------+ | | | Customer | | CNC | | | +-----------+ +-------+ | | /|\ /|\ | +---------|-------------------------------------------|-------+ | Customer Service Model | CMI | | +------ --|-------------------------------------------|--------+ | \|/ | | | +------------+ | | | | Service | \|/ | | |Orchestrator| +----------+ | | +------------+ | | | | /|\ | MDSC | | | | Service Delivery Model | | | | \|/ | | | | +------------+ +----------+ | | | Network | /|\ | | |Orchestrator| | | | +------------+ | | | /|\ | | | | | | +---------|-------------------------------------------|--------+ | | MPI | Network Configuration Model | +---------|-------------------------------------------|--------+ | \|/ \|/ | | +----------+ +-----------+ | | | Domain | | PNC | | | |Controller| +-----------+ | | +----------+ /|\ /|\ | | /|\ /|\ | | | | | | | | | +------|-----|-------------------------------------|-----|-----+ | | Device Configuration Model | | SBI \|/ \|/ \|/ \|/ --- --- --- --- / \ / \ / \ / \ \ / \ / \ / \ / --- --- --- --- Figure 3 : Mapping between Service Model and ACTN Architecture Zhang, et al. Expires January 4, 2017 [Page 7] Internet-Draft ACTN YANG October 2016 As shown in Figure 3, the architecture described in [Service-YANG] can be mapped to the ACTN architecture well. A point worth noting is that here the functions of the MDSC can include: A. Customer mapping/translation This function is to map customer intent-like commands into network provisioning requests to the Physical Network Controller (PNC) according to business OSS/NMS provisioned static or dynamic policy. Specifically, it provides mapping and translation of customer's service request into a set of parameters that are specific to a network type and technology such that network configuration process is made possible. B. Service/Virtual service coordination This function translates customer service-related information into the virtual network service operations in order to seamlessly operate virtual networks while meeting customer's service requirements. In the context of ACTN, service/virtual service coordination includes a number of service orchestration functions such as multi-destination load balancing, guarantees of service quality, bandwidth and throughput and notification for service fault and performance degradation and so forth. C. Multi domain coordination This function oversees the specific aspects of the different domains and builds a single abstracted end-to-end network topology in order to coordinate end-to-end path computation and path/service provisioning. Domain sequence path calculation/determination is also a part of this function. D. Virtualization/Abstraction This function provides an abstracted view of the underlying network resources towards customer, being it the client or a higher level controller entity. It includes network path computation based on customer service connectivity request constraints, based on the global network-wide abstracted topology and the creation of an abstracted view of network slices allocated to each customer, according to customer-specific network objective functions, and to the customer traffic profile. The first two of these functions (A and B) are related to service orchestration while function C is related to network orchestration and function D is related to both service and network orchestration. Zhang, et al. Expires January 4, 2017 [Page 8] Internet-Draft ACTN YANG October 2016 4.1. Customer Service Models in the ACTN Architecture (CMI) Customer Service Models, which are used between a customer and a service orchestrator as in [Service-YANG], should be used between the CNC and MDSC (e.g., CMI) serving as providing a simple intent- like model/interface. Among the key functions of Customer Service Models on the CMI is the service request. A request will include specific service properties, including: service type and its characteristics, bandwidth, constraint information, and end-point characteristics. The following table provides a list of functions needed to build the CMI. They are mapped with Customer Service Models. Function Yang Models ----------------------------------------------------------- Transport Service Request [Transport-Service-Model] VN Service Request [ACTN-VN-YANG] Path Computation Request* [PATH-COMPUTATION-API] *Path computation request in the CMI context means network path computation request based on customer service connectivity request constraints. 4.2. Service Delivery Models in ACTN Architecture The Service Delivery Models (as shown in Figure 3) where the service orchestration and the network orchestration could be implemented as separate components as seen in [Service-YANG]. This is also known as Network Service Models. On the other hand, from an ACTN architecture point of view, the service delivery model between the service orchestrator and the network orchestrator is an internal interface between sub-components of the MDSC. 4.3. Network Configuration Models in ACTN Architecture (MPI) The Network Configuration Models is used between the network orchestrator and the controller in [Service-YANG]. In ACTN, this model is used primarily between a MDSC and a PNC. The Network Configuration Model can be also used for the foundation of more advanced models, like hierarchical MDSCs (see Section 4.5) Zhang, et al. Expires January 4, 2017 [Page 9] Internet-Draft ACTN YANG October 2016 The Network Configuration Model captures the parameters which are network wide information. The following table provides a list of mandatory and optional functions needed to build the MPI. They are mapped with Network Configuration Yang Models. Note that various Yang models are work in progress. Function Yang Models ------------------------------------------ Configuration Scheduling [Schedule] Path computation [PATH_COMPUTATION-API]* Path Provisioning [TE-Tunnel]** Topology Abstraction [TE-topology] Telemetry TBD Service Provisioning TBD*** * Related draft is presenting use cases for path computation API, and Yang related model is foreseen to be added. ** Note that path provisioning function is provided by ietf-te module in [TE-Tunnel]. *** This function needs to be investigated further. This can be a part of [TE-Tunnel] which is to be determined. Service provisioning is an optional function that builds on top the path provisioning one. Path provisioning and Topology abstraction functions are mandatory in any case, while Path Computation may be mandatory or optional depending on the type of topology abstraction used. Details of this topic are discussed in [ACTN-Abstraction]. Telemetry may also be an optional function. 4.4. Device Models in ACTN Architecture (SBI) For the device YANG models are used for per-device configuration purpose, they can be used between the PNC and the physical network/devices. An example of Device Models is ietf-te-device yang module defined in [TE-tunnel]. Note that SBI is not in the scope of ACTN. This section is provided to give some examples of YANG-based Device Models. Zhang, et al. Expires January 4, 2017 [Page 10] Internet-Draft ACTN YANG October 2016 4.5. Advanced Models There may be some variation of interface C whereby there may be MDSC-MDSC interface (MMI) in case where there may be a recursive hierarchy among the MDSCs. This is a variation of ACTN architecture. See Figure 4 for this. +-------+ +-------+ +-------+ | CNC-A | | CNC-B | | CNC-C | +-------+ +-------+ +-------+ \ | / ---------- | ---------- \ | / +-----------------------+ | MDSC | +-----------------------+ / | \ ---------- | ----------- / | \ +----------+ +----------+ +--------+ | MDSC | | MDSC | | MDSC | +----------+ +----------+ +--------+ | / | / \ | / | / \ +-----+ +-----+ +-----+ +-----+ +-----+ | PNC | | PNC | | PNC | | PNC | | PNC | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 4: MDSC Controller Hierarchy The MDSC-MDSC interface can be viewed as a recursive network configuration model which is similar to the MDSC-PNC interface. 5. Examples of Using Different Types of YANG Models 5.1. Simple Connectivity Examples The data model in [Transport-Service-Model] provides an intent-like connectivity service model which can be used in connection-oriented transport networks. It would be used as follows in the ACTN architecture: Zhang, et al. Expires January 4, 2017 [Page 11] Internet-Draft ACTN YANG October 2016 . A CNC uses this service model to specify the two client nodes that are to be connected, and also indicates the amount of traffic (i.e., the bandwidth required) and payload type. What may be additionally specified is the SLA that describes the required quality and resilience of the service. . The MDSC uses the information in the request to pick the right network (domain) and also to select the provider edge nodes corresponding to the customer edge nodes. If there are multiple domains, then the MDSC needs to coordinate across domains to set up network tunnels to deliver a service. Thus coordination includes, but is not limited to, picking the right domain sequence to deliver a service. Before it can perform such functions, it needs to get the topology information from each PNC, be it abstract or not, using topology YANG models such as [te-topology]. Additionally, an MDSC can initiate the creation of a tunnel (or tunnel segment) in order to fulfill the service request from CNC based on path computation upon the overall topology information it synthesized from different PNCs. The based model that can cater this purpose is the te-tunnel model specified in [te-tunnel]. . Then, the PNC needs to decide the explicit route of such a tunnel or tunnel segment (in case of multiple domains), and create such a tunnel using protocols such as PCEP and RSVP-TE or using per-hop configuration. 5.2. VN service example The service model defined in [ACTN-VN-YANG] describes a virtual network (VN) as a service which is a set of multiple connectivity services: . A CNC will specify to the MDSC a list of VN members. Each VN member specifies either a single connectivity service, or a source with multiple potential destination points in the case that the precise destination sites are to be determined by MDSC. o In the first case, the procedure is the same as the connectivity service, except that in this case, there is a list of connections requested. Zhang, et al. Expires January 4, 2017 [Page 12] Internet-Draft ACTN YANG October 2016 o In the second case, where the CNC requests the MDSC to select the right destination out of a list of candidates, the MDSC needs to choose the best candidate and reply with the chosen destination for a given VN member. After this is selected, the connectivity request setup procedure is the same as in the connectivity-as-a-service example. 5.3. Data Center-Interconnection Example This section describes more concretely how existing YANG models described in Section 4 map to an ACTN data center interconnection use case. Figure 5 shows a use-case which shows service policy- driven Data Center selection and is a reproduction of Figure A.1 from [ACTN-Info]. Zhang, et al. Expires January 4, 2017 [Page 13] Internet-Draft ACTN YANG October 2016 +----------------+ | CNC | | (Global DC | | Operation | | Control) | +--------+-------+ | | VN Requirement/Policy: CMI: | | - Endpoint/DC location info Service model | | - Endpoint/DC dynamic | | selection policy | | (for VM migration, DR, LB) | v +---------+---------+ | Multi-domain | Service policy-driven |Service Coordinator| dynamic DC selection MPI: +-----+---+---+-----+ Network Configuration | | | Model | | | +----------------+ | +---------------+ | | | +-----+-----+ +------+-----+ +------+-----+ | PNC for | | PNC for | | PNC for | | Transport | | Transport | | Transport | | Network A | | Network B | | network C | +-----------+ +------------+ +------------+ Device | | | Model | | | | | | +---+ ------ ------ ------ +---+ |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| +---+ | | | | | | +---+ | TN A +-----+ TN B +----+ TN C | / | | | | | / \\\\ //// / \\\\ //// \\\\ //// +---+ ------ / ------ \ ------ \ |DC2| / \ \+---+ +---+ / \ |DC6| +---+ \ +---+ +---+ |DC3| \|DC4| +---+ +---+ DR: Disaster Recovery LB: Load Balancing Figure 5: Service Policy-driven Data Center Selection Zhang, et al. Expires January 4, 2017 [Page 14] Internet-Draft ACTN YANG October 2016 Figure 5 shows how VN policies from the CNC (Global Data Center Operation) are incorporated by the MDSC to support multi-destination applications. Multi-destination applications refer to applications in which the selection of the destination of a network path for a given source needs to be decided dynamically to support such applications. Data Center selection problems arise for VM mobility, disaster recovery and load balancing cases. VN's policy plays an important role for virtual network operation. Policy can be static or dynamic. Dynamic policy for data center selection may be placed as a result of utilization of data center resources supporting VMs. The MDSC would then incorporate this information to meet the objective of this application. 5.3.1. CMI (CNC-MDSC Interface) [ACTN-VN-YANG] is used to express the definition of a VN, its VN creation request, the service objectives (metrics, QoS parameters, etc.), dynamic service policy when VM needs to be moved from one Data Center to another Data Center, etc. This service model is used between the CNC and the MDSC (CMI). The CNC in this use-case is an external entity that wants to create a VN and operates on the VN. 5.3.2. MPI (MDSC-PNC Interface) The Network Configuration Model is used between the MDSC and the PNCs. Based on the Customer Service Model's request, the MDSC will need to translate the service model into the network configuration model to instantiate a set of multi-domain connections between the prescribed sources and the destinations. The MDSC will also need to dynamically interact with the CNC for dynamic policy changes initiated by the CNC. Upon the determination of the multi-domain connections, the MDSC will need to use the network configuration model such as [TE-Tunnel] to interact with each PNC involved on the path. [TE-Topology] is used to for the purpose of underlying domain network abstraction from the PNC to the MDSC. 5.3.3. PDI (PNC-Device interface) The Device Model can be used between the PNC and its underlying devices that are controlled by the PNC. The PNC will need to trigger signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to provision its domain path segment. There can be a plethora of choices how to control/manage its domain network. The PNC is responsible to abstract its domain network resources and update it Zhang, et al. Expires January 4, 2017 [Page 15] Internet-Draft ACTN YANG October 2016 to the MDSC. Note that this interface is not in the scope of ACTN. This section is provided just for an illustration purpose. 6. Security This document is an informational draft. When the models mentioned in this draft are implemented, detailed security consideration will be given in such work. How security fits into the whole architecture has the following components: - the use of Restconf security between components - the use of authentication and policy to govern which services can be requested by different parties. - how security may be requested as an element of a service and mapped down to protocol security mechanisms as well as separation (slicing) of physical resources) 7. Acknowledgements We thank Adrian Farrel for providing useful comments and suggestions for this draft. 8. References 8.1. Informative References [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", draft-wu-opsawg-service-model-explained, work in progress. [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module Classification", draft-ietf-netmod- yang-model-classification, work in progress. [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241. [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf, work in progress. Zhang, et al. Expires January 4, 2017 [Page 16] Internet-Draft ACTN YANG October 2016 [ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for Abstraction and Control of TE Networks", draft-ietf-teas- actn-requirements, work in progress. [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and Control of Traffic Engineered Networks", draft-ietf-teas- actn-framework, work in progress. [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", draft-ietf-teas-yang-te-topo, work in progress. [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te, work in progress. [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN Operation", draft-lee-teas-actn-vn-yang, work in progress. [ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction and Control of TE Networks (ACTN)", draft-leebelotti-teas- actn-info, work in progress. [Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model for Connection-oriented Transport Networks", draft-zhang- teas-transport-service-model, work in progress. [PATH-COMPUTATION-API] I.Busi/S.Belotti et al. "Path Computation API", draft-busibel-ccamp-path-computation-api-00.txt, work in progress [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, work in progress. [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration Scheduling", draft-liu-netmod-yang-schedule, work in progress. [ACTN-Abstraction] Y. Lee, D. Dhody, and D. Ceccarelli, "ACTN Abstraction Methods", draft-lee-tease-actn-abstraction, work in progress. Zhang, et al. Expires January 4, 2017 [Page 17] Internet-Draft ACTN YANG October 2016 9. Contributors Contributor's Addresses Dhruv Dhoddy Huawei Technologies Email: dhruv.ietf@gmail.com Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Zhang, et al. Expires January 4, 2017 [Page 18] Internet-Draft ACTN YANG October 2016 Authors' Addresses Young Lee Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA Phone: (469)277-5838 Email: leeyoung@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Bin Yeong Yoon ETRI Email: byyun@etri.re.kr Oscar Gonzalez de Dios Telefonica Email: oscar.gonzalezdedios@telefonica.com Zhang, et al. Expires January 4, 2017 [Page 19]