Network Working Group YL. Zhao
Internet-Draft J. Zhang
Intended status: Informational BUPT
Expires: April 23, 2012 RQ. Jing
China Telecom Beijing Research
Institute
DJ. Wang
XH. Fu
ZTE Corporation
October 21, 2011
Protocol Extension Requirement for Cooperation between PCE and
Distributed Routing Controller in GMPLS Networks
draft-zhaoyl-pce-dre-03
Abstract
Path Computation Element (PCE) is proposed for path computation in
multi-layer and multi-domain networks where PCE can be implemented in
either centralized method or distributed method. In the former case,
PCE can serve tens or hundreds of nodes simultaneously, while in the
later case, each node is equipped with a PCE, which can be regarded
as a distributed routing controller (DRC) in GMPLS networks and each
one of those provides similar path computation capability. PCE and
DRC have different advantages in path computation respectively. PCE
is suitable for cross-layer and cross-domain path computation,
especially in multi-constraints environment. But distributed routing
controller is good at path computation in parallel ways and
distributed network control in local domain. A cooperative path
computation architecture named Dual Routing Engine (DRE) is necessary
to be used in the future networks, for it based on the ideas of the
cooperation of these two types of path computation engines and can
take the advantages of both centralized and distributed method by
which the PCE is implemented. The corresponding PCE communication
protocol extension and other protocol requirements for cooperation
between PCE and distributed routing controller are listed in this
document to recommend the standard interfaces between different
components in DRE architecture.
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-
Zhao, et al. Expires April 23, 2012 [Page 1]
Internet-Draft Cooperation between PCE and DRC October 2011
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 April 23, 2012.
Copyright Notice
Copyright (c) 2011 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.
Zhao, et al. Expires April 23, 2012 [Page 2]
Internet-Draft Cooperation between PCE and DRC October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. Cooperative Architecture based on PCE and Distributed
Routing Controller . . . . . . . . . . . . . . . . . . . . . . 6
4.1. DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Different Application Scenarios . . . . . . . . . . . . . . . 9
5.1. Cross layers and cross domains . . . . . . . . . . . . . . 10
5.2. Independent coexistence . . . . . . . . . . . . . . . . . 10
5.3. Security backup . . . . . . . . . . . . . . . . . . . . . 10
5.4. Policy-enabled . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Constraint-based . . . . . . . . . . . . . . . . . . . . . 11
5.6. Service-oriented . . . . . . . . . . . . . . . . . . . . . 11
5.7. Cooperation between network level and node level . . . . . 11
6. PCEP Extension Requirements . . . . . . . . . . . . . . . . . 12
6.1. PCEP extension requirement for the communication
between RES and PCE . . . . . . . . . . . . . . . . . . . 12
6.2. PCEP extension requirement for the communication
between RES and DRC . . . . . . . . . . . . . . . . . . . 12
7. Other Protocol Extension Requirements . . . . . . . . . . . . 13
7.1. OSPF-TE extension requirement for the cooperative
architecture . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. RSVP-TE extension requirement for the cooperative
architecture . . . . . . . . . . . . . . . . . . . . . . . 13
8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Zhao, et al. Expires April 23, 2012 [Page 3]
Internet-Draft Cooperation between PCE and DRC October 2011
1. Introduction
Path Computation Element (PCE) is proposed to complete the
constraint-based shortest path computation in Multi-protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) multi-layer and multi-
domain networks [RFC4665]. And a series of Request for Comments
(RFCs) related to PCE technology, such as requirements for PCE
discovery, PCE Communication Protocol (PCEP), a backward recursive
PCE-based computation procedure (BRPC) and so on, have been
standardized. Studies have been proving that PCE is suitable for
cross-layer and cross-domain design of networks, capable of end-to-
end path computation under multiple constraints [1-2] and could be
potentially applied to resource assignment and routing optimization
[3-4]. PCE can be implemented either in centralized method or
distributed method. In the former case, PCE can serve tens or
hundreds of nodes simultaneously. while in the later case, each node
is equipped with a PCE, which can be regarded as a distributed
routing controller (DRC) in GMPLS networks and each one of them
provides similar path computation capability. DRC in GMPLS/ASON
control plane is good at the path computation in parallel ways and
distributed network control in local domain. On the other hand, DRC
can also be used in the management and configuration of resource in
internal node. Becaues of that the huge bandwidth requirement is
emerging, links with the transmission capacity of Tbit/s and
switching at Pbit/s are necessary for next generation optical
networks. According to the level of current photonics technology
level, the node's architecture should to be very complicated with
large power consumption. Therefore, how to configure the switching
architecture in the node will be a very important issue for the
entire network performance. On the other side, of course, PCE and
DRC has corresponding disadvantages respectively.
In order to optimize the performance of optical networks under
different application scenarios, PCE and distributed routing
controller are needed to cooperate with each other. A cooperative
path computation architecture named Dual Routing Engine (DRE) is
proposed, which includes two types of path computation engines, i.e.
PCE and distributed routing controller, and can combine advantages of
both of them. In this document, several different application
scenarios are described. And PCE communication protocol extension
and other protocol extension requirements for cooperation between PCE
and distributed routing controller are also listed here.
1.1. 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 [RFC2119].
Zhao, et al. Expires April 23, 2012 [Page 4]
Internet-Draft Cooperation between PCE and DRC October 2011
2. Terminologies
LSR: Label Switching Router.
LSP: Label Switched Path.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by the Path Computation Element.
PCE (Path Computation Element): an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
PCEP: PCE Communication Protocols, the communication protocol between
PCC and PCE.
DRC: Distributed Routing Controller, the module that can complete
path computation in local domain or in internal node.
DRE: Dual Routing Engine, including PCE and DRC.
TED: Traffic Engineering Database.
RID: Resource Information Databases.
3. General Assumptions
PCE and distributed routing controller are two path computation
engines which have been standardized by IETF working group. They can
both complete the path computation in GMPLS networks. In order to
show how the cooperative architecture based on PCE and distributed
routing controller works, some assumptions as follows should be made
before.
o Each GMPLS-based control node is equipped with a distributed
routing controller which can complete the path computation in
local domain and even the path computation and resource
configuration in the internal node, and each domain is equipped
with no less than one PCE which can not only complete the intra-
domain path computation, but also complete the inter-domain path
computation.
o The topology and TE information are updated as soon as any change
occurs in the network, and the information kept at PCE and
distributed routing controller are synchronized by OSPF-TE.
Zhao, et al. Expires April 23, 2012 [Page 5]
Internet-Draft Cooperation between PCE and DRC October 2011
o PCE and distributed routing controller can be selected arbitrary
according to the local routing strategy.
o Constraints and strategies can be considered by PCE during the
process of the intra-domain path computation and the inter-domain
path computation.
o An end-to-end path which crosses domains or crosses layers can be
completed by several PCEs or several DRCs or several PCEs and
DRCs. For example, the section of an end-to-end path in one
domain may be computed by PCE, but the other section of this path
in another domain may be computed by DRC.
4. Cooperative Architecture based on PCE and Distributed Routing
Controller
As shown in Fig. 1, cooperative architecture consists of Path
Computation Element (PCE) and distributed routing controller (DRC).
Both of them maintain Traffic Engineering Databases (TEDs) to keep
network topology and other status information within the scope of
their respective functions. There is a function module named Routing
Engine Selector (RES) at each control node, which is responsible for
managing the switchover process between PCE and DRC and choosing the
right one when a LSP setup request is arriving. RES as well as
posses the function of PCC when cooperating with PCE and DRC and can
be implemented in Connection Controller (CC) module of GMPLS-based
control plane.
Zhao, et al. Expires April 23, 2012 [Page 6]
Internet-Draft Cooperation between PCE and DRC October 2011
------- -------
| PCE |-------------------------| PCE |
------- -------
/|\ /|\
/ | \ / | \
/ | \ / | \
-----------/---|---\---------- ----------/---|---\----------
| / ------- \ | | / ------ \ |
| / | RES | \ | | / | RES | \ |
| / ---|--- \ | | / ---|--- \ |
| / /---|---\ \ | | / /---|---\ \ |
| / /| DRC |\ \ | | / /| DRC |\ \ |
| / / ------- \ \ | | / / ------- \ \ |
| / / \ \ | | / / \ \ |
| / / \ \ | | / / \ \ |
| / / \ \ | | / / \ \ |
| ------- ------- | | ------- ------- |
| | RES |-----------| RES |-----| RES |-----------| RES ||
| ---|--- ---|--- | | ---|--- ---|--- |
| ---|--- ---|--- | | ---|--- ---|--- |
| | DRC | | DRC || || DRC | | DRC ||
| ------- ------- | | ------- ------- |
| domain A | | domain B |
------------------------------ -----------------------------
Fig.1 Cooperative architecture in multi-layer and multi-domain
networks
4.1. DRC
DRC offers general routing functions based on GMPLS/ASON control
plane including link state adverting, topology updating and path
computation. A typical DRC contains two essential modules which are
topology analysis module and path computation module. The former
floods network topology and resource utilization information to
sychronize TED maintained on each node. The latter responds to a
routing request from Connection Controller (CC), finds the optimized
path solution and returns it to CC. Besides these general routing
functions, DRC can also complete the resource allocation and
configuration, which refer to internal resource allocation, ports
interconnection, and switch fabric configuration in the internal
node. This function is getting more and more important as the
structure of the internal node is getting more and more complex.
Details of DRC's operation are out of this document's scope.
Zhao, et al. Expires April 23, 2012 [Page 7]
Internet-Draft Cooperation between PCE and DRC October 2011
4.2. PCE
PCE is of particular advantage of centralized path computation in
multi-layer and multi-domain networks, especially in multi-
constraints environment. There is a Client/Server model between RES
and PCE. RES sends a TE-LSP computation request to PCE. PCE
performs path computation and returns the results back to RES.
As shown in Fig.2, RES chooses the best PCE based on a certain policy
first. It sends performance query requests to multiple related PCEs,
each of which evaluates itself individually and then feeds back to
the RES. RES gathers performance status information from PCEs and
decides which PCE is feasible. Thus a combination of RES and PCE is
founded. Secondly PCE deals with the path computation requests
coming from RES by the using of message parser. After the message
parsing, if a request carries path information, it will be delivered
towards path computer module. Or, if it carries policy information
from RES, it should be firstlly interpreted by policy parser along
with local policy settings and then loaded into path computer.
Finally path computer implements multi-constraint routing on the
basis of the path information, policy information and TE information.
If path computation is successful the details of the whole route will
be returned to RES. If it only gets an incomplete route a new
application for path computation request will be sent to the next hop
RES. Then a PCE or DRC will be selected to complement the incomplete
route.
Zhao, et al. Expires April 23, 2012 [Page 8]
Internet-Draft Cooperation between PCE and DRC October 2011
---------------------
| RES |__________
| in Domain A | |
--------------------- |
| |
1.Sending the path computation |
request to the selected PCE |
| | _________________
__________________________________ | |4. Whether to |
| | | | Response the |
| ____________________ | | |RES in domain A or|
| | | | | | to the |
| | The Message Parser | | | | next hop RES |
| | | | | /|is depending on the
| | | | | / | output of path |
| -------------------- | | / | computer |
| | | | / ------------------
| | | | /
| 2.Delivering the message | | /
| to policy parser or directively | | /
| to path computer according to | |/ -------------------
| the information carried |----+-----| RES |
| | | | | in Domain B |
| ----------- ----------- | -------------------
| | | | | |
| | The | | Path | |
| | Policy | |Computation| |
| | Parser | | Module | |
| | | | | |
| ----------- ----------- |
| | | |
| 3.Passing the reques to path |
| computer after policy parsing |
| |
| The Selected PCE |
|__________________________________|
Fig.2 The path computation request handlling procedure of PCE
5. Different Application Scenarios
Cooperation between PCE and DRC is one of the key issues in the
cooperative architecture, for it helps to achieve fast and exact
routing due to the advantages of both PCE and DRC. This section will
list several typical application scenarios of cooperation between PCE
and DRC.
Zhao, et al. Expires April 23, 2012 [Page 9]
Internet-Draft Cooperation between PCE and DRC October 2011
5.1. Cross layers and cross domains
It is necessary for PCE to collaborate with DRC when the requirements
for path computation occur in multi-layer and multi-domain GMPLS
networks. PCE could be shared among several domains or layers and
make the best use of the inter-domain and inter-layer network
resources, so it is more suitable for inter-domain or inter-layer
path computation. In contrast to PCE, DRC usually runs to fulfill
intra-domain or intra-layer routing.
5.2. Independent coexistence
Both PCE and DRC are working independently under this scenario.
While one customer applies a TE-LSP computation, the respective RES/
RESs could select PCE or DRC arbitrarily. Of course each time only
one path computation engine can be selected. If a lot of
applications for path computation arrive simultaneously, the burst
computing load may be also balanced between them according to the
implementation of RES. The changing topology and resource status
information should be maintained in PCE and DRC in time although it
is difficult to manage the information synchronization on both sides.
5.3. Security backup
The cooperation mechanisms among different engines make it possible
that PCE and DRC backup each other to enhance the routing security
and reliability, since they both satisfy the demands of path
computation from customers. When the working engine (e.g. PCE)
fails, computation tasks could be switched to another reserved engine
(e.g. DRC) as soon as possible. In such a case both PCE and DRC
should maintain the accordant network topology and resource status
information.
5.4. Policy-enabled
In order to compute the optimal path in consideration of traffic
engineering, different policies are implemented, which mean there are
series of rules and actions from management plane or control plane.
PCE is obviously more suitable for policy-enabled path computation
framework than DRC. Tab.1 lists some typical policy application
instances that may be exerted to the cooperative path computation
architecture. Effective combinations of the above scenarios as well
as possible new scenarios could occurence in the real networks.
Zhao, et al. Expires April 23, 2012 [Page 10]
Internet-Draft Cooperation between PCE and DRC October 2011
+------------------------+------------------------------------------+
| Policy application | Description |
| scenarios | |
+------------------------+------------------------------------------+
| Policy configured | To centrally administer configured paths |
| paths | |
| Provider selection | To be applied in multi-provider |
| policy | topologies |
| Policy based | To provide constraints in a path |
| constraints | computation request |
| Advanced load | To balance the traffic load for the |
| balancing | whole network |
+------------------------+------------------------------------------+
Policy-enabled path computation instances
Table 1
5.5. Constraint-based
Constraint-based path computation is a basic function especially for
TE-LSP establishment. Available bandwidth, diversity, Shared Risk
Link Group (SRLG), optical impairments, wavelength continuity and
other constraints are likely to be considered. However, it is
difficult to compute an optimal path with these constraints under the
condition of the general GMPLS/ASON routing architecture. The
centralized operation manner makes PCE easy to fulfill constraint-
based path computation.
5.6. Service-oriented
PCEs can collaborate to finish constraint-based path computation
without sharing TE information with each other, which are
particularly useful when end-to-end constraints have to be taken into
account because of protection and path diversity. PCEs should play
an important role in service-oriented applications such as Layer 1
Virtual Private Network (L1 VPN), Bandwidth on Demand (BoD) and so
on. Based on GMPLS/ASON architecture, the advantages of PCE and
service plane can be combined to implement the framework of service-
oriented application.
5.7. Cooperation between network level and node level
In this application scenario, PCE maintains Traffic Engineering
Databases (TEDs) to keep network topology, and DRC maintains Resource
Information Databases (RIDs) to keep node internal topology and
resource status. Both of them maintain the status information within
the scope of their functions. Routing Engine Selector (RES) is
Zhao, et al. Expires April 23, 2012 [Page 11]
Internet-Draft Cooperation between PCE and DRC October 2011
responsible for managing the switchover process between PCE and DRC
and choosing the right one when a LSP setup request arrives.
The interconnection between different nodes is becoming the routing
problem generally, which can be solved by PCE framework effectively,
especially in multi-domain, multi-layer and multi-constraints
scenarios, while the interconnection within the node is the problem
of resource allocation and configuration, which refers to internal
resource allocation, ports interconnection, and switch fabric
configuration. Through the cooperation of PCE and DRC, we can make
resource configuration more effectively and improve the performance
of the entire optical networks.
6. PCEP Extension Requirements
As an extension of PCC, RES can not only complete the communication
between PCE and DRC, but also complete the cooperation between PCE
and DRC. There are some PCEP extension requirements for the
cooperative path computation architecture and the procedure.
6.1. PCEP extension requirement for the communication between RES and
PCE
PCEP is the communication protocol between RES and PCE. However,
there is some extension requirement for PCEP in the cooperative path
computation architecture.
Firstly, an identification which appoints different application
scenarios should be added to the path computation request messages
from RES to PCE, and the corresponding data structure should be
defined according to different identifications. For example, in the
policy-enabled scenario, a policy object is necessary to be defined
in the message sent from RES to PCE, and PCE should be able to parse
the different policies and conduct the corresponding operations
during the procedure of path computation.
Secondly, in the reply message from PCE to RES, some indication
information should be contained besides the routes information, such
as the inter-domain loose path or the intra-domain path, the complete
end-to-end path or section path, some failure information and path
computation engine switchover requests.
6.2. PCEP extension requirement for the communication between RES and
DRC
DRC can complete the path computation in local domain in the
distributed method, which is usually implemented in the OSPF-TE
Zhao, et al. Expires April 23, 2012 [Page 12]
Internet-Draft Cooperation between PCE and DRC October 2011
module of GMPLS-based control plane. After the path computation, DRC
returns the computation results to RES (CC) including the detailed
routes or some failure or indication information.
As another important application, DRC can complete the path
computation, resource management and configuration in the internal
node even the node structure is getting more and more complex. In
this application scenario, DRC has the function of routing and
resource allocation.
In all the application scenarios, DRC has all the analogous functions
with PCE and some different extension functions, such as the
functions above. So there is a requirement for application scenarios
identification in the communication message between RES and DRC. The
communication protocol between RES and DRC is necessary to be
standardized because of that the function of control node is getting
more and more complex. Because RES and DRC are implemented in the
same control node and DRC has similar functions with PCE, a
simplified PCEP can be used as the communication protocol between RES
and DRC, which can include the path computation request,
identification and reply messages only.
7. Other Protocol Extension Requirements
7.1. OSPF-TE extension requirement for the cooperative architecture
In the cooperative path computation architecture, the topology and TE
information should be kept and synchronized at each control node and
PCE in local domain, and should also be updated as soon as any change
occurs. Meanwhile, all the inter-domain links and TE information
should be kept and synchronized at each PCE. So there is an
extension requirement for OSPF-TE to guarantee the information at
each node synchronized in time.
Besides the normal topology and TE information, some other
constraints information may be necessary to be contained in the
OSPF-TE protocol flooding in the entire networks, such as the
physical impairment information. Then there is an extension
requirement for the OSPF-TE protocol to enable the synchronization of
all the constraint information at each node, which is of great value
for the path computation and resource allocation.
7.2. RSVP-TE extension requirement for the cooperative architecture
In different cooperation modes between PCE and DRC, an end-to-end
path may be computed by several PCE and DRC, and then be setup by
signaling from the source node to the destination node. However,
Zhao, et al. Expires April 23, 2012 [Page 13]
Internet-Draft Cooperation between PCE and DRC October 2011
sometimes an end-to-end path which crosses domains or layers may be
computed and setup section by section. Signaling should be triggered
when a section path is gained. The current RSVP-TE protocol is
necessary to be extended to support this application scenario.
Furthermore, as the scheme of path and resource allocation in the
internal node is gained, the resource reservation and action of
switches are need to be conducted by some protocol as the control
node is getting more and more complex. RSVP-TE is the optimal option
for this need, and to be extended.
8. Discussions
According to the development of GMPLS networks, the cooperative
architecture can be introduced in two steps. First, PCE and DRC can
cooperate with each other to complete the path computation of the
entire networks at network level. Second, PCE and DRC can cooperate
with each other to complete the path computation at network level and
resource computation and allocation at node level with the network
size increasing and node structure getting complex.
9. Security Considerations
The cooperation between PCE and DRC can enhance the security of
networks because they can backup each other. However, because the
information is kept at both PCE and DRC, especially in the condition
of the exchanging of information across domain boundaries is
necessary in the multi-domain operations, there are some security and
confidentiality risks, which can be minimized through the inheritance
of the security requirement defined [RFC5440] and [RFC5376].
10. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
Zhao, et al. Expires April 23, 2012 [Page 14]
Internet-Draft Cooperation between PCE and DRC October 2011
11.2. Informative References
[1] Nishioka, Itaru., "End-to-End path routing with PCEs in
multi-domain GMPLS networks", July 2008.
[2] Jabbari, Bijan., "On Constraints for Path Computation in
Multi-Layer Switched Networks", August 2007.
[3] Giorgetti, A. and F. Paolucci, "Routing and Wavelength
Assignment in PCE-based Wavelength Switched Optical
Networks", September 2008.
[4] Hayashi, Michiaki., "Advance Reservation-Based Network
Resource Manger for Optical Networks", February 2008.
Authors' Addresses
Yongli Zhao
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811761857
Email: yonglizhao@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Jie Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613911060930
Email: lgr24@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Zhao, et al. Expires April 23, 2012 [Page 15]
Internet-Draft Cooperation between PCE and DRC October 2011
Ruiquan Jing
China Telecom Beijing Research Institute
118 Xizhimenwai Avenue
Beijing 100035
P.R.China
Phone: +86-10-58552000
Email: jingrq@ctbri.com.cn
URI: http://www.ctbri.com.cn/
Dajiang Wang
ZTE Corporation
No.16,Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +8613811795408
Email: wang.dajiang@zte.com.cn
URI: http://www.zte.com.cn/
Xihua Fu
ZTE Corporation
West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
Xi'an 710065
P.R.China
Phone: +8613798412242
Email: fu.xihua@zte.com.cn
URI: http://www.zte.com.cn/
Zhao, et al. Expires April 23, 2012 [Page 16]