idnits 2.17.00 (12 Aug 2021) /tmp/idnits6097/draft-mirsky-ippm-hybrid-two-step-06.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 (October 26, 2020) is 572 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-direct-export-01 == Outdated reference: A later version (-12) exists of draft-song-ippm-postcard-based-telemetry-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track W. Lingqiang 5 Expires: April 29, 2021 G. Zhui 6 ZTE Corporation 7 H. Song 8 Futurewei Technologies 9 October 26, 2020 11 Hybrid Two-Step Performance Measurement Method 12 draft-mirsky-ippm-hybrid-two-step-06 14 Abstract 16 Development of, and advancements in, automation of network operations 17 brought new requirements for measurement methodology. Among them is 18 the ability to collect instant network state as the packet being 19 processed by the networking elements along its path through the 20 domain. This document introduces a new hybrid measurement method, 21 referred to as hybrid two-step, as it separates the act of measuring 22 and/or calculating the performance metric from the act of collecting 23 and transporting network state. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 29, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6 66 4.2. Operation of the HTS Intermediate Node . . . . . . . . . 8 67 4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 9 68 4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 9 69 4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 8.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 Successful resolution of challenges of automated network operation, 81 as part of, for example, overall service orchestration or data center 82 operation, relies on a timely collection of accurate information that 83 reflects the state of network elements on an unprecedented scale. 84 Because performing the analysis and act upon the collected 85 information requires considerable computing and storage resources, 86 the network state information is unlikely to be processed by the 87 network elements themselves but will be relayed into the data storage 88 facilities, e.g., data lakes. The process of producing, collecting 89 network state information also referred to in this document as 90 network telemetry, and transporting it for post-processing should 91 work equally well with data flows or injected in the network test 92 packets. RFC 7799 [RFC7799] describes a combination of elements of 93 passive and active measurement as a hybrid measurement. 95 Several technical methods have been proposed to enable the collection 96 of network state information instantaneous to the packet processing, 97 among them [P4.INT] and [I-D.ietf-ippm-ioam-data]. The 98 instantaneous, i.e., in the data packet itself, collection of 99 telemetry information simplifies the process of attribution of 100 telemetry information to the particular monitored flow. On the other 101 hand, this collection method impacts the data packets, potentially 102 changing their treatment by the networking nodes. Also, the amount 103 of information the instantaneous method collects might be incomplete 104 because of the limited space it can be allotted. Other proposals 105 defined methods to collect telemetry information in a separate packet 106 from each node traversed by the monitored data flow. Examples of 107 this approach to collecting telemetry information are 108 [I-D.ietf-ippm-ioam-direct-export] and 109 [I-D.song-ippm-postcard-based-telemetry]. These methods allow data 110 collection from any arbitrary path and avoid directly impacting data 111 packets. On the other hand, the correlation of data and the 112 monitored flow requires that each packet with telemetry information 113 also includes characteristic information about the monitored flow. 115 This document introduces Hybrid Two-Step (HTS) as a new method of 116 telemetry collection that improvers accuracy of a measurement by 117 separating the act of measuring or calculating the performance metric 118 from the collecting and transporting this information while 119 minimizing the overhead of the generated load in a network. HTS 120 method extends the two-step mode of Residence Time Measurement (RTM) 121 defined in [RFC8169] to on-path network state collection and 122 transport. HTS allows the collection of telemetry information from 123 any arbitrary path, does not change data packets of the monitored 124 flow and makes the process of attribution of telemetry to the data 125 flow simple. 127 2. Conventions used in this document 129 2.1. Terminology 131 RTM Residence Time Measurement 133 ECMP Equal Cost Multipath 135 MTU Maximum Transmission Unit 137 HTS Hybrid Two-Step 139 Network telemetry - the process of collecting and reporting of 140 network state 142 2.2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 3. Problem Overview 152 Performance measurements are meant to provide data that characterize 153 conditions experienced by traffic flows in the network and possibly 154 trigger operational changes (e.g., re-route of flows, or changes in 155 resource allocations). Modifications to a network are determined 156 based on the performance metric information available at the time 157 that a change is to be made. The correctness of this determination 158 is based on the quality of the collected metrics data. The quality 159 of collected measurement data is defined by: 161 o the resolution and accuracy of each measurement; 163 o predictability of both the time at which each measurement is made 164 and the timeliness of measurement collection data delivery for 165 use. 167 Consider the case of delay measurement that relies on collecting time 168 of packet arrival at the ingress interface and time of the packet 169 transmission at the egress interface. The method includes recording 170 a local clock value on receiving the first octet of an affected 171 message at the device ingress, and again recording the clock value on 172 transmitting the first byte of the same message at the device egress. 173 In this ideal case, the difference between the two recorded clock 174 times corresponds to the time that the message spent in traversing 175 the device. In practice, the time that has been recorded can differ 176 from the ideal case by any fixed amount and a correction can be 177 applied to compute the same time difference taking into account the 178 known fixed time associated with the actual measurement. In this 179 way, the resulting time difference reflects any variable delay 180 associated with queuing. 182 Depending on the implementation, it may be a challenge to compute the 183 difference between message arrival and departure times and - on the 184 fly - add the necessary residence time information to the same 185 message. And that task may become even more challenging if the 186 packet is encrypted. Recording the departure of a packet time in the 187 same packet may be decremental to the accuracy of the measurement, 188 because the departure time includes the variable time component (such 189 as that associated with buffering and queuing of the packet). A 190 similar problem may lower the quality of, for example, information 191 that characterizes utilization of the egress interface. If unable to 192 obtain the data consistently, without variable delays for additional 193 processing, information may not accurately reflect the egress 194 interface state. To mitigate this problem [RFC8169] defined an RTM 195 two-step mode. 197 Another challenge associated with methods that collect network state 198 information into the actual data packet is the risk to exceed the 199 Maximum Transmission Unit (MTU) size, especially if the packet 200 traverses overlay domains or VPNs. Since the fragmentation is not 201 available at the transport network, operators may have to reduce MTU 202 size advertised to client layer or risk missing network state data 203 for the part, most probably the latter part, of the path. 205 4. Theory of Operation 207 The HTS method consists of the two phases: 209 o performing a measurement or obtaining network state information, 210 one or more than one type, on a node; 212 o collecting and transporting the measurement. 214 HTS uses HTS Trigger carried in a data packet or a specially 215 constructed test packet. For example, an HTS Trigger could be a 216 packet that includes iOAM Namespace-ID and IOAM-Trace-Type 217 information [I-D.ietf-ippm-ioam-data] or a packet in the flow to 218 which the Alternate-Marking method [RFC8321] is applied. Nature of 219 the HTS Trigger is a transport network layer-specific, and its 220 description is outside the scope of this document. The packet that 221 includes the HTS Trigger in this document is also referred to as the 222 trigger packet. 224 The HTS method uses the HTS Follow-up packet, in this document also 225 referred to as the follow-up packet, to collect measurement and 226 network state data from the nodes. The node that creates the HTS 227 Trigger also generates the HTS Follow-up packet. The follow-up 228 packet contains characteristic information, copied from the trigger 229 packet, sufficient for participating HTS nodes to associate it with 230 the original packet. The exact composition of the characteristic 231 information is specific for each transport network, and its 232 definition is outside the scope of this document. The follow-up 233 packet also uses the same encapsulation as the data packet. If not 234 payload but only network information used to load-balance flows in 235 equal cost multipath (ECMP), use of the network encapsulation 236 identical to the trigger packet should guarantee that the follow-up 237 packet remains in-band, i.e., traverses the same set of network 238 elements, with the original data packet with the HTS Trigger. Only 239 one outstanding follow-up packet MUST be on the node for the given 240 path. That means that if the node receives an HTS Trigger for the 241 flow on which it still waits for the follow-up packet to the previous 242 HTS Trigger, the node will originate the follow-up packet to 243 transport the former set of the network state data and transmit it 244 before it sends the follow-up packet with the latest collection of 245 network state information. 247 4.1. Operation of the HTS Ingress Node 249 A node that originates the HTS Trigger is referred to as HTS ingress 250 node. As stated, the ingress node originates the follow-up packet. 251 The follow-up packet has the transport network encapsulation 252 identical with the trigger packet followed by the HTS shim and one or 253 more telemetry information elements encoded as Type-Length-Value 254 {TLV}. Figure 1 displays the example of the follow-up packet format. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 ~ Transport Network ~ 261 | Encapsulation | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |Ver|HTS Shim Len| Flags | Sequence Number | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Telemetry Data Profile | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 ~ Telemetry Data TLVs ~ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 1: Follow-up Packet Format 274 Fields of the HTS shim are as follows: 276 Version (Ver) is the two-bits long field. It specifies the 277 version of the HTS shim format. This document defines the format 278 for the 0b00 value of the field. 280 HTS Shim Length is the six bits-long field. It defines the length 281 of the HTS shim in bytes. The minimal value of the field is four 282 bytes. 284 0 285 0 1 2 3 4 5 6 7 286 +-+-+-+-+-+-+-+-+ 287 |F| Reserved | 288 +-+-+-+-+-+-+-+-+ 290 Figure 2: Flags Field Format 292 Flags is eight-bits long field. The format of the Flags field 293 displayed in Figure 2. 295 Full (F) flag MUST be set to zero by the node originating the 296 HTS follow-up packet and MUST be set to one by the node that 297 does not add its telemetry data to avoid exceeding MTU size. 299 The node originating the follow-up packet MUST zero the 300 Reserved field and ignore it on the receipt. 302 Sequence Number is 16 bits-long field. The zero-based value of 303 the field reflects the place of the HTS follow-up packet in the 304 sequence of the HTS follow-up packets originated in response to 305 the same HTS trigger. The ingress node MUST set the value of the 306 field to zero. 308 Telemetry Data Profile is the optional variable length field of 309 bit-size flags. Each flag indicates requested type of telemetry 310 data to be collected at the each HTS node. The increment of the 311 field is four bytes with a minimum length of zero. For example, 312 IOAM-Trace-Type information defined in [I-D.ietf-ippm-ioam-data] 313 can be used in the Telemetry Data Profile field. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 ~ Value ~ 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 3: Telemetry Data TLV Format 325 Telemetry Data TLV is a variable-length field. Multiple TLVs MAY 326 be placed in an HTS packet. Additional TLVs may be enclosed 327 within a given TLV, subject to the semantics of the (outer) TLV in 328 question. Figure 3 presentes the format of a Telementry Data TLV, 329 where fields are defined as the following: 331 Type - two-octet-long field that characterizes the 332 interpretation of the Value field. 334 Length - two-octet-long field equal to the length of the Value 335 field in octets. 337 Value - a variable-length field. Its interpretation and 338 encoding is determined by the value of the Type field. IOAM 339 data fields, defined in [I-D.ietf-ippm-ioam-data], MAY be 340 carried in the Value field. 342 All multibyte fields defined in this specification are in network 343 byte order. 345 4.2. Operation of the HTS Intermediate Node 347 Upon receiving the trigger packet the HTS intermediate node MUST: 349 o copy the transport information; 351 o start the HTS Follow-up Timer for the obtained flow. 353 Upon receiving the follow-up packet the HTS intermediate node MUST: 355 o verify that the matching transport information exists and the Full 356 flag is cleared, then stop the associated HTS Follow-up timer; 358 o collect telemetry data requested in the Telemetry Data Profile 359 field or defined by the local HTS policy; 361 o if adding the collected telemetry would not exceed MTU, then 362 append data into Telemetry Data TLVs field and transmit the 363 follow-up packet; 365 o otherwise, set the value of the Full flag to one and transmit the 366 received a follow-up packet; 368 o originate the new follow-up packet using the same transport 369 information. The value of the Sequence Number field in the HTS 370 shim MUST be set to the value of the field in the received follow- 371 up packet incremented by one. Copy collected telemetry data and 372 transmit the packet. 374 If the HTS Follow-up Timer expires, the intermediate node MUST: 376 o originate the follow-up packet using transport information 377 associated with the expired timer; 379 o initialize the HTS shim by setting Version field to 0b00 and 380 Sequence Number field to 0. Values of HTS Shim Length and 381 Telemetry Data Profile fields MAY be set according to the local 382 policy. 384 o copy telemetry information into Telemetry Data TLVs field and 385 transmit the packet. 387 If the intermediate node receives a "late" follow-up packet, i.e., a 388 packet to which the node has no associated HTS Follow-up timer, the 389 node MUST forward the "late" packet. 391 4.3. Operation of the HTS Egress Node 393 Upon receiving the trigger packet the HTS egress node MUST: 395 o copy the transport information; 397 o start the HTS Collection timer for the obtained flow. 399 When the egress node receives the follow-up packet for the known 400 flow, i.e., the flow to which the Collection timer is running, the 401 node MUST: 403 o copy telemetry information; 405 o restart the corresponding Collection timer. 407 When the Collection timer expires the egress relays the collected 408 telemetry information for processing and analysis to a local or 409 remote agent. 411 4.4. Considerations for HTS Timers 413 This specification defines two timers - HTS Follow-up and HTS 414 Collection. Because for the particular flow there MUST be not more 415 than one HTS Trigger, values of HTS timers bounded by the rate of the 416 trigger generation for that flow. 418 4.5. Deploying HTS in a Multicast Network 420 Previous sections discussed the operation of HTS in a unicast 421 network. Multicast services are important, and the ability to 422 collect telemetry information is an invaluable component in 423 delivering a high quality of experience. While the replication of 424 data packets is necessary, replication of HTS follow-up packets is 425 not. Replication of multicast data packets down a multicast tree may 426 be set based on multicast routing information or explicit information 427 included in the special header, as, for example, in Bit-Indexed 428 Explicit Replication [RFC8296]. A replicating node processes HTS 429 packet as defined below: 431 o the first transmitted multicast packet MUST be followed by the 432 received corresponding HTS packet as described in Section 4.2; 434 o each consecutively transmitted copy of the original multicast 435 packet MUST be followed by the new HTS packet originated by the 436 replicating node that acts as a intermediate HTS node when the HTS 437 Follow-up timer expired. 439 As a result, there are no duplicate copies of Telemetry Data TLV for 440 the same pair of ingress and egress interfaces. At the same time, 441 all ingress/egress pairs traversed by the given multicast packet 442 reflected in their respective Telemetry Data TLV. Consequently, a 443 centralized controller would be able to reconstruct and analyze the 444 state of the particular multicast distribution tree based on HTS 445 packets collected from egress nodes. 447 5. IANA Considerations 449 TBD 451 6. Security Considerations 453 Nodes that practice HTS method are presumed to share a trust model 454 that depends on the existence of a trusted relationship among nodes. 455 This is necessary as these nodes are expected to correctly modify the 456 specific content of the data in the follow-up packet, and the degree 457 to which HTS measurement is useful for network operation depends on 458 this ability. In practice, this means either confidentiality or 459 integrity protection cannot cover those portions of messages that 460 contain the network state data. Though there are methods that make 461 it possible in theory to provide either or both such protections and 462 still allow for intermediate nodes to make detectable yet 463 authenticated modifications, such methods do not seem practical at 464 present, particularly for protocols that used to measure latency and/ 465 or jitter. 467 The ability to potentially authenticate and/or encrypt the network 468 state data for scenarios both with and without the participation of 469 intermediate nodes that participate in HTS measurement is left for 470 further study. 472 While it is possible for a supposed compromised node to intercept and 473 modify the network state information in the follow-up packet, this is 474 an issue that exists for nodes in general - for all data that to be 475 carried over the particular networking technology - and is therefore 476 the basis for an additional presumed trust model associated with an 477 existing network. 479 7. Acknowledgments 481 Authors express their gratitude and appreciation to Joel Halpern for 482 the most helpful and insightful discussion on the applicability of 483 HTS in a Service Function Chaining domain. 485 8. References 487 8.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 8.2. Informative References 500 [I-D.ietf-ippm-ioam-data] 501 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 502 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 503 progress), July 2020. 505 [I-D.ietf-ippm-ioam-direct-export] 506 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 507 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 508 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 509 export-01 (work in progress), August 2020. 511 [I-D.song-ippm-postcard-based-telemetry] 512 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 513 "Postcard-based On-Path Flow Data Telemetry", draft-song- 514 ippm-postcard-based-telemetry-07 (work in progress), April 515 2020. 517 [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, 518 October 2017. 520 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 521 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 522 May 2016, . 524 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 525 and A. Vainshtein, "Residence Time Measurement in MPLS 526 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 527 . 529 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 530 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 531 for Bit Index Explicit Replication (BIER) in MPLS and Non- 532 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 533 2018, . 535 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 536 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 537 "Alternate-Marking Method for Passive and Hybrid 538 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 539 January 2018, . 541 Authors' Addresses 543 Greg Mirsky 544 ZTE Corp. 546 Email: gregimirsky@gmail.com 548 Wang Lingqiang 549 ZTE Corporation 550 No 19 ,East Huayuan Road 551 Beijing 100191 552 P.R.China 554 Phone: +86 10 82963945 555 Email: wang.lingqiang@zte.com.cn 557 Guo Zhui 558 ZTE Corporation 559 No 19 ,East Huayuan Road 560 Beijing 100191 561 P.R.China 563 Phone: +86 10 82963945 564 Email: guo.zhui@zte.com.cn 565 Haoyu Song 566 Futurewei Technologies 567 2330 Central Expressway 568 Santa Clara 569 USA 571 Email: hsong@futurewei.com