Internet DRAFT - draft-he-cdni-cap-info-advertising
draft-he-cdni-cap-info-advertising
CDNI Working Group Xiaoyan.He
Internet Draft Spencer.Dawkins
Intended status: Standards Track Huawei
Expires: September 2012 Ge.Chen
China Telecom
Yunfei.Zhang
Wei.Ni
China Mobile
March 6, 2012
Capability Information Advertising for CDN Interconnection
draft-he-cdni-cap-info-advertising-01.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 6, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
He et all Expires September 6, 2012 [Page 1]
Internet-Draft cap-info-advertising March 2012
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.
Abstract
This document describes protocol for capability information
advertising which is used to communicate capability and status
information among interconnected Content Delivery Networks (CDNs).
Table of Contents
1. Introduction ................................................ 3
1.1. Terminology ............................................ 3
1.2. Place of capability advertising in CDNI model ........... 3
2. Conventions used in this document ............................ 5
3. CDN selection criteria ...................................... 5
4. Description of information ................................... 6
4.1. General information .................................... 6
4.1.1. Service status .................................... 6
4.1.2. IP version ........................................ 7
4.2. Footprint .............................................. 7
4.3. Load status ............................................ 7
4.3.1. Basic serving indicator ............................ 8
4.3.2. Detailed resource status........................... 8
4.4. Cost preferences ....................................... 8
4.5. Authentication capability ............................... 9
4.6. Delivery service capability ............................ 10
5. Overview of the capability advertising protocol ............. 10
5.1. Transport mechansim of the protocol .................... 10
5.2. Opration mode of the protocol .......................... 10
5.3. Discovery of the protocol contact point ................ 11
6. Protocol Specification ..................................... 11
6.1. Encoding of downstream CDN information ................. 11
He et all Expires September 6, 2012 [Page 2]
Internet-Draft cap-info-advertising March 2012
6.1.1. Load status object ................................ 11
6.1.2. Cost object ...................................... 12
6.1.3. Authenticity object ............................... 12
6.1.4. Footprint object .................................. 12
6.1.5. Encoding of general information ................... 13
6.2. Message description ................................... 13
6.2.1. Report mode ...................................... 13
6.2.2. Query mode ....................................... 14
6.3. Message examples ...................................... 14
6.3.1. Report mode ...................................... 14
6.3.2. Query mode ....................................... 16
7. Security Considerations .................................... 17
8. IANA Considerations ........................................ 17
9. References ................................................. 17
9.1. Normative References................................... 17
9.2. Informative References ................................. 18
10. Acknowledgments ........................................... 18
1. Introduction
In the context of CDNI, the downstream CDN needs to advertise some
of its information to the upstream CDN to facilitate the upstream
CDN selecting an appropriate CDN as the target in request routing,
such as downstream CDN capabilities, resources and affinities (i.e.
Preferences or cost).
This document focuses on defining the information needed to be
exchanged in CDNI and the corresponding advertising protocol, which
is one of the main components of CDNI.
1.1. Terminology
This document reuses the terminology defined in [I-D.draft-cdni-
problem-statement].
1.2. Place of capability advertising in CDNI model
Figure 1 from [I-D.draft-cdni-problem-statement] illustrating the
CDNI model. The capability information advertising protocol is not
He et all Expires September 6, 2012 [Page 3]
Internet-Draft cap-info-advertising March 2012
explicitly shown. Although that might be changed later upon the
working group's decision, but now it is thought that capability
advertisement is part of the function of the Request Routing
interface.
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control Interface| +-------------+ |
|******* Control |<======|====|========>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | Logging Interface| +------*------+ *|
|* ***** Logging |<======|====|========>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | Request Routing | * * * *|
.....*...+-*---------*-+ | Interface | +-*---------*-+...*.*...
. |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . CDNI Metadata | * * *| .
. |* * * +-------------+ |. Interface | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ....Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request.............................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
He et all Expires September 6, 2012 [Page 4]
Internet-Draft cap-info-advertising March 2012
**** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI
Figure 1: CDNI Model
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. CDN selection criteria
An upstream CDN may perform downstream CDN selection according to
different kinds of filtering criteria deriving from CP's requirement
and/or its local policy.
One kind of criteria is derived from CP's requirement. Each CP is
most likely to expect to control the distribution and delivery of
its contents by its delegated CDN. To achieve that, CP reflects its
requirements via metadata pertaining to the content and transfer the
metadata to the CDN to enforce that. In the context of CDNI, this
metadata should also be further transferred to a downstream CDN for
the same purpose. Subsequently, while the upstream CDN receving a
content request and intends to select an appropriate downstream CDN
from multiple ones to redirect the request, it should filter the
downstream CDNs according the metadata, e.g. in the metadata, it is
required the content should be delivered via HTTP adaptive streaming
service, a downstream CDN without the capability should not be
selected. Therefore, the required capability contained in the
metadata as a source of filtering criteria is needed for CDN
selection and is to be advertised from a downstream CDN to an
upstream CDN.
Another kind of criteria is derived from upstream CDN's local policy.
There are various kind of local poicy deployed, e.g. minimal load
first, minimal expense first, optimal QoS preferred etc. To
implement these policies, relative capability/status information of
a downstream CDN should be advertised to its upstream CDN.
In addition, general information like service status, IP version of
downstream CDN should also be taken into account while making the
CDN selection.
Based on the above mentioned filtering criteria, we can list the
He et all Expires September 6, 2012 [Page 5]
Internet-Draft cap-info-advertising March 2012
corresponding capability and status information needed as followings:
* General information like the service status, IP version of the
downstream CDN is needed.
* Footprint of the downstream CDN is needed if proximity is
preferred while making routing decision.
* Load status of resources is needed if minimal load is preferred
while making routing decision.
* Cost information of downstream CDN is needed if minimal cost is
preferred while making routing decision.
* Delivery capability information like delivery service type, user
authentication method of downstream CDN is needed if CP's
requirements contained in CDNI metadata is the main preference of
routing decision.
Note: The information needed to be advertised according to the CDNI
metadata should be adjusted once protocol on that interface is
finalized.
4. Description of information
According to the CDN selection criteria listed in section 3, the
relative capability and status information advertised from a
dwonstream CDN to an interconnected upstream CDN is described in
detail in the following clause. The information is considered all as
mandatory unless otherwise state explicitly.
4.1. General information
4.1.1. Service status
Service status is used to indicate that the downstream CDN is in
service or out of service of CDNI. In service means that the
downstream CDN's status is normal and it is willing to take requests
from an upstream CDN. Out of service means that the downstream CDN can
not take any requests from an upstream CDN due to some abnormal cases,
e.g.:
O Some kind of resource on the downstream CDN is exhausted.
O Network link between the two connected CDNs is abnormal.
He et all Expires September 6, 2012 [Page 6]
Internet-Draft cap-info-advertising March 2012
O Downstream CDN is down.
4.1.2. IP version
IP address version of which a downstream CDN can serve for endpoints.
The value it takes could be "IPV4", "IPV6" and "IPV4&IPV6" the last
one means that the downstream CDN can serve for both the types of
endpoints.
4.2. Footprint
Footprint indicates the geographic region for which a CDN can serve.
It is identified by a set of country, state and city code
combination as defined in ISO 3166-2 or a set of autonomous system
number or a set of IP subnet.
A downstream CDN may advertise its footprint in a macro level e.g.
the country names of the serving regions belong to, it may also
advertise its footprint in a granularity of subset of the macro
level, e.g. detail state or city name of the serving regions. In the
later case, if there are multiple regions belong to one country a
downstream CDN can serve, then there will be multiple state or city
footprint elements in one advertisement message. This finer
granularity allows an upstream CDN understand the downstream CDN
more precisely but puts more requirements on the downstream CDN.
Therefore, it is up to the downstream CDN to determine to which
granularity it should advertise to an upstream CDN.
Upon each footprint, the other information like load status of
resources, capability information described in the following part of
this section are encapsulated to express the current status and
capabilities associated to this specific region.
4.3. Load status
Load status represents the status of resources assigned to an
upstream CDN by a downstream CDN and their current usage. This
information is important for the upstream CDN to implement the
minimal load first local policy. It contains a mandatory binary
serving indication to tell the upstream CDN whether the downstream
CDN can or cannot serve end users on behalf of the upstream CDN from
the perspective of resource load. It can optional contains the
detailed contracted and current used value of a specific resource in
case that the downstream CDN is willing to advertise such
information to the upstream CDN. For example they belong to one
group and have a strong trust relationship between them.
He et all Expires September 6, 2012 [Page 7]
Internet-Draft cap-info-advertising March 2012
4.3.1. Basic serving indicator
Basic serving indicator is used to tell whether a downstream CDN has
the ability to accept more additional requests from the upstream CDN
or not from the perspective of its resource load status.
4.3.2. Detailed resource status
Detailed resource status is used to advertise the maximum value of
capacity the downstream CDN committed to the upstream CDN and the
current assignments of it. This information can be leveraged by the
upstream CDN to implement a more accurate CDN selection if there
exists multiple candidate downstream CDNs through the previous basic
serving indication. It is reflected through the following three
category resource in detail:
* Connection Allowed, Connection Assigned
This information is used to indicate the maximum number of
simultaneous TCP connections for HTTP of the downstream CDN
committed to provide to the upstream CDN for content delivery and
the current used number respectively.
* Bandwidth Allowed, Bandwidth Consumed
This information is used to indicate the maximum value of bandwidth
for content delivery of the downstream CDN committed to provide to
the upstream CDN and current used value respectively.
Note: The value of "andwidth Allowed" and "Bandwidth Consumed" may
be an absolute value taking only the physical bandwidth of the CDN
into account or it may be a normalized value which may also consider
the disk I/O capacity and CPU usage as a whole. This depends on the
CDN specific implementation and is out of scope of CDNI.
* Cached Assets Allowed, Cached Assets
This information is used to indicate the maximum value of storage
capacity of cache of the downstream CDN committed to provide to the
upstream CDN and current used value respectively.
4.4. Cost preferences
Cost preferences of the downstream CDN. Different downstream CDNs
He et all Expires September 6, 2012 [Page 8]
Internet-Draft cap-info-advertising March 2012
may characterize cost via various metrics e.g. hop-count, air-miles,
or monetary cost. An upstream CDN can negotiate with a downstream
CDN on how to characterize cost of CDNI via the attributes "cost
type" and "cost mode".
Note: The detailed mechanism that the two interconnected CDNs
negotiating on the abstract cost assignment is out of scope of this
draft.
o type: identifies what the costs represent, e.g. hop-count,
monetary cost etc;
o mode: identifies how the costs should be interpreted.
Specifically, the mode attribute indicates whether returned costs
should be interpreted as numerical values or ordinal rankings. It is
important to communicate such information to the upstream CDN, as
certain operations may not be valid on certain costs returned by a
downstream CDN.
o cost: value of the cost corresponding to the selected type and
mode.
4.5. Authentication capability
Authentication capability describes the authentication type and
relative parameters a downstream CDN supports to the clients. It
provides information for content delivery such that the user agent
can be authenticated as a client when requesting content from a
downstream CDN. The authentication capability contains the
following attributes:
O type - a string indicating the authorization type "url-signing"
or "url-token". The "url-signing" type refers to URL signing
authorization. The "url-token" type refers to token-based
authorization.
O algorithm- a string containing the signature algorithm (e.g.
"md5", "sha-1", etc.).
He et all Expires September 6, 2012 [Page 9]
Internet-Draft cap-info-advertising March 2012
O key type - a boolean if true, URL signing uses symmetric keys,
otherwise asymmetric.
4.6. Delivery service capability
Type of the delivery service a downstream CDN supports, e.g.
Microsoft Smooth Streaming, Apple HTTP Live Streaming. It contains
the following attributes:
O service type- a string containing the type of the delivery
service e.g. "HLS"and "DASH".
5. Overview of the capability advertising protocol
5.1. Transport mechansim of the protocol
CDN capability is information coupling with a specified application
(CDNI), it should be conveyed via an application layer protocol
rather than any other underlying layer protocol e.g. IP layer
protocol which should de-coupling with any application. In this
document HTTP/1.1 protocol [RFC2616] is used as the transport
mechanism for capability information advertising as its a natural
choice for integration with existing applications and infrastructure.
5.2. Operation mode of the protocol
The capability information advertising protocol takes two modes. One
is report mode, where the downstream CDN advertises its capability
information to the upstream CDN during at a periodic interval, e.g.
every 5 minutes. The other one is query mode, where the upstream CDN
acquires the capability information from the downstream CDN
periodically, e.g. every 5 minutes. The upstream CDN utilizes the
capability information to makes its routing decision upon receiving
a content request from an end user.
He et all Expires September 6, 2012 [Page 10]
Internet-Draft cap-info-advertising March 2012
5.3. Discovery of the protocol contact point
To enable communication over the capability information advertising
protocol, the two interconnected CDNs need to know each other's
contact address. The contact address may be statically pre-
configured, dynamically discovered via control interface, or other
means. However, they are not specified in this document, as this is
considered not in the scope of the CDNI capability information
advertising protocol.
6. Protocol Specification
This section describes the details of the capability information
advertising protocol.
6.1. Encoding of downstream CDN information
6.1.1. Load status object
This object defines load status of resources of a downstream CDN
described in section 4.3.
Object{
JSONInteger ServeStatus;
JSONInteger MaxConnection;
JSONInteger CurrentConnection;
JSONString MaxBandWidth;
JSONString CurrentBandWidth;
JSONString MaxCacheStorage;
JSONString CurrentCacheStorage;
}LoadStatus,
He et all Expires September 6, 2012 [Page 11]
Internet-Draft cap-info-advertising March 2012
6.1.2. Cost object
Cost object defines cost preferences described in section 4.4.
Object{
JSONString CostType;
JSONString CostMode;
JSONInteger CostValue;
}Cost,
6.1.3. Authenticity object
Authenticity object defines authentication capability of a
downstream CDN described in section 4.5.
Object{
JSONString [AuthType]<1..*>;
JSONString [Algo]<1..*>;
JSONInteger Symmetric;
}Authenticity,
6.1.4. Footprint object
Footprint object defines footprint and status, capability associated
with the particular area the footprint identified. Footprint is
described in section 4.2.
Object{
JSONString Country;
JSONString State; [OPTIONAL]
JSONString City; [OPTIONAL]
LoadStatus loadStatus;
Cost cost;
He et all Expires September 6, 2012 [Page 12]
Internet-Draft cap-info-advertising March 2012
Authenticity authenticity;
JSONString [DeliveryType]<1..*>;
}FootPrint,
6.1.5. Encoding of general information
{
JSONString ServiceStatus;
JSONString [IPVersion]<"IPV4","IPV6">;
FootPrint [FootPrint]<0..*>;
}
6.2. Message description
The HTTP/1.1 protocol is used for capability advertising.
The HTTP request is HTTP POST for Report mode and HTTP GET for Query
mode respectively.
The request URI in both modes conforms to [RFC3986]. The URI format
in this document is as follows: HTTP://<host>/<url-path>, where the
<host> specifies a destination, and the <url-path> conveys the
message name.
The message body representation specified in this document takeing
JavaScript Object Notation(JSON) as example. However, other well-
defined representations (e.g., XML) are also acceptable.
6.2.1. Report mode
The Downstream CDN issues an HTTP POST message to the Upstream CDN
to report its capability information.
The message name in the request URI is "CdniCapReport".
He et all Expires September 6, 2012 [Page 13]
Internet-Draft cap-info-advertising March 2012
The Content-Type header field is "application/json".
The message body includes capability information.
Upon successful receipt of the POST request, the Upstream CDN
responds with a 200 OK message.
6.2.2. Query mode
The Upstream CDN issues a HTTP GET message to a Downstream CDN to
query its capability information.
The message name in the request URI is "CdniCapQuery".
Upon successful receipt of the GET request, the Downstream CDN
responds a 200 OK message with its capability information.
The Content-Type header field for the response is "application/json".
6.3. Message examples
This section gives some message examples for capability information
advertising protocol.
6.3.1. Report mode
The POST request and corresponding response are illustrated as below.
Request example (Downstream CDN to Upstream CDN):
POST http://contact-address.ucdn.example/CdniCapReport HTTP/1.1
Content-Type: application/json
He et all Expires September 6, 2012 [Page 14]
Internet-Draft cap-info-advertising March 2012
Content-Length: TBD
{
"ServiceStatus":"In",
"IPVersion":["IPV4","IPV6"],
"FootPrint":[
{
"Country":"China",
"State":"Beijing",
"City":"",
"LoadStatus":{
"ServeStatus":1,
"MaxConnection":5000,
"CurrentConnection":1000,
"MaxBandWidth":"1500M",
"CurrentBandWidth":"1000M",
"MaxCacheStorage":"5000TB",
"CurrentCacheStorage":"3000TB"
},
"Cost":{
"CostType" :"monetary",
"CostMode": "ordinal",
"CostValue": "1"
},
"Authenticity":{
"AuthType":["urlSigning","urlToken"],
"Algo":["MD5"],
"Symmetric":1
},
"DeliveryType":["HLS","HSS","HDS","RTSP"]
},{
"Country":"China",
"State":"Guangdong",
"City":"",
"LoadStatus":{
"ServeStatus":0,
"MaxConnection":5000,
"CurrentConnection":4900,
"MaxBandWidth":"1500M",
"CurrentBandWidth":"1450M",
He et all Expires September 6, 2012 [Page 15]
Internet-Draft cap-info-advertising March 2012
"MaxCacheStorage":"5000TB",
"CurrentCacheStorage":"4990TB"
},
"Cost":{
"CostType": "monetary",
"CostMode": "numerical",
"CostValue": "30"
},
"Authenticity":{
"AuthType":["urlToken"],
"Algo":["SHA1"],
"Symmetric":1
},
"DeliveryType":["HLS","HSS","HDS","RTSP"]
}]
}
Response example:
HTTP/1.1 200 OK
6.3.2. Query mode
The GET request and corresponding response are illustrated as below.
Request example (Upstream CDN to Downstream CDN):
GET http://contact-address.dcdn.example/CdniCapQuery HTTP/1.1
Response example:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: TBD
He et all Expires September 6, 2012 [Page 16]
Internet-Draft cap-info-advertising March 2012
The content of message body is the same as that of POST message
illustrated in section 6.3.1.
7. Security Considerations
Capability advertising is a main function which will affect the
final routing decision of an upstream CDN, security threats on it
include that any identity spoofing of the downstream CDN or changing
of the capability advertising message with malicious intent which
would cause the upstream CDN redirect an end user request to an
inappropriate downstream CDN which possible cannot provide service
to the end user.
It is mentioned in section 8 of the requirement draft [I-D.draft-
cdni-requirements], all the CDNI interface shall support secure
operation over unsecured IP connectivity (e.g. The Internet). This
includes authentication, confidentiality, integrity protection as
well as protection against spoofing and replay. As this security
requirement applies to all the CDNI interfaces and it is recommended
that the working group addresses this issue and considers a
consistent solution in another separate document later.
8. IANA Considerations
If the approach described in this document is adopted, we would
request that IANA allocate the message name "CdniCapReport" and
CdniCapQuery" in the HTTP Parameters registry.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
He et all Expires September 6, 2012 [Page 17]
Internet-Draft cap-info-advertising March 2012
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax and Semantics",
RFC 3986, January 2005.
9.2. Informative References
[I-D.draft-cdni-use-cases]
"Use Cases for Content Delivery Network Interconnection",
Gilles Bertrand, Stephan Emile, Grant Watson, Trevor
Burbridge, Philip Eardley, Kevin Ma, 22-Sep-11, <draft-ietf-
cdni-use-cases-03.txt>.
[I-D.draft-cdni-problem-statement]
"Content Distribution Network Interconnection (CDNI) Problem
Statement", Ben Niven-Jenkins, Francois Faucheur, Nabil
Bitar, 9-Sep-11, <draft-ietf-cdni-problem-statement-03.txt>.
[I-D.draft-cdni-requirements]
"Content Distribution Network Interconnection (CDNI)
Requirements", Kent Leung, Yiu Lee, 9-Sep-11, <draft-ietf-
cdni-requirements-02.txt>.
[I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-01 (work in
progress), July 2011.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-10 (work in progress), October 2011.
[I-D.draft-caulfield-metadata]
Caulfield and Leung, Ledraft-caulfield-cdni-metadata-core-00
"Content Distribution Network Interconnect (CDNI) Core Metadata",
October 2011.
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
The authors would like to thank Scott Wainner and Ben Niven-Jenkins
for their review and comments.
He et all Expires September 6, 2012 [Page 18]
Internet-Draft cap-info-advertising March 2012
He et all Expires September 6, 2012 [Page 19]
Internet-Draft cap-info-advertising March 2012
Authors' Addresses
Xiaoyan He
Huawei
B2, Huawei Industrial Base, 518129
China
Email: hexiaoyan@huawei.com
Spencer Dawkins
Huawei
Email: spencer@wonderhamster.org
Ge Chen
China Telecom
109 West Zhongshan Ave,Tianhe District,Guangzhou,P.R.C
Email: cheng@gsta.com
Yunfei Zhang
China Mobile
Email: zhangyunfei@chinamobile.com
Wei Ni
China Mobile
No.32 Xuanwumen West Street Xicheng District Beijing, 100053
China
Email: niwei@chinamobile.com
He et all Expires September 6, 2012 [Page 20]
