idnits 2.17.1 draft-vasseur-ccamp-te-router-info-00.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 3667, Section 5.1 on line 448. -- Found old boilerplate from RFC 3978, Section 5.5 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 435. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 9) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 215 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the TE Mesh Group is contained within a single area, the TE Mesh Group Information TLV must be advertised with an area scope for OSPF and MUST not be leaked across levels for IS-IS. -- 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 (July 2004) is 7197 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: 'OSPF' is mentioned on line 132, but not defined == Missing Reference: 'FACILTY-BACKUP' is mentioned on line 147, but not defined == Missing Reference: 'P2MP-REQ' is mentioned on line 215, but not defined == Unused Reference: 'RFC' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'ISIS-IP' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'FACILITY-BACKUP' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'P2MP-Req' is defined on line 527, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS' ** Obsolete normative reference: RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-03 == Outdated reference: A later version (-03) exists of draft-ietf-tewg-interarea-mpls-te-req-02 == Outdated reference: A later version (-09) exists of draft-ietf-tewg-interas-mpls-te-req-07 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-p2mp-requirement-02 -- No information found for draft-dry-mpls-rsvp-te-p2mp - is the name correct? Summary: 14 errors (**), 0 flaws (~~), 21 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group JP Vasseur (Ed.) 2 Cisco System Inc. 3 Internet Draft JL Le Roux (Ed.) 4 France Telecom 6 Category: Standard Track 7 Expires: January 2005 July 2004 9 Routing extensions for discovery of TE router information 11 draft-vasseur-ccamp-te-router-info-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or IPR claims of which I am aware have been disclosed, and any 17 of which I become aware will be disclosed, in accordance with RFC 18 3668. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes extensions to MPLS Traffic Engineering 40 routing for the advertisement of Traffic Engineering Router 41 Information and capabilities. This document specifies a functional 42 description of these extensions whereas protocol specific formats and 43 mechanisms are described in separate documents. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119. 51 Table of Contents 53 1. Contributors....................................................2 54 2. Terminology.....................................................3 55 3. Introduction....................................................3 56 4. TE Node Capability Descriptor TLV...............................4 57 4.1. Description...................................................4 58 4.2. Required Information..........................................5 59 4.3. Procedure.....................................................5 60 5. PCE Discovery Information.......................................5 61 5.1. Description...................................................5 62 5.2. Required Information..........................................6 63 5.3. Procedure.....................................................7 64 6. TE Mesh Group Information.......................................8 65 6.1. Description...................................................8 66 6.2. Required Information..........................................8 67 6.3. Procedure.....................................................8 68 7. Security Considerations.........................................9 69 8. Intellectual Property Statement.................................9 70 8.1. IPR Disclosure Acknowledgement................................9 71 9. Acknowledgment..................................................9 72 10. References....................................................10 73 11. Editors' Address:.............................................11 75 1. Contributors 77 This document was the collective work of several. The text and 78 content of this document was contributed by the editors and the 79 co-authors listed below (the contact information for the editors 80 appears in section 14, and is not repeated below): 82 Paul Mabey Seisho Yasukawa 83 Qwest Communications NTT 84 950 17th street 9-11, Midori-Cho 3-Chome 85 Denver, CO 80202 Musashino-Shi, Tokyo 180-8585 86 USA JAPAN 87 Email: pmabey@qwest.com Email: yasukawa.seisho@lab.ntt.co.jp 89 Stefano Previdi Peter Psenak 90 Cisco System, Inc. Cisco System, Inc. 91 Via del Serafico 200 Pegasus Park 92 00142 Roma DE Kleetlaan 6A 93 ITALY 1831, Diegmen 94 Email: sprevidi@cisco.com BELGIUM 95 Email: ppsenak@cisco.com 97 2. Terminology 99 Terminology used in this document 101 LSR: Label Switch Router. 103 PCE: Path Computation Element whose function is to compute the 104 path of a TE LSP it is not the head-end for. The PCE may be 105 an LSR or an offline tool not forwarding packet. 107 PCC: Path Computation Client (any head-end LSR) requesting a TE 108 LSP path computation to the Path Computation Element. 110 TE LSP: Traffic Engineering Label Switched Path. 112 TE LSP head-end: head/source of the TE LSP. 114 TE LSP tail-end: tail/destination of the TE LSP. 116 IGP Area: OSPF Area or ISIS level 118 Link State Advertisement: An OSPF LSA or ISIS LSP 120 Intra-area TE LSP: TE LSP whose path does not transit across 121 areas. 123 Inter-area TE LSP: A TE LSP whose path transits across at least 124 two different IGP areas. 126 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 127 two different ASes or sub-ASes (BGP confederations). 129 3. Introduction 131 MPLS Traffic Engineering (MPLS-TE) routing ([ISIS-TE], [OSPF-TE]) 132 relies on extensions to link state IGP routing protocols ([OSPF], 133 [ISIS]) in order to carry Traffic Engineering link information used 134 for constraint based routing. Further Generalized MPLS (GMPLS) 135 related extensions are defined in [ISIS-G] and [OSPF-G]. 137 The current MPLS-TE/GMPLS routing focuses on TE link information. In 138 return TE router information are limited to the TE router id. 139 However, it would be highly useful to advertise more TE router 140 information for various purposes such as: 142 - A Path Computation Elements (PCE) can compute paths for TE-LSPs 143 it is not the head-end for. This can be an LSR or an offline 144 tool not forwarding packets. PCE are useful in various MPLS-TE 145 and GMPLS situations such as, for instance, inter-domain path 146 computation (see [INT-DOMAIN-FRWK]) or backup path computation 147 (see [FACILTY-BACKUP]). It would be highly useful that a node 148 advertise its PCE capabilities so as for the LSRs in the network 149 to automatically discover PCEs in addition to their capabilities, 150 and thus would reduce the LSR configuration overhead. This would 151 also allow for the dynamic discovery of a new PCE or that a PCE 152 is not longer alive. 154 - A TE mesh group is a group of LSRs that are connected by a full 155 mesh of TE-LSPs. It is useful to advertise the desire of a node 156 to join/leave a particular TE mesh group. This allows for an 157 automatic provisioning of a full mesh of TE LSP, and thus 158 drastically reduces the configuration overhead. 160 - Data plane capabilities related to the node itself and not to 161 its links, such as the capability to be a branch node or a bud 162 LSR of a P2MP LSP tunnel (see [P2MP-REQ]). These node 163 capabilities should be advertised by the IGP for path selection. 164 It would also be highly useful to advertise control plane node 165 Capabilities; for instance, the capability to support GMPLS 166 signaling for a packet LSR, or the capability to support P2MP 167 signaling. This would ease backward compatibility. For instance 168 this would allow selecting a path that would avoid nodes that do 169 not support a given signaling feature, or automatically 170 triggering a mechanism that would handle these nodes on the path. 172 This document specifies routing extensions in support of carrying 173 Traffic Engineering router information for MPLS Traffic Engineering 174 (MPLS-TE) and Generalized MPLS (GMPLS). Such Traffic Engineering 175 router information will be carried into Link State Advertisements. 177 This document specifies a functional description of the extensions 178 required to advertise TE router information and capabilities. Generic 179 routing protocol formats, procedure and definitions are provided in 180 this document whereas protocol specific formats and procedures are 181 defined in [OSPF-CAP], [OSPF-TE-CAP] for OSPF, and in [ISIS-CAP] and 182 [ISIS-TE-CAP] for ISIS. 184 The TE Router Information and capabilities defined in this document 185 consists of three pieces of information: 186 -The TE Node Capability Descriptor TLV used to advertise 187 data and control plane TE capabilities of an LSR, 188 -The PCE Discovery Information TLV used to advertise PCE 189 capabilities. 190 -The TE Mesh Group Information TLV used to advertise the desire 191 of an LSR to join/leave one or more TE mesh groups. 193 4. TE Node Capability Descriptor TLV 195 4.1. Description 197 LSRs in a network may have distinct control plane and data plane 198 Traffic Engineering capabilities. The TE Node capability Descriptor 199 TLV describes data and control plane capabilities of an LSR. Such 200 information can be used for instance for path computation algorithm 201 so as to avoid nodes that do not support a given TE feature either in 202 the control or data plane or to trigger procedure to handle these 203 nodes. In some case, this may also be useful for backward 204 compatibility. 206 4.2. Required Information 208 The TE Node Capability Descriptor TLV contains two variable length 209 sets of bit flags: the Control Plane Capability flags and the Data 210 Plane Capability flags. Each flag corresponds to a given capability. 212 Two flags are currently defined in the Data Plane Capability Flags: 214 B bit: when set, this flag indicates that the LSR can act as a branch 215 node on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]). 217 E bit: when set, this flag indicates that the LSR can act as a bud 218 LSR on a P2MP LSP, i.e. and LSR that is both transit and egress. 220 Three flags are currently defined in the Control Plane Capability 221 Flags: 223 M bit: when set, this flag indicates that the LSR supports MPLS-TE 224 signalling ([RSVP-TE]). 226 G bit: when set this flag indicates that the LSR supports GMPLS 227 signalling ([RSVP-G]). 229 P bit: when set, this flag indicates that the LSR supports P2MP MPLS- 230 TE signalling ([RSVP-P2MP]). 232 Note that new flags may be added if required. 234 4.3. Procedure 236 The TE Node Capability Descriptor TLV is carried in Link State 237 Advertisements. A router MUST originate a new Link State 238 Advertisement whenever the content of this information changes, or 239 whenever required by regular routing procedure (e.g. refresh). 241 TE Node Capability Descriptor TLVs are optional. When a Link State 242 Advertisement does not contain any TE Node capability Descriptor TLV, 243 this means that the TE Capabilities of that LSR are unknown. 245 5. PCE Discovery Information 247 5.1. Description 249 The PCE Discovery Information allows for the auto-discovery of one or 250 more Path Computation Element(s). In various MPLS and GMPLS 251 situations, such as inter-domain TE or backup path computation, an 252 LSR may require to send a request to a Path Computation Element (PCE) 253 to compute one or more TE LSPs paths obeying a set of specified 254 constraints. Note that a PCE can be an LSR or an offline tool without 255 any forwarding capability. 257 The PCE Discovery Information allows a PCE to announce its capability 258 to be a Path Computation Element within an area or an AS. This allows 259 every LSR in the network to automatically discover the PCEs and 260 recognize their capabilities, which substantially simplifies head-end 261 LSR configuration. Moreover, this also allows for: 262 - The dynamic detection of any new PCE, 263 - To determine that PCE is no longer active, 264 - To perform some load sharing among a set of potential PCE 265 candidates. 267 5.2. Required Information 269 The PCE Discovery Information carries the IP address to be used to 270 reach the PCE. This address will typically be a loop-back address 271 that is always reachable, provided the router is not isolated. The 272 PCE IP address is mandatory, and MUST appear only once, except when 273 the PCE has both an IPv4 and an IPv6 address. 275 The PCE Discovery Information TLV also carries an optional set of 276 capability flag bits that is used by the PCE to signal its PCE 277 capabilities. This could then be used by an LSR to select the 278 appropriate PCE among a list of PCE candidates. 280 Six capability flags are currently defined. The first three bits 281 define the scope for which the PCE is capable of performing the TE 282 LSP Path Computation. 284 L bit: 285 Local scope. When set, this flag indicates that the PCE can compute 286 paths for the area/level the PCE Discovery Information TLV is flooded 287 into (the PCE can compute TE LSP paths for intra-area TE LSPs). 289 I bit: 290 Inter-area scope. When set, the PCE can perform TE LSP path 291 computation for inter-area TE LSPs but within the same AS. 293 A bit: 294 Inter-AS scope. When set, the PCE can perform path computation 295 for inter-AS TE LSPs. 297 Note that those flags are not exclusive (a PCE may set one or more 298 flags). 300 P bit: 301 Request Priority. The notion of request priority allows a PCC to 302 specify the degree of urgency of a particular request. When set, this 303 flag indicates that the PCE takes into account the 'request priority' 304 in its scheduling of the various requests. 306 M bit: 307 Multiple Path Computation. When set, this flag indicates that the PCE 308 is capable of computing more than one path obeying a set of specified 309 constraints (in a single pass), provided that they exist. 311 D bit: 312 Diversity. When set, this flag indicates that the PCE is capable of 313 computing diversely routed paths (link, node, SRLG). The PCC may 314 request the PCE to compute N diversely routed paths obeying a set of 315 specified constraints. Such N paths may not exist of course depending 316 on the current state of the network. 318 Note that new flags may be defined in the future to announce 319 additional PCE capabilities. 321 If the PCE is capable of computing inter-AS TE LSP path, the PCE 322 Discovery Information TLV MAY also contain the list of AS numbers 323 identifying the AS for which the PCE can compute inter-AS TE LSP 324 paths (TE-LSPs having their destination address in this AS). This set 325 is optional and should be included only when the A bit is set. 327 5.3. Procedure 329 The PCE Discovery Information TLV is carried in Link State 330 Advertisements. A router MUST originate a new Link State 331 Advertisement whenever the content of this information changes, or 332 whenever required by regular routing procedure (e.g. refresh) 334 The PCE Discovery Information TLV is optional. 336 If the PCE can compute an intra-area TE LSP path, the L bit 337 MUST be set. If it can compute an intra-area TE LSP path only for the 338 LSRs in the area it resides in, then the PCE Discovery Information 339 must be contained within an area. Otherwise, if the PCE can compute 340 intra-area TE LSP paths for the whole AS, then the PCE Discovery 341 Information TLV must be flooded across the whole AS. 343 If the PCE can compute an inter-area TE LSP path, the I bit MUST be 344 set. If it can compute an inter-area TE LSP path only for the LSRs in 345 the area(s) it resides in (for instance the PCE is an ABR computing 346 an inter-area TE LSP path for its area), then the PCE Discovery 347 Information must be contained within this or these area(s). Else, if 348 it can compute an inter-area TE LSP path for the whole AS, then the 349 PCE Discovery Information must be flooded across the whole AS. 351 If the PCE can compute an inter-AS TE LSP path, the A bit MUST be 352 set, and the PCE Discovery Information must be flooded across the 353 whole AS. 355 6. TE Mesh Group Information 357 6.1. Description 359 As of today, there are different approaches in deploying MPLS Traffic 360 Engineering: 362 (1) The 'systematic' approach consisting of setting up a full 363 mesh of TE LSPs between a set of LSRs, 365 (2) The 'by exception' approach where a set of TE LSPs are 366 set up on hot spots to alleviate a congestion resulting 367 for instance in an unexpected traffic growth in some part 368 of the network. 370 Setting up a full mesh of TE LSPs between a set of LSRs requires the 371 configuration of a large number of TE LSPs on every head-end LSR. A 372 full TE mesh of n LSRs requires to set up O(n^2) TE LSPs. 373 Furthermore, the addition of any new LSR in the mesh implies to 374 configure n TE LSPs on the new LSR and to add a new TE LSP on every 375 LSR ending to this new LSR, which gives a total of 2*n TE LSPs. This 376 is not only time consuming but also a risky operation for 377 Service Providers. Hence, a more automatic way of setting up a full 378 mesh of TE LSPs is desirable. 380 A TE-mesh group is defined as a group of LSRs fully meshed by a set 381 of LSPs having common TE attributes. An LSR MUST setup a TE-LSP 382 towards each LSR belonging to its TE mesh-group(s). 384 The TE Mesh-Group Information allows an LSR to advertise its desire 385 to join/leave one or more TE mesh-groups. 387 6.2. Required Information 389 The TE Mesh Group Information TLV allows an LSR to advertise the set 390 of TE mesh-groups it belongs to. For each mesh group announced by the 391 LSR, the TE Mesh Group Information TLV carries the following set of 392 information: 393 -A Mesh-Group number identifying the TE mesh-group, 394 -A Tail-end address (address used as a tail end address by other 395 LSRs belonging to the same mesh-group), 396 -A Tail-end name: string used to ease the TE-LSP naming (e.g. 397 'head-name->tail-name'). 399 6.3. Procedure 401 The TE Mesh-Group Information TLV is carried in Link State 402 Advertisements. A router MUST originate a new Link State 403 Advertisement whenever the content of this information changes, or 404 whenever required by regular routing procedure (e.g. refresh) 405 The TE Mesh-Group Information is optional. 407 If the TE Mesh Group is contained within a single area, the TE Mesh 408 Group Information TLV must be advertised with an area scope for OSPF 409 and MUST not be leaked across levels for IS-IS. 411 Conversely, if the TE Mesh Group spans multiple IGP areas, the TE 412 Mesh Group Information TLV must be advertisement with a routing 413 domain scope for OSPF and MUST be leaked across levels for IS-IS. 415 7. Security Considerations 417 No new security issues are raised in this document. 419 8. Intellectual Property Statement 421 The IETF takes no position regarding the validity or scope of any 422 Intellectual Property Rights or other rights that might be claimed to 423 pertain to the implementation or use of the technology described in 424 this document or the extent to which any license under such rights 425 might or might not be available; nor does it represent that it has 426 made any independent effort to identify any such rights. Information 427 on the procedures with respect to rights in RFC documents can be 428 found in BCP 78 and BCP 79. 430 Copies of IPR disclosures made to the IETF Secretariat and any 431 assurances of licenses to be made available, or the result of an 432 attempt made to obtain a general license or permission for the use of 433 such proprietary rights by implementers or users of this 434 specification can be obtained from the IETF on-line IPR repository at 435 http://www.ietf.org/ipr. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights that may cover technology that may be required to implement 440 this standard. Please address the information to the IETF at ietf- 441 ipr@ietf.org.. 443 8.1. IPR Disclosure Acknowledgement 445 By submitting this Internet-Draft, I certify that any applicable 446 patent or other IPR claims of which I am aware have been disclosed, 447 and any of which I become aware will be disclosed, in accordance with 448 RFC 3668. 450 9. Acknowledgment 452 We would like to thank Yannick Le Louedec, for its useful comments. 454 10. References 456 Normative references 458 [RFC] Bradner, S., "Key words for use in RFCs to indicate 459 requirements levels", RFC 2119, March 1997. 461 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 462 RFC 3667, February 2004. 464 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 465 Technology", BCP 79, RFC 3668, February 2004. 467 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 469 [ISIS] "Intermediate System to Intermediate System Intra-Domain 470 Routing Exchange Protocol " ISO 10589. 472 [ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 473 dual environments", RFC 1195, December 1990. 475 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 476 Extensions to OSPF Version 2", RFC 3630, September 2003. 478 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 479 Engineering", RFC 3784, June 2004. 481 Informative References 483 [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support 484 of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- 485 gmpls-routing-09.txt (work in progress) 487 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 488 Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- 489 gmpls-extensions-12.txt, work in progress. 491 [ISIS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 492 Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- 493 extensions-19.txt, work in progress. 495 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 496 J.P., "Extensions to OSPF for advertising Optional Router 497 Capabilities", draft-ietf-ospf-cap-03.txt, work in progress. 499 [OSPF-TE-CAP] Vasseur, J.P., Psenak, P., Yasukawa, S., "OSPF MPLS 500 Traffic Engineering Capabilities", draft-vasseur-ospf-te-caps-00.txt, 501 work in progress. 503 [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N., "IS-IS extensions 504 for advertising router information", draft-vasseur-isis-caps-02.txt, 505 work in progress. 507 [ISIS-TE-CAP] Vasseur, J.P, Previdi, S., Mabey, P., Le Roux, J.L., 508 "IS-IS MPLS Traffic Engineering Capabilities", draft-vasseur-isis-te- 509 caps-00.txt, work in progress. 511 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements 512 for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- 513 mpls-te-req-02.txt, work in progress. 515 [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic 516 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req- 517 07.txt, work in progress. 519 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A 520 Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel- 521 ccamp-inter-domain-framework-01.txt, work in progress. 523 [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for 524 PCE based MPLS Facility Backup Path Computation", draft-leroux-pce- 525 backup-comp-frwk-00.txt, work in progress 527 [P2MP-Req] Yasukawa, S., et. al., "Requirements for point-to- 528 multipoint extension to RSVP-TE", draft-ietf-mpls-p2mp-requirement- 529 02.txt, work in progress. 531 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 532 tunnels", RFC 3209, December 2001. 534 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 535 RFC 3473, January 2003. 537 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 538 RSVP-TE for point-to-multipoint TE LSPs", draft-dry-mpls-rsvp-te- 539 p2mp-00.txt, work in progress. 541 11. Editors' Address: 543 Jean-Philippe Vasseur 544 Cisco Systems, Inc. 545 300 Beaver Brook Road 546 Boxborough , MA - 01719 547 USA 548 Email: jpv@cisco.com 550 Jean-Louis Le Roux 551 France Telecom 552 2, avenue Pierre-Marzin 553 22307 Lannion Cedex 554 FRANCE 555 Email: jeanlouis.leroux@francetelecom.com 557 Full Copyright Statement 559 Copyright (C) The Internet Society (2004). This document is subject to 560 the rights, licenses and restrictions contained in BCP 78, and except as 561 set forth therein, the authors retain all their rights. 563 This document and the information contained herein are provided on an 564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 565 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 566 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 567 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 568 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.