idnits 2.17.1 draft-vasseur-ospf-te-caps-00.txt: -(337): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(387): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 620. -- Found old boilerplate from RFC 3978, Section 5.5 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 607. ** 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? == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 3) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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 259 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 -- 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 7225 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: 'P2MP-REQ' is mentioned on line 203, but not defined == Missing Reference: 'PATH-COMP' is mentioned on line 335, but not defined == Unused Reference: 'RFC' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'OSPF-G' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'P2MP-Req' is defined on line 666, 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) == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-02 -- Possible downref: Normative reference to a draft: ref. 'TE-INFO' == 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: 13 errors (**), 0 flaws (~~), 19 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 OSPF Working Group JP Vasseur 2 Internet Draft Peter Psenak 3 Cisco System Inc. 4 Seisho Yasukawa 5 NTT 6 Jean-Louis Le Roux 7 France Telecom 9 Category: Standard Track 10 Expires: January 2005 July 2004 12 OSPF MPLS Traffic Engineering capabilities 14 draft-vasseur-ospf-te-caps-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or IPR claims of which I am aware have been disclosed, and any 20 of which I become aware will be disclosed, in accordance with RFC 21 3668. 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document specifies OSPF traffic engineering capability TLVs 43 related to various MPLS Traffic Engineering capabilities. These OSPF 44 TE capability TLVs are carried within the OSPF router information LSA 45 (opaque type of 4, opaque ID of 0). 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119. 53 Table of Contents 55 1. Terminology.....................................................2 56 2. Introduction....................................................3 57 3. TE Node Capability Descriptor TLV format........................4 58 3.1. The DATA-PLANE-CAPABILITY sub-TLV.............................4 59 3.2. The CONTROL-PLANE-CAPABILITY sub-TLV..........................5 60 4. PCED TLV format.................................................5 61 4.1. PCE-ADDRESS sub-TLV...........................................6 62 4.2. PCE-CAPABILITY sub-TLV........................................6 63 4.3. AS-DOMAIN sub-TLV.............................................8 64 5. TE-Mesh-Group TLV format........................................8 65 6. Element of procedure............................................9 66 6.1. TE-NODE-CAP TLV...............................................9 67 6.2. PCED TLV.....................................................10 68 6.3. TE-MESH-GROUP TLV............................................12 69 7. Interoperability with routers non supporting this capability...12 70 8. Security considerations........................................12 71 9. Intellectual Property Statement................................12 72 9.1. IPR Disclosure Acknowledgement...............................13 73 10. References....................................................13 74 11. Authors' Address:.............................................14 76 1. Terminology 78 Terminology used in this document 80 LSR: Label Switch Router. 82 PCE: Path Computation Element whose function is to compute the 83 path of a TE LSP it is not the head-end for. The PCE may be 84 an LSR or an offline tool not forwarding packet. 86 PCC: Path Computation Client (any head-end LSR) requesting a TE 87 LSP path computation to the Path Computation Element. 89 TE LSP: Traffic Engineering Label Switched Path. 91 TE LSP head-end: head/source of the TE LSP. 93 TE LSP tail-end: tail/destination of the TE LSP. 95 Intra-area TE LSP: TE LSP whose path does not transit across 96 areas. 98 Inter-area TE LSP: A TE LSP whose path transits across at least 99 two different IGP areas. 101 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 102 two different ASes or sub-ASes (BGP confederations). 104 2. Introduction 106 This document defines OSPF protocol extensions and procedures for 107 the advertisement TE node capabilities. A functional description of 108 these extensions can be found in [TE-INFO], and is not repeated here. 110 This document describes the usage of three OSPF TE capabilities TLVs: 111 the PCED (PCE Discovery), the TE-MESH-GROUP and the TE-NODE-CAP 112 TLVs. These OSPF TE capability TLVs are carried within the OSPF 113 router information LSA (opaque type of 4, opaque ID of 0) specified 114 in [OSPF-CAP]. 116 Each TE TLV defined in this document (carried in an OSPF router 117 information LSA as defined in [OSPF-CAP]) has the following format: 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Type | length | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | | 125 // Value // 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Where 130 Type: identifies the TLV type 131 Length: length of the value field in octets 133 The format of the TLV is the same as the TLV format used by the 134 Traffic Engineering Extensions to OSPF [OSPF-TE]. The TLV is padded 135 to four-octet alignment; padding is not included in the length field 136 (so a three octet value would have a length of three, but the total 137 size of the TLV would be eight octets). Nested TLVs are also 32-bit 138 aligned. Unrecognized types are ignored. All types between 32768 139 and 65535 are reserved for vendor-specific extensions. All other 140 undefined type codes are reserved for future assignment by IANA. 142 Note that a sub-TLV is similar to a TLV: TLV are carried within an 143 LSA as sub-TLVs are carried within TLVs. Each sub-TLV describes a 144 particular MPLS Traffic Engineering capability. In the rest of this 145 document both terms will be used interchangeably. 147 The TE-NODE-CAP TLV is used for the advertisement of both control 148 plane and data plane TE node capabilities. The TE-NODE-CAP sub-TLV is 149 made of a set of non-ordered sub-TLVs each having the format as 150 described above. 152 The PCED TLV is used for the advertisement of Path Computation 153 Element Capabilities. The PCED sub-TLV is made of a set 154 of non-ordered sub-TLVs each having the format as described above. 156 The TE-MESH-GROUP TLV is used to advertise the desire to 157 join/leave a given MPLS-TE mesh group. The TE-MESH-GROUP sub-TLV does 158 not have any sub-TLV currently defined. 160 3. TE Node Capability Descriptor TLV format 162 This section specifies the sub-TLVs carried within the TE-NODE-CAP 163 TLV payload which defines the TE node capabilities. 165 The TE-NODE-CAP TLV type is 1. 167 The TE-NODE-CAP TLV is made of various non ordered sub-TLVs. 168 Currently two sub-TLVs are defined. 170 TLV type Length Name 171 1 variable DATA-PLANE-CAPABILITY sub-TLV 172 2 variable CONTROL-PLANE-CAPABILITY sub-TLV 174 Any non recognized sub-TLV MUST be silently ignored. 176 More sub-TLV could be added in the future to handle new capabilities 178 3.1. The DATA-PLANE-CAPABILITY sub-TLV 180 The DATA-PLANE-CAPABILITY is a series of bit flags and has a variable 181 length. 183 CODE: 1 184 LENGTH: Variable (N*8) 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |B|E| | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 // // 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 TE-NODE-CAP sub-TLV format 195 Two bits are currently defined: 197 -B bit: When set this indicates that the LSR can act as a branch node 198 on a P2MP LSP. 200 -E bit: When set, this indicates that the LSR can act as a bud LSR on 201 a P2MP LSP, i.e. and LSR that is both transit and egress. 203 See [P2MP-REQ]) and [RSVP-P2MP] for more detail on the usage of these 204 bits. 206 Note that more flags may be defined in the future. 208 3.2. The CONTROL-PLANE-CAPABILITY sub-TLV 210 The CONTROL-PLANE-CAPABILITY is a series of bit flags and has a 211 variable length. 213 CODE: 2 214 LENGTH: Variable (N*8) 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |M|G|P| | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 // // 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 TE-NODE-CAP sub-TLV format 225 Currently three flags are defined: 227 -M bit: If set this indicates that the LSR supports MPLS-TE 228 signalling ([RSVP-TE]). 230 -G bit: If set this indicates that the LSR supports GMPLS signalling 231 ([RSVP-G]). 233 -P bit: If set this indicates that the LSR supports P2MP MPLS-TE 234 signalling ([RSVP-P2MP]). 236 Note that more flags may be defined in the future. 238 4. PCED TLV format 240 This section specifies the sub-TLVs carried within the PCED TLV 241 payload which define the PCE capabilities. 243 The PCED TLV type is 2 245 The PCED TLV is made of various non ordered sub-TLVs defined 246 bellow: 248 TLV type Length Name 249 1 variable PCE-ADDRESS sub-TLV 250 2 8 PCE-CAPABILITY sub-TLV 251 3 8 AS-DOMAIN sub-TLV 253 Any non recognized sub-TLV MUST be silently ignored. 255 4.1. PCE-ADDRESS sub-TLV 257 The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach 258 the PCE described by this PCED sub-TLV. This address will typically 259 be a loop-back address that is always reachable, provided the router 260 is not isolated. The PCE-ADDRESS sub-TLV is mandatory. 262 The PCE-ADDRESS sub-TLV type is 1, length is 4 octets for an IPv4 263 address and 20 octets for an IPv6 address, and the value is the PCE 264 IPv4 or IPv6 address. 266 CODE: 1 267 LENGTH: Variable (4 or 20) 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | address-type | Reserved | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 // PCE IP address // 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 PCE-ADDRESS sub-TLV format 280 Address-type: 281 1 IPv4 282 2 IPv6 284 The PCE-ADDRESS sub-TLV MUST appear exactly once in the PCED sub-TLV 285 originated by a router. The only exception is when the PCE has both 286 an IPv4 and IPv6 address; in this case, two Path Computation Element 287 address sub-TLVs might be inserted: one for the IPv4 address, one for 288 the IPv6 address, in this order. 290 4.2. PCE-CAPABILITY sub-TLV 292 The PCE-CAPABILITY sub-TLV is used by the PCE to signal its Path 293 Computation Element capabilities. This could then be used by an LSR 294 to select the appropriate PCE among a list of PCE candidates. This 295 sub-TLV is optional. 297 The PCE-CAPABILITY sub-TLV type is 2 and the length is 8 octets. 299 CODE: 2 300 LENGTH: 8 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Reserved |D|M|P|A|I|L| 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 PCE-CAPABILITY sub-TLV format 309 The first 3 bits L, I and A defines the PCE scope for which the 310 Path Computation Element is capable of performing the TE LSP path 311 computation. 313 L bit: 314 Local scope. When set, this flag indicates that the PCE can compute 315 paths for the area/level the ISIS CAPABILITY TLV is flooded into (the 316 PCE can compute TE LSP paths for intra-area TE LSPs). 318 I bit: 319 Inter-area scope. When set, the PCE can perform TE LSP path 320 computation for inter-area TE LSPs but within the same AS. 322 A bit: 323 Multi-domain scope. When set, the PCE can perform path computation 324 for inter-AS TE LSPs. In this case, the PCED sub-TLV MUST contain one 325 or more AS-DOMAIN sub-TLV(s), each describing the domain for which 326 the PCE can compute TE LSPs paths having their destination address in 327 the respective AS. 329 Note that those flags are not exclusive (a PCE may set one or more 330 flags). 332 P bit: 333 The notion of request priority allows a PCC to specify how urgent the 334 request is, by setting a flag in the REQUEST_ID object of the Path 335 computation request message. See [PATH-COMP] for more details. 337 P=1: the PCE takes into account the ��request priority�� in its 338 scheduling of the various requests. 339 P=0: the PCE does not take the request priority into account. 341 M bit 342 M=1: the PCE is capable of computing more than one path obeying a set 343 of specified constraints (in a single pass), provided that they 344 exist. 345 M=0: the PCE cannot compute more than one path in a single pass 346 obeying a set of specified constraints. 348 D bit 349 The PCC may request the PCE to compute N diversely routed paths 350 obeying a set of specified constraints. Such N paths may not exist of 351 course depending on the current state of the network. S 352 D=1: the PCE is capable of computing diversely (link, node, SRLG) 353 routed paths. 354 D=0: the PCE is not capable of computing diversely routed paths. 355 The D bit is relevant if and only if the M bit has been set to 1. It 356 MUST be set to 0 if the M bit is set to 0. 358 Note that for future capabilities, it may be desirable to introduce 359 new flags or may be new sub-TLV to be carried in the PCED capability 360 sub-TLV if the capability needs more than just a single flag to be 361 described. 363 4.3. AS-DOMAIN sub-TLV 365 When the PCE can perform path computation for an inter-AS TE LSP, the 366 A bit of the PCE-CAPABILITY sub-TLV MUST be set. Moreover, one or 367 more sub-TLVs MUST be included within the PCED sub-TLV, each sub-TLV 368 identifying an AS number. Each AS-DOMAIN sub-TLV has the following 369 form: 371 CODE: 3 372 LENGTH: 4 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | AS Number | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 AS-DOMAIN sub-TLV format 381 The AS-DOMAIN sub-TLV type is 3, length is 4 octets, and the value is 382 the AS number identifying the AS for which the PCE can compute inter- 383 AS TE LSP paths (TE LSP having their destination address in this AS). 384 When coded on four bytes, the AS Number field MUST have its 385 left two bytes set to 0. 387 The set of AS-DOMAIN sub-TLVs specifies a list of ASes (AS1,�, 388 ASn). This means that the PCE can compute TE LSP path such that the 389 destination address of the TE LSP belongs to this set of ASes. 391 5. TE-Mesh-Group TLV format 393 The TE-MESH-GROUP TLV has the following format: 395 CODE: 3 396 LENGTH: Variable (N*8 octets) 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | mesh-group-number | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Tail-end address | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Tail-end name | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 // // 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 TE-MESH-GROUP sub-TLV format 411 N is the number of mesh-groups. 413 For each Mesh-group announced by the LSR, the TLV contains: 414 - A mesh-group-number: identifies the mesh-group number, 415 - A Tail-end address: user configurable IP address to be used as a 416 tail-end address by other LSRs belonging to the same mesh-group. 417 - A Tail-end name: 32-bits string which facilitates the TE LSP 418 identification which can be very useful in inter-area/AS MPLS TE 419 environments. 421 6. Element of procedure 423 The TLVs defined in this document are carried within an OSPF router 424 information opaque LSA (opaque type of 4, opaque ID of 0) as defined 425 in [OSPF-CAP]. 427 A router MUST originate a new OSPF router information LSA whenever 428 the content of the any of the carried TLV changes or whenever 429 required by the regular OSPF procedure (LSA refresh (every 430 LSRefreshTime)). 432 As defined in RFC2370, an opaque LSA has a flooding scope determined 433 by its LSA type: 434 - link-local (type 9), 435 - area-local (type 10) 436 - entire OSPF routing domain (type 11). In this case, the 437 flooding scope is equivalent to the Type 5 LSA flooding scope. 439 A router may generate multiple OSPF router information LSAs with 440 different flooding scopes. 442 6.1. TE-NODE-CAP TLV 444 The TE-NODE-CAP may be carried within a type 10 or 11 router 445 information LSA depending on the MPLS Traffic Engineering capability. 446 The flooding scope is defined on a per capability basis. Capabilities 447 with a identical flooding scope MUST be flooded within the same TE- 448 NODE-CAP TLV carried within a router information LSA. 450 6.2. PCED TLV 452 The PCED TLV may be carried within a type 10 or 11 router information 453 LSA depending on the Path Computation Element scope. 455 - If the PCE can compute an intra-area TE LSP, the L bit of the 456 PCE-CAPABILITY TLV of the PCED TLV MUST be set and the PCED TLV 457 MUST be generated within a Type 10 router information LSA, 459 - If the PCE can compute an inter-area TE LSP, the I bit of the 460 PCE-CAPABILITY TLV of the PCED TLV MUST be set. The PCED TLV 461 MUST be generated: 462 - within a Type 10 router information LSA if the PCE can 463 compute an inter-area TE LSP path for the LSRs in the 464 area it is attached to (for instance the PCE is an ABR 465 computing an inter-area TE LSP path for its attached 466 areas) 467 - within a Type 11 router information LSA if the PCE can 468 compute an inter-area TE LSP path for the whole domain. 470 - If the PCE can compute an inter-AS TE LSP path, the A bit of 471 the PCE-CAPABILITY TLV of the PCED TLV MUST be set and the PCED 472 TLV MUST be generated within a Type 11 router information LSA, 474 Note: if the PCE can compute both intra and inter-area TE LSP 475 paths, both the L and I bits of the PCE-CAPABILITY TLV MUST be set. 476 The flags are not exclusive. This only applies to the PCED TLV 477 carried within the type 10 router information LSA. 479 If a PCE can compute an intra-area TE LSP and an inter-area or inter- 480 AS TE LSP path, it MUST originate: 481 - a type 10 OSPF router information LSA with a PCED TLV having 482 the L, I and A flags of its PCE-CAPABILITY TLV set as 483 described above. 484 - a type 11 OSPF router information LSA with a PCED TLV having 485 L=0 and the I and A flags of its PCE-CAPABILITY TLV set as 486 described above. 488 Example 490 <-----------------AS1-----------------> 492 <---area 1--><----area 0-----><-area 2-> 494 R1---------ABR1*------------ABR3*-----| ------------ 495 | | | | | | 496 | S1 | S2 | ASBR1*--eBGP--ASBR2-| AS2 | 497 | | | | | | 498 R2---------ABR2*------------ABR4------| ------------ 499 The areas contents are not detailed. 501 Assumptions: 502 - area 1 and area 2 are regular areas 503 - the * indicates a Path Computation Element capability 504 - ABR1 is a PCE for area 1 only 505 - ABR2 is a PCE for intra and inter-area TE LSP path computation in 506 area 0 and 1 507 - ABR3 is a PCE for only inter-area TE LSP path computation for the 508 whole domain, 509 - S1 is a PCE for area 1 only 510 - S2 is a PCE for the whole domain, 511 - ASBR1 is a PCE for inter-AS TE LSPs whose destination resides in 512 AS2 (not for intra or inter-area area TE LSPs). 514 In the example above: 515 - S1 originates a type 10 router information LSA with a PCED TLV such 516 that: 517 o The L bit of the PCE-CAPABILITY TLV is set, 518 o The I and A bits of the PCE-CAPABILITY TLV are cleared. 520 - ABR1 originates in area 1 a type 10 router information LSA with a 521 PCED TLV such that: 522 o The L bit of the PCE-CAPABILITY TLV is set, 523 o The I and A bits of the PCE-CAPABILITY sub-TLV are cleared, 525 - ABR2 originates in both area 0 and 1 a type 10 router information 526 LSA with a PCED TLV such that: 527 o The L and I bits of the PCE-CAPABILITY TLV are set, 528 o The A bit of the PCE-CAPABILITY TLV is cleared 530 - ABR3 originates a type 11 router information LSA with a PCED TLV 531 such that: 532 o The L bit of the PCE-CAPABILITY TLV is cleared, 533 o The I bit of the PCE-CAPABILITY TLV is set, 534 o The A bit of the PCE-CAPABILITY TLV is cleared, 536 - S2 originates: 537 - in area 0 a type 10 router information LSA with a PCED TLV 538 such that: 539 o The L and I bits of the PCE-CAPABILITY sub-TLV are 540 set, 541 o The A bit of the PCE-CAPABILITY TLV is cleared, 542 - a type 11 router information LSA with a PCED TLV such that: 543 o The L bit of the PCE-CAPABILITY TLV is cleared, 544 o The I bit of the PCE-CAPABILITY TLV is set, 545 o The A bit of the PCE-CAPABILITY TLV is cleared, 547 - ASBR1 originates a type 11 router information LSA with a PCED TLV 548 such that: 550 o The L bit and the I bit of the PCE-CAPABILITY TLV are cleared, 551 o The A bit of the PCE-CAPABILITY TLV set, 552 o One AS-DOMAIN TLV within the PCED TLV with AS number = AS2 554 The receipt of a new router information LSA carrying a PCED TLV never 555 triggers an SPF calculation. 557 When an LSR or a Path Computation Element is newly configured as a 558 PCE, the corresponding router information LSA MUST be immediately 559 flooded. 561 When a PCE capability changes, the corresponding router information 562 LSA MUST be immediately flooded. 564 When a PCE looses its Path Computation Element capability, the 565 corresponding router information LSA MUST be immediately flooded with 566 LS age = MaxAge. 568 6.3. TE-MESH-GROUP TLV 570 The TE-MESH-GROUP TLV may be carried within a type 10 or 11 router 571 information LSA depending on the MPLS TE mesh-group profile: 573 - If the MPLS TE mesh-group is contained within a single area 574 (all the LSRs have their head-end and tail-end LSR within the 575 same OSPF area), the TE-MESH-GROUP TLV MUST be generated 576 within a Type 10 router information LSA, 577 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE- 578 MESH-GROUP TLV MUST be generated within a Type 11 router 579 information LSA, 581 7. Interoperability with routers non supporting this capability 583 There is no interoperability issue as a router not supporting the TE- 584 NODE-CAP, PCED or TE-MESH-GROUP TLVs SHOULD just silently discard 585 those TLVs as specified in RFC2370. 587 8. Security considerations 589 No new security issues are raised in this document. 591 9. Intellectual Property Statement 593 The IETF takes no position regarding the validity or scope of any 594 Intellectual Property Rights or other rights that might be claimed to 595 pertain to the implementation or use of the technology described in 596 this document or the extent to which any license under such rights 597 might or might not be available; nor does it represent that it has 598 made any independent effort to identify any such rights. Information 599 on the procedures with respect to rights in RFC documents can be 600 found in BCP 78 and BCP 79. 602 Copies of IPR disclosures made to the IETF Secretariat and any 603 assurances of licenses to be made available, or the result of an 604 attempt made to obtain a general license or permission for the use of 605 such proprietary rights by implementers or users of this 606 specification can be obtained from the IETF on-line IPR repository at 607 http://www.ietf.org/ipr. 609 The IETF invites any interested party to bring to its attention any 610 copyrights, patents or patent applications, or other proprietary 611 rights that may cover technology that may be required to implement 612 this standard. Please address the information to the IETF at ietf- 613 ipr@ietf.org.. 615 9.1. IPR Disclosure Acknowledgement 617 By submitting this Internet-Draft, I certify that any applicable 618 patent or other IPR claims of which I am aware have been disclosed, 619 and any of which I become aware will be disclosed, in accordance with 620 RFC 3668. 622 10. References 624 Normative references 626 [RFC] Bradner, S., "Key words for use in RFCs to indicate 627 requirements levels", RFC 2119, March 1997. 629 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 630 RFC 3667, February 2004. 632 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 633 Technology", BCP 79, RFC 3668, February 2004. 635 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 637 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 638 Extensions to OSPF Version 2", RFC 3630, September 2003. 640 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 641 J.P., "Extensions to OSPF for advertising Optional Router 642 Capabilities", draft-ietf-ospf-cap-02.txt, work in progress. 644 [TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions 645 for discovery of TE router information", draft-vasseur-ccamp-te- 646 router-info-00.txt, work in progress. 648 Informative References 650 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 651 Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- 652 gmpls-extensions-12.txt, work in progress. 654 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements 655 for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- 656 mpls-te-req-02.txt, work in progress. 658 [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic 659 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req- 660 07.txt, work in progress. 662 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A 663 Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel- 664 ccamp-inter-domain-framework-01.txt, work in progress. 666 [P2MP-Req] Yasukawa, S., et. al., "Requirements for point-to- 667 multipoint extension to RSVP-TE", draft-ietf-mpls-p2mp-requirement- 668 02.txt, work in progress. 670 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 671 tunnels", RFC 3209, December 2001. 673 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 674 RFC 3473, January 2003. 676 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 677 RSVP-TE for point-to-multipoint TE LSPs", draft-dry-mpls-rsvp-te- 678 p2mp-00.txt, work in progress. 680 11. Authors' Address: 682 Jean-Philippe Vasseur (Editor) 683 Cisco Systems, Inc. 684 300 Beaver Brook Road 685 Boxborough , MA - 01719 686 USA 687 Email: jpv@cisco.com 689 Peter Psenak 690 CISCO Systems, Inc. 691 Pegasus Parc 692 De Kleetlaan 6A 693 1831, Diegem 694 BELGIUM 695 Email: ppsenak@cisco.com 697 Seisho Yasukawa 698 NTT Network Service Systems Laboratories, NTT Corporation 699 9-11, Midori-Cho 3-Chome 700 Musashino-Shi, Tokyo 180-8585 Japan 701 Phone: + 81 422 59 4769 702 Email: yasukawa.seisho@lab.ntt.co.jp 704 Jean-Louis Le Roux 705 France Telecom 706 2, avenue Pierre-Marzin 707 22307 Lannion Cedex 708 FRANCE 709 Email: jeanlouis.leroux@francetelecom.com 711 Full Copyright Statement 713 Copyright (C) The Internet Society (2004). This document is subject to 714 the rights, licenses and restrictions contained in BCP 78, and except as 715 set forth therein, the authors retain all their rights. 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 719 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 720 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 721 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.