idnits 2.17.00 (12 Aug 2021) /tmp/idnits30065/draft-dunbar-sfc-path-control-00.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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 453 has weird spacing: '... the direc...' == Line 457 has weird spacing: '... along the ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2014) is 2766 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: 'SRC-arch' is mentioned on line 113, but not defined == Missing Reference: 'SFC-arch' is mentioned on line 337, but not defined == Missing Reference: 'SFF-sequence' is mentioned on line 193, but not defined == Missing Reference: 'SFF-SF-sequence' is mentioned on line 194, but not defined == Outdated reference: draft-ietf-sfc-problem-statement has been published as RFC 7498 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SFC working group L. Dunbar 2 Internet Draft A. Malis 3 Intended status: Standard Track Huawei 4 Expires: April 2015 6 October 24, 2014 8 Framework for Service Function Path Control 9 draft-dunbar-sfc-path-control-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be modified, 18 and derivative works of it may not be created, except to publish it 19 as an RFC and to translate it into languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on April 27, 2009. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 This draft describes the framework of protection and restoration of 57 Service Function Path when some service functions on the path fail 58 or need to be replaced. 60 Table of Contents 62 1. Introduction...................................................3 63 2. Conventions used in this document..............................3 64 3. Terminology....................................................3 65 4. Background.....................................................4 66 4.1. Multiple Entities of one Service Function.................4 67 4.2. Rendered Service Path (RSP)...............................5 68 4.2.1. SFF-sequence and SFF-SF-sequence representation......5 69 4.3. Multiple ways of Controlling RSP..........................6 70 4.4. Impact of Virtualized Service Functions to SFP............8 71 5. Local Restoration of Service Functions.........................8 72 6. Global Restoration of Service functions.......................10 73 6.1. Encoding the Exact SFF-SF-sequence in Data Packets.......10 74 6.2. Dynamic establishment of an RSP..........................11 75 6.3. Out-Of-Band Signaling of changes on SFP..................12 76 6.4. Hybrid Method............................................12 77 7. Regional Restoration of Service Function......................12 78 8. Conclusion and Recommendation.................................13 79 9. Manageability Considerations..................................13 80 10. Security Considerations......................................13 81 11. IANA Considerations..........................................13 82 12. References...................................................13 83 12.1. Normative References....................................13 84 12.2. Informative References..................................14 85 13. Acknowledgments..............................................14 87 1. Introduction 89 This draft describes the framework for protection and restoration of 90 a Service Function Path (SFP) when some functions on the path fail 91 or need to be replaced. 93 Protection and restoration become more crucial in virtualized 94 environments (e.g. ETSI NFV), where service functions are 95 instantiated as VMs on servers. There is higher chance of state 96 changes for those Service functions as the result of being 97 decommissioned or replaced when over-utilized. 99 2. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC-2119 [RFC2119]. 105 In this document, these words will appear with that interpretation 106 only when in ALL CAPS. Lower case uses of these words are not to be 107 interpreted as carrying RFC-2119 significance. 109 3. Terminology 111 This draft uses the following terminologies defined by SFC-arch. 113 RSP: Rendered Service Path [SRC-arch] 115 SF: Service Function [SFC-arch]. 117 SFC: Service Function Chain [SFC-arch]. 119 SFF: Service Function Forwarder [SFC-arch]. 121 SFP: Service Function Path [SFC-arch]. 123 Here are the terminologies specific for this draft: 125 VSFI: SFC Visible Service Function Instance. 127 SFIC: Service Function Instance Component. One service 128 function (e.g. NAT44) could have two different service function 129 instantiations, one that applies policy-set-A (NAT44-A) and other 130 that applies policy-set-B (NAT44-B). There could be multiple 131 "entities" of NAT44-B (e.g. one "entity" only has 10G capability), 132 and many "entities" of NAT44-B. Each entity has its own unique 133 address. The "entity" in this context is called "Service Function 134 Instance Component" (SFIC). 136 Service Chain: The sequence of service functions, e.g. Chain#1 137 {s1, s4, s6}, Chain#2{s4, s7} at functional level. Also see the 138 definition of "Service Function Chain" in [SFC-Problem]. 140 Service Chain Instance Path: The actual Service Function Instance 141 Components selected for a service chain. 143 VNF: Virtualized Network Function [NFV-Terminology]. 145 4. Background 147 4.1. Multiple Entities of one Service Function 149 One service function (say, NAT44) could have two different service 150 function instantiations, one that applies to policy-set-A (NAT44-A) 151 and other that applies to policy-set-B (NAT44-B). There could be 152 multiple "entities" of NAT44-A (e.g. one "entity" only has 10G 153 capability), and many "entities" of NAT44-B. Each entity has its own 154 unique address (or Locator in [SFC-Reduction]). The "Entity" in this 155 context is called "Service Function Instance Component" (SFIC). 157 Identical SFICs could be attached to different Service Function 158 Forwarder (SFF) nodes. It is also possible to have multiple 159 identical SFICs attached to one Service Function Forwarder (SFF) 160 node, especially in a Network Function Virtualization (NFV) 161 environment where each SFIC is a virtual service function with 162 limited capacity. 164 At the functional level, the order of service functions, e.g. 165 Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often 166 which SFIC of the Service Function "s1" is selected for the Chain #1 167 is not. 169 Some SFICs are visible to Service Chain Path. Sometimes a collection 170 of SFICs can appear as one single entity to the Service Chain Path. 171 When multiple SFICs are attached to one SFF, the collection of all 172 those SFICs can appear as a single Service Function to the Service 173 Chain Path. As described in Section 5.5 of [SFC-arch], the SFF can 174 make local decision in choosing the SFIC among the collection of 175 directly attached identical SFICs. The individual SFIC in this 176 collection doesn't have to be visible to the SFP, the classifier, or 177 orchestration. 179 It is also possible that multiple SFICs of one service function can 180 be reached by different SFF nodes as depicted by Figure 5 of [SFC- 181 arch]. 183 For the ease of description, the term "Service Function Instance" is 184 used in this draft to represent the identical SFICs that are visible 185 to the SFP, e.g. the SFICs attached to different SFFs. 187 4.2. Rendered Service Path (RSP) 189 [SFC-arch] defines RSP as the constrained specification of where 190 packets using a certain service chain must go. 192 RSP can be logically represented by an ordered sequence of SFF nodes 193 [SFF-sequence] and an ordered sequence of SFs on each SFF of the 194 list [SFF-SF-sequence]. 196 RSP can also be SF-sequence without specifying which SFFs for the 197 SFs. 199 The SFF-SF-sequence can be explicitly encoded in the SFC header for 200 the SFP, or can be passed down, as "traffic steering policies", to 201 the relevant SFF nodes. 203 4.2.1. SFF-sequence and SFF-SF-sequence representation 205 Logically, the SFF-sequence is represented by the list of SFF nodes 206 on the SFP. For a Chain sf2 -> sf3 -> sf4 in the Figure 5 of SFC- 207 arch (with some minor changes), suppose the RSP is sf2 & sf3 at sff- 208 a; sf4 at SFF-c, then the SFF-sequence is [sff-a -> sff-c]. The SFF- 209 SF-sequence is (sff-a: sf2->sf3)-> (sff-c: sf4). 211 The SFF-sequence and/or SFF-SF-sequence, e.g. {sff-a, sff-c}, can be 212 explicitly encoded in the SFC header for the SFP. 214 Alternatively, the SFF-sequence and/or SFF-SF-sequence can be passed 215 down, as "traffic steering policies", to the "sff-a" and "sff-c" 216 nodes for the SFP. The traffic steering policies can be represented 217 as "matching" & "action". 219 +---+ +---+ +---+ +---+ +---+ +---+ 220 |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| 221 +---+ +---+ +---+ +---+ +---+ +---+ 222 | | | | | | 223 +-----+-----+ +-----+-----+ 224 | | 225 + + 226 +----+ +-----+ +-----+ +-----+ +-----+ 227 source+-->|sffx|+-->|sff-a|+->|sff-b|+-->|sff-c|+-->|sff-d|+-->destination 228 +----+ +-----+ +-----+ +-----+ +-----+ 229 + + + 230 | | | 231 +---+ +---+ +---+ 232 |sf1| |sf4| |sf3| 233 +---+ +---+ +---+ 234 Figure 1:Framework of Service Function Path 236 Suppose the SFC ID for this SFP is "yellow", the policy to "sff-a" 237 can be: 239 Matching | Action 240 --------------------------------------+------------------------- 241 SFC ID="yellow"& ingress = sffx-port | next-hop: "sf2" 243 SFC ID = "yellow" & ingress= sf2-port | next-hop: "sf3" 245 SFC ID = "yellow" & ingress=sf3-port | next-hop: sff-b 247 Figure 2:Traffic Steering Policy for SFF-SF-sequence 249 4.3. Multiple ways of Controlling RSP 251 How SFF-SF-sequence is selected for a given SFP to form the actual 252 RSP is outside the scope of this draft. It is assumed that there is 253 an entity (e.g. service chain orchestration system) that is 254 responsible for creating the SFF-sequence or SFF-SF-sequence for 255 SFPs. 257 This document focuses on the framework of replacing service 258 functions for a given SFP/RSP. 260 To make the description easier, the following Service Chain 261 architecture reference is used: 263 Some head end Service Chain Classifier can be configured with (or 264 has the ability to specify) the exact SFF-SF-sequence for a given 265 SFP. Some Classifier may only specify the SFF-sequence for a given 266 SFP. Some Classifier may not specify SFF-sequence for a given SFP. 268 The SFF-SF-sequence or SFF-sequence can be 270 1. encoded in SFC header of every data packet; 271 2. Dynamic establishment of SFF-SF-sequence based on SF-Sequence; 272 3. sent as out-of-band control messages to all the relevant nodes 273 to install the appropriate flow steering policies; or 274 4. dynamically programmed into each node by a centralized network 275 controller or by a network management system (as I2RS). 277 The benefit of encoding the exact path in every data packet has less 278 contention when there is change of RSP. 280 The approach 2), 3), and 4) above are more appropriate for RSPs that 281 don't change frequently and for large flows. 283 For the approach 1) above, all the forwarding nodes, e.g. SFFs, need 284 to look up the SFF-sequence or SFF-SF-sequence for every packet to 285 determine the next hop. For large flows, i.e. large number of 286 packets in the flow, the processing of interpreting the SFF- 287 sequence/SFF-SF-sequence is repetitive and can be resource 288 intensive. 290 When the exact SFF-SF-sequence is specified by the Classifier node, 291 any state change of SFP visible SFICs need to be propagated to the 292 Classifier node. 294 When the in-band or out-of-band signaling methods are used, i.e. 295 sending flow steering policies to relevant SFF nodes or network 296 nodes, the packets associated with the SFP don't need to carry the 297 SFF-SF-sequence or SFF-sequence. The forwarding nodes, e.g. SFFs, can 298 establish the proper forwarding based on the signaling. So they don't 299 need to interpret the sequence carried by each packet. Forwarding can 300 be more efficient. 302 The out-of-band method doesn't even require the head end Service 303 Chain Classifier to be configured with, nor has the capability to 304 specify, the exact RSP. The out-of-band steering policies can be sent 305 from an external entity, such as a centralized network controller or 306 service chain orchestration system. Under this scenario, it doesn't 307 require the head end Chain Classifier node to be aware of any change 308 on the RSP. 310 There are times that it might not be feasible for the head end 311 Service Chain Classifier to be notified of the changes of SFF- 312 sequence or SFF-SF-Sequence for a given SFP because of the time 313 taken for the notification and the limited capability of the 314 Classifier nodes. 316 If each Service Function has a large number of SFICs, it scales 317 better if the Classifier node doesn't need to be notified with 318 status of SFICs on a SFP. 320 4.4. Impact of Virtualized Service Functions to SFP 322 When a SFP consists of virtualized service functions, e.g. in an 323 ETSI NFV environment, the likelihood of changes to the corresponding 324 RSP can be higher due to: 326 - Higher failure rate of virtualized service functions because 327 most of them will not have build-in protection mechanism 328 - When a virtualized function is over-utilized, it is relatively 329 easy to replace it by another one (SFIC) or instantiate more 330 SFICs to take over the work load. 332 5. Local Restoration of Service Functions 334 When one SF Forwarder (SFF) node has multiple Service Function 335 Instance Components (SFICs) of the same service function attached, 336 the SFF can make a local decision on which SFIC is selected for a a 337 given SFP, as described in Section 5.5 of [SFC-arch]. 339 E.g. In the diagram below, The SF Forwarder (SFF) "A" has two 340 instances of Service Function #7(SF7-1 & SF7-2), and 3 instances of 341 Service Function #2 (SF2-2, SF2-4, SF2-5). 343 +----+ +---+ +---+ +---+ 344 | SF2| |SF2| |SF2| |SFx| 345 | -2 | |-4 | |-5 | |-1 | 346 +----+ +---+ +---+ +---+ 347 | | | | 348 +------+-------+-------+ 349 | 350 +----+ +---+ | +---+ +---+ 351 | SF7| |SF7| | |SF5| |SF5| 352 | -1 | |-2 | | |-2 | |-4 | 353 +----+ +---+ | +---+ +---+ 354 : / / / 355 : / / /-----/ 356 \ / / / 357 +--------------+ +---------- +----+ 358 -- >| Chain |-- | SFF |------| SFF| ----> 359 |classifier | | A | | C | 360 +--------------+ +----------+ +----+ 362 Figure 3:Local Restoration of Service Functions 364 For a service function chain that consists of "Service Function #7" 365 followed by "Service Function #2", which is represented by SF7->SF2, 366 the steering policy to SFF "A" could be simply SF7->SF2 without 367 specifying which components of SF7 & SF2 are selected. In order for 368 a SFF node to make local decision to choose one of the identical 369 SFICs for a service function, the SFF node has to be aware of the 370 SFICs for a given function on the SFP. The SFF node can be notified 371 or configured with such information: 373 SF7 == {Port# for SF7-1, Port# for SF7-3} 375 SF2 == {Port# for SF2-2, Port# for SF2-4, Port# SF2-5} 377 The multiple components within the {} represents the equal SFICs 378 that the SFF can select locally. 380 The local protection and restoration is relatively simple and clean. 381 ECMP can be used to balance all the available SFICs attached 382 locally. 384 6. Global Restoration of Service functions 386 Sometimes changing the SFP's RSP involves using SFICs at different 387 SFF nodes. 389 For a Chain sf2 -> sf3 -> sf4 in the Figure 5 of SFC-arch (with some 390 minor changes): 392 +---+ +---+ +---+ +---+ +---+ +---+ 393 |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| 394 +---+ +---+ +---+ +---+ +---+ +---+ 395 | | | | | | 396 +-----+-----+ +-----+-----+ 397 | | 398 + + 399 +---+ +-----+ +-----+ +-----+ +-----+ 400 source+-->|sff|+-->|sff-a|+->|sff-b|+-->|sff-c|+-->|sff-d|+-->dst 401 +---+ +-----+ +-----+ +-----+ +-----+ 402 + + + 403 | | | 404 +---+ +---+ +---+ 405 |sf1| |sf4| |sf3| 406 +---+ +---+ +---+ 408 Original Service Chain path: sf2 & sf3 at SFF-a; sf4 at SFF-c. 410 When the "sf3" attached to "sff-a" fails or over-utilized, the RSP 411 needs to use the sf3 attached to "sff-c". The Path becomes: 413 - sf2 at "sff-a"; sf3 & sf4 at "sff-c". 415 This section examines possible ways to achieve the restoration when 416 the change of SFP involves multiple SFF nodes. 418 6.1. Encoding the Exact SFF-SF-sequence in Data Packets 420 If the detailed SFF-SF-sequence is encoded in data packets, the SC 421 Classifier needs to be notified of the changes of the RSP. The 422 Classifier either gets notified of the exact SFF-SF-sequence from 423 external entity (e.g. controller or orchestration) or has the ability 424 reconstruct the new RSP. The later approach needs protocol for the 425 Classifier to be aware (or updated) of all the visible SFICs' states 426 and their runtime topology. 428 This method won't cause any contention issue among all the involved 429 nodes. 431 As mentioned in the previous section, encoding exact RSP path 432 requiring all involved nodes to interpret SFF-SF-sequence in each 433 packet to establish runtime forwarding policy, which can be resource 434 intensive. This approach is not optimal when the RSP doesn't change 435 very frequently, as in minutes or hours. 437 6.2. Dynamic establishment of an RSP 439 A similar method to MPLS RSVP-TE [RSVP-TE] signaling can be 440 considered to dynamically establish the SFF-SF-sequence based on the 441 SF-sequence. 443 Here is the overview of this approach. More details will be added 444 later. 446 - The external controller computes the Service Chain Instance 447 Path or Service Chain path at functional level and sent to 448 the head end classifier node. 449 - The (segment) Head end Classifier node uses "Request for 450 Path" signaling (like MPLS's RSVP) to establish the RSP to 451 the nodes that on the path. 452 - All the nodes on the path establish the SF Forwarding Rule to 453 the directly attached service functions (or the service 454 function instances), and the appropriate tunnel from the 455 egress port to the next SFF node for the given SFP. 456 - When the Path Confirmation is received (i.e. all the nodes 457 along the path have completed the SF Forwarding Rule 458 establishment and tunnel establishment), the head end can put 459 user data along the pre-established Tunnel (e.g. VxLAN). 461 The drawback of this approach is that the head end node might 462 receive packets belonging to the service function chain before all 463 the involved nodes (SFF or SF) have made the needed changes. 465 It is very similar to the issues encountered by MPLS Fast Reroute 466 [FRR]. MPLS FRR allows that packets to be dropped when a restoration 467 path is being dynamically signaled because there was not a pre- 468 established backup path. 470 6.3. Out-Of-Band Signaling of changes on SFP 472 If the out-of-band method is used, i.e. sending the updated flow 473 steering policies to indicate the changes of the SFP path, there 474 could be issues of synchronization and race conditions. For example, 475 if the SFF "A" and SFF "C" get flow steering policies at slightly 476 different times, some packets of the flow might miss some service 477 functions on the chain. 479 In SDN or SDN-like environments, changes to a SFP can be dynamically 480 programmed to relevant SFF nodes via out-of-band signal form a 481 central controller or Network Management System (as in I2RS). 483 This approach does not require using end to end signaling protocol 484 among Classier nodes and SFF nodes. But there may be problems 485 introduced (such as loops or dropped packets) if SFF nodes are not 486 updated in the proper order or not at the same time; the nodes should 487 be updated in a similar time scale to the use of a signaling 488 protocol. In addition, the network may have a single point of failure 489 if the controller or NMS is not itself redundant. 491 6.4. Hybrid Method 493 For global restoration of service functions on a SFP, it is 494 worthwhile to explore a hybrid mode, i.e. when there are changes 495 involving using identical SFICs at different SFF nodes, the SC 496 Classifier node is informed to encode the explicit SFFs for each SF 497 in the SFC header of the data packets until all the involved SFF 498 nodes complete the installation of the new steering policy for the 499 path. 501 7. Regional Restoration of Service Function 503 It might not be always be feasible for the head end Service Chain 504 Classifier to be aware of the exact SFICs selected for a given SFP 505 due to too many SFICs for each SF, notifications not being promptly 506 sent to the classifier node, or other reasons. Then Regional 507 restoration should be considered. 509 Regional restoration can take the similar approach as the Global 510 restoration: choosing a regional ingress node that can take over the 511 responsibility of installing the new steering policies to the 512 involved SFF nodes or network nodes. 514 The Regional ingress node should be: 516 - on the data path of the flow of the given service chain; 518 - in front of the relevant the SFF nodes or network nodes that 519 are impacted by the change of the Service Chain Path; 521 - capable of encoding the detailed Service Chain Path to the 522 Service Chain Header of data packets of the identified flow; 523 and 525 - capable of removing the detailed Service Chain Path encoding 526 in data packets after all the impacted SFF nodes and network 527 nodes completed the policy installation. 529 8. Conclusion and Recommendation 531 TBD 533 9. Manageability Considerations 535 TBD 537 10. Security Considerations 539 TBD 541 11. IANA Considerations 543 This document requires no IANA actions. RFC Editor: Please remove 544 this section before publication. 546 12. References 548 12.1. Normative References 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 12.2. Informative References 555 [SFC-Problem] P. Quinn, et al, "Service Function Chaining Problem 556 statement", draft-ietf-sfc-problem-statement-02, work in 557 progress, April 2014 559 [NFV-Terminology] ETSI NFV ISG, "Network Functions Virtualisation 560 (NFV); Terminology for Main Concepts in NFV", ETSI GS NFV 561 003 V1.1.1, Oct. 2013, 562 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01. 563 01_60/gs_NFV003v010101p.pdf 565 [SFC-Reduction] R. Parker, "Service Function Chaining: Chain to Path 566 Reduction", draft-parker-sfc-chain-to-path-00, work in 567 progress, Nov. 2013 569 [RSVP-TE] D. Awduche, Berger, L., Gan, D., Li, T., Srinivasan, V., 570 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 571 Tunnels", RFC 3209, December 2001. 573 [FRR] P. Pan, Swallow, G., and Atlas, A., "Fast Reroute 574 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005 576 13. Acknowledgments 578 Many thanks to Ron Bonica for the discussion in formulating the 579 content for the draft. 581 This document was prepared using 2-Word-v2.0.template.dot. 583 Authors' Addresses 585 Linda Dunbar 586 Huawei Technologies 587 5340 Legacy Drive, Suite 175 588 Plano, TX 75024, USA 589 Phone: (469) 277 5840 590 Email: ldunbar@huawei.com 592 Andrew G. Malis 593 Huawei Technologies 594 USA 595 Email: agmalis@gmail.com