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