idnits 2.17.1 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.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 (May 21, 2019) is 1801 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME S. Kampati 3 Internet-Draft M. Bharath 4 Intended status: Standards Track W. Pan 5 Expires: November 22, 2019 Huawei 6 May 21, 2019 8 IKEv2 Optional SA&TS Payloads in Child Exchange 9 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 11 Abstract 13 This document describes a method for reducing the size of the 14 Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying 15 IKE SAs and Child SAs by removing or making optional of SA & TS 16 payloads. Reducing size of IKEv2 exchanges is desirable for low 17 power consumption battery powered devices. It also helps to avoid IP 18 fragmentation of IKEv2 messages. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 22, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Negotiation of Support for Optimizing Optional Payload at 59 Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 3 60 3.2. Optional Payload Optimization at Rekeying IKE SAs . . . . 4 61 3.2.1. Rekeying IKE SAs When No Change of Initiator and 62 Responder's Cryptographic Suites . . . . . . . . . . 4 63 3.2.2. Rekeying IKE SAs When Initiator's Cryptographic 64 Suites Changed . . . . . . . . . . . . . . . . . . . 5 65 3.2.3. Rekeying IKE SAs When Responder's Cryptographic 66 Suites Changed . . . . . . . . . . . . . . . . . . . 5 67 3.3. Optional Payload Optimization at Rekeying Child SAs . . . 6 68 3.3.1. Rekeying Child SAs When No Change of Initiator and 69 Responder's Cryptographic Suites and ACL 70 Configuration . . . . . . . . . . . . . . . . . . . . 6 71 3.3.2. Rekeying Child SAs When Initiator's Cryptographic 72 Suites or ACL Configuration Changed . . . . . . . . . 7 73 3.3.3. Rekeying Child SAs When Responder's Cryptographic 74 Suites or ACL Configuration Changed . . . . . . . . . 7 75 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 8 77 4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 9 78 4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 9 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 7.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 The Internet Key Exchange protocol version 2 (IKEv2) specified in 89 [RFC7296] is used in the IP Security (IPsec) architecture for the 90 purposes of Security Association (SA) parameters negotiation and 91 authenticated key exchange. The protocol uses UDP as the transport 92 for its messages, which size varies from less than one hundred bytes 93 to several kBytes. 95 In 4G networks security gateways/ePDG and in 5G networks cRAN/Cloud 96 will support more than 100,000 IKE/IPSEC tunnels. So on an average, 97 for every second there may be hundreds or thousands of IKE SAs and 98 Child SAs that are rekeying. This takes huge amount of bandwidth, 99 packet fragmentation and more processing resources. And it can be 100 solved by introducing the solution described in this document. 102 This is useful in Internet of Things (IoT) devices which utilizing 103 lower power consumption technology. The appendix A of 104 [I-D.mglt-6lo-diet-esp-requirements] gives some estimate data. 106 Most devices don't prefer to change cryptographic suites frequently. 107 By taking this advantage the SA and TS payloads can be made optional 108 at the time of rekeying IKE SAs and Child SAs. In such situation, 109 only a new SPI value is needed to create the new IKE SA and Child SA. 110 So a new Notify payload which contains the needed SPI value can be 111 sent instead of the SA and TS payloads. 113 In case of rekeying IKE SAs, the SA payloads can be optimized if 114 there is no change of cryptographic suites. In case of rekeying 115 Child SAs, the SA and TS payloads can be optimized if there is no 116 change of cryptographic suites and ACL configuration. 118 2. Conventions Used in This Document 120 2.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. Protocol Details 130 This section provides protocol details and contains the normative 131 parts. 133 3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying 134 IKE SAs and Child SAs 136 The initiator indicates its support for optimizing optional payloads 137 at rekeying IKE SAs and Child SAs by including a Notify payload of 138 type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. If the 139 responder also supports this extension, it includes the 140 MINIMAL_REKEY_SUPPORTED notification in the response message. If the 141 responder doesn't support this extension, it MUST ignore the 142 MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST 143 NOT respond error to the initiator. 145 The IKE_AUTH message exchange in this case is shown below: 147 Initiator Responder 148 -------------------------------------------------------------------- 149 HDR, SK {IDi, [CERT,] [CERTREQ,] 150 [IDr,] AUTH, SAi2, TSi, TSr, 151 N(MINIMAL_REKEY_SUPPORTED)} --> 152 <-- HDR, SK {IDr, [CERT,] AUTH, 153 SAr2, TSi, TSr, 154 N(MINIMAL_REKEY_SUPPORTED)} 156 3.2. Optional Payload Optimization at Rekeying IKE SAs 158 The payload optimization at rekeying IKE SAs MUST NOT be used unless 159 both peers have indicated their support of this extension by using 160 the negotiation method described in Section 3.1. If the initiator or 161 responder decides to use this payload optimization, then it includes 162 the SA_UNCHANGED notification in its CREATE_CHILD_SA exchange message 163 at the time of rekeying IKE SAs. This SA_UNCHANGED notification MUST 164 be included in a CREATE_CHILD_SA exchange message when there is no SA 165 payloads included. The new IKE SA is created with the SPI value in 166 the SA_UNCHANGED notification. 168 3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's 169 Cryptographic Suites 171 At the time of rekeying IKE SAs, the initiator MAY send the 172 SA_UNCHANGED notification payload instead of the SA payloads when 173 there is no change in its cryptographic suites since last 174 negotiation. After receiving the initiator's request message with 175 the SA_UNCHANGED notification, the responder MAY respond to the 176 initiator with the SA_UNCHANGED notification payload instead of the 177 SA payloads if there is also no change in its cryptographic suites 178 since last negotiation. 180 The CREATE_CHILD_SA message exchange in this case is shown below: 182 Initiator Responder 183 -------------------------------------------------------------------- 184 HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> 185 <-- HDR, SK {N(SA_UNCHANGED), Nr, KEr} 187 The initiator sends a SA_UNCHANGED notification payload, a Nonce 188 payload and a Diffie-Hellman value in the KEi payload. A new 189 initiator SPI is supplied in the SPI field of the SA_UNCHANGED 190 notification payload. 192 The responder replies (using the same Message ID to respond) with a 193 SA_UNCHANGED notification payload, a Nonce payload and a Diffie- 194 Hellman value in the KEr payload. A new responder SPI is supplied in 195 the SPI field of the SA_UNCHANGED notification payload. 197 When the SA_UNCHANGED notification payload is included, the SA 198 payload MUST NOT be included. 200 3.2.2. Rekeying IKE SAs When Initiator's Cryptographic Suites Changed 202 At the time of or before rekeying IKE SAs, the initiator's 203 cryptographic suites may be changed while there is no change of 204 responder's cryptographic suites. New cryptographic suites may be 205 added to the initiator, or some outdated cryptographic suites may be 206 deleted from the initiator. 208 In this situation, the initiator MUST send the SA payloads in the 209 CREATE_CHILD_SA request message at the time of rekeying IKE SAs. 211 If the responder selects a different cryptographic suite than which 212 was previously negotiated, then the rekeying MUST be conducted in the 213 original way defined in [RFC7296], the responder sends the SA 214 payloads with the selected cryptographic suite in the CREATE_CHILD_SA 215 response message. 217 If the responder selects the previously negotiated cryptographic 218 suite to rekey the IKE SA, it MAY send the SA_UNCHANGED notification 219 payload instead of the SA payload in the CREATE_CHILD_SA response 220 message, and the initiator MUST use the cryptographic suite 221 negotiated previously to create the new IKE SA. The CREATE_CHILD_SA 222 message exchange in this case is shown below: 224 Initiator Responder 225 -------------------------------------------------------------------- 226 HDR, SK {SA, Ni, KEi} --> 227 <-- HDR, SK {N(SA_UNCHANGED), Nr, KEr} 229 3.2.3. Rekeying IKE SAs When Responder's Cryptographic Suites Changed 231 At the time of or before rekeying IKE SAs, the responder's 232 cryptographic suites may be changed while there is no change of 233 initiator's cryptographic suites. New cryptographic suites may be 234 added to the responder, or some outdated cryptographic suites may be 235 deleted from the responder. 237 In this situation, the initiator sends the SA_UNCHANGED notification 238 payload instead of the SA payloads in the CREATE_CHILD_SA request 239 message at the time of rekeying IKE SAs. 241 If the responder decides to continue using the previously negotiated 242 cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED 243 notification payload in the CREATE_CHILD_SA response message, then 244 the rekeying is conducted like Section 3.2.1. 246 If the responder decides to re-negotiate the cryptographic suite, it 247 MUST send NO_PROPOSAL_CHOSEN notification payload in the 248 CREATE_CHILD_SA response message. After receiving this error 249 notification, the initiator MUST retry the CREATE_CHILD_SA exchange 250 with the SA payloads. Then the rekeying is conducted in the original 251 way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in 252 this case is shown below: 254 Initiator Responder 255 -------------------------------------------------------------------- 256 HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> 257 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), 258 Nr, KEr} 259 HDR, SK {SA, Ni, KEi} --> 260 <-- HDR, SK {SA, Ni, KEi} 262 3.3. Optional Payload Optimization at Rekeying Child SAs 264 The payload optimization at rekeying Child SAs MUST NOT be used 265 unless both peers have indicated their support of this extension by 266 using the negotiation method described in Section 3.1. If the 267 initiator or responder decides to use this payload optimization, then 268 it includes the SA_TS_UNCHANGED notification in its CREATE_CHILD_SA 269 exchange message at the time of rekeying Child SAs. This 270 SA_TS_UNCHANGED notification MUST be included in a CREATE_CHILD_SA 271 exchange message when there is no SA and TS payloads included. The 272 new Child SA is created with the SPI value in the SA_TS_UNCHANGED 273 notification. 275 3.3.1. Rekeying Child SAs When No Change of Initiator and Responder's 276 Cryptographic Suites and ACL Configuration 278 At the time of rekeying Child SAs, the initiator MAY send the 279 SA_TS_UNCHANGED notification payload instead of the SA and TS 280 payloads when there is no change in its cryptographic suites and ACL 281 configuration since last negotiation. After receiving the 282 initiator's request message with the SA_TS_UNCHANGED notification, 283 the responder MAY respond to the initiator with the SA_TS_UNCHANGED 284 notification payload instead of the SA and TS payloads if there is 285 also no change in its cryptographic suites and ACL configuration 286 since last negotiation. 288 The CREATE_CHILD_SA message exchange in this case is shown below: 290 Initiator Responder 291 -------------------------------------------------------------------- 292 HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED), 293 Ni, [KEi,]} --> 294 <-- HDR, SK {N(SA_TS_UNCHANGED), 295 Nr, [KEr,]} 297 3.3.2. Rekeying Child SAs When Initiator's Cryptographic Suites or ACL 298 Configuration Changed 300 At the time of or before rekeying Child SAs, the initiator's 301 cryptographic suites or ACL configuration may be changed while there 302 is no change of responder's cryptographic suites and ACL 303 configuration. 305 In this situation, the initiator MUST send the SA and TS payloads in 306 the CREATE_CHILD_SA request message at the time of rekeying Child 307 SAs. 309 If the responder selects a different cryptographic suite or different 310 Traffic Selectors than which were previously negotiated, then the 311 rekeying MUST be conducted in the original way defined in [RFC7296], 312 the responder sends the SA payloads with the selected cryptographic 313 suite and the TS payloads in the CREATE_CHILD_SA response message. 315 If the responder selects the previously negotiated cryptographic 316 suite and Traffic Selectors to rekey the Child SA, it MAY send the 317 SA_TS_UNCHANGED notification payload instead of the SA and TS 318 payloads in the CREATE_CHILD_SA response message, and the initiator 319 MUST use the cryptographic suite and Traffic Selectors negotiated 320 previously to create the new Child SA. The CREATE_CHILD_SA message 321 exchange in this case is shown below: 323 Initiator Responder 324 -------------------------------------------------------------------- 325 HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] 326 TSi, TSr} --> 327 <-- HDR, SK {N(SA_TS_UNCHANGED), 328 Nr, KEr} 330 3.3.3. Rekeying Child SAs When Responder's Cryptographic Suites or ACL 331 Configuration Changed 333 At the time of or before rekeying Child SAs, the responder's 334 cryptographic suites or ACL configuration may be changed while there 335 is no change of initiator's cryptographic suites and ACL 336 configuration. 338 In this situation, the initiator MAY send the SA_TS_UNCHANGED 339 notification payload instead of the SA and TS payloads in the 340 CREATE_CHILD_SA request message at the time of rekeying Child SAs. 342 If the responder decides to continue using the previously negotiated 343 cryptographic suite and Traffic Selectors to rekey the Child SA, it 344 MAY send the SA_TS_UNCHANGED notification payload in the 345 CREATE_CHILD_SA response message, then the rekeying is conducted like 346 Section 3.3.1. 348 If the responder decides to re-negotiate the cryptographic suite or 349 Traffic Selectors, it MUST send NO_PROPOSAL_CHOSEN notification 350 payload in the CREATE_CHILD_SA response message. After receiving 351 this error notification, the initiator MUST retry the CREATE_CHILD_SA 352 exchange with the SA and TS payloads. Then the rekeying is conducted 353 in the original way defined in [RFC7296]. The CREATE_CHILD_SA 354 message exchange in this case is shown below: 356 Initiator Responder 357 -------------------------------------------------------------------- 358 HDR, SK {N(SA_TS_UNCHANGED), Ni, KEi} --> 359 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), 360 Nr, KEr} 361 HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] 362 TSi, TSr} --> 363 <-- HDR, SK {SA, Nr, [KEr,] 364 TSi, TSr} 366 4. Payload Formats 368 4.1. MINIMAL_REKEY_SUPPORTED Notification 370 The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and 371 responder to inform their ability of optimizing optional payload at 372 the time of rekeying IKE SAs and Child SAs to the peers. It is 373 formatted as follows: 375 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Next Payload |C| RESERVED | Payload Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 o Protocol ID (1 octet) - MUST be 0. 385 o SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 387 o Notify Message Type (2 octets) - MUST be , the value assigned for the MINIMAL_REKEY_SUPPORTED 389 notification. 391 This notification contains no data. 393 4.2. SA_UNCHANGED Notification 395 The SA_UNCHANGED notification is used to replace the SA payloads at 396 the time of rekeying IKE SAs when there is no change of cryptographic 397 suites in initiator or responder. It is formatted as follows: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Next Payload |C| RESERVED | Payload Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |Protocol ID | SPI Size (=8) | Notify Message Type | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Security Parameter Index (SPI) | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 o Protocol ID (1 octet) - MUST be 1. 412 o SPI Size (1 octet) - MUST be 8. 414 o Notify Message Type (2 octets) - MUST be , the value assigned for the SA_UNCHANGED notification. 417 o SPI (8 octets) - Security Parameter Index. The initiator sends 418 initiator SPI. The responder sends responder SPI. 420 4.3. SA_TS_UNCHANGED Notification 422 The SA_TS_UNCHANGED notification is used to replace the SA payloads 423 and TS payloads at the time of rekeying Child SAs when there is no 424 change of cryptographic suites and ACL configuration in initiator or 425 responder. It is formatted as follows: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Next Payload |C| RESERVED | Payload Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 |Protocol ID | SPI Size (=4) | Notify Message Type | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Security Parameter Index (SPI) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 o Protocol ID (1 octet) - MUST be either (2) to indicate AH or (3) 438 to indicate ESP. 440 o SPI Size (1 octet) - MUST be 4. 442 o Notify Message Type (2 octets) - MUST be , the value assigned for the SA_TS_UNCHANGED notification. 445 o SPI (4 octets) - Security Parameter Index. The initiator sends 446 initiator SPI. The responder sends responder SPI. 448 5. IANA Considerations 450 This document defines two new Notify Message Types in the "IKEv2 451 Notify Message Types - Status Types" registry. IANA is requested to 452 assign codepoints in this registry. 454 NOTIFY messages: status types Value 455 ---------------------------------------------------------- 456 MINIMAL_REKEY_SUPPORTED TBD 457 SA_UNCHANGED TBD 458 SA_TS_UNCHANGED TBD 460 6. Security Considerations 462 TBD 464 7. References 466 7.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 474 Kivinen, "Internet Key Exchange Protocol Version 2 475 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 476 2014, . 478 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 479 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 480 May 2017, . 482 7.2. Informative References 484 [I-D.mglt-6lo-diet-esp-requirements] 485 Migault, D., Guggemos, T., and C. Bormann, "Requirements 486 for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt- 487 6lo-diet-esp-requirements-02 (work in progress), July 488 2016. 490 Authors' Addresses 492 Sandeep Kampati 493 Huawei Technologies 494 Divyashree Techno Park, Whitefield 495 Bangalore, Karnataka 560066 496 India 498 Email: sandeepkampati@huawei.com 500 Meduri S S Bharath 501 Huawei Technologies 502 Divyashree Techno Park, Whitefield 503 Bangalore, Karnataka 560066 504 India 506 Email: MeduriS.Bharath@huawei.com 508 Wei Pan 509 Huawei Technologies 510 101 Software Avenue, Yuhuatai District 511 Nanjing, Jiangsu 512 China 514 Email: william.panwei@huawei.com