idnits 2.17.1 draft-song-ippm-postcard-based-telemetry-08.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([I-D.ietf-ippm-ioam-direct-export]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 210 has weird spacing: '...sr pkts gen p...' -- The document date (October 30, 2020) is 1274 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-07 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-00 == Outdated reference: A later version (-03) exists of draft-song-ippm-ioam-ipv6-support-00 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-01 -- Obsolete informational reference (is this intentional?): RFC 2925 (Obsoleted by RFC 4560) -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM H. Song 3 Internet-Draft Futurewei 4 Intended status: Informational T. Zhou 5 Expires: May 3, 2021 Z. Li 6 Huawei 7 G. Mirsky 8 ZTE Corp. 9 J. Shin 10 SK Telecom 11 K. Lee 12 LG U+ 13 October 30, 2020 15 Postcard-based On-Path Flow Data Telemetry using Packet Marking 16 draft-song-ippm-postcard-based-telemetry-08 18 Abstract 20 The document describes a packet-marking variation of the Postcard- 21 Based Telemetry (PBT), referred to as PBT-M. Unlike the instruction- 22 based PBT, as embodied in [I-D.ietf-ippm-ioam-direct-export], PBT-M 23 does not require the encapsulation of a telemetry instruction header, 24 so it avoids some of the implementation challenges of the 25 instruction-based PBT. However, PBT-M has unique issues that need to 26 be considered. This document serves as a scheme overview and 27 provides design guidelines applicable to implementations in different 28 network protocols. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 3, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. PBT-M: Marking-based PBT . . . . . . . . . . . . . . . . . . 4 66 3. New Challenges . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. PBT-M Design Considerations . . . . . . . . . . . . . . . . . 7 68 4.1. Packet Marking . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. Flow Path Discovery . . . . . . . . . . . . . . . . . . . 8 70 4.3. Packet Identity for Export Data Correlation . . . . . . . 8 71 4.4. Control the Load . . . . . . . . . . . . . . . . . . . . 9 72 5. Implementation Recommendation . . . . . . . . . . . . . . . . 9 73 5.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Postcard Format . . . . . . . . . . . . . . . . . . . . . 9 75 5.3. Data Correlation . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 80 10. Informative References . . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Motivation 85 To gain detailed data plane visibility to support effective network 86 OAM, it is essential to be able to examine the trace of user packets 87 along their forwarding paths. Such on-path flow data reflect the 88 state and status of each user packet's real-time experience and 89 provide valuable information for network monitoring, measurement, and 90 diagnosis. 92 The telemetry data include but not limited to the detailed forwarding 93 path, the timestamp/latency at each network node, and, in case of 94 packet drop, the drop location, and the reason. The emerging 95 programmable data plane devices allow user-defined data collection or 96 conditional data collection based on trigger events. Such on-path 97 flow data are from and about the live user traffic, which complements 98 the data acquired through other passive and active OAM mechanisms 99 such as IPFIX [RFC7011] and ICMP [RFC2925]. 101 On-path telemetry was developed to cater to the need of collecting 102 on-path flow data. There are two basic modes for on-path telemetry: 103 the passport mode and the postcard mode. In the passport mode, each 104 node on the path adds the telemetry data to the user packets (i.e., 105 stamp the passport). The accumulated data-trace carried by user 106 packets are exported at a configured end node. In the postcard mode, 107 each node directly exports the telemetry data using an independent 108 packet (i.e., send a postcard) to avoid the need for carrying the 109 data with user packets. 111 In-situ OAM trace option (IOAM) [I-D.ietf-ippm-ioam-data] is a 112 representative of the passport mode on-path telemetry. A prominent 113 advantage of the passport mode is that it naturally retains the 114 telemetry data correlation along the entire path. The passport mode 115 also reduces the number of data export packets. These help to 116 simplify the data collector and analyzer's work. On the other hand, 117 the passport mode faces the following challenges. 119 o Issue 1: Since the telemetry instruction header and data 120 processing must be done in the data-plane fast-path, it may 121 interfere with the normal traffic forwarding (e.g., leading to 122 forwarding performance degradation) and lead to inaccurate 123 measurements (e.g., resulting in longer latency measurements than 124 usual). This undesirable "observer effect" is problematic to 125 carrier networks where stringent SLA must be observed. 127 o Issue 2: The passport mode may significantly increase the user 128 packet's original size by adding data at each on-path node. The 129 size may exceed the path MTU, so either the technique cannot 130 apply, or the packet needs to be fragmented. That could be 131 challenging when other network service headers (e.g., segment 132 routing or service function chaining) are also present. Limiting 133 the data size or path length reduces the effectiveness of INT. 135 o Issue 3: The instruction header needs to be encapsulated into user 136 packets for transport. [I-D.brockners-inband-oam-transport] has 137 discussed several encapsulation approaches for different transport 138 protocols. So far, there is no feasible solution to encapsulate 139 the instruction header in MPLS and IPv4 networks, which are still 140 the most widely deployed. It is also challenging to encapsulate 141 the instruction header in IPv6 [I-D.song-ippm-ioam-ipv6-support]. 143 o Issue 4: The telemetry information is transported in plain text 144 along the network paths. The instruction header and data are 145 vulnerable to eavesdropping and tampering as well as DoS attack. 146 Extra protective measurement is difficult on the data-plane fast- 147 path. 149 o Issue 5: Since the passport mode only exports the telemetry data 150 at the designated end node, if the packet is dropped in the 151 network, the data will be lost as well. It cannot pinpoint the 152 packet drop location, which is desired by fault diagnosis. Even 153 worse, the end node may be unaware of the packet and data loss at 154 all. 156 The postcard mode provides a perfect complement to the passport mode. 157 In the variant of the postcard-based telemetry (PBT) which uses an 158 instruction header, the postcards that carry telemetry data can be 159 generated by a node's slow path and transported in-band or out-of- 160 band, independent of the original user packets. IOAM direct export 161 option (DEX) [I-D.ietf-ippm-ioam-direct-export] is a representative 162 of PBT. Since an instruction header is still needed while 163 successfully addressing issue 2 and 5 and partially addressing issue 164 1 and 4, this type of instruction-based PBT still cannot address 165 issue 3. 167 This document describes another variation of the postcard mode on- 168 path telemetry, the marking-based PBT (PBT-M). Unlike the 169 instruction-based PBT, PBT-M does not require the encapsulation of a 170 telemetry instruction header, so it avoids some of the implementation 171 challenges of the instruction-based PBT. However, PBT-M has unique 172 issues that need to be considered. This document discusses the 173 challenges and their solutions of the marking-based PBT. 175 2. PBT-M: Marking-based PBT 177 As the name suggests, PBT-M only needs a marking-bit in the existing 178 headers of user packets to trigger the telemetry data collection and 179 export. The sketch of PBT-M is as follows. If on-path data need to 180 be collected, the user packet is marked at the path head node. At 181 each PBT-aware node, if the mark is detected, a postcard (i.e., the 182 dedicated OAM packet triggered by a marked user packet) is generated 183 and sent to a collector. The postcard contains the data requested by 184 the management plane. The requested data are configured by the 185 management plane. Once the collector receives all the postcards for 186 a single user packet, it can infer the packet's forwarding path and 187 analyze the data set. The path end node is configured to unmark the 188 packets to its original format if necessary. 190 The overall architecture of PBT-M is depicted in Figure 1. 192 +------------+ +-----------+ 193 | Network | | Telemetry | 194 | Management |(-------| Data | 195 | | | Collector | 196 +-----:------+ +-----------+ 197 : ^ 198 :configurations |postcards 199 : |(OAM pkts) 200 ...............:.....................|........ 201 : : : | : 202 : +---------:---+-----------:---+--+-------:---+ 203 : | : | : | : | 204 V | V | V | V | 205 +------+-+ +-----+--+ +------+-+ +------+-+ 206 usr pkts | Head | | Path | | Path | | End | 207 ====>| Node |====>| Node |====>| Node |====>| Node |===> 208 | | | A | | B | | | 209 +--------+ +--------+ +--------+ +--------+ 210 mark usr pkts gen postcards gen postcards gen postcards 211 gen postcards unmark usr pkts 213 Figure 1: Architecture of PBT-M 215 PBT-M aims to address the issues listed above. It also introduces 216 some new benefits. The advantages of PBT-M are summarized as 217 follows. 219 o 1: PBT-M avoids augmenting user packets with new headers and 220 introducing new data plane protocols. The telemetry data 221 collecting signaling remains in the data plane. 223 o 2: PBT-M is extensible for collecting arbitrary new data to 224 support possible future use cases. The data set to be collected 225 can be configured through the management plane or control plane. 226 Since there is no limitation on the types of data, any data other 227 than those defined in [I-D.ietf-ippm-ioam-data] can also be 228 collected. Since there is no size constraint anymore, it is free 229 to use a more flexible data set template for data type definition. 231 o 3: PBT-M avoids interfering with the normal forwarding and 232 affecting the forwarding performance. Hence, the collected data 233 are free to be transported independently through in-band or out- 234 of-band channels. The data collecting, processing, assembly, 235 encapsulation, and transport are, therefore, decoupled from the 236 forwarding of the corresponding user packets and can be performed 237 in data-plane slow-path if necessary. 239 o 4: For PBT-M, the types of data collected from each node can vary 240 depending on application requirements and node capability. This 241 is either impossible or very difficult to be supported by the 242 passport mode in which the instruction header conveys data types 243 collected per node. 245 o 5: PBT-M makes it easy to secure the collected data without 246 exposing it to unnecessary entities. For example, both the 247 configuration and the telemetry data can be encrypted before being 248 transported, so passive eavesdropping and a man-in-the-middle 249 attack can both be deterred. 251 o 6: Even if a user packet under inspection is dropped at some node 252 in the network, the postcards collected from the preceding nodes 253 are still valid and can be used to diagnose the packet drop 254 location and reason. 256 3. New Challenges 258 Although PBT-M addresses the issues of the passport mode telemetry 259 and the instruction-based PBT, it introduces a few new challenges. 261 o Challenge 1 (Packet Marking): A user packet needs to be marked to 262 trigger the path-associated data collection. Since the PBT-M does 263 not augment user packets with any new header fields, it needs to 264 reserve or reuse bits from the existing header fields. This 265 raises a similar issue as in the Alternate Marking Scheme 266 [RFC8321] 268 o Challenge 2 (Configuration): Since the packet header will not 269 carry OAM instructions anymore, the data plane devices need to be 270 configured to know what data to collect. However, in general, the 271 forwarding path of a flow packet (due to ECMP or dynamic routing) 272 is unknown beforehand (note that there are some notable 273 exceptions, such as segment routing). If the per-flow customized 274 data collection is required, configuring the data set for each 275 flow at all data plane devices might be expensive in terms of 276 configuration load and data plane resources. 278 o Challenge 3 (Data Correlation): Due to the variable transport 279 latency, the dedicated postcard packets for a single packet may 280 arrive at the collector out of order or be dropped in networks for 281 some reason. In order to infer the packet forwarding path, the 282 collector needs some information from the postcard packets to 283 identify the user packet affiliation and the order of path node 284 traversal. 286 o Challenge 4 (Load Overhead): Since each postcard packet has its 287 header, the overall network bandwidth overhead of PBT is higher 288 than IOAM. A large number of postcards could add processing 289 pressure on data collecting servers. That can be used as an 290 attack vector for DoS. 292 4. PBT-M Design Considerations 294 To address the above challenges, we propose several design details of 295 PBT-M. 297 4.1. Packet Marking 299 To trigger the path-associated data collection, usually, a single bit 300 from some header field is sufficient. While no such bit is 301 available, other packet-marking techniques are needed. We discuss 302 several possible application scenarios. 304 o IPv4. Alternate Marking (AM) [RFC8321] is an IP flow performance 305 measurement framework that also requires a single bit for packet 306 coloring. The difference is that AM does in-network measurement 307 while PBT-M only collects and exports data at network nodes (i.e., 308 the data analysis is done at the collector rather than in the 309 network nodes). AM suggests to use some reserved bit of the Flag 310 field or some unused bit of the TOS field. Actually, AM can be 311 considered a sub-case of PBT-M, so that the same bit can be used 312 for PBT-M. The management plane is responsible for configuring 313 the actual operation mode. 315 o SFC NSH. The OAM bit in the NSH header can be used to trigger the 316 on-path data collection [I-D.ietf-sfc-nsh]. PBT does not add any 317 other metadata to NSH. 319 o MPLS. Instead of choosing a header bit, we take advantage of the 320 synonymous flow label [I-D.bryant-mpls-synonymous-flow-labels] 321 approach to mark the packets. A synonymous flow label indicates 322 the on-path data should be collected and forwarded through a 323 postcard. 325 o SRv6: A flag bit in SRH can be reserved to trigger the on-path 326 data collection [I-D.song-6man-srv6-pbt]. SRv6 OAM 327 [I-D.ietf-6man-spring-srv6-oam] has adopted the O-bit in SRH flags 328 as the marking bit to trigger the telemetry. 330 4.2. Flow Path Discovery 332 In case the path that a flow traverses is unknown in advance, all 333 PBT-aware nodes should be configured to react to the marked packets 334 by exporting some basic data, such as node ID and TTL before a data 335 set template for that flow is configured. This way, the management 336 plane can learn the flow path dynamically. 338 If the management plane wants to collect the on-path data for some 339 flow, it configures the head node(s) with a probability or time 340 interval for the flow packet marking. When the first marked packet 341 is forwarded in the network, the PBT-aware nodes will export the 342 basic data set to the collector. Hence, the flow path is identified. 343 If other data types need to be collected, the management plane can 344 further configure the data set's template to the target nodes on the 345 flow's path. The PBT-aware nodes collect and export data accordingly 346 if the packet is marked and a data set template is present. 348 If the flow path is changed for any reason, the new path can be 349 quickly learned by the collector. Consequently, the management plane 350 controller can be directed to configure the nodes on the new path. 351 The outdated configuration can be automatically timed out or 352 explicitly revoked by the management plane controller. 354 4.3. Packet Identity for Export Data Correlation 356 The collector needs to correlate all the postcard packets for a 357 single user packet. Once this is done, the TTL (or the timestamp, if 358 the network time is synchronized) can be used to infer the flow 359 forwarding path. The key issue here is to correlate all the 360 postcards for the same user packet. 362 The first possible approach includes the flow ID plus the user packet 363 ID in the OAM packets. For example, the flow ID can be the 5-tuple 364 IP header of the user traffic, and the user packet ID can be some 365 unique information pertaining to a user packet (e.g., the sequence 366 number of a TCP packet). 368 If the packet marking interval is large enough, the flow ID is enough 369 to identify a user packet. As a result, it can be assumed that all 370 the exported postcard packets for the same flow during a short time 371 interval belong to the same user packet. 373 Alternatively, if the network is synchronized, then the flow ID plus 374 the timestamp at each node can also infer the postcard affiliation. 375 However, some errors may occur under some circumstances. For 376 example, two consecutive user packets from the same flows are marked, 377 but one exported postcard from a node is lost. It is difficult for 378 the collector to decide to which user packet the remaining postcard 379 is related. In many cases, such a rare error has no catastrophic 380 consequence. Therefore it is tolerable. 382 4.4. Control the Load 384 PBT-M should not be applied to all the packets all the time. It is 385 better to be used in an interactive environment where the network 386 telemetry applications dynamically decide which subset of traffic is 387 under scrutiny. The network devices can limit the PBT rate through 388 sampling and metering. The PBT packets can be distributed to 389 different servers to balance the processing load. 391 It is important to understand that the total amount of data exported 392 by PBT-M is identical to that of IOAM. The only extra overhead is 393 the packet header of the postcards. In the case of IOAM, it carries 394 the data from each node throughout the path to the end node before 395 exporting the aggregated data. On the other hand, PBT-M directly 396 exports local data. The overall network bandwidth impact depends on 397 the network topology and scale, and PBT-M could be more bandwidth 398 efficient. 400 5. Implementation Recommendation 402 5.1. Configuration 404 The head node's ACL should be configured to filter out the target 405 flows for telemetry data collection. Optionally, a flow packet 406 sampling rate or probability could be configured to monitor a subset 407 of the flow packets. 409 The telemetry data set that should be exported by postcards at each 410 path node could be configured using the data set templates specified, 411 for example, in IPFIX [RFC7011]. In future revisions, we will 412 provide more details. 414 The PBT-aware path nodes could be configured to respond or ignore the 415 marked packets. 417 5.2. Postcard Format 419 The postcard should use the same data export format as that used by 420 IOAM. [I-D.spiegel-ippm-ioam-rawexport] proposes a raw format that 421 can be interpreted by IPFIX. In future revisions, we will provide 422 more details. 424 5.3. Data Correlation 426 Enough information should be included to help the collector to 427 correlate and order the postcards for a single user packet. 428 Section 4.3 provides several possible means. The application 429 scenario and network protocol are important factors to determine the 430 means to use. In future revisions, we will provide details for 431 representative applications. 433 6. Security Considerations 435 Several security issues need to be considered. 437 o Eavesdrop and tamper: the postcards can be encrypted and 438 authenticated to avoid such security threats. 440 o DoS attack: PBT can be limited to a single administrative domain. 441 The mark must be removed at the egress domain edge. The node can 442 rate-limit the extra traffic incurred by postcards. 444 7. IANA Considerations 446 No requirement for IANA is identified. 448 8. Contributors 450 We thank Alfred Morton who provided valuable suggestions and comments 451 helping improve this draft. 453 9. Acknowledgments 455 TBD. 457 10. Informative References 459 [I-D.brockners-inband-oam-transport] 460 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 461 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 462 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 463 situ OAM Data", draft-brockners-inband-oam-transport-05 464 (work in progress), July 2017. 466 [I-D.bryant-mpls-synonymous-flow-labels] 467 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 468 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 469 bryant-mpls-synonymous-flow-labels-01 (work in progress), 470 July 2015. 472 [I-D.ietf-6man-spring-srv6-oam] 473 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 474 Chen, "Operations, Administration, and Maintenance (OAM) 475 in Segment Routing Networks with IPv6 Data plane (SRv6)", 476 draft-ietf-6man-spring-srv6-oam-07 (work in progress), 477 July 2020. 479 [I-D.ietf-ippm-ioam-data] 480 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 481 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 482 progress), July 2020. 484 [I-D.ietf-ippm-ioam-direct-export] 485 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 486 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 487 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 488 export-00 (work in progress), February 2020. 490 [I-D.ietf-sfc-nsh] 491 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 492 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 493 November 2017. 495 [I-D.song-6man-srv6-pbt] 496 Song, H., "Support Postcard-Based Telemetry for SRv6 OAM", 497 draft-song-6man-srv6-pbt-01 (work in progress), October 498 2019. 500 [I-D.song-ippm-ioam-ipv6-support] 501 Song, H., Li, Z., and S. Peng, "Approaches on Supporting 502 IOAM in IPv6", draft-song-ippm-ioam-ipv6-support-00 (work 503 in progress), March 2020. 505 [I-D.spiegel-ippm-ioam-rawexport] 506 Spiegel, M., Brockners, F., Bhandari, S., and R. 507 Sivakolundu, "In-situ OAM raw data export with IPFIX", 508 draft-spiegel-ippm-ioam-rawexport-01 (work in progress), 509 October 2018. 511 [RFC2925] White, K., "Definitions of Managed Objects for Remote 512 Ping, Traceroute, and Lookup Operations", RFC 2925, 513 DOI 10.17487/RFC2925, September 2000, 514 . 516 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 517 "Specification of the IP Flow Information Export (IPFIX) 518 Protocol for the Exchange of Flow Information", STD 77, 519 RFC 7011, DOI 10.17487/RFC7011, September 2013, 520 . 522 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 523 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 524 "Alternate-Marking Method for Passive and Hybrid 525 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 526 January 2018, . 528 Authors' Addresses 530 Haoyu Song 531 Futurewei 532 2330 Central Expressway 533 Santa Clara, 95050 534 USA 536 Email: hsong@futurewei.com 538 Tianran Zhou 539 Huawei 540 156 Beiqing Road 541 Beijing, 100095 542 P.R. China 544 Email: zhoutianran@huawei.com 546 Zhenbin Li 547 Huawei 548 156 Beiqing Road 549 Beijing, 100095 550 P.R. China 552 Email: lizhenbin@huawei.com 554 Greg Mirsky 555 ZTE Corp. 557 Email: gregimirsky@gmail.com 558 Jongyoon Shin 559 SK Telecom 560 South Korea 562 Email: jongyoon.shin@sk.com 564 Kyungtae Lee 565 LG U+ 566 South Korea 568 Email: coolee@lguplus.co.kr