Advanced Topics in IP Multicast...

BRKIPM-2008

Advanced Topics in IP Multicast Deployment

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKIPM-2008 2

Agenda

Market Overview

PIM Configuration notes

Market Data Topologies

High Availability

Admission Control

Channel Changing

Receiver Tracking

Multicast in 802.11


Market Overview


Multicast Solutions

Finance (Trading, Market Data, Financial SP)

Tibco, Hoot-n-Holler, Data Systems

Enterprise Video and collaborative environments

Cisco TelePresence®, DMS, MP/WebEx Video Conferencing, Video Surveillance

Broadband (Entertainment)

Includes Cable, DSL, ETTH, LRE, Wireless

Broadcast TV / IP/TV, VOD, Connected Home

Service Provider (Transit Services)

Native v4 and v6

Label Switched Multicast (LSM)

Multicast VPNs (IP and MPLS-based)


Multicast for IP/TV Delivery

Multicast

1. Efficiently Controls network traffic

2. Reduces server and CPU loads

3. Eliminates traffic redundancy

4. Makes Multipoint applications possible

Multicast Benefits

Increase Productivity and Save Cost

Generate New Revenue Stream

0

2

4

6

8

Ne

two

rk T

raff

ic

1 20 40 60 80 100# Clients

Multicast

Unicast

Distribute Information to Large Audiences

over an IP Network


Market Data Architectural ComponentsService

Distribution

Network

Stock Exchange

Data CenterTraders

Financial Service

Providers

A Feed

B Feed

Location A

Location B

Brokerage

Data Center


Mobile

Access anywhere

Seamless

Secure

Similar look and feel

Ease of use

Mobility Vision

Coffee Shop

Hotel

Plane Airport LoungeCar Train

Train Station

Customer

Intelligent Mobile Device

Web AppsTelepresence

eLearning &

Communication

Access

Footprint

Streaming

Media

Video

SurveillanceCommunication and Collaboration

http://www.sphynx.de/assets/images/747-2.jpg


PIM Configuration Notes


PIM Modes

Bidirectional PIM (PIM-Bidir)

Supports only Shared Trees

Sparse Mode (PIM-SM) (ASM)

Original (Classic)

Supports both Shared and Source Trees

Source Specific Multicast (PIM-SSM)

aka Single Source Multicast

Supports only Source Trees

No need for RPs, RP Failover, etc.


PIM Mode Selection Criteria

Use SSM

For One-to-Many applications

Eliminates need for RP Engineering

Greatly simplifies network

Data and Control Planes are decoupled

Use Bidir

For Many-to-Many | Few applications

Drastically reduces total (S,G) state in network

Data and Control Planes are decoupled

Use PIM-SM

For all other general purpose applications

SSM/BiDir and SM can all coexist in the same network at the same time and applications can be moved gracefully (groupwise) between modes


Intermittent Source Applications

Definition:

Applications with sources that temporarily stop sending for > 3 minutes

Impact:

(S,G) state times out within the network

Initial packets often lost during SPT switchover


Solutions to Intermittent Sources

PIM-Bidir or PIM-SSM

No data driven events

Periodic keepalives or heartbeats

S,G Expiry timer

Needs to be set on every router

Typically set to maintain state throughout entire trading day

ip pim sparse sg-expiry-timer <secs>

Available 12.2(18)SXE5, 12.2(18)SXF4, 12.2(35)SE


Static RPs

Hard-coded RP address

When used, must be configured on every router

All routers must have the same RP address (per group)

Anycast RP must be used for Redundancy

Configuration

ip pim rp-address <address> [group-list <acl>]

[override][bidir]

Optional group list specifies group range

Default: Range = 224.0.0.0/4

Override keyword ―overrides‖ Auto-RP information

Default: Auto-RP and BSR learned info takes precedence

Bidir keyword specifies this group range as PIM-Bidir


Why Use Auto-RP?

Auto-RP is a dynamic method for the network to learn RP to Group mapping information

This helps when:

RP address and group ranges change often

Your network has 100s or 1000s of routers and you want to simplify the config

There are several RPs for different applications

RPs maintained by different administrative groups


Auto-RP Configuration—Auto-RP Listener

Use global command (recommended)ip pim autorp listener

Added support for Auto-RP Environments

Modifies interface behavior:

Interface can be configured in SM

Interface always uses DM for ONLY Auto-RP groups

Only needed if Auto-RP is to be used

Available 12.3(4)T, 12.2(28)S, 12.1(13)E7

Use with interface command

ip pim sparse-mode Recommended

Prevents DM Flooding

No longer need:ip pim sparse-dense-mode


Dense Mode Fallback

Caused by loss of local RP information (in older IOS® releases)

Entry in Group-to-RP mapping cache times out

Can happen when:

All C-RPs fail

Auto-RP/BSR mechanism fails

Possibly a result of network congestion

Group is switched over to Dense mode

(*,G) mroute entry changes to Dense mode

Flags of (S,G) entries change from JT to T

(S,G) PIM Joins are no longer sent

State times out on upstream router—traffic flow stops

All existing PIM-SM SPTs are dropped!

Dense mode flooding begins if interfaces configured with:

ip pim sparse-dense-mode


Avoiding DM Fallback in Auto-RP/BSR

Use RP-of-last-resort

Assign local Loopback as RP-of-last-resort on each router

Example

ip pim rp-address <local_loopback> 10

access-list 10 deny 224.0.1.39

access-list 10 deny 224.0.1.40

access-list 10 permit any

Needed Prior to IOS 12.3(4)T, 12.2(33)SXH


Avoiding DM Fallback Automatically

New 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

Behavior is enabled by default if all interfaces are in sparse mode

Available 12.3(4)T, 12.2(33)SXH


Auto-RP Summary

Use Auto-RP Listener with Sparse Mode interfaces

With newer code you automatically get No Dense Mode Fallback

With older code that doesn‘t have:


Use RP of Last Resort to prevent loss of active S,G entries in case of RP failure

With ancient code that doesn‘t have AutoRPListener

Use sparse-dense interfaces

Use RP of Last Resort

Or Upgrade ;-)


Anycast RP Overview

MSDP

RecRec RecRec

Src Src

SA SAA

RP1

10.1.1.1B

RP2

10.1.1.1

X


Anycast RP Overview

RecRec RecRec

SrcSrc

A

RP1

10.1.1.1B

RP2

10.1.1.1

X


Anycast RP Configuration

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

!



MSDPB

RP2

A

RP1

C D

ip pim rp-address 10.0.0.1 ip pim rp-address 10.0.0.1


Combining Auto-RP and Anycast-RP

Provides advantages of both methods

Rapid RP failover of Anycast RP

No DM Fallback

Configuration flexibility of Auto-RP

Ability to effectively disable undesired groups

Anycast RP and Auto-RP May Be Combined


Anycast RP with Auto-RP Configuration


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 msdp peer 10.0.0.3 connect-source loopback

1



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

!



MSDPB

RP2

A

RP1

ip multicast-routing

ip pim autorp-listener


C


ip pim autorp-listener


D


Bidir PIM—Phantom RP

Question: Does a Bidir RP even have to physically exist?

Answer: No. It can just be a phantom address.

RP

Receiver 2

E1 (DF) E1 (DF) E1 (DF) E1 (DF)

E1 (DF) E1 (DF)

E0 (DF)

C

E0 E0 E0 E0

E0 E0

Source Receiver 1

F

D

E

A B



!

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

Phantom RP on Point-to-Point Core

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


Phantom RP with Auto-RP

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 Loopback1

Available 12.4(7)T, 12.2(18)SXF4


Market Data Topologies


Brokerage

Content

ProviderContent

ProviderContent

Provider

Financial

Service

Provider

Brokerage Brokerage

Market Data Distribution—Interface

Static Forwarding

Static Service Levels—Cable Model

Dynamic Forwarding

Hybrid Design


Traditional MD Interface Requirements

Customers and Providers Prefer Lowest Common Denominator—Least Coordination

Providers are under contract to deliver stream

Each side wants to limit organizational liability and coordination—KISS

Ideal Scenario: Provider and Customer have separate multicast domains

Therefore:

Traffic is statically nailed up

No PIM Neighbors

No DR on edge

No PIM Joins

No shared RP

No MSDP


Market Data

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


MD Distribution—Virtual RP

MD 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


Market Data

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



MD Distribution—Edge Router Is RP


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


Market Data

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



MD Distribution—Edge Router Is RP


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


Market Data

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


MD Distribution—Edge Router Proxy Registers to RP


Customer Edge router has dense-mode on IIF and proxy registers to RP

RP is configured inside customer network


Market Data

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

interface Loopback1

ip address 10.1.3.2 255.255.255.255


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

interface Loopback1

ip address 10.1.3.1 255.255.255.255




MD Distribution—Edge Router Is RP and MSDP Peer

Customer Edge router is RP and MSDP peer of main customer RP


Market Data

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

interface Loopback1

ip address 10.1.3.2 255.255.255.255




RP

interface Loopback0

ip address 10.1.1.1 255.255.255.255

interface Loopback1

ip address 10.1.3.1 255.255.255.255




MD Distribution—Edge Router Is RP and MSDP Peer

Customer Edge router is RP and MSDP peer of main customer RP

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

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 for Market Data 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

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 is free to use any forwarding model, e.g. PIM-SM, PIM-SSM, PIM-Bidir

Each is responsible for their portion of the delivery model—clear demarcation

Simple, straight-forward

Has traditionally been first choice for FSP

Main Disadvantage

Customer is not able to control subscriptions and bandwidth usage of last mile dynamically

As data rates climb this is more of a issue


Dynamic Forwarding

Rising data rates and 24 hour trading are driving 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


Dynamic Service—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

Need Better Solution

ip igmp join-group <group> passive —under consideration

IGMP report will be sent but traffic will not be punted to CPU

IGMP host code on router will respond to queries

L flag will not be set?


Market Data

Source Network

Customer

224.0.31.20

DestinationSource

10.2.2.2

e0

e1

IGMP

IGMP

PIM

MD Distribution—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


Market Data

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

e0loopback1

PIM

10.4.4.0/24

MD Distribution—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


Market Data

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

e0loopback1

PIM

10.4.4.0/24

MD Distribution—igmp mroute-proxy detail

4. The first PIM *,G Join on e0 triggers an unsolicited IGMP report to be generated on the loopback1 interface

3. PIM *,G Join message is received on e0 interface and mroute state is created; the igmp mroute-proxy command on interface causes special internal flag to be added to mroute

2. PIM *,G Join message filters up towards virtual RP

1. Host sends IGMP report and creates mroute state


Market Data

Source Network

e0

IGMP

IGMPe1

Customer

e0loopback1

PIM

10.4.4.0/24

MD Distribution—igmp mroute-proxy detail

6. When the periodic IGMP query is run on loopback1 the igmp proxy-service command initiates a walk through the mroutetable looking for the mroute-proxy flag; an IGMP report is generated for each mroutewith the mroute-proxy flag set

As long as the mroute is kept alive with PIM joins the IGMP reports will be forwarded

5. The igmp helper command directs the IGMP report out the e1 interface

IGMP reports are dynamic—they are only sent when there is interest in the customer domain; however, the edge router does not respond to queries from provider router

Consideration:Seven times more IGMP messages than needed

Complex config


Dynamic Service—Dynamic Subscriptions with IGMP

Better Solution: IGMP Host Proxy

Global command:

ip igmp host-proxy <group acl>

Functionality:

1. When mroute state is created for any group defined by <acl>

The mroute-proxy flag will be set

An IGMP report is generated for the mroute and set out the IIF of the mroute

2. When an IGMP Query is received for a group defined by <acl>

If mroute state exists, generate IGMP report

3. When a PIM Prune is received for a group defined by <acl>

An IGMP leave message is generated

4. All modes of PIM should be supported—PIM-SM, PIM-Bidir and PIM-SSM; the groups must be defined on the router and the behavior will work appropriately—this solution should be compliant with RFC4605

Coming

Soon


Market Data

Source Network

Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1

RP

RP

RP

MD Distribution—Other Options

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


Dynamic Forwarding—S,G PIM Joins

Works in situations that are 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


Market Data Design Whitepapers

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


High Availability


IP/TV Deployments Today

Two schools of thought in deployments today:

I think I need 50ms convergence

IPMulticast is fast enough

IP Multicast is UDP

The only acceptable loss is 0ms

How much is ―reasonable‖?

50ms ―requirement‖ is not a video requirement

Legacy telco voice requirement

Efforts for 50ms only cover a limited portion network events

Where to put the effort?

Make IPMulticast better?

Improve the transport?

Add layers of network complexity to improve core convergence?


Application Side Resiliency

FEC: Forward Error Correction

Compensate for statistical packet loss

Use existing FEC, e.g. for MPEG transport to overcome N msec (>= 50 msec) failures?

Cover loss of N[t] introduces delay > N[t]!

Retransmissions

Done e.g. with vendor IP/TV solutions—unicast retransmissions

Candidate large bursts of retransmissions!

Limit #retransmissions necessary

Multicast retransmissions (e.g. PGM ?)

No broadcast IP/TV solutions use this


Impact of Packet Loss on MPEG Stream

Compressed Digitized Video is sent as I, B, P Frames

I-frames: Contain full picture information

Transmit I frames approximately every 15 frames (GOP interval)

P-frames: Predicted from past I or P frames

B-frames: Use past and future I or P frames

I B B P B B P B B P B BI B B P B B P B B P B B

I-Frame Loss “Corrupts” P/B Frames for the Entire GOP


Service Availability Overview

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 Cisco IOS/IGP configuration used to inject these source server routes into the main IGP being used (OSPF/ISIS)

Dual Transmission with Path separation


Video Source Redundancy: Two Approaches

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

Src

RIP (v2)

Report (UDP)

Router


Anycast-Based Load Balancing

1.1.1.1 1.1.1.1

IGMP Report IGMP Report

I Will Send Join

to the Nearest

1.1.1.1/32

I Will Send Join

to the Nearest

1.1.1.1/32

PIM Join PIM Join

Service Router 2Service Router 1

Agg RouterAgg Router

STB STB

Source 2Source 2


Encoder Failover Using Anycast

1.1.1.1 1.1.1.1

Service Router 2Service Router 1

Agg RouterAgg Router

STB STB

Source 2Source 2

IGP Recalc >>

PIM Join

X


Source RedundancyAnycast/Prioritycast Policies

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

Src B

Secondary

10.2.3.4/32

Rcvr 2Rcvr 1

Src A

Primary

10.2.3.4/31

Example: Prioritycast with

Prefixlength Announcement


Source RedundancyAnycast/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 (BGP…)?

No vendor proprietary source sync proto required

Per program, not only per-source-device failover

Use different source address per program


FRR for Native IP Multicast/mLDP

Do not require RSVP-TE for general purpose multicast deployments

Sub 50 msec FRR possible to implement for PIM or mLDP

Make-before-break during convergence

Use of link-protection tunnels

Initial: one-hop RSVP-TE P2P tunnels

Future: NotVia IPFRR tunnels (no TE needed then)


Multicast only Fast ReRoute - MoFRR

It is make-before-break solution

Multicast routing doesn‘t have to wait for unicastrouting 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









MoFRR - Concept Example

S

R

BJoin

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


Multicast Fast Convergence

IP multicast

All failures/topology changes are corrected byre-converging the trees

Re-convergence time is sum of:

Failure detection time (only for failure cases)

Unicast routing re-convergence time

~ #Multicast-trees x PIM re-convergence time

Possible

~ minimum of 200 msec initial

~ 500 ... 4000 trees convergence/sec (perf)

Same behavior with mLDP


Multicast Node Protectionwith p2p Backup Tunnels

If router with fan-out of N fails, N-times as much backup bandwidth as otherwise is needed

Provisioning issue depending on topology!

Some ideas to use multipoint backup to resolve this, but…

Recommendation? Rely on Node HA instead!!

S(ource)Rcvr1

R1 R2 R3

R4 R5 R6

Rcvr2


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

How Triggered PIM Join(s)

Work When Active Route

Processor Fails:


Multi-Topology (MT)-Technologyand IP Multicast

… When not all traffic should flow on the same paths

Interdomain: Incongruent routing

BGP SAFI2 (MBGP)

Intradomain: Incongruent routing workarounds

Static mroutes

Multiple IGP processes (tricky)

Do Not Use: DVMRP—in process of being removed from Cisco IOS

Intradomain: Multi-Topology-Routing

Multicast and Unicast solution in Cisco IOS (c7600); multiple topologies for unicast, one additional for multicast (today)

Intradomain: MT-technology for multicast

Subset of MTR: Only the routing component, sufficient for incongruent routing for IP multicast; currently: MT-ISIS in Cisco IOS-XR for IP multicast


Auto Multicast without explicit Tunnels

Tunnel through non-multicast enabled network segment

draft-ietf-mboned-auto-multicast-09

GRE or UDP encap

Relay uses well known ‗anycast‘ address

Difference to IPSec, L2TPv3, MobileIP, …

Simple and targeted to problem

Consideration for NAT (UDP)

Ease implemented in applications (PC/STB) (UDP)

Variety of target deployment cases

Relay in HAG—provide native multicast in home

Gateway in core-SP—non-multicast Access-SP

Access-SP to Home—non-multicast DSL

In-Home only—e.g. multicast WLAN issues

Non

multicast

Multicast

Capable

AMT Gateway

AMT Relay

AMT Tunnel

Non-

Multicast

HAGNAT


Video Topology

Multicast Topology

Voice Topology

Cisco IOS IPv4 Multi-Topology Routing (MTR)

Define traffic-class specific topologies across a contiguous subsection of the network

Individual links can belong to multiple topologies

Base Topology

Start with a Base Topology

Includes All Routers and All Links

Full Solution with Both MT-Technology Routing and Forwarding


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


What Is Live-live (with Path Diversity)?

Why bother?

Only resiliency solution in the network that that can be driven to provide zero packet loss under any single failure in the network—without introducing more than path propagation delay (latency)!

Much more interesting for multicast than unicast

Individual unicast packet flow typically for just one receiver

Individual multicast flow (superbowl) for N(large) receivers!

Path diversity in the network

Lots of alternatives: VRF-lite, routing tricks, RSVP-TE, L2 VLAN

Multi-topology routing considered most simple/flexible approach!

Standard solution in finance market data networks

Legacy: Path diversity through use of two networks!


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

STBs

STBs

HFC1

HFC2RH1b

RH1b

RH1a


cFRRPIM/mLDP Break before Make

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)


cFRRPIM/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 !

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

Source

(S)

Receiver (D)

IP Packet

R1

R2 R3

?

PIM Join

e.g. (S,G)

RPF Selection


Cisco IOS IPv4 Multipath (1)

Classic Cisco IOS IPv4 multicast: ~ Cisco IOS 11.0 (or earlier)

ip multicast multipath

Disabled by default: RPF-selection selects the highest IP address PIM neighbor amongst the nexthop of the available (equal cost) paths

RFC-2362 compliant (old PIM-SM RFC); new PIM-SM RFC-4601 does not specify multipath behavior anymore

If enabled: per-source (and per-RP for (*,G)) multipath:

multipath_classic(A.B.C.D, Npaths) = (A ^ B ^ C ^ D) % Npaths

A.B.C.D is the IP address of the source or RP

Npaths is the number of paths available

Result is the path to choose 0..(Npaths-1)


Cisco IOS IPv4 Multipath (2)

Need to enable consistently on all (downstream) routers in LANs to avoid inconsistent RPF-selection on LAN

Inconsistent selection would cause asserts on LANs, resulting in some duplicate/delayed packets!

Algorithm is polarizing

Can be good and bad

Algorithm does not include group-address:

Consider a single Video server is sending many video flows via SSM: (S,G1) … (S,G100); no load-splitting will happen because source is always the same


Cisco IOS IPv4 Per (S,G) Improvements for ECMP

Added two per (S,G) ECMP alternatives to IPv4 IP multicastip 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-polarizingHash(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

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


Admission Control


Static vs. dynamic trees

1. ―Broadcast Video‖Dynamic IGMP forward up to DSLAM

DSL link can only carry required program!

static forwarding into DSLAM

Fear of join latency

History (ATM-DSLAM)

2. ―Switched Digital Video‖Allow oversubscription of PE-

AGG/DSLAM link

3. ―Real Multicast‖dynamic tree building full path

Source

Home

Gateway

DSLAM

PE-AGGSta

tic (

PIM

) tr

ee

(1)

Sta

tic (

PIM

) tr

ee

(2)

IGM

P jo

ins

PIM

jo

ins

(3)

IGM

P jo

ins

IGM

P jo

ins


Switched Digital VideoWhy oversubscription of access links makes sense

Switched Digital VideoConsider 500…1000 users on DSLAM

Consider 300 available TV programs

Monitor customer behavior – what is being watched ?Example (derived from actual MSO measurements)

Some 50 TV programs almost always watched (big channels)

Out of remaining 220 TV programs never than ¼ watched

Never need more bandwidth than ~ 125 channels!

Dynamic joining towards core ?Todays offered content << #users aggregated -> worst case traffic will always flow.

More a provisioning issue – and when content expands well beyond current cable-TV models


Admission control

Congestion must be avoided

Inelastic: TV traffic can not throttle upon congestion

One flow too many disturbs all flows

Need to do per TV-flow admission control

Router-links

Router local CLI solution

Strategic solution: RSVP

Already used for unicast VoD

Can only share bandwidth between unicast and multicast with RSVP

Broadband access (DSL link, Cable)

Issues with L2 equipment (eg: DSLAM)


3. Fair sharing of bandwidth

1GE

Multicast Call Admission Control

250-500 users

per DLAM

DSLAM

DSLAM

DSLAM

Example CAC use:

4. 250 Mbps for each CP

250 Mbps Internet/etc

1. Three CPs

10GE

Content

Provider 1

Content

Provider 2

Content

Provider 3

Content

Providers

Service

ProviderPaying

Customers

2. Different BW:

- MPEG2 SDTV: 4 Mbps

- MPEG2 HDTV: 18 Mbps

- MPEG4 SDTV: 1.6 Mbps

- MPEG4 HDTV: 6 Mbps

MPEG4 SDTV

MPEG2 SDTV

MPEG4 SDTVMPEG2 HDTV

MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


5. Simply add global costs

PE


Broadband link access, admission control

DSL

link

BRAS No IGMP snooping (replication) on DSLAM

PE-AGG access/admission control on PE-AGG link affects only single subscriber == equivalent to do access/admission control on DSL link.

Or BRAS (if traffic not native but via PPPoE tunnel

IGMP snooping on DSLAM

PE-AGG stopping multicast traffic on PE-AGG link will affect all subscriber. Only DSLAM can control DSL link multicast traffic

IP Multicast extensions to ANCP(Access Node Control Protocol)

Work in IETF

In IGMP snooping on DSLAM, before forwarding, request authorization from ANCP server.

Allow ANCP server to download access control list to DSLAM.

Similar model as defined in DOCSIS 3.0

CMTS controls CM

ANCP

PE-AGG

DSLAM

PE-AGG

link


Channel Changing


Join Latency

Static forwarding (to PE-AGG, or DSLAM) To avoid join latency

Sometimes other reasons too (policy, …)

Bogus ?Hop-by-hop Join latency (PIM/IGMP) very low, eg: individual < 100 msec …

Joins stop at first router/switch in tree that already forwards tree

Probability for joins to go beyond PE-AGG very low !If you zap to a channel and it takes ¼ sec more: You are the first guy watching this channel in a vicinity of eg: 50,000 people. Are you sure you want to watch this lame program ?

ImportantTotal channel zapping performance of system – Primetime TV full hour or (often synchronized) commercial breaks.

Join latency during bursts might be worse than on average. (DSLAM performance)


IGMPv2 leave latencyObsolete problem

Congesting issues due to IGMPv2 leave latency when only admission control mechanism is:

DSL link fits only N TV programs …and subscriber can only have N STB.

Example:

4Mbps DSL link, 3.5 Mbps MPEG2

Can only receive one TV channel at a time

Leave latency on channel change complex (triggers IGMP queries from router/DSLAM) and long (spec default: 2 seconds)

Resolved with IGMPv3/MLDv2

Ability for explicit tracking (vendor specific)

Can immediately stop forwarding upon leaves


Channel ChangingGOP size and channel changing

GOP size of N seconds causes channel change latency USER EXPERIENCE>= N seconds

Can not start decoding before next I-frame

Need/should-have channel change acceleration for GOP sizes > 0.5 sec ?

Many codec dependencies:

How much bandwidth is saved in different codecs by raising GOP size but keep the quality.


Video Quality Experience

Three functions (currently): Video Quality monitoring, FEC/ARQ support for DSL links, Fast Channel change

Uses standards RTP/RTCP, FEC extensions.

Fast channel channel by RTCP ―retransmission‖ triggered resend of missing GOP packets from VQE (cached on VQE).

STBHome

GatewayDSLAM

PE-AGG

Core Distribution

regional

Aggregation Home NetAccess

ASERVER VQE

multicast

Unicast/

(multicast)

control

VQE Client

library


Receiver Tracking


NewIGMP Explicit Tracking

Displays receiver IP address and interface for IGMPv2 hosts

Available on 6500 in 12.2(33)SXH

es1-7606-c3#show ip igmp snooping explicit-tracking vlan 301

Source/Group Interface Reporter Filter_mode

---------------------------------------------------------------------------

0.0.0.0/224.0.1.39 Vl301: 126.1.99.15 EXCLUDE

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/2 126.1.99.41 EXCLUDE







---------------------------------------------------------------------------

0.0.0.0/224.0.1.39 Vl301: 126.1.99.15 EXCLUDE

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/2 126.1.99.41 EXCLUDE

Host IP Addr







---------------------------------------------------------------------------

0.0.0.0/224.0.1.39 Vl301: 126.1.99.15 EXCLUDE

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/2 126.1.99.41 EXCLUDE

VLAN 301 Physical Int/Switchport


NewUser Subscriber Rates

Displays total traffic subscribed from one user

Combines information from:

show ip igmp snooping explicit-tracking vlan [vlan]

show ip mroute [group] active

Available on 6500 in 12.2(33)SXI

es1-7606-c3#show ip igmp snooping subscriber-rate 126.1.99.37

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.37 996 pps/366 kbps (1 sec)

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.37 996 pps/366 kbps (1 sec)

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.37 1000 pps/368 kbps (1 sec)

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.37 1000 pps/368 kbps (1 sec)

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.37 1000 pps/368 kbps (1 sec)

--------------------------

Total = 4992 pps/1836 kbps (1 sec)


Multicast in 802.11


I can‘t do my job without wireless. It has to work.

―‖

Wireless is best-effort. I can‘t support a level 1 SLA.

―‖

Pull Toward Business Mobility

IT Lacks RF Resources and ExpertiseVS

ContinuedGrowth and Reliance

on Wi-Fi Devices


Multicast in 802.11

Driven by applications: iTunes streaming, IP/TV, Vocera, WebEX, etc.

Challenges:

Variable data rate

Frames admit increased loss due to interferences, collisions

Data distribution delayed as APs buffer multicast

Multicast unreliability

Multicast packets (UDP) are sent as broadcast packets

Do not use error correction: ―fire and forget‖

Sent at highest supported mandatory data rate: 11 MB for B/G, 24 MB for A


Background on Video and WiFi Multicast

Streaming video requirements

•Many video codecs such as MPEG-2 are intolerant of packet loss

•Loss of one packet impacts multiple video frames

•Since many frames are ―incremental‖ from previous frames

ex., MPEG-2 requires a PLR of < 0.5% or serious impairments occur

Native WiFi multicast is not a reliable service

•In WiFi, it is normal to see a Packet Error Rate (PER) of 1 or 2%

•For unicast, this is normally corrected by the use of ACKs.

If no ACK received, then re-send

•But for multicast there are no ACKs

Packet Loss Rate (PLR) = PER = 1 or 2% (or higher)


Physical Layer Enhancements

Performance parity with 100 Mbps fast Ethernet

Improved reliability

Backward compatibility with A/B/G

Improved immunity to noise


MAC Layer Enhancement: MC2UC

Application:

Broadcast video over WiFi at Hotspots

Issue:

Broadcast video is multicast on IP network

But multicast over WiFi is not reliable

Leads to poor video quality

Multicast to Unicast Solution:

Snoop IGMP request for video

Convert video to unicast on WiFi last hop

Transparent to the client


MAC Layer Enhancement: MC2UC

Multicast source

Wirednetwork

Multicast converted to unicast

WLC


VideoStream Multicast Delivery Solution

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


VideoStream Delivery Solution

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 wifi 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


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 InCAPWAP Tunnels

One Multicast Packet InCAPWAP

Multicast Group

One CAPWAP Multicast

Packet Out

Three CAPWAP Unicast

Packets Out

Unicast Mechanism

Multicast Mechanism

Network Replicates

Packet as Needed


Multicast Mode Selection

Multicast mode and multicast group configured on WLC general interface


Questions ?


BRKIPM-2008 Recommended Reading


We value your feedback - don't forget to complete your online session evaluations after each session. Complete 4 session evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Networkers 20th Anniversary t-shirt.

All surveys can be found on our onsite portal and mobile website: www.ciscoliveeurope.com/connect/mobi/login.ww

You can also access our mobile site and complete your evaluation from your mobile phone:

1. Scan the Access Code(See http://tinyurl.com/qrmelist for software,

alternatively type in the access URL)

2. Login

3. Complete and Submit the evaluation

Please complete your Session Survey

http://www.ciscoliveeurope.com/connect/mobi/login.ww

http://tinyurl.com/qrmelist

Date post:	26-Jul-2020
Category:	Documents
Upload:	others
View:	12 times
Download:	0 times