idnits 2.17.1 draft-bashandy-idr-bgp-repair-label-04.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1, 2012) is 4371 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) ** Obsolete normative reference: RFC 3107 (ref. '4') (Obsoleted by RFC 8277) == Outdated reference: A later version (-05) exists of draft-ietf-idr-best-external-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Bashandy 2 Internet Draft B. Pithawala 3 Intended status: Standards Track Cisco Systems 4 Expires: October 2012 Jakob Heitz 5 Ericsson 6 May 1, 2012 8 Scalable, Loop-Free BGP FRR using Repair Label 9 draft-bashandy-idr-bgp-repair-label-04.txt 11 Abstract 13 Consider a BGP free core scenario. Suppose the provider edge BGP 14 speakers PE1, PE2,..., PEn know about a prefix P/m via the external 15 routers CE1, CE2,..., CEm. If the PE router PEi loses connectivity to 16 the primary path, it is desirable to immediately restore traffic by 17 rerouting packets arriving from the core to PEi and destined to the 18 prefix P/m to one of the other PE routers that advertised P/m, say PEj, 19 until BGP re-converges. However if the loss of connectivity of PEi to 20 the primary path also resulted in the loss of connectivity between PEj 21 and CEj, rerouting a packet before the control plane converges may 22 result in a loop. In this document, we propose using a repair label for 23 traffic restoration while avoiding loops. We propose advertising the 24 "repair" label through BGP. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 This document may contain material from IETF Documents or IETF 32 Contributions published or made publicly available before November 33 10, 2008. The person(s) controlling the copyright in some of this 34 material may not have granted the IETF Trust the right to allow 35 modifications of such material outside the IETF Standards Process. 36 Without obtaining an adequate license from the person(s) controlling 37 the copyright in such materials, this document may not be modified 38 outside the IETF Standards Process, and derivative works of it may 39 not be created outside the IETF Standards Process, except to format 40 it for publication as an RFC or to translate it into languages other 41 than English. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six 49 months and may be updated, replaced, or obsoleted by other documents 50 at any time. It is inappropriate to use Internet-Drafts as 51 reference material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 This Internet-Draft will expire on April 1, 2012. 61 Copyright Notice 63 Copyright (c) 2011 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with 71 respect to this document. Code Components extracted from this 72 document must include Simplified BSD License text as described in 73 Section 4.e of the Trust Legal Provisions and are provided without 74 warranty as described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction...................................................3 79 1.1. Conventions used in this document.........................4 80 1.2. Terminology...............................................4 81 2. Protocol Operation.............................................5 82 2.1. Control plane Operation...................................5 83 2.1.1. Additional Rules for allocating and advertising a Repair 84 label.......................................................6 85 2.2. Forwarding Plane Operation................................6 86 2.3. Example...................................................7 87 3. How to Disseminate Repair Label Information....................9 88 3.1.1. Structure of the Repair Label Path Attribute........10 89 3.1.2. Semantics of the Repair Label Attribute.............10 90 3.1.3. Additional Rule when Forwarding Advertisements 91 Containing the Repair Path Attribute.......................11 92 4. Security Considerations.......................................12 93 5. IANA Considerations...........................................12 94 6. Conclusions...................................................12 95 7. References....................................................12 96 7.1. Normative References.....................................12 97 7.2. Informative References...................................13 98 8. Acknowledgments...............................................13 100 1. Introduction 102 In a BGP free core, where traffic is tunneled between edge routers 103 and edge routers assign labels to prefixes, BGP speakers advertise 104 reachability information about prefixes and associate a local label 105 with each prefix such as L3VPN [9], 6PE [10], and Softwire [8]. 106 Suppose that a given edge router is chosen as the best next-hop for 107 a prefix P/m. An ingress router that receives a packet from an 108 external router and destined for the prefix P/m pushes the label 109 advertised by the egress edge router and then "tunnels" the packet 110 across the core to that egress router. Upon receiving the labeled 111 packet from the core, the egress router uses the label on the packet 112 to take the appropriate forwarding decision. 114 In modern networks, it is not uncommon to have a prefix reachable 115 via multiple edge routers. One example is the best external path 116 [7]. Another more common and widely deployed scenario is L3VPN [9] 117 with multi-homed VPN sites. As an example, consider the L3VPN 118 topology depicted in Figure 1. 120 +--------------------------+ 121 | | 122 | BGP free Core | 123 | | 124 | +------------------PE1----+ 125 | / | \ 126 | / | \ 127 | / | \ 128 | / | \ 129 | / | * 130 PE3 | CE....... VPN prefix 131 | \ | * (P/m) 132 | \ | / 133 | \ | / 134 | \ | / 135 | \ | / 136 | +------------------PE2----+ 137 | | 138 | | 139 +--------------------------+ 141 Figure 1 VPN prefix reachable via multiple PEs 143 PE3 is the ingress PE. PE1 and PE2 are both egress PEs connected to 144 CE. CE advertises one or more VPN prefixes, denoted by P/m. PE1 and 145 PE2 advertise P/m as VPNv4 or VPNv6 routes to all ingress PEs, 146 including PE3, and associates a label with each route. 148 Suppose that the ingress PE, PE3, chooses PE1 as the next-hop for 149 the prefix P/m. In order to minimize traffic loss, it is highly 150 desirable for PE1 to reroute all traffic destined to P/m to PE2 as 151 soon as the connectivity to CE is lost without waiting for the 152 control plane (whether it is IGP or BGP) to re-converge and compute 153 the new best path. In doing so, PE1 pushes the label advertised by 154 PE2 for the prefix P/m, and then "tunnels" the packet to PE2. 155 However if the loss of PE1-CE connectivity was due to CE crash, then 156 PE2 will also reroute the traffic back to PE1, resulting in a loop. 157 Due to ultra scalability requirements, where there is a need to 158 support thousands of peers and hundreds of thousands of prefixes, 159 there is a need to support quick traffic restoration without waiting 160 for the control plane to converge and without risking loops. 162 1.1. Conventions used in this document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC-2119 [1]. 168 In this document, these words will appear with that interpretation 169 only when in ALL CAPS. Lower case uses of these words are not to be 170 interpreted as carrying RFC-2119 significance. 172 1.2. Terminology 174 This section outlines the terms used in this document. For ease of 175 use, we will use terms similar to those used by L3VPN [9] 177 o Protected prefix: a prefix P/m (of any AFI) that a BGP speaker 178 has an external path to. The BGP speaker may learn about the 179 prefix from an external peer through BGP, some other protocol, or 180 manual configuration. The protected prefix is advertised to some 181 or all the internal peers. 183 o Primary egress PE: an IBGP peer that can reach the protected 184 prefix P/m through an external path and advertised the prefix to 185 the other IBGP peers. The primary egress PE was chosen as the 186 best path by one or more internal peers. In other words, the 187 primary egress PE is an egress PE that will normally be used when 188 there is no failure. Referring to Figure 1, PE1 is a primary 189 egress PE. 191 o CE: an external router through which an egress PE can reach a 192 prefix P/m. The router "CE" in Figure 1 is an example of such a 193 CE 195 o Ingress PE: a BGP speaker that learns about a prefix through 196 another IBGP peer and chooses that IBGP peer as the next-hop for 197 the prefix. PE3 in Figure 1 is an example of an ingress PE 199 o Repairing PE: the egress PE that attempts to restore traffic when 200 the primary path is no longer reachable "without" waiting for BGP 201 to re-converge. The repairing PE restores the traffic by 202 rerouting the traffic (through a tunnel) towards the pre- 203 calculated repair PE when it detects that the primary path is no 204 longer reachable. Referring to Figure 1, if PE3 chooses PE1 as 205 the primary egress PE and PE1 decides to reroute traffic to PE2 206 on losing reachability with CE, then PE1 is a repairing PE. 208 o Primary label: the label advertised by the primary egress PE to 209 be used for normal traffic forwarding. 211 o Repair egress PE: an egress PE other than the primary egress PE 212 that can reach the protected prefix P/m through an external 213 neighbor. The repair PE is pre-calculated via other repairing PEs 214 prior to any failure 216 o Repair label: the label that will be pushed on the packet when 217 the repairing PE reroutes the traffic (through a tunnel) towards 218 the repair egress PE. Section 2. discusses how the repair label 219 is used. Section 3. discusses semantics of and the method for 220 disseminating repair label information. 222 o Repair path: the repair egress PE and the repair label. 224 o internal and external: internal or external to the core. 226 2. Protocol Operation 228 This section explains the operation of the control and forwarding 229 planes of routers participating in BGP-free core traffic 230 restoration. 232 2.1. Control plane Operation 234 1. As usual, each PE allocates a local label for each prefix it can 235 reach through an external neighbor CE. This is the primary label 236 used for normal traffic forwarding. 238 2. To provide repair path information to all PEs, the PE also 239 allocates a repair label to the prefix if it can reach that 240 prefix via an external neighbor. Different repair label 241 allocation schemes are proposed in Section 3. . 243 3. The PE advertises both the primary and repair labels to all IBGP 244 peers. 246 4. When a PE receives the label advertisement from egress PEs, it 247 calculates a primary egress PE and a repair egress PE based on 248 its internal path selection criteria. Note that the method of 249 choosing the repair path is beyond the scope of this document. 251 5. In the end, for some of the prefixes advertised by more than one 252 PE, a PE will have 254 o a primary path 256 o a repair path consisting of a repair PE and a repair label 257 advertised by the chosen repair PE. 259 6. A PE "never" protects a repair label. Hence on any PE, a repair 260 label only has paths towards the CE. However a primary label may 261 have a repair path towards a chosen repair PE 263 2.1.1. Additional Rules for allocating and advertising a Repair label 265 o A repair PE MUST NOT advertise a repair label for a prefix if it 266 does NOT have an external path to the prefix 268 o The forwarding entry for the repair label on the repair PE MUST 269 NOT point to an internal path 271 o Repair labels SHOULD be advertised with labeled address families 272 only. That is AFI/SAFI 1/4, 2/4, 1/128, and 2/128. 274 2.2. Forwarding Plane Operation 276 This section specifies the forwarding plane operation when a PE 277 receives a packet and any of the following two conditions are true: 279 o The PE lost the primary path and has not yet calculated another 280 primary path and programmed it in the forwarding plane. 282 o The arriving packet arrived from the core and the PE does not 283 have an external path. It is noteworthy to mention that this 284 condition should be a temporary condition until all ingress PEs 285 converge and stop sending traffic to that PE. 287 The forwarding plane processes arriving traffic as follows: 289 1. If the repairing PE is an egress PE, the packet arrives at the 290 repairing PE with the primary label at the top because the packet 291 is "tunneled" from the ingress PE(s). In that case, the repairing 292 PE swaps the incoming label stack with the "repair label stack" 293 advertised by the repair egress PE. Section 3.1.2. specifies all 294 the details 296 2. The repairing PE tunnels the packet to the repair PE 298 3. At the repair PE, the packet arrives with the repair label at the 299 top. The repair PE uses the incoming label stack to take 300 forwarding decisions 302 4. If the repair egress PE can reach the CE, the repair PE forwards 303 the packet towards the CE. 305 5. If the repair PE cannot reach the CE, the traffic will be dropped 306 because a PE never protects a repair label 308 2.3. Example 310 Consider the L3VPN [9] topology depicted in Figure 2 where two PEs 311 are connected to the same PE. Assume that the core is LDP. We will 312 be using an advertised repair label. 314 PE1 315 \ 316 \ 317 \ 318 \ 319 LDP core CE....... VPN prefix 320 / (10.0.0.0/8) 321 / 322 / 323 / 324 PE2 326 Figure 2 : L3VPN Example 328 PE1: Repairing egress PE 329 PE2: repair PE 330 Primary VPN label advertised by PE1 to all PEs: 4000 331 Repair VPN label advertised by PE1 to all PEs: 5000 332 Primary VPN label advertised by PE2 to all PEs: 2000 333 Repair VPN label advertised by PE2 all PEs: 3000 335 LDP label for PE2 on PE1 is 1234 336 LDP label for PE1 on PE2 is 4567 338 Before failure 339 ''''''''''''''' 340 PE1 has the following FIB entries 342 4000 -----> CE (unlabeled) 343 -----> PE2, swap 4000 with 3000 and then push 1234 344 5000 -----> CE (unlabeled) 346 PE2 has the following 347 2000 -----> CE (unlabeled) 348 -----> PE1, swap 2000 with 5000 and then push 4567 349 3000 ------> CE (unlabeled) 351 After the CE crashes 352 '''''''''''''''''''' 353 PE1 has the following entry: 354 4000 -----> PE2, swap 4000 with 3000 and then push 1234 355 5000 -----> Drop 357 PE2 has the following 358 2000 -----> PE1, swap 2000 with 5000 and then push 4567 359 3000 ------> Drop 361 Because of the above routing entries, any traffic arriving from the 362 core at PE1 and destined for 10.0.0/8, is rerouted towards PE2 363 using the repair VPN label 3000. PE2 will just drop it instead of 364 looping it back towards PE1. 366 After the link between PE1 and CE fails (CE did not crash) 367 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 368 PE1 has the following entry: 369 4000 -----> PE2, swap 4000 with 3000 and then push 1234 370 5000 -----> Drop 372 PE2 has the following 373 2000 -----> CE (unlabeled) 374 -----> PE1, swap 2000 with 5000 and then push 4567 376 3000 ------> CE 378 Because of the above routing entries, any traffic arriving from the 379 core at PE1 and destined for 10.0.0/8 is rerouted towards PE2 using 380 the repair VPN label 3000. PE2 will forward the traffic towards CE. 382 3. How to Disseminate Repair Label Information 384 We propose to advertise the repair label as an optional path 385 attribute. Advertising the repair label as an optional path 386 attributes has some advantages: 388 o An egress PE can benefit from a scalable repair label allocation 389 schemes such as per-CE repair label allocation 391 o Allows the repairing PE to share the same repair path among 392 multiple protected prefixes. Since the repair path is shared by 393 all labels sharing the path attribute, the repairing PE can 394 optimize its RIB and FIB by sharing the same repair path data 395 structure among a large number of protected prefixes. 397 o Reduces the BGP update message size. Instead of having to send 398 additional labels per prefix, multiple prefixes can share the 399 same repair label 401 o The number of labels used for traffic restoration does not depend 402 on the number of protected prefixes 404 o Allows for incremental deployment because the attribute is 405 optional 407 The main disadvantage of sharing the same repair path among multiple 408 primary paths is loss of fine grain control. It is not possible to 409 manage, control, or provide differentiated handling to traffic on 410 per prefix basis until the network re-converges. The loss of fine 411 grain control is limited to the BGP re-convergence period. 413 It is noteworthy to mention that per-CE and/or per next-hop repair 414 label allocation has some advantages over per-prefix repair label 415 allocation. First it results in using fewer labels. Second it allows 416 for better packing in BGP messages. Third it does not require 417 special handling in the forwarding plane at the repair PE. Fourth it 418 simplifies the forwarding plane while maximizing the packet 419 switching performance because the egress PE can take a forwarding 420 decision with a single FIB lookup. 422 3.1.1. Structure of the Repair Label Path Attribute 424 This document defines the repair label attribute as an optional non- 425 transitive path attribute [2] as follows: 427 Attribute name: REPAIR_LABEL 429 Type code: TBD 431 Attribute Flags: 433 Optional bit: 1 435 Transitive bit: 0 437 Partial bit: 0 439 Extended Length bit: 0 441 Length of the attribute: length in octets of the attribute 443 Attribute Value: The attribute value contains a stack of one or 444 more labels. The encoding of the labels is identical to encoding 445 of the "label" field in [4]. The value of the bottom of stack 446 (BOS) bit is determined at traffic restoration time as specified 447 in Section 3.1.2. . 449 3.1.2. Semantics of the Repair Label Attribute 451 This document specifies the semantics of the repair label attribute 452 when the attribute carries one repair label only. The semantics of 453 more than one repair label is beyond the scope of this document. 455 Suppose a BGP speaker PE1 receives an update message with a repair 456 label attribute containing the label "Lr2" from the IBGP peer PE2. 457 Suppose the NLRI in the MP_REACH_NLRI attribute [3] contains the 458 prefixes R1, R2,. . . , Rn each bound to a label L21, L22,. . . , 459 L2n, respectively. This means the following: 461 1. PE2 will never attempt to repair a packet arriving with the label 462 "Lr2". Hence PE2 will either forward the packet to an external CE 463 or drop the packet 465 2. PE2 expects the following from PE1: 467 a. Case a: The route Ri on PE1 is bound to a local label "L1i". 468 Suppose PE1 receives a packet from the core with the label 469 "L1i" at the top of the stack. If the PE1 loses the primary 470 path for a prefix Ri or PE1 receives a packet from the core 471 while not having an external path, and PE1 decides that PE2 472 is the repair PE for the prefix Ri, then PE1 MUST swap the 473 label "L1i" on the packet with the repair label "Lr2" and 474 then tunnel the packet to PE2. The bottom of stack (BOS) bit 475 MUST be copied from the label arriving on the packet to the 476 label "Lr2" 478 b. Case b: The route Ri on PE1 is bound to an aggregate label 479 (e.g. per-vrf label). In that case, if PE1 receives a packet 480 from the core, PE1 has to perform more than one route lookup 481 to determine the primary path. Eventually, there will either 482 be an IP lookup or a label lookup that points to the primary 483 path: 485 i. A label lookup points to the primary path: In that case, 486 PE1 handles the packet as described in item 2.a above. 488 ii. An IP lookup points to the primary path: In that case, 489 if the PE1 loses the primary path for a prefix Ri or PE1 490 receives a packet from the core while not having an 491 external path, PE1 handles the packet as follows 493 1. PE1 pops all labels on the packet 495 2. PE1 MUST push the label "Lr2" 497 3. PE1 tunnels the packet to PE2. The bottom of stack 498 (BOS) bit in "Lr2" MUST be set as specified in [5]. 500 3.1.3. Additional Rule when Forwarding Advertisements Containing the 501 Repair Path Attribute 503 As specified in Section 3.1.1. , the repair label attribute is a 504 non-transitive attribute. However there may be cases, such as inter- 505 AS option (b)[9], route reflectors [11], or confederation [12], 506 where a router may replace the advertised next-hop with its own 507 before forwarding an advertisement. If a BGP speaker replaces the 508 next-hop attribute with its own and the advertisement contains a 509 repair label attribute with label stack "Sr", there are two options 511 o Option 1: The BGP speaker MUST NOT advertise the repair label 512 attribute 514 o Option 2: The BGP speaker MUST replace the repair label stack 515 "Sr" with a locally allocated label stack "Sr1" before 516 advertising the route and then advertise the stack "Sr1" in the 517 repair label attribute. For the forwarding plane, the BGP speaker 518 MUST install a swap forwarding entry such that if the BGP speaker 519 receives a packet with the label stack "Sr1", it swaps "Sr1" with 520 the stack "Sr". 522 Note that advertising the repair label attribute by the router 523 depends on whether the router understands the semantics of and 524 supports the repair label attribute at the time of receiving an 525 advertisement containing the repair label attribute. 527 4. Security Considerations 529 No additional security risk is introduced by using the mechanisms 530 proposed in this document 532 5. IANA Considerations 534 This document defines a new BGP path attribute. IANA maintains a 535 list of the current BGP attribute typecodes in [6]. This document 536 proposes defining a new typecode value of "TBD" for the REPAIR_LABEL 537 path attribute 539 6. Conclusions 541 This document proposes using a repair label to allow restoring 542 traffic prior to BGP convergence while avoiding loops 544 7. References 546 7.1. Normative References 548 [1] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 552 4 (BGP-4), RFC 4271, January 2006 554 [3] Bates, T., Chandra, R., Katz, D., and Rekhter Y., 555 "Multiprotocol Extensions for BGP", RFC 4760, January 2007 557 [4] Rosen, E., Rekhter, Y., "Carrying Label Information in BGP-4", 558 RFC 3107, May 2001 560 [5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, 561 D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 562 3032, January 2001. 564 7.2. Informative References 566 [6] BGP Parameters, http://www.iana.org/assignments/bgp- 567 parameters/bgp-parameters.xhtml 569 [7] Marques,P., Fernando, R., Chen, E, Mohapatra, P., 570 "Advertisement of the best external route in BGP", draft-ietf- 571 idr-best-external-02.txt, April 2004. 573 [8] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 574 Framework", RFC 5565, June 2009. 576 [9] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 577 Networks (VPNs)", RFC 4364, February 2006. 579 [10] De Clercq, J. , Ooms, D., Prevost, S., Le Faucheur, F., 580 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 581 Edge Routers (6PE)", RFC 4798, February 2007 583 [11] Bates, T., Chen, E., and Chandra, R., "BGP Route Reflection: 584 An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, 585 April 2006 587 [12] Traina, P., McPherson, P., and Scudder, J., "Autonomous System 588 Confederations for BGP", RFC 5065, August 2007 590 8. Acknowledgments 592 Special thanks to Keyur Patel, Robert Raszuk, and Eric Rosen for the 593 valuable comments 595 This document was prepared using 2-Word-v2.0.template.dot. 597 Authors' Addresses 599 Ahmed Bashandy 600 Cisco Systems 601 170 West Tasman Dr, San Jose, CA 95134 602 Email: bashandy@cisco.com 604 Burjiz Pithawala 605 Cisco Systems 606 170 West Tasman Dr, San Jose, CA 95134 607 Email: bpithaw@cisco.com 609 Jakob Heitz 610 Ericsson 611 100 Headquarters Drive, San Jose, CA, 95134 612 Email: jakob.heitz@ericsson.com