idnits 2.17.1 draft-agv-sfc-packet-loss-measurement-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SFC-PM-arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2016) is 2856 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: 'RFC2119' is mentioned on line 116, but not defined == Missing Reference: 'P' is mentioned on line 429, but not defined == Missing Reference: 'M' is mentioned on line 429, but not defined == Missing Reference: 'W' is mentioned on line 429, but not defined == Missing Reference: 'I-D quinn-sfc-nsh-tlv' is mentioned on line 363, but not defined == Unused Reference: 'RFC2784' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC7498' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'SFC-arch' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'SFC-PM-Delay' is defined on line 483, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Working Group Anil Kumar S N 3 INTERNET-DRAFT Gaurav Agrawal 4 Intended Status: Standards Track Vinod Kumar S 5 Expires: December 30, 2016 Huawei Technologies India 6 June 28, 2016 8 Packet Loss Measurement for SFC 9 draft-agv-sfc-packet-loss-measurement-01 11 Abstract 13 This document describes performance measurement(PM) packet loss 14 measurement for Service Function Chains (SFCs) to assess the 15 operational status and behavior of a SF, a subset of SFs, a whole SFC 16 as a function of the actual deterministic SF/SFC. Packet loss 17 mechanism described in this document is based on [SFC-PM-arch] 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 30, 2016 36 Copyright and License Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2 Terms & Definition . . . . . . . . . . . . . . . . . . . . . 4 56 1.3 Applicability and Scope . . . . . . . . . . . . . . . . . . 4 57 2 Massage Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1 Performance Measurement Context Header . . . . . . . . . . . 5 59 2.2 Packet Loss PM Context Header . . . . . . . . . . . . . . . 6 60 2.3 Performance Measurement Flow ID . . . . . . . . . . . . . . 8 61 3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1 Packet Loss Statistics Counter . . . . . . . . . . . . . . . 9 63 3.2 Initiating a Packet Loss Measurement . . . . . . . . . . . . 9 64 3.3 Encapsulation of Classified Packets . . . . . . . . . . . . 10 65 3.4 Incoming Packets Processing at MA . . . . . . . . . . . . . 10 66 3.5 Outgoing Packets Processing at MA . . . . . . . . . . . . . 11 67 3.6 MA Reporting the statistics to Collector . . . . . . . . . . 11 68 3.7 Packet Loss Calculation at Collector . . . . . . . . . . . . 11 69 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 70 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1 TLV Class . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 74 7.2 Informative References . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1 Introduction 79 The delivery of end-to-end services often requires various service 80 functions. These include traditional network service functions such 81 as firewalls and traditional IP Network Address Translators (NATs), 82 as well as application-specific functions. The definition and 83 instantiation of an ordered set of service functions and subsequent 84 "steering" of traffic through them is termed Service Function 85 Chaining (SFC). 87 The common reasons for packet drop are traffic congestion, service 88 function (DPI/Firewall/Router etc.) performance issue, software 89 issues (bugs), faulty hardware or cabling and service function 90 processing errors. 92 Proper operation of a SFC depends on the ability to monitor and 93 quickly identify faults and focus attention on the root cause of the 94 problem. Also service provider service level agreements (SLAs) 95 depends on the capability to measure and monitor performance metrics 96 for packet delay. SFC delay measurement is one of the important tool 97 to achieve above requirements. 99 Packet loss measurement capability provides operators with greater 100 visibility into the performance characteristics of their networks, 101 thereby facilitating planning, troubleshooting, and network 102 performance evaluation. 104 This document specifies best possible efficient and accurate 105 mechanism for packet loss measurement for service function chains 106 (SFCs) for a SFC network domain. 108 The packet loss measurement described in this document is realized by 109 adding a new context header in the network service header. 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 1.2 Terms & Definition 119 Refer to RFC 7665 for definitions of SFC terms. 121 Measurement Collector: An operational function that collects 122 measurement data from a measurement agent. Measurement 123 collector is responsible for collecting the performance 124 measurement data from measurement agent. Measurement 125 collector functionality could be integrated with one of 126 the MA or with the controller itself. 128 Measurement Agent: An operational function that contains one or 129 more measurement functions. Measurement agents is 130 responsible for understand and analyze performance 131 measurement control information encoded in NSH metadata 132 and perform the performance data collecting and report the 133 same to measurement collector with key information to 134 identify performance measurement instance along with data 135 collected. 137 Measurement Controller: An operational function that controls 138 running, scheduling, and general coordination of measurement 139 functions by instructing a measurement agent using NSH 140 metadata. Measurement controller is responsible for 141 configuring the performance measurement instance. 142 Optionally performance measurement instance can be 143 configured manually at the ingress in which case 144 controller is not required 146 1.3 Applicability and Scope 148 This document defines the implementation mechanism for the packet 149 loss measurement as per performance measurement architecture [SFC-PM- 150 arch]. This document defines a new NSH message format for carrying 151 packet loss measurement related control information. It also defines 152 operations to be carried out for packet loss measurement. 153 communication mechanism between measurement controller, measurement 154 collector and MA is out of scope of this document. 156 2 Massage Format 158 2.1 Performance Measurement Context Header 160 The format of the Performance measurement context headers, is as 161 described below. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | TLV Class = (IANA PM Class) |C| PM Type |R|R|R| Len | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | PM Metadata | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: Performance Measurement Context Header 173 TLV Class: As per [I-D.ietf-sfc-nsh] the TLV class value for 174 performance measurement needs to be applied from IANA. 176 PM Type: indicates the type of performance measurement that 177 needs to be carried out by the MA. 179 Length: Length of the variable PM metadata, in 4-byte words. 181 2.2 Packet Loss PM Context Header 183 The format of the packet loss PM context headers, is as 184 described below. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | TLV Class = (IANA PM Class) |C| PM Type |R|R|R| Len | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Measurement Window Index | Reserved | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | MA Identifier1 | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 ~ ~ 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | MA IdentifierN | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: Packet Loss PM Context Header 207 TLV Class: As per [I-D.ietf-sfc-nsh] the TLV class value for 208 performance measurement needs to be applied from IANA. 210 PM Type: Indicates the type of performance measurement that needs 211 to be carried out by the MA. (IANA assigned PM Type PM Loss value) 213 This memo defines the following values. 214 0x1 - Packet Loss : indicates PM meta data contains info for 215 packet loss. Specified SF(s) SHOULD participate in packet loss PM. 217 0x2 - SF Hop by Hop Packet Loss : indicates PM meta data 218 contains info for packet loss. All the SF(s) in the SFP SHOULD 219 participate in the packet loss PM 221 0x3 - SFF Hop by Hop Packet Loss : indicates PM meta data contains 222 info for packet loss. All the SFF(s) in the SFP SHOULD participate 223 in the packet loss PM 225 0x4 - All Hop by Hop Packet Loss : indicates PM meta data contains 226 info for packet loss. All the SF(s) and SFF(s)in the SFP SHOULD 227 participate in the packet loss PM 228 0x5 - SFP as a whole : indicates PM meta data contains information 229 for packet delay. Classifier (source MA) and SF domain boundary SFF 230 (sink MA) SHOULD participate in the packet delay computation. 232 Additional values can be added for future PM types and scenarios. 234 Length: Length of the variable PM metadata, in 4-byte words. It will 235 have a minimum length of 1 indicating the presence of measurement 236 window index. 238 Measurement Window Index: 16 bit number to denote the current 239 measurement window to which the packet belongs. 241 Reserved: Reserved 16 bits for future purpose. 243 Reserved: Reserved 16 bits for future purpose. 244 MA identifier list: List of participating MA in the SFP. 246 MA identifier has two parts 247 1) Node identifier - 24 bit 248 a) For SFF: MUST be unique number assigned by controller 249 b) For SF: All zero. Context identifier itself identifies 250 SF node. 251 2) Context identifier - 8 bit 252 a) For SFF: Service index of next SF. 253 b) For SF: Service index 255 MA identifier SHOULD be in decreasing order of the SI for 256 optimized traversal of the SI participation. 258 The Length of the packet loss PM context headers, is fixed to 1 as 259 described below, when the PM Type is 2 to 5. Since all SF's in the 260 SFP has to perform the loss measurement specified in PM type field. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | TLV Class = (IANA PM Class) |C| Type 2to5 |R|R|R| Len=0x1 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Measurement Window Index | Reserved | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 2.3 Performance Measurement Flow ID 272 The method of encoding the PMF id is done using the flow id defined 273 in [I-D.ietf-sfc-nsh]. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | TLV Class = 0x0 |C| Type=0x7 |R|R|R| L=0x1 | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Performance Measurement Flow ID | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Sample encoding of PMF using flow ID 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Service Path ID | Service Index | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | TLV Class=IANA |C| Type=0x2 |R|R|R| Len | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Measurement Window Index | Reserved | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | TLV Class = 0x0 |C| Type=0x7 |R|R|R| L=0x1 | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Performance Measurement Flow ID | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 3 Operations 303 3.1 Packet Loss Statistics Counter 305 Every MA needs to maintain the packet loss statistics which they 306 immediately report it to collector or may accumulate and report to 307 collector at a reporting interval which depends on local policy. 309 Below 2 packet statistics counters will be created and maintained at 310 every MA 312 1) Rx-STAT[P][M][W] 314 2) Tx-STAT[P][M][W] 316 Rx-STAT[P][M][W]: This 2 dimensional statistics counter is maintained 317 at every MA. Where P stands for PMF ID, M stands for MA identifier 318 and W stands for window ID. Rx- STAT[P][M][W] counter maintains the 319 number of packets received for a given PMF ID + MA identifier + 320 window. PMF ID is unique within a SFC Domain, for a given PMF ID 321 there could be multiple windows. Rx-STAT[P][M][W] statistics counter 322 is created when first PM packet for loss measurement is received for 323 PMF ID + MA identifier + window within a Reporting interval. Rx- 324 STAT[P][M][W] statistics counter is deleted at expiry of current 325 reporting interval after Rx-STAT[P][M][W] statistics counters are 326 reported to collector. 328 Tx-STAT[P][M][W]: This 2 dimensional statistics counter is maintained 329 at every MA. Where P stands for PMF ID and W stands for window ID. 330 Tx- STAT[P][M][W] counter maintains the number of packets sent out 331 for a given PMF ID + MA identifier + window. PMF ID is unique within 332 a SFC Domain, for a given PMF ID there could be multiple Windows. Tx- 333 STAT[P][M][W] statistics counter is created when first PM packet for 334 loss measurement is sent for PMF ID + MA identifier + window within a 335 Reporting interval. Rx-STAT[P][M][W] statistics counter is deleted at 336 expiry of current reporting interval after Tx-STAT[P][M][W] 337 statistics counters are reported to collector. 339 3.2 Initiating a Packet Loss Measurement 341 Measurement Controller programs the PM Instance at the classifier. 342 Classifier starts the packet classification (based on the 343 classification rule/policy). The packet classification policy may be 344 customer/network/service specific. Classifier updates/encodes 345 corresponding PM instance for classified packets for each PM schedule 346 in PM context header. 348 3.3 Encapsulation of Classified Packets 350 For the classified packet, PM Context Header is prepared with 351 following information 353 - Set the type class value to the IANA allocated PM class. 354 - Set the type value to the required packet loss measurement type. 355 - If type value = 0x1 356 o Encode the list of MA identifier that need to participate in 357 Packet Loss Measurement. 358 - If Value = 0x2, 0x3, 0x4, 0x5 359 o No need to encode MA identifier, since the type dictates the 360 involved participating MA 361 - Set the window identifier as the current running window number 362 - Encode the 32 bit globally unique PMF ID using the flow ID 363 context header as defined in [I-D quinn-sfc-nsh-tlv]. 365 3.4 Incoming Packets Processing at MA 367 On receiving the packet with NSH header following operations are 368 carried out: 370 Step 1: Detection of PM context header in a packet, by verifying 371 the PM TLV class as allocated by IANA. 372 (If not detected, move to step 6) 374 Step 2: Check if PM type field value is 1 to 5. 375 (If not move to step 6). 377 Step 3: If PM type value = 2 to 5 move directly to Step 5 379 Step 4: Check presence of self MA identifier in MA identifier List. 380 (If not present, move to step 6) 382 Step 5: Record the value of PMF ID and window ID; increment the value 383 of statistics counter Rx-STAT[P][M][W] by 1. If statistics 384 counter doesn't exist, create it and initialize it with 1. 386 Step 6: Packet is sent for normal processing 388 3.5 Outgoing Packets Processing at MA 390 At outgoing port of MA following operations are carried out. 392 Step 1: Record the value of PMF ID and window ID; increment the value 393 of statistics counter Tx-STAT[P][M][W] by 1. If statistics 394 counter doesn't exist, create it and initialize it with 1. 396 Step 2: Packet is sent for normal processing 398 3.6 MA Reporting the statistics to Collector 400 Reporting timer will run on Each MA. Consistency of this timer 401 should be ensured across the entire MA in the SFP, ensuring the 402 same is out of scope of this document. 404 On expiry of this timer following information needs to be sent 405 to the Collector. 407 - MA identifier 408 - PM Type Value 409 - Value of all the accumulated Tx-STAT[P][M][W] statistics 410 counter along with the corresponding PMF ID and Window Id 411 - Value of all the accumulated Rx-STAT[P][M][W] statistics counter 412 along with the corresponding PMF ID and window Id 414 MA may delete the Tx-STAT[P][M][W], Rx-STAT[P][M][W] after sending 415 the same to collector. 417 3.7 Packet Loss Calculation at Collector 419 Collector accumulates the statistics counters per PMF per MA 420 identifier per MA per window. On receipt of report from a MA for a 421 PMF if it has statistics related for an already collected window, 422 received statistics will be summed up, otherwise a new entry is 423 created. Collector computes the packet loss using the accumulated 424 statistics per PMF per MA per window. 426 Packet Loss between MA (for example from MA1 to MA2) = (MA1)Tx- 427 STAT[P][M][W] - (MA2)Rx-STAT[P][M][W] 429 Packet Loss at MA = (MA)Tx-STAT[P][M][W] - (MA)Rx-STAT[P][M][W] 431 4 Security Considerations 433 No specific security considerations for this document 435 5 IANA Considerations 437 5.1 TLV Class 439 IANA is requested to allocate a new class value for performance 440 measurement from "Network Service Header (NSH) Parameters" registry. 442 Value Description Reference 443 ----- ----------- --------- 444 New Performance Measurement [SFC-PM-arch] 446 6. Acknowledgments 447 We would like to thank Nobin Mathew for his review and comments. 449 7 References 451 7.1 Normative References 453 [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service 454 Header", draft- ietf-sfc-nsh-01 (work in progress), July 455 2015. 457 7.2 Informative References 459 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 460 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784 461 DOI 10.17487/RFC2784, March 2000, 462 . 464 [RFC5226] Narten, T. and H. Alvestrand,"Guidelines for Writing an 465 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 466 DOI 10.17487/RFC5226, May 2008, 467 . 469 [RFC7498] Quinn, P., Ed. and T. Nadeau,Ed.,"Problem Statement for 470 Service Function Chaining", RFC 7498, DOI 10.17487/ 471 RFC7498, April 2015, 472 . 474 [SFC-arch] 475 Quinn, P., Ed. and J. Halpern, Ed., "Service Function 476 Chaining (SFC) Architecture", 2014, 477 . 479 [SFC-PM-arch] 480 Anil, Gaurav and Vinod., "Performance Measurement 481 Architecture for SFC", 2015, 483 [SFC-PM-Delay] 484 Anil, Gaurav and Vinod., "Packet Delay Measurement for 485 SFC", 2015, 487 Authors' Addresses 489 Anil Kumar S N 490 Huawei Technologies India Pvt. Ltd, 491 Near EPIP Industrial Area, 492 Kundalahalli Village, 493 Whitefield, 494 Bangalore - 560037 496 EMail: anil.sn@huawei.com 498 Gaurav Agrawal 499 Huawei Technologies India Pvt. Ltd, 500 Near EPIP Industrial Area, 501 Kundalahalli Village, 502 Whitefield, 503 Bangalore - 560037 505 EMail: gaurav.agrawal@huawei.com 507 Vinod Kumar S 508 Huawei Technologies India Pvt. Ltd, 509 Near EPIP Industrial Area, 510 Kundalahalli Village, 511 Whitefield, 512 Bangalore - 560037 514 EMail: vinods.kumar@huawei.com