Network Working Group Simon Delord Internet Draft Raymond Key Category: Standard Track Expires: September 2010 Frederic Jounay France Telecom March 01, 2010 Extension to LDP-VPLS for Ethernet broadcast and multicast draft-delord-l2vpn-ldp-vpls-broadcast-exten-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 01, 2010. Delord et al. Expires September 2010 [Page 1] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 Abstract This document proposes a simple extension to LDP-VPLS to optimise Ethernet Multicast/Broadcast traffic within a carrier's network. It allows the use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. 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 [RFC2119]. Table of Contents 1. Introduction....................................................3 2. Terminology.....................................................3 3. Problem Definition..............................................4 3.1 Ethernet broadcast/multicast handling in a VPLS domain.........4 3.2 Problem Statement..............................................4 4 Prerequisites....................................................5 4.1 P2MP PW & P2MP LSPs............................................5 4.2 P2MP PW to VPLS Instance Mapping...............................5 5. Proposed extensions to VPLS for Ethernet broadcast/multicast....6 5.1 Flooding/Forwarding & Address Learning.........................8 5.1.1 Flooding/Forwarding..........................................8 5.1.2 Address Learning.............................................8 5.2 Hierarchical VPLS..............................................8 6. Security Considerations.........................................9 7. IANA Considerations.............................................9 8. Acknowledgements................................................9 9. References......................................................9 9.1. Normative References..........................................9 9.2. Informative References........................................9 Authors' Addresses................................................10 Intellectual Property and Copyright Statements....................10 Delord et al. Expires September 2010 [Page 2] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 1. Introduction This document proposes a simple extension to LDP-VPLS [RFC4762] to optimise Ethernet Multicast/Broadcast traffic within a carrier's network. It allows the use of unidirectional point-to-multipoint PseudoWires (P2MP PWs) to minimise payload frame duplication on physical links. VPLS is a L2VPN service that provides multipoint-to-multipoint connectivity for Ethernet across an IP or MPLS-enabled IP Packet Switched Network. VPLS emulates the Ethernet VLAN functionality of traditional Ethernet network. [RFC5501] provides an in-depth discussion on broadcast/multicast related requirements for VPLS, including Ethernet broadcast and multicast associated challenges. A comprehensive solution to address the challenges of [RFC5501] has been proposed in [VPLS-Multicast-BGP]. However, one of the requirements of [VPLS-Multicast-BGP] is for LDP-VPLS deployments to use BGP as an auto-discovery mechanism to setup P-multicast trees. Extract from [VPLS-Multicast-BGP] section 7: An LDP-VPLS implementation that supports P-Multicast trees described in this document, MUST support the BGP A-D procedures to setup P-Multicast trees and it MAY support FEC 129 to automate the signaling of PWs. The solution proposed in this document differs from [VPLS-Multicast- BGP] as it addresses [RFC5501] issue B only (replication of PWs on shared physical path) and does not require the addition of BGP for the LDP-VPLS implementation. 2. Terminology This document uses terminology described in [RFC4762] and [P2MP-PW-REQ]. Delord et al. Expires September 2010 [Page 3] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 3. Problem Definition 3.1 Ethernet broadcast/multicast handling in a VPLS domain [RFC4762] use MAC-based forwarding as a data forwarding mechanism between VSIs. An Ethernet broadcast/multicast frame is forwarded to all ACs other than the ingress AC. This implies point-to-multipoint traffic from the ingress PE to all other PEs in the VPLS instance. It is important to note that [RFC4762] treats an Ethernet multicast frame in exactly the same way as an Ethernet broadcast frame and does not restrict the transmission of an Ethernet multicast frame to a smaller set of receivers. An Ethernet host receiving a frame checks the destination address in the frame to determine whether it is the intended destination. 3.2 Problem Statement of Ethernet broadcast/multicast replication within a VPLS domain [RFC4762] uses only point-to-point PWs between PEs. When the Ethernet destination address is broadcast or multicast the ingress PE replicates the frame on every PW towards remote PE belonging to the same VPLS instance. Depending on the mapping between the logical topology of the VPLS and the physical topology of the network, multiple PWs may transverse same physical link, resulting in multiple copies of the same payload Ethernet frame on the physical link. Such approach is inefficient in terms of bandwidth usage. [RFC5501] provides an in-depth discussion on broadcast/multicast related requirements for VPLS. It highlights two specific issues: - Issue A: replication to non-member site. - Issue B: replication of PWs on shared physical path. The aim of this document is to address issue B for Ethernet multicast/broadcast traffic only in the context of [RFC4762]. Delord et al. Expires September 2010 [Page 4] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 4. Prerequisites The proposed solution relies on mechanisms described in [RFC4762] and requires the following elements. 4.1. P2MP PW & P2MP LSPs This document assumes that mechanisms to setup and operate P2MP PWs and P2MP LSPs are available on at least some of the network elements of the VPLS domain considered. P2MP PWs can be statically or dynamically configured as long as they meet the following criteria: - Each Root PE MUST be able to select a set of Leaf PEs belonging to the same VPLS instance to connect them via a P2MP PW. The selection of the egress PEs can be done manually (as per section 5 of [RFC4762]). - A PE MAY be Root for one or more P2MP PWs attached to a specific VPLS instance. - The P2MP PWs are unidirectional only. An example of a dynamic approach that meets the above requirements is described in [P2MP-PW-LDP]. 4.2. P2MP PW to VPLS Instance Mapping The proposed solution requires that each P2MP PW be mapped to the same VPLS instance on all PEs (Root or Leaf) that belong to this P2MP PW. The P2MP PW to VPLS instance mapping can be done manually or dynamically. An example of dynamic mapping is described in [P2MP-PW-LDP]. The proposed solution allows for a Root PE to map more than one P2MP PW to a specific VPLS instance. However in this case, the Root PE MUST NOT associate a leaf PE to more than one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE to receive duplicate copies of the same Ethernet frame from different P2MP PWs). Delord et al. Expires September 2010 [Page 5] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 5. Proposed extensions to VPLS for Ethernet broadcast/multicast This section proposes extensions to VPLS for Ethernet broadcast and multicast frames only. Figure 1 shows a topological model of a VPLS between four PEs with an arbitrary set of ACs attached to each VSI. +---------+ +---------+ | PE1 | | PE2 | | +---+ | | +---+ | | | | | | | +-------AC4--- | | V | | | | V | | | | | | | | | | ----AC1----+--+ | | Ethernet | | +--+----AC5--- | | S +--+-----PW-----+--+ S | | | | | | | | | | ----AC2----+--+ | | | | | | | | I | | | | I | | | | | | Ethernet | | | | ----AC3----+--+ | | PW +-----+--+ | | | +-+-+ | / | +-+-+ | | | \ | / | | | +----+---\+ / +----+----+ | \ / | Ethernet| \/ |Ethernet PW| /\ |PW | / \Ethernet | +----+---/+ \PW +----+----+ |PE3 | / | \ |PE4 | | | +---+ | \ | +---+ | ----AC6----+--+ | | \ | | +--+----AC8---- | | V | | +----+--+ V | | | | | | | | | | ----AC7----+--+ | | Ethernet | | +--+----AC9---- | | S +--+-----PW-----+--+ S | | | | | | | | | | | | | | | | | | | I | | | | I | | | | | | | | | | | | | | | | | | | +-+-+ | | +-+-+ | | | | | +---------+ +---------+ Figure 1 Reference Diagram for VPLS Delord et al. Expires September 2010 [Page 6] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 Figure 2 shows the proposed extensions to VPLS for Ethernet broadcast and multicast. On top of the topology presented in Figure 1, two P2MP PWs have been added to the existing set of P2P PWs. +---------+ +---------+ | PE1 | | PE2 | | +---+ | | +---+ | | | | | | | +-------AC4--- | | V | | Ethernet | | V | | | | | | P2MP | | | | ----AC1----+--+ | | PW1 | | +--+----AC5--- | | S +--+->--+-->----+--+ S | | | | | | | | | | | ----AC2----+--+ | | | | | | | | | I | | | +->-+--+ I | | | | | | | | | | | | ----AC3----+--+ | | | | | | | | | +---+ | | | | +---+ | | | | | | | +---------+ | | +---------+ | | | | | | | | +---------+ | | +---------+ |PE3 | | | |PE4 | | +---+ | | | | +---+ | ----AC6----+--+ | | +->-----+--+ +--+----AC8---- | | V | | | | | | | | | | | | | | | | ----AC7----+--+ | | | | | +--+----AC9---- | | S +--+->------+->-+--+ S | | | | | | Ethernet | | | | | | | P2MP | | | | | | I | | PW2 | | I | | | | | | | | | | | | | | | | | | | +-+-+ | | +-+-+ | | | | | +---------+ +---------+ Figure 2: Proposed Extensions to VPLS for Ethernet broadcast/multicast P2MP PW1 is composed of PE1 as the root PE and PE2 and PE4 as leaf PEs. P2MP PW2 is composed of PE3 as the root PE and PE2 and PE4 as leaf PEs. Delord et al. Expires September 2010 [Page 7] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 Note that for sake of clarity, Figure 2 does not show the full-mesh of P2P PWs presented in Figure 1. Also note that the solution does not dictate that P2MP PWs be used on all PEs in the VPLS, for example there is only a P2P PW between PE1 and PE3 and a P2P PW between PE2 and PE4. 5.1. Flooding/Forwarding & Address Learning for Broadcast & Multicast Ethernet Frames This document defines new rules for the flooding/forwarding of Ethernet broadcast/multicast frames on the Root PE and the associated learning rules on the Leaf PEs. 5.1.1. Flooding/Forwarding For a Broadcast or Multicast Ethernet frame arriving on a specific VPLS instance on a PE, the forwarding actions are the following: - If there is a P2MP PW towards a remote PE belonging to the same VPLS instance, the P2MP PW associated to this remote PE is used to forward the Ethernet frame. - If there is no P2MP PW towards a remote PE belonging to the same VPLS instance, the P2P PW associated to this remote PE is used to forward the Ethernet frame. 5.1.2. Address Learning The Leaf PEs MUST support the ability to perform MAC address learning for packets received on a P2MP PW. When a Leaf PE receives an Ethernet frame on a P2MP PW it: - First determines the Root PE of the P2MP PW - Then determines the P2P PW associated with that Root PE - Finally, creates a forwarding state in the VPLS instance for the P2P PW associated with the Root PE with a destination MAC address being the same as the source MAC address being learned. 5.2. Hierarchical VPLS H-VPLS considerations will be added in a later revision of this draft. Delord et al. Expires September 2010 [Page 8] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 6. Security Considerations This section will be added in a future version. 7. IANA Considerations There are no specific IANA considerations in this document. 8. Acknowledgments This section will be added in a future version. 9. References 9.1. Normative References [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, January 2007 [RFC5501] Kamite, et al., Requirements for Multicast Support in Virtual Private LAN Services, March 2009 [VPLS-Multicast-BGP] Raggarwa, Kamite & Fang, "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-05.txt, Work in Progress, July 2009 [P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point to Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-02.txt, Work in Progress, January 2010. [P2MP-PW-LDP] L. Martini, F. Jounay, et. al, "Signaling Root- Initiated Point-to-Multipoint Pseudowires using LDP", draft-martini-pwe3-p2mp-pw-01.txt, work in Progress, October 2009. 9.2. Informative References Delord et al. Expires September 2010 [Page 9] Internet Draft Ext to LDP-VPLS for broadcast multicast March 2010 Author's Addresses Simon Delord Australia Email: simon.delord@gmail.com Raymond Key Australia Email: raymond.key@ieee.org Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: frederic.jounay@orange-ftgroup.com Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Delord et al. Expires September 2010 [Page 10]