idnits 2.17.00 (12 Aug 2021) /tmp/idnits35861/draft-ietf-pce-disco-proto-isis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1020. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1033. 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 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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: 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 (December 2006) is 5635 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) == Unused Reference: 'RFC2119' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 948, 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 (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 ** Downref: Normative reference to an Informational RFC: RFC 4674 ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) == Outdated reference: draft-ietf-pce-pcep has been published as RFC 5440 Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 8 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: June 2007 J.P. Vasseur (Editor) 6 Cisco System Inc. 8 Yuichi Ikejiri 9 NTT Communications 11 Raymond Zhang 12 BT Infonet 14 December 2006 16 IS-IS protocol extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-isis-01.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 where 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 a Label Switch Router (LSR) participating to the IGP, 49 or even a server participating passively to the IGP, a simple and 50 efficient way for PCE discovery consists of relying on IGP flooding. 51 For that purpose this document defines IS-IS extensions for the 52 advertisement of PCE Discovery information within an IS-IS area or 53 within the entire IS-IS 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 (to be removed before publication).....................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. IS-IS 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......................................8 75 5.1.3. PCE-DOMAINS sub-TLV........................................10 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...................................11 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........................14 83 5.1.6.3. Switch Caps sub-TLV......................................14 84 5.2. The IS-IS PCES sub-TLV.....................................15 85 5.2.1. The CONGESTION sub-TLV.....................................15 86 6. Elements of Procedure......................................16 87 6.1.1. PCES TLV specific procedure................................17 88 7. Backward compatibility.....................................17 89 8. IANA considerations........................................18 90 8.1. IS-IS sub-TLVs.............................................18 91 8.2. Capability bits............................................19 92 9. Security Considerations....................................19 93 10. Manageability Considerations...............................20 94 11. Acknowledgments............................................20 95 12. References.................................................20 96 12.1. Normative references.......................................20 97 12.2. Informative references.....................................21 98 13. Editors' Addresses:........................................21 99 14. Contributors' Adresses:....................................21 100 15. Intellectual Property Statement............................21 102 1. Note (to be removed before publication) 104 This document specifies sub-TLVs to be carried within the IS-IS 105 Router Capability TLV ([IS-IS-CAP]). Because this document does not 106 introduce any new IS-IS element of procedure it will be discussed 107 within the PCE Working Group with a review of the IS-IS Working 108 Group. 110 2. Terminology 112 Terminology used in this document 114 ABR: IGP Area Border Router (L1L2 router). 116 AS: Autonomous System. 118 Domain: any collection of network elements within a common sphere 119 of address management or path computational responsibility. 120 Examples of domains include IGP areas and Autonomous Systems. 122 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 123 boundaries. 125 Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries. 127 Inter-area TE LSP: A TE LSP whose path transits through two or 128 more IGP areas. 130 Inter-AS TE LSP: A TE LSP whose path transits through two or more 131 ASes or sub-ASes (BGP confederations). 133 LSR: Label Switch Router. 135 PCC: Path Computation Client: any client application requesting a 136 path computation to be performed by a Path Computation Element. 138 PCE: Path Computation Element: an entity (component, application, 139 or network node) that is capable of computing a network path or 140 route based on a network graph, and applying computational 141 constraints. 143 PCEP: Path Computation Element communication Protocol. 145 TE LSP: Traffic Engineered Label Switched Path. 147 3. Introduction 149 [RFC4655] describes the motivations and architecture for a Path 150 Computation Element (PCE)-based path computation model for Multi 151 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic 152 Engineered Label Switched Paths (TE-LSPs). The model allows for the 153 separation of PCE from PCC (also referred to as non co-located PCE) 154 and allows for cooperation between PCEs. This relies on a 155 communication protocol between PCC and PCE, and between PCEs. The 156 requirements for such communication protocol can be found in [RFC4657] 157 and the communication protocol is defined in [PCEP]. 159 The PCE architecture requires, of course, that a PCC be aware of the 160 location of one or more PCEs in its domain, and also potentially of 161 some PCEs in other domains, e.g. in case of inter-domain TE LSP 162 computation. 164 A network may comprise a large number of PCEs with potentially 165 distinct capabilities. In such context it is highly desirable to have 166 a mechanism for automatic and dynamic PCE discovery, which allows 167 PCCs to automatically discover a set of PCEs, along with additional 168 information required for PCE selection, and to dynamically detect new 169 PCEs or any modification of PCE information. Detailed requirements 170 for such a PCE discovery mechanism are described in [RFC4674]. 172 Moreover, it may also be useful to discover when a PCE experiences 173 some processing congestion state and exits such state, in order for 174 the PCCs to take some appropriate actions (e.g. redirect to another 175 PCE). Note that the PCE selection algorithm is out of the scope of 176 this document. 178 When PCCs are LSRs participating to the IGP (OSPF, IS-IS), and PCEs 179 are LSRs or a servers also participating to the IGP, an efficient 180 mechanism for PCE discovery within an IGP routing domain consists of 181 relying on IGP advertisements. 183 This document defines IS-IS extensions allowing a PCE participating 184 to the IS-IS routing to advertise its location along with some 185 information useful for PCE selection, so as to satisfy dynamic PCE 186 discovery requirements set forth in [RFC4674]. This document also 187 defines extensions allowing a PCE participating to the IS-IS routing 188 to advertise its potential processing congestion state. 190 Generic capability mechanisms for IS-IS have been defined in [IS-IS- 191 CAP] the purpose of which is to allow a router to advertise its 192 capability within an IS-IS area or an entire IS-IS routing domain. 193 Such IS-IS extensions fully satisfy the aforementioned dynamic PCE 194 discovery requirements. 196 This document defines two new sub-TLVs (named the PCE Discovery 197 (PCED) TLV and the PCE Status (PCES) TLV) for IS-IS, to be carried 198 within the IS-IS Capability TLV ([IS-IS-CAP]). The PCE information 199 advertised is detailed in section 4. Protocol extensions and 200 procedures are defined in section 5 and 6. 202 This document does not define any new IS-IS element of procedure but 203 how the procedures defined in [IS-IS-CAP] should be used. 205 The routing extensions defined in this document allow for PCE 206 discovery within an IS-IS Routing domain. Solutions for PCE discovery 207 across AS boundaries are beyond the scope of this document, and for 208 further study. 210 This document defines a set of sub-TLVs that are nested within each 211 other. When the degree of nesting TLVs is 2 (a TLV is carried within 212 another TLV) the TLV carried within a TLV is called a sub-TLV. 213 Strictly speaking, when the degree of nesting is 3, a subsub-TLV is 214 carried within a sub-TLV that is itself carried within a TLV. For the 215 sake of terminology simplicity, we refer to sub-TLV, a TLV carried 216 within a TLV regardless of the degree of nesting. 218 4. Overview 220 4.1. PCE Information 222 The PCE information advertised via IS-IS falls into two categories: 223 PCE Discovery Information and PCE Status information. 225 4.1.1. PCE Discovery Information 227 The PCE Discovery information is comprised of: 229 - The PCE location: an IPv4 and/or IPv6 address that must be 230 used to reach the PCE. It is RECOMMENDED to use addresses always 231 reachable; 233 - The PCE inter-domain functions: PCE path computation scope (i.e. 234 inter-area, inter-AS, inter-layer…); 236 - The PCE domain(s): set of one or more domain(s) where the PCE has 237 visibility and can compute paths; 239 - The PCE Destination domain(s): set of one or more destination 240 domain(s) towards which a PCE can compute paths; 242 - A set of general PCEP capabilities (e.g. support for request 243 prioritization) and path computation specific capabilities 244 (e.g. supported constraints, supported objective functions). 246 Optional elements to describe more complex capabilities may also be 247 advertised. 249 PCE Discovery information is by nature fairly static and does not 250 change with PCE activity. Changes in PCE Discovery information may 251 occur as a result of PCE configuration updates, PCE 252 deployment/activation, PCE deactivation/suppression or PCE failure. 253 Hence, this information is not expected to change frequently. 255 4.1.2. PCE Status Information 257 The PCE Status is optional and can be used to report a PCE processing 258 congested state along with an estimated congestion duration. This is 259 dynamic information, which may change with PCE activity. 261 Procedures for a PCE to move from a processing congested state to a 262 non-congested state are beyond the scope of this document, but the 263 rate at which a PCE Status change is advertised MUST not impact by 264 any mean the IGP scalability. Particular attention should be given on 265 procedures to avoid state oscillations. 267 4.2. Flooding scope 269 The flooding scope for PCE Discovery Information can be limited to 270 one or more IS-IS areas the PCE belongs to or can be extended across 271 the entire IS-IS routing domain. 272 Note that some PCEs may belong to multiple areas, in which case the 273 flooding scope may comprise these areas. This could be the case of a 274 L1L2 router for instance advertising its PCE information within the 275 L2 level and/or a subset of its attached L1 area(s). 277 5. IS-IS extensions 279 5.1. IS-IS PCED TLV format 281 The IS-IS PCED TLV is made of various non ordered sub-TLVs. 283 The format of the IS-IS PCED TLV and its sub-TLVs is the same as the 284 TLV format used by the Traffic Engineering Extensions to IS-IS 285 [RFC3784]. That is, the TLV is composed of 1 octet for the type, 1 286 octet specifying the TLV length and a value field. 288 The IS-IS PCED TLV has the following format: 290 TYPE: To be assigned by IANA 291 LENGTH: Variable 292 VALUE: set of sub-TLVs 294 Sub-TLVs types are under IANA control. 296 Currently five sub-TLVs are defined (suggested type values to be 297 assigned by IANA): 298 Sub-TLV type Length Name 299 1 variable PCE-ADDRESS sub-TLV 300 2 3 PATH-SCOPE sub-TLV 301 3 variable PCE-DOMAINS sub-TLV 302 4 variable PCE-DEST-DOMAINS sub-TLV 303 5 variable GENERAL-CAP sub-TLV 304 6 variable PATH-COMP-CAP sub-TLV 306 The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within 307 the PCED TLV. 309 The PCE-DOMAINS and PCE-DEST-DOMAINS sub-TLVs are optional. They may 310 be present in the PCED TLV to facilitate selection of inter-domain 311 PCEs. 313 The GENERAL-CAP and PATH-COMP-CAP sub-TLVs are optional and MAY be 314 present in the PCED TLV to facilitate the PCE selection process. 316 Any non recognized sub-TLV MUST be silently ignored. 318 Additional sub-TLVs could be added in the future to advertise 319 additional PCE information. 321 The PCED TLV is carried within an IS-IS CAPABILITY TLV defined in 322 [IS-IS-CAP], whose S bit is determined by the desired flooding scope. 324 5.1.1. PCE-ADDRESS sub-TLV 326 The PCE-ADDRESS sub-TLV specifies the IP address that MUST be 327 used to reach the PCE. It is RECOMMENDED to make use of an address 328 that is always reachable, provided the PCE is alive. 330 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 331 PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and 332 IPv6 address. It MUST NOT appear more than once for the same address 333 type. 335 The PCE-ADDRESS sub-TLV has the following format: 337 TYPE: To be assigned by IANA (Suggested value =1) 338 LENGTH: 5 for IPv4 address and 17 for IPv6 address 339 VALUE: This comprises one octet indicating the address-type and 4 340 or 16 octets encoding the IPv4 or IPv6 address to be used 341 to reach the PCE 343 Address-type: 344 1 IPv4 345 2 IPv6 347 5.1.2. The PATH-SCOPE sub-TLV 349 The PATH-SCOPE sub-TLV indicates the PCE path computation scope which 350 refers to the PCE ability to compute or take part into the 351 computation of intra-area, inter-area, inter-AS or inter-layer_TE 352 LSP(s). 354 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 355 PCED TLV. There MUST be exactly one instance of the PATH-SCOPE sub- 356 TLV within each PCED TLV. 358 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 359 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 360 and four fields indicating PCE preferences. 362 The PATH-SCOPE sub-TLV has the following format: 364 TYPE: To be assigned by IANA (Suggested value =2) 365 LENGTH: 3 366 VALUE: This comprises a one-byte flag of bits where each bit 367 represents a supported path scope, followed by a 2-bytes 368 preferences field indicating PCE preferences. 370 Here is the structure of the bits flag: 372 +-+-+-+-+-+-+-+-+ 373 |0|1|2|3|4|5|Res| 374 +-+-+-+-+-+-+-+-+ 376 Bit Path Scope 378 0 L bit: Can compute intra-area path 379 1 R bit: Can act as PCE for inter-area TE LSPs computation 380 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 381 computation 382 3 S bit: Can act as PCE for inter-AS TE LSPs computation 383 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 384 computation 385 5 Y bit: Can compute or take part into the computation of 386 paths across layers 387 6-7 Reserved for future usage. 389 Here is the structure of the preferences field 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |PrefL|PrefR|PrefS|PrefY| Res | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Pref-L field: PCE's preference for intra-area TE LSPs computation. 397 Pref-R field: PCE’s preference for inter-area TE LSPs computation. 399 Pref-S field: PCE’s preference for inter-AS TE LSPs computation. 401 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 403 Res: Reserved for future usage. 405 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 406 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 407 respectively. These bits are non mutually exclusive. 409 When set the Rd bit indicates that the PCE can act as a default PCE 410 for inter-area TE LSPs computation (the PCE can compute path for any 411 destination area). Similarly, when set the Sd bit indicates that the 412 PCE can act as a default PCE for inter-AS TE LSPs computation (the 413 PCE can compute path for any destination AS). 415 When the Rd bit is set, the PCE-DEST-DOMAIN TLV (see 5.1.4) does not 416 contain any Area ID DOMAIN sub-TLV. 418 Similarly, when the Sd bit is set, the PCE-DEST-DOMAIN TLV does not 419 contain any AS-DOMAIN sub-TLV. 421 The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the 422 PCE to specify a preference for each computation scope, where 7 423 reflects the highest preference. Such preference can be used for 424 weighted load balancing of requests. An operator may decide to 425 configure a preference to each PCE so as to balance the path 426 computation load among them, with respect to their respective CPU 427 capacity. The algorithms used by a PCC to balance its path 428 computation requests according to such PCE’s preference are out of 429 the scope of this document. Same or distinct preferences may be used 430 for different scopes. For instance an operator that wants a PCE 431 capable of both inter-area and inter-AS computation to be used 432 preferably for inter-AS computation may configure a PrefS higher than 433 the PrefR. When the PrefL, PrefR, PRefS or PrefY is cleared, this 434 indicates an absence of preference. 436 When the L bit, R bit, S or Y bit are cleared the PrefL, PrefR, 437 PrefS, PrefY fields MUST respectively be set to 0. 439 5.1.3. PCE-DOMAINS sub-TLV 441 The PCE-DOMAINS sub-TLV specifies the set of domains (areas or AS) 442 where the PCE has topology visibility and can compute paths. It 443 contains a set of one or more sub-TLVs where each sub-TLV identifies 444 a domain. 446 The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be 447 inferred by other IGP information, for instance when the PCE is 448 inter-domain capable (i.e. when the R bit or S bit is set) and the 449 flooding scope is the entire routing domain. 451 The PCE-DOMAINS sub-TLV has the following format: 453 TYPE: To be assigned by IANA (Suggested value =2) 454 LENGTH: Variable 455 VALUE: This comprises a set of one or more DOMAIN sub-TLVs where 456 each DOMAIN sub-TLV identifies a domain where the PCE has 457 topology visibility and can compute paths 459 DOMAIN sub-TLVs types are under IANA control. 461 Currently two DOMAIN sub-TLVs are defined (suggested type values to 462 be assigned by IANA): 463 Sub-TLV type Length Name 464 1 variable Area ID sub-TLV 465 2 4 AS number sub-TLV 467 At least one DOMAIN sub-TLV MUST be present in the PCE-DOMAINS sub- 468 TLV. Note than when the PCE visibility is an entire AS, the PCE- 469 DOMAINS sub-TLV MUST uniquely include one AS number sub-TLV. 471 5.1.3.1. Area ID DOMAIN sub-TLV 473 This sub-TLV carries an IS-IS area ID. It has the following format 475 TYPE: To be assigned by IANA (Suggested value =1) 476 LENGTH: Variable 477 VALUE: This comprises a variable length IS-IS area ID. This is the 478 combination of an Initial Domain Part (IDP) and High Order 479 part of the Domain Specific part (HO-DSP) 481 5.1.3.2. AS Number DOMAIN sub-TLV 483 The AS Number sub-TLV carries an AS number. It has the following 484 format: 486 TYPE: To be assigned by IANA (Suggested value =2) 487 LENGTH: 4 488 VALUE: AS number identifying an AS. When coded on two 489 bytes (which is the current defined format as the 490 time of writing this document), the AS Number field 491 MUST have its left two bytes set to 0. 493 5.1.4. PCE-DEST-DOMAINS sub-TLV 495 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 496 (areas, AS) toward which a PCE can compute paths. It means that the 497 PCE can compute or take part in the computation of inter-domain TE 498 LSPs whose destinations are located within one of these domains. It 499 contains a set of one or more DOMAIN sub-TLVs where each DOMAIN sub- 500 TLV identifies a domain. 502 The PCE-DEST-DOMAINS sub-TLV has the following format: 504 TYPE: To be assigned by IANA (Suggested value =3) 505 LENGTH: Variable 506 VALUE: This comprises a set of one or more area or/and AS DOMAIN sub- 507 TLVs where each sub-TLV identifies a destination domain toward 508 which a PCE can compute path. 510 The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and 511 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 512 cleared. 514 The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub- 515 TLV. It MUST include at least one area ID sub-TLV, if the R bit of 516 the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is 517 cleared. Similarly, it MUST include at least one AS number sub-TLV if 518 the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH- 519 SCOPE TLV is cleared. 521 5.1.5. GENERAL-CAP sub-TLV 523 The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCEP 524 related capabilities. It carries a 32-bit flag, where each bit 525 corresponds to a general PCE capability. It MAY also include optional 526 sub-TLVs to encode more complex capabilities. 528 The GENERAL-CAP sub-TLV has the following format: 530 TYPE: To be assigned by IANA (Suggested value =4) 531 LENGTH: Variable 532 VALUE: This comprises a 32-bit General Capabilities flag where 533 each bit corresponds to a general PCE capability, and 534 optional sub-TLVs that may be defined to specify more 535 complex capabilities. Currently no sub-TLVs are defined. 537 The following bits in the General Capabilities 32-bit flag are to be 538 assigned by IANA: 540 0 1 2 3 541 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 |P|M| Reserved | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Bit Capabilities 549 0 P bit: Support for Request prioritization. 550 1 M bit: Support for multiple requests within the same 551 request message. 553 2-31 Reserved for future assignments by IANA. 555 5.1.6. The PATH-COMP-CAP sub-TLV 557 The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path 558 computation specific capabilities of a PCE. 559 It comprises a 32-bit flag, where each bit corresponds to a path 560 computation capability. It MAY also include optional sub-TLVs to 561 encode more complex capabilities. 563 The PATH-COMP-CAP sub-TLV has the following format: 565 TYPE: To be assigned by IANA (suggested value = 5) 566 LENGTH: Variable 567 VALUE: This comprises one 32 bit Path Computation Capabilities 568 Flag, where each bit corresponds to a path computation 569 capability, and optional sub-TLVs that may be defined to 570 specify more complex capabilities. Three optional sub-TLVs 571 are currently defined. 572 The following bits in the Path Computation Capabilities 32-bit Flag 573 are to be assigned by IANA: 575 0 1 2 3 576 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 |G|B|D|L|S|0|P| Reserved | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Bit Capabilities 584 0 G bit: Capability to handle GMPLS link contraints 585 1 B bit: Capability to compute bidirectional paths 586 2 D bit: Capability to compute link/node/SRLG diverse paths 587 3 L bit: Capability to compute load-balanced paths 588 4 S bit: Capability to compute a set of paths in a 589 synchronized Manner 590 5 O bit: Support for multiple objective functions 591 6 P bit: Capability to handle path constraints (e.g. max hop 592 count, metric bound) 594 7-31 Reserved for future assignments by IANA. 596 The G, B, D, L, S, O and P bits are not exclusive. 598 Three optional sub-TLVs are currently defined for the PATH-COMP-CAP 599 TLV: 600 - The Objective Functions sub-TLV (type to be defined, suggested 601 value =1) that carries a list of supported objective functions, 602 where each objective function is identified by a 16 bit integer. 603 - The Opaque Objective Function sub-TLV (type to be defined, 604 suggested value =2) that allows the user to encode a specific 605 objective function in any appropriate language. 606 - The Switch Caps sub-TLV (type to be defined, suggested value =3) 607 that carries a list of supported switching capabilities. This 608 means that the PCE can compute paths for the listed switching 609 capabilities. 611 5.1.6.1. Objective Functions sub-TLV 613 The format of the Objective Functions sub-TLV is as follows: 614 TYPE: To be defined by IANA (suggested value =1) 615 LENGTH: Variable (N*2) 616 VALUE: This comprises a set of one or more 16 bit function 617 ids, where each function id identifies a supported 618 objective functions. 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | function 1 | function 2 | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 // // 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | function N | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Objectives functions and their identification will be defined in a 629 separate document. 631 The Objective Functions sub-TLV is optional. It MAY be present within 632 the PATH-COMP-CAP TLV. When present it MUST be present only once in 633 the PATH-COMP-CAP TLV. 635 5.1.6.2. Opaque Objective Function sub-TLV 637 The format of the Opaque Objective Function sub-TLV is as follows: 639 TYPE: To be defined by IANA (suggested value =2) 640 LENGTH: Variable 641 VALUE: This encodes a specific objective function in any 642 appropriate language. 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Opaque objective function | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 The Opaque Objective function sub-TLV is optional. The PATH-COMP-CAP TLV 649 MAY comprise 0, one or more Opaque Objective Functions. 651 5.1.6.3. Switch Caps sub-TLV 653 The format of the Switch Caps sub-TLV is as follows: 655 TYPE To be defined by IANA (suggested value =3) 656 LENGTH Variable = N, where N is the number of supported 657 switching capabilities 658 VALUE This comprises a set of one or more 8-bit switching 659 types, where each switching types identifies a 660 supported switching capability. 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | SC type | SC type | SC type | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 // // 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Switching type values are defined in [RFC4205]. 670 The Switch Caps sub-TLV is optional. It MAY be present in the PATH-COMP- 671 CAP TLV. When present it MUST be present only once in the PATH-COMP-CAP 672 TLV. 674 5.2. The IS-IS PCES sub-TLV 676 The IS-IS PCE Status TLV (PCES sub-TLV) carries information related 677 to PCE processing congestion state. The PCES sub-TLV is carried 678 within an IS-IS Capability TLV which is defined in [IS-IS-CAP]. 680 The IS-IS PCES sub-TLV has the following format: 682 TYPE: To be assigned by IANA 683 LENGTH: Variable 684 VALUE: set of sub-TLVs 686 Sub-TLVs types are under IANA control. 688 Currently two sub-TLVs are defined (suggested type values to be 689 assigned by IANA): 690 Sub-TLV type Length Name 691 1 variable PCE-ADDRESS sub-TLV 692 2 3 CONGESTION sub-TLV 694 There MUST be exactly one occurrence of the PCE-ADDRESS and 695 CONGESTION sub-TLVs within a PCES sub-TLV. The PCE-ADDRESS sub-TLV is 696 defined in section 5.1.1. It carries one of the PCE IP addresses and 697 is used to identify the PCE experiencing a processing congestion 698 state. This is required as the PCES and PCED TLVs may be carried in 699 separate IS-IS Capability TLVs. 700 A PCE implementation MUST use the same IP address for the PCE- 701 ADDRESS sub-TLV carried within the PCED sub-TLV and the PCE-ADDRESS 702 sub-TLV carried within the PCES sub-TLV. 704 Any non recognized sub-TLV MUST be silently ignored. 706 Additional sub-TLVs could be added in the future to advertise 707 additional congestion information. 709 5.2.1. The CONGESTION sub-TLV 711 The CONGESTION sub-TLV is used to indicate whether a PCE experiences 712 a processing congestion state or not along with optionally the PCE 713 expected congestion duration. 714 The CONGESTION sub-TLV is mandatory. There MUST be a single instance 715 of the CONGESTION sub-TLV within the PCES TLV. 717 The format of the CONGESTION sub-TLV is as follows: 719 TYPE: To be assigned by IANA (Suggested value =2) 720 LENGTH: 3 721 VALUE: This comprises a one-byte flag of bits indicating the 722 congestion status, followed by a 2-bytes field indicating the 723 congestion duration. 725 Here is the TLV structure 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 |C| Reserved| Congestion Duration | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 Value 732 -C bit: When set this indicates that the PCE experiences 733 congestion and cannot accept any new request. When 734 cleared this indicates that the PCE does not 735 experience congestion and can accept new requests. 737 -Congestion Duration: 2-bytes, the estimated PCE congestion 738 duration in seconds. 740 When C is set and the Congestion Duration field is equal to 0, this 741 means that the Congestion Duration is unknown. 742 When C is cleared the Congestion Duration MUST be set to 0. 744 6. Elements of Procedure 746 The PCED and PCES TLV are carried within an IS-IS Capability TLV 747 defined in [IS-IS-CAP]. 749 As PCES information is likely to change more frequently than the PCED 750 information, it is RECOMMENDED to carry PCES and PCED TLVs in 751 separate IS-IS Capability TLVs, so as not to carry all PCED 752 information each time the PCE status changes. 754 An IS-IS router MUST originate a new IS-IS LSP whenever the content 755 of any of the PCED TLV or PCES TLV changes or whenever required by 756 the regular IS-IS procedure (LSP refresh). 758 When the scope of the PCED or PCES TLV is area local it MUST be 759 carried within an IS-IS CAPABILITY TLV having the S bit cleared. 760 When the scope of the PCED or PCES TLV is the entire IGP domain, the 761 PCED TLV MUST be carried within an IS-IS CAPABILITY TLV having the S 762 bit set. 763 When only the L bit of the PATH-SCOPE sub-TLV is set, the flooding 764 scope MUST be local. 765 Note that the flooding scopes of the PCED and PCES TLVs may be 766 distinct, in which case they are carried in distinct IS-IS Capability 767 TLVs. 769 The PCED and PCES sub-TLVs are OPTIONAL. When an IS-IS LSP does not 770 contain any PCED or PCES sub-TLV, this means that the PCE information 771 of that node is unknown. 773 A change in PCED or PCES information MUST not trigger any 774 SPF computation. 776 The way PCEs retrieve their own information is out of the scope of 777 this document. Some information may be configured (e.g. address, 778 preferences, scope) and other information may be automatically 779 retrieved (e.g. areas of visibility). 781 6.1.1. PCES TLV specific procedure 783 When a PCE enters into a processing congestion state, the conditions 784 of which are implementation dependent, it SHOULD originate a new IS- 785 IS LSP with a Capability TLV carrying a PCES TLV with the C bit set 786 and optionally a non-null expected congestion duration. 788 When a PCE exists from the processing congestion state, the 789 conditions of which are implementation dependent, two cases are 790 considered: 791 - If the congestion duration in the previously originated PCES 792 TLV was null, it SHOULD originate a PCES TLV with the C bit cleared 793 and a null congestion duration; 794 - If the congestion duration in the previously originated PCES 795 TLV was non null, it MAY originate a PCES TLV. Note that in some 796 particular cases it may be desired to originate a PCES TLV with the C 797 bit cleared if the congestion duration was over estimated. 799 The congestion duration allows reducing the amount of IS-IS flooding, 800 as only uncongested-to-congested state transitions are advertised. 802 An implementation SHOULD support an appropriate dampening algorithm 803 so as to dampen IS-IS flooding in order to not impact the IS-IS 804 scalability. It is RECOMMENDED to introduce some hysteresis for 805 congestion state transition, so as to avoid state oscillations that 806 may impact IS-IS performances. For instance two thresholds MAY be 807 configured: a resource congestion upper-threshold and a resource 808 congestion lower-threshold. An LSR enters the congested state when 809 the CPU load reaches the upper threshold and leaves the congested 810 state when the CPU load goes under the lower threshold. 812 Upon receipt of an updated PCES TLV a PCC should take appropriate 813 actions. In particular, the PCC SHOULD stop sending requests to a 814 congested PCE, and SHOULD gradually start sending again requests to a 815 no longer congested PCE. 817 7. Backward compatibility 819 The PCED and PCES TLVs defined in this document do not introduce any 820 interoperability issue. 821 An IS-IS router not supporting the PCED/PCES TLVs will just silently 822 ignore the TLV as specified in [IS-IS-CAP]. 824 8. IANA considerations 826 8.1. IS-IS sub-TLVs 828 IANA will assign two new codepoints for the PCED and PCES sub-TLVs 829 carried within the IS-IS CAPABILITY TLV defined in [IS-IS-CAP]. 831 Type Description Reference 833 1 PCED [IS-IS-CAP] 834 2 PCES [IS-IS-CAP] 836 8.1.1 Sub-TLVs of the PCED sub-TLV 838 IANA is requested to manage sub-TLV types for the PCED sub-TLV. 840 Five sub-TLVs types are defined for the PCED sub-TLV and should be 841 assigned by IANA: 843 Type Description Reference 845 1 PCE-ADDRESS This document 846 2 PATH-SCOPE This document 847 3 PCE-DOMAINS This document 848 4 PCE-DEST-DOMAINS This document 849 5 GENERAL-CAP This document 850 6 PATH-COMP-CAP This document 852 Sub-TLVs of the PCE-DOMAINS and and PCE-DEST-DOMAINS sub-TLVs 854 Two sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 855 DOMAINS sub-TLVs and should be assigned by IANA: 857 Type Description Reference 859 1 Area ID This document 860 2 AS Number This document 862 Sub-TLV of the PATH-COMP-CAP sub-TLV 864 Three sub-TLV types are defined for the PATH-COMP-CAP sub-TLV and 865 should be assigned by IANA: 867 Type Description Reference 869 1 Objective Functions This document 870 2 Opaque Objective Function This document 871 3 Switch Caps sub-TLV This document 873 8.1.2 Sub-TLVs of the PCES sub-TLV 875 IANA is requested to manage sub-TLV types for the PCES TLV. 877 Type Description Reference 879 1 PCE-ADDRESS This document 880 2 CONGESTION This document 882 8.2. Capability bits 884 IANA is requested to manage the space of the General Capabilities 885 32-bit flag and the Path Computation Capabilities 32-bit flag defined 886 in this document, numbering them in the usual IETF notation starting 887 at zero and continuing through 31. 888 New bit numbers may be allocated only by an IETF Consensus action. 889 Each bit should be tracked with the following qualities: 890 - Bit number 891 - Defining RFC 892 - Name of bit 894 Currently two bits are defined in the General Capabilities flag. Here 895 are the suggested values: 896 -0: Support for Request prioritization. 897 -1: Support for multiple messages within the same request message 899 Currently seven bits are defined in the Path Computation Capabilities 900 flag. Here are the suggested values: 902 -0: Capability to handle GMPLS Constraints 903 -1: Capability to compute bidirectional paths 904 -2: Capability to compute link/node/SRLG diverse paths 905 -3: Capability to compute load-balanced paths 906 -4: Capability to compute a set of paths in a 907 synchronized Manner 908 -5: Support for multiple objective function 909 -6: Capability to handle path constraints (e.g. hop count, metric 910 bound) 912 9. Security Considerations 914 Any new security issues raised by the procedures in this document 915 depend upon the opportunity for LSPs to be snooped, the 916 ease/difficulty of which has not been altered. As the LSPs may now 917 contain additional information regarding PCE capabilities, this 918 new information would also become available. Mechanisms defined to 919 secure ISIS Link State PDUs [RFC3567], and their TLVs, can be used to 920 secure PCED and PCES TLVs as well. 922 10. Manageability Considerations 924 Manageability considerations for PCE Discovery are addressed in 925 section 4.10 of [RFC4674]. 927 11. Acknowledgments 929 We would like to thank Lucy Wong and Adrian Farrel for their useful 930 comments and suggestions. 932 12. References 934 12.1. Normative references 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, March 1997. 939 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 940 3667, February 2004. 942 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 943 Technology", RFC 3979, March 2005. 945 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 946 Routing Exchange Protocol " ISO 10589. 948 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 949 dual environments", RFC 1195, December 1990. 951 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 952 Engineering", RFC 3784, June 2004. 954 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 955 router information", draft-ietf-isis-caps, work in progress. 957 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 958 Element (PCE)-based Architecture", RFC4655, august 2006. 960 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 961 RFC4674, October 2006. 963 [RFC4205] Kompella, Rekhter, " IS-IS Extensions in Support of 964 Generalized Multi-Protocol Label Switching (GMPLS)", RFC4205, October 965 2005. 967 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 968 Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, 969 July 2003. 971 12.2. Informative references 973 [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol 974 Generic Requirements", RFC4657, September 2006. 976 [PCEP] Vasseur et al., "Path Computation Element (PCE) communication 977 Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work in progress. 979 13. Editors' Addresses: 981 Jean-Louis Le Roux (Editor) 982 France Telecom 983 2, avenue Pierre-Marzin 984 22307 Lannion Cedex 985 FRANCE 986 Email: jeanlouis.leroux@orange-ftgroup.com 988 Jean-Philippe Vasseur (Editor) 989 Cisco Systems, Inc. 990 1414 Massachusetts avenue 991 Boxborough , MA - 01719 992 USA 993 Email: jpv@cisco.com 995 14. Contributors' Adresses: 997 Yuichi Ikejiri 998 NTT Communications Corporation 999 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1000 Tokyo 100-8019 1001 JAPAN 1002 Email: y.ikejiri@ntt.com 1004 Raymond Zhang 1005 BT Infonet 1006 2160 E. Grand Ave. 1007 El Segundo, CA 90025 1008 USA 1009 Email: raymond_zhang@infonet.com 1011 15. Intellectual Property Statement 1013 The IETF takes no position regarding the validity or scope of any 1014 Intellectual Property Rights or other rights that might be claimed to 1015 pertain to the implementation or use of the technology described in 1016 this document or the extent to which any license under such rights 1017 might or might not be available; nor does it represent that it has 1018 made any independent effort to identify any such rights. Information 1019 on the procedures with respect to rights in RFC documents can be 1020 found in BCP 78 and BCP 79. 1022 Copies of IPR disclosures made to the IETF Secretariat and any 1023 assurances of licenses to be made available, or the result of an 1024 attempt made to obtain a general license or permission for the use of 1025 such proprietary rights by implementers or users of this 1026 specification can be obtained from the IETF on-line IPR repository at 1027 http://www.ietf.org/ipr. 1029 The IETF invites any interested party to bring to its attention any 1030 copyrights, patents or patent applications, or other proprietary 1031 rights that may cover technology that may be required to implement 1032 this standard. Please address the information to the IETF at 1033 ietf-ipr@ietf.org. 1035 Disclaimer of Validity 1037 This document and the information contained herein are provided 1038 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1039 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1040 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1041 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1042 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1043 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1044 FOR A PARTICULAR PURPOSE. 1046 Copyright Statement 1048 Copyright (C) The IETF Trust (2006). This document is subject to the 1049 rights, licenses and restrictions contained in BCP 78, and except as 1050 set forth therein, the authors retain all their rights.