Multicast over VPLS

21 November 2005
Chris Liljenstolpe, CTO IP Division, APAC
<chris.liljenstolpe@alacatel.com>
All rights reserved © 2005, Alcatel

VPLS Physical Network Considerations
Page 2Inter-Office Fiber
VPLS PE

VPLS PE
VPLS PE
VPLS PE
VPLS PE

VPLS PEIP

IPIP Edge

IP Edge
VPLS PE

VPLS PE

VideoVideo
Physical Hub and Spoke

Physical Ring

¾ VPLS is flexible for both Mesh and Ring topology
 Meshy can avoid spanning tree and use 802.3ad for redundancyy but more fiber use

 Ringy H-VPLS provides sub-50ms restoration and bandwidth efficiency with better fiber efficiency

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, AlcatelBandwidth Efficiency for Multicast on VPLS RingPage 3

H-VPLS

Meshed VPLS

IPIP
IP Edge
VPLS PE

VPLS PE

IP Edge
VPLS PE

VPLS PE

IP Edge
VPLS PE

VPLS PE

IP Edge
VPLS PE

VPLS PE

VPLS benefits in ring topology  No spanning tree
 Sub-50ms recovery with MPLS Fast-reroutefor Multicast: Bandwidth efficiency for broadcast TV service withH-VPLS

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

Daisy chained H-VPLS for Multicast
Page 4MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

Broadcast TV based on H-VPLS Ring:
Redundancy
Page 5PIM

IGMPQuerierIPPIM¾ H-VPLS Ring provides full
redundancy¾ In case of inter-7450 link failure
recovery is via MPLS fastreroute Sub 50ms recovery

IP Edge IP Edge

VPLS PE

VPLS PE
Fast-rerouterestoration

VPLS PE
VPLS PE

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

Broadcast TV based on H-VPLS Ring:
Redundancy
Page 6¾ H-VPLS Ring provides fullredundancy

PIM

IGMPQuerier¾ In case of inter-7450 link failure
recovery is via MPLS fastreroute

IPPIM
IGMPQuerier

IP Edge IP Edge
VPLS PE

VPLS PE

 Sub 50ms recovery¾ In case of link failure to 7750,
IGMP election process willcause 7750 2 to take overmulticast
2- 3s recovery (IGMP timers)

VPLS PE
VPLS PE

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

Broadcast TV based on H-VPLS Ring:
Redundancy
Page 7¾ H-VPLS Ring provides full
redundancy

PIM

IGMPQuerier¾ In case of inter-7450 link failure
recovery is via MPLS fastreroute

IPPIM
IGMPQuerier

IP Edge IP Edge
VPLS PE

VPLS PE Sub 50ms recovery¾ In case of link failure to 7750,
IGMP election process willcause 7750 2 to take overmulticast
2- 3s recovery (IGMP timers)

VPLS PE
VPLS PE¾ In case of 7450 node failure,
the ring is broken and both
multicast routers become
active2- 3s recovery

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, AlcatelNew development inMPLS Multicast

All rights reserved © 2005, Alcatel

What do we mean by MPLS Multicast?
Page 9Do we mean “don’t send traffic to uninterested listeners?”

orDo we mean “optimize network bandwidth utilization in thecore?”

These two, while related, are distinct problem spaces.

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

The un-interested listener problem
Page 10What we are attempting to solve
 Primary goal - prevent un-interested listeners from getting traffic

from multicast groups that they have not registered for.
 Secondary goal - be as bandwidth optimal as possible, withoutchanging the underlying MPLS mechanisms

What we can’t solve
 Given point two, above, we can’t be bandwidth optimal BETWEENLSPs.

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

The un-interested listener problem (continued)
Page 11

To date, almost all customer traffic ingressing/egressing
an MPLS network is related to a VPN or the publicInternet.
As public Internet traffic in each LSP is routed at layer
three at each LSP end-point, classical IP Multicast
capabilities will address this first problem type (LSPs arebehaving as simple “wires”).
VPN traffic (either L2 or L3) may be switched at the LSPlevel (in most cases, actually), the Multicast information
may not be visible on the “surface” of the packet inquestion

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

The un-interested listener problem (VPN)
Page 12

As the Multicast data may not be exposed on the surfaceof the packet at the LSP end-point, the LER must snoop
for Multicast data to implement the solution to the uninterested listener problem.
The snooping targets must include IGMP, and PIM-*, at aminimum.
The proposed L2 and L3 Multicast snooping statemachines are similar in the IETF standards work.
The snooping device must then decide, based on
snooped state, as to Multicast tree maintenance to insurethat the interested listener can receive the intended
Multicast data, and the un-interested is not burdened with
“un-interesting” groups.
MPLS Japan / 21 Nov 2005

All rights reserved © 2005, AlcatelBandwidth Optimization
Page 13

While, in the previous discussion, the maintenance of aMulticast tree within an end-to-end VPN service will
somewhat optimize bandwidth (especially at the edges of
the network or within a specific LSP), it will do nothing tooptimize Multicast bandwidth between LSPs
Assume three nodes, S, L and L’. S is a multicast source;
while L and L’ are multicast listeners. SL is an LSP thatlinks S to L, and SL’ is the LSP that links S to L’. Both SL
and SL’ share the same physical link circuit, C., and S-L’is another LSP, but both traverse over the same physicalcircuit C.

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, AlcatelBandwidth Optimization (con’t)
Page 14If we use the previous mechanisms to address themulticast requirement, then SL and SL’ would besomewhat optimized for bandwidth utilization, SL and SL’
would each cary one packet for each packet originated by
S on the two LSPs.
To address this, LSPs need to have the flexibility tooperate as p-to-mp or mp-to-mp links.
Two basic architectures have been proposed in the IETF
for *p-to-mp LSPs.
 RSVP-TE signaled p-to-mp LSPs
 LDP signaled p-to-mp LSPs

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

RSVP-TE signalled p-to-mp LSPs (trafficengineered)Page 15

Positives
 High levels of control available

Negatives Need a-priory knowledge of listeners
 Need to know topology of the network

Non +/ Sender initiated

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

LDP signaled p-to-mp LSPs (Routed)
Page 16

Positive No apriory listener knowledge needed No need to know topology

Negatives No RSVP/traffic engineering treatment

Non +/ Receiver initiated

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, AlcatelRouted p-to-mp LSPs
Page 17A complete LDP signaling solution (draft minei)
No need to run another protocol
 Need to update LDP to carry Multicast information in TLVs.
A hybrid PIM-SSM and LDP signalling solution (draftboddapati)
PIM-SSM required No need to update LDP
 Use PIM to calculate the tree and signal Multicast memberships
 Use LDP to distribute labels

Most work is on (S,G) Multicast. (*,G) Multicast would be implemented, inmost cases, as n(S,G) where n is the number of senders in the network.

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

More Carrier Input Needed
Page 18

Is the listener or bandwidth problem more important?
If solving the bandwidth problem, is TE or routed p-to-mp
setup more interesting?
Is PIM acceptable in the MPLS core?

MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel

Page 19www.alcatel.com
MPLS Japan / 21 Nov 2005

All rights reserved © 2005, Alcatel