0% found this document useful (0 votes)
17 views

Multi Cast

This document introduces IP multicast. It discusses the advantages of multicast over unicast such as more efficient use of network bandwidth and optimized delivery of data to multiple receivers. Common multicast applications are listed along with potential future applications that could utilize multicast. Key components of IP multicast including multicast protocols, sources, receivers and addressing are outlined at a high level. Challenges of multicast such as non-reliable delivery and potential for congestion are also noted.

Uploaded by

mario
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views

Multi Cast

This document introduces IP multicast. It discusses the advantages of multicast over unicast such as more efficient use of network bandwidth and optimized delivery of data to multiple receivers. Common multicast applications are listed along with potential future applications that could utilize multicast. Key components of IP multicast including multicast protocols, sources, receivers and addressing are outlined at a high level. Challenges of multicast such as non-reliable delivery and potential for congestion are also noted.

Uploaded by

mario
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 116

INTRODUCTION TO

IP MULTICAST

© 2004 Cisco Systems, Inc. All rights reserved. 1


Agenda

• Why Multicast?
• Multicast Fundamentals
• PIM Protocols
• RP choices
• Multicast at Layer 2
• Interdomain IP Multicast
• Latest Additions

© 2004 Cisco Systems, Inc. All rights reserved. 2


WHY MULTICAST?

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 3
Unicast vs. Multicast

Unicast
Server

Router

Multicast
Server

Router
© 2004 Cisco Systems, Inc. All rights reserved. 4
Multicast Advantages
• Enhanced Efficiency:
Efficiency Controls network traffic and reduces server and CPU
loads
• Optimized Performance:
Performance Eliminates traffic redundancy
• Distributed Applications:
Applications Makes multipoint applications possible

Example: Audio Streaming


Multicast All clients listening to the same 8 Kbps audio

Unicast
0.8
0.6
Traffic
0.4
Mbps
0.2
0
1 20 40 60 80 100
# Clients
© 2004 Cisco Systems, Inc. All rights reserved. 5
Multicast Applications

Today Tomorrow
• Finance Applications
• Broadband access
–Trading Stocks and Commodities
• Video conferencing
• Streaming Multimedia
–E-Learning • Digital TV
–Corporate communications
• Digital audio
• Enterprise Resource
Applications • Networked gaming
–Data warehousing and content • PDAs and Home
synchronization
appliances
• Any one-to-many data
push applications

© 2004 Cisco Systems, Inc. All rights reserved. 6


Multicast Disadvantages

Multicast Is UDP Based!!!


• Best Effort Delivery:
Delivery Drops are to be expected. Multicast applications
should not expect reliable delivery of data and should be designed accordingly.
Reliable Multicast is still an area for much research. Expect to see more
developments in this area.

• No Congestion Avoidance:
Avoidance Lack of TCP windowing and “slow-start”
mechanisms can result in network congestion. If possible, Multicast
applications should attempt to detect and avoid congestion conditions.

• Duplicates:
Duplicates Some multicast protocol mechanisms (e.g. Asserts, Registers
and SPT Transitions) result in the occasional generation of duplicate packets.
Multicast applications should be designed to expect occasional duplicate
packets.

• Out of Order Delivery : Some protocol mechanisms may also result in out
of order delivery of packets.

© 2004 Cisco Systems, Inc. All rights reserved. 7


MULTICAST FUNDAMENTALS

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 8
Multicast Components
Cisco End-to-End Architecture

ISP A
ISP B

MSDP
RP
Multicast Source
Multicast Source DR Y
X RP
ISP B

ISP A
IGMP Snooping, MBGP
CGMP, RGMP
DR

IGMP PIM-SM DR

Bidir PIM
PIM-SSM
MVPN
Campus Multicast Interdomain Multicast
• End Stations (hosts-to-routers): • Multicast routing across domains
– IGMP – MBGP
• Switches (Layer 2 Optimization): • Multicast Source Discovery
– CGMP, IGMP Snooping or RGMP – MSDP with PIM-SM
• Routers (Multicast Forwarding Protocol): • Source Specific Multicast
– PIM Sparse Mode or Bidirectional PIM – PIM-SSM

© 2004 Cisco Systems, Inc. All rights reserved. 9


IP Multicast Group Concept
Sender & Receiver
Group
Member 3

1. You MUST BE a Sender


“member” of a group
to receive it data
A B D “Non” Group
2. If you send to group
Member
address, all members
receive it
C E
3. You DO NOT have to be

a member of a group Group Group


to send to a group Member 1 Member 2
Receiver Receiver
© 2004 Cisco Systems, Inc. All rights reserved. 10
Multicast Addressing
IPv4 Header
Version IHL
e ve r b e
Type of Service Total Length

s ca n n s
d d r es A d dr es
e A up
Sourc G r o
Identification Flags Fragment Offset

lt ic a s t
D M u
Class
Time to Live Protocol Header Checksum

Source Source Address


1.0.0.0 - 223.255.255.255 (Class A, B, C)

Destination Destination Address


224.0.0.0 - 239.255.255.255 (Class D) Multicast Group Address Range

Options Padding

© 2004 Cisco Systems, Inc. All rights reserved. 11


Multicast Group Address Range

224.0.0.0 - 239.255.255.255 (Class D)

• Reserved Link-Local Addresses


– 224.0.0.0 – 224.0.0.255
– Transmitted with TTL = 1
– Examples:
• 224.0.0.1 All systems on this subnet
• 224.0.0.2 All routers on this subnet
• 224.0.0.5 OSPF routers
• 224.0.0.13 PIMv2 Routers
• 224.0.0.22 IGMPv3

• Other Reserved Addresses


– 224.0.1.0 – 224.0.1.255
– Not local in scope (Transmitted with TTL > 1)
– Examples:
• 224.0.1.1 NTP Network Time Protocol
• 224.0.1.32 Mtrace routers
• 224.0.1.78 Tibco Multicast1
© 2004 Cisco Systems, Inc. All rights reserved. 12
Multicast Addressing

• Administratively Scoped Addresses


– 239.0.0.0 – 239.255.255.255
– Private address space
• Similar to RFC1918 unicast addresses
• Not used for global Internet traffic
• Used to limit “scope” of multicast traffic
• Same addresses may be in use at different locations for different
multicast sessions
– Examples
• Site-local scope: 239.255.0.0/16
• Organization-local scope: 239.192.0.0/14

• SSM (Source Specific Multicast) Range


– 232.0.0.0 – 232.255.255.255
– Primarily targeted for Internet style Broadcast

© 2004 Cisco Systems, Inc. All rights reserved. 13


Multicast Addressing

IP Multicast MAC Address Mapping


(FDDI and Ethernet)
32 Bits

1110 28 Bits

239.255.0.1
5 Bits
Lost

01-00-5e-7f-00-01
25 Bits 23 Bits
48 Bits

© 2004 Cisco Systems, Inc. All rights reserved. 14


Multicast Addressing

IP Multicast MAC Address Mapping


(FDDI & Ethernet)
Be Aware of the 32:1 Address Overlap
32 - IP Multicast Addresses
224.1.1.1
224.129.1.1
225.1.1.1 1 - Multicast MAC Address
225.129.1.1 (FDDI and Ethernet)
.
. 0x0100.5E01.0101
.
238.1.1.1
238.129.1.1
239.1.1.1
239.129.1.1
© 2004 Cisco Systems, Inc. All rights reserved. 15
How are Multicast Addresses Assigned?

• Dynamic Address Assignment


– Session Directory Tool (SDR)
• Historically used to announce session/group information on a well-
known multicast group
• Has problems scaling
– Multicast Address Dynamic Client Allocation Protocol (MADCAP) -
RFC 2730
• Similar to DHCP
• Server and Client API shipped in W2K
• Applications need to support to support MADCAP
– Multicast Address Set-Claim (MASC) - RFC 2909
• Hierarchical, dynamic address allocation scheme
• Top of hierarchy is at an Internet exchange
• Children request addresses from parent
• Complex garbage-collection problem
• Not in use
© 2004 Cisco Systems, Inc. All rights reserved. 16
Madcap in MS Server

© 2004 Cisco Systems, Inc. All rights reserved. 17


How Are Multicast Addresses Assigned? (contd.)

• Static Global Group Address Assignment


– Temporary method to meet immediate needs
– Group range: 233.0.0.0 – 233.255.255.255
• Your AS number is inserted in middle two octets
• Remaining low-order octet used for group assignment
– Defined in RFC 2770
• “GLOP Addressing in 233/8”

• Manual Address Allocation by the Admin !!


– Is still the most common practice

© 2004 Cisco Systems, Inc. All rights reserved. 18


Host-Router Signaling: IGMP

• How hosts tell routers about group membership


• Routers solicit group membership from directly
connected hosts
• RFC 1112 specifies version 1 of IGMP
– Supported on Windows 95

• RFC 2236 specifies version 2 of IGMP


– Supported on latest service pack for Windows and most UNIX systems

• RFC 3376 specifies version 3 of IGMP


– Supported in Window XP and various UNIX systems

© 2004 Cisco Systems, Inc. All rights reserved. 19


Host-Router Signaling: IGMP

Joining a Group

H1 H2 224.1.1.1 H3

Report

• Host sends IGMP Report to join group

© 2004 Cisco Systems, Inc. All rights reserved. 20


Host-Router Signaling: IGMP

Maintaining a Group
224.1.1.1 H1 224.1.1.1 H2 224.1.1.1 H3

X X
Suppressed Report Suppressed

Query

• Router sends periodic Queries to 224.0.0.1


• One member per group per subnet reports
• Other members suppress reports
© 2004 Cisco Systems, Inc. All rights reserved. 21
Host-Router Signaling: IGMP

Leaving a Group (IGMPv1)


H1 H2 H3 #1

General Query

#2
• Host quietly leaves group
• Router sends 3 General Queries (60 secs apart)
• No IGMP Report for the group is received
• Group times out (Worst case delay ~= 3 minutes)
© 2004 Cisco Systems, Inc. All rights reserved. 22
Host-Router Signaling: IGMP

Leaving a Group (IGMPv2)


224.1.1.1
H1 H2 H3

Leave to
#1 224.0.0.2

Group Specific
Query to 224.1.1.1
#2
• Host sends Leave message to 224.0.0.2
• Router sends Group specific query to 224.1.1.1
• No IGMP Report is received within ~3 seconds
• Group 224.1.1.1 times out
© 2004 Cisco Systems, Inc. All rights reserved. 23
Host-Router Signaling: IGMPv3

• RFC 3376
– Adds Include/Exclude Source Lists
– Enables hosts to listen only to a specified
subset of the hosts sending to the group
– Requires new ‘IPMulticastListen’ API
• New IGMPv3 stack required in the O/S.

– Apps must be rewritten to use IGMPv3


Include/Exclude features

© 2004 Cisco Systems, Inc. All rights reserved. 24


Host-Router Signaling: IGMPv3

• New Membership Report address


– 224.0.0.22 (IGMPv3 Routers)
• All IGMPv3 Hosts send reports to this address
– Instead of the target group address as in IGMPv1/v2
• All IGMPv3 Routers listen to this address
• Hosts do not listen or respond to this address
– No Report Suppression
• All Hosts on wire respond to Queries
– Host’s complete IGMP state sent in single response
• Response Interval may be tuned over broad range
– Useful when large numbers of hosts reside on subnet

© 2004 Cisco Systems, Inc. All rights reserved. 25


IGMPv3—Joining a Group

1.1.1.10 1.1.1.11 1.1.1.12

H1 H2 H3

v3 Report Group: 224.1.1.1


(224.0.0.22) Exclude: <empty>

1.1.1.1

rtr-a

• Joining member sends IGMPv3 Report to 224.0.0.22


immediately upon joining

© 2004 Cisco Systems, Inc. All rights reserved. 26


IGMPv3—Joining Specific Source(s)

1.1.1.10 1.1.1.11 1.1.1.12

H1 H2 H3

v3 Report Group: 224.1.1.1


(224.0.0.22) Include: 10.0.0.1

1.1.1.1

rtr-a

• IGMPv3 Report contains desired source(s) in the Include


list.

• Only “Included” source(s) are joined.


© 2004 Cisco Systems, Inc. All rights reserved. 27
IGMPv3—Maintaining State

1.1.1.10 1.1.1.11 1.1.1.12

H1 H2 H3

v3 Report v3 Report v3 Report


(224.0.0.22) (224.0.0.22) (224.0.0.22)

1.1.1.1 Query

• Router sends periodic queries


• All IGMPv3 members respond

– Reports contain multiple Group state records


© 2004 Cisco Systems, Inc. All rights reserved. 28
Multicast Distribution Trees

Shortest Path or Source Distribution Tree


Source 1
Notation: (S, G)
S = Source
G = Group
Source 2

A B D F

C E

Receiver 1 Receiver 2

© 2004 Cisco Systems, Inc. All rights reserved. 29


Multicast Distribution Trees

Shortest Path or Source Distribution Tree


Source 1
Notation: (S, G)
S = Source
G = Group
Source 2

A B D F

C E

Receiver 1 Receiver 2

© 2004 Cisco Systems, Inc. All rights reserved. 30


Multicast Distribution Trees

Shared Distribution Tree


Notation: (*, G)
* = All Sources
G = Group

A B D (RP) F

(RP) PIM Rendezvous Point


C E
Shared Tree

Receiver 1 Receiver 2

© 2004 Cisco Systems, Inc. All rights reserved. 31


Multicast Distribution Trees

Shared Distribution Tree


Source 1 Notation: (*, G)
* = All Sources
G = Group

Source 2

A B D (RP) F

(RP) PIM Rendezvous Point


C E
Shared Tree
Source Tree

Receiver 1 Receiver 2

© 2004 Cisco Systems, Inc. All rights reserved. 32


Multicast Distribution Trees

Characteristics of Distribution Trees

• Source or Shortest Path trees


– Uses more memory O(S x G) but you get optimal paths from
source to all receivers; minimizes delay

• Shared trees
– Uses less memory O(G) but you may get sub-optimal paths
from source to all receivers; may introduce extra delay

© 2004 Cisco Systems, Inc. All rights reserved. 33


Multicast Forwarding

• Multicast Routing is backwards from Unicast


Routing
– Unicast Routing is concerned about where the
packet is going.
– Multicast Routing is concerned about where the
packet came from.
• Multicast Routing uses “Reverse Path
Forwarding”

© 2004 Cisco Systems, Inc. All rights reserved. 34


Multicast Forwarding

Reverse Path Forwarding (RPF)


• What is RPF?
A router forwards a multicast datagram only if received on
the up stream interface to the source (i.e. it follows the
distribution tree).

• The RPF Check


• The routing table used for multicasting is checked against
the “source” IP address in the packet.
• If the datagram arrived on the interface specified in the
routing table for the source address; then the RPF check
succeeds.
• Otherwise, the RPF Check fails.

© 2004 Cisco Systems, Inc. All rights reserved. 35


Multicast Forwarding

Example: RPF Checking

Source
151.10.3.21

RPF Check Fails


Packet arrived on wrong interface!

Mcast Packets

© 2004 Cisco Systems, Inc. All rights reserved. 36


Multicast Forwarding

A closer look: RPF Check Fails


Multicast Packet from
Source 151.10.3.21

X
S0

RPF Check Fails! S1 S2


Unicast Route Table E0
Network Interface
151.10.0.0/16 S1
198.14.32.0/24 S0 Packet Arrived on Wrong Interface!
204.1.16.0/24 E0
Discard Packet!

© 2004 Cisco Systems, Inc. All rights reserved. 37


Multicast Forwarding

A closer look: RPF Check Succeeds

Multicast Packet from


Source 151.10.3.21
S0

S1 S2
RPF Check Succeeds! E0
Unicast Route Table
Network Interface
151.10.0.0/16 S1 Packet Arrived on Correct Interface!
198.14.32.0/24 S0 Forward out all outgoing interfaces.
204.1.16.0/24 E0 (i. e. down the distribution tree)

© 2004 Cisco Systems, Inc. All rights reserved. 38


“Multicast Routing is not unicast routing.
You have to think of it differently. It is
not like OSPF. It is not like RIP. It is not
like anything you may be familiar with.”
Multicast vs. Unicast Routing

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 39
PIM PROTOCOLS

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 40
Types of Multicast Protocols

• Dense-mode
– Uses “Push” Model
– Traffic Flooded throughout network
– Pruned back where it is unwanted
– Flood & Prune behavior (typically every 3 minutes)
– PIM-DM State Refresh has eliminated this behavior

• Sparse-mode
– Uses “Pull” Model
– Traffic sent only to where it is requested
– Explicit Join behavior

© 2004 Cisco Systems, Inc. All rights reserved. 41


PIM-DM

• Protocol Independent
– Supports all underlying unicast routing protocols including:
static, RIP, IGRP, EIGRP, IS-IS, BGP, and OSPF

• Uses reverse path forwarding


– Floods network and prunes back based on multicast group
membership
– Assert mechanism used to prune off redundant flows

• Appropriate for...
– Lab work and router performance testing

© 2004 Cisco Systems, Inc. All rights reserved. 42


PIM-DM Flood and Prune

Initial Flooding

Source

(S, G) State created in


Multicast Packets every router in the network!

Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 43


PIM-DM Flood and Prune

Pruning Unwanted Traffic

Source

Multicast Packets
Prune Messages

Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 44


PIM-DM Flood and Prune

Results After Pruning

Source

(S, G) State still exists in


Multicast Packets every router in the network!

Flood and Prune process


repeats every 3 minutes!!! Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 45


PIM-DM: Evaluation

• Primary use:
– Test Labs and router performance testing

• Advantages:
– Easy to configure—two commands
– Simple flood and prune mechanism

• Potential issues...
– Inefficient flood and prune behavior
– Complex Assert mechanism
– Mixed control and data planes
• Results in (S, G) state in every router in the network
• Can result in non-deterministic topological behaviors
– No support for shared trees

© 2004 Cisco Systems, Inc. All rights reserved. 46


PIM-SM (RFC 2362)

• Supports both source and shared trees


– Assumes no hosts want multicast traffic unless they specifically ask
for it
• Uses a Rendezvous Point (RP)
– Senders and Receivers “rendezvous” at this point to learn of each
others existence.
• Senders are “registered” with RP by their first-hop router.
• Receivers are “joined” to the Shared Tree (rooted at the RP) by their
local Designated Router (DR).
• Appropriate for…
– Wide scale deployment for both densely and sparsely populated
groups in the enterprise
– Optimal choice for all production networks regardless of size and
membership density.

© 2004 Cisco Systems, Inc. All rights reserved. 47


PIM-SM Shared Tree Join

RP

(*, G) State created only


(*, G) Join along the Shared Tree.
Shared Tree

Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 48


PIM-SM Sender Registration

RP
Source

(S, G) State created only


Traffic Flow along the Source Tree.
Shared Tree
Source Tree
(S, G) Register (unicast) Receiver
(S, G) Join

© 2004 Cisco Systems, Inc. All rights reserved. 49


PIM-SM Sender Registration

RP
Source

(S, G) traffic begins arriving


Traffic Flow at the RP via the Source tree.
Shared Tree RP sends a Register-Stop
Source Tree back to the first-hop router to
(S, G) Register (unicast) Receiver stop the Register process.
(S, G) Register-Stop (unicast)

© 2004 Cisco Systems, Inc. All rights reserved. 50


PIM-SM Sender Registration

RP
Source

Source traffic flows natively


Traffic Flow along SPT to RP.
Shared Tree From RP, traffic flows down
Source Tree the Shared Tree to Receivers.
Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 51


PIM-SM SPT Switchover

RP
Source

Last-hop router joins the Source


Traffic Flow Tree.
Shared Tree Additional (S, G) State is created
Source Tree along new part of the Source Tree.
(S, G) Join Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 52


PIM-SM SPT Switchover

RP
Source

Traffic Flow
Traffic begins flowing down the
Shared Tree new branch of the Source Tree.
Source Tree
Additional (S, G) State is created
(S, G)RP-bit Prune Receiver along along the Shared Tree to
prune off (S, G) traffic.

© 2004 Cisco Systems, Inc. All rights reserved. 53


PIM-SM SPT Switchover

RP
Source

(S, G) Traffic flow is now


Traffic Flow pruned off of the Shared Tree
Shared Tree and is flowing to the Receiver
via the Source Tree.
Source Tree
Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 54


PIM-SM SPT Switchover

RP
Source

(S, G) traffic flow is no longer


Traffic Flow needed by the RP so it Prunes
Shared Tree the flow of (S, G) traffic.
Source Tree
(S, G) Prune Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 55


PIM-SM SPT Switchover

RP
Source

(S, G) Traffic flow is now only


Traffic Flow flowing to the Receiver via a
Shared Tree single branch of the Source
Tree.
Source Tree
Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 56


“The default behavior of PIM-SM is that
routers with directly connected members
will join the Shortest Path Tree as soon
as they detect a new multicast source.”
PIM-SM Frequently Forgotten Fact

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 57
PIM-SM: Evaluation

• Effective for sparse or dense distribution


of multicast receivers
• Advantages:
– Traffic only sent down “joined” branches
– Can switch to optimal source-trees for high traffic sources
dynamically
– Unicast routing protocol-independent
– Basis for inter-domain multicast routing
• When used with MBGP, MSDP and/or SSM

© 2004 Cisco Systems, Inc. All rights reserved. 58


Source Specific Multicast

• Assume a One-to-Many Multicast Model.


– Example: Video/Audio broadcasts, Stock Market data

• Why does PIM-SM need a Shared Tree?


– So that hosts and 1st hop routers can learn who the active source is
for the group.
• What if this was already known?
– Hosts could use IGMPv3 to signal exactly which (S,G) SPT to join.
– The Shared Tree & RP wouldn’t be necessary.
– Different sources could share the same Group address and not
interfere with each other.
• Result: Source Specific Multicast (SSM)

• RFC 3569 An Overview of Source-Specific Multicast (SSM)

© 2004 Cisco Systems, Inc. All rights reserved. 59


Source Specific Multicast Advantages

• Simplifies Multicast deployment and eliminates


the concept of RP and dependence on MSDP for
finding sources.
• Optimized and Reduce latency for multicast
forwarding in case of one to many applications.
• Simplifies Address allocation problem for global
single source groups.
• Allows immediate use of shortest forwarding path
to a specific source, without need to create shared
tree.

© 2004 Cisco Systems, Inc. All rights reserved. 60


PIM Source Specific Mode

Source Receiver learns of source, group/port


Receiver sends IGMPv3 (S,G) Join
First-hop send PIM s,g join directly toward
Source

A B C D
Out-of-band Source
(S, G) Join Directory
Example: Web Server

D F
IGMPv3 (S, G) Join

Receiver 1

© 2004 Cisco Systems, Inc. All rights reserved. 61


PIM Source Specific Mode

Source Result: Shortest Path Tree rooted


at the Source, with NO Shared Tree.

A B C D

E F

Receiver 1

© 2004 Cisco Systems, Inc. All rights reserved. 62


PIM-SSM: Evaluation

• Ideal for applications with one source sending to many


receivers
• Solves multicast address allocation problems.
– Flows differentiated by both source and group.
• Not just by group.
– Content providers can use same group ranges.
• Since each (S,G) flow is unique.

• Helps prevent certain DoS attacks


– “Bogus” source traffic:
• Can’t consume network bandwidth.
• Not received by host application.

© 2004 Cisco Systems, Inc. All rights reserved. 63


Many-to-Any State Problem

• Creates huge amounts of (S,G) state


– State maintenance workloads skyrocket
• High OIL fanouts make the problem worse

– Router performance begins to suffer


• Using Shared-Trees only.
– Provides some (S,G) state reduction
• Results in (S,G) state only along SPT to RP
• Frequently still too much (S,G) state
• Need a solution that only uses (*,G) state

© 2004 Cisco Systems, Inc. All rights reserved. 64


Bidirectional PIM: Overview

RP Sender/
Receiver Receiver

Shared Tree

Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 65


Bidirectional PIM: Overview

RP Sender/
Receiver Receiver

Source Traffic forwarded


bidirectionally using (*,G) state.

Shared Tree
Source Traffic
Receiver

© 2004 Cisco Systems, Inc. All rights reserved. 66


Bidir PIM: Evaluation

• Ideal for Many to Many applications


• Drastically reduces network mroute state.
– Eliminates ALL (S,G) state in the network.
• SPT’s between sources to RP eliminated.
• Source traffic flows both up and down Shared Tree.

– Allows Many-to-Any applications to scale.


• Permits virtually an unlimited number of sources.

© 2004 Cisco Systems, Inc. All rights reserved. 67


PIM-SM: One Size Fits All?

• Effective for sparse or dense distribution


of multicast receivers
• Advantages:
– Widely deployed
– Source-trees or Shared tree possible
– Basis for current inter-domain multicast with MSDP

© 2004 Cisco Systems, Inc. All rights reserved. 68


RP CHOICES

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 69
How Does the Network Know about the RP ?

• Static configuration
• AutoRP
• BSR

© 2004 Cisco Systems, Inc. All rights reserved. 70


Static RP’s

• Hard-coded RP address
– When used, must be configured on every router
– All routers must have the same RP address
– RP fail-over not possible
• Exception: If Anycast RPs are used.

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

– Optional group list specifies group range


• Default: Range = 224.0.0.0/4 (Includes Auto-RP Groups!!!!)
Groups!!!!
– Override keyword “overrides” Auto-RP information
• Default: Auto-RP learned info takes precedence

© 2004 Cisco Systems, Inc. All rights reserved. 71


Auto-RP Overview

• All routers automatically learn RP address


– No configuration necessary except on:
• Candidate RPs
• Mapping Agents
• Makes use of Multicast to distribute info
– Two specially IANA assigned Groups used
• Cisco-Announce - 224.0.1.39
• Cisco-Discovery - 224.0.1.40
– These groups normally operate in Dense mode
• Permits backup RP’s to be configured
– Warning: Can fall back into Dense mode if misconfigured.
• Can be used with Admin-Scoping

© 2004 Cisco Systems, Inc. All rights reserved. 72


Auto-RP: From 10,000 Feet

MA MA

Announce
Announce

A B

Announce Announce Announce Announce


C D
C-RP C-RP
1.1.1.1 2.2.2.2
Announce

Announce
RP-Announcements multicast to the
Cisco Announce (224.0.1.39) group
Announce

© 2004 Cisco Systems, Inc. All rights reserved. 73


Auto-RP: From 10,000 Feet

very
y
ver

o
co

Disc
Dis
Dis Disc
co ver ove
y MA ry MA
Disc
A Dis
co ver
B o very
y
y

ry
ver

ove
co

Disc
C D
Dis

C-RP C-RP
1.1.1.1 2.2.2.2

RP-Discoveries multicast to the


Cisco Discovery (224.0.1.40) group
Discovery

© 2004 Cisco Systems, Inc. All rights reserved. 74


BSR Overview

• A single Bootstrap Router (BSR) is elected


– Multiple Candidate BSR’s (C-BSR) can be configured
• Provides backup in case currently elected BSR fails
– C-RP’s send C-RP announcements to the BSR
• C-RP announcements are sent via unicast
• BSR stores ALL C-RP announcements in the “RP-set”
– BSR periodically sends BSR messages to all routers
• BSR Messages contain entire RP-set and IP address of BSR
• Messages are flooded hop-by-hop throughout the network away from the
BSR
– All routers select the RP from the RP-set
• All routers use the same selection algorithm; select same RP

• BSR cannot be used with Admin-Scoping

© 2004 Cisco Systems, Inc. All rights reserved. 75


BSR: From 10,000 Feet

PIMv2
Sparse Mode F

BSR
A
D t C-
en RP
e m Ad
tis ve
ver t ) (u
ni rtise
Ad icas ca
RP n st men
C- (u ) t

C-RP C-RP
B C

© 2004 Cisco Systems, Inc. All rights reserved. 76


BSR: From 10,000 Feet

PIMv2

BSR Msgs
Sparse Mode F

BSR Msgs BSR Msgs


BSR
A
D

BSR Msgs

C-RP C-RP
B C

E
BSR Msgs Flooded Hop-by-Hop

© 2004 Cisco Systems, Inc. All rights reserved. 77


MULTICAST AT LAYER 2

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 78
L2 Multicast Frame Switching

Problem: Layer 2 Flooding of


Multicast Frames
PIM
• Typical L2 switches treat multicast
traffic as unknown or broadcast and
must “flood” the frame to every port
• Static entries can sometimes be set to
specify which ports should receive Multicast M
which group(s) of multicast traffic
• Dynamic configuration of these entries
would cut down on user administration

© 2004 Cisco Systems, Inc. All rights reserved. 79


L2 Multicast Frame Switching

Solution 1: IGMPv1-v2 Snooping


• Switches become “IGMP” aware
• IGMP packets intercepted by the NMP or by special PIM
hardware ASICs
– Requires special hardware to maintain throughput
• Switch must examine contents of IGMP messages to
determine which ports want what traffic
– IGMP membership reports
– IGMP leave messages IGMP
• Impact on low-end Layer-2 switches:
– Must process ALL Layer 2 multicast packets
– Admin. load increases with multicast traffic load
– Generally results in switch Meltdown !!! IGMP

© 2004 Cisco Systems, Inc. All rights reserved. 80


L2 Multicast Frame Switching

Solution 2: CGMP—Cisco Group


Management Protocol
• Runs on both the switches and the router
• Router sends CGMP multicast packets to the switches at a PIM
well known multicast MAC address:
– 0100.0cdd.dddd
• CGMP packet contains :
– Type field—Join or Leave
– MAC address of the IGMP client CGMP IGMP
– Multicast address of the group Commands
• Switch uses CGMP packet info to add or remove a Layer-2
entry for a particular multicast MAC address

© 2004 Cisco Systems, Inc. All rights reserved. 81


CGMP Basics

IGMP Report CGMP Join


Dst MAC = 0100.5e01.0203 USA = 0080.c7a2.1093
Src MAC = 0080.c7a2.1093
1/1 1/1 GDA = 0100.5e01.0203
Dst IP = 224.1.2.3
Src IP = 192.1.1.1
IGMP Group = 224.1.2.3
5/1 5/1

(a) (b)

© 2004 Cisco Systems, Inc. All rights reserved. 82


L2 Multicast Frame Switching

• Impact of IGMPv3 on IGMP Snooping


– IGMPv3 Reports sent to separate group (224.0.0.22)
• Switches listen to just this group.
• Only IGMP traffic – no data traffic.
• Substantially reduces load on switch CPU.
• Permits low-end switches to implement IGMPv3 Snooping
– No Report Suppression in IGMPv3
• Enables individual member tracking
– IGMPv3 supports Source-specific Includes/Excludes
• Permits (S,G) state to be maintained by switch
– Currently not implemented by any switches.
• May be necessary for full IGMPv3 functionality

© 2004 Cisco Systems, Inc. All rights reserved. 83


Summary: Frame Switches

• IGMP snooping
– Switches with Layer 3 aware Hardware/ASICs
• High-throughput performance maintained
• Increases cost of switches
– Switches without Layer 3 aware Hardware/ASICs
• Suffer serious performance degradation or even Meltdown!
Meltdown
– Shouldn’t be a problem when IGMPv3 is implemented

• CGMP
– Requires Cisco routers and switches
– Can be implemented in low-cost switches

© 2004 Cisco Systems, Inc. All rights reserved. 84


INTERDOMAIN IP MULTICAST

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 85
MBGP Overview

• MBGP: Multiprotocol BGP


– Defined in RFC 2858 (extensions to BGP)
– Can carry different types of routes
• Unicast
• Multicast

– Both routes carried in same BGP session


– Does not propagate multicast state info
– Same path selection and validation rules
• AS-Path, LocalPref, MED, …

© 2004 Cisco Systems, Inc. All rights reserved. 86


MBGP Overview

• New Multiprotocol Attributes


– MP_REACH_NLRI
– MP_UNREACH_NLRI

• MP_REACH_NLRI and MP_UNREACH_NLRI


– Address Family Information (AFI) = 1 (IPv4)
• Sub-AFI = 1 (NLRI is used for unicast)
• Sub-AFI = 2 (NLRI is used for multicast RPF check)

© 2004 Cisco Systems, Inc. All rights reserved. 87


MBGP Overview

• Separate BGP tables maintained


– Unicast Routing Information Base (URIB)
– Multicast Routing Information Base (MRIB)
• URIB
– Contains unicast prefixes for unicast forwarding
– Populated with BGP unicast NLRI
• AFI = 1, Sub-AFI = 1
• MRIB
– Contains unicast prefixes for RPF checking
– Populated with BGP multicast NLRI
• AFI = 1, Sub-AFI = 2

© 2004 Cisco Systems, Inc. All rights reserved. 88


MBGP Overview

• MBGP allows divergent paths and policies


– Same IP address holds dual significance
• Unicast routing information
• Multicast RPF information
– For same IPv4 address two different NLRI with different
next-hops
– Can therefore support both congruent and incongruent
topologies

© 2004 Cisco Systems, Inc. All rights reserved. 89


MSDP Concept

• Simple but elegant


– Utilize inter-domain source trees
– Reduces problem to locating
active sources
– RP or receiver last-hop can join
inter-domain source tree

© 2004 Cisco Systems, Inc. All rights reserved. 90


MSDP RFC 3618 Concepts

• Works with PIM-SM only


– RP’s knows about all sources in a domain
• Sources cause a “PIM Register” to the RP
• Can tell RP’s in other domains of its sources
– Via MSDP SA (Source Active) messages
– RP’s know about receivers in a domain
• Receivers cause a “(*, G) Join” to the RP
• RP can join the source tree in the peer domain
– Via normal PIM (S, G) joins

© 2004 Cisco Systems, Inc. All rights reserved. 91


MSDP Overview

MSDP Example Domain E

MSDP Peers RP Join (*, 224.2.2.2)

r
Domain C

RP

Domain B

RP

RP

Domain D

RP

Domain A

© 2004 Cisco Systems, Inc. All rights reserved. 92


MSDP Overview

MSDP Example Domain E

MSDP Peers RP

Source Active SA SA r
Messages Domain C

RP
SA
Domain B SA SA

RP

SA RP

SA Domain D
SA Message
192.1.1.1, 224.2.2.2
RP
SA Message
192.1.1.1, 224.2.2.2 s
Domain A
Register
192.1.1.1, 224.2.2.2
© 2004 Cisco Systems, Inc. All rights reserved. 93
MSDP Overview

MSDP Example Domain E

MSDP Peers RP

r
Domain C

.2.2.2)
RP

(S, 224in
Jo
Domain B

RP

RP

Domain D

RP
s
Domain A

© 2004 Cisco Systems, Inc. All rights reserved. 94


MSDP Overview

MSDP Example Domain E

MSDP Peers RP

Multicast Traffic r
Domain C

RP

Domain B

RP

RP

Domain D

RP
s
Domain A

© 2004 Cisco Systems, Inc. All rights reserved. 95


MSDP Overview

MSDP Example Domain E

MSDP Peers RP

Multicast Traffic r
Domain C Join
.2)
(S, 224.2.2

RP

Domain B

RP

RP

Domain D

RP
s
Domain A

© 2004 Cisco Systems, Inc. All rights reserved. 96


MSDP Overview

MSDP Example Domain E

MSDP Peers RP

Multicast Traffic r
Domain C

RP

Domain B

RP

RP

Domain D

RP
s
Domain A

© 2004 Cisco Systems, Inc. All rights reserved. 97


Anycast RP: Overview

• Uses single statically defined RP address


– Two or more routers have same RP address
• RP address defined as a Loopback Interface.
• Loopback address advertised as a Host route.
– Senders & Receivers Join/Register with closest RP
• Closest RP determined from the unicast routing table.
– Can never fall back to Dense mode.
• Because RP is statically defined.

• MSDP session(s) run between all RPs


– Informs RPs of sources in other parts of network
– RPs join SPT to active sources as necessary

© 2004 Cisco Systems, Inc. All rights reserved. 98


Anycast RP: Overview

Src Src

RP1 RP2
MSDP
X

A SA SA B
10.1.1.1 10.1.1.1

Rec Rec Rec Rec

© 2004 Cisco Systems, Inc. All rights reserved. 99


Anycast RP: Overview

Src Src

RP1 RP2
X

A B
10.1.1.1 10.1.1.1

Rec Rec Rec Rec

© 2004 Cisco Systems, Inc. All rights reserved. 100


Anycast RP Configuration

RP1 RP2
MSDP
A B
ip pim rp-address 10.0.0.1 ip pim rp-address 10.0.0.1

X Y

Interface loopback 0 Interface loopback 0


ip address 10.0.0.2 255.255.255.255 ip address 10.0.0.3 255.255.255.255

Interface loopback 1 Interface loopback 1


ip address 10.0.0.1 255.255.255.255 ip address 10.0.0.1 255.255.255.255
! !
ip msdp peer 10.0.0.3 connect-source loopback 0 ip msdp peer 10.0.0.2 connect-source loopback 0
ip msdp originator-id loopback 0 ip msdp originator-id loopback 0

© 2004 Cisco Systems, Inc. All rights reserved. 101


LATEST ADDITIONS

9783_05_2004_X2
© 2004 Cisco Systems, Inc. All rights reserved. © 2003, Cisco Systems, Inc. All rights reserved. 102
Multicast VPN
The Customer Requirement
• MPLS VPN customers want to run multicast within their
VPNs
• Multicast deployment is expanding
• MPLS VPNs do not support multicast today
• Multicast options in MPLS VPNs today
–GRE tunnels from CE to CE
CE CE Does NOT Scale !!!!

CE
CE
MPLS
CE Core CE

© 2004 Cisco Systems, Inc. All rights reserved. CE CE 103


Multicast VPN (MVPN)

• Allows an ISP to provide its MPLS VPN customers


the ability to transport their Multicast traffic across
MPLS packet-based core networks
• Provides a “Ships in the Night” approach with
MPLS
• A scalable architecture solution for MPLS networks
based on native multicast deployment in the core
• Uses draft-rosen-vpn-mcast encapsulation and
signaling to build MVPN Multicast VPN (MVPN)

© 2004 Cisco Systems, Inc. All rights reserved. 104


Multicast VPN
Terminology Used

• VPN: Virtual Private Network


–Although different VPN models exist, the discussion here is for MPLS
based VPNs

• MVPN: Multicast VPN


–A VPN that supports multicast natively

• VRF: VPN Routing and Forwarding


–per-site forwarding tables
• MVRF: Multicast VRF
–A VRF that supports unicast and multicast tables

© 2004 Cisco Systems, Inc. All rights reserved. 105


Multicast VPN
Terminology Used

• MDT: Multicast Distribution Tree


– A multicast tree, built in the core network between PE and P
routers that distributes multicast traffic between sites

• Default-MDT:
– Default MDT group used for control traffic and flooding channel
for dense mode and low bandwidth groups.

• Data-MDT:
– MDT group created on demand for MVPN (S,G) pairs, usually
high bandwidth traffic

© 2004 Cisco Systems, Inc. All rights reserved. 106


Multicast VPN (MVPN)
Concept and Fundamentals
Receiver 4 Join high • Customer CE devices
CE
bandwidth source
A
joins the MPLS Core
CE Receiver 1 through provider’s PE
CE B2
New York CE devices
B1 PE E
San
A • The MPLS Core forms a
Francisco PE Default MDT for a given
MPLS VPN
PE B E Customer
Core
Default CE
MDT • A High-bandwidth
For low
F
source for that
Bandwidth &
control Data customer starts
traffic only. MDT sending traffic
Los
PE For High
Bandwidth • Interested receivers 1 &
D
Angeles traffic only.
2 join that High
CE C
PE Dallas Bandwidth source
D

C CE • Data-MDT is formed for


Receiver 3
this High-Bandwidth
High bandwidth Join high source
bandwidth source Receiver 2
multicast source
© 2004 Cisco Systems, Inc. All rights reserved. 107
IPv4 versus IPv6 Multicast

IP Service IPv4 Solution IPv6 Solution


Address Range 32-bit, class D 128-bit (112-bit Group)

Protocol Independent
Protocol Independent
Routing All IGPs,and BGP4+
All IGPs,and BGP4+
with v6 mcast SAFI

Forwarding PIM-DM, PIM-SM, PIM-SM, PIM-SSM,


PIM-SSM, PIM-bidir PIM-bidir
Group
IGMPv1, v2, v3 MLDv1, v2
Management

Boundary/Border Scope Identifier


Domain Control

MSDP across Single RP within


Inter-domain Independent PIM Globally Shared
Solutions Domains Domains
© 2004 Cisco Systems, Inc. All rights reserved. 108
IPv6 Multicast Addresses (RFC 3513)

128 bits
Group ID (112 bits)

T or Lifetime, 0 if permanent, 1 if temporary


1111 1111
Flags P proposed for unicast-based assignments
Flags =
F F P T scope Others are undefined and must be zero

8 bits 8 bits 1 = interface-local


2 = link
Scope = 4 = admin-local
5 = site
8 = organization
E = global

© 2004 Cisco Systems, Inc. All rights reserved. 109


IP Routing for Multicast

• RPF based on reachability to v6 source same as with v4


multicast
• RPF still protocol independent:
–Static routes, mroutes
–Unicast RIB: BGP, ISIS, OSPF, EIGRP, RIP, etc
–Multi-protocol BGP (mBGP)
– - support for v6 mcast sub-address family
– - provide translate function for non-supporting peers

© 2004 Cisco Systems, Inc. All rights reserved. 110


IPv6 Multicast Forwarding

• PIM-Sparse Mode (PIM-SM)


–draft-ietf-pim-sm-v2-new-09.txt,
• PIM-Source Specific Mode (PIM-SSM)
–RFC3569 SSM overview (v6 SSM needs MLDv2)
–unicast prefix based multicast addresses ff30::/12
–-> SSM range is ff3X::/32
•-> current allocation is from ff3X::/96

• PIM-bidirectional Mode (PIM-bidir)


–draft-ietf-pim-bidir-06.txt

© 2004 Cisco Systems, Inc. All rights reserved. 111


RP Mapping Mechanisms for IPv6 PIM-SM

• Static RP assignment
• BSR
• Auto-RP – no current draft

© 2004 Cisco Systems, Inc. All rights reserved. 112


Multicast Listener Discover: MLD

• MLD is equivalent to IGMP in IPv4


• MLD messages are transported over ICMPv6
• Version number confusion:
– MLDv1 corresponds to IGMPv2
• RFC 2710
– MLDv2 corresponds to IGMPv3, needed for SSM
• draft-vida-mld-v2-08.txt
• MLD snooping
– draft-ietf-magma-snoop-11.txt
• CGMP for v6 under consideration

© 2004 Cisco Systems, Inc. All rights reserved. 113


You Now Know…

• Why Multicast?
• Multicast Fundamentals
• PIM Protocols
• RP choices
• Multicast at Layer 2
• Interdomain IP Multicast
• Latest Additions IPv6 and MVPN

© 2004 Cisco Systems, Inc. All rights reserved. 114


More Information

• White Papers

• Web and Mailers

• Cisco Press

CCO Multicast page:


http://www.cisco.com/go/ipmulticast
Questions:
cs-ipmulticast@cisco.com
Customer Support Mailing List:
tac@cisco.com RTFB = “Read the Fine Book”
© 2004 Cisco Systems, Inc. All rights reserved. 115
RST-1701
9783_05_2004_X2 © 2004 Cisco Systems, Inc. All rights reserved. 116

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy