Internet DRAFT - draft-zhou-aponf-architecture

draft-zhou-aponf-architecture



Network Working Group                                            C. Zhou
Internet-Draft                                                   T. Tsou
Intended status: Informational                       Huawei Technologies
Expires: January 21, 2015                                       D. Lopez
                                                              Telefonica
                                                          G. Karagiannis
                                                    University of Twente
                                                                  Q. Sun
                                                           China Telecom
                                                           July 21, 2014


   The Architecture for Application-based Policy On Network Functions
                    draft-zhou-aponf-architecture-03

Abstract

   Currently, there are network management applications that present
   specific demands on a communication network.  This document describes
   the APONF basic architecture, its elements and interfaces.  The main
   APONF architecture entities are the Network Management Application
   Agent (NMAA), which is a network entity that creates and runs network
   services, and Application-based Policy Decision (ABPD), which
   supports classified application models.  Each of these models support
   application demands that are similar in nature and therefore can be
   grouped/classified together.  Moreover, the ABPD maps the classified
   application models into network capabilities, e.g., network
   management and controlling policies.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 21, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. 


Zhou, et al.             Expires January 21, 2015               [Page 1]

Internet-Draft             APONF Architecture                  July 2014

   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.

Requirements Language

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of the APONF Architecture  . . . . . . . . . . . . .   3
   4.  Network Management Applications . . . . . . . . . . . . . . .   5
     4.1.  Network Management Application Agent (NMAA) . . . . . . .   5
   5.  Application Based Policy Decision . . . . . . . . . . . . . .   7
   6.  Network Elements  . . . . . . . . . . . . . . . . . . . . . .  10
   7.  The APONF Interface . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   12. Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12




1.  Introduction

   As the Internet grows, more and more new services keep on arising,
   and network traffic is rapidly increased, which may result in slow
   performance of network devices (e.g., BRAS) and poor end-user
   experience.  In addition, especially for cloud applications, the
   cloud tenants and developers usually need to use the communication
   network capabilities, such as dynamic network management and dynamic
   traffic steering, easily, accurately and efficiently.  In this way,
   the deployment of new applications and services may be accelerated
   and the user experience can be improved.

   In particular, today network operators are challenged to create an
   abstract view of their network infrastructure and help service
   developers on using and programming this abstraction rather than
   manipulating individual devices.  In this context, network management
   applications can be used to provide the required configuration and

Zhou, et al.             Expires January 21, 2015               [Page 2]

Internet-Draft             APONF Architecture                  July 2014


   application programming interfaces to such service developers.
   Subsequently, a network management application can use the
   application based demands and possibly update its associated network 
   service graph A network service graph provides an abstraction view of 
   a network infrastructure, which also includes network service 
   attributes. The network service attributes are network management 
   application dependent which may include the network service 
   dependencies and network configuration and topology used by a network 
   management application, the used flow steering policy, the IPv6 
   transition policy, the Distributed Data Center application policy. 
   Network management applications are Operational Support System (OSS) 
   like applications that help a communication service provider to 
   monitor, control, analyze and manage a communication network.

   For each network service instance a network service graph needs to be 
   generated and maintained. 

   The up to date network service graph needs to (1) be communicated 
   between the  network management application systems and the network 
   management and controlling systems, (2) map the attributes of the 
   network service graph into specific network management policies, 
   i.e., device level configuration models.

   The main goal of this document is to specify the APONF basic
   architecture, its elements and interfaces.  The main APONF
   architecture entities are the Network Management Application Agent
   (NMAA) and the Application-based Policy Decision (ABPD).  NMAA is a
   network entity that creates and runs network services and is able to
   use the application based demands and possibly update their
   associated  network service graph.  The ABPD is able to map the 
   network service graphs into specific network management policies, 
   i.e., device level configuration models.  The definition of these 
   network management policies is out of the APONF scope.

2.  Terminology

   The terminology used in the APONF problem statement draft  
   [ID.karagiannis-aponf-problem-statement] applies also to this draft.


3.  Overview of the APONF Architecture

   This section depicts an overview of the architecture of application-
   based policy on network functions.  Figure 1 shows APONF
   architecture.  The basic components of the APONF architecture are:

   Network Management Application: Operational Support System (OSS) like
   applications that help a communication service provider to monitor,
   control, analyze and manage a communication network.  Several network
   management applications MAY communicate with the Application Based
   Policy Decision block via the Network Management Application Agent.


Zhou, et al.             Expires January 21, 2015               [Page 3]

Internet-Draft             APONF Architecture                  July 2014

+---------------------------------+    +------------------------- ----+
| Network Management Application  |    |Network Management Application|
|                                 |    |                              |
|                                 |    |                              |
|   +---------------------+       |    |   +---------------------+    |
|   | Network Management  |       |    |   | Network Management  |    |
|   |  Application Agent  |       |... |   |  Application Agent  |    |
|   |                     |       |    |   |                     |    |
|   |      (NMAA)         |       |    |   |    (NMAA)           |    |
|   +------------+--------+       |    |   +---------+-----------+    |
|                |                |    |             |                |
|                |                |    |             |                |
+----------------|----------------+    +-------------|----------------+
                 |                                   |
                 |                                   |
 +---------------|------------------------------------|----------------+
 |+--------------v-------------+   +---+ +--------v-------------------+|
 ||Classified Application Model|   |...| |Classified Application Model||
 |+----------------------------+   +---+ +----------------------------+|
  |                                                                    |
  |                    Application Based Policy Decision (ABPD)        |
  +-----------------------------------^--------------------------------+
                                      |
                                      |
                                      |
                 +--------------------+---------------------+
                 |                                          |
                 |                                          |
                 |                                          |
   +-------------v---------------+         +------------v-------------+
   |                             |         |                          |
   |                             |   ...   |                          |
   | Network Element             |         | Network Element          |
   +-----------------------------+         +--------------------------+

       Figure 1: Architecture of application-based policy on network
                                 functions

   The Network Management Application Agent (NMAA): a network entity 
   that creates and runs network services. These network services 
   should be developed by an operator, which in the context of APONF are 
   assumed to be already available.
   The NMAA is able to generate, for each of these network service 
   Instances, and using application based demands a network service 
   graph. 

   Application Based Policy Decision(ABPD): A network entity which
   provides an interface to NMAA(s) and is able to map the classified
   application based models, which are including the classified
   application based demands and the network service graph, into 
   specific network management policies, i.e., device level 
   configuration models, which are used by the communication network.  
   ABPD can communicate with multiple NMAAs simultaneously.

Zhou, et al.             Expires January 21, 2015               [Page 4]

Internet-Draft             APONF Architecture                  July 2014

   Network Element (NE):handles incoming packets based on the ABDP
   network management policies and the corresponding network management
   and controlling procedures.

   Figure 1 shows the basic architecture of application-based policy on
   network functions.

4.  Network Management Applications

   This architecture is expected to be used for several categories of
   network management applications.  Such network management
   applications are representing the realizations of the APONF use
   cases, which are: "Distributed Data Center " 
   [ID.draft-cheng-aponf-ddc-use-cases], "IPv6 transition " 
   [ID.draft-sun-aponf-openv6-use-cases],
   "Virtualized Enterprise Applications " 
   [ID.draft-huang-aponf-use-cases] , "Source Address Validation and 
   Traceback (SAVI)" [ID.draft-bi-aponf-sdsavi], and "Using the abstract 
   view of network by service developers" 
   [ID.draft-liu-aponf-using-abstract-view-use-case].

   These network management applications are represented by a set of
   network services.  Each network service can be represented by a
   classified application based policy model, since it can model the
   group of demands coming from a bundle of end user applications that 
   impose similar requirements on the communication network.  Such 
   network services can be "Distributed Data Center ", " IPv6 
   transition", "Virtualized Enterprise Applications " and "Source 
   Address Validation and Traceback (SAVI) " and "Using the abstract 
   view of network by service developers". For each network service 
   instance a network service graph needs to be generated and 
   maintained. 

4.1.  Network Management Application Agent (NMAA)

   The NMAA is part of the network management application and is a
   network entity that creates and runs network services.  These network
   services should be developed by an operator, which in the context of 
   APONF are assumed to be already available.

   The assumption here is that the network management application has a
   complete view of the available network and network capabilities that
   it can use.  Moreover, it is assumed that the network management
   application is able to have the abstract view of the network and on
   how the network service is mapped into this abstract view.  This
   network abstract view is defined using the network service graph . It 
   is assumed that the NMAA can create and maintain the network service 
   graph. 

   An NMAA is a typical OSS gateway or Network Management Station
   entity, that needs to support the following new functional blocks as
   shown in Figure 2:


Zhou, et al.             Expires January 21, 2015               [Page 5]

Internet-Draft             APONF Architecture                  July 2014

   +----------------------------------------------+
   |NMAA                                          |
   |                                              |
   |    +--------------+     +----------------+   |
   |    |              |     | Create/Update  |   |
   |    | Typical OSS  |     |network service |   |
   |    |              |     |  graph         |   |
   |    +--------------+     +----------------+   |
   |                                              |
   |                                              |
   |                                              |
   |  +--------------+        +-----------------+ |
   |  | End User     |        |NMAA - ABDP      | |
   |  | Application  |        |                 | |
   |  | Interaction  |        |  Interface      | |
   |  +--------------+        +-----------------+ |
   +----------------------------------------------+

                Figure 2: NMAA Functionality Block Diagram

   o  Typical OSS (Operations Support System) features.

   o  Create/Update network service graphs: this is a NMAA functional 
      block and is used by the NMAA to use the network service 
      description and create or update a network service graph.
      The assumption used here is that the description of the network
      services is provided to end user applications in such a way that
      the end user application developer can use and program certain
      network capabilities such that the end user QoE can significantly 
      be increased. The modified versions of the network service 
      description are made known to the network management application 
      and NMAA.  This event initiates the update of the network service 
      graph.

   o  End User Application Interaction: this functional block is used to
      provide and receive information to/from the end user application
      engine.  This functional block is in charge to provide the
      description of the network services to end user applications in
      such a way that the end user application developer can use and
      program certain network capabilities such that the end user QoE 
      can significantly be increased. This functional block is also used 
      to receive the modified versions of the network service from the 
      end user application and to inform the "Create/Update network 
      service graph" functional block about this change. This event 
      initiates the update of the network service graph. Note that it is 
      assumed that the realization of this functional block and the 
      interface with the end user are out of the APONF's scope.

   o  "NMAA - ABDP interface": this functional block is used to support 
      a signaling protocol used between NMAA and the ABDP. Note that 
      one candidate IETF protocol that can be used for this purpose 
      is an enhanced version of the IETF Network Configuration Protocol 
      (NETCONF) [RFC6241].   

Zhou, et al.             Expires January 21, 2015               [Page 6]

Internet-Draft             APONF Architecture                  July 2014

   The Network Management Application Agent (NMAA) will use the APONF
   interface to communicate with the Application Based Policy Decision
   (ABPD) entity.

5.  Application Based Policy Decision

   The Application-Based Policy Decision (ABPD) block, is a an entity
   used between the Network Management Applications and the network
   elements to provide and maintain the application based policies.  It
   supports the APONF interface/protocol and is a software repository,
   which stores the information associated with each NE, and maps the
   classified application models, i.e., application based demands and
   the network service graph, into existing network management policies, 
   i.e., device configuration models. In particular, by creating 
   application based policies that mirror application semantics, a 
   better mapping to existing network management policies can be 
   realized.  This provides a simple, self-documenting mechanism for 
   capturing application-based policy requirements and mapping them to 
   existing network management policies.  This will allow applications 
   to use the network capabilities in a more accurate and efficient way.

   Figure 3 illustrates the ABPD functionality block diagram, which is
   based on [ID.farrkingel-pce-abno-architecture] and enhanced to
   satisfy the demands of the APONF use cases. Note that the realization 
   of the functional blocks defined in 
   [ID.farrkingel-pce-abno-architecture] is out of the scope of APONF.
   However, the capabilities provided by the "Provisioning manager"   
   functional block can be combined with capabilities provided by the   
   APONF defined "ABPD Network Management Interface" functional block.
   The Application Based Policy Decision (ABPD) block includes all the
   functional blocks provided in Figure 1 of  
   [ID.farrkingel-pce-abno-architecture], together with the following
   new defined functional blocks:

   o  Fresh network service graphs Maintenance: maintains a fresh 
      abstract view of the network.  Note that this is realized using 
      the network service graph that is created by the NMAA. Important 
      to note that for each network service / classified application 
      model that is managed by a network management application a 
      different network service graph is needed.  So in order to support 
      this capability, the APONF architecture needs to support a 
      functional block that stores all these abstract views of the 
      network in different network service graphs that are identified by 
      an unique ID.

   o  Application to Network Mapping: the following features are
      supported by this functional block:





Zhou, et al.             Expires January 21, 2015               [Page 7]

Internet-Draft             APONF Architecture                  July 2014

      1.  Translates the actions and the changed network service graph 
          received from the network management application, see 
          explanation below, to a new network service graph.  This is 
          accomplished by using application based demands generated by 
          network management applications systems to map the network 
          service graph into specific network management policies,
          i.e., into device level configuration models.  Such
          application based demands are:

   +----------------------------------------------------------------+
   |ABPD Block                                                      |
   |             +--------------------------+                       |
   |             | ABPD Management Interface|                       |
   |             +------------+-------------+                       |
   |         +--------------+ | +---------------++--------------+   |
   |         | ABPD-NMAA    | | | Fresh network ||Application to|   |
   |         |              | | |               ||  Network     |   |
   |         |              | | |               ||  Mapping     |   |
   |         |              | | |               ||              |   |
   |         |              | | |               ||              |   |
   |         | Interface    | | | Maintenance   ||              |   |
   |         +-----------+--+ | +------+--------++-+------------+   |
   |                     |    |       |           |                 |
   |                     |    |       |           |                 |
   |                   +-+----+------+------------+-+               |
   |         +------+  |                            |     +-------+ |
   |         |Policy+--+     ABPD Controller        +-----+       | |
   |         |Agent |  |                            +--+  |  OAM  | |
   |         +-+--+-+  +-+------------+----------+--+  |  |Handler| |
   |           |  |      |            |          |     |  |       | |
   |     +-----++ | +----+-+  +-------+-------+  |     |  +-------+ |
   |     |ALTO  | +-+ VNTM |--+               |  |     |            |
   |     |Server|   +--+-+-+  |               |  | +---+--------+   |
   |     +--+---+      | |    |      PCE      |  | |I2RS client |   |
   |        |  +-------+ |    |               |  | |            |   |
   |        |  |         |    |               |  | +------------+   |
   | +------+--+-+       |    |               |  |                  |
   | | Databases +-------:----+               |  |                  |
   | |   TED     |       |    +-+---+----+----+  |                  |
   | |  LSP-DB   +       |      |   |    |       |                  |
   | +-----+--+--+     +-+---------------+-------+-+                |
   |                   |    Provisioning Manager   |                |
   |                   +---------------------------+                |
   +----------------------------------------------------------------+

     Figure 3: ABPD Functionality Block Diagram, based on 
            [ID.farrkingel-pce-abno-architecture].

             Encapsulating, de-encapsulating packets associated with a
             flow into a tunnel (for example, VPN service, IPv6
             transition service demands on the network).



Zhou, et al.             Expires January 21, 2015               [Page 8]

Internet-Draft             APONF Architecture                  July 2014

             Blocking, or dropping packets associated with a flow in
             (the edge of) the network element when the network security
             service is aware of the attack (for example, SAVI service,
             Anti-DoS service demands on the network).

             Configure and dynamically reconfigure data centers to the
             steer and reroute traffic associated with a specific flow.

             Configure and dynamically reconfigure data centers to
             change priorities of different types of traffic associated
             with a specific flow.

             Logging the traffic associated with a flow for network
             security service, 

             Optimization of the traffic based on the IETF ALTO     
             [ID.draft-ietf-alto-protocol],

             Other actions defined by the administrator.

      2.  if required updates all databases, see Section 2.3.1.8 of
          [ID.farrkingel-pce-abno-architecture].

      3.  Uses existing network management and signaling protocols, i2rs
          [I2RS], SFC [SFC], NETCONF [NETCONF], etc., to request
          the implementation of the changes into the network.

   o  ABPD Network Management Interface: this functional block provides
      the interface with existing network management, i2rs,
      NETCONF, etc. protocols to request and negotiate the
      implementation of the changes into the network configuration.

   o  ABPD -NMAA interface: this functional block is used to support the 
      communication between NMAA and the ABDP. Note that a candidate 
      IETF protocol that can be used for the support of this 
      interface is an enhanced   For example, a possible protocol that 
      can be enhanced and used is the Network Configuration Protocol 
      (NETCONF) [RFC6241].   
  

   The definition of the network management policies is out of the APONF
   scope.

   These application-based policy models can meet the application's
   demands on the communication network and map these demands to network
   management policies that can be understood by the communication
   network.







Zhou, et al.             Expires January 21, 2015               [Page 9]

Internet-Draft             APONF Architecture                  July 2014

6.  Network Elements

   The Network Element (NE) handles incoming packets based on the policy
   information communicated with the ABPD block and makes corresponding
   policy enforcement, which is based on existing network management
   policies, see Section 5.

   A NE may be a physical entity or a virtual entity and is locally
   managed, whether via CLI, SNMP, or NeTConf.  Examples of NEs can
   include:

   o  A router that has an extended function module.  The extended
      module handles incoming packets based on the flow table of the
      module.

   o  A server that runs vRouter or vSwitch.

   o  A CGN that runs NAT, Tunnel En/De-capsulation functions.

   o  A virtual network function entity.

7.  The APONF Interface

   This APONF Interface/Protocol, needs to be specified by the APONF
   effort and is used to support the communication between the NMAA
   entity and the ABPD entity.  Several IETF protocols can be used 
   for this purpose. 
   A gap analysis is being performed in order to identify and select the 
   IETF protocol that, after extension, can enable the streaming 
   transfer of bulk-variable/data of the up to date network service 
   graphs between network management application systems and the network 
   management and controlling systems. 
   For example, a possible protocol that can be enhanced and used is the 
   Network Configuration Protocol (NETCONF) [RFC6241].   

8.  Security Considerations

   Security is a key aspect of any protocol that allows state
   installation and extracting of detailed configuration states.  More
   investigation remains to fully define the security requirements, such
   as authorization and authentication levels.

9.  IANA Considerations

   No IANA considerations.

10.  Acknowledgements

   The authors of this draft would like to thank the following persons
   for the provided valuable feedback: Jose Saldana, Spencer Dawkins,
   Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian Farrer, Marc
   Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed Boucadair,   
   Jean Francois Tremblay, Tom Taylor.

Zhou, et al.             Expires January 21, 2015              [Page 10]

Internet-Draft             APONF Architecture                  July 2014


   Special thanks are expressed to the authors of the ID 
   [ID.farrkingel-pce-abno-architecture], since a significant part of 
   the ABPD functional blocks are based on the architecture described in 
   [ID.farrkingel-pce-abno-architecture].

11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

12.  Informative References

   [I2RS] Interface to the Routing System (i2rs) charter, 
   http://datatracker.ietf.org/wg/i2rs/charter/

   [ID.draft-ietf-alto-protocol] R. Alimi, R. Penno, Y. Yang, "ALTO 
   Protocol", IETF Internet draft (work in progress), draft-ietf-alto-
   protocol-27, March 2014

   [ID.farrkingel-pce-abno-architecture] King, D. and A. Farrel, 
   "A PCE-based Architecture for Application-based Network Operations", 
   Feb 2014.

   [ID.karagiannis-aponf-problem-statement] G. Karagiannis, W. Liu, 
   T. Tsou, Q. Sun, and D. Lopez,"Problem Statement for Application 
   Policy on Network Functions (APONF)(work in progress)", June 2014.

   [ID.draft-sun-aponf-openv6-use-cases] C. Xie, Q. Sun, JF. Tremblay, 
   "Use case of IPv6 transition in APONF", IETF Internet draft 
   Work in progress), draft-sun-aponf-openv6-use-cases-00, July 2014

   [ID.draft-cheng-aponf-ddc-use-cases] Y. Cheng, C. Zhou, 
    G. Karagiannis, JF. Tremblay, "Use Cases for Distributed Data Center 
    Applicatinos in APONF", IETF Internet draft (Work in progress), 
    draft-cheng-aponf-ddc-use-cases-00, July 4, 2014

   [ID.draft-huang-aponf-use-cases] C. Huang, Jiafeng Zhu, Peng He, 
   Shucheng (Will) Liu, G. Karagiannis, "Use Cases on Application-
   centric Network Management and Service Provision" IETF Internet draft 
   (Work in progress), draft-huang-aponf-use-cases-01, Juy 2014

   [ID.draft-liu-aponf-using-abstract-view-use-case] W. Liu, T. Tsou, 
   G. Karagiannis, J. Saldana, "APONF Use Case: Using Abstract View of 
   Network by Application Developers", IETF Internet draft (Work in 
   progress), draft-liu-aponf-using-abstract-view-use-case-00, 
   July 4, 2014

   [ID.draft-bi-aponf-sdsavi] J. Bi, G. Yao, "Software Defined SAVI", 
   IETF Internet draft (Work in progress), 
   draft-bi-aponf-sdsavi-00, July 4, 2014

Zhou, et al.             Expires January 21, 2015              [Page 11]

Internet-Draft             APONF Architecture                  July 2014

   [NETCONF] Network Configuration (netconf) charter,   
   http://datatracker.ietf.org/wg/netconf/charter/

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

   [SFC] IETF SFC (Service Function Chaining) WG charter,  
   http://datatracker.ietf.org/wg/sfc/charter/


Authors' Addresses

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: cathy.zhou@huawei.com


   Tina Tsou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: Tina.Tsou.Zouting@huawei.com


   Diego Lopez
   Telefonica

   Email: diego@tid.es


   Georgios Karagiannis
   University of Twente

   Email: g.karagiannis@utwente.nl


   Qiong Sun
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing  100035
   P.R. China

   Email: sunqiong@ctbri.com.cn






Zhou, et al.             Expires January 21, 2015              [Page 12]