idnits 2.17.00 (12 Aug 2021) /tmp/idnits38180/draft-ietf-pce-disco-proto-isis-07.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 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 837. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances 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: A change in PCED information MUST not trigger any SPF computation at a receiving router. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2007) is 5361 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) == Outdated reference: draft-ietf-isis-caps has been published as RFC 4971 ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) -- No information found for draft-ietf-pce-disco-proto-ospf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PCED-OSPF' == Outdated reference: draft-ietf-pce-pcep has been published as RFC 5440 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux (Editor) 3 Internet Draft France Telecom 4 Intended Status: Standard Track 5 Expires: March 2008 J.P. Vasseur (Editor) 6 Cisco System Inc. 8 Yuichi Ikejiri 9 NTT Communications 11 Raymond Zhang 12 BT Infonet 14 September 2007 16 IS-IS protocol extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-isis-07.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 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). All rights reserved. 47 Abstract 49 There are various circumstances where it is highly desirable for a 50 Path Computation Client (PCC) to be able to dynamically and 51 automatically discover a set of Path Computation Elements (PCE), 52 along with some information that can be used for PCE selection. When 53 the PCE is a Label Switching Router (LSR) participating in the 54 Interior Gateway Protocol (IGP), or even a server participating 55 passively in the IGP, a simple and efficient way to discover PCEs 56 consists of using IGP flooding. For that purpose this document 57 defines extensions to the Intermediate System to Intermediate System 58 (IS-IS) routing protocol for the advertisement of PCE Discovery 59 information within an IS-IS area or within the entire IS-IS routing 60 domain. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 Table of Contents 70 Terminology........................................................3 71 1. 3 72 2. Introduction................................................4 73 3. Overview....................................................5 74 3.1. PCE Information.............................................5 75 3.1.1. PCE Discovery Information...................................5 76 3.1.2. PCE Overload Information....................................6 77 3.2. Flooding Scope..............................................6 78 4. The IS-IS PCED Sub-TLV......................................6 79 4.1. PCE-ADDRESS Sub-TLV.........................................7 80 4.2. The PATH-SCOPE Sub-TLV......................................7 81 4.3. PCE-DOMAIN Sub-TLV..........................................9 82 4.4. NEIG-PCE-DOMAIN Sub-TLV....................................10 83 4.5. PCE-CAP-FLAGS Sub-TLV......................................11 84 4.6. The OVERLOAD Sub-TLV.......................................11 85 5. Elements of Procedure......................................12 86 5.1. OVERLOAD Sub-TLV Specific Procedures.......................12 87 6. Backward Compatibility.....................................13 88 7. IANA Considerations........................................13 89 8. Security Considerations....................................13 90 9. Manageability Considerations...............................14 91 9.1. Control of Policy and Functions............................14 92 9.2. Information and Data Model.................................14 93 9.3. Liveness Detection and Monitoring..........................14 94 9.4. Verify Correct Operations..................................14 95 9.5. Requirements on Other Protocols and Functional 96 Components...............................................14 98 9.6. Impact on Network Operations...............................15 99 10. Acknowledgments............................................15 100 11. References.................................................15 101 11.1. Normative References.......................................15 102 11.2. Informative References.....................................16 103 12. Editors' Addresses:........................................16 104 13. Contributors' Adresses:....................................16 105 14. Intellectual Property Statement............................17 107 1. Terminology 109 AS: Autonomous System. 111 IGP: Interior Gateway Protocol. Either of the two routing 112 protocols Open Shortest Path First (OSPF) or Intermediate System 113 to Intermediate system (IS-IS). 115 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 116 boundaries. 118 Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries. 120 Inter-area TE LSP: A TE LSP whose path transits two or 121 more IGP areas. That is a TE-LSP that crosses at least one IGP 122 area boundary. 124 Inter-AS TE LSP: A TE LSP whose path transits two or more 125 ASes or sub-ASes (BGP confederations). That is a TE-LSP that 126 crosses at least one AS boundary. 128 IS-IS LSP: Link State PDU 130 LSR: Label Switching Router. 132 PCC: Path Computation Client: Any client application requesting a 133 path computation to be performed by a Path Computation Element. 135 PCE: Path Computation Element: An entity (component, application, 136 or network node) that is capable of computing a network path or 137 route based on a network graph, and applying computational 138 constraints. 140 PCE-Domain: In a PCE context this refers to any collection of 141 network elements within a common sphere of address management or 142 path computational responsibility (referred to as "domain" in 143 [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. 144 This should be distinguished from an IS-IS routing domain as 145 defined by [ISO]. 147 PCEP: Path Computation Element communication Protocol. 149 TE LSP: Traffic Engineered Label Switched Path. 151 2. Introduction 153 [RFC4655] describes the motivations and architecture for a Path 154 Computation Element (PCE)-based path computation model for Multi 155 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic 156 Engineered Label Switched Paths (TE-LSPs). The model allows for the 157 separation of the PCE from a Path Computation Client (PCC) (also 158 referred to as a non co-located PCE) and allows for cooperation 159 between PCEs. This relies on a communication protocol between PCC and 160 PCE, and between PCEs. The requirements for such a communication 161 protocol can be found in [RFC4657] and the communication protocol is 162 defined in [PCEP]. 164 The PCE architecture requires that a PCC be aware of the location of 165 one or more PCEs in its domain, and also potentially of some PCEs in 166 other domains, e.g. in case of inter-domain TE LSP computation. 168 A network may contain a large number of PCEs with potentially 169 distinct capabilities. In such a context it is highly desirable to 170 have a mechanism for automatic and dynamic PCE discovery, which 171 allows PCCs to automatically discover a set of PCEs, along with 172 additional information about each PCE that may be required for the 173 PCC to perform PCE selection. Additionally, it is valuable for a PCC 174 to dynamically detect new PCEs or any modification of the PCE 175 information. Detailed requirements for such a PCE discovery mechanism 176 are provided in [RFC4674]. 178 Moreover, it may also be useful to discover when a PCE experiences 179 processing overload and when it exits such a state, in order for the 180 PCCs to take some appropriate actions (e.g. redirect their requests 181 to another PCE). Note that the PCE selection algorithm applied by a 182 PCC is out of the scope of this document. 184 When PCCs are LSRs participating in the IGP (OSPF, IS-IS), and PCEs 185 are either LSRs or servers also participating in the IGP, an 186 effective mechanism for PCE discovery within an IGP routing domain 187 consists of utilizing IGP advertisements. 189 This document defines IS-IS extensions to allow a PCE in an IS-IS 190 routing domain to advertise its location along with some information 191 useful to a PCC for PCE selection, so as to satisfy dynamic PCE 192 discovery requirements set forth in [RFC4674]. This document also 193 defines extensions allowing a PCE in an IS-IS routing domain to 194 advertise its processing overload state. 196 Generic capability advertisement mechanisms for IS-IS are defined in 197 [IS-IS-CAP]. These allow a router to advertise its capabilities 198 within an IS-IS area or an entire IS-IS routing domain. This document 199 leverages this generic capability advertisement mechanism to fully 200 satisfy the aforementioned dynamic PCE discovery requirements. 202 This document defines a new sub-TLV (named PCE Discovery (PCED)) to 203 be carried within the IS-IS Router Capability TLV ([IS-IS-CAP]). 205 The PCE information advertised is detailed in section 3. Protocol 206 extensions and procedures are defined in section 4 and 5. 208 The IS-IS extensions defined in this document allow for PCE discovery 209 within an IS-IS Routing domain. Solutions for PCE discovery across AS 210 boundaries are beyond the scope of this document, and for further 211 study. 213 This document defines a set of sub-TLVs that are nested within each 214 other. When the degree of nesting TLVs is 2 (a TLV is carried within 215 another TLV) the TLV carried within a TLV is called a sub-TLV. 216 Strictly speaking, when the degree of nesting is 3, a subsub-TLV is 217 carried within a sub-TLV that is itself carried within a TLV. For the 218 sake of terminology simplicity, we refer to sub-TLV, a TLV carried 219 within a TLV regardless of the degree of nesting. 221 3. Overview 223 3.1. PCE Information 225 The PCE information advertised via IS-IS falls into two categories: 226 PCE Discovery information and PCE Overload information. 228 3.1.1. PCE Discovery Information 230 The PCE Discovery information is comprised of: 232 - The PCE location: an IPv4 and/or IPv6 address that is used to reach 233 the PCE. It is RECOMMENDED to use an address that is always 234 reachable; 236 - The PCE path computation scope (i.e. inter-area, inter-AS, inter- 237 layer); 239 - The set of one or more PCE-Domain(s) into which the PCE has 240 visibility and can compute paths; 242 - The set of one or more neighbor PCE-Domain(s) towards which a PCE 243 can compute paths; 245 - A set of communication capabilities (e.g. support for request 246 prioritization) and path computation specific capabilities 247 (e.g. supported constraints). 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 3.1.2. PCE Overload Information 257 The PCE Overload Information is optional and can be used to report 258 a PCE's overload state in order to discourage the PCCs to send new 259 path computation requests. 261 A PCE may decide to clear the overload state according to local 262 implementation triggers (e.g. CPU utilization, average queue length 263 below some pre-defined thresholds). The rate at which a PCE status 264 change is advertised MUST NOT impact by any means the IGP 265 scalability. Particular attention should be given on procedures to 266 avoid state oscillations. 268 3.2. Flooding Scope 270 The flooding scope for PCE information advertised through IS-IS can 271 be a single L1 area, a L1 area and the L2 sub-domain, or the entire 272 IS-IS routing domain. 274 4. The IS-IS PCED Sub-TLV 276 The IS-IS PCED sub-TLV is made of a set of non ordered sub-TLVs. 278 The format of the IS-IS PCED sub-TLV and its sub-TLVs is identical to 279 the TLV format used by the Traffic Engineering Extensions to IS-IS 280 [RFC3784]. That is, the TLV is comprised of 1 octet for the type, 1 281 octet specifying the TLV length, and a value field. The Length field 282 defines the length of the value portion in octets. 284 The IS-IS PCED sub-TLV has the following format: 286 TYPE: To be assigned by IANA (suggested value = 5) 287 LENGTH: Variable 288 VALUE: set of sub-TLVs 290 Six sub-TLVs are defined: 291 Sub-TLV type Length Name 292 1 variable PCE-ADDRESS sub-TLV 293 2 3 PATH-SCOPE sub-TLV 294 3 variable PCE-DOMAIN sub-TLV 295 4 variable NEIG-PCE-DOMAIN sub-TLV 296 5 variable PCE-CAP-FLAGS sub-TLV 297 6 1 OVERLOAD sub-TLV 299 The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within 300 the PCED sub-TLV. 302 The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They 303 MAY be present in the PCED sub-TLV to facilitate selection of inter- 304 domain PCEs. 306 The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED 307 sub-TLV to facilitate the PCE selection process. 309 The OVERLOAD sub-TLV is optional and MAY be present in the PCED sub- 310 TLV, to indicate a PCE's processing overload state. 312 Any non recognized sub-TLV MUST be silently ignored. 314 The PCED sub-TLV is carried within an IS-IS CAPABILITY TLV defined in 315 [IS-IS-CAP]. 317 No additional sub-TLVs will be added to the PCED TLV in the future. 318 If a future application requires advertising additional PCE 319 information in IS-IS, this will not be carried in the CAPABILITY TLV. 321 The following sub-sections describe the sub-TLVs which may be carried 322 within the PCED sub-TLV. 324 4.1. PCE-ADDRESS Sub-TLV 326 The PCE-ADDRESS sub-TLV specifies the IP address that can 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 sub-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. If it appears more than once only the first occurrence MUST be 334 processed and other MUST be ignored. 336 The PCE-ADDRESS sub-TLV has the following format: 338 TYPE: 1 339 LENGTH: 5 for IPv4 address and 17 for IPv6 address 340 VALUE: This comprises one octet indicating the address-type and 4 341 or 16 octets encoding the IPv4 or IPv6 address to be used 342 to reach the PCE. 344 Address-type: 345 1 IPv4 346 2 IPv6 348 4.2. The PATH-SCOPE Sub-TLV 350 The PATH-SCOPE sub-TLV indicates the PCE path computation scope, 351 which refers to the PCE's ability to compute or take part in the 352 computation of intra-area, inter-area, inter-AS, or inter-layer_TE 353 LSP(s). 355 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 356 PCED sub-TLV. There MUST be exactly one instance of the PATH-SCOPE 357 sub-TLV within each PCED sub-TLV. If it appears more than once only 358 the first occurrence MUST be processed and other MUST be ignored. 360 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 361 supported path scopes, and four fields indicating PCE preferences. 363 The PATH-SCOPE sub-TLV has the following format: 365 TYPE: 2 366 LENGTH: 3 367 VALUE: This comprises a one-octet flags field where flag 368 represents a supported path scope, followed by a 2-octets 369 preferences field indicating PCE preferences. 371 Here is the structure of the bits flag: 373 +-+-+-+-+-+-+-+-+ 374 |0|1|2|3|4|5|Res| 375 +-+-+-+-+-+-+-+-+ 377 Bit Path Scope 379 0 L bit: Can compute intra-area path 380 1 R bit: Can act as PCE for inter-area TE LSP computation 381 2 Rd bit: Can act as a default PCE for inter-area TE LSP 382 computation 383 3 S bit: Can act as PCE for inter-AS TE LSP computation 384 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 385 computation 386 5 Y bit: Can compute or take part into the computation of 387 paths across layers 388 6-7 Reserved for future usage. 390 Here is the structure of the preferences field 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |PrefL|PrefR|PrefS|PrefY| Res | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Res: Reserved for future usage. 398 Pref-L field: PCE's preference for intra-area TE LSPs computation. 400 Pref-R field: PCE's preference for inter-area TE LSPs computation. 402 Pref-S field: PCE's preference for inter-AS TE LSPs computation. 404 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 406 Res: Reserved for future usage. 408 The L, R, S, and Y bits are set when the PCE can act as a PCE for 409 intra-area, inter-area, inter-AS or inter-layer TE LSPs computation 410 respectively. These bits are non-exclusive. 412 When set the Rd bit indicates that the PCE can act as a default PCE 413 for inter-area TE LSP computation (that is the PCE can compute a path 414 towards any neighbor area). Similarly, when set, the Sd bit indicates 415 that the PCE can act as a default PCE for inter-AS TE LSP computation 416 (the PCE can compute a path towards any neighbor AS). 418 When the Rd and Sd bit are set, the PCED sub-TLV MUST NOT contain any 419 NEIG-PCE-DOMAIN sub-TLV (see 4.1.4). 421 When the R/S bit is cleared, the Rd/Sd bit SHOULD be cleared and MUST 422 be ignored. 424 The PrefL, PrefR, PrefS and PrefY fields are each three bits long and 425 allow the PCE to specify a preference for each computation scope, 426 where 7 reflects the highest preference. Such preference can be used 427 for weighted load balancing of requests. An operator may decide to 428 configure a preference for each computation scope to each PCE so as 429 to balance the path computation load among them. The algorithms used 430 by a PCC to balance its path computation requests according to such 431 PCE preference are out of the scope of this document and is a matter 432 for local or network wide policy. The same or distinct preferences 433 may be used for each scopes. For instance an operator that wants a 434 PCE capable of both inter-area and inter-AS computation to be used 435 preferably for inter-AS computation may configure a PrefS higher than 436 the PrefR. 438 When the L bit, R bit, S bit or Y bit are cleared the PrefL, PrefR, 439 PrefS, PrefY fields SHOULD respectively be set to 0 and MUST be 440 ignored. 442 Both reserved fields SHOULD be set to zero on transmission and MUST 443 be ignored on receipt. 445 4.3. PCE-DOMAIN Sub-TLV 447 The PCE-DOMAIN sub-TLV specifies a PCE-Domain (areas and/or ASes) 448 where the PCE has topology visibility and through which the PCE can 449 compute paths. 451 The PCE-DOMAIN sub-TLV MAY be present when PCE-Domains cannot be 452 inferred by other IGP information, for instance when the PCE is 453 inter-domain capable (i.e. when the R bit or S bit is set) and the 454 flooding scope is the entire routing domain (see section 5 for a 455 discussion of how the flooding scope is set and interpreted). 457 A PCED sub-TLV MAY include multiple PCE-DOMAIN sub-TLVs when the PCE 458 has visibility in multiple PCE-Domains. 460 The PCE-DOMAIN sub-TLV has the following format: 462 TYPE: 3 463 LENGTH: Variable 464 VALUE: This is comprised of one octet indicating the domain-type 465 (area ID or AS Number) and a variable length IS-IS area ID or a 32 466 bits AS number, identifying a PCE-domain where the PCE has visibility. 468 Two domain types are defined: 469 1 Area ID 470 2 AS Number 471 The Area ID is the area address as defined in [ISO]. 473 When coded in two octets (which is the current defined format as the 474 time of writing this document), the AS Number field MUST have its 475 left two octets set to 0. 477 4.4. NEIG-PCE-DOMAIN Sub-TLV 479 The NEIG-PCE-DOMAIN sub-TLV specifies a neighbour PCE-domain (area, 480 AS) toward which a PCE can compute paths. It means that the PCE can 481 take part in the computation of inter-domain TE LSPs whose path 482 transits this neighbour PCE-domain. 484 A PCED sub-TLV MAY include several NEIG-PCE-DOMAIN sub-TLVs when the 485 PCE can compute paths towards several neighbour PCE-domains. 487 The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN 488 sub-TLV: 490 TYPE: 4 491 LENGTH: Variable 492 VALUE: This comprises one octet indicating the domain-type (area ID 493 or AS Number) and a variable length IS-IS area ID or a 32 bits AS 494 number, identifying a PCE-domain towards which the PCE can compute 495 paths. 497 Two domain types are defined: 498 1 Area ID 499 2 AS Number 501 The Area ID is the area address as defined in [ISO]. 503 When coded in two octets (which is the current defined format as the 504 time of writing this document), the AS Number field MUST have its 505 first two octets set to 0. 507 The NEIG-PCE-DOMAIN sub-TLV MUST be present if the R bit is set and 508 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 509 cleared. 511 4.5. PCE-CAP-FLAGS Sub-TLV 513 The PCE-CAP-FLAGs sub-TLV is an optional sub-TLV used to indicate 514 PCEP related capabilities. It MAY be present within the PCED sub-TLV. 515 It MUST NOT be present more than once. If it appears more than once 516 only the first occurrence MUST be processed and other MUST be ignored. 518 The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array 519 of units of 32 bit flags numbered from the most significant as bit 520 zero, where each bit represents one PCE capability. 522 The PCE-CAP-FLAGS sub-TLV has the following format: 524 TYPE: 5 525 LENGTH: Multiple of 4 526 VALUE: This contains an array of units of 32 bit flags numbered 527 from the most significant as bit zero, where each bit 528 represents one PCE capability. 530 The PCE capability registry is managed by IANA, it is common 531 with OSPF and defined in [PCED-OSPF]. 533 Reserved bits SHOULD be set to zero on transmission and MUST be 534 ignored on receipt. 536 4.6. The OVERLOAD Sub-TLV 538 The OVERLOAD sub-TLV is used to indicate that a PCE is experiencing a 539 processing overload state and may optionally include expected PCE 540 overload duration. 541 The OVERLOAD sub-TLV is optional, it MAY be carried within the PCED 542 sub-TLV. It MUST NOT be present more than once. If it appears more 543 than once only the first occurrence MUST be processed and other MUST 544 be ignored. 546 The format of the OVERLOAD sub-TLV is as follows: 548 TYPE: 6 549 LENGTH: 1 550 VALUE: This comprises a one octet of bit flags indicating the 551 overload status. Currently only the first flag is defined. 553 Here is the TLV structure 555 +-+-+-+-+-+-+-+-+ 556 |C| Reserved| 557 +-+-+-+-+-+-+-+-+ 558 Value 559 -C bit: When set this indicates that the PCE is overloaded 560 and cannot accept any new request. When cleared this 561 indicates that the PCE is not overloaded and can 562 accept new requests. 564 5. Elements of Procedure 566 The PCED sub-TLV is advertised within an IS-IS Router Capability TLV 567 defined in [IS-IS-CAP]. As such, elements of procedures are inherited 568 from those defined in [IS-IS-CAP]. 570 The flooding scope is controlled by the S flag in the IS-IS Router 571 Capability TLV (see [IS-IS-CAP]). When the scope of the PCED sub-TLV 572 is area local it MUST be carried within an IS-IS Router Capability 573 TLV having the S bit cleared. When the scope of the PCED sub-TLV is 574 the entire IS-IS routing domain, it MUST be carried within an IS-IS 575 Router Capability TLV having the S bit set. Note that when only the L 576 bit of the PATH-SCOPE sub-TLV is set, the flooding scope MUST be area 577 local. 579 Note that a L1L2 node may include both in its L1 and L2 LSPs a PCED 580 TLV in a Router Capability TLV with the S bit cleared. This allows 581 restricting the flooding scope to the L1 area and the L2 sub-domain. 583 An IS-IS router MUST originate a new IS-IS LSP whenever there is a 584 change in a PCED TLV associated with a PCE it advertises. 586 When a PCE is deactivated, the IS-IS Router advertising this PCE MUST 587 originate a new IS-IS LSP that no longer includes the corresponding 588 PCED TLV. 590 The PCE address(s), i.e. the address(s) indicated within the PCE 591 ADDRESS sub-TLV, SHOULD be reachable via some prefix(es) advertised 592 by IS-IS; this allows speeding up the detection of a PCE failure. 593 Note that when the PCE address is no longer reachable, this means 594 that the PCE node has failed or has been torn down, or that there is 595 no longer IP connectivity to the PCE node. 597 A change in PCED information MUST not trigger any SPF computation at 598 a receiving router. 600 The way PCEs determine the information they advertise is out of the 601 scope of this document. Some information may be configured (e.g., 602 address, preferences, scope) and other information may be 603 automatically determined by the PCE (e.g. areas of visibility). 605 5.1. OVERLOAD Sub-TLV Specific Procedures 607 When a PCE enters into an overload state, the conditions of which are 608 implementation dependent, a new IS-IS LSP with an OVERLOAD sub-TLV 609 with the C bit set MAY be generated. 611 When a PCE exists from an overload state, the conditions of which are 612 implementation dependent (e.g. CPU utilization, average queue length 613 below some pre-defined thresholds), a new IS-IS LSP with an OVERLOAD 614 sub-TLV with the C bit cleared SHOULD be generated, if an OVERLOAD 615 sub-TLV with the C bit set had previously been generated. 617 A PCE implementation supporting the IS-IS extensions defined in this 618 document SHOULD support an appropriate dampening algorithm so as to 619 dampen flooding of PCE Overload information in order to not impact 620 the IS-IS scalability. It is RECOMMENDED to introduce some hysteresis 621 for overload state transition, so as to avoid state oscillations that 622 may impact IS-IS performance. For instance two thresholds MAY be 623 configured: an upper-threshold and a lower-threshold. An LSR enters 624 the overload state when the CPU load reaches the upper threshold and 625 leaves the overload state when the CPU load goes under the lower 626 threshold. 628 Upon receipt of an updated OVERLOAD sub-TLV a PCC should take 629 appropriate actions. In particular, the PCC SHOULD stop sending 630 requests to an overloaded PCE, and SHOULD gradually start sending 631 again requests to a PCE that is no longer overloaded. 633 6. Backward Compatibility 635 The PCED sub-TLV defined in this document does not introduce any 636 interoperability issues. 638 An IS-IS router not supporting the PCED sub-TLV will just silently 639 ignore the TLV as specified in [IS-IS-CAP]. 641 7. IANA Considerations 643 Once a registry for the IS-IS Router Capability sub-TLVs, defined in 644 [IS-IS-CAP] has been assigned, IANA will assign a new sub-TLV code- 645 point for the PCED sub-TLV carried within the Router Capability TLV. 647 Value Sub-TLV References 648 ----- -------- ---------- 649 5 PCED sub-TLV (this document) 651 8. Security Considerations 653 This document defines IS-IS extensions for PCE discovery within an 654 administrative domain. Hence the security of the PCE discovery relies 655 on the security of IS-IS. 657 Mechanisms defined to ensure authenticity and integrity of IS-IS LSPs 658 [RFC3567], and their TLVs, can be used to secure the PCED sub-TLV as 659 well. 661 IS-IS provides no encryption mechanism for protecting the privacy of 662 LSPs, and in particular the privacy of the PCE discovery information. 664 9. Manageability Considerations 666 Manageability considerations for PCE Discovery are addressed in 667 section 4.10 of [RFC4674]. 669 9.1. Control of Policy and Functions 671 Requirements on the configuration of PCE discovery parameters on PCCs 672 and PCEs are discussed in section 4.10.1 of [RFC4674]. 674 Particularly, a PCE implementation SHOULD allow configuring the 675 following parameters on the PCE: 676 -The PCE IPv4/IPv6 address(es) (see section 4.1.1) 677 -The PCE Scope, including the inter-domain functions (inter- 678 area, inter-AS, inter-layer), the preferences, and whether the 679 PCE can act as default PCE (see section 4.1.2) 680 -The PCE domains (see section 4.1.3) 681 -The neighbour PCE domains (see section 4.1.4) 682 -The PCE capabilities (see section 4.1.5) 684 9.2. Information and Data Model 686 A MIB module for PCE Discovery is defined in [PCED-MIB]. 688 9.3. Liveness Detection and Monitoring 690 PCE Discovery Protocol liveness detection relies upon IS-IS liveness 691 detection. IS-IS already includes a liveness detection mechanism 692 (Hello PDUs), and PCE discovery does not require additional 693 capabilities. 695 Procedures defined in section 5.1 allow a PCC detecting when a PCE 696 has been deactivated, or is no longer reachable. 698 9.4. Verify Correct Operations 700 The correlation of information advertised against information 701 received can be achieved by comparing the PCED information in the PCC 702 and in the PCE, which is stored in the PCED MIB [PCED-MIB]. The 703 number of dropped, corrupt, and rejected information elements are 704 stored in the PCED MIB. 706 9.5. Requirements on Other Protocols and Functional Components 708 The IS-IS extensions defined in this document do not imply any 709 requirement on other protocols. 711 9.6. Impact on Network Operations 713 Frequent changes in PCE information, and particularly in PCE overload 714 information, may have a significant impact on IS-IS and might 715 destabilize the operation of the network by causing the PCCs to swap 716 between PCEs. 718 As discussed in section 5.1, a PCE implementation SHOULD support an 719 appropriate dampening algorithm so as to dampen IS-IS flooding in 720 order to not impact the IS-IS scalability. 722 Also, as discussed in section 4.10.4 of [RFC4674], it MUST be 723 possible to apply at least the following controls: 725 - Configurable limit on the rate of announcement of changed 726 parameters at a PCE. 727 - Control of the impact on PCCs such as through discovery messages 728 rate-limiting. 729 - Configurable control of triggers that cause a PCC to swap to 730 another PCE. 732 10. Acknowledgments 734 We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike 735 Shand, Lou Berger, and David Ward, for their useful comments and 736 suggestions. 738 11. References 740 11.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [ISO] "Intermediate System to Intermediate System Intra-Domain 746 Routeing Exchange Protocol for use in Conjunction with the 747 Protocol for Providing the Connectionless-mode Network Service 748 (ISO 8473)", ISO DP 10589, February 1990. 750 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 751 Engineering", RFC 3784, June 2004. 753 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 754 router information", draft-ietf-isis-caps, work in progress. 756 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 757 Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, 758 July 2003. 760 [PCED-OSPF] Le Roux, Vasseur, et al. "OSPF protocol extensions for 761 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 762 proto-ospf, work in progress. 764 11.2. Informative References 766 [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic 767 Requirements", RFC4657, September 2006. 769 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 770 communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work 771 in progress. 773 [PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path 774 Computation Element Discovery", draft-ietf-pce-disc-mib, work in 775 progress. 777 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 778 Element (PCE)-based Architecture", RFC4655, august 2006. 780 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 781 RFC4674, October 2006. 783 12. Editors' Addresses: 785 Jean-Louis Le Roux (Editor) 786 France Telecom 787 2, avenue Pierre-Marzin 788 22307 Lannion Cedex 789 FRANCE 790 Email: jeanlouis.leroux@orange-ftgroup.com 792 Jean-Philippe Vasseur (Editor) 793 Cisco Systems, Inc. 794 1414 Massachusetts avenue 795 Boxborough , MA - 01719 796 USA 797 Email: jpv@cisco.com 799 13. Contributors' Adresses: 801 Yuichi Ikejiri 802 NTT Communications Corporation 803 1-1-6, Uchisaiwai-cho, Chiyoda-ku 804 Tokyo 100-8019 805 JAPAN 806 Email: y.ikejiri@ntt.com 808 Raymond Zhang 809 BT Infonet 810 2160 E. Grand Ave. 811 El Segundo, CA 90025 812 USA 813 Email: raymond_zhang@bt-infonet.com 815 14. Intellectual Property Statement 817 The IETF takes no position regarding the validity or scope of any 818 Intellectual Property Rights or other rights that might be claimed to 819 pertain to the implementation or use of the technology described in 820 this document or the extent to which any license under such rights 821 might or might not be available; nor does it represent that it has 822 made any independent effort to identify any such rights. Information 823 on the procedures with respect to rights in RFC documents can be 824 found in BCP 78 and BCP 79. 826 Copies of IPR disclosures made to the IETF Secretariat and any 827 assurances of licenses to be made available, or the result of an 828 attempt made to obtain a general license or permission for the use of 829 such proprietary rights by implementers or users of this 830 specification can be obtained from the IETF on-line IPR repository at 831 http://www.ietf.org/ipr. 833 The IETF invites any interested party to bring to its attention any 834 copyrights, patents or patent applications, or other proprietary 835 rights that may cover technology that may be required to implement 836 this standard. Please address the information to the IETF at 837 ietf-ipr@ietf.org. 839 Disclaimer of Validity 841 This document and the information contained herein are provided 842 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 843 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 844 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 845 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 846 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 847 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 848 FOR A PARTICULAR PURPOSE. 850 Copyright Statement 852 Copyright (C) The IETF Trust (2007). This document is subject to the 853 rights, licenses and restrictions contained in BCP 78, and except as 854 set forth therein, the authors retain all their rights.