idnits 2.17.1 draft-ietf-pce-disco-proto-igp-01.txt: -(471): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1020): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1428): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1463): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1519. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 11 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Procedures for a PCE to move from a processing congested state to a non congested state are beyond the scope of this document, but the rate at which a PCE Status change is advertised MUST not impact by any mean the IGP scalability. Particular attention should be given on procedures to avoid state oscillations. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that a change in PCED information MUST not trigger any SPF computation. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that a change in PCED information MUST not trigger any SPF computation. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISIS-CAP' is mentioned on line 1248, but not defined == Missing Reference: 'PCE-DISC-REQ' is mentioned on line 202, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 875, but not defined == Unused Reference: 'RFC2119' is defined on line 1417, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 1423, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 1434, but no explicit reference was found in the text == Unused Reference: 'IS-IS-TE' is defined on line 1440, but no explicit reference was found in the text == Unused Reference: 'IS-IS-CAP' is defined on line 1447, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) ** Downref: Normative reference to an Informational draft: draft-ietf-pce-architecture (ref. 'PCE-ARCH') ** Downref: Normative reference to an Informational draft: draft-ietf-pce-discovery-reqs (ref. 'PCE-DISCO-REQ') == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-01 Summary: 10 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux (Editor) 3 Internet Draft France Telecom 4 Category: Standard Track 5 Expires: September 2006 J.P. Vasseur (Editor) 6 Cisco System Inc. 8 Yuichi Ikejiri 9 NTT Communications 11 Raymond Zhang 12 BT Infonet 14 March 2006 16 IGP protocol extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-igp-01.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet- Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 There are various circumstances in which it is highly desirable for a 45 Path Computation Client (PCC) to be able to dynamically and 46 automatically discover a set of Path Computation Element(s) (PCE), 47 along with some of information that can used for PCE selection. When 48 the PCE is an LSR participating to the IGP, or even a server 49 participating passively to the IGP, a simple and efficient way for 50 PCE discovery consists of relying on IGP flooding. For that purpose 51 this document defines OSPF and ISIS extensions for the advertisement 52 of PCE Discovery information within an IGP area or the entire routing 53 domain. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119. 61 Table of Contents 63 1. Note........................................................3 64 2. Terminology.................................................3 65 3. Introduction................................................4 66 4. Overview....................................................5 67 4.1. PCE Information.............................................5 68 4.1.1. PCE Discovery Information...................................5 69 4.1.2. PCE Status Information......................................6 70 4.2. Flooding scope..............................................6 71 5. OSPF extensions.............................................6 72 5.1. The OSPF PCED TLV...........................................6 73 5.1.1. PCE-ADDRESS sub-TLV.........................................8 74 5.1.2. PATH-SCOPE sub-TLV..........................................8 75 5.1.3. PCE-DOMAINS sub-TLV........................................10 76 5.1.3.1. IPv4 area ID DOMAIN sub-TLV..............................11 77 5.1.3.2. IPv6 area ID DOMAIN sub-TLV..............................11 78 5.1.3.3. AS Number sub-TLV........................................12 79 5.1.4. PCE-DEST-DOMAINS sub-TLV...................................12 80 5.1.5. GENERAL-CAP sub-TLV........................................13 81 5.1.6. The PATH-COMP-CAP sub-TLV..................................14 82 5.2. The OSPF PCES TLV..........................................15 83 5.2.1. The CONGESTION sub-TLV.....................................16 84 5.3. Elements of Procedure......................................16 85 5.3.1. PCED TLV Procedure.........................................17 86 5.3.2. PCES TLV procedure.........................................17 87 6. ISIS extensions............................................19 88 6.1. IS-IS PCED TLV format......................................19 89 6.1.1. PCE-ADDRESS sub-TLV........................................20 90 6.1.2. The PATH-SCOPE sub-TLV.....................................20 91 6.1.3. PCE-DOMAINS sub-TLV........................................22 92 6.1.3.1. Area ID DOMAIN sub-TLV...................................22 93 6.1.3.2. AS Number DOMAIN sub-TLV.................................23 94 6.1.4. PCE-DEST-DOMAINS sub-TLV...................................23 95 6.1.5. GENERAL-CAP sub-TLV........................................23 96 6.1.6. The PATH-COMP-CAP sub-TLV..................................24 97 6.2. The ISIS PCES TLV..........................................25 98 6.2.1. The CONGESTION sub-TLV.....................................25 99 6.3. Elements of Procedure......................................26 100 6.3.1. PCED TLV Procedure.........................................26 101 6.3.2. PCES TLV procedure.........................................27 102 7. Backward compatibility.....................................27 103 8. IANA considerations........................................28 104 8.1. OSPF TLVs..................................................28 105 8.2. ISIS TLVs..................................................28 106 8.3. Capability bits............................................29 107 9. Security Considerations....................................29 108 10. References.................................................29 109 10.1. Normative references........................................29 110 10.2. Informative references......................................30 111 11. Authors' Addresses:........................................30 112 12. Intellectual Property Statement............................31 114 1. Note 116 This document specifies new TLVs and sub-TLVs to be carried within 117 the OSPF Router information LSA ([OSPF-CAP]) and ISIS Router 118 Capability TLV ([ISIS-CAP]) respectively. Because this document does 119 not introduce any new element of procedure it will be discussed 120 within the PCE Working Group with a review of the OSPF and ISIS 121 Working Groups. Furthermore, once stabilized, it may be decided to 122 split the document in two documents addressing the OSPF and ISIS 123 aspects respectively. 125 2. Terminology 127 Terminology used in this document 129 ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router). 131 AS: Autonomous System. 133 ASBR: AS Border Router. 135 Domain: any collection of network elements within a common sphere 136 of address management or path computational responsibility. 137 Examples of domains include IGP areas and Autonomous Systems. 139 IGP Area: OSPF Area or ISIS level. 141 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 142 boundaries. 144 Inter-area TE LSP: A TE LSP whose path transits through 145 two or more IGP areas. 147 Inter-AS MPLS TE LSP: A TE LSP whose path transits 148 through two or more ASes or sub-ASes (BGP confederations). 150 LSR: Label Switch Router. 152 PCC: Path Computation Client: any client application requesting a 153 path computation to be performed by a Path Computation Element. 155 PCE: Path Computation Element: an entity (component, application, 156 or network node) that is capable of computing a network path or 157 route based on a network graph, and applying computational 158 constraints. 160 PCECP: Path Computation Element Communication Protocol. 162 TE LSP: Traffic Engineered Label Switched Path 164 3. Introduction 166 [PCE-ARCH] describes the motivations and architecture for a PCE-based 167 path computation model for MPLS and GMPLS TE LSPs. The model allows 168 the separation of PCE from PCC (also referred to as non co-located 169 PCE) and allows cooperation between PCEs. This relies on a 170 communication protocol between PCC and PCE, and between PCEs. The 171 requirements for such communication protocol can be found in [PCECP- 172 REQ] and the communication protocol is defined in [PCEP]. 174 The PCE architecture requires, of course, that a PCC be aware of the 175 location of one or more PCEs in its domain, and also potentially of 176 some PCEs in other domains, e.g. in case of inter-domain TE LSP 177 computation. 179 A network may comprise a large number of PCEs with potentially 180 distinct capabilities. In such context it would be highly desirable 181 to have a mechanism for automatic and dynamic PCE discovery, which 182 would allow PCCs to automatically discover a set of PCEs, along with 183 additional information required for PCE selection, and to dynamically 184 detect new PCEs or any modification of PCE information. 185 Detailed requirements for such a PCE discovery mechanism are 186 described in [PCE-DISCO-REQ]. 188 Moreover, it may also be useful to discover when a PCE experiences 189 some processing congestion state and exits such state in order for 190 the PCCs to take some appropriate actions (e.g. redirect to another 191 PCE). Note that the PCE selection algorithm is out of the scope of 192 this document. 194 When PCCs are LSRs participating to the IGP (OSPF, ISIS), and PCEs 195 are LSRs or a servers also participating to the IGP, an efficient 196 mechanism for PCE discovery within an IGP routing domain consists of 197 relying on IGP advertisements. 199 This document defines OSPF and ISIS extensions allowing a PCE 200 participating in the IGP to advertise its location along with some 201 information useful for PCE selection so as to satisfy dynamic PCE 202 discovery requirements set forth in [PCE-DISC-REQ]. This document 203 also defines extensions allowing a PCE participating to the IGP to 204 advertise its potential processing congestion state. 206 Generic capability mechanisms have been defined in [OSPF-CAP] and 207 [ISIS-CAP] for OSPF and ISIS respectively the purpose of which is to 208 allow a router to advertise its capability within an IGP area or an 209 entire routing domain. Such IGP extensions fully satisfy the 210 aforementioned dynamic PCE discovery requirements. 212 This document defines two new TLVs (named the PCE Discovery (PCED) 213 TLV and the PCE Status (PCES) TLV) for ISIS and OSPF to be carried 214 within the ISIS Capability TLV ([ISIS-CAP]) and the OSPF Router 215 Information LSA ([OSPF-CAP]). 217 The PCE information advertised is detailed in section 4. Protocol 218 extensions and procedures are defined in section 5 and 6 for ISIS and 219 OSPF respectively. 221 This document does not define any new OSPF or ISIS element of 222 procedure but how the procedures defined in [OSPF-CAP] and [ISIS-CAP] 223 should be used. 225 The routing extensions defined in this document allow for PCE 226 discovery within an IGP Routing domain. Solutions for PCE discovery 227 across AS boundaries are beyond the scope of this document, and for 228 further study. 230 4. Overview 232 4.1. PCE Information 234 PCE information advertised within the IGP includes PCE Discovery 235 Information and PCE Status information. 237 4.1.1. PCE Discovery Information 239 The PCE Discovery information is comprised of: 241 - The PCE location: This is a set of one or more IPv4 and or IPv6 242 addresses that MUST be used to reach the PCE. It is RECOMMENDED to 243 use loopback addresses always reachable. 245 - The PCE inter-domain functions: this refers to the PCE path 246 computation scope (i.e. inter-area, inter-AS, inter-layer�). 248 - The PCE domain(s): This is the set domain(s) where the PCE has 249 visibility and can compute paths. 251 - The PCE Destination domain(s): This is the set of destination 252 domain(s) towards which a PCE can compute paths. 254 - A set of general PCECP capabilities (e.g. support for request 255 prioritization) and path computation specific capabilities 256 (e.g. supported constraints, supported objective functions�). 258 These are two variable length sets of bits flags, where each bit 259 represent a given PCE capability. 261 It may also contain optional elements to describe more complex 262 capabilities. 264 PCE Discovery information is by nature a static information that does 265 not change with PCE activity. Changes in PCE Discovery information 266 may occur as a result of PCE configuration updates, PCE 267 deployment/activation or PCE deactivation/suppression. Hence, this 268 information is not expected to change frequently. 270 4.1.2. PCE Status Information 272 The PCE Status is optional information that can be used to report a 273 PCE processing congested state along with an estimated congestion 274 duration. This dynamic information may change with PCE activity. 276 Procedures for a PCE to move from a processing congested state to a 277 non congested state are beyond the scope of this document, but the 278 rate at which a PCE Status change is advertised MUST not impact by 279 any mean the IGP scalability. Particular attention should be given on 280 procedures to avoid state oscillations. 282 4.2. Flooding scope 284 The flooding scope for PCE Discovery Information can be limited to 285 one or more IGP areas the PCE belongs to or can be extended across 286 the entire routing domain. 287 Note that some PCEs may belong to multiple areas, in which case the 288 flooding scope may comprise these areas. This could be the case of an 289 ABR for instance advertising its PCE information within the backbone 290 area and/or a subset of its attached IGP area(s). 292 5. OSPF extensions 294 5.1. The OSPF PCED TLV 296 The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered 297 sub-TLVs. 299 The format of the OSPF PCED TLV and its sub-TLVs is the identical as 300 the TLV format used by the Traffic Engineering Extensions to OSPF 301 [OSPF-TE]. That is, the TLV is composed of 2 octets for the type, 2 302 octets specifying the TLV length and a value field. The Length field 303 defines the length of the value portion in octets. 304 The TLV is padded to four-octet alignment; padding is not included in 305 the length field (so a three octet value would have a length of 306 three, but the total size of the TLV would be eight octets). Nested 307 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 308 types between 32768 and 65535 are reserved for vendor-specific 309 extensions. All other undefined type codes are reserved for future 310 assignment by IANA. 312 The OSPF PCED TLV has the following format: 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 // sub-TLVs // 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Type To be defined by IANA (suggested value=2) 324 Length Variable 325 Value This comprises one or more sub-TLVs 327 Sub-TLVs types are under IANA control. 329 Currently five sub-TLVs are defined (type values to be assigned by 330 IANA): 331 Sub-TLV type Length Name 332 1 variable PCE-ADDRESS sub-TLV 333 2 4 PATH-SCOPE sub-TLV 334 3 variable PCE-DOMAINS sub-TLV 335 4 variable PCE-DEST-DOMAINS sub-TLV 336 5 variable GENERAL-CAP sub-TLV 337 6 variable PATH-COMP-CAP sub-TLV 339 The sub-TLVs PCE-ADDRESS and PATH SCOPE MUST always be present within 340 the PCED TLV. 342 The sub-TLVs PCE-DOMAINS and PCE-DEST-DOMAINS are optional. They MUST 343 be present only in some specific inter-domain cases. 345 The GENERAL-CAP and PATH-COMP-CAP sub-TLVs are optional and MAY be 346 present in the PCED TLV to facilitate the PCE selection process. 348 Any non recognized sub-TLV MUST be silently ignored. 350 Additional sub-TLVs could be added in the future to advertise 351 additional information. 353 The PCED TLV is carried within an OSPF Router Information LSA 354 defined in [OSPF-CAP], the opaque type of which is determined by the 355 desired flooding scope. 357 5.1.1. PCE-ADDRESS sub-TLV 359 The PCE-ADDRESS sub-TLV specifies the IP address that MUST be used to 360 reach the PCE. It is RECOMMENDED to make use of a loop-back address 361 that is always reachable, provided that the PCE is alive. 362 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 363 PCED TLV. The PCE-ADDRESS sub-TLV MUST appear at least once in the 364 PCED sub-TLV originated by a PCE. It MAY appear multiple times, for 365 instance when the PCE has both an IPv4 and IPv6 address. 367 The format of the PCE-ADDRESS sub-TLV is as follows: 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | address-type | Reserved | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | 376 // PCE IP Address // 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 PCE-ADDRESS sub-TLV format 382 Type To be assigned by IANA (suggested value =1) 383 Length 4 (IPv4) or 16 (IPv6) 385 Address-type: 386 1 IPv4 387 2 IPv6 389 PCE IP Address: The IP address to be used to reach the PCE. 390 This is the address that will be used for 391 setting up PCC-PCE communication sessions. 393 5.1.2. PATH-SCOPE sub-TLV 395 The PATH-SCOPE sub-TLV indicates the PCE path computation scope(s), 396 which refers to the PCE ability to compute or take part into the 397 computation of intra-area, inter-area, inter-AS or inter-layer_TE 398 LSP(s). 400 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 401 PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each 402 PCED TLV. 404 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 405 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 406 and four fields indicating PCE preferences. 408 The PATH-SCOPE sub-TLV has the following format: 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Type To be defined by IANA (suggested value =3) 418 Length Variable 419 Value This comprises a 2 bytes flag where each bit 420 represents a supported path scope, as well as four 421 preference fields allowing to specify PCE preferences. 423 The following bits are defined: 425 Bit Path Scope 427 0 L bit: Can compute intra-area path 428 1 R bit: Can act as PCE for inter-area TE LSPs 429 computation 430 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 431 computation 432 3 S bit: Can act as PCE for inter-AS TE LSPs computation 433 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 434 computation 435 5 Y bit: Can compute or take part into the computation of 436 paths across layers. 438 Pref-L field: PCE's preference for intra-area TE LSPs computation. 440 Pref-R field: PCE�s preference for inter-area TE LSPs computation. 442 Pref-S field: PCE�s preference for inter-AS TE LSPs computation. 444 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 446 Res: Reserved for future usage. 448 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 449 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 450 respectively. These bits are non exclusive. 452 When set the Rd bit indicates that the PCE can act as a default PCE 453 for inter-area TE LSPs computation (the PCE can compute path for any 454 destination area). Similarly, when set the Sd bit indicates that the 455 PCE can act as a default PCE for inter-AS TE LSPs computation (the 456 PCE can compute path for any destination AS). 458 When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not 459 contain any Area ID DOMAIN sub-TLV. 461 Similarly, when the Sd bit is set the PCE-DEST-DOMAIN TLV does not 462 contain any AS DOMAIN sub-TLV. 464 The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the 465 PCE to specify a preference for each computation scope, where 7 466 reflects the highest preference. Such preference can be used for 467 weighted load balancing of requests. An operator may decide to 468 configure a preference to each PCE so as to balance the path 469 computation load among them, with respect to their respective CPU 470 capacity. The algorithms used by a PCC to load balance its path 471 computation requests according to such PCE�s preference is out of the 472 scope of this document. Same or distinct preferences may be used for 473 different scopes. For instance an operator that wants a PCE capable 474 of both inter-area and inter-AS computation to be used preferably for 475 inter-AS computation may configure a PrefS higher than the PrefR. 477 When the L bit, R bit, S or Y bit are cleared the PrefL, PrefR, 478 PrefS, PrefY bit MUST respectively be set to 0. 480 5.1.3. PCE-DOMAINS sub-TLV 482 The PCE-DOMAINS sub-TLV specifies the set of domains (areas, AS) 483 where the PCE has topology visibility and can compute paths. It 484 contains a set of one or more sub-TLVs where each sub-TLV identifies 485 a domain. 487 The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be 488 inferred by other IGP information, for instance when the PCE is 489 inter-domain capable (i.e. when the R bit or S bit is set) and the 490 flooding scope is the entire routing domain. 492 The PCE-DOMAINS sub-TLV has the following format: 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 // DOMAIN sub-TLVs // 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Type To be defined by IANA (suggested value =3) 504 Length Variable 505 Value This comprises a set of one or more DOMAIN sub-TLVs 506 where each DOMAIN sub-TLV identifies a domain where 507 the PCE has topology visibility and can compute paths. 509 Sub-TLVs types are under IANA control. 511 Currently three DOMAIN sub-TLVs are defined (suggested type values to 512 be assigned by IANA): 513 Sub-TLV type Length Name 514 1 variable IPv4 area ID sub-TLV 515 2 variable IPv6 area ID sub-TLV 516 3 variable AS number sub-TLV 518 The PCE-DOMAINS sub-TLV MUST include at least one DOMAIN sub-TLV. 519 Note than when the PCE visibility is an entire AS, the PCE-DOMAINS 520 sub-TLV MUST uniquely include one AS number sub-TLV. 522 5.1.3.1. IPv4 area ID DOMAIN sub-TLV 524 The IPv4 area ID DOMAIN sub-TLV carries an IPv4 OSPF area identifier. 525 It has the following format: 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type | Length | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | IPv4 Area ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Type To be assigned by IANA (suggested value =1) 535 Length 4 536 IPv4 OSPF area ID: The IPv4 identifier of the OSPF area 538 5.1.3.2. IPv6 area ID DOMAIN sub-TLV 540 The IPv6 area ID sub-TLV carries an IPv6 OSPF area identifier. It has 541 the following format: 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type | Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | IPv6 Area ID | 548 | | 549 | | 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Type To be assigned by IANA (suggested value =2) 554 Length 16 555 IPv6 OSPF area ID: The IPv6 identifier of the OSPF area 557 5.1.3.3. AS Number sub-TLV 559 The AS Number sub-TLV carries an AS number. It has the following 560 format: 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type | Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | AS Number | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Type To be assigned by IANA (suggested value =3) 570 Length 4 571 AS Number: AS number identifying an AS. When coded on two 572 bytes (which is the current defined format as the 573 time of writing this document), the AS Number field 574 MUST have its left two bytes set to 0. 576 5.1.4. PCE-DEST-DOMAINS sub-TLV 578 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 579 (areas, AS) toward which a PCE can compute path. It means that the 580 PCE can compute or take part in the computation of inter-domain LSPs 581 whose destinations are located within one of these domains. It 582 contains a set of one or more sub-TLVs where each sub-TLV identifies 583 a domain. 585 The PCE-DEST-DOMAINS sub-TLV has the following format: 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type | Length | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 // DOMAIN sub-TLVs // 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Type To be defined by IANA (suggested value =3) 597 Length Variable 598 Value This comprises a set of one or more Area and/or AS 599 DOMAIN sub-TLVs where each DOMAIN sub-TLV identifies a 600 domain toward which a PCE can compute paths. 602 The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and 603 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 604 cleared. 606 The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub- 607 TLV. It MUST include at least one area ID sub-TLV, if the R bit of 608 the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is 609 cleared. Similarly, it MUST include at least one AS number sub-TLV if 610 the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH- 611 SCOPE TLV is cleared. 613 5.1.5. GENERAL-CAP sub-TLV 615 The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP 616 related capabilities. 617 The value field of the GENERAL-CAP sub-TLV is made of bit flags, 618 where each bit corresponds to a general PCE capability. It MAY also 619 include optional sub-TLVs to encode more complex capabilities. 621 The format of the GENERAL-CAP sub-TLV is as follows: 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Type | Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | General PCE Capabilities | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 // Optional sub-TLVs // 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Type To be assigned by IANA (suggested value =1) 634 Length It is set to N x 4 octets. N starts 635 from 1 and can be increased when there is a need. 636 Each 4 octets are referred to as a capability flag. 637 Value This comprises one or more capability flags. 638 For each 4 octets, the bits are indexed from the most 639 significant to the least significant, where each bit 640 represents one general PCE capability. When 641 the first 32 capabilities are defined, a new 642 capability flag will be used to accommodate the next 643 capability. Optional TLVs may be defined to specify 644 more complex capabilities: there is no optional TLVs 645 currently defined. 647 IANA is requested to manage the space of general PCE capability bit 648 flags. 650 The following bits in the first capability flag are to be assigned by 651 IANA: 653 Bit Capabilities 655 0 P bit: Support for Request prioritization. 656 1 M bit: Support for multiple messages within the same 657 request message. 659 2-31 Reserved for future assignments by IANA. 661 5.1.6. The PATH-COMP-CAP sub-TLV 663 The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path 664 computation specific capabilities. It is made of a set of bit flags, 665 where each bit correspond to a path computation capability. It MAY 666 also include optional sub-TLVs to encode more complex capabilities. 668 The format of the PATH-COMP-CAP sub-TLV is as follows: 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Type | Length | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Path Computation Capabilities | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 // Optional sub-TLVs // 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Type To be assigned by IANA (suggested value =1) 681 Length It is set to N x 4 octets. N starts 682 from 1 and can be increased when there is a need. 683 Each 4 octets are referred to as a capability flag. 684 Value This comprises one or more capability flags. 685 For each 4 octets, the bits are indexed from the most 686 significant to the least significant, where each bit 687 represents one path computation PCE capability. When 688 the first 32 capabilities are defined, a new 689 capability flag will be used to accommodate the next 690 capability. Optional TLVs may be defined to specify 691 more complex capabilities: there is no optional TLVs 692 currently defined. 694 IANA is requested to manage the space of PCE path commutation 695 capability bit flags. 697 The following bits in the first capability flag are to be assigned by 698 IANA: 700 Bit Capabilities 702 0 G bit: Capability to handle GMPLS contraints 703 1 B bit: Capability to compute bidirectional paths 704 2 D bit: Capability to compute link/node/SRLG diverse paths 705 3 L bit: Capability to compute load-balanced paths 706 4 S bit: Capability to compute a set of paths in a 707 synchronized Manner 708 5 O bit: Support for multiple objective functions 710 6-31 Reserved for future assignments by IANA. 712 The G, B, D, L, S and O bits are not exclusive. 714 5.2. The OSPF PCES TLV 716 The OSPF PCE Status TLV (PCES TLV) carries information related to PCE 717 processing congestion state. 718 The PCES TLV is carried within an OSPF Router Information LSA which 719 is defined in [OSPF-CAP]. 721 The OSPF PCES TLV has the following format: 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Type | Length | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 // PCE ADDRESS sub-TLV // 728 // CONGESTION sub-TLV // 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 Type To be defined by IANA (suggested value=3) 732 Length Variable 733 Value This comprises a PCE ADDRESS sub-TLV, identifying the 734 PCE and a CONGESTION sub-TLV that contains congestion 735 information. 737 Sub-TLV types are under IANA control. 739 Currently two sub-TLVs are defined (type values to be assigned by 740 IANA): 741 Sub-TLV type Length Name 742 1 variable PCE-ADDRESS sub-TLV 743 2 4 CONGESTION sub-TLV 745 The PCE-ADDRESS and CONGESTION sub-TLVs MUST be present once 746 in a PCES TLV. The PCE-ADDRESS sub-TLV is defined in section 5.1.1. 747 It carries one of the PCE IP addresses and is used to identify the 748 PCE the processing congestion state information is applied to. This 749 is required as the PCES and PCED TLVs may be carried in separate 750 Router Information LSAs. 752 Any non recognized sub-TLV MUST be silently ignored. 754 Additional sub-TLVs could be added in the future to advertise 755 additional congestion information. 757 5.2.1. The CONGESTION sub-TLV 759 The CONGESTION sub-TLV is used to indicate whether a PCE experiences 760 a processing congestion state or not along with optionally the 761 expected PCE congestion duration. 762 The CONGESTION sub-TLV is mandatory. It MUST be carried once within 763 the PCES TLV. 765 The format of the CONGESTION sub-TLV is as follows: 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Type | Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 |C| Reserved | Congestion Duration | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Type To be assigned by IANA (suggested value =2) 776 Length 4 778 Value 779 -C bit: When set this indicates that the PCE experiences 780 congestion and cannot support any new request. When 781 cleared this indicates that the PCE does not 782 experiences congestion an can support a new request. 784 -Congestion Duration: 2-bytes, the estimated PCE congestion 785 duration in seconds. 787 When C is set and the Congestion Duration field is equal to 0, this 788 means that the Congestion Duration is unknown. 789 When C is cleared the Congestion Duration MUST be set to 0. 791 5.3. Elements of Procedure 793 The PCED and PCES TLV are carried within an OSPF Router information 794 opaque LSA (opaque type of 4, opaque ID of 0) which is defined in 795 [OSPF-CAP]. As the PCES information is likely to change more 796 frequently than the PCED information, it is RECOMMENDED to carry PCES 797 and PCED TLVs in separate Router Information LSAs, so as not to carry 798 all PCED information each time the PCE status changes. 800 5.3.1. PCED TLV Procedure 802 A router MUST originate a new OSPF router information LSA whenever 803 the content of the PCED TLV changes or whenever required by the 804 regular OSPF procedure (LSA refresh (every LSRefreshTime)). 806 The PCED TLV may be carried within a type 10 or 11 router information 807 LSA depending on the flooding scope of the PCE information. 808 If the flooding scope is local to an area then it MUST be carried 809 within a type 10 router information LSA. 810 If the flooding scope is the entire domain then it MUST be carried 811 within type 11 router information LSA. 812 Note that when the L bit of the PATH-SCOPE TLV is set and the R bit 813 and S bit are cleared, the flooding scope MUST be local, and the PCED 814 TLV MUST be carried within a type 10 Router Information LSA. 816 PCED sub-TLVs are OPTIONAL. When an OSPF LSA does not contain 817 any PCED sub-TLV, this means that the PCE information of that 818 node is unknown. 820 Note that a change in PCED information MUST not trigger any SPF 821 computation. 823 The way PCEs retrieve their own information is out of the scope of 824 this document. Some information may be configured on the PCE (e.g. 825 address, preferences, scope) and other information may be 826 automatically retrieved by the PCE (e.g. areas of visibility). 828 5.3.2. PCES TLV procedure 830 A router MUST originate a new OSPF router information LSA whenever 831 the content of the PCES TLV changes or whenever required by the 832 regular OSPF procedure (LSA refresh (every LSRefreshTime)). 834 When a PCE enters into a processing congestion state, the conditions 835 of which are implementation dependent, it SHOULD originate a Router 836 Information LSA with a PCES TLV with the C bit set, and optionally a 837 non-null expected congestion duration. 839 When a PCE leaves the processing congestion state, the conditions of 840 which are implementation dependent, there are two cases: 841 - If the congestion duration in the previously originated PCES 842 TLV was null, it SHOULD originate a PCES TLV with the C bit cleared 843 and a null congestion duration; 844 - If the congestion duration in the previously originated PCES 845 TLV was non null, it MAY not originate a PCES TLV. Note that in some 846 particular cases it may be desired to originate a PCES TLV with the C 847 bit cleared if the saturation duration was over estimated. 849 The congestion duration allows reducing the amount of OSPF flooding, 850 as only uncongested-congested state transitions are flooded. 852 It is expected that a proper implementation will support dampening 853 algorithms so as to dampen OSPF flooding in order to not impact the 854 OSPF scalability. It is recommended to introduce some hysteresis for 855 saturation state transition, so as to avoid state oscillations that 856 may impact OSPF performances. For instance two thresholds could be 857 configured: A resource saturation upper-threshold and a resource 858 saturation lower-threshold. An LSR enters the congested state when 859 the CPU load reaches the upper threshold and leaves the congested 860 state when the CPU load goes under the lower threshold. 862 Upon receipt of an updated PCES TLV a PCC should take appropriate 863 actions. In particular, the PCC should stop sending requests to a 864 congested PCE, and should gradually start sending again requests to a 865 no longer congested PCE. Such PCC procedures are out of the scope of 866 this document. 868 6. ISIS extensions 870 6.1. IS-IS PCED TLV format 872 The IS-IS PCED TLV is made of various non ordered sub-TLVs. 874 The format of the IS-IS PCED TLV and its sub-TLVs is the same as the 875 TLV format used by the Traffic Engineering Extensions to IS-IS [ISIS- 876 TE]. That is, the TLV is composed of 1 octet for the type, 1 octet 877 specifying the TLV length and a value field. 879 The IS-IS PCED TLV has the following format: 881 TYPE: To be assigned by IANA 882 LENGTH: Variable 883 VALUE: set of sub-TLVs 885 Sub-TLVs types are under IANA control. 887 Currently five sub-TLVs are defined (suggested type values to be 888 assigned by IANA): 889 Sub-TLV type Length Name 890 1 variable PCE-ADDRESS sub-TLV 891 2 3 PATH-SCOPE sub-TLV 892 3 variable PCE-DOMAINS sub-TLV 893 4 variable PCE-DEST-DOMAINS sub-TLV 894 5 variable GENERAL-CAP sub-TLV 895 6 variable PATH-COMP-CAP sub-TLV 897 The sub-TLVs PCE-ADDRESS and PATH-SCOPE MUST always be present within 898 the PCED TLV. 900 The sub-TLVs PCE-DOMAINS and PCE-DEST-DOMAINS are optional. They MUST 901 be present only in some specific inter-domain cases. 903 The GENERAL-CAP and PATH-COMP-CAP are optional and MAY be present in 904 the PCED TLV to facilitate the PCE selection process. 906 Any non recognized sub-TLV MUST be silently ignored. 908 Additional sub-TLVs could be added in the future to advertise 909 additional PCE information. 911 The PCED TLV is carried within an ISIS CAPABILITY TLV defined in 912 [ISIS-CAP], whose S bit is determined by the desired flooding scope. 914 6.1.1. PCE-ADDRESS sub-TLV 916 The PCE-ADDRESS sub-TLV specifies the IP address that MUST be used to 917 reach the PCE. It is RECOMMENDED to make use of a loop-back addresse 918 that is always reachable, provided the PCE is alive. 919 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 920 PCED TLV. 922 The PCE-ADDRESS sub-TLV has the following format: 924 TYPE: To be assigned by IANA (Suggested value =1) 925 LENGTH: 4 for IPv4 address and 16 for IPv6 address 926 VALUE: This comprises one octet indicating the address-type and 4 927 or 16 octets encoding the IPv4 or IPv6 address to be used 928 to reach the PCE 930 Address-type: 931 1 IPv4 932 2 IPv6 934 The PCE-ADDRESS sub-TLV MUST appear at least once in the PCED sub-LTV 935 originated by a PCE. It MAY appear multiple times, for instance when 936 the PCE has both an IPv4 and IPv6 address. 938 6.1.2. The PATH-SCOPE sub-TLV 940 The PATH-SCOPE sub-TLV indicates the PCE path computation scope which 941 refers to the PCE ability to compute or take part into the 942 computation of intra-area, inter-area, inter-AS or inter-layer_TE 943 LSP(s). 945 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 946 PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each 947 PCED TLV. 949 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 950 supported path scopes (intra-area, inter-area, inter-AS, inter-layer) 951 and four fields indicating PCE preferences. 953 The PATH-SCOPE sub-TLV has the following format: 955 TYPE: To be assigned by IANA (Suggested value =2) 956 LENGTH: 3 957 VALUE: This comprises a one-byte flag of bits where each bit 958 represents a supported path scope, followed by a 2-bytes 959 preferences field indicating PCE preferences. 961 Here is the structure of the bit flag: 963 +-+-+-+-+-+-+-+-+ 964 |0|1|2|3|4|5|Res| 965 +-+-+-+-+-+-+-+-+ 967 Bit Path Scope 969 0 L bit: Can compute intra-area path 970 1 R bit: Can act as PCE for inter-area TE LSPs 971 computation 972 2 Rd bit: Can act as a default PCE for inter-area TE LSPs 973 computation 974 3 S bit: Can act as PCE for inter-AS TE LSPs computation 975 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 976 computation 977 5 Y bit: Can compute or take part into the computation of 978 paths across layers 979 6-7 Reserved for future usage. 981 Here is the structure of the preferences field 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 |PrefL|PrefR|PrefS|PrefY| Res | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Pref-L field: PCE's preference for intra-area TE LSPs computation. 989 Pref-R field: PCE�s preference for inter-area TE LSPs computation. 991 Pref-S field: PCE�s preference for inter-AS TE LSPs computation. 993 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 995 Res: Reserved for future usage. 997 The bits L, R, S and Y bits are set when the PCE can act as a PCE for 998 intra-area, inter-area, inter-AS and inter-layer TE LSPs computation 999 respectively. These bits are non exclusive. 1001 When set the Rd bit indicates that the PCE can act as a default PCE 1002 for inter-area TE LSPs computation (the PCE can compute path for any 1003 destination area). Similarly, when set the Sd bit indicates that the 1004 PCE can act as a default PCE for inter-AS TE LSPs computation (the 1005 PCE can compute path for any destination AS). 1007 When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not 1008 contain any Area ID DOMAIN sub-TLV. 1010 Similarly, when the Sd bit is set the PCE-DEST-DOMAIN TLV does not 1011 contain any AS DOMAIN sub-TLV. 1013 The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the 1014 PCE to specify a preference for each computation scope, where 7 1015 reflects the highest preference. Such preference can be used for 1016 weighted load balancing of requests. An operator may decide to 1017 configure a preference to each PCE so as to balance the path 1018 computation load among them, with respect to their respective CPU 1019 capacity. The algorithms used by a PCC to balance its path 1020 computation requests according to such PCE�s preference is out of the 1021 scope of this document. Same or distinct preferences may be used for 1022 different scopes. For instance an operator that wants a PCE capable 1023 of both inter-area and inter-AS computation to be used preferably for 1024 inter-AS computation may configure a PrefS higher than the PrefR. 1026 When the L bit, R bit, S or Y bit are cleared the PrefL, PrefR, 1027 PrefS, PrefY bit MUST respectively be set to 0. 1029 6.1.3. PCE-DOMAINS sub-TLV 1031 The PCE-DOMAINS sub-TLV specifies the set of domains (areas or AS) 1032 where the PCE has topology visibility and can compute paths. It 1033 contains a set of one or more sub-TLVs where each sub-TLV identifies 1034 a domain. 1036 The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be 1037 inferred by other IGP information, for instance when the PCE is 1038 inter-domain capable (i.e. when the R bit or S bit is set) and the 1039 flooding scope is the entire routing domain. 1041 The PCE-DOMAINS sub-TLV has the following format: 1043 TYPE: To be assigned by IANA (Suggested value =2) 1044 LENGTH: Variable 1045 VALUE: This comprises a set of one or more DOMAIN sub-TLVs where 1046 each DOMAIN sub-TLV identifies a domain where the PCE has 1047 topology visibility and can compute paths 1049 DOMAIN Sub-TLVs types are under IANA control. 1051 Currently two DOMAIN sub-TLVs are defined (suggested type values to 1052 be assigned by IANA): 1053 Sub-TLV type Length Name 1054 1 variable Area ID sub-TLV 1055 2 variable AS number sub-TLV 1057 At least one DOMAIN sub-TLV MUST be present in the PCE-DOMAINS sub- 1058 TLV. 1060 6.1.3.1. Area ID DOMAIN sub-TLV 1062 This sub-TLV carries an ISIS area ID. It has the following format 1064 TYPE: To be assigned by IANA (Suggested value =1) 1065 LENGTH: Variable 1066 VALUE: This comprises a variable length ISIS area ID. This is the 1067 combination of an Initial Domain Part (IDP) and High Order 1068 part of the Domain Specific part (HO-DPS) 1070 6.1.3.2. AS Number DOMAIN sub-TLV 1072 The AS Number sub-TLV carries an AS number. It has the following 1073 format: 1075 TYPE: To be assigned by IANA (Suggested value =2) 1076 LENGTH: 4 1077 VALUE: AS number identifying an AS. When coded on two 1078 bytes (which is the current defined format as the 1079 time of writing this document), the AS Number field 1080 MUST have its left two bytes set to 0. 1082 6.1.4. PCE-DEST-DOMAINS sub-TLV 1084 The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains 1085 (areas, AS) toward which a PCE can compute path. It means that the 1086 PCE can compute or take part in the computation of inter-domain LSPs 1087 whose destinations are located within one of these domains. It 1088 contains a set of one or more DOMAIN sub-TLVs where each DOMAIN sub- 1089 TLV identifies a domain. 1091 The PCE-DEST-DOMAINS sub-TLV has the following format: 1093 TYPE: To be assigned by IANA (Suggested value =3) 1094 LENGTH: Variable 1095 VALUE: This comprises a set of one or more Area or/and AS DOMAIN sub- 1096 TLVs where each sub-TLV identifies a destination domain toward 1097 which a PCE can compute path. 1099 The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and 1100 the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is 1101 cleared. 1103 The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub- 1104 TLV. It MUST include at least one area ID sub-TLV, if the R bit of 1105 the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is 1106 cleared. Similarly, it MUST include at least one AS number sub-TLV if 1107 the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH- 1108 SCOPE TLV is cleared. 1110 6.1.5. GENERAL-CAP sub-TLV 1112 The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP 1113 related capabilities. 1114 This is a series of bits flags, where each bit corresponds to a 1115 general PCE capability. It MAY also include optional sub-TLVs to 1116 encode more complex capabilities. 1118 The GENERAL-CAP sub-TLV has the following format: 1120 TYPE: To be assigned by IANA (Suggested value =4) 1121 LENGTH: It is set to N. N starts from 1 and can be increased when 1122 there is a need. Each octet is referred to as a 1123 capability flag. 1124 VALUE: This comprises one or more general PCE capability 1125 flags. 1127 The following bits in the first capability flag are to be assigned by 1128 IANA: 1130 0 1 2 3 4 5 6 7 1131 +-+-+-+-+-+-+-+-+ 1132 |P|M| Reserved | 1133 +-+-+-+-+-+-+-+-+ 1135 P bit: Support for request prioritization. 1136 M bit: Support for multiple messages within the same request message. 1138 Reserved bits are for future assignment by IANA. 1140 6.1.6. The PATH-COMP-CAP sub-TLV 1142 The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path 1143 computation specific capabilities of a PCE. 1144 This is a series of bit flags, where each bit correspond to a path 1145 computation capability. It MAY also include optional sub-TLVs to 1146 encode more complex capabilities. 1148 The PATH-COMP-CAP sub-TLV has the following format: 1150 TYPE: To be assigned by IANA (suggested value = 5) 1151 LENGTH: It is set to N. N starts from 1 and can be increased 1152 when there is a need. Each octet is referred to as a 1153 capability flag. 1154 VALUE: This comprises one or more Path Computation specific PCE 1155 capability flags. 1157 The following bits in the first capability flag are to be assigned by 1158 IANA. 1160 0 1 2 3 4 5 6 7 1161 +-+-+-+-+-+-+-+-+ 1162 |M|G|D|L|S|0|Res| 1163 +-+-+-+-+-+-+-+-+ 1165 G bit: Capability to handle GMPLS constraints 1166 B bit: Capability to compute bidirectional paths 1167 D bit: Capability to compute link/node/SRLG diverse paths 1168 L bit: Capability to compute load-balanced paths 1169 S bit: Capability to compute a set of paths in a 1170 synchronized Manner 1171 O bit: Support for multiple objective functions 1173 Reserved bits are for future assignment by IANA. 1175 The G, B, D, L, S and O bits are not exclusive. 1177 6.2. The ISIS PCES TLV 1179 The ISIS PCE Status TLV (PCES TLV) carries information related to PCE 1180 processing congestion state. 1181 The PCES TLV is carried within an ISIS Capability TLV which is 1182 defined in [ISIS-CAP]. 1184 The ISIS PCES TLV has the following format: 1186 TYPE: To be assigned by IANA 1187 LENGTH: Variable 1188 VALUE: set of sub-TLVs 1190 Sub-TLVs types are under IANA control. 1192 Currently two sub-TLVs are defined (suggested type values to be 1193 assigned by IANA): 1194 Sub-TLV type Length Name 1195 1 variable PCE-ADDRESS sub-TLV 1196 2 3 CONGESTION sub-TLV 1198 The PCE-ADDRESS and CONGESTION sub-TLVs MUST be present once 1199 in a PCES TLV. The PCE-ADDRESS sub-TLV is defined in section 6.1.1. 1200 It carries one of the PCE IP addresses and is used to identify the 1201 PCE the processing congestion state information is applied to. This 1202 is required as the PCES and PCED TLVs may be carried in separate 1203 ISIS Capability TLVs. 1205 Any non recognized sub-TLV MUST be silently ignored. 1207 Additional sub-TLVs could be added in the future to advertise 1208 additional congestion information. 1210 6.2.1. The CONGESTION sub-TLV 1212 The CONGESTION sub-TLV is used to indicate whether a PCE experiences 1213 a processing congestion state or not along with optionally the PCE 1214 expected congestion duration. 1215 The CONGESTION sub-TLV is mandatory. It MUST be carried once within 1216 the PCES TLV. 1218 The format of the CONGESTION sub-TLV is as follows: 1220 TYPE: To be assigned by IANA (Suggested value =2) 1221 LENGTH: 3 1222 VALUE: This comprises a one-byte flag of bits indicating the 1223 congestion status, followed by a 2-bytes field indicating the 1224 congestion duration. 1226 Here is the TLV structure 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 |C| Reserved| Congestion Duration | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 Value 1233 -C bit: When set this indicates that the PCE experiences 1234 congestion and cannot support any new request. When 1235 cleared this indicates that the PCE does not 1236 experiences congestion an can support a new request. 1238 -Congestion Duration: 2-bytes, the estimated PCE congestion 1239 duration in seconds. 1241 When C is set and the Congestion Duration field is equal to 0, this 1242 means that the Congestion Duration is unknown. 1243 When C is cleared the Congestion Duration MUST be set to 0. 1245 6.3. Elements of Procedure 1247 The PCED and PCES TLV are carried within an ISIS Capability TLV which 1248 is defined in [ISIS-CAP]. As PCES information is likely to change 1249 more frequently than the PCED information, it is RECOMMENDED to carry 1250 PCES and PCED TLVs in separate ISIS Capability TLVs, so as not to 1251 carry all PCED information each time the PCE status changes. 1253 6.3.1. PCED TLV Procedure 1255 An ISIS router MUST originate a new ISIS LSP whenever the content 1256 of any of the PCED TLV changes or whenever required by the regular 1257 ISIS procedure (LSP refresh). 1259 When the scope of the PCED TLV is area local it MUST be carried 1260 within an ISIS CAPABILITY TLV having the S bit cleared. 1261 When the scope of the PCED TLV is the entire domain, the PCED TLV 1262 MUST be carried within an ISIS CAPABILITY TLV having the S bit set. 1263 Note that when only the L bit of the PATH-SCOPE sub-TLV is set and 1264 the flooding scope MUST be local. 1266 PCED sub-TLVs are OPTIONAL. When an ISIS LSP does not contain 1267 any PCED sub-TLV, this means that the PCE information of 1268 that node is unknown. 1270 Note that a change in PCED information MUST not trigger any SPF 1271 computation. 1273 The way PCEs retrieve their own information is out of the scope of 1274 this document. Some information may be configured (e.g. address, 1275 preferences, scope) and other information may be automatically 1276 retrieved (e.g. areas of visibility). 1278 6.3.2. PCES TLV procedure 1280 An ISIS router MUST originate a new ISIS LSP whenever the content 1281 of any of the PCES TLV changes or whenever required by the regular 1282 IS-IS procedure (LSP refresh). 1284 When a PCE enters into a processing congestion state, the conditions 1285 of which are implementation dependent, it SHOULD originate a new ISIS 1286 LSP with a Capability TLV carrying a PCES TLV with the C bit set and 1287 optionally a non-null expected congestion duration. 1289 When a PCE leaves the processing congestion state, the conditions of 1290 which are implementation dependent, there are two cases: 1291 - If the congestion duration in the previously originated PCES 1292 TLV was null, it SHOULD originate a PCES TLV with the C bit cleared 1293 and a null congestion duration; 1294 - If the congestion duration in the previously originated PCES 1295 TLV was non null, it MAY not originate a PCES TLV. Note that in some 1296 particular cases it may be desired to originate a PCES TLV with the C 1297 bit cleared if the saturation duration was over estimated. 1299 The congestion duration allows reducing the amount of ISIS flooding, 1300 as only uncongested-congested state transitions are flooded. 1302 It is expected that a proper implementation will support dampening 1303 algorithms so as to dampen ISIS flooding in order to not impact the 1304 ISIS scalability. It is recommended to introduce some hysteresis for 1305 congestion state transition, so as to avoid state oscillations that 1306 may impact ISIS performances. For instance two thresholds could be 1307 configured: A resource saturation upper-threshold and a resource 1308 saturation lower-threshold. An LSR enters the congested state when 1309 the CPU load reaches the upper threshold and leaves the congested 1310 state when the CPU load goes under the lower threshold. 1312 Upon receipt of an updated PCES TLV a PCC should take appropriate 1313 actions. In particular, the PCC should stop sending requests to a 1314 congested PCE, and should gradually start sending again requests to a 1315 no longer congested PCE. Such PCC procedures are out of the scope of 1316 this document. 1318 7. Backward compatibility 1320 The PCED and PCEs TLVs defined in this document do not introduce any 1321 interoperability issue. 1322 For OSPF, a router not supporting the PCED/PCES TLVs SHOULD just 1323 silently ignore the TLVs as specified in [RFC2370]. 1325 For ISIS a router not supporting the PCED/PCES TLVs SHOULD just 1326 silently ignore the TLV. 1328 8. IANA considerations 1330 8.1. OSPF TLVs 1332 IANA will assign a new codepoint for the OSPF PCED TLV defined in 1333 this document and carried within the Router Information LSA. 1334 Five sub-TLVs types are defined for this TLV and should be assigned 1335 by IANA: 1336 -PCE-ADDRESS sub-TLV (suggested value = 1) 1337 -PATH-SCOPE sub-TLV (suggested value = 2) 1338 -PCE-DOMAINS sub-TLV (suggested value = 3) 1339 -PCE-DEST-DOMAINS sub-TLV (suggested value =4) 1340 -GENERAL-CAP sub-TLV (suggested value = 5) 1341 -PATH-COMP-CAP sub-TLV (suggested value = 6) 1343 Three sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 1344 DOMAINS TLVs and should be assigned by IANA: 1345 -IPv4 area ID sub-TLV (suggested value = 1) 1346 -IPv6 area ID sub-TLV (suggested value = 2) 1347 -AS number sub-TLV (suggested value = 3) 1349 IANA will assign a new codepoint for the OSPF PCES TLV defined in 1350 this document and carried within the Router Information LSA. 1351 Two sub-TLVs types are defined for this TLV and should be assigned by 1352 IANA: 1353 -PCE-ADDRESS sub-TLV (suggested value = 1) 1354 -CONGESTION sub-TLV (suggested value = 2) 1356 8.2. ISIS TLVs 1358 IANA will assign a new codepoint for the PCED TLV defined in this 1359 document and carried within the ISIS CAPABILITY TLV. 1360 Five sub-TLVs types are defined for the PCED TLV and should be 1361 assigned by IANA: 1362 -PCE-ADDRESS sub-TLV (suggested value = 1) 1363 -PATH-SCOPE sub-TLV (suggested value = 2) 1364 -PCE-DEST-DOMAINS sub-TLV (suggested value = 3) 1365 -PCE-DOMAINS sub-TLV (suggested value = 4) 1366 -GENERAL-CAP sub-TLV (suggested value = 5) 1367 -PATH-COMP-CAP sub-TLV (suggested value = 6) 1369 Two sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST- 1370 DOMAINS TLVs and should be assigned by IANA: 1371 -Area ID sub-TLV (suggested value = 1) 1372 -AS number sub-TLV (suggested value = 2) 1374 IANA will assign a new codepoint for the ISIS PCES TLV defined in 1375 this document and carried within the ISIS CAPABILITY TLV. 1377 Two sub-TLVs types are defined for this TLV and should be assigned by 1378 IANA: 1379 -PCE-ADDRESS sub-TLV (suggested value = 1) 1380 -CONGESTION sub-TLV (suggested value = 2) 1382 8.3. Capability bits 1384 IANA is requested to manage the space of general and path computation 1385 specific PCE capability bits flags, numbering them in the usual IETF 1386 notation starting at zero and continuing at least through 31. 1387 New bit numbers may be allocated only by an IETF Consensus action. 1388 Each bit should be tracked with the following qualities: 1389 - Bit number 1390 - Defining RFC 1391 - Name of bit 1393 Currently two bits are defined in the first general PCE capability 1394 flag. Here are the suggested values: 1395 -0: Support for Request prioritization. 1396 -1: Support for multiple messages within the same request message 1398 Currently six bits are defined in the first path computation specific 1399 PCE capability flag. Here are the suggested values: 1401 -0: Capability to handle GMPLS Constraints 1402 -1: Capability to compute bidirectional paths 1403 -2: Capability to compute link/node/SRLG diverse paths 1404 -3: Capability to compute load-balanced paths 1405 -4: Capability to compute a set of paths in a 1406 synchronized Manner 1407 -5: Support for multiple objective functions 1409 9. Security Considerations 1411 To be completed in further revisions. 1413 10. References 1415 10.1. Normative references 1417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1418 Requirement Levels", BCP 14, RFC 2119, March 1997. 1420 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1421 3667, February 2004. 1423 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 1424 Technology", RFC 3979, March 2005. 1426 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1428 [RFC2370] Coltun, R., �The OSPF Opaque LSA Option�, RFC 2370, July 1429 1998. 1431 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 1432 Routing Exchange Protocol " ISO 10589. 1434 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1435 dual environments", RFC 1195, December 1990. 1437 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 1438 Extensions to OSPF Version 2", RFC 3630, September 2003. 1440 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 1441 Engineering", RFC 3784, June 2004. 1443 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 1444 J.P., "Extensions to OSPF for advertising Optional Router 1445 Capabilities", draft-ietf-ospf-cap, work in progress. 1447 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 1448 router information", draft-ietf-isis-caps, work in progress. 1450 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 1451 Element (PCE) Architecture", draft-ietf-pce-architecture, work in 1452 progress. 1454 [PCE-DISCO-REQ] Le Roux, J.L., et al. "Requirements for PCE 1455 discovery", draft-ietf-pce-discovery-reqs, work in progress 1457 10.2. Informative references 1459 [PCECP-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol 1460 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in 1461 progress. 1463 [PCEP] Vasseur et al., �Path Computation Element (PCE) communication 1464 Protocol (PCEP) - Version 1�, draft-ietf-pce-pcep-01.txt, work in 1465 progress. 1467 11. Authors' Addresses: 1469 Jean-Louis Le Roux (Editor) 1470 France Telecom 1471 2, avenue Pierre-Marzin 1472 22307 Lannion Cedex 1473 FRANCE 1474 Email: jeanlouis.leroux@francetelecom.com 1476 Jean-Philippe Vasseur (Editor) 1477 Cisco Systems, Inc. 1478 1414 Massachusetts avenue 1479 Boxborough , MA - 01719 1480 USA 1481 Email: jpv@cisco.com 1483 Yuichi Ikejiri 1484 NTT Communications Corporation 1485 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1486 Tokyo 100-8019 1487 JAPAN 1488 Email: y.ikejiri@ntt.com 1490 Raymond Zhang 1491 BT Infonet 1492 2160 E. Grand Ave. 1493 El Segundo, CA 90025 1494 USA 1495 Email: raymond_zhang@infonet.com 1497 12. Intellectual Property Statement 1499 The IETF takes no position regarding the validity or scope of any 1500 Intellectual Property Rights or other rights that might be claimed to 1501 pertain to the implementation or use of the technology described in 1502 this document or the extent to which any license under such rights 1503 might or might not be available; nor does it represent that it has 1504 made any independent effort to identify any such rights. Information 1505 on the procedures with respect to rights in RFC documents can be 1506 found in BCP 78 and BCP 79. 1508 Copies of IPR disclosures made to the IETF Secretariat and any 1509 assurances of licenses to be made available, or the result of an 1510 attempt made to obtain a general license or permission for the use of 1511 such proprietary rights by implementers or users of this 1512 specification can be obtained from the IETF on-line IPR repository at 1513 http://www.ietf.org/ipr. 1515 The IETF invites any interested party to bring to its attention any 1516 copyrights, patents or patent applications, or other proprietary 1517 rights that may cover technology that may be required to implement 1518 this standard. Please address the information to the IETF at 1519 ietf-ipr@ietf.org. 1521 Disclaimer of Validity 1523 This document and the information contained herein are provided on an 1524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1525 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1526 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1527 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1528 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1531 Copyright Statement 1532 Copyright (C) The Internet Society (2006). This document is subject 1533 to the rights, licenses and restrictions contained in BCP 78, and 1534 except as set forth therein, the authors retain all their rights.