idnits 2.17.00 (12 Aug 2021) /tmp/idnits21237/draft-ietf-pce-inter-layer-req-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 4, 2010) is 4179 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-pce-pcep-mib has been published as RFC 7420 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Takeda (Ed.) 3 Internet Draft NTT 4 Category: Informational A. Farrel 5 Old Dog Consulting 6 Expires: June 4, 2011 December 4, 2010 8 PCC-PCE Communication and PCE Discovery Requirements for 9 Inter-Layer Traffic Engineering 11 draft-ietf-pce-inter-layer-req-15.txt 13 Abstract 15 The Path Computation Element (PCE) provides functions of path 16 computation in support of traffic engineering in Multi-Protocol Label 17 Switching (MPLS) and Generalized MPLS (GMPLS) controlled networks. 19 MPLS and GMPLS networks may be constructed from layered client/server 20 networks. It is advantageous for overall network efficiency to 21 provide end-to-end traffic engineering across multiple network 22 layers. PCE is a candidate solution for such requirements. 24 Generic requirements for a communication protocol between Path 25 Computation Clients (PCCs) and PCEs are presented in RFC 4657, "PCE 26 Communication Protocol Generic Requirements". Generic requirements 27 for a PCE discovery protocol are presented in RFC 4674, "Requirements 28 for Path Computation Element (PCE) Discovery". 30 This document complements the generic requirements and presents 31 detailed sets of PCC-PCE communication protocol requirements and PCE 32 discovery protocol requirements for inter-layer traffic engineering. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Table of Contents 57 1. Introduction...................................................3 58 1.1. Terminology..................................................3 59 2. Motivation for PCE-Based Inter-Layer Path Computation..........4 60 3. PCC-PCE Communication and Discovery Requirements for Inter- 61 Layer Traffic Engineering......................................5 62 3.1. PCC-PCE Communication........................................5 63 3.1.1. Control of Inter-Layer Path Computation....................5 64 3.1.2. Control of The Type of Path to be Computed.................5 65 3.1.3. Communication of Inter-Layer Constraints...................7 66 3.1.4. Adaptation Capability......................................7 67 3.1.5. Cooperation Between PCEs...................................7 68 3.1.6. Inter-Layer Diverse paths..................................7 69 3.2. Capabilities Advertisements for PCE Discovery................8 70 3.3. Supported Network Models.....................................8 71 4. Manageability considerations...................................8 72 4.1. Control of Function and Policy...............................8 73 4.2. Information and Data Models..................................9 74 4.3. Liveness Detection and Monitoring............................9 75 4.4. Verifying Correct Operation..................................9 76 4.5. Requirements on Other Protocols and Functional Components....9 77 4.6. Impact on Network Operation.................................10 78 5. Security Considerations.......................................10 79 6. IANA Considerations...........................................10 80 7. Acknowledgments...............................................11 81 8. References....................................................11 82 8.1. Normative References........................................11 83 8.2. Informative References......................................11 84 9. Authors' Addresses............................................12 86 1. Introduction 88 The Path Computation Element (PCE) defined in [RFC4655] is an entity 89 that is capable of computing a network path or route based on a 90 network graph, and applying computational constraints. 92 A network may comprise multiple layers. These layers may represent 93 separation of technologies (e.g., packet switch capable (PSC), time 94 division multiplex (TDM), lambda switch capable (LSC)) into GMPLS 95 regions [RFC3945], separation of data plane switching granularity 96 levels (e.g., PSC-1 and PSC-2, or VC4 and VC12) into GMPLS layers 97 [RFC5212], or a distinction between client and server networking 98 roles (e.g., commercial or administrative separation of client and 99 server networks). In this multi-layer network, Label Switched Paths 100 (LSPs) in lower layers are used to carry upper-layer LSPs. The 101 network topology formed by lower-layer LSPs and advertised to the 102 higher layer is called a Virtual Network Topology (VNT) [RFC5212]. 104 In layered networks under the operation of Multiprotocol Label 105 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 106 protocols, it is important to provide mechanisms to allow global 107 optimization of network resources. That is, to take into account all 108 layers, rather than optimizing resource utilization at each layer 109 independently. This allows better network efficiency to be achieved. 110 This is what we call Inter-layer traffic engineering. This includes 111 mechanisms allowing computation of end-to-end paths across layers 112 (known as inter-layer path computation), and mechanisms for control 113 and management of the VNT by setting up and releasing LSPs in the 114 lower layers [RFC5212]. 116 Inter-layer traffic engineering is included in the scope of the PCE 117 architecture [RFC4655], and PCE can provide a suitable mechanism for 118 resolving inter-layer path computation issues. The applicability of 119 the PCE-based path computation architecture to inter-layer traffic 120 engineering is described in [RFC5623]. 122 This document presents sets of requirements for communication between 123 path computation clients (PCCs) and PCEs using the PCE communication 124 protocol (PCEP), and for PCE discovery for inter-layer traffic 125 engineering. It supplements the generic requirements documented in 126 [RFC4657] and [RFC4674]. 128 1.1. Terminology 130 LSP: Label Switched Path. 132 LSR: Label Switching Router. 134 PCC: Path Computation Client, any client entity (component, 135 application or network node) requesting a path computation to be 136 performed by a Path Computation Element. 138 PCE: Path Computation Element, an entity that is capable of computing 139 a network path or route based on a network graph and applying 140 computational constraints. 142 PCEP: PCE Communication Protocol, a protocol for communication 143 between PCCs and PCEs. 145 Although this requirements document is an informational document not 146 a protocol specification, the key words "MUST", "MUST NOT", 147 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 148 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 149 interpreted as described in RFC 2119 [RFC2119] for clarity of 150 requirement specification. 152 2. Motivation for PCE-Based Inter-Layer Path Computation 154 [RFC4206] defines a way to signal an MPLS or a GMPLS LSP with an 155 explicit route in a higher layer of a network that includes hops 156 traversed by LSPs in lower layers of the network. The computation of 157 end-to-end paths across layers is called Inter-Layer Path 158 Computation. 160 An LSR in the higher layer might not have information on the topology 161 of lower layers, particularly in an overlay or augmented model, and 162 hence might not be able to compute an end-to-end path across layers. 164 PCE-based inter-layer path computation consists of relying on one or 165 more PCEs to compute an end-to-end path across layers. This could 166 rely on a single PCE path computation where the PCE has topology 167 information about multiple layers and can directly compute an end-to- 168 end path across layers considering the topology of all of the layers. 169 Alternatively, the inter-layer path computation could be performed as 170 a multiple PCE computation where each member of a set of PCEs has 171 information about the topology of one or more layers, but not all 172 layers, and collaborate to compute an end-to-end path. 174 Consider a two-layer network where the higher-layer network is a 175 packet-based IP/MPLS or GMPLS network and the lower-layer network is 176 a GMPLS-controlled optical network. An ingress LSR in the higher- 177 layer network tries to set up an LSP to an egress LSR also in the 178 higher-layer network across the lower-layer network, and needs a path 179 in the higher-layer network. However, suppose that there is no TE 180 link between border LSRs, which are located on the boundary between 181 the higher-layer and lower-layer networks, and that the ingress LSR 182 does not have topology visibility in the lower layer. If a single- 183 layer path computation is applied for the higher layer, the path 184 computation fails. On the other hand, inter-layer path computation is 185 able to provide a route in the higher layer and a suggestion that a 186 lower-layer LSP be setup between border LSRs, considering both layers 187 as TE topologies. 189 Further discussion of the application of PCE to inter-layer path 190 computation can be found in [RFC5623]. 192 3. PCC-PCE Communication and Discovery Requirements for Inter-Layer 193 Traffic Engineering 195 This section sets out additional requirements specific to the 196 problems of multi-layer TE that are not covered in [RFC4657] or 197 [RFC4674]. 199 3.1. PCC-PCE Communication 201 PCEP MUST allow requests and replies for inter-layer path 202 computation. 204 This requires no additional messages, but implies the following 205 additional constraints to be added to PCEP. 207 3.1.1. Control of Inter-Layer Path Computation 209 A request from a PCC to a PCE MUST support the inclusion of an 210 optional indication of whether inter-layer path computation is 211 allowed. In the absence of such an indication, the default is that 212 inter-layer path computation is not allowed. 214 3.1.2. Control of The Type of Path to be Computed 216 The PCE computes and returns a path to the PCC that the PCC can use 217 to build a higher-layer or lower-layer LSP once converted to an 218 Explicit Route Object (ERO) for use in RSVP-TE signaling. There are 219 two options [RFC5623]. 221 - Option 1: Mono-layer path. The PCE computes a "mono layer" path, 222 i.e., a path that includes only TE links from the same layer. 224 - Option 2: Multi-layer path. The PCE computes a "multi-layer" path, 225 i.e., a path that includes TE links from distinct layers [RFC4206]. 227 It may be necessary or desirable for a PCC to control the type of 228 path that is produced by a PCE. For example, a PCC may know that it 229 is not possible for technological or policy reasons to signal a 230 multi-layer path and that a mono-layer path is required, or the PCC 231 may know that it does not wish the layer border node to have control 232 of path computation. In order to make this level of control possible, 233 PCEP MUST allow the PCC to select the path types to be computed, and 234 that may be returned, by choosing one or more from the following 235 list: 237 - A mono-layer path that is specified by strict hop(s). The path may 238 include virtual TE link(s). 240 - A mono-layer path that includes loose hop(s). 242 - A multi-layer path that can include the path (as strict or loose 243 hops) of one or more lower-layer LSPs not yet established. 245 The path computation response from a PCE to a PCC MUST report the 246 type of path computed, and where a multi-layer path is returned, PCEP 247 MUST support the inclusion, as part of end-to-end path, of the path 248 of the lower-layer LSPs to be established. 250 If a response message from a PCE to PCC carries a mono-layer path 251 that is specified by strict hops but includes virtual TE link(s), or 252 includes loose hop(s), or carries a multi-layer path that can include 253 the complete path of one or more lower-layer LSPs not yet 254 established, the signaling of the higher-layer LSP may trigger the 255 establishment of the lower-layer LSPs (triggered signaling). The 256 triggered signaling may increase the higher-layer connection setup 257 latency. An ingress LSR for the higher-layer LSP, or a PCC, needs to 258 know whether triggered signaling is required or not. 260 A request from a PCC to a PCE MUST allow indicating whether triggered 261 signaling is acceptable or not. 263 A response from a PCE to a PCC MUST allow indicating whether the 264 computed path requires triggered signaling or not. 266 Note that a PCE may not be able to distinguish virtual TE links from 267 regular TE links. In such cases, even if a request from a PCC to a 268 PCE indicates that triggered signaling is not acceptable, a PCE may 269 choose virtual TE links in path computation. Therefore, when a 270 network uses virtual TE links and a PCE is not able to distinguish 271 virtual TE links from regular TE links, it MUST be understood that a 272 PCE may choose virtual TE links even if a request from a PCC to a PCE 273 indicates triggered signaling is not acceptable. 275 Also note that an ingress LSR may be present in multiple layers. 276 Thus, when a mono-layer path is requested or supplied, PCEP MUST be 277 able to indicate the required/provided path layer. 279 3.1.3. Communication of Inter-Layer Constraints 281 A request from a PCC to a PCE MUST support the inclusion of 282 constraints for a multi-layer path. This includes control over which 283 network layers may, must, or must not be included in the computed 284 path. Such control may be expressed in terms of the switching types 285 of the layer networks. 287 Furthermore, it may be desirable to constrain the number of layer 288 boundaries crossed (i.e., the number of adaptations performed on the 289 end-to-end path), so PCEP SHOULD include a constraint or objective 290 function to minimize or cap the number of adaptations on a path, and 291 a mechanism to report that number when a path is supplied. 293 The path computation request MUST also allow for different objective 294 functions to be applied within different network layers. For example, 295 the path in a packet-network may need to be optimized for least delay 296 using the IGP metric as a measure of delay, while the path in an 297 under-lying TDM network might be optimized for fewest hops. 299 3.1.4. Adaptation Capability 301 It MUST be possible for the path computation request to indicate the 302 desired adaptation function at the end points of the lower-layer LSP 303 that is being computed. This will be particularly important where the 304 ingress and egress LSR participate in more than one layer network but 305 may not be capable of all associated adaptations. 307 3.1.5. Cooperation Between PCEs 309 When each layer is in scope of a different PCE, which only has access 310 to the topology information of its layer, the PCEs of each layer need 311 to cooperate to perform inter-layer path computation. In this case, 312 communication between PCEs is required for inter-layer path 313 computation. A PCE that behaves as a client is defined as a PCC 314 [RFC4655]. 316 PCEP MUST allow requests and replies for multiple PCE inter-layer 317 path computation. 319 3.1.6. Inter-Layer Diverse paths 321 PCEP MUST allow for the computation of diverse inter-layer paths. A 322 request from a PCC to a PCE MUST support the inclusion of multiple 323 path requests, with the desired level of diversity at each layer 324 (link, node, SRLG). 326 3.2. Capabilities Advertisements for PCE Discovery 328 In the case where there are several PCEs with distinct capabilities 329 available, a PCC has to select one or more appropriate PCEs. For that 330 purpose, the PCE discovery mechanism MAY support the disclosure of 331 some detailed PCE capabilities. A PCE MAY (to be consistent with the 332 above text and RFC4674) be able to advise the following inter-layer- 333 path-computation-related PCE capabilities: 335 - Support for inter-layer path computation 336 - Support for mono-layer/multi-layer paths 337 - Support for inter-layer constraints 338 - Support for adaptation capability 339 - Support for inter-PCE communication 340 - Support for inter-layer diverse path computation 342 3.3. Supported Network Models 344 PCEP SHOULD allow several architectural alternatives for interworking 345 between MPLS and GMPLS-controlled networks: overlay, integrated and 346 augmented models [RFC3945], [RFC5145], [RFC5146]. 348 4. Manageability considerations 350 4.1. Control of Function and Policy 352 An individual PCE MAY elect to support inter-layer computations and 353 advertise its capabilities as described in the previous sections. PCE 354 implementations MAY provide a configuration switch to allow support 355 of inter-layer path computations to be enabled or disabled. When the 356 level of support is changed, this SHOULD be re-advertised. 358 However, a PCE MAY also elect to support inter-layer computations, 359 but not to advertise the fact, so that only those PCCs configured to 360 know of the PCE and its capabilities can use it. 362 Support for, and advertisement of support for, inter-layer path 363 computation MAY be subject to policy and a PCE MAY hide its inter- 364 layer capabilities from certain PCCs by not advertising them through 365 the discovery protocol, and not reporting them to the specific PCCs 366 in any PCEP capabilities exchange. Further, a PCE MAY be directed by 367 policy to refuse an inter-layer path computation request for any 368 reason including, but not limited to, the identity of the PCC that 369 makes the request. 371 4.2. Information and Data Models 373 PCEP extensions to support inter-layer computations MUST be 374 accompanied by MIB objects for the control and monitoring of the 375 protocol and of the PCE that performs the computations. The MIB 376 objects MAY be provided in the same MIB module as used for general 377 PCEP control and monitoring [PCEP-MIB] or MAY be provided in a new 378 MIB module. 380 The MIB objects MUST provide the ability to control and monitor all 381 aspects of PCEP relevant to inter-layer path computation. 383 4.3. Liveness Detection and Monitoring 385 No changes are necessary to the liveness detection and monitoring 386 requirements as already embodied in [RFC4657]. It should be noted, 387 however, that inter-layer path computations might require extended 388 cooperation between PCEs (as is also the case for inter-AS and inter- 389 area computations) and so the liveness detection and monitoring 390 SHOULD be applied to each PCEP communication and aggregated to report 391 the behavior of an individual PCEP request to the originating PCC. 393 In particular, where a request is forwarded between multiple PCEs 394 neither the PCC nor the first PCE can monitor the liveness of all 395 PCE-PCE connections or of the PCEs themselves. In this case, suitable 396 performance of the original PCEP request relies on each PCE operating 397 correct monitoring procedures and correlating any failures back to 398 the PCEP requests that are outstanding. These requirements are no 399 different from those for any cooperative PCE usage, and are expected 400 to be already covered by general, and by inter-AS and inter-area 401 implementations. Such a procedure is specified in [RFC5441]. In 402 addition, [RFC5886] specifies mechanisms to gather various state 403 metrics along the path computation chain. 405 4.4. Verifying Correct Operation 407 There are no additional requirements beyond those expressed in 408 [RFC4657] for verifying the correct operation of the PCEP. Note that 409 verification of the correct operation of the PCE and its algorithms 410 is out of scope for the protocol requirements, but a PCC MAY send the 411 same request to more than one PCE and compare the results. 413 4.5. Requirements on Other Protocols and Functional Components 415 A PCE operates on a topology graph that may be built using 416 information distributed by TE extensions to the routing protocol 417 operating within the network. In order that the PCE can select a 418 suitable path for the signaling protocol to use to install the inter- 419 layer LSP, the topology graph must include information about the 420 inter-layer signaling and forwarding (i.e. adaptation) capabilities 421 of each LSR in the network. 423 Whatever means are used to collect the information to build the 424 topology graph, the graph MUST include the requisite information. If 425 the TE extensions to the routing protocol are used, these SHOULD 426 satisfy the requirements as described in [RFC5212]. 428 4.6. Impact on Network Operation 430 The use of a PCE to compute inter-layer paths is not expected to have 431 significant impact on network operations if the upper layer Traffic 432 Engineering practices are aware of the frequent changes that might 433 occur in the VNT. It should also be noted that the introduction of 434 inter-layer support to a PCE that already provides mono-layer path 435 computation might change the loading of the PCE and that might have 436 an impact on the network behavior especially during recovery periods 437 immediately after a network failure. 439 On the other hand, it is envisioned that the use of inter-layer path 440 computation will have significant benefits to the operation of a 441 multi-layer network including improving the network resource usage 442 and enabling a greater number of higher-layer LSPs to be supported. 444 5. Security Considerations 446 Inter-layer traffic engineering with PCE may raise new security 447 issues when PCE-PCE communication is done between different layer 448 networks for inter-layer path computation. Security issues may also 449 exist when a single PCE is granted full visibility of TE information 450 that applies to multiple layers. 452 The formal introduction of a VNT Manager component as described in 453 [RFC5623] provides the basis for the application of inter-layer 454 security and policy. 456 It is expected that solutions for inter-layer protocol extensions 457 will address these issues in detail. 459 6. IANA Considerations 461 This Informational document makes no requests for IANA action. 463 7. Acknowledgments 465 We would like to thank Kohei Shiomoto, Ichiro Inoue, Dean Cheng, 466 Meral Shirazipour, Julien Meuric, and Stewart Bryant for their useful 467 comments. Thanks to members of ITU-T Study Group 15 Question 14 for 468 their constructive comments during the liaison process. 470 8. References 472 8.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 475 requirements levels", RFC 2119, March 1997. 477 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 478 Architecture", RFC 3945, October 2004. 480 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) 481 Hierarchy with Generalized Multi-Protocol Label Switching 482 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 484 8.2. Informative References 486 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 487 Element (PCE)-Based Architecture", RFC 4655, September 488 2006. 490 [RFC4657] J. Ash, J.L Le Roux et al., " Path Computation Element 491 (PCE) Communication Protocol Generic Requirements", RFC 492 4657, September 2006. 494 [RFC4674] JL Le Roux et al., "Requirements for Path Computation 495 Element (PCE) Discovery", RFC 4674, September 2006. 497 [RFC5145] K. Shiomoto, "Framework for MPLS-TE to GMPLS Migration", 498 RFC 5145, March 2008. 500 [RFC5146] K. Kumaki et al., "Interworking Requirements to Support 501 Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 502 2008. 504 [RFC5212] K. Shiomoto et al., "Requirements for GMPLS-Based Multi- 505 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 506 2008. 508 [RFC5623] E. Oki et al., "Framework for PCE-Based Inter-Layer MPLS 509 and GMPLS Traffic Engineering", RFC 5623, September 2009. 511 [PCEP-MIB] A. Koushik, and E. Stephan, "PCE communication protocol 512 (PCEP) Management Information Base", draft-ietf-pce-pcep- 513 mib (work in progress). 515 [RFC5441] JP. Vasseur (Ed.), "A Backward-Recursive PCE-Based 516 Computation (BRPC) Procedure to Compute Shortest 517 Constrained Inter-Domain Traffic Engineering Label Switched 518 Paths", RFC 5441, April 2009. 520 [RFC5886] JP. Vasseur (Ed.), "A Set of Monitoring Tools for Path 521 Computation Element (PCE)-Based Architecture", RFC 5886, 522 June 2010. 524 9. Authors' Addresses 526 Eiji Oki 527 University of Electro-Communications 528 Tokyo, Japan 529 Email: oki@ice.uec.ac.jp 531 Jean-Louis Le Roux 532 France Telecom R&D, 533 Av Pierre Marzin, 534 22300 Lannion, France 535 Email: jeanlouis.leroux@orange-ftgroup.com 537 Kenji Kumaki 538 KDDI Corporation 539 Garden Air Tower 540 Iidabashi, Chiyoda-ku, 541 Tokyo 102-8460, JAPAN 542 Email: ke-kumaki@kddi.com 544 Adrian Farrel 545 Old Dog Consulting 546 Email: adrian@olddog.co.uk 548 Tomonori Takeda 549 NTT 550 3-9-11 Midori-cho, 551 Musashino-shi, Tokyo 180-8585, Japan 552 Email: takeda.tomonori@lab.ntt.co.jp 554 Full Copyright Statement 556 Copyright (c) 2010 IETF Trust and the persons identified as the 557 document authors. All rights reserved. 559 This document is subject to BCP 78 and the IETF Trust's Legal 560 Provisions Relating to IETF Documents 561 (http://trustee.ietf.org/license-info) 562 in effect on the date of publication of this document. Please 563 review these documents carefully, as they describe your rights and 564 restrictions with respect to this document. Code Components 565 extracted from this document must include Simplified BSD License 566 text as described in Section 4.e of the Trust Legal Provisions and 567 are provided without warranty as described in the Simplified BSD 568 License.