CCAMP Working Group Xian Zhang
Internet-Draft Huawei
Intended status: Standards Track R. Jing
China Telecom
W. Jian
China Unicom
Jeong-dong Ryoo
ETRI
Y. Xu
CAICT
Daniel King
Lancaster University
Expires: September 05, 2016 March 07, 2016
YANG Models for the Northbound Interface of a Transport Network
Controller: Requirements, Functions, and a List of YANG Models
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt
Abstract
A transport network is a server-layer network designed to provide
connectivity services for a client-layer network to carry the client
traffic opaquely across the server-layer network resources. A
transport network may be constructed from equipment utilizing any of
a number of different transport technologies such as the evolving
optical transport infrastructure (Synchronous Optical Networking
(SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport
Network (OTN)) or packet transport as epitomized by the MPLS
Transport Profile (MPLS-TP).
All transport networks have high benchmarks for reliability and
operational simplicity. This suggests a common, technology-
independent management/control paradigm that can be extended to
represent and configure specific technology attributes.
This document describes the requirements facing transport networks
in order to provide open interfaces for resource programmability and
control/management automation. A list of existing and additional
YANG models is provided to fulfill the functional requirements.
Zhang et al Expires September 2016 [Page 1]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
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 September 05, 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.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 4
3. Terminology and Notations.................................... 4
4. Functional Requirements...................................... 5
4.1. Scenarios ............................................. 5
4.2. Function Requirement Summary ........................... 8
5. Function Analysis ........................................... 9
Zhang et al Expires September 2016 [Page 2]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
5.1. Toplogy Related Functions .............................. 9
5.1.1 Obtaining Access Point Info ...................... 9
5.1.2 Obtaining Topology ............................... 9
5.1.3 Virtual Network Operations ...................... 10
5.2. Tunnel Operations ..................................... 10
5.3. Service Requests ...................................... 10
6. Security Considerations..................................... 17
7. Manageability Considerations................................ 17
8. IANA Considerations ........................................ 18
9. Acknowledgements ........................................... 18
10. References ................................................ 18
10.1. Normative References............................... 18
10.2. Informative References............................. 18
11. Contributors' Address...................................... 19
Authors' Addresses ............................................. 19
1. Introduction
A transport network is a server-layer network designed to provide
connectivity services, or more advanced services like Virtual
Private Networks (VPN) for a client-layer network to carry the
client traffic opaquely across the server-layer network resources.
It acts as a pipe provider for upper-layer networks, such as IP
network and mobile networks.
Transport networks, such as Synchronous Optical Networking (SONET) /
Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN),
Wavelength Division Multiplexing (WDM), and flexi-grid networks, are
often built using equipment from a single vendor and are managed
using private interfaces to dedicated Element Management Systems
(EMS) / Network Management Systems (NMS). All transport networks
have high benchmarks for reliability and operational simplicity.
This suggests a common, technology-independent management/control
paradigm that is extended to represent and configure specific
technology attributes.
The need of network providers to manage multi-vendor and multi-
domain transport networks (where each domain is an island of
equipment from a single supplier) has been further stressed by the
expansion in network size. At the same time, applications such as
data center interconnection require larger and more dynamic
connectivity matrices. Therefore, transport networks face new
challenges going beyond automatic provisioning of tunnel setup
enabled by GMPLS (Generalized Multi-Protocol Label Switching)
protocols to achieve automatic service provisioning, as well as
Zhang et al Expires September 2016 [Page 3]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
address opportunities enabled by partitioning the network through
the process of resource slicing. With lower operational expenditure
(OPEX) and capital expenditure (CAPEX) as the usual objectives, open
interfaces to transport networks are considered by network providers
as a way to meet these requirements. The concept of Software
Defined Networking (SDN) leverages these ideas.
The YANG language [RFC6020] is currently the data modeling language
of choice within the IETF and has been adopted by a number of
industry-wide open management and control initiatives. YANG may be
used to model both configuration and operational states; it is
vendor-neutral and supports extensible APIs for control and
management of elements.
This document analyzes typical scenarios that need transport network
control/management openness, and lists functions desired to enable
deployment. Moreover, a list of YANG models and their relationships
have been identified that can help facilitate the deployment and
operation of transport network open interfaces. Note that some of
the models discussed meet the requirements described, and are
already being developed in the IETF. Thus, this document provides a
reference of existing models, and provides information of the
missing ones which need further work.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. Terminology and Notations
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in the YANG data tree
presented later in this draft is defined in [ietf-netmod-rfc6087bis].
They are provided below for reference.
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":").
Zhang et al Expires September 2016 [Page 4]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
4. Functional Requirements
4.1. Scenarios
There are several scenarios where an open interface to access
server-layer (transport) network resources would be useful. Here two
typical scenarios are provided.
The first one is depicted as below (Figure 1):
/--\ +------+ +------+ /--\
| 1 ~~~| A +------------------| B |~~~~~ 3 |
\--/ +-----++ +--+---+ \--/
| |
| |
| |
++-----+ +---+--+
| F +------------+ C |
++-----+ +--+---+
| |
| |
| |
| |
| |
+---+-+ +---+-+ /---\
| E +---------------+ D |~~~~ 4 |
/--\~~~~~+-----+ +-----+ \---/
| 2 |
\--/
+----+ /--\
| | Transport NE | | DC
+----+ \--/
----- Transport Link ~~~ Transport-DC link
(a) Data Centers interconnected via a transport network
+---------------------+
| Data Center Network |
| Controller |
+---------+-----------+
Zhang et al Expires September 2016 [Page 5]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
|
|
|
| Open Interface
|
|
+---------+-----------+
| Transport Network |
| Controller |
+---------------------+
(b) The controller architecture for data center interconnection
Figure 1: Scenario 1: Data centers interconnected via a transport
network and the controller architecture
For the data center operator, assuming the objective is to trigger
the transport network to provide connectivity on demand, the
following capabilities, at a minimum, would be required on the open
itnerface between the two contollers illustrated in Figure 1:
A: The ability to obtain information about a set of access points of
the transport network facing the client side, including information
such as access point identifiers, capabilities, etc.; for instance,
transport-network-side end point identifiers related to the access
link between DC1 and Transport NE A.
B: The capability to send a request for a service using the
aforementioned access point information, as well as the ability to
retrieve a list of service requests and their statuses. In this
request, it should at least be possible to include source node,
destination node, and requested bandwidth to request the transport
network to set up tunnels/paths so as to provide the requested
connectivitiy for the service request.
C: Note that in this case acquistion of the topology, be it physical
or logical, of the transport network is not a compulsory requirement,
but it may indeed be able to give data center providers more control
over the transport resource usage. Furtheremore, the client
controller can impose a virtual network of its own choice by
requesting a slice of network resource with its choice of network
parameters (such as network topology type, bandwidth etc.).
The second scenario, more complicated than the first, is depicted as
below (Figure 2). In this example, we focus on the management and
control via open interfaces for multi-domain networks with
homogeneous technologies (such as OTN), but it can be extended
Zhang et al Expires September 2016 [Page 6]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
further to multi-domain networks with heterogeneous technologies
with higher complexity.
+-------------------------------------------------+
| Orchestrator/Coordinator |
+---------+--------------+-------------------+----+
| | |
| | |
+------------+--+ | +----------+----------+
| Controller 1 | | | Controller 2 |
+---------+-----+ | +-------+-------------+
# +----------------+ #
#Qx | Controller 3 | #
# +----------------+ #TL1
# # #
----+----- # ----+-----
____/ \____ # ____/ \____
| | # | |
| | # | |
| Network Domain +***********+ Network Domain |
| 1 | # | 2 |
|____ ___| # |____ ___|
\ / #PCEP \ /
----------- # *----------
* * # * *
* * # * *
* * # * *
* * # * *
* * # * *
* * # * *
* *----+-----* *
* ____/ \____ *
*| |*
| |
| Network Domain |
| 3 |
|____ ___|
\ /
----------
***** inter-domain links
----- Open Interfaces
##### Controller-device interfaces
Figure 2: Scenario 2: Multi-domain network control and management
Zhang et al Expires September 2016 [Page 7]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
For the second scenario, the orchestrator/coordinator controls and
manages three distinct network domains, each controlled/managed by
their domain controller. In order to orchestrate across
domains/layers, the orchestrator needs its interface between domain
controllers to be equipped with the following functions:
A: Access to the topologies reported by each domain controller,
including cross-domain links for the purpose of planning and
requesting the paths of end-to-end tunnels. Multiple technologies
within a domain (i.e., a multi-layer network), this might be
reflected in the reported topology. Depending on the abstraction
level of the reported topology, the orchestrator has different
control granularities.
B: The ability to set up, delete and modify tunnels, be it within
one domain or across multiple domains. Furthermore, it should have
the abilty to view the tunnels created within each domain as well as
thouse that cross domains as reported by each domain controller.
4.2. Function Requirement Summary
For the open interface of a transport controller towards a
northbound client, five functions are derived from the scenarios
explained in the last section. They are summarized in the table
below and we also match these functions with YANG models that are
being developed in existing drafts.
Analysis and descriptions of whether and how these functions are
supported by the YANG models are provided in more detail in Section
5.
+-------------+-----------------------+-----------------------+
| Functions | Description | Related Existing |
| | | YANG Models |
|-------------+-----------------------+-----------------------+
| Obtaining |Getting the necessary | |
| Access |access points info | [TE-Topo] |
| Point Info | | |
+-------------+-----------------------+-----------------------+
| Obtaining |Getting the topology |[TE-Topo], [WDM-Topo] |
| Topology |info |[ODU-Topo] |
+-------------+-----------------------+-----------------------+
| Tunnel |Tunnel Setup, Deletion | |
| Operations |Modification and Info | [TE-Tunnel] |
| |Retrieval | |
+-------------+-----------------------+-----------------------+
Zhang et al Expires September 2016 [Page 8]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
| Service |Requesting connectivity| |
| Request |service and retrieval | [this I.D.] |
| |the list of service | |
| |request | |
+-------------+-----------------------+-----------------------+
| Virtual |Requesting a virtual | |
| Network |network and related |[TE-Topo], [WDM topo] |
| Operations |control operations, |[ODU-Topo] |
| |(e.g.,update, deletion)| |
+-------------+-----------------------+-----------------------+
5. Function Analysis
5.1. Toplogy Related Functions
As shown in Section 4, the functions of obtaining access point
information, obtaining topology, and imposing virtual network
operations can take advantages of the same set of topology YANG
models. These functions are briefly explained further in the
following sub-sections.
5.1.1 Obtaining Access Point Info
For cases such as scenario 1, a client may have no interest in
directly controlling network resources, but might want an automated
open control interface for initiating service requests. In this
case, a transport controller may provide the access point
information. This information can then be used in service request
sent over the open interface.
The TE Topology YANG model provided in [TE-topo] can be used to
provide a list of links. If the remote node and termination point
information is unknown, it is omitted from the reported information.
If the client-side node and termination point information is
obtained via configuration or a distributed discovery mechanism,
then it can also be added into the reported information.
Technology-specific details might also be needed to further express
the constraints/attributes associated with the access points. Note
that all of this information is usually read only.
5.1.2 Obtaining Topology
Refer to [TE-Topo] for explanations and examples on how to obtain
the topology. For technology specific topology information, other
models such as those provided in [WDM-Topo] and [ODU-Topo] maybe
used.
Zhang et al Expires September 2016 [Page 9]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
5.1.3 Virtual Network Operations
There are two ways to request the creation of a virtual network.
One is to define the topology explicitly using the model provided in
the topology YANG drafts listed in Section 5.1.2.. The other way is
to provide an estimated traffic information (a traffic matrix) and
ask for a network controller of the provider network to provide a
virtual network that can fulfill the demand. This second approach
does not have a supporting model and need further work.
5.2. Tunnel Operations
Thecurrent [TE-Tunnel] provides a technology agnostic Traffic-
Engieering (TE) device tunnel. The model included in that draft is
currently being developed to make it generic for both controller and
device usage. It is expected that the next version of this draft
will provide such a generic TE tunnel model that can cater to the
base requirementss for tunnel operations but it may need to be
augmented to support controller-specific operations.
Futhermore, technology-specific augmentations of the base generic TE
tunnel models are needed. For example, for Optical Channel (OCh)
tunnels in WDM networks, information such as the lambda resource
usage is needed. Similarly, for ODU tunnels, information such as
the usage of tributary slots is needed.
5.3. Service Requests
The service model is an important model that enables automated
operations between a client controller and a provider controller.
The transport connectivity service model is different from the model
of a tunnel since the transport connectivity service model hides
technical details from a client.
A transport connectivity service model is provided below:
module: ietf-transport-service
+--rw transport_service
| +--rw service* [service-id]
| +--rw service-id uint32
| +--rw service-name? string
| +--rw source
| | +--rw node-id? node-id
| | +--rw tp-id? tp-id
| +--rw destination
| | +--rw node-id? node-id
Zhang et al Expires September 2016 [Page 10]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
| | +--rw tp-id? tp-id
| +--rw service-type? service-types
| +--rw supporting-tunnel* [name]
| | +--rw name string
| +--rw bandwidth decimal64
| +--rw SLA? SLAtypes
| +--rw intended-policies
| +--rw schedule
| +--rw schedules
| +--rw schedule* [schedule-id]
| +--rw schedule-id uint32
| +--rw start? yang:date-and-time
| +--rw schedule-duration? string
| +--rw repeat-interval? string
+--rw service-state
+--ro service* [service-id]
+--ro service-id uint32
+--ro service-name? string
+--ro source
| +--ro node-id? node-id
| +--ro tp-id? tp-id
+--ro destination
| +--ro node-id? node-id
| +--ro tp-id? tp-id
+--ro service-type? service-types
+--ro supporting-tunnel* [name]
| +--ro name string
+--ro bandwidth decimal64
+--ro SLA? SLAtypes
+--ro applied-policies
| +--ro schedule
| +--ro schedules
| +--ro schedule* [schedule-id]
| +--ro schedule-id uint32
| +--ro start? yang:date-and-time
| +--ro schedule-duration? string
| +--ro repeat-interval? string
+--ro status? state-types
The corresponding YANG code is provided below:
<CODE BEGINS> file " ietf-transport-service@2016-3-7.yang"
module ietf-transport-service {
yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf_transport_service";
prefix tser;
Zhang et al Expires September 2016 [Page 11]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
import ietf-inet-types {
prefix inet;
}
import ietf-schedule {
prefix "sch";
}
organization "TBD";
contact
"WILL-BE-DEFINED-LATER";
description
"this module describes a service module that is essential
API for a client to ask for a provider network for a path
without the need to care about underlying technologies.
Capability to specify constraints/policies are provided as
optional features.";
revision 2016-03-07 {
description
"Initial revision.";
reference "to add the draft name";
}
typedef tp-id { //client termination port
type union {
type uint32;
type inet:ip-address; // IPv4 or IPv6 address
}
description
"the client termination port of a transport device";
}
typedef node-id { //client termination port
type union {
type uint32;
type inet:ip-address; // IPv4 or IPv6 address
}
description
"the node id of a transport device";
}
typedef service-types {
type enumeration {
enum "EPL" {
Zhang et al Expires September 2016 [Page 12]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
value 0;
description
"EPL service";
}
enum "EVPL" {
value 1;
description
"EVPL";
}
enum "EPLAN" {
value 2;
description
"EPLAN";
}
enum "EVPLAN" {
value 3;
description
"EVPLAN";
}
}
description "the type of a service request";
}
typedef state-types{
type enumeration {
enum "NORMAL" {
value 0;
description
"service is normal/up and running";
}
enum "DOWN" {
value 1;
description
"service is down.";
}
enum "DEGRADED"{
value 2;
description
"service is in degraded state.";
}
}
description "the state of a service.";
}
typedef SLAtypes{
type enumeration{
enum "1+1+R"{
Zhang et al Expires September 2016 [Page 13]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
value 0;
description
"A reroute will be provided after both the working and
protection path fails.";
}
enum "1+1"{
value 1;
description
"a protection path is provided.";
}
enum "Rerouting"{
value 2;
description
"rerouting after the working path fails";
}
enum "unprotected"{
value 3;
description
"no protection provided";
}
}
}
grouping service-basics {
//later put all service under so that it can reused
// in states.
leaf service-id {
type uint32;
description "an unique identificaiton of a service.";
}
leaf service-name{
type string;
description "name for a service";
}
container source{
leaf node-id {
type node-id;
description "node id";
}
leaf tp-id {
type tp-id;
description "TBD";
}
description "Service source information";
}
Zhang et al Expires September 2016 [Page 14]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
container destination{
leaf node-id {
type node-id;
description "node id";
}
leaf tp-id {
type tp-id;
description "TBD";
}
description "Service destination information";
}
leaf service-type {
type service-types;
description "the type of a service request";
}
list supporting-tunnel{
key "name";
leaf name{
type string;
description "the name of a tunnel";
}
description "the list of tunnesl to support the list";
}
leaf bandwidth {
type decimal64 {
fraction-digits 2;
}
mandatory true;
description "the bandwidth requested by a service.";
}
leaf SLA{
type SLAtypes;
description "the type of protection expected for this
service";
}
}
container transport_service {
description
"serves as a top-level container for a list of services";
Zhang et al Expires September 2016 [Page 15]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
list service {
key "service-id";
description
"an unique identifier of a service";
uses service-basics;
container intended-policies {
container schedule {
uses sch:schedules;
description "to specify bandwidth scheduling
information of this service.";
}
description "specify the policy associated with a
service";
}//end of policy
}//end of service list
}//service top container
container service-state
{
list service {
config false;
key "service-id";
description "operational state of a service";
uses service-basics;
container applied-policies{
container schedule {
uses sch:schedules;
description "to specify bandwidth scheduling
information of this service.";
}
}
leaf status {
type state-types;
description "TBD";
}
}//end of a service state
}//end of state
}
<CODE ENDS>
Zhang et al Expires September 2016 [Page 16]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
6. Security Considerations
Clearly modifying server-layer resources will have a significant
impact on network infrastructure. More specifically they will
provide the services and applications running across client-layers,
which the server-layer is supporting. Therefore, security must be an
important consideration when implementing the architecture, models
and protocol mechanisms discussed in this document.
Communicating service and network information (including access
point identifiers, capabilities, topologies, etc.) across external
interfaces represents a security risk. Thus, mechanisms to encrypt
or preserve the domain topology confidentiality should be used.
A key consideration are the external protocols (those shown as
entering or leaving the orchestrator and controllers shown in Figure
2 (Scenario 2: Multi-domain network control and management)) which
must be appropriately secured. This security should include
authentication and authorization to control access to different
functions that the orchestrator may perform to modify or create
state in the server-layer, and the establishment and management of
the orchestrator to controller relationship.
The orchestrator will contain significant data about the network
domains, the services carried by each domain, and customer type
information. Therefore, access to information held in the
orchestrator must be secured. Since such access will be largely
through external mechanisms, it may be pertinent to apply policy-
based controls to restrict access and functions.
7. Manageability Considerations
The core objectives of this document are to assist in the deployment
and operation of transport services across server-layer network
infrastructure. The model-driven management/control principles,
which are vendor-neutral and supported by extensible APIs, should be
utilized.
The open models described in this document are based on YANG
[RFC6020] and the RESTCONF [RESTCONF] messaging protocol, a REST-
Zhang et al Expires September 2016 [Page 17]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
like protocol running over HTTP for accessing data defined in YANG,
may also be used.
8. IANA Considerations
TBD.
9. Acknowledgements
Thank Igor Bryskin for useful discussions on relevant YANG models.
10. References
10.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and
Reviewers of YANG Data Model Documents", draft-ietf-
netmod-rfc6087bis-01, work in progress, October 2014.
10.2. Informative References
[TE-Topo] Liu X., Bryskin I., et al, "YANG Data Model for TE
Topologies", draft-ietf-teas-yang-te-topo-02, October 2015.
[WDM-Topo] Lee Y., et al, "A Yang Data Model for WSON Optical
Networks", draft-lee-ccamp-wson-yang-02, work in progress,
July 2015.
[ODU-Topo] Zhang X., Rao B., Liu X., "A YANG Data Model for Layer 1
Network Topology", draft-zhang-ccamp-l1-topo-yang-02,
December 2015.
[TE-Tunnel] Saad T., Gandhi R., Liu X., et al, "A YANG Data Model
for Traffic Engineering Tunnels and Interfaces", draft-
ietf-teas-yang-te-02, October, 2015.
[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", Work in Progress, draft-ietf-netconf-restconf-
09, December 2015.
Zhang et al Expires September 2016 [Page 18]
draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt March 2016
11. Contributors' Address
Sergio Belotti
Nokia
Sergio.belotti@nokia.com
Young Lee
Futurewei Technologies
leeyoung@huawei.com
Aihua Guo
Huawei Technologies Canada
aihuaguo@huawei.com
Authors' Addresses
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Ruiquan Jing
China Telecom
jingrq@ctbri.com.cn
Wei Jian
China Unicom
jianwei@chinaunicom.cn
Jeong-dong Ryoo
ETRI
ryoo@etri.re.kr
Yunbin Xu
China Academy of Information and Communication Technology (CAICT)
xuyunbin@ritt.cn
Daniel King
Lancaster University
d.king@lancaster.ac.uk
Zhang et al Expires September 2016 [Page 19]