Agenda
Why Multicast VPNs?
Multicast VPN Solution
Cisco’s Implementation
Deployment Considerations
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential

Why Multicast VPNs
Until now only unicast has been supported in MPLS/BGP VPN
VPN customers need multicast connectivity
Applications that require multicast
Internet multicast connectivity

Service Providers want to offer additional services
eg Video streaming to its VPN customers
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential

Challenges
Core (P) routers have no knowledge of VPN source addresses
Multicast (PIM) uses the source address to determine the RPF interface

VPN group address may overlap

For optimal traffic forwarding multicast routing in the core is required

Core stability must be assured PIM is a soft-state protocol hence limited # of states can be supported
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Why Multicast VPNs

Workaround has been point-to-point GRE tunnels
from CE to CE

Not scalable with many CE routers
Traffic overhead
Administrational overhead
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Point-to-point tunneling removes the benefits of multicast
Traffic has to be replicated by the CE router for each remote CE router
Traffic in the core will be multiplied by the number of CE routers
Non-congruent unicast/multicast due to RPF issues
A better solution is required
Agenda

Why Multicast VPNs ?

Multicast VPN Solution

Cisco’s Implementation

Deployment Considerations
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Multicast VPN solution

Based on draft-rosen-vpn-mcasttxt
Section 2, “Multicast Domains”

CEs maintain PIM adjacency with PEs only

P-network does not hold (S, G)s for individual
customers

Customer multicast groups can overlap
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Multicast Domains  Terminology

Multicast Domain (MD): Set of VRFs that can send
multicast to each other

Multicast VRF (MVRF): A VRF that supports both
unicast and multicast forwarding tables

Multicast Tunnel (MT): Used to carry multicast Cpackets
among PE routers in a common MD
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Multicast Domains  Operation

An MVRF is assigned to a MD

Per MD a P-group address is defined

This P-group address must be unique

C-packets are encapsulated on the PE routers and
send on the MT as P-packets
Source address is address of MP-BGP update-source
Destination address is P-group address
Encapsulation could be GRE/IPinIP/MPLS
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Multicast Domains  Summary

State in the core is minimized
Optimally one state in the core for all multicast states within
a VPN
Stability of core is provided
Service Provider has control of own destiny

Traffic replication not optimal as PE routers without
interested receivers still receive all multicast traffic
per VPN
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Multicast Domains  Example
PE
PE
PE
CE
CE
CE
Provider Network
PE-CE PIM neighborship
PE-P PIM neighborship
PE-PE PIM neighborship (over MT)
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Multicast Domains  Example
PE
PE
PE
CE
CE
CE
Sender
Receiver
C-data-packet
S=192111
D=239111
P-packet
S=10111
D=239222
Payload=C-packet
C-data-packet
S=192111
D=239111
C-control-packet
S=192222
D=2240013
P-packet
S=10222
D=239222
Payload=C-packet
C-control-packet
S=192222
D=2240013
Both customer control and data traffic are sent over the multicast tunnel
P routers only see P packets, so they won’t build state for traffic inside the VPN
P packets will go to each PE router that is in the multicast domain
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Agenda

Why Multicast VPNs ?

Multicast VPN Solution

Cisco’s Implementation

Deployment Considerations
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Cisco’s Implementation

Overview

Configuration of Default-MDT

MP-iBGP Update

Multicast Tunnels

MVRF

Data flow over the Default-MDT

Setup of Data-MDT

Data flow over the Data-MDT
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Cisco’s Implementation  Overview

Implementation is based on Multicast Domains
Network stability is key in network operations
With enhancement optimal forwarding can be accomplished
Provider has control of own destiny
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Cisco’s Implementation  Overview

Additional requirements
Service provider may have a preference for a PIM operating
mode or already has deployed multicast in core
VPN customer may have a preference for a PIM operating
mode or already has deployed multicast in the network

Implementation must support all modes

PIM mode used in the core and VPN should be
unrelated
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Cisco’s Implementation  Overview

Available PIM modes
PIM Bidirectional (PIM-BIDIR)
PIM Source Specific Multicast (PIM-SSM)
PIM Sparse-Mode (PIM-SM)
PIM Dense-Mode (PIM-DM)

No sane service provider uses PIM-DM in the core,
therefore it is not supported as protocol in the core
Neither is any other protocol which is not based on PIM
(like dvmrp, mospf etc)
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Cisco’s Implementation  Overview
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Cisco’s Implementation  Overview

Additional challenges
Multicast packets in an MVRF are being sent and received on a
multicast tunnel that is established between the PE routers
No unicast routing over this tunnel
RPF information in PIM is based on unicast routing information
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Blue Multicast Domain
Red Multicast Domain
Each Default-MDT uses a separate
Multicast Group inside of Provider’s
Network
Provider
Net
(*,239111)
(*,239112)
Source
(*,239111)
(*,239112)
Receiver
PIM Control Traffic Flow
Source
S=192111
G=23925511
C - PIM control packet
S=192222
D=2240013
Payload: PIM Join/Prune
(Join 192111, 23925511)
(*,239111)
Default-MDT
Receiver
S=192111
G=23925511
C - PIM control packet
S=192222
D=2240013
Payload: PIM Join/Prune
(Join 192111, 23925511)
P - data packet
S=10222
D=239111
(C-PIM control packet)
Multicast Data Traffic Flow
Source
S=192111
G=23925511
C - data packet
S=192111
D=23925511
Payload: (multicast data)
P- data packet
S=10111
D=239111
Payload: (C - data packet)
(*,239111)
Default-MDT
Receiver
S=192111
G=23925511
C - data packet
S=192111
D=23925511
Payload: (multicast data)
Advantage : Reduces multicast state in the P routers in the core
Disadvantage : Can result in wasted bandwidth
Solution : Use separate Data-MDTs for high rate sources
High-Rate
Source
S=192111
G=23925511
Receiver
S=192111
G=23925511
(*,239111)
Default-MDT
Traffic exceeds Data-MDT threshold configured on PE router
High-Rate
Source
S=192111
G=239111
(*,239111)
Default-MDT
P- control packet
S=10111
D=2240013
Payload: (PIM MDT-Data)
S=192111, G=239111
MDT Group = 239221
Receiver
S=192111
G=239111
PE router signals switch to Data-MDT using new group, 239221
(*,239221)
Data-MDT
Data-MDT is built using group 239221
(*,239221)
Data-MDT
Data only goes to PE routers that have receivers
C - data packet
S=192111
D=239111
Payload: (multicast data)
C - data packet
S=192111
D=239111
Payload: (multicast data)
P- data packet
S=10111
D=239221
Payload: (C - data packet)
(*,239221)
Data-MDT
Cisco’s Implementation

Overview

Configuration of Default-MDT

MP-iBGP Update

Multicast Tunnels

MVRF

Data flow over the Default-MDT

Setup of Data-MDT

Data flow over the Data-MDT
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Configuration of Default-MDT

Default-MDT has two components
Group address: Configurable
Source address: Update-Source of MP-iBGP session
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Default-MDT Group Address

Group address must be configured
Group address MUST be the same for all MVRFs
belonging to the same MVPN
Group address MUST be different for all MVRFs belonging
to different VPNs that are configured on the same PE
router
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Default-MDT Group Address  Example
PE1
PE4
PE2 PE3
ip vrf green
rd 1:80
route-target export 1:1
route-target import 1:1
mdt default 239111
ip vrf red
rd 1:99
route-target export 1:99
route-target import 1:99
mdt default 239112
ip vrf green
rd 1:80
route-target export 1:80
route-target import 1:80
mdt default 239111
ip vrf red
rd 1:99
route-target export 1:99
route-target import 1:99
mdt default 239112
ip vrf green
rd 1:80
route-target export 1:80
route-target import 1:80
mdt default 239111 ip vrf red
rd 1:99
route-target export 1:99
route-target import 1:99
mdt default 239112
P
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Configuration of Default-MDT

Default-MDT has two components
Group address: Configurable
Source address: Update-Source of MP-iBGP session
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Default-MDT source address

Source address of the Default-MDT is the address
used to source the MP-iBGP sessions with the
other PE routers with MVRFs belonging to the
same VPN
Common practice is to use the ‘update-source’ keyword in
the BGP config and choose a loopback interface
This is a requirement for MVPN

The update-source interface MUST be the same for
all MP-iBGP sessions configured on the router for
the Default-MDT to be setup properly

No additional commands are needed
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
Default-MDT Source Address  Example
ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential MVPN 37
PE4
PE2 PE3
P router bgp 1
neighbor <PE2> remote-as 1
neighbor <PE2> update-source Loopback0
neighbor <PE4> remote-as 1
neighbor <PE4> update-source Loopback0
!
address-family ipv4 vrf RED
redistribute <IGP>
exit-address-family
!
address-family vpnv4
neighbor <PE2> activate
neighbor <PE2> send-community-extended
neighbor <PE4> activate
neighbor <PE4> send-community-extended
exit-address-family
PE1
Cisco’s Implementation

Overview

Configuration of Default-MDT

MP-iBGP Update

Multicast Tunnels

MVRF

Data flow over the Default-MDT

Setup of Data-MDT

Data flow over the Data-MDT
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
MP-iBGP Update

Key is a BGP neighbor relationship with remote PE
routers

PE routers tell other routers that they participate in
an MVPN
This triggers the setup of the Default-MDT
New RD type in VPN-IPv4 address
New extended community

BGP next hop is used to determine the RPF
information
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
MP-iBGP Update  Additions

(M)VPN-IPv4 address (12 bytes)
Route Distinguisher - 8 bytes
type-field: 2 bytes
value-field: 6 bytes
New type : 0x02 (Multicast-VPN)
Value field (AS format must be used):
2 bytes ASN
4 bytes assigned number
IPv4 address - 4 bytes
VRF next hop
Used for SSM in the Core)
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential
MP-iBGP Update  Additions
Extended community attribute - 8 bytes
Type Field : 2 bytes
Value Field : 6 bytes
New type: 0x09 (AS format)
Value Field :
2 bytes ASN
4 bytes assigned number (MDT Group address)
OR (currently not supported)
New type: 0x0109 (Address format)
Value Field :
4 bytes IPv4 address (MDT Group address)
2 bytes assigned number
MVPN ⓒ 2009 Cisco Systems, Inc All rights reserved Cisco Confidential