idnits 2.17.1 draft-ietf-mpls-explicit-resource-control-bundle-10.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 130 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], [RFC2234], [RFC3936], [RFC3471], [RFC2119], [RFC3473], [RFC5420], [RFC3945], [RFC5920], [RFC3477], [RFC4201], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 284: '... address. A node MUST NOT push on a Co...' RFC 2119 keyword, line 291: '...stream and upstream interfaces MUST be...' RFC 2119 keyword, line 348: '... The following SHOULD result in "Bad...' RFC 2119 keyword, line 366: '... it MUST check if it represents ...' RFC 2119 keyword, line 371: '... object" error SHOULD be reported as...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2011) is 4749 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? 'RFC3209' on line 534 looks like a reference -- Missing reference section? 'RFC3473' on line 541 looks like a reference -- Missing reference section? 'RFC3945' on line 550 looks like a reference -- Missing reference section? 'RFC4201' on line 553 looks like a reference -- Missing reference section? 'RFC3471' on line 537 looks like a reference -- Missing reference section? 'RFC2119' on line 525 looks like a reference -- Missing reference section? 'RFC3477' on line 546 looks like a reference -- Missing reference section? 'RFC5420' on line 556 looks like a reference -- Missing reference section? 'RFC5920' on line 561 looks like a reference -- Missing reference section? 'RFC3936' on line 503 looks like a reference -- Missing reference section? 'RFC2205' on line 521 looks like a reference -- Missing reference section? 'RFC2234' on line 530 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Zamfir 3 Internet Draft Z. Ali 4 Intended status: Experimental Cisco Systems 5 Expires: October 26, 2011 D. Papadimitriou 6 Alcatel-Lucent 7 April 27, 2011 9 Component Link Recording and Resource Control for TE Links 11 draft-ietf-mpls-explicit-resource-control-bundle-10.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 26, 2011. 36 Abstract 38 Record Route is a useful administrative tool that has been used 39 extensively by the service providers. However, when TE links are 40 bundled, identification of label resource in Record Route object 41 (RRO) is not sufficient to determine the component link within a TE 42 link that is being used by a given LSP. In other words, when link 43 bundling is used, resource recording requires mechanisms to specify 44 the component link identifier, along with the TE link identifier and 45 Label. As it is not possible to record component link in the RRO, 46 this document defines the extensions to RSVP-TE [RFC3209] and 47 [RFC3473] to specify component link identifiers for resource 48 recording purposes. 50 Component Link Recording & Resource Control for TE Links April 27, 2011 52 This document also defines the Explicit Route object (ERO) 53 counterpart of the RRO extension. The ERO extensions are needed to 54 perform explicit label/resource control over bundled TE link. 55 Hence, this document defines the extensions to RSVP-TE [RFC3209] 56 and [RFC3473] to specify component link identifiers for explicit 57 resource control and recording over TE link bundles. 59 Table of Contents 61 1. Introduction................................................3 62 Conventions used in this document..............................4 63 2. Terminology.................................................4 64 3. LSP Resource Recording......................................4 65 3.1. Component Interface Identifier RRO Subobject...........5 66 3.2. Processing of Component Interface ID RRO Subobject.....6 67 4. Signaling Component Interface Identifier in ERO.............7 68 4.1. Component Interface ID ERO Subobject...................7 69 4.2. Processing of Component Interface ID ERO Subobject.....8 70 5. Backward Compatibility.....................................10 71 6. Security Considerations....................................10 72 7. IANA Considerations........................................10 73 8. References.................................................11 74 8.1. Normative References..................................11 75 9. Acknowledgments............................................12 76 10. Copyright.................................................13 78 Component Link Recording & Resource Control for TE Links April 27, 2011 80 1. Introduction 82 In GMPLS networks [RFC3945] where unbundled (being either Packet- 83 Switching Capable, Layer2-Switching Capable, Time Division 84 Multiplexing or Lambda-Switching Capable) Traffic Engineering (TE) 85 Links are used, one of the types of resources that an LSP originator 86 could control and record are the component links used by non- 87 neighboring nodes on the LSP path. The resource control and 88 recording is done by the use of the EXPLICIT_ROUTE object (ERO) and 89 RECORD_ROUTE object (RRO), respectively. 91 Link Bundling, introduced in [RFC4201], is used to improve routing 92 scalability by reducing the amount of TE related information that 93 need to be flooded and handled by IGP in a TE network. This is 94 accomplished by aggregating and abstracting the TE Link components. 95 In some cases the component link selection/recording within a TE 96 link is left as a local decision (ERO and RRO contains only TE 97 links). However there are cases when it is desirable for a non-local 98 (e.g., LSP head-end) node to make this selection. The use of such 99 information has found since so far three main applications (while 100 not excluding others unknown at the time of writing): diagnostic, 101 association of component specific attributes for which the bundled 102 information is too coarse (e.g., Shared Risk Link Groups) and thus 103 blocking SRLG-disjoint LSP establishment, allocation of labels at 104 network edges, and notification in case of failures. The latter is 105 useful when a single TE link interconnects two parts of the network. 106 In case one of its components fails notifying a complete TE link 107 failure leaves the network disconnected. In either case, it is 108 required to know which component link within a bundled TE link has 109 been used for a given LSP. For these cases, the TE Link and the 110 Label currently specified in the ERO/RRO are not enough and the 111 component link needs to be specified along with the label. In the 112 case of bi-directional Label Switched Paths (LSP) both upstream 113 and downstream information may be specified. Therefore, explicit 114 resource control and recording over a bundled TE link also requires 115 ability to specify a component link within the TE link. 117 Another important assumption of this document is that the identifier 118 space used for component link identification are unique for a given 119 node (following [RFC4201]). The reason stems as follows: most 120 experimental developments started with TE links composed by a single 121 component link and then only bundling was added by grouping them. 122 Component links where thus identified such that they could mimic the 123 behavior of TE link processing. This also justifies the experimental 124 status of this document. 126 This document defines extensions to and describes the use of RSVP-TE 128 Component Link Recording & Resource Control for TE Links April 27, 2011 130 [RFC3209], [RFC3471], [RFC3473] to specify the component link 131 identifier for resource recording and explicit resource control over 132 TE link bundles. Specifically, in this document, component interface 133 identifier RRO and ERO subobjects are defined to complement their 134 Label RRO and ERO counterparts. Furthermore, procedures for 135 processing component interface identifier RRO and ERO subobjects and 136 how they can co-exist with the Label RRO and ERO subobjects are 137 specified. 139 Conventions used in this document 141 In examples, "C:" and "S:" indicate lines sent by the client and 142 server respectively. 144 The key words "MUST", "MUST NoT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 In this document, these words will appear with that interpretation 149 only when in ALL CAPS. Lower case uses of these words are not to be 150 interpreted as carrying RFC 2119 significance. 152 In this document, the characters ">>" preceding an indented line(s) 153 indicates a compliance requirement statement using the key words 154 listed above. This convention aids reviewers in quickly identifying 155 or finding the explicit compliance requirements of this RFC. 157 2. Terminology 159 o) TE Link: Unless specified otherwise, it refers to a bundled 160 Traffic Engineering link as defined in [RFC4201]. Furthermore, the 161 terms TE Link and bundled TE Link are used interchangeably in this 162 document. 164 o) Component (interface) link: refers (locally) to a link that is 165 part of a bundled TE link as described in RFC4201. 167 o) Component Interface Identifier: Refers to an ID used to uniquely 168 identify a Component Interface. on a bundled link a combination of 169 is sufficient to unambiguously 170 identify the appropriate resources used by an LSP. The IDs used for 171 component link identification are unique for a given node [RFC4201]. 173 3. LSP Resource Recording 175 LSP Resource Recording refers to the ability to record the resources 176 used by an LSP. 178 Component Link Recording & Resource Control for TE Links April 27, 2011 180 The procedure for unbundled numbered TE links is described in 181 [RFC3209] and for unbundled unnumbered TE links in [RFC3477]. For 182 the purpose of recording LSP resources used over bundled TE Links, 183 the Component Interface Identifier RRO sub-object is introduced. 185 3.1. Component Interface Identifier RRO subobject 187 A new subobject of the Record Route object (RRO) is used to record 188 component interface identifier of a (bundled) TE Link. This 189 subobject has the following format: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |L| Type | Length |U| Reserved (must be zero) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 // IPv4, IPv6 or unnumbered Component Interface Identifier // 198 | . . . | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 L: 1 bit 203 This bit must be set to 0. 205 Type 207 Type 10 (TBD): Component Interface identifier IPv4 208 Type 11 (TBD): Component Interface identifier IPv6 209 Type 12 (TBD): Component Interface identifier Unnumbered 211 Length 213 Component Link Record. & Resource Control for TE Link Bundles 215 The Length contains the total length of the subobject in 216 bytes, including the Type and Length fields. The Length is 217 8 bytes for the Component Interface identifier IPv4 and 218 Component Interface identifier Unnumbered types. For 219 Component Interface identifier IPv6 type of sub-object, the 220 length field is 20 bytes. 222 U: 1 bit 224 This bit indicates the direction of the component interface. 225 It is set to 0 for the downstream interface. 226 It is set to 1 for the upstream interface and is only used for 227 bi-directional LSPs. 229 Component Link Recording & Resource Control for TE Links April 27, 2011 231 3.2. Processing of Component Interface identifier RRO Subobject 233 If a node desires component link recording, the "Component Link 234 Recording desired" flag (value TBD) should be set in the 235 LSP_ATTRIBUTES object, object that is defined in [RFC5420]. 237 Setting of "Component Link Recording desired" flag is independent of 238 the Label Recording flag in SESSION_ATTRIBUTE object as specified in 239 [RFC3209]. Nevertheless, the following combinations are valid: 241 1) If both Label and Component Link flags are clear, then neither 242 Labels nor Component Links are recorded. 244 2) If Label Recording flag is set and Component Link flag is 245 clear, then only Label Recording is performed as defined in 246 [RFC3209]. 248 3) If Label Recording flag is clear and Component Link flag is 249 set, then Component Link Recording is performed as defined in 250 this document. 252 4) If both Label Recording and Component Link flags are set, then 253 Label Recording is performed as defined in [RFC3209] and also 254 Component Link recording is performed as defined in this 255 document. 257 In most cases, a node initiates recording for a given LSP by adding 258 the RRO to the Path message. If the node desires Component Link 259 recording and if the outgoing TE link is bundled, then the initial 260 RRO contains the Component Link identifier (numbered or unnumbered) 261 as selected by the sender. As well, the Component Link Recording 262 desired flag is set in the LSP_ATTRIBUTE object. If the node also 263 desires label recording, it sets the Label_Recording flag in the 264 SESSION_ATTRIBUTE object. 266 When a Path message with the "Component Link Recording desired" flag 267 set is received by an intermediate node, if a new Path message is to 268 be sent for a downstream bundled TE link, the node adds a new 269 Component Link subobject to the RECORD_ROUTE object (RRO) and 270 appends the resulting RRO to the Path message before transmission. 271 Note also that, unlike Labels, Component Link identifiers are always 272 known on receipt of the Path message. 274 When the destination node of an RSVP session receives a Path message 275 with an RRO and the "Component Link Recording desired" flag set, 276 this indicates that the sender node needs TE route as well as 277 component link recording. The destination node initiates the RRO 279 Component Link Recording & Resource Control for TE Links April 27, 2011 281 process by adding an RRO to Resv messages. The processing mirrors 282 that of the Path messages. The Component Interface Record subobject 283 is pushed onto the RECORD_ROUTE object (RRO) prior to pushing on the 284 node"s IP address. A node MUST NOT push on a Component Interface 285 Record subobject without also pushing on the IP address or 286 unnumbered Interface Id subobject that identifies the TE Link. 288 When component interfaces are recorded for unidirectional LSPs, the 289 downstream interface is the one identified by the Component 290 Interface subobject. For bi-directional LSPs, component interface 291 RRO subobjects for both downstream and upstream interfaces MUST be 292 included. 294 4. Signaling Component Interface Identifier in ERO 296 4.1. Component Interface Identifier ERO subobject 298 A new oPTIoNAL subobject of the EXPLICIT_ROUTE object (ERO) is used 299 to specify component interface identifier of a bundled TE Link. 300 This Component Interface Identifier subobject has the following 301 format: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |L| Type | Length |U| Reserved (MUST be zero) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 // IPv4, IPv6 or unnumbered Component Interface Identifier // 310 | . . . | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 L: 1 bit 315 This bit must be set to 0. 317 Type 319 Type 10 (TBD): Component Interface identifier IPv4 320 Type 11 (TBD): Component Interface identifier IPv6 321 Type 12 (TBD): Component Interface identifier Unnumbered 323 Length 325 The Length contains the total length of the subobject in 326 bytes, including the Type and Length fields. The Length is 327 8 bytes for the Component Interface identifier types: IPv4 328 and Component Interface identifier Unnumbered. For Component 329 Interface identifier IPv6 type of sub-object, the length field 331 Component Link Recording & Resource Control for TE Links April 27, 2011 333 is 20 bytes. 335 U: 1 bit 337 This bit indicates the direction of the component interface. 338 It is 0 for the downstream interface. It is set to 1 for the 339 upstream interface and is only used for bi-directional LSPs. 341 4.2. Processing of Component Interface Identifier ERO Subobject 343 The Component Interface Identifier ERO subobject follows a subobject 344 containing the IP address, or the link identifier [RFC3477], 345 associated with the TE link on which it is to be used. It is used to 346 identify the component of a bundled TE Link. 348 The following SHOULD result in "Bad EXPLICIT_ROUTE object" error 349 being sent upstream by a node processing an ERO that contains the 350 Component Interface ID sub-object: 352 o) The first component interface identifier subobject is not 353 preceded by a sub-object containing an IPv4 or IPv6 address, or 354 an interface identifier [RFC3477], associated with a TE link. 356 o) The Component Interface Identifier ERO subobject follows a 357 subobject that has the L-bit set. 359 o) on unidirectional LSP setup, there is a Component Interface 360 Identifier ERO subobject with the U-bit set. 362 o) Two Component Interface Identifier ERO subobjects with the same 363 U-bit values exist. 365 If a node implements the component interface identifier subobject, 366 it MUST check if it represents a component interface in the bundled 367 TE Link specified in the preceding subobject that contains the 368 IPv4/IPv6 address or interface identifier of the TE Link. If the 369 content of the component interface identifier subobject does not 370 match a component interface in the TE link, a "Bad EXPLICIT_ROUTE 371 object" error SHOULD be reported as "Routing Problem" (error code 372 24). 374 If U-bit of the subobject being examined is cleared (0) and the 375 upstream interface specified in this subobject is acceptable, then 376 the value of the upstream component interface is translated locally 377 in the TLV of the IF_ID RSVP_HOP object [RFC3471]. The local 378 decision normally used to select the upstream component link is 379 bypassed except for local translation into the outgoing interface 380 identifier from the received incoming remote interface identifier. 382 Component Link Recording & Resource Control for TE Links April 27, 2011 384 If this interface is not acceptable, a "Bad EXPLICIT_ROUTE object" 385 error SHOULD be reported as "Routing Problem" (error code 24). 387 If the U-bit of the subobject being examined is set (1), then the 388 value represents the component interface to be used for upstream 389 traffic associated with the bidirectional LSP. Again, if this 390 interface is not acceptable or if the request is not one for a 391 bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD 392 be reported as "Routing Problem" (error code 24). otherwise, the 393 component interface IP address/ identifier is copied into a TLV sub- 394 object as part of the IF_ID RSVP_HOP object. The local decision 395 normally used to select the upstream component link is bypassed 396 except for local translation into the outgoing interface identifier 397 from the received incoming remote interface identifier. 399 The IF_ID RSVP_HOP object constructed as above MUST be included in 400 the corresponding outgoing Path message. 402 Note that, associated with a TE Link sub-object in the ERO, either 403 the (remote) upstream component interface or the (remote) downstream 404 component interface or both may be specified. As specified in 405 [RFC4201] there is no relationship between the TE Link type 406 (numbered or unnumbered) and the Link type of any one of its 407 components. 409 The Component Interface Identifier ERO subobject is optional. 410 Similarly, presence of the Label ERO sub-objects is not mandatory 411 [RFC3471], [RFC3473]. Furthermore, component interface identifier 412 ERO subobject and Label ERO subobject may be included in the ERO 413 independently of each other. one of the following alternatives 414 applies: 416 o) When both sub-objects are absent, a node may select any 417 appropriate component link within the TE link and any label on 418 the selected component link. 420 o) When the Label subobject is only present for a bundled link, then 421 the selection of the component link within the bundle is a local 422 decision and the node may select any appropriate component link, 423 which can assume the label specified in the Label ERO. 425 o) When only the component interface identifier ERO subobject is 426 present, a node MUST select the component interface specified in 427 the ERO and may select any appropriate label value at the 428 specified component link. 430 o) When both component interface identifier ERO subobject and Label 431 ERO subobject are present, the node MUST select the locally 433 Component Link Recording & Resource Control for TE Links April 27, 2011 435 corresponding component link and the specified label value on 436 that component link. When present, both subobjects may appear in 437 any relative order to each other but they MUST appear after the 438 TE Link subobject that they refer to. 440 After processing, the component interface identifier subobjects are 441 removed from the ERO. 443 Inferred from above, the interface subobject should never be the 444 first subobject in a newly received message. If the component 445 interface subobject is the first subobject in a received ERO, then 446 it SHOULD be treated as a "Bad strict node" error. 448 Note: Information to construct the Component Interface ERO subobject 449 MAY come from the same mean used to populate the label ERO 450 subobject. Procedures by which an LSR at the head-end of an LSP 451 obtains the information needed to construct the Component Interface 452 subobject are outside the scope of this document. 454 5. Backward Compatibility 456 The extensions specified in this document do not affect the 457 processing of the RRO, ERO at nodes that do not support them. A node 458 that does not support the Component Interface RRO subobject but that 459 does support Label subobject SHOULD only insert the Label subobject 460 in the RRO as per [RFC3471] and [RFC3473]. 462 A node that receives an ERO that contains a Component Link ID 463 subobject SHOULD send "Bad EXPLICIT_ROUTE object" if it does not 464 implement this subobject. 466 Per [RFC3209], Section 4.4.5, a non-compliant node that receives an 467 RRO that contains Component Interface Identifier sub-objects should 468 ignore and pass them on. This limits the full applicability of if 469 nodes traversed by the LSP are compliant with the proposed 470 extensions. 472 6. Security Considerations 474 An implementation of the extensions described in this document does 475 exposes the component interface identifiers to other nodes in the 476 network. If this is considered confidential information the 477 mechanisms described in [RFC5920] should be considered. 479 7. IANA Considerations 481 This document introduces the following RSVP protocol elements: 483 Component Link Recording & Resource Control for TE Links April 27, 2011 485 o) Component Interface Identifier RRO subobject of the RECORD_ROUTE 486 object (RRO): 488 . IANA registry: RSVP PARAMETERS 489 . Registry Name: Class Names, Class Numbers, and Class Types 490 . Reference: [RFC3936] 491 . Following subobjects have been added to the existing entry for: 493 21 RECORD_ROUTE 494 . Type 10 (TBD): Component Interface identifier IPv4 495 . Type 11 (TBD): Component Interface identifier IPv6 496 . Type 12 (TBD): Component Interface identifier Unnumbered 498 o) Component Interface Identifier subobject of the EXPLICIT_ROUTE 499 object (ERO). 501 . IANA registry: RSVP PARAMETERS 502 . Registry Name: Class Names, Class Numbers, and Class Types 503 . Reference: [RFC3936] 504 . Following subobjects have been added to the existing entry for: 506 20 EXPLICIT_ROUTE 507 . Type 10 (TBD): Component Interface identifier IPv4 508 . Type 11 (TBD): Component Interface identifier IPv6 509 . Type 12 (TBD): Component Interface identifier Unnumbered 511 o) A new "Component Link Recording desired" flag (value TBD) 512 of the LSP_ATTRIBUTES object [RFC5420]: 514 . Bit Flag: 0x80 515 . Name: Local Component Link Recording desired 517 8. References 519 8.1. Normative References 521 [RFC2205] R.Braden, et al., "Resource ReSerVation Protocol (RSVP) 522 Version 1, Functional Specification", RFC 2205, 523 September 1997. 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 Component Link Recording & Resource Control for TE Links April 27, 2011 530 [RFC2234] Crocker, D. and overell, P. (Editors), "Augmented BNF for 531 Syntax Specifications: ABNF", RFC 2234, Internet Mail 532 Consortium and Demon Internet Ltd., November 1997. 534 [RFC3209] D.Awduche, et al., "Extensions to RSVP for LSP Tunnels", 535 RFC 3209, December 2001. 537 [RFC3471] L.Berger, et al., "Generalized Multi-Protocol Label 538 Switching (GMPLS) Signaling Functional Description", RFC 539 3471, January 2003. 541 [RFC3473] L.Berger, et al., "Generalized Multi-Protocol Label 542 Switching (GMPLS) Signaling Resource ReserVation 543 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 544 3473, January 2003. 546 [RFC3477] K.Kompella, et al., "Signaling Unnumbered Links in 547 Resource ReSerVation Protocol - Traffic Engineering 548 (RSVP-TE)", RFC 3477, January 2003. 550 [RFC3945] E.Mannie, et al., "Generalized Multi-Protocol Label 551 Switching (GMPLS) Architecture", RFC 3945, October 2004. 553 [RFC4201] K.Kompella, et al., "Link Bundling in MPLS Traffic 554 Engineering", RFC 4201, January 2003. 556 [RFC5420] A.Farrel, et al., "Encoding of Attributes for 557 Multiprotocol Label Switching (MPLS) Label Switched Path 558 (LSP) Establishment Using Resource ReserVation Protocol- 559 Traffic Engineering (RSVP-TE)", RFC 5420. 561 [RFC5920] L.Fang, "Security Framework for MPLS and GMPLS Networks", 562 RFC 5920, July 2010. 564 9. Acknowledgments 566 Funding for the RFC Editor function is provided by the IETF 567 Administrative Support Activity (IASA). 569 Component Link Recording & Resource Control for TE Links April 27, 2011 571 10. Copyright Notice 573 Copyright (c) 2011 IETF Trust and the persons identified as the 574 document authors. All rights reserved. 576 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 577 Relating to IETF Documents (http://trustee.ietf.org/license-info) 578 in effect on the date of publication of this document. Please 579 review these documents carefully, as they describe your rights and 580 restrictions with respect to this document. Code Components 581 extracted from this document must include Simplified BSD License 582 text as described in Section 4.e of the Trust Legal Provisions and 583 are provided without warranty as described in the Simplified BSD 584 License. 586 Authors Addresses 588 Anca Zamfir 589 Cisco Systems Inc. 590 Email: ancaz@cisco.com 592 Zafar Ali 593 Cisco systems Inc. 594 Email: zali@cisco.com 596 Dimitri Papadimitriou 597 Alcatel-Lucent Bell 598 Email: dimitri.papadimitriou@alcatel-lucent.com