idnits 2.17.1 draft-shen-mpls-rsvp-setup-protection-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2013) is 3948 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: 'RFC 4090' is mentioned on line 424, but not defined == Unused Reference: 'RFC2205' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC3472' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 493, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Yimin. Shen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Yuji. Kamite 5 Expires: December 30, 2013 NTT Communications Corporation 6 Eric. Osborne 7 Cisco Systems 8 June 28, 2013 10 RSVP Setup Protection 11 draft-shen-mpls-rsvp-setup-protection-03 13 Abstract 15 RFC 4090 specifies an RSVP facility-backup fast reroute mechanism for 16 protecting LSPs against link and node failures. This document 17 extends the mechanism to provide so-called "setup protection" for 18 LSPs during their initial Path message signaling time. In 19 particular, it enables a router to reroute an LSP via an existing 20 bypass LSP, when there is a failure of the immediate downstream link 21 or node along the desired path. Therefore, it can be used to avoid 22 LSP signaling failure and reduce setup time in such kind of 23 situation, and allow an LSP to be established temporarily over a 24 bypass LSP when an alternative path can only be resolved at a much 25 later time. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 30, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 63 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. New RSVP Attribute Flag . . . . . . . . . . . . . . . . . 5 65 3.2. New RSVP Attributes TLVs . . . . . . . . . . . . . . . . 5 66 3.2.1. Protected LSP Sender IPv4 Address TLV . . . . . . . . 6 67 3.2.2. Protected LSP Sender IPv6 Address TLV . . . . . . . . 6 68 3.3. PLR behavior . . . . . . . . . . . . . . . . . . . . . . 7 69 3.4. MP behavior . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.5. Local Revertive Mode . . . . . . . . . . . . . . . . . . 9 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 In RSVP facility-backup fast reroute (FRR) [RFC 4090], the router at 82 a point of local repair (PLR) of an LSP can redirect traffic via a 83 bypass LSP upon a failure of the immediate downstream link or node. 84 Such protection is normally established after the LSP has been set 85 up. This is because the PLR must know the label and address of the 86 next-hop router (in link protection) or those of the next-next-hop 87 router (in node protection), before it can select or create a bypass 88 LSP to protect the LSP. The information of the label and the address 89 is carried in the Resv message of the LSP. 91 Imagine a scenario where a new LSP is being signaled, and its Path 92 message carries an EXPLICIT_ROUTE object (ERO) with a strict path 93 that is statically configured or computed offline based on a topology 94 that assumes no failure of the network. If a link or node along the 95 path happens to be in a failure condition, RSVP signaling will stop 96 at the router upstream adjacent to the failure, as the next hop in 97 the strict path no longer matches the current network topology. This 98 will be the case even if there is an existing bypass LSP protecting 99 the link or node for some existing LSPs. In other words, this new 100 LSP is not protected during the setup time, i.e. the initial Path 101 message signaling. 103 In this situation, the network would normally rely on IGP to update 104 traffic engineering (TE) information throughout the network, and the 105 router upstream adjacent to the failure to send a PathErr message to 106 trigger the ingress router to compute and signal a new path. 107 However, this approach may not always be possible or desirable in the 108 following scenarios: 110 1. Static strict path. As described above, if the ERO carries an 111 explicit path with a sequence of strict hops that are statically 112 configured or computed offline based on a topology assuming no 113 network failure, the LSP will not be established until the path 114 is modified. This is a typical case where CSPF calculation is 115 disabled at the LSP's ingress router due to the operational 116 preference of service provider. 118 2. LSPs with a strict requirement for setup time. IGP TE 119 information flooding, PathErr message propagation and path re- 120 computation and re-signaling may introduce a significant delay to 121 LSP establishment. This may impact on LSP setup time, and even 122 become unacceptable for LSPs that have a strict requirement for 123 it, such as on-demand transport LSPs for real-time data or TV 124 broadcast. For these LSPs, a guaranteed establishment and setup 125 time are considered as more important than path optimality. 127 3. Sibling P2MP sub-LSPs sharing a common link. In this case, the 128 new LSP is a sub-LSP of a P2MP LSP, and its desired path is 129 supposed to share the failed link with an existing sibling sub- 130 LSP, i.e. another sub-LSP of the same P2MP LSP, which is being 131 protected by a bypass LSP. If the new sub-LSP is rerouted via a 132 different path, it will not be able to share the data flow over 133 the bypass LSP with that sibling sub-LSP, creating unnecessary 134 traffic flow in the network. 136 For networks where a failure, delay or resignaling during LSP setup 137 is not desirable, this document extends the RSVP facility-backup fast 138 reroute mechanism to provide a graceful solution, called "setup 139 protection". During the initial Path message signaling of an LSP, if 140 there is a link or node failure along the desired path, and if there 141 is a bypass LSP protecting the link or node, the LSP can be signaled 142 through the bypass LSP without a delay. The LSP will be established 143 as if it were originally set up along the desired path (i.e. primary 144 path) and then failed over to the bypass LSP after the failure. 145 Meanwhile, actions may be taken to resolve the failure or resignal 146 the LSP via an alternative path, by following procedures or timing 147 appropriate to the service provider. The setup protection is 148 applicable to both P2P LSPs and P2MP LSPs, when such kind of 149 temporary rerouting is not considered as a violation of desired path, 150 as in the case of the normal fast reroute. It may be enabled by 151 policy on a per LSP basis. 153 2. Specification of Requirements 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119. 159 3. Theory of Operation 161 When an LSP is being signaled by RSVP, a Path message is sent hop by 162 hop from the ingress router to the egress router, following the path 163 defined by an ERO. The setup protection mechanism in this document 164 enables a router to reroute the LSP via a bypass LSP, if the router 165 detects a failure of the immediate downstream link or node 166 represented by the next hop in the ERO, called "next ERO hop". In 167 this case, the current router is referred to as a PLR. 169 The mechanism is only relevant when the Path message carries the 170 "local protection desired" flag in the SESSION_ATTRIBUTE object [RFC 171 4090] and a new "setup protection desired" flag defined in this 172 document (Section 3.1). That is, setup protection is explicitly 173 requested for the LSP. 175 In link protection, the mechanism is only applicable when the next 176 ERO hop received by a PLR is a strict hop. In node protection, the 177 mechanism is only applicable when both the next and the next-next ERO 178 hops received by the PLR are strict hops. Otherwise, setup 179 protection would be unnecessary, as the router may perform a loose 180 hop expansion to reroute the LSP via any alternative path around the 181 downstream failure. The strict ERO hops ensure that the PLR can 182 unambiguously decide the intended downstream link or node and 183 reliably detect its status. In link protection, the strict next ERO 184 hop also indicates the merge point (MP), i.e. the destination of the 185 bypass LSP to be used to reroute the LSP. In node protection, the 186 strict next-next ERO hop indicates the MP. 188 When performing setup protection, the PLR signals a backup LSP by 189 tunneling Path message through the bypass LSP. Like the Path message 190 of a backup LSP in the normal facility-backup FRR ([RFC 4090]), this 191 Path message carries an address of the PLR as the sender address in 192 SENDER_TEMPLATE object. In addition, the Path message also carries 193 the information of the protected LSP (Section 3.2). When the MP 194 receives the Path message, it terminates the backup LSP, and re- 195 creates the protected LSP. If the MP is the egress router of the 196 protected LSP, it terminates the protected LSP as well. If the MP is 197 a transit router of the protected LSP, it signals the LSP further 198 downstream. 200 Eventually, the LSP will be established end to end, with the backup 201 LSP tunneled through the bypass LSP from the PLR to the MP. The RSVP 202 state on the PLR and the MP and the RSVP messages generated by these 203 routers are no different than those in a post-failure situation of a 204 normal facility-backup FRR. 206 Later, when the failure is resolved, the PLR MAY revert the LSP to 207 the primary path, in the same manner as the local revertive mode 208 specified in [RFC 4090]. 210 The setup protection MAY be enabled and disabled on a router based on 211 configuration. For an LSP to be setup-protected, the mode MUST be 212 enabled on both PLR and MP. If it is enabled on the PLR but disabled 213 on the MP, the MP SHOULD reject the Path message of the backup LSP 214 and send a PathErr message, as described Section 3.4. 216 3.1. New RSVP Attribute Flag 218 In order for an LSP to explicitly request setup protection, this 219 document defines a new "setup protection desired" flag for the 220 Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420]. The flag 221 is set by the ingress router in the Path message of the LSP, i.e. the 222 protected LSP. It MUST be supported by all routers that intend to 223 serve as PLRs for setup protection. 225 3.2. New RSVP Attributes TLVs 227 This document defines the following two new RSVP Attributes TLVs [RFC 228 5420]. They are used by a PLR to convey to an MP the original sender 229 address in SENDER_TEMPLATE object of the Path message of a protected 230 LSP. 232 o Protected LSP Sender IPv4 Address TLV 234 o Protected LSP Sender IPv6 Address TLV 235 One of the TLVs SHOULD be carried by the LSP_REQUIRED_ATTRIBUTES 236 object of the Path message of the backup LSP that the PLR sends to 237 the MP. The information is used by the MP to build Path message for 238 the protected LSP. The MP SHOULD NOT propagate the TLV downstream 239 via that Path message. 241 3.2.1. Protected LSP Sender IPv4 Address TLV 243 The Protected LSP Sender IPv4 Address TLV is defined with type TBD. 244 It is allowed in LSP_REQUIRED_ATTRIBUTES object, and not allowed in 245 LSP_ATTRIBUTES object. The encoding is as below. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type (TBD) | Length (8) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Value | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1 257 Type 259 TBD 261 Length 263 8 265 Value 267 Original sender address in the IPv4 SENDER_TEMPLATE object of the 268 protected LSP. 270 3.2.2. Protected LSP Sender IPv6 Address TLV 272 The Protected LSP Sender IPv6 Address TLV is defined with type TBD. 273 It is allowed in LSP_REQUIRED_ATTRIBUTES object, and not allowed in 274 LSP_ATTRIBUTES object. The encoding is as below. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type (TBD) | Length (20) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 // Value // 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 2 288 Type 290 TBD 292 Length 294 20 296 Value 298 Original sender address in the IPv6 SENDER_TEMPLATE object of the 299 protected LSP. 301 3.3. PLR behavior 303 When a router has a Path message to send out, if the Path message 304 carries the "local protection desired" flag in the SESSION_ATTRIBUTE 305 object and the "setup protection desired" flag in the LSP_ATTRIBUTES 306 object, and if the next ERO hop is a strict IPv4 or IPv6 prefix, the 307 router SHOULD validate the reachability of the prefix against routing 308 tables, traffic engineering (TE) database, or a database that 309 reflects the current status of the network topology. If the prefix 310 is reachable and is one hop away from the current router, the router 311 should send out the Path message as it is. Otherwise, there is a 312 possibility that the link or node corresponding to the prefix has 313 failed. 315 The router SHOULD further search for an existing bypass LSP that is 316 protecting the prefix. If the protected LSP desires link protection, 317 the destination of the bypass LSP (i.e. MP) must be the router that 318 owns the prefix. If the LSP desires node protection and the next- 319 next ERO hop of the LSP is a strict prefix, the MP must be the router 320 that owns this prefix. 322 If a bypass LSP is not found by the above criteria, the router MUST 323 originate a PathErr with code = 24 (routing problem) and sub-code = 2 324 (bad strict node). 326 If a bypass LSP is found, the router MUST act as a PLR for setup 327 protection, and reroute the protected LSP via the bypass LSP. If 328 multiple satisfactory bypass LSPs exist, the PLR MAY select one based 329 on bandwidth constraints or local policies. Specifically, if the 330 protected LSP is a sub-LSP of a P2MP LSP, a bypass LSP that is 331 protecting an existing sibling sub-LSP MUST be preferred, to minimize 332 traffic duplication in the network. 334 The PLR SHOULD NOT send the Path message of the protected LSP any 335 further. Instead, it MUST create a backup LSP, and send a Path 336 message of the backup LSP to the MP via the bypass LSP. The Path 337 message is constructed by using the sender template specific method 338 [RFC 4090]. In particular, it has the sender address in the 339 SENDER_TEMPLATE object set to an address of the PLR. It MUST carry 340 an LSP_REQUIRED_ATTRIBUTES object with a Protected LSP Sender IPv4 341 Address TLV or Protected LSP Sender IPv6 Address TLV. 343 Upon receiving a Resv message of the backup LSP from the MP, the PLR 344 SHOULD bring up both of the backup LSP and the protected LSP. If the 345 PLR is the ingress router of the protected LSP, the LSP has been set 346 up successfully. If the PLR is a transit router, it MUST send a Resv 347 message upstream for the protected LSP, with the "local protection 348 available" and "local protection in use" set to 1, and if applicable, 349 the "node protection" and "bandwidth protection" flags set to 1, in 350 the RRO hop corresponding to the PLR. The PLR SHOULD also originate 351 a PathErr message with code = 25 (notify error) and sub-code = 3 352 (tunnel locally repaired), as if the LSP had just fell over to the 353 bypass LSP. 355 The PLR SHOULD also install a forwarding entry for the protected LSP. 356 In the typical case, the forwarding entry should result in two 357 outgoing labels for packets. The inner label is the backup LSP's 358 label, and the outer label is the bypass LSP's label. However, the 359 forwarding entry may result in one or no label, if either or both of 360 the backup LSP and the bypass LSP have the Implicit NULL label. 362 If the PLR receives a PathErr message when signaling the backup LSP, 363 the PLR MUST NOT bring up the backup LSP or the protected LSP. If 364 the PLR is a transit router of the protected LSP, it MUST propagate 365 the PathErr message upstream for the protected LSP. Likewise, if the 366 PLR receives a PathErr message of the backup LSP after the backup LSP 367 and the primary LSP have previously been brought up, and the PLR is a 368 transit router of the protected LSP, it SHOULD also propagate the 369 PathErr message upstream for the protected LSP. 371 When the PLR receives a ResvTear message of the backup LSP, the PLR 372 MUST bring down both the backup LSP and the protected LSP. If the 373 PLR is a transit router of the protected LSP, it MUST send a ResvTear 374 message upstream for the protected LSP. 376 In any cases where the PLR needs to bring down the protected LSP due 377 to a received PathTear message, an RSVP state time-out, a 378 configuration change, an administrative command, etc, the PLR MUST 379 also bring down the backup LSP by sending a PathTear message through 380 the bypass LSP. 382 3.4. MP behavior 384 When an MP receives the Path message of a backup LSP, it MUST realize 385 the setup protection situation based on the presence of Protected LSP 386 Sender IPv4 Address TLV or Protected LSP Sender IPv6 Address TLV in 387 LSP_REQUIRED_ATTRIBUTES object. 389 If setup protection mode is disabled on the MP, it MUST reject the 390 Path message, by sending a PathErr with code = 2 (policy control 391 failure) to the PLR. 393 Otherwise, the MP MUST terminate the backup LSP and re-create the 394 protected LSP. If the MP is the egress router of the protected LSP, 395 it MUST also terminate the protected LSP. If the MP is a transit 396 router of the LSP, it MUST send a Path message downstream for the 397 protected LSP. The Path message has the sender address in 398 SENDER_TEMPLATE object set to the original address of the ingress 399 router, based on the above received Protected LSP Sender IPv4 Address 400 TLV or Protected LSP Sender IPv6 Address TLV. The Path message MUST 401 NOT carry any Protected LSP Sender IPv4 Address TLV or Protected LSP 402 Sender IPv6 Address TLV in LSP_REQUIRED_ATTRIBUTES object. 404 The MP MUST allocate a label for the backup LSP, and distribute it to 405 the PLR via Resv message of the backup LSP. If the protected LSP is 406 a sub-LSP of a P2MP LSP and there is an existing sibling sub-LSP 407 whose backup LSP is tunneled through the same bypass LSP, the MP MUST 408 allocate the same label as the sibling sub-LSP, in order to avoid 409 traffic duplication at the PLR. 411 When the MP receives a PathTear message for the backup LSP, it MUST 412 bring down both the backup LSP and the protected LSP. If the MP is a 413 transit router of the protected LSP, it MUST send a PathTear message 414 downstream for the protected LSP. 416 In any cases where the MP receives or originates a PathErr or 417 ResvTear message for the protected LSP, the MP MUST send the same 418 type of message to the PLR for the backup LSP. 420 3.5. Local Revertive Mode 422 When the failed link or node is restored, the PLR MAY revert the 423 protected LSP to its desired primary path, by following the procedure 424 of local revertive mode described in [RFC 4090]. 426 4. IANA Considerations 428 This document defines a new flag for the Attribute Flags TLV, which 429 is carried in the LSP_ATTRIBUTES Object of Path message. This flag 430 is used to communicate whether setup protection is desired for an 431 LSP. The value of the new flag needs to be assigned by IANA. 433 Setup Protection Desired: TBD 435 This document defines two new RSVP Attributes TLVs, which are carried 436 in the LSP_REQUIRED_ATTRIBUTES object of Path message. The values of 437 the new types need to be assigned by IANA. 439 Protected LSP Sender IPv4 Address TLV 441 Protected LSP Sender IPv6 Address TLV 443 5. Security Considerations 445 The security considerations discussed in RFC 3209, RFC 4090 and RFC 446 4875 apply to this document. 448 6. Acknowledgements 450 Thanks to Rahul Aggarwal, Disha Chopra, and Nischal Sheth for their 451 contribution. 453 7. References 455 7.1. Normative References 457 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 458 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 459 Functional Specification", RFC 2205, September 1997. 461 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 462 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 463 Tunnels", RFC 3209, December 2001. 465 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 466 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 467 2005. 469 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 470 Ayyangarps, "Encoding of Attributes for MPLS LSP 471 Establishment Using Resource Reservation Protocol Traffic 472 Engineering (RSVP-TE)", RFC 5420, February 2009. 474 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 475 "Extensions to Resource Reservation Protocol - Traffic 476 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 477 Switched Paths (LSPs)", RFC 4875, May 2007. 479 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 480 (GMPLS) Signaling Functional Description", RFC 3471, 481 January 2003. 483 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 484 Protocol Label Switching (GMPLS) Signaling Constraint- 485 based Routed Label Distribution Protocol (CR-LDP) 486 Extensions", RFC 3472, January 2003. 488 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 489 Label Switching Architecture", RFC 3031, January 2001. 491 7.2. Informative References 493 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 494 Networks", RFC 5920, July 2010. 496 Authors' Addresses 498 Yimin Shen 499 Juniper Networks 500 10 Technology Park Drive 501 Westford, MA 01886 502 USA 504 Phone: +1 9785890722 505 Email: yshen@juniper.net 507 Yuji Kamite 508 NTT Communications Corporation 509 Granpark Tower 3-4-1 Shibaura, Minato-ku 510 Tokyo 108-8118 511 Japan 513 Email: y.kamite@ntt.com 515 Eric Osborne 516 Cisco Systems 518 Email: eosborne@cisco.com