Network Working Group Prabakaran T.S Internet Draft Musthafa A.S Document: FutureSoft, a Flextronics draft-praba-l2vpn-vpls-mcast-emul-00.txt Company Expires: August 2005 Multicast Emulation over VPLS draft-praba-l2vpn-vpls-mcast-emul-00.txt Status of this memo By submitting this Internet-Draft, we represent that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668. 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 Virtual Private LAN Service (VPLS), the PE devices provide a logical interconnect such that CE devices belonging to a specific VPLS instance appear to be connected by a single LAN. A VPLS solution performs replication for multicast traffic at the ingress PE devices. When replicated at the ingress PE, multicast traffic wastes bandwidth when 1. Multicast traffic is sent to sites with no members, and 2. Pseudo wires to different sites go through a shared Prabakaran & Musthafa August 2005 [Page 1] INTERNET DRAFT Multicast Emulation over VPLS February 2005 path. This document addresses the above cases by using LDP signaling to emulate Multicast operation over VPLS with out using IGMP and PIM snooping as described in [VPLS-MCAST]. 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. 1. Introduction In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices provide a logical interconnect such that Customer Edge (CE) devices belonging to a specific VPLS instance appear to be connected by a single LAN. Forwarding information base for particular VPLS instance is populated dynamically by source MAC address learning. This is a straightforward solution to support unicast traffic, with reasonable flooding for unicast unknown traffic. Since a VPLS provides LAN emulation for IEEE bridges as wells as for routers, the unicast and multicast traffic need to follow the same path for layer-2 protocols to work properly. As such, multicast traffic is treated as broadcast traffic and is flooded to every site in the VPLS instance. VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication for multicast traffic at the ingress PE devices. When replicated at the ingress PE, multicast traffic wastes bandwidth when: 1. Multicast traffic is sent to sites with no members, 2. Pseudo wires to different sites go through a shared path, and 3. Multicast traffic is forwarded along a shortest path tree as opposed to the minimum cost spanning tree. This document addresses the issue of wasting bandwidth in the above 1 and 2 cases by using LDP signaling to emulate Multicast operation over VPLS with out using IGMP and PIM snooping. Using VPLS in conjunction with the small modification in LDP signaling has the following advantages: - It improves VPLS to support IP multicast efficiently (not necessarily optimum, as there can still be bandwidth waste), - It prevents sending multicast traffic to sites with no members, - It keeps P routers in the core stateless, - The Service Provider (SP) does not need to perform the tasks to provide multicast service (e.g., running PIM, managing P-group addresses, managing multicast tunnels), - The SP does not need to maintain PIM adjacencies with the customers, - This Multicast Emulation over VPLS feature avoids the Prabakaran & Musthafa August 2005 [Page 2] INTERNET DRAFT Multicast Emulation over VPLS February 2005 dependency over multicast protocols like IGMP and PIM snooping or any other multicast routing protocols DVMRP and MOSPF. In this document, we describe the procedures for using LDP signaling to emulate Multicast service without using Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM) snooping over VPLS for efficient distribution of IP multicast traffic. 2. Overview of VPLS In case of VPLS, the PE devices provide a logical interconnect such that CE devices belonging to a specific VPLS appear to be connected by a single LAN. End-to-end VPLS consists of a bridge module and a LAN emulation module ([L2VPN-FR]). In a VPLS, a customer site receives Layer-2 service from the SP. The PE is attached via an access connection to one or more CEs. The PE performs forwarding of user data packets based on information in the Layer-2 header, that is, MAC destination address. The CE sees a bridge. The details of VPLS reference model, which we summarize here, can be found in [L2VPN_FR]. In VPLS, the PE can be viewed as containing a Virtual Switching Instance (VSI) for each L2VPN that it serves. A CE device attaches, possibly through an access network, to a bridge module of a PE. Within the PE, the bridge module attaches, through an Emulated LAN Interface to an Emulated LAN. For each VPLS, there is an Emulated LAN instance. The Emulated LAN consists of VPLS Forwarder module (one per PE per VPLS service instance) connected by pseudo wires (PW), where the PWs may be traveling through Packet Switched Network (PSN) tunnels over a routed backbone. VSI is a logical entity that contains a VPLS forwarder module and part of the bridge module relevant to the VPLS service instance [L2VPN-FR]. Hence, the VSI terminates PWs for interconnection with other VSIs and also terminates attachment circuits (ACs) for accommodating CEs. A VSI includes the forwarding information base for a L2VPN [L2VPN- FR] which is the set of information regarding how to forward Layer-2 frames received over the AC from the CE to VSIs in other PEs supporting the same L2VPN service (and/or to other ACs), and contains information regarding how to forward Layer-2 frames received from PWs to ACs. Forwarding information bases can be populated dynamically (such as by source MAC address learning) or statically (e.g., by configuration). Each PE device is responsible for proper forwarding of the customer traffic to the appropriate destination(s) based on the forwarding information base of the corresponding VSI. Prabakaran & Musthafa August 2005 [Page 3] INTERNET DRAFT Multicast Emulation over VPLS February 2005 3. Multicast Traffic over VPLS In VPLS, if a PE receives a frame from an Attachment Circuit (AC) with no matching entry in the forwarding information base for that particular VPLS instance, it floods the frame to all other PEs (which are part of this VPLS instance) and to directly connected ACs (other than the one that the frame is received from). The flooding of a frame occurs when: - The destination MAC address has not been learned, - The destination MAC address is a broadcast address, - The destination MAC address is a multicast address. Malicious attacks (e.g., receiving unknown frames constantly) aside, the first situation is handled by VPLS solutions as long as destination MAC address can be learned. After that point on, the frames will not be flooded. A PE is REQUIRED to have safeguards, such as unknown unicast limiting and MAC table limiting, against malicious unknown unicast attacks. There is no way around flooding broadcast frames. To prevent runaway broadcast traffic from adversely affecting the VPLS service and the SP network, a PE is REQUIRED to have tools to rate limit the broadcast traffic as well. Similar to broadcast frames, multicast frames are flooded as well, as a PE can not know where multicast members reside. Rate limiting multicast traffic, while possible, should be done carefully since several network control protocols relies on multicast. For one thing, layer-2 and layer-3 protocols utilize multicast for their operation. For instance, Bridge Protocol Data Units (BPDUs) use an IEEE assigned "all bridges multicast MAC address", while OSPF packets are multicast to the "all OSPF routers multicast MAC address". If the rate-limiting of multicast traffic is not done properly, the customer network will experience instability and poor performance. A VPLS solution MUST NOT affect the operation of customer layer-2 protocols (e.g., BPDUs). Additionally, a VPLS solution MUST NOT affect the operation of layer-3 protocols. In the following section, we describe procedures to constrain the flooding of IP multicast traffic in VPLS. 4. Constraining of IP Multicast in a VPLS The objective of improving the efficiency of VPLS for multicast traffic that we are trying to optimize here has the following Prabakaran & Musthafa August 2005 [Page 4] INTERNET DRAFT Multicast Emulation over VPLS February 2005 constraints: - The service is VPLS, i.e., a layer-2 VPN, - In VPLS, ingress replication is required, - There is no layer-3 adjacency (e.g., PIM) between a CE and a PE. Under these circumstances, the one approach is emulating Multicast implementation in VPLS without using IGMP, PIM snooping or any other multicast routing protocols DVMRP and MOSPF. Another approach to constrain multicast traffic in a VPLS is to utilize point-multipoint LSPs (e.g., [PMP-RSVP-TE]). This approach is outside the scope of this document. Note that, in some extremely controlled cases, such as a ring topology of PE routers with no P routers or a tree topology, the efficiency of the replication of IP multicast can be improved. For instance, spoke PWs of a hierarchical VPLS can be daisy-chained together and some replication rules can be devised. These cases are not expected to be common and will not be considered in this document. In the following sections, we provide some guidelines for the implementation of Multicast emulation over VPLS without using IGMP and PIM snooping. 4.1 General Rules for multicast emulation over VPLS using LDP The following rules for the correct operation of multicast emulation over VPLS using LDP signaling MUST be followed. Rule 1: PEs MUST follow the split-horizon rule for mesh PWs as defined in [VPLS-LDP]. Rule 2: Multicast emulation states in a PE MUST be per VPLS instance. Rule 3: If the PE does not have any entry for the multicast emulation state, the multicast traffic to that group in the VPLS instance MUST be flooded. Rule 4: A PE MUST support multicast emulation mode selection per VPLS instance via CLI and/or EMS. 4.2 LDP Extensions Prabakaran & Musthafa August 2005 [Page 5] INTERNET DRAFT Multicast Emulation over VPLS February 2005 A new PW Multicast Flow Status TLV is proposed in this document. The PW Multicast Flow Status TLV will be used in the Label Mapping and Notification messages of LDP. PW Multicast Status TLV manipulates the multicast traffic flooding onto the PWs. The description of the PW Multicast Flow Status TLV is stated below. 4.2.1 PW Multicast Flow Status TLV The format of the PW Multicast Flow(MF) Status TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|PW MF Status (0x096D) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MF Status Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PW MF Status [Note: MF Status TLV type 0x096D as defined in [IANA] pending IANA allocation] Length The length contains the length of the PW Multicast Flow status value in bytes. The length is always 4. MF Status Code MF Status code is specified as bit mask indicating which combination of the option is enabled in MF Status code. The bit fields indicating the MF status code are: 00000001 : MF emulation enable 00000010 : MF emulation disable 00000100 : MF un-register 00001000 : MF register 00010000 : Reserved (unused) 00100000 : Reserved (unused) 01000000 : Reserved (unused) 10000000 : Reserved (unused) The above-mentioned bits are OR-ed to get the final MF status code. When MF emulation disable bit is set then the remaining bit fields are in-significant. The only allowed OR-ing combination is MF Prabakaran & Musthafa August 2005 [Page 6] INTERNET DRAFT Multicast Emulation over VPLS February 2005 emulation enable with MF register or MF un-register and the rest of the combinations are in-significant. Reserved The reserved field is always set to zero and it is unused. 4.2.2 Signaling of Pseudo Wire Multicast Flow Status TLV The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled. When the PWs is first set up, the PEs MUST attempt to check the multicast emulation supported capable, if supported, the PW Multicast Flow Status TLV MUST include it in the initial label mapping signaling following label mapping TLV, the PW FEC, and the interface parameters field. The PW Multicast Flow Status TLV will then be used for the lifetime of the Pseudowire. This is shown in the following diagram: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PWId FEC or Generalized ID FEC + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Generic Label (0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|PW MF Status (0x0???) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MF Status Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If PW status TLV is sent following the label mapping TLV in the initial PW FEC Message, then the PW Multicast Flow Status TLV MUST be included after the PW status TLV. Note that if the PW Multicast Flow Status TLV is not supported, by the remote peer, it will automatically be ignored, since the LDP ignore bit is set. The PW Multicast Flow Status TLV, therefore, will not be present in the Prabakaran & Musthafa August 2005 [Page 7] INTERNET DRAFT Multicast Emulation over VPLS February 2005 corresponding FEC advertisement from the remote LDP peer resulting in exactly the above behavior. If the PW Multicast Flow Status TLV is not present following the label mapping TLV in the initial PW FEC Message received by a PE, then the PW Multicast Flow Status TLV will not be used. Initial label mapping messages between peer results in the usage of the PW Multicast Flow status TLV. Subsequent updates of PW Multicast Flow status is conveyed through the Notification messages. The PW Multicast Flow Status TLV is transported to the remote PW peer via the LDP notification message for PW Multicast Flow status update. The general format of the Notification Message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status (TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Multicast Flow Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC or Generalized ID FEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Status TLV status code is set to 0x0000002B "PW Multicast Flow status", to indicate that PW Multicast Flow status TLV follows. Since this notification does not refer to any particular message the Message Id, and Message Type fields are set to 0. [ Note: Status Code 0x0000002B as defined in [IANA] pending IANA allocation ] The PW FEC TLV processing SHOULD be done similar to the procedure specified in section 5.3.2 of [PW-CTRL-PROT]. 4.3 Operational overview This section details the operation of the scheme proposed in this document. Prabakaran & Musthafa August 2005 [Page 8] INTERNET DRAFT Multicast Emulation over VPLS February 2005 4.3.1 LDP signaling Multicast emulation over VPLS feature capable PE peers by default sets the MF emulation enable bit field in the PW MF status TLV along with either MF register bit field set or with MF un-register bit field set. If the former case is set, the label mapping message receiving PE MUST forward the multicast traffic onto the PW, if the later case is set, the label mapping message receiving PE MUST not send the multicast flow onto the PW. This can be done in the initial label mapping messages between peers or MF emulation enable alone in the initial label mapping and the subsequent update either MF register or MF un-register via notification messages. By default the MF Status code SHOULD set MF emulation enable bit to support this multicast emulation over VPLS feature. The following table shows the expected behavior of the multicast emulation over VPLS capable peer: +-------------------------------------------------------------------+ |MF |MF |MF |MF | | |emulation|emulation|un-register|register| Description | |enable |disable | | | | |---------+---------+-----------+--------+--------------------------| | 1 | 0 | 0 | 0 | Default VPLS behavior | |---------+---------+-----------+--------+--------------------------| | 1 | 0 | 0 | 1 | Send multicast flow on | | | | | | the PW | |-------------------+-----------+--------+--------------------------| | 1 | 0 | 1 | 0 | Don't send multicast | | | | | | flow on the PW(filter) | |---------+---------+-----------+--------+--------------------------| | 1 | 0 | 1 | 1 | Invalid configuration | | | | | | data, default VPLS | | | | | | behavior | |---------+---------+-----------+--------+--------------------------| | x | 1 | x | x | Emulation support | | | | | | disabled, default VPLS | | | | | | behavior | +-------------------------------------------------------------------+ Table 1: MF Status code options The following cases are considered for LDP signaling: Prabakaran & Musthafa August 2005 [Page 9] INTERNET DRAFT Multicast Emulation over VPLS February 2005 Case 1: MF emulation disable bit field is set Initial label mapping messages between PEs with PW MF status TLV has MF emulation disable bit field set, triggers the existing multicast default VPLS behavior and the subsequent update is done using notification messages. Case 2: MF emulation enable bit field is set Initial label mapping messages between PEs with PW MF status TLV has MF emulation enable bit field set, indicates to the peer that the multicast emulation over VPLS feature is supported and the subsequent update is done using notification messages. Case 3: MF emulation enable bit and MF register bit fields are set Initial label mapping messages between PEs with PW MF status TLV has MF emulation enable bit and MF register bit fields set, indicates to the peer that the multicast emulation over VPLS feature is supported and the multicast flow SHOULD be forwarded onto the PW and the subsequent update is done using notification messages. Case 4: MF emulation enable bit and MF un-register bit fields are set Initial label mapping messages between PEs with PW MF status TLV has MF emulation enable bit and MF un-register bit fields set, indicates to the peer that the multicast emulation over VPLS feature is supported and the multicast flow SHOULD NOT be forwarded onto the PW and the subsequent update is done using notification messages. The standard LDP error conditions during LDP signaling SHOULD be handled as detailed in [LDP]. It is also strongly RECOMMENDED that the PW MF status TLV signaling procedures said above is fully implemented. By using the above procedures in LDP signaling, the multicast data traffic filtering is done with out using IGMP and PIM snooping. 4.3.2 Data forwarding The existing default VPLS forwarding behavior states that the received multicast traffic is treated as broadcast traffic and is flooded to every site in the VPLS instance. If we enable Multicast emulation over VPLS feature, the multicast data traffic should not be flooded on the PWs which are requested explicitly not to send multicast data traffic. This can be achieved easily by having normal data forwarding table and multicast data forwarding table at the forwarder. Whenever the multicast traffic is received, the forwarder checks the multicast data forwarding table for the VPLS instance and the corresponding PWs. The multicast data traffic is sent only to the PWs which are all interested in multicast data traffic, this check is done based on the MF un-register flag set at the forwarder level during LDP signaling. The implementation depends Prabakaran & Musthafa August 2005 [Page 10] INTERNET DRAFT Multicast Emulation over VPLS February 2005 on the forwarder architecture and its details are outside the scope of this document. 5 Interoperability considerations The feature described in this document would be operational only if both the PE routers support the LDP extensions described above. If one of them does not support the LDP extensions then the un- supporting PE may silently ignore the additional TLV processing or it may return appropriate advisory notification messages. If, [VPLS- MCAST] draft is implemented then implementing this feature is not much useful. 6. IANA Considerations 6.1 LDP TLV TYPE This document uses a new LDP TLV type, IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The following value is suggested for assignment: TLV type Description 0x096D Multicast Flow(MF) Status TLV 6.2 LDP status messages This document uses a new LDP status code, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The following value is suggested for assignment: 0x0000002B "PW Multicast Flow status" 7. Security Considerations Security considerations provided in VPLS solution documents (i.e., [VPLS-LDP] and [VPLS-BGP) apply to this document as well. 8. References 8.1 Normative References [LDP] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. January 2001. RFC3036 Prabakaran & Musthafa August 2005 [Page 11] INTERNET DRAFT Multicast Emulation over VPLS February 2005 [PW-CTRL-PROT] Eric C. Rosen, Luca Martini, Nasser El-Aawar, Toby Smith, Giles Heron. "Pseudowire Setup and Maintenance using LDP", work in progress [VPLS-LDP] Lasserre, M, et al. "Virtual Private LAN Services over MPLS", work in progress [VPLSD-BGP] Kompella, K, et al. "Virtual Private LAN Service", work in progress [VPLS-MCAST] Serbest, Y, et al. "Supporting IP Multicast over VPLS", work in progress [L2VPN-FR] Andersson, L, et al. "L2VPN Framework", work in progress [PMP-RSVP-TE] Aggarwal, R, et al. "Extensions to RSVP-TE for Point to Multipoint TE LSPs", work in progress 8.2 Informative References [ARCH] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-07.txt (work in progress), September 2004 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998. [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation- 08.txt (work in progress), April 2004 [note1] FEC element type 128,129 is pending IANA approval. [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 9. Acknowledgements The mechanism described in this document has been inspired by prior work about Supporting IP Multicast over VPLS mechanisms. Specifically the draft authored by Y. Serbest, Ray Qiu, Venu Hemige, Rob Nath on Supporting IP Multicast over VPLS, most of the introduction inputs of this document has been taken from the above draft and also which provided the motivation to come up with this Prabakaran & Musthafa August 2005 [Page 12] INTERNET DRAFT Multicast Emulation over VPLS February 2005 contribution. We also wish to place on record the suggestions and review comments given by Sridhar T, Anton Basil R and Manikantan S for this work. The support given by other well wishers and friends during this work is recalled with gratitude. 10. Authors' Address Prabakaran T.S. FutureSoft, a Flextronics Company, 480-481, Anna salai, Nandanam, Chennai - 600 035, India Phone : +91-44-24330550 Email : prabakarts@future.futsoft.com Musthafa A.S. FutureSoft, a Flextronics Company, 480-481, Anna salai, Nandanam, Chennai - 600 035, India Phone : +91-44-24330550 Email : musthafaa@future.futsoft.com 11. 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. Prabakaran & Musthafa August 2005 [Page 13] INTERNET DRAFT Multicast Emulation over VPLS February 2005 12. Full copyright statement "Copyright (C) The Internet Society (2005). 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." "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." Prabakaran & Musthafa August 2005 [Page 14]