idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-05.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 document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2012) is 4426 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) == Unused Reference: 'RFC2119' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'P2MP FRR' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 502, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'P2MP FRR' Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track N. So 5 Expires: September 14, 2012 Verizon Inc. 6 A. Liu 7 Ericsson 8 O. Komolafe 9 Cisco Systems 10 L. Liu 11 KDDI R&D Lab Inc. 12 March 13, 2012 14 Extensions to RSVP-TE for P2MP LSP Egress Local Protection 15 draft-chen-mpls-p2mp-egress-protection-05.txt 17 Abstract 19 This document describes extensions to Resource Reservation Protocol - 20 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 21 a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched 22 Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized 23 MPLS (GMPLS) network. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 14, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 62 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. An Example of Egress Local Protection . . . . . . . . . . 4 64 4.2. Set up of Backup sub LSP . . . . . . . . . . . . . . . . . 5 65 4.3. Forwarding State for Backup sub LSP(s) . . . . . . . . . . 6 66 4.4. Detection of Egress Node Failure . . . . . . . . . . . . . 6 67 5. Egress Local Protection with FRR . . . . . . . . . . . . . . . 7 68 6. Representation of a Backup Sub LSP . . . . . . . . . . . . . . 7 69 6.1. EGRESS_BACKUP_SUB_LSP Object . . . . . . . . . . . . . . . 7 70 6.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object . . . . . . . . . . 8 71 6.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object . . . . . . . . . . 8 72 6.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object . . . . . . 9 73 7. Path Message . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Format of Path Message . . . . . . . . . . . . . . . . . . 9 75 7.2. Processing of Path Message . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" 86 describes two methods for protecting P2P LSP tunnels or paths at 87 local repair points. The first method is a one-to-one protection 88 method, where a detour backup P2P LSP for each protected P2P LSP is 89 created at each potential point of local repair, which is an 90 intermediate node between the ingress node and the egress node of the 91 protected LSP. The second method is a facility bypass backup 92 protection method, where a bypass backup P2P LSP tunnel is created 93 using MPLS label stacking to protect a potential failure point for a 94 set of P2P LSP tunnels. The bypass backup tunnel can protect a set 95 of P2P LSPs having similar backup constraints. 97 RFC 4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to 98 use the one-to-one protection method and facility bypass backup 99 protection method to protect a link or intermediate node failure on 100 the path of a P2MP LSP. However, there is no mention of locally 101 protecting any egress node failure in a protected P2MP LSP. 103 An existing method for protecting the egress nodes of a P2MP LSP sets 104 up a backup P2MP LSP from a backup ingress node to the backup egress 105 nodes, where each egress node is paired with a backup egress node and 106 protected by the backup egress node. The backup P2MP LSP carries the 107 same traffic as the P2MP LSP at the same time. A traffic receiver 108 from the P2MP LSP is normally connected to an egress node and its 109 paired backup egress node. It receives the traffic from the egress 110 node in normal situations. 112 The receiver selects the egress or backup egrss node for receiving 113 the traffic according to the route to the source through RPF. In a 114 normal situation, it selects the egress node. When the egress node 115 fails, it selects the backup egress for receiving the traffic since 116 the route to the source through the egress node is gone and the route 117 to the source through the backup egress node is active. 119 The main disadvantage of this method is that double network resources 120 such as double bandwidths are used for protecting the egress nodes 121 since the backup P2MP LSP consumes the same amount of network 122 resource as the primary P2MP LSP. The impact on network efficiency 123 can be significant in case of large P2MP deployments. 125 This document proposes a new method to locally protect the egress 126 nodes of a P2MP LSP, which is called Egress Local Protection. It 127 specifies the mechanism and extensions to RSVP-TE for locally 128 protecting an egress node of a Traffic Engineered (TE) point-to- 129 multipoint (P2MP) Label Switched Path through using a backup P2MP sub 130 LSP. The new method overcomes the disadvantages described above. 132 The same extensions and mechanism can also be used to protect the 133 egress node of a TE P2P LSP. 135 2. Terminology 137 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 138 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 140 3. Conventions Used in This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119. 146 4. Mechanism 148 This section briefly describes a solution that locally protects an 149 egress node of a P2MP LSP through using a backup P2MP sub LSP. We 150 first show an example, and then present different parts of the 151 solution, which includes the creation of the backup sub LSP, the 152 forwarding state for the backup sub LSP, and the detection of a 153 failure in the egress node. 155 4.1. An Example of Egress Local Protection 157 Figure 1 below illustrates an example of using backup sub LSPs to 158 locally protect egress nodes of a P2MP LSP. The P2MP LSP is from 159 ingress node R1 to three egress nodes: L1, L2 and L3. It is 160 represented by double lines in the figure. 162 La, Lb and Lc are the designated backup egress nodes for the egress 163 nodes L1, L2 and L3 of the P2MP LSP respectively. In order to 164 distinguish an egress node (e.g., L1 in the figure) and a backup 165 egress node (e.g., La in the figure), an egress node is called a 166 primary egress node in the follwing description. 168 The backup sub LSP used to protect the primary egress node L1 is from 169 its previous hop node R3 to the backup egress node La. The backup 170 sub LSP used to protect the primary egress node L2 is from its 171 previous hop node R5 to the backup egress node Lb. The backup sub 172 LSP used to protect the primary egress node L3 is from its previous 173 hop node R5 to the backup egress node Lc via the intermediate node 174 Rc. 176 During normal operation, the traffic transported by the P2MP LSP is 177 forwarded through R3 to L1, then delivered to its destination CE1. 178 When the failure of L1 is detected, R3 forwards the traffic to the 179 backup egress node La, which then delivers the traffic to its 180 destination CE1. The time for switching the traffic after L1 fails 181 is within tens of milliseconds. 183 L1's failure CAN be detected by a BFD session between L1 and R3. 185 [R2]=====[R3]=====[L1]----[CE1] 186 // \ / 187 // \ / 188 // \___[La]_/ 189 // 190 // 191 // 192 // 193 +---[R1]====[R4]====[R5]=====[L2]----[CE2] 194 | |\\ \ / 195 | | \\ \ / 196 [S]--| | \\ \__[Lb]_/ 197 | | \\ 198 | | \\ 199 | \\ 200 | \\ 201 | \\ 202 | [L3]----[CE3] 203 | / 204 | / 205 [Rc]_______[Lc]_/ 207 Figure 1: P2MP sub LSP for Locally Protecting Egress 209 4.2. Set up of Backup sub LSP 211 A backup egress node is designated for a primary egress node of a 212 LSP. The previous hop node of the primary egress node sets up a 213 backup sub LSP from itself to the backup egress node after receiving 214 the information about the backup egress node. 216 The previous hop node sets up the backup sub LSP, creates and 217 maintains its state in the same way as of setting up a source to leaf 218 (S2L) sub LSP from the signalling's point of view. It constructs and 219 sends a RSVP-TE PATH message along the path for the backup sub LSP, 220 receives and processes a RSVP-TE RESV message that responses to the 221 PATH message. 223 4.3. Forwarding State for Backup sub LSP(s) 225 The forwarding state for the backup sub LSP is different from that 226 for a P2MP S2L sub LSP. After receiving the RSVP-TE RESV message for 227 the backup sub LSP, the previous hop node creates a forwarding entry 228 with an inactive state or flag called inactive forwarding entry. 229 This inactive forwarding entry is not used to forward any data 230 traffic during normal operations. It SHALL only be used after the 231 failure of the primary egress node. 233 Upon detection of the primary egress node failure, the state or flag 234 of the forwarding entry for the backup sub LSP is set to be active. 235 Thus, the previous hop node of the primary egress node will forward 236 the traffic to the backup egress node through the backup sub LSP, 237 which then send the traffic to its destination. 239 4.4. Detection of Egress Node Failure 241 The previous hop node of the primary egress node SHALL detect four 242 types of failures described below: 244 o The failure of the primary egress node (e.g. L1 in Figure 1) 246 o The failure of the link between the primary egress node and its 247 previous hop node (e.g. the link between R3 and L1 in Figure 1) 249 o The failure of the destination node for the primary egress node 250 (e.g. CE1 in Figure 1) 252 o The failure of the link between the primary egress node and its 253 destination node (e.g. the failure of the link between L1 and CE1 254 in Figure 1). 256 Failure of the primary egress node and the link between itself and 257 its previous hop node CAN be detected through a BFD session between 258 itself and its previous hop node in MPLS networks. 260 In the GMPLS networks where the control plane and data plane are 261 physically separated, the detection and localization of failures in 262 the physical layer can be achieved by introducing the link management 263 protocol (LMP) or assisting by performance monitoring devices. 265 Failure of the destination node and the link between the primary 266 egress node and the destination node CAN be detected by a BFD session 267 between the previous hop node and the destination node. 269 Upon detecting any above mentioned failures, the previous hop node 270 imports the traffic from the LSP into the backup sub LSP. The 271 traffic is then delivered to its destination through the backup 272 egress node. 274 5. Egress Local Protection with FRR 276 RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use 277 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" (FFR 278 for short) to locally protect failures in a link or intermediate node 279 of a P2MP LSP. However, there is not any standard that locally 280 protects the egresses of the P2MP LSP. The egress local protection 281 mechanism proposed in this document fills this gap. Thus, through 282 using the egress local protection and the FRR, we can locally protect 283 the egress nodes, all the links and the intermediate nodes of a P2MP 284 LSP. The traffic switchover time is within tens of milliseconds 285 whenever any of the egresses, the links and the intermediate nodes of 286 the P2MP LSP fails. 288 All the egress nodes of the P2MP LSP can be locally protected through 289 using the egress local protection. All the links and the 290 intermediate nodes of the LSP can be locally protected by using the 291 FRR. Note that the methods for locally protecting all the links and 292 the intermediate nodes of a P2MP LSP are out of scope of this 293 document. 295 6. Representation of a Backup Sub LSP 297 A backup sub LSP exists within the context of a P2MP LSP in a way 298 similar to a S2L sub LSP. It is identified by the P2MP LSP ID, 299 Tunnel ID, and Extended Tunnel ID in the SESSION object, the tunnel 300 sender address and LSP ID in the SENDER_TEMPLATE object, and the 301 backup sub LSP destination address in the EGRESS_BACKUP_SUB_LSP 302 object (to be defined in the section below). 304 An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to 305 optionally specify the explicit route of a backup sub LSP that is 306 from a previous hop node to a backup egress node. The EB-SERO is 307 defined in the following section. 309 6.1. EGRESS_BACKUP_SUB_LSP Object 311 An EGRESS_BACKUP_SUB_LSP object identifies a particular backup sub 312 LSP belonging to the LSP. 314 6.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object 316 The class of the EGRESS_BACKUP_SUB_LSP IPv4 object is the same as 317 that of the S2L_SUB_LSP IPv4 object defined in RFC 4875. The C-Type 318 of the object is a new number 3, or may be another number assigned by 319 Internet Assigned Numbers Authority (IANA). 321 EGRESS_BACKUP_SUB_LSP Class = 50, 322 EGRESS_BACKUP_SUB_LSP_IPv4 C-Type = 3 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Egress Backup Sub LSP IPv4 destination address | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Egress IPv4 address | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Egress Backup Sub LSP IPv4 destination address 333 IPv4 address of the backup sub LSP destination is the backup 334 egress node. 335 Egress IPv4 address 336 IPv4 address of the egress node 338 6.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object 340 The class of the EGRESS_BACKUP_SUB_LSP IPv6 object is the same as 341 that of the S2L_SUB_LSP IPv6 object defined in RFC 4875. The C-Type 342 of the object is a new number 4, or may be another number assigned by 343 Internet Assigned Numbers Authority (IANA). 345 EGRESS_BACKUP_SUB_LSP Class = 50, 346 EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Egress Backup Sub LSP IPv6 destination address | 352 | (16 bytes) | 353 | .... | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Egress IPv6 address | 356 | (16 bytes) | 357 | .... | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Egress Backup Sub LSP IPv6 destination address 361 IPv6 address of the backup sub LSP destination is the backup 362 egress node. 363 Egress IPv6 address 364 IPv6 address of the egress node 366 6.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object 368 The format of an EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) 369 object is defined as identical to that of the ERO. The class of the 370 EB-SERO is the same as that of the SERO defined in RFC 4873. The EB- 371 SERO uses a new C-Type 3, or may use another number assigned by 372 Internet Assigned Numbers Authority (IANA). The formats of sub- 373 objects in an EB-SERO are identical to those of sub-objects in an ERO 374 defined in RFC 3209. 376 7. Path Message 378 This section describes extensions to the Path message defined in RFC 379 4875. The Path message is enhanced to transport the information 380 about a backup egress node to the previous hop node of a primary 381 egress node of a P2MP LSP through including an egress backup sub LSP 382 descriptor list. 384 7.1. Format of Path Message 386 The format of the enhanced Path message is illustrated below. 388 ::= [ ] 389 [ [ | ] ...] 390 [ ] 391 392 393 [ ] 394 395 [ ] 396 [ ... ] 397 [ ] 398 [ ] 399 [ ] 400 [ ... ] 401 402 [] 403 [] 405 The format of the egress backup sub LSP descriptor list in the 406 enhanced Path message is defined as follows. 408 ::= 409 410 [ ] 412 ::= 413 414 [ ] 416 7.2. Processing of Path Message 418 The ingress node of a LSP initiates a Path message with an egress 419 backup sub LSP descriptor list for protecting primary egress nodes of 420 the LSP. In order to protect a primary egress node of the LSP, the 421 ingress node MUST add an EGRESS_BACKUP_SUB_LSP object into the list. 422 The object contains the information about the backup egress node to 423 be used to protect the failure of the primary egress node. An 424 EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE object (EB-SERO), which 425 describes an explicit path to the backup egress node, SHALL follow 426 the EGRESS_BACKUP_SUB_LSP. 428 If the previous hop node of the primary egress node receives the Path 429 message with an egress backup sub LSP descriptor list, it generates a 430 new Path message based on the information in the 431 EGRESS_BACKUP_SUB_LSP (and according to EB-SERO if it exists) 432 containing the backup egress node. 434 The format of this new Path message is the same as that of the Path 435 message defined in RFC 4875. This new Path message is used to signal 436 the segment of a special S2L sub-LSP from the previous hop node to 437 the backup egress node. The new Path message is sent to the next-hop 438 node along the path for the backup sub LSP. 440 If an intermediate node receives the Path message with an egress 441 backup sub LSP descriptor list. Then it MUST put the 442 EGRESS_BACKUP_SUB_LSP (according to EB-SERO if exists) containing a 443 backup egress into a Path message to be sent towards the backup 444 egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP containing 445 a backup egress node in the list. 447 When a primary egress node of the LSP receives the Path message with 448 an egress backup sub LSP descriptor list, it SHOULD ignore the egress 449 backup sub LSP descriptor list and generate a PathErr message. 451 8. IANA Considerations 453 TBD 455 9. Acknowledgement 457 The authors would like to thank Richard Li, Rob Rennison, Neil 458 Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam and Quintin Zhao 459 for their valuable comments and suggestions on this draft. 461 10. References 463 10.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997. 468 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 469 Considered Useful", BCP 82, RFC 3692, January 2004. 471 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 472 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 473 Functional Specification", RFC 2205, September 1997. 475 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 476 Label Switching Architecture", RFC 3031, January 2001. 478 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 479 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 480 Tunnels", RFC 3209, December 2001. 482 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 483 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 484 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 486 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 487 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 488 May 2005. 490 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 491 "Extensions to Resource Reservation Protocol - Traffic 492 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 493 Switched Paths (LSPs)", RFC 4875, May 2007. 495 [P2MP FRR] 496 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 497 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 498 draft-leroux-mpls-p2mp-te-bypass , March 1997. 500 10.2. Informative References 502 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 503 Multipoint Traffic-Engineered MPLS Label Switched Paths 504 (LSPs)", RFC 4461, April 2006. 506 Authors' Addresses 508 Huaimo Chen 509 Huawei Technologies 510 Boston, MA 511 USA 513 Email: Huaimochen@huawei.com 515 Ning So 516 Verizon Inc. 517 2400 North Glenville Drive 518 Richardson, TX 75082 519 USA 521 Email: Ning.So@verizonbusiness.com 522 Autumn Liu 523 Ericsson 524 CA 525 USA 527 Email: autumn.liu@ericsson.com 529 Olufemi Komolafe 530 Cisco Systems 531 96 Commercial Street 532 Edinburgh, EH6 6LX 533 United Kingdom 535 Email: femi@cisco.com 537 Lei Liu 538 KDDI R&D Lab Inc. 539 2-1-15 540 Ohara Fujimino-shi, Saitama 541 Japan 543 Email: le-liu@kddilabs.jp