idnits 2.17.1 draft-bernstein-ccamp-gmpls-vcat-lcas-04.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3946, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3946, updated by this document, for RFC5378 checks: 2001-05-11) -- 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 (August 4, 2006) is 6447 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) == Unused Reference: 'ITU-T-G.7043' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'ITU-T-G.707' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'ITU-T-G.709' is defined on line 523, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3946 (Obsoleted by RFC 4606) -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E-RECOVERY' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Updates: RFC 3946 D. Caviglia 4 Category: Standards Track Ericsson 5 Expires: February 2007 R. Rabbat (ed.) 6 Fujitsu 7 H. van Helvoort 8 Huawei 9 August 4, 2006 11 Operating Virtual Concatenation (VCAT) and the Link Capacity 12 Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label 13 Switching (GMPLS) 14 draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on February 4, 2007. 42 Abstract 44 This document describes requirements for, and use of, the Generalized 45 Multi-Protocol Label Switching (GMPLS) control plane in conjunction 46 with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 47 mechanism and its companion Link Capacity Adjustment Scheme (LCAS) 48 which can be used for hitless dynamic resizing of the inverse 49 multiplex group. These techniques apply to the Optical Transport 50 Network (OTN), Synchronous Optical Network (SONET), Synchronous 51 Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) 52 signals. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119 [RFC2119]. 60 Table of Contents 62 1. Introduction...................................................3 63 2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-03..........3 64 3. VCAT/LCAS Scenarios and Specific Requirements..................3 65 3.1. Multiple VCAT Groups per GMPLS Endpoint...................3 66 3.2. Component Signal Configuration Requirements...............4 67 3.3. VCAT Operation With or Without LCAS.......................4 68 4. GMPLS Mechanisms for Signaling VCAT/LCAS.......................4 69 4.1. Co-Routed Signals.........................................5 70 4.1.1. One-shot Setup of Co-Routed Signal...................5 71 4.1.2. Incremental Setup of Co-Routed Signal................5 72 4.1.3. Removing a Component Signal..........................6 73 4.1.4. Removing Multiple Component Signals in One Shot......6 74 4.1.5. Use of multiple LSPs for Co-Routed Signals...........7 75 4.1.6. Teardown of Whole VCG................................7 76 4.2. Diversely Routed Signals..................................7 77 4.2.1. Associating Diversely Routed Signals.................7 78 4.2.2. Procedures for VCG Setup Using Diversely Routed 79 Components..................................................8 80 4.2.3. Procedures for VCG Reduction/Teardown Using Diversely 81 Routed Components...........................................9 82 4.2.4. Update of Already Established LSPs...................9 83 4.2.5. One LSP per Circuit..................................9 84 5. IANA Considerations...........................................10 85 6. Security Considerations.......................................10 86 7. Contributors..................................................11 87 8. Acknowledgments...............................................11 88 9. References....................................................12 89 9.1. Normative References.....................................12 90 9.2. Informative References...................................12 91 Author's Addresses...............................................13 92 Intellectual Property Statement..................................14 93 Disclaimer of Validity...........................................14 94 Copyright Statement..............................................14 95 Acknowledgment...................................................15 97 1. Introduction 99 The Generalized Multi-Protocol Label Switching (GMPLS) suite of 100 protocols allows the automated control of different switching 101 technologies including SONET/SDH. 103 This document describes extensions to RSVP-TE to support the Virtual 104 Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its 105 companion Link Capacity Adjustment Scheme (LCAS). These extensions 106 enable the setup of diversely routed circuits that are members of the 107 same VCAT group. 109 2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-03 111 o Dropped appendices 113 o Updated references 115 o Fixed error w/r to sessions. The LSPs belong to different sessions 117 o Many editorial changes throughout the document 119 o Rewrote the introduction 121 3. VCAT/LCAS Scenarios and Specific Requirements 123 There are a number of specific requirements for the support of 124 VCAT/LCAS in GMPLS that can be derived from the carriers' 125 application-specific demands for the use of VCAT/LCAS and from the 126 flexible nature of VCAT/LCAS. These are set out in the following 127 section. 129 3.1. Multiple VCAT Groups per GMPLS Endpoint 131 In general, an LSR can be ingress/egress of one or more VCAT groups. 132 VCAT and LCAS are interface capabilities. An LSR may have, for 133 example, VCAT-capable interfaces that are not LCAS-capable. It may 134 at the same time have interfaces that are neither VCAT nor LCAS- 135 capable. 137 3.2. Component Signal Configuration Requirements 139 We list in this section the different scenarios that SHOULD be 140 supported. Here we use the term "VCG" to refer to the entire VCAT 141 group and the terminology "set" and "subset" to refer to the 142 collection of potential VCAT group member signals. 144 o Fixed, co-routed: A fixed bandwidth VCG, transported over a co- 145 routed set of member signals. This is the case where the intended 146 bandwidth of the VCG does not change and all member signals follow 147 the same route and minimize differential delay. The intent here 148 is the capability to allocate an amount of bandwidth close to that 149 required at the client layer. 151 o Fixed, diversely routed: A fixed bandwidth VCG, transported over 152 at least two diversely routed subsets of member signals. In this 153 case, the subsets are link-disjoint over at least one link of the 154 route. The intent here is more efficient use of network resources 155 (no unique route has the required bandwidth), and additional 156 resilience and graceful degradation in the case of failure (note 157 that differential delay may be a limiting factor). 159 o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or 160 decreased via the addition or removal of member signals), 161 transported over a co-routed set of members. Intent here is 162 dynamic sizing of bandwidth. 164 o Dynamic, diversely routed: A dynamic VCAT group, transported over 165 at least two diversely routed subsets of member signals. The 166 intent here is dynamic resizing and resilience (but differential 167 delay may be a limiting factor). 169 3.3. VCAT Operation With or Without LCAS 171 VCAT capabilities may be present with or without the presence of 172 LCAS. The use of LCAS is beneficial to the provision of services, 173 but in the absence of LCAS, VCAT is still a valid technique. 174 Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for 175 both the case where LCAS is available and the case where it is not 176 available. The GMPLS procedures for the two cases SHOULD be 177 identical. 179 4. GMPLS Mechanisms for Signaling VCAT/LCAS 181 We describe in this section the signaling mechanisms that already 182 exist in GMPLS using RSVP-TE [RFC3473] and the extensions needed, for 183 diversely routed paths and in support of the LCAS procedure. 185 Section 4.1 is included for informational purposes only. It 186 describes existing procedures and makes no changes. 188 Section 4.2 describes new procedures to support diversely routed VCAT 189 groups. Where possible it reuses applicable existing procedures from 190 section 4.1. 192 4.1. Co-Routed Signals 194 Note that this section is for informational purposes only. 196 The existing signaling protocols support co-routed signal setup using 197 the NVC field as explained in section 2.1 of [RFC3946bis]. In this 198 case, one single LSP is set up in support of the VCAT group. 200 There are two options for setting up the VCAT group, depending on 201 hardware capability, or management preferences: one-shot setup and 202 incremental setup. 204 The following sections explain the procedure based on an example of 205 setting up a VC4-7v SDH VCAT group (corresponding to an STS-3c-7v 206 SONET VCAT group). 208 4.1.1. One-shot Setup of Co-Routed Signal 210 An RSVP-TE Path message is used with the following parameters. 212 With regards to the traffic parameters, the elementary signal is 213 chosen (6 for VC-4/STS-3c_SPE). The value of NVC is then set to 7. 215 A Multiplier Transform greater than 1 (say N>1) is used if the 216 operator wants to set up N VCAT groups that will belong to, and be 217 assigned to, one LSP. 219 SDH or SONET labels in turn have to be assigned for each member of 220 the VCG and concatenated to form a single Generalized Label 221 constructed as an ordered list of 32-bit timeslot identifiers of the 222 same format as TDM labels. [RFC3946bis] requires that the order of 223 the labels reflect the order of the payloads to concatenate, and not 224 the physical order of time-slots. 226 4.1.2. Incremental Setup of Co-Routed Signal 228 In some cases, it may be necessary or desirable to set up the VCG 229 members individually, or to add group members to an existing group. 231 One example of this need is when the hardware that supports VCAT can 232 only add VCAT elements one at a time or cannot automatically match 233 the elements at the ingress and egress for the purposes of inverse 234 multiplexing. Serial or incremental setup solves this problem. 236 In order to accomplish incremental setup an iterative process is used 237 to add group members. For each iteration, NVC is incremented up to 238 the final value required. The iteration consists of the successful 239 completion of Path and Resv signaling. At first, NVC = 1 and the 240 label includes just one timeslot identifier 242 At each of the next iterations, NVC is set to (NVC +1), one more 243 timeslot identifier is added to the ordered list in the Generalized 244 Label (in the Path or Resv message). A node that receives a Path 245 message that contains changed fields will process the full Path 246 message and, based on the new value of NVC, it will add a component 247 signal to the VCAT group, and switch the new timeslot based on the 248 new label information. 250 Following the addition of the new label to the LSP, LCAS may be used 251 in-band to add the new label into the existing VCAT group. LCAS 252 signaling for this function is described in [ITU-T-G.7042]. 254 4.1.3. Removing a Component Signal 256 The procedure to remove a component signal is similar to that used to 257 add components as described in Section 4.1.2. The LCAS in-band 258 signaling step is taken first to take the component out of the group. 259 LCAS signaling is described in [ITU-T-G.7042]. 261 In this case, the NVC value is decremented by 1 and the timeslot 262 identifier for the dropped component is removed from the ordered list 263 in the Generalized Label. This function is not supported without 264 management intervention for VCAT-only interfaces as removing one 265 component of the VCG will result in errors in the inverse- 266 multiplexing procedure of VCAT and result in the teardown of the 267 whole group. So, this is a feature that only LCAS-capable VCAT 268 interfaces can support without management intervention at the end 269 points. 271 4.1.4. Removing Multiple Component Signals in One Shot 273 The procedure is similar to 4.1.3. In this case, the NVC value is 274 changed to the new value and all relevant timeslot identifiers for 275 the components to be torn down are removed from the ordered list in 276 the Generalized Label. This is also not supported for VCAT-only 277 interfaces without management intervention as removing one component 278 of the VCG will tear down the whole group, but the use of LCAS can 279 facilitate this procedure. 281 4.1.5. Use of multiple LSPs for Co-Routed Signals 283 Co-routed signals may also be supported by distinct LSPs signaled 284 separately using exactly the techniques described for diversely 285 routed signals in Section 4.2. 287 4.1.6. Teardown of Whole VCG 289 The entire LSP is deleted in a single step (i.e., all components are 290 removed in one go) using deletion procedures of [RFC3473]. 292 4.2. Diversely Routed Signals 294 The initial GMPLS specification did not support diversely routed 295 signals using the NVC construct. In fact, [RFC3946bis] says: 297 [...] The standard definition for virtual concatenation allows 298 each virtual concatenation components to travel over diverse 299 paths. Within GMPLS, virtual concatenation components must 300 travel over the same (component) link if they are part of the 301 same LSP. This is due to the way that labels are bound to a 302 (component) link. Note however, that the routing of components 303 on different paths is indeed equivalent to establishing 304 different LSPs, each one having its own route. Several LSPs 305 can be initiated and terminated between the same nodes and 306 their corresponding components can then be associated together 307 (i.e., virtually concatenated). 309 Diverse routing of signals can be a useful capability but requires 310 the extensions identified in this document. 312 4.2.1. Associating Diversely Routed Signals 314 The feature that needs to be added is the functionality to associate 315 the components of the same VCG. For this purpose, we use the 316 Association Object that was defined in [E2E-RECOVERY] to associate 317 working and recovery LSPs. 319 A diversely routed VCG uses a number of routes R <= VCG size, as some 320 routes may be the same for several components. A number of LSPs, L 321 (VCG >= L >= R) are used with each LSP establishing at least one 322 component of the VCG, and at most all of the co-routed members of the 323 group. For a set of c components using the same route, we set up the 324 LSP with NVC = c exactly as explained in section 4.1.1. Therefore, 325 the association of group members or of sub-groups to form the VCG 326 requires the association of the LSPs used to establish the group 327 members. 329 To be able to distinguish the LSPs in the VCG each must have a unique 330 identifier. LSPs are identified by the combination of Session and 331 Sender Template fields. It is common practice when make-before-break 332 [RFC3209] is supported to allow LSPs with the same Session, but 333 different Sender Templates (specifically with different LSP IDs) to 334 share resources. Since resource sharing between VCG members must not 335 be allowed (because we want each LSP to contribute capacity to the 336 VCG), but since we want to continue to support make-before-break for 337 each group member, it is necessary to distinguish the LSPs in the VCG 338 by varying the fields in the Session object. Specifically, a 339 different Tunnel ID is used to identify each LSP in the VCG. 341 Thus, VCG members cannot be associated through the Session object, 342 and the Association object is used instead. 344 The assignment of the Association ID is outside the scope of GMPLS 345 but MUST be unique for each VCAT group. 347 Note that the use of the Association object to associate members of a 348 VCG does not preclude the use of another instance of the object with 349 a different Association ID to indicate the association of working and 350 recovery LSPs, as [E2E-RECOVERY] allows the use of multiple 351 Association objects. We differentiate between the Association 352 objects used for the VCAT group and other Association objects through 353 the definition of a new association type to indicate that this is a 354 VCG association. 356 Association Type: 16 bits 358 Value Type 359 ----- ---- 361 3 VCAT group 363 See [E2E-RECOVERY] for the definition of other fields and values of 364 the Association object. 366 4.2.2. Procedures for VCG Setup Using Diversely Routed Components 368 For every route R, use the procedure outlined in section 4.1.1 or 369 4.1.2 depending on the capability of the equipment or local policy. 370 The Path message MUST include the Association object with type set to 371 3, and each Path message MUST use the same Association ID. 373 Following the addition of each new LSP (i.e., once the RESV message 374 has been received by the ingress LSR), LCAS signaling is used in-band 375 to hitlessly add the new label into the existing group [ITU-T- 376 G.7042]. 378 4.2.3. Procedures for VCG Reduction/Teardown Using Diversely Routed 379 Components 381 To remove the component circuits on any route, LCAS signaling is used 382 in-band to remove the labels associated with the LSP from the group. 383 LCAS signaling is defined in [ITU-T-G.7042]. 385 In addition, the procedures outlined in section 4.1.3 or 4.1.4 are 386 used to tear down the unwanted LSP. 388 Again, this can only be done on LCAS-capable interfaces. If the 389 procedure is attempted on VCAT-only interfaces, then the whole VCG is 390 torn down (this is not a graceful teardown so ingress/egress initiate 391 a Path Tear/Resv Tear) on all routes. 393 4.2.4. Update of Already Established LSPs 395 Established co-routed VCAT groups currently do not support the 396 Association object. If a co-routed VCAT Group size is to be 397 increased with new diversely routed members, we use the LSP 398 modification procedure described in [RFC2205]. An Association object 399 is added to the Path message for the existing LSP(s). That 400 Association object can then be used to set up new diversely routed 401 group members. 403 The same applies to SONET/SDH LSPs. An operator may decide to use an 404 already cross-connected SONET/SDH LSP for diversely-routed VCAT. In 405 this case the modification procedure described in [RFC2205] is used 406 as well. 408 4.2.5. One LSP per Circuit 410 These procedures can support the use of as many LSPs as there are 411 circuits in the VCG. This can be done when each circuit is 412 separately routed, or when some of the circuits are co-routed, and 413 each LSP will be used to set up one element of the VCG. The 414 Association object is used to indicate the VCG association. 416 5. IANA Considerations 418 This document requests from IANA the assignment of a new Association 419 Type within the Association object. This object was defined in [E2E- 420 RECOVERY]. 422 The value 3 "VCAT group" is suggested in section 4.2.1. 424 6. Security Considerations 426 This document introduces a new use of the Association object for 427 GMPLS signaling [RFC3473] to associate diversely routed VCAT group 428 members. It does not introduce any new signaling messages, nor 429 change the relationship between LSRs that are adjacent in the control 430 plane. This association information in the event of an interception 431 may indicate that there are members of the same VCAT group that take 432 a different route and may indicate to an interceptor that the network 433 may be more robust. 435 Otherwise, this document does not introduce any additional security 436 considerations. 438 7. Contributors 440 Wataru Imajuku (NTT) 441 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 442 Japan 444 Phone +81-46-859-4315 445 Email: imajuku.wataru@lab.ntt.co.jp 447 Julien Meuric 448 France Telecom 449 2, avenue Pierre Marzin 450 22307 Lannion Cedex 451 France 453 Phone: + 33 2 96 05 28 28 454 Email: julien.meuric@orange-ft.com 456 Lyndon Ong 457 Ciena 458 PO Box 308 459 Cupertino, CA 95015 460 United States of America 462 Phone: +1 408 705 2978 463 Email: lyong@ciena.com 465 8. Acknowledgments 467 The authors would like to thank Maarten Vissers and Adrian Farrel for 468 extensive reviews and contributions to this draft. 470 9. References 472 9.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, March 1997. 477 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. 478 Jamin, "Resource ReSerVation Protocol (RSVP) -- 479 Version 1, Functional Specification", RFC 2205, 480 September 1997. 482 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 483 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 484 LSP Tunnels", RFC 3209, December 2001. 486 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 487 Switching (GMPLS) Signaling Resource ReserVation 488 Protocol-Traffic Engineering (RSVP-TE) Extensions", 489 RFC 3473, January 2003. 491 [RFC3946bis] Mannie, E. and D. Papadimitriou, "Generalized Multi- 492 Protocol Label Switching (GMPLS) Extensions for 493 Synchronous Optical Network (SONET) and Synchronous 494 Digital Hierarchy (SDH) Control", IETF draft, work in 495 progress, December 2005. 497 [E2E-RECOVERY] Lang, J.P., Rekhter, Y., and D. Papadimitriou (eds.), 498 "RSVP-TE Extensions in support of End-to-End 499 Generalized Multi-Protocol Label Switching (GMPLS)- 500 based Recovery", IETF draft, work in progress, April 501 2005. 503 9.2. Informative References 505 [ANSI-T1.105] American National Standards Institute, "Synchronous 506 Optical Network (SONET) - Basic Description including 507 Multiplex Structure, Rates, and Formats", ANSI T1.105- 508 2001, May 2001. 510 [ITU-T-G.7042] International Telecommunications Union, "Link Capacity 511 Adjustment Scheme (LCAS) for Virtual Concatenated 512 Signals", ITU-T Recommendation G.7042, February 2004. 514 [ITU-T-G.7043] International Telecommunications Union, "Virtual 515 Concatenation of Plesiochronous Digital Hierarchy 516 (PDH) Signals", ITU-T Recommendation G.7043, July 517 2004. 519 [ITU-T-G.707] International Telecommunications Union, "Network Node 520 Interface for the Synchronous Digital Hierarchy 521 (SDH)", ITU-T Recommendation G.707, December 2003. 523 [ITU-T-G.709] International Telecommunications Union, "Interfaces 524 for the Optical Transport Network (OTN)", ITU-T 525 Recommendation G.709, March 2003. 527 Author's Addresses 529 Greg Bernstein 530 Grotto Networking 532 Phone: +1-510-573-2237 533 Email: gregb@grotto-networking.com 535 Diego Caviglia 536 Ericsson 537 Via A. Negrone 1/A 16153 538 Genoa Italy 540 Phone: +39 010 600 3736 541 Email: diego.caviglia@(marconi.com, ericsson.com) 543 Richard Rabbat 544 Fujitsu Laboratories of America 545 1240 East Arques Ave, MS 345 546 Sunnyvale, CA 94085 547 United States of America 549 Phone: +1 408-530-4537 550 Email: richard@us.fujitsu.com 551 Huub van Helvoort 552 Huawei Technologies, Ltd. 553 Kolkgriend 38, 1356 BC Almere 554 The Netherlands 556 Phone: +31 36 5315076 557 Email: hhelvoort@huawei.com 559 Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of Validity 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright Statement 595 Copyright (C) The Internet Society (2006). 597 This document is subject to the rights, licenses and restrictions 598 contained in BCP 78, and except as set forth therein, the authors 599 retain all their rights. 601 Acknowledgment 603 Funding for the RFC Editor function is currently provided by the 604 Internet Society.