idnits 2.17.1 draft-ietf-pim-igmp-mld-extension-07.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 (9 May 2022) is 711 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: 10 November 2022 Cisco Systems, Inc. 6 Z. Zhang 7 ZTE Corporation 8 H. Asaeda 9 NICT 10 9 May 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-07 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 10 November 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 for 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 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 type is always 350 ignored, the value can be arbitrary data. The number of octets 351 used MUST match the specified length. contents of this field is 352 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 type MUST specify any additional 376 processing and validation. These rules, if any, will be examined 377 only after the general validation (above) succeeds. 379 TLVs with unsupported 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 type MUST specify under 398 what conditions the new type should be used, including for which 399 message types. It MUST also be specified what the behavior should be 400 if a message is not used in the defined manner, e.g., if it is 401 present in a query message, when it was only expected to be used in 402 reports. 404 When defining new types, care should be taken to consider the effect 405 of partial support for the new TLV, by either the hosts or routers, 406 on the same link. Further, it must be considered whether there are 407 any dependencies or restrictions on combinations between the new 408 types and any pre-existing 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. Two extension types are provided for 435 "Experimental Use" [RFC8126]. These types can be used by experiments 436 without any need for an assignment. Any experiments should be 437 confined to closed environments where it is unlikely that it may 438 conflict with other experiments. An experimental type might be used 439 in public deployments if the experimental use is not enabled by 440 default. The default should be to ignore all experimental types. 441 The initial content of the registry should be as below. 443 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 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 488 Group Management Protocol Version 3 (IGMPv3) and Multicast 489 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 490 DOI 10.17487/RFC5790, February 2010, 491 . 493 Authors' Addresses 495 Mahesh Sivakumar 496 Juniper Networks 497 64 Butler St 498 Milpitas, CA 95035 499 United States of America 500 Email: sivakumar.mahesh@gmail.com 502 Stig Venaas 503 Cisco Systems, Inc. 504 Tasman Drive 505 San Jose, CA 95134 506 United States of America 507 Email: stig@cisco.com 509 Zheng(Sandy) Zhang 510 ZTE Corporation 511 No. 50 Software Ave, Yuhuatai District 512 Nanjing 513 210000 514 China 515 Email: zhang.zheng@zte.com.cn 516 Hitoshi Asaeda 517 National Institute of Information and Communications Technology 518 4-2-1 Nukui-Kitamachi, 519 184-8795 520 Japan 521 Email: asaeda@nict.go.jp