idnits 2.17.1 draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. ** 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: ---------------------------------------------------------------------------- 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 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 (October 23, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 413, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft Kenji Kumaki, Ed 4 Category: Informational KDDI Corporation 5 Expires: April 24, 2007 Tomohiro Otani 6 KDDI R&D Labs 7 Shuichi Okamoto 8 NICT 9 Kazuhiro Fujihara 10 Yuichi Ikejiri 11 NTT 12 Communications 13 October 23, 2006 15 Interworking Requirements to Support operation of MPLS-TE over GMPLS 16 networks 18 draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-02.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 24, 2007. 45 Copyright Notice 47 Copyright (C) The Internet Society (2006). 49 Abstract 51 This document describes a framework and Service Provider requirements 52 for operating Multiprotocol Label Switching (MPLS) traffic 53 engineering (TE) networks over Generalized MPLS (GMPLS) networks. 55 Operation of an MPLS-TE network as a client network to a GMPLS 56 network has enhanced operational capabilities than provided by a co- 57 existent protocol model (ships in the night). 59 The GMPLS network may be a packet or a non-packet network, and may 60 itself be a multi-layer network supporting both packet and non-packet 61 technologies. A MPLS-TE Label Switched Path (LSP) originates and 62 terminates on an MPLS Label Switching Router (LSR). The GMPLS network 63 provides transparent transport for the end-to-end MPLS-TE LSP. 65 Specification of solutions is out of scope for this document. 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC-2119. 73 Table of Contents 75 1. Introduction...................................................3 76 2. Reference model................................................4 77 3. Detailed Requirements..........................................5 78 3.1 End-to-End Signaling.......................................5 79 3.2 Triggered Establishment of GMPLS LSPs......................5 80 3.3 Diverse Paths for End-to-End MPLS-TE LSPs..................5 81 3.4 Advertisement of MPLS-TE Information via the GMPLS Network.5 82 3.5 Selective Advertisement of MPLS-TE Information via a Border 83 Node...........................................................6 84 3.6 Interworking of MPLS-TE and GMPLS protection...............6 85 3.7 Independent Failure Recovery and Reoptimization............6 86 3.8 Complexity and Risks.......................................6 87 3.9 Scalability consideration..................................6 88 3.10 Performance Consideration.................................7 89 3.11 Management Considerations.................................7 90 4. Security Considerations........................................7 91 5. Recommended Solution Architecture..............................7 92 5.1 Use of Contiguous, Hierarchical, and Stitched LSPs.........8 93 5.2 MPLS-TE Control Plane Connectivity.........................8 94 5.3 Fast Reroute Protection....................................8 95 6. IANA Considerations............................................9 96 7. Normative References...........................................9 97 8. Informative References........................................10 98 9. Acknowledgments...............................................10 99 10.Author's Addresses............................................10 100 11.Intellectual Property Statement...............................11 102 1. Introduction 104 Multiprotocol Label Switching traffic engineering (MPLS-TE) networks 105 are often deployed over transport networks such that the transport 106 networks provide connectivity between the Label Switching Routers 107 (LSRs) in the MPLS-TE network. Increasingly, these transport networks 108 are operated using a Generalized Multiprotocol Label Switching 109 (GMPLS) control plane and label Switched Paths (LSPs) in the GMPLS 110 network provide connectivity in the MPLS-TE network. 112 Generalized Multiprotocol Label Switching (GMPLS) protocols were 113 developed as extensions to Multiprotocol Label Switching traffic 114 engineering (MPLS-TE) protocols. MPLS-TE is limited to the control of 115 packet switching networks, but GMPLS can also control sub-packet 116 technologies at layers one and two. 118 The GMPLS network may be managed by an operator as a separate network 119 (as it was when it was under management plane control before the use 120 of GMPLS as a control plane), but optimizations of management and 121 operation may be achieved by coordinating the use of the MPLS-TE and 122 GMPLS networks and operating the two networks with a close 123 client/server relationship. 125 GMPLS LSP setup may triggered by the signaling of MPLS-TE LSPs in the 126 MPLS-TE network so that the GMPLS network is reactive to the needs of 127 the MPLS-TE network. The triggering process can be under the control 128 of operator policies without needing direct intervention by an 129 operator. 131 The client/server configuration just described can also apply in 132 migration scenarios for MPLS-TE packet switching networks that are 133 being migrated to be under GMPLS control. [MIGRATE] describes a 134 migration scenario called the Island Model. In this scenario, groups 135 of nodes (islands) are migrated from the MPLS-TE protocols to the 136 GMPLS protocols and operate entirely surrounded by MPLS-TE nodes (the 137 sea). This scenario can be effectively managed as a client/server 138 network relationship using the framework described in this document. 140 In order to correctly manage the dynamic interaction between the MPLS 141 and GMPLS networks, it is necessary to understand the operational 142 requirements and the control that the operator can impose. Although 143 this problem is very similar to the multi-layer networks described in 144 [MLN], it must be noted that those networks operate GMPLS protocols 145 in both the client and server networks which facilitates smoother 146 interworking. Where the client network uses MPLS-TE protocols over 147 the GMPLS server network there is a need to study the interworking of 148 the two protocol sets. 150 This document examines the protocol requirements for protocol 151 interworking to operate an MPLS-TE network as a client network over a 152 GMPLS server network, and provides a framework for such operations. 154 2. Reference model 156 The reference model used in this document is shown in Figure 1. It 157 can easily be seen that the interworking between MPLS-TE and GMPLS 158 protocols must occur on a node and not on a link. Nodes on the 159 interface between the MPLS-TE and GMPLS networks must be responsible 160 for handling both protocol sets and for providing any protocol 161 interworking that is required. We call these nodes Border Routers. 163 -------------- ------------------------- -------------- 164 | MPLS Client | | GMPLS Server Network | | MPLS Client | 165 | Network | | | | Network | 166 | | | | | | 167 | ---- --+--+-- ----- ----- --+--+-- ---- | 168 | | | | | | | | | | | | | | 169 | |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS| | 170 | |LSR | | Router | | LSR | | LSR | | Router | |LSR | | 171 | | | | | | | | | | | | | | 172 | ---- --+--+-- ----- ----- --+--+-- ---- | 173 | | | | | | 174 | | | | | | 175 -------------- ------------------------- -------------- 177 | | GMPLS LSP | | 178 | |<------------------------->| | 179 | | 180 |<--------------------------------------------->| 181 End-to-End MPLS-TE LSP 183 Figure 1. Reference model of MPLS-TE/GMPLS interworking 185 MPLS-TE network connectivity is provided through a GMPLS LSP which is 186 created between Border Routers. End-to-end connectivity between MPLS 187 LSRs in the client MPLS-TE networks is provided by an MPLS-TE LSP 188 that is carried across the MPLS-TE network by the GMPLS LSP using 189 hierarchical LSP techniques [RFC4206], LSP stitching segments 190 [STITCH] or a contiguous LSP. LSP stitching segments and contiguous 191 LSPs are only available where the GMPLS network is a packet switching 192 network. 193 3. Detailed Requirements 195 This section describes detailed requirements for MPLS-TE/GMPLS 196 interworking in support of the reference model shown in figure 1. 198 3.1 End-to-End Signaling 200 The solution MUST be able to preserve MPLS signaling information 201 signaled within the MPLS-TE client network at the start of the MPLS- 202 TE LSP, and deliver it on the other side of the GMPLS server network 203 for use within the MPLS-TE client network at the end of the MPLS-TE 204 LSP. This may require protocol mapping (and re-mapping), protocol 205 tunneling, or the use of remote protocol adjacencies. 207 3.2 Triggered Establishment of GMPLS LSPs 209 The solution MUST provide the ability to establish end-to-end MPLS- 210 TE LSPs over a GMPLS server network. It SHOULD be possible for GMPLS 211 LSPs across the core network to be set up between Border Routers 212 triggered by the signaling of MPLS-TE LSPs in the client network. 213 GMPLS LSPs MAY also be pre-established as the result of management 214 plane control. 216 3.3 Diverse Paths for End-to-End MPLS-TE LSPs 218 The solution SHOULD provide the ability to establish end-to-end 219 MPLS-TE LSPs having diverse paths for protection of the LSP traffic. 220 This means that MPLS-TE LSPs SHOULD be kept diverse both within the 221 client MPLS-TE network and as they cross the server GMPLS network. 222 This means that there SHOULD be a mechanism to request the provision 223 of diverse GMPLS LSPs between a pair of Border Routers to provide 224 protection of the GMPLS span, but also that there SHOULD be a way to 225 keep GMPLS LSPs between different Border Routers disjoint. 227 3.4 Advertisement of MPLS-TE Information via the GMPLS Network 229 The solution SHOULD provide the ability to advertise of TE 230 information from MPLS-TE client networks across the GMPLS server 231 network. 232 The advertisement of TE information from within an MPLS-TE client 233 network to all LSRs in the client network enables a head end LSR to 234 compute an optimal path for an LSP to a tail end LSR that is reached 235 over the GMPLS server network. 236 Where there is more than one client MPLS-TE network, the TE 237 information from separate MPLS-TE networks MUST be kept private, 238 confidential and secure. 240 3.5 Selective Advertisement of MPLS-TE Information via a Border Node 242 The solution SHOULD provide the ability to distribute TE reachability 243 information from the GMPLS server network to MPLS-TE networks 244 selectively. This information is useful for the LSRs in the MPLS-TE 245 networks to compute paths that cross the GMPLS server network and to 246 select the correct Border Routers to provide connectivity. 248 The solution MUST NOT distribute TE information from within a non-PSC 249 GMPLS server network to any client MPLS-TE network as that 250 information may cause confusion and selection of inappropriate paths. 252 3.6 Interworking of MPLS-TE and GMPLS protection 254 If an MPLS-TE LSPs is protected using MPLS Fast Reroute (FRR) 255 [RFC4090], then similar PROTECTION MUST be provided over the GMPLS 256 island. Operator and policy controls SHOULD be made available at the 257 Border Router to determine how suitable protection is provided in the 258 GMPLS island. 260 3.7 Independent Failure Recovery and Reoptimization 262 The solution SHOULD provide failure recovery and reoptimization in 263 the GMPLS server network without impacting MPLS-TE client network and 264 vice versa. That is, it SHOULD be possible to recover from a fault 265 within the GMPLS island or to reoptimize the path across the GMPLS 266 island without requiring signaling activity within the MPLS-TE client 267 network. Similarly, it SHOULD be possible to perform recovery or 268 reoptimization within the MPLS-TE client network without requiring 269 signaling activity within the GMPLS server networks. 271 In case that failure in the GMPLS server network can not be repaired 272 transparently, some kind of notification of the failure SHOULD be 273 transmitted to MPLS-TE network. 275 3.8 Complexity and Risks 277 The solution SHOULD NOT introduce unnecessary complexity to the 278 current operating network to such a degree that it would affect the 279 stability and diminish the benefits of deploying such a solution in 280 service provider networks. 282 3.9 Scalability consideration 284 The solution MUST scale well with consideration to at least the 285 following considerations. 287 - The number of GMPLS-capable nodes (i.e., the size of the GMPLS 288 server network). 290 - The number of MPLS-TE-capable nodes (i.e., the size of the MPLS-TE 291 client network). 292 - The number of MPLS-TE client networks. 293 - The number of GMPLS LSPs. 294 - The number of MPLS-TE LSPs. 296 3.10 Performance Consideration 298 The solution SHOULD be evaluated with regard to the following 299 criteria. 301 - Failure and restoration time. 302 - Impact and scalability of the control plane due to added 303 overheads. 304 - Impact and scalability of the data/forwarding plane due to added 305 overheads. 307 3.11 Management Considerations 309 Manageability of deployment of an MPLS-TE client network over GMPLS 310 server network MUST addresses the following considerations. 312 - Need for coordination of MIB modules used for control plane 313 management and monitoring in the client and server networks. 314 - Need for diagnostic tools that can discover and isolate faults 315 across the border between the MPLS-TE client and GMPLS server 316 networks. 318 4. Security Considerations 320 We will write security considerations in next version. 322 5. Recommended Solution Architecture 324 The recommended solution architecture to meet the requirements set 325 out in the previous sections is known as the Border Peer Model. This 326 architecture is a variant of the Augmented Model described in 327 [RFC3945]. The remainder of this document presents an overview of 328 this architecture. Details of protocol solutions are described in 329 [BORDER-PEER]. 331 In the Augmented Model, routing information from the lower layer 332 (server) network is filtered at the interface to the higher layer 333 (client) network and is distributed within the higher layer network. 334 In the Border Peer Model, the interface between the client and server 335 networks is the Border Router. This router has visibility of the 336 routing information in the server network yet also participates as a 337 peer in the client network. However, the Border Router does not 338 distribute server routing information into the client network. 340 The Border Peer Model may also be contrasted with the Overlay Model 341 [RFC3945]. In this model there is a protocol request/response 342 interface (the user network interface - UNI) between the client and 343 server networks. [RFC4208] shows how this interface may be supported 344 by GMPLS protocols operated between client edge and server edge 345 routers while retaining the routing information within the server 346 network. The Border Peer Model can be viewed as placing the UNI 347 within the Border Router thus giving the Border Router peer 348 capabilities in both the client and server network. 350 5.1 Use of Contiguous, Hierarchical, and Stitched LSPs 352 All three LSP types MAY be supported in the Border Peer Model, but 353 contiguous LSPs are the hardest to support because they require 354 protocol mapping between the MPLS-TE client network and the GMPLS 355 server network. Such protocol mapping can currently be achieved since 356 MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism 357 is not future-proofed. 359 Contiguous and stitched LSPs can only be supported where the GMPLS 360 server network has the same switching type (that is, packet 361 switching) as the MPLS-TE network. Requirements for independent 362 failure recovery within the GMPLS island require the use of loose 363 path reoptimization techniques [LOOSE-REOPT] and end-to-end make- 364 before-break [RFC3209] which will not provide rapid recovery. 366 For these reasons, the use of hierarchical LSPs across the server 367 network is RECOMMENDED for the Border Peer Model, but see the 368 discussion of Fast Reroute protection in section 5.3. 370 5.2 MPLS-TE Control Plane Connectivity 372 Control plane connectivity between MPLS-TE LSRs connected by a GMPLS 373 island in the Border Peer Model MAY be provided by the control 374 channels of the GMPLS network. If this is done, a tunneling mechanism 375 (such as GRE [RFC2784]) SHOULD be used to ensure that MPLS-TE 376 information is not consumed by the GMPLS LSRs. But care is required 377 to avoid swamping the control plane of the GMPLS network with MPLS-TE 378 control plane (particularly routing) messages. 380 In order to ensure scalability, control plane messages for the MPLS- 381 TE client network MAY be carried between Border Routers in a single 382 hop MPLS-TE LSP routed through the data plane of the GMPLS server 383 network. 385 5.3 Fast Reroute Protection 386 If the GMPLS network is packet switching, Fast Reroute protection can 387 be offered on all hops of a contiguous LSP. If the GMPLS network is 388 packet switching then all hops of a hierarchical GMPLS LSP or GMPLS 389 stitching segment can be protected using Fast Reroute. If the end-to- 390 end MPLS-TE LSP requests Fast Reroute protection, the GMPLS packet 391 switching network SHOULD provide such protection. 393 However, note that it is not possible to provide FRR node protection 394 of the upstream Border Router without careful consideration of 395 available paths, and protection of the downstream Border Router is 396 not possible where hierarchical LSPs or stitching segments are used. 398 Note further that Fast Reroute is not available in non-packet 399 technologies. However, other protection techniques are supported by 400 GMPLS for non-packet networks and are likely to provide similar 401 levels of protection. 403 The limitations of FRR need careful consideration by the operator and 404 may lead to the decision to provide end-to-end protection for the 405 MPLS-TE LSP. 407 6. IANA Considerations 409 This requirement document makes no requests for IANA action. 411 7. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 417 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 418 Tunnels", RFC 3209, December 2001. 420 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 421 (GMPLS) Architecture", RFC3945, October 2004. 423 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 424 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 426 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) 427 Hierarchy with Generalized Multi-Protocol Label Switching 428 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 430 [RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label 431 Switching (GMPLS) User-Network Interface (UNI): Resource 432 ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 433 for the Overlay Model", RFC 4208, October 2005. 435 [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching 436 with Generalized MPLS Traffic Engineering", draft-ietf- 437 ccamp-lsp-stitching, work in progress. 439 8. Informative References 441 [RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation 442 (GRE)", RFC 2784, March 2000. 444 [BORDER-PEER] Kumaki, K. et al. "Operational, Deployment and 445 Interworking Considerations for GMPLS", draft-kumaki- 446 ccamp-mpls-gmpls-interworking, work in progress. 448 [LOOSE-REOPT] Vasseur, JP., Ikejiri, Y., and Zhang, R., 449 "Reoptimization of Multiprotocol Label Switching 450 (MPLS) Traffic Engineering (TE) loosely routed Label 451 Switch Path (LSP)", draft-ietf-ccamp-loose-path-reopt, 452 work in progress. 454 [MIGRATE] Shiomoto, K., et al., "Framework for MPLS-TE to GMPLS 455 migration", draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, 456 work in progress. 458 [MLN] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, M., 459 Brungard, D., "Requirements for GMPLS-based multi-region and 460 multi-layer networks (MRN/MLN)", draft-ietf-ccamp-gmpls-mln- 461 reqs, work in progress. 463 9. Acknowledgments 465 The author would like to express the thanks to Raymond Zhang, Adrian 466 Farrel, and Deborah Brungard for their helpful and useful comments 467 and feedback. 469 10.Author's Addresses 471 Kenji Kumaki (Editor) 472 KDDI Corporation 473 Garden Air Tower 474 Iidabashi, Chiyoda-ku, 475 Tokyo 102-8460, JAPAN 476 Email: ke-kumaki@kddi.com 478 Tomohiro Otani 479 KDDI R&D Laboratories, Inc. 480 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 481 Saitama, 356-8502. Japan Email: otani@kddilabs.jp 483 Shuichi Okamoto 484 NICT JGN II Tsukuba Reserach Center 485 1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117 486 Tokyo, 100-0004, Japan E-mail :okamoto-s@nict.go.jp 488 Kazuhiro Fujihara 489 NTT Communications Corporation 490 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 491 Tokyo 163-1421, Japan 492 EMail: kazuhiro.fujihara@ntt.com 494 Yuichi Ikejiri 495 NTT Communications Corporation 496 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 497 Tokyo 163-1421, Japan 498 EMail: y.ikejiri@ntt.com 500 11.Intellectual Property Statement 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed 504 to pertain to the implementation or use of the technology described 505 in this document or the extent to which any license under such 506 rights might or might not be available; nor does it represent that 507 it has made any independent effort to identify any such rights. 508 Information on the procedures with respect to rights in RFC 509 documents can be found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use 514 of such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository 516 at http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at 522 ietf-ipr@ietf.org. 524 Disclaimer of Validity 526 This document and the information contained herein are provided on 527 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 528 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 529 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 530 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 531 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 532 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 534 Copyright Statement 536 Copyright (C) The Internet Society (2006). This document is subject 537 to the rights, licenses and restrictions contained in BCP 78, and 538 except as set forth therein, the authors retain all their rights. 540 Acknowledgement 542 Funding for the RFC Editor function is currently provided by the 543 Internet Society.