idnits 2.17.1 draft-ietf-teas-lsp-attribute-ro-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 (March 01, 2015) is 3316 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: 'I-D.ietf-teas-rsvp-te-srlg-collect' is defined on line 547, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-wson-signaling-09 == Outdated reference: A later version (-05) exists of draft-ietf-teas-rsvp-te-li-lb-04 == Outdated reference: A later version (-08) exists of draft-ietf-teas-rsvp-te-srlg-collect-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS C. Margaria, Ed. 3 Internet-Draft Juniper 4 Intended status: Standards Track G. Martinelli 5 Expires: September 2, 2015 Cisco 6 S. Balls 7 B. Wright 8 Metaswitch 9 March 01, 2015 11 LSP Attribute in ERO 12 draft-ietf-teas-lsp-attribute-ro-03 14 Abstract 16 RFC5420 extends RSVP-TE to specify or record generic attributes which 17 apply to the whole of the path of an Label Switched Path (LSP). This 18 document defines an extension to the RSVP Explicit Route Object (ERO) 19 and Record Route Object (RRO) objects to allow it to specify or 20 record generic attributes which apply to a given hop. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 2, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. ERO Hop Attributes Subobject . . . . . . . . . . . . . . . . 3 59 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. HOP Attributes TLVs . . . . . . . . . . . . . . . . . . . 4 61 2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. RRO Hop Attributes Subobject . . . . . . . . . . . . . . . . 5 63 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2.1. Subobject Presence Rule . . . . . . . . . . . . . . . 6 66 3.2.2. Reporting Compliance with ERO Hop Attributes . . . . 6 67 3.2.3. Compatibility with RRO Attributes subobject . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. ERO Hop Attribute Subobject . . . . . . . . . . . . . . . 7 70 4.2. RRO LSP Attribute Subobject . . . . . . . . . . . . . . . 7 71 4.3. Existing Attribute Flags . . . . . . . . . . . . . . . . 7 72 4.4. Existing LSP Attribute TLVs . . . . . . . . . . . . . . . 8 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched 83 Paths (LSPs) can be route-constrained by making use of the Explicit 84 Route object (ERO) and related sub-objects as defined in [RFC3209], 85 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 86 Several documents have identified the need for attributes that can be 87 targeted at specific hops in the path of an LSP, including [RFC6163], 88 [I-D.ietf-ccamp-wson-signaling], [I-D.ietf-teas-rsvp-te-li-lb] or 89 [I-D.ali-ccamp-rc-objective-function-metric-bound]. This document 90 provides a generic mechanism for use by these other documents. 92 RSVP already supports generic extension of LSP Attributes in 93 [RFC5420]. In order to support current and future ERO constraint 94 extensions this document provides a mechanism to define per-Hop 95 attributes. 97 The document describes a generic mechanism for carrying information 98 related to specific nodes when signaling an LSP. This document does 99 not restrict what that information can be used for. The defined 100 approach builds on LSP Attributes defined in [RFC5420], and enables 101 attributes to be expressed in ERO and Secondary Explicit Route object 102 (SERO) objects. A new ERO sub-object is defined, containing a list 103 of generic per-Hop attributes. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. ERO Hop Attributes Subobject 113 The ERO Hop Attributes subobject MAY be carried in the ERO or SERO 114 object if they are present. The subobject uses the standard format 115 of an ERO subobject. 117 2.1. Encoding 119 The length is variable and content is a list of HOP Attributes TLVs 120 defined in Section 2.2. The size of the ERO sub-object limits the 121 size of the attribute TLV to 250 bytes. The typical size of 122 currently defined and forthcoming LSP_ATTRIBUTE TLVs applicable to a 123 specific hop (WSON_SIGNALING, Objective Function (OF) and Metric) is 124 not foreseen to exceed this limit. 126 The ERO Hop Attributes subobject is defined as follows: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |L| Type | Length | Reserved |R| 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 // Attributes TLVs // 135 | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 The L, Type and Length parameters are as defined in [RFC3209] 139 Section 4.3.3. The L bit MUST be set to 0. The Type for the ERO Hop 140 Attributes subobject is TBA by IANA. The attributes TLV are encoded 141 as defined in Section 2.2. 143 Reserved Reserved, MUST be set to 0 when the subobject is inserted 144 in the ERO, MUST NOT be changed when a node processes the ERO and 145 MUST be ignored on the node addressed by the preceding ERO 146 subobjects. 148 R This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE 149 semantic defined in [RFC5420]. When set it indicates required hop 150 attributes to be processed by the node. When cleared, it 151 indicates that the hop attributes are not required as described in 152 Section 2.3. 154 Attributes TLVs The TLVs as defined in Section 2.2. 156 2.2. HOP Attributes TLVs 158 ERO Attributes carried by the new objects defined in this document 159 are encoded within TLVs. One or more TLVs MAY be present in each 160 object. There are no ordering rules for TLVs, and interpretation 161 SHOULD NOT be placed on the order in which TLVs are received. The 162 TLV format is defined in [RFC5420] Section 3. 164 The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO 165 Hop Attributes Subobject. Flags set in the an Attribute Flags TLV 166 [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be 167 interpreted in the context of the received ERO. Only a subset of 168 defined flags are defined as valid for use in Attribute Flags TLV 169 carried in a ERO Hop Attributes Subobject. Invalid flags SHALL be 170 silently ignored. Unknown flags SHOULD trigger the generation of a 171 PathErr with Error Code "Unknown Attributes Bit" as defined in 172 [RFC5420] Section 5.2. The set of valid flags are defined in 173 Section 4.3. 175 2.3. Procedures 177 As described in [RFC3209] and [RFC3473] the ERO is managed as a list 178 where each hop information starts with a subobject identifying an 179 abstract node or link. The ERO Hop Attributes subobject MAY be 180 appended after any of the existing subobjects defined in [RFC3209], 181 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 182 Several ERO Hop Attributes subobject MAY be present, for each hop. 184 Document defining specific Hop attribute TLV has to describe after 185 which kind of subobject they are valid and if TLV modification rules 186 applies. For instance, subobject presence rules can be defined by 187 describing rules similar to [RFC4990] Section 6.1. 189 If a node is processing an ERO Hop Attributes subobject and does not 190 support handling of the subobject it will behave as described in 192 [RFC3209] when an unrecognized ERO subobject is encountered. This 193 node will return a PathErr with error code "Routing Error" and error 194 value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object 195 included, truncated (on the left) to the offending unrecognized 196 subobject. 198 When the R bit is set a node MUST examine the attribute TLV present 199 in the subobject following the rules described in [RFC5420] 200 Section 5.2. When the R bit is not set a node MUST examine the 201 attribute TLV present in the subobject following the rules described 202 in [RFC5420] Section 4.2. 204 A node processing an ERO Hop Attributes subobject with an HOP 205 Attributes TLV longer than the ERO subobject SHOULD return a PathErr 206 with error code "Routing Error" and error value "Bad EXPLICIT_ROUTE 207 object" with the EXPLICIT_ROUTE object included, truncated (on the 208 left) to the offending malformed subobject. A processing node MUST 209 NOT originates a HOP Attributes TLV longer than the ERO HOP 210 Attributes Subobject. The processing of the Hop attribute TLVs 211 SHOULD be described in the documents defining them. 213 3. RRO Hop Attributes Subobject 215 In some cases it is important to determine if an OPTIONAL Hop 216 attribute has been processed by a node. 218 3.1. Encoding 220 The RRO Hop Attributes subobject MAY be carried in the RECORD_ROUTE 221 object if it is present. The subobject uses the standard format of 222 an RRO subobject. 224 The RRO Hop Attributes subobject is defined as follows: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Length | Reserved | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 // Attributes TLVs // 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 The Type and Length parameters are as defined in [RFC3209] 237 Section 4.4.1. The Type for the RRO Hop Attributes subobject is TBA 238 by IANA. The attributes TLV are encoded as defined in Section 2.2. 240 Reserved Reserved, MUST be set to 0 when the subobject is inserted 241 in the RRO, MUST NOT be changed when a node process the RRO and 242 MUST be ignored on the node addressed by the preceding RRO 243 subobjects. 245 Attributes TLVs The processed or additional HOP Attributes, using 246 the format defined in Section 2.2. 248 3.2. Procedures 250 3.2.1. Subobject Presence Rule 252 The RRO rules defined in [RFC3209] are not changed. The RRO Hop 253 Attributes subobject MUST be pushed after the RRO Attributes 254 subobject (if present) defined in [RFC5420]. The RRO Hop Attributes 255 subobject MAY be present between a pair of subobjects identifying 256 Label Switching Router (LSR) or links. Unless local policy apply all 257 such subobjects SHOULD be forwarded unmodified by transit LSRs. 259 It is noted that a node (e.g., a domain edge node) MAY edit the RRO 260 to prune/modify the RRO, including the RRO Hop Attribute subobject 261 before forwarding due to confidentiality policy or other reasons (for 262 instance RRO size reduction). 264 3.2.2. Reporting Compliance with ERO Hop Attributes 266 To report that an ERO Hop attribute has been considered, or to report 267 an additional attribute, an LSR MAY add a RRO Hop Attributes 268 subobject with the HOP Attribute TLV which describes the attribute to 269 be reported. The requirement to report compliance MUST be specified 270 in the document that defines the usage of an Hop attribute. 272 3.2.3. Compatibility with RRO Attributes subobject 274 The RRO Hop Attributes subobject extends the capability of the RRO 275 Attributes subobject defined in [RFC5420] Section 7.2 by allowing the 276 node to report the attribute value. The mechanism defined in this 277 document is compatible with the RRO Attributes subobject using the 278 following procedures. 280 For LSP attributes signaled in the LSP_ATTRIBUTES or 281 LSP_REQUIRED_ATTRIBUTES objects, a node SHOULD use the RRO Attributes 282 subobject to report processing of those attributes. 284 For LSP attributes signaled in the ERO Hop Attributes subobject and 285 not in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects, if a 286 node desires to report the attributes, it SHOULD use the RRO Hop 287 Attributes subobject and SHOULD NOT use the RRO Attributes subobject. 289 Ingress nodes not supporting the RRO Hop Attributes subobject will 290 drop the information, as described in [RFC3209] Section 4.4.5. 292 A node MAY use the RRO Hop Attribute to report a LSP Attribute 293 signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only if the 294 following conditions are met: 296 The Attribute and its corresponding flag is allowed on both the 297 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes 298 subobject. 300 The document defining this Attribute specify this specific 301 behavior. 303 4. IANA Considerations 305 4.1. ERO Hop Attribute Subobject 307 IANA manages the "RSVP PARAMETERS" registry located at 308 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. 309 We request IANA to make an allocation in the Sub-object type 20 310 EXPLICIT_ROUTE - Type 1 Explicit Route registry. 312 This document introduces a new ERO sub-object: 314 Value Description Reference 315 ------ ----------------- ------------------------ 316 TBA Hop Attributes This document, Section 2 318 4.2. RRO LSP Attribute Subobject 320 IANA manages the "RSVP PARAMETERS" registry located at 321 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. 322 We request IANA to make an allocation in the Sub-object type 21 323 ROUTE_RECORD - Type 1 Route Record registry. We request the value to 324 be the same as Section 4.1. 326 This document introduces a new RRO sub-object: 328 Value Description Reference 329 ------ ----------------- ------------------------ 330 TBA Hop Attributes This document, Section 3 332 4.3. Existing Attribute Flags 334 IANA manages the "Attribute Flags" registry as part of the "RSVP-TE 335 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 336 te-parameters/rsvp-te-parameters.xml. A new column in the registry 337 is introduced by this document. This column indicates if the flag is 338 permitted to be used in a Attribute Flags TLV carried in the ERO Hop 339 Attributes Subobject. The column uses the heading "ERO" and the 340 registry is to be updated as follows: 342 Bit Name Attribute Attribute RRO ERO Reference 343 FlagsPath FlagsResv 344 0 End-to-end re-routing Yes No No No [RFC4920] 345 1 Boundary re-routing Yes No No No [RFC4920] 346 2 Segment-based re- Yes No No No [RFC4920] 347 routing 348 3 LSP Integrity Required Yes No No No [RFC4875] 349 4 Contiguous LSP Yes No Yes No [RFC5151] 350 5 LSP stitching desired Yes No Yes No [RFC5150] 351 6 Pre-Planned LSP Flag Yes No No No [RFC6001] 352 7 Non-PHP behavior flag Yes No Yes No [RFC6511] 353 8 OOB mapping flag Yes No Yes No [RFC6511] 354 9 Entropy Label Yes Yes No No [RFC6790] 355 Capability 356 10 OAM MEP entities Yes Yes Yes No [RFC7260] 357 desired 358 11 OAM MIP entities Yes Yes Yes No [RFC7260] 359 desired 360 12 SRLG collection Flag Yes Yes Yes No [I.D.draft- 361 (TEMPORARY - registered ietf-teas- 362 2014-09-11, expires rsvp-te- 363 2015-09-11) srlg-collect] 365 New allocation requests to this registry SHALL indicate the value to 366 be used in the ERO column. 368 4.4. Existing LSP Attribute TLVs 370 IANA manages the "RSVP-TE PARAMETERS" registry located at 371 http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- 372 parameters.xml. The "Attributes TLV Space" registry manage the 373 following attributes, as defined in [RFC5420]: 375 o TLV Type (T-field value) 377 o TLV Name 379 o Whether allowed on LSP_ATTRIBUTES object 381 o Whether allowed on LSP_REQUIRED_ATTRIBUTES object 383 We request IANA to add the following information for each TLV in the 384 RSVP TLV type identifier registry. 386 o Whether allowed on LSP Hop Attributes ERO subobject 388 The existing registry is modified for existing TLVs as follows: The 389 following abbreviation are used in the table: 391 LSP_A Whether allowed on LSP_ATTRIBUTES object. 393 LSP_RA Whether allowed on LSP_REQUIRED_ATTRIBUTES object. 395 HOP_A Whether allowed on LSP Hop Attributes subobject. 397 T Name LSP_A LSP_RA HOP_A Ref. 398 - --------------------- ----- ------ ----- -------- 399 1 Attribute Flags Yes Yes Yes [RFC5420] 400 2 Service ID TLV Yes No No [RFC6060] 401 3 OAM Configuration TLV Yes Yes No [RFC7260] 403 5. Security Considerations 405 This document adds new subobject in the EXPLICIT_ROUTE and the 406 ROUTE_RECORD object carried in RSVP message used in MPLS and GMPLS 407 signaling. It builds on mechanism defined in [RFC3209] and [RFC5420] 408 and does not introduce any new security. The existing security 409 considerations described in [RFC2205], [RFC3209], [RFC3473] and 410 [RFC5420] do apply. 412 As any RSVP-TE signaling request, the procedures defined in this 413 document permit the transfer and reporting of functional preferences 414 on specific node. The mechanism added in this document does allow 415 more control of LSP attributes at a given node. As other inputs, a 416 node SHOULD check the Hop Attributes against his policies and 417 admission procedures. A node MAY reject the message using existing 418 RSVP error code like "Policy Control Failure" or "Admission Control 419 Failure". The node MAY also, depending on the specific TLV 420 procedures, modify the requested attribute. This can reveal 421 information about the LSP request and status to anyone with 422 unauthorized access. The mechanism described in this document do not 423 contribute to this issue, which can be only resolved by encrypting 424 the content of the whole signaling message. 426 In addition the reporting of attributes using the RRO can reveal 427 details about the node that the operator wishes to remains 428 confidential. The same strategy and policies that apply to other RRO 429 subobjects also apply to this new mechanism. It is RECOMMENDED that 430 domain boundary policies take the releasing of RRO hop attributes 431 into consideration. 433 6. Acknowledgments 435 The authors would like to thanks Lou Berger for his directions and 436 Attila Takacs for inspiring this 437 [I-D.kern-ccamp-rsvpte-hop-attributes]. The authors also thanks Dirk 438 Schroetter for his contribution to the initial versions of the 439 documents (version -00 up to -02). 441 7. References 443 7.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 449 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 450 Functional Specification", RFC 2205, September 1997. 452 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 453 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 454 Tunnels", RFC 3209, December 2001. 456 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 457 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 458 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 460 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 461 in Resource ReSerVation Protocol - Traffic Engineering 462 (RSVP-TE)", RFC 3477, January 2003. 464 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 465 "GMPLS Segment Recovery", RFC 4873, May 2007. 467 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 468 Extension to Resource ReserVation Protocol-Traffic 469 Engineering (RSVP-TE)", RFC 4874, April 2007. 471 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 472 "Extensions to Resource Reservation Protocol - Traffic 473 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 474 Switched Paths (LSPs)", RFC 4875, May 2007. 476 [RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and 477 G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS 478 RSVP-TE", RFC 4920, July 2007. 480 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 481 "Label Switched Path Stitching with Generalized 482 Multiprotocol Label Switching Traffic Engineering (GMPLS 483 TE)", RFC 5150, February 2008. 485 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 486 MPLS and GMPLS Traffic Engineering -- Resource Reservation 487 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 488 5151, February 2008. 490 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 491 Ayyangarps, "Encoding of Attributes for MPLS LSP 492 Establishment Using Resource Reservation Protocol Traffic 493 Engineering (RSVP-TE)", RFC 5420, February 2009. 495 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 496 Topology Confidentiality in Inter-Domain Path Computation 497 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 499 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 500 Reservation Protocol (RSVP) Extensions for Path Key 501 Support", RFC 5553, May 2009. 503 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 504 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 505 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 506 MRN)", RFC 6001, October 2010. 508 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 509 "Generalized Multiprotocol Label Switching (GMPLS) Control 510 of Ethernet Provider Backbone Traffic Engineering (PBB- 511 TE)", RFC 6060, March 2011. 513 [RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate 514 Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE 515 Label Switched Paths", RFC 6511, February 2012. 517 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 518 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 519 RFC 6790, November 2012. 521 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 522 Extensions for Operations, Administration, and Maintenance 523 (OAM) Configuration", RFC 7260, June 2014. 525 7.2. Informative References 527 [I-D.ali-ccamp-rc-objective-function-metric-bound] 528 Ali, Z., Swallow, G., Filsfils, C., Fang, L., Kumaki, K., 529 Kunze, R., Ceccarelli, D., and X. Zhang, "Resource 530 ReserVation Protocol-Traffic Engineering (RSVP-TE) 531 Extension for Signaling Objective Function and Metric 532 Bound", draft-ali-ccamp-rc-objective-function-metric- 533 bound-05 (work in progress), February 2014. 535 [I-D.ietf-ccamp-wson-signaling] 536 Bernstein, G., Xu, S., Lee, Y., Martinelli, G., and H. 537 Harai, "Signaling Extensions for Wavelength Switched 538 Optical Networks", draft-ietf-ccamp-wson-signaling-09 539 (work in progress), September 2014. 541 [I-D.ietf-teas-rsvp-te-li-lb] 542 Dong, J., Chen, M., Li, Z., and D. Ceccarelli, "GMPLS 543 RSVP-TE Extensions for Lock Instruct and Loopback", draft- 544 ietf-teas-rsvp-te-li-lb-04 (work in progress), February 545 2015. 547 [I-D.ietf-teas-rsvp-te-srlg-collect] 548 Zhang, F., Dios, O., Li, D., Margaria, C., Hartley, M., 549 and Z. Ali, "RSVP-TE Extensions for Collecting SRLG 550 Information", draft-ietf-teas-rsvp-te-srlg-collect-00 551 (work in progress), December 2014. 553 [I-D.kern-ccamp-rsvpte-hop-attributes] 554 Kern, A. and A. Takacs, "Encoding of Attributes of LSP 555 intermediate hops using RSVP-TE", draft-kern-ccamp-rsvpte- 556 hop-attributes-00 (work in progress), October 2009. 558 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 559 Addresses in Generalized Multiprotocol Label Switching 560 (GMPLS) Networks", RFC 4990, September 2007. 562 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 563 GMPLS and Path Computation Element (PCE) Control of 564 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 565 April 2011. 567 Authors' Addresses 568 Cyril Margaria (editor) 569 Juniper 570 200 Somerset Corporate Boulevard, , Suite 4001 571 Bridgewater, NJ 08807 572 USA 574 Email: cmargaria@juniper.net 576 Giovanni Martinelli 577 Cisco 578 via Philips 12 579 Monza 20900 580 IT 582 Phone: +39 039 209 2044 583 Email: giomarti@cisco.com 585 Steve Balls 586 Metaswitch 587 100 Church Street 588 Enfield EN2 6BQ 589 GB 591 Phone: +44 208 366 1177 592 Email: steve.balls@metaswitch.com 594 Ben Wright 595 Metaswitch 596 100 Church Street 597 Enfield EN2 6BQ 598 GB 600 Phone: +44 208 366 1177 601 Email: Ben.Wright@metaswitch.com