idnits 2.17.1 draft-oki-pce-inter-layer-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. 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 is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2007) is 6009 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) ** Downref: Normative reference to an Informational draft: draft-ietf-pce-inter-layer-req (ref. 'PCE-INTER-LAYER-REQ') -- Possible downref: Normative reference to a draft: ref. 'PCE-INTER-LAYER-FRWK' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Oki 2 Internet Draft NTT 3 Category: Standards Track J-L Le Roux 4 Expires: April 2008 France Telecom 5 A. Farrel 6 Old Dog Consulting 7 October 2007 9 Extensions to the Path Computation Element communication Protocol 10 (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering 12 draft-oki-pce-inter-layer-ext-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The Path Computation Element (PCE) provides path computation 41 functions in support of traffic engineering in Multi-Protocol Label 42 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 44 MPLS and GMPLS networks may be constructed from layered service 45 networks. It is advantageous for overall network efficiency to 46 provide end-to-end traffic engineering across multiple network 47 layers through a process called inter-layer traffic engineering. 48 PCE is a candidate solution for such requirements. 50 The PCE communication Protocol (PCEP) is designed as a 51 communication protocol between Path Computation Clients (PCCs) and 52 PCEs. This document presents PCEP extensions for inter-layer 53 traffic engineering. 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 59 this document are to be interpreted as described in RFC 2119 60 [RFC2119]. 62 Table of Contents 64 1. Introduction.................................................2 65 2. Overview of PCE-Based Inter-Layer Path Computation...........3 66 3. Protocol Extensions..........................................4 67 3.1. INTER-LAYER Object........................................4 68 3.2. SWITCH-LAYER Object.......................................5 69 3.2.1. REQ-ADAP-CAP Object......................................7 70 4. Procedure....................................................7 71 4.1. Path Computation Request..................................7 72 4.2. Path Computation Reply....................................8 73 5. Updated Format of PCEP Messages..............................8 74 6. Manageability considerations.................................9 75 7. IANA considerations.........................................10 76 8. Security Considerations.....................................10 77 9. Acknowledgments.............................................10 78 10. References.................................................10 79 10.1. Normative Reference......................................10 80 10.2. Informative Reference....................................11 81 11. Authors' Addresses.........................................11 82 12. Intellectual Property Statement............................11 84 1. Introduction 86 The Path Computation Element (PCE) defined in [RFC4655] is an 87 entity that is capable of computing a network path or route based 88 on a network graph, and applying computational constraints. A Path 89 Computation Client (PCC) may make requests to a PCE for paths to be 90 computed. 92 A network may comprise multiple layers. These layers may represent 93 separations of technologies (e.g., packet switch capable (PSC), 94 time division multiplex (TDM), lambda switch capable (LSC)) 96 Oki, Le Roux, and Farrel Expires April 2008 2 98 [RFC3945], separation of data plane switching granularity levels 99 (e.g., PSC-1 and PSC-2, or VC4 and VC12) [MLN-REQ], or a 100 distinction between client and server networking roles (e.g., 101 commercial or administrative separation of client and server 102 networks). In this multi-layer network, Label Switched Paths (LSPs) 103 in lower layers are used to carry upper-layer LSPs. The network 104 topology formed by lower-layer LSPs and advertised to the higher 105 layer is called a Virtual Network Topology (VNT) [MLN-REQ]. 107 It is important to optimize network resource utilization globally, 108 i.e., taking into account all layers, rather than optimizing 109 resource utilization at each layer independently. This allows 110 better network efficiency to be achieved. This is what we call 111 inter-layer traffic engineering. This includes mechanisms allowing 112 the computation of end-to-end paths across layers (known as inter- 113 layer path computation), and mechanisms for control and management 114 of the VNT by setting up and releasing LSPs in the lower layers 115 [MLN-REQ]. 117 PCE can provide a suitable mechanism for resolving inter-layer path 118 computation issues. The framework for applying the PCE-based path 119 computation architecture to inter-layer traffic engineering is 120 described in [PCE-INTER-LAYER-FRWK]. 122 The PCE communication protocol (PCEP) is designed as a 123 communication protocol between PCCs and PCEs and is defined in 124 [PCEP]. A set of requirements for PCEP extensions to support inter- 125 layer traffic engineering is described in [PCE-INTER-LAYER-REQ]. 127 This document presents PCEP extensions for inter-layer traffic 128 engineering that satisfy the requirements described in [PCE-INTER- 129 LAYER-REQ]. 131 2. Overview of PCE-Based Inter-Layer Path Computation 133 [RFC4206] defines a way to signal a higher-layer LSP which has an 134 explicit route that includes hops traversed by LSPs in lower layers. 135 The computation of end-to-end paths across layers is called Inter- 136 Layer Path Computation. 138 A Label Switching Router (LSR) in the higher-layer might not have 139 information on the lower-layer topology, particularly in an overlay 140 or augmented model [RFC3945], and hence may not be able to compute 141 an end-to-end path across layers. 143 PCE-based inter-layer path computation consists of using one or 144 more PCEs to compute an end-to-end path across layers. This could 145 be achieved by relying on a single PCE that has topology 146 information about multiple layers and can directly compute an end- 147 to-end path across layers considering the topology of all of the 149 Oki, Le Roux, and Farrel Expires April 2008 3 150 layers. Alternatively, the inter-layer path computation could be 151 performed using multiple cooperating PCEs where each PCE has 152 information about the topology of one or more layers (but not all 153 layers) and where the PCEs collaborate to compute an end-to-end 154 path. 156 [PCE-INTER-LAYER-FRWK] describes models for inter-layer path 157 computation in more detail. 159 3. Protocol Extensions 161 This section describes PCEP extensions for inter-layer path 162 computation. Three new objects are defined: the INTER-LAYER object, 163 the SWITCH-LAYER object, and the REQ-ADAP-CAP object. 165 3.1. INTER-LAYER Object 167 The INTER-LAYER object is optional and can be used in PCReq and 168 PCRep messages. 170 In a PCReq message, the INTER-LAYER object indicates whether inter- 171 layer path computation is allowed, the type of path to be computed, 172 and whether nested signaling is allowed. When the INTER-LAYER 173 object is absent from a PCReq message, the receiving PCE SHOULD 174 process as though inter-layer path computation had been explicitly 175 disallowed (I-bit set to zero - see below). 177 In a PCRep message, the INTER-LAYER object indicates whether inter- 178 layer path computation has been performed, the type of path that 179 has been computed, and whether nested signaling is used. 181 When a PCReq message includes more than one request, an INTER-LAYER 182 object is used per request. When a PCRep message includes more than 183 one path per request, an INTER-LAYER object is used per path. 185 INTER-LAYER Object-Class is to be assigned by IANA (recommended 186 value=18) 188 INTER-LAYER Object-Type is to be assigned by IANA (recommended 189 value=1) 191 Oki, Le Roux, and Farrel Expires April 2008 4 192 The format of the INTER-LAYER object body is as follows: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Reserved |N|I| 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 I flag (1 bit): the I flag is used by a PCC in a PCReq message to 201 indicate to a PCE whether an inter-layer path is allowed. When the 202 I flag is set (one), the PCE MAY perform inter-layer path 203 computation and return an inter-layer path. When the flag is clear 204 (zero), the path that is returned MUST NOT be an inter-layer path. 206 The I flag is used by a PCE in a PCRep message to indicate to a PCC 207 whether the path returned is an inter-layer path. When the I flag 208 is set (one), the path is an inter-layer path. When it is clear 209 (zero), the path is contained within a single layer either because 210 inter-layer path computation was not performed or because a mono- 211 layer path was found notwithstanding the use of inter-layer path 212 computation. 214 N flag (1 bit): the N flag is used by a PCC in a PCReq message to 215 indicate to a PCE whether nested signaling is allowed. When the N 216 flag is set (one), nested signaling is allowed. When it is clear 217 (zero), nested signaling is not allowed. 219 The N flag is used by a PCE in a PCRep message to indicate to a PCC 220 whether nested signaling is required to support the returned path. 221 When the N flag is set (one), nested signaling is required. When it 222 is clear (zero), nested signaling is not required. 224 Note that nested signaling is used to support hierarchical 225 [RFC4206] or stitched [LSP-STITCH] LSPs according to the physical 226 attributes of the network layers. 228 If the I flag is clear (zero), the N flag has no meaning and MUST 229 be ignored. 231 Reserved bits of the INTER-LAYER object SHOULD be transmitted as 232 zero and SHOULD be ignored on receipt. A PCE that forwards a path 233 computation request to other PCEs SHOULD preserve the settings of 234 reserved bits in the PCReq messages it sends and in the PCRep 235 messages it forwards to PCCs. 237 3.2. SWITCH-LAYER Object 239 The SWITCH-LAYER object is optional on a PCReq message and 240 specifies switching layers in which a path MUST, or MUST NOT be 242 Oki, Le Roux, and Farrel Expires April 2008 5 243 established. A switching layer is expressed as a switching type and 244 encoding type. The SWITCH-LAYER object MUST NOT be used on a PCRep 245 unless an INTER-LAYER object is also present on the PCReq message. 247 The SWITCH-LAYER object is optional on a PCRep message, where it is 248 used with the NO-PATH object in the case of unsuccessful path 249 computation to indicate the set of constraints that could not be 250 satisfied. 252 SWTICH-LAYER Object-Class is to be assigned by IANA (recommended 253 value=19) 255 SWTICH-LAYER Object-Type is to be assigned by IANA (recommended 256 value=1) 258 The format of the SWTICH-LAYER object body is as follows: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | LSP Enc. Type |Switching Type | Reserved |I| 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | . | 265 // . // 266 | . | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | LSP Enc. Type |Switching Type | Reserved |I| 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Each row indicates the switching type and encoding type that MUST, 272 or MUST NOT be used for specified layer(s) in the computed path. 274 LSP Encoding Type (8 bits): see [RFC3471] for a description of 275 parameters. 277 Switching Type (8 bits): see [RFC3471] for a description of 278 parameters. 280 I flag (1 bit): the I flag indicates whether or NOT a layer with 281 the specified switching type and encoding type MUST be used by the 282 computed path. When the I flag is set (one), the computed path MUST 283 traverse a layer with the specified switching type and encoding 284 type. When the I flag is clear (zero), the computed path MUST NOT 285 enter or traverse any layer with the specified switching type and 286 encoding type. 288 A PCC may want to specify only a Switching Type and not an LSP 289 Encoding Type. In this case, the LSP Encoding Type is set to zero. 291 Oki, Le Roux, and Farrel Expires April 2008 6 293 3.2.1. 294 REQ-ADAP-CAP Object 296 The REQ-ADAP-CAP object is optional and is used to specify a 297 requested adaptation capability for both ends of the lower layer 298 LSP. The REQ-ADAP-CAP object is used in inter-PCE communication, 299 where the PCE that is responsible for computing higher layer paths 300 acts as a PCC to request a path computation from a PCE that is 301 responsible for computing lower layer paths. 303 The REQ-ADAP-CAP object can be carried within a PCReq message and a 304 PCRep message. It is used in a PCRep message in case of 305 unsuccessful path computation (in this case, the PCRep message also 306 contains a NO-PATH object and the REQ-ADAP-CAP object is used to 307 indicate the set of constraints that could not be satisfied). 309 The REQ-ADAP-CAP object MAY be used in a mono-layer network to 310 specify a requested adaptation capability for both ends of the LSP. 311 In this case, it MAY be carried without INTER-LAYER Object. 313 REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended 314 value=20) 316 REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended 317 value=1) 319 The format of the REQ-ADAP-CAP object body is as follows: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Switching Cap | Encoding | Reserved | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Switching Capability (8 bits): see [RFC4203] for a description of 328 parameters. 330 Encoding (8 bits): see [RFC3471] for a description of parameters. 332 A PCC may want to specify a Switching Capability, but not an 333 Encoding. In this case, the Encoding MUST be set zero. 335 4. Procedure 337 4.1. Path Computation Request 339 A PCC requests inter-layer path computation in a PCReq message by 340 including the INTER-LAYER object with the I flag set. The INTER- 341 LAYER object indicates whether inter-layer path computation is 342 allowed and whether nested signaling is allowed. 344 Oki, Le Roux, and Farrel Expires April 2008 7 345 The SWITCH-LAYER object, which MUST NOT be present unless the 346 INTER-LAYER object is also present, is optionally used to specify 347 the switching types and encoding types that define layers that MUST, 348 or MUST NOT, be used in the computed path. 350 The REQ-ADAP-CAP object is optionally used to specify the interface 351 switching capability of both ends of the lower layer LSP. The REQ- 352 ADAP-CAP object is used in inter-PCE communication, where the PCE 353 that is responsible for computing higher layer paths makes a 354 request as a PCC to a PCE that is responsible for computing lower 355 layer paths. 357 4.2. Path Computation Reply 359 The requested PCE replies to the requesting PCC for the inter-layer 360 path computation result in a PCRep message including the INTER- 361 LAYER object. 363 In the case of unsuccessful path computation, the PCRep message 364 also contains a NO-PATH object, and the SWITCH-TYPE object and/or 365 the REQ-ADAP-CAP MAY be used to indicate the set of constraints 366 that could not be satisfied. 368 5. Updated Format of PCEP Messages 370 The format of the PCReq message is updated as follows: 372 ::= 373 [] 374 376 where: 377 ::= 378 [] 380 ::=[] 382 ::= 383 384 [] 385 [] 386 [] 387 [] 388 [] 389 [] 390 [] 391 [] 393 Oki, Le Roux, and Farrel Expires April 2008 8 395 [] 396 [] 397 where: 399 ::=[] 401 The format of the PCRep message is updated as follows: 403 ::= 404 406 where: 407 ::=[] 409 ::= 410 [] 411 [] 413 ::=[] 415 ::= 416 [] 417 [] 418 [] 419 [] 420 [] 421 [] 422 [] 423 [] 425 where: 426 ::=[] 428 6. Manageability considerations 430 TBD 432 Manageability of inter-layer traffic engineering with PCE must 433 address the following consideration for section 5.1. 435 - need for a MIB module for control and monitoring 436 - need for built-in diagnostic tools 438 Oki, Le Roux, and Farrel Expires April 2008 9 439 - configuration implication for the protocol 441 7. IANA considerations 443 TBD 445 8. Security Considerations 447 TBD 449 Inter-layer traffic engineering with PCE may raise new security 450 issues when PCE-PCE communication is done between different layer 451 networks for inter-layer path computation. Security issues may also 452 exist when a single PCE is granted full visibility of TE 453 information that applies to multiple layers. 455 It is expected that solutions for inter-layer protocol extensions 456 will address these issues in detail using security techniques such 457 as authentication. 459 9. Acknowledgments 461 10. References 463 10.1. Normative Reference 465 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 466 requirements levels", RFC 2119, March 1997. 468 [RFC3471] L. Burger, "Generalized Multi-Protocol Label Switching 469 (GMPLS)�E RFC 3471, January 2003. 471 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 472 Architecture", RFC 3945, October 2004. 474 [RFC4203] K. Kompella and Y. Rekhter, "OSPF Extensions in Support 475 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, 476 October 2005. 478 [RFC4206] K. Kompella, and Y. Rekhter, "Label Switched Paths (LSP) 479 Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) 480 Traffic Engineering (TE)", RFC 4206, October 2005. 482 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 483 communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep 484 (work in progress). 486 Oki, Le Roux, and Farrel Expires April 2008 10 488 [PCE-INTER-LAYER-REQ] E. Oki et al., "PCC-PCE Communication 489 Requirements for Inter-Layer Traffic Engineering", draft-ietf-pce- 490 inter-layer-req (work in progress). 492 [PCE-INTER-LAYER-FRWK] E. Oki et al., "Framework for PCE-Based 493 Inter-Layer MPLS and GMPLS Traffic Engineering", draft-oki-pce- 494 inter-layer-frwk (work in progress) 496 10.2. Informative Reference 498 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 499 Element (PCE)-Based Architecture", RFC 4655, September 2006. 501 [MLN-REQ] K. Shiomoto et al., "Requirements for GMPLS-based multi- 502 region and multi-layer networks (MRN/MLN)", draft-ietf-ccamp-gmpls- 503 mln-reqs (work in progress). 505 [LSP-STITCH] A. Ayyangar et al., "Label Switched Path Stitching 506 with Generalized Multiprotocol Label Switching Traffic Engineering 507 (GMPLS TE) ", draft-ietf-ccamp-lsp-stitching (work in progress). 509 11. Authors' Addresses 511 Eiji Oki 512 NTT 513 3-9-11 Midori-cho, 514 Musashino-shi, Tokyo 180-8585, Japan 515 Email: oki.eiji@lab.ntt.co.jp 517 Jean-Louis Le Roux 518 France Telecom R&D, 519 Av Pierre Marzin, 520 22300 Lannion, France 521 Email: jeanlouis.leroux@orange-ftgroup.com 523 Adrian Farrel 524 Old Dog Consulting 525 Email: adrian@olddog.co.uk 527 12. Intellectual Property Statement 529 The IETF takes no position regarding the validity or scope of any 530 Intellectual Property Rights or other rights that might be claimed 531 to pertain to the implementation or use of the technology described 532 in this document or the extent to which any license under such 533 rights might or might not be available; nor does it represent that 534 it has made any independent effort to identify any such rights. 535 Information on the procedures with respect to rights in RFC 536 documents can be found in BCP 78 and BCP 79. 538 Oki, Le Roux, and Farrel Expires April 2008 11 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use 542 of such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository 544 at http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at ietf- 550 ipr@ietf.org. 552 Disclaimer of Validity 554 This document and the information contained herein are provided on 555 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 556 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 557 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 558 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 559 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 560 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 561 FOR A PARTICULAR PURPOSE. 563 Copyright Statement 565 Copyright (C) The IETF Trust (2007). 567 This document is subject to the rights, licenses and restrictions 568 contained in BCP 78, and except as set forth therein, the authors 569 retain all their rights. 571 Oki, Le Roux, and Farrel Expires April 2008 12