idnits 2.17.1 draft-ietf-pce-discovery-reqs-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 600. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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 Internet-Drafts being working documents. ** 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 524, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J.L. Le Roux (Editor) 2 Internet Draft France Telecom 3 Category: Informational 4 Expires: January 2006 6 July 2005 8 Requirements for Path Computation Element (PCE) Discovery 10 draft-ietf-pce-discovery-reqs-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document presents a set of requirements for a Path Computation 39 Element (PCE) discovery mechanism that would allow a Path Computation 40 Client (PCC) to discover dynamically and automatically a set of PCEs 41 along with certain information relevant for PCE selection. It is 42 intended that solutions that specify procedures and protocol(s) or 43 protocol(s) extensions for such PCE discovery satisfy these 44 requirements. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC-2119. 52 Table of Contents 54 1. Contributors................................................2 55 2. Terminology.................................................3 56 3. Introduction................................................3 57 4. Problem Statement and Requirements overview.................4 58 4.1. Problem Statement...........................................4 59 4.2. Requirements overview.......................................5 60 5. Example of application scenario.............................6 61 6. Detailed Requirements.......................................7 62 6.1. PCE Information to be disclosed.............................7 63 6.1.1. Discovery of PCE Location...................................7 64 6.1.2. Discovery of PCE computation scope(s) and domain(s) 65 under control...............................................7 66 6.1.3. Discovery of PCE Capabilities...............................8 67 6.1.4. Discovery of Alternate PCEs.................................8 68 6.2. Scope of PCE Discovery......................................9 69 6.3. PCE Information Synchronization.............................9 70 6.4. Detecting PCE Liveliness....................................9 71 6.5. Discovery of PCE capacity and congestion...................10 72 6.6. Security Requirements......................................10 73 6.7. Extensibility..............................................10 74 6.8. Scalability................................................10 75 7. Security Considerations....................................11 76 8. Acknowledgments............................................11 77 9. References.................................................11 78 10. Authors' Addresses:........................................11 79 11. Intellectual Property Statement............................12 81 1. Contributors 83 The following are the authors that contributed to the present 84 document: 86 Jean-Louis Le Roux (France Telecom) 87 Paul Mabey (Qwest Communications) 88 Eiji Oki (NTT) 89 Richard Rabbat (Fujitsu) 90 Ting Wo Chung (Bell Canada) 91 Raymond Zhang (BT Infonet) 93 2. Terminology 95 Terminology used in this document 97 LSR: Label Switch Router 99 TE-LSP: Traffic Engineered Label Switched Path 101 PCE: Path Computation Element: an entity (component, application, 102 or network node) that is capable of computing a network path or 103 route based on a network graph, and applying computational 104 constraints. 106 PCC: Path Computation Client: any client application requesting a 107 path computation to be performed by a Path Computation Element. 109 IGP Area: OSPF Area or ISIS level/area 111 ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router) 113 AS: Autonomous System 115 ASBR: AS Border Router 117 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 118 boundaries. 120 Inter-area TE LSP: A TE LSP whose path transits through 121 two or more IGP areas. 123 Inter-AS MPLS TE LSP: A TE LSP whose path transits 124 through two or more ASes or sub-ASes (BGP confederations). 126 Domain: any collection of network elements within a common sphere 127 of address management or path computational responsibility. 128 Examples of domains include IGP areas and Autonomous Systems. 130 3. Introduction 132 The PCE Architecture [PCE-ARCH] defines a Path Computation Element 133 (PCE) as an entity capable of computing TE-LSPs paths satisfying a 134 set of constraints. A PCE serves path computation requests sent by 135 Path Computation Clients (PCC). 136 A PCC is a client application requesting a path computation to be 137 performed by a PCE. This can be, for instance, an LSR requesting a 138 path for a TE-LSP for which it is the head-end, or a PCE requesting a 139 path computation of another PCE (inter-PCE communication). The 140 communication between a PCC and a PCE requires a client-server 141 protocol whose generic requirements are listed in [PCE-COM-REQ]. 143 There are several motivations for the adoption of a PCE-based 144 architecture to perform a path computation. They are listed in [PCE- 145 ARCH]. This includes applications such as CPU intensive path 146 computation, inter-domain path computation and backup path 147 computation. 149 The PCE architecture requires, of course, that a PCC be aware of the 150 location of one or more PCEs in its domain, and also potentially of 151 some PCEs in other domains, for inter-domain path computation. 153 In that context it would be highly desirable to define a mechanism 154 for automatic and dynamic PCE discovery, which would allow PCCs to 155 automatically discover a set of PCEs, including information required 156 for PCE selection, and to dynamically detect new PCEs or any 157 modification of PCE's information. This includes the discovery by a 158 PCC of a set of one or more PCEs in its domain, and potentially in 159 some other domains. The latter is a desirable function in the case of 160 inter-domain path computation for example. 162 This document lists a set of functional requirements for such an 163 automatic and dynamic PCE discovery mechanism. Section 3 points out 164 the problem statement. Section 4 illustrates an application scenario. 165 Finally section 5 addresses detailed requirements. 167 It is intended that solutions that specify procedures and protocol(s) 168 or protocol(s) extensions for such PCE discovery satisfy these 169 requirements. There is no intent either to specify solution specific 170 requirements or to make any assumption on the protocol(s) that could 171 be used for the discovery. 173 Note that requirements listed in this document apply equally to MPLS- 174 TE and GMPLS-capable PCEs. 176 It is also important to note that the notion of a PCC encompasses a 177 PCE acting as PCC when requesting a path computation of another PCE 178 (inter-PCE communication). Hence, this document does not make the 179 distinction between PCE discovery by PCCs and PCE discovery by PCEs. 181 4. Problem Statement and Requirements overview 183 4.1. Problem Statement 185 A routing domain may in practice be comprised of multiple PCEs: 186 -The path computation load may be balanced among a set of PCEs 187 to improve scalability; 188 -For the purpose of redundancy, primary and backup PCEs may be 189 used; 190 -PCEs may have distinct path computation capabilities (multi- 191 constrained path computation, backup path computation...); 192 -In an inter-domain context there can be several PCEs with 193 distinct path computation scopes (intra-area, inter-area, 194 inter-AS, inter-layer), each PCE being responsible for path 195 computation in one or more domains within its scope. 197 As an example, in a multi-area network made of one backbone area and 198 N peripheral areas, and where inter-area MPLS-TE path computation 199 relies on multiple-PCE path computation with ABRs acting as PCEs, the 200 backbone area would comprise at least N PCEs. In existing multi-area 201 networks, N can be quite large (e.g. beyond fifty). 203 In order to allow for efficient PCE selection by PCCs and efficient 204 load balancing of requests, a PCC has to know the location of PCEs in 205 its domain, along with some information relevant for PCE selection, 206 and also potentially of some PCEs in other domains, for inter-domain 207 path computation purpose. 208 Such PCE information could be learnt through manual configuration, on 209 each PCC, of the set of PCEs along with their capabilities. Such 210 manual configuration approach may be sufficient, and even desired in 211 some particular situations, but it obviously faces several 212 limitations: 213 -This may imply a substantial configuration overhead (see the 214 above example with N PCEs); 215 -This would not allow a PCC to dynamically detect that a new 216 PCE is available, that an existing PCE is no longer available, 217 or that there is a change in the PCE's information. 219 Furthermore, as with any manual configuration approach, this may lead 220 to undesirable configuration errors. 222 Hence, an automated PCE discovery mechanism allowing a PCC to 223 dynamically discover a set of PCEs is highly desirable. 225 4.2. Requirements overview 227 A PCE discovery mechanism that satisfies the requirements set forth 228 in this document MUST allow a PCC to automatically discover the 229 location of one or more PCEs in its domain and also, potentially, of 230 PCEs in other domains, of interest for inter-domain path computation 231 purpose. 233 A PCE discovery mechanism MUST allow discovering the path computation 234 scope(s) of a PCE (intra-area, inter-area, inter-AS�). It MUST also 235 allow a PCC to discover the set of one or more domains under the path 236 computation responsibility of a PCE. 238 A PCE discovery mechanism MUST allow PCCs to dynamically discover 239 that a new PCE has appeared or that there is a change in PCE's 240 information. It MUST also allow PCCs to dynamically discover that a 241 PCE is no longer available. 243 The PCE discovery MUST be secure. In particular, key consideration 244 MUST be given in terms of how to establish a trust model for PCE 245 discovery. 247 OPTIONALLY a PCE discovery mechanism MAY be used so as to disclose a 248 set of PCE capabilities. 250 5. Example of application scenario 252 <----------------AS1--------------------> <----AS2--- 253 Area 1 Area 0 Area 2 254 R1---------R3-----R5-------R6-----------R9----------R11----R13 255 | | | | | 256 | | | | | 257 R2---------R4-----R7-------R8-----------R10---------R12----R14 259 S1 261 Figure 1 263 Figure 1 above illustrates a network with several PCEs: 264 -The ABR R3 is a PCE that can take part in inter area path 265 computation. It can compute paths in area 1 and area 0; 266 -The ABR R6 is a PCE that can take part in inter-area path 267 computation. It can compute paths in area 0 and area2; 268 -The ASBR R9 is a PCE that can take part in inter-AS path 269 computation, responsible for path computation in AS1 towards AS2; 270 -The ASBR R12 is a PCE that can take part in inter-AS path 271 computation, responsible for path computation in AS2 towards AS1; 272 -The server S1 is a PCE that can be used to compute diverse paths and 273 backup paths in area 1. 275 The PCE discovery mechanism will allow: 276 -each LSR in area 1 and 0 to dynamically discover R3, as a PCE for 277 inter-area path computation as well as its path computation domains: 278 area1 and area0; 279 -each LSR in area 0 and 2 to dynamically discover R6, as a PCE for 280 inter-area path computation, as well as its path computation domains: 281 area2 and area0; 282 -each LSR in AS1 and some PCEs in AS2 to dynamically discover R9 as a 283 PCE for inter-AS path computation in AS1 towards AS2; 284 -each LSR in area 1 to dynamically discover S1, as a PCE for diverse 285 path computation and backup path computation in area1. 287 6. Detailed Requirements 289 6.1. PCE Information to be disclosed 291 The PCE discovery mechanism MUST allow disclosing some PCE 292 information that will allow PCCs to select appropriate PCEs. 294 We distinguish two levels of information to be disclosed by the PCE 295 discovery mechanism: 296 -Mandatory information: This comprises discovery of PCE location, 297 PCE computation scopes and domains under control 298 -Optional information: This comprises discovery of PCE 299 capabilities and alternate PCEs. 301 Note that the latter information is optional in the context of the 302 PCE discovery mechanism. It could also be obtained by other 303 mechanisms, such as for instance the PCC-PCE communication protocol. 305 6.1.1. Discovery of PCE Location 307 The PCE discovery mechanism MUST allow discovering, for a given PCE, 308 the IPv4 and/or IPv6 address to be used to reach the PCE. This 309 address will typically be a loop-back address that is always 310 reachable, if there is any connectivity to the PCE. 311 This address will be used by PCCs to communicate with a PCE, thanks 312 to a PCC-PCE communication protocol. 314 6.1.2. Discovery of PCE computation scope(s) and domain(s) under 315 control 317 Inter-domain path computation is a key application of the PCE 318 architecture. This can rely on a multiple-PCE path computation, 319 where PCEs in each domain compute a part of the end-to-end path and 320 collaborate with each other to find the end-to-end-path. This can 321 also rely on a single-PCE path computation where a PCE has visibility 322 inside multiple domains and can compute an inter-domain path. 324 Hence the PCE discovery mechanism MUST allow discovering the path 325 computation scope of a PCE, i.e. if a PCE can be used to compute or 326 to take part in the computation of intra-area, inter-area or inter-AS 327 TE-LSP. Note that these path computation scopes are not mutually 328 exclusive. 330 Also the PCE discovery mechanism MUST allow discovering the set of 331 one or more domains under the path computation responsibility of a 332 PCE, i.e. where a PCE has visibility and can compute paths. These 333 domains can be identified using a domain identifier: For instance, an 334 IGP area can be identified by the Area ID (OSPF or ISIS), and an AS 335 can be identified by the AS number. 336 It MUST also allow discovering the set of one or more domain(s) 337 towards which a PCE can compute paths. 339 6.1.3. Discovery of PCE Capabilities 341 In the case where there are several PCEs with distinct capabilities 342 available, a PCC has to select one or more appropriate PCEs. 344 For that purpose the PCE discovery mechanism MAY be used so as to 345 disclose some PCE capabilities. 347 For the sake of illustration this could include for instance some 348 path computation related capabilities: 349 -The capability to compute MPLS-TE and/or GMPLS paths; 350 -The type of link and path constraints supported: e.g. 351 bandwidth, affinities, delay; 352 -The objective functions supported: e.g. shortest constrained 353 path, shortest bounded delay path; 354 -The capability to compute multiple paths in a synchronized 355 manner: e.g. diverse path computation, load balancing 356 computation; 357 -Some GMPLS specific capabilities: e.g. the supported interface 358 switching capabilities, the support for multi-layer 359 path computation; 360 And this could also include some general capabilities: 361 -The capability to handle request prioritization; 362 -The capability to authenticate PCCs and to be authenticated. 364 Such information regarding PCE capabilities could then be used by a 365 PCC to select an appropriate PCE from a list of candidate PCEs. 367 Note that the description of general and path computation specific 368 PCE capabilities is out of the scope of this document. It is expected 369 that this will be described in a separate document. 371 It is paramount that dynamic discovery of PCE capabilities MUST NOT 372 generate an excessive amount of information and SHOULD be limited to 373 a small set of generic capabilities. 374 If required, the exhaustive discovery of detailed capabilities could 375 be ensured by means of the PCC-PCE communication protocol. 376 Actually a tradeoff should be found between capability discovery by 377 the PCE discovery mechanism and by the PCC-PCE communication 378 protocol. One of the objectives of the PCE discovery mechanism is to 379 help PCCs to select appropriate PCEs and limit the likelihood of PCC- 380 PCE communication rejections that may occur in case a PCE cannot 381 support a given capability. 383 6.1.4. Discovery of Alternate PCEs 385 In the case of a PCE failure, a PCC has to select another PCE, if one 386 is available. It could be useful in various situations, to indicate a 387 set of one or more alternate PCEs that can be selected in case a 388 given PCE fails. 390 Hence the PCE Discovery mechanism SHOULD allow the advertising, for a 391 given PCE of the location of one or more assigned alternate PCEs. 393 6.2. Scope of PCE Discovery 395 The PCE Discovery mechanism MUST allow the control of the scope of 396 the PCE information discovery (IGP Area, AS, set of AS) on a per PCE 397 basis. In other words it MUST allow to control to which PCC or group 398 of PCCs the information related to a PCE may be disclosed. 400 The choice for the discovery scope of a given PCE MUST include the 401 followings: 403 -All PCCs in a single IGP area 405 -All PCCs in a set of adjacent IGP areas 407 -All PCCs in a single AS 409 -All PCCs in a set of ASes 411 -A set of one or more PCCs in a set of one or more ASes 413 Particularly this also implies that the PCE Discovery mechanism MUST 414 allow for the discovery of PCE information across IGP areas and 415 across AS boundaries. 417 Note that it MUST be possible to deactivate PCE discovery on a per 418 PCE basis. 420 6.3. PCE Information Synchronization 422 The PCE discovery mechanism MUST allow a PCC to detect any change in 423 the information related to a PCE (e.g. capability modifications). 425 In addition it MUST be possible to dynamically detect new PCEs. 427 The PCE Discovery Mechanism SHOULD allow such detection under 60 428 seconds. 430 Note that PCE information is expected to be fairly stable and not to 431 change frequently. 433 6.4. Detecting PCE Liveliness 435 The PCE discovery mechanism MUST allow a PCC to detect when a PCE is 436 no longer alive. This allows a PCC to rapidly switch to another PCE 437 (for instance a predefined alternate PCE), and thus minimizes path 438 computation service disruption. 440 The PCE discovery mechanism SHOULD allow such detection under 60 441 seconds. 443 6.5. Discovery of PCE capacity and congestion 445 PCE WG feedback is requested on the following items: 446 -Is there a need for the discovery of PCE capacity in terms of 447 computation power? This static parameter could be used to 448 ensure weighted load balancing of requests in case PCEs do not 449 have the same capacity. 450 -May the PCE discovery mechanism be used so that a PCE report 451 its status as "congested" in case it is too busy? PCCs may then 452 use this dynamic information to prefer a different PCE. 454 6.6. Security Requirements 456 The PCE Discovery mechanism MUST address security issues across 457 multiple ASes. 459 Key consideration MUST be given in terms of how to establish a trust 460 model for PCE discovery. The PCE discovery mechanism MUST explicitly 461 support a specific set of one ore more trust model(s). 463 The PCE discovery mechanism MUST deliver the operational security 464 objectives where required. The overall security objectives of 465 privacy, authentication, and integrity may take on varying level of 466 importance. These objectives MAY be met by other established means 467 and protocols. 469 Particularly, mechanisms MUST be defined to ensure authentication, 470 integrity and privacy of PCE discovery information. 472 It MUST be possible to restrict the scope of discovery to a set of 473 authorized PCCs. In particular, the identity of any PCE MUST only be 474 learnt by authorized PCCs. 476 It MUST be possible for PCEs to authenticate PCCs and for PCCs to 477 authenticate PCEs. It MUST also be possible to encrypt discovery 478 information. 480 6.7. Extensibility 482 The PCE discovery mechanism MUST be flexible and extensible so as to 483 easily allow for the inclusion of some additional PCE information 484 that could be defined in the future. 486 6.8. Scalability 488 The PCE discovery mechanism MUST be designed to scale well with an 489 increase of any of the following parameters: 490 -Number of PCCs; 491 -Number of PCEs; 492 -Number of IGP Areas in the discovery scope; 493 -Number of ASs in the discovery scope. 495 Particularly, in case routing protocols (IGP, BGP) are extended to 496 support PCE discovery, the extensions MUST NOT cause a degradation in 497 routing protocol performance. The same applies to a signaling 498 solution that could serve for this discovery. 500 7. Security Considerations 502 This document is a requirement document and hence does not raise by 503 itself any particular security issue. 505 A set of security requirements that MUST be addressed when 506 considering the design and deployment of a PCE Discovery mechanism 507 have been identified in section 6.6. 509 8. Acknowledgments 511 We would like to thank Benoit Fondeviole, Thomas Morin, Emile 512 Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai 513 Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin and Dimitri 514 Papadimitriou, for their useful comments and suggestions. 516 9. References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 522 3667, February 2004. 524 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 525 Technology", BCP 79, RFC 3668, February 2004. 527 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 528 Element (PCE) Architecture", draft-ietf-pce-architecture, work in 529 progress. 531 [PCE-COM-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol 532 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in 533 progress. 535 10. Authors' Addresses: 537 Jean-Louis Le Roux 538 France Telecom 539 2, avenue Pierre-Marzin 540 22307 Lannion Cedex 541 FRANCE 542 Email: jeanlouis.leroux@francetelecom.com 543 Paul Mabey 544 Qwest Communications 545 950 17th Street, 546 Denver, CO 80202, 547 USA 548 Email: pmabey@qwest.com 550 Eiji Oki 551 NTT 552 Midori-cho 3-9-11 553 Musashino-shi, Tokyo 180-8585, 554 JAPAN 555 Email: oki.eiji@lab.ntt.co.jp 557 Richard Rabbat 558 Fujitsu Laboratories of America 559 1240 East Arques Ave, MS 345 560 Sunnyvale, CA 94085 561 USA 562 Email: richard@us.fujitsu.com 564 Ting Wo Chung 565 Bell Canada 566 181 Bay Street, Suite 350 567 Toronto, Ontario, M5J 2T3 568 CANADA, 569 Email: ting_wo.chung@bell.ca 571 Raymond Zhang 572 BT Infonet 573 2160 E. Grand Ave. 574 El Segundo, CA 90025 575 USA 576 Email: raymond_zhang@infonet.com 578 11. Intellectual Property Statement 580 The IETF takes no position regarding the validity or scope of any 581 Intellectual Property Rights or other rights that might be claimed to 582 pertain to the implementation or use of the technology described in 583 this document or the extent to which any license under such rights 584 might or might not be available; nor does it represent that it has 585 made any independent effort to identify any such rights. Information 586 on the procedures with respect to rights in RFC documents can be 587 found in BCP 78 and BCP 79. 589 Copies of IPR disclosures made to the IETF Secretariat and any 590 assurances of licenses to be made available, or the result of an 591 attempt made to obtain a general license or permission for the use of 592 such proprietary rights by implementers or users of this 593 specification can be obtained from the IETF on-line IPR repository at 594 http://www.ietf.org/ipr. 596 The IETF invites any interested party to bring to its attention any 597 copyrights, patents or patent applications, or other proprietary 598 rights that may cover technology that may be required to implement 599 this standard. Please address the information to the IETF at 600 ietf-ipr@ietf.org. 602 Disclaimer of Validity 604 This document and the information contained herein are provided on an 605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 607 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 608 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 609 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 612 Copyright Statement 614 Copyright (C) The Internet Society (2005). This document is subject 615 to the rights, licenses and restrictions contained in BCP 78, and 616 except as set forth therein, the authors retain all their rights.