idnits 2.17.00 (12 Aug 2021) /tmp/idnits28172/draft-wang-ccamp-latency-te-metric-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 18, 2010) is 4233 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'G.8021' is mentioned on line 288, but not defined == Outdated reference: draft-ietf-rtgwg-cl-requirement has been published as RFC 7226 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wang 3 Internet-Draft X. Fu 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 21, 2011 Oct 18, 2010 7 GMPLS extensions to communicate latency as a TE performance metric 8 draft-wang-ccamp-latency-te-metric-00 10 Abstract 12 Latency is such requirement that must be achieved according to the 13 SLA signed between customers and service providers, so mechanism is 14 needed to collect, compute and identify the latency by signaling and 15 routing protocol. 17 This document describes the requirement and method to compute and 18 identify the latency by control plane in today's network which is 19 consisted of packet transport network and optical transport network 20 in order to meet the latency SLA of the customer. This document also 21 describes RSVP-TE signaling and OSPF routing extensions needed to 22 support the computation and identification of latency. These 23 extensions are intended to advertise and convey the information of 24 node latency and link latency as TE performance metric. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 21, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. List of Acronyms . . . . . . . . . . . . . . . . . . . . . 5 64 3. Analysis of the Latency Measurement Mechanism . . . . . . . . 5 65 3.1. Support of SLA . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Latency Value . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Latency of Server Layer Network . . . . . . . . . . . . . 7 68 3.4. Role of the Control Plane . . . . . . . . . . . . . . . . 7 69 4. A New Latency Measurement Mechanism . . . . . . . . . . . . . 8 70 4.1. Advertisement of the Latency Value . . . . . . . . . . . . 8 71 4.2. Latency Collection and Verification . . . . . . . . . . . 8 72 5. Signaling and Routing Extensions to Support Latency 73 Measurement . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Routing Extensions to Support the Advertisement of 75 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Signaling Extensions to Support the Latency Measurement . 10 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 In a network, latency, a synonym for delay, is an expression of how 87 much time it takes for a packet of data to get from one designated 88 point to another. In some usages, latency is measured by sending a 89 packet that is returned to the sender and the round-trip time is 90 considered the latency. In this document, we refer to the former 91 expression. 93 In many cases, latency is a sensitive topic. For example, two stock 94 exchanges, one in Beijing, which is a city of north China and another 95 in Shenzhen, which is a city of south China. Both of them need to 96 synchronize with each other. A little change may result in large 97 loss. So something SHOULD be assured that the network path latency 98 MUST be limited to a value lower than the upper limit. SLA contract 99 which includes the requirement of latency is signed between service 100 providers and customers. In the future, latency demand will be 101 needed by more and more customers. 103 Measurement mechanism of link latency has been defined in many 104 technologies. For example, the measurement mechanism of link latency 105 has been provided in ITU-T [G.8021] and [Y.1731] for Ethernet. The 106 link transit latency between two Ethernet equipments can be measured 107 by using this mechanism. Similarly, overhead byte and measurement 108 mechanism of latency has been provided in OTN (i.e., ITU-T [G.709]). 109 In order to measure the link latency between two OTN nodes, PM&TCM 110 which include Path Latency Measurement field and flag used to 111 indicate the beginning of measurement of latency is added to the 112 overhead of ODUk. The detailed measurement mechanism of link latency 113 is out of scope of this document. You can refer to ITU-T G.709 for 114 more messages. Technologies that do not support the measurement of 115 latency SHOULD be developed to allow the measurement of link latency 116 in scenario similar to the above. This is out of scope of this 117 document. Node latency can also be recorded at each node by 118 recording the process time at the beginning and at the end. More 119 detail of the node latency is described in section 3.2. 121 Current operation and maintenance mode of latency measurement is high 122 in cost and low in efficiency. Only after the path needed by the 123 customers' business is determined, signal can be sent to detect 124 whether the latency of the path fit the requirement of the customers. 125 If not, another path SHOULD be determined by the ingress node until 126 one can. So a low cost and high efficiency latency measurement 127 method SHOULD be provided in order to support the SLA. However, the 128 control plane does not provide latency measure mechanism. A new 129 method is provided that the node latency, link latency and latency 130 variation can be collected by control plane from the transport plane. 131 Then node latency, link latency values and latency variation can be 132 used by service provider through control plane to provide a path 133 correspond with the customers' requirement. As there is demand from 134 the customer, this method can be used to select a path correspond 135 with customers' latency demand. In this document, link latency 136 refers to the latency of the link between two neighbor nodes or a FA- 137 LSP. 139 This document describes the requirement and method to compute and 140 identify the latency by control plane in today's network which is 141 consisted of packet transport network and optical transport network 142 in order to meet the latency SLA of the customer. This document also 143 describes RSVP-TE signaling and OSPF routing extensions needed to 144 support the computation and identification of latency. Latency can 145 be divided into two types as described above: node latency which is 146 provided by the node as a result of process time at each node and 147 link latency as a result of packet traverse between two neighbor 148 nodes or a FA-LSP. Latency variation is also a parameter that is 149 used to indicate the variation range of the latency value. 150 Extensions are also intended to advertise and convey the information 151 of node latency, link latency and latency variation as TE performance 152 metric. 154 [RFC4203] details the OSPF extensions in support of Generalized 155 Multi-Protocol Label Switching (GMPLS). In order to support the 156 advertisement of the attributes of the node latency, link latency and 157 latency variation by routing, extensions SHOULD be made to [RFC4203] 158 in this document. Thus ingress node that is responsible for the 159 creation of the path will have a good knowledge of the latency of the 160 path. 162 [RFC3473] details the Generalized Multi-Protocol Label Switching 163 (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering 164 (RSVP-TE) Extensions. Extensions SHOULD be made to [RFC3473] to 165 collect the node, link latency and latency variation along the path, 166 so egress node can determine whether such a path is adaptive. This 167 extensions is not necessary unless there is a need. 169 1.1. Conventions Used in This Document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 2. Terminology 177 The reader is assumed to be familiar with the terminology in 178 [RFC3473] and [RFC4203]. 180 Frame Delay: 181 The definition of Frame Delay in ITU-T Y.1731 can be seen below. 182 Frame Delay can be specified as round-trip delay for a frame, where 183 Frame Delay is defined as the time elapsed since the start of 184 transmission of the first bit of the frame by a source node until the 185 reception of the last bit of the loop backed frame by the same source 186 node, when the loop back is performed at the frame's destination 187 node. 189 Frame Delay Variation: 190 The definition of Frame Delay in ITU-T [Y.1731] can be seen below. 191 Frame Delay Variation is a measure of the variations in the Frame 192 Delay between a pair of service frames. 194 Path Monitoring & Tandem Connection Monitoring: 195 Path Monitoring & Tandem Connection Monitoring is a field contained 196 in [G.709] OTN ODUk overhead, which can be used to support the 197 measurement of latency between two OTN nodes. 199 Service Level Agreement: 200 A service level agreement is a part of a service contract where the 201 level of service is formally defined between service providers and 202 customers. 204 2.1. List of Acronyms 206 FD: Frame Delay 207 FDV: Frame Delay Variation 208 PM&TCM: Path Monitoring & Tandem Connection Monitoring 209 SLA: Service Level Agreement 211 3. Analysis of the Latency Measurement Mechanism 213 As described in the Introduction section, latency is sensitive in 214 many cases like finance, storage. A little frame delay may result in 215 large loss. So network latency values MUST be strictly limited to a 216 value lower than the upper limit described in the SLA. Latency 217 measurement mechanism is important to certain customers. However, 218 the control plane does not provide latency measure mechanism. A 219 method is provided that the node latency, link latency and latency 220 variation can be collected by control plane from the latency 221 measurement of the transport plane. Then node latency, link latency 222 values and latency variation can be used by service provider through 223 control plane to provide a path correspond with the customers' 224 demand. In this document, link latency refers to the latency of the 225 link between two neighbor nodes or a FA-LSP. This section analyzes 226 latency support for SLA contract signed between customers and 227 providers, analysis of the mechanism of latency measurement, latency 228 of the server layer network and role of the control plane in this new 229 latency measurement mechanism. 231 3.1. Support of SLA 233 In today's network (e.g., DWDM), latency measurement is required by 234 many service providers because of the demand from the customers. 235 Latency is especially important for the customers who provide service 236 like finance, storage. As a result of the demand, SLA contract which 237 includes the demand of latency is signed between service providers 238 and customers. According to the definition in section 2, SLA (i.e., 239 Service Level Agreement) is a part of a service contract where the 240 level of service is formally defined between service providers and 241 customers. Service providers MUST provide accurate latency 242 measurement result to the customers per SLA levels. Latency to 243 different customers can be different per SLA levels. 245 However, current operation and maintenance mode of latency 246 measurement through transport plane is high in cost and low in 247 efficiency. Only after the path needed by the customers' business is 248 determined, signal can be sent to detect whether the latency of the 249 path fit the requirement of the customers. A new method described in 250 this document is provided to support a low cost and high efficiency 251 latency measurement mechanism in order to support the SLA. This can 252 be seen in the 4th section and 5th section. 254 3.2. Latency Value 256 The mechanism of latency measurement can be sorted into two types. 257 In order to monitor the performance, pro-active latency measurement 258 is required. Generally, every 15 minutes or 24 hours, the value of 259 FD and FDV SHOULD be collected. Similarly, on demand latency 260 measurement is required due to the goal of maintenance. This can be 261 done every fixed time interval (e.g., 5 minutes or 1 hour). 263 As described in [CL-REQ], when a traffic flow moves from one 264 component link to another in the same composite link between a set of 265 nodes (or sites), it MUST be processed in a minimally disruptive 266 manner. When a traffic flow moves from a current link to a target 267 link with different latency, reordering can occur if the target link 268 latency is less than that of the current and clumping can occur if 269 target link latency is more than that of the current. Therefore, the 270 solution SHALL provide a means to indicate that a traffic flow shall 271 select a component link with the minimum latency value and a maximum 272 acceptable latency value. 274 Similarly, the value of latency is not fixed because of different 275 signal process technology (The packet transport network use 276 statistical multiplexing and the optical transport network use time 277 division multiplex). For example, in statistical multiplexing 278 business, latency for every business may be different because of the 279 existence of buffering and priority. At this time, average latency 280 value is needed when refer to node latency. Average latency value of 281 node can be derived through the computation of the node or management 282 plane configuration. 284 latency varation is also needed in the case the latency value of, for 285 example, average latency value's variation range. 287 Measurement mechanism of link latency has been defined in many 288 technologies like Ethernet, OTN. You can refer to ITU-T [G.8021], 289 [Y.1731] and [G.709] for more information. 291 3.3. Latency of Server Layer Network 293 When a LSP traverses a server layer FA-LSP, the latency information 294 of the FA-LSP SHOULD be provided by signaling protocol message if 295 needed. Extension to the current signaling protocol is done to carry 296 the latency information of the server layer FA-LSP. This is 297 described in section 4 and section 5. 299 The boundary nodes of the FA-LSP SHOULD be aware of the latency 300 information of this FA-LSP (i.e., minimum latency, maximum latency, 301 average latency). If the latency information of the FA-LSP changes, 302 the ingress node of the FA-LSP will receive the TE link information 303 advertisement including the latency value which is already changed, 304 then it will compute the total latency value of the FA-LSP again. If 305 this value changes, the client layer of the FA-LSP MUST also be 306 notified about the total value of the latency. 308 The ingress node or egress node of the FA-LSP can advertise the total 309 value of the latency to the client layer nodes connecting to the 310 ingress node or egress node through signaling protocol message (e.g., 311 notify message or refresh message). If the FA-LSP is able to form a 312 routing adjacency and/or as a TE link in the client network, the 313 value of the FA-LSP can be used as TE link metric and advertised into 314 the client layer routing instances or PCE. 316 3.4. Role of the Control Plane 318 Current mechanism of latency measurement is provided by transport 319 plane instead of control plane. The latency information between two 320 specified nodes will be detected if there is latency demand of the 321 path between the two nodes. This is low in efficiency and high in 322 cost if the latency information does not correspond with the 323 customers' demand. 325 A new method of latency measurement mechanism is provided by 326 collecting the node latency value, link latency value between two 327 neighbor nodes or a FA-LSP and latency variation, then these values 328 is provided to the control plane. Control plane can compute a path 329 correspond with customers' demand with these latency values. 331 4. A New Latency Measurement Mechanism 333 This new latency measurement can be divided into two phases. The 334 first phase is the advertisement of the latency information by 335 routing protocol, including node latency, link latency between two 336 neighbor nodes or a FA-LSP and latency variation, so every node in 337 the network can be aware of the latency of every node and link. The 338 second phase is the latency collection and verification along the 339 path from the ingress node to the egress node by signaling protocol, 340 so an adaptive LSP can be found out and verified. 342 4.1. Advertisement of the Latency Value 344 As described in the introduction section, a node in the packet 345 transport network or optical transport network can detect link 346 latency value which has connection with it. Also the node latency 347 can be recorded at every node. Then these link latency values of the 348 neighbor nodes, node latency and latency variation is notified to the 349 control plane. The control plane instances then advertise these link 350 latency values, node latency values and latency variation as 351 attributes of the TE link to the other nodes in the routing domain or 352 PCE by routing protocol. If any latency values change, then the 353 change MUST be notified to the control plane instances, then 354 advertise by routing protocol in the routing domain or to the PCE. 355 As a result, control plane instances and PCE can have every node 356 latency values, link latency values and latency variation in the 357 network. 359 4.2. Latency Collection and Verification 361 When the PCE receives the request which indicates the demand of 362 latency, PCE can compute a path which satisfies customers' latency 363 demand with the node latency values, link latency values and latency 364 variation in the network. The ingress node initializes the creation 365 of the LSP with path signaling message which includes the latency 366 demand parameter. The path signaling message collects the node 367 latency value, link latency value and latency variation along the 368 path. When the path signaling message reaches the egress node, the 369 egress node can verify whether the value of the latency is applicable 370 by comparing the LSP latency with the latency demand parameter 371 carried in the path message. Similarly, when egress node returns 372 recv signaling message to ingress node, node latency values, link 373 latency values and latency variation will also be gathered in the 374 reverse direction. The ingress node verifies whether the latency 375 values from the egress node to the ingress node is applicable.This 376 extensions is not necessary unless there is a need. 378 When a LSP traverses a server layer FA-LSP, the latency information 379 of the FA-LSP is advertised by routing protocol and carried in the 380 signaling message. The latency information of the server layer FA- 381 LSP can be carried in the ERBO object which is defined in 382 [draft-fuxh-ccamp-boundary-explicit-control-ext]. Region boundaries 383 carried in ERBO contain one pair or multiple pair of nodes. One pair 384 of boundary nodes indicates the head node and the end node of the FA- 385 LSP (i.e., the region boundary). The latency values information of 386 the FA-LSP between two boundary nodes is carried in the signaling 387 message directly behind a pair of boundary nodes in the ERBO. 388 Ingress node will re-compute the total latency value of the FA-LSP if 389 the total latency value of the FA-LSP changes. The latency value of 390 the FA-LSP SHOULD be announced to the client layer of the FA-LSP, 391 also advertised in the routing domain. 393 5. Signaling and Routing Extensions to Support Latency Measurement 395 Extensions SHOULD be done to existing OSPF-TE routing protocol and 396 RSVP-TE routing protocol, in order to support the advertisement, the 397 collection and the verification of the latency values. In this 398 section, routing extensions and signaling extensions will be 399 described. 401 5.1. Routing Extensions to Support the Advertisement of Latency 403 Some extensions to the existing OSPF-TE routing protocol to support 404 the advertisement of the node latency value, link latency and latency 405 variation value in the routing domain or to the PCE as TE metric. 406 OSPF-TE routing protocol can be used to carry latency information by 407 adding a sub-TLV to the TE link which is defined in [RFC4203]. The 408 latency value can be used as constraint for routing computation and 409 as a factor impacting the node and link performance. 411 As defined in [RFC3630] and [RFC4203], the top-level TLV can take one 412 of two values (1) Router address or (2) Link. Node latency sub-TLV 413 and link latency sub-TLV can be added behind the top-level TLV. The 414 link latency sub-TLV has the same format as node latency TLV. They 415 both include these parameters like minimum latency value, minimum 416 latency variation value, maximum latency value, maximum latency 417 variation value, average latency value, average latency variation 418 value. The format of the sub-TLV can be seen below. 420 0 1 2 3 421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type | Length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Minimum Latency Value | Latency Variation Value | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Maximum Latency Value | Latency Variation Value | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Average Latency Value | Latency Variation Value | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 1: Format of the sub-TLV 434 - Minimum Latency Value: a value indicates the boundary of the node 435 latency or link latency along with maximum latency value. 437 - Maximum Latency Value: a value indicates the boundary of the node 438 latency or link latency along with maximum latency value. 440 - Average Latency Value: a value indicates the average of the node 441 latency or link latency. 443 - Latency Variation Value: a value indicates the variation range of 444 the minimum latency value, maximum latency value or average 445 latency value. 447 5.2. Signaling Extensions to Support the Latency Measurement 449 Extensions SHOULD also be done to the RSVP-TE signaling protocol to 450 support the collection and verification of the latency measurement. 451 This can be achieved base on the extension to the RRO which is 452 defined in [RFC3209] by adding an interface ID (i.e., IP Address) or 453 interface identifier defined in [RFC3477], then adding the sub-TLV 454 which has the same format with that described above. When a node 455 receives the path message, node latency value, link latency value and 456 latency variation along the path which has correlation to the node 457 will be added behind the interface identifier and node ID sub-object. 458 At the same time, the latency values requirement from the ingress 459 node to the egress node have been added into the TE metric TLV. When 460 the egress node receives the path message, the latency value of the 461 LSP can be compute by the node latency value, link latency value and 462 latency variation carried behind RRO. If the total latency value 463 does not meet the requirement of the customer, patherr message SHOULD 464 be created and return to the ingress node. Recv message can be used 465 to collect and verify the latency information in the reverse 466 direction in the same way. 468 The signaling format of the sub-TLV has the same format as that 469 described in the section 5.1. This format can also been used behind 470 a pair of boundary nodes which are carried in ERBO to indicate the 471 latency information of the FA-LSP if there are requirement of the 472 server layer. 474 6. Security Considerations 476 TBD 478 7. IANA Considerations 480 TBD 482 8. References 484 8.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 490 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 491 Tunnels", RFC 3209, December 2001. 493 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 494 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 495 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 497 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 498 in Resource ReSerVation Protocol - Traffic Engineering 499 (RSVP-TE)", RFC 3477, January 2003. 501 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 502 (TE) Extensions to OSPF Version 2", RFC 3630, 503 September 2003. 505 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 506 of Generalized Multi-Protocol Label Switching (GMPLS)", 507 RFC 4203, October 2005. 509 8.2. Informative References 511 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 512 Link", draft-ietf-rtgwg-cl-requirement-02 . 514 [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical 515 Transport Network (OTN)", December 2009. 517 Authors' Addresses 519 Qilei Wang 520 ZTE Corporation 521 No.68 ZiJingHua Road,Yuhuatai District 522 Nanjing 210012 523 P.R.China 525 Email: wang.qilei@zte.com.cn 526 URI: http://wwwen.zte.com.cn/ 528 Xihua Fu 529 ZTE Corporation 530 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 531 Xi An 710065 532 P.R.China 534 Phone: +8613798412242 535 Email: fu.xihua@zte.com.cn 536 URI: http://wwwen.zte.com.cn/