idnits 2.17.00 (12 Aug 2021) /tmp/idnits41763/draft-ietf-pce-disco-proto-igp-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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1202. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 8 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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: Note that a change in PCED information MUST not trigger normal SPF computation. == 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: Note that a change in PCED information MUST not trigger normal SPF computation. -- 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 (December 2005) is 6000 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: 'ISIS-CAP' is mentioned on line 750, but not defined == Missing Reference: 'PCE-DISC-REQ' is mentioned on line 182, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 713, but not defined == Unused Reference: 'OSPF-v2' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'IS-IS-TE' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1150, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) == Outdated reference: draft-ietf-ospf-cap has been published as RFC 4970 == Outdated reference: draft-ietf-isis-caps has been published as RFC 4971 == Outdated reference: draft-ietf-pce-architecture has been published as RFC 4655 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-architecture (ref. 'PCE-ARCH') == Outdated reference: draft-ietf-pce-discovery-reqs has been published as RFC 4674 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-discovery-reqs (ref. 'PCE-DISCO-REQ') -- Obsolete informational reference (is this intentional?): RFC 3667 (Obsoleted by RFC 3978) -- Obsolete informational reference (is this intentional?): RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: draft-ietf-pce-comm-protocol-gen-reqs has been published as RFC 4657 Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux (Editor) 3 Internet Draft France Telecom 4 Category: Standard Track J.P. Vasseur (Editor) 5 Expires: May 2006 Cisco System Inc. 6 Yuichi Ikejiri 7 NTT 9 December 2005 11 IGP protocol extensions for Path Computation Element (PCE) Discovery 13 draft-ietf-pce-disco-proto-igp-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute 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 In various situations it would be highly useful for a Path 40 Computation Client (PCC) to be able to dynamically and automatically 41 discover a set of Path Computation Element(s) (PCE), along with some 42 of information relevant for PCE selection. When the PCE is an LSR 43 participating to the IGP, or even a server participating passively to 44 the IGP, a simple and efficient way for PCE discovery, consists of 45 relying on IGP flooding. For that purpose this document defines 46 simple OSPF and ISIS extensions for the advertisement of PCE 47 Discovery information within and across IGP areas. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119. 55 Table of Contents 57 1. Note........................................................3 58 2. Terminology.................................................3 59 3. Introduction................................................4 60 4. PCE Discovery Information...................................5 61 4.1. Description.................................................5 62 4.2. Mandatory versus optional PCE information...................5 63 4.3. Flooding scope..............................................5 64 4.4. Frequency of change.........................................6 65 5. OSPF extensions.............................................6 66 5.1. The OSPF PCED TLV...........................................6 67 5.1.1. PCE-ADDRESS sub-TLV.........................................7 68 5.1.2. PATH-SCOPE sub-TLV..........................................8 69 5.1.3. PCE-DOMAINS sub-TLV.........................................9 70 5.1.3.1. IPv4 area ID DOMAIN sub-TLV..............................10 71 5.1.3.2. IPv6 area ID DOMAIN sub-TLV..............................11 72 5.1.3.3. AS Number sub-TLV........................................11 73 5.1.4. PCE-DEST-DOMAINS sub-TLV...................................11 74 5.1.5. The GENERAL-CAP sub-TLV....................................12 75 5.1.6. The PATH-COMP-CAP sub-TLV..................................13 76 5.2. Elements of Procedure......................................14 77 6. ISIS extensions............................................16 78 6.1. IS-IS PCED TLV format......................................16 79 6.1.1. PCE-ADDRESS sub-TLV........................................17 80 6.1.2. The PATH-SCOPE sub-TLV.....................................17 81 6.1.3. PCE-DOMAINS sub-TLV........................................19 82 6.1.3.1. Area ID DOMAIN sub-TLV...................................19 83 6.1.3.2. AS Number DOMAIN sub-TLV.................................19 84 6.1.4. PCE-DEST-DOMAINS sub-TLV...................................20 85 6.1.5. GENERAL-CAP sub-TLV........................................20 86 6.1.6. The PATH-COMP-CAP sub-TLV..................................21 87 6.2. Elements of procedure......................................22 88 7. Backward compatibility.....................................22 89 8. Security Considerations....................................22 90 9. IANA considerations........................................22 91 9.1. OSPF TLVs..................................................22 92 9.2. ISIS TLVs..................................................23 93 9.3. Capability bits............................................23 94 10. Security Considerations....................................24 95 11. References.................................................24 96 11.1. Normative references.......................................24 97 11.2. Informative references.....................................24 98 12. Authors' Addresses:........................................25 99 13. Intellectual Property Statement............................25 101 1. Note 103 This document specifies new TLVs and sub-TLVs to be carried within 104 the OSPF Router information LSA ([OSPF-CAP]) and ISIS Router 105 Capability TLV ([ISIS-CAP]). Because this document does not introduce 106 any new element of procedure it will be discussed within the PCE 107 Working Group with a review of the OSPF and ISIS Working Groups. 108 Furthermore, once stabilized, it may be decided to split the document 109 in two documents addressing the OSPF and ISIS aspects respectively. 111 2. Terminology 113 Terminology used in this document 115 LSR: Label Switch Router 117 TE LSP: Traffic Engineered Label Switched Path 119 PCE: Path Computation Element: an entity (component, application, 120 or network node) that is capable of computing a network path or 121 route based on a network graph, and applying computational 122 constraints. 124 PCC: Path Computation Client: any client application requesting a 125 path computation to be performed by a Path Computation Element. 127 IGP Area: OSPF Area or ISIS level 129 ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router) 131 AS: Autonomous System 133 ASBR: AS Border Router 135 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 136 boundaries. 138 Inter-area TE LSP: A TE LSP whose path transits through 139 two or more IGP areas. 141 Inter-AS MPLS TE LSP: A TE LSP whose path transits 142 through two or more ASes or sub-ASes (BGP confederations). 144 Domain: any collection of network elements within a common sphere 145 of address management or path computational responsibility. 146 Examples of domains include IGP areas and Autonomous Systems. 148 3. Introduction 150 [PCE-ARCH] describes the motivations and architecture for a PCE-based 151 path computation model for MPLS and GMPLS TE LSPs. The model allows 152 the separation of PCE from PCC (also referred to as non co-located 153 PCE) and allows cooperation between PCEs. This relies on a 154 communication protocol between PCC and PCE, and between PCEs, whose 155 generic requirements are listed in [PCE-COM-REQ]. 157 The PCE architecture requires, of course, that a PCC be aware of the 158 location of one or more PCEs in its domain, and also potentially of 159 some PCEs in other domains, e.g. in case of inter-domain path 160 computation. 162 A network may comprise a large number of PCEs with potentially 163 distinct capabilities. In such context it would be highly desirable 164 to have a mechanism for automatic and dynamic PCE discovery, which 165 would allow PCCs to automatically discover a set of PCEs, including 166 information required for PCE selection, and to dynamically detect new 167 PCEs or any modification of PCE information. This includes the 168 discovery by a PCC of a set of one or more PCEs in its domain, and 169 potentially in some other domains. The latter is a desirable function 170 in the case of inter-domain path computation for example. 171 Detailed requirements for such a PCE discovery mechanism are 172 described in [PCE-DISCO-REQ]. 174 When PCCs are LSRs participating to the IGP (OSPF, ISIS), and PCEs 175 are LSRs participating to the IGP or any network servers 176 participating to the IGP, an efficient mechanism for PCE discovery 177 consists of relying on IGP advertisement. 179 This document defines OSPF and ISIS extensions allowing a PCE 180 participating to the IGP to advertise its location along with some 181 information useful for PCE selection so as to satisfy dynamic PCE 182 discovery requirements set forth in [PCE-DISC-REQ]. 184 Generic capability mechanisms have been defined in [OSPF-CAP] and 185 [ISIS-CAP] for OSPF and ISIS respectively the purpose of which is to 186 allow a router to advertise its capability within an IGP area or an 187 entire routing domain. This perfectly fits with the aforementioned 188 dynamic PCE discovery requirements. Thus, a new TLV (named the PCE 189 Discovery (PCED) TLV) is defined for ISIS and OSPF to be carried 190 within the ISIS Capability TLV ([ISIS-CAP]) for ISIS and the OSPF 191 Router Information LSA ([OSPF-CAP]). 193 The PCE discovery information is detailed in section 3. Protocol 194 extensions and procedures are defined in section 4 and 5 for ISIS and 195 OSPF respectively. This document does not define any new OSPF or ISIS 196 element of procedure but how the procedures defined in [OSPF-CAP] and 197 [ISIS-CAP] should be used. 199 The routing extensions defined in this document allow for PCE 200 discovery within and across IGP areas. Solutions for PCE discovery 201 across AS boundaries are for further study. 203 4. PCE Discovery Information 205 4.1. Description 207 The PCE Discovery information allows for dynamic discovery of PCEs. 208 This information is advertised by means of IGP advertisements by 209 PCE(s) participating to the IGP. It allows all PCCs participating to 210 the IGP to dynamically discover PCEs along with information useful 211 for PCE selection. 213 Such dynamic PCE discovery has various advantages: 214 - Simplified PCC configuration, 215 - Reduces risk of misconfiguration, 216 - Dynamic detection of a new PCE, 217 - Dynamic detection of any change in PCE information 218 - Dynamic detection of PCE aliveness (PCE liveness may require 219 additional mechanisms provided by the PCC-PCE communication 220 protocol) 222 4.2. Mandatory versus optional PCE information 224 The PCE Discovery information is comprised of: 226 - The PCE location: This is a set of one ore more IPv4 and or IPv6 227 addresses used to reach the PCE. These are basically loopback 228 addresses always reachable provided that the PCE is still alive. 230 - The PCE inter-domain functions: this refers to the PCE path 231 computation scope (i.e. inter-area, inter-AS, inter-layer…). 233 - The PCE domain(s): This is the set domain(s) where the PCE has 234 visibility and can compute paths. 236 - The set of destination domain(s) towards which a PCE can compute 237 paths. 239 - A set of general PCE capabilities (e.g. support for request 240 prioritization) and path computation specific PCE capabilities 241 (e.g. supported constraints, supported objective functions…) 242 These are two variable length sets of bits flags, where each bit 243 represent a given PCE capability. 245 4.3. Flooding scope 247 The PCE Discovery information can be flooded locally within the IGP 248 area the PCE belongs to, or globally across the entire routing 249 domain. Note that some PCEs may belong to multiple areas, in which 250 case the flooding scope can correspond to these areas. This could be 251 the case of an ABR for instance that can advertise its PCE 252 information within the backbone area and/or a subset of its attached 253 IGP area(s). 255 4.4. Frequency of change 257 The rate at which PCE information is advertised must be controlled so 258 as to not impact by any mean the IGP scalability. Changes in PCE 259 information may occur as result of PCE configuration updates, PCE 260 deployment/activation or PCE deactivation/suppression. Hence, this 261 information is not expected to change frequently. 263 5. OSPF extensions 265 5.1. The OSPF PCED TLV 267 The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered 268 sub-TLVs. 270 The format of the OSPF PCED TLV and its sub-TLVs is the identical as 271 the TLV format used by the Traffic Engineering Extensions to OSPF 272 [OSPF-TE]. That is, the TLV is composed of 2 octets for the type, 2 273 octets specifying the TLV length and a value field. The Length field 274 defines the length of the value portion in octets. 275 The TLV is padded to four-octet alignment; padding is not included in 276 the length field (so a three octet value would have a length of 277 three, but the total size of the TLV would be eight octets). Nested 278 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 279 types between 32768 and 65535 are reserved for vendor-specific 280 extensions. All other undefined type codes are reserved for future 281 assignment by IANA. 283 The OSPF PCED TLV has the following format: 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 // sub-TLVs // 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Type To be defined by IANA (suggested value=2) 295 Length Variable 296 Value This comprises one or more sub-TLVs 298 Sub-TLVs types are under IANA control. 300 Currently five sub-TLVs are defined (type values to be assigned by 301 IANA): 303 Sub-TLV type Length Name 304 1 variable PCE-ADDRESS sub-TLV 305 2 4 PATH-SCOPE sub-TLV 306 3 variable PCE-DOMAINS sub-TLV 307 4 variable PCE-DEST-DOMAINS sub-TLV 308 5 variable GENERAL-CAP sub-TLV 309 6 variable PATH-COMP-CAP sub-TLV 311 The sub-TLVs PCE-ADDRESS and PATH SCOPE MUST always be present within 312 the PCED TLV. 314 The sub-TLVs PCE-DOMAINS and DEST-DOMAINS, MUST only be present in 315 some particular inter-domain cases. 317 The GENERAL-CAP and PATH-COMP-CAP are optional and MAY be present in 318 the PCED TLV to facilitate PCE selection. 320 Any non recognized sub-TLV MUST be silently ignored. 322 Additional sub-TLVs could be added in the future to advertise 323 additional information. 325 The PCED TLV is carried within an OSPF Router Information LSA which 326 is defined in [OSPF-CAP]. 328 5.1.1. PCE-ADDRESS sub-TLV 330 The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach 331 the PCE. This address will typically be a loop-back address that is 332 always reachable, provided that the PCE is alive. 333 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 334 PCED TLV. 336 The format of the PCE-ADDRESS sub-TLV is as follows: 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | address-type | Reserved | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 // PCE IP Address // 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 PCE-ADDRESS sub-TLV format 351 Type To be assigned by IANA (suggested value =1) 352 Length 8 or 20 353 Address-type: 354 1 IPv4 355 2 IPv6 356 PCE IP Address: The IP address to be used to reach the PCE. 357 This is the address that will be used for 358 setting up PCC-PCE communication sessions. 360 The PCE-ADDRESS sub-TLV MUST appear at least once in the PCED sub-TLV 361 originated by a PCE. It MAY appear multiple times, for instance when 362 the PCE has both an IPv4 and IPv6 address. 364 5.1.2. PATH-SCOPE sub-TLV 366 The PATH-SCOPE sub-TLV indicates the PCE path computation scope; in 367 other words the ability of the PCE to compute or take part into the 368 computation of intra-area, inter-area, inter-AS or inter-layer_TE 369 LSP(s). 371 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 372 PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each 373 PCED TLV. 375 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 376 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 377 and two fields indicating PCE preferences. 379 The PATH-SCOPE sub-TLV has the following format: 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |0|1|2|3|4|5| Reserved |PrefR|PrefS| Reserved | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Type To be defined by IANA (suggested value =3) 389 Length Variable 390 Value This comprises a 2 bytes flag where each bit 391 represents a supported path scope, as well as two 392 preference fields allowing to specify PCE preferences. 394 The following bits are defined: 396 Bit Path Scope 398 0 L bit: Can compute intra-area path 399 1 R bit: Can act as PCE for inter-area TE LSPs 400 computation 401 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 402 computation 404 3 S bit: Can act as PCE for inter-AS TE LSPs computation 405 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 406 computation 407 5 Y bit: Can compute or take part into the computation of 408 paths across layers. 410 Pref field: PCE’s preference 412 Pref-S field: PCE’s preference for inter-AS TE LSPs computation 414 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 415 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 416 respectively. These bits are non exclusive. 418 When set the Rd bit indicates that the PCE can act as a default PCE 419 for inter-area TE LSPs computation, it means that it can compute path 420 for any destination area. Similarly, when set the Sd bit indicates 421 that the PCE can act as a default PCE for inter-AS TE LSPs 422 computation, it means that it can compute path for any destination 423 AS. 425 When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not 426 comprise any Area ID DOMAIN sub-TLV. 427 When the Sd bit is set the PCE-DEST-DOMAIN TLV does not comprise any 428 AS DOMAIN sub-TLV. 430 The PrefR and PrefS fields are 3-bit long and allow the PCE to 431 specify a preference where 7 reflects the highest preference. For the 432 sake of illustration, consider the situation where N ABRs act as PCEs 433 for inter-area TE LSPs computation. An operator may decide to 434 configure a preference to each PCE that could be used to load balance 435 the path computation load with respect to their respective CPU 436 capacity. The algorithms used by a PCC to load balance its path 437 computation requests according to such PCE’s preference is out of the 438 scope of this document. 440 5.1.3. PCE-DOMAINS sub-TLV 442 The PCE-DOMAINS sub-TLV specifies the set of domains (areas, AS) 443 where the PCE has topology visibility and can compute paths. It 444 contains a set of one or more sub-TLVs where each sub-TLV identifies 445 a domain. 447 The PCE-DOMAINS sub-TLV MUST only be present when PCE domains cannot 448 be inferred by other IGP information, for instance when the PCE is 449 inter-domain capable (i.e. when the R bit or S bit is set) and the 450 flooding scope the entire routing domain. 452 The PCE-DOMAINS sub-TLV has the following format: 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type | Length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 // DOMAIN sub-TLVs // 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Type To be defined by IANA (suggested value =3) 464 Length Variable 465 Value This comprises a set of one or more DOMAIN sub-TLVs 466 where each DOMAIN sub-TLV identifies a domain where 467 the PCE has topology visibility and can compute TE LSP 468 paths. 470 Sub-TLVs types are under IANA control. 472 Currently three DOMAIN sub-TLVs are defined (suggested type values to 473 be assigned by IANA): 474 Sub-TLV type Length Name 475 1 variable IPv4 area ID sub-TLV 476 2 variable IPv6 area ID sub-TLV 477 3 variable AS number sub-TLV 479 The PCE-DOMAINS sub-TLV MUST include at least one DOMAIN sub-TLV. 480 Note than when the PCE visibility is an entire AS, the PCE-DOMAINS 481 sub-TLV MUST uniquely include one AS number sub-TLV. 483 5.1.3.1. IPv4 area ID DOMAIN sub-TLV 485 The IPv4 area ID DOMAIN sub-TLV carries an IPv4 OSPF area identifier. 486 It has the following format: 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type | Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | IPv4 Area ID | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Type To be assigned by IANA (suggested value =1) 496 Length 4 497 IPv4 OSPF area ID: The IPv4 identifier of the OSPF area 499 5.1.3.2. IPv6 area ID DOMAIN sub-TLV 501 The IPv6 area ID sub-TLV carries an IPv6 OSPF area identifier. It has 502 the following format: 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | IPv6 Area ID | 509 | | 510 | | 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Type To be assigned by IANA (suggested value =2) 515 Length 16 516 IPv6 OSPF area ID: The IPv6 identifier of the OSPF area 518 5.1.3.3. AS Number sub-TLV 520 The AS Number sub-TLV carries an AS number. It has the following 521 format: 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | AS Number | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Type To be assigned by IANA (suggested value =3) 531 Length 4 532 AS Number: AS number identifying an AS. When coded on two 533 bytes (which is the current defined format as the 534 time of writing this document), the AS Number field 535 MUST have its left two bytes set to 0. 537 5.1.4. PCE-DEST-DOMAINS sub-TLV 539 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 540 (areas, AS) toward which a PCE can compute path. It means that the 541 PCE can compute or take part in the computation of inter-domain LSPs 542 whose destination is located in one of these domains. It contains a 543 set of one or more sub-TLVs where each sub-TLV identifies a domain. 545 The PCE-DEST-DOMAINS sub-TLV has the following format: 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | | 552 // DOMAIN sub-TLVs // 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Type To be defined by IANA (suggested value =3) 557 Length Variable 558 Value This comprises a set of one or more Area and/or AS 559 DOMAIN sub-TLVs where each DOMAIN sub-TLV identifies a 560 domain toward which a PCE can compute paths. 562 The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub- 563 TLV. 565 The PCE-DEST-DOMAINS sub-TLV is optional. It MUST be present only if 566 the R bit is set and the Rd bit is cleared, and/or, if the S bit is 567 set and the Sd bit is cleared. 569 The PCE-DEST-DOMAINS sub-TLV MUST include at least one area ID sub- 570 TLV, if the R bit of the PATH-SCOPE TLV is set and the Rd bit of the 571 PATH-SCOPE TLV is cleared. 572 Similarly, the PCE-DEST- DOMAINS sub-TLV MUST include at least one AS 573 number sub-TLV if the S bit of the PATH-SCOPE TLV is set and the Sd 574 bit of the PATH-SCOPE TLV is cleared. 576 5.1.5. The GENERAL-CAP sub-TLV 578 The GENERAL-CAP sub-TLV is used to indicate general PCE capabilities. 579 The GENERAL-CAP sub-TLV is optional. It MAY be carried within the 580 PCED TLV. 581 The value field of the GENERAL-CAP sub-TLV is made of bit flags, 582 where each bit corresponds to a general PCE capability. 584 The format of the GENERAL-CAP sub-TLV is as follows: 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type | Length | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | General PCE Capabilities | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 // Optional sub-TLVs // 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Type To be assigned by IANA (suggested value =1) 597 Length It is set to N x 4 octets. N starts 598 from 1 and can be increased when there is a need. 599 Each 4 octets are referred to as a capability flag. 600 Value This comprises one or more capability flags. 601 For each 4 octets, the bits are indexed from the most 602 significant to the least significant, where each bit 603 represents one general PCE capability. When 604 the first 32 capabilities are defined, a new 605 capability flag will be used to accommodate the next 606 capability. Optional TLVs may be defined to specify 607 more complex capabilities: there is no optional TLVs 608 currently defined. 610 IANA is requested to manage the space of general PCE capability bit 611 flags. 613 The following bits in the first capability flag are to be assigned by 614 IANA: 616 Bit Capabilities 618 0 P bit: Support for Request prioritization. 619 1 M bit: Support for multiple messages within the same 620 request message. 622 2-31 Reserved for future assignments by IANA. 624 5.1.6. The PATH-COMP-CAP sub-TLV 626 The PATH-COMP-CAP sub-TLV is used to indicate path computation 627 specific capabilities of a PCE. 628 The PATH-COMP-CAP sub-TLV is optional. It MAY be carried within the 629 PCED TLV. 630 This is a series of bit flags, where each bit correspond to a path 631 computation capability. 633 The format of the PATH-COMP-CAP sub-TLV is as follows: 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Type | Length | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Path Computation Capabilities | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 // Optional sub-TLVs // 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Type To be assigned by IANA (suggested value =1) 646 Length It is set to N x 4 octets. N starts 647 from 1 and can be increased when there is a need. 648 Each 4 octets are referred to as a capability flag. 649 Value This comprises one or more capability flags. 650 For each 4 octets, the bits are indexed from the most 651 significant to the least significant, where each bit 652 represents one path computation PCE capability. When 653 the first 32 capabilities are defined, a new 654 capability flag will be used to accommodate the next 655 capability. Optional TLVs may be defined to specify 656 more complex capabilities: there is no optional TLVs 657 currently defined. 659 IANA is requested to manage the space of PCE path commutation 660 capability bit flags. 662 The following bits in the first capability flag are to be assigned by 663 IANA: 665 Bit Capabilities 667 0 M bit: Capability to compute P2P paths in MPLS-TE networks 668 1 G bit: Capability to compute P2P paths in GMPLS networks 669 2 D bit: Capability to compute link/node/SRLG diverse paths 670 3 L bit: Capability to compute load-balanced paths 671 4 S bit: Capability to compute a set of paths in a 672 synchronized Manner 673 5 O bit: Support for multiple objective functions 675 6-31 Reserved for future assignments by IANA. 677 The M, G, D, L, S and O bits are not exclusive. 679 5.2. Elements of Procedure 681 The PCED TLV is carried within an OSPF Router information opaque LSA 682 (opaque type of 4, opaque ID of 0) which is defined in [OSPF-CAP]. 684 A router MUST originate a new OSPF router information LSA whenever 685 the content of any of the carried TLVs changes or whenever 686 required by the regular OSPF procedure (LSA refresh (every 687 LSRefreshTime)). 689 The PCED TLV may be carried within a type 10 or 11 router information 690 LSA depending on the flooding scope of the PCE information. 692 If the flooding scope is local to an area then it MUST be carried 693 within a type 10 router information LSA. 694 If the flooding scope is the entire domain then it MUST be carried 695 within type 11 router information LSA. 696 Note that when the L bit of the PATH-SCOPE TLV is set and the R bit 697 and S bit are cleared, the flooding scope MUST be local, and the PCED 698 TLV MUST be carried within a type 10 Router Information LSA. 700 PCED TLVs are OPTIONAL. When an OSPF LSA does not contain any PCED 701 TLV, this means that the PCE information of that node is unknown. 703 Note that a change in PCED information MUST not trigger normal SPF 704 computation. 706 6. ISIS extensions 708 6.1. IS-IS PCED TLV format 710 The IS-IS PCED TLV is made of various non ordered sub-TLVs. 712 The format of the IS-IS PCED TLV and its sub-TLVs is the same as the 713 TLV format used by the Traffic Engineering Extensions to IS-IS [ISIS- 714 TE]. That is, the TLV is composed of 1 octet for the 715 type, 1 octet specifying the TLV length and a value field. 717 The IS-IS PCED TLV has the following format: 719 TYPE: To be assigned by IANA 720 LENGTH: Variable 721 VALUE: set of sub-TLVs 723 Sub-TLVs types are under IANA control. 725 Currently five sub-TLVs are defined (suggested type values to be 726 assigned by IANA): 727 Sub-TLV type Length Name 728 1 variable PCE-ADDRESS sub-TLV 729 2 2 PATH-SCOPE sub-TLV 730 3 variable PCE-DOMAINS sub-TLV 731 4 variable PCE-DEST-DOMAINS sub-TLV 732 5 variable GENERAL-CAP sub-TLV 733 6 variable PATH-COMP-CAP sub-TLV 735 The sub-TLVs PCE-ADDRESS and PATH-SCOPE MUST always be present within 736 the PCED TLV. 738 The sub-TLVs PCE-DOMAINS and DEST-DOMAINS, MUST only be present in 739 some particular inter-domain cases. 741 The GENERAL-CAP and PATH-COMP-CAP are optional and MAY be present in 742 the PCED TLV to facilitate PCE selection. 744 Any non recognized sub-TLV MUST be silently ignored. 746 Additional sub-TLVs could be added in the future to advertise 747 additional PCE information. 749 The PCED TLV is carried within an ISIS CAPABILITY TLV which is 750 defined in [ISIS-CAP]. 752 6.1.1. PCE-ADDRESS sub-TLV 754 The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach 755 the PCE. This address will typically be a loop-back address that is 756 always reachable, provided the PCE is alive. 757 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 758 PCED TLV. 760 The PCE-ADDRESS sub-TLV has the following format: 762 TYPE: To be assigned by IANA (Suggested value =1) 763 LENGTH: 4 for IPv4 address and 16 for IPv6 address 764 VALUE: This comprises one octet indicating the address-type and 4 765 or 16 octets encoding the IPv4 or IPv6 address to be used 766 to reach the PCE 768 Address-type: 769 1 IPv4 770 2 IPv6 772 The PCE-ADDRESS sub-TLV MUST appear at least once in the PCED sub-LTV 773 originated by a PCE. It MAY appear multiple times, for instance when 774 the PCE has both an IPv4 and IPv6 address. 776 6.1.2. The PATH-SCOPE sub-TLV 778 The PATH-SCOPE sub-TLV indicates the PCE path computation scope; in 779 other words the ability of the PCE to compute or take part into the 780 computation of intra-area, inter-area, inter-AS or inter-layer_TE 781 LSP(s). 783 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 784 PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each 785 PCED TLV. 787 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 788 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 789 and two fields indicating PCE preferences. 791 The PATH-SCOPE sub-TLV has the following format: 793 TYPE: To be assigned by IANA (Suggested value =2) 794 LENGTH: Variable 795 VALUE: This comprises a one-byte flag of bits where each bit 796 represents a supported path scope, followed by a one-byte 797 preference field indicating PCE preferences. 799 Here is the structure of the bits flag: 801 0 1 2 3 4 5 6 7 802 +-+-+-+-+-+-+-+-+ 803 |0|1|2|3|4|5|Res| 804 +-+-+-+-+-+-+-+-+ 806 Bit Path Scope 808 0 L bit: Can compute intra-area path 809 1 R bit: Can act as PCE for inter-area TE LSPs 810 computation 811 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 812 computation 813 3 S bit: Can act as PCE for inter-AS TE LSPs computation 814 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 815 computation 816 5 Y bit: Can compute or take part into the computation of 817 paths across layers 819 Here is the structure of the preference field 821 0 1 2 3 4 5 6 7 822 +-+-+-+-+-+-+-+-+ 823 |PrefR|PrefS|Res| 824 +-+-+-+-+-+-+-+-+ 826 PrefR field: PCE’s preference for inter-area TE LSPs computation 828 PrefS field: PCE’s preference for inter-AS TE LSPs computation 830 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 831 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 832 respectively. These bits are non exclusive. 834 When set the Rd bit indicates that the PCE can act as a default PCE 835 for inter-area TE LSPs computation, it means that it can compute path 836 for any destination area. Similarly, when set the Sd bit indicates 837 that the PCE can act as a default PCE for inter-AS TE LSPs 838 computation, it means that it can compute path for any destination 839 AS. 841 When the Rd bit is set the PCE-DEST-DOMAINS TLV (see 6.1.4) does not 842 comprise any Area ID DOMAIN sub-TLV. When the Sd bit is set the PCE- 843 DEST-DOMAINS TLV does not comprise any AS DOMAIN sub-TLV. 845 The PrefR and PrefS fields are 3-bit long and allow the PCE to 846 specify a preference where 7 reflects the highest preference. For the 847 sake of illustration, consider the situation where N ABRs act as PCEs 848 for inter-area TE LSPs computation. An operator may decide to 849 configure a preference to each PCE that could be used to load balance 850 the path computation load with respect to their respective CPU 851 capacity. The algorithms used by a PCC to load balance its path 852 computation requests according to such PCE’s preference is out of the 853 scope of this document 855 6.1.3. PCE-DOMAINS sub-TLV 857 The PCE-DOMAINS sub-TLV specifies the set of domains (areas, AS) 858 where the PCE has topology visibility and can compute paths. It 859 contains a set of one or more sub-TLVs where each sub-TLV identifies 860 a domain. 862 The PCE-DOMAINS sub-TLV MUST only be present when PCE domains cannot 863 be inferred by other IGP information, for instance when the PCE is 864 inter-domain capable (i.e. when the R bit or S bit is set) and the 865 flooding scope is the entire routing domain. 867 The PCE-DOMAINS sub-TLV has the following format: 869 TYPE: To be assigned by IANA (Suggested value =2) 870 LENGTH: Variable 871 VALUE: This comprises a set of one or more DOMAIN sub-TLVs where 872 each DOMAIN sub-TLV identifies a domain where the PCE has 873 topology visibility and can compute paths 875 DOMAIN Sub-TLVs types are under IANA control. 877 Currently two DOMAIN sub-TLVs are defined (suggested type values to 878 be assigned by IANA): 879 Sub-TLV type Length Name 880 1 variable Area ID sub-TLV 881 2 variable AS number sub-TLV 883 At least one DOMAIN sub-TLV MUST be present in the PCE-DOMAINS sub- 884 TLV. 886 6.1.3.1. Area ID DOMAIN sub-TLV 888 This sub-TLV carries an ISIS area ID. It has the following format 890 TYPE: To be assigned by IANA (Suggested value =1) 891 LENGTH: Variable 892 VALUE: This comprises a variable length ISIS area ID. This is the 893 combination of an Initial Domain Part (IDP) and High Order 894 part of the Domain Specific part (HO-DPS) 896 6.1.3.2. AS Number DOMAIN sub-TLV 898 The AS Number sub-TLV carries an AS number. It has the following 899 format: 901 TYPE: To be assigned by IANA (Suggested value =2) 902 LENGTH: 4 903 VALUE: AS number identifying an AS. When coded on two 904 bytes (which is the current defined format as the 905 time of writing this document), the AS Number field 906 MUST have its left two bytes set to 0. 908 6.1.4. PCE-DEST-DOMAINS sub-TLV 910 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 911 (areas, AS) toward which a PCE can compute path. It means that the 912 PCE can compute or take part in the computation of inter-domain LSPs 913 whose destination is located in one of these domains. It contains a 914 set of one or more DOMAIN sub-TLVs where each DOMAIN sub-TLV 915 identifies a domain. 917 The PCE-DEST-DOMAINS sub-TLV has the following format: 919 TYPE: To be assigned by IANA (Suggested value =2) 920 LENGTH: Variable 921 VALUE: This comprises a set of one or more Area or/and AS DOMAIN sub- 922 TLVs where each sub-TLV identifies a destination domain toward 923 which a PCE can compute path. 925 At least one DOMAIN sub-TLV MUST be present in the PCE-DEST-DOMAINS 926 sub-TLV. 928 The PCE-DEST-DOMAINS sub-TLV is optional. It MUST be present only if 929 the R bit is set and the Rd bit is cleared, and/or, if the S bit is 930 set and the Sd bit is cleared. 932 The PCE-DEST-DOMAINS sub-TLV MUST include at least one area ID sub- 933 TLV, if the R bit of the PATH-SCOPE TLV is set and the Rd bit of the 934 PATH-SCOPE TLV is cleared. Similarly, the PCE-DEST-DOMAINS sub-TLV 935 MUST include at least one AS number sub-TLV if the S bit of the PATH- 936 SCOPE TLV is set and the Sd bit of the PATH-SCOPE TLV is cleared. 938 6.1.5. GENERAL-CAP sub-TLV 940 The GENERAL-CAP sub-TLV is used to indicate general PCE capabilities. 941 The GENERAL-CAP sub-TLV is optional. It MAY be carried within the 942 PCED TLV. 943 This is a series of bits flags, where each bit corresponds to a 944 general PCE capability. 946 The GENERAL-CAP sub-TLV has the following format: 948 TYPE: To be assigned by IANA (Suggested value =4) 949 LENGTH: It is set to N. N starts from 1 and can be increased when 950 there is a need. Each octet is referred to as a 951 capability flag. 953 VALUE: This comprises one or more general PCE capability 954 flags. 956 The following bits in the first capability flag are to be assigned by 957 IANA: 959 0 1 2 3 4 5 6 7 960 +-+-+-+-+-+-+-+-+ 961 |P|M| Reserved | 962 +-+-+-+-+-+-+-+-+ 964 P bit: Support for request prioritization. 965 M bit: Support for multiple messages within the same request message. 967 Reserved bits are for future assignment by IANA. 969 6.1.6. The PATH-COMP-CAP sub-TLV 971 The PATH-COMP-CAP sub-TLV is used to indicate path computation 972 specific capabilities of a PCE. 973 The PATH-COMP-CAP sub-TLV is optional. It MAY be carried within the 974 PCED TLV. 975 This is a series of bit flags, where each bit correspond to a path 976 computation capability. 978 The PATH-COMP-CAP sub-TLV has the following format: 980 TYPE: To be assigned by IANA (suggested value = 5) 981 LENGTH: It is set to N. N starts from 1 and can be increased 982 when there is a need. Each octet is referred to as a 983 capability flag. 984 VALUE: This comprises one or more Path Computation specific PCE 985 capability flags. 987 The following bits in the first capability flag are to be assigned by 988 IANA. 990 0 1 2 3 4 5 6 7 991 +-+-+-+-+-+-+-+-+ 992 |M|G|D|L|S|0|Res| 993 +-+-+-+-+-+-+-+-+ 995 M bit: Capability to compute P2P paths in MPLS-TE networks 996 G bit: Capability to compute P2P paths in GMPLS networks 997 D bit: Capability to compute link/node/SRLG diverse paths 998 L bit: Capability to compute load-balanced paths 999 S bit: Capability to compute a set of paths in a 1000 synchronized Manner 1001 O bit: Support for multiple objective functions 1003 Reserved bits are for future assignment by IANA. 1005 6.2. Elements of procedure 1007 The PCED TLV is carried within an IS-IS CAPABILITY TLV defined in 1008 [IS-IS-CAP]. 1010 An IS-IS router MUST originate a new IS-IS LSP whenever the content 1011 of any of the PCED TLV changes or whenever required by the regular 1012 IS-IS procedure (LSP refresh). 1014 When the scope of the PCED TLV is area local it MUST be carried 1015 within an ISIS CAPABILITY TLV having the S bit cleared. 1016 When the scope of the PCED TLV is the entire domain, the PCED TLV 1017 MUST be carried within an ISIS CAPABILITY TLV having the S bit set. 1018 Note that when the L bit of the PATH-SCOPE sub-TLV is set and the R 1019 and S bits are cleared the flooding scope MUST be local. 1021 PCED TLVs are OPTIONAL. When an IS-IS LSP does not contain any PCED 1022 TLV, this means that the PCE information of that node is unknown. 1024 Note that a change in PCED information MUST not trigger normal SPF 1025 computation. 1027 7. Backward compatibility 1029 The PCED TLVs defined in this document do not introduce any 1030 interoperability issue. For OSPF, a router not supporting the PCED 1031 TLV SHOULD just silently ignore the TLV as specified in RFC2370. For 1032 IS-IS a router not supporting the PCED TLV SHOULD just silently 1033 ignore the TLV. 1035 8. Security Considerations 1037 No new security issues are raised in this document. 1039 9. IANA considerations 1041 9.1. OSPF TLVs 1043 IANA will assign a new codepoint for the OSPF PCED TLV defined in 1044 this document and carried within the Router Information LSA. 1046 Five sub-TLVs types are defined for this TLV and should be assigned 1047 by IANA: 1048 -PCE-ADDRESS sub-TLV (suggested value = 1) 1049 -PATH-SCOPE sub-TLV (suggested value = 2) 1050 -PCE-DOMAINS sub-TLV (suggested value = 3) 1051 -PCE-DEST-DOMAINS sub-TLV (suggested value =4) 1052 -GENERAL-CAP sub-TLV (suggested value = 5) 1053 -PATH-COMP-CAP sub-TLV (suggested value = 6) 1055 Three sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 1056 DOMAINS TLVs and should be assigned by IANA: 1057 -IPv4 area ID sub-TLV (suggested value = 1) 1058 -IPv6 area ID sub-TLV (suggested value = 2) 1059 -AS number sub-TLV (suggested value = 3) 1061 9.2. ISIS TLVs 1063 IANA will assign a new codepoint for the PCED TLV defined in this 1064 document and carried within the ISIS CAPABILITY TLV. 1066 Five sub-TLVs types are defined for the PCED TLV and should be 1067 assigned by IANA: 1068 -PCE-ADDRESS sub-TLV (suggested value = 1) 1069 -PATH-SCOPE sub-TLV (suggested value = 2) 1070 -PCE-DOMAINS sub-TLV (suggested value = 3) 1071 -GENERAL-CAP sub-TLV (suggested value = 4) 1072 -PATH-COMP-CAP sub-TLV (suggested value = 5) 1074 Two sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 1075 DOMAINS TLVs and should be assigned by IANA: 1076 -Area ID sub-TLV (suggested value = 1) 1077 -AS number sub-TLV (suggested value = 2) 1079 9.3. Capability bits 1081 IANA is requested to manage the space of general and path computation 1082 specific PCE capability bits flags, numbering them in the usual IETF 1083 notation starting at zero and continuing at least through 31. 1084 New bit numbers may be allocated only by an IETF Consensus action. 1085 Each bit should be tracked with the following qualities: 1086 - Bit number 1087 - Defining RFC 1088 - Name of bit 1090 Currently two bits are defined in the first general PCE capability 1091 flag. Here are the suggested values: 1092 -0: Support for Request prioritization. 1093 -1: Support for multiple messages within the same request message 1095 Currently six bits are defined in the first path computation specific 1096 PCE capability flag. Here are the suggested values: 1098 -0: Capability to compute P2P paths in MPLS-TE networks 1099 -1: Capability to compute P2P paths in GMPLS networks 1100 -2: Capability to compute link/node/SRLG diverse paths 1101 -3: Capability to compute load-balanced paths 1102 -4: Capability to compute a set of paths in a 1103 synchronized Manner 1104 -5: Support for multiple objective functions 1106 10. Security Considerations 1108 No new security issues are raised in this document. 1110 11. References 1112 11.1. Normative references 1114 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1116 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 1117 Routing Exchange Protocol " ISO 10589. 1119 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1120 dual environments", RFC 1195, December 1990. 1122 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 1123 Extensions to OSPF Version 2", RFC 3630, September 2003. 1125 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 1126 Engineering", RFC 3784, June 2004. 1128 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 1129 J.P., "Extensions to OSPF for advertising Optional Router 1130 Capabilities", draft-ietf-ospf-cap, work in progress. 1132 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 1133 router information", draft-ietf-isis-caps, work in progress. 1135 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 1136 Element (PCE) Architecture", draft-ietf-pce-architecture, work in 1137 progress. 1139 [PCE-DISCO-REQ] Le Roux, J.L., et al. "Requirements for PCE 1140 discovery", draft-ietf-pce-discovery-reqs, work in progress 1142 11.2. Informative references 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, March 1997. 1147 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1148 3667, February 2004. 1150 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 1151 Technology", BCP 79, RFC 3668, February 2004. 1153 [PCE-COM-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol 1154 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in 1155 progress. 1157 12. Authors' Addresses: 1159 Jean-Louis Le Roux 1160 France Telecom 1161 2, avenue Pierre-Marzin 1162 22307 Lannion Cedex 1163 FRANCE 1164 Email: jeanlouis.leroux@francetelecom.com 1166 Jean-Philippe Vasseur 1167 Cisco Systems, Inc. 1168 300 Beaver Brook Road 1169 Boxborough , MA - 01719 1170 USA 1171 Email: jpv@cisco.com 1173 Yuichi Ikejiri 1174 NTT Communications Corporation 1175 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1176 Tokyo 100-8019 1177 JAPAN 1178 Email: y.ikejiri@ntt.com 1180 13. Intellectual Property Statement 1182 The IETF takes no position regarding the validity or scope of any 1183 Intellectual Property Rights or other rights that might be claimed to 1184 pertain to the implementation or use of the technology described in 1185 this document or the extent to which any license under such rights 1186 might or might not be available; nor does it represent that it has 1187 made any independent effort to identify any such rights. Information 1188 on the procedures with respect to rights in RFC documents can be 1189 found in BCP 78 and BCP 79. 1191 Copies of IPR disclosures made to the IETF Secretariat and any 1192 assurances of licenses to be made available, or the result of an 1193 attempt made to obtain a general license or permission for the use of 1194 such proprietary rights by implementers or users of this 1195 specification can be obtained from the IETF on-line IPR repository at 1196 http://www.ietf.org/ipr. 1198 The IETF invites any interested party to bring to its attention any 1199 copyrights, patents or patent applications, or other proprietary 1200 rights that may cover technology that may be required to implement 1201 this standard. Please address the information to the IETF at 1202 ietf-ipr@ietf.org. 1204 Disclaimer of Validity 1206 This document and the information contained herein are provided on an 1207 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1208 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1209 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1210 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1211 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1212 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1214 Copyright Statement 1216 Copyright (C) The Internet Society (2005). This document is subject 1217 to the rights, licenses and restrictions contained in BCP 78, and 1218 except as set forth therein, the authors retain all their rights.