A YANG Data Model for Layer 1 (ODU) Network Topology
draft-zhang-ccamp-l1-topo-yang-03

CCAMP Working Group                                         Xian Zhang 
Internet-Draft                                             Baoquan Rao 
Intended status: Standards Track                                Huawei 
                                                         Anurag Sharma 
                                                              Infinera 
                                                            Xufeng Liu 
                                                              Ericsson 
 
 
Expires: January 06, 2017                                July 08, 2016 
                                      

                                     
          A YANG Data Model for Layer 1 (ODU) Network Topology 
                                      
                   draft-zhang-ccamp-l1-topo-yang-03.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). 

   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 (e.g., obtaining) of 
   an OTN network. 

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." 
Zhang et al             Expires January 2017                  [Page 1] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

   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 Janruary 6th, 2017. 

   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............................ 3 
   3. Terminology and Notations.................................... 3 
   4. YANG Data Model for Layer 1 Topology .........................4 
      4.1. YANG Tree .............................................  4 
         4.1.1. Augmentation....................................... 5 
         4.1.2. The node and link list .............................5 
      4.2. YANG Code .............................................  6 
   5. Security Considerations..................................... 13 
   6. Manageability Considerations................................ 14 
   7. IANA Considerations ........................................ 14 
   8. Acknowledgements ........................................... 14 
   9. References ................................................. 14 
      9.1. Normative References .................................. 14 
      9.2. Informative References ................................ 15 
   10. Contributors' Address ......................................15 
   Authors' Addresses .............................................15 
    
    

 
 
Zhang et al             Expires January 2017                  [Page 2] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

1. Introduction 

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

   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 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 controller or a 
   network management system within the network ;  

      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)-electronic layer and also enables 
   manipulation of an OTN network. 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 
 
 
Zhang et al             Expires January 2017                  [Page 3] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

   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 

4.1. YANG Tree 

 
module: ietf-odu-topology 
augment /nd:networks/nd:network/nd:network-types/tet:te-topology: 
   +--rw l1-network! 
augment /nd:networks/nd:network: 
   +--rw name?   string 
augment /nd:networks/nd:network/nd:node: 
   +--rw name?   string 
augment /nd:networks/nd:network/nd:node/lnk:termination-
point/tet:te/tet:config: 
   +--rw client-facing?         empty 
   +--rw tpn?                   uint16 
   +--rw tsg?                   identityref 
   +--rw protocol-type?         identityref 
   +--rw fec-enabled?           boolean 
   +--rw adaptation-type?       adaptation-type 
   +--rw sink-adapt-active?     boolean 
   +--rw source-adapt-active?   boolean 
   +--rw timeslots 
      +--rw values*   uint8 
augment /nd:networks/nd:network/nd:node/lnk:termination-
point/tet:te/tet:state: 
   +--ro client-facing?         empty 
   +--ro tpn?                   uint16 
   +--ro tsg?                   identityref 
   +--ro protocol-type?         identityref 
 
 
Zhang et al             Expires January 2017                  [Page 4] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

   +--ro fec-enabled?           boolean 
   +--ro adaptation-type?       adaptation-type 
   +--ro sink-adapt-active?     boolean 
   +--ro source-adapt-active?   boolean 
   +--ro timeslots 
      +--ro values*   uint8 
augment /nd:networks/nd:network/lnk:link/tet:te/tet:config: 
   +--rw odu-type?   identityref 
   +--rw distance?   uint32 
augment /nd:networks/nd:network/lnk:link/tet:te/tet:state: 
   +--ro odu-type?   identityref 
   +--ro distance?   uint32 
augment /nd:networks/nd:network/nd:node/tet:te/tet:tunnel-termination-
point/tet:state: 
   +--ro odu-Type?   identityref 
augment /nd:networks/nd:network/lnk:link/tet:te/tet:config/tet:te-link-
attributes/tet:schedules/tet:schedule: 
   +--rw odu-type?     identityref 
   +--rw oduflex-bw?   uint32 
augment /nd:networks/nd:network/lnk:link/tet:te/tet:state/tet:te-link-
attributes/tet:schedules/tet:schedule: 
   +--ro odu-type?     identityref 
   +--ro oduflex-bw?   uint32 
 
4.1.1. Augmentation  

   As can be seen, from the tree shown in Section 4,1, the YANG module 
   presented augments from a more generic Traffic Engineered (TE)  
   network topology model, i.e., the ietf-te-topology YANG module as 
   specified in [draft-ietf-teas-yang-te-topo-04].  

   Note the model in this draft uses the YANG model named ietf-
   transport-types.yang defined in [draft-sharma-ccamp-otn-service-
   model-00]. 

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.  

   Similarly, a link is identified by the link-id, which is unique 
   within a node. It includes the association with nodes as well as 

 
 
Zhang et al             Expires January 2017                  [Page 5] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

   interfaces. Moreover, it includes information that is of interest to 
   the client, for purposes, such as path computation, monitoring etc.  

   Since for an optical transport network, its client interface 
   attributes has technology-specific attributes that need to be 
   captured to give the client all the necessary information for its 
   use. For full control purpose, this attributes and information are 
   also captured and listed in this YANG module. 

4.2. YANG Code  

 
  <CODE BEGINS> file " ietf-odu-topology@2016-07-07.yang" 
   
  module ietf-odu-topology { 
   yang-version 1; 
    
   namespace "urn:ietf:params:xml:ns:yang:ietf-odu-topology"; 
   prefix "l1topo"; 
    
   import ietf-network { 
     prefix "nd"; 
   } 
    
   import ietf-network-topology { 
     prefix "lnk"; 
   } 
    
   import ietf-te-topology { 
     prefix "tet"; 
   } 
   
   import ietf-transport-types { 
     prefix "tran-types";  
   } 
    
   organization  
     "Internet Engineering Task Force (IETF) CCAMP WG"; 
   contact 
     " 
     WG List: <mailto:ccamp@ietf.org> 
   
     ID-draft editor:  
     Xian ZHANG (zhang.xian@huawei.com); 
     Anurag Sharma (AnSharma@infinera.com); 
     "; 
    
 
 
Zhang et al             Expires January 2017                  [Page 6] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

   description 
     "This module defines a protocol independent Layer 1/ODU  
     topology data model."; 
   
   revision 2016-07-07 { 
     description 
       "Initial version."; 
     reference 
       "draft-zhang-ccamp-l1-topo-yang-01.txt"; 
   } 
    
   /* 
   typedef 
   */ 
    
   typedef adaptation-type { 
     type enumeration { 
       enum CBR { 
         description "Constant Bit Rate."; 
       } 
       enum ATMvp { 
         description "ATM VP."; 
       } 
       enum GFP { 
         description "Generic Framing Procedure."; 
       } 
       enum NULL { 
         description "NULL"; 
       }      
       enum PRBS { 
         description "Pseudo Random Binary Sequence"; 
       } 
       enum RSn { 
         description "TBD"; 
       } 
     } 
      
     description 
       "Defines a type representing the adaptation type  
       on the termination point."; 
   } 
   
    
   /* 
   Groupings 
   */ 
   
 
 
Zhang et al             Expires January 2017                  [Page 7] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

   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 { 
     leaf name { 
       type string; 
       description "the network name"; 
     } 
     description "name attribute for l1 network";      
   } 
    
   grouping l1-node-attributes { 
     description "l1-node-attributes"; 
     leaf name { 
       type string; 
       description "a name for this node."; 
     }  
   } 
   
   grouping l1-link-attributes { 
     description "l1 link attributes"; 
      
     leaf odu-type { 
       type identityref{ 
         base tran-types:tributary-protocol-type; 
       } 
       description "the ODU type supported by this link"; 
     } 
   
     leaf distance { 
       type uint32;  
       description "distance in the unit of kilometers"; 
     } 
   } 
    
   grouping ttp-odu-attributes { 
     description "ttp ODU attributes"; 
      
     leaf odu-Type { 
       type identityref{ 
         base tran-types:tributary-protocol-type; 
 
 
Zhang et al             Expires January 2017                  [Page 8] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

       } 
       description "the ODU type supported by this ttp"; 
     } 
   } 
    
   grouping sch-odu-attributes { 
     description "additional odu attributes for scheduled link"; 
      
     leaf odu-type { 
       type identityref{ 
         base tran-types:tributary-protocol-type; 
       } 
       description "the ODU type scedhuled"; 
     } 
      
     leaf oduflex-bw { 
       type uint32; 
       description "banwidth for ODUflex type"; 
     } 
   } 
    
   grouping l1-tp-attributes { 
     description "l1-tp-attributes"; 
   
     leaf client-facing { 
       type empty; 
       description  
         "if present, it means this tp is a client-facing tp"; 
     } 
   
     leaf tpn { 
       type uint16 { 
         range "0..4095"; 
       } 
       description  
       "Tributary Port Number. Applicable in case of mux services."; 
       reference 
       "RFC7139: GMPLS Signaling Extensions for Control of Evolving 
        G.709 Optical Transport Networks."; 
     } 
   
     leaf tsg { 
       type identityref { 
         base tran-types:tributary-slot-granularity; 
       } 
       description "Tributary slot granularity."; 
       reference 
 
 
Zhang et al             Expires January 2017                  [Page 9] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

       "G.709/Y.1331, February 2012: Interfaces for the Optical 
        Transport Network (OTN)"; 
     } 
   
     leaf protocol-type { 
       type identityref { 
         base tran-types:tributary-protocol-type; 
       } 
       description "Protocol type for the Termination Point."; 
     } 
   
     leaf fec-enabled { 
       type boolean; 
       description 
        "This attribute is optional and indicates whether Forward 
        Error Correction (FEC) is enabled or not for the  
        Termination Point."; 
     } 
   
     leaf adaptation-type { 
       type adaptation-type; 
       description 
        "This attribute indicates the type of the supported  
        adaptation function at the termination point."; 
       reference 
       "G.874.1, January 2002: Optical transport network (OTN):  
       Protocol-neutral management information model for the  
       network element view."; 
     } 
   
     leaf sink-adapt-active { 
       type boolean; 
       description 
       "This attribute allows for activation or deactivation of  
      the sink adaptation function. The value of TRUE means active."; 
       reference 
       "G.874.1, January 2002: Optical transport network (OTN):  
       Protocol-neutral management information model for the  
       network element view "; 
     } 
   
     leaf source-adapt-active { 
       type boolean; 
       description 
       "This attribute allows for activation or deactivation of  
       the sink adaptation function. The value of TRUE  
       means active."; 
 
 
Zhang et al             Expires January 2017                 [Page 10] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

       reference 
       "G.874.1, January 2002: Optical transport network (OTN):  
       Protocol-neutral management information model for  
       the network element view "; 
     } 
   
     container timeslots { 
       description  
        "A list of tributary timeslots used by the ODU  
        Termination Point."; 
       leaf-list values { 
         type uint8; 
         description  
           "Tributary timeslot value."; 
         reference 
          "G.709/Y.1331, February 2012: Interfaces for the  
          Optical Transport Network (OTN)"; 
       }  
     } 
   } 
   
   
    /* 
    * Data nodes 
    */ 
   augment "/nd:networks/nd:network/nd:network-types/tet:te-topology" { 
     uses l1-network-type; 
     description "augment network types to include L1 newtork"; 
   } 
    
   augment "/nd:networks/nd:network" { 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment only for L1 network"; 
     } 
     uses l1-network-attributes;     
     description "Augment network configuration";    
   } 
    
   augment "/nd:networks/nd:network/nd:node" { 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment only for L1 network"; 
     } 
     description "Augment node configuration"; 
     uses l1-node-attributes; 
   } 
   
   augment "/nd:networks/nd:network/nd:node/" 
 
 
Zhang et al             Expires January 2017                 [Page 11] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

      +"lnk:termination-point/tet:te/tet:config" { 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment only for L1 network"; 
     } 
     description "OTN TP attributes config in a ODU topology."; 
     uses l1-tp-attributes; 
   } 
    
   augment "/nd:networks/nd:network/nd:node" + 
           "/lnk:termination-point/tet:te/tet:state" { 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment only for L1 network"; 
     } 
     description "OTN TP attributes state in a ODU topology."; 
     uses l1-tp-attributes; 
   }  
    
   augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" { 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment only for L1 network."; 
     } 
     description "Augment link configuration"; 
      
     uses l1-link-attributes; 
   } 
    
   augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" { 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment only for L1 network."; 
     } 
     description "Augment link state"; 
      
     uses l1-link-attributes; 
   } 
    
   augment "/nd:networks/nd:network/nd:node/tet:te" + 
       "/tet:tunnel-termination-point/tet:state"{ 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment only for L1 network"; 
     } 
     description "Augment ttp state"; 
     uses ttp-odu-attributes; 
   } 
    
   augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" 
       +"/tet:te-link-attributes/tet:schedules/tet:schedule"{ 
     when "nd:network-types/tet:te-topology/l1-network" { 
 
 
Zhang et al             Expires January 2017                 [Page 12] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

       description "Augment only for L1 network."; 
     } 
     description "Augment link schedule config"; 
      
     uses sch-odu-attributes; 
   } 
    
   augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" 
       +"/tet:te-link-attributes/tet:schedules/tet:schedule"{ 
     when "nd:network-types/tet:te-topology/l1-network" { 
       description "Augment link schedule state."; 
     } 
     description "Augment link schedule config"; 
      
     uses sch-odu-attributes; 
   } 
  } 
   
  <CODE ENDS>  
 
5. Security Considerations 

   Since the data model defined in this draft is manipulated via, for 
   example, the interface between an orchestrator and a transport 
   network controller. The security concerns mentioned in [draft-ietf-
   teas-yang-te-topo-04] also applies to this draft. 
    
   The YANG module defined in this memo is designed to be accessed via   
   the RESTCONF protocol defined in [draft-ietf-netconf-restconf-13] , 
   or maybe via the NETCONF protocol [RFC6241].   
    
   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., 
   <POST>) 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.] 
    

 
 
Zhang et al             Expires January 2017                 [Page 13] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

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

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

   [draft-ietf-netconf-restconf] Bierman A., Bjorklund M., Watsen K., 
             "RESTCONF Protocol", draft-ietf-netconf-restconf-13, work 
             in progress, April 2016; 

   [draft-sharma-ccamp-otn-service-model] Sharma A., Rao R., Zhang X., 
             "OTN Service YANG Model", draft-sharma-ccamp-otn-service-
             model-00, work in progress, July 2016;  

 
 
Zhang et al             Expires January 2017                 [Page 14] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

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; 

    [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 

   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
    
   Anurag Sharma 
   Infinera 
 
 
Zhang et al             Expires January 2017                 [Page 15] 


draft-zhang-ccamp-l1-topo-yang-03.txt                        July 2016 
    

   ansharma@infinera.com
    
    
   Xufeng Liu 
   Ericsson 
   Xufeng.liu@ericsson.com
    
    
    

 
 
Zhang et al             Expires January 2017                 [Page 16]