CCAMP Working Group                                          Xian Zhang
Internet-Draft                                              Baoquan Rao
Intended status: Standards Track                                 Huawei
                                                             Xufeng Liu
                                                               Ericsson


Expires: April 16, 2016                                October 19, 2015




             A YANG Data Model for Layer 1 Network Topology

                   draft-zhang-ccamp-l1-topo-yang-00.txt


Abstract

   This draft describes a YANG data model to manipulate the topologies
   of a layer 1 Optical Transport Network (OTN). It is independent of
   control plane protocols and captures topology related information
   pertaining to OTN and also enables manipulation of an OTN network
   via the I2RS interface.

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 April 16, 2016.

   Copyright Notice


Zhang et al              Expires April 2016                   [Page 1]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


   Copyright (c) 2015 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 ................................................ 2
   2. Conventions used in this document............................ 3
   3. Terminology and Notations.................................... 3
   4. YANG Data Model for Layer 1 Topology .........................3
      4.1. YANG Tree  ............................................. 4
         4.1.1. Augmentation....................................... 5
         4.1.2. The node and link list............................. 5
         4.1.3. Notification .......................................6
      4.2. YANG Code  ............................................. 6
   5. Security Considerations..................................... 17
   6. Manageability Considerations................................ 17
   7. IANA Considerations ........................................ 17
   8. Acknowledgements ........................................... 17
   9. References ................................................. 18
      9.1. Normative References .................................. 18
      9.2. Informative References ................................ 18
   10. Contributors' Address ...................................... 18
   Authors' Addresses ............................................. 19



1. Introduction

   This document defines a data model of a layer one network topology,
   using YANG [RFC6020]. The model can be used by an application
   exposing to a management system. Moreover, it can also be used by an
   application via the I2RS interface [draft-ietf-i2rs-architecture],
   in the following ways (but not limited to):

     o to obtain a whole view of the network topology information of
   its interest e.g., via a network element or maybe a Path Computation
   Element (PCE) or a network management system within the network ;


Zhang et al              Expires April 2016                   [Page 2]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


      o to receive notifications with regard to the information of the
   change of the network topology of its interest;

      o to enforce the establishment/update of a network topology with
   the characteristic specified in the data model, e.g., by a network
   controller or a client controller to manipulate the network provided
   by the provider for flexible control and management;

   The YANG model defined in this draft is independent of control plane
   protocols and captures topology related information pertaining to an
   Optical Transport Networks (OTN) and also enables manipulation of an
   OTN network via the I2RS interface. Other network layers, such as
   fixed Dense Wavelength Switched Optical Network (WSON) and flexible
   optical networks (a.k.a., flexi-grid networks) are covered in [WSON-
   YANG] and [Flexi-YANG], respectively.

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 (":").

      o  Ellipsis ("...") stands for contents of subtrees that are not
   shown.

4. YANG Data Model for Layer 1 Topology

   [Editor's note: It was agreed that the model presented in this draft
   will be augmenting from TE topology YANG, which is not available


Zhang et al              Expires April 2016                   [Page 3]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


   during the time of writing due to its revision to augment from the
   generic topology YANG produced in I2RS WG. So, this issue will be
   addressed in the further versions of this draft.]

4.1. YANG Tree

module: ietf-layer1topology
augment /nt:network/nt:network-types:
   +--rw l1-network!
augment /nt:network:
   +--rw l1-network-attributes
      +--rw name?   string
augment /nt:network/nt:node:
   +--rw l1-node-attributes
      +--rw name?                  string
      +--rw connectivity-matrix* [id]
      |  +--rw id        uint32
      |  +--rw type?     enumeration
      |  +--rw in-tp* [tp-ref]
      |  |  +--rw tp-ref    leafref
      |  +--rw out-tp* [tp-ref]
      |  |  +--rw tp-ref    leafref
      |  +--rw dir       enumeration
      +--ro oper-status?           enumeration
augment /nt:network/nt:node/nttopo:termination-point:
   +--rw physical-info
      +--rw shelf-id?     uint32
      +--rw board-id?     uint32
      +--rw subcard-id?   uint32
      +--rw port-id?      uint32
augment /nt:network/nttopo:link:
   +--rw l1-link-attributes!
      +--rw source-tp-type          enumeration
      +--rw admin-status?           enumeration
      +--rw link-protection-type?   enumeration
      +--rw switching-capability?   identityref
      +--rw encoding?               identityref
      +--rw srlg
      |  +--rw srlg-values*   uint32
      +--rw (link-attributes)?
      |  +--:(ODU)
      |  |  +--rw ODU-type?               uint32
      |  |  +--rw availabe-resources
      |  |  |  +--rw granularity            enumeration
      |  |  |  +--rw num?                   uint32
      |  |  |  +--rw availability-bitmap*   boolean
      |  |  +--rw mapping-info


Zhang et al              Expires April 2016                   [Page 4]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


      |  |     +--rw mapping-list*   string
      |  +--:(client)
      |     +--rw max-bandwidth?          uint32
      |     +--rw unreserved-bandwidth?   uint32
      |     +--rw local-ip?               inet:ip-address
      |     +--rw remote-ip?              inet:ip-address
      +--ro oper-status?            enumeration
notifications:
   +---n link-failure
   |  +--ro topology-ref    leafref
   |  +--ro link-ref        leafref
   |  +--ro admin_status?   leafref
   |  +--ro oper-status?    leafref
   +---n node-failure
      +--ro topology-ref    leafref
      +--ro node-ref        leafref
      +--ro oper-status?    leafref

4.1.1. Augmentation

   As can be seen in the YANG module presented augments from a more
   generic network topology model, i.e., the ietf-network-topology YANG
   module as specified in [draft-ietf-i2rs-yang-network-topo]. This is
   to follow the network model structure suggested in [draft-ietf-i2rs-
   yang-network-topo] figure 1.

   [Editor's note: how TE topo YANG fits in this figure has been
   discussed and yet to be updated in that draft.]

4.1.2. The node and link list

   The module presented in this draft contains all the nodes and links
   information pertaining to a layer one network. As specified in the
   ietf-network YANG module, a node is identified by the node-id, which
   is unique within the network. Within the nodes, all the interfaces
   pertaining to this node and their potential capabilities/constraints
   SHOULD be present. Besides this, the constraints associated with a
   node as a whole SHOULD also be present, such as the connectivity
   constraints introduced due to abstraction or due to the hardware
   limitations.

   Similarly, a link is identified by the link-id, which is unique
   within a node. It includes the association with nodes as well as
   interfaces. Moreover, it includes information that is of interest to
   the management and I2RS client, for purposes, such as path
   computation, monitoring etc. For termination points, physical
   information is provided as an optional feature and it provides


Zhang et al              Expires April 2016                   [Page 5]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


   additional information to allow management/I2RS client to be better
   informed of this attribute and can help visualize and simply the
   operation of termination points selection.

   [editor's note]: for next update: any specific information related
   to an OTN interface has to be described in the context of
   technologic specific extension of OTN-TDM ISCD''.

   Since for an optical transport network, its client interface
   attributes may be different with that of the links within the
   network. For full control purpose, this attributes and information
   are also captured and listed in this YANG module.

4.1.3. Notification

   Two types of notifications are introduced: node failure and link
   failure.

4.2. YANG Code

<CODE BEGINS> file "ietf-layer1topology@2015-10-19.yang''

module ietf-layer1topology {
  yang-version 1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-layer1topology";
  prefix "l1topo";

  import ietf-inet-types {
    prefix "inet";
  }
  import ietf-network {
    prefix "nt";
  }

  import ietf-network-topology {
    prefix "nttopo";
  }

  import ietf-te-types {
    prefix "ietf-te-types";
  }

  organization
    "Internet Engineering Task Force (IETF) CCAMP WG";
  contact
    "ID-draft editor: zhang.xian@huawei.com";


Zhang et al              Expires April 2016                   [Page 6]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015



  description
    "This module defines a protocol independent Layer One/OTN
    topology data model.";

  revision 2015-10-16 {
    description
      "Initial version.";
    reference
      "draft-zhang-ccamp-l1-topo-yang-00.txt";
  }

  /*
  Groupings
  */

  grouping srlg-attributes {
    description
      "Shared Risk Link Group Attributes";
    reference
      "RFC 4203: OSPF Extensions in Support of Generalized
      Multi-Protocol Label Switching (GMPLS)";
    leaf-list srlg-values {
      type uint32;
      description "SRLG value list";
    }
  }

  grouping l1-network-type {
    container l1-network {
      presence "indicates a L1 network, i.e., Optical
      Transport Network (OTN).";
      description "l1 network type";
    }
    description "l1-network-type";
  }

  grouping l1-network-attributes {
    container l1-network-attributes {
      leaf name {
        type string;
        description "the network name";
      }
      description "name attribute for l1 network";
    }
    description "l1-network-attributes";
  }


Zhang et al              Expires April 2016                   [Page 7]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015



  grouping l1-node-attributes {
    description "l1-node-attributes";
    container l1-node-attributes {
      description "l1-node-attributes";
      leaf name {
        type string;
        description "a name for this node.";
      }

      list connectivity-matrix {
        key "id";

        description
          "This describes the connectivity constraints within
          a node in the network. It can be one matrix or a set
          of matrixes. Further details, read the reference
          provided below.";
        reference
          "https://tools.ietf.org/html/draft-ietf-ccamp-general
          -constraint-encode-16 Section 2.1";

        leaf id {
          type uint32;
          description "matrix id";
        }
        leaf type {
          type enumeration {
            enum fixed {
              value 0;
              description "Fixed";
            }
            enum dynamic {
              value 1;
              description "Dynamic/changeable";
            }
          }
          description
            "This field describes the attribute of a
            connectivity matrix, i.e., whether it is
            fixed or switched.";
        }
        list in-tp {
          key "tp-ref";

          description
            "This list describes a (sub)-set of ingoing


Zhang et al              Expires April 2016                   [Page 8]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


            interfaces within a node that may have
            connectivity constraints.
            Note: directionality may not be relevant
             and it is decided by the dir parameter.";

          leaf tp-ref {
            type leafref {
              path "../../../../nttopo:termination-point/"+
              "nttopo:tp-id";
            }
            description "reference to an incoming interface,
            must be within the same node";
          }
        }
        list out-tp {
          key "tp-ref";

          description
            "This list describes a (sub)-set of outgoing
            interfaces within a node that may have
            connectivity constraints.
            Note: directionality may not be relevant and
            it is decided by the dir parameter.";

          leaf tp-ref {
            type leafref {
              path "../../../../nttopo:termination-point"+
              "/nttopo:tp-id";
            }
            description "reference to an outgoing interface,
            must be within the same node";
          }
        }
        leaf dir{
          type enumeration{
            enum "uni-dir"{
              description
              "the matrix is unidirectional.";
            }
            enum "bi-dir"{
              description
              "this matrix is bidirectional.";
            }
          }
          mandatory true;
          description
            "the directionality attribute of a connc. matrix.";


Zhang et al              Expires April 2016                   [Page 9]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


        }
      }

      leaf oper-status {
        type enumeration {
          enum "unknown" {
            description "unknown - lost connect with control
                 plane.";
          }
          enum "up" {
            description "normal";
          }
          enum "down" {
            description "not available";
          }
        }

        config false;
        description "operational status of a node";
      }
    }
  }

  grouping l1-link-attributes {
    description "l1-link-attributes";
    container l1-link-attributes {
      presence "L1 link attributes";
      description "l1 link attributes";
      leaf source-tp-type {
        type enumeration {
          enum "client-side" {
            description "client side";
          }
          enum "line-side" {
            description "line side";
          }
        }
        mandatory true;
        description
        "the type of a port:0-client side; 1 - line side";
      }

      leaf admin-status {
        type enumeration {
          enum "up" {
            description "up";
          }


Zhang et al              Expires April 2016                  [Page 10]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


          enum "down" {
            description "normal";
          }
       }
       description "administrative status of a link";
      }

      leaf link-protection-type {
        type enumeration {
          enum "extra-traffic" {
            description "Extra traffic";
          }
          enum "unprotected" {
            description "unprotected";
          }
          enum "shared" {
            description "Shared";
          }
          enum "1-for-1" {
            description "Dedicated one for one protection";
          }
          enum "1-plus-1" {
            description "Dedicated one plus one protection";
          }
          enum "enhanced" {
            description "a protection type that is more reliable
            than Dedicated 1+1, e.g.,4 fiber BLSR/MS-SPRING.";
          }
        }
        description
          "Link Protection Type configured for this link";
        reference
          "RFC3471: Generalized Multi-Protocol Label Switching
          (GMPLS) Signaling Functional Description.";
      }

      leaf switching-capability {
        type identityref{
          base ietf-te-types:switching-capabilities;
        }
        description
          "the switching capability supported by the link";
      }

      leaf encoding {
        type identityref{
          base ietf-te-types:lsp-encoding-types;


Zhang et al              Expires April 2016                  [Page 11]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


        }
        description
          "the encoding type supported by this link.";
      }

      container srlg {
        uses srlg-attributes;
        description " the SRLG values of a link";
      }

      choice link-attributes {
        case ODU {
          leaf ODU-type {
            type uint32;
            description "link capacity, subject to change
            to the type of enumeration";
          }

          container availabe-resources {
            leaf granularity {
              type enumeration {
                enum "1.25G" {
                  description "1.25G";
                }
                enum "2.5G" {
                  description "2.5G";
                }
              }
              mandatory true;
              description "the base unit for unreserved-bandwidth
                     description";
            }
            leaf num {
              type uint32;
             description "number * granularity = max-bandwidth";
            }
            leaf-list availability-bitmap {
              type boolean;
              description "0-avaialble, 1- unavaialbe";
            }
            description "describe what is available in the unit
                  of granularity";
          }
          container mapping-info {
            leaf-list mapping-list {
              type string;



Zhang et al              Expires April 2016                  [Page 12]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


                                             description "it can be one or multiple mapping
                     route";
            }
            description "mapping supported by this link; subject
            to further change";
          }
        }
        case client {
          leaf max-bandwidth {
            type uint32;
            description "max bandwidth supported by this client
            facing link";
          }
          leaf unreserved-bandwidth {
            type uint32;
            description "available bandwidth on this link";
          }
          leaf local-ip {
            type inet:ip-address;
            description "the local-end ip address of a link";
          }
          leaf remote-ip {
            type inet:ip-address;
            description "the remote-end ip address of a link";
          }
        }
        description "attributes for a client interface";
      }

      leaf oper-status {
        type enumeration {
          enum "unknown" {
                        description "unknown-lost connection with control
                 plane";
          }
          enum "normal" {
            description "normal";
          }
          enum "down" {
            description "down";
          }
          enum "degraded" {
            description "degraded, temporarily unusable";
          }
        }

        config false;


Zhang et al              Expires April 2016                  [Page 13]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


        description "status of a link";
      }
    }
  }

  grouping l1-tp-attributes {
    description "l1-tp-attributes";
    container physical-info {
      description "physical info of an termination point/port";
      leaf shelf-id {
        type uint32;
        description "shelf-id of which this tp belongs to";
      }
      leaf board-id {
        type uint32;
        description "board-id of which this tp belongs to";
      }
      leaf subcard-id {
        type uint32;
        description "subcard id information, if no such info.,"+
        "fill in 0xff.";
      }
      leaf port-id {
        type uint32;
        description "port-id of which this tp belongs to";
      }
    }
  }

   /*
    * Data nodes
    */

  augment "/nt:network/nt:network-types" {
    uses l1-network-type;
    description "augment network types to include L1 newtork";
  }

  augment "/nt:network" {
    when "nt:network-types/l1-network" {
      description "Augment only for L1 network";
    }
    uses l1-network-attributes;
    description "Augment network configuration";
  }

  augment "/nt:network/nt:node" {


Zhang et al              Expires April 2016                  [Page 14]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


    when "nt:network-types/l1-network" {
      description "Augment only for L1 network";
    }
    description "Augment node configuration";

    uses l1-node-attributes;
  }

  augment "/nt:network/nt:node/nttopo:termination-point" {
    when "nt:network-types/l1-network" {
      description "Augment only for L1 network";
    }
    description "Augment tp configuration";

    uses l1-tp-attributes;
  }

  augment "/nt:network/nttopo:link" {
    when "nt:network-types/l1-network" {
      description "Augment only for L1 network.";
    }
    description "Augment link configuration";

    uses l1-link-attributes;
  }

  notification link-failure {
    leaf topology-ref {
      type leafref {
        path "/nt:network/nt:network-id";
      }
      mandatory true;
      description "the topology reference of which"
      +"this link belongs to";
    }
    leaf link-ref {
      type leafref {
        path "/nt:network[nt:network-id= current ()"+
        "/../topology-ref]/nttopo:link/nttopo:link-id";
      }
      mandatory true;
      description "";
    }
    leaf admin_status {
      type leafref {
        path
          "/nt:network/nttopo:link[nttopo:link-id ="+


Zhang et al              Expires April 2016                  [Page 15]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


          "current()/../link-ref]/l1-link-attributes/admin-status";
      }
      description "admin status of the reported link";
    }
    leaf oper-status {
      type leafref {
        path
          "/nt:network/nttopo:link[nttopo:link-id = current()"
          +"/../link-ref]/l1-link-attributes/oper-status";
      }
      description "";
    }
    description
     "link failure information";
  } //notification-link failure

  notification node-failure {
    leaf topology-ref {
      type leafref {
        path "/nt:network/nt:network-id";
      }
      mandatory true;
      description "";
    }
    leaf node-ref {
      type leafref {
        path "/nt:network[nt:network-id= current ()"+
        "/../topology-ref]/nt:node/nt:node-id";
      }
      mandatory true;
      description "";
    }
    leaf oper-status {
      type leafref {
        path
          "/nt:network/nt:node[nt:node-id = current()"
          +"/../node-ref]/l1-node-attributes/oper-status";
      }
      description "";
    }
    description
     "node failure information";
  }
}
<CODE ENDS>




Zhang et al              Expires April 2016                  [Page 16]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015



5. Security Considerations

   Since the data model defined in this draft is manipulated via the
   I2RS interface. The security concerns mentioned in [draft-ietf-i2rs-
   architecture] also applies to this draft.

   The YANG module defined in this memo is designed to be accessed via
   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
   secure transport layer and the mandatory-to-implement secure
   transport is SSH [RFC6242].  The NETCONF access control model
   [RFC6536] provides the means to restrict access for particular
   NETCONF users to a pre-configured subset of all available NETCONF
   protocol operations and content.

   There are a number of data nodes defined in the YANG module which
   are writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or
   vulnerable in some network environments.  Write operations (e.g.,
   <edit-config>) to these data nodes without proper protection can
   have a negative effect on network operations.

   [Editor's note: to List specific subtrees and data nodes and their
   sensitivity/vulnerability.]

6. Manageability Considerations

   TBD.

7. IANA Considerations

   TBD.

8. Acknowledgements

   The initial YANG model specified in this draft is based on draft-
   clemm-i2rs-yang-network-topo but it is modified according to the
   features of the layer one networks.

   We would like to thank the authors of the above mentioned draft for
   their helpful discussion during the creation of this draft.




Zhang et al              Expires April 2016                  [Page 17]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


9. References

9.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.

9.2. Informative References

   [draft-ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S.,
             Ward, D., Nadeau T., ''An Architecture for the Interface to
             the Routing System'', draft-ietf-i2rs-architecture-08, work
             in progress, January 2015;

   [draft-ietf-i2rs-yang-network-topo] Clemm A., Medved J., Tkacik T.,
             Varga R., et al, ''A YANG Data Model for Network
             Topologies'', draft-ietf-i2rs-yang-network-topo-01, work in
             progress, June 2015;

   [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.

   [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman,
             "Network Configuration Protocol (NETCONF)", RFC6241, June
             2011.

   [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
             Shell (SSH)", RFC 6242, June 2011.

   [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
             Protocol (NETCONF) Access Control Model", RFC 6536, March
             2012.

   [WSON-YANG] Lee, Y., et al, " A Yang Data Model for WSON Optical
             Networks", draft-lee-ccamp-wson-yang-02, work in progress,
             July 2015.

   [Flexi-YANG] Lopez de Varga, J.E., et al, "YANG data model for
             Flexi-Grid Optical Networks", draft-vergara-ccamp-
             flexigrid-yang-01, work in progress, July 2015.

10. Contributors' Address


Zhang et al              Expires April 2016                  [Page 18]


draft-zhang-ccamp-l1-topo-yang-00.txt                      October 2015


   Sergio Belotti
   Alcatel-Lucent
   Sergio.belotti@alcatel-lucent.com

Authors' Addresses
   Xian Zhang
   Huawei Technologies
   Email: zhang.xian@huawei.com

   Baoquan Rao
   Huawei Technologies
   raobaoquan@huawei.com

   Xufeng Liu
   Ericsson
   Xufeng.liu@ericsson.com
































Zhang et al              Expires April 2016                  [Page 19]