idnits 2.17.00 (12 Aug 2021) /tmp/idnits37693/draft-ietf-pce-disco-proto-isis-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 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 965. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 972. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 978. ** 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 6 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: Procedures for a PCE to move from a processing congested state to a non congested state are beyond the scope of this document, but the rate at which a PCE Status change is advertised MUST not impact by any mean the IGP scalability. Particular attention should be given on procedures to avoid state oscillations. == 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: The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and IPv6 address. It MUST not appear more than twice. == 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 or PCES information MUST not trigger any 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 (September 2006) is 5726 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 808, but not defined == Missing Reference: 'PCE-DISC-REQ' is mentioned on line 183, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 277, but not defined == Unused Reference: 'RFC2119' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'IS-IS-TE' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'IS-IS-CAP' is defined on line 901, but no explicit reference was found in the text == Unused Reference: 'PCE-DISCO-REQ' is defined on line 907, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) -- 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-isis-caps has been published as RFC 4971 ** Downref: Normative reference to an Informational RFC: RFC 4655 == 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 normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: draft-ietf-pce-comm-protocol-gen-reqs has been published as RFC 4657 == Outdated reference: draft-ietf-pce-pcep has been published as RFC 5440 -- No information found for draft-ietf-pce-disco-proto-ospf - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 20 warnings (==), 9 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 5 Expires: March 2007 J.P. Vasseur (Editor) 6 Cisco System Inc. 8 Yuichi Ikejiri 9 NTT Communications 11 Raymond Zhang 12 BT Infonet 14 September 2006 16 IS-IS protocol extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-isis-00.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet- Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 There are various circumstances in which it is highly desirable for a 45 Path Computation Client (PCC) to be able to dynamically and 46 automatically discover a set of Path Computation Element(s) (PCE), 47 along with some of information that can be used for PCE selection. 48 When the PCE is an LSR participating to the IGP, or even a server 49 participating passively to the IGP, a simple and efficient way for 50 PCE discovery consists of relying on IGP flooding. For that purpose 51 this document defines ISIS extensions for the advertisement of PCE 52 Discovery information within an ISIS area or within the entire ISIS 53 routing domain. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119. 61 Table of Contents 63 1. Note........................................................3 64 2. Terminology.................................................3 65 3. Introduction................................................4 66 4. Overview....................................................5 67 4.1. PCE Information.............................................5 68 4.1.1. PCE Discovery Information...................................5 69 4.1.2. PCE Status Information......................................6 70 4.2. Flooding scope..............................................6 71 5. ISIS extensions.............................................6 72 5.1. IS-IS PCED TLV format.......................................6 73 5.1.1. PCE-ADDRESS sub-TLV.........................................7 74 5.1.2. The PATH-SCOPE sub-TLV......................................7 75 5.1.3. PCE-DOMAINS sub-TLV.........................................9 76 5.1.3.1. Area ID DOMAIN sub-TLV...................................10 77 5.1.3.2. AS Number DOMAIN sub-TLV.................................10 78 5.1.4. PCE-DEST-DOMAINS sub-TLV...................................10 79 5.1.5. GENERAL-CAP sub-TLV........................................11 80 5.1.6. The PATH-COMP-CAP sub-TLV..................................12 81 5.1.6.1. Objective Functions sub-TLV..............................13 82 5.1.6.2. Opaque Objective Function sub-TLV........................13 83 5.1.6.3. Switch Caps sub-TLV......................................14 84 5.2. The ISIS PCES TLV..........................................14 85 5.2.1. The CONGESTION sub-TLV.....................................15 86 6. Elements of Procedure......................................16 87 6.1.1. PCES TLV specific procedure................................16 88 7. Backward compatibility.....................................17 89 8. IANA considerations........................................17 90 8.1. ISIS TLVs..................................................17 91 8.2. Capability bits............................................18 92 9. Security Considerations....................................19 93 10. References.................................................19 94 10.1. Normative references.......................................19 95 10.2. Informative references.....................................19 96 11. Authors' Addresses:........................................20 97 12. Intellectual Property Statement............................20 99 1. Note 101 This document specifies sub-TLVs to be carried within the ISIS Router 102 Capability TLV ([ISIS-CAP]). Because this document does not introduce 103 any new ISIS element of procedure it will be discussed within the PCE 104 Working Group with a review of the ISIS Working Group. 106 2. Terminology 108 Terminology used in this document 110 ABR: IGP Area Border Router (L1L2 router). 112 AS: Autonomous System. 114 ASBR: AS Border Router. 116 Domain: any collection of network elements within a common sphere 117 of address management or path computational responsibility. 118 Examples of domains include IGP areas and Autonomous Systems. 120 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 121 boundaries. 123 Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries. 125 Inter-area TE LSP: A TE LSP whose path transits through 126 two or more IGP areas. 128 Inter-AS MPLS TE LSP: A TE LSP whose path transits 129 through two or more ASes or sub-ASes (BGP confederations). 131 LSR: Label Switch Router. 133 PCC: Path Computation Client: any client application requesting a 134 path computation to be performed by a Path Computation Element. 136 PCE: Path Computation Element: an entity (component, application, 137 or network node) that is capable of computing a network path or 138 route based on a network graph, and applying computational 139 constraints. 141 PCECP: Path Computation Element Communication Protocol. 143 TE LSP: Traffic Engineered Label Switched Path. 145 3. Introduction 147 [RFC4655] describes the motivations and architecture for a PCE-based 148 path computation model for MPLS and GMPLS TE LSPs. The model allows 149 the separation of PCE from PCC (also referred to as non co-located 150 PCE) and allows cooperation between PCEs. This relies on a 151 communication protocol between PCC and PCE, and between PCEs. The 152 requirements for such communication protocol can be found in [PCECP- 153 REQ] and the communication protocol is defined in [PCEP]. 155 The PCE architecture requires, of course, that a PCC be aware of the 156 location of one or more PCEs in its domain, and also potentially of 157 some PCEs in other domains, e.g. in case of inter-domain TE LSP 158 computation. 160 A network may comprise a large number of PCEs with potentially 161 distinct capabilities. In such context it would be highly desirable 162 to have a mechanism for automatic and dynamic PCE discovery, which 163 would allow PCCs to automatically discover a set of PCEs, along with 164 additional information required for PCE selection, and to dynamically 165 detect new PCEs or any modification of PCE information. 166 Detailed requirements for such a PCE discovery mechanism are 167 described in [PCE-DISC-REQ]. 169 Moreover, it may also be useful to discover when a PCE experiences 170 some processing congestion state and exits such state, in order for 171 the PCCs to take some appropriate actions (e.g. redirect to another 172 PCE). Note that the PCE selection algorithm is out of the scope of 173 this document. 175 When PCCs are LSRs participating to the IGP (OSPF, ISIS), and PCEs 176 are LSRs or a servers also participating to the IGP, an efficient 177 mechanism for PCE discovery within thisan IGP routing domain consists 178 of relying on IGP advertisements. 180 This document defines ISIS extensions allowing a PCE participating to 181 the ISIS routing to advertise its location along with some 182 information useful for PCE selection, so as to satisfy dynamic PCE 183 discovery requirements set forth in [PCE-DISC-REQ]. This document 184 also defines extensions allowing a PCE participating to the ISIS 185 routing to advertise its potential processing congestion state. 187 Generic capability mechanisms for ISIS have been defined in [ISIS- 188 CAP] the purpose of which is to allow a router to advertise its 189 capability within an ISIS area or an entire ISIS routing domain. Such 190 ISIS extensions fully satisfy the aforementioned dynamic PCE 191 discovery requirements. 193 This document defines two new sub-TLVs (named the PCE Discovery 194 (PCED) TLV and the PCE Status (PCES) TLV) for ISIS, to be carried 195 within the ISIS Capability TLV ([ISIS-CAP]). The PCE information 196 advertised is detailed in section 4. Protocol extensions and 197 procedures are defined in section 5 and 6. 199 This document does not define any new ISIS element of procedure but 200 how the procedures defined in [ISIS-CAP] should be used. 202 The routing extensions defined in this document allow for PCE 203 discovery within an ISIS Routing domain. Solutions for PCE discovery 204 across AS boundaries are beyond the scope of this document, and for 205 further study. 207 Similar extensions to OSPF for PCE discovery can be found in [OSPF- 208 PCE-DISCO]. 210 4. Overview 212 4.1. PCE Information 214 PCE information advertised within ISIS includes PCE Discovery 215 Information and PCE Status information. 217 4.1.1. PCE Discovery Information 219 The PCE Discovery information is comprised of: 221 - The PCE location: This an IPv4 and/or IPv6 address that must be 222 used to reach the PCE. It is RECOMMENDED to use addresses always 223 reachable; 225 - The PCE inter-domain functions: this refers to the PCE path 226 computation scope (i.e. inter-area, inter-AS, inter-layer…); 228 - The PCE domain(s): This is the set of one or more domain(s) where 229 the PCE has visibility and can compute paths; 231 - The PCE Destination domain(s): This is the set of one or more 232 destination domain(s) towards which a PCE can compute paths; 234 - A set of general PCECP capabilities (e.g. support for request 235 prioritization) and path computation specific capabilities 236 (e.g. supported constraints, supported objective functions). 238 It may also contain optional elements to describe more complex 239 capabilities. 241 PCE Discovery information is by nature a static information that does 242 not change with PCE activity. Changes in PCE Discovery information 243 may occur as a result of PCE configuration updates, PCE 244 deployment/activation, PCE deactivation/suppression or PCE failure. 245 Hence, this information is not expected to change frequently. 247 4.1.2. PCE Status Information 249 The PCE Status is optional information that can be used to report a 250 PCE processing congested state along with an estimated congestion 251 duration. This is a dynamic information, which may change with PCE 252 activity. 254 Procedures for a PCE to move from a processing congested state to a 255 non congested state are beyond the scope of this document, but the 256 rate at which a PCE Status change is advertised MUST not impact by 257 any mean the IGP scalability. Particular attention should be given on 258 procedures to avoid state oscillations. 260 4.2. Flooding scope 262 The flooding scope for PCE Discovery Information can be limited to 263 one or more ISIS areas the PCE belongs to or can be extended across 264 the entire ISIS routing domain. 265 Note that some PCEs may belong to multiple areas, in which case the 266 flooding scope may comprise these areas. This could be the case of an 267 ABR for instance advertising its PCE information within the backbone 268 area and/or a subset of its attached IGP area(s). 270 5. ISIS extensions 272 5.1. IS-IS PCED TLV format 274 The IS-IS PCED TLV is made of various non ordered sub-TLVs. 276 The format of the IS-IS PCED TLV and its sub-TLVs is the same as the 277 TLV format used by the Traffic Engineering Extensions to IS-IS [ISIS- 278 TE]. That is, the TLV is composed of 1 octet for the type, 1 octet 279 specifying the TLV length and a value field. 281 The IS-IS PCED TLV has the following format: 283 TYPE: To be assigned by IANA 284 LENGTH: Variable 285 VALUE: set of sub-TLVs 287 Sub-TLVs types are under IANA control. 289 Currently five sub-TLVs are defined (suggested type values to be 290 assigned by IANA): 291 Sub-TLV type Length Name 292 1 variable PCE-ADDRESS sub-TLV 293 2 3 PATH-SCOPE sub-TLV 294 3 variable PCE-DOMAINS sub-TLV 295 4 variable PCE-DEST-DOMAINS sub-TLV 296 5 variable GENERAL-CAP sub-TLV 297 6 variable PATH-COMP-CAP sub-TLV 299 The sub-TLVs PCE-ADDRESS and PATH-SCOPE MUST always be present within 300 the PCED TLV. 302 The sub-TLVs PCE-DOMAINS and PCE-DEST-DOMAINS are optional. They MAY 303 be present in some specific inter-domain cases. 305 The sub-TLVs GENERAL-CAP and PATH-COMP-CAP are optional and MAY be 306 present in the PCED TLV to facilitate the PCE selection process. 308 Any non recognized sub-TLV MUST be silently ignored. 310 Additional sub-TLVs could be added in the future to advertise 311 additional PCE information. 313 The PCED TLV is carried within an ISIS CAPABILITY TLV defined in 314 [ISIS-CAP], whose S bit is determined by the desired flooding scope. 316 5.1.1. PCE-ADDRESS sub-TLV 318 The PCE-ADDRESS sub-TLV specifies the IP address that MUST be 319 used to reach the PCE. It is RECOMMENDED to make use of an address 320 that is always reachable, provided the PCE is alive. 322 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 323 PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and 324 IPv6 address. It MUST not appear more than twice. 326 The PCE-ADDRESS sub-TLV has the following format: 328 TYPE: To be assigned by IANA (Suggested value =1) 329 LENGTH: 5 for IPv4 address and 17 for IPv6 address 330 VALUE: This comprises one octet indicating the address-type and 4 331 or 16 octets encoding the IPv4 or IPv6 address to be used 332 to reach the PCE 334 Address-type: 335 1 IPv4 336 2 IPv6 338 5.1.2. The PATH-SCOPE sub-TLV 340 The PATH-SCOPE sub-TLV indicates the PCE path computation scope which 341 refers to the PCE ability to compute or take part into the 342 computation of intra-area, inter-area, inter-AS or inter-layer_TE 343 LSP(s). 345 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 346 PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each 347 PCED TLV. 349 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 350 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 351 and four fields indicating PCE preferences. 353 The PATH-SCOPE sub-TLV has the following format: 355 TYPE: To be assigned by IANA (Suggested value =2) 356 LENGTH: 3 357 VALUE: This comprises a one-byte flag of bits where each bit 358 represents a supported path scope, followed by a 2-bytes 359 preferences field indicating PCE preferences. 361 Here is the structure of the bits flag: 363 +-+-+-+-+-+-+-+-+ 364 |0|1|2|3|4|5|Res| 365 +-+-+-+-+-+-+-+-+ 367 Bit Path Scope 369 0 L bit: Can compute intra-area path 370 1 R bit: Can act as PCE for inter-area TE LSPs 371 computation 372 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 373 computation 374 3 S bit: Can act as PCE for inter-AS TE LSPs computation 375 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 376 computation 377 5 Y bit: Can compute or take part into the computation of 378 paths across layers 379 6-7 Reserved for future usage. 381 Here is the structure of the preferences field 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |PrefL|PrefR|PrefS|PrefY| Res | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Pref-L field: PCE's preference for intra-area TE LSPs computation. 389 Pref-R field: PCE’s preference for inter-area TE LSPs computation. 391 Pref-S field: PCE’s preference for inter-AS TE LSPs computation. 393 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 395 Res: Reserved for future usage. 397 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 398 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 399 respectively. These bits are non mutually exclusive. 401 When set the Rd bit indicates that the PCE can act as a default PCE 402 for inter-area TE LSPs computation (the PCE can compute path for any 403 destination area). Similarly, when set the Sd bit indicates that the 404 PCE can act as a default PCE for inter-AS TE LSPs computation (the 405 PCE can compute path for any destination AS). 407 When the Rd bit is set, the PCE-DEST-DOMAIN TLV (see 5.1.4) does not 408 contain any Area ID DOMAIN sub-TLV. 410 Similarly, when the Sd bit is set, the PCE-DEST-DOMAIN TLV does not 411 contain any AS DOMAIN sub-TLV. 413 The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the 414 PCE to specify a preference for each computation scope, where 7 415 reflects the highest preference. Such preference can be used for 416 weighted load balancing of requests. An operator may decide to 417 configure a preference to each PCE so as to balance the path 418 computation load among them, with respect to their respective CPU 419 capacity. The algorithms used by a PCC to balance its path 420 computation requests according to such PCE’s preference are out of 421 the scope of this document. Same or distinct preferences may be used 422 for different scopes. For instance an operator that wants a PCE 423 capable of both inter-area and inter-AS computation to be used 424 preferably for inter-AS computation may configure a PrefS higher than 425 the PrefR. 427 When the L bit, R bit, S or Y bit are cleared the PrefL, PrefR, 428 PrefS, PrefY fields MUST respectively be set to 0. 430 5.1.3. PCE-DOMAINS sub-TLV 432 The PCE-DOMAINS sub-TLV specifies the set of domains (areas or AS) 433 where the PCE has topology visibility and can compute paths. It 434 contains a set of one or more sub-TLVs where each sub-TLV identifies 435 a domain. 437 The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be 438 inferred by other IGP information, for instance when the PCE is 439 inter-domain capable (i.e. when the R bit or S bit is set) and the 440 flooding scope is the entire routing domain. 442 The PCE-DOMAINS sub-TLV has the following format: 444 TYPE: To be assigned by IANA (Suggested value =2) 445 LENGTH: Variable 446 VALUE: This comprises a set of one or more DOMAIN sub-TLVs where 447 each DOMAIN sub-TLV identifies a domain where the PCE has 448 topology visibility and can compute paths 450 DOMAIN Sub-TLVs types are under IANA control. 452 Currently two DOMAIN sub-TLVs are defined (suggested type values to 453 be assigned by IANA): 454 Sub-TLV type Length Name 455 1 variable Area ID sub-TLV 456 2 variable AS number sub-TLV 458 At least one DOMAIN sub-TLV MUST be present in the PCE-DOMAINS sub- 459 TLV. 461 5.1.3.1. Area ID DOMAIN sub-TLV 463 This sub-TLV carries an ISIS area ID. It has the following format 465 TYPE: To be assigned by IANA (Suggested value =1) 466 LENGTH: Variable 467 VALUE: This comprises a variable length ISIS area ID. This is the 468 combination of an Initial Domain Part (IDP) and High Order 469 part of the Domain Specific part (HO-DSP) 471 5.1.3.2. AS Number DOMAIN sub-TLV 473 The AS Number sub-TLV carries an AS number. It has the following 474 format: 476 TYPE: To be assigned by IANA (Suggested value =2) 477 LENGTH: 4 478 VALUE: AS number identifying an AS. When coded on two 479 bytes (which is the current defined format as the 480 time of writing this document), the AS Number field 481 MUST have its left two bytes set to 0. 483 5.1.4. PCE-DEST-DOMAINS sub-TLV 485 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 486 (areas, AS) toward which a PCE can compute path. It means that the 487 PCE can compute or take part in the computation of inter-domain LSPs 488 whose destinations are located within one of these domains. It 489 contains a set of one or more DOMAIN sub-TLVs where each DOMAIN sub- 490 TLV identifies a domain. 492 The PCE-DEST-DOMAINS sub-TLV has the following format: 494 TYPE: To be assigned by IANA (Suggested value =3) 495 LENGTH: Variable 496 VALUE: This comprises a set of one or more Area or/and AS DOMAIN sub- 497 TLVs where each sub-TLV identifies a destination domain toward 498 which a PCE can compute path. 500 The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and 501 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 502 cleared. 504 The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub- 505 TLV. It MUST include at least one area ID sub-TLV, if the R bit of 506 the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is 507 cleared. Similarly, it MUST include at least one AS number sub-TLV if 508 the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH- 509 SCOPE TLV is cleared. 511 5.1.5. GENERAL-CAP sub-TLV 513 The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP 514 related capabilities. It carries a 32-bit flag, where each bit 515 corresponds to a general PCE capability. It MAY also include optional 516 sub-TLVs to encode more complex capabilities. 518 The GENERAL-CAP sub-TLV has the following format: 520 TYPE: To be assigned by IANA (Suggested value =4) 521 LENGTH: Variable 522 VALUE: This comprises a 32-bit General Capabilities flag where 523 each bit corresponds to a general PCE capability, and 524 optional sub-TLVs that may be defined to specify more 525 complex capabilities. Currently no sub-TLVs are defined. 527 The following bits in the General Capabilities 32-bit flag are to be 528 assigned by IANA: 530 0 1 2 3 531 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 |P|M| Reserved | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Bit Capabilities 538 0 P bit: Support for Request prioritization. 539 1 M bit: Support for multiple requests within the same 540 request message. 542 2-31 Reserved for future assignments by IANA. 544 5.1.6. The PATH-COMP-CAP sub-TLV 546 The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path 547 computation specific capabilities of a PCE. 548 It comprises a 32-bit flag, where each bit corresponds to a path 549 computation capability. It MAY also include optional sub-TLVs to 550 encode more complex capabilities. 552 The PATH-COMP-CAP sub-TLV has the following format: 554 TYPE: To be assigned by IANA (suggested value = 5) 555 LENGTH: Variable 556 VALUE: This comprises one 32 bit Path Computation Capabilities 557 Flag, where each bit corresponds to a path computation 558 capability, and optional sub-TLVs that may be defined to 559 specify more complex capabilities. Three optional sub-TLVs 560 are currently defined. 561 The following bits in the Path Computation Capabilities 32-bit Flag 562 are to be assigned by IANA: 564 0 1 2 3 565 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |G|B|D|L|S|0|P| Reserved | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Bit Capabilities 573 0 G bit: Capability to handle GMPLS link contraints 574 1 B bit: Capability to compute bidirectional paths 575 2 D bit: Capability to compute link/node/SRLG diverse paths 576 3 L bit: Capability to compute load-balanced paths 577 4 S bit: Capability to compute a set of paths in a 578 synchronized Manner 579 5 O bit: Support for multiple objective functions 580 6 P bit: Capability to handle path constraints (e.g. max hop 581 count, metric bound) 583 7-31 Reserved for future assignments by IANA. 585 The G, B, D, L, S, O and P bits are not exclusive. 587 Three optional sub-TLVs are currently defined for the PATH-COMP-CAP 588 TLV: 589 - The Objective Functions sub-TLV (type to be defined, suggested 590 value =1) that carries a list of supported objective functions, 591 where each objective function is identified by a 16 bit integer. 592 - The Opaque Objective Function sub-TLV (type to be defined, 593 suggested value =2) that allows the user to encode a specific 594 objective function in any appropriate language. 595 - The Switch Caps sub-TLV (type to be defined, suggested value =3) 596 that carries a list of supported switching capabilities. This 597 means that the PCE can compute paths for the listed switching 598 capabilities. 600 5.1.6.1. Objective Functions sub-TLV 602 The format of the Objective Functions sub-TLV is as follows: 603 TYPE: To be defined by IANA (suggested value =1) 604 LENGTH: Variable (N*2) 605 VALUE: This comprises a set of one or more 16 bit function 606 ids, where each function id identifies a supported 607 objective functions. 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | function 1 | function 2 | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 // // 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | function N | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Objectives functions and their identification will be defined in a 618 separate document. 620 The Objective Functions sub-TLV is optional. It MAY be present within 621 the PATH-COMP-CAP TLV. When present it MUST be present only once in 622 the PATH-COMP-CAP TLV. 624 5.1.6.2. Opaque Objective Function sub-TLV 626 The format of the Opaque Objective Function sub-TLV is as follows: 628 TYPE: To be defined by IANA (suggested value =2) 629 LENGTH: Variable 630 VALUE: This encodes a specific objective function in any 631 appropriate language. 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Opaque objective function | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 The Opaque Objective function sub-TLV is optional. The PATH-COMP-CAP TLV 638 MAY comprise 0, one or more Opaque Objective Functions. 640 5.1.6.3. Switch Caps sub-TLV 642 The format of the Switch Caps sub-TLV is as follows: 644 TYPE To be defined by IANA (suggested value =3) 645 LENGTH Variable = N, where N is the number of supported 646 switching capabilities 647 VALUE This comprises a set of one or more 8-bit switching 648 types, where each switching types identifies a 649 supported switching capability. 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | SC type | SC type | SC type | | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 // // 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Switching type values are defined in [RFC4205]. 659 The Switch Caps sub-TLV is optional. It MAY be present in the PATH-COMP- 660 CAP TLV. When present it MUST be present only once in the PATH-COMP-CAP 661 TLV. 663 5.2. The ISIS PCES TLV 665 The ISIS PCE Status TLV (PCES TLV) carries information related to PCE 666 processing congestion state. 667 The PCES TLV is carried within an ISIS Capability TLV which is 668 defined in [ISIS-CAP]. 670 The ISIS PCES TLV has the following format: 672 TYPE: To be assigned by IANA 673 LENGTH: Variable 674 VALUE: set of sub-TLVs 676 Sub-TLVs types are under IANA control. 678 Currently two sub-TLVs are defined (suggested type values to be 679 assigned by IANA): 680 Sub-TLV type Length Name 681 1 variable PCE-ADDRESS sub-TLV 682 2 3 CONGESTION sub-TLV 684 The PCE-ADDRESS and CONGESTION sub-TLVs MUST be present once 685 in a PCES TLV. The PCE-ADDRESS sub-TLV is defined in section 6.1.1. 686 It carries one of the PCE IP addresses and is used to identify the 687 PCE the processing congestion state information is applied to. This 688 is required as the PCES and PCED TLVs may be carried in separate 689 ISIS Capability TLVs. 691 Any non recognized sub-TLV MUST be silently ignored. 693 Additional sub-TLVs could be added in the future to advertise 694 additional congestion information. 696 5.2.1. The CONGESTION sub-TLV 698 The CONGESTION sub-TLV is used to indicate whether a PCE experiences 699 a processing congestion state or not along with optionally the PCE 700 expected congestion duration. 701 The CONGESTION sub-TLV is mandatory. It MUST be carried once within 702 the PCES TLV. 704 The format of the CONGESTION sub-TLV is as follows: 706 TYPE: To be assigned by IANA (Suggested value =2) 707 LENGTH: 3 708 VALUE: This comprises a one-byte flag of bits indicating the 709 congestion status, followed by a 2-bytes field indicating the 710 congestion duration. 712 Here is the TLV structure 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 |C| Reserved| Congestion Duration | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 Value 719 -C bit: When set this indicates that the PCE experiences 720 congestion and cannot support any new request. When 721 cleared this indicates that the PCE does not 722 experience congestion an can support a new request. 724 -Congestion Duration: 2-bytes, the estimated PCE congestion 725 duration in seconds. 727 When C is set and the Congestion Duration field is equal to 0, this 728 means that the Congestion Duration is unknown. 729 When C is cleared the Congestion Duration MUST be set to 0. 731 6. Elements of Procedure 733 The PCED and PCES TLV are carried within an ISIS Capability TLV which 734 is defined in [ISIS-CAP]. 736 As PCES information is likely to change more frequently than the PCED 737 information, it is RECOMMENDED to carry PCES and PCED TLVs in 738 separate ISIS Capability TLVs, so as not to carry all PCED 739 information each time the PCE status changes. 741 An ISIS router MUST originate a new ISIS LSP whenever the content 742 of any of the PCED TLV or PCES TLV changes or whenever required by 743 the regular ISIS procedure (LSP refresh). 745 When the scope of the PCED or PCES TLV is area local it MUST be 746 carried within an ISIS CAPABILITY TLV having the S bit cleared. 747 When the scope of the PCED or PCES TLV is the entire IGP domain, the 748 PCED TLV MUST be carried within an ISIS CAPABILITY TLV having the S 749 bit set. 750 Note that when only the L bit of the PATH-SCOPE sub-TLV is set, 751 the flooding scope MUST be local. 752 Note that the flooding scopes of the PCED and PCES TLVs may be 753 distinct, in which case they are carried in distinct ISIS Capability 754 TLVs. 756 PCED and PCES sub-TLVs are OPTIONAL. When an ISIS LSP does not 757 contain any PCED or PCES sub-TLV, this means that the PCE information 758 of that node is unknown. 760 Note that a change in PCED or PCES information MUST not trigger any 761 SPF computation. 763 The way PCEs retrieve their own information is out of the scope of 764 this document. Some information may be configured (e.g. address, 765 preferences, scope) and other information may be automatically 766 retrieved (e.g. areas of visibility). 768 6.1.1. PCES TLV specific procedure 770 When a PCE enters into a processing congestion state, the conditions 771 of which are implementation dependent, it SHOULD originate a new ISIS 772 LSP with a Capability TLV carrying a PCES TLV with the C bit set and 773 optionally a non-null expected congestion duration. 775 When a PCE leaves the processing congestion state, the conditions of 776 which are implementation dependent, there are two cases: 777 - If the congestion duration in the previously originated PCES 778 TLV was null, it SHOULD originate a PCES TLV with the C bit cleared 779 and a null congestion duration; 780 - If the congestion duration in the previously originated PCES 781 TLV was non null, it MAY originate a PCES TLV. Note that in some 782 particular cases it may be desired to originate a PCES TLV with the C 783 bit cleared if the saturation duration was over estimated. 785 The congestion duration allows reducing the amount of ISIS flooding, 786 as only uncongested-congested state transitions are flooded. 788 An implementation SHOULD support an appropriate dampening algorithm 789 so as to dampen ISIS flooding in order to not impact the ISIS 790 scalability. It is RECOMMENDED to introduce some hysteresis for 791 congestion state transition, so as to avoid state oscillations that 792 may impact ISIS performances. For instance two thresholds MAY be 793 configured: A resource saturation upper-threshold and a resource 794 saturation lower-threshold. An LSR enters the congested state when 795 the CPU load reaches the upper threshold and leaves the congested 796 state when the CPU load goes under the lower threshold. 798 Upon receipt of an updated PCES TLV a PCC should take appropriate 799 actions. In particular, the PCC SHOULD stop sending requests to a 800 congested PCE, and SHOULD gradually start sending again requests to a 801 no longer congested PCE. 803 7. Backward compatibility 805 The PCED and PCES TLVs defined in this document do not introduce any 806 interoperability issue. 807 An ISIS router not supporting the PCED/PCES TLVs SHOULD just silently 808 ignore the TLV as specified in [ISIS-CAP]. 810 8. IANA considerations 812 8.1. ISIS TLVs 814 IANA will assign a new codepoint for the PCED TLV defined in this 815 document and carried within the ISIS CAPABILITY TLV. 816 IANA is requested to manage sub-TLV types for the PCED TLV. 817 Five sub-TLVs types are defined for the PCED TLV and should be 818 assigned by IANA: 819 -PCE-ADDRESS sub-TLV (suggested value = 1) 820 -PATH-SCOPE sub-TLV (suggested value = 2) 821 -PCE-DOMAINS sub-TLV (suggested value = 3) 822 -PCE-DEST-DOMAINS sub-TLV (suggested value = 4) 823 -GENERAL-CAP sub-TLV (suggested value = 5) 824 -PATH-COMP-CAP sub-TLV (suggested value = 6) 826 Two sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 827 DOMAINS TLVs and should be assigned by IANA: 829 -Area ID sub-TLV (suggested value = 1) 830 -AS number sub-TLV (suggested value = 2) 832 Three sub-TLV types are defined for the PATH-COMP-CAP TLV and should 833 be assigned by IANA: 834 -Objective Functions sub-TLV (suggested value =1) 835 -Opaque Objective Function sub-TLV (suggested value =2) 836 -Switch Caps sub-TLV (suggested value =3) 838 IANA will assign a new codepoint for the ISIS PCES TLV defined in 839 this document and carried within the ISIS CAPABILITY TLV. 840 IANA is requested to manage sub-TLV types for the PCES TLV. Two sub- 841 TLVs types are defined for this TLV and should be assigned by IANA: 842 -PCE-ADDRESS sub-TLV (suggested value = 1) 843 -CONGESTION sub-TLV (suggested value = 2) 845 8.2. Capability bits 847 IANA is requested to manage the space of the General Capabilities 848 32-bit flag and the Path Computation Capabilities 32-bit flag defined 849 in this document, numbering them in the usual IETF notation starting 850 at zero and continuing through 31. 851 New bit numbers may be allocated only by an IETF Consensus action. 852 Each bit should be tracked with the following qualities: 853 - Bit number 854 - Defining RFC 855 - Name of bit 857 Currently two bits are defined in the General Capabilities flag. Here 858 are the suggested values: 859 -0: Support for Request prioritization. 860 -1: Support for multiple messages within the same request message 862 Currently six bits are defined in the Path Computation Capabilities 863 flag. Here are the suggested values: 865 -0: Capability to handle GMPLS Constraints 866 -1: Capability to compute bidirectional paths 867 -2: Capability to compute link/node/SRLG diverse paths 868 -3: Capability to compute load-balanced paths 869 -4: Capability to compute a set of paths in a 870 synchronized Manner 871 -5: Support for multiple objective function 872 -6: Capability to handle path constraints (e.g. hop count, metric 873 bound) 875 9. Security Considerations 877 This document raises no new security issues for IS-IS. 879 10. References 881 10.1. Normative references 883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 884 Requirement Levels", BCP 14, RFC 2119, March 1997. 886 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 887 3667, February 2004. 889 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 890 Technology", RFC 3979, March 2005. 892 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 893 Routing Exchange Protocol " ISO 10589. 895 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 896 dual environments", RFC 1195, December 1990. 898 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 899 Engineering", RFC 3784, June 2004. 901 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 902 router information", draft-ietf-isis-caps, work in progress. 904 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 905 Element (PCE)-based Architecture", RFC4655, august 2006. 907 [PCE-DISCO-REQ] Le Roux, J.L., et al. "Requirements for PCE 908 discovery", draft-ietf-pce-discovery-reqs, work in progress 910 [RFC4205] Kompella, Rekhter, " IS-IS Extensions in Support of 911 Generalized Multi-Protocol Label Switching (GMPLS)", RFC4205, October 912 2005. 914 10.2. Informative references 916 [PCECP-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol 917 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in 918 progress. 920 [PCEP] Vasseur et al., “Path Computation Element (PCE) communication 921 Protocol (PCEP) - Version 1”, draft-ietf-pce-pcep, work in progress. 923 [OSPF-PCE-DISCO] Le Roux, Vasseur, et al., "OSPF Extensions for PCE 924 Discovery", draft-ietf-pce-disco-proto-ospf, work in progress. 926 11. Authors' Addresses: 928 Jean-Louis Le Roux (Editor) 929 France Telecom 930 2, avenue Pierre-Marzin 931 22307 Lannion Cedex 932 FRANCE 933 Email: jeanlouis.leroux@orange-ft.com 935 Jean-Philippe Vasseur (Editor) 936 Cisco Systems, Inc. 937 1414 Massachusetts avenue 938 Boxborough , MA - 01719 939 USA 940 Email: jpv@cisco.com 942 Yuichi Ikejiri 943 NTT Communications Corporation 944 1-1-6, Uchisaiwai-cho, Chiyoda-ku 945 Tokyo 100-8019 946 JAPAN 947 Email: y.ikejiri@ntt.com 949 Raymond Zhang 950 BT Infonet 951 2160 E. Grand Ave. 952 El Segundo, CA 90025 953 USA 954 Email: raymond_zhang@infonet.com 956 12. Intellectual Property Statement 958 The IETF takes no position regarding the validity or scope of any 959 Intellectual Property Rights or other rights that might be claimed to 960 pertain to the implementation or use of the technology described in 961 this document or the extent to which any license under such rights 962 might or might not be available; nor does it represent that it has 963 made any independent effort to identify any such rights. Information 964 on the procedures with respect to rights in RFC documents can be 965 found in BCP 78 and BCP 79. 967 Copies of IPR disclosures made to the IETF Secretariat and any 968 assurances of licenses to be made available, or the result of an 969 attempt made to obtain a general license or permission for the use of 970 such proprietary rights by implementers or users of this 971 specification can be obtained from the IETF on-line IPR repository at 972 http://www.ietf.org/ipr. 974 The IETF invites any interested party to bring to its attention any 975 copyrights, patents or patent applications, or other proprietary 976 rights that may cover technology that may be required to implement 977 this standard. Please address the information to the IETF at 978 ietf-ipr@ietf.org. 980 Disclaimer of Validity 982 This document and the information contained herein are provided on an 983 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 984 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 985 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 986 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 987 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 988 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 990 Copyright Statement 992 Copyright (C) The Internet Society (2006). This document is subject 993 to the rights, licenses and restrictions contained in BCP 78, and 994 except as set forth therein, the authors retain all their rights.