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 Overview


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

PIM Configuration Notes


Multicast Application Types

9

Multicast Applications

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

http://www.ietf.org/rfc/rfc3170.txt


The Multicast “Application Spectrum”

10

Many-to-Many | Few applications One-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

RP2

10.1.1.1

FHR FHR 10.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

S P 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

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 B Vif 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 subnet

Gig0/0

Interconnecting PIM Domains - Static and Dynamic Models


Interconnecting PIM Domains

• 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

Destination Source

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

Destination Source

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

Destination Source

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

This Method Will Not Work with Future Versions of IOS


Edge Router Proxy Registers to RP

39

Source Network

Customer

224.0.2.64

Destination Source

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

Destination Source

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

Destination Source

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

Destination Source

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

Every router in customer network 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

Destination Source

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

http://www.cisco.com/go/financial



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

VP

LS

Native

IPv4

mV

PN

IPv4

Native

IPv6

MLDP Control Plane

C-Multicast Signalling

Forwarding Plane

BGP / PIM / PORT / Static

Clients

m6

PE

m6

VP

E

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 PE Sender/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 Multicast Applications

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

High Availability


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 2 Rcvr 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

D D

A A

B B C C


Lin

e C

ard

Lin

e C

ard

Lin

e C

ard

Lin

e C

ard

AC

TIV

E

STA

ND

BY

Failure

AC

TIV

E

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

http://tools.ietf.org/id/draft-ietf-mboned-auto-multicast










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

HFC2 RH1b

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

Multicast in 802.11


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


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

http://www.pearson-books.com/CLMilan2014




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

http://www.ciscolive365.com/

https://www.facebook.com/ciscoliveus

https://twitter.com/

http://linkd.in/CiscoLI

Technology

Advanced Topics in IP Multicast Deployment