Networking Working Group JP. Vasseur (Editor) Internet-Draft Cisco Systems, Inc Expires: August 9, 2006 JL. Leroux (Editor) France Telecom S. Yasukawa NTT S. Previdi P. Psenak Cisco Systems, Inc P. Mabbey Comcast February 5, 2006 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership draft-ietf-ccamp-automesh-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Vasseur, Le Roux et al. Expires August 9, 2006 [Page 1] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 The set up of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Path (LSP) among a set of Label Switch Routers (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IGP routing extensions for ISIS and OSPF so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Vasseur, Le Roux et al. Expires August 9, 2006 [Page 2] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. TE Mesh-Group . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Required Information . . . . . . . . . . . . . . . . . . . 5 4. TE-MESH-GROUP TLV formats . . . . . . . . . . . . . . . . . . 5 4.1. OSPF TE-MESH-GROUP TLV format . . . . . . . . . . . . . . 5 4.2. IS-IS TE-MESH-GROUP TLV format . . . . . . . . . . . . . . 8 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 10 5.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Backward compatibility . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Vasseur, Le Roux et al. Expires August 9, 2006 [Page 3] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 1. Terminology Terminology used in this document LSR: Label Switch Router. TE LSP: Traffic Engineering Label Switched Path. TE LSP head-end: head/source of the TE LSP. TE LSP tail-end: tail/destination of the TE LSP. IGP Area: OSPF area or IS-IS level. 2. Introduction There are two well-known approaches in deploying MPLS Traffic Engineering: (1) The so-called "strategic" approach that consists of setting up a full mesh of TE LSPs between a set of LSRs, (2) The so-called "tactical" approach where a set of TE LSPs are provisioned on well identified "hot spots" in order to alleviate a congestion resulting for instance from an unexpected traffic growth in some parts of the network. The set up of a full mesh of TE LSPs among a set of LSRs is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Setting up a full mesh of TE LSPs between N LSRs requires the configuration of a potentially large number of TE LSPs (O(N^2)). Furthermore, the addition of any new LSR in the mesh requires the configuration of N additional TE LSPs on the new LSR and one new TE LSP on every LSR of the existing mesh destined to this new LSR, which gives a total of 2*N TE LSPs to be configured. Such operation is not only time consuming but also a risky operation (prone to misconfiguration) for Service Providers. Hence, an automatic mechanism for setting up TE LSPs meshes is desirable and requires the ability to automatically discover the LSRs that belong to the mesh. This document specifies routing extensions so as to automatically discover the members of a mesh, also referred to as a "TE mesh- group". Note that the mechanism(s) needed for the dynamic creation of TE LSPs is implementation specific and outside the scope of this document. Routing extensions have been defined in [I-D.ietf-ospf-cap] and Vasseur, Le Roux et al. Expires August 9, 2006 [Page 4] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 [I-D.ietf-isis-caps] in order to advertise router capabilities. This document specifies IGP (OSPF and IS-IS) TE Mesh Group TLVs allowing for the automatic discovery of a TE LSP mesh members, to be carried in the OSPF Router Information LSA [I-D.ietf-ospf-cap] and ISIS Router Capability TLV [I-D.ietf-isis-caps]. The routing extensions specified in this document provide the ability to signal multiple TE mesh groups. An LSR may belong to one or more TE mesh-group(s). 3. TE Mesh-Group 3.1. Description A TE mesh-group is defined as a group of LSRs that are connected by a full mesh of TE LSPs. Routing extensions are specified in this document allowing for dynamic discovery of the TE mesh-group members. Procedures are also specified for a member to join and leave a TE mesh-group. 3.2. Required Information This document specifies a TE-MESH-GROUP TLV that indicates the set of TE mesh-group(s) an LSR belongs to. For each TE mesh-group membership announced by an LSR, the TE-MESH-GROUP TLV advertises the following information: - A mesh-group number identifying the TE mesh-group the LSR belongs to. - A Tail-end address (used as TE LSP tail-end address by other LSRs belonging to the same mesh-group). - A Tail-end name: string used to ease the TE-LSP naming. 4. TE-MESH-GROUP TLV formats 4.1. OSPF TE-MESH-GROUP TLV format Vasseur, Le Roux et al. Expires August 9, 2006 [Page 5] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 the OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information LSA defined in [I-D.ietf-ospf-cap]) has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - OSPF TE-MESH-GROUP TLV format Where Type: identifies the TLV type Length: length of the value field in octets The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV format used by the Traffic Engineering Extensions to OSPF (see[RFC3630]). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored. All types between 32768 and 65535 are reserved for vendor-specific extensions. All other undefined type codes are reserved for future assignment by IANA. The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to join/leave a given TE mesh- group. No sub-TLV is currently defined for the TE-mesh-group TLV. Vasseur, Le Roux et al. Expires August 9, 2006 [Page 6] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 The TE-MESH-GROUP TLV has the following format: TYPE: To be assigned by IANA (Suggested Value: 3) LENGTH: Variable 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name (NULL padded display string) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - TE-MESH-GROUP TLV format (IPv4 Address) TYPE: To be assigned by IANA (Suggested Value: 4) LENGTH: Variable 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tail-end IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name (NULL padded display string) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - TE-MESH-GROUP TLV format (IPv6 Address) For each TE mesh-group announced by the LSR, the TE-MESH-GROUP TLV comprises: - A mesh-group-number that identifies the mesh-group number - A Tail-end address: an IPv4 or IPv6 IP address to be used as a tail-end TE LSP address by other LSRs belonging to the same mesh- group - A Tail-end name: a variable length field used to facilitate the TE LSP identification. The Name length field indicates the length of Vasseur, Le Roux et al. Expires August 9, 2006 [Page 7] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 the display string before padding, in bytes. 4.2. IS-IS TE-MESH-GROUP TLV format The IS-IS TE-MESH-GROUP TLV (advertised in the IS-IS CAPABILITY TLV defined in [I-D.ietf-isis-caps] ) is composed of 1 octet for the type, 1 octet specifying the TLV length and a value field. The format of the TE-MESH-GROUP TLV is identical to the TLV format used by the Traffic Engineering Extensions for IS-IS [RFC3784]. The TE- MESH-GROUP TLV is used to advertise the desire of an LSR to join/ leave a given TE mesh-group. No sub-TLV is currently defined for the TE-MESH-GROUP TLV. Vasseur, Le Roux et al. Expires August 9, 2006 [Page 8] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 The TE-MESH-GROUP TLV has the following format: TYPE: To be assigned by IANA (Suggested value: 3). LENGTH: Variable 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name (NULL padded display string) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - TE-MESH-GROUP TLV format (IPv4 Address) TYPE: To be assigned by IANA (Suggested Value: 4) LENGTH: Variable 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tail-end IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name (NULL padded display string) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - TE-MESH-GROUP TLV format (IPv6 Address) For each TE mesh-group announced by the LSR, the TE-MESH-GROUP TLV comprises: - A mesh-group-number that identifies the mesh-group number - A Tail-end address: an IPv4 or IPv6 IP address to be used as a tail-end TE LSP address by other LSRs belonging to the same mesh- group Vasseur, Le Roux et al. Expires August 9, 2006 [Page 9] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 - A Tail-end name: a variable length field used to facilitate the TE LSP identification. The Name length field indicates the length of the display string before padding, in bytes. 5. Elements of procedure The TE-MESH-GROUP TLV is carried within the OSPF Routing Information LSA or ISIS Router capability TLV. As such, elements of procedure are inherited from those defined in [I-D.ietf-ospf-cap] and [I-D.ietf-isis-caps] for OSPF and ISIS respectively. Specifically, a router MUST originate a new LSA/LSP whenever the content of this information changes, or whenever required by regular routing procedure (e.g. refresh). The TE-MESH-GROUP TLV is OPTIONAL and must at most appear once in a OSPF Router Information LSA or ISIS Router Capability TLV. 5.1. OSPF The TE-MESH-GROUP TLV is advertised within an OSPF Router Information opaque LSA (opaque type of 4, opaque ID of 0) as defined in [I-D.ietf-ospf-cap]. A router MUST originate a new OSPF router information LSA whenever the content of the any of the advertised TLV changes or whenever required by the regular OSPF procedure (LSA refresh (every LSRefreshTime)). If an LSR desires to join or leave a particular TE mesh group, it MUST originate a new OSPF Router Information LSA comprising the updated TE-MESH-GROUP TLV. In the case of a join, a new entry will be added to the TE-MESH-GROUP TLV; conversely, if the LSR leaves a mesh-group the corresponding entry will be removed from the TE-MESH-GROUP TLV. Note that both operations can be performed in the context of a single refresh. An implementation SHOULD be able to detect any change to a previously received TE-MESH-GROUP TLV from a specific LSR. As defined in [RFC2370], an opaque LSA has a flooding scope determined by its LSA type: - link-local (type 9); - area-local (type 10); - entire OSPF routing domain (type 11). In this case, the flooding scope is equivalent to the Type 5 LSA flooding scope. A router may generate multiple OSPF Router Information LSAs with different flooding scopes. The TE-MESH-GROUP TLV may be advertised within a type 10 or 11 Router Information LSA depending on the MPLS TE mesh Vasseur, Le Roux et al. Expires August 9, 2006 [Page 10] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 group profile: - If the MPLS TE mesh-group is contained within a single area (all the LSRs of the mesh-group are contained within a single area), the TE-MESH-GROUP TLV MUST be generated within a Type 10 Router Information LSA; - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- group TLV MUST be generated within a Type 11 router information LSA. It is expected that the number of mesh-groups and consequently the number of TE-MESH-GROUP TLVs advertised within a Routing Information LSA will be very limited (to at most 10 or so). Moreover, TE mesh- group membership is fairly static and should not change frequently. 5.2. ISIS The TE-MESH-GROUP TLV is advertised within the IS-IS Router CAPABILITY TLV defined in [I-D.ietf-isis-caps]. An IS-IS router MUST originate a new IS-IS LSP whenever the content of the any of the advertised sub-TLV changes or whenever required by regular IS-IS procedure (LSP refresh). If an LSR desires to join or leave a particular TE mesh group, it MUST originate a new LSP comprising the refreshed ISIS Router capability TLV comprising the updated TE-MESH- GROUP TLV. In the case of a join, a new entry will be added to the TE-MESH-GROUP TLV; conversely, if the LSR leaves a mesh-group the corresponding entry will be deleted to the TE-MESH-GROUP TLV. Note that both operations can be performed in the context of a single refresh. An implementation SHOULD be able to detect any change to a previously received TE-MESH-GROUP TLV from a specific LSR. If the flooding scope of an MPLS Traffic Engineering capability is limited to an IS-IS level/area, the TLV MUST not be leaked across level/area and the S flag of the Router CAPABILITY TLV MUST be cleared. Conversely, if the flooding scope of an MPLS Traffic Engineering capability is the entire routing domain, the TLV MUST be leaked across IS-IS levels/areas, and the S flag of the Router CAPABILITY TLV MUST be set. In both cases the flooding rules specified in [I-D.ietf-isis-caps] apply. As specified in [I-D.ietf-isis-caps], a router may generate multiple IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. It is expected that the number of mesh groups and consequently the number of TE-MESH-GROUP TLV advertised within an ISIS Router Capability TLV will be very limited (to at most 10 or so). Moreover, TE mesh-group membership is fairly static and should not change Vasseur, Le Roux et al. Expires August 9, 2006 [Page 11] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 frequently. 6. Backward compatibility The TE-MESH-GROUP TLVs defined in this document do not introduce any interoperability issue. For OSPF, a router not supporting the TE- MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in [RFC2370]. For IS-IS a router not supporting the TE-MESH-GROUP TLV SHOULD just silently ignore the TLV. 7. IANA Considerations OSPF IANA will assign new OSPF TLV code-point for the newly defined TE- MESH-GROUP TLVs carried within the Router Information LSA. TE-MESH-GROUP TLV (IPv4) (suggested value=3) TE-MESH-GROUP TLV (IPv6) (suggested value=4) ISIS IANA will assign new ISIS TLV code-point for the newly defined TE- MESH-GROUP TLVs carried within the ISIS Router Capability TLV. TE-MESH-GROUP TLV (IPv4) (suggested value=3) TE-MESH-GROUP TLV (IPv6) (suggested value=4) 8. Security Considerations No new security issues are raised in this document. 9. Acknowledgements We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec and Dave Ward for their useful comments. 10. References Vasseur, Le Roux et al. Expires August 9, 2006 [Page 12] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 10.1. Normative References [I-D.ietf-isis-caps] Vasseur, J., "IS-IS Extensions for Advertising Router Information", draft-ietf-isis-caps-06 (work in progress), January 2006. [I-D.ietf-ospf-cap] Lindem, A., "Extensions to OSPF for Advertising Optional Router Capabilities", draft-ietf-ospf-cap-08 (work in progress), December 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. 10.2. Informative References [OSPF-TE] Katz, et al., RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2", September 2003. [PCE-DISCO] J.L Le Roux, JP Vasseur et al, draft-ietf-pce-disco-proto-igp (work in progress)., "IGP protocol extensions for Path Computation Element (PCE) Discovery", May . Vasseur, Le Roux et al. Expires August 9, 2006 [Page 13] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 Authors' Addresses JP Vasseur (Editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com JL Le Roux (Editor) France Telecom 2, Avenue Pierre-Marzin Lanion, 22307 FRANCE Email: jeanlouis.leroux@francetelecom.com Seisho Yasukawa NTT 9-11, Midori-Cho 3-Chome Tokyo, 180-8585 JAPAN Email: yasukawa.seisho@lab.ntt.co.jp Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Roma, 00142 Italy Email: sprevidi@cisco.com Peter Psenak Cisco Systems, Inc Pegasus Park DE Kleetlaan 6A Diegmen, 1831 BELGIUM Email: ppsenak@cisco.com Vasseur, Le Roux et al. Expires August 9, 2006 [Page 14] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 Paul Mabbey Comcast USA Email: Vasseur, Le Roux et al. Expires August 9, 2006 [Page 15] Internet-Draft draft-ietf-ccamp-automesh-01.txt February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vasseur, Le Roux et al. Expires August 9, 2006 [Page 16]