1. 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji Kamite (NTT Communications) Frederic Jounay (France Telecom) Ben Niven-Jenkins (BT)

2. 72nd IETF Dublin July 2008 Introduction What is VPMS? –VPMS is defined as a Layer 2 service that provides point-to- multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. –Difference from other L2VPNs VPWS supports point-to-point only; no replication VPLS supports replication but requires full-mesh and MAC forwarding (VSI) WG Re-chartering –L2VPN WG Re-chartering proposal to take VPMS –PWE3 WG Re-chartered to take P2MP-PW (potential solution) This draft’s objective –Introduce service framework and become a base reference –Specify functional requirements to guide a proper solution

3. 72nd IETF Dublin July 2008 Use Cases Ethernet Use Case (Section 4.1) –IP-based TV broadcasting –Audio/video device with Ether interface (MPEG-TS, HD-SDI) –MPEG-TS/IP/Ethernet in DVB-H with static multicast ATM-based Use Case (Section 4.2) –IP multicast wholesale –p2mp PVPs/PVCs TDM-base Use Case (Section 4.3) –Mobile backhauling -- deliver the clock (CESoPSN, SAToP, TDMoIP)

4. 72nd IETF Dublin July 2008 Reference Model A “VPMS instance” corresponds to a unique unidirectional P2MP topology AC is configured as "sender" or "receiver" not both. CE: Customer Edge PE: Provider Edge AC: Attachment Circuit Routed Backbone CE1 CE4 CE2 CE3 CE5CE6 AC1 AC4 AC2 AC3 AC5 AC6 Sender Receiver VPMS A VPMS B VPMS A PE3 PE1PE2

5. 72nd IETF Dublin July 2008 Requirements Summary Customer Requirements (Section.2) –Service Topology –Transparency –QoS –Protection and Restoration etc. Provider Requirements (Section.3 ) –Scalability –PW signaling / PSN tunneling (Details will be covered by P2MP-PW Reqts work) –Auto-Discovery –Activation and Deactivation –Inter-AS etc.

6. 72nd IETF Dublin July 2008 Multiple Source Support VPMS PE1 VPMS PE2 CE1CE2 CE5 AC1 AC2 AC3 AC4 CE4 VPMS PE3 VPMS PE4 MUST support multiple sender topologies in one VPMS instance Each P2MP topology MUST only have a single sender, however multiple P2MP topologies can be grouped together into a single VPMS instance. (For protection and restoration at sender-side) VPMS A Sender Receiver Sender Receiver

7. 72nd IETF Dublin July 2008 Reverse Traffic Support Every AC is considered unidirectional Direction is an additional element to identify a unique AC –L2 header/circuit (e.g., VLAN id, Physical port ) plus traffic direction (Tx or Rx ) CE2 CE1 CE3 CE5 AC1 PE2 AC2 AC5 Receiver VPMS A PE4 PE1 Tx Rx AC6 PE3 VPMS B AC3 AC4 TxRx Sender VPMS A VPMS B Receiver VPMS A Sender VPMS A VPMS B Receiver Unique instance per direction

8. 72nd IETF Dublin July 2008 Auto-discovery Discovering VPMS Related Information –SHOULD support auto-discovery methods to minimize the amount of configuration the SP must perform – Information Example PE router ID / IP address as location information Information to identify ACs and their VPMS instance CE role in each VPMS (Sender and/or Receiver)

9. 72nd IETF Dublin July 2008 Activation / Deactivation SHOULD provide a way to activate/deactivate the administrative status of each CE/AC. SHOULD allow single-sided activation operation at a sender PE (for centralized control) CE2 CE1 CE3 CE5 AC1 PE2 AC5 Receiver (activated) VPMS A PE4 PE1 PE3 AC2 AC3 Sender VPMS A NO VPMS provisioned VPMS A Single-sided activation on each AC at source PE CE4 AC4 Receiver (deactivated and not receiving data) VPMS A Receiver (activated) deactivated

10. 72nd IETF Dublin July 2008 Next Step Remaining major work –OAM –Security This draft is being well coordinated with P2MP Reqts work (draft-jounay-pwe3-p2mp-pw- requirements) that is proposed in PWE3 Propose to adopt this as a WG document - to have consensus on this basic framework