idnits 2.17.1 draft-bernstein-ccamp-gmpls-vcat-lcas-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 496. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 (October 11, 2005) is 6772 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) -- Looks like a reference, but probably isn't: 'BernDiegoRabbat' on line 312 == Unused Reference: '4' is defined on line 428, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 437, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 441, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 447, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP working Group G. Bernstein 3 Internet-Draft Grotto Networking 4 Expires: April 14, 2006 D. Caviglia 5 Marconi 6 R. Rabbat 7 Fujitsu 8 October 11, 2005 10 Operating Virtual concatenation (VCAT) and the Link Capacity Adjustment 11 Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) 12 draft-bernstein-ccamp-gmpls-vcat-lcas-01 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 months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 14, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document describes the use of the Generalized Multi-Protocol 46 Label Switching (GMPLS) control plane in conjunction with the Virtual 47 Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its 48 companion Link Capacity Adjustment Scheme (LCAS) which can be used 49 for hitless dynamic resizing of the inverse multiplex group. These 50 techniques apply to the Optical Transport Network (OTN), Synchronous 51 Optical Network (SONET), Synchronous Digital Hierarchy (SDH) and 52 Plesiochronous Digital Hierarchy (PDH) signals. 54 Table of Contents 56 1. Overview of VCAT and LCAS . . . . . . . . . . . . . . . . . . 3 57 1.1. VCAT signals and components . . . . . . . . . . . . . . . 3 58 1.2. VCAT Capabilities and Limitations . . . . . . . . . . . . 3 59 1.3. The LCAS Protocol . . . . . . . . . . . . . . . . . . . . 4 60 2. Problem Statement and Current Support . . . . . . . . . . . . 5 61 2.1. Discovery of Enabled End Systems . . . . . . . . . . . . . 5 62 2.2. Client to End Point Mappings . . . . . . . . . . . . . . . 5 63 2.3. VCAT configuration without LCAS . . . . . . . . . . . . . 6 64 2.4. VCAT configuration with LCAS . . . . . . . . . . . . . . . 7 65 2.5. Component Signal Configuration Scenarios . . . . . . . . . 8 66 3. Possible Extensions to GMPLS to support additional 67 VCAT/LCAS scenarios . . . . . . . . . . . . . . . . . . . . . 10 68 3.1. Mechanisms for Discovery of VCAT/LCAS . . . . . . . . . . 10 69 3.2. Mechanism to Support Multiple Client to End Point 70 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.3. Support for Component Signal Configuration Scenarios . . . 10 72 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . . . . . 14 77 1. Overview of VCAT and LCAS 79 Virtual Concatenation (VCAT) is a standardized layer 1 inverse 80 multiplexing technique that can be applied to OTN [6], SONET [3], SDH 81 [2], and PDH [5] component signals. By inverse multiplexing we mean 82 a method that combines multiple links at a particular layer into an 83 aggregate link to achieve a commensurate increase in available 84 bandwidth on that aggregate link. More formally, VCAT essentially 85 combines the payload bandwidth of multiple path layer network signals 86 (or trails) to support a single client (e.g. Ethernet) layer link. 87 For a more detailed introduction see [1]. 89 1.1. VCAT signals and components 91 In the following we will use SDH terminology rather than both SONET 92 and SDH terminology. In SDH Virtual Concatenation (VCAT) can be 93 applied to the following component time division multiplex (TDM) 94 signals referred to as Virtual Containers (VCs): VC-11, VC-12, VC-2, 95 VC-3, and VC-4 97 Only like component signals can be aggregated into a VCAT group. 98 These groups are respectively known as: VC-11-Xv, VC-12-Xv, VC-2-Xv, 99 VC-3-Xv, and VC-4-Xv. In the previous designations X is an integer 100 running from 1 to a value N dependent upon the component type. See 101 [2] for details. 103 VCAT can be applied to the following PDH signals as specified in 104 reference [5]: DS1,E1, E3, DS3. Similar to the SONET/SDH case these 105 component signals can only be combined with like signals to produce 106 aggregates. For some reason the virtual concatenation groups of the 107 PDH signals were not given unique designations in [5] so we shall 108 adopt a similar notation to the SDH VCAT signals for the permitted 109 PDH VCAT signals that follow: DS1-Xv, E1-Xv, E3-Xv, DS3-Xv. 111 Concatenation in the optical transport network (OTN) is realized by 112 means of virtual concatenation of Optical Channel Payload Unit (OPU) 113 signals. OPUk signals (k=1, 2, 3) can be concatenated into OPUk-Xv 114 aggregates with X= 1,..., 256. See reference [6] for details. 116 1.2. VCAT Capabilities and Limitations 118 VCAT performs inverse multiplexing by octet/byte de-interleaving of 119 the encapsulated client bit stream. Hence the main limitation of any 120 VCAT standard or implementation is the ammount of differential delay 121 that can be accomodated between the component signals. These are 122 summarized for the different signal types in reference [1] with 123 details given in the respective standards documents. 125 1.3. The LCAS Protocol 127 The Link Capacity Adjustment Scheme for VCAT signals is a protocol 128 for dynamically and hitlessly changing (i.e., increasing and 129 decreasing) the capacity of a VCAT group. LCAS also provides 130 survivability capabilities, automatically decreasing the capacity if 131 a member of the VCAT group experiences a failure in the network, and 132 increasing the capacity when the network fault is repaired. LCAS, 133 itself, provides a mechanism for interworking between LCAS and non- 134 LCAS VCAT end points. VCAT does not require LCAS for its operation. 136 LCAS functionality does not overlap or conflict with GMPLS' routing 137 or signaling functionality for the establishment of component links 138 or entire VCAT groups. LCAS instead is used to control whether a 139 particular component signal is actually put into service carrying 140 traffic for the VCAT group. 142 LCAS provides for graceful degradation of failed links by having the 143 sink end report back the receive status of all member components. In 144 the case of a reported member failure, the source end will stop using 145 the component and the source end will send an LCAS message to the 146 sink end that it is not transmitting data on that component. The 147 worst case notification times are summarized in [1]. 149 2. Problem Statement and Current Support 151 In this section we list a number of VCAT/LCAS usage scenarios and 152 their current level of support. We will evaluate the applicability 153 of GMPLS to these scenarios and for those scenarios that GMPLS does 154 not currently support we describe possible GMPLS extensions in 155 Section 3. Note the term "component" signal in the text is used as a 156 simplified notion to the more formal concepts of VC-n, ODUk, and PDH 157 termination function as well as VC-n, ODUk and PDH path/trail. 159 2.1. Discovery of Enabled End Systems 161 Discovering VCAT: VCAT sources can only communicate with VCAT capable 162 sinks. Hence the VCAT capabilities of a PDH, SDH, or OTN path 163 termination points need to be known. 165 Currently no support for discovery of VCAT or LCAS apriori, i.e., 166 via routing information. Support for "discovery" of VCAT 167 capability at connection establishment time via signaling, i.e., 168 we can request VCAT connection and if the end system cannot 169 support it,it would refuse the connection. TBD -- is there a 170 specific error code concerning "VCAT not supported". 172 Discovering LCAS: LCAS offers additional functionality between VCAT 173 capable sources and sinks. Hence the LCAS capabilities of VCAT 174 enabled path termination points can be useful to know in advance 175 of component signal setup. 177 Currently there is no mechanism to ask for an LCAS enabled end 178 point nor is there a way to find out if the other end is LCAS 179 enabled until after the connection is established. This is a 180 problem if we specifically want hitless dynamic resizing or fast 181 graceful degradation for a VCAT group. 183 2.2. Client to End Point Mappings 185 Fixed Client to End point Mapping: Per client signal there is a 186 VC-n-Xv circuit in which the X VC-n termination points are 187 dedicated to this client signal. At any point in time, Y out of X 188 VC-n termination points may be set up to carry client traffic. 189 For example when VCAT is deployed on a Router, the VCAT group 190 connects directly to one STM-N interface port (in absence of a HO 191 or LO switch fabric in the router). The transport network will 192 then split the VCAT group into two or more subgroups of 193 components, each being routed via diverse routes. 195 Variable Client to End point Mapping: For a set of M client signals 196 there are M VC-n-Xv VCAT endpoints sharing a set of N (N>M) VC-n 197 termination points. Typically MxX > N (example: M=10, X=7, N=64); 198 i.e. there is a kind of overbooking. Implication: must be able to 199 accommodate multiple different sized VCAT groups at an 200 "interface". For example an STM-64 interface can support many 201 different VC-4-Xv groups. 203 Implications: In both these cases we can have more than one VCAT 204 group per GMPLS link. In general it is the responsibility of the 205 signaling entity at the source and destination ends to choose the 206 appropriate VC-n termination points for the VCAT group and in the 207 case of "variable client mapping" to perform needed internal 208 configuration. However multiple VCAT groups per GMPLS link or 209 GMPLS addressed entity introduces an unresolvable ambiguity when 210 disjoint connections are set up or dynamic resizing is applied 211 since there is currently no "VCAT group identifier" in GMPLS 212 signaling. 214 2.3. VCAT configuration without LCAS 216 Base Configuration: For VCAT to operate the sink end needs to be 217 informed of how many components are in the VCAT group. It has no 218 other way of knowing if it is currently receiving all components 219 intended to be in the group. 221 Fixed sized co-routed groups are supported with current GMPLS 222 signaling. Disjointly routed groups are not currently supported. 224 Group Resizing: Additions or removals of components from a VCAT group 225 without are not hitless, that is data loss will occur while the 226 source and sink become synchronized as to the number of members in 227 the group. 229 Currently not supported within GMPLS. In particular, with each 230 addition or removal of a component the sink end point needs to be 231 told the expected number of components in the group. 233 Failure Conditions: Failure of a component must detected external to 234 VCAT system. The entire group is rendered inoperable until source 235 takes the failed component out of service and sink end is notified 236 to take component out of service. 238 Currently not supported within GMPLS. The source needs to be told 239 what component has failed and remove it from service, then the 240 sink must be told to also remove it from service. 242 2.4. VCAT configuration with LCAS 244 Base Configuration: Sink end (and source end) are first configured 245 with the value of "Y" (the number of components), and more 246 specifically which of the X (e.g. VC-n) access points (and thus 247 (VC-n) termination functions) are allocated to the VCAT group with 248 Y (VC-n) components. LCAS then detects automatically which of 249 those Y (VC-n) components is carrying actual traffic and puts them 250 into service for the group. 252 Currently both co-routed and disjointly routed VCAT groups can be 253 supported if there is no VCAT group ambiguity. 255 Component Addition: When a new component signal has to be added to a 256 VCAT group the following procedure applies. 258 1. Configure the adaptation source/sink functions and change the 259 number of components, Y, to Y+1 by identifying which of the 260 X-Y (e.g. VC-n) access points currently outside the group is 261 added to the group; 263 2. The new component is created, e.g., the cross-connections are 264 establish along the components path. 266 3. As soon as LCAS protocol information exchange is finished, 267 i.e., the state NORM is reached, client traffic is sent on the 268 added component. 270 This procedure does not affect the already established LCAS 271 members, that is, client traffic is not sent on the new component 272 until the LCAS procedure is complete; 274 This can be supported within GMPLS if, after GMPLS has 275 successfully established a potential new component, the source end 276 LCAS is (internally) told to add it to the group. 278 Component Removal: When a component is removed the following 279 procedure applies: 281 1. LCAS protocol is used to remove the component from the group, 282 that is, incoming traffic client data is transmitted on the 283 other VCAT component(s) to assure that the procedure is not 284 traffic affecting 286 2. Configure the adaptation source/sink functions and change the 287 number of components Y to Y-1; i.e. remove the VC-n access 288 point from the group. 290 3. The component connection can be, if needed, removed from the 291 transport network. 293 This can be supported within GMPLS if, before GMPLS tears down a 294 component, LCAS is told (local to source end) to remove the 295 component from service in the group. 297 Component Failure: When a component fails, the LCAS sink detects the 298 failure (how this is done is outside the scope of this ID) and 299 informs the source of this failure via the member status (MST) 300 information. The source then: 302 1. Takes the failed component out of service and if necessary 303 rearranges the sequencing of the VCAT group. 305 2. Informs the sink about the component removed from service and 306 any re-arranging of the VCAT group. 308 When the failed component is repaired, LCAS can automatically add 309 the repaired component back to the group, or alternatively a new 310 component can be added to bring the group back to its original 311 size. Note that component failure is not hitless, but note the 312 fast notification times of [BernDiegoRabbat]. 314 Currently supported since no action required of GMPLS. 316 2.5. Component Signal Configuration Scenarios 318 Here we use the term "group" to refer to the entire VCAT group and 319 the terminology "set" and "subset" to refer to the collection of 320 potential VCAT group member signals. Note that all assesments of 321 whether a scenario is curretly supported assumes either (a) a single 322 VCAT group per GMPLS addressable entity, or (b) a mechanism is in 323 place to disambiguate multiple VCAT groups (see Section 2.2). 325 Fixed, Co-routed: A fixed bandwidth VCAT group, transported over a 326 co-routed set of member signals. This is the case where the 327 intended bandwidth of the VCAT group does not change and all 328 member signals follow a similar route. The intent here is the 329 capability to allocate the "right" amount of bandwidth. 331 Currently supported in GMPLS. 333 Fixed, Disjoint: A fixed bandwidth VCAT group, transported over at 334 least two disjointly routed subsets of member signals. The intent 335 here is additional resilience and graceful degradation in the case 336 of failure. 338 If LCAS is present this scenario is supported under GMPLS. Not 339 supported without LCAS since we need two-way communications of 340 some type between source and sink to coordinate which members are 341 to be used in the group in a failure scenario. 343 Dynamic, Co-routed: A dynamic VCAT group (bandwidth can be increased 344 or decreased via the addition or removal of member signals), 345 transported over a co-routed set of members. Intent here is 346 dynamic sizing of bandwidth. 348 If LCAS present this scenario is currently supported by GMPLS. 349 Implications: LCAS is needed for hitless resizing. Note before 350 LCAS can do its part of getting traffic over the modified VCAT 351 group, the two VCAT/LCAS endpoints need to be configured (Y -> Y+1 352 or Y -> Y-1); this requires either "communication" between the two 353 endpoints (when one of the endpoints is configured by call/ 354 connection controller, or simple communication of the call/ 355 connection controller with both endpoints. Without LCAS we still 356 need two way communications between source and sink to coordinate 357 which members are used in the group and changes will not be 358 hitless. 360 Dynamic, Disjoint: A dynamic VCAT group, transported over at least 361 two disjointly routed subsets of member signals. Intent here is 362 dynamic resizing and resilience. 364 Currently support and implications similar to the "dynamic, co- 365 routed" and "fixed, disjoint" cases. 367 Shared Pool: Two or more VCAT groups between the same source and sink 368 who desire to share a pool of component signals between them. 369 Each VCAT group may have a dedicated set of members, and may also 370 obtain additional members from a "common pool" of components. 371 Note that at any given point in time a component signal can belong 372 to at most one VCAT group. The intent here is to allow dynamic 373 resizing of VCAT groups via the sharing of a pool of established 374 component signals without requiring complete circuit provisioning, 375 i.e., only the group membership of the component signal would 376 change. 378 Currently not supported by GMPLS. Implications: a communications 379 mechanism between source and sink to indicate during a "change" 380 which group a component should now belong. 382 3. Possible Extensions to GMPLS to support additional VCAT/LCAS 383 scenarios 385 Here we look at what might be reasonable to add to GMPLS to support 386 the interest scenarios of Section 2 that were not currently covered. 388 3.1. Mechanisms for Discovery of VCAT/LCAS 390 Would like to get both VCAT and LCAS capability of end systems via 391 routing... 393 Would like to be able to specifically ask for LCAS capability via 394 signaling... 396 3.2. Mechanism to Support Multiple Client to End Point Mappings 398 This is a very important capability and it is very similar to one 399 that is being proposed in the end-to-end signaling for recovery I-D. 400 In particular the ASSOCIATION object. Note, however, since there is 401 a rather high probability that at some point we might use VCAT/LCAS 402 with GMPLS based protection we would really need an ASSOCIATION 403 object type specific to VCAT. Association objects are not unique and 404 therefore adding a new type to the Association object would make it a 405 good candidate to support this requirement. 407 3.3. Support for Component Signal Configuration Scenarios 409 TBD based on analysis of use of admin-status object. If the admin- 410 status object is sufficient we will detail its use in this 411 application since it is currently an optional object. 413 4. References 415 [1] Bernstein, G., Caviglia, D., and R. Rabbat, "VCAT/LCAS in a 416 Clamshell", To Be Published available at http:// 417 www.grotto-networking.com/pages/VCAT-in-a-Clamshell-DRAFT.pdf, 418 October 2005. 420 [2] International Telecommunications Union, "Network node interface 421 for the synchronous digital hierarchy (SDH)", ITU- 422 T Recommendation G.707, December 2003. 424 [3] American National Standards Institute, "Synchronous Optical 425 Network (SONET) - Basic Description including Multiplex 426 Structure, Rates, and Formats", ANSI T1.105-2001, 2001. 428 [4] "Link capacity adjustment scheme (LCAS) for virtual concatenated 429 signals", ITU-T Recommendation G.7042, February 2004. 431 [5] "Virtual concatenation of plesiochronous digital hierarchy (PDH) 432 signals", ITU-T Recommendation G.7043, July 2004. 434 [6] "Interfaces for the Optical Transport Network (OTN)", ITU- 435 T Recommendation G.709, March 2003. 437 [7] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 438 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 439 August 1996. 441 [8] "Information technology - Telecommunications and information 442 exchange between systems - Local and metropolitan area networks 443 - Specific requirements - Part 3: Carrier sense multiple access 444 with collision detection (CSMA/CD) access method and physical 445 layer specifications", IEEE Standard 802.3, March 2002. 447 [9] Bernstein, G., Rajagopalan, B., and D. Saha, "Optical Network 448 Control: Archtecture, Protocols", Addison-Wesley, 2004. 450 Appendix A. Acknowledgements 452 The authors would like to thank Maarten Vissers for extensive reviews 453 and contributions to this draft. 455 Authors' Addresses 457 Greg Bernstein 458 Grotto Networking 460 Phone: +1 510 573 2237 461 Email: gregb@grotto-networking.com 463 Diego Caviglia 464 Marconi 466 Email: Diego.Caviglia@marconi.com 468 Richard Rabbat 469 Fujitsu 471 Phone: +1 408 530 4537 472 Email: richard@us.fujitsu.com 474 Intellectual Property Statement 476 The IETF takes no position regarding the validity or scope of any 477 Intellectual Property Rights or other rights that might be claimed to 478 pertain to the implementation or use of the technology described in 479 this document or the extent to which any license under such rights 480 might or might not be available; nor does it represent that it has 481 made any independent effort to identify any such rights. Information 482 on the procedures with respect to rights in RFC documents can be 483 found in BCP 78 and BCP 79. 485 Copies of IPR disclosures made to the IETF Secretariat and any 486 assurances of licenses to be made available, or the result of an 487 attempt made to obtain a general license or permission for the use of 488 such proprietary rights by implementers or users of this 489 specification can be obtained from the IETF on-line IPR repository at 490 http://www.ietf.org/ipr. 492 The IETF invites any interested party to bring to its attention any 493 copyrights, patents or patent applications, or other proprietary 494 rights that may cover technology that may be required to implement 495 this standard. Please address the information to the IETF at 496 ietf-ipr@ietf.org. 498 Disclaimer of Validity 500 This document and the information contained herein are provided on an 501 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 502 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 503 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 504 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 505 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 506 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 508 Copyright Statement 510 Copyright (C) The Internet Society (2005). This document is subject 511 to the rights, licenses and restrictions contained in BCP 78, and 512 except as set forth therein, the authors retain all their rights. 514 Acknowledgment 516 Funding for the RFC Editor function is currently provided by the 517 Internet Society.