idnits 2.17.1 draft-ietf-pce-disco-proto-ospf-08.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 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 875. 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 -- 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 (October 2007) is 6037 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 811, 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 (~~), 2 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: April 2008 J.P. Vasseur (Editor) 6 Cisco System Inc. 8 Yuichi Ikejiri 9 NTT Communications 11 Raymond Zhang 12 BT Infonet 14 October 2007 16 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-ospf-08.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 (PCEs), 52 along with information that can be used by the PCC for PCE selection. 53 When 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 announce 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 Discovery Information...................................5 73 3.2. Flooding Scope..............................................5 74 4. The OSPF PCED TLV...........................................6 75 4.1. PCE-ADDRESS Sub-TLV.........................................7 76 4.2. PATH-SCOPE Sub-TLV..........................................8 77 4.3. PCE-DOMAIN Sub-TLV.........................................10 78 4.4. NEIG-PCE-DOMAIN Sub-TLV....................................11 79 4.5. PCE-CAP-FLAGS Sub-TLV......................................11 80 5. Elements of Procedure......................................13 81 6. Backward Compatibility.....................................13 82 7. IANA Considerations........................................14 83 7.1. OSPF TLV...................................................14 84 7.2. PCE Capability Flags registry..............................14 85 8. Security Considerations....................................15 86 9. Manageability Considerations...............................15 87 9.1. Control of Policy and Functions............................15 88 9.2. Information and Data Model.................................15 89 9.3. Liveness Detection and Monitoring..........................15 90 9.4. Verify Correct Operations..................................16 91 9.5. Requirements on Other Protocols and Functional 92 Components...............................................16 93 9.6. Impact on Network Operations...............................16 94 10. Acknowledgments............................................16 95 11. References.................................................16 96 11.1. Normative References.......................................16 97 11.2. Informative References.....................................17 98 12. Editor's Addresses.........................................17 99 13. Contributors' Addresses....................................18 100 14. Intellectual Property Statement............................18 102 1. Terminology 104 ABR: OSPF Area Border Router. 106 AS: Autonomous System. 108 IGP: Interior Gateway Protocol. Either of the two routing 109 protocols Open Shortest Path First (OSPF) or Intermediate System 110 to Intermediate System (ISIS). 112 Intra-area TE LSP: A TE LSP whose path does not cross an IGP area 113 boundary. 115 Intra-AS TE LSP: A TE LSP whose path does not cross an AS 116 boundary. 118 Inter-area TE LSP: A TE LSP whose path transits two or more IGP 119 areas. That is a TE LSP that crosses at least one IGP area 120 boundary. 122 Inter-AS TE LSP: A TE LSP whose path transits two or more 123 ASes or sub-ASes (BGP confederations). That is a TE LSP that 124 crosses at least one AS boundary. 126 LSA: Link State Advertisement. 128 LSR: Label Switching Router. 130 PCC: Path Computation Client. Any client application requesting a 131 path computation to be performed by a Path Computation Element. 133 PCE: Path Computation Element. An entity (component, application, 134 or network node) that is capable of computing a network path or 135 route based on a network graph, and applying computational 136 constraints. 138 PCE-Domain: In a PCE context this refers to any collection of 139 network elements within a common sphere of address management or 140 path computational responsibility (referred to as a "domain" in 141 [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. 142 This should be distinguished from an OSPF routing domain. 144 PCEP: Path Computation Element Protocol. 146 TE LSP: Traffic Engineered Label Switched Path. 148 2. Introduction 150 [RFC4655] describes the motivations and architecture for a Path 151 Computation Element (PCE)-based 152 path computation model for Multi-Protocol Label Switching (MPLS) and 153 Generalized MPLS (GMPLS) Traffic Engineered Label Switched Paths (TE 154 LSPs). The model allows for the separation of the PCE from a Path 155 Computation Client (PCC) (also referred to as a non co-located PCE) 156 and allows for cooperation between PCEs (where one PCE acts as a PCC 157 to make requests of the other PCE). This relies on a communication 158 protocol between PCC and PCE, and also between PCEs. The requirements 159 for such a communication protocol can be found in [RFC4657], and the 160 communication protocol is defined in [PCEP]. 162 The PCE architecture requires that a PCC be aware of the location of 163 one or more PCEs in its domain, and also, potentially, of PCEs in 164 other domains, e.g., in the case of inter-domain TE LSP computation. 166 A network may contain a large number of PCEs, each with potentially 167 distinct capabilities. In such a context it is highly desirable to 168 have a mechanism for automatic and dynamic PCE discovery that allows 169 PCCs to automatically discover a set of PCEs along with additional 170 information about each PCE that may be used by a PCC to perform PCE 171 selection. Additionally, it is valuable for a PCC to dynamically 172 detect new PCEs, failed PCEs, or any modification to the PCE 173 information. Detailed requirements for such a PCE discovery mechanism 174 are provided in [RFC4674]. 176 Note that the PCE selection algorithm applied by a PCC is out of the 177 scope of this document. 179 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 180 are either LSRs or servers also participating in the IGP, an 181 effective mechanism for PCE discovery within an IGP routing domain 182 consists of utilizing IGP advertisements. 184 This document defines extensions to OSPFv2 [RFC2328] and OSPFv3 185 [RFC2740] to allow a PCE in an OSPF routing domain to advertise its 186 location along with some information useful to a PCC for PCE 187 selection so as to satisfy dynamic PCE discovery requirements set 188 forth in [RFC4674]. 190 Generic capability advertisement mechanisms for OSPF are defined in 191 [OSPF-CAP]. These allow a router to advertise its capabilities within 192 an OSPF area or an entire OSPF routing domain. This document 193 leverages this generic capability advertisement mechanism to fully 194 satisfy the dynamic PCE discovery requirements. 196 This document defines a new TLV (named the PCE Discovery (PCED) TLV) 197 to be carried within the OSPF Router Information LSA ([OSPF-CAP]). 199 The PCE information advertised is detailed in Section 3. Protocol 200 extensions and procedures are defined in Sections 4 and 5. 202 The OSPF extensions defined in this document allow for PCE discovery 203 within an OSPF routing domain. Solutions for PCE discovery across AS 204 boundaries are beyond the scope of this document, and for further 205 study. 207 3. Overview 209 3.1. PCE Discovery Information 211 The PCE discovery information is composed of: 213 - The PCE location: an IPv4 and/or IPv6 address that is used to reach 214 the PCE. It is RECOMMENDED to use an address that is always 215 reachable if there is any connectivity to the PCE; 217 - The PCE path computation scope (i.e., intra-area, inter-area, 218 inter-AS, or inter-layer); 220 - The set of one or more PCE-Domain(s) into which the PCE has 221 visibility and for which the PCE can compute paths; 223 - The set of zero, one or more neighbor PCE-Domain(s) toward which 224 the PCE can compute paths; 226 - A set of communication capabilities (e.g., support for request 227 prioritization) and path computation-specific capabilities 228 (e.g., supported constraints). 230 PCE discovery information is by nature fairly static and does not 231 change with PCE activity. Changes in PCE discovery information may 232 occur as a result of PCE configuration updates, PCE 233 deployment/activation, PCE deactivation/suppression, or PCE failure. 234 Hence, this information is not expected to change frequently. 236 3.2. Flooding Scope 238 The flooding scope for PCE information advertised through OSPF can be 239 limited to one or more OSPF areas the PCE belongs to, or can be 240 extended across the entire OSPF routing domain. 242 Note that some PCEs may belong to multiple areas, in which case the 243 flooding scope may comprise these areas. This could be the case for 244 an ABR, for instance, advertising its PCE information within the 245 backbone area and/or a subset of its attached IGP area(s). 247 4. The OSPF PCED TLV 249 The OSPF PCE Discovery TLV (PCED TLV) contains non-ordered set of 250 sub-TLVs. 252 The format of the OSPF PCED TLV and its sub-TLVs is identical to the 253 TLV format used by the Traffic Engineering Extensions to OSPF 254 [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 255 octets specifying the TLV length, and a value field. The Length field 256 defines the length of the value portion in octets. 258 The TLV is padded to four-octet alignment; padding is not included in 259 the Length field (so a three octet value would have a length of 260 three, but the total size of the TLV would be eight octets). Nested 261 TLVs are also four-octet aligned. Unrecognized types are ignored. 263 The OSPF PCED TLV has the following format: 265 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 // sub-TLVs // 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Type To be defined by IANA (suggested value=5) 276 Length Variable 277 Value This comprises one or more sub-TLVs 279 Five sub-TLVs are defined: 280 Sub-TLV type Length Name 281 1 variable PCE-ADDRESS sub-TLV 282 2 4 PATH-SCOPE sub-TLV 283 3 4 PCE-DOMAIN sub-TLV 284 4 4 NEIG-PCE-DOMAIN sub-TLV 285 5 variable PCE-CAP-FLAGS sub-TLV 287 The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within 288 the PCED TLV. 290 The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They MAY be 291 present in the PCED TLV to facilitate selection of inter-domain PCEs. 293 The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED 294 TLV to facilitate the PCE selection process. 296 Malformed PCED TLVs or sub-TLVs not explicitly described in this 297 document MUST cause the LSA to be treated as malformed according to 298 the normal procedures of OSPF. 300 Any unrecognized sub-TLV MUST be silently ignored. 302 The PCED TLV is carried within an OSPF Router Information LSA 303 defined in [OSPF-CAP]. 305 No additional sub-TLVs will be added to the PCED TLV in the future. 306 If a future application requires the advertisement of additional PCE 307 information in OSPF, this will not be carried in the Router 308 Information LSA. 310 The following sub-sections describe the sub-TLVs which may be carried 311 within the PCED sub-TLV. 313 4.1. PCE-ADDRESS Sub-TLV 315 The PCE-ADDRESS sub-TLV specifies an IP address that can be 316 used to reach the PCE. It is RECOMMENDED to make use of an address 317 that is always reachable, provided that the PCE is alive and 318 reachable. 320 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 321 PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and IPv6 322 address. It MUST NOT appear more than once for the same address type. 323 If it appears more than once, only the first occurrence is processed 324 and any others MUST be ignored. 326 The format of the PCE-ADDRESS sub-TLV is as follows: 328 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type = 1 | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | address-type | Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 // PCE IP Address // 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 PCE-ADDRESS sub-TLV format 342 Type 1 343 Length 8 (IPv4) or 20 (IPv6) 345 Address-type: 347 1 IPv4 348 2 IPv6 350 Reserved: SHOULD be set to zero on transmission and MUST be 351 ignored on receipt. 353 PCE IP Address: The IP address to be used to reach the PCE. 355 4.2. PATH-SCOPE Sub-TLV 357 The PATH-SCOPE sub-TLV indicates the PCE path computation scope, 358 which refers to the PCE's ability to compute or take part in the 359 computation of paths for intra-area, inter-area, inter-AS, or inter- 360 layer_TE LSPs. 362 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 363 PCED TLV. There MUST be exactly one instance of the PATH-SCOPE sub- 364 TLV within each PCED TLV. If it appears more than once, only the 365 first occurrence is processed and any others MUST be ignored. 367 The PATH-SCOPE sub-TLV contains a set of bit-flags indicating the 368 supported path scopes, and four fields indicating PCE preferences. 370 The PATH-SCOPE sub-TLV has the following format: 372 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type = 2 | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Type 2 381 Length 4 382 Value This comprises a 2-octet flag field where each bit 383 represents a supported path scope, as well as four 384 preference fields used to specify PCE preferences. 386 The following bits are defined: 388 Bit Path Scope 390 0 L bit: Can compute intra-area paths 391 1 R bit: Can act as PCE for inter-area TE LSP 392 computation 393 2 Rd bit: Can act as a default PCE for inter-area TE LSP 394 computation 395 3 S bit: Can act as PCE for inter-AS TE LSP computation 396 4 Sd bit: Can act as a default PCE for inter-AS TE LSP 397 computation 398 5 Y bit: Can compute or take part into the computation 399 of paths across layers. 401 PrefL field: PCE's preference for intra-area TE LSPs 402 computation. 404 PrefR field: PCE's preference for inter-area TE LSPs 405 computation. 407 PrefS field: PCE's preference for inter-AS TE LSPs 408 computation. 410 PrefY field: PCE's preference for inter-layer TE LSPs 411 computation. 413 Res: Reserved for future use. 415 The L, R, S, and Y bits are set when the PCE can act as a PCE for 416 intra-area, inter-area, inter-AS, or inter-layer TE LSPs computation 417 respectively. These bits are non-exclusive. 419 When set, the Rd bit indicates that the PCE can act as a default PCE 420 for inter-area TE LSPs computation (that is, the PCE can compute a 421 path toward any neighbor area). Similarly, when set, the Sd bit 422 indicates that the PCE can act as a default PCE for inter-AS TE LSP 423 computation (the PCE can compute a path toward any neighbor AS). 425 When the Rd and Sd bit are set the PCED TLV MUST NOT contain a NEIG- 426 PCE-DOMAIN sub-TLV (see Section 4.1.4). 428 When the R bit is clear, the Rd bit SHOULD be clear on transmission 429 and MUST be ignore on receipt. When the S bit is clear, the Sd bit 430 SHOULD be clear on transmission and MUST be ignored on receipt. 432 The PrefL, PrefR, PrefS, and PrefY fields are each three bits long 433 and allow the PCE to specify a preference for each computation scope, 434 where 7 reflects the highest preference. Such preferences can be used 435 for weighted load balancing of path computation requests. An operator 436 may decide to configure a preference for each computation scope at 437 each PCE so as to balance the path computation load among them. The 438 algorithms used by a PCC to load balance its path computation 439 requests according to such PCE preferences is out of the scope of 440 this document and is a matter for local or network-wide policy. The 441 same or different preferences may be used for each scope. For 442 instance, an operator that wants a PCE capable of both inter-area and 443 inter-AS computation to be prefered for use for inter-AS computations 444 may configure PrefS higher than PrefR. 446 When the L, R, S, or Y bits are cleared, the PrefL, PrefR, PrefS, and 447 PrefY fields SHOULD respectively be set to 0 on transmission and MUST 448 be ignored on receipt. 450 Both reserved fields SHOULD be set to zero on transmission and MUST 451 be ignored on receipt. 453 4.3. PCE-DOMAIN Sub-TLV 455 The PCE-DOMAIN sub-TLV specifies a PCE-Domain (area or AS) where the 456 PCE has topology visibility and through which the PCE can compute 457 paths. 459 The PCE-DOMAIN sub-TLV SHOULD be present when PCE-Domains for which 460 the PCE can operate cannot be inferred by other IGP information, for 461 instance when the PCE is inter-domain capable (i.e., when the R bit 462 or S bit is set) and the flooding scope is the entire routing domain 463 (see Section 5 for a discussion of how the flooding scope is set and 464 interpreted). 466 A PCED TLV may include multiple PCE-DOMAIN sub-TLVs when the PCE has 467 visibility into multiple PCE-Domains. 469 The PCE-DOMAIN sub-TLV has the following format: 471 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type=3 | Length | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Domain-type | Reserved | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Domain ID | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 PCE-DOMAIN sub-TLV format 483 Type 3 484 Length 8 486 Two domain-type values are defined: 487 1 OSPF Area ID 488 2 AS Number 490 Domain ID: With the domain-type set to 1, this indicates the 32 491 bit Area ID of an area where the PCE has visibility and can 492 compute paths. With domain-type set to 2, this indicates an AS 493 number of an AS where the PCE has visibility and can compute 494 paths. When the AS number is coded in two octets, the AS Number 495 field MUST have its first two octets set to 0. 496 . 498 4.4. NEIG-PCE-DOMAIN Sub-TLV 500 The NEIG-PCE-DOMAIN sub-TLV specifies a neighbor PCE-domain (area or 501 AS) toward which a PCE can compute paths. It means that the PCE can 502 take part in the computation of inter-domain TE LSPs with paths that 503 transit this neighbor PCE-domain. 505 A PCED sub-TLV may include several NEIG-PCE-DOMAIN sub-TLVs when the 506 PCE can compute paths towards several neighbour PCE-domains. 508 The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN 509 sub-TLV: 511 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type = 4 | Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Domain-type | Reserved | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Domain ID | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 NEIG-PCE-DOMAIN sub-TLV format 523 Type 4 524 Length 8 526 Two domain-type values are defined: 527 1 OSPF Area ID 528 2 AS Number 530 Domain ID: With the domain-type set to 1, this indicates the 32 531 bit Area ID of a neighbour area toward which the PCE can 532 compute paths. With domain-type set to 2, this indicates the AS 533 number of a neighbor AS toward which the PCE can compute paths. 534 When the AS number is coded in two octets, the AS Number field 535 MUST have its first two octets set to 0. 537 The NEIG-PCE-DOMAIN sub-TLV MUST be present at least once with 538 domain-type set to 1 if the R bit is set and the Rd bit is cleared, 539 and MUST be present at least once with domain-type set to 2 if the S 540 bit is set and the Sd bit is cleared. 542 4.5. PCE-CAP-FLAGS Sub-TLV 544 The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to indicate PCE 545 capabilities. It MAY be present within the PCED TLV. It MUST NOT be 546 present more than once. If it appears more than once, only the first 547 occurrence is processed and any others MUST be ignored. 549 The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array 550 of units of 32 bit-flags numbered from the most significant bit as 551 bit zero, where each bit represents one PCE capability. 553 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type = 5 | Length | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | 561 // PCE Capability Flags // 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Type 5 566 Length Multiple of 4 octets 567 Value This contains an array of units of 32 bit flags 568 numbered from the most significant as bit zero, where 569 each bit represents one PCE capability. 571 IANA is requested to manage the space of the PCE Capability Flags 573 The following bits are to be assigned by IANA: 575 Bit Capabilities 577 0 Path computation with GMPLS link constraints 578 1 Bidirectional path computation 579 2 Diverse path computation 580 3 Load-balanced path computation 581 4 Synchronized path computation 582 5 Support for multiple objective functions 583 6 Support for additive path constraints 584 (max hop count, etc.) 585 7 Support for request prioritization 586 8 Support for multiple requests per message 588 9-31 Reserved for future assignments by IANA. 590 These capabilities are defined in [RFC4657]. 592 Reserved bits SHOULD be set to zero on transmission and MUST be 593 ignored on receipt. 595 5. Elements of Procedure 597 The PCED TLV is advertised within OSPFv2 Router Information LSAs 598 (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router Information 599 LSAs (function code of 12) which are defined in [OSPF-CAP]. As such, 600 elements of procedure are inherited from those defined in [OSPF-CAP]. 602 In OSPFv2 the flooding scope is controlled by the opaque LSA type (as 603 defined in [RFC2370]) and in OSPFv3 by the S1/S2 bits (as defined in 604 [RFC2740]). If the flooding scope is local to an area then the PCED 605 TLV MUST be carried within an OSPFv2 type 10 router information LSA 606 or an OSPFV3 Router Information LSA with the S1 bit set and the S2 607 bit clear. If the flooding scope is the entire IGP domain then the 608 PCED TLV MUST be carried within an OSPFv2 type 11 Router Information 609 LSA or OSPFv3 Router Information LSA with the S1 bit clear and the S2 610 bit set. When only the L bit of the PATH-SCOPE sub-TLV is set, the 611 flooding scope MUST be area local. 613 When the PCE function is deactivated, the OSPF speaker advertising 614 this PCE MUST originate a new Router Information LSA that no longer 615 includes the corresponding PCED TLV, provided there are other TLVs in 616 the LSA. If there are no other TLVs in the LSA, it MUST either send 617 an empty Router Information LSA or purge it by prematurely aging it. 619 The PCE address (i.e., the address indicated within the PCE ADDRESS 620 TLV) SHOULD be reachable via some prefixes advertised by OSPF. This 621 allows the detection of a PCE failure to be sped up. When the PCE 622 address is no longer reachable, the PCE node has failed, has been 623 torn down, or there is no longer IP connectivity to the PCE. 625 A change in information in the PCED TLV MUST NOT trigger any SPF 626 computation at a receiving router. 628 The way PCEs determine the information they advertise is out of the 629 scope of this document. Some information may be configured on the PCE 630 (e.g., address, preferences, scope) and other information may be 631 automatically determined by the PCE (e.g., areas of visibility). 633 6. Backward Compatibility 635 The PCED TLV defined in this document does not introduce any 636 interoperability issues. 638 A router not supporting the PCED TLV will just silently ignore the 639 TLV as specified in [OSPF-CAP]. 641 7. IANA Considerations 643 7.1. OSPF TLV 645 IANA has defined a registry for TLVs carried in the Router 646 Information LSA defined in [OSPF-CAP]. IANA is requested to assign a 647 new TLV code-point for the PCED TLV carried within the Router 648 Information LSA. 650 Value TLV Name Reference 651 ----- -------- ---------- 652 5 PCED (this document) 654 7.2. PCE Capability Flags registry 656 This document provides new capability bit flags, which are present 657 in the PCE-CAP-FLAGS TLV referenced in section 4.1.5. 659 The IANA is requested to create a new top-level OSPF registry, the 660 "PCE Capability Flags" registry, and to manage the space of PCE 661 capability bit flags numbering them in the usual IETF notation 662 starting at zero and continuing at least through 31, with the most 663 significant bit as bit zero. 665 New bit numbers may be allocated only by an IETF Consensus action. 667 Each bit should be tracked with the following qualities: 669 - Bit number 670 - Capability Description 671 - Defining RFC 673 Several bits are defined in this document. Here are the suggested 674 values: 676 Bit Capability Description 678 0 Path computation with GMPLS link constraints 679 1 Bidirectional path computation 680 2 Diverse path computation 681 3 Load-balanced path computation 682 4 Synchronized paths computation 683 5 Support for multiple objective functions 684 6 Support for additive path constraints 685 (max hop count, etc.) 686 7 Support for request prioritization 687 8 Support for multiple requests per message 689 8. Security Considerations 691 This document defines OSPF extensions for PCE discovery within an 692 administrative domain. Hence the security of the PCE discovery relies 693 on the security of OSPF. 695 Mechanisms defined to ensure authenticity and integrity of OSPF LSAs 696 [RFC2154], and their TLVs, can be used to secure the PCE Discovery 697 information as well. 699 OSPF provides no encryption mechanism for protecting the privacy of 700 LSAs, and in particular the privacy of the PCE discovery information. 702 9. Manageability Considerations 704 Manageability considerations for PCE Discovery are addressed in 705 Section 4.10 of [RFC4674]. 707 9.1. Control of Policy and Functions 709 Requirements for the configuration of PCE discovery parameters on 710 PCCs and PCEs are discussed in Section 4.10.1 of [RFC4674]. 712 In particular, a PCE implementation SHOULD allow the following 713 parameters to be configured on the PCE: 714 - The PCE IPv4/IPv6 address(es) (see Section 4.1) 715 - The PCE Scope, including the inter-domain functions (inter- 716 area, inter-AS, inter-layer), the preferences, and whether the 717 PCE can act as default PCE (see Section 4.2) 718 - The PCE domains (see Section 4.3) 719 - The neighbour PCE domains (see Section 4.4) 720 - The PCE capabilities (see Section 4.5) 722 9.2. Information and Data Model 724 A MIB module for PCE Discovery is defined in [PCED-MIB]. 726 9.3. Liveness Detection and Monitoring 728 PCE Discovery Protocol liveness detection relies upon OSPF liveness 729 detection. OSPF already includes a liveness detection mechanism 730 (Hello protocol), and PCE discovery does not require additional 731 capabilities. 733 Procedures defined in Section 5 allow a PCC to detect when a PCE has 734 been deactivated, or is no longer reachable. 736 9.4. Verify Correct Operations 738 The correlation of information advertised against information 739 received can be achieved by comparing the information in the PCED TLV 740 received by the PCC with that stored at the PCE using the PCED MIB 741 [PCED-MIB]. The number of dropped, corrupt, and rejected information 742 elements are available through the PCED MIB. 744 9.5. Requirements on Other Protocols and Functional Components 746 The OSPF extensions defined in this document do not imply any 747 requirement on other protocols. 749 9.6. Impact on Network Operations 751 Frequent changes in PCE information advertised in the PCED TLV, may 752 have a significant impact on OSPF and might destabilize the operation 753 of the network by causing the PCCs to swap between PCEs. 755 As discussed in Section 4.10.4 of [RFC4674], it MUST be possible to 756 apply at least the following controls: 758 - Configurable limit on the rate of announcement of changed 759 parameters at a PCE. 760 - Control of the impact on PCCs such as through rate-limiting 761 the processing of PCED TLVs. 762 - Configurable control of triggers that cause a PCC to swap to 763 another PCE. 765 10. Acknowledgments 767 We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike 768 Shand, and Lou Berger for their useful comments and suggestions. 770 We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, and 771 Tim Polk for their comments during the final stages of publication. 773 11. References 775 11.1. Normative References 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, March 1997. 780 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 782 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 783 RFC 2740, December 1999. 785 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 786 1998. 788 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 789 Extensions to OSPF Version 2", RFC 3630, September 2003. 791 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 792 J.P., "Extensions to OSPF for advertising Optional Router 793 Capabilities", draft-ietf-ospf-cap, work in progress. 795 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 796 Digital Signatures", RFC 2154, June 1997. 798 11.2. Informative References 800 [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic 801 Requirements", RFC4657, September 2006. 803 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 804 communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work 805 in progress. 807 [PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path 808 Computation Element Discovery", draft-ietf-pce-disc-mib, work in 809 progress. 811 [PCED-ISIS] Le Roux, Vasseur, et al. "IS-IS protocol extensions for 812 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 813 proto-isis, work in progress. 815 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 816 Element (PCE)-based Architecture", RFC4655, August 2006. 818 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 819 RFC4674, October 2006. 821 12. Editor's Addresses 823 Jean-Louis Le Roux (Editor) 824 France Telecom 825 2, avenue Pierre-Marzin 826 22307 Lannion Cedex 827 FRANCE 828 Email: jeanlouis.leroux@orange-ftgroup.com 830 Jean-Philippe Vasseur (Editor) 831 Cisco Systems, Inc. 832 1414 Massachusetts avenue 833 Boxborough , MA - 01719 834 USA 835 Email: jpv@cisco.com 837 13. Contributors' Addresses 839 Yuichi Ikejiri 840 NTT Communications Corporation 841 1-1-6, Uchisaiwai-cho, Chiyoda-ku 842 Tokyo 100-8019 843 JAPAN 844 Email: y.ikejiri@ntt.com 846 Raymond Zhang 847 BT Infonet 848 2160 E. Grand Ave. 849 El Segundo, CA 90025 850 USA 851 Email: raymond_zhang@bt.infonet.com 853 14. Intellectual Property Statement 855 The IETF takes no position regarding the validity or scope of any 856 Intellectual Property Rights or other rights that might be claimed to 857 pertain to the implementation or use of the technology described in 858 this document or the extent to which any license under such rights 859 might or might not be available; nor does it represent that it has 860 made any independent effort to identify any such rights. Information 861 on the procedures with respect to rights in RFC documents can be 862 found in BCP 78 and BCP 79. 864 Copies of IPR disclosures made to the IETF Secretariat and any 865 assurances of licenses to be made available, or the result of an 866 attempt made to obtain a general license or permission for the use of 867 such proprietary rights by implementers or users of this 868 specification can be obtained from the IETF on-line IPR repository at 869 http://www.ietf.org/ipr. 871 The IETF invites any interested party to bring to its attention any 872 copyrights, patents or patent applications, or other proprietary 873 rights that may cover technology that may be required to implement 874 this standard. Please address the information to the IETF at 875 ietf-ipr@ietf.org. 877 Disclaimer of Validity 879 This document and the information contained herein are provided 880 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 881 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 882 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 883 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 884 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 885 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 886 FOR A PARTICULAR PURPOSE. 888 Copyright Statement 890 Copyright (C) The IETF Trust (2007). This document is subject to the 891 rights, licenses and restrictions contained in BCP 78, and except as 892 set forth therein, the authors retain all their rights.