idnits 2.17.1 draft-ietf-mpls-explicit-resource-control-bundle-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 474. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-mpls-explicit-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mpls-explicit-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-mpls-explicit-', but the file name used is 'draft-ietf-mpls-explicit-resource-control-bundle-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 1 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC3473], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 138 has weird spacing: '...control and r...' == Line 402 has weird spacing: '...objects may a...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 2006) is 6639 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3477' is mentioned on line 159, but not defined == Missing Reference: 'RFC 3471' is mentioned on line 380, but not defined == Missing Reference: 'RFC 3473' is mentioned on line 380, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-05 -- No information found for draft-farrel-rsvpte-attributes - is the name correct? Summary: 7 errors (**), 1 flaw (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group 3 Internet Draft Anca Zamfir 4 Zafar Ali 5 Cisco Systems 6 D. Papadimitriou 7 Alcatel 8 Document: draft-ietf-mpls-explicit- 9 resource-control-bundle-01.txt 10 Expires: August 2006 February 2006 12 Component Link Recording and Resource Control for GMPLS Link Bundles 14 draft-ietf-mpls-explicit-resource-control-bundle-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 Record Route is a useful administrative tool that has been used 41 extensively by the service providers. However, when TE links are 42 bundled, identification of label resource in RRO is not enough for 43 the administrative purpose. Network service providers would like to 44 know the component link within a TE link that is being used by a 46 Zamfir, A., Ali, Z., Papadimitriou, D. 48 draft-ietf-mpls-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 50 given LSP. In other words, when link bundling is used, resource 51 recording requires mechanisms to specify the component link 52 identifier, along with the TE link identifier and Label. As , it is 53 not possible to record component link in the RRO, this draft defines 54 the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify 55 component link identifiers for resource recording purposes. 57 This draft also defines the ERO counterpart of the RRO extension. The 58 ERO extensions are needed to perform explicit label/ resource control 59 over bundled TE link. Hence, this draft defines the extensions to 60 RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers 61 for explicit resource control and recording over GMPLS link bundles. 63 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Table of Contents 71 1. Terminology....................................................2 72 2. Resource Control and Recording.................................3 73 3. LSP Resource Recording.........................................4 74 3.1 Component Interface Identifier RRO subobject...............4 75 3.2 Processing of Component Interface identifier RRO Subobject.5 76 4. Signaling Component Interface Identifier in ERO................6 77 4.1 Processing of Component Interface Identifier ERO Subobject.7 78 5. Forward Compatibility Note.....................................9 79 6. Security Considerations........................................9 80 7. IANA Considerations...........................................10 81 8. Intellectual Property Considerations..........................10 82 9. References....................................................10 83 9.1 Normative Reference.......................................10 84 9.2 Informative Reference.....................................11 85 10. Author's Addresses...........................................11 86 11. Full Copyright Statement.....................................11 88 1. Terminology 90 TE Link: Unless specified otherwise, it refers to a bundled Traffic 91 Engineering link as defined in [BUNDLE]. Furthermore, the terms TE 92 Link and bundled TE Link are used interchangeably in this draft. 94 Zamfir, A., Ali, Z., Papadimitriou, D 95 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 97 Component (interface) link: refers (locally) to a component link as 98 part of a bundled TE link. A component link is numbered/ unnumbered 99 in its own right. For unnumbered component links, the component link 100 ID is assumed to be unique on an advertising node. For numbered 101 component links, the component link ID is assumed to be unique within 102 a domain. 104 Component Interface Identifier: Refers to an ID used to uniquely 105 identify a Component Interface. On a bundled link a combination of 106 is sufficient to unambiguously 107 identify the appropriate resources used by an LSP [BUNDLE]. 109 2. Resource Control and Recording 111 In GMPLS networks that deals with unbundled (being either PSC, L2SC, 112 TDM or LSC) TE Links, one of the types of resources that an LSP 113 originator can control and would like to record are the TE Link 114 interfaces used by the LSP. The resource control and recording is 115 done by the use of an explicit route, i.e., Explicit Route (ERO) 116 Object and record Route, i.e., Record Route Object (RRO) object, 117 respectively. 119 Link Bundling introduced by [BUNDLE], is used to improve routing 120 scalability by reducing the amount of TE related information that 121 needs to be flooded and handled by IGP in a TE network. This is 122 accomplished by aggregating and abstracting the TE Link resource. In 123 some cases the complete resource identification is left as a local 124 decision. However, as described above there are cases when it is 125 desirable for a non-local (e.g., LSP head-end) node to identify 126 completely or partially the LSP resources. In either case, for 127 administrative reasons, it is required to know which component link 128 within a bundled TE link has been used for a given LSP. 130 When link bundling is used to aggregate multiple component links into 131 a TE link, label is not the only resource that needs to be identified 132 and recorded. In other words, the TE Link and the Label specified in 133 the ERO/ RRO objects are not enough to completely identify the 134 resource. For the bundled TE link case, in order to fully specify the 135 resources on a link for a given LSP, the component link needs to be 136 specified along with the label. In the case of bi-directional LSPs 137 both upstream and downstream information may be specified. Therefore, 138 explicit resource control and recording over a bundled TE link also 139 requires ability to specify a component link within the TE link. 141 This draft defines extensions to and describes the use of RSVP-TE 142 [RFC3209], [RFC3471], [RFC3473] to specify the component link 143 identifier for resource recording and explicit resource control over 144 GMPLS link bundles. Specifically, in this document, component 146 Zamfir, A., Ali, Z., Papadimitriou, D 147 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 149 interface identifier RRO and ERO subobjects are defined to complement 150 their Label RRO and ERO counterparts. Furthermore, procedures for 151 processing component interface identifier RRO and ERO subobjects and 152 how they can co-exist with the Label RRO and ERO subobjects are 153 specified. 155 3. LSP Resource Recording 157 This refers to the ability to record the resources used by an LSP. 158 The procedure for unbundled numbered TE links is described in 159 [RFC3209] and for unbundled unnumbered TE links in [RFC 3477]. For 160 the purpose of recording LSP resources used over bundled TE Links, 161 the Component Interface Identifier RRO sub-object is introduced. 163 3.1 Component Interface Identifier RRO subobject 165 A new subobject of the Record Route Object (RRO) is used to record 166 component interface identifier of a (bundled) TE Link. This subobject 167 has the following format: 168 Figure 2: Component Interface Identifier RRO subobject 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |L| Type | Length |U| Reserved (must be zero) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 // IPv4, IPv6 or unnumbered Component Interface Identifier // 176 | . . . | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 0 1 2 3 181 L: 1 bit 183 This bit must be set to 0. 185 Type 187 10 (TBD) Component Interface identifier IPv4 188 11 (TBD) Component Interface identifier IPv6 189 12 (TBD) Component Interface identifier Unnumbered 191 Length 193 Zamfir, A., Ali, Z., Papadimitriou, D 194 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 196 The Length contains the total length of the subobject in 197 bytes, including the Type and Length fields. The Length is 198 8 bytes for the Component Interface identifier IPv4 and 199 Component Interface identifier Unnumbered types. For 200 Component Interface identifier IPv6 type of sub-object, the 201 length field is 20 bytes. 203 U: 1 bit 205 This bit indicates the direction of the component 206 interface. It is 0 for the downstream interface. It is 207 set to 1 for the upstream interface and is only used for 208 bi-directional LSPs. 210 3.2 Processing of Component Interface identifier RRO Subobject 212 If a node desires component link recording, the "Component Link 213 Recording desired" flag (value TBD) should be set in the 214 LSP_ATTRIBUTES object, object that is defined in [RSVP-TE-ATTRIBUTE]. 215 Setting of "Component Link Recording desired" flag is independent of 216 the Label Recording flag in SESSION_ATTRIBUTE object as specified in 217 [RFC3209]. Nevertheless, the following combinations are valid: 218 1) If both Label and Comp Link flags are clear, then neither 219 Labels nor Component Links are recorded. 220 2) If Label Recording flag is set and Component Link flag is 221 clear, then only Label Recording is performed as defined in 222 [RFC3209]. 223 3) If Label Recording flag is clear and Component Link flag is 224 set, then Component Link Recording is performed as defined in this 225 proposal. 226 4) If both Label Recording and Component Link flags are set, then 227 Label Recording is performed as defined in [RFC3209] and also 228 Component Link recording is performed as defined in this proposal. 230 In most cases, a node initiates recording for a given LSP by adding 231 the RRO to the Path message. If the node desires Component Link 232 recording and if the outgoing TE link is bundled, then the initial 233 RRO contains the Component Link identifier (numbered or unnumbered) 234 as selected by the sender. As well, the Component Link Recording 235 desired flag is set in the LSP_ATTRIBUTE object. If the node also 236 desires label recording, it sets the Label_Recording flag in the 237 SESSION_ATTRIBUTE object. 239 When a Path message with the "Component Link Recording desired" flag 240 set is received by an intermediate node, if a new Path message is to 241 be sent for a downstream bundled TE link, the node adds a new 242 Component Link subobject to the RRO and appends the resulting RRO to 243 the Path message before transmission. 245 Zamfir, A., Ali, Z., Papadimitriou, D 246 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 248 Note also that, unlike Labels, Component Link identifiers are always 249 known on receipt of the Path message. 251 When the destination node of an RSVP session receives a Path message 252 with an RRO and the "Component Link Recording desired" flag set, this 253 indicates that the sender node needs TE route as well as component 254 link recording. The destination node initiates the RRO process by 255 adding an RRO to Resv messages. The processing mirrors that of the 256 Path messages 258 The Component Interface Record subobject is pushed onto the 259 RECORD_ROUTE object prior to pushing on the node's IP address. A node 260 MUST NOT push on a Component Interface Record subobject without also 261 pushing on the IP address or unnumbered Interface Id subobject that 262 identifies the TE Link. 264 When component interfaces are recorded for bi-directional LSPs, 265 component interface RRO subobjects for both downstream and upstream 266 interfaces MUST be included. 268 4. Signaling Component Interface Identifier in ERO 270 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 271 to specify component interface identifier of a bundled TE Link. 273 This subobject has the following format: 275 Figure 1: Component Interface Identifier ERO subobject 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |L| Type | Length |U| Reserved (MUST be zero) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 // IPv4, IPv6 or unnumbered Component Interface Identifier // 283 | . . . | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 L: 1 bit 288 This bit must be set to 0. 290 Type 292 10 (TBD) Component Interface identifier IPv4 293 11 (TBD) Component Interface identifier IPv6 295 Zamfir, A., Ali, Z., Papadimitriou, D 296 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 298 12 (TBD) Component Interface identifier Unnumbered 300 Length 302 The Length contains the total length of the subobject in 303 bytes, including the Type and Length fields. The Length is 304 8 bytes for the Component Interface identifier types: IPv4 305 and Component Interface identifier Unnumbered. For 306 Component Interface identifier IPv6 type of sub-object, 307 the length field is 20 bytes. 309 U: 1 bit 310 This bit indicates the direction of the component 311 interface. It is 0 for the downstream interface. It is 312 set to 1 for the upstream interface and is only used for 313 bi-directional LSPs. 315 4.1 Processing of Component Interface Identifier ERO Subobject 317 The Component Interface Identifier ERO subobject follows a subobject 318 containing the IP address, or the link identifier [RFC3477], 319 associated with the TE link on which it is to be used. It is used to 320 identify the component of a bundled TE Link. 322 The following SHOULD result in "Bad EXPLICIT_ROUTE object" error 323 being sent upstream by a node processing an ERO that contains the 324 Component Interface ID sub-object: 326 o The first component interface identifier subobject is not 327 preceded by a sub-object containing an IPv4 or IPv6 address, or 328 an interface identifier [RFC3477], associated with a TE link. 329 o The Component Interface Identifier ERO subobject follows a 330 subobject that has the L-bit set. 331 o On unidirectional LSP setup, there is a Component Interface 332 Identifier ERO subobject with the U-bit set. 333 o Two Component Interface Identifier ERO subobjects with the same 334 U-bit values exist. 336 If a node implements the component interface identifier subobject, it 337 must check if it represents a component interface in the bundled TE 338 Link specified in the preceding subobject that contains the IPv4/IPv6 339 address or interface identifier of the TE Link. If the content of the 340 component interface identifier subobject does not match a component 341 interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD 342 be reported as "Routing Problem" (error code 24). 344 Zamfir, A., Ali, Z., Papadimitriou, D 345 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 347 If U-bit of the subobject being examined is cleared (0) and the 348 upstream interface specified in this subobject is acceptable, then 349 the value of the upstream component interface is translated locally 350 in the TLV of the IF_ID RSVP HOP object [RFC 3471]. The local 351 decision normally used to select the upstream component link is 352 bypassed except for local translation into the outgoing interface 353 identifier from the received incoming remote interface identifier. If 354 this interface is not acceptable, a "Bad EXPLICIT_ROUTE object" error 355 SHOULD be reported as "Routing Problem" (error code 24). 357 If the U-bit of the subobject being examined is set (1), then the 358 value represents the component interface to be used for upstream 359 traffic associated with the bidirectional LSP. Again, if this 360 interface is not acceptable or if the request is not one for a 361 bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD be 362 reported as "Routing Problem" (error code 24). Otherwise, the 363 component interface IP address/ identifier is copied into a TLV sub- 364 object as part of the IF_ID RSVP_HOP object. The local decision 365 normally used to select the upstream component link is bypassed 366 except for local translation into the outgoing interface identifier 367 from the received incoming remote interface identifier. 369 The IF_ID RSVP_HOP object constructed as above MUST be included in 370 the corresponding outgoing Path message. 372 Note that, associated with a TE Link sub-object in the ERO, either 373 the (remote) upstream component interface or the (remote) downstream 374 component interface or both may be specified. As specified in 375 [BUNDLE] there is no relationship between the TE Link type (numbered 376 or unnumbered) and the Link type of any one of its components. 378 The component interface identifier ERO subobject is optional. 379 Similarly, presence of the Label ERO sub-objects is not mandatory 380 [RFC 3471], [RFC 3473]. Furthermore, component interface identifier 381 ERO subobject and Label ERO subobject may be included in the ERO 382 independently of each other. One of the following alternatives 383 applies: 384 o When both sub-objects are absent, a node may select any appropriate 385 component link within the TE link and any label on the selected 386 component link. 387 o When the Label subobject is only present for a bundled link, then 388 the selection of the component link within the bundle is a local 389 decision and the node may select any appropriate component link, 390 which can assume the label specified in the Label ERO. 391 o When only the component interface identifier ERO subobject is 392 present, a node MUST select the component interface specified in the 394 Zamfir, A., Ali, Z., Papadimitriou, D 395 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 397 ERO and may select any appropriate label value at the specified 398 component link. 399 o When both component interface identifier ERO subobject and Label 400 ERO subobject are present, the node MUST select the locally 401 corresponding component link and the specified label value on that 402 component link. When present, both subobjects may appear in any 403 relative order to each other but they MUST appear after the TE Link 404 sub-object that they refer to. 406 After processing, the component interface identifier subobjects are 407 removed from the ERO. 409 Inferred from above, the interface subobject should never be the 410 first subobject in a newly received message. If the component 411 interface subobject is the first subobject in a received ERO, then it 412 SHOULD be treated as a "Bad strict node" error. 414 Note: Information to construct the Component Interface ERO subobject 415 may come from the same mean used to populate the label ERO subobject. 416 Procedures by which an LSR at the head-end of an LSP obtains the 417 information needed to construct the Component Interface subobject are 418 outside the scope of this document. 420 5. Forward Compatibility Note 422 The extensions specified in this draft do not affect the processing 423 of the RRO, ERO at nodes that do not support them. A node that does 424 not support the Component Interface RRO subobject but that does 425 support Label subobject SHOULD only insert the Label subobject in the 426 RRO as per [RFC3471] and [RFC3473]. 428 A node that receives an ERO that contains a Component Link ID 429 subobject SHOULD send "Bad EXPLICIT_ROUTE object" if it does not 430 implement this subobject. 432 As per [RFC3209], Section 4.4.5, a non-compliant node that receives 433 an RRO that contains Component Interface Identifier sub-objects 434 should ignore and pass them on. This limits the full applicability of 435 if nodes traversed by the LSP are compliant with the proposed 436 extensions. 438 6. Security Considerations 440 This document does not introduce new security issues. The security 441 considerations pertaining to the original RSVP protocol [RFC2205] 442 remain relevant. 444 Zamfir, A., Ali, Z., Papadimitriou, D 445 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 447 7. IANA Considerations 449 Type of Component Interface Identifier ERO subobject needs to be 450 assigned. 452 8. Intellectual Property Considerations 454 The IETF takes no position regarding the validity or scope of any 455 Intellectual Property Rights or other rights that might be claimed to 456 pertain to the implementation or use of the technology described in 457 this document or the extent to which any license under such rights 458 might or might not be available; nor does it represent that it has 459 made any independent effort to identify any such rights. Information 460 on the procedures with respect to rights in RFC documents can be 461 found in BCP 78 and BCP 79. 463 Copies of IPR disclosures made to the IETF Secretariat and any 464 assurances of licenses to be made available, or the result of an 465 attempt made to obtain a general license or permission for the use of 466 such proprietary rights by implementers or users of this 467 specification can be obtained from the IETF on-line IPR repository at 468 http://www.ietf.org/ipr. 470 The IETF invites any interested party to bring to its attention any 471 copyrights, patents or patent applications, or other proprietary 472 rights that may cover technology that may be required to implement 473 this standard. Please address the information to the IETF at ietf- 474 ipr@ietf.org. 476 9. References 478 9.1 Normative Reference 480 [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, 481 Functional Specification", RFC 2205, Braden, et al, September 482 1997. 483 [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, 484 RFC 3209, December 2001. 485 [BUNDLE] "Link Bundling in MPLS Traffic Engineering", draft-ietf- 486 mpls-bundle-05.txt, K. Kompella, et al, January 2003. 487 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) 488 Signaling Functional Description, RFC 3471, L. Berger, et al, 489 January 2003. 490 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 491 Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP- 492 TE) Extensions", RFC 3473, L. Berger, et al, January 2003. 494 Zamfir, A., Ali, Z., Papadimitriou, D 495 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 497 [RFC3477] "Signaling Unnumbered Links in Resource ReSerVation 498 Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella, 499 Y. Rekhter, January 2003. 500 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 501 RFC 2119, S. Bradner, March 1997. 503 9.2 Informative Reference 505 [RSVP-TE-ATTRIBUTE] "Encoding of Attributes for Multiprotocol Label 506 Switching (MPLS) Label Switched Path (LSP) Establishment Using 507 RSVP-TE", draft-farrel-rsvpte-attributes-00.txt., A. Farrel. 508 et al, April 2004 510 10. Author's Addresses 512 Anca Zamfir 513 Cisco Systems Inc. 514 2000 Innovation Dr., 515 Kanata, Ontario, K2K 3E8 516 Canada. 517 Phone: (613)-254-3484 518 Email: ancaz@cisco.com 520 Zafar Ali 521 Cisco Systems Inc. 522 2000 Innovation Dr., 523 Kanata, Ontario, K2K 3E8 524 Canada. 525 Phone: (613) 889-6158 526 Email: zali@cisco.com 528 Dimitri Papadimitriou (Alcatel) 529 Fr. Wellesplein 1, 530 B-2018 Antwerpen, Belgium 531 Phone: +32 3 240-8491 532 Email: dimitri.papadimitriou@alcatel.be 534 11. Full Copyright Statement 536 Copyright (C) The Internet Society (2006). This document is subject 537 to the rights, licenses and restrictions contained in BCP 78, and 538 except as set forth therein, the authors retain all their rights. 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 544 Zamfir, A., Ali, Z., Papadimitriou, D 545 draft-ietf-mpls-explicit-resource-control-bundle-01.txt Feb. 2006 547 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 548 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 549 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Zamfir, A., Ali, Z., Papadimitriou, D