idnits 2.17.1 draft-ietf-pce-disco-proto-igp-02.txt: -(473): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1109): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1622): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1665): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1666): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1719. ** 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 11 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 specifies the IP address(es) that MUST be used to reach the PCE. It is RECOMMENDED to make use of an address that is always reachable, provided that the PCE is alive. 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: The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP related capabilities. It MAY be present within the PCED TLV. It MUST not be present more than once. The value field of the GENERAL-CAP sub-TLV is made of a 32-bit flag, where each bit corresponds to a general PCE capability. It MAY also include optional sub-TLVs to encode more complex capabilities. == 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 PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path computation specific capabilities. It MAY be present within the PCED TLV. It MUST not be present more than once. It is made of a 32-bit flag, where each bit correspond to a path computation capability. It MAY also include optional sub-TLVs to encode more complex capabilities. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that a change in PCED information MUST not trigger any SPF computation. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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: The P in the PCED sub-LTV originated by a PCE. It MAY appear multiple times, for instance when the PCE has both an IPv4 and IPv6 address. It MUST not appear more than two times. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that a change in PCED information MUST not trigger 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 (June 2006) is 6524 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 1500, but not defined == Missing Reference: 'PCE-DISC-REQ' is mentioned on line 208, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 961, but not defined == Unused Reference: 'RFC2119' is defined on line 1608, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1611, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 1614, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 1617, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 1625, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 1628, but no explicit reference was found in the text == Unused Reference: 'IS-IS-TE' is defined on line 1634, but no explicit reference was found in the text == Unused Reference: 'IS-IS-CAP' is defined on line 1641, but no explicit reference was found in the text == Unused Reference: 'PCE-DISCO-REQ' is defined on line 1648, 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) ** Obsolete normative reference: RFC 2740 (ref. 'OSPF-v3') (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) ** Downref: Normative reference to an Informational draft: draft-ietf-pce-architecture (ref. 'PCE-ARCH') ** 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) Summary: 12 errors (**), 0 flaws (~~), 22 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: December 2006 J.P. Vasseur (Editor) 6 Cisco System Inc. 8 Yuichi Ikejiri 9 NTT Communications 11 Raymond Zhang 12 BT Infonet 14 June 2006 16 IGP protocol extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-igp-02.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 OSPF and ISIS extensions for the advertisement 52 of PCE Discovery information within an IGP area or within the entire 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. OSPF extensions.............................................7 72 5.1. The OSPF PCED TLV...........................................7 73 5.1.1. PCE-ADDRESS sub-TLV.........................................8 74 5.1.2. PATH-SCOPE sub-TLV..........................................9 75 5.1.3. PCE-DOMAINS sub-TLV........................................10 76 5.1.3.1. IPv4 area ID DOMAIN sub-TLV..............................11 77 5.1.3.2. IPv6 area ID DOMAIN sub-TLV..............................12 78 5.1.3.3. AS Number sub-TLV........................................12 79 5.1.4. PCE-DEST-DOMAINS sub-TLV...................................12 80 5.1.5. GENERAL-CAP sub-TLV........................................13 81 5.1.6. The PATH-COMP-CAP sub-TLV..................................14 82 5.1.6.1. Objective Functions sub-TLV..............................15 83 5.1.6.2. Opaque Objective Function sub-TLV........................16 84 5.1.6.3. Switch Caps sub-TLV......................................16 85 5.2. The OSPF PCES TLV..........................................17 86 5.2.1. The CONGESTION sub-TLV.....................................18 87 5.3. Elements of Procedure......................................19 88 5.3.1. PCES TLV specific procedures...............................19 89 6. ISIS extensions............................................21 90 6.1. IS-IS PCED TLV format......................................21 91 6.1.1. PCE-ADDRESS sub-TLV........................................22 92 6.1.2. The PATH-SCOPE sub-TLV.....................................22 93 6.1.3. PCE-DOMAINS sub-TLV........................................24 94 6.1.3.1. Area ID DOMAIN sub-TLV...................................25 95 6.1.3.2. AS Number DOMAIN sub-TLV.................................25 96 6.1.4. PCE-DEST-DOMAINS sub-TLV...................................25 97 6.1.5. GENERAL-CAP sub-TLV........................................26 98 6.1.6. The PATH-COMP-CAP sub-TLV..................................26 99 6.1.6.1. Objective Functions sub-TLV..............................28 100 6.1.6.2. Opaque Objective Function sub-TLV........................28 101 6.1.6.3. Switch Caps sub-TLV......................................29 102 6.2. The ISIS PCES TLV..........................................29 103 6.2.1. The CONGESTION sub-TLV.....................................30 104 6.3. Elements of Procedure......................................30 105 6.3.1. PCES TLV specific procedure................................31 106 7. Backward compatibility.....................................32 107 8. IANA considerations........................................32 108 8.1. OSPF TLVs..................................................32 109 8.2. ISIS TLVs..................................................33 110 8.3. Capability bits............................................33 111 9. Security Considerations....................................34 112 10. References.................................................34 113 10.1. Normative references.......................................34 114 10.2. Informative references.....................................35 115 11. Authors' Addresses:........................................35 116 12. Intellectual Property Statement............................36 118 1. Note 120 This document specifies new TLVs and sub-TLVs to be carried within 121 the OSPF Router information LSA ([OSPF-CAP]) and ISIS Router 122 Capability TLV ([ISIS-CAP]) respectively. Because this document does 123 not introduce any new element of procedure it will be discussed 124 within the PCE Working Group with a review of the OSPF and ISIS 125 Working Groups. Furthermore, once stabilized, it may be decided to 126 split the document in two documents addressing the OSPF and ISIS 127 aspects respectively. 129 2. Terminology 131 Terminology used in this document 133 ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router). 135 AS: Autonomous System. 137 ASBR: AS Border Router. 139 Domain: any collection of network elements within a common sphere 140 of address management or path computational responsibility. 141 Examples of domains include IGP areas and Autonomous Systems. 143 IGP Area: OSPF Area or ISIS level. 145 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 146 boundaries. 148 Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries. 150 Inter-area TE LSP: A TE LSP whose path transits through 151 two or more IGP areas. 153 Inter-AS MPLS TE LSP: A TE LSP whose path transits 154 through two or more ASes or sub-ASes (BGP confederations). 156 LSR: Label Switch Router. 158 PCC: Path Computation Client: any client application requesting a 159 path computation to be performed by a Path Computation Element. 161 PCE: Path Computation Element: an entity (component, application, 162 or network node) that is capable of computing a network path or 163 route based on a network graph, and applying computational 164 constraints. 166 PCECP: Path Computation Element Communication Protocol. 168 TE LSP: Traffic Engineered Label Switched Path. 170 3. Introduction 172 [PCE-ARCH] describes the motivations and architecture for a PCE-based 173 path computation model for MPLS and GMPLS TE LSPs. The model allows 174 the separation of PCE from PCC (also referred to as non co-located 175 PCE) and allows cooperation between PCEs. This relies on a 176 communication protocol between PCC and PCE, and between PCEs. The 177 requirements for such communication protocol can be found in [PCECP- 178 REQ] and the communication protocol is defined in [PCEP]. 180 The PCE architecture requires, of course, that a PCC be aware of the 181 location of one or more PCEs in its domain, and also potentially of 182 some PCEs in other domains, e.g. in case of inter-domain TE LSP 183 computation. 185 A network may comprise a large number of PCEs with potentially 186 distinct capabilities. In such context it would be highly desirable 187 to have a mechanism for automatic and dynamic PCE discovery, which 188 would allow PCCs to automatically discover a set of PCEs, along with 189 additional information required for PCE selection, and to dynamically 190 detect new PCEs or any modification of PCE information. 191 Detailed requirements for such a PCE discovery mechanism are 192 described in [PCE-DISC-REQ]. 194 Moreover, it may also be useful to discover when a PCE experiences 195 some processing congestion state and exits such state, in order for 196 the PCCs to take some appropriate actions (e.g. redirect to another 197 PCE). Note that the PCE selection algorithm is out of the scope of 198 this document. 200 When PCCs are LSRs participating to the IGP (OSPF, ISIS), and PCEs 201 are LSRs or a servers also participating to the IGP, an efficient 202 mechanism for PCE discovery within an IGP routing domain consists of 203 relying on IGP advertisements. 205 This document defines OSPF and ISIS extensions allowing a PCE 206 participating in the IGP to advertise its location along with some 207 information useful for PCE selection so as to satisfy dynamic PCE 208 discovery requirements set forth in [PCE-DISC-REQ]. This document 209 also defines extensions allowing a PCE participating to the IGP to 210 advertise its potential processing congestion state. 212 Generic capability mechanisms have been defined in [OSPF-CAP] and 213 [ISIS-CAP] for OSPF and ISIS respectively the purpose of which is to 214 allow a router to advertise its capability within an IGP area or an 215 entire routing domain. Such IGP extensions fully satisfy the 216 aforementioned dynamic PCE discovery requirements. 218 This document defines two new TLVs (named the PCE Discovery (PCED) 219 TLV and the PCE Status (PCES) TLV) for ISIS and OSPF, to be carried 220 within the ISIS Capability TLV ([ISIS-CAP]) and the OSPF Router 221 Information LSA ([OSPF-CAP]). 223 The PCE information advertised is detailed in section 4. Protocol 224 extensions and procedures are defined in section 5 for OSPF and 6 for 225 ISIS. 227 This document does not define any new OSPF or ISIS element of 228 procedure but how the procedures defined in [OSPF-CAP] and [ISIS-CAP] 229 should be used. 231 The routing extensions defined in this document allow for PCE 232 discovery within an IGP Routing domain. Solutions for PCE discovery 233 across AS boundaries are beyond the scope of this document, and for 234 further study. 236 4. Overview 238 4.1. PCE Information 240 PCE information advertised within the IGP includes PCE Discovery 241 Information and PCE Status information. 243 4.1.1. PCE Discovery Information 245 The PCE Discovery information is comprised of: 247 - The PCE location: This an IPv4 and/or IPv6 address that must be 248 used to reach the PCE. It is RECOMMENDED to use addresses always 249 reachable; 251 - The PCE inter-domain functions: this refers to the PCE path 252 computation scope (i.e. inter-area, inter-AS, inter-layer�); 254 - The PCE domain(s): This is the set of one or more domain(s) where 255 the PCE has visibility and can compute paths; 257 - The PCE Destination domain(s): This is the set of one or more 258 destination domain(s) towards which a PCE can compute paths; 260 - A set of general PCECP capabilities (e.g. support for request 261 prioritization) and path computation specific capabilities 262 (e.g. supported constraints, supported objective functions�). 264 It may also contain optional elements to describe more complex 265 capabilities. 267 PCE Discovery information is by nature a static information that does 268 not change with PCE activity. Changes in PCE Discovery information 269 may occur as a result of PCE configuration updates, PCE 270 deployment/activation, PCE deactivation/suppression or PCE failure. 271 Hence, this information is not expected to change frequently. 273 4.1.2. PCE Status Information 275 The PCE Status is optional information that can be used to report a 276 PCE processing congested state along with an estimated congestion 277 duration. This is a dynamic information, which may change with PCE 278 activity. 280 Procedures for a PCE to move from a processing congested state to a 281 non congested state are beyond the scope of this document, but the 282 rate at which a PCE Status change is advertised MUST not impact by 283 any mean the IGP scalability. Particular attention should be given on 284 procedures to avoid state oscillations. 286 4.2. Flooding scope 288 The flooding scope for PCE Discovery Information can be limited to 289 one or more IGP areas the PCE belongs to or can be extended across 290 the entire routing domain. 291 Note that some PCEs may belong to multiple areas, in which case the 292 flooding scope may comprise these areas. This could be the case of an 293 ABR for instance advertising its PCE information within the backbone 294 area and/or a subset of its attached IGP area(s). 296 5. OSPF extensions 298 5.1. The OSPF PCED TLV 300 The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered 301 sub-TLVs. 303 The format of the OSPF PCED TLV and its sub-TLVs is the identical as 304 the TLV format used by the Traffic Engineering Extensions to OSPF 305 [OSPF-TE]. That is, the TLV is composed of 2 octets for the type, 2 306 octets specifying the TLV length and a value field. The Length field 307 defines the length of the value portion in octets. 308 The TLV is padded to four-octet alignment; padding is not included in 309 the length field (so a three octet value would have a length of 310 three, but the total size of the TLV would be eight octets). Nested 311 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 312 types between 32768 and 65535 are reserved for vendor-specific 313 extensions. All other undefined type codes are reserved for future 314 assignment by IANA. 316 The OSPF PCED TLV has the following format: 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 // sub-TLVs // 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Type To be defined by IANA (suggested value=2) 328 Length Variable 329 Value This comprises one or more sub-TLVs 331 Sub-TLVs types are under IANA control. 333 Currently five sub-TLVs are defined (type values to be assigned by 334 IANA): 335 Sub-TLV type Length Name 336 1 variable PCE-ADDRESS sub-TLV 337 2 4 PATH-SCOPE sub-TLV 338 3 variable PCE-DOMAINS sub-TLV 339 4 variable PCE-DEST-DOMAINS sub-TLV 340 5 variable GENERAL-CAP sub-TLV 341 6 variable PATH-COMP-CAP sub-TLV 343 The sub-TLVs PCE-ADDRESS and PATH SCOPE MUST always be present within 344 the PCED TLV. 346 The sub-TLVs PCE-DOMAINS and PCE-DEST-DOMAINS are optional. They MAY 347 be present in some specific inter-domain cases. 349 The GENERAL-CAP and PATH-COMP-CAP sub-TLVs are optional and MAY be 350 present in the PCED TLV to facilitate the PCE selection process. 352 Any non recognized sub-TLV MUST be silently ignored. 354 Additional sub-TLVs could be added in the future to advertise 355 additional information. 357 The PCED TLV is carried within an OSPF Router Information LSA 358 defined in [OSPF-CAP]. 360 5.1.1. PCE-ADDRESS sub-TLV 362 The PCE-ADDRESS sub-TLV specifies the IP address(es) that MUST be 363 used to reach the PCE. It is RECOMMENDED to make use of an address 364 that is always reachable, provided that the PCE is alive. 365 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 366 PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and IPv6 367 address. It MUST not appear more than twice. 369 The format of the PCE-ADDRESS sub-TLV is as follows: 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | address-type | Reserved | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 // PCE IP Address // 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 PCE-ADDRESS sub-TLV format 384 Type To be assigned by IANA (suggested value =1) 385 Length 4 (IPv4) or 16 (IPv6) 387 Address-type: 388 1 IPv4 389 2 IPv6 391 PCE IP Address: The IP address to be used to reach the PCE. 392 This is the address that will be used for 393 setting up PCC-PCE communication sessions. 395 5.1.2. PATH-SCOPE sub-TLV 397 The PATH-SCOPE sub-TLV indicates the PCE path computation scope(s), 398 which refers to the PCE ability to compute or take part into the 399 computation of intra-area, inter-area, inter-AS or inter-layer_TE 400 LSP(s). 402 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 403 PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each 404 PCED TLV. 406 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 407 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 408 and four fields indicating PCE preferences. 410 The PATH-SCOPE sub-TLV has the following format: 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Type To be defined by IANA (suggested value =3) 420 Length Variable 421 Value This comprises a 2 bytes flag where each bit 422 represents a supported path scope, as well as four 423 preference fields allowing to specify PCE preferences. 425 The following bits are defined: 427 Bit Path Scope 429 0 L bit: Can compute intra-area path 430 1 R bit: Can act as PCE for inter-area TE LSPs 431 computation 432 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 433 computation 434 3 S bit: Can act as PCE for inter-AS TE LSPs computation 435 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 436 computation 437 5 Y bit: Can compute or take part into the computation of 438 paths across layers. 440 Pref-L field: PCE's preference for intra-area TE LSPs computation. 442 Pref-R field: PCE�s preference for inter-area TE LSPs computation. 444 Pref-S field: PCE�s preference for inter-AS TE LSPs computation. 446 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 448 Res: Reserved for future usage. 450 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 451 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 452 respectively. These bits are non exclusive. 454 When set the Rd bit indicates that the PCE can act as a default PCE 455 for inter-area TE LSPs computation (the PCE can compute path for any 456 destination area). Similarly, when set the Sd bit indicates that the 457 PCE can act as a default PCE for inter-AS TE LSPs computation (the 458 PCE can compute path for any destination AS). 460 When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not 461 contain any Area ID DOMAIN sub-TLV. 463 Similarly, when the Sd bit is set the PCE-DEST-DOMAIN TLV does not 464 contain any AS DOMAIN sub-TLV. 466 The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the 467 PCE to specify a preference for each computation scope, where 7 468 reflects the highest preference. Such preference can be used for 469 weighted load balancing of requests. An operator may decide to 470 configure a preference to each PCE so as to balance the path 471 computation load among them, with respect to their respective CPU 472 capacity. The algorithms used by a PCC to load balance its path 473 computation requests according to such PCE�s preference is out of the 474 scope of this document. Same or distinct preferences may be used for 475 different scopes. For instance an operator that wants a PCE capable 476 of both inter-area and inter-AS computation to be used preferably for 477 inter-AS computation may configure a PrefS higher than the PrefR. 479 When the L bit, R bit, S or Y bit are cleared, the PrefL, PrefR, 480 PrefS, PrefY fields MUST respectively be set to 0. 482 5.1.3. PCE-DOMAINS sub-TLV 484 The PCE-DOMAINS sub-TLV specifies the set of domains (areas, AS) 485 where the PCE has topology visibility and can compute paths. It 486 contains a set of one or more sub-TLVs where each sub-TLV identifies 487 a domain. 489 The PCED TLV MUST include zero or one PCE-DOMAINS sub-TLV. 490 The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be 491 inferred by other IGP information, for instance when the PCE is 492 inter-area capable (i.e. when the R bit is set) and the flooding 493 scope is the entire IGP routing domain. 495 The PCE-DOMAINS sub-TLV has the following format: 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | 502 // DOMAIN sub-TLVs // 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Type To be defined by IANA (suggested value =3) 507 Length Variable 508 Value This comprises a set of one or more DOMAIN sub-TLVs 509 where each DOMAIN sub-TLV identifies a domain where 510 the PCE has topology visibility and can compute paths. 512 Sub-TLVs types are under IANA control. 514 Currently three DOMAIN sub-TLVs are defined (suggested type values to 515 be assigned by IANA): 516 Sub-TLV type Length Name 517 1 variable IPv4 area ID sub-TLV 518 2 variable IPv6 area ID sub-TLV 519 3 variable AS number sub-TLV 521 The PCE-DOMAINS sub-TLV MUST include at least one DOMAIN sub-TLV. 522 Note than when the PCE visibility is an entire AS, the PCE-DOMAINS 523 sub-TLV MUST uniquely include one AS number sub-TLV. 525 5.1.3.1. IPv4 area ID DOMAIN sub-TLV 527 The IPv4 area ID DOMAIN sub-TLV carries an IPv4 OSPF area identifier. 528 It has the following format: 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Type | Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | IPv4 Area ID | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Type To be assigned by IANA (suggested value =1) 538 Length 4 539 IPv4 OSPF area ID: The IPv4 identifier of the OSPF area 541 5.1.3.2. IPv6 area ID DOMAIN sub-TLV 543 The IPv6 area ID sub-TLV carries an IPv6 OSPF area identifier. It has 544 the following format: 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | IPv6 Area ID | 551 | | 552 | | 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Type To be assigned by IANA (suggested value =2) 557 Length 16 558 IPv6 OSPF area ID: The IPv6 identifier of the OSPF area 560 5.1.3.3. AS Number sub-TLV 562 The AS Number sub-TLV carries an AS number. It has the following 563 format: 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type | Length | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | AS Number | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Type To be assigned by IANA (suggested value =3) 573 Length 4 574 AS Number: AS number identifying an AS. When coded on two 575 bytes (which is the current defined format as the 576 time of writing this document), the AS Number field 577 MUST have its left two bytes set to 0. 579 5.1.4. PCE-DEST-DOMAINS sub-TLV 581 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 582 (areas, AS) toward which a PCE can compute path. It means that the 583 PCE can compute or take part in the computation of inter-domain LSPs 584 whose destinations are located within one of these domains. It 585 contains a set of one or more sub-TLVs where each sub-TLV identifies 586 a domain. 588 The PCE-DEST-DOMAINS sub-TLV has the following format: 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Length | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | 595 // DOMAIN sub-TLVs // 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Type To be defined by IANA (suggested value =3) 600 Length Variable 601 Value This comprises a set of one or more Area and/or AS 602 DOMAIN sub-TLVs where each DOMAIN sub-TLV identifies a 603 domain toward which a PCE can compute paths. 605 The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and 606 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 607 cleared. 609 The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub- 610 TLV. It MUST include at least one area ID sub-TLV, if the R bit of 611 the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is 612 cleared. Similarly, it MUST include at least one AS number sub-TLV if 613 the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH- 614 SCOPE TLV is cleared. 616 5.1.5. GENERAL-CAP sub-TLV 618 The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP 619 related capabilities. It MAY be present within the PCED TLV. It MUST 620 not be present more than once. 621 The value field of the GENERAL-CAP sub-TLV is made of a 32-bit flag, 622 where each bit corresponds to a general PCE capability. It MAY also 623 include optional sub-TLVs to encode more complex capabilities. 625 The format of the GENERAL-CAP sub-TLV is as follows: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Type | Length | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | General Capabilities Flag | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 // Optional sub-TLVs // 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Type To be assigned by IANA (suggested value =1) 637 Length Variable. 638 Value This comprises a 32-bit flag. The bits are indexed 639 from the most significant to the least significant, 640 where each bit represents one general PCE capability. 641 Optional TLVs may be added to specify more complex 642 capabilities: there is no optional TLV currently 643 defined. 645 IANA is requested to manage the space of the General Capabilities 32- 646 bit flag. 648 The following bits are to be assigned by IANA: 650 Bit Capabilities 652 0 P bit: Support for Request prioritization. 653 1 M bit: Support for multiple messages within the same 654 request message. 656 2-31 Reserved for future assignments by IANA. 658 5.1.6. The PATH-COMP-CAP sub-TLV 660 The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path 661 computation specific capabilities. It MAY be present within the PCED 662 TLV. It MUST not be present more than once. 663 It is made of a 32-bit flag, where each bit correspond to a path 664 computation capability. It MAY also include optional sub-TLVs to 665 encode more complex capabilities. 667 The format of the PATH-COMP-CAP sub-TLV is as follows: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Type | Length | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Path Computation Capabilities Flag | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 // Optional sub-TLVs // 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Type To be assigned by IANA (suggested value =1) 680 Length Variable. 681 Value This comprises a 32 bit flag. Bits are indexed from 682 the most significant to the least significant, where 683 each bit represents one path computation capability. 684 Optional TLVs may be defined to specify more complex 685 capabilities. Three optional sub-TLVs are currently 686 defined. 688 IANA is requested to manage the space of the Path Commutation 689 Capabilities 32-bit flag. 691 The following bits are to be assigned by IANA: 693 Bit Capabilities 695 0 G bit: Capability to handle GMPLS link contraints 696 1 B bit: Capability to compute bidirectional paths 697 2 D bit: Capability to compute link/node/SRLG diverse paths 698 3 L bit: Capability to compute load-balanced paths 699 4 S bit: Capability to compute a set of paths in a 700 synchronized Manner 701 5 O bit: Support for multiple objective functions 702 6 P bit: Capability to handle path constraints (e.g. hop 703 count, metric bound) 705 7-31 Reserved for future assignments by IANA. 707 The G, B, D, L, S, O and P bits are not exclusive. 709 Three optional sub-TLVs are currently defined for the PATH-COMP-CAP 710 TLV: 711 - The Objective Functions sub-TLV (type to be defined, suggested 712 value =1) that carries a list of supported objective functions, 713 where each objective function is identified by a 16 bit integer. 714 - The Opaque Objective Function sub-TLV (type to be defined, 715 suggested value =2) that allows the user to encode a specific 716 objective function in any appropriate language. 717 - The Switch Caps sub-TLV (type to be defined, suggested value =3) 718 that carries a list of supported switching capabilities. It means 719 that the PCE can compute path for the listed switching 720 capabilities. 722 5.1.6.1. Objective Functions sub-TLV 724 The format of the Objective Functions sub-TLV is as follows 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type | Length | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | function 1 | function 2 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 // // 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | function N | | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Type To be defined by IANA (suggested value =1) 739 Length Variable (N*2), where N is the number of supported 740 objective functions. 741 Value This comprises a set of one or more 16 bit function 742 ids, where each function id identifies a supported 743 objective function. 745 Objectives functions and their identification will be defined in a 746 separate document. 748 The Objective Functions sub-TLV is optional, it MAY be present with 749 the PATH-COMP-CAP TLV. When present it MUST be present only once in 750 the PATH-COMP-CAP TLV. 752 5.1.6.2. Opaque Objective Function sub-TLV 754 The format of the Opaque Objective Function sub-TLV is as follows 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Type | Length | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Opaque objective function | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Type To be defined by IANA (suggested value =2) 765 Length Variable 766 Value This encode a specific objective function in any 767 appropriate language. 769 The Opaque Objective Function sub-TLV is optional. The PATH-COMP-CAP TLV 770 MAY comprise 0, one or more Opaque Objective Functions. 772 5.1.6.3. Switch Caps sub-TLV 774 The format of the Switch Caps sub-TLV is as follows 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type | Length | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | SC type | SC type | SC type | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 // // 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Type To be defined by IANA (suggested value =3) 787 Length Variable = N, where N is the number of supported 788 switching capabilities 789 Value This comprises a set of one or more 8-bit switching 790 types, where each switching type identifies a 791 supported switching capability. 793 Switching type values are defined in [RFC4203]. 795 The Objective function sub-TLV is optional, it MAY be present in the 796 PATH-COMP-CAP TLV. When present it MUST be present only once in the 797 PATH-COMP-CAP TLV. 799 5.2. The OSPF PCES TLV 801 The OSPF PCE Status TLV (PCES TLV) carries information related to PCE 802 processing congestion state. 803 The PCES TLV is carried within an OSPF Router Information LSA which 804 is defined in [OSPF-CAP]. 806 The OSPF PCES TLV has the following format: 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Type | Length | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 // PCE ADDRESS sub-TLV // 813 // CONGESTION sub-TLV // 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Type To be defined by IANA (suggested value=3) 817 Length Variable 818 Value This comprises a PCE ADDRESS sub-TLV, identifying the 819 PCE and a CONGESTION sub-TLV that contains congestion 820 information. 822 Sub-TLV types are under IANA control. 824 Currently two sub-TLVs are defined (type values to be assigned by 825 IANA): 826 Sub-TLV type Length Name 827 1 variable PCE-ADDRESS sub-TLV 828 2 4 CONGESTION sub-TLV 830 The PCE-ADDRESS and CONGESTION sub-TLVs MUST be present once 831 in a PCES TLV. The PCE-ADDRESS sub-TLV is defined in section 5.1.1. 832 It carries one of the PCE IP addresses and is used to identify the 833 PCE the processing congestion state information is applied to. This 834 is required as the PCES and PCED TLVs may be carried in separate 835 Router Information LSAs. 837 Any non recognized sub-TLV MUST be silently ignored. 839 Additional sub-TLVs could be added in the future to advertise 840 additional congestion information. 842 5.2.1. The CONGESTION sub-TLV 844 The CONGESTION sub-TLV is used to indicate whether a PCE experiences 845 a processing congestion state or not along with optionally the 846 expected PCE congestion duration. 847 The CONGESTION sub-TLV is mandatory. It MUST be carried once within 848 the PCES TLV. 850 The format of the CONGESTION sub-TLV is as follows: 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Type | Length | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |C| Reserved | Congestion Duration | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Type To be assigned by IANA (suggested value =2) 861 Length 4 863 Value 864 -C bit: When set this indicates that the PCE experiences 865 congestion and cannot support any new request. When 866 cleared this indicates that the PCE does not 867 experience congestion an can support a new request. 869 -Congestion Duration: 2-bytes, the estimated PCE congestion 870 duration in seconds. 872 When C is set and the Congestion Duration field is equal to 0, this 873 means that the Congestion Duration is unknown. 874 When C is cleared the Congestion Duration MUST be set to 0. 876 5.3. Elements of Procedure 878 The PCES and PCED TLV are advertised within an OSPFv2 Router 879 Information LSA (Opaque type of 4 and Opaque ID of 0) or OSPFv3 880 Router information LSA (function code of 12) which are defined in 881 [OSPF-CAP]. As such, elements of procedure are inherited 882 from those defined in [OSPF-CAP]. 884 As the PCES information is likely to change more frequently than the 885 PCED information, it is RECOMMENDED to carry PCES and PCED TLVs in 886 separate Router Information LSAs, so as not to carry all PCED 887 information each time the PCE status changes. 889 In OSPFv2 the flooding scope is controlled by the opaque LSA type (as 890 defined in [RFC2370]) and in OSPFv3 by the S1/S2 bits (as defined in 891 [OSPF-v3]). If the flooding scope is local to an area then the PCED 892 or PCES TLV MUST be carried within an OSPFv2 type 10 router 893 information LSA or an OSPFV3 Router Information LSA with the S1 bit 894 set and the S2 bit cleared. If the flooding scope is the entire 895 domain then the PCED or PCES TLV MUST be carried within an OSPFv2 896 type 11 Router Information LSA or OSPFv3 Router Information LSA with 897 the S1 bit cleared and the S2 bit set. 898 Note that when only the L bit of the PATH-SCOPE sub-TLV is set and 899 the flooding scope MUST be local. 900 Note that the flooding scope of the PCED and PCES TLVs may be 901 distinct, in which case they will be carried in separate LSA. 903 A router MUST originate a new OSPF router information LSA whenever 904 the content of the PCED TLV or PCES TLV changes or whenever required 905 by the regular OSPF procedure (LSA refresh (every LSRefreshTime)). 907 PCED and PCES sub-TLVs are OPTIONAL. When an OSPF LSA does not 908 contain any PCED or PCES sub-TLV, this means that the PCE information 909 of that node is unknown. 911 Note that a change in PCED information MUST not trigger any SPF 912 computation. 914 The way PCEs retrieve their own information is out of the scope of 915 this document. Some information may be configured on the PCE (e.g. 916 address, preferences, scope) and other information may be 917 automatically retrieved by the PCE (e.g. areas of visibility). 919 5.3.1. PCES TLV specific procedures 921 When a PCE enters into a processing congestion state, the conditions 922 of which are implementation dependent, it SHOULD originate a Router 923 Information LSA with a PCES TLV with the C bit set, and optionally a 924 non-null expected congestion duration. 926 When a PCE leaves the processing congestion state, the conditions of 927 which are implementation dependent, there are two cases: 928 - If the congestion duration in the previously originated PCES 929 TLV was null, it SHOULD originate a PCES TLV with the C bit cleared 930 and a null congestion duration; 931 - If the congestion duration in the previously originated PCES 932 TLV was non null, it MAY originate a PCES TLV. Note that in some 933 particular cases it may be desired to originate a PCES TLV with the C 934 bit cleared if the saturation duration was over estimated. 936 The congestion duration allows reducing the amount of OSPF flooding, 937 as only uncongested-congested state transitions are flooded. 939 An implementation SHOULD support an appropriate dampening algorithm 940 so as to dampen OSPF flooding in order to not impact the OSPF 941 scalability. It is RECOMMENDED to introduce some hysteresis for 942 congestion state transition, so as to avoid state oscillations that 943 may impact OSPF performances. For instance two thresholds MAY be 944 configured: A resource saturation upper-threshold and a resource 945 saturation lower-threshold. An LSR enters the congested state when 946 the CPU load reaches the upper threshold and leaves the congested 947 state when the CPU load goes under the lower threshold. 949 Upon receipt of an updated PCES TLV a PCC should take appropriate 950 actions. In particular, the PCC SHOULD stop sending requests to a 951 congested PCE, and SHOULD gradually start sending again requests to a 952 no longer congested PCE. 954 6. ISIS extensions 956 6.1. IS-IS PCED TLV format 958 The IS-IS PCED TLV is made of various non ordered sub-TLVs. 960 The format of the IS-IS PCED TLV and its sub-TLVs is the same as the 961 TLV format used by the Traffic Engineering Extensions to IS-IS [ISIS- 962 TE]. That is, the TLV is composed of 1 octet for the type, 1 octet 963 specifying the TLV length and a value field. 965 The IS-IS PCED TLV has the following format: 967 TYPE: To be assigned by IANA 968 LENGTH: Variable 969 VALUE: set of sub-TLVs 971 Sub-TLVs types are under IANA control. 973 Currently five sub-TLVs are defined (suggested type values to be 974 assigned by IANA): 975 Sub-TLV type Length Name 976 1 variable PCE-ADDRESS sub-TLV 977 2 3 PATH-SCOPE sub-TLV 978 3 variable PCE-DOMAINS sub-TLV 979 4 variable PCE-DEST-DOMAINS sub-TLV 980 5 variable GENERAL-CAP sub-TLV 981 6 variable PATH-COMP-CAP sub-TLV 983 The sub-TLVs PCE-ADDRESS and PATH-SCOPE MUST always be present within 984 the PCED TLV. 986 The sub-TLVs PCE-DOMAINS and PCE-DEST-DOMAINS are optional. They MAY 987 be present in some specific inter-domain cases. 989 The GENERAL-CAP and PATH-COMP-CAP are optional and MAY be present in 990 the PCED TLV to facilitate the PCE selection process. 992 Any non recognized sub-TLV MUST be silently ignored. 994 Additional sub-TLVs could be added in the future to advertise 995 additional PCE information. 997 The PCED TLV is carried within an ISIS CAPABILITY TLV defined in 998 [ISIS-CAP], whose S bit is determined by the desired flooding scope. 1000 6.1.1. PCE-ADDRESS sub-TLV 1002 The PCE-ADDRESS sub-TLV specifies the IP address(es) that MUST be 1003 used to reach the PCE. It is RECOMMENDED to make use of an address 1004 that is always reachable, provided the PCE is alive. 1006 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 1007 PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and 1008 IPv6 address. It MUST not appear more than twice. 1010 The PCE-ADDRESS sub-TLV has the following format: 1012 TYPE: To be assigned by IANA (Suggested value =1) 1013 LENGTH: 4 for IPv4 address and 16 for IPv6 address 1014 VALUE: This comprises one octet indicating the address-type and 4 1015 or 16 octets encoding the IPv4 or IPv6 address to be used 1016 to reach the PCE 1018 Address-type: 1019 1 IPv4 1020 2 IPv6 1022 The P in the PCED sub-LTV 1023 originated by a PCE. It MAY appear multiple times, for instance when 1024 the PCE has both an IPv4 and IPv6 address. It MUST not appear more 1025 than two times. 1027 6.1.2. The PATH-SCOPE sub-TLV 1029 The PATH-SCOPE sub-TLV indicates the PCE path computation scope which 1030 refers to the PCE ability to compute or take part into the 1031 computation of intra-area, inter-area, inter-AS or inter-layer_TE 1032 LSP(s). 1034 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 1035 PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each 1036 PCED TLV. 1038 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 1039 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 1040 and four fields indicating PCE preferences. 1042 The PATH-SCOPE sub-TLV has the following format: 1044 TYPE: To be assigned by IANA (Suggested value =2) 1045 LENGTH: 3 1046 VALUE: This comprises a one-byte flag of bits where each bit 1047 represents a supported path scope, followed by a 2-bytes 1048 preferences field indicating PCE preferences. 1050 Here is the structure of the bit flag: 1052 +-+-+-+-+-+-+-+-+ 1053 |0|1|2|3|4|5|Res| 1054 +-+-+-+-+-+-+-+-+ 1056 Bit Path Scope 1058 0 L bit: Can compute intra-area path 1059 1 R bit: Can act as PCE for inter-area TE LSPs 1060 computation 1061 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 1062 computation 1063 3 S bit: Can act as PCE for inter-AS TE LSPs computation 1064 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 1065 computation 1066 5 Y bit: Can compute or take part into the computation of 1067 paths across layers 1068 6-7 Reserved for future usage. 1070 Here is the structure of the preferences field 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 |PrefL|PrefR|PrefS|PrefY| Res | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Pref-L field: PCE's preference for intra-area TE LSPs computation. 1078 Pref-R field: PCE�s preference for inter-area TE LSPs computation. 1080 Pref-S field: PCE�s preference for inter-AS TE LSPs computation. 1082 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 1084 Res: Reserved for future usage. 1086 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 1087 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 1088 respectively. These bits are non exclusive. 1090 When set the Rd bit indicates that the PCE can act as a default PCE 1091 for inter-area TE LSPs computation (the PCE can compute path for any 1092 destination area). Similarly, when set the Sd bit indicates that the 1093 PCE can act as a default PCE for inter-AS TE LSPs computation (the 1094 PCE can compute path for any destination AS). 1096 When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not 1097 contain any Area ID DOMAIN sub-TLV. 1099 Similarly, when the Sd bit is set the PCE-DEST-DOMAIN TLV does not 1100 contain any AS DOMAIN sub-TLV. 1102 The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the 1103 PCE to specify a preference for each computation scope, where 7 1104 reflects the highest preference. Such preference can be used for 1105 weighted load balancing of requests. An operator may decide to 1106 configure a preference to each PCE so as to balance the path 1107 computation load among them, with respect to their respective CPU 1108 capacity. The algorithms used by a PCC to balance its path 1109 computation requests according to such PCE�s preference is out of the 1110 scope of this document. Same or distinct preferences may be used for 1111 different scopes. For instance an operator that wants a PCE capable 1112 of both inter-area and inter-AS computation to be used preferably for 1113 inter-AS computation may configure a PrefS higher than the PrefR. 1115 When the L bit, R bit, S or Y bit are cleared the PrefL, PrefR, 1116 PrefS, PrefY fields MUST respectively be set to 0. 1118 6.1.3. PCE-DOMAINS sub-TLV 1120 The PCE-DOMAINS sub-TLV specifies the set of domains (areas or AS) 1121 where the PCE has topology visibility and can compute paths. It 1122 contains a set of one or more sub-TLVs where each sub-TLV identifies 1123 a domain. 1125 The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be 1126 inferred by other IGP information, for instance when the PCE is 1127 inter-domain capable (i.e. when the R bit or S bit is set) and the 1128 flooding scope is the entire routing domain. 1130 The PCE-DOMAINS sub-TLV has the following format: 1132 TYPE: To be assigned by IANA (Suggested value =2) 1133 LENGTH: Variable 1134 VALUE: This comprises a set of one or more DOMAIN sub-TLVs where 1135 each DOMAIN sub-TLV identifies a domain where the PCE has 1136 topology visibility and can compute paths 1138 DOMAIN Sub-TLVs types are under IANA control. 1140 Currently two DOMAIN sub-TLVs are defined (suggested type values to 1141 be assigned by IANA): 1142 Sub-TLV type Length Name 1143 1 variable Area ID sub-TLV 1144 2 variable AS number sub-TLV 1146 At least one DOMAIN sub-TLV MUST be present in the PCE-DOMAINS sub- 1147 TLV. 1149 6.1.3.1. Area ID DOMAIN sub-TLV 1151 This sub-TLV carries an ISIS area ID. It has the following format 1153 TYPE: To be assigned by IANA (Suggested value =1) 1154 LENGTH: Variable 1155 VALUE: This comprises a variable length ISIS area ID. This is the 1156 combination of an Initial Domain Part (IDP) and High Order 1157 part of the Domain Specific part (HO-DPS) 1159 6.1.3.2. AS Number DOMAIN sub-TLV 1161 The AS Number sub-TLV carries an AS number. It has the following 1162 format: 1164 TYPE: To be assigned by IANA (Suggested value =2) 1165 LENGTH: 4 1166 VALUE: AS number identifying an AS. When coded on two 1167 bytes (which is the current defined format as the 1168 time of writing this document), the AS Number field 1169 MUST have its left two bytes set to 0. 1171 6.1.4. PCE-DEST-DOMAINS sub-TLV 1173 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 1174 (areas, AS) toward which a PCE can compute path. It means that the 1175 PCE can compute or take part in the computation of inter-domain LSPs 1176 whose destinations are located within one of these domains. It 1177 contains a set of one or more DOMAIN sub-TLVs where each DOMAIN sub- 1178 TLV identifies a domain. 1180 The PCE-DEST-DOMAINS sub-TLV has the following format: 1182 TYPE: To be assigned by IANA (Suggested value =3) 1183 LENGTH: Variable 1184 VALUE: This comprises a set of one or more Area or/and AS DOMAIN sub- 1185 TLVs where each sub-TLV identifies a destination domain toward 1186 which a PCE can compute path. 1188 The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and 1189 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 1190 cleared. 1192 The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub- 1193 TLV. It MUST include at least one area ID sub-TLV, if the R bit of 1194 the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is 1195 cleared. Similarly, it MUST include at least one AS number sub-TLV if 1196 the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH- 1197 SCOPE TLV is cleared. 1199 6.1.5. GENERAL-CAP sub-TLV 1201 The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP 1202 related capabilities. It carries a 32-bit flag, where each bit 1203 corresponds to a general PCE capability. It MAY also include optional 1204 sub-TLVs to encode more complex capabilities. 1206 The GENERAL-CAP sub-TLV has the following format: 1208 TYPE: To be assigned by IANA (Suggested value =4) 1209 LENGTH: Variable 1210 VALUE: This comprises a 32-bit General Capabilities flag where 1211 each bit corresponds to a general PCE capability, and 1212 optional sub-TLVs that may be defined to specify more 1213 complex capabilities. Currently no sub-TLVs are defined. 1215 The following bits in the General Capabilities 32-bit flag are to be 1216 assigned by IANA: 1218 0 1 2 3 1219 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 |P|M| Reserved | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Bit Capabilities 1227 0 P bit: Support for Request prioritization. 1228 1 M bit: Support for multiple messages within the same 1229 request message. 1231 2-31 Reserved for future assignments by IANA. 1233 6.1.6. The PATH-COMP-CAP sub-TLV 1235 The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path 1236 computation specific capabilities of a PCE. 1237 This is a 32-bit flag, where each bit corresponds to a path 1238 computation capability. It MAY also include optional sub-TLVs to 1239 encode more complex capabilities. 1241 The PATH-COMP-CAP sub-TLV has the following format: 1243 TYPE: To be assigned by IANA (suggested value = 5) 1244 LENGTH: Variable 1245 VALUE: This comprises one 32 bit Path Computation Capabilities 1246 Flag, where each bit corresponds to a path computation 1247 capability, and optional sub-TLVs that may be defined to 1248 specify more complex capabilities. Three optional sub-TLVs 1249 are currently defined. 1251 The following bits in the Path Computation Capabilities 32-bit Flag 1252 are to be assigned by IANA: 1254 0 1 2 3 1255 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 ||M|G|D|L|S|0|P Reserved | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 Bit Capabilities 1263 0 G bit: Capability to handle GMPLS link contraints 1264 1 B bit: Capability to compute bidirectional paths 1265 2 D bit: Capability to compute link/node/SRLG diverse paths 1266 3 L bit: Capability to compute load-balanced paths 1267 4 S bit: Capability to compute a set of paths in a 1268 synchronized Manner 1269 5 O bit: Support for multiple objective functions 1270 6 P bit: Capability to handle path constraints (e.g. hop 1271 count, metric bound) 1273 7-31 Reserved for future assignments by IANA. 1275 The G, B, D, L, S, O and P bits are not exclusive. 1277 Three optional sub-TLVs are currently defined for the PATH-COMP-CAP 1278 TLV: 1279 - The Objective Functions sub-TLV (type to be defined, suggested 1280 value =1) that carries a list of supported objective functions, 1281 where each objective function is identified by a 16 bit integer. 1282 - The Opaque Objective Function sub-TLV (type to be defined, 1283 suggested value =2) that allows the user to encode a specific 1284 objective function in any appropriate language. 1285 - The Switch Caps sub-TLV (type to be defined, suggested value =3) 1286 that carries a list of supported switching capabilities. This 1287 means that the PCE can compute paths for the listed switching 1288 capabilities. 1290 6.1.6.1. Objective Functions sub-TLV 1292 The format of the Objective Functions sub-TLV is as follows: 1293 TYPE: To be defined by IANA (suggested value =1) 1294 LENGTH: Variable (N*2) 1295 VALUE: This comprises a set of one or more 16 bit function 1296 ids, where each function id identifies a supported 1297 objective functions. 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | function 1 | function 2 | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 // // 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | function N | | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 Objectives functions and their identification will be defined in a 1308 separate document. 1310 The Objective Functions sub-TLV is optional. It MAY be present within 1311 the PATH-COMP-CAP TLV. When present it MUST be present only once in 1312 the PATH-COMP-CAP TLV. 1314 6.1.6.2. Opaque Objective Function sub-TLV 1316 The format of the Opaque Objective Function sub-TLV is as follows: 1318 TYPE: To be defined by IANA (suggested value =2) 1319 LENGTH: Variable 1320 VALUE: This encode a specific objective function in any 1321 appropriate language. 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Opaque objective function | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 The Opaque Objective function sub-TLV is optional. The PATH-COMP-CAP TLV 1328 MAY comprise 0, one or more Opaque Objective Functions. 1330 6.1.6.3. Switch Caps sub-TLV 1332 The format of the Switch Caps sub-TLV is as follows: 1334 TYPE To be defined by IANA (suggested value =3) 1335 LENGTH Variable = N, where N is the number of supported 1336 switching capabilities 1337 VALUE This comprises a set of one or more 8-bit switching 1338 types, where each switching types identifies a 1339 supported switching capability. 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | SC type | SC type | SC type | | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 // // 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 Switching type values are defined in [RFC4205]. 1349 The Switch Caps sub-TLV is optional. It MAY be present in the PATH-COMP- 1350 CAP TLV. When present it MUST be present only once in the PATH-COMP-CAP 1351 TLV. 1353 6.2. The ISIS PCES TLV 1355 The ISIS PCE Status TLV (PCES TLV) carries information related to PCE 1356 processing congestion state. 1357 The PCES TLV is carried within an ISIS Capability TLV which is 1358 defined in [ISIS-CAP]. 1360 The ISIS PCES TLV has the following format: 1362 TYPE: To be assigned by IANA 1363 LENGTH: Variable 1364 VALUE: set of sub-TLVs 1366 Sub-TLVs types are under IANA control. 1368 Currently two sub-TLVs are defined (suggested type values to be 1369 assigned by IANA): 1370 Sub-TLV type Length Name 1371 1 variable PCE-ADDRESS sub-TLV 1372 2 3 CONGESTION sub-TLV 1374 The PCE-ADDRESS and CONGESTION sub-TLVs MUST be present once 1375 in a PCES TLV. The PCE-ADDRESS sub-TLV is defined in section 6.1.1. 1376 It carries one of the PCE IP addresses and is used to identify the 1377 PCE the processing congestion state information is applied to. This 1378 is required as the PCES and PCED TLVs may be carried in separate 1379 ISIS Capability TLVs. 1381 Any non recognized sub-TLV MUST be silently ignored. 1383 Additional sub-TLVs could be added in the future to advertise 1384 additional congestion information. 1386 6.2.1. The CONGESTION sub-TLV 1388 The CONGESTION sub-TLV is used to indicate whether a PCE experiences 1389 a processing congestion state or not along with optionally the PCE 1390 expected congestion duration. 1391 The CONGESTION sub-TLV is mandatory. It MUST be carried once within 1392 the PCES TLV. 1394 The format of the CONGESTION sub-TLV is as follows: 1396 TYPE: To be assigned by IANA (Suggested value =2) 1397 LENGTH: 3 1398 VALUE: This comprises a one-byte flag of bits indicating the 1399 congestion status, followed by a 2-bytes field indicating the 1400 congestion duration. 1402 Here is the TLV structure 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 |C| Reserved| Congestion Duration | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 Value 1409 -C bit: When set this indicates that the PCE experiences 1410 congestion and cannot support any new request. When 1411 cleared this indicates that the PCE does not 1412 experience congestion an can support a new request. 1414 -Congestion Duration: 2-bytes, the estimated PCE congestion 1415 duration in seconds. 1417 When C is set and the Congestion Duration field is equal to 0, this 1418 means that the Congestion Duration is unknown. 1419 When C is cleared the Congestion Duration MUST be set to 0. 1421 6.3. Elements of Procedure 1423 The PCED and PCES TLV are carried within an ISIS Capability TLV which 1424 is defined in [ISIS-CAP]. 1426 As PCES information is likely to change more frequently than the PCED 1427 information, it is RECOMMENDED to carry PCES and PCED TLVs in 1428 separate ISIS Capability TLVs, so as not to carry all PCED 1429 information each time the PCE status changes. 1431 An ISIS router MUST originate a new ISIS LSP whenever the content 1432 of any of the PCED TLV or PCES TLV changes or whenever required by 1433 the regular ISIS procedure (LSP refresh). 1435 When the scope of the PCED or PCES TLV is area local it MUST be 1436 carried within an ISIS CAPABILITY TLV having the S bit cleared. 1437 When the scope of the PCED or PCES TLV is the entire IGP domain, the 1438 PCED TLV MUST be carried within an ISIS CAPABILITY TLV having the S 1439 bit set. 1440 Note that when only the L bit of the PATH-SCOPE sub-TLV is set and 1441 the flooding scope MUST be local. 1442 Note that the flooding scope of the PCED and PCES TLVs may be 1443 distinct, in which case they are carried in distinct ISIS Capability 1444 TLVs. 1446 PCED and PCES sub-TLVs are OPTIONAL. When an ISIS LSP does not 1447 contain any PCED or PCES sub-TLV, this means that the PCE information 1448 of that node is unknown. 1450 Note that a change in PCED information MUST not trigger any SPF 1451 computation. 1453 The way PCEs retrieve their own information is out of the scope of 1454 this document. Some information may be configured (e.g. address, 1455 preferences, scope) and other information may be automatically 1456 retrieved (e.g. areas of visibility). 1458 6.3.1. PCES TLV specific procedure 1460 When a PCE enters into a processing congestion state, the conditions 1461 of which are implementation dependent, it SHOULD originate a new ISIS 1462 LSP with a Capability TLV carrying a PCES TLV with the C bit set and 1463 optionally a non-null expected congestion duration. 1465 When a PCE leaves the processing congestion state, the conditions of 1466 which are implementation dependent, there are two cases: 1467 - If the congestion duration in the previously originated PCES 1468 TLV was null, it SHOULD originate a PCES TLV with the C bit cleared 1469 and a null congestion duration; 1470 - If the congestion duration in the previously originated PCES 1471 TLV was non null, it MAY originate a PCES TLV. Note that in some 1472 particular cases it may be desired to originate a PCES TLV with the C 1473 bit cleared if the saturation duration was over estimated. 1475 The congestion duration allows reducing the amount of ISIS flooding, 1476 as only uncongested-congested state transitions are flooded. 1478 An implementation SHOULD support an appropriate dampening algorithm 1479 so as to dampen ISIS flooding in order to not impact the ISIS 1480 scalability. It is RECOMMENDED to introduce some hysteresis for 1481 congestion state transition, so as to avoid state oscillations that 1482 may impact ISIS performances. For instance two thresholds MAY be 1483 configured: A resource saturation upper-threshold and a resource 1484 saturation lower-threshold. An LSR enters the congested state when 1485 the CPU load reaches the upper threshold and leaves the congested 1486 state when the CPU load goes under the lower threshold. 1488 Upon receipt of an updated PCES TLV a PCC should take appropriate 1489 actions. In particular, the PCC SHOULD stop sending requests to a 1490 congested PCE, and SHOULD gradually start sending again requests to a 1491 no longer congested PCE. 1493 7. Backward compatibility 1495 The PCED and PCES TLVs defined in this document do not introduce any 1496 interoperability issue. 1497 For OSPF, a router not supporting the PCED/PCES TLVs SHOULD just 1498 silently ignore the TLVs as specified in [OSPF-CAP]. 1499 For ISIS a router not supporting the PCED/PCES TLVs SHOULD just 1500 silently ignore the TLV as specified in [ISIS-CAP]. 1502 8. IANA considerations 1504 8.1. OSPF TLVs 1506 IANA will assign a new codepoint for the OSPF PCED TLV defined in 1507 this document and carried within the Router Information LSA. 1508 IANA is requested to manage sub-TLV types for the PCED TLV. 1510 Five sub-TLVs types are defined for this TLV and should be assigned 1511 by IANA: 1512 -PCE-ADDRESS sub-TLV (suggested value = 1) 1513 -PATH-SCOPE sub-TLV (suggested value = 2) 1514 -PCE-DOMAINS sub-TLV (suggested value = 3) 1515 -PCE-DEST-DOMAINS sub-TLV (suggested value =4) 1516 -GENERAL-CAP sub-TLV (suggested value = 5) 1517 -PATH-COMP-CAP sub-TLV (suggested value = 6) 1519 Three sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 1520 DOMAINS TLVs and should be assigned by IANA: 1521 -IPv4 area ID sub-TLV (suggested value = 1) 1522 -IPv6 area ID sub-TLV (suggested value = 2) 1523 -AS number sub-TLV (suggested value = 3) 1525 Three sub-TLV types are defined for the PATH-COMP-CAP TLV and should 1526 be assigned by IANA: 1527 -Objective Functions sub-TLV (suggested value =1) 1528 -Opaque Objective Function TLV (suggested value =2) 1529 -Switch Caps sub-TLV (suggested value =3) 1531 IANA will assign a new codepoint for the OSPF PCES TLV defined in 1532 this document and carried within the Router Information LSA. 1533 IANA is requested to manage sub-TLV types for the PCES TLV. Two sub- 1534 TLVs types are defined for this TLV and should be assigned by IANA: 1535 -PCE-ADDRESS sub-TLV (suggested value = 1) 1536 -CONGESTION sub-TLV (suggested value = 2) 1538 8.2. ISIS TLVs 1540 IANA will assign a new codepoint for the PCED TLV defined in this 1541 document and carried within the ISIS CAPABILITY TLV. 1542 IANA is requested to manage sub-TLV types for the PCED TLV. 1543 Five sub-TLVs types are defined for the PCED TLV and should be 1544 assigned by IANA: 1545 -PCE-ADDRESS sub-TLV (suggested value = 1) 1546 -PATH-SCOPE sub-TLV (suggested value = 2) 1547 -PCE-DEST-DOMAINS sub-TLV (suggested value = 3) 1548 -PCE-DOMAINS sub-TLV (suggested value = 4) 1549 -GENERAL-CAP sub-TLV (suggested value = 5) 1550 -PATH-COMP-CAP sub-TLV (suggested value = 6) 1552 Two sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 1553 DOMAINS TLVs and should be assigned by IANA: 1554 -Area ID sub-TLV (suggested value = 1) 1555 -AS number sub-TLV (suggested value = 2) 1557 Three sub-TLV type are defined for the PATH-COMP-CAP TLV and should 1558 be assigned by IANA: 1559 -Objective Functions TLV (suggested value =1) 1560 -Opaque Objective Function TLV (suggested value =2) 1561 -Switch Caps sub-TLV (suggested value =3) 1563 IANA will assign a new codepoint for the ISIS PCES TLV defined in 1564 this document and carried within the ISIS CAPABILITY TLV. 1565 IANA is requested to manage sub-TLV types for the PCES TLV. Two sub- 1566 TLVs types are defined for this TLV and should be assigned by IANA: 1567 -PCE-ADDRESS sub-TLV (suggested value = 1) 1568 -CONGESTION sub-TLV (suggested value = 2) 1570 8.3. Capability bits 1572 IANA is requested to manage the space of the General Capabilities 1573 32-bit flag and the Path Computation Capabilities 32-bit flag defined 1574 in this document, numbering them in the usual IETF notation starting 1575 at zero and continuing through 31. 1576 New bit numbers may be allocated only by an IETF Consensus action. 1577 Each bit should be tracked with the following qualities: 1578 - Bit number 1579 - Defining RFC 1580 - Name of bit 1582 Currently two bits are defined in the General Capabilities flag. Here 1583 are the suggested values: 1584 -0: Support for Request prioritization. 1585 -1: Support for multiple messages within the same request message 1587 Currently six bits are defined in the Path Computation Capabilities 1588 flag. Here are the suggested values: 1590 -0: Capability to handle GMPLS Constraints 1591 -1: Capability to compute bidirectional paths 1592 -2: Capability to compute link/node/SRLG diverse paths 1593 -3: Capability to compute load-balanced paths 1594 -4: Capability to compute a set of paths in a 1595 synchronized Manner 1596 -5: Support for multiple objective function 1597 -6: Capability to handle path constraints (e.g. hop count, metric 1598 bound) 1600 9. Security Considerations 1602 To be completed in further revisions. 1604 10. References 1606 10.1. Normative references 1608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1609 Requirement Levels", BCP 14, RFC 2119, March 1997. 1611 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1612 3667, February 2004. 1614 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 1615 Technology", RFC 3979, March 2005. 1617 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1619 [OSPF-v3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1620 RFC 2740, December 1999. 1622 [RFC2370] Coltun, R., �The OSPF Opaque LSA Option�, RFC 2370, July 1623 1998. 1625 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 1626 Routing Exchange Protocol " ISO 10589. 1628 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1629 dual environments", RFC 1195, December 1990. 1631 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 1632 Extensions to OSPF Version 2", RFC 3630, September 2003. 1634 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 1635 Engineering", RFC 3784, June 2004. 1637 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 1638 J.P., "Extensions to OSPF for advertising Optional Router 1639 Capabilities", draft-ietf-ospf-cap, work in progress. 1641 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 1642 router information", draft-ietf-isis-caps, work in progress. 1644 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 1645 Element (PCE) Architecture", draft-ietf-pce-architecture, work in 1646 progress. 1648 [PCE-DISCO-REQ] Le Roux, J.L., et al. "Requirements for PCE 1649 discovery", draft-ietf-pce-discovery-reqs, work in progress 1651 [RFC4203] Kompella, Rekhter, " OSPF Extensions in Support of 1652 Generalized Multi-Protocol Label Switching (GMPLS)", RFC4203, October 1653 2005. 1655 [RFC4205] Kompella, Rekhter, " IS-IS Extensions in Support of 1656 Generalized Multi-Protocol Label Switching (GMPLS)", RFC4205, October 1657 2005. 1659 10.2. Informative references 1661 [PCECP-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol 1662 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in 1663 progress. 1665 [PCEP] Vasseur et al., �Path Computation Element (PCE) communication 1666 Protocol (PCEP) - Version 1�, draft-ietf-pce-pcep, work in progress. 1668 11. Authors' Addresses: 1670 Jean-Louis Le Roux (Editor) 1671 France Telecom 1672 2, avenue Pierre-Marzin 1673 22307 Lannion Cedex 1674 FRANCE 1675 Email: jeanlouis.leroux@francetelecom.com 1677 Jean-Philippe Vasseur (Editor) 1678 Cisco Systems, Inc. 1679 1414 Massachusetts avenue 1680 Boxborough , MA - 01719 1681 USA 1682 Email: jpv@cisco.com 1683 Yuichi Ikejiri 1684 NTT Communications Corporation 1685 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1686 Tokyo 100-8019 1687 JAPAN 1688 Email: y.ikejiri@ntt.com 1690 Raymond Zhang 1691 BT Infonet 1692 2160 E. Grand Ave. 1693 El Segundo, CA 90025 1694 USA 1695 Email: raymond_zhang@infonet.com 1697 12. Intellectual Property Statement 1699 The IETF takes no position regarding the validity or scope of any 1700 Intellectual Property Rights or other rights that might be claimed to 1701 pertain to the implementation or use of the technology described in 1702 this document or the extent to which any license under such rights 1703 might or might not be available; nor does it represent that it has 1704 made any independent effort to identify any such rights. Information 1705 on the procedures with respect to rights in RFC documents can be 1706 found in BCP 78 and BCP 79. 1708 Copies of IPR disclosures made to the IETF Secretariat and any 1709 assurances of licenses to be made available, or the result of an 1710 attempt made to obtain a general license or permission for the use of 1711 such proprietary rights by implementers or users of this 1712 specification can be obtained from the IETF on-line IPR repository at 1713 http://www.ietf.org/ipr. 1715 The IETF invites any interested party to bring to its attention any 1716 copyrights, patents or patent applications, or other proprietary 1717 rights that may cover technology that may be required to implement 1718 this standard. Please address the information to the IETF at 1719 ietf-ipr@ietf.org. 1721 Disclaimer of Validity 1723 This document and the information contained herein are provided on an 1724 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1725 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1726 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1727 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1728 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1729 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1731 Copyright Statement 1733 Copyright (C) The Internet Society (2006). This document is subject 1734 to the rights, licenses and restrictions contained in BCP 78, and 1735 except as set forth therein, the authors retain all their rights.