Brkipm-2011 - Multicast Mpls

Multicast MPLS
BRKIPM-2011
Luc De Ghein
Agenda
 Introduction
 LSP types
 Tree building compared
 Tree types compared
 Aggregation
 Assigning flows to LSPs
 Applications of Label Switched Multicast
– In-band signaling
– mVPN
– VPLS
BRKIPM-2011 © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Introduction
Multicast Solutions
 Finance (Trading, Market Data, Financial SP)
– Tibco, Hoot-n-Holler, Data Systems
 Enterprise Video and collaborative environments
– Cisco TelePresence®, DMS, MP/WebEx
Video Conferencing, Video Surveillance
 Broadband (Entertainment)
– Includes Cable, DSL, ETTH, LRE, Wireless
– Broadcast TV / IP/TV, VOD, Connected Home
 Service Provider (Transit Services)
– Multicast VPNs (IP and MPLS-based)
– Label Switched Multicast (LSM)
Multicast for IP/TV Delivery
Distribute Information to Large Audiences over an IP Network
Multicast
Unicast
Network Traffic
8
6
4
2
0
1 20 40 60 80 100
# Clients
Multicast
1. Efficiently controls network traffic Multicast Benefits
2. Reduces server and CPU loads  Increase Productivity and Save Cost
3. Eliminates traffic redundancy  Generate New Revenue Stream
4. Makes multipoint applications possible
What is Label Switched Multicast ?
 IP multicast packets are transported using MPLS encapsulation
 MPLS encoding for LSM documented in RFC 5332
 Unicast and multicast share the same label space
 MPLS protocols RSVP-TE and LDP are modified to support P2MP and MP2MP
LSPs
Why Label Switched Multicast ?
 Shared control plane with unicast
– Less protocols to manage in the core
 Shared forwarding plane with unicast
– Only MPLS as encapsulation
 Apply unicast MPLS features to Multicast
– Fast ReRoute (FRR)
– Bandwidth reservation
Protocols for Building Multicast LSPs
 Multipoint LDP (mLDP)
– Extensions to LDP
– Support both P2MP and MP2MP LSP
– RFC 6388
 RSVP-TE P2MP
– Extensions to unicast RSVP-TE
– RFC 4875
Protocols for Assigning Flows to LSPs
 BGP
– RFC 6514
– Also describes Auto-Discovery
 PIM
– RFC 6513
 mLDP In-band signaling
– RFC 6826
 Static
LSM Solution Space
IPv4 IPv6 IPv4 IPv6
Native
Native
VPLS
mVPN
mVPN
Service
C-Multicast Signaling (PE) PIM BGP None
Core Tree Signaling PIM MLDP P2MP TE
Encapsulation/Forwarding IP/GRE LSM
LSP Types
LSP types
 Point to Point (P2P) & (Multi-Point to Point)

– Well known for unicast
 Point to Multi-Point (P2MP)
– Supported by MLDP and RSVP-TE
 Multi-Point to Multi-Point (MP2MP)
– Supported by MLDP not by RSVP-TE
 Point to Point to Multi-point (PPMP)
– Supported by MLDP and RSVP-TE
Unicast MPLS Forwarding Paradigms
Multipoint to Point Point to Point
IP/MPLS IP/MPLS
MP2P LSP P2P LSP
 Aggregates traffic
 Signaled with LDP (generally)  Signaled with RSVP-TE
 Signaled with BGP (occasionally)  Constraint-based/explicit routing
 Path based on IP routing  Admission control
Multicast MPLS Forwarding Paradigms
Point to Multipoint Multipoint to Multipoint
IP/MPLS IP/MPLS
PM2P LSP MP2MP LSP
 Replication of traffic in core

 Allows only the root of the P2MP LSP to inject
packets into the tree  Replication of traffic in core
 Signaled with MLDP  Bidirectional
Path based on IP routing  All the leafs of the LSP can inject and receive
 Signaled with RSVP-TE packets from the LSP
Constraint-based / explicit routing  Signaled with multicast LDP (mLDP)
Admission control  Path based on IP routing
Multicast MPLS Forwarding Paradigms
Point – Point to Multipoint
IP/MPLS
P2P LSP
P2MP LSP
 Combination of P2P and P2MP

 P2P from leaf to the root
 P2MP from root to the leafs
 Signaled with mLDP or RSVP-TE
 P2P to root used for control packets
 P2MP used for data & control
LSP Types and Forwarding
P2MP tree packet replication and forwarding
P#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface 23
20 23 [ipv4 10.100.1.6 232.1.1.1] \ 20

0 Et1/0 10.1.1.1
18 [ipv4 10.100.1.6 232.1.1.1] \
0 Et3/0 10.1.3.3
18
MP2MP tree
P#show mpls forwarding-table 21
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface 19
23
19 21 [mdt 1000:2000 0] \
19 [mdt 1000:2000 0]
33516
912
\
Et2/0
Et1/0
10.1.2.2
10.1.1.1
} 24
20
20 24
21
[mdt 1000:2000 0]
[mdt 1000:2000 0]
1932
1932
\
\
Et3/0
Et2/0
10.1.3.3
10.1.2.2
} 19
MP2MP LSP is combination

23 24
19
[mdt 1000:2000 0]
[mdt 1000:2000 0]
912
\
33940
\
Et3/0
Et1/0
10.1.3.3
10.1.1.1
} of P2MP LSPs
Tree Types
Official Tree Names
Multi-directional Inclusive PMSI Selective PMSI Multidirectional Selective PMSI
MI-PMSI S-PMSI MS-PMSI
(default-MDT) (data-MDT) (Partitioned-MDT)
S-PMSI MS-PMSI
MI-PMSI
PE PE
PE PE PE
PE
P PE
P
PE PE PE PE PE
PE
Combination E-
Like E-LAN
Like NBMA LAN and NBMA
Full mesh P2MP or
one MP2MP A single MP2MP
Good when sources A single P2MP Good when sources
are in every site in few sites
PMSI = Provider Multicast Service Interface

LSP Types
Summary
 3 types of LSPs
 P2MP
– One 2 Many
 MP2MP
– Many 2 Many
 PPMP
– One 2 Many for data traffic
– Many 2 Many for control traffic
Tree Building Compared
MLDP Overview
 LSPs are build from the leaf to the root
 Supports P2MP and MP2MP LSPs
 Supports Fast Reroute (FRR) via RSVP TE unicast backup path
 No periodic signaling, reliable using TCP
 Control plane is P2MP or MP2MP
 Data plane is P2MP
mLDP FEC and Opaque Values
 Multicast FEC is advertised by mLDP
 Root node address and opaque value identify the P2MP or MP2MP tree
 Root node address is
– learned dynamically (BGP next hop address), for P2MP trees
– configured, for MP2MP trees
 Value is used to carry multicast stream information, like
– (S,G) : in-band signalling
– LSP identifier : Default/Data MDT
– …
 The opaque value has meaning to root and leaves
– Root and leaves are edge devices
– Opaque value is mapped to PIM state on the edge devices
 Opaque value is completely transparent to intermediate nodes (P routers)
mLDP P2MP LSP
Signalling
Label Receiver
Mapping CE
Leaf
Receiver
CE
Leaf
Ingress
Source
Router
(Root)
Receiver
Leaf CE
 The egress (leafs) receives a PIM Join

 The leaf sends a mLDP label mapping to the Root (via the core)
 The ingress PE received one update due to receiver driven logic
mLDP P2MP LSP
State
Receiver
Leaf CE
Receiver
Leaf CE
Ingress
Source Router
(Root)
Receiver
Leaf CE
 Control Plane: 1 P2MP LSP

 Forwarding Plane: 1 P2MP LSP replication
 When a leaf wants to leave, msg is only sent to the next branch point,
not all the way to ingress PE
mLDP MP2MP LSP
Signalling
Label Mapping Sender/Receiver

TO root Leaf CE
Sender/Receiver
Sender/Receiver
Leaf CE
Ingress
Router
(Root) Sender/Receiver
Label Mapping
FROM root Leaf CE
 The leaf sends a mLDP label mapping to the Root, just like P2MP
 On each link, a label mapping is sent in the reverse direction (away from the
root), creating a bidirectional MP2MP LSP
mLDP MP2MP
State
Receiver
Leaf CE
Receiver
Sender/Receiver CE
Leaf
Ingress
Router
(Root)
Receiver
Leaf CE
 Control Plane: 1 MP2MP LSP

 Forwarding Plane: 4 P2MP LSP
 Control plane state is converted to a set of P2MP replications in forwarding
RSVP-TE Overview
 LSPs are build from the head-end to the tail-end

 Supports only P2MP LSPs
 Supports traffic engineering
– Bandwidth reservation
– Explicit routing
– Fast ReRoute
 Signaling is periodic
 P2P technology at control plane
– Inherits P2P scaling limitations
 P2MP at the data plane
RSVP-TE P2MP
Signalling
BGP Auto Discovery leaf updates

or static configuration Receiver
Leaf CE
Receiver
CE
Leaf
Ingress
Source Router
(Root)
Resv Path Receiver
Leaf CE
 The Leafs sends a BGP Auto Discovery message to notify the ingress PE
 The ingress sends RSVP-TE Path messages to the leaves
 The leaves respond with RSVP-TE Resv messages
RSVP-TE P2MP
State
Receiver
Leaf CE
Receiver
Leaf CE
Ingress
Source Router
(Root)
Receiver
CE
Leaf
 Control Plane: 3 P2P sub-LSPs from the Root to the Leaves

 Data Plane: The 3 P2P sub-LSP are merged into 1 P2MP for replication
 When a leaf want to leave, the control message is sent all the way to
ingress PE to remove the LSP
LSM Signalling
Compared side-by-side
RSVP-TE mLDP
The egress (leaf) receives a PIM Join

The egress (leaf) receives a PIM Join
The Leafs sends a BGP A-D leaf to notify the ingress PE The leaf sends a mLDP label mapping to the ingress PE
The ingress sends RSVP-TE Path messages to the leaves
The leaves respond with RSVP-TE Resv messages
The core router received 6 updates The core router received 3 update messages
Control Plane Scale Comparison
 Similarities
– Both are based on existing MPLS technology (LDP or RSVP TE)
– Both require changes to support Multicast
– Both support FRR
 Differences
– RSVP-TE
 Support bandwidth reservation
 No MP2MP support
 Periodic refresh of states
– mLDP
 Support MP2MP LSPs
 TCP based protocol - no periodic refresh of states
 Less signaling and state to support an LSP, more scalable
Control Plane Scale Comparison
 Scenario: A single P2MP LSP with 100 receivers (single core router)
 Comparison for state (sub-LSPs) and Control Plane updates on the PE and P
router
396
400
350
300
250
198
200
150
99 100 99 mLDP
100
50 RSVP-TE
1 1 1
0
P-state P-updates PE-state PE-
updates
Tree Building Compared
Summary
 mLDP
– Scalable due to receiver driven tree building
– Supports MP2MP
– Does not support traffic engineering
 RSVP-TE
– Supports traffic engineering (bandwidth reservation etc.)
– Does not support MP2MP
– Less scalable due to head-end signaling (P2P)
 Each protocol has its pro and cons
– Its up to the application/service requirement
Tree Types Compared
Tree Types Compared
P2MP vs. MP2MP
 mLDP with MP2MP provides great scalability advantages for “any to any”
topologies
 “any to any” communication applications:
– mVPN supporting Bidirectional PIM
– mVPN Rosen model default MDT
– If a provider does not want tree state per ingress PE source
– VPLS unknown unicast/broadcast
Tree Types Compared
When to use a PPMP
 PPMP is an emulated MP2MP LSP

 Control plane is MP2MP, data plane is P2MP
 Does not work with PIM bidir
 Allows PIM to be run over P2MP LSPs, as with RSVP-TE that does not support
MP2MP
 Core routers don’t support MP2MP (dual vendor issues)
Tree Types Compared
MVPN full P2MP Mesh vs MP2MP
 Single VPN with 1000 PEs

 Sender/Receiver in every site
 3 ways to build the core tree:
1. Full-mesh P2MP TE Tree
2. Full-mesh P2MP MLDP Tree
3. One MP2MP MLDP Tree
Tree Types Compared
State Comparison
 Full-mesh P2MP TE Core Tree produce orders of magnitude more states (sub-LSP) on
the P router than the MP2MP tree
1000000
100000
(log scale)
Core State
10000
1000
100
10
1
P2MP TE 10 100 1000
P2MP mLDP Number of PE's
MP2MP
Tree Types compared
Protocol Updates Comparison
 With 1,000 PEs, full-mesh P2MP TE Core Tree produces order of magnitude more
protocol updates on the P router than the MP2MP tree
1000000
Protocol Updates
100000
(log scale)
10000
1000
100
10
1
P2MP TE 10 100 1000
P2MP mLDP Number of PE's
MP2MP
Tree Types compared
Summary
 Any-2-any is best supported over a MP2MP LSP

 A full mesh of P2MP is costly
– Also requires upstream assigned labels for DF election (PIM BiDir)
 If MP2MP is not available, PPMP may be used
– Mostly needed for control plane MP2MP, like PIM
Aggregation
Aggregation
 Conflicting goals High state No flooding
 Scale improvement
– Minimize the number of LSPs by re-using LSPs to
transport multiple multicast flows (aggregation)
 Bandwidth consumption
– By re-using an LSP, multicast flows will be delivered to
routers that do not have receivers for it (flooding)
Maximum
Low state
flooding
The Impact of Flooding
 Single P2MP LSP rooted at PE1
5M per multicast stream
PE1
P2MP LSP
10M flooding PE3

5M flooding PE4
5M flooding PE5
5M forwarded 10M forwarded 10M forwarded
Aggregation Levels
1. No aggregation
– Each multicast flow has its own LSP
2. LSP per VPN per PE
– Multicast flows for a VPN per PE share single LSP
3. LSP per VPN
– Multicast flows for a VPN (any PE) share single LSP
4. LSP per PE
– Multicast flows per PE (any VPN) share single LSP
5. Single LSP for ALL multicast
– All multicast flows (any PE) (any VPN) share single LSP
Aggregation Policy
Summary
 Aggregation level depends on application in combination with tree building

protocol
 The more LSPs that can be supported, the less aggregation that is needed
 Options 1 and 2 most suitable for global table multicast
– Number of multicast flows in the order of 1 – 10 K
 Options 2 and 3 most suitable for VPN
 Options 4 & 5 require upstream label allocation (VPN demultiplixer label) to
aggregate VPNs over a single PE tree
– This is an expensive solution!
– Very high level of flooding!
Assigning Flows to LSPs
Flow Mapping
 Static
 PIM
 BGP Auto – Discovery (AD)
 BGP Customer Multicast (C-Mcast)
 In-band signaling (mLDP only)
Flow Mapping
Overview
PIM BGP
PIM PIM PIM PIM
Source PE PE Receiver Source PE PE Receiver

S1,S2
MPLS cloud S1,S2
MPLS cloud
PIM in Overlay BGP in Overlay
mLDP → PIM PIM → mLDP

static map static map translation translation
PIM PIM PIM PIM
Source PE PE Receiver Source PE PE Receiver

S1,S2
MPLS cloud S1,S2
MPLS cloud
Static Inband
Flow Mapping
Static
 Today mostly applicable to RSVP-TE P2MP

 Static configuration of multicast flows per LSP
 Allows aggregation of multiple flows in a single LSP
 Aggregation level 2 and 3
Flow Mapping
PIM
 Dynamically assigning flows to an LSP by running PIM over the LSP

 Works over MP2MP and PPMP LSP types
 Mostly applicable (but not limited) to mVPN
 No changes to PIM in order to support this
 Allows aggregation of multiple flows in a single LSP
 Aggregation level 1, 2 and 3
Flow Mapping
Auto Discovery
 Auto Discovery (AD) = The process of discovering all the PEs with members
in a given mVPN
 Used to establish the MDT in the SP core
 Can also be used to discover set of PEs interested in a given C-group (to
enable S-PMSI creation)
– S-PMSI = Data MDT
Flow Mapping
Auto Discovery Without BGP
 Rosen GRE needs Default MDT

 Core is PIM
• ASM or BiDir
• RP is configured/learned: the PEs learn of each other through the RP
• SSM
• AF IPv4 MDT under BGP is needed to learn the PEs
BGP IPv4/IPv6 MVPN Address Family
 Specified in RFC 4271, using BGP Multiprotocol Extensions [RFC4760] with an
AFI of 1 or 2 and an SAFI of MCAST-VPN
 Used for advertisement of the following AD routes:
– Intra I-PMSI (default mdt)
– S-PMSI (data mdt)
– Source active
– Leaf-AD
 Two new extended communities:

– VRF route import (replacing connector attribute, i.e. storing route originator IP address )
– Source AS (used for inter-AS mVPN)
 New BGP attributes

– PMSI tunnel attribute
– PPMP label attribute
 The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute

contains the MCAST-VPN NLRI
Flow Mapping
BGP Auto Discovery + C-Signalling
Inside the BGP update
PMSI Tunnel Attribute mcast vpn NLRI

Flags (1 0-6 – Reserved 1 Intra-AS I-PMSI A-D route
octet) 7 – L – Leaf information required 2 Inter-AS I-PMSI A-D route
0 No tunnel information present 3 S-PMSI A-D route AD type
1 RSVP-TE P2MP LSP Route type (1 octet) 4 Leaf A-D route
2 mLDP P2MP LSP 5 Source Active A-D route
Tunnel type 3 PIM-SSM Tree 6 Shared Tree Join route
7 Source Tree Join route
C type
(1 octet) 4 PIM-SM Tree
5 PIM-Bidir Tree Length in octets of the Route Type specific field of
Length (1 octet)
6 Ingress Replication MCAST-VPN NLRI
7 mLDP MP2MP LSP One or more of the following:
MPLS label (3
MPLS label
octects)
1 RSVP-TE P2MP LSP - <Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID> RD (8 octets)
2 mLDP P2MP LSP - <P2MP FEC Element> Route type specific MCAST source length (1 octet)
(variable length) MCAST source (variable)
3 PIM-SSM Tree - <P- Root Node Address, P-Multicast Group>
Tunnel MCAST group length (1 octet)
4 PIM-SM Tree - <Sender Address, P-Multicast Group>
Identifier
(variable) 5 PIM-Bidir Tree - <Sender Address, P-Multicast Group> MCAST group (variable)
6 Ingress replication - <unicast tunnel endpoint IP address of the local PE that is to be Originating router’s IP address
this PE’s receiving endpoint address for the tunnel>
7 mLDP MP2MP LSP - <MP2MP FEC Element>
Flow Mapping
BGP Auto Discovery
 BGP MCAST NLRI, and MCAST SAFI, type 1 & 2

 Dynamically assigning flows to an LSP by the head-end (root) of the LSP
using BGP A-D
 BGP A-D advertises the following in an update
– Tunnel identifier (protocol and FEC)
– Multicast flow (*,*),(*,G),(S,*),(S,G)
 Downstream receivers can immediately join the LSP
– Tree identifier and multicast flow advertized together
 Used for Default-MDT
Flow Mapping
BGP Auto Discovery
 BGP MCAST NLRI, and MCAST SAFI, type 3

 Dynamically assigning flows to an LSP by the head-end (root) of the LSP
using BGP A-D
 BGP A-D advertises the following in an update
– Tunnel identifier (protocol and FEC)
– Multicast flow (*,*),(*,G),(S,*),(S,G)
 Downstream receivers can immediately join the LSP
– Tree identifier and multicast flow advertized together
 Used for data-MDT and Partitioned MDT
Flow mapping
BGP Customer-Multicast
 BGP MCAST NLRI, and MCAST SAFI, type 5, 6, 7

 Dynamically assign flows to an LSP by the tail-end (Leaf) of the LSP using
BGP C-Mcast
 BGP C-Mcast advertises the following in an update
– Tunnel identifier (protocol and LSP FEC)
– Multicast flow (*,G),(S,G)
 Tunnel identifier is signaled by BGP AD in advance
– Using I-PMSI BGP AD updates, type 1, 2
 Aggregation levels 1,2,3,4 and 5
 Used as an alternative to PIM in the mVPN context
– PIM overlay is replaced by BGP overlay
Flow mapping
 BGP Customer Multicast (C-Mcast) signalling on overlay

 Mostly needed for multi-vendor mVPN interoperability
 Tail-end driven updates is not a natural fit to BGP
– BGP is good in one-2-many, not many-2-one
 In mVPN context, PIM is still the PE-CE protocol
 PIM is not removed - BGP C-Mcast is added !
 BGP C-Mcast does not add value to the network, unless you are interested in
aggregation level 4 and 5
 Easy for SSM
 Complex to understand/troubleshoot for ASM
Flow Mapping
 SAFI 2 in VRF and SAFI 129 across the core

– Allows for different mcast vs unicast topologies across MPLS
– SAFI 129 = VPN mcast SAFI
– A PE can select an upstream mcast hop which is different than the unicast next hop (RPF is not the
unicast route)
– e.g.
multicast IPv6 2/1 mullticast vpnv6 2/129 multicast IPv6 2/1
router bgp 1
address-family vpnv4 unicast multicast IPv4 1/2 mullticast vpnv4 1/129 multicast IPv4 1/2
address-family vpnv6 unicast
address-family vpnv4 multicast
unicast ipv6 2/1 unicast vpnv6 2/128 unicast ipv6 2/1
address-family vpnv6 multicast
unicast ipv4 1/1 unicast vpnv4 1/128 unicast ipv4 1/1
and
address-family ipv4 unicast vrf vrf1

address-family ipv6 unicast vrf vrf1 MPLS cloud
Receiver
address-family ipv4 multicast vrf vrf1 Source CE PE PE CE
S1,S2
address-family ipv6 multicast vrf vrf1
Flow mapping
In-Band signaling
 Only works with mLDP

 Multicast flow information encoded in the mLDP FEC
 IPv4 and IPv6 multicast in global or VPN context
 Typical for SSM or PIM Sparse mode sources
 IPTV walled-garden deployment
 draft-ietf-mpls-mldp-in-band-signaling
 Aggregation level 1
Flow Mapping
Good to Know
 Rosen (GRE or mLDP) uses Default and Data MDT

– Default MDT (always on) can carry anything
• All (*,G) must be on it
• Some (S,G), low rate
– Data MDT (on demand)
• Can only carry (S,G)
 Partitioned MDT
– Shared
– MDT carries (*,G) and (S,G) for which no Data MDT is triggered
– Besides one shared MDT, multiple Data MDTs can be used
Flow Mapping
Summary
 Static
– Mostly applicable to RSVP-TE
 PIM
– Well known, used since the introduction of mVPN over GRE in 2000
 BGP A-D
– Useful where head-end assigns the flows to the LSP
 BGP C-mcast
– Alternative to PIM in mVPN context, mostly required in dual vendor networks
 mLDP In-band signalling
– Method to stitch a PIM tree to a mLDP LSP without any additional signaling
Applications of Label Switched Multicast
Applications of LSM
 In-band signaling global table

 In-band signaling VPN context
 Rosen Model mVPN over mLDP
 Partitioned MDT mVPN over mLDP
 Multicast in global over P2MP TE
 mVPN over P2MP TE
 VPLS over P2MP
In-band Signaling Global Context
In-band Signaling Global Context
PIM (S1,G)
PIM (S2,G)
PIM (S1,G) P2MP LSP FEC {S1,G}
PIM (S2,G) P2MP LSP FEC {S2,G}
P2MP LSP FEC {S3,G} Receiver
Source
S1,S2 R-PE
Root-PE
PIM (S1,G)
PIM (S3,G)
PIM (S3,G)
Source
Receiver
S3
PE
R-PE
MPLS cloud
 PIM (S,G) tree is mapped to a mLDP P2MP LSP

 Root PE is learned via BGP Next-Hop of the Source address route
 R-PE may use SSM Mapping if Receiver is not SSM aware
In-band Ssignaling Global Context
 Very useful for IPTV deployments
 Works only with PIM SSM today
– (*,G) inband signalling is works in progress
 SSM Mapping may be deployed to convert to SSM
 One-2-One mapping between PIM tree and mLDP LSP
 No flooding/wasting of bandwidth
 Works well if the amount of state is bound
 IOS support
– GSR, CRS (shipping)
– 7600 (shipping)
– ASR9K (in progress)
– ASR1K, ISR4451-X (shipping)
In-band Signaling VPN Context
PIM (S1,G)
P2MP LSP FEC {RD,S1,G} PIM (S2,G)
PIM (S1,G)
PIM (S2,G)
P2MP LSP FEC {RD,S2,G}
P2MP LSP FEC {RD,S1,G} RD
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
PIM (S1,G)
PIM (S1,G)
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 PIM (S1,G) CE Receiver
 PIM (S,G) VPN tree is mapped to a mLDP P2MP LSP

 Root PE is learned via BGP Next-Hop of the VPNv4 Source address route
 R-PE may use SSM Mapping if Receiver is not SSM aware
 RD of the source VRF is included in the mLDP FEC to allow overlapping
(S,G) addresses
 Same characteristics as in-band signalling in global context

 Not well suited for generic mVPN support
 IOS support
– 7600 (shipping)
– ASR1K, ISR4451-X (shipping)
Rosen Model mVPN over mLDP
Rosen mVPN over mLDP
Default MDT
Default MDT
PIM join
PIM join
CE
Leaf PE
CE
Leaf PE
CE
Leaf PE
CE
Leaf PE CE
Leaf PE
 Default-MDT created in core using single MP2MP LSP

 PIM used for Customer route signalling over default-MDT
 Default-MDT emulates a virtual LAN
Data MDT
Data-MDT
CE
Leaf PE
CE Leaf PE
CE
Leaf PE
CE Leaf PE CE
Leaf PE
 For high rate sources data-MDT created using P2MP LSPs

 Removes traffic from default-MDT to offload PE’s that did not join stream
 Creation of data-MDT is signalled dynamically using MDT Join messages or
BGP A-D routes
Rosen Co-Existence/Migration
 Rosen GRE and Rosen mLDP can co-exist, even in one VRF
– GRE is preferred if both are present
 Migration is possible from Rosen GRE to Rosen mLDP

 Steps
1. Enable mLDP in core
2. Migrate per PE, per VRF at a time
• Preference command to prefer mLDP over GRE
mdt preference mldp
mGRE mLDP
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G) mdt preference mldp
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4
Summary
 FRR option using existing unicast TE tunnels

 Default-MDT created using MP2MP LSP
 MP2MP is more scalable than PIM SM/SSM since no per PE state created in
provider core
 BGP A-D support for Data-MDTs
 IOS support
– 7600 (shipping)
– ASR9K (shipping)
– ASR1K (shipping)
Partitioned MDT mVPN over mLDP
Introduction
 Dynamic version of Rosen model

 Key difference
– MDT built only when customer traffic needs to be transported across core
 Address issues in Rosen model
– Optimizes deployments where customer sources are mostly co-located in few sites
– Supports Anycast sources
– Reduces the number of PIM neighbors
Auto Discovery of Candidate PE’s
BGP MVPN SAFI
[*,*] PE1
mLDP ID X
Receiver
(S1, G)
CE
PE 3
Source CE PE 1
(S1,G)
BGP MVPN SAFI Receiver
CE (S2, G)
[*,*] PE2 BGP RR PE 4
mLDP ID Y
Receiver
(S1, G)
CE PE 2 (S2, G)
Source CE
PE 5
(S2,G)
 Initially there is no (default) MDT

 Candidate PE’s advertise their LSP identifier as [*,*] wildcard S-PMSI via BGP AD, we
call this the MS-PMSI
 In this example PE1 and PE2 are candidates
 Note, using BGP AD MVPN SAFI is optional, Cisco also supports it without
Setting up the MDT
MP2MP or P2MP LSP
PIM join
(S1,G)
Multicast packet Receiver

(S1, G)
CE
BGP MVPN SAFI PE3
Source CE PE1 [*,*] PE1, mLDP X
(S1,G)
[*,*] PE2, mLDP Y Receiver
(S2, G)
CE
PE4
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5
 PE3 determines that S1 is reachable via PE1 by doing a RIB lookup

 PE3 joins the [*,*] mLDP LSP as advertised by BGP AD for PE1
 When the mLDP LSP is ready, PE3 sends PIM join. Tree is either MP2MP or P2MP
 PE5 joins same (S1,G) it follows same procedures as PE3
 PE4 does not see P-MDT traffic and signalling for (S1,G)
Setting up the MDT
MP2MP or P2MP LSP PIM join
Multicast packet (S2,G)
Receiver
(S1, G)
BGP MVPN SAFI CE
PE3
CE [*,*] PE1, mLDP X
Source PE1 [*,*] PE2, mLDP Y
(S1,G)
Receiver
CE (S2, G)
PE4
Receiver
(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
 PE4 determines that S2 is reachable via PE2 by doing a RIB lookup

 PE4 joins the [*,*] mLDP LSP as advertised by BGP AD for PE2
 When the mLDP LSP is ready, PE4 sends PIM join. Tree is either MP2MP or P2MP.
 PE2 joins (S2,G) in customer site and forwards packet down LSP
 PE5 now joins (S2,G) and follows same procedures as PE4
PPMP Usage
Unicast LSP PPMP
Label Label PIM Join
PPMP LSP
PIM join
Multicast packet (S1,G)
Receiver
turnaround Unicast LSP (S1, G)
CE
PE3
Source CE
PE1 BGP MVPN SAFI
(S1,G)
[*,*] PE1, mLDP X Receiver
[*,*] PE2, mLDP Y CE (S2, G)
PE4
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
PE5
(S2,G)
 PPMP is needed when P2MP is used and PIM as overlay signalling protocol
 Root advertises BGP MVPN prefix with PPMP label
 Leafs use the PPMP label to encapsulate PIM Joins/Prunes to root, which turns around the packet and sends it out
mcast on the P2MP tree to all egress PEs
 A P2P LSP is not set up explicitly, its an existing P2P LSP that is used to reach the root
 Why does the PIM Join/Prune need to be received by all egress PE routers?
– Because of the way PIM Sparse mode works (e.g. PIM router needs to see Joins/Prunes from other PIM routers)
Control Tree
 Control tree is an additional (P2MP) tree
– Used for control mVPN packets
– Used for customer RP discovery
 BSR announcements
 AutoRP-CRP announcements
 AutoRP-MA announcements
 Control trees are only used for partitioned MDT

– Rosen : default MDT is used
– Global in-band : no need for control tree
– VRF in-band: C-control traffic is translated to core mLDP state
 For Partitioned MDT

– BGP-AD must be enabled
– PIM initiates an additional core-tree in mLDP, with Opaque-value type 2 (P2MP) for C-RP-Discovery
– When an egress PE receives this A-D route, it will join the core-tree and receive the
BSR/AutoRP announcements
Summary
 Only PIM join sent towards root

– For Partitioned MDT, joins will only be sent on MDT if they are intended for the root of the tree
and not to other PE’s
– Core tree selected based on root, which is the ingress PE
 Only root (ingress PE) is seen as PIM adjacency

 Core tree is either MP2MP or P2MP
– If PIM bidir needs to be supported, MP2MP is required
 BGP A-D used to signal core tree [*,*]

 BGP A-D used/needed to signal data-MDT
– BGP is needed because Partitioned MDT does not lead to full mesh of PIM across core tree
(Default MDT)
 PIM or BGP as overlay signalling protocol

Summary
 No core state if no customer traffic

 Optimised when sources are co-located in few sites
 Smaller PIM broadcast domain than Rosen mLDP
– Fewer unnecessary PIM Join/Prune messages
– No asserts (only one root per P-MDT)
 Only one PIM Adjacency seen

– By design only root is PIM adjacent over the MDT
 IOS support
– 7600 (planning)
– ASR1K (planning)
mLDP Forwarding
Note
 mLDP packets are forwarded in the core with only one label, even when
VRFs are used
– This one MPLS label signifies forwarding and identifies the VRF
• L3VPN uses two labels for unicast forwarding
– mLDP does not have penultimate hop popping (PHP)
– mLDP does not use explicit null
Inter-as and CsC
 mLDP can provide Inter-as and CsC

– GRE
– All mLDP profiles
 P2MP TE cannot provide Inter-AS or CsC
Multicast in Global over P2MP TE
Multicast in Global over P2MP TE
Static Mapping
P2MP TE LSP
PIM join
multicast packet (S1,G)
Receiver
(S1, G)
Source
CE
(S1,G) PE3
CE
PE1
PIM join
(S1,G)
Receiver
(S1, G)
CE (S2, G)
PE5
 Static mapping om PIM state at the edge

 TE Headend sends Path msgs, TE Tailend sends Resv msgs
mVPN over P2MP TE
mVPN over P2MP TE
BGP Update (S,G)
P2MP TE LSP
Route type 3 S-PMSI A-D route
Tunnel type 1 - RSVP-TE P2MP LSP

BGP Update (S,G)
PIM join
multicast packet (S1,G)
Receiver
(S1, G)
CE
PE3
CE PE1
Source
(S1,G) BGP Update
(S,G) PIM join
(S1,G)
Receiver
(S1, G)
CE (S2, G)
PE5
 BGP signals Route Type, Tunnel Type, TE endpoint

 TE Headend sends Path msgs, TE Tailend sends Resv msgs
VPLS over P2MP
VPLS over P2MP
Introduction
 VPLS currently uses mesh of P2P LSPs to replicate

– Traffic destined to unknown unicast MAC address
– All multicast traffic
 This is not efficient and may cause scalability issues, specially if the multicast traffic
increases for many sites.
 VPLS is optimized with a P2MP LSP per VFI, either
– mLDP P2MP LSP
– RSVP-TE P2MP LSP
 Build on top of unicast Targeted-LDP signaling

 Increase scalability at the head-end
 Decrease bandwidth usage in the network
VPLS over P2MP
Bandwidth Saving
P2P LSP Receiver

VFI (S1, G)
CE
PE2
VFI
P2P LSP
P2MP
CE PE1
Source
(S1,G) VFI
Root of
P2MP tree P2P LSP
Receiver
PE3 (S1, G)
CE
 2 copies of the same packet sent over the same link when using P2P LSPs
versus
 1 copy of packet sent over p2mp LSP
VPLS over P2MP
MAC Learning
P2P LSP Receiver

VFI (S1, G)
CE
PE2
VFI
P2P LSP
P2MP
CE PE1
Source
(S1,G) VFI
Root of
P2MP tree P2P LSP
Receiver
PE3 (S1, G)
CE
 Frames arriving on P2MP PW with unknown SMAC require lookup of rootPE and VFI to
associate SMAC with correct P2P PW leading to rootPE for this VFI
VPLS over P2MP
Summary
 When using a P2MP LSP per VFI for multicast, all VPLS sites will get the
packets, flooding ( 2)
 With VPLS there is no L3 lookup, so no way for the router to prevent packets
from flooding the customer
 For that reason IGMP snooping is implemented on the egress PE’s to prevent
flooding the customer network
 IOS support
– GSR, CRS, ASR9K (in progress)
LSM Conclusion
Multicast over MPLS Profiles
Rosen GRE P2MP TE Inband Signalling Rosen mLDP Partitioned MDT core tree
GRE encap MPLS encap
Static Global P2MP TE Global Inband global

8 mLDP 7
(static (S,G))
VRF Inband Partitioned MDT VRF

Rosen GRE 0 6 Rosen mLDP
mLDP 1
MP2MP
2
MP2MP
Rosen GRE with VRF Static over P2MP Rosen mLDP Partitioned MDT
3 4
BGP-AD TE with BGP-AD 10 MP2MP with BGP- 9 MP2MP with BGP-
(static (S,G)) AD AD
BGP AD
Partitioned MDT
Rosen Static over P2MP Rosen mLDP P2MP 5
18 17 P2MP with BGP-
TE with BGP-AD with BGP-AD AD
*no Data MDT
Rosen GRE with Rosen Static over P2MP Rosen mLDP Partitioned MDT
BGP-AD and TE with BGP-AD and 16 MP2MP with BGP- MP2MP with BGP-AD 15
11 13
BGP c-mcast BGP c-mcast signalling AD and BGP c- and BGP c-mcast
BGP C-mcast
signalling mcast signalling signalling
*no Data MDT signalling
Rosen mLDP P2MP Partitioned MDT P2MP
14
with BGP-AD and 12 with BGP-AD and BGP
*static = static destination BGP c-mcast c-mcast signalling
list in the core signalling
Conclusion
 Unified unicast/multicast forwarding
 mLDP and RSVP are both useful tree building protocols for transporting multicast over
MPLS
 It depends on the application and the scalability/feature requirements which protocol is
preferred
 Aggregation is useful to limit the number of LSPs that are created
– Too much aggregation causes flooding
 There are different options to assign multicast flows to LSP’s, Static, PIM, BGP, and
mLDP in-band signaling
 For general purpose mVPN we recommend mLDP for tree building and PIM for
assigning flows to the LSP
 With mLDP in the core, you can choose any model (per VPN/customer) !
Questions?
Complete Your Online Session Evaluation
 Give us your feedback and
you could win fabulous prizes.
Winners announced daily.
 Receive 20 Cisco Daily Challenge
points for each session evaluation
you complete.
 Complete your session evaluation
online now through either the mobile
app or internet kiosk stations.
Maximize your Cisco Live experience with your
free Cisco Live 365 account. Download session
PDFs, view sessions on-demand and participate in
live activities throughout the year. Click the Enter
Cisco Live 365 button in your Cisco Live portal to
log in.
Comparisons – Core Protocols
PIM vs mLDP
PIM mLDP
• mature protocol • new enhancement to older protocol
• no need for new code • need new code, but base mLDP code (for P routers)
has been around for years now
• soft state (periodic refresh)
• hard state (no periodic updates)
• mGRE encap
• MPLS label switching
(unified forwarding plane)
• customer state present in core with Data MDT • customer state present in core with Data MDT
• customer state in core with in-band signalling
Comparisons – Core Protocols
mLDP vs MPLS TE (for mVPN)
mLDP MPLS P2MP TE

• new enhancement to older protocol • new enhancement to older protocol
• need base mLDP code on P routers • need to upgrade P routers
• hard state (no periodic updates) • soft state (periodic refresh)
• dynamic tree building • static P2MP trees
• FRR possible (P2P TE tunnel) • FRR possible
• no “BW reservation” • “BW reservation”
• setup driven by tail ends • setup driven by head ends
• P2MP and MP2MP trees • P2MP trees only
• suitable for all mcast applications • mostly suitable for video delivery
best for many-to-many best for few-to-many
Comparisons – Customer Signalling Protocols
PIM vs BGP
PIM BGP
• older protocol, proven, well known • new enhancement to older protocol
• no changes needed • new procedures, complex for PIM SM
• soft state (periodic refresh) • hard state (no periodic updates)
• info driven to specific PE router • info driven to all PE routers
• PIM adjacencies to all PE routers • BGP adjacencies to all PE routers

but likely only to RRs
Comparisons – Solutions
Rosen GRE vs Rosen mLDP
Rosen mGRE Rosen mLDP
• PIM/mcast in core needed • mLDP in core
• encapsulation in core is mGRE • encapsulation in core is MPLS
• huge number of deployments • deployments ramping up
• C-PIM in overlay, but BGP is possible • C-PIM in overlay, but BGP is possible
• Control traffic over Default MDT • Control traffic over Default MDT
• Data MDT is signalled by PIM (or BGP) in overlay • Data MDT is signalled by PIM (or BGP) in overlay
• Data MDT is P2MP mcast IP tree • Data MDT is P2MP FEC
Comparisons – Solutions
mLDP
VRF mLDP In-band Signalling mLDP Partitioned MDT
• mLDP in core • mLDP in core
• encapsulation in core is MPLS • encapsulation in core is MPLS
• C-(S,G) state is present on P routers • C-(S,G) state is not present on P routers

(in mLDP) there is one P-MDT per ingress PE per VRF
• no overlay signalling • overlay signalling
• Control traffic over control tree
• Data MDT (new P2MP FEC) can only be signalled by BGP
• PIM hello’s are one way only

Brkipm-2011 - Multicast Mpls

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brkipm-2011 - Multicast Mpls

Uploaded by

Copyright:

Available Formats

Multicast MPLS

Distribute Information to Large Audiences over an IP Network

IPv4 IPv6 IPv4 IPv6

C-Multicast Signaling (PE) PIM BGP None

Core Tree Signaling PIM MLDP P2MP TE

Encapsulation/Forwarding IP/GRE LSM

 Point to Point (P2P) & (Multi-Point to Point)

MP2P LSP P2P LSP

PM2P LSP MP2MP LSP

 Replication of traffic in core

 Combination of P2P and P2MP

20 23 [ipv4 10.100.1.6 232.1.1.1] \ 20

MP2MP LSP is combination

PMSI = Provider Multicast Service Interface

 The egress (leafs) receives a PIM Join

 Control Plane: 1 P2MP LSP

Label Mapping Sender/Receiver

 Control Plane: 1 MP2MP LSP

 LSPs are build from the head-end to the tail-end

BGP Auto Discovery leaf updates

 Control Plane: 3 P2P sub-LSPs from the Root to the Leaves

The egress (leaf) receives a PIM Join

The leaves respond with RSVP-TE Resv messages

 PPMP is an emulated MP2MP LSP

 Single VPN with 1000 PEs

 Any-2-any is best supported over a MP2MP LSP

5M per multicast stream

10M flooding PE3

5M forwarded 10M forwarded 10M forwarded

 Aggregation level depends on application in combination with tree building

PIM PIM PIM PIM

Source PE PE Receiver Source PE PE Receiver

PIM in Overlay BGP in Overlay

mLDP → PIM PIM → mLDP

PIM PIM PIM PIM

Source PE PE Receiver Source PE PE Receiver

 Today mostly applicable to RSVP-TE P2MP

 Dynamically assigning flows to an LSP by running PIM over the LSP

 Rosen GRE needs Default MDT

 Two new extended communities:

 New BGP attributes

 The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute

PMSI Tunnel Attribute mcast vpn NLRI

 BGP MCAST NLRI, and MCAST SAFI, type 1 & 2

 BGP MCAST NLRI, and MCAST SAFI, type 3

 BGP MCAST NLRI, and MCAST SAFI, type 5, 6, 7

 BGP Customer Multicast (C-Mcast) signalling on overlay

 SAFI 2 in VRF and SAFI 129 across the core

address-family ipv4 unicast vrf vrf1

 Only works with mLDP

 Rosen (GRE or mLDP) uses Default and Data MDT

 In-band signaling global table

 PIM (S,G) tree is mapped to a mLDP P2MP LSP

 PIM (S,G) VPN tree is mapped to a mLDP P2MP LSP

 Same characteristics as in-band signalling in global context

 Default-MDT created in core using single MP2MP LSP

 For high rate sources data-MDT created using P2MP LSPs

 Migration is possible from Rosen GRE to Rosen mLDP

 FRR option using existing unicast TE tunnels

 Dynamic version of Rosen model

 Initially there is no (default) MDT

Multicast packet Receiver

 PE3 determines that S1 is reachable via PE1 by doing a RIB lookup

 PE4 determines that S2 is reachable via PE2 by doing a RIB lookup

 BGP A-D used to signal core tree [,]