Network Working Group J.L. Le Roux (Editor) France Telecom IETF Internet Draft J.P. Vasseur (Editor) Cisco System Inc. Proposed Status: Standard Track Seisho Yasukawa Expires: April 2007 NTT Martin Vigoureux Alcatel October 2006 IGP Routing extensions for discovery of P2MP TE LSP Leaf LSRs draft-leroux-mpls-p2mp-te-autoleaf-02.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. Abstract In various situations, such as TV broadcasting with several regional sources, it is required to setup a series of Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) between a set of head-end Label Switching Routers (LSRs) and a group of leaf LSRs referred to as a Leaf Group. Setting up such a series of P2MP TE LSPs requires for the set of head-end LSRs to be aware of all leaf LSRs, which may lead to the cumbersome configuration of a potentially Le Roux, Vasseur, Yasukawa, Vigoureux [Page 1] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 large number of leaf LSRs on each head-end LSRs. Furthermore leaf LSRs may want to dynamically join or leave a Leaf Group without requiring manual configuration on the head-end LSRs. This document specifies IGP routing extensions for IS-IS and OSPF so as to provide an automatic discovery of the set of leaf LSRs members of a Leaf Group, in order to automate the creation and modification of a series of P2MP TE-LSPs. Conventions used in this document 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. Table of Contents 1. Note........................................................3 2. Terminology.................................................3 3. Introduction................................................3 4. Leaf Group..................................................4 4.1. Description.................................................4 4.2. Required Information........................................4 5. LEAF-GROUP TLV formats......................................4 5.1. OSPF LEAF-GROUP TLV format..................................4 5.2. IS-IS LEAF-GROUP TLV format.................................6 6. Elements of procedure.......................................7 6.1. OSPF........................................................7 6.2. IS-IS.......................................................8 7. Backward compatibility......................................9 8. IANA Considerations.........................................9 8.1. OSPF........................................................9 8.2. IS-IS.......................................................9 9. Security Considerations....................................10 10. References.................................................10 10.1. Normative references.......................................10 10.2. Informative References.....................................11 11. Authors' Address...........................................11 12. Intellectual Property Statement............................12 Le Roux, Vasseur, Yasukawa, Vigoureux [Page 2] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 1. Note This document defines the concept of “Auto-leaf” along with the required IS-IS and OSPF extensions that may be described in separate documents at a later stage. 2. Terminology This document uses terminologies defined in [RFC3031], [RFC3209], [RFC4461], and [RSVP-P2MP-TE]. 3. Introduction [RSVP-P2MP-TE] defines RSVP-TE extensions for setting up P2MP TE LSPs, with one head-end LSR and a set of one or more leaf LSRs (leaves). In various situations, such as for instance TV broadcasting with several non collocated sources, it is required to setup a series of P2MP TE LSPs between a set of head-end LSRs and a common group of leaf LSRs, that is a series of P2MP TE-LSPs with distinct head-end LSRs and the same group of leaf LSRs. Such a group of leaf LSRs is referred to as a "P2MP Leaf Group". The setup of such a P2MP LSP series requires for each head-end LSRs to be aware of all leaf LSRs in the P2MP Leaf Group. It is not uncommon for a P2MP Leaf Group to contain a significant number of leaf LSRs, and there may be a potentially large number of head-end LSRs. In such situations, this requires cumbersome configuration of all leaf LSRs on each head-end LSRs, prone to misconfiguration. Furthermore, Leaf LSRs may desire to dynamically join or leave a P2MP Leaf Group. Hence an automatic mechanism allowing head-end LSRs to discover the leaf LSRs willing to join or leave a Leaf Group would undoubtedly ease the configuration task. This document specifies IGP (OSPF and IS-IS) extensions so as to automatically discover the leaf LSRs of a Leaf Group. Note that the mechanisms needed for the dynamic creation of P2MP TE LSPs and dynamic Leaf addition/removal (grafting/pruning), are implementation specific and outside the scope of this document. An implementation should take special care of implementing the appropriate dampening mechanisms to avoid any unacceptable impact on the IGP scalability. Routing extensions have been defined in [OSPF-CAP] and [ISIS-CAP] in order to advertise router capabilities. This document specifies IGP (OSPF and ISIS) Leaf Group TLVs allowing an LSR to advertise its desire to join/leave one or more Leaf Group(s), to be carried in the OSPF Router Information LSA [OSPF-CAP] and IS-IS Router Capability TLV [ISIS-CAP]. This allows the automatic creation and modification of a series of P2MP TE LSPs without manual intervention. Le Roux, Vasseur, Yasukawa, Vigoureux [Page 3] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 4. Leaf Group 4.1. Description A Leaf Group is defined as a group of LSRs, which are leaves of a series of one or more P2MP TE LSPs. Routing extensions are specified in this document allowing for dynamic discovery of the Leaf Group members. Procedures are also specified for a member to join or leave a Leaf group. An LSR may belong to multiple Leaf Groups. 4.2. Required Information This document specifies a LEAF-GROUP TLV that indicates the set of Leaf Group(s) an LSR belongs to. For each Leaf Group membership announced by an LSR, the LEAF-GROUP TLV is used to advertise a Leaf Group number identifying the Leaf group the LSR belongs to. 5. LEAF-GROUP TLV formats 5.1. OSPF LEAF-GROUP TLV format The format of the OSPF LEAF-GROUP TLV is the same as the TLV format used by the Traffic Engineering Extensions to OSPF [OSPF-TE]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length and a value field. The TLV is zero 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). The OSPF LEAF-GROUP TLV is used to advertise the desire of an LSR to join/leave a set of one or more Leaf Group(s). The OSPF IPv4 LEAF-GROUP TLV (advertised in an OSPFv2 Router Information LSA defined in [OSPF-CAP]) has the following format: TYPE: To be assigned by IANA (Suggested Value: 5) LENGTH: Variable (>=8, multiple of 4) VALUE: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf LSR IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf Group Number 1 | // // | Leaf Group Number N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - IPv4 LEAF-GROUP TLV format Le Roux, Vasseur, Yasukawa, Vigoureux [Page 4] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 The OSPF IPv6 LEAF-GROUP TLV (advertised in an OSPFv3 Router Information LSA defined in [OSPF-CAP]) has the following format: TYPE: To be assigned by IANA (Suggested Value: 6) LENGTH: Variable (>= 20, multiple of 4) VALUE: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Leaf LSR IPv6 address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf Group Number 1 | // // | Leaf Group Number N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - IPv6 LEAF-GROUP TLV format The LEAF-GROUP TLV contains: - A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L sub-LSP destination address (defined in [RSVP-P2MP-TE]). - A set of one or more Leaf Group number(s), encoded with 32 bit integers that identify the Leaf Group(s) the LSR belongs to. Le Roux, Vasseur, Yasukawa, Vigoureux [Page 5] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 5.2. IS-IS LEAF-GROUP TLV format The IS-IS LEAF-GROUP TLV is composed of 1 octet for the type, 1 octet specifying the TLV length and a value field. The format of the LEAF- GROUP TLV is identical to the TLV format used by the Traffic Engineering Extensions for IS-IS [RFC3784]. The ISIS LEAF-GROUP TLV is used to advertise the desire of an LSR to join/leave a set of one or more Leaf Groups. The ISIS IPv4 LEAF-GROUP TLV (advertised in an IS-IS Router Capability TLV defined in [ISIS-CAP]) has the following format: TYPE: To be assigned by IANA (Suggested Value: 5) LENGTH: Variable (>=8, multiple of 4) VALUE: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf LSR IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf Group Number 1 | // // | Leaf Group Number N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - IPv4 LEAF-GROUP TLV format The ISIS IPv6 LEAF-GROUP TLV (advertised in an IS-IS router information LSA defined in [ISIS-CAP]) has the following format: TYPE: To be assigned by IANA (Suggested Value: 6) LENGTH: Variable VALUE: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Leaf LSR IPv6 address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf Group Number 1 | // // | Leaf Group Number N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - IPv6 LEAF-GROUP TLV format Le Roux, Vasseur, Yasukawa, Vigoureux [Page 6] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 The P2MP-LEAF-GROUP TLV comprises: - A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L sub-LSP destination address (defined in [RSVP-P2MP-TE]). - A set of one or more Leaf Group number(s), encoded with 32 bit integers that identifies the Leaf Group(s) the LSR belongs to. 6. Elements of procedure 6.1. OSPF The LEAF-GROUP TLV is carried within an OSPFv2 Router Information LSA (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router information LSA (function code of 12) that are defined in [OSPF-CAP]. As such, elements of procedure are inherited from those defined in [OSPF-CAP]. The LEAF-GROUP TLV is OPTIONAL. An OSPF Router Information LSA may comprise zero one or more LEAF-GROUP TLVs. Several TLVs are used when distinct destination addresses have to be used for distinct Leaf Groups. In OSPFv2 the flooding scope is controlled by the opaque LSA type (as defined in [RFC2370]) and in OSPFv3 by the S1/S2 bits (as defined in [OSPFv3]). The LEAF-GROUP TLV flooding scope will be determined according to the location of the head-end LSR(s) for the P2MP TE LSP related to the LEAF GROUP and the location of the Leaf LSR originating the LEAF- GROUP TLV: - If the head-end LSR(s) and leaf LSR originating the P2MP-LEAF- GROUP TLV are located within the same area, the LEAF-GROUP TLV MUST be generated within an OSPFV2 type 10 Router Information LSA or an OSPFV3 Router Information LSA with the S1 bit set and the S2 bit cleared. - If the head-end LSR(s) and leaf LSRs originating the LEAF-GROUP TLV are located within distinct areas the LEAF-GROUP TLV MUST be generated within an OSPFV2 type 11 Router Information LSA or an OSPFV3 Router Information LSA with the S1 bit cleared and the S2 bit set. A router MUST originate a new OSPF Router Information LSA whenever the content of the advertised LEAF-GROUP TLV changes or whenever required by the regular OSPF procedure (LSA refresh (every LSRefreshTime)). If an LSR desires to join or leave a particular Leaf group, it MUST originate a new OSPF Router Information LSA containing the updated LEAF-GROUP TLV. In the case of a join a new entry will be added to the LEAF-GROUP TLV; conversely, if the LSR leaves a Leaf Group the corresponding entry will be removed from the LEAF-GROUP Le Roux, Vasseur, Yasukawa, Vigoureux [Page 7] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 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 LEAF-GROUP TLV from a specific LSR. A P2MP LSP is likely to aggregate a large number of multicast channels and hence the number of Leaf Groups an LSR belongs to is expected to be very small, typically less than 10. Otherwise, in the case of a large number of Leaf Groups care should be given to the relevance of using an IGP-based discovery mechanism. Moreover, as spelt out in [RFC4461], the dynamics of the P2MP LSP is likely to be relatively small. A working figure for an established P2MP TE LSP is less than 10% churn per day; that is, a relatively slow rate of churn. Nevertheless appropriate rate limiting and dampening mechanisms SHOULD be implemented so as to avoid any unacceptable impact on IGP scalability. The dampening and rate limiting algorithms in use are outside of the scope of this document. 6.2. IS-IS The LEAF-GROUP TLV is carried within the IS-IS Router CAPABILITY TLV that is defined in [ISIS-CAP]. As such, elements of procedure are inherited from those defined in [ISIS-CAP]. The LEAF-GROUP TLV is OPTIONAL. An IS-IS Router CAPABILITY TLV may comprise zero one or more LEAF-GROUP TLVs. Several TVLs are used when distinct destination addresses have to be used for distinct Leaf Groups. The LEAF-GROUP TLV flooding scope will depend on the head-end LSR(s) and generating LSR location: - If the head-end LSR(s) and generating LSR are located within a single IS-IS area/level, the LEAF-GROUP TLV MUST not be leaked across IS-IS level/area and the S flag of the Router CAPABILITY TLV MUST be cleared. - If the head-end LSR(s) and generating LSR are located within distinct IS-IS area/level, the LEAF-GROUP TLV MUST be leaked across IS-IS level/area and the S flag of the Router CAPABILITY TLV MUST be set. An IS-IS router MUST originate a new IS-IS LSP whenever the content of the advertised LEAF-GROUP TLV changes or whenever required by the regular IS-IS procedure (LSP refresh). If an LSR desires to join or leave a particular Leaf Group, it MUST originate a new IS-IS LSP containing the updated LEAF-GROUP TLV. In the case of a join a new entry will be added to the LEAF-GROUP TLV; conversely, if the LSR leaves a Leaf Group the corresponding entry will be removed from the LEAF-GROUP TLV. Note that both operations can be performed in the context of a single refresh. An implementation SHOULD be able to Le Roux, Vasseur, Yasukawa, Vigoureux [Page 8] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 detect any change to a previously received LEAF-GROUP TLV from a specific LSR. A P2MP LSP is likely to aggregate a large number of multicast channels and hence the number of Leaf groups an LSR belongs to is expected to be very small, typically less than 10. Otherwise, in the case of a large number of Leaf Groups care should be given to the relevance of using an IGP-based discovery mechanism. Moreover, as spelt out in [RFC4461], the dynamics of the P2MP LSP is likely to be relatively small. A working figure for an established P2MP TE LSP is less than 10% churn per day; that is, a relatively slow rate of churn. Nevertheless appropriate rate limiting and dampening mechanisms SHOULD be implemented so as to avoid any unacceptable impact on IGP scalability. The dampening and rate limiting algorithms in use are outside of the scope of this document. 7. Backward compatibility The LEAF-GROUP TLVs defined in this document do not introduce any interoperability issue. For OSPF, a router not supporting the LEAF-GROUP TLV MUST just silently ignore the TLV as specified in [OSPF-CAP]. For IS-IS a router not supporting the LEAF-GROUP TLV MUST just silently ignore the TLV as specified in [IS-IS-CAP]. 8. IANA Considerations 8.1. OSPF IANA is in charge of the assignment of TLV code points for the Router Information LSA defined in [OSPF-CAP]. IANA will assign a new codepoint for the LEAF-GROUP TLVs defined in this document and carried within the Router Information LSA. IPv4 LEAF-GROUP TLV (suggested value=5) IPv6 LEAF-GROUP TLV (suggested value=6) 8.2. IS-IS IANA is in charge of the assignment of TLV code points for the IS-IS Router CAPABILITY TLV defined in [ISIS-CAP]. IANA will assign a new codepoint for the LEAF-GROUP TLVs defined in this document and carried within the IS-IS Router CAPABILITY TLV. IPv4 LEAF-GROUP TLV (suggested value=5) IPv6 LEAF-GROUP TLV (suggested value=6) Le Roux, Vasseur, Yasukawa, Vigoureux [Page 9] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 9. Security Considerations This document specifies the content of the LEAF GROUP TLV in IS-IS and OSPF, to be used for automating the setup of P2MP TE-LSPs. As this TLV is not used for SPF computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with this TLV may have an effect on the configuration of P2MP TE-LSP. Mechanisms defined to secure IS-IS Link State PDUs [ISIS-HMAC], OSPF LSAs [OSPF-SIG], and their TLVs, can be used to secure this TLV as well. DoS attacks that would consist of advertising a considerable number of Leaf Groups would not lead to the generation of the corresponding P2MP TE LSPs since this would also require for other LSRs acting as head-end to be also configured with matching Leaf Groups. 10. References 10.1. Normative references [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005. [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF-v3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [IS-IS] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol " ISO 10589. [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003. [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, J.P., "Extensions to OSPF for advertising Optional Router Capabilities", draft-ietf-ospf-cap, work in progress. Le Roux, Vasseur, Yasukawa, Vigoureux [Page 10] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising router information", draft-ietf-isis-caps, work in progress. [RSVP-P2MP-TE] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- p2mp, work in progress. 10.2. Informative References [RFC4461] Yasukawa, S., et. al., "Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006. 11. Authors' Addresses Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@francetelecom.com JP Vasseur (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 USA Email: jpv@cisco.com Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Martin Vigoureux Alcatel Route de Nozay, 91461 Marcoussis cedex, France Phone: +33 (0)1 69 63 18 52 Email: martin.vigoureux@alcatel.fr Le Roux, Vasseur, Yasukawa, Vigoureux [Page 11] Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-02.txt October 2006 12. 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. Le Roux, Vasseur, Yasukawa, Vigoureux [Page 12]