idnits 2.17.1 draft-song-multicast-telemetry-04.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2020) is 1451 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: 'A' is mentioned on line 182, but not defined -- Looks like a reference, but probably isn't: '0' on line 181 -- Looks like a reference, but probably isn't: '1' on line 182 == Unused Reference: 'RFC4687' is defined on line 413, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4687 == Outdated reference: A later version (-14) exists of draft-ietf-bier-oam-requirements-09 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-09 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-06 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-02 == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM H. Song 3 Internet-Draft M. McBride 4 Intended status: Standards Track Futurewei Technologies 5 Expires: October 9, 2020 G. Mirsky 6 ZTE Corp. 7 April 7, 2020 9 Requirement and Solution for Multicast Traffic On-path Telemetry 10 draft-song-multicast-telemetry-04 12 Abstract 14 This document discusses the requirement of on-path telemetry for 15 multicast traffic. The existing solutions are examined and their 16 issues are addressed with new modifications that adapt to the 17 multicast scenario. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in BCP 24 14 [RFC2119][RFC8174] when, and only when, they appear in all 25 capitals, as shown here. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 9, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements for Multicast Traffic Telemetry . . . . . . . . 3 63 3. Issues of Existing Techniques . . . . . . . . . . . . . . . . 3 64 4. Proposed Modifications to Existing Techniques . . . . . . . . 4 65 4.1. Per-hop postcard using IOAM DEX . . . . . . . . . . . . . 4 66 4.2. Per-section postcard . . . . . . . . . . . . . . . . . . 6 67 5. Considerations for Different Multicast Protocols . . . . . . 7 68 5.1. Application in PIM . . . . . . . . . . . . . . . . . . . 8 69 5.2. Application in P2MP . . . . . . . . . . . . . . . . . . . 8 70 5.3. Application in BIER . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Multicast traffic is an important traffic type in today's Internet. 83 Multicast provides services that are often real time (e.g., online 84 meeting) or have strict QoS requirements (e.g., IPTV, Market Data). 85 Multicast packet drop and delay can severely affect the application 86 performance and user experience. 88 It is important to monitor the performance of the multicast traffic. 89 Existing OAM techniques cannot gain direct and accurate information 90 about the multicast traffic. New on-path telemetry techniques such 91 as In-situ OAM [I-D.ietf-ippm-ioam-data] and Postcard-based Telemetry 92 [I-D.song-ippm-postcard-based-telemetry] provide promising means to 93 directly monitor the network experience of multicast traffic. 94 However, multicast traffic has some unique characteristics which pose 95 some challenges on efficiently applying such techniques. 97 This document describes the requirement for multicast traffic 98 telemetry and shows the issues of the existing on-path telemetry 99 techniques. We then propose modifications to make these techniques 100 adapt to the multicast application. 102 2. Requirements for Multicast Traffic Telemetry 104 Multicast traffic is forwarded through a multicast tree. With PIM 105 and P2MP (MLDP, RSVP-TE) the forwarding tree is established and 106 maintained by the multicast routing protocol. With BIER, no state is 107 created in the network to establish a forwarding tree, instead, a 108 bier header provides the necessary information for each packet to 109 know the egress points. Multicast packets are only replicated at 110 each tree branch node for efficiency. 112 There are several requirements for multicast traffic telemetry, a few 113 of which are: 115 o Reconstruct and visualize the multicast tree through data plane 116 monitoring. 118 o Gather the multicast packet delay and jitter performance. 120 o Find the multicast packet drop location and reason. 122 o Gather the VPN state and tunnel information in case of P2MP 123 multicast. 125 In order to meet these requirements, we need the ability to directly 126 monitor the multicast traffic and derive data from the multicast 127 packets. The conventional OAM mechanisms, such as multicast ping and 128 trace, may not be sufficient to meet these requirements. 130 3. Issues of Existing Techniques 132 On-path Telemetry techniques that directly retrieve data from 133 multicast traffic's live network experience are ideal to address the 134 above mentioned requirements. The representative techniques include 135 In-situ OAM (IOAM) Trace option [I-D.ietf-ippm-ioam-data], IOAM 136 Direct Export (DEX) option [I-D.ioamteam-ippm-ioam-direct-export], 137 and Postcard-based Telemetry with Packet Marking(PBT-M) 138 [I-D.song-ippm-postcard-based-telemetry]. However, unlike unicast, 139 multicast poses some unique challenges to applying these techniques. 141 Multicast packets are replicated at each branch node in the 142 corresponding multicast tree. Therefore, there are multiple copies 143 of a packets in the network. 145 If the IOAM trace option is used for on-path data collection, the 146 partial trace data will also be replicated into multiple copies. The 147 end result is that each copy of the multicast packet has a complete 148 trace, whereas most of the data is redundant. Data redundancy 149 introduces unnecessary header overhead, wastes network bandwidth, and 150 complicates the data processing. In case the multicast tree is 151 large, and the path is long, the redundancy problem becomes severe. 153 The PBT solutions, including the IOAM DEX option and PBT-M, can be 154 used to eliminate such data redundancy, because each node on the tree 155 only sends a postcard covering local data. However, they cannot 156 track the tree branches properly so it can bring confusion about the 157 multicast tree topology. For example, Node A has two branches, one 158 to Node B and the other to node D, and Node B leads to Node C and 159 Node D leads to Node E. From the received postcards, one cannot tell 160 whether or not Node C(E) is the next hop of Node B(D). 162 The fundamental reason for this problem is that there is not an 163 identifier (either implicit or explicit) to correlate the data on 164 each branch. 166 4. Proposed Modifications to Existing Techniques 168 We propose two solutions to address the above issues. One is built 169 on PBT and requires augmentation or modification to the instruction 170 header of the IOAM Direct Export Option; the other combines the IOAM 171 trace option and PBT for an optimized solution. 173 4.1. Per-hop postcard using IOAM DEX 175 The straightforward way to mitigate PBT's multiple tree tracking 176 weakness is to augment it with a branch identifier field. Note that 177 this only works for the IOAM DEX option but not for PBT-M because the 178 IOAM DEX option uses an instruction header. To make the branch 179 identifier globally unique, the branch node ID plus an index is used. 180 For example, if Node A has two branches, one to Node B and one to 181 Node C, Node A will use [A, 0] as the branch identifier for the 182 branch to B, and [A, 1] for the branch to C. The identifier is 183 unchanged for each multicast tree instance and carried with the 184 multicast packet until the next branch node. Each postcard needs to 185 include the branch identifier in the export data. The branch 186 identifier, along with the other fields such as flow ID and sequence 187 number, is sufficient for the data analyzer to reconstruct the 188 topology of the multicast tree. 190 Figure 1 shows an example of this solution. "P" stands for the 191 postcard packet. The square brackets contains the branch identifier. 192 The curly brace contains the telemetry data about a specific node. 194 P:[A,0]{A} P:[A,0]{B} P:[B,1]{D} P:[B,0]{C} 195 ^ ^ ^ ^ 196 : : : : 197 : : : : 198 : : : +-:-+ 199 : : : | | 200 : : +---:----->| C |--... 201 +-:-+ +-:-+ | : | | 202 | | | |----+ : +---+ 203 | A |------->| B | : 204 | | | |--+ +-:-+ 205 +---+ +---+ | | | 206 +-->| D |--.... 207 | | 208 +---+ 210 Figure 1: Per-hop Postcard 212 Each branch fork node need to generate the branch ID for each branch 213 in its multicast tree instance and include it in the IOAM DEX option 214 header so the downstream node can learn it. The branch ID contains 215 two parts: the branch fork node ID and a unique branch index. 217 Figure 2 shows that the branch ID is carried as an optional field 218 after the flow ID and sequence number optional fields in the IOAM DEX 219 option header. A bit "M" in the Flags field is reserved to indicate 220 the presence of the branch index field. The "M" flag position will 221 be determined later after the other flags are specified in 222 [I-D.ioamteam-ippm-ioam-direct-export]. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Namespace-ID |M| Flags | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | IOAM-Trace-Type | Reserved | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Flow ID (optional) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Sequence Number (Optional) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Encoded Branch ID (optional) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 2: Carry Branch Index in IOAM DEX option header 240 To avoid introducing a new type of data field to the IOAM DEX option 241 header, we can encode the branch identifier using the existing node 242 ID data field as defined in [I-D.ietf-ippm-ioam-data] . Currently, 243 the node ID field occupies three octets. The simple solution is to 244 shorten the node ID field so a number of bits can be saved to encode 245 the branch index, as shown in Figure 3. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Hop_Lim | node_id | branch index | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 3: Encode Branch Index with Node ID Method 1 255 Another encoding method is to use the sum of the node ID and the 256 branch index as the new node ID, as shown in Figure 4. As long as 257 the node IDs are assigned with large enough gap, the telemetry data 258 analyzer can still successfully recover the original node ID and 259 branch index. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Hop_Lim | node_id + branch index | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 4: Encode Branch Index with Node ID Method 2 269 Once a node gets the branch ID information from the upstream, it MUST 270 carry this information in its telemetry data export postcards, so the 271 original multicast tree can be correctly reconstructed based on the 272 postcards. 274 4.2. Per-section postcard 276 The second solution is a combination of the IOAM trace mode and PBT. 277 To avoid data redundancy at each branch node, the trace data 278 accumulated, to that point, is exported by a postcard before the 279 packet is replicated. In this case, each branch still needs to 280 maintain some identifier to help correlate the postcards for each 281 tree section. The natural way to accomplish this is to simply carry 282 the branch node's data (including its ID) in the trace of each 283 branch. This is also necessary because each replicated multicast 284 packet can have different telemetry data pertaining to this 285 particular copy (e.g., node delay, egress timestamp, and egress 286 interface). As a consequence, the local data exported by each branch 287 node can only contain partial data (e.g., ingress interface and 288 ingress timestamp). 290 Figure 5 shows an example in a segment of a multicast tree. Node B 291 and D are two branch nodes and they will export a postcard covering 292 the trace data for the previous section. The end node of each path 293 will also need to export the data of the last section as a postcard. 295 P:{A,B'} P:{B1,C,D'} 296 ^ ^ 297 : : 298 : : 299 : : {D1} 300 : : +--... 301 : +---+ +---+ | 302 : {B1} | |{B1,C}| |--+ {D2} 303 : +-->| C |----->| D |-----... 304 +---+ +---+ | | | | |--+ 305 | | {A} | |--+ +---+ +---+ | 306 | A |---->| B | +--... 307 | | | |--+ +---+ {D3} 308 +---+ +---+ | | |{B2,E} 309 +-->| E |--... 310 {B2} | | 311 +---+ 313 Figure 5: Per-section Postcard 315 There is no need to modify the IOAM trace mode header format. We 316 just need to configure the branch node to export the postcard and 317 refresh the IOAM header and data. 319 5. Considerations for Different Multicast Protocols 321 MTRACEv2 [RFC8487] provides an active probing approach for the 322 tracing of an IP multicast routing path. Mtrace can also provide 323 information such as the packet rates and losses, as well as other 324 diagnostic information. New on-path telemetry techniques will 325 enhance Mtrace, and other existing OAM solutions, with more granular 326 and realtime network status data through direct measurements. There 327 are various multicast protocols that are used to forward the 328 multicast data. Each will require their own unique on-path telemetry 329 solution. 331 5.1. Application in PIM 333 PIM-SM [RFC7761] is the most widely used multicast routing protocol 334 deployed today. Of the various PIM modes (PIM-SM, PIM-DM, BIDIR-PIM, 335 PIM-SSM), PIM-SSM is the preferred method due to its simplicity and 336 removal of network source discovery complexity. With all PIM modes, 337 control plane state is established in the network in order to forward 338 multicast UDP data packets. But with PIM-SSM, the discovery of 339 multicast sources is performed outside of the network via HTTP, SDN, 340 etc. IP Multicast packets fall within the range of 224.0.0.0 through 341 239.255.255.255. The telemetry solution will need to work within 342 this address range and provide telemetry data for this UDP traffic. 344 The proposed solutions for encapsulating the telemetry instruction 345 header and metadata in IPv4/IPv6 UDP packets are described in 346 [I-D.herbert-ipv4-udpencap-eh] and 347 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment]. 349 5.2. Application in P2MP 351 Multicast Label Distribution Protocol (MLDP) and P2MP RSVP-TE are 352 commonly used within a Multicast VPN (MVPN) environment. MLDP 353 provides extensions to LDP to establish point-to-multipoint (P2MP) 354 and multipoint-to-multipoint (MP2MP) label switched paths (LSPs) in 355 MPLS networks. P2MP RSVP-TE provides extensions to RSVP-TE for 356 establish traffic-engineered P2MP LSPs in MPLS networks. The 357 telemetry solution will need to be able to follow these P2MP paths. 358 The telemetry instruction header and data should be encapsulated into 359 MPLS packets on P2MP paths. A corresponding proposal is described in 360 [I-D.song-mpls-extension-header]. 362 5.3. Application in BIER 364 BIER [RFC8279] adds a new header to multicast packets and allows the 365 multicast packets to be forwarded according to the header only. By 366 eliminating the requirement of maintaining per multicast group state, 367 BIER is more scalable than the traditional multicast solutions. 369 OAM Requirements for BIER [I-D.ietf-bier-oam-requirements] lists many 370 of the requirements for OAM at the BIER layer which will help in the 371 forming of on-path telemetry requirements as well. 373 There is also current work to provide solutions for BIER forwarding 374 in ipv6 networks. For instance, a solution, BIER in Non-MPLS IPv6 375 Networks [I-D.xie-bier-ipv6-encapsulation], proposes a new bier 376 Option Type codepoint from the "Destination Options and Hop-by-Hop 377 Options" IPv6 sub-registry. This is similar to what IOAM proposes 378 for IPv6 transport. 380 Depending on how the BIER header is encapsulated into packets with 381 different transport protocols, the method to encapsulate the 382 telemetry instruction header and metadata also varies. It is also 383 possible to make the instruction header and metadata a part of the 384 BIER header itself, such as in a TLV. 386 6. Security Considerations 388 No new secuirty issues are identified other than those discovered by 389 the IOAM and PBT drafts. 391 7. IANA Considerations 393 The document makes no request of IANA. 395 8. Contributors 397 TBD 399 9. Acknowledgments 401 The authors would like to thank Frank Brockners, Tianran Zhou for the 402 comments and advice. 404 10. References 406 10.1. Normative References 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 414 "Operations and Management (OAM) Requirements for Point- 415 to-Multipoint MPLS Networks", RFC 4687, 416 DOI 10.17487/RFC4687, September 2006, 417 . 419 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 420 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 421 Multicast - Sparse Mode (PIM-SM): Protocol Specification 422 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 423 2016, . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 427 May 2017, . 429 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 430 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 431 Explicit Replication (BIER)", RFC 8279, 432 DOI 10.17487/RFC8279, November 2017, 433 . 435 [RFC8487] Asaeda, H., Meyer, K., and W. Lee. Ed., "Mtrace Version 2: 436 Traceroute Facility for IP Multicast", RFC 8487, 437 DOI 10.17487/RFC8487, October 2018, 438 . 440 10.2. Informative References 442 [I-D.herbert-ipv4-udpencap-eh] 443 Herbert, T., "IPv4 Extension Headers and UDP Encapsulated 444 Extension Headers", draft-herbert-ipv4-udpencap-eh-01 445 (work in progress), March 2019. 447 [I-D.ietf-bier-oam-requirements] 448 Mirsky, G., Pignataro, C., Kumar, N., Chen, M., and S. 449 Pallagatti, "Operations, Administration and Maintenance 450 (OAM) Requirements for Bit Index Explicit Replication 451 (BIER) Layer", draft-ietf-bier-oam-requirements-09 (work 452 in progress), February 2020. 454 [I-D.ietf-ippm-ioam-data] 455 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 456 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 457 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 458 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 459 ietf-ippm-ioam-data-09 (work in progress), March 2020. 461 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] 462 Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni, 463 B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment 464 Considerations for In-situ OAM with IPv6 Options", draft- 465 ioametal-ippm-6man-ioam-ipv6-deployment-03 (work in 466 progress), March 2020. 468 [I-D.ioamteam-ippm-ioam-direct-export] 469 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 470 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 471 OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- 472 export-00 (work in progress), October 2019. 474 [I-D.song-ippm-postcard-based-telemetry] 475 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 476 "Postcard-based On-Path Flow Data Telemetry", draft-song- 477 ippm-postcard-based-telemetry-06 (work in progress), 478 October 2019. 480 [I-D.song-mpls-extension-header] 481 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 482 Extension Header", draft-song-mpls-extension-header-02 483 (work in progress), February 2019. 485 [I-D.xie-bier-ipv6-encapsulation] 486 Xie, J., Geng, L., McBride, M., Asati, R., and S. 487 Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6 488 Networks", draft-xie-bier-ipv6-encapsulation-06 (work in 489 progress), March 2020. 491 Authors' Addresses 493 Haoyu Song 494 Futurewei Technologies 495 2330 Central Expressway 496 Santa Clara 497 USA 499 Email: hsong@futurewei.com 501 Mike McBride 502 Futurewei Technologies 503 2330 Central Expressway 504 Santa Clara 505 USA 507 Email: mmcbride@futurewei.com 509 Greg Mirsky 510 ZTE Corp. 512 Email: gregimirsky@gmail.com