idnits 2.17.1 draft-ietf-pim-igmp-mld-extension-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 : ---------------------------------------------------------------------------- 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 (3 June 2022) is 694 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) -- Looks like a reference, but probably isn't: '1' on line 296 -- Looks like a reference, but probably isn't: '2' on line 302 == Missing Reference: 'N' is mentioned on line 273, but not defined == Missing Reference: 'M' is mentioned on line 312, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sivakumar 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track S. Venaas 5 Expires: 5 December 2022 Cisco Systems, Inc. 6 Z. Zhang 7 ZTE Corporation 8 H. Asaeda 9 NICT 10 3 June 2022 12 Internet Group Management Protocol version 3 (IGMPv3) and Multicast 13 Listener Discovery version 2 (MLDv2) Message Extension 14 draft-ietf-pim-igmp-mld-extension-08 16 Abstract 18 This document specifies a generic mechanism to extend IGMPv3 and 19 MLDv2 by using a list of TLVs (Type, Length and Value). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 5 December 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 3 56 3. Extension Format . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Multicast Listener Query Extension . . . . . . . . . . . 4 58 3.2. Version 2 Multicast Listener Report Extension . . . . . . 5 59 3.3. IGMP Membership Query Extension . . . . . . . . . . . . . 6 60 3.4. IGMP Version 3 Membership Report Extension . . . . . . . 7 61 4. No-op TLV . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Processing the extension . . . . . . . . . . . . . . . . . . 9 63 6. Applicability and backwards compatibility . . . . . . . . . . 10 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 10.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 This document defines a generic method to extend IGMPv3 [RFC3376] and 75 MLDv2 [RFC3810] messages to accommodate information other than what 76 is contained in the current message formats. This is done by 77 allowing a list of TLVs (Type, Length and Value) to be used in the 78 Additional Data section of IGMPv3 and MLDv2 messages. This document 79 defines a registry for such TLVs, while other documents will define 80 the specific types and their values, and their semantics. The 81 extension would only be used when at least one TLV is to be added to 82 the message. This extension also applies to the lightweight versions 83 of IGMPv3 and MLDv2 as defined in [RFC5790]. 85 When this extension mechanism is used, it replaces the Additional 86 Data section defined in IGMPv3/MLDv2 with TLVs. 88 Additional Data is defined for Query messages in IGMPv3 [RFC3376] 89 Section 4.1.10 and MLDv2 [RFC3810] Section 5.1.12, and for Report 90 messages in IGMPv3 [RFC3376] Section 4.2.11 and MLDv2 [RFC3810] 91 Section 5.2.11. 93 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Extension Format 103 For each of the IGMPv3 and MLDv2 headers, a previously reserved bit 104 is used to indicate the presence of this extension. When this 105 extension is used, the Additional Data of IGMPv3 and MLDv2 messages 106 is formatted as follows. Note that this format contains a variable 107 number of TLVs. It MUST contain at least one TLV. 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Extension Type 1 | Extension Length 1 | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Extension Value 1 | 115 . . . 116 . . . 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Extension Type 2 | Extension Length 2 | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Extension Value 2 | 121 . . . 122 . . . 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Extension Type n | Extension Length n | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Extension Value n | 127 . . . 128 . . . 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1: Figure 1: Extension Format 133 Extension Type: 2 octets. This identifies a particular Extension 134 Type as defined in the IGMP/MLD Extension Type Registry. If this 135 is not the first TLV, it will follow immediately after the end of 136 the previous one. There is no alignment or padding. 138 Extension Length: 2 octets. This specifies the length in octets 139 of the following Extension Value field. The length may be zero if 140 no value is needed. 142 Extension Value: This field contains the value. The length and 143 the contents of this field is according to the specification of 144 the Extension Type. 146 IGMPv3 and MLDv2 messages are defined so that they can fit within the 147 network MTU, in order to avoid fragmentation. An IGMPv3/MLDv2 report 148 message contains a number of records. The records are called Group 149 Records for IGMPv3, and Address Records for MLDv2. When this 150 extension mechanism is used, the number of records in each Report 151 message SHOULD be kept small enough that the entire message, 152 including any extension TLVs can fit within the network MTU. 154 3.1. Multicast Listener Query Extension 156 The MLDv2 Query Message format [RFC3810] with extension is shown 157 below. The E-bit MUST be set to 1 to indicate that the extension is 158 present. Otherwise, it MUST be 0. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type = 130 | Code | Checksum | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Maximum Response Code | Reserved | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 * * 169 | | 170 * Multicast Address * 171 | | 172 * * 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |E| Resv|S| QRV | QQIC | Number of Sources (N) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 * * 179 | | 180 * Source Address [1] * 181 | | 182 * * 183 | | 184 +- -+ 185 | | 186 * * 187 | | 188 * Source Address [2] * 189 | | 190 * * 191 | | 192 +- . -+ 193 . . . 194 . . . 195 +- -+ 196 | | 197 * * 198 | | 199 * Source Address [N] * 200 | | 201 * * 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Extension | 205 ~ ~ 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 2: Figure 2: MLD Query Extension 210 3.2. Version 2 Multicast Listener Report Extension 212 The MLDv2 Report Message format [RFC3810] with extension is shown 213 below. The E-bit MUST be set to 1 to indicate that the extension is 214 present. Otherwise, it MUST be 0. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type = 143 | Reserved | Checksum | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 |E| Reserved |Nr of Mcast Address Records (M)| 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 . . 225 . Multicast Address Record [1] . 226 . . 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 . . 231 . Multicast Address Record [2] . 232 . . 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | . | 236 . . . 237 | . | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 . . 241 . Multicast Address Record [M] . 242 . . 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Extension | 246 ~ ~ 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 3: Figure 3: MLD Report Extension 251 3.3. IGMP Membership Query Extension 253 The IGMPv3 Query Message format [RFC3376] with the extension is shown 254 below. The E-bit MUST be set to 1 to indicate that the extension is 255 present. Otherwise, it MUST be 0. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type = 0x11 | Max Resp Code | Checksum | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Group Address | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |E| Resv|S| QRV | QQIC | Number of Sources (N) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Source Address [1] | 267 +- -+ 268 | Source Address [2] | 269 +- . -+ 270 . . . 271 . . . 272 +- -+ 273 | Source Address [N] | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Extension | 276 ~ ~ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 4: Figure 4: IGMP Query Extension 281 3.4. IGMP Version 3 Membership Report Extension 283 The IGMPv3 Report Message format [RFC3376] with the extension is 284 shown below. The E-bit MUST be set to 1 to indicate that the 285 extension is present. Otherwise, it MUST be 0. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type = 0x22 | Reserved | Checksum | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |E| Reserved | Number of Group Records (M) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 . . 296 . Group Record [1] . 297 . . 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 . . 302 . Group Record [2] . 303 . . 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | . | 307 . . . 308 | . | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 . . 312 . Group Record [M] . 313 . . 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Extension | 317 ~ ~ 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 5: Figure 5: IGMP Report Extension 322 4. No-op TLV 324 The no-op TLV is a No-Operation TLV that MUST be ignored during 325 processing. This TLV may be useful for verifying that 326 implementations correctly implement this extension mechanism. Note 327 that there is no alignment requirement, so there is no need to use 328 this Extension Type to provide alignment. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | No-op Type = 0 | No-op Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Value | 336 . . . 337 . . . 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 6: Figure 6: No-op TLV Format 342 No-op Type: 2 octets. The type of the No-op TLV extension is the 343 value 0. 345 Extension Length: 2 octets. This specifies the length in octets 346 of the following Value field. The length may be zero if no value 347 is needed. 349 Value: This field contains the value. As this Extension Type is 350 always ignored, the value can be arbitrary data. The number of 351 octets used MUST match the specified length. contents of this 352 field is according to the specification of the Extension Type. 354 5. Processing the extension 356 The procedure specified in this document applies only when the E-bit 357 is set. 359 If the validation of the TLVs fails, the entire Additional Data field 360 MUST be ignored as specified in IGMPv3 [RFC3376] and MLDv2 [RFC3810]. 361 The following checks must pass for the validation of the TLVs not to 362 fail: 364 At least one TLV MUST be present. 366 There MUST NOT be any data in the IP payload after the last TLV. 367 To check this, the parser needs to walk through each of the TLVs 368 until there are less than four octets left in the IP payload. If 369 there are any octets left, validation fails. 371 The total length of the Extension MUST NOT exceed the remainder of 372 the IP payload length. For this validation, one only examines the 373 content of the Extension Length fields. 375 Future documents defining a new Extension Type MUST specify any 376 additional processing and validation. These rules, if any, will be 377 examined only after the general validation (above) succeeds. 379 TLVs with unsupported Extension Types MUST be ignored. 381 6. Applicability and backwards compatibility 383 IGMP and MLD implementations, particularly implementations on hosts, 384 rarely change, and the adoption process of this extension mechanism 385 is expected to be slow. Also, as new extension TLVs are defined, it 386 may take a long time before they are supported. Due to this, 387 defining new extension TLVs should not be taken lightly, and it is 388 crucial to consider backwards compatibility. 390 Implementations that do not support this extension mechanism will 391 ignore it, as specified in [RFC3376] and [RFC3810]. Also, as 392 mentioned in the previous section, unsupported extension TLVs are 393 ignored. 395 It is possible that a new extension TLV only applies to queries, or 396 only to reports, or there may be other specific conditions for when 397 it is to be used. A document defining a new Extension Type MUST 398 specify under what conditions the new Extension Type should be used, 399 including for which message types. It MUST also be specified what 400 the behavior should be if a message is not used in the defined 401 manner, e.g., if it is present in a query message, when it was only 402 expected to be used in reports. 404 When defining new Extension Types, care should be taken to consider 405 the effect of partial support for the new TLV, by either the hosts or 406 routers, on the same link. Further, it must be considered whether 407 there are any dependencies or restrictions on combinations between 408 the new Extension Types and any pre-existing Extension Types. 410 This document defines an extension mechanism only for IGMPv3 and 411 MLDv2. Hence, this mechanism does not apply if hosts or routers send 412 older version messages. 414 7. Security Considerations 416 The Security Considerations of [RFC3376] and [RFC3810] also apply 417 here. 419 This document extends the IGMP and MLD message formats, allowing for 420 a variable number of TLVs. Implementations must take care when 421 parsing the TLVs to not exceed the packet boundary, an attacker could 422 intentionally specify a TLV with a length exceeding the boundary. 424 An implementation could add a large number of minimal TLVs in a 425 message to increase the cost of processing the message to magnify a 426 Denial of Service attack. 428 8. IANA Considerations 430 IANA is asked to create a new registry called "IGMP/MLD Extension 431 Types" in the "Internet Group Management Protocol (IGMP) Type 432 Numbers" section, with registration procedure "IETF Review" 433 [RFC8126], and with this document as a reference. The registry is 434 common for IGMP and MLD. 436 Two Extension Types are provided for "Experimental Use" [RFC8126]. 437 Any experiments should be confined to closed environments where it is 438 unlikely that they may conflict with other experiments, see 439 [RFC3692]. 441 The initial content of the registry should be as below. 443 Extension Type Length Name Reference 444 -------------------------------------------------------------- 445 0 variable No-op [this document] 446 1-65533 Unassigned 447 65534 variable Experimental use 448 65535 variable Experimental use 450 9. Acknowledgements 452 The authors thank Ron Bonica, Ian Duncan, Wesley Eddy, Leonard 453 Giuliano, Jake Holland, Tommy Pauly, Pete Resnick, Alvaro Retana and 454 Zhaohui Zhang for reviewing the document and providing valuable 455 feedback. 457 10. References 459 10.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 467 Thyagarajan, "Internet Group Management Protocol, Version 468 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 469 . 471 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 472 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 473 DOI 10.17487/RFC3810, June 2004, 474 . 476 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 477 Writing an IANA Considerations Section in RFCs", BCP 26, 478 RFC 8126, DOI 10.17487/RFC8126, June 2017, 479 . 481 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 482 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 483 May 2017, . 485 10.2. Informative References 487 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 488 Considered Useful", BCP 82, RFC 3692, 489 DOI 10.17487/RFC3692, January 2004, 490 . 492 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 493 Group Management Protocol Version 3 (IGMPv3) and Multicast 494 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 495 DOI 10.17487/RFC5790, February 2010, 496 . 498 Authors' Addresses 500 Mahesh Sivakumar 501 Juniper Networks 502 64 Butler St 503 Milpitas, CA 95035 504 United States of America 505 Email: sivakumar.mahesh@gmail.com 507 Stig Venaas 508 Cisco Systems, Inc. 509 Tasman Drive 510 San Jose, CA 95134 511 United States of America 512 Email: stig@cisco.com 514 Zheng(Sandy) Zhang 515 ZTE Corporation 516 No. 50 Software Ave, Yuhuatai District 517 Nanjing 518 210000 519 China 520 Email: zhang.zheng@zte.com.cn 521 Hitoshi Asaeda 522 National Institute of Information and Communications Technology 523 4-2-1 Nukui-Kitamachi, 524 184-8795 525 Japan 526 Email: asaeda@nict.go.jp