INTERNET DRAFT Ray Qiu Internet Engineering Task Force Alcatel draft-qiu-serbest-l2vpn-vpls-mcast-ldp- Yetik Serbest 01.txt SBC March 2006 Venu Hemige Category: Informational Suresh Boddapati Expires: September 2006 Alcatel Multicast State Distribution between VPLS PE routers Using LDP Status of this memo 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. IPR Disclosure Acknowledgement 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. Abstract In Virtual Private LAN Service (VPLS), as also in IEEE Bridged Networks, the switches simply flood multicast traffic on all ports in the LAN by default. Multicast Snooping can be used to avoid the unnecessary flooding as defined in [MAGMA-SNOOP] and [PIM-SNOOP]. When the number of Pseudo Wires (PWs) and refresh messages increases dramatically, it is desirable to reduce the messages exchanged between VPLS PE routers to improve scalability. This document describes the procedures and recommendations for using LDP for distributing Multicast state information between VPLS PE routers. 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. Introduction....................................................2 2. Snooping on ACs.................................................2 3. Forwarding PIM/IGMP messages in Data Plane......................3 4. LDP Multicast Capability........................................3 5. Distributing Multicast State Information........................3 5.1. Distributing PIM Neighbor State...............................4 5.2. Distributing PIM Join/Prune State.............................5 5.3. Distributing PIM-DM Graft and Graft Ack State.................7 5.4. Distributing IGMP/MLD State...................................7 6. Building Multicast State........................................9 7. Security Considerations.........................................9 8. IANA Considerations.............................................9 9. Normative References............................................9 10. Informative References........................................10 11. Acknowledgments...............................................10 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. Multicast traffic is treated as broadcast traffic and is flooded to every site in the VPLS instance. Multicast snooping can be used to avoid the unnecessary flooding of multicast traffic. The detailed procedures and recommendations are described in [MAGMA-SNOOP] and [PIM-SNOOP]. However, Multicast snooping for VPLS introduces some control plane overhead to the VPLS PE routers, especially when snooping is enabled on VPLS Pseudo Wires (PWs). It is desirable to reduce the overhead to improve network scalability by supporting Multicast state distribution between PE routers. LDP is a standard signaling protocol for VPLS [VPLS-LDP] and its stateful characteristics and TLV encoding make it the best choice for this purpose. 2. Snooping on ACs VPLS PE routers are required to snoop on ACs and run appropriate state machines to build their multicast state accordingly. Procedures and recommendations for snooping on ACs are defined in [MAGMA-SNOOP] and [PIM-SNOOP]. 3. Forwarding PIM/IGMP messages in Data Plane PIM/IGMP messages are forwarded in data plane based on their destination MAC addresses and VPLS PE routers snoop the packets, but SHOULD not alter the packets in any way. 4. LDP Multicast Capability A new optional parameter, the Multicast Capability TLV, is introduced to signal a PE router's support of Multicast state exchange, to its LDP peers. It is carried in the LDP Initialization message. 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| Multicast Capability (TBD)| Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|D|I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S bit PIM-SM bit. This bit indicates whether distributing PIM-SM, PIM-SSM and BIDIR-PIM state information via LDP is supported. D bit PIM-DM bit. This bit indicates whether distributing PIM-DM state information via LDP is supported. I bit IGMP/MLD bit. This bit indicates whether distributing IGMP/MLD state information via LDP is supported. Reserved bits MUST be set to zero on transmission and MUST be ignored on receipt. 5. Distributing Multicast State Information This section defines the necessary extensions to the LDP specification [RFC3036] for distributing Multicast state information in a VPLS. The Multicast state information needs to be signaled to remote VPLS PE routers because snooping on PWs is disabled. It can be done using an LDP Notification Message that contains a FEC TLV (to identify the VPLS instance) and a Multicast State TLV. A new status code is introduced for the Status TLV to indicate the existence of a Multicast State TLV in the message. The encoding for 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast State TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding for the Status code 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|0| Multicast State Encoded (Value: TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding for the Multicast State 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| Multicast State TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1. Distributing PIM Neighbor State A VPLS PE router that supports PIM snooping [PIM-SNOOP] snoops PIM hello message and builds its PIM Neighbors Database accordingly. When a Hello message from a PIM router attached to an AC is different than its previous Hello message, it MUST be communicated to all VPLS peers via an LDP Notification message. To add a PIM neighbor, an LDP Notification Message with PIM Hello Sub TLV is used; to remove a PIM neighbor, The same message is sent with hello hold-time set to zero. PIM Hello Sub TLV PIM Hello sub TLV is encoded in the Multicast State TLV Value field. The encoding for PIM Hello Sub 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIM Hello Sub TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // PIM Hello Sub TLV Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding for the PIM Hello Sub TLV Value 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIM Neighbor Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The OptionType, OptionLength, and OptionValue are the same as defined in [PIM-SM] section 4.9.2. 5.2. Distributing PIM Join/Prune State A VPLS PE router that supports PIM snooping [PIM-SNOOP] snoops PIM Join/Prune messages and builds its PIM state accordingly. When the first Join message is received for an (*,G,N)/(S,G,N), where N is the upstream-neighbor; or when the prune-pending-timer expires (which in turn triggers a Prune message) for an (*,G,N)/(S,G,N), the J/P message needs to be sent to the LDP neighbors in pim_iifs [PIM-SNOOP] for that (*,G)/(S,G) via LDP. The J/P message is not sent to all LDP peers, which further reduces control plane overhead. One exception is BIDIR- PIM [BIDIR-PIM], which requires the J/P message to be sent to all LDP peers within the VPLS domain. Periodic state refreshes are not sent to other PE routers via LDP. PIM J/P Sub TLV PIM J/P sub TLV is encoded in the Multicast State TLV Value field. The encoding for PIM J/P Sub 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIM J/P Sub TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // PIM J/P Sub TLV Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding for the PIM J/P Sub TLV Value 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Neighbor Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address m (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding is the same as defined in [PIM-SM] section 4.9.5. 5.3. Distributing PIM-DM Graft and Graft Ack State PIM-DM Graft and Graft Ack states are only sent to the LDP peer where the upstream neighbor is attached. The encoding for PIM Graft Sub 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIM Graft Sub TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // PIM Graft Sub TLV Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding for PIM Graft Sub TLV Value is the same as PIM J/P Sub TLV Value. The encoding for PIM Graft Ack Sub 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIM Graft Ack Sub TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // PIM Graft Ack Sub TLV Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding for PIM Graft Ack Sub TLV Value is the same as PIM J/P Sub TLV Value. 5.4. Distributing IGMP/MLD State IGMP/MLD states may also be exchanged using LDP. The encoding for IGMP/MLD Sub 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IGMP/MLD Sub TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num groups m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Joined Sources n | Num Pruned Sources p | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 2 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 2 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address p (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address m (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Joined Sources n | Num Pruned Sources p | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 2 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 2 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address p (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The definitions for Encoded-Group format and Encoded-Source format is defined in [PIM-SM] section 4.9.1. Just like in the PIM J/P Sub TLV, the Joined Source Addresses are encoded before the Pruned Source Addresses. The wildcard bit 'W' in the Encoded-Source field is used to encode a (*,G) state. The RPT bit 'R' in the Encoded-Source field when encoded in a Pruned Source Address indicates an excluded source. When encoding an IGMP/MLD Sub TLV at the downstream PE, - A (*,G) Join is encoded when local_include(*,G) becomes non- empty; - A (*,G) Prune is encoded when local_include(*,G) becomes empty; - An (S,G) Join is encoded when local_include(S,G) becomes non- empty - An (S,G) Prune is encoded when { local_include(S,G) (+) local_exclude(S,G) } becomes empty. - An (S,G) Exclude is encoded when local_exclude(S,G) becomes non-empty. The macros local_include(*,G), local_include(S,G) and local_exclude(S,G) are defined in [PIM-SNOOP]. 6. Building Multicast State The procedures and recommendations on how to build Multicast state upon receiving the Multicast State TLV are defined in [PIM-SNOOP]. 7. Security Considerations Security considerations provided in VPLS solution documents (i.e., [VPLS-LDP]) apply to this document as well. 8. IANA Considerations The type field in the Multicast Capability TLV, Multicast State TLV and the Multicast State Sub TLVs are yet to be defined and subject to IANA approval. 9. Normative References [RFC3036] Andersson, L., et al. "LDP Specification", RFC 3036, January 2001. 10. Informative References [MAGMA-SNOOP] Christensen, M., et al. "Considerations for IGMP and MLD Snooping Switches", work in progress. [PIM-SNOOP] Hemige, V., Serbest, Y., et al. "PIM Snooping for VPLS", work in progress. [VPLS-LDP] Lasserre, M., et al. "Virtual Private LAN Services over MPLS", work in progress. [PIM-SM] Fenner, B., et al. "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification (revised)", work in progress. [BIDIR-PIM] Handley, M., et al. "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", work in progress. 11. Acknowledgments The authors are grateful to the following for invaluable discussions: Vach Kompella, Sunil Khandekar, Alex Zinin, Rob Nath, Marc Lasserre, and Himanshu Shah. Authors' Addresses Ray Qiu Alcatel North America 701 East Middlefield Rd. Mountain View, CA 94043 Ray.Qiu@alcatel.com Yetik Serbest SBC Labs 9505 Arboretum Blvd. Austin, TX 78759 Yetik_Serbest@labs.sbc.com Venu Hemige Alcatel North America 701 East Middlefield Rd. Mountain View, CA 94043 Venu.hemige@alcatel.com Suresh Boddapati Alcatel North America 701 East Middlefield Rd. Mountain View, CA 94043 Suresh.boddapati@alcatel.com 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. Full 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. 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.