idnits 2.17.1 draft-minto-2547-egress-node-fast-protection-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In this model, the protector serves as a centralized protector MAY NOT have a direct connection to multi-homed site. This model can be played by existing PEs or other PEs. In the event of an egress PE failure, protector MUST send the traffic to a alternate egress PE with VPN label advertised alternate egress PE for the prefix which in turn sends the traffic to the multi-homed site. In the topology-1 RR could act as protector for both red and blue VPN site2. This is Centralized protector model (A PE protecting set of VPNs and not connected to any VPN site). -- The document date (October 25, 2011) is 4564 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 5331' is mentioned on line 366, but not defined == Missing Reference: 'RFC 4090' is mentioned on line 89, but not defined == Missing Reference: 'RFC 3031' is mentioned on line 394, but not defined == Unused Reference: 'RFC5331' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'LDP-UPSTREAM' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RSVP-NON-PHP-OOB' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 522, but no explicit reference was found in the text -- Duplicate reference: RFC5920, mentioned in 'RFC5286', was also mentioned in 'RFC5920'. Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeganathan 3 Internet-Draft M. Konstantynowicz 4 Intended status: Standards Track H. Gredler 5 Expires: April 27, 2012 Juniper Networks 6 October 25, 2011 8 2547 egress PE Fast Failure Protection 9 draft-minto-2547-egress-node-fast-protection-00 11 Abstract 13 This document specifies a mechanism for protecting RFC2547 based VPN 14 service against egress node failure. The mechanism enables local 15 repair to be performed immediately upon a egress node failure. In 16 particular, the router at point of local repair (PLR) can redirect 17 VPN traffic to a protector to repair in the order of tens of 18 milliseconds, achieving fast protection that is comparable to MPLS 19 fast reroute. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 27, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Reference topology . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Protector and Protection Models . . . . . . . . . . . . . 6 61 5.1.1. Co-located protector . . . . . . . . . . . . . . . . . 6 62 5.1.2. Centralized protector . . . . . . . . . . . . . . . . 6 63 5.2. Context Identifier and VPN prefixes. . . . . . . . . . . . 6 64 5.3. Context Identifier Advertisement by IGP . . . . . . . . . 7 65 5.3.1. Context-identifier advertised as stub router. . . . . 7 66 5.3.1.1. ISIS context-node . . . . . . . . . . . . . . . . 8 67 5.3.1.2. OSPF context-node . . . . . . . . . . . . . . . . 8 68 5.4. Forwarding State on Protector PE . . . . . . . . . . . . . 8 69 5.4.1. Alternate egress PE for protected prefix. . . . . . . 9 70 5.5. Bypass LSP . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.5.1. RSVP-TE Signaled Bypass LSP and Backup LSP . . . . . . 9 72 5.5.2. LDP Signaled Bypass LSP . . . . . . . . . . . . . . . 10 73 6. Egress node Failure . . . . . . . . . . . . . . . . . . . . . 10 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 This document specifies a mechanism for protecting RFC2547 based VPN 84 against egress PE failure. The procedures in this document are 85 relevant only when a VPN site is multi-homed to two or more PEs. 86 This is designed on the basis of MPLS context specific label 87 switching [RFC 5331]. Fast-protection refers to the ability to 88 provide local repair upon a failure in the order of tens of 89 milliseconds, which is comparable to MPLS fast-reroute [RFC 4090]. 90 This is achieved by establishing local protection as close to a 91 failure as possible. Compared with the existing global repair 92 mechanisms that rely on control plane convergence, these procedures 93 can provide faster restoration for VPN traffic. However, they are 94 intended to complement the global repair mechanisms, rather than 95 replacing them in any way. 97 2. Specification of Requirements 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119. 103 3. Terminology 105 Protected PE: A PE which request protection for minimum one VPN 106 prefix. 108 Protected prefix: A VPN prefix that required protection in case of 109 Protected PE goes down. 111 Protector: A router which protect one or more VPN prefix when a 112 Protected PE goes down. 114 BGP nexthop: A nexthop advertised in the BGP-Update for the VPN 115 prefix by a BGP speaker. 117 VPN label: A label advertised by a BGP speaker for set of VPN 118 prefixes. This label can be per-VRF label or per nexthop label or 119 per prefix label. 121 Transport LSP: A LSP setup to BGP nexthop either by LDP or RSVP. 123 Alternative egress PE: A PE originates same IP prefix as Protected 124 prefix in a same VPN. 126 VPN transport LSP: A Transport LSP that carries VPN traffic. 128 Context table: A context-specific label space routing table. This 129 table is per is populated with VPN labels advertised by the 130 protected-PE. 132 Context node: A stub router advertised into IGP by protected PE for a 133 context-identifier. 135 4. Reference topology 137 This document refers to the following topologies to describe various 138 roles and solution. 140 ....................... 141 . . 142 +-------+--CE1----PE1 PE4----CE5---+-------+ 143 | red | . \ / . | red | 144 | site1 | . \ / . | site2 | 145 +-------+--CE2-----+ P--P--PLR1 +----CE6---+-------+ 146 . | / | | \ | . 147 . PE2 RR | PE5 . 148 . | \ | | / | . 149 +-------+--CE3-----+ P--P--PLR2 +----CE7--+-------+ 150 | blue | . / \ . |blue | 151 | site1 | . / \ . |site2 | 152 +-------+--CE4-----PE3 PE6----CE8--+-------+ 153 . . 154 . . 155 ....................... 157 Figure 1 159 In Topology-1 two VPNs red and blue with two sites multihomed with 160 PEs. Let assume blue and red VPN site2 prefixes required egress 161 protection in case of PE5 goes down. PE5 is protected PE for site2 162 prefixes for both VPN. PE4 is alternate PE for red site2 prefixes. 163 PE6 is alternate PE for blue site2 prefixes. For PE4 could act as 164 protector for red VPN site2 and PE6 could acts as protector for blue 165 VPN site2. This model is co-located protector model. RR could act 166 as protector for both red and blue VPN site2. This is Centralized 167 protector model (A PE protecting set of VPNs and not connected to any 168 VPN site). 170 ....................... 171 . . 172 +-------+--CE1----PE1 PE4----CE5---+-------+ 173 | red | . \ / . | red | 174 | site1 | . \ / . | site2 | 175 +-------+--CE2-----+ P--P--PLR1 +----CE6---+-------+ 176 . | / | | \ | . 177 . PE2 RR | PE5 . 178 . | \ | | / | . 179 +-------+--CE3-----+ P--P--PLR2 +----CE7--+-------+ 180 | red | . / \ . |red | 181 | site5 | . / \ . |site4 | 182 +-------+--CE4-----PE3 PE6----CE8--+-------+ 183 . . 184 . . 185 ....................... 187 Figure 2 189 In Topology-2 has a VPNs red with four sites and multihomed with PEs. 190 Let assume red VPN site2 and site4 prefixes required egress 191 protection in case of PE5 goes down. PE5 is protected PE for site2, 192 site4 prefixes for red VPN. PE4 is alternate PE for site2 prefixes. 193 PE6 is alternate PE for site4 prefixes. Either PE4 or PE6 could act 194 as protector. This is a slight variation of the co-located model. 196 5. Theory of Operation 198 The Egress PEs attached to multi-homed site export VPN prefixes with 199 different route distinguisher, different nexthop but with same route 200 target. The other PEs attached to other sites with same VPN import 201 these route into VRF creates more than one path to multi-homed sites. 202 When one egress PE goes down all VPN traffic towards the multihomed 203 site moved to alternate egress PEs attached to the multi-homed site. 204 This is done by ingress PE. The VPN traffic going via failed PE get 205 dropped in penultimate hop router until ingress PE reroute VPN 206 traffic. Even though connectivity of multi-homed site is not bound 207 to an egress PE the transport LSP bind to egress PE. As result of 208 down transport LSP VPN traffic getting dropped in P router. This 209 document specifies a mechanism that repair VPN traffic at point of 210 failure (typically a P router which penultimate hop of the transport 211 LSP) and still keep P router unaware of the VPN information with the 212 help of protector (a new role). The PLR (point of local repair) send 213 VPN traffic to protector through bypass LSP incase of egress PE 214 failure. This protector send VPN traffic received from PLR to the 215 alternative egress PE until the ingress reroute traffic to alternate 216 egress PE. 218 5.1. Protector and Protection Models 220 Protector, is a new role for the egress PE failure local repair. 221 This protector role could be played by a PE(alternate egress PE) or 222 any other nodes which participates in VPN control plane for VPN 223 prefixes that required egress node protection. Hence, there are two 224 protection models based on the location and role of a protector. 226 5.1.1. Co-located protector 228 In this model, the protector is a alternate egress PE for a protected 229 prefix. It is co-located with the alternate PE for the protected 230 prefix, and it has a direct connection to the multi-homed site that 231 originate the protected prefix. In the event of an egress node 232 failure, the protector receives traffic from the PLR, and sends the 233 traffic to the multi-homed site. In the topology-1 PE4 could act as 234 protector for red VPN site2 and PE6 could acts as protector for blue 235 VPN site2. This model is co-located protector model. RR could act 236 as protector for both red and blue VPN site2. This is Centralized 237 protector model (A PE protecting set of VPNs and not connected to any 238 VPN site). 240 A slight variant of this model is, protector is not alternate PE for 241 a protected prefix but has same VRF. In the topology-2 either PE4 or 242 PE6 could act as protector. This is example for the above model. 244 5.1.2. Centralized protector 246 In this model, the protector serves as a centralized protector MAY 247 NOT have a direct connection to multi-homed site. This model can be 248 played by existing PEs or other PEs. In the event of an egress PE 249 failure, protector MUST send the traffic to a alternate egress PE 250 with VPN label advertised alternate egress PE for the prefix which in 251 turn sends the traffic to the multi-homed site. In the topology-1 RR 252 could act as protector for both red and blue VPN site2. This is 253 Centralized protector model (A PE protecting set of VPNs and not 254 connected to any VPN site). 256 A network MAY use either protection model or a combination of both, 257 depending on requirements. 259 5.2. Context Identifier and VPN prefixes. 261 The context-identifier is an IP address that is either globally 262 unique or unique in the private address space of the routing domain. 263 In Egress PE each VPN prefix is assigned to context-identifier. The 264 granularity of a context identifier is {Egress PE, VPN prefix} tuple. 265 However, a given context identifier MAY be assigned to one or 266 multiple VPN prefix. 268 Possible context identifier assignments are 270 o Unique context-identifier for all VPN prefixes, both VPN-IPv4 and 271 VPN-IPv6. 273 o Unique context-identifier per address family. 275 o Unique context-identifier per site for all VPN prefixes, both VPN- 276 IPv4 and VPN-IPv6. 278 o Unique context-identifier per site per address family. 280 o Unique context-identifier per CE address (nexthop). 282 o Unique context identifier for each prefix. 284 The first one is coarsest granularity of a context identifier and the 285 last one is finest granularity of a context identifier. While all of 286 the above options are possible in principle, their practical usage is 287 likely to vary widely, as not all of them may be of practical usage. 288 A given context identifier MUST NOT be used by more than one 289 protected PE. The egress PE that required protection for a VPN 290 prefix MUST put context-identifier as nexthop in BGP update. This 291 context-identifier as nexthop indicates to protector that this prefix 292 need protection. For e.g. In topology 1 PE5(protected PE) advertise 293 VPN prefixes with context-identifier as BGP nexthop. 295 5.3. Context Identifier Advertisement by IGP 297 IGP MUST advertise context identifiers to allow computation of TE 298 paths for bypass LSPs and VPN transport LSPs that are destined for 299 context identifiers. Context identifiers MUST be advertised a stub 300 router in IGP and TE. Advertised as a stub router allow operator to 301 deploy egress protection without upgrading all P routers. 303 A protected PE MUST advertise a context identifier as a stub router 304 to TE domain and in IGP. Also Protected PE MUST advertise a link to 305 the stub router. 307 A protector MUST advertise link to stub router advertised by 308 protected PE in IGP and TE. 310 5.3.1. Context-identifier advertised as stub router. 312 Context-identifier advertised as stub router required two parts. A 313 node representation (context-node) and links to the node. The 314 protected PE and protector advertise link to context-node and 315 protected PE advertise context-node. 317 The protected PE will advertise context-node in to IGP. The 318 router-id of the context-node is context-identifier. The system-ID 319 is derived from the context-identifier with BCD encoding. The 320 resulting system-ID MUST be unique with in IGP routing domain. 321 Context-node advertised with two unnumbered transit links with MAX 322 routable link metric to protected PE and protector. For TE these 323 unnumbered links advertised with zero bandwidth and MAX TE metric. 324 Other TE characteristic of TE links could be configured to advertise. 325 The router-ID or system-ID of the protector could be dynamically 326 learned from the IGP link state database or could be configured in 327 protected PE. 329 Protected PE MUST advertise unnumbered transit link with metric 1 and 330 TE metric 1 to context-node. Protector MUST advertise unnumbered 331 transit link with maximum routable link metric and maximum TE metric 332 to the context-node. Other TE characteristic of the links could be 333 configured and advertised in to TE. 335 5.3.1.1. ISIS context-node 337 Only zeroth fragment of the context-node is only valid. All Other 338 fragments SHOULD be ignored. Zeroth fragment MUST include area 339 address TLV and MAY include hostname TLV. 341 The set of area addresses advertised MUST be a subset of the set of 342 Area Addresses advertised in the protected LSP number zero at the 343 corresponding level. Preferably, the advertisement SHOULD be 344 syntactically identical to that included in the normal LSP number 345 zero at the corresponding level. The hostname could be set as 346 . 348 The Overload (OL) MUST be set to 1. The Attached (ATT), and 349 Partition Repair (P) bits MUST be set to 0. 351 5.3.1.2. OSPF context-node 353 The advertising router and Link State ID of router LSA MUST be 354 context-identifier. All options bits in router LSA MUST be set to 355 zero. The number of links MUST be 2. 357 5.4. Forwarding State on Protector PE 359 A protector maintain the forwarding state in context-specific label 360 spaces on a per protected PE basis. In particular, the protector 361 MUST learn the VPN label by participating the VPN routing and also 362 MUST keep all routes associated with VPN it required to protect. 364 For each VPN label with an associated context-identifier protector 365 MUST map the context identifier to a context-specific label space 366 [RFC 5331], and program the VPN label in that label space in 367 forwarding plane. For each VPN prefix that required protection 368 programmed in the forwarding plane with BGP nexthop to alternate 369 egress PE. This VPN label in the context-specific label space 370 identify the layer-3 forwarding table that need to lookup to send it 371 alternate egress PE. The protector MAY maintain only VPN prefix 372 originated with-in the multi-homed site for given {egress PE, VPN}. 373 These VPN labels in context table and VPN context table will not be 374 used in forwarding after ingress reroute the traffic to alternative 375 PE. Protector MUST delete VPN label and the VPN context table after 376 ingress reroute the traffic. This shall be achieved with a timer. 377 This timer default value is 180 seconds. 379 5.4.1. Alternate egress PE for protected prefix. 381 Any route with BGP nexthop which has the following properties 383 Exact matching route-target set (RD may be different) 385 Exact matching Prefix part (not RD) 387 will be eligible as alternate egress PE for prefix. 389 5.5. Bypass LSP 391 An LSP MUST be either manually or automatically provisioned on a PLR 392 to enable the PLR to send traffic to a protector, in the event of an 393 egress PE failure. This LSP is referred to as a bypass LSP. The 394 bypass LSP MUST be a LSP with ultimate hop popping (UHP) [RFC 3031]. 395 That is, the protector MUST assign an un-reserved label to the bypass 396 LSP. When the protector PE receives VPN packets on the bypass LSP 397 from a PLR, it MUST rely on the bypass LSP's UHP label to determine 398 the context-specific label space to forward the packets. 400 5.5.1. RSVP-TE Signaled Bypass LSP and Backup LSP 402 If a bypass LSP is an RSVP-TE signaled LSP, its destination MUST be 403 the context identifier of the protected VPN prefix. The path taken 404 by the bypass LSP MAY be statically configured or dynamically 405 computed by CSPF. The signaling of the bypass LSP MUST be triggered 406 by the "local protection desired" and "node protection desired" bits 407 in SESSION_ATTRIBUTE of Path message of the transport LSP [RFC 2205, 408 RFC 3209, RFC 4090]. After the bypass LSP is established, the PLR 409 MUST set the "local protection available" and "node protection" bits 410 in RRO of Resv message of the transport LSP. The protector MUST 411 terminate the backup LSP as an egress. Once the local repair takes 412 effect, the PLR MUST set the "local protection in use" bit in RRO of 413 Resv message of the transport LSP. 415 5.5.2. LDP Signaled Bypass LSP 417 If it is LDP LSP then LDP FEC for this LSP MUST be the context 418 identifier of the protected segment. Prefix LFA with node protection 419 can be used for bypass LSP computation. 421 6. Egress node Failure 423 This section summarizes the procedures egress protection described 424 above section for completeness. A Egress PE and a protector both 425 advertise the context identifier of a protected prefixes in IGP as a 426 stub link or stub router, with the egress PE advertising a lower 427 metric and protector with maximum metric. The PLR establishes a UHP 428 bypass LSP to the protector. The destination address of the bypass 429 LSP is the context identifier. The protector programs forwarding 430 state in such a way that packets received on the bypass LSP will be 431 forwarded based on VPN label in the context table, and prefix lookup 432 in VPN context table. The context table identified by the UHP label 433 of the bypass LSP, i.e. the context identifier. 435 When the penultimate Hop router receives a VPN packet from the MPLS 436 network, if the egress PE is down, the PLR tunnels the packet through 437 the bypass LSP to the protector. The protector PE identifies the 438 forwarding context of the egress PE based on the top label of the 439 packet which is the UHP label of the bypass LSP. Then forwards 440 protector the packet based on a second label lookup in the protected 441 PE's context label space followed by layer-3 lookup in the VPN 442 context table. These UHP label, context table label and layer-3 443 lookup results in forwarding the packet to the site or send it to 444 alternate egress PE based on protector model. 446 For E.g. In topology-1 RR is act as Protector and PE5 required 447 protection for red, blue site2 prefixes. As red, blue site2 VPN 448 prefixes advertised with context-identifier, the protector set up the 449 forwarding table for prefixes from site2 with alternative egress PE 450 as nexthop. When PLR detects PE5 failure it send to protector 451 through bypass LSP. In protector the top label identify the context 452 space table. VPN label in the context table identify the VPN layer-3 453 forwarding table with contains site2 prefixes with alternate PE as 454 nexthop. A Layer-3 lookup gives mpls path to alternate egress PE and 455 protector forward packet to alternate egress PE and reach to the 456 site2. 458 7. Security Considerations 460 The security considerations discussed in RFC 5036, RFC 5331, RFC 461 3209, and RFC 4090 apply to this document. 463 8. Acknowledgements 465 This document leverages work done by Yakov Rekhter and several others 466 on LSP tail-end protection. Thanks to Nischal Sheth, Nitin Bahadur, 467 Yimin shen for their contribution. 469 9. References 471 9.1. Normative References 473 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 474 Label Assignment and Context-Specific Label Space", 475 RFC 5331, August 2008. 477 [RFC4364] Rekhter, Y. and E. Rosen, "BGP/MPLS IP Virtual Private 478 Networks (VPNs)", RFC 4364, February 2006. 480 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 481 Specification", RFC 5036, October 2007. 483 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 484 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 485 Functional Specification", RFC 2205, September 1997. 487 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 488 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 489 Tunnels", RFC 3209, December 2001. 491 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 492 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 493 May 2005. 495 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 496 (GMPLS) Signaling Functional Description", RFC 3471, 497 January 2003. 499 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 500 Label Switching Architecture", RFC 3031, January 2001. 502 [LDP-UPSTREAM] 503 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 504 for LDP", draft-ietf-mpls-ldp-upstream (work in progress), 505 2011. 507 [RSVP-NON-PHP-OOB] 508 Ali, A., Swallow, Z., and R. Aggarwal, "Non PHP Behavior 509 and out-of-band mapping for RSVP-TE LSPs", 510 draft-ietf-mpls-rsvp-te-no-php-oob-mapping (work in 511 progress), 2011. 513 9.2. Informative References 515 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 516 Networks", RFC 5920, July 2010. 518 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 519 IP Fast Reroute: Loop-Free Alternates", RFC 5920, 520 September 2008. 522 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 523 RFC 5714, January 2010. 525 Authors' Addresses 527 Jeyananth Minto Jeganathan 528 Juniper Networks 529 1194 N Mathilda Avenue 530 Sunnyvale, CA 94089 531 USA 533 Email: minto@juniper.net 535 Maciek Konstantynowicz 536 Juniper Networks 537 1194 N Mathilda Avenue 538 Sunnyvale, CA 94089 539 USA 541 Email: maciek@juniper.net 542 Hannes Gredler 543 Juniper Networks 544 1194 N Mathilda Avenue 545 Sunnyvale, CA 94089 546 USA 548 Email: hannes@juniper.net 550 Juniper Networks