Internet DRAFT - draft-xia-ibnemo-icim

draft-xia-ibnemo-icim







Internet-Draft                                               Y. Xia, Ed.
Intended status: Standards Track                            T. Zhou, Ed.
Expires: December 2, 2016                                  Y. Zhang, Ed.
                                                                S. Hares
                                                                  Huawei
                                                               P. Aranda
                                                                D. Lopez
                                                             Telefornica
                                                            J. Crowcroft
                                                    Cambridge University
                                                                Y. Zhang
                                                            China Unicom
                                                            May 31, 2016


                    Intent Common Information Model
                        draft-xia-ibnemo-icim-02

Abstract

   Intent Common Information Model (ICIM) defines a unified model for
   expressing different layers' intent whatever role, responsibility,
   knowledge, etc.  This document provides an information model to be
   inherited and expanded to construct specific intent model in
   different areas.  According to this information model, network intent
   model is put forward which can satisfy users' need in different
   layers, such as, end-users, business developers, and network
   administers.

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 December 2, 2016.






Xia, et al.             Expires December 2, 2016                [Page 1]

Internet-Draft              Abbreviated-Title                   May 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Intent Common Information Model Overview  . . . . . . . . . .   3
     2.1.  Elements  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Relationships in ICIM . . . . . . . . . . . . . . . . . .   6
     2.3.  Intent and Policy . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Role-based Intent . . . . . . . . . . . . . . . . . . . .   7
     2.5.  Intent and FSM  . . . . . . . . . . . . . . . . . . . . .   7
   3.  Intent Modeling . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Intent overview . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  Top level intent expression . . . . . . . . . . . . . . .  10
     3.4.  Objects in the network  . . . . . . . . . . . . . . . . .  10
     3.5.  Type of result  . . . . . . . . . . . . . . . . . . . . .  11
     3.6.  Operation composition . . . . . . . . . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Network operations have traditionally been designed bottom-up
   starting with low level device interfaces designed by protocol
   experts.In order that interfaces could be wildly used by various
   users, information details are exposed as much as possible.  It
   enables better control of devices, but leaves huge burden of
   selecting useful information to users without well training.  Since
   the north bound interface (NBI) is used by network users, a more
   appropriate design is to express user intent and abstract the network



Xia, et al.             Expires December 2, 2016                [Page 2]

Internet-Draft              Abbreviated-Title                   May 2016


   from the top down.  The intent base NBI expresses what a network
   service consumer (e.g., application, operator) requires from the
   network but it does not completely specify or constrain how that
   service may or should be delivered by the network.  The intent is
   expected to be independent of protocols, network interface styles,
   vendor features, media attributes, or any other network
   implementations.

   Intent Common Information Model (ICIM) specifies a generic model for
   expressing key components of intent interface and the relationship
   between these components.  This document provides a common model
   which could be inherited from and expanded to construct specific
   intent interface in dedicated areas.  According to this information
   model, intent interface in network area can satisfy users' intention
   in different roles, such as, end-users, business developers, network
   administers, etc.

1.1.  Terminology

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

2.  Intent Common Information Model Overview

   Intent Common Information Model aims to specify a unified information
   model which satisfied different areas, scenarios, and other
   constraints.  So, it is a complete and detailed information model to
   define the constituent elements of intent.  However, not all elements
   need to be present when mapping this model to a specific data model,
   since some of the elements can be obtained by system automatically.
   From the overall perspective, construction elements of intent can be
   described as:

   -user of intent who author and own this intent

   -intent content which is a desired purpose and

   -the specific context which is the background circumstance
   information.

   Furthermore, in general, person's intent content usually describes
   the ultimate state of some objects or applies actions to these
   objects.  So intent content can be abstracted into further:

   -object which is the target for intent

   -result which is a desired state and



Xia, et al.             Expires December 2, 2016                [Page 3]

Internet-Draft              Abbreviated-Title                   May 2016


   -operation which is the specific actions to achieve a purpose.

2.1.  Elements

   2.1.1 Users

   User is an abstract class which specifies the subject and owner to
   express the intent.  It is a performance of roles in real world, that
   is, each user serves as a role or a combination of roles actually.
   For example, end-users, business designers, network administrators
   are all instances of User class which act as specific roles.  When a
   user is labeled as a role, he will have the desire and requirement to
   express intent belonged to this role.  Owning to different network
   abstraction views, intent is different for specific user when this
   information model is applied to specific scenario.

   Though one user serves as one role in most cases, it is sensible and
   acceptable that one user serves as multiple roles and intent of these
   users may involve more functions and huge operation scope.

   2.1.2 Context

   Context is an abstraction class which refers to a set of specific
   background information such as, timer, price, and so on.  Context has
   a huge influence on a person designing a detailed plan or selecting
   the best program to achieve a purpose.  For example, when an
   enterprise plans to build a dedicated connection between two sites,
   price and distance will be the context in this scenario.  While may
   not be part of how an entity expresses or executes some intent, it is
   a factor that must be considered with the expression of intent.

   2.1.3 Object

   Object is an abstract class which refers an abstract class which
   defines some entities affected or managed by intent.  For the
   management, users could manage life cycle of the objects through some
   concrete operations, such as, create, update, delete, etc.  In
   addition, users could use other specific operations to affect the
   behavior of managed objects.  For example, a business designer want
   all traffic be filtered by a special firewall.  The object of this
   business designers intent could be the all traffic flowing on a
   specific network (e.g.  L3VPN), and this intent impacts the
   forwarding behavior of the traffic network.  Object is different in
   specific area.  In network area, object is an aggregation class with
   CustomerFacingNode, Connection and ServiceFlow.  For objects, users
   could construct some specific objects to achieve intent, and it is
   also allowed for users to assign intent to existing resources which
   is physical/virtual devices or defined by other ways.



Xia, et al.             Expires December 2, 2016                [Page 4]

Internet-Draft              Abbreviated-Title                   May 2016


   2.1.4 Result

   Result is a type of intent which refers to an final state or
   something an individual wants to achieve.  This type of intent
   shields difference and diversity of an environment away from the
   users' intent.  The person just describes the final state of objects
   without worrying about how to achieve it.  For example, a result
   could be that the company accesses any sites on the Internet safely.
   It just defines a result that ignores technology details, such as,
   firewall, ACL, and so on.

   In addition to the expecting state, violation is another special
   state which has an important status when achieving integral
   compliance.  For example, a typical scenario is that one specific
   tenant does not want his virtual machines to share a some hypervisor
   with other tenants.  This type of result just shows the undesired
   state which express users' intent, so this kind of intent should be
   another type of result.

   2.1.5 Operation

   Operation is a type of intent which refers to some specific actions
   an individual desires to take for realizing the purpose.  This type
   of intent formulates explicit plan to realize a purpose which may
   take a better control of the whole system.  According to the
   diversity of system support capability, there are large sets of
   operations for users to take.

   Generally, operations can be divided into two categories.  One is
   action without condition.  For example, create a virtual machine.
   This kind of operation defines a concrete action which is executed
   immediately without any trigger.  The other is action with condition.
   For this kind of operations, condition is a trigger for the action.
   And actions will not be executed immediately until the condition
   clause is tested to be true.  For example, "do load balancing when
   the utilization of a link exceeds 80%".  In this example,
   "utilization of a link > 80%" is the trigger, and "do load balancing"
   is the action.  Action will not be executed until the trigger is
   true.  Actions are different according to users' role which has
   different abstraction views.  And actions will not be detailed
   configurations in devices, but high-level and packaged functions
   which are translated into configurations.  For example, the service
   providers' action "do load balancing" is device independent, and
   network operators' action may configure load balance pools depending
   on specific devices.






Xia, et al.             Expires December 2, 2016                [Page 5]

Internet-Draft              Abbreviated-Title                   May 2016


2.2.  Relationships in ICIM

   2.2.1 Relationship between Result and Operation

   Users are free to express their intent, no matter it is an final
   result or specific operations in their mind, but there are some
   relationships between these two basic types of intent.  Result refers
   to an ultimate and relatively permanent status, regardless which ways
   to maintain it.  However, operations specify what kinds of action
   need to take explicitly, which more focus on temporary or specific
   behavior to achieve some goal.  One typical service scenario is that
   all links' utilization should not exceed 80%. By way of Result, the
   intent will be expecting all links' utilizations are smaller than 80%
   (or avoiding any link' utilization exceeds 80%).  By way of
   Operation, the intent will be if links' utilization exceeds 80%,
   redirect some flows to other links (or some other actions could
   achieve this goal).

   For result, users just need to express the goal without worrying how
   to implement it in a specific system which allows users to focus on
   real requirement.  To achieve the result, it needs some reasoning
   mechanisms to transfer it to real executable operations which are
   supported by specific system.  So in a specific scenario, a result
   can generate a set of concrete operations.  For the above example, if
   user just expresses the result, that is, all links' utilizations are
   smaller than 80%. The system will choose suitable operations to
   achieve this status automatically, i.e., expand the capacity of links
   whose utilization exceed 80%, or redirect flows to other links whose
   capacities are far less than 80%.

   2.2.2 Relationship between Object and Operation

   Operation refers to some specific actions on some objects, so object
   is the target of an action.  In general, any action will include some
   objects to execute this action.  When users want to execute some
   actions to achieve goals, they may construct the target objects and
   assign specific actions on them, and it is allowed for users to use
   existing resources to do some operations.  Though object is the
   target of action, it offers the constraint for optional operations.
   For example, for a virtual machine, the optional operations are
   create, delete, migrate, etc.

   2.2.3 Relationship between Object and Result

   Result refers to some final state for some objects.  This type of
   intent does not define which specific operations to take, but only
   express the desired state of objects.  So it is independent on
   objects' concrete capability.  For example, intent is all virtual



Xia, et al.             Expires December 2, 2016                [Page 6]

Internet-Draft              Abbreviated-Title                   May 2016


   machines' CPU utilization could not exceed 80%. It does not assign
   specific operations.  So reasoning mechanism will choose suitable
   operations to satisfy this intent, such as, migrate virtual machine
   or expand it.

2.3.  Intent and Policy

   In industry, Policy already has a clear definition, such as in
   RFC3060.  Policy rule consists of an event, a set of conditions and a
   set of actions.  When an event occurs, actions will be taken until
   condition clauses are evaluated to be true.

   As mentioned above, intent refers to a purpose in achieving result or
   performing operation.  The intent has a larger scope compared with
   the policy since Intent can express both result and operation.  On
   one hand if a result is described by intent, there may be no specific
   action given to show how to achieve this intent.  On the other hand,
   if operation described by intent, conditions of action is optional.
   Policy is a specific form of operation in intent.

2.4.  Role-based Intent

   In an integrated system, roles are divided into several categories
   according to the division of work, architecture of system, etc.  In
   network system, network abstraction will be quite different in the
   perspective of each role.  So intent has strong dependencies on
   roles.  Intent expressed by different categories of roles will focus
   on different points and have different intent expression.

   For example, if an agent is labeled as service provider role, he may
   just care about the high-level services, such as, security
   communication.  And if he is labeled as network architecture role, he
   will care about the details of the whole architecture.

2.5.  Intent and FSM

   Intent, standing on the perspective of users, expresses intuitive
   service requirement, including desired network services or means to
   fulfill network goals.  In other words, the Intent model defines a
   series of FSMs(finite-state machines) and transition between these
   state machines to implement the managment of service's life cycle.

   Specifically, each state machine, combining with elements which
   construct intent, represents a specific state of one or several
   objects, for example, a normal-work state or exception state of a
   connectivity service.  Both current state(or initial state) and
   result state(or desired state) are one type of state machines, the
   main difference between which is that result state is an ultimate



Xia, et al.             Expires December 2, 2016                [Page 7]

Internet-Draft              Abbreviated-Title                   May 2016


   state repects users' requirement, otherwise, current state represents
   a initial state needs to be transited to others states to satisfy
   users' intent.

   Operation, including specific actions, represents the transition
   between current state and result state that describe the state of
   objects as mentioned above.  The transition between service states
   could be shown as below.

                                  operation
                          +-------------------------+
                          |                         |
                   +------+------+           +------+-----+
                   |current state+-----------+result state|
                   +-------------+           +------------+
                            Figure 1 intent and FSMs

   Just as mentioned in the section 2.2, operation is the mean to change
   network service state to fulfill users' intent, namely, the result
   state.  For users, who clearly grasp how to reach result state or
   have to assgin actions for other reasons, they could descibe specific
   operations in intent to realize the result.  Otherwise, users just
   need to descibe what's the result or desired state, and the complier
   system will produces specific operations to achive the result.

   A typical scenario is the constraint for bandwidth utilization.  For
   user who does not know the ways to adjust bandwidth, he may express
   his intent with desired state, namely, the result state is bandwidth-
   utilization<80% and system will choose suitable ways to adjust
   bandwidth, such as, expansion or changing route.  But for users who
   has experience with network operation, he may express his intent with
   operaiton, namely, do load balancing if bandwidth-utilization>80%.
   Both expressiones descibe service state machines and transition, but
   operation could implement the transition between current state and
   result state.

3.  Intent Modeling

   This section defines the concept and hierarchy of intent, and
   describes the Intent Common Information Model.

3.1.  Notation

   The notation used in this document is adapted from the UML (United
   Modeling Language).  We will use the UML for the intent information
   modeling.  This section listed symbols that will be used in this
   document for relationships among information models.




Xia, et al.             Expires December 2, 2016                [Page 8]

Internet-Draft              Abbreviated-Title                   May 2016


   -->

   Stands for the association relationship.  Association represents the
   static relationship shared among the objects of two classes.

   --A

   Stands for the aggregation relationship.  Aggregation is a variant of
   the "has a" association relationship; aggregation is more specific
   than association.  It is an association that represents a part-whole
   or part-of relationship.  Aggregation can occur when a class is a
   collection or container of other classes, but the contained classes
   do not have a strong lifecycle dependency on the container.  The
   contents of the container are not automatically destroyed when the
   container is.

   --C

   Stands for the composition relationship.  Composition is a stronger
   variant of the "has a" association relationship.  It is more specific
   than aggregation.  Composition usually has a strong lifecycle
   dependency between instances of the container class and instances of
   the contained class.  If the container is destroyed, normally every
   instance that it contains is destroyed as well.

   --G

   Stands for the generalization relationship.  The Generalization
   indicates that one of the two related classes (the subclass) is
   considered to be a specialized form of the other (the super type) and
   the super class is considered a 'Generalization' of the subclass.  In
   practice, this means that any instance of the subtype is also an
   instance of the super class.

3.2.  Intent overview

   In general, intent is one's specific mental activity, so it strongly
   depends on the subject.  Different users may have different intent.
   In addition, context, omitted usually, is an important factor when
   achieving purpose, which offers necessary background information to
   impact the decision.  It illustrates the overview of the intent.
   Figure 2 indicates that the user has intent in some context.  For
   example, an enterprise wants to block all http traffic in work time.
   In this intent, the user is the enterprise, the intent is to block
   all http traffic in the work hours, and the context includes the
   definition of the "enterprise" and the "work hours".





Xia, et al.             Expires December 2, 2016                [Page 9]

Internet-Draft              Abbreviated-Title                   May 2016


                   +------+ has +------+ in  +-------+
                   | user +---->+intent+---->+context|
                   +------+     +------+     +-------+
                  Figure 2 general prescription for intent

3.3.  Top level intent expression

   In Cambridge Dictionaries, the definition of "intent" is the fact
   that you want and plan to do something.  So, in general, intent
   refers to an agent's purpose on getting the result or performing some
   specific operation.  In specific areas, these results or operations
   will relate to some objects.  Figure 3 describes the general
   expression of intent.

                                +--------+
                                | intent |
                                +-C-A-A--+
                                  | | |
                      +-----------+ | +-------------+
                      |             |               |
                      |             |               |
                  +---+---+      +--+---+     +-----+-----+
                  | object|      |result|     | operation |
                  +-------+      +------+     +-----------+
                        Figure 3 intent expression

   One type of intent is to express key operations that a user wants to
   execute.  The underlying intent system can generate a complete
   operation list from user's request.  The other type of intent is to
   express the result or state without dictating any operations.

   For example, intent of a user may be a result without defining how to
   realize it, such as, requiring security communication between two
   sites, or dictate some detailed operations in order to achieve a
   purpose, such as, filtering all traffics by firewall between these
   two sites.

3.4.  Objects in the network

   Object is an abstraction class which can be inherited from and
   expanded in different area.  It, cared about by users, represents the
   target of result and operations.  In network area, the object, i.e.
   the target of intent, can be generalized into
   CustomerFacingNode(CFN), Connection and ServiceFlow, as shown in
   Figure 4.






Xia, et al.             Expires December 2, 2016               [Page 10]

Internet-Draft              Abbreviated-Title                   May 2016


                                    +------------------+
                                +---+CustomerFacingNode|
                                |   +------------------+
                    +------+    |
                    |      +G+--+   +----------+
                    |Object+G+------+Connection|
                    |      +G+--+   +----------+
                    +------+    |
                                |   +-----------+
                                +---+ServiceFlow|
                                    +-----------+
                  Figure 4 common objects in network area

   The CustomerFacingNode represents the functions a user-facing network
   node may provide in a network such as network services, forwarding
   functions (firewall, load balancer, virtual router, and others), or a
   group of network elements.  A group of network elements can be a
   subnet, an autonomous system, or a confederation of autonomous
   systems.

   The Connection describes the link resources between two CFNs.  These
   link resources construct the foundation of communications between
   different CFNs.  User could take connection as physical link, and
   assign bandwidth on it.

   The ServiceFlow refers to the traffic in network which describes data
   packets have some certain common characters.  ServiceFlow model
   describes the connectivity in virtual network, namely, if users want
   to describe the communications between CFNs without direct
   connection, they have to define the service flow and assign operation
   to allow the service flow.

3.5.  Type of result

   Result refers to the final state which is expected or avoided.
   Figure 5 describes two types of result.  Both of the results just
   show the performance of some objects, without caring about how to
   reach them.

   Result could be expressed as a set of logic clause connected with
   propositional literals including AND, OR and NOT.  The logic clause
   could be described as an expression with relational operators, such
   as equal, greater-than, less-than, belong-to.

   With this model, users could express the desired state as an
   expression.  System will resolve the expression and seek ways to make
   it true.  The result will be achieved when the expression is
   evaluated to be true.  The typical examples are shown as follows:



Xia, et al.             Expires December 2, 2016               [Page 11]

Internet-Draft              Abbreviated-Title                   May 2016


   - For example, a user may express an intent as the network link
   utilization must less than 80%. This expression is a type of result
   which describes an expected state.  The left operand is the
   utilization of all links, the right operand is 80%, and the operator
   is less-than.

   - Another example is an enterprise wants the development team and
   sales team not to share a common link.  In this intent, the left
   operand is the union of the link set of development team occupied and
   the link set of sales team occupied.  The operation will be equal,
   and the right operator is an empty set.

   Though a unified information model for the Result is proposed in
   here, it is still a preliminary version which just expresses the
   basic components.  The formalization and standardization are still
   open issues need to be studied further.  More comprehensive and
   detailed manifestations will be added in the next version.

                                 +--------+
                                 | result |
                                 +--G-G---+
                                    | |
                              +-----+ +-----+
                              |             |
                          +---+----+    +---+---+
                          | expect |    | avoid |
                          +--------+    +-------+
                       Figure 5 expression of Result

3.6.  Operation composition

   Operation refers to some specific actions in order to achieve some
   purposes.  An operation must have some actions.  However, if
   condition and constraint can be optionally defined in operations, it
   depends on specific scenario and users' requirement.  Once a
   condition is involved in operation, actions will not be executed
   immediately until condition is true.  In additional, constraint
   restricts action itself or the scope of action.

   For example, redirect traffic to back-up link when the utilization of
   current link exceeds 80%, except the flow from VIP user.  In this
   scenario, the condition is link utilization exceeds 80%, the action
   is redirect traffic, and the constraint is VIP flow could not be
   redirected.







Xia, et al.             Expires December 2, 2016               [Page 12]

Internet-Draft              Abbreviated-Title                   May 2016


                                 +---------+
                                 |operation|
                                 +--A-C-A--+
                                    | | |
                          +---------+ | +------------+
                          |           |              |
                          |           |              |
                     +----+----+   +--+---+    +-----+----+
                     |condition|   |action|    |constraint|
                     +---------+   +------+    +----------+
                      Figure 6 composition of operation

4.  Security Considerations

   TBD

5.  IANA Considerations

   This draft includes no request to IANA.

6.  Acknowledgements

   The authors would like to thanks the valuable comments made by Wei
   Cao, Sheng Jiang, Zhigang Ji, Xuewei Wang, Shixing Liu, Yan Zhang.

7.  Informative References

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

Authors' Addresses

   Yinben Xia
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District
   Beijing  100095
   China

   Email: xiayinben@huawei.com


   Tianran Zhou
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District
   Beijing  100095
   China

   Email: zhoutianran@huawei.com



Xia, et al.             Expires December 2, 2016               [Page 13]

Internet-Draft              Abbreviated-Title                   May 2016


   Yali Zhang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District
   Beijing  100095
   China

   Email: zhangyali369@huawei.com


   Susan Hares
   Huawei Technologies Co., Ltd
   7453 Hickory Hill Saline
   MI  48176
   USA

   Email: shares@ndzh.com


   Pedro Andres Aranda
   Telefornica I+D
   Don Ramon de la Cruz, 82 Street Madrid
   28006
   Spain

   Email: pedroa.aranda@telefonica.com


   Diego R. Lopez
   Telefornica I+D
   Don Ramon de la Cruz, 82 Street Madrid
   28006
   Spain

   Email: diego.r.lopez@telefonica.com


   Jon Crowcroft
   University of Cambridge Computer Laboratory
   William Gates Building, 15 JJ Thomson Avenue Cambridge
   CB3 0FD UK

   Email: jon.crowcroft@cl.cam.ac.uk









Xia, et al.             Expires December 2, 2016               [Page 14]

Internet-Draft              Abbreviated-Title                   May 2016


   Yan Zhang
   China Unicom P.R.
   China

   Email: zhangy1036@chinaunicom.cn














































Xia, et al.             Expires December 2, 2016               [Page 15]