idnits 2.17.1 draft-ietf-pce-disco-proto-ospf-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 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 949. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 634 has weird spacing: '...ded and can...' -- 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 6040 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'PCED-ISIS' is defined on line 885, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Downref: Normative reference to an Experimental RFC: RFC 2154 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 OSPF protocol extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-ospf-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 Open Shortest Path First (OSPF) routing 58 protocol for the advertisement of PCE Discovery information within an 59 OSPF area or within the entire OSPF routing domain. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 Table of Contents 69 1. Terminology.................................................3 70 2. Introduction................................................4 71 3. Overview....................................................5 72 3.1. PCE Information.............................................5 73 3.2. PCE Discovery Information...................................5 74 3.2.1. PCE Overload Information....................................5 75 3.3. Flooding Scope..............................................6 76 4. The OSPF PCED TLV...........................................6 77 4.1. PCE-ADDRESS Sub-TLV.........................................7 78 4.2. PATH-SCOPE Sub-TLV..........................................8 79 4.3. PCE-DOMAIN Sub-TLV.........................................10 80 4.4. NEIG-PCE-DOMAIN Sub-TLV....................................11 81 4.5. PCE-CAP-FLAGS Sub-TLV......................................12 82 4.6. The OVERLOAD Sub-TLV.......................................13 83 5. Elements of Procedure......................................14 84 5.1. OVERLOAD sub-TLV Specific Procedures.......................14 85 6. Backward Compatibility.....................................15 86 7. IANA Considerations........................................15 87 7.1. OSPF TLV...................................................15 88 7.2. PCE Capability Flags registry..............................15 89 8. Security Considerations....................................16 90 9. Manageability Considerations...............................16 91 9.1. Control of Policy and Functions............................16 92 9.2. Information and Data Model.................................17 93 9.3. Liveness Detection and Monitoring..........................17 94 9.4. Verify Correct Operations..................................17 95 9.5. Requirements on Other Protocols and Functional 96 Components...............................................17 97 9.6. Impact on network operations...............................17 98 10. Acknowledgments............................................18 99 11. References.................................................18 100 11.1. Normative references.......................................18 101 11.2. Informative references.....................................18 102 12. Editor's Addresses.........................................19 103 13. Contributors' Addresses....................................19 104 14. Intellectual Property Statement............................19 106 1. Terminology 108 ABR: OSPF Area Border Router. 110 AS: Autonomous System. 112 IGP: Interior Gateway Protocol. Either of the two routing 113 protocols Open Shortest Path First (OSPF) or Intermediate System 114 to Intermediate System (ISIS). 116 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 117 boundaries. 119 Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries. 121 Inter-area TE LSP: A TE LSP whose path transits two or more IGP 122 areas. That is a TE-LSP that crosses at least one IGP area 123 boundary. 125 Inter-AS TE LSP: A TE LSP whose path transits two or more 126 ASes or sub-ASes (BGP confederations). That is a TE-LSP that 127 crosses at least one AS boundary. 129 LSA: Link State Advertisement 131 LSR: Label Switching Router. 133 PCC: Path Computation Client: Any client application requesting a 134 path computation to be performed by a Path Computation Element. 136 PCE: Path Computation Element: An entity (component, application, 137 or network node) that is capable of computing a network path or 138 route based on a network graph, and applying computational 139 constraints. 141 PCE-Domain: In a PCE context this refers to any collection of 142 network elements within a common sphere of address management or 143 path computational responsibility (referred to as "domain" in 144 [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. 145 This should be distinguished from an OSPF routing domain. 147 PCEP: Path Computation Element Protocol. 149 TE LSP: Traffic Engineered Label Switched Path. 151 2. Introduction 153 [RFC4655] describes the motivations and architecture for a PCE-based 154 path computation model for Multi Protocol Label Switching (MPLS) and 155 Generalized MPLS (GMPLS) Traffic Engineered Label Switched Paths (TE- 156 LSPs). The model allows for the separation of the PCE from a Path 157 Computation Client (PCC) (also referred to as a non co-located PCE) 158 and allows for cooperation between PCEs. This relies on a 159 communication protocol between PCC and PCE, and between PCEs. The 160 requirements for such a communication protocol can be found in 161 [RFC4657] and the communication protocol is defined in [PCEP]. 163 The PCE architecture requires that a PCC be aware of the location of 164 one or more PCEs in its domain, and also potentially of some PCEs in 165 other domains, e.g. in case of inter-domain TE LSP computation. 167 A network may contain a large number of PCEs with potentially 168 distinct capabilities. In such a context it is highly desirable to 169 have a mechanism for automatic and dynamic PCE discovery, which 170 allows PCCs to automatically discover a set of PCEs, along with 171 additional information about each PCE that may be required for the 172 PCC to perform PCE selection. Additionally, it is valuable for a PCC 173 to dynamically detect new PCEs or any modification of the PCE 174 information. Detailed requirements for such a PCE discovery mechanism 175 are provided in [RFC4674]. 177 Moreover, it may also be useful to discover when a PCE experiences 178 processing overload and when it exits such a state, in order for the 179 PCCs to take some appropriate actions (e.g. to redirect their 180 requests to another PCE). Note that the PCE selection algorithm 181 applied by a PCC is out of the scope of this document. 183 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 184 are either LSRs or servers also participating in the IGP, an 185 effective mechanism for PCE discovery within an IGP routing domain 186 consists of utilizing IGP advertisements. 188 This document defines OSPF extensions to allow a PCE in an OSPF 189 routing domain to advertise its location along with some information 190 useful to a PCC for PCE selection so as to satisfy dynamic PCE 191 discovery requirements set forth in [RFC4674]. This document also 192 defines extensions allowing a PCE in an OSPF routing domain to 193 advertise its overload state. 195 Generic capability advertisement mechanisms for OSPF are defined in 196 [OSPF-CAP]. These allow a router to advertise its capabilities within 197 an OSPF area or an entire OSPF routing domain. This document 198 leverages this generic capability advertisement mechanism to fully 199 satisfy the aforementioned dynamic PCE discovery requirements. 201 This document defines a new TLV (named the PCE Discovery (PCED) TLV) 202 to be carried within the OSPF Router Information LSA ([OSPF-CAP]). 204 The PCE information advertised is detailed in section 3. Protocol 205 extensions and procedures are defined in section 4 and 5. 207 The OSPF extensions defined in this document allow for PCE discovery 208 within an OSPF Routing domain. Solutions for PCE discovery across AS 209 boundaries are beyond the scope of this document, and for further 210 study. 212 3. Overview 214 3.1. PCE Information 216 The PCE information advertised via OSPF falls into two categories: 217 PCE Discovery information and PCE Overload information. 219 3.2. PCE Discovery Information 221 The PCE Discovery information is comprised of: 223 - The PCE location: an IPv4 and/or IPv6 address that is used to reach 224 the PCE. It is RECOMMENDED to use an address that is always 225 reachable; 227 - The PCE path computation scope (i.e. inter-area, inter-AS, inter- 228 layer); 230 - The set of one or more PCE-Domain(s) into which the PCE has 231 visibility and can compute paths; 233 - The set of one or more neighbor PCE-Domain(s) towards which a PCE 234 can compute paths; 236 - A set of communication capabilities (e.g. support for request 237 prioritization) and path computation specific capabilities 238 (e.g. supported constraints). 240 PCE Discovery information is by nature fairly static and does not 241 change with PCE activity. Changes in PCE Discovery information may 242 occur as a result of PCE configuration updates, PCE 243 deployment/activation, PCE deactivation/suppression, or PCE failure. 244 Hence, this information is not expected to change frequently. 246 3.2.1. PCE Overload Information 248 The PCE Overload information is optional and can be used to report a 249 PCE's overload state in order to discourage the PCCs to send new path 250 computation requests. 252 A PCE may decide to clear the overload state according to local 253 implementation triggers (e.g. CPU utilization, average queue length 254 below some predefined thresholds). The rate at which a PCE Status 255 change is advertised MUST NOT impact by any means the IGP 256 scalability. Particular attention MUST be given on procedures to 257 avoid state oscillations. 259 3.3. Flooding Scope 261 The flooding scope for PCE information advertised through OSPF can be 262 limited to one or more OSPF areas the PCE belongs to, or can be 263 extended across the entire OSPF routing domain. 265 Note that some PCEs may belong to multiple areas, in which case the 266 flooding scope may comprise these areas. This could be the case for 267 an ABR for instance advertising its PCE information within the 268 backbone area and/or a subset of its attached IGP area(s). 270 4. The OSPF PCED TLV 272 The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered 273 sub-TLVs. 275 The format of the OSPF PCED TLV and its sub-TLVs is identical to the 276 TLV format used by the Traffic Engineering Extensions to OSPF 277 [RFC3630]. That is, the TLV is comprised of 2 octets for the type, 2 278 octets specifying the TLV length, and a value field. The Length field 279 defines the length of the value portion in octets. 281 The TLV is padded to four-octet alignment; padding is not included in 282 the Length field (so a three octet value would have a length of 283 three, but the total size of the TLV would be eight octets). Nested 284 TLVs are also four-octet aligned. Unrecognized types are ignored. 286 The OSPF PCED TLV has the following format: 288 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | 294 // sub-TLVs // 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Type To be defined by IANA (suggested value=5) 299 Length Variable 300 Value This comprises one or more sub-TLVs 302 Six sub-TLVs are defined: 303 Sub-TLV type Length Name 304 1 variable PCE-ADDRESS sub-TLV 305 2 4 PATH-SCOPE sub-TLV 306 3 variable PCE-DOMAIN sub-TLV 307 4 variable NEIG-PCE-DOMAIN sub-TLV 308 5 variable PCE-CAP-FLAGS sub-TLV 309 6 4 OVERLOAD sub-TLV 311 The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within 312 the PCED TLV. 314 The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They MAY be 315 present in the PCED TLV to facilitate selection of inter-domain PCEs. 317 The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED 318 TLV to facilitate the PCE selection process. 320 The OVERLOAD sub-TLV is optional and MAY be present in the PCED TLV, 321 to indicate a PCE's overload state. 323 Any non recognized sub-TLV MUST be silently ignored. 325 The PCED TLV is carried within an OSPF Router Information LSA 326 defined in [OSPF-CAP]. 328 No additional sub-TLVs will be added to the PCED TLV in the future. 329 If a future application requires advertising additional PCE 330 information in OSPF, this will not be carried in the Router 331 Information LSA. 333 The following sub-sections describe the sub-TLVs which may be carried 334 within the PCED sub-TLV. 336 4.1. PCE-ADDRESS Sub-TLV 338 The PCE-ADDRESS sub-TLV specifies the IP address(es) that can be 339 used to reach the PCE. It is RECOMMENDED to make use of an address 340 that is always reachable, provided that the PCE is alive. 342 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 343 PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and IPv6 344 address. It MUST NOT appear more than once for the same address type. 345 If it appears more than once, only the first occurrence MUST be 346 processed and other MUST be ignored. 348 The format of the PCE-ADDRESS sub-TLV is as follows: 350 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type = 1 | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | address-type | Reserved | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 // PCE IP Address // 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 PCE-ADDRESS sub-TLV format 364 Type 1 365 Length 8 (IPv4) or 20 (IPv6) 367 Address-type: 368 1 IPv4 369 2 IPv6 371 PCE IP Address: The IP address to be used to reach the PCE. 373 4.2. PATH-SCOPE Sub-TLV 375 The PATH-SCOPE sub-TLV indicates the PCE path computation scope, 376 which refers to the PCE's ability to compute or take part in the 377 computation of intra-area, inter-area, inter-AS, or inter-layer_TE 378 LSP(s). 380 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 381 PCED TLV. There MUST be exactly one instance of the PATH-SCOPE sub- 382 TLV within each PCED TLV. If it appears more than once, only the 383 first occurrence MUST be processed and other MUST be ignored. 385 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 386 supported path scopes and four fields indicating PCE preferences. 388 The PATH-SCOPE sub-TLV has the following format: 390 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type = 2 | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Type 2 398 Length 4 399 Value This comprises a 2-octet flag field where each bit 400 represents a supported path scope, as well as four 401 preference fields used to specify PCE preferences. 403 The following bits are defined: 405 Bit Path Scope 407 0 L bit: Can compute intra-area paths 408 1 R bit: Can act as PCE for inter-area TE LSP 409 computation 410 2 Rd bit: Can act as a default PCE for inter-area TE LSP 411 computation 412 3 S bit: Can act as PCE for inter-AS TE LSP computation 413 4 Sd bit: Can act as a default PCE for inter-AS TE LSP 414 computation 415 5 Y bit: Can compute or take part into the computation 416 of paths across layers. 418 Pref-L field: PCE's preference for intra-area TE LSPs computation. 420 Pref-R field: PCE's preference for inter-area TE LSPs computation. 422 Pref-S field: PCE's preference for inter-AS TE LSPs computation. 424 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 426 Res: Reserved for future usage. 428 The L, R, S, and Y bits are set when the PCE can act as a PCE for 429 intra-area, inter-area, inter-AS, or inter-layer TE LSPs computation 430 respectively. These bits are non-exclusive. 432 When set the Rd bit indicates that the PCE can act as a default PCE 433 for inter-area TE LSPs computation (that is the PCE can compute a 434 path towards any neighbor area). Similarly, when set, the Sd bit 435 indicates that the PCE can act as a default PCE for inter-AS TE LSP 436 computation (the PCE can compute a path towards any neighbor AS). 438 When the Rd and Sd bit are set the PCED TLV MUST NOT contain any 439 NEIG-PCE-DOMAIN sub-TLV (see 4.1.4). 441 When the R/S bit is cleared, the Rd/Sd bit SHOULD be cleared and MUST 442 be ignored. 444 The PrefL, PrefR, PrefS and PrefY fields are each three bits long and 445 allow the PCE to specify a preference for each computation scope, 446 where 7 reflects the highest preference. Such preference can be used 447 for weighted load balancing of requests. An operator may decide to 448 configure a preference for each computation scope to each PCE so as 449 to balance the path computation load among them. The algorithms used 450 by a PCC to load balance its path computation requests according to 451 such PCE preference is out of the scope of this document and is a 452 matter for local or network wide policy. The same or distinct 453 preferences may be used for each scope. For instance an operator that 454 wants a PCE capable of both inter-area and inter-AS computation to be 455 used preferably for inter-AS computation may configure a PrefS higher 456 than the PrefR. 458 When the L bit, R bit, S bit or Y bit are cleared, the PrefL, PrefR, 459 PrefS, PrefY fields SHOULD respectively be set to 0 and MUST be 460 ignored. 462 Both reserved fields SHOULD be set to zero on transmission and MUST 463 be ignored on receipt. 465 4.3. PCE-DOMAIN Sub-TLV 467 The PCE-DOMAIN sub-TLV specifies a PCE-Domain (areas and/or ASes) 468 where the PCE has topology visibility and through which the PCE can 469 compute paths. 471 The PCE-DOMAIN sub-TLV MAY be present when PCE-Domains cannot be 472 inferred by other IGP information, for instance when the PCE is 473 inter-domain capable (i.e. when the R bit or S bit is set) and the 474 flooding scope is the entire routing domain (see section 5 for a 475 discussion of how the flooding scope is set and interpreted). 477 A PCED TLV MAY include multiple PCE-DOMAIN sub-TLVs when the PCE has 478 visibility in multiple PCE-Domains. 480 The PCE-DOMAIN sub-TLV has the following format: 482 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type=3 | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Domain-type | Reserved | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 // Domain ID // 491 | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 PCE-DOMAIN sub-TLV format 496 Type 3 497 Length Variable 498 3 domain-type values are defined: 499 1 IPv4 Area Address 500 2 IPv6 Area Address 501 3 AS Number 503 Domain ID: With the address type 1/2 this indicates the IPv4/v6 504 address of an area where the PCE has visibility. With address- 505 type 3 this indicates an AS number where the PCE has 506 visibility. When coded in two octets (which is the current 507 defined format as the time of writing this document), the AS 508 Number field MUST have its first two octets set to 0. 509 . 510 4.4. NEIG-PCE-DOMAIN Sub-TLV 512 The NEIG-PCE-DOMAIN sub-TLV specifies a neighbour PCE-domain (area, 513 AS) toward which a PCE can compute paths. It means that the PCE can 514 take part in the computation of inter-domain TE LSPs whose path 515 transits this neighbour PCE-domain. 517 A PCED sub-TLV MAY include several NEIG-PCE-DOMAIN sub-TLVs when the 518 PCE can compute paths towards several neighbour PCE-domains. 520 The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN 521 sub-TLV: 523 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type = 4 | Length | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Domain-type | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 // Domain ID // 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 NEIG-PCE-DOMAIN sub-TLV format 537 Type 4 538 Length Variable 540 3 domain-type values are defined: 541 1 IPv4 Area Address 542 2 IPv6 Area Address 543 3 AS Number 545 Domain ID: With the address type 1/2 this indicates the 546 IPv4/v6 address of a neighbour area towards which the PCE can 547 compute paths. With address-type 3 this indicates the AS number 548 of a neighbour AS towards which the PCE can compute paths. When 549 coded in two octets (which is the current defined format as the 550 time of writing this document), the AS Number field MUST have 551 its first two octets set to 0. 553 The NEIG-PCE-DOMAIN sub-TLV MUST be present if the R bit is set and 554 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 555 cleared. 557 4.5. PCE-CAP-FLAGS Sub-TLV 559 The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to indicate PCE 560 capabilities. It MAY be present within the PCED TLV. It MUST NOT be 561 present more than once. If it appears more than once, only the first 562 occurrence MUST be processed and other MUST be ignored. 564 The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array 565 of units of 32 flags numbered from the most significant as bit zero, 566 where each bit represents one PCE capability. 568 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type = 5 | Length | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 // PCE Capability Flags // 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Type 5 581 Length Multiple of 4 octets 582 Value This contains an array of units of 32 bit flags 583 numbered from the most significant as bit zero, where 584 each bit represents one PCE capability. 586 IANA is requested to manage the space of the PCE Capability Flags 587 The following bits are to be assigned by IANA: 589 Bit Capabilities 591 0 Path computation with GMPLS link constraints 592 1 Bidirectional path computation 593 2 Diverse path computation 594 3 Load-balanced path computation 595 4 Synchronized paths computation 596 5 Support for multiple objective functions 597 6 Support for additive path constraints 598 (max hop count, etc.) 599 7 Support for request prioritization 600 8 Support for multiple requests per message 602 9-31 Reserved for future assignments by IANA. 604 These capabilities are defined in [RFC4657]. 606 Reserved bits SHOULD be set to zero on transmission and MUST be 607 ignored on receipt. 609 4.6. The OVERLOAD Sub-TLV 611 The OVERLOAD sub-TLV is used to indicate that a PCE is experiencing 612 a processing overload state. 614 The OVERLOAD sub-TLV is optional, it MAY be carried within the PCED 615 TLV. It MUST NOT be present more than once. If it appears more than 616 once, only the first occurrence MUST be processed and other MUST be 617 ignored. 619 The format of the OVERLOAD sub-TLV is as follows: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type = 6 | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 |C| Reserved | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Type 6 630 Length 4 631 Value 632 -C bit: When set this indicates that the PCE is overloaded 633 and cannot accept any new request. When cleared this 634 indicates that the PCE is not overloaded and can 635 accept new requests. 637 5. Elements of Procedure 639 The PCED TLV is advertised within OSPFv2 Router Information LSAs 640 (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router information 641 LSAs (function code of 12) which are defined in [OSPF-CAP]. As such, 642 elements of procedure are inherited from those defined in [OSPF-CAP]. 644 In OSPFv2 the flooding scope is controlled by the opaque LSA type (as 645 defined in [RFC2370]) and in OSPFv3 by the S1/S2 bits (as defined in 646 [RFC2740]). If the flooding scope is local to an area then the PCED 647 TLV MUST be carried within an OSPFv2 type 10 router information LSA 648 or an OSPFV3 Router Information LSA with the S1 bit set and the S2 649 bit cleared. If the flooding scope is the entire domain then the PCED 650 TLV MUST be carried within an OSPFv2 type 11 Router Information LSA 651 or OSPFv3 Router Information LSA with the S1 bit cleared and the S2 652 bit set. When only the L bit of the PATH-SCOPE sub-TLV is set, the 653 flooding scope MUST be area local. 655 An OSPF router MUST originate a new Router Information LSA whenever 656 there is a change in a PCED TLV associated with a PCE it advertises. 658 When a PCE is deactivated, the OSPF router advertising this PCE MUST 659 originate a new Router Information LSA that no longer includes the 660 corresponding PCED TLV. 662 The PCE address, i.e. the address indicated within the PCE ADDRESS 663 TLV, SHOULD be reachable via some prefixes advertised by OSPF; this 664 allows speeding up the detection of a PCE failure. Note that when the 665 PCE address is no longer reachable, this means that the PCE node has 666 failed or has been torn down, or that there is no longer IP 667 connectivity to the PCE node. 669 A change in PCED information MUST NOT trigger any SPF computation at 670 a receiving router. 672 The way PCEs determine the information they advertise is out of the 673 scope of this document. Some information may be configured on the PCE 674 (e.g., address, preferences, scope) and other information may be 675 automatically determined by the PCE (e.g., areas of visibility). 677 5.1. OVERLOAD sub-TLV Specific Procedures 679 When a PCE enters into an overload state, the conditions of which are 680 implementation dependent, a Router Information LSA with an OVERLOAD 681 sub-TLV with the C bit set MAY be generated. 683 When a PCE exits from an overload state, the conditions of which are 684 implementation dependent (e.g. CPU utilization, average queue length 685 below some pre-defined threshold), a new Router Information LSA with 686 an OVERLOAD sub-TLV with the C bit cleared SHOULD be generated, if 687 the overload information had been previously advertised. 689 A PCE implementation supporting the OSPF extensions defined in this 690 document SHOULD support an appropriate dampening algorithm so as to 691 dampen OSPF flooding of PCE Overload information in order to not 692 impact the OSPF scalability. It is RECOMMENDED to introduce some 693 hysteresis for overload state transition, so as to avoid state 694 oscillations that may impact OSPF performance. For instance two 695 thresholds MAY be configured: An upper-threshold and a lower- 696 threshold; an LSR enters the overload state when the CPU load reaches 697 the upper threshold and leaves the overload state when the CPU load 698 goes under the lower threshold. 700 Upon receipt of an updated OVERLOAD sub-TLV a PCC SHOULD take 701 appropriate actions. In particular, the PCC SHOULD stop sending 702 requests to an overloaded PCE, and SHOULD gradually start sending 703 again requests to a PCE that is no longer overloaded. 705 6. Backward Compatibility 707 The PCED TLV defined in this document does not introduce any 708 interoperability issues. 710 A router not supporting the PCED TLV will just silently ignore the 711 TLV as specified in [OSPF-CAP]. 713 7. IANA Considerations 715 7.1. OSPF TLV 717 Once the OSPF RI TLVs registry defined in [OSPF-CAP] will have been 718 assigned, IANA will assign a new TLV code-point for the PCED TLV 719 carried within the Router Information LSA. 721 Value TLV Name Reference 722 ----- -------- ---------- 723 5 PCED (this document) 725 7.2. PCE Capability Flags registry 727 This document provides new capability bit flags, which are present 728 in the PCE-CAP-FLAGS TLV referenced in section 4.1.5. 730 The IANA is requested to create a new top-level OSPF registry, the 731 "PCE Capability Flags" registry, and to manage the space of PCE 732 capability bit flags numbering them in the usual IETF notation 733 starting at zero and continuing at least through 31, with the most 734 significant bit as bit zero. 736 New bit numbers may be allocated only by an IETF Consensus action. 738 Each bit should be tracked with the following qualities: 740 - Bit number 741 - Capability Description 742 - Defining RFC 744 Several bits are defined in this document. Here are the suggested 745 values: 747 Bit Capability Description 749 0 Path computation with GMPLS link constraints 750 1 Bidirectional path computation 751 2 Diverse path computation 752 3 Load-balanced path computation 753 4 Synchronized paths computation 754 5 Support for multiple objective functions 755 6 Support for additive path constraints 756 (max hop count, etc.) 757 7 Support for request prioritization 758 8 Support for multiple requests per message 760 8. Security Considerations 762 This document defines OSPF extensions for PCE discovery within an 763 administrative domain. Hence the security of the PCE discovery relies 764 on the security of OSPF. 766 Mechanisms defined to ensure authenticity and integrity of OSPF LSAs 767 [RFC2154], and their TLVs, can be used to secure the PCE Discovery 768 information as well. 770 OSPF provides no encryption mechanism for protecting the privacy of 771 LSAs, and in particular the privacy of the PCE discovery information. 773 9. Manageability Considerations 775 Manageability considerations for PCE Discovery are addressed in 776 section 4.10 of [RFC4674]. 778 9.1. Control of Policy and Functions 780 Requirements on the configuration of PCE discovery parameters on PCCs 781 and PCEs are discussed in section 4.10.1 of [RFC4674]. 783 Particularly, a PCE implementation SHOULD allow configuring the 784 following parameters on the PCE: 785 -The PCE IPv4/IPv6 address(es) (see section 4.1.1) 786 -The PCE Scope, including the inter-domain functions (inter- 787 area, inter-AS, inter-layer), the preferences, and whether the 788 PCE can act as default PCE (see section 4.1.2) 789 -The PCE domains (see section 4.1.3) 790 -The neighbour PCE domains (see section 4.1.4) 791 -The PCE capabilities (see section 4.1.5) 793 9.2. Information and Data Model 795 A MIB module for PCE Discovery is defined in [PCED-MIB]. 797 9.3. Liveness Detection and Monitoring 799 PCE Discovery Protocol liveness detection relies upon OSPF liveness 800 detection. OSPF already includes a liveness detection mechanism 801 (Hello protocol), and PCE discovery does not require additional 802 capabilities. 804 Procedures defined in section 5.1 allow a PCC detecting when a PCE 805 has been deactivated, or is no longer reachable. 807 9.4. Verify Correct Operations 809 The correlation of information advertised against information 810 received can be achieved by comparing the PCED information in the PCC 811 and in the PCE, which is stored in the PCED MIB [PCED-MIB]. The 812 number of dropped, corrupt, and rejected information elements are 813 stored in the PCED MIB. 815 9.5. Requirements on Other Protocols and Functional Components 817 The OSPF extensions defined in this document do not imply any 818 requirement on other protocols. 820 9.6. Impact on network operations 822 Frequent changes in PCE information, and particularly in PCE overload 823 information, may have a significant impact on OSPF and might 824 destabilize the operation of the network by causing the PCCs to swap 825 between PCEs. 827 As discussed in section 5.1, a PCE implementation SHOULD support an 828 appropriate dampening algorithm so as to dampen OSPF flooding in 829 order to not impact the OSPF scalability. 831 Also, as discussed in section 4.10.4 of [RFC4674], it MUST be 832 possible to apply at least the following controls: 834 - Configurable limit on the rate of announcement of changed 835 parameters at a PCE. 836 - Control of the impact on PCCs such as through discovery messages 837 rate-limiting. 838 - Configurable control of triggers that cause a PCC to swap to 839 another PCE. 841 10. Acknowledgments 843 We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike 844 Shand and Lou Berger for their useful comments and suggestions. 846 We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, and 847 Tim Polk for their comments during the final stages of publication. 849 11. References 851 11.1. Normative references 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, March 1997. 856 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 857 RFC 2740, December 1999. 859 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 860 1998. 862 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 863 Extensions to OSPF Version 2", RFC 3630, September 2003. 865 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 866 J.P., "Extensions to OSPF for advertising Optional Router 867 Capabilities", draft-ietf-ospf-cap, work in progress. 869 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 870 Digital Signatures", RFC 2154, June 1997. 872 11.2. Informative references 874 [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic 875 Requirements", RFC4657, September 2006. 877 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 878 communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work 879 in progress. 881 [PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path 882 Computation Element Discovery", draft-ietf-pce-disc-mib, work in 883 progress. 885 [PCED-ISIS] Le Roux, Vasseur, et al. "IS-IS protocol extensions for 886 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 887 proto-isis, work in progress. 889 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 890 Element (PCE)-based Architecture", RFC4655, August 2006. 892 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 893 RFC4674, October 2006. 895 12. Editor's Addresses 897 Jean-Louis Le Roux (Editor) 898 France Telecom 899 2, avenue Pierre-Marzin 900 22307 Lannion Cedex 901 FRANCE 902 Email: jeanlouis.leroux@orange-ftgroup.com 904 Jean-Philippe Vasseur (Editor) 905 Cisco Systems, Inc. 906 1414 Massachusetts avenue 907 Boxborough , MA - 01719 908 USA 909 Email: jpv@cisco.com 911 13. Contributors' Addresses 913 Yuichi Ikejiri 914 NTT Communications Corporation 915 1-1-6, Uchisaiwai-cho, Chiyoda-ku 916 Tokyo 100-8019 917 JAPAN 918 Email: y.ikejiri@ntt.com 920 Raymond Zhang 921 BT Infonet 922 2160 E. Grand Ave. 923 El Segundo, CA 90025 924 USA 925 Email: raymond_zhang@bt.infonet.com 927 14. Intellectual Property Statement 929 The IETF takes no position regarding the validity or scope of any 930 Intellectual Property Rights or other rights that might be claimed to 931 pertain to the implementation or use of the technology described in 932 this document or the extent to which any license under such rights 933 might or might not be available; nor does it represent that it has 934 made any independent effort to identify any such rights. Information 935 on the procedures with respect to rights in RFC documents can be 936 found in BCP 78 and BCP 79. 938 Copies of IPR disclosures made to the IETF Secretariat and any 939 assurances of licenses to be made available, or the result of an 940 attempt made to obtain a general license or permission for the use of 941 such proprietary rights by implementers or users of this 942 specification can be obtained from the IETF on-line IPR repository at 943 http://www.ietf.org/ipr. 945 The IETF invites any interested party to bring to its attention any 946 copyrights, patents or patent applications, or other proprietary 947 rights that may cover technology that may be required to implement 948 this standard. Please address the information to the IETF at 949 ietf-ipr@ietf.org. 951 Disclaimer of Validity 953 This document and the information contained herein are provided 954 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 955 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 956 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 957 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 958 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 959 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 960 FOR A PARTICULAR PURPOSE. 962 Copyright Statement 964 Copyright (C) The IETF Trust (2007). This document is subject to the 965 rights, licenses and restrictions contained in BCP 78, and except as 966 set forth therein, the authors retain all their rights.