Advanced Topics in IP Multicast Deployment

Advanced Topics in IP Multicast
Deployment
BRKIPM-2008
Greg Shepherd
Distinguished Engineer

© 2014 Cisco and/or its affiliates. All rights reserved.BRKIPM-2008 Cisco Public
Abstract Reminder
 This session covers tools and techniques that will assist with deploying IP Multicast.
 We begin with some configuration examples which discuss PIM modes and Rendezvous
Point Deployment models for PIM SM domains
 Examples are then given for ways of interconnecting separate PIM domains
 A description of a technology called Automatic Multicast Tunnels (for extending multicast
content between sites which are not homogeneously connected) is provided
 We discuss the integration of multicast with MPLS (Label Switched Multicast).
 We discuss ways of delivering a highly available multicast service.
 We briefly discuss the deployment of IP Multicast in a wireless environment.
 This session is primarily for network engineers in enterprise and service provider network
environment. Attendees should have a basic understanding of IP Multicast
3

 Multicast Market Overview
 PIM Configuration notes
 Interconnecting PIM domains
 Label Switched Multicast
 High Availability
 Multicast in 802.11
4
Agenda

Multicast Applications
6
 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)
‒ Native v4 and v6
‒ Label Switched Multicast (LSM)
‒ Multicast VPNs (IP and MPLS-based)

Multicast Benefits For Content Delivery
Growth of Internet Based Live Video Services
7
By 2014 10% of all Internet video content will be live

Multicast Application Types
9
One-to-Many (1toM) Many-to-Many (MtoM) Many-to-One (Mto1)
Audio/Video
Lectures, presentations,
concerts, television, radio
Push Media
News headlines, weather
updates, sports scores
Distribution
Web site content, executable
binaries
Announcements
Network time, multicast
session schedules, random
numbers, keys, security
Monitoring
Stock prices, sensors
Conferencing
Audio/Video conferences,
whiteboards
Sharing Resources
Synchronized distributed
databases
Games
Multi-player with distributed
interactive simulations
Others
Concurrent processing,
collaboration, two-way distance
learning
Resource Discovery
Service location, device
discovery
Data Collection
Monitoring applications,
video surveillance
Others
Auctions, polling, jukebox,
accounting
For a detailed analysis see RFC3170

The Multicast “Application Spectrum”
10
Many-to-Many | Few applicationsOne-to-Many applications
SSM
For One-to-Many applications
Eliminates need for RP Engineering
Data and Control Planes decoupled
Bidir
For Many-to-Many | Few applications
Drastically reduces (S,G) state in network
Data and Control Planes decoupled
All modes can coexist and applications can be moved
gracefully (by group) between modes
SM
For One-to-Many applications
Original (Classic)
Supports both Shared and Source Trees

Impact of Source Specific Multicast (SSM)
 Hosts join a specific source within a group
Content identified by specific (S,G) instead of (*,G)
Hosts responsible for learning (S,G) information
 Last-hop router sends (S,G) join toward source
Shared Tree is never Joined or used
Eliminates possibility of content Jammers
Only specified (S,G) flow is delivered to host
 Eliminates Networked-Based Source Discovery
No RPs for SSM groups
 Simplifies address allocation
Content sources can use same group without fear of interfering with each other
11

Socket Interface Extensions for Multicast
 Protocol Independent (supports both IPv4 and IPv6)
 Source-Specific Multicast API
– Section 5.1.2 of the RFC
– MCAST_JOIN_SOURCE_GROUP Join Source Specific Group
– MCAST_LEAVE_SOURCE_GROUP Leave Source Specific Group
– MCAST_LEAVE_GROUP Drop all sources for group / interface
 Suggested best practices
– One multicast group per socket to prevent overload
– Verify interface presently used for multicast (Ethernet, Wi-Fi, 3G, etc..)
Source Filters (RFC 3678)
12

Rendezvous Points Auto-RP
13
 Dynamic way to learn RP to Group mapping information for IPv4
 Two IANA reserved groups forward mapping information:
‒ 224.0.1.39 - cisco-rp-announce
‒ 224.0.1.40 - cisco-rp-discovery
 Groups carry Group to RP mappings
 Usually forwarded in Dense Mode:
‒ IOS state appear in mroute tables
‒ NXOS creates no visible mroutes / configured to forward / listen to groups:
‒ ip pim auto-rp forward listen
‒ IOS XR RPF floods to neighbors (no requirement for Dense Mode)
 This helps when:
‒ RP address and group ranges change often
‒ Network has many routers
‒ Simple config desired
‒ Several RPs for different applications
‒ RPs maintained by different administrative groups

Auto-RP Listener – Cisco IOS
14
 Use global command (recommended):
‒ ip pim autorp listener
‒ Added support for Auto-RP Environments
‒ Modifies interface behavior:
Interface configured in SM and only use DM for
Auto-RP group
Only needed if Auto-RP is used
 Use with interface command
‒ ip pim sparse-mode
Prevents DM Flooding
 No longer need:
‒ ip pim sparse-dense-mode
‒ Available 12.3(4)T, 12.2(28)S, 12.1(13)E7

Avoid DM Fallback Automatically – Cisco IOS
 IOS global command
– no ip pim dm-fallback
 Totally prevents DM Fallback!
– No DM Flooding (since all state remains in SM)
 Default RP Address = 0.0.0.0 [nonexistent]
– Used if all RPs fail
 All SPTs remain active
 Enabled by default if all interfaces are in sparse mode
 Available 12.3(4)T, 12.2(33)SXH
15

Auto-RP in IOS XR
 IOS XR supports Auto-RP
 IOS XR Auto RP operation is interoperable with IOS
 IOS XR needs no DM state
 Auto RP groups RPF flooded to PIM neighbors
 No support for AutoRP in IPv6 in ANY OS
16

Rendezvous Points - Anycast RP
 Allows RP redundancy (even with static RP assignment)
 Converges in (deterministic) IGP timescale
 Relies on MSDP (IOS and IOS XR) or entirely based on PIM (NXOS)
 http://tools.ietf.org/html/rfc3446
17

Anycast RP – MDSP Config
18
Interface loopback 0
ip address 10.0.0.1 255.255.255.255
ip pim sparse-mode
ip address 10.0.0.2 255.255.255.255
!
ip msdp peer 10.0.0.3 connect-source loopback 1
ip msdp originator-id loopback 1
ip address 10.0.0.1 255.255.255.255
ip pim sparse-mode
ip address 10.0.0.3 255.255.255.255
!
B
RP2
A
RP1
C D
ip pim rp-address 10.0.0.1 ip pim rp-address 10.0.0.1

Combining Anycast RP with Auto-RP
19
ip address 10.0.0.1 255.255.255.255
ip address 10.0.0.2 255.255.255.255
!
ip pim send-rp-announce loopback 0 scope 32
ip pim send-rp-discovery loopback 1 scope 32
!
ip address 10.0.0.1 255.255.255.255
ip address 10.0.0.3 255.255.255.255
!
ip pim send-rp-announce loopback 0 scope 32
ip pim send-rp-discovery loopback 1 scope 32
!
MSDP
B
RP2
A
RP1
C
ip multicast-routing
ip pim autorp-listener
no ip pim dm-fallback
D
•Rapid RP failover of Anycast RP
•No DM Fallback
•Configuration flexibility of Auto-RP
•Ability to disable undesired groups

Anycast RP (PIM) - Operations
20
• FHR sends registers to RP1
• RP1 decapsulates packet, replicates it down RPT, joins SPT
• Copy of register sent to RP2, source is RP1’s address
• RP1 sends register-stop to FHR
• RP2 decapsulates packet, replicates it down RPT, joins SPT
• RP2 sends register-stop to RP1
• If no RPTs exist, discard register, send register-stop to sender, LHR and/or RP1
RP1
10.1.1.1
RP2
10.1.1.1
LHR
RP
2
10.1.1.1
FHR
FHR10.1.1.1
PIM register
PIM register stop

Anycast RP – PIM Config (NXOS)
21
B
RP2
A
RP1
feature pim
interface loopback1
ip address 10.10.10.10/32
ip router ospf 10 area 0.0.0.0
ip pim sparse-mode
interface loopback2
ip address 100.100.100.100/32
ip pim sparse-mode
ip pim anycast-rp 100.100.100.100 10.10.10.10
ip pim anycast-rp 100.100.100.100 20.20.20.20
ip pim rp-address 100.100.100.100 group-list 224.0.0.0/4
feature pim
interface loopback1
ip address 20.20.20.20/32
ip pim sparse-mode
interface loopback2
ip address 100.100.100.100/32
ip pim sparse-mode
ip pim anycast-rp 100.100.100.100 10.10.10.10
ip pim anycast-rp 100.100.100.100 20.20.20.20
C
feature pim
feature pim
D

!
interface Loopback0
ip address 1.1.1.1 255.255.255.252
ip pim sparse-mode
ip ospf network point-to-point
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
!
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
!
router ospf 11
network 1.1.1.0 0.0.0.3 area 0
network 10.1.1.0 0.0.0.255 area 0
network 10.1.2.0 0.0.0.255 area 0
!
ip pim bidir-enable
ip pim rp-address 1.1.1.2 bidir
BiDir Phantom RP
22
RP: 1.1.1.2
!
interface Loopback0
ip address 1.1.1.1 255.255.255.248
ip pim sparse-mode
ip ospf network point-to-point
!
ip address 10.1.1.2 255.255.255.0
ip pim sparse-mode
!
ip address 10.1.2.2 255.255.255.0
ip pim sparse-mode
!
router ospf 11
network 1.1.1.0 0.0.0.7 area 0
network 10.1.1.0 0.0.0.255 area 0
network 10.1.2.0 0.0.0.255 area 0
!
ip pim bidir-enable
ip pim rp-address 1.1.1.2 bidir
SP
30 Bit Mask 29 Bit Mask
OSPF requires
P2P interfaces
Question: Does Bidir RP have to physically exist?
Answer: No. It can be a phantom address.

Phantom RP with Auto-RP
23
ip pim send-rp-announce 1.1.1.2 scope 32 bidir
ip pim send-rp-discovery Loopback1 scope 32
interface Loopback0
ip address 1.1.1.1 255.255.255.252
ip pim sparse-mode
ip pim send-rp-announce <[int] | [ip-address]> scope [group-list] [bidir]
 Previously, Auto-RP could only advertise IP address on interface
(e.g. loopback) as RP
 New option has been added—now we can advertise any address
on a directly connected subnet
 In example below, Phantom RP address is being advertised through Auto-RP; the source of
the Mapping packets are the address
on Loopback
 Available 12.4(7)T, 12.2(18)SXF4

Intermittent Sources
24
 “Intermittent” means applications / sources that temporarily stop
sending for > 3 minutes
 (S,G) state times out. Initial packets lost during SPT switchover
 Solutions:
 PIM-Bidir or PIM-SSM (no data driven events)
 Periodic keepalives or heartbeats

Intermittent Sources – (S,G) Expiry Timer
25
 (S,G) expiry timer:
 Set on every router to maintain state for entire trading day (36000
seconds = 10 hours)
ip pim sparse sg-expiry-timer <secs>
Available 12.2(18)SXE5, 12.2(18)SXF4, 12.2(35)SE and NXOS
7010-1# sh run pim | in sg
ip pim sg-expiry-timer 36000 sg-list sg-expiry
7010-1# sh route-map sg-expiry
route-map sg-expiry, permit, sequence 10
Match clauses:
ip multicast: group 239.1.2.0/23
Set clauses:

Interconnecting PIM Domains
- NAT / Service Reflection

Benefits of Multicast Destination NAT
28
• Address Collision
‒ Solves overlapping services in scoped address range
• Domain Separation
‒ Creates two PIM domains
‒ Edge router becomes source / receiver in each domain
• Redundancy
‒ Allows creation of A and B stream
• Source Network Issues
‒ Allows free selection and scoping of source subnet
• Translation or Splitting options:
‒ Multicast-to-Multicast
‒ Multicast-to-Unicast
‒ Unicast-to-Multicast

Multicast Service Reflection Interface
29
• Appears as multicast receiver in source domain
• Appears as multicast source in receiver domain
• Similar to loopback interface – logical interface always up
• Resides on unique subnet excluded from IGP updates
• Maintains information about:
 Input interface
 Private-to-public destination group mappings
 Mask length which defines destination pool range
 Source IP address of translated packet
PIM Domain A
PIM Domain BVif 1 Interface

Service Reflection Interface Configuration
30
 Asssign Vif1 to globally
unique IP subnet
 Vif1 subnet to be used as
source address of NATed
packets
 Advertise Vif1 subnet in
routing protocol
 Configure multicast
routing for NATed address
range not shown (PIM-
SM, SSM, or Bidir-PIM)
interface Vif1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 10.0.0.0
no auto-summary
PIM Domain
A
PIM Domain
B
Vif1 Interface
224.1.1.0 to 239.1.1.0
224.1.1.1 to 239.1.1.1
. . .
224.1.1.255 to 239.1.1.255
Configure Vif1 & Routing:

Service Reflection – Receiver / Group Range
31
interface Vif1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
ip igmp static-group class-map static
!
class-map type multicast-flows static
group 224.1.1.0 to 224.1.1.255
PIM Domain
A
PIM Domain
B
Vif1 Interface
224.1.1.0 to 239.1.1.0
224.1.1.1 to 239.1.1.1
. . .
224.1.1.255 to 239.1.1.255
 Static IGMP groups pull streams
from PIM Domain A to Border
Router
 Use IGMP Static Group Range to
simplify configuration
 Supported since 12.2(18)SXF5

Service Reflection Parameters
32
interface Vif1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
ip service reflect Gig0/0 destination 239.1.1.0 to
239.1.1.255 mask-len 24 source 10.1.1.2
PIM Domain
A
PIM Domain
B
Vif1 Interface
224.1.1.0 to 239.1.1.0
224.1.1.1 to 239.1.1.1
. . .
224.1.1.255 to 239.1.1.255
 Include input interface
 Define destination pool
range and mask length
 Specify source IP address
from Vif1 subnetGig0/0

- Static and Dynamic Models

• Static Forwarding
• Static Service Levels—Cable Model
• Dynamic Forwarding
• Hybrid Design
• Provider / Customer prefer
least coordination
• Providers under contract to deliver stream
• Each side wants to limit organizational liability / coordination
• Provider / Customer have separate multicast domains
• Therefore:
– Traffic statically nailed up, no PIM Neighbors, no edge DR, no PIM Joins
accepted, no RP shared, no MSDP peering
34
Brokerage
Content
Provider
Financial Service Provider
Brokerage Brokerage
Content
Provider
Content
Provider

Static Subscriptions with IGMP
Customers Want Ability to “Nail Up” Service
 Existing Issues
– ip igmp join-group <group>
 Sends an IGMP report out the interface
 Traffic gets punted to CPU
– ip igmp static-group <group>
 Adds interface to OIL
 Does not send IGMP report out the interface
 Workarounds
– Separate router—Put IGMP join group on a dedicated router
35

Virtual RP
36
Source Network
Customer
224.0.2.64
DestinationSource
10.2.2.2
e0
e1
interface Ethernet0
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
ip igmp static-group 224.0.2.64
Virtual RP
interface Ethernet1
ip address 10.1.2.2 255.255.255.0
ip pim sparse-mode
ip pim rp-address 10.1.1.1
ip route 10.1.1.1 255.255.255.255 10.1.2.5
router ospf 11
network 10.1.0.0 0.0.255.255 area 0
redistribute static subnets
 Feed is statically nailed up
 Customer Edge router advertises
RP address from upstream interface
 Every router in customer network needs
to know about the RP

Edge Router is RP
37
Source Network
Customer
224.0.2.64
DestinationSource
10.2.2.2
e0
e1
interface Ethernet0
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
RP
interface Ethernet1
ip address 10.1.2.2 255.255.255.0
ip pim sparse-mode
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
 Customer Edge router is RP—so that
it will accept a non-connected source
 Every router in customer network
needs to be know about the RP

Edge Router is RP - Caveat
38
Source Network
Customer
224.0.2.64
DestinationSource
10.2.2.2
e0
e1
interface Ethernet0
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
RP
interface Ethernet1
ip address 10.1.2.2 255.255.255.0
ip pim sparse-mode
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
 Customer Edge router is RP—so that
it will accept a non-connected source
needs to be know about the RP
This Method Will Not Work
with Future Versions of IOS

Edge Router Proxy Registers to RP
39
Source Network
Customer
224.0.2.64
DestinationSource
10.2.2.2
e0
e1
RP
interface Ethernet1
ip address 10.1.2.2 255.255.255.0
ip pim dense-mode proxy-register list 100
access-list 100 permit ip any any
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
interface Ethernet0
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
 Customer Edge router has dense-mode on
IIF and proxy registers to RP
 RP is configured inside customer network

Edge Router is RP and MSDP Peer
40
Source Network
Customer
224.0.2.64
DestinationSource
10.2.2.2
e0
e1
RP
interface Ethernet1
ip address 10.1.2.2 255.255.255.0
ip pim dense-mode
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse mode
interface Loopback1
ip address 10.1.3.2 255.255.255.255
ip pim sparse mode
ip msdp peer 10.1.3.1 connect-source Loopback1
ip msdp originator-id Loopback1
RP
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse mode
interface Loopback1
ip address 10.1.3.1 255.255.255.255
ip pim sparse mode

Edge Router is RP and MSDP Peer
41
Source Network
Customer
224.0.2.64
DestinationSource
10.2.2.2
e0
e1
RP
interface Ethernet1
ip address 10.1.2.2 255.255.255.0
ip pim dense-mode
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse mode
interface Loopback1
ip address 10.1.3.2 255.255.255.255
ip pim sparse mode
RP
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse mode
interface Loopback1
ip address 10.1.3.1 255.255.255.255
ip pim sparse mode
Dense mode is required on the IIF so that the
A flag will be set and MSDP will forward an SA

Static Forwarding—Cable Model
42
 Basic Service
‒ ip access-list standard basic-service
permit 239.192.1.0 0.0.0.255 ! Basic service channels
 Premium Service
‒ ip access-list standard premium-service
permit 239.192.2.0 0.0.0.255 ! Premium service channels
 Premium Plus Service
‒ ip access-list standard premium-plus-service
permit 239.192.2.0 0.0.0.255 ! Premium service channels
permit 239.192.3.0 0.0.0.255 ! Premium Plus service channels
Adapt Cable Model of Provisioning by qualifying multicast boundary with each of following:

interface Vlan6
...
Static Forwarding - Group Range Command
 Subscribing dozens or hundreds of groups can be cumbersome with the static-group
command:
 The static group range command simplifies the config:
 Available in 12.2(18)SXF5
43
class-map type multicast-flows
market-data group 224.0.2.64 to 224.0.2.80
interface Vlan6
ip igmp static-group class-map market-data

Advantages of Static Forwarding
Provider and Customer Have Separate Multicast Domains
 Each free to use any forwarding model, e.g. PIM-SM, PIM-SSM,
PIM-Bidir
 Each responsible for their portion of the delivery model—clear
demarcation
 Simple, straight-forward
 Has traditionally been first choice for Financial Service Provider
44
Main Disadvantage
Customer unable to control subscriptions and bandwidth usage of
last mile dynamically
As data rates climb this is more of a issue

Dynamic Forwarding Options
 Rising data rates and 24 hour trading drive the requirement for dynamic
subscriptions
 Methods:
– IGMP Membership Reports
– PIM Joins—*,G for PIM-SM and PIM-Bidir
– PIM Joins—S,G for PIM-SSM
45

Source Network
Customer
224.0.31.20
DestinationSource
10.2.2.2
e0
e1
IGMP
IGMP
PIM
Dynamic Forwarding – Provider Wants IGMP
Report
 Assumes that hosts sit on edge of customer network or breaks
multicast delivery model
 Stretches the original design and purpose
of IGMP
 In deployment today
– We can make this work dynamically today
with a combination of:
 ip igmp helper
 ip igmp proxy-service
 ip igmp mroute-proxy
 Industry may want to recommend this model going forward
46

Source Network
e0
IGMP
IGMP
interface Loopback1
ip address 10.3.3.3 255.255.255.0
ip pim sparse-mode
ip igmp helper-address 10.4.4.4
ip igmp proxy-service
ip igmp access-group filter-igmp-helper
ip igmp query-interval 9
interface Ethernet0
ip address 10.2.2.2 255.255.255.0
ip pim sparse-mode
ip igmp mroute-proxy Loopback1
ip route 20.20.20.20 255.255.255.255 10.4.4.4
e1
Customer
e0
loopback1
PIM
10.4.4.0/24
47
Dynamic Forwarding – igmp mroute-proxy
 igmp proxy service and helper are configured
on loopback
 Downstream interface is configured
with igmp mroute-proxy
needs to be know about the virtual RP
Virtual RP: 20.20.20.20

Dynamic Forwarding – igmp mroute-proxy (Detail)
48
Source Network
e0
IGMP
(*, 239.254.1.0), 00:00:01/00:02:55, RP 20.20.20.20, flags: SC
Incoming interface: FastEthernet1/15, RPF nbr 10.2.2.2, RPF-MFD
Outgoing interface list:
Vlan194, Forward/Sparse, 00:00:01/00:02:55, H
e1
Customer
e0
loopback1
PIM
10.4.4.0/24
 PIM (*,G) Join message is received
on e0 interface and mroute state
is created; igmp mroute-proxy command on
interface causes special internal flag to be
added to mroute
 PIM (*,G) Join message filters up towards
virtual RP
 The first PIM (*,G) Join on e0 triggers an
unsolicited IGMP report to be generated on the
loopback1 interface
 Host sends IGMP report and creates mroute
state

Dynamic Forwarding – igmp mroute-proxy (Detail)
49
Source Network
e0
IGMP
IGMP
e1
Customer
e0
loopback1
PIM
10.4.4.0/24
 When periodic IGMP query is run on loopback1 the
igmp proxy-service command initiates a walk
through the mroute table looking for mroute-proxy flag;
IGMP report generated for each mroute with flag.
 While mroute is kept alive (with PIM joins) IGMP
reports are forwarded
 The igmp helper command directs the IGMP report
out the e1 interface
 IGMP reports are dynamic - only
sent when there is interest in the customer
domain; however edge router does not respond to
queries from provider router
 Consideration:
•More IGMP messages
•Complex configuration

Source Network
Customer
224.0.2.64
DestinationSource
10.2.2.2
e0
e1
RP
RP
RP
Dynamic Forwarding – PIM / MSDP
 Provider accepts PIM join
– Sparse Mode
 Provider must supply RP addr
 Requires PIM Neighbor relationship
 No RP on customer Side
 One multicast domain
– Source Specific Multicast
 Provider must supply S,G info
 Requires PIM Neighbor relationship
 MSDP
– Standard Interdomain Multicast
– Requires peering relationship
50

Dynamic Forwarding – (S,G) PIM Joins
 Works in situations ideal for SSM
 No need to share RP info or use MSDP
 Redundancy options:
– Host Side
 Host can join both primary and secondary servers—for both A and B streams
 Host will need to arbitrate between primary and standby
– Network/Server Side
 Anycast Source—Hosts only join one server and network tracks server and forwards active
stream
51

Market Data Design Whitepapers
52
 Market Data Network Architecture (MDNA)
 Trading Floor Architecture
 Design Best Practices for Latency Optimization
 IP Multicast Best Practices for Enterprise
Customers
‒ http://www.cisco.com/go/financial
A Set of Four Documents that Cover All Aspects of Network and Application
Design for Market Data Distribution

What is Label Switched Multicast ?
54
 IP multicast packets are transported using MPLS encapsulation.
 MPLS encoding for LSM documented in rfc5332.
 Unicast and Multicast share the same label space.
 MPLS protocols RSVP-TE and LDP are modified to support P2MP and
MP2MP LSPs.

LSM Protocols
55
For BUILDING LSP’s:
 Multicast LDP (MLDP)
‒ Extensions to LDP
‒ Support both P2MP and
MP2MP LSP
‒ RFC6388
 RSVP-TE P2MP
‒ Extensions to unicast RSVP-TE
‒ RFC4875
For ASSIGNING FLOWS to LSPs:
• BGP
RFC6514
Also describes Auto-Discovery
• PIM
RFC6513
• MLDP In-band signaling
• Static

LSM Services
56
 LSM architecture supports a range of services or “clients”
 Clients use combination of multicast signalling and control plane
 All LSM traffic is forwarded using MFI or LFIB mechanisms
Shares the same forwarding plane as unicast MPLS
LSM Forwarding (MFI/LFIB)
P2MP TE
VPLS
Native
IPv4
mVPN
IPv4
Native
IPv6
MLDPControl Plane
C-Multicast Signalling
Forwarding Plane
BGP / PIM / PORT / Static
Clients
m6PE
m6VPE
IPv6

MLDP P2MP - Signalling
 Egress router (leaf) receives PIM Join
 Leaf sends mLDP label mapping to Ingress router (Root) (via core)
 Ingress PE received one update due to receiver driven logic
57
Ingress
Router
(Root)
Leaf
Leaf
Leaf CE
Receiver
CE
Receiver
CE
Receiver
Source
Label
Mapping

MLDP P2MP - State
 Control Plane: 1 P2MP LSP
 Forwarding Plane: 1 P2MP LSP replication
 When leaf router wants to leave, message only sent to next branch point,
not to ingress PE;
58
Ingress
Router
(Root)
Leaf
Leaf
Leaf CE
Receiver
CE
Receiver
CE
Receiver
Source
P
PE

MLDP MP2MP - Signalling
 Leaf sends mLDP label mapping to Root, (just like P2MP)
 On each link, label mapping sent in reverse direction (away from root),
creating bidirectional MP2MP LSP
59
Ingress
Router
(Root)
Leaf
Leaf
Leaf
CE
Sender/Re
ceiver
CE
CE
Sender/Re
ceiver
Label Mapping TO
root
Sender/Rec
eiver
Sender/Rec
eiver
Label Mapping
FROM root

MLDP MP2MP - State
 Control Plane: 1 MP2MP LSP
 Forwarding Plane: 4 P2MP LSP
 Control plane state converted to set of P2MP replications in forwarding plane
60
Ingress
Router
(Root)
Leaf
Leaf
Leaf CE
Receiver
CE
Receiver
CE
Receiver
P
PESender/Rec
eiver

RSVP-TE - Signalling
 Leafs sends BGP Auto Discovery leaf to notify ingress PE
 Ingress PE sends RSVP-TE Path messages to leaves
 Leaves respond with RSVP-TE Resv messages
61
Ingress
Router
(Root)
Leaf
Leaf
Leaf CE
Receiver
CE
Receiver
CE
Receiver
Source
BGP Auto Discovery leaf updates
or static configuration
Resv Path

RSVP-TE Example - State
 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
62
Ingress
Router
(Root)
Leaf
Leaf
Leaf CE
Receiver
CE
Receiver
CE
Receiver
Source
P
PE

Applications of LSM
 IPTV / Internet multicast transport
– draft-ietf-mpls-mldp-in-band-signaling-02
– 1-1 mapping between IP multicast flow and LSP
– Forwarding uses the global table (non-VPN)
 VPLS
– draft-ietf-pwe3-p2mp-pw-00
– Use MLDP to create Pseudowires
 Carriers Carrier service
– draft-wijnands-mpls-mldp-csc-01
– A provider offering services to another provider
63

© 2014 Cisco and/or its affiliates. All rights reserved.BRKIPM-2008 Cisco Public 64
Applications of LSM (cont)
 MVPN (Rosen Model)
– RFC6037
– Using MLDP MP2MP for the default MDT (MI-PMSI).
– Using MLDP or RSVP-TE P2MP for the data MDT (MS-PMSI).
– Same as GRE model, just the encapsulation changed.
 MVPN (Dynamic partitioned MDT)
– draft-rosen-l3vpn-mvpn-mspmsi-05.
– Dynamic model of above.
– Using MLDP MP2MP for the dynamic MDT.

LSM Status
65
LSM Protocols Distinct Properties
MLDP
draft-ietf-mpls-ldp-p2mp-08
 Dynamic Tree Building suitable for broad set
 FRR as optional capability
 Receiver-driven dynamic tree building
approach
P2MP RSVP-TE
RFC-4875
 Deterministic bandwidth guarantees over entire
tree (calculation overhead limits this to static
tree scenarios)
 Headend-defined trees
 FRR inherent in tree setup
 Useful for small but significant subset of
Multicast Applications: Broadcast TV where
bandwidth restrictions exist

LSM – Decision Points
 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, PIM, BGP,
MLDP in-band signaling and static.
 For general purpose MVPN we recommend MLDP for tree building and PIM
for assigning flows to the LSP.
66

Service Availability Overview
68
IP Host Components Redundancy
 Single transmission from Logical IP address
‒ Anycast — Use closest instance
‒ Prioritycast — Use best / preferred instance
Benefit over anycast: no synchronization of sources
needed, operationally easier to predict which source
is used
‒ Signaling host to network for fast failover
RIPv2 as a simple signaling protocol
Normal configuration to inject source routes into IGP (OSPF/ISIS)
 Dual Transmission with Path separation

Source Redundancy: Approaches
69
Primary Backup Live-Live/Hot-Hot
 Two sources: one is active and
src’ing content, second is in standby
mode (not src’ing content)
 Heartbeat mechanism used to
communicate with each other
 Two sources, both are active and
src’ing multicast into the network
 No protocol between the two sources
 Only one copy is on the network at
any instant
 Single multicast tree is built per the
unicast routing table
 Two copies of the multicast packets
will be in the network at any instant
 Two multicast trees on almost
redundant infrastructure
 Uses required bandwidth  Uses 2X network bandwidth
 Receiver’s functionality simpler:
Aware of only one src, failover logic
handled between sources
 Receiver is smarter:
Is aware/configured with two feeds
(s1,g1), (s2,g2) / (*,g1), (*,g2)
Joins both and receives both feeds
 This approach requires the network
to have fast IGP and PIM
convergence
 This approach does not require fast
IGP and PIM convergence

Source Redundancy: Anycast/Prioritycast
Signaling
 Redundant sources (or NMS) announce
Source Address via RIPv2
 Per stream source announcement
 Routers redistribute (with policy)
into IGP
– Easily done from IP/TV middleware (UDP)
– No protocol machinery required—only
periodic announce packets
– Small periodicity for fast failure detection
– All routers support RIPv2 (not deployed as IGP):
 Allows secure constrained configuration on routers
70
Src
RIP (v2)
Report (UDP)
Router

Source Redundancy - Anycast/Prioritycast
 Policies
– Anycast: Clients connect to the closest
instance of redundant IP address
– Prioritycast: Clients connect to the highest-priority instance
of the redundant IP address
 Also used in other places
– e.g. PIM-SM and Bidir-PIM RP redundancy
 Policy simply determined by routing announcement and
routing config
– Anycast well understood
– Prioritycast: Engineer metrics of announcements or
use different
prefix length
71
Secondary
10.2.3.4/32
Rcvr 2Rcvr 1
Primary
10.2.3.4/31
Example: Prioritycast with
Prefixlength Announcement

Anycast / Prioritycast Benefits
 Sub-second failover possible
 Represent program channel as single (S,G)
– SSM: single tree, no signaling; ASM: no RPT/SPT
 Move instances “freely” around the network
– Most simply within IGP area
– Regional to national encoder failover options (BGP based)
 No proprietary source sync protocol required
 Per program failover
– Use different source address per program
72

Multicast Fast Convergence
 IP multicast
– Failures/changes corrected by re-converging trees
– Re-convergence time is sum of:
 Failure detection time + Unicast routing re-convergence time
 ~ #Multicast-trees x PIM re-convergence time
– “Typical” reconvergence times:
 ~ 200 msec initial tree rebuild (500 - 4000 trees convergence/sec for subsequent
trees)
 Same behavior with PIM and mLDP
 Do not require RSVP-TE for general purpose multicast deployments
 Sub 50 msec FRR possible for PIM or mLDP
– Make-before-break during convergence
– Use of link-protection tunnels
73

Multicast Only Fast ReRoute - MoFRR
 Make-before-Break solution
 Multicast routing doesn’t have to wait for unicast
routing to converge
 An alternative to source redundancy, but:
– Don’t have to provision sources
– Don’t have to sync data streams
– No duplicate data to multicast receivers
 No repair tunnels
 No new setup protocols
 No forwarding/hardware changes
 http://tools.ietf.org/html/draft-karan-mofrr-00
74

MoFRR - Concept Example
75
S
R
B
Join
Path
Data Path
Alt
Path
Alt Data Path
Wasted Bandwidth
Wasted Bandwidth
R
Not
1. D has ECMP path {BA, CA} to S
2. D sends join on RPF path through C
3. D can send alternate-join on BA path
4. A has 2 oifs leading to a single receiver
5. When RPF path is up, duplicates come to D
6. But D RPF fails on packets from B
7. If upstream of D there are
receivers, bandwidth is only
wasted from that point to D
8. When C fails or DC link fails, D makes
local decision to accept packets from B
9. Eventually unicast routing says B is new
RPF path
rpf Path (RPF Join)
Alt Join (Sent on Non-rpf)
Data Path
Interface in oif-list
Link Down or RPF-Failed Packet Drop
DD
AA
BB CC

LineCard
LineCard
LineCard
LineCard
ACTIVE
STANDBY
Failure
ACTIVE
Periodic PIM Joins
GENID PIM Hello
Triggered PIM Joins
Multicast HA for SSM: Triggered PIM Join(s)
 Active Route Processor receives periodic PIM Joins in
steady-state
 Active Route Processor fails
 Standby Route Processor takes over
 PIM Hello with GENID is sent out
 Triggers adjacent PIM neighbors to resend PIM Joins
refreshing state of distribution tree(s) preventing them
from timing out
76
How Triggered PIM Join(s) Work When Active Route Processor Fails:

Automatic IP Multicast Tunneling
 Automatic IP Multicast Tunneling:
–http://tools.ietf.org/id/draft-ietf-mboned-auto-multicast
 Designed to provide a migration path to a fully multicast enabled backbone
 Allows multicast to reach unicast-only receivers without the need for any
explicit tunneling
 Provide benefits of multicast wherever multicast is already deployed
–Hybrid solution
–Multicast networks get the benefit of multicast
 Works seamlessly with existing applications
–Requires only client-side shim (somewhere in client) and router support (in some
places)
Supports IPv4, IPv6, IPv4 mcast over IPv6, IPv6 mcast over IPv4
77

Elements Required for Deploying AMT
 AMT requires Multicast
 AMT requires Source Specific Multicast
 AMT Gateway
–Sits in the end device, home network
 AMT Relay
– Site in the Service Provider network
AMT architecture
78
AMT Relay
AMT Gateway

AMT Components
• Gateway
• Initiates connection to multicast network via AMT Discovery message
• Discovery message sent to “well known” Anycast address
• May be a host (PC, Mac, Xbox, Android, ConnectedTV, iPad, …)
Running as a Java applet on host or embedded in an application
• Or part of home or enterprise gateway/router with LAN multicast enabled
• Relay
• Listens for AMT Discovery messages to build AMT tunnel to requesting gateways
• May be on a router at the unicast/multicast boundary or in an appliance near the
boundary
• Part of the Service Provider infrastructure
79

80
Mcast-Enabled ISP
Unicast-Only Network
Content Owner
Mcast-Enabled Local Provider
Multicast Traffic
Unicast Stream
Enables Multicast Content
to a Large (Global)
Audience
Creates an Expanding Radius
of Incentive to Deploy Multicast
AMT Relay
AMT Gateway

81
 AMT deployment scenario
Mcast-Enabled ISP Content Owner
Enables Multicast Content
to a Large (Global)
Audience
Creates an Expanding Radius
of Incentive to Deploy Multicast
AMT Relay
AMT Gateway
Multicast Traffic
Unicast Stream

Live-Live
 Live-Live—Spatial Separation
– Two separate paths through network; can engineer manually
(or with RSVP-TE P2MP )
– Use of two topologies (MTR)
– “Naturally” diverse/split networks work well (SP cores,
likely access networks too), especially with ECMP
– Target to provide “zero loss” by merging copies based
on sequence number
 Live-Live—Temporal Separation
– In application device—delay one copy—need to know
maximum network outage
82

Cable Industry Example
 Path separation does not necessarily mean separate parts of network!
– Carrying copies counterclockwise in rings allows single ring redundancy
to provide live-live guarantee; less expensive network
 Target in cable industry (previously used non-IP SONET rings!)
– IP live-live not necessarily end-to-end (STB), but towards Edge-QAM (RH*)—
merging traffic for non-IP delivery over digital cable
– With path separation in IP network and per-packet merge in those devices
solution can target zero packet loss instead of just sub 50msec
83
STBs
STBs
HFC1
HFC2RH1b
RH1b
RH1a

cFRR - PIM/mLDP Break Before Make
84
RPF change on C from A to C:
1.Receive RPF change from IGP
2.Send prunes to A
3.Change RPF to B
4.Send joins to B
Same methodology, different terminology in mLDP
‒ RPF == ingres label binding
Some more details (not discussed)
A B
S(ource)
Cost: 10
C
Cost: 12
R(eceiver)

cFRR -PIM/mLDP Make Before Break
1. Receive RPF change from unicast
2. Send joins to A
3. Wait for right time to go to 4.
– Until upstream is forwarding traffic
4. Change RPF to A
5. Send prunes to B
Should only do Make-before-Break when old path
(B) is known to still forward traffic after 1.
– Path via B failed but protected
– Path to A better, recovered
– Not: path via B fails, unprotected
 Make before Break could cause more
interruption than Break before Make !
85
A B
S(ource)
Cost: 10
C
Cost: 12
R(eceiver)

Multipath for IP Multicast
 In unicast, multipath selection
happens during packet forwarding
 In multicast, multipath selection
happens during RPF-selection
for PIM join!
– Multipath selection happening
whenever route from RPF-lookup
has more than one path (like from
IGP equal cost multipath)
– Also needs to be enabled
86
Source
(S)
Receiver (D)
IP Packet
R1
R2 R3
?
PIM Join
e.g. (S,G)
RPF Selection

Cisco IOS IPv4 Per (S,G)
Improvements for ECMP
87
 Added two per (S,G) ECMP alternatives to IPv4 IP multicast
‒ ip multicast multipath [ s-g-hash [ basic | next-hop-based]]
 Basic: polarizing/predictable—but per (S,G):
‒ (S XOR G % Nlinks)
 Next-hop-based: stable/non-polarizing
‒ Hash(S,G, Nbr-i) = bsr_hash(bsr_hash(S,G), Nbr-i ))
‒ Select Nbr-i | max({ Hash(S,G,Nbr-i) | NBr-i })
‒ Nbr-i is the IP address of the next-hop of a path; Bsr_hash is the
hash function also used in the BSR protocol in PIM (creates random number out of its two parameters)
‒ Algorithm select the one neighbor for which the Hash(S,G,Nbr-i)
is highest

Next-Hop Load-Split Algorithm
 Needed to have non-polarizing
algorithm and non-assert-causing!
– Router-local hash to cause non-polarization
would cause assert issue!
 Also would like stability under
re-convergence:
– Re-convergence causes interruption! More in
multicast than unicast; when loosing/adding
an ECMP path, traffic on unaffected paths
should not need to re-converge!
– Polarizing algorithm is not-stable: change in
number of ECMP path changes “modulo” of
algorithm, reshuffling large percentage of
flows unnecessarily!
 Hash algorithm taken from BSR/RFC,
better than XOR for this purpose
88
R4
R1 R2 R3
If Link to R1 fails, R4
Re-Converges Both Red Trees
toward R2 and R3 without
Affecting the Orange and Blue
Trees that Already Used those
Two Next Hops

Background on Video and Wi-Fi Multicast
90
 Streaming video requirements
• Video codecs such as MPEG-2 are intolerant of packet loss
• Loss of one packet impacts multiple video frames
• Since many frames are “incremental”
• MPEG-2 requires a PLR of < 0.5%
 Native Wi-Fi multicast is not a reliable service
• Wi-Fi => Packet Error Rate 1 - 2%
• Corrected by ACKs for unicast
• For multicast there are no ACKs

MAC Layer Enhancement: MC2UC
91
Multicast
source
Wired
network
Multicast
converted to
unicast
WLC
 Application:
‒ Broadcast video over Wi-Fi at Hotspots
 Issue:
‒ Broadcast video is multicast on IP network
‒ But multicast over Wi-Fi is not reliable
‒ Leads to poor video quality
 Multicast to Unicast Solution:
‒ Snoop IGMP request for video
‒ Convert video to unicast on Wi-Fi last hop
‒ Transparent to the client

Video Stream Multicast Delivery Solution
92
1
2
5.5
6
9
11
12
18
24
36
48
54
M0
M1
...
M14
M15
802.11
Data Rates
B/G
N
Video
Server
AP 1140
• IGMP state monitored for each client. Only send
video to clients requesting
• Multicast packets replicated at AP and sent to
individual clients at their data-rate
• Resource Reservation Control (RRC) used to prevent
channel oversubscription. Works in conjunction with
Voice CAC
• Stream Prioritization ensures important videos take
precedence over others
• SAP/SNMP error message created when Channel
Subscription violated
Technical Solution
Smooth, Reliable Video
• Video delivered reliably at
802.11n data rates
• Quality of Video protected in
varying channel load conditions
• Prevents video flooding
• Prioritizes Business Video over
other video
Video Impact
Default 802.11B/G
mandatory data rates
Intelligence
in the AP
QoS Marked
on CAPWAP
From WLC

Video Stream Delivery Solution
93
Stream Prioritization • Identify specific Video Streams for preferential
QoS treatment
Resource Reservation Control
(RRC)
• Quality of Video Enforcement by denying client
when channel busy
• Video Bandwidth protection to prevent video from
consuming Wi-Fi channel
Multicast Direct • Sends multicast video stream as unicast directly
to client
• Video QoS promotion
• Enables use of 11n data rates and standards
packet error correction
Monitoring • Client alert for insufficient bandwidth
• SNMP trap for QoS/bandwidth problem
Roaming Support (existing)
• Roaming with pre-built multicast flows
• Proxy IGMP join (cross controller roam)
IGMP snooping (existing)
• Prevents video flooding
Feature Overview

© 2014 Cisco and/or its affiliates. All rights reserved.BRKIPM-2008 Cisco Public 94
Network Layer Enhancement
 Improved multicast performance over wireless networks
 Multicast packet replication occurs only at points in the network
where it is required, saving wired network bandwidth
One Multicast Packet In
CAPWAP Tunnels
One Multicast Packet In
CAPWAP
Multicast Group
One CAPWAP Multicast
Packet Out
Three CAPWAP Unicast
Packets Out
Unicast Mechanism
Multicast Mechanism
Network Replicates
Packet as Needed

Multicast Mode Selection
95
 Multicast mode and multicast group configured on WLC general interface

Agenda
96
 Multicast Market Overview
 PIM Configuration notes
 Interconnecting PIM domains
 Label Switched Multicast
 High Availability
 Multicast in 802.11

Questions?
97

Call to Action…
Visit the World of Solutions:-
 Cisco Campus
 Walk-in Labs
 Technical Solutions Clinics
 Meet the Engineer
 Lunch Time Table Topics, held in the main Catering Hall
 Recommended Reading: For reading material and further resources for this
session, please visit www.pearson-books.com/CLMilan2014
98

 Complete your online session
evaluation
 Complete four session evaluations
and the overall conference evaluation
to receive your Cisco Live T-shirt
Complete Your Online Session Evaluation
99

Final Thoughts
 Get hands-on experience with the Walk-in Labs located in World of Solutions,
booth 1042
 Come see demos of many key solutions and products in the main Cisco booth
2924
 Visit www.ciscoLive365.com after the event for updated PDFs, on-demand
session videos, networking, and more!
 Follow Cisco Live! using social media:
– Facebook: https://www.facebook.com/ciscoliveus
– Twitter: https://twitter.com/#!/CiscoLive
– LinkedIn Group: http://linkd.in/CiscoLI
100

Advanced Topics in IP Multicast Deployment

Advanced Topics in IP Multicast Deployment

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Advanced Topics in IP Multicast Deployment

Similar to Advanced Topics in IP Multicast Deployment (20)

Recently uploaded

Recently uploaded (20)

Advanced Topics in IP Multicast Deployment