Supporting IP Multicast over
VPLS
draft-serbest-l2vpn-vpls-mcast-03.txt
Suresh Boddapati
Venu Hemige
Sunil Khandekar
Vach Kompella
Marc Lasserre
Rob Nath
Ray Qiu
Yetik Serbest
Himanshu Shah
• Problem Definition
– In VPLS, multicast traffic is flooded to all sites, with or without receivers.
• Objectives
– Do not multicast send traffic to sites without receivers
– Keep core P routers stateless (Multicast)
– Reduce BW waste
• Use ingress replication, but replicate only to the sites with receivers.
• Should be extensible to use other tunneling technologies
VPLS Multicast Procedures
• This draft addresses building of replication state on PEs for
IGMP and PIM only.
• PEs on the customer facing ports (Downstream PEs)
MUST perform IGMP/PIM snooping. There is no way
around this.
–
–
–
–
Procedures for IGMP snooping defined in draft-ietf-magma-snoop-12.txt
This draft defines the procedures for PIM snooping.
Snooping for various flavors of PIM are discussed in detail.
This draft also defines the rules when both IGMP and PIM are
active in a VPLS instance.
• PEs on Pseudo-Wire Ports (Upstream PEs) may learn
multicast state using one of
– IGMP/PIM Snooping just like it is done on ACs.
– Via LDP (added in this revision).
IGMP/PIM Snooping on PWs
• This requires no additional work. Work done for learning on ACs can
be leveraged.
• Should be good for low to medium scale VPLS deployments.
• Since IGMP/PIM are soft-state protocols, the amount of periodic
refreshes received on a PW is a function of
f(numVplsInstances, numPEs, numGroups, numReceivers).
• In large-scale VPLS deployments, this will not scale very well.
• Proxy procedures can be implemented to mitigate the problem to a
certain extent.
• But for a more robust solution, the WG recommended a reliable,
refresh-free solution to build multicast states on PWs.
Using LDP to learn multicast
membership on PWs
Why LDP?
• LDP is already being used in VPLS to setup PWs.
• LDP is a reliable protocol – so refreshes of multicast states are not
required.
• PIM Multicast States need only be built on the PE(s) connected to the
downstream C-Routers and the upstream C-Router.
• PIM C-Join/Prunes need only be sent to the one upstream PE
connected to the C-RPF-Neighbor - flooding is not required and is
wasteful.
Multicast State Learning via LDP
• PIM Hello TLV
– We define a new TLV to carry PIM C-Hellos that are snooped at the
downstream PE to all remote PEs.
– This TLV is sent in an LDP Address Message to all remote PEs.
– Learning about PIM C-Routers is necessary for
• the PEs to determine where the upstream C-Router exists.
• to determine if Join Suppression is active in a VPLS instance.
• PIM Join TLV
– We define a new TLV to carry PIM C-Join/Prune messages that are
snooped at the downstream PE to the upstream PE.
– This TLV is sent in an LDP Address Message to the upstream PE.
• PIM C-Packets must also be forwarded by the downstream PE (these
are intended for C-routers).
• PIM C-Join/Prune packets may need to be unicast-forwarded to the CRPF-Neighbor.
Special Considerations
•
Duplicate Traffic Scenarios
– There are several scenarios that can result in duplicate traffic.
– This draft defines how PEs should identify duplicate traffic and trigger
PIM-Assert among the C-Routers.
•
Why Unicast-Forward PIM C-Join/Prunes to the C-Upstream-Neighbor?
– For VPLS Multicast to work, PIM Join Suppression MUST be disabled on
all C-Routers.
– Several of the existing PIM implementations do not support this ability to
disable PIM Join Suppression.
– Whether C-Routers have this capability is out of the provider’s control.
– If a PE determines that PIM Join Suppression is “active” in a VPLS, then it
SHOULD unicast-forward the C-Join/Prunes to prevent Join Suppression.
•
PIM-BIDIR
– In this case, traffic may arrive on any interface, not just from the RPF.
– So PIM C-Join/Prunes need to be sent to all PEs via LDP.
– Forwarding State is built on all PEs.
Next Steps
• Comments please.