idnits 2.17.1 draft-margaria-ccamp-label-set-ero-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 238 has weird spacing: '... Type x Lab...' == Line 348 has weird spacing: '... Type x...' -- The document date (March 03, 2012) is 4436 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 541, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-gmpls-aps-req' is defined on line 580, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pce-gmpls-aps-req-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP C. Margaria, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track R. Casellas 5 Expires: September 4, 2012 CTTC 6 O. Gonzalez de Dios 7 Telefonica Investigacion y 8 Desarrollo 9 March 03, 2012 11 Expressing Label Set in ERO 12 draft-margaria-ccamp-label-set-ero-00 14 Abstract 16 The paths chosen by Generalized MPLS (GMPLS) Traffic Engineering (TE) 17 Label Switched Paths (LSPs) can be constrained using the Explicit 18 Route (ERO) object and related sub-objects. Standard ERO sub-objects 19 can specify the Autonomous System (AS), LSR Node Ids, Numbered or 20 unnumbered TE links, downstream and upstream labels, and PCE path 21 keys thus restricting which resources are to be used by a TE-LSP. 23 The Explicit Label Control (ELC) in the explicit route object (ERO) 24 allows both terminating an LSP on a particular outgoing port and 25 label of an egress node, as well as restricting which label to use on 26 any hop along the path determined by the route. However, currently, 27 its not allowed to specify more than 2 labels (downstream and 28 upstream label), and it is not possible to specify, for a given 29 section or segment of a TE-LSP path, a set of labels to restrict 30 which label to be allocated from a Set of candidate labels. 32 This memo provides extensions to the RSVP-TE and PCEP protocols to 33 support Label Sets in the form of ERO sub-objects, being applicable 34 to ERO and ERO-like (IRO, RRO, XRO) sub-objects, extending the ELC 35 concept to a set of candidate labels. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 4, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 73 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 74 2. Solution overview . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Multiple consecutive Label ERO subobjects . . . . . . . . . . 7 76 4. Label Set ERO subobject . . . . . . . . . . . . . . . . . . . 8 77 4.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 8 78 5. LSP_ATTRIBUTE extensions . . . . . . . . . . . . . . . . . . . 10 79 5.1. TARGETED_LSP_ATTRIBUTE TLV . . . . . . . . . . . . . . . . 10 80 5.2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 13 81 6. Evaluation of proposed solution alternatives . . . . . . . . . 14 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 7.1. Label Set ERO subobject . . . . . . . . . . . . . . . . . 15 84 7.2. LSP_ATTRIBUTE . . . . . . . . . . . . . . . . . . . . . . 15 85 7.2.1. Attribute Flags . . . . . . . . . . . . . . . . . . . 15 86 7.2.2. Service ID TLV . . . . . . . . . . . . . . . . . . . . 15 87 7.2.3. Targeted LSP attribute TLV . . . . . . . . . . . . . . 16 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 18 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched 99 Paths (LSPs) can be route-constrained by making use of the Explicit 100 Route (ERO) object and related sub-objects as defined in [RFC3209], 101 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 102 In general, ERO sub-objects identify the resources to be used by a 103 GMPLS, and can be used to restrict, exclude (IRO/XRO), define (ERO) 104 or report (RRO) such resources. 106 The Explicit Label Control (ELC) in the explicit route object (ERO) 107 allows both terminating an LSP on a particular outgoing port and 108 label of an egress node, as well as restricting which label to use on 109 any hop along the path determined by the route. However, currently, 110 its not allowed to specify more than 2 labels (downstream and 111 upstream label), and it is not possible to specify, for a given 112 section or segment of a TE-LSP path, a set of labels to restrict 113 which label to be allocated from a Set of candidate labels. 115 On the other hand, [RFC3473] defines the RSVP-TE LABEL_SET object, 116 which can be used in a Path Message to restrict the choice of the 117 generalized label, allocated by the downstream node to a set of 118 labels. 120 Extending the semantics of the Explicit Label Control to a label set 121 and restricting / limiting the choice of label within a given Label 122 Set, while maintaining the applicability of ERO and ERO-like RSVP-TE 123 and PCEP objects can be beneficial in the following cases: 125 o To constrain and restrict the choice of a Label at a given port 126 (including egress port) to be selected from a set of labels but 127 without strictly enforcing a single value (for example, when 128 conveying a set of available labels due to hardware limitations 129 such as tunable wavelengths). 131 o Due to known label switching constraint on some section of the TE- 132 LSP path: explicitly specify the label constraint on a specific 133 link by requesting a Label Set to limit the choice of the label. 135 o To constraint a distributed wavelength assignment (D-WA) for a TE- 136 LSP DWDM transparent optical section 138 o To allow a PCE or any other centralized entity to indicate a set 139 of labels to be used in signaling, not only in the initial Label 140 set but in any hop along the path. 142 o To allow a Path Computation Client (PCC) to indicate, as an input 143 constraint when requesting a combined R&WA computation to a PCE, 144 which set of wavelengths are acceptable at a given TE link, 145 transparent segment or end-to-end path, depending on the label 146 (wavelength) continuity restrictions of the underlying data plane. 148 o To exclude (i.e., in a XRO object) a set of Labels from being 149 considered in a label allocation, reusing the efficient encoding 150 that has been proposed for Label sets and Label set ERO sub- 151 objects. 153 o To control resource sharing for pre-planned protecting LSP, where 154 one can indicate which labels should be shared in addition to the 155 PPRO disjointness constraints. 157 1.1. Contributing Authors 159 1.2. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119. 165 2. Solution overview 167 In order to support specifying several labels as a potential set of 168 labels to be used when allocating a label, several solutions are 169 applicable and described in this document: 171 Allowing several consecutive Label ERO subobjects in an ERO 172 object. 174 Defining a Label Set ERO subobject to be used in an ERO (and 175 similar) object. 177 Extending the LSP_ATTRIBUTES object with a new TLV targeting 178 attributes at a given node. 180 A short overview of each solution is provided in the next sections 181 and an evaluation of each one on is provided afterwards. 183 3. Multiple consecutive Label ERO subobjects 185 This approach would require relaxing the rules that define how Label 186 sub-objects are used within an ERO/XRO/RRO object, and notably in 187 what concerns Explicit Label Control. In particular, the procedure 188 described in [RFC3473] section 5.1.1 is modified as follows: 190 The following SHOULD NOT result in a "Bad EXPLICIT_ROUTE object" 191 errors: 193 For there to be two label subobjects with the same U-bit values 195 It is allowed to have several consecutive Label subobects with the 196 same U-bit values, which become equally valid alternatives for the 197 downstream label. 199 To support the label subobject, a node must check to see if one or 200 more sub-objects following its associated address/interface sub- 201 objects are label subobjects. If this is the case, the sub-objects 202 are examined: a RSVP-TE LABEL_SET object (Type 36) is constructed 203 with the values of the labels that have the U-bit cleared. This 204 LABEL_SET object MUST be included in the outgoing Path message and 205 MAY be splitted into several LABEL_SET objects (LABEL_SET for the 206 downstream direction). Note that this LABEL_SET does not replace the 207 existing LABEL_SET and MAY be merged with it. 209 The new Label_Set objects included in the Path message do not replace 210 existing Label_Set object. 212 If the U-bit of the subobject being examined is set (1), then the set 213 of value of the Label subobject with U bit set should be used to 214 restrict the choice of the upstream label associated with the 215 bidirectional LSP. If this label is not acceptable, a "Bad 216 EXPLICIT_ROUTE object" error SHOULD be generated. If the label is 217 acceptable, the assigned label is copied into a new Upstream_Label 218 object. This Upstream_Label object MUST be included on the 219 corresponding outgoing Path message. 221 4. Label Set ERO subobject 223 In this solution a new Label Set subobject is defined. 225 The Label Set ERO subobject is defined as follows: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |L| Type | Length |U| Reserved | C-Type(1) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Label Set | 233 | ... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 See [RFC3471] for a description of L,U and Label Set parameters. 238 Type x Label Set 240 Length The Length contains the total length of the subobject in 241 bytes, including the Type and Length fields. The Length is always 242 divisible by 4. 244 C-Type The C-Type of the included Label Object. Copied from the 245 Label Object. 247 4.1. Procedures 249 The Label Set subobject follows a similar procedure to the 250 aforementioned one that is used when several Label sub-objects are 251 allowed. The Label Set subobject must follow a subobject identifying 252 the link where the Label Set is applicable (a subobject containing a 253 IP address or an interface identifier) or a previous Label Set 254 subobject. Several Label Set subobject may be present. The 255 following SHOULD result in "bad EXPLICIT_ROUTE object" errors: 257 If the first Label Set subobject is not preceded by a subobject 258 containing an IP address or an interface identifier associated 259 with an output link 261 On unidirectional LSP setup, for there to be a label set subobject 262 with the U-bit set 264 It is not allowed to mix Label Set and Label subobject. 266 The following text is adapted from the Label subobject procedure 267 described in [RFC3473] 268 To support the label set subobject, a node must check to see if the 269 subobject following its associate address/interface is a label set 270 subobject. If it is, the following subobjects are examined. If the 271 U-bit of the subobject being examined is clear (0), then value of the 272 label set is copied into a a RSVP-TE LABEL_SET object (Type 36). One 273 LABEL_SET object MUST be included in the outgoing Path message. The 274 LABEL-SET object MAY be splitted into several LABEL_SET objects or 275 MAY be merged with the existing LABEL-SET objects of this LSP. 277 If the U-bit of the subobject being examined is set (1), then value 278 of the label set is used to choose the label to be used for upstream 279 traffic associated with the bidirectional LSP. If this label is not 280 acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. 281 If the label set is acceptable and a label assigned, the label is 282 copied into a new Upstream_Label object. This Upstream_Label object 283 MUST be included on the corresponding outgoing Path message. 285 After processing, the label set subobjects are removed from the ERO. 287 Note an implication of the above procedures is that the label set 288 subobject should never be the first subobject in a newly received 289 message. If the label subobject is the the first subobject an a 290 received ERO, then it SHOULD be treated as a "Bad strict node" error. 292 Procedures by which an LSR at the head-end of an LSP obtains the 293 information needed to construct the Label Set subobject are outside 294 the scope of this document. 296 5. LSP_ATTRIBUTE extensions 298 In order to indicate, at a given hop or interface within the ERO, a 299 set of candidate labels to be used when selecting the generalized 300 label, it is also possible to use LSP_ATTRIBUTE extensions [RFC5240] 301 . To this end, the procedure to generate the outgoing RSVP-TE Path 302 message LABEL_SET object from the information contained in the 303 LSP_ATTRIBUTE is similar conceptually to the previous ones. The 304 following new TLVs are required for this solution : 306 o a TLV indicating attributes for a node/interface (one per node/ 307 interface) 309 o This TLV will contain sub-TLV, here: 311 * Attribute Flag TLV 313 * A Label Set TLV 315 * Any Attribute TLV which are applicable to a specific Node/ 316 interface 318 A new flag should be defined for the Targeted LSP attribute, 319 requiring this will then depend in which object this is added. The 320 Label Set TLV also required a new flag, but it SHOULD NOT appear 321 directly in the LSP_ATTRIBUTE, this solution add TLVs that can be 322 scoped only to specific interface or node. The RRO subobject 323 attribute processing is not modified, a Node MAY report all the bits 324 from the Attribute flag TLV in LSP_ATTRIBUTES or/and 325 LSP_REQUIERED_ATTRIBUTES or/and the Attribute flag TLV in the 326 TARGETED_LSP_ATTRIBUTE TLV. 328 5.1. TARGETED_LSP_ATTRIBUTE TLV 330 A new TLV is introduced, the TARGETED_LSP_ATTRIBUTE TLV, which is 331 valid on Path message only in LSP_ATTRIBUTE and 332 LSP_REQUIRED_ATTRIBUTES Object. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | Identifier Type | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 ~ Identifier (Variable) ~ 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 // TLVs // 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Type x 350 Length The Length contains the total length of the subobject in 351 bytes, including the Type and Length fields. This length must be 352 a multiple of four and must be at least eight. 354 Identifier Type The type of identifier used, currently the following 355 types are defined: 357 0 IPv4 address 359 1 IPv6 address 361 2 Unnumbered address 363 Identifier Depending on the Identifier type this field contains: 365 IPv4 address A 32 bit IPv4 address 367 IPv6 address A 128 bit IPv6 Address 369 Unnumbered address A 64 bit field containing a 32 bit Node Id and 370 32 bit unnumbered address 372 TLVs A list of TLVs 374 An IPv4 Identifier type 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Length | Identifier Type=0 (IPv4) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | IPv4 address | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 // TLVs // 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 An IPv6 Identifier type 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type | Length | Identifier Type=1 (IPv6) | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 | IPv6 address | 396 | | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 // TLVs // 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 An Unnumbered interface identifier 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Length | Identifier Type=2 (Unnumbered)| 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Node Id | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Unnumbered interface id | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 // TLVs // 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 5.2. PCEP Extensions 422 This solution does not fit to existing PCEP object, One possible 423 solution would be to map the RSVP LSP_ATTRIBUTE logic to PCEP LSPA 424 object and define a set of LSPA TLVs carrying relevant LSP_ATTRIBUTE 425 TLVs. This is for further study. 427 6. Evaluation of proposed solution alternatives 429 The First two solutions would easily allow a centralized entity such 430 as a PCE or a NMS to add this per-hop constraints information but 431 would imply a greater impact to existing deployments. Let us note 432 that, in general, a PCE currently uses the existing ERO sub-objects 433 (with different semantics) in the following PCEP sub-objects. 435 o ERO - to indicate the result of a Path Computation given one or 436 more requests. 438 o IRO - to specify which elements, resources, etc. must be used in a 439 path computation. 441 o XRO - to specify which elements, resources, etc. must be excluded 442 in a path computation. 444 o RRO - to report of existing Paths 446 Making use of the LSP_ATTRIBUTES would reduce the impact on existing 447 deployment yet allow to mandate the support of the attribute if 448 desired, but will introduce several source for Label information. 450 7. IANA Considerations 452 7.1. Label Set ERO subobject 454 IANA is requested to make the following subobject allocations from 455 the "EXPLICIT_ROUTE Subobject Type" registry. 457 Sub-object type TBA 459 Name Label Set 461 Reference This document 463 7.2. LSP_ATTRIBUTE 465 IANA is request to add the following information for each TLV in the 466 RSVP TLV type identifier registry. 468 o Whether allowed on TARGETED_LSP_ATTRIBUTE TLV 470 The existing registry is modified for existing TLVs. 472 7.2.1. Attribute Flags 474 The new TLV type definition is as follow 476 o TLV Type = 1 478 o TLV Name = Attribute Flags TLV 480 o Allowed on LSP_ATTRIBUTES object 482 o Allowed on LSP_REQUIRED_ATTRIBUTES object 484 o Allowed on TARGETED_LSP_ATTRIBUTE TLV 486 7.2.2. Service ID TLV 488 The new TLV type definition is as follow 490 o TLV Type = 1 492 o TLV Name = Attribute Flags TLV 494 o Allowed on LSP_ATTRIBUTES object 495 o Not allowed on LSP_REQUIRED_ATTRIBUTES object 497 o Not allowed on TARGETED_LSP_ATTRIBUTE TLV 499 7.2.3. Targeted LSP attribute TLV 501 IANA is requested to make the following allocations from the RSVP 502 Attribute TLV Space registry. 504 o TLV Type = n 506 o TLV Name = Targeted LSP attribute TLV 508 o Allowed on LSP_ATTRIBUTES object 510 o Allowed on LSP_REQUIRED_ATTRIBUTES object 512 o Not allowed on TARGETED_LSP_ATTRIBUTE TLV 514 IANA is request to make the following allocation from the RSVP 515 Attribute Flags registry 517 Bit Name Attribute Flags Attribute Flags RRO Reference 518 No Path Resv 520 9 Targeted LSP Yes No Yes This 521 Attribute document 523 10 Label Set Yes No No This 524 document 526 8. Security Considerations 528 None. 530 9. Contributing Authors 531 10. Acknowledgments 533 The research leading to these results has received funding from the 534 European Community's Seventh Framework Program FP7/2007-2013 under 535 grant agreement no 247674. 537 11. References 539 11.1. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 545 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 546 Tunnels", RFC 3209, December 2001. 548 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 549 (GMPLS) Signaling Functional Description", RFC 3471, 550 January 2003. 552 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 553 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 554 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 556 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 557 in Resource ReSerVation Protocol - Traffic Engineering 558 (RSVP-TE)", RFC 3477, January 2003. 560 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 561 "GMPLS Segment Recovery", RFC 4873, May 2007. 563 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 564 Extension to Resource ReserVation Protocol-Traffic 565 Engineering (RSVP-TE)", RFC 4874, April 2007. 567 [RFC5240] Joshi, B. and R. Bijlani, "Protocol Independent Multicast 568 (PIM) Bootstrap Router MIB", RFC 5240, June 2008. 570 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 571 Topology Confidentiality in Inter-Domain Path Computation 572 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 574 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 575 Reservation Protocol (RSVP) Extensions for Path Key 576 Support", RFC 5553, May 2009. 578 11.2. Informative References 580 [I-D.ietf-pce-gmpls-aps-req] 581 Caviglia, D., Zhang, F., Ogaki, K., and T. Otani, 582 "Document:", draft-ietf-pce-gmpls-aps-req-05 (work in 583 progress), January 2012. 585 Authors' Addresses 587 Cyril Margaria (editor) 588 Nokia Siemens Networks 589 St Martin Strasse 76 590 Munich, 81541 591 Germany 593 Phone: +49 89 5159 16934 594 Email: cyril.margaria@nsn.com 596 Ramon Casellas 597 CTTC 598 Av. Carl Friedrich Gauss n.7 599 Castelldefels, Barcelona 600 Spain 602 Phone: +34 93 645 29 00 603 Email: ramon.casellas@cttc.es 605 Oscar Gonzalez de Dios 606 Telefonica Investigacion y Desarrollo 607 C/ Emilio Vargas 6 608 Madrid, 28043 609 Spain 611 Phone: +34 91 3374013 612 Email: ogondio@tid.es