idnits 2.17.00 (12 Aug 2021) /tmp/idnits59967/draft-ietf-teas-lsp-attribute-ro-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 23, 2015) is 2609 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 597, but no explicit reference was found in the text == Outdated reference: draft-ietf-ccamp-wson-signaling has been published as RFC 7689 == Outdated reference: draft-ietf-teas-rsvp-te-li-lb has been published as RFC 7571 == Outdated reference: draft-ietf-teas-rsvp-te-srlg-collect has been published as RFC 8001 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 24, 2015 Cisco 6 S. Balls 7 B. Wright 8 Metaswitch 9 March 23, 2015 11 LSP Attribute in ERO 12 draft-ietf-teas-lsp-attribute-ro-05 14 Abstract 16 RFC5420 extends RSVP-TE to specify or record generic attributes which 17 apply to the whole of the path of a 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 24, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. RRO Hop Attributes Subobject . . . . . . . . . . . . . . . . 6 63 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. Subobject Presence Rule . . . . . . . . . . . . . . . 7 66 3.2.2. Reporting Compliance with ERO Hop Attributes . . . . 7 67 3.2.3. Compatibility with RRO Attributes subobject . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. ERO Hop Attribute Subobject . . . . . . . . . . . . . . . 8 70 4.2. RRO LSP Attribute Subobject . . . . . . . . . . . . . . . 8 71 4.3. Existing Attribute Flags . . . . . . . . . . . . . . . . 8 72 4.4. Existing LSP Attribute TLVs . . . . . . . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 7.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 is OPTIONAL. If used it is carried 114 in the ERO or SERO. The subobject uses the standard format of an ERO 115 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-1 by IANA. The attributes TLV are 141 encoded 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. Each object MAY contain one or more TLVs. 160 There are no ordering rules for TLVs, and interpretation SHOULD NOT 161 be placed on the order in which TLVs are received. The TLV format is 162 defined in [RFC5420] Section 3. 164 The Attribute Flags TLV defined in [RFC5420] are carried in an ERO 165 Hop Attributes Subobject. Flags set in the an Attribute Flags TLV 166 [RFC5420] carried in an 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 an 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 The presence and ordering rule of the Attribute Flags TLV in an ERO 176 Hop Attributes Subobject is defined by each Flag. A document 177 defining a Flag to be used in an Attribute Flags TLV carried in the 178 ERO Hop Attributes Subobject has to describe: 180 o after which kinds of ERO subobject the Flag is valid 182 o if ordering of the Flag and other ERO subobjects associated with 183 the same hop (e.g., Label subobjects) is significant, 185 o if ordering is significant, how the Flag is interpreted in 186 association with the preceding subobjects, 188 o any Flag modification rules that might apply. 190 2.3. Procedures 192 As described in [RFC3209] the ERO is managed as a list of subobjects 193 each identifying a specific entity, an abstract node or a link that 194 defines a waypoint in the network path. Identifying subobjects of 195 various types are defined in [RFC3209], [RFC3477], [RFC4873], 196 [RFC4874], [RFC5520] and [RFC5553]. 198 [RFC3473] modified the ERO list by allowing one or two Label 199 subobjects to be interposed in the list after a subobject identifying 200 a link. One or more ERO Hop Attributes subobjects applicable to a 201 particular hop MAY be inserted directly after any of the existing 202 identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873], 203 [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are 204 present for a hop, the ERO Hop Attributes subobject(s) MAY also be 205 inserted after the Label subobjects. 207 The attributes specified in an ERO Hop Attributes subobject apply to 208 the immediately preceding subobject(s) in the ERO subobject list. 210 A document defining a specific Hop Attribute TLV has to describe: 212 o after which kinds of ERO subobject they are valid , 214 o if ordering of the Hop Attributes subobject and other ERO 215 subobjects associated with the same hop (e.g., Label subobjects) 216 is significant, 218 o if ordering is significant, how the attribute is interpreted in 219 association with the preceding ERO subobjects, and 221 o any TLV modification rules that might apply. 223 For instance, subobject presence rules can be defined by describing 224 rules similar to [RFC4990] Section 6.1. 226 If a node is processing an ERO Hop Attributes subobject and does not 227 support handling of the subobject it will behave as described in 228 [RFC3209] when an unrecognized ERO subobject is encountered. This 229 node will return a PathErr with error code "Routing Error" and error 230 value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object 231 included, truncated (on the left) to the offending unrecognized 232 subobject. 234 When the R bit is set a node MUST examine the attribute TLV present 235 in the subobject following the rules described in [RFC5420] 236 Section 5.2. When the R bit is not set a node MUST examine the 237 attribute TLV present in the subobject following the rules described 238 in [RFC5420] Section 4.2. 240 A node processing an ERO Hop Attributes subobject with a HOP 241 Attributes TLV longer than the ERO subobject SHOULD return a PathErr 242 with error code "Routing Error" and error value "Bad EXPLICIT_ROUTE 243 object" with the EXPLICIT_ROUTE object included, truncated (on the 244 left) to the offending malformed subobject. A processing node MUST 245 NOT originates a HOP Attributes TLV longer than the ERO HOP 246 Attributes Subobject. The processing of the Hop attribute TLVs 247 SHOULD be described in the documents defining them. 249 3. RRO Hop Attributes Subobject 251 In some cases it is important to determine if an OPTIONAL Hop 252 attribute has been processed by a node. 254 3.1. Encoding 256 The RRO Hop Attributes subobject is OPTIONAL. If used it is carried 257 in the RECORD_ROUTE object. The subobject uses the standard format 258 of an RRO subobject. 260 The RRO Hop Attributes subobject is defined as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length | Reserved | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 // Attributes TLVs // 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 The Type and Length parameters are as defined in [RFC3209] 273 Section 4.4.1. The Type for the RRO Hop Attributes subobject is 274 TBA-2 by IANA. The attributes TLV are encoded as defined in 275 Section 2.2. 277 Reserved Reserved, MUST be set to 0 when the subobject is inserted 278 in the RRO, MUST NOT be changed when a node process the RRO and 279 MUST be ignored on the node addressed by the preceding RRO 280 subobjects. 282 Attributes TLVs The processed or additional HOP Attributes, using 283 the format defined in Section 2.2. 285 3.2. Procedures 287 3.2.1. Subobject Presence Rule 289 The RRO rules defined in [RFC3209] are not changed. The RRO Hop 290 Attributes subobject MUST be pushed after the RRO Attributes 291 subobject (if present) defined in [RFC5420]. The RRO Hop Attributes 292 subobject MAY be present between a pair of subobjects identifying 293 Label Switching Router (LSR) or links. Unless local policy apply all 294 such subobjects SHOULD be forwarded unmodified by transit LSRs. 296 It is noted that a node (e.g., a domain edge node) MAY edit the RRO 297 to prune/modify the RRO, including the RRO Hop Attribute subobject 298 before forwarding due to confidentiality policy or other reasons (for 299 instance RRO size reduction). 301 3.2.2. Reporting Compliance with ERO Hop Attributes 303 To report that an ERO Hop attribute has been considered, or to report 304 an additional attribute, an LSR can add a RRO Hop Attributes 305 subobject with the HOP Attribute TLV which describes the attribute to 306 be reported. The requirement to report compliance MUST be specified 307 in the document that defines the usage of a Hop attribute. 309 3.2.3. Compatibility with RRO Attributes subobject 311 The RRO Hop Attributes subobject extends the capability of the RRO 312 Attributes subobject defined in [RFC5420] Section 7.2 by allowing the 313 node to report the attribute value. The mechanism defined in this 314 document is compatible with the RRO Attributes subobject using the 315 following procedures. 317 For LSP attributes signaled in the LSP_ATTRIBUTES or 318 LSP_REQUIRED_ATTRIBUTES objects, a node SHOULD use the RRO Attributes 319 subobject to report processing of those attributes. 321 For LSP attributes signaled in the ERO Hop Attributes subobject and 322 not in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects, if a 323 node desires to report the attributes, it SHOULD use the RRO Hop 324 Attributes subobject and SHOULD NOT use the RRO Attributes subobject. 325 Ingress nodes not supporting the RRO Hop Attributes subobject will 326 drop the information, as described in [RFC3209] Section 4.4.5. 328 A node can use the RRO Hop Attribute to report an LSP Attribute 329 signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only if the 330 following conditions are met: 332 The Attribute and its corresponding flag is allowed on both the 333 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes 334 subobject. 336 The document defining this Attribute specify this specific 337 behavior. 339 4. IANA Considerations 341 4.1. ERO Hop Attribute Subobject 343 IANA manages the "RSVP PARAMETERS" registry located at 344 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. 345 We request IANA to make an allocation in the Sub-object type 20 346 EXPLICIT_ROUTE - Type 1 Explicit Route registry. 348 This document introduces a new ERO sub-object: 350 Value Description Reference 351 ------ ----------------- ------------------------ 352 TBA-1 Hop Attributes This document, Section 2 354 4.2. RRO LSP Attribute Subobject 356 IANA manages the "RSVP PARAMETERS" registry located at 357 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. 358 We request IANA to make an allocation in the Sub-object type 21 359 ROUTE_RECORD - Type 1 Route Record registry. We request the value to 360 be the same as Section 4.1. 362 This document introduces a new RRO sub-object: 364 Value Description Reference 365 ------ ----------------- ------------------------ 366 TBA-2 Hop Attributes This document, Section 3 368 4.3. Existing Attribute Flags 370 IANA manages the "Attribute Flags" registry as part of the "RSVP-TE 371 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 372 te-parameters/rsvp-te-parameters.xml. A new column in the registry 373 is introduced by this document. This column indicates if the flag is 374 permitted to be used in an Attribute Flags TLV carried in the ERO Hop 375 Attributes Subobject. The column uses the heading "ERO" and the 376 registry is to be updated as follows: 378 Bit Name Attribute Attribute RRO ERO Reference 379 FlagsPath FlagsResv 380 0 End-to-end re-routing Yes No No No [RFC4920] 381 This Document 382 1 Boundary re-routing Yes No No No [RFC4920] 383 This Document 384 2 Segment-based re- Yes No No No [RFC4920] 385 routing 386 This Document 387 3 LSP Integrity Required Yes No No No [RFC4875] 388 This Document 389 4 Contiguous LSP Yes No Yes No [RFC5151] 390 This Document 391 5 LSP stitching desired Yes No Yes No [RFC5150] 392 This Document 393 6 Pre-Planned LSP Flag Yes No No No [RFC6001] 394 This Document 395 7 Non-PHP behavior flag Yes No Yes No [RFC6511] 396 This Document 397 8 OOB mapping flag Yes No Yes No [RFC6511] 398 This Document 399 9 Entropy Label Yes Yes No No [RFC6790] 400 Capability 401 This Document 402 10 OAM MEP entities Yes Yes Yes No [RFC7260] 403 desired 404 This Document 405 11 OAM MIP entities Yes Yes Yes No [RFC7260] 406 desired 407 This Document 408 12 SRLG collection Flag Yes Yes Yes No [I.D.draft- 409 (TEMPORARY - registered ietf-teas- 410 2014-09-11, expires rsvp-te- 411 2015-09-11) srlg-collect] 412 This Document 414 New allocation requests to this registry SHALL indicate the value to 415 be used in the ERO column. 417 4.4. Existing LSP Attribute TLVs 419 IANA manages the "RSVP-TE PARAMETERS" registry located at 420 http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- 421 parameters.xml. The "Attributes TLV Space" registry manage the 422 following attributes, as defined in [RFC5420]: 424 o TLV Type (T-field value) 425 o TLV Name 427 o Whether allowed on LSP_ATTRIBUTES object 429 o Whether allowed on LSP_REQUIRED_ATTRIBUTES object 431 We request IANA to add the following information for each TLV in the 432 RSVP TLV type identifier registry. 434 o Whether allowed on LSP Hop Attributes ERO subobject 436 The existing registry is modified for existing TLVs as follows: The 437 following abbreviation are used in the table: 439 LSP_A Whether allowed on LSP_ATTRIBUTES object. 441 LSP_RA Whether allowed on LSP_REQUIRED_ATTRIBUTES object. 443 HOP_A Whether allowed on LSP Hop Attributes subobject. 445 T Name LSP_A LSP_RA HOP_A Ref. 446 - --------------------- ----- ------ ----- -------------- 447 1 Attribute Flags Yes Yes Yes [RFC5420] 448 This Document 449 2 Service ID TLV Yes No No [RFC6060] 450 This Document 451 3 OAM Configuration TLV Yes Yes No [RFC7260] 452 This Document 454 5. Security Considerations 456 This document adds new subobject in the EXPLICIT_ROUTE and the 457 ROUTE_RECORD object carried in RSVP message used in MPLS and GMPLS 458 signaling. It builds on mechanism defined in [RFC3209] and [RFC5420] 459 and does not introduce any new security. The existing security 460 considerations described in [RFC2205], [RFC3209], [RFC3473] and 461 [RFC5420] do apply. 463 As any RSVP-TE signaling request, the procedures defined in this 464 document permit the transfer and reporting of functional preferences 465 on specific node. The mechanism added in this document does allow 466 more control of LSP attributes at a given node. As other inputs, a 467 node SHOULD check the Hop Attributes against his policies and 468 admission procedures. A node MAY reject the message using existing 469 RSVP error code like "Policy Control Failure" or "Admission Control 470 Failure". The node MAY also, depending on the specific TLV 471 procedures, modify the requested attribute. This can reveal 472 information about the LSP request and status to anyone with 473 unauthorized access. The mechanism described in this document do not 474 contribute to this issue, which can be only resolved by encrypting 475 the content of the whole signaling message. 477 In addition the reporting of attributes using the RRO can reveal 478 details about the node that the operator wishes to remains 479 confidential. The same strategy and policies that apply to other RRO 480 subobjects also apply to this new mechanism. It is RECOMMENDED that 481 domain boundary policies take the releasing of RRO hop attributes 482 into consideration. 484 6. Acknowledgments 486 The authors would like to thanks Lou Berger for his directions and 487 Attila Takacs for inspiring this 488 [I-D.kern-ccamp-rsvpte-hop-attributes]. The authors also thanks Dirk 489 Schroetter for his contribution to the initial versions of the 490 documents (version -00 up to -02). 492 7. References 494 7.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 500 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 501 Functional Specification", RFC 2205, September 1997. 503 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 504 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 505 Tunnels", RFC 3209, December 2001. 507 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 508 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 509 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 511 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 512 in Resource ReSerVation Protocol - Traffic Engineering 513 (RSVP-TE)", RFC 3477, January 2003. 515 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 516 "GMPLS Segment Recovery", RFC 4873, May 2007. 518 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 519 Extension to Resource ReserVation Protocol-Traffic 520 Engineering (RSVP-TE)", RFC 4874, April 2007. 522 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 523 "Extensions to Resource Reservation Protocol - Traffic 524 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 525 Switched Paths (LSPs)", RFC 4875, May 2007. 527 [RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and 528 G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS 529 RSVP-TE", RFC 4920, July 2007. 531 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 532 "Label Switched Path Stitching with Generalized 533 Multiprotocol Label Switching Traffic Engineering (GMPLS 534 TE)", RFC 5150, February 2008. 536 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 537 MPLS and GMPLS Traffic Engineering -- Resource Reservation 538 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 539 5151, February 2008. 541 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 542 Ayyangarps, "Encoding of Attributes for MPLS LSP 543 Establishment Using Resource Reservation Protocol Traffic 544 Engineering (RSVP-TE)", RFC 5420, February 2009. 546 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 547 Topology Confidentiality in Inter-Domain Path Computation 548 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 550 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 551 Reservation Protocol (RSVP) Extensions for Path Key 552 Support", RFC 5553, May 2009. 554 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 555 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 556 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 557 MRN)", RFC 6001, October 2010. 559 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 560 "Generalized Multiprotocol Label Switching (GMPLS) Control 561 of Ethernet Provider Backbone Traffic Engineering (PBB- 562 TE)", RFC 6060, March 2011. 564 [RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate 565 Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE 566 Label Switched Paths", RFC 6511, February 2012. 568 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 569 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 570 RFC 6790, November 2012. 572 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 573 Extensions for Operations, Administration, and Maintenance 574 (OAM) Configuration", RFC 7260, June 2014. 576 7.2. Informative References 578 [I-D.ali-ccamp-rc-objective-function-metric-bound] 579 Ali, Z., Swallow, G., Filsfils, C., Fang, L., Kumaki, K., 580 Kunze, R., Ceccarelli, D., and X. Zhang, "Resource 581 ReserVation Protocol-Traffic Engineering (RSVP-TE) 582 Extension for Signaling Objective Function and Metric 583 Bound", draft-ali-ccamp-rc-objective-function-metric- 584 bound-05 (work in progress), February 2014. 586 [I-D.ietf-ccamp-wson-signaling] 587 Bernstein, G., Xu, S., Lee, Y., Martinelli, G., and H. 588 Harai, "Signaling Extensions for Wavelength Switched 589 Optical Networks", draft-ietf-ccamp-wson-signaling-10 590 (work in progress), March 2015. 592 [I-D.ietf-teas-rsvp-te-li-lb] 593 Dong, J., Chen, M., Li, Z., and D. Ceccarelli, "GMPLS 594 RSVP-TE Extensions for Lock Instruct and Loopback", draft- 595 ietf-teas-rsvp-te-li-lb-05 (work in progress), March 2015. 597 [I-D.ietf-teas-rsvp-te-srlg-collect] 598 Zhang, F., Dios, O., Li, D., Margaria, C., Hartley, M., 599 and Z. Ali, "RSVP-TE Extensions for Collecting SRLG 600 Information", draft-ietf-teas-rsvp-te-srlg-collect-00 601 (work in progress), December 2014. 603 [I-D.kern-ccamp-rsvpte-hop-attributes] 604 Kern, A. and A. Takacs, "Encoding of Attributes of LSP 605 intermediate hops using RSVP-TE", draft-kern-ccamp-rsvpte- 606 hop-attributes-00 (work in progress), October 2009. 608 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 609 Addresses in Generalized Multiprotocol Label Switching 610 (GMPLS) Networks", RFC 4990, September 2007. 612 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 613 GMPLS and Path Computation Element (PCE) Control of 614 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 615 April 2011. 617 Authors' Addresses 619 Cyril Margaria (editor) 620 Juniper 621 200 Somerset Corporate Boulevard, , Suite 4001 622 Bridgewater, NJ 08807 623 USA 625 Email: cmargaria@juniper.net 627 Giovanni Martinelli 628 Cisco 629 via Philips 12 630 Monza 20900 631 IT 633 Phone: +39 039 209 2044 634 Email: giomarti@cisco.com 636 Steve Balls 637 Metaswitch 638 100 Church Street 639 Enfield EN2 6BQ 640 GB 642 Phone: +44 208 366 1177 643 Email: steve.balls@metaswitch.com 645 Ben Wright 646 Metaswitch 647 100 Church Street 648 Enfield EN2 6BQ 649 GB 651 Phone: +44 208 366 1177 652 Email: Ben.Wright@metaswitch.com