Cisco Live 2014 - Amazon Web Services Tibco Multicast1 23. BRKIPM-1261-rev10 © 2015 Cisco and/or its affiliates. All rights reserved. ... BRKIPM-1261-rev10 © 2015 Cisco and/or its

1BRKIPM-1261-rev10 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public


Introduction to IP Multicast

Beau WilliamsonCiscoLive Distinguished Speaker

Twitter: @Mr_Multicast

BRKIPM-1261


• To provide you with an understanding of the concepts, mechanics and protocols used to build IP multicast networks.

• To enable you to ask the right questions, and make the correct architectural decisions in deploying and maintaining an IP Multicast enabled network.

• To prove that Multicast doesn’t have to be:

• Hard

• Scary

Session Goals


• Why Multicast?

• Multicast History and Fundamentals

• PIM Protocols

• RP Choices

• Multicast at Layer 2

• Interdomain IP Multicast

• IPv6 Multicast

AgendaGeekometer


Why Multicast?

© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKIPM-1261-rev10

Server

Router

Unicast

Server

Router

Multicast

Unicast vs. Multicast Scaling

Number of Streams

6


Multicast History & Fundamentals


A Brief History of Multicast

• Steven Deering, 1985, Stanford University

– Yeah, he was way ahead of his time and too clever for all of us.

• A solution for layer2 applications in the growing layer3 campus network

– Think overlay broadcast domain

• Broadcast Domain

– all members receive

– all members can source

– members dynamically come and go

8



• RFC966 –A Multicast Extension to the Internet Protocol

– Circa 1985

– Aka “The Multicast Dead-Sea Scrolls” by some people

• Multi-destination delivery is useful to several applications, including:

– distributed, replicated databases [6,9].

– conferencing [11].

– distributed parallel computation, including distributed gaming

[2].

• All inherently many-to-many applications

• No mention of one-to-many services such as Video/IPTV

9



• Overlay Broadcast Domain Requirements

– Tree building and maintenance

– Network-based source discovery

– Source route information

– Overlay mechanism – tunneling

• The first solution had it all

• Distance Vector Multicast Routing Protocol

– DVMRP, RFC1075 – 1988

10



• PIM – Protocol Independent Multicast

• “Independent” of which unicast routing protocol you run

– It does require that you’re running one.

– Uses local routing table to determine route to sources

• Router-to-router protocol to build and maintain distribution trees

• Source discovery handled one of two ways:

1. Flood-and-prune PIM-DM, Dense Mode

2. Explicit Join w/ Rendezvous Point (RP) PIM-SM

• Sparse Mode - The Current Standard

11



• PIM-SM – Protocol Independent Multicast Sparse Mode





• Long, Sordid IETF history

– RFC4601 – 2006 (original draft was rewritten from scratch)

• Primary challenges to the final specification were in addressing Network-based source discovery.

12



• Today’s dominant applications are primarily one-to-many

– IPTV, Contribution video over IP, etc.

– Sources are well known

• SSM – Source Specific Multicast – RFC3569, RFC4608 – 2003





• Very simple and the preferred solution for one-to-many applications

13

© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKIPM-1261-rev10 14

Multicast Uses

• Any applications with multiple receivers

– One-to-many or many-to-many

• Live video distribution

• Collaborative groupware

• Periodic data delivery—“push”technology

– Stock quotes, sports scores, magazines, newspapers, adverts

• Server/Website replication

• Reducing network/resource overhead

– More than multiple point-to-point flows

• Resource discovery

• Distributed interactive simulation (DIS)

– War games

– Virtual reality

14


Multicast Considerations

• Best effort 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; PGM, FEC, QoS

• No congestion 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: 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

• Multicast Is UDP-Based

15


Multicast ComponentsCisco End-to-End Architecture

• End stations (hosts-to-routers)

IGMP, MLD, AMT

Campus Multicast

• Switches (Layer 2 optimization)

IGMP snooping

• Routers (multicast forwarding protocol)

PIM sparse mode or bidirectional PIM

Multicast routing across domainsMBGP

Interdomain Multicast Multicast source discovery

MSDP with PIM-SM

Source Specific MulticastSSM

ISP B

Multicast Source

Y

ISP A

Multicast Source

X ISP B

IGMP

AMT

PIM-SM: ASM, SSM, BiDir

MVPN, BIER

IGMP Snooping PIM Snooping

MBGP

MSDP

ISP A

DR

DR

RP

RP

DR

16


Multicast Fundamentals



18

Multicast Myth Busters

“Multicast is complicated, scary and hard

to understand!”


Unicast vs. Multicast Addressing

src addr:

10.1.1.1

src addr:

10.1.1.1

A unique packet

addressed to each

destination IP Address.

Same packet

addressed to “Group”

destination address...

19

12.1.1.1

11.1.1.1

13.1.1.1

Multicast

Group

Address

e.g. 224.1.1.1


Unicast vs. Multicast Addressing

src addr:

10.1.1.1

src addr:

10.1.1.1

12.1.1.1

11.1.1.1

13.1.1.1

..replicated at each

node along the

tree.

A unique packet

addressed to each

destination IP Address.

20

Multicast

Group

Address

e.g. 224.1.1.1


Multicast Addressing Multicast AddressingIPv4 Header

Options Padding

Time to Live Protocol Header Checksum

Identification Flags Fragment Offset

Version IHL Type of Service Total Length

Source Address

Destination AddressDestination

Source

224.0.0.0 - 239.255.255.255 (Class D) Multicast Group Address RangeDestination

1.0.0.0 - 232.255.255.255 (Class A, B, C)

Source Always the unique unicast origin address of

the packet – same as unicast

21


Multicast Addressing

• Multicast Group addresses are NOT in the unicast route table.

• A separate multicast route table is maintained for active multicast trees.

• Multicast trees are initiated by receivers signaling their request to join a group.

• Sources do not need to join, they just send.

• Multicast routing protocols build the trees:

– Hop-by-hop, from the receivers (tree leaves) to the source (tree root).

– Tree path follows the unicast route table backward to the source using source address.

– Multicast relies on a dependable unicast infrastructure.

• Class D Group addresses – 224/4

22


Multicast Addressing—224/4• Reserved link-local addresses

• 224.0.0.0–224.0.0.255

• Transmitted with TTL = 1

• Examples224.0.0.1 All systems on this subnet224.0.0.2 All routers on this subnet224.0.0.5 OSPF routers224.0.0.13 PIMv2 routers224.0.0.22 IGMPv3

• Other IANA reserved addresses

• 224.0.1.0–224.0.1.255

• Not local in scope (transmitted with TTL > 1)

• Examples224.0.1.1 NTP (Network Time Protocol)224.0.1.32 Mtrace routers224.0.1.78 Tibco Multicast1

23


Multicast Addressing—224/4

• 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—scoped traffic

• SSM (Source Specific Multicast) range

– 232.0.0.0–232.255.255.255

– Primarily targeted for Internet-style broadcast

24


Multicast AddressingIP Multicast MAC Address Mapping

32 Bits

28 Bits

25 Bits 23 Bits

48 Bits

01-00-5e-7f-00-01

1110

5 BitsLost

239.255.0.1

25


Multicast AddressingIP Multicast MAC Address Mapping

224.1.1.1

224.129.1.1

225.1.1.1

225.129.1.1...

238.1.1.1

238.129.1.1

239.1.1.1

239.129.1.1

0x0100.5E01.0101

1–Multicast MAC Address

32–IP Multicast Addresses

Be Aware of the 32:1 Address Overlap

26


How are Multicast Flows Identified

• Every Multicast Flow can be identified by two components:

– Source IP Address• The address of the Sender

– Multicast Group Address• 224/4 (Class D) IP Address

• Example(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s

Incoming interface: Ethernet 0/0, RPF nbr 207.109.83.33

Outgoing interface list:

Ethernet 1/0, Forward/Sparse, 3w1d/00:02:40


• How do Hosts Signal to Routers which flow they want?

– IPv4: IGMP

– IPv6: MLD

27

Multicast Flow from Source 2.2.2.2 to

Group 232.1.1.1


Host-Router Signaling: IGMP

• IGMP Version 3 is current version

– RFC3376 Oct 2002 (Over 10 years old)

• Uses 224.0.0.22 (IGMPv3 routers) Link-Local Multicast Address

– All IGMP hosts send Membership Reports to this address

– All IGMP routers listen to this address

– Hosts do not listen or respond to this address (unlike previous IGMP versions)

• Membership Reports

– Sent by Hosts

– Contain list of Multicast (Source, Group) pairs to Include/Exclude (Join/Leave)

• Membership Queries

– Sent by Routers to refresh/maintain list of Multicast traffic to deliver.

28


IGMPv3 – Membership Report Packet Format

# of Group Records (M)Number of Group Records in Report

Group Records 1 - MGroup address plus list of zero or more sources to Include/Exclude(See Group Record format)

Record TypeInclude, Exclude, Chg-to-Include, Chg-to-Exclude, Allow New Srcs, Block Old Srcs

# of Sources (N)Number of Sources in Record

Source Address 1- NAddress of Source

7 15 31

Reserved ChecksumType = 0x22

Reserved # of Group Records (M)

Group Record [1]

Group Record [2]

Group Record [M]

.

.

.

7 15 31

Aux Data Len # of Sources (N)Record Type

Multicast Group Address

Source Address [1]

Source Address [2]..

Source Address [N]

Auxiliary Data

29


IGMPv3 – Query Packet Format

Type = 0x11IGMP Query

Max. Resp. TimeMax. time to send a response

if < 128, Time in 1/10 secsif > 128, FP value (12.8 - 3174.4 secs)

Group Address:Multicast Group Address(0.0.0.0 for General Queries)

S FlagSuppresses processing by routers

QRV (Querier Robustness Value)Affects timers and # of retries

QQIC (Querier’s Query Interval)Same format as Max. Resp. Time

Number of Sources (N)(Non-zero for Group-and-Source Query)

Source AddressAddress of Source

Group Address

7 15 31

Source Address [N]

.

.

.

Source Address [1]

Source Address [2]

Type = 0x11Max. Resp.

CodeChecksum

QQIC Number of Sources (N)QRVS

30


IGMPv3 – Joining Group “G” Source “S”

31

Type: Allow New (5)

Group: 232.1.1.1

Source: {2.2.2.2}

Report

(224.0.0.22)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3H2

show ip igmp groups 232.1.1.1 detail

Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,

SS - Static Source, VS - Virtual Source,

Ac - Group accounted towards access control limit

Interface: GigabitEthernet3/3

Group: 232.1.1.1

Flags: SSM

Uptime: 00:01:14

Group mode: INCLUDE

Last reporter: 192.168.102.11

Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static,

V - Virtual, M - SSM Mapping, L - Local,

Ac - Channel accounted towards access control limit)

Source Address Uptime v3 Exp CSR Exp Fwd Flags

2.2.2.2 00:01:14 00:02:08 stopped Yes R


IGMPv3 – Maintaining State

• Router sends periodic General Queries to All Hosts

– General Query: Group=0, #Srcs=0

• All IGMP members respond

– Reports can contain multiple Group State records

32

(224.0.0.1)

Query

Group: 0.0.0.0

Source: {}

Type: Include (1)

Group: 232.1.1.1

Source: {2.2.2.2}

Report

(224.0.0.22)

Type: Include (1)

Group: 232.1.1.1

Source: {2.2.2.2}

Report

(224.0.0.22)

Type: Include (1)

Group: 232.1.1.1

Source: {2.2.2.2}

Report

(224.0.0.22)

H1 H2 H3

192.168.102.10 192.168.102.11 192.168.102.12

Member

Group: 232.1.1.1

Source: 2.2.2.2Hn

(Destination IP Address)


IGMPv3 – Leaving Group “G” Source “S”

1. H2 leaves Group-Source

2. Sends “Block Old” Membership Report

3. Router sends Group-Source Query– Group-Source Query: Group=G, #Srcs=N

33

Type: Block Old (6)

Group: 232.1.1.1

Source: {2.2.2.2}

Report

(224.0.0.22)

H1 H2 H3H3

(232.1.1.1)

Query

Group: 232.1.1.1

Source: {2.2.2.2}

1

3

2H2

192.168.102.10 192.168.102.11 192.168.102.12

Member

Group: 232.1.1.1

Source: 2.2.2.2Hn






3. Router sends Group-Source Query

4. A remaining member host sends report

5. Group-Source flow remains active

34

Type: Include

Group: 232.1.1.1

Source: {2.2.2.2}

Report

(224.0.0.22)

H1 H2 H3H3

4

5

192.168.102.10 192.168.102.11 192.168.102.12

Member

Group: 232.1.1.1

Source: 2.2.2.2Hn



(232.1.1.1)

Query

Group: 232.1.1.1

Source: {2.2.2.2}

8

Type: Block Old (6)

Group: 232.1.1.1

Source: {2.2.2.2}

Report

(224.0.0.22)




8. Router sends Group-Source Query

35

H1 H2 H36

7

H3

192.168.102.10 192.168.102.11 192.168.102.12

Member

Group: 232.1.1.1

Source: 2.2.2.2Hn





7. Sends Remove Membership Report

8. Router sends Group-Source specific query

9. State times out. Group-Source flow pruned.

36

H1 H2 H3

9

192.168.102.10 192.168.102.11 192.168.102.12

Member

Group: 232.1.1.1

Source: 2.2.2.2Hn



Unicast vs. Multicast Routing/Forwarding

• Destination IP address directly indicates where to forward packet

• Unicast Routing protocols build a table of destination/interface/next-hop triples

• Unicast Forwarding is hop-by-hop simply based on these entries

– Unicast routing table determines interface and next-hop router to forward packet

• Unicast Routing/Forwarding

37



• Destination Group address doesn’t directly indicate where to forward packet.

• Multicast Routing is Backwards from Unicast Routing

– Multicast Routing builds a tree backwards from the receivers to the source.• Concerned with “Where the packet will come from?”

• More specifically, “What’s the route back to the Source?”

– Trees are built via connection requests called Joins “sent” toward the source.

– Joins follow the unicast routing table backwards toward the source.

– Joins create Multicast tree/forwarding state in the routers along the tree.• Trees are rebuilt dynamically in case of network topology changes.

– Only when a tree is completely built from receiver backwards to the source can source traffic flow down the tree to the receivers.• Say that over and over to yourself when working with Multicast!

• Multicast Routing & Forwarding

38



• All of this can easily lead to “thinking with your Unicast Lizard Brain!”

– If you ever get confused by Multicast, just remember to . . .

• Multicast Routing & Forwarding

39

“Stand on your head!”


Multicast Tree Building

1. Multicast packet’s source address is checked against the unicast routing table

2. Determines interface & next-hop multicast router in the direction of the source

– Which is where the Joins are sent

3. This interface becomes the “Incoming” interface

– Often referred to as the “RPF” (Reverse Path Forwarding) interface

– A router forwards a multicast datagram only if received on the Incoming/RPF interface

• A bit of History

– The term “RPF” is actually a left-over from early Dense mode Multicast days

– Multicast traffic was flooded everywhere (i.e. no explicit Join signaling to build trees)

– Traffic was only accepted on the “RPF” interface to avoid loops

– We still tend to use the term to indicate the calculation of the Incoming interface.

40


Multicast Routing & Forwarding

41

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1



42

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

IGMP “Join”

(2.2.2.2, 232.1.1.1)

Mroute Entry



43

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

PIM Join

(2.2.2.2, 232.1.1.1)

Mroute Entry

Mroute Entry



44

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

PIM Join

(2.2.2.2, 232.1.1.1)

Mroute Entry

Mroute Entry

Mroute Entry



45

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry



46

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry

Receiver

IGMP “Join”

(2.2.2.2, 232.1.1.1)

Mroute Entry



47

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry

Receiver

PIM Join

(2.2.2.2, 232.1.1.1)

Mroute Entry



48

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry

Receiver

Mroute Entry



49

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

Receiver

Mroute Entry

show ip mroute 232.1.1.1

(2.2.2.2, 232.1.1.109), 3w1d/00:02:40, flags: s







50

Source

2.2.2.2

Receiver

Traffic to

232.1.1.1

Receiver

This type of Multicast has a special name: Source Specific Multicast (SSM)

Mroute Entry

show ip mroute 232.1.1.1

(2.2.2.2, 232.1.1.109), 3w1d/00:02:40, flags: s







• Based on source address

• Best path to source found in unicast route table

• Determines where to send join

• Joins continue towards source to build multicast tree

• Multicast data flows down tree

RPF Calculation

51

R1

C

D

10.1.1.1

E1

E2Unicast Route Table

Network Interface10.1.0.0/24 E0

Join

Join

A

E0

E

SRC

B



• Based on source address

• Best path to source found in unicast route table

• Determines where to send join

• Joins continue towards source to build multicast tree

• Multicast data flows down tree

RPF Calculation

52

R1

C

D

A

R2

10.1.1.1

E1E0

E2E

Join

Join

SRC

B



• What if we have equal-cost paths?

– We can’t use both

• Tie-breaker

– Use highest next-hop IP address

RPF Calculation

53

R1

B C

D E

A

10.1.1.1

E1E0

E2Unicast Route TableNetwork Intfc Nxt-Hop10.1.0.0/24 E0 1.1.1.110.1.0.0/24 E1 1.1.2.1

1.1.2.11.1.1.1 Join

F

SRC


Multicast State

54

rtr-a#show ip mroute 232.1.1.1

(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s





Multicast route entries are in (S,G) form.

Incoming interface points upstreamtoward the root of the tree (i.e. Source)

Outgoing interface list is where receivers have joined downstream and where packetswill be replicated and forwarded downstream.

rtr-b#show ip route 232.1.1.109

% Network not in table

Multicast Group addressesare NEVER in the unicast route table.



• Key Point

–If you ever get confused by Multicast . . .

. . . just remember to “Stand on your head”.

(Because Multicast is an Upside-down world where we are interested in where the packet came from, not its destination address.)

55



56

Multicast Myth Busters

“Multicast is complicated, scary and hard

to understand!”



57

See there . . .

. . . that wasn’t so hard, was it?


What makes Multicast Complicated?


Biggest Multicast Complicating Factor

• Lazy One-to-Many Application Developers

– “Let’s just let the Network do all the work to keep track of Sources.”

– Uses old and outdated IGMPv2 methods to join (*,G) only.• Really!!!! IGMPv3 has been out for 10+ years!!

• Even Apple OS supports IGMPv3

– Suffers from Capt. Midnight stream hijacking

– Complicates Multicast Address management/allocation• Now you have to worry about what application uses what Multicast Address

• Requires complex Any-Source Multicast (ASM) & Rendezvous Point Engineering/Mgmt

– Or maybe BiDir Multicast

– Source Specific Multicast (SSM) avoided all of these network issues

• Network-Based Source Discovery

59


Multicast Complicating Factor

• Ad-Hoc Multicast Applications

– No “good” way to know or predict who will become a source.

– Sometimes you just have to support Network-Based Source Discovery

• Requires complex Any-Source Multicast (ASM) & Rendezvous Point Engineering/Mgmt

– Or maybe BiDir Multicast

60

• Network-Based Source Discovery


Network-Based Source Discovery

• Requires Any-Source Multicast (ASM)

– Much, much more complicated than SSM or Bidir

– Requires physical Rendezvous Point (RP) router(s) & RP Redundancy methods

– Uses Shortest-Path Trees (ala SSM) to first deliver traffic to RP

– Then uses a common “Shared Tree” rooted at RP to deliver all Multicast traffic

– Routers w/directly connected receivers then learn about new sources via Shared Tree

– Then join Shortest-Path Tree to all the sources.

. . . or use of Bidir Multicast (Bidir) . . .

– A bit more complicated than Source Specific Multicast but easier than ASM.

– True “Broadcast” like Multicast

– Uses a common “Shared Tree” to deliver all Multicast traffic• Traffic flows both up and down the Tree to get to the Receivers (i.e. Bidirectional)

• Shared Tree rooted at some designated location in the network (not necessarily a router).

61


Types of Multicast Trees


Receiver 3

Multicast Distribution Tree TypesShortest Path or Source Distribution Tree

63

Notation: (S1, G)

S = Source

G = Group

Receiver 1

Source 1

Receiver 2

Source 2B D FA

C E


Multicast Distribution TreesShortest Path or Source Distribution Tree

64

Receiver 1

Source 1Notation: (S2, G)

S = Source

G = Group

Receiver 2

Source 2A B D F

C

These are the type of trees we’ve

been talking about so far.

Receiver 3E


Multicast Distribution TreesShared Distribution Tree

65

Notation: (*, G)

* = All Sources

G = Group

(RP) PIM Rendezvous Point

Shared Tree

Receiver 1

Source 1

Receiver 2

Source 2A B FD

C E

RP


Multicast Distribution TreesShared Distribution Tree

66

Notation: (*, G)

* = All Sources

G = Group

(RP) PIM Rendezvous Point

Source Tree(s)

(used to get traffic to RP)

Receiver 1

Source 1

Receiver 2

Source 2F

C E

DARP

B

Shared Tree


Multicast 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 suboptimal paths from source to all receivers; may introduce extra delay

• Characteristics of Distribution Trees

67


Bidirectional Multicasti.e. Bidir PIM


Bidirectional (BiDir) PIM

• Idea:

– Use Shared Tree to bring traffic up from sources to the RP and then down to receivers

• Benefits:

– Less state in routers • Only (*, G) state is used

• Source traffic follows the Shared Tree – Flows up the Shared Tree to reach the RP

– Flows down the Shared Tree to reach all other receivers

69


PIM Modifications for BiDir Operation

• All trees rooted at the RP

– Data traveling from source toward RP is moving UPSTREAM

– Data traveling from RP toward receivers is moving DOWNSTREAM

• Designated Forwarders (DF)

– One DF per link• Router with best path to the RP is elected DF

• Election mechanism insures all routers on link agree on who is DF

• Prevents route loops from forming

• BiDir (*,G) forwarding rules:

– DF is the only router that picks-up upstream traveling packets off the link to forward towards the RP

70


Bidir Forwarding/Tree Building

Branch of Shared Tree Is Now Built Down to Receiver 1

E

A B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

F

D

71

IGMP (*,G)

Join

PIM (*,G)

Join

PIM (*,G)

JoinE0 (DF)

RP



Example of Bidir State along Shared Tree

E

A B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

F

72

(*, 224.1.1.1), 00:00:04/00:00:00, RP 172.16.21.1, flags: BC

Bidir-Upstream: Ethernet0, RPF nbr 172.16.9.1


Ethernet0, Bidir-Upstream/Sparse-Dense, 00:00:04/00:00:00

Ethernet1, Forward/Sparse-Dense, 00:00:04/00:02:55

D

E0 (DF)

RP



E

A B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

F

73

D

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BP

Bidir-Upstream: Ethernet0, RPF nbr 172.16.7.1


Ethernet0, Bidir-Upstream/Sparse-Dense, 00:32:20/00:00:00Source

Arriving Traffic from Source Causes Router “A” to Create (*, G) State

E0 (DF)

RP



Arriving Traffic Causes Router “E” & RP to Create (*, G) State

Source

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E0 (DF)

Receiver 1

74

E

A B C

RP

E1 (DF)

E0

E1 (DF)

E0

F

D


Any-Source Multicasti.e. ASM PIM


PIM-SM Shared Tree Join

76

Receiver

RP

(*, G) Join

Shared Tree

(*, G) State Created OnlyAlong the Shared Tree


PIM-SM Sender Registration

77

Receiver

RP

(S, G) Join

Source

(S, G) Register (unicast)

Source Tree

(S, G) State Created OnlyAlong the Source TreeTraffic Flow

Shared Tree



78

Receiver

RPSource

Shared Tree

Source Tree RP Sends a Register-Stop Back to the First-Hop Router to Stop the Register Process(S, G) Register-Stop (unicast)

Traffic Flow

(S, G) Register (unicast)

(S, G) Traffic Begins Arriving at the RP via the Source Tree



79

Receiver

RPSource

Shared Tree

Source Tree

Traffic FlowSource Traffic Flows NativelyAlong SPT to RP

From RP, Traffic Flows Downthe Shared Tree to Receivers


PIM-SM SPT Switchover

80

Receiver

RP

(S, G) Join

Source

Source Tree

Shared Tree

Last-Hop Router Joins the Source Tree

Additional (S, G) State Is Created Along New Part of the Source Tree

Traffic Flow



81

Receiver

RPSource

Source Tree

Shared Tree

(S, G)RP-bit Prune

Traffic Begins Flowing Down the New Branch of the Source Tree

Additional (S, G) State Is Created Along the Shared Tree to Prune Off (S, G) Traffic

Traffic Flow



82

Receiver

RPSource

Source Tree

Shared Tree

(S, G) Traffic Flow Is Now Pruned Off of the Shared Tree and Is Flowing to the Receiver via the Source Tree

Traffic Flow



83

Receiver

RPSource

Source Tree

Shared Tree

(S, G) Traffic Flow Is No Longer Needed by the RP so It Prunes the Flow of (S, G) Traffic

Traffic Flow

(S, G) Prune



84

Receiver

RPSource

Source Tree

Shared Tree

(S, G) Traffic Flow Is Now Only Flowing to the Receiver via a Single Branch of the Source Tree

Traffic Flow


– PIM Frequently Forgotten Fact

The default behavior of PIM-SM (ASM) is that

routers with directly connected members will

join the shortest path tree as soon as they

detect a new multicast source.”

85


Click to edit source

“Fuggidaboudit!”“Fuggidaboudit!”

Source: “The Wiseguys’s Guide to IP Multicast”, ©2005, T. Soprano

It does “Flood & Prune” without any Joins!

It can meltdown your network and blackhole your traffic!

86

But what about PIM Dense Mode??


RP Choices


How Does the Network Learn RP Address?

• Static configuration

– Manually on every router in the PIM domain

• AutoRP

– Originally a Cisco® solution

– Facilitated PIM-SM early transition

• BSR

– draft-ietf-pim-sm-bsr

88


Static RPs

89

• Hard-configured RP address

‒ When used, must be configured on every router

‒ All routers must have the same RP address

‒ RP failover 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!)

‒ Override keyword “overrides” auto-RP information

• Default: auto-RP learned info takes precedence


Auto-RP – From 10,000 Feet

Announce Announce

An

no

un

ce

An

no

un

ce

Announce Announce

An

no

un

ce

An

no

un

ce

Announce

RP-Announcements Multicast to the

Cisco Announce (224.0.1.39) Group

A

C DC-RP

1.1.1.1

C-RP

2.2.2.2

B

MA MA

90


A

C DC-RP

1.1.1.1

C-RP

2.2.2.2

B

MA MA

Auto-RP – From 10,000 Feet

Discovery

RP-Discoveries Multicast to the

Cisco Discovery (224.0.1.40) Group

91


E

G

A

BSR – From 10,000 Feet

B C

C-BSR

F

C-BSR

D

C-BSR

BSR Election Process

BSR Msgs

BSR Msgs Flooded Hop-by-Hop

92



Highest Priority

C-BSR

Is Elected as

BSR

BSR

E

A

B C

FD

G

93


BSR

C-RP


C-RP

E

A

B C

FD

G

94


A

C-RPC-RP


BSR Msgs

BSR Msgs Containing RP-SET

Flooded Hop-by-Hop

BSR

E

B C

FD

G

A

95


Multicast at Layer2


L2 Multicast Frame Switching

• 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 which group(s) of multicast traffic

• Dynamic configuration of these entries would cut down on user administration

• Problem: Layer 2 Flooding of Multicast Frames

97

PIM

Multicast M



• IGMPv3 reports sent to a special link-local group (224.0.0.22)

– Switches listen to just this group• Only contains IGMP control traffic – no multicast data traffic

– Permits low-end switches to easily implement IGMP snooping• By just joining/listening to that link-local Group

– Switch examines contents of IGMP messages • To determine which ports want what Multicast traffic

• Adds entries to TCAM as appropriate

• All IGMPv3 hosts send complete update of desired flows– i.e. No Host Suppression

– Enables switch to perform complete individual host/port tracking

• IGMP Snooping

98



• IGMP Join/Leave packets sent to same Group Address as Multicast data

– Not to a separate IGMP Control address (e.g. 224.0.0.22)

– Switch CPU must wade through all Multicast Data packets looking for IGMP packets

– Requires special ($$$) hardware/ASICs to avoid impact to the switch

• Impact on older low-end, Layer 2 switches w/o special hardware

– Must process all Layer 2 multicast packets

– Admin load increases with multicast traffic load

– Often results in switch meltdown• “It worked just fine when we tested it with just some Multicast pings!”

• Older IGMPv1–v2 Snooping

99


Interdomain IP Multicast


MP-BGP Overview

• Originally 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

– That’s PIM’s job

• Same path selection and validation rules

– AS-Path, LocalPref, MED…

• MP-BGP: Multiprotocol BGP

101


MP-BGP Overview

• Separate BGP tables maintained

– Unicast prefixes for unicast forwarding

– Unicast prefixes for multicast RPF checking

• AFI = 1, Sub-AFI = 1

– Contains unicast prefixes for unicast forwarding

– Populated with BGP unicast NLRI

• AFI = 1, Sub-AFI = 2

– Contains unicast prefixes for RPF checking

– Populated with BGP multicast NLRI

102


MBGP Overview

• 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

• MBGP Allows Divergent Paths and Policies

103


Inter-domain SSM Multicast – Simple!

104

Domain C

Domain B

Domain D

Domain E

Domain ASource in 232/8

Receiver LearnsS and G Out of Band, i.e., Webpage

Receiver

Source “S”

MP-BGP Peering


MP-BGP Peering

Inter-domain SSM Multicast – Simple!

105

Domain C

Domain B

Domain D

Domain E

Domain A

Data flows natively along the interdomain source tree

ReceiverMulticast Traffic

Source in 232/8

Source “S”


Inter-domain ASM

Really??


Inter-domain ASM Issues

• Global Group Address Allocation/Management

– With ASM we have to make sure that we use unique Groups• Otherwise we start mixing up the Multicast flows

– Solution(?): GLOP Addressing• 233.0.0.0–233.255.255.255

• Put your ASN in the middle two Octets

• Provides /24 group prefix per ASN

• How do we do Inter-domain Source Discovery?

– Can we all agree on what domain “owns” the RP?• And for which Global Multicast Group??

– GLOP Addressing?

– Why not have RP’s in each domain “share” Source information?

– Solution: Multicast Source Discovery Protocol (MSDP)

107


MSDP – Multicast Source Discovery Protocol

• RFC 3618

• ASM only

– RPs knows about all sources in their domain• Sources cause a “PIM Register” to the RP

• Tell RPs in other domains of it’s sources– Via MSDP SA (Source Active) messages

– RPs 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

108


MSDP OverviewMSDP Example

109

Domain C

Domain B

Domain D

Domain E

Domain A

MSDP Peers Join (*, 233.3.2.1)

RP

RP

RP

RP

RP

Receiver

ASN770GLOP: 233.3.2.0/24



110

Domain C

Domain B

Domain D

Domain E

SA

SA

SASA

SA

SA

Source Active

Messages

SA

Domain A

MSDP Peers

Register

8.1.1.1, 233.3.2.1

RP

RP

RP

RP

RP

Source

Receiver

ASN770GLOP: 233.3.2.0/24

SA Message

8.1.1.1, 233.3.2.1

SA Message

8.1.1.1, 233.3.2.1



111

Domain C

Domain B

Domain D

Domain E

Domain A

MSDP Peers

RP

RP

RP

RP

RP

Source

Receiver

ASN770GLOP: 233.3.2.0/24



112

Domain C

Domain B

Domain D

Domain E

Domain A

Multicast Traffic

MSDP Peers

RP

RP

RP

RP

RP

Source

Receiver

ASN770GLOP: 233.3.2.0/24



113

Domain C

Domain B

Domain D

Domain E

Domain A

MSDP Peers

RP

RP

RP

RP

RP

Source

Receiver

ASN770GLOP: 233.3.2.0/24

Multicast Traffic



114

Domain C

Domain B

Domain D

Domain E

Domain A

MSDP Peers

RP

RP

RP

RP

RP

Source

ASN770GLOP: 233.3.2.0/24

ReceiverMulticast Traffic


Intra-domain uses for MSDP

• Anycast-RP

– Redundant RP technique for ASM which uses MSDP for RP synchronization

• Uses single 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 and receivers join/register with closest RP• Closest RP determined from the unicast routing table

• 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

115


Anycast RP – Overview

116

MSDP

RecRec RecRec

Src Src

SA SAA

RP1

10.1.1.1B

RP2

10.1.1.1

X


Anycast RP – Overview

117

RecRec RecRec

SrcSrc

A

RP1

10.1.1.1B

RP2

10.1.1.1

X


Internet IP Multicast

• We can build multicast distribution trees.

‒ PIM SSM

• We can RPF on Inter-domain Sources

‒ MP-BGP

• We no longer need (or want) network-based source discovery

‒ SSM

• So Inter-domain IP Multicast is in every home, right?

118


Then What’s Missing??!!

• Without an overlay mechanism, Multicast in the Internet is an all or nothing solution

– Each receiver must be on an IP multicast-enabled path

– Many core networks have IP multicast-enabled, but few edge networks accept multicast transit traffic

– Dr. Deering had tunneling in the original solution (DVMRP – now outdated)

• Multicast-aware content owners

– Forced to provide unicast streams to gain audience size

• For live content, Unicast cannot scale dynamically

– Splitters/caches just distribute the problem• Still has a cost per user

• We need a way to “Tunnel” through non-Multicast domains!

119


Automatic Multicast Tunneling


AMT—Automatic Multicast Tunneling

• Automatic IP multicast without explicit tunnels

– RFC7450 - Automatic Multicast Tunneling

• Allow multicast content distribution to extend to unicast-only connected receivers

– Bring the flat scaling properties of multicast to the Internet

• Provide the benefits of multicast wherever multicast is deployed

– Let the networks which have deployed multicast benefit from their deployment

• Work seamlessly with existing applications

– No OS kernel changes

121

https://www.rfc-editor.org/rfc/rfc7450.txt


Native Interdomain Multicast (SSM)

122

Mcast-Enabled ISP

Unicast-Only Network

Content Owner

Mcast-Enabled Local Provider

Mcast Traffic

Mcast Join

As long as IP Multicast is enabled on every router from the source to the receivers, the benefits of IP Multicast are realized


Native Interdomain Multicast (SSM)

123

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

The benefits being an unlimited number of Receivers can be served with a single stream of content at no additional costs


AMT – Automatic Multicast Tunneling

124

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

AMT Messages

The AMT Anycast Address Allows for All AMT Gateways to Find the “Closest” AMT Relay— the Nearest Edge of the Multicast Topology of the Source

Once the Multicast Join times-out, an AMT Relay Discovery issent from Host Gateway toward the Global AMT Anycast Address

AMT Relay

AMT Host

Gateway



125

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

AMT Messages

The AMT Relay sends back aRelay Advertisement (i.e. “use me”).

AMT Relay

AMT Host

Gateway



126

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

AMT Messags

(S,G) is learned from the AMT Join Message,then (S,G) PIM Join is sent toward the Source

AMT Relay

AMT Host

Gateway

Note: AMT Join/Leaves arereally IGMP/MLD packetstunneled to/from Relay



127

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

AMT Relay Replicates Stream on Behalf of Downstream AMT Receiver, Adding a Unicast Header Destined to the Receiver

Ucast Stream

AMT Relay

AMT Host

Gateway

AMT Messages



128

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

Additional receivers are served by the AMT Relays; the benefits of IP Multicast are retained by the content owner and all enabled networks in the path.

Ucast Stream

AMT Relay

AMT Host

Gateway AMT Host

Gateways

AMT Messages



129

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

Ucast Stream

Creates an Expanding Radius of Incentive to Deploy Multicast

AMT Relay

AMT Host

Gateway AMT Host

Gateways

AMT Messages

Enables Multicast Content to a Large (Global) Audience



130

Mcast-Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

Ucast Stream


AMT Relay

AMT Host

Gateway AMT Host

Gateways

AMT Messages




131

Mcast-Enabled ISP Content Owner


Mcast Traffic

Mcast Join

Ucast Stream

AMT Relay

AMT Host

Gateway AMT Host

Gateways

AMT Messages




IPv6 Multicast


IPv4 vs. IPv6 Multicast

133

IP Service IPv4 Solution IPv6 Solution

Address Range 32-Bit, Class D 128-Bit (112-Bit Group)

RoutingProtocol-Independent

All IGPs and GBP4+

Protocol-Independent

All IGPs and BGP4+ with v6 Mcast SAFI

ForwardingPIM-DM, PIM-SM: ASM, SSM, BiDir

PIM-SM: ASM, SSM, BiDir

Group Management IGMPv1, v2, v3 MLDv1, v2

Domain Control Boundary/Border Scope Identifier

Interdomain Source DiscoveryMSDP Across Independent PIM

DomainsSingle RP Within Globally Shared

Domains


IPv6 Multicast Addressesper RFC 4291

1111 1111

128 bits

8 bits 8 bits

FF

Scope =

Flags

Scope Flags =P

FF

8

Flags

4

Scope

4

Group-ID

TR

T or Lifetime, 0 if Permanent, 1 if Temporary

P for Unicast-based Assignments

R for Embedded RP

Others Are Undefined and Must Be Zero

1 = interface-local

2 = link

4 = admin-local

5 = site

8 = organization

E = global

0, 3, F = reserved

Note: Other scopes (6, 7, 9-D)

are unassigned but can be

used

134


48 Bits

80 Bits Lost

IPv6 Layer 2 Multicast Addressing Mapping

Similar to IPv4: 5 bits are lost

(28 significant L3 multicast bits are mapped into 23 L2 MAC bits)

More than 1 multicast address (in fact 2^80) will map to the same MAC address.

For example: FF02::1 33-33-00-00-00-01FF3E::1 33-33-00-00-00-01

Pick multicast group addresses that give distinct multicast MAC addresses

• RFC 2464

FF

8

Flags

4

High-Order

80

Scope

4

Low-Order

32

33-33-xx-xx-xx-xx

Ethernet MAC Address

IPv6 Multicast Address112 Bits

135


FF

8

Flags

4

Network-Prefix

64

Scope

4

Group-ID

32

Plen

8

Rsvd

8

Unicast-based Multicast addressesRFC 3306

• RFC 3306 – Unicast-based Multicast Addresses

– Similar to IPv4 GLOP Addressing (233/8 + ASN = 256 group addresses)

– Solves IPv6 global address allocation problem.

– Flags = 00PTP = 1, T = 1 => Unicast-based Multicast address

– Example

Content provider’s unicast prefix

1234:5678:9abc::/48

Multicast address

FF3E:0030:1234:5678:9abc::1 (hex “30” is 48 bits)

136


IPv6 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.

– Multiprotocol BGP (MP-BGP)• Support for v6 mcast subaddress family

137


IPv6 Multicast Tree Building & Forwarding

• PIM-Sparse Mode (PIM-SM)

– RFC4601

• PIM Source Specific Mode (SSM)

– RFC3569 SSM overview (v6 SSM needs MLDv2)

– Unicast, prefix-based multicast addresses ff30::/12

– SSM range is ff3X::/96

• PIM Bi-Directional Mode (BiDir)

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

138


RP Mapping Mechanisms for IPv6

• Static RP assignment

• BSR

• Auto-RP—no current plans

• Embedded RP

139


Embedded RP Addressing

• Proposed new multicast address type

– Uses unicast-based multicast addresses (RFC 3306)

• RP address is embedded in multicast address

• Flag bits = 0RPT

– R = 1, P = 1, T = 1 Embedded RP address

• Network-Prefix::RPadr = RP address

• For each unicast prefix you own, you now also own:

– 16 RPs for each of the 16 multicast scopes (256 total) with 2^32 multicast groups assigned to each RP (2^40 total)

• Multicast Address with Embedded RP address – RFC3956

FF

8

Flags

4

Network-Prefix

64

Scope

4

Rsvd

4

RPadr

4

Group-ID

32

Plen

8

140


Embedded RP Addressing – ExampleMulticast Address with Embedded RP address

FF76:0130:1234:5678:9abc::4321

FF

8

Flags

4

Network-Prefix

64

Scope

4

Rsvd

4

RPadr

4

Group-ID

32

Plen

8

1234:5678:9abc::1Resulting RP address

141


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• RFC 3810

• MLD snooping

– draft-ietf-magma-snoop-12.txt

142


Conclusion


Now You Know…

• Why multicast?

• Multicast fundamentals

• PIM protocols

• RP choices

• Multicast at Layer 2

• Inter-domain IP multicast

• IPv6 Multicast bits

144


Participate in the “My Favorite Speaker” Contest

• Promote your favorite speaker through Twitter and you could win $200 of Cisco Press products (@CiscoPress)

• Send a tweet and include

– Your favorite speaker’s Twitter handle <@Mr_Multicast>

– Two hashtags: #CLUS #MyFavoriteSpeaker

• You can submit an entry for more than one of your “favorite” speakers

• Don’t forget to follow @CiscoLive and @CiscoPress

• View the official rules at http://bit.ly/CLUSwin

• Promote Your Favorite Speaker and You Could be a Winner

145

http://bit.ly/CLUSwin


Complete Your Online Session Evaluation

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

• Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card.

• Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect.

146


Continue Your Education

• Demos in the Cisco Campus

• Walk-in Self-Paced Labs

• Table Topics

• Meet the Engineer 1:1 meetings

147

Thank you



Documents

Cisco Live 2014 - Amazon Web Services Tibco Multicast1 23. BRKIPM-1261-rev10 © 2015 Cisco and/or its affiliates. All rights reserved. ... BRKIPM-1261-rev10 © 2015 Cisco and/or its