BRKIPM-1261-Rev5 Introduction to IP Multicast

BRKIPM-1261-rev5 Introduction to IP Multicast

Beau Williamson CCIE R/S #1346 Emeritus CiscoLive Distinguished Speaker Twitter: @Mr_Multicast BRKIPM-1261 Cisco Spark

Questions? Use Cisco Spark to communicate with the speaker after the session

How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space

Cisco Spark spaces will be cs.co/clus17/#session ID available until July 3, 2017. E.g: session ID = BRKCOL-1800

• BRKIPM-2264 – Troubleshooting Multicast • Wednesday, Jun 28, 8:00 a.m. - 10:00 a.m. | Level 2, Mandalay Bay A

• BRKIPM-2249 – Segment Routing and Multicast • Monday, Jun 26, 4:00 p.m. - 5:30 p.m. | Level 3, Palm D

• LABCCIE-3010 – CCIE SP - Multicast VPN • M,Tu,W,Th, 10:00 a.m. - 10:45 a.m. | WISP 77

• LABMPL-2005 – Introduction to Multicast Label Distribution (mLDP) • M,Tu,W,Th, 10:00 a.m. - 10:45 a.m. | WISP 78

• LTRMPL-3103 – Next Generation Multicast VPN • Monday, Jun 26, 8:00 a.m. - 12:00 p.m. | MGM Grand, Level 1, Room 108

• BRKIPM-3017 – Advanced mVPN Deployment Models • Tuesday, Jun 27, 4:00 p.m. - 5:30 p.m. | Level 3, South Seas

• BRKSPV-2919 – Video Transport Architectures • Wednesday, Jun 28, 1:30 p.m. - 3:30 p.m. | Level 2, Reef B

BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 Session Goals • 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

BRKIPM-1261 Agenda

• Multicast Fundamentals Geekometer • Source-Specific Multicast (SSM) • Bidirectional Multicast (Bidir) • Any-Source Multicast (ASM) • ASM Redundant RP Choices • Multicast at Layer 2 • Multicast over MPLS – mLDP • Bit-Indexed Explicit Replication – BIER • Inter-domain IP Multicast • IPv6 Multicast

BRKIPM-1261 Multicast Fundamentals

BRKIPM-1261 7 Why Multicast Unicast vs. Multicast Scaling

Unicast

Server

Router Number of Streams

Multicast

Server

Router

• Any applications with multiple receivers • Server/Website replication • One-to-many or many-to-many • Reducing network/resource • Live video distribution overhead • More than multiple point-to-point flows • Collaborative groupware • Resource discovery • Periodic data delivery—“push” technology • Stock quotes, sports scores, magazines, • Distributed interactive simulation newspapers, adverts (DIS) • War games • Inter Data Center L2 Underlay • Virtual reality • VXLAN, etc. for BUM

• 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 complicated, scary and hard to understand!”

12.1.1.1

11.1.1.1

src addr: 10.1.1.1 A unique packet addressed to each 13.1.1.1 destination IP Address.

Multicast Group src addr: Address e.g. 224.1.1.1 10.1.1.1 Same packet addressed to “Group” destination address...

12.1.1.1

11.1.1.1

src addr: 10.1.1.1 A unique packet addressed to each 13.1.1.1 destination IP Address.

Multicast Group src addr: Address e.g. 224.1.1.1 10.1.1.1 ..replicated at each node along the tree.

Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

SourceSource Source AlwaysAddress the unique unicast origin address of 1.0.0.0 - 232.255.255.255 (Class A, B, C) the packet – same as unicast

DestinationDestination Destination Address 224.0.0.0 - 239.255.255.255 (Class D) Multicast Group Address Range

Options Padding

• 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. • i.e. Multicast relies on a dependable unicast infrastructure!

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

• 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

32 Bits

1110 28 Bits 239.255.0.1 5 Bits Lost

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

25 Bits 23 Bits 48 Bits

Be Aware of the 32:1 Address Overlap

32–IP Multicast Addresses

224.1.1.1 224.129.1.1 225.1.1.1 225.129.1.1 1–Multicast MAC Address . . . 238.1.1.1 0x0100.5E01.0101 238.129.1.1 239.1.1.1 239.129.1.1

• Every Multicast Flow can be identified by two components: • Source IP Address • The address of the Sender Multicast Flow from Source 2.2.2.2 to • Multicast Group Address Group 232.1.1.1 • 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 Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33

• How do Hosts Signal to Routers which flow they want? • IPv4: IGMP • IPv6: MLD

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

BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 21 IGMPv3 – Membership Report Packet Format 7 15 31 Type = 0x22 Reserved Checksum 7 15 31 Record Type Aux Data Len # of Sources (N) Reserved # of Group Records (M) Multicast Group Address Group Record [1] Source Address [1] Source Address [2] Group Record [2] . . . . Source Address [N] . Auxiliary Data Group Record [M] Record Type Include, Exclude, Chg-to-Include, # of Group Records (M) Chg-to-Exclude, Allow New Srcs, Number of Group Records in Report Block Old Srcs Group Records 1 - M Group address plus list of zero or # of Sources (N) more sources to Include/Exclude Number of Sources in Record (See Group Record format) Source Address 1- N Address of Source

Type = 0x11 IGMP Query 7 15 31 Max. Resp. Max. Resp. Time Type = 0x11 Checksum Max. time to send a response Code if < 128, Time in 1/10 secs if > 128, FP value (12.8 - 3174.4 secs) Group Address Group Address: Multicast Group Address S QRV QQIC Number of Sources (N) (0.0.0.0 for General Queries)

S Flag Source Address [1] Suppresses processing by routers QRV (Querier Robustness Value) Source Address [2] 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 Address [N] Source Address Address of Source

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 Type: Allow New (5) H3 Group: 232.1.1.1 Source: {2.2.2.2} Report (224.0.0.22)

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 Member Last reporter: 192.168.102.11 Group: 232.1.1.1 Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static, Hn Source: 2.2.2.2 V - Virtual, M - SSM Mapping, L - Local, Ac - Channel accounted towards access control limit) (Destination IP Address) Source Address Uptime v3 Exp CSR Exp Fwd Flags 2.2.2.2 00:01:14 00:02:08 stopped Yes R

192.168.102.10 192.168.102.11 192.168.102.12

H1 Type: Include (1) H2 Type: Include (1) H3 Type: Include (1) Group: 232.1.1.1 Group: 232.1.1.1 Group: 232.1.1.1 Source: {2.2.2.2} Source: {2.2.2.2} Source: {2.2.2.2} Report Report Report (224.0.0.22) (224.0.0.22) (224.0.0.22)

(224.0.0.1) Query Group: 0.0.0.0 Source: {} • Router sends periodic General Queries to All Hosts • General Query: Group=0, #Srcs=0

Member • All IGMP members respond Hn Group: 232.1.1.1 Source: 2.2.2.2

• Reports can contain multiple Group State records (Destination IP Address)

192.168.102.10 192.168.102.11 192.168.102.12

2 1 H1 H2 Type: Block Old (6) H3 Group: 232.1.1.1 Source: {2.2.2.2} Report (224.0.0.22)

(232.1.1.1) Query 3 Group: 232.1.1.1 Source: {2.2.2.2} 1. H2 leaves Group-Source 2. Sends “Block Old” Membership Report 3. Router sends Group-Source Query Member Hn Group: 232.1.1.1 • Group-Source Query: Group=G, #Srcs=N Source: 2.2.2.2 (Destination IP Address)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3 Type: Include Group: 232.1.1.1 Source: {2.2.2.2} 4 Report (224.0.0.22)

5 1. H2 leaves Group-Source 2. Sends “Block Old” Membership Report 3. Router sends Group-Source Query Member 4. A remaining member host sends report Hn Group: 232.1.1.1 Source: 2.2.2.2 5. Group-Source flow remains active (Destination IP Address)

192.168.102.10 192.168.102.11 192.168.102.12

6 H1 H2 H3 Type: Block Old (6) Group: 232.1.1.1 Source: {2.2.2.2} Report 7 (224.0.0.22)

(232.1.1.1) Query 8 Group: 232.1.1.1 Source: {2.2.2.2} 6. H3 leaves Group-Source 7. Sends “Block Old” Membership Report 8. Router sends Group-Source Query Member Hn Group: 232.1.1.1 Source: 2.2.2.2

(Destination IP Address)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3

6. H3 leaves Group-Source 7. Sends Remove Membership Report 8. Router sends Group-Source specific query Member Hn Group: 232.1.1.1 9. State times out. Group-Source flow pruned. Source: 2.2.2.2 (Destination IP Address)

• 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

BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 30 Unicast vs. Multicast Routing/Forwarding Multicast Routing & Forwarding • Destination Group address doesn’t directly indicate where to forward packet. • Forwarding State must be created to build trees to describe forwarding path.

• 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 (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!

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

• If you ever get confused by Multicast, just remember to . . . “Stand on your head!” your on “Stand

BRKIPM-1261 33 Source Specific Multicast (SSM) Concepts

• Assumes one-to-many model • Most Internet multicast fits this model • IP/TV also fits this model

• Hosts responsible for source discovery • Typically via some out-of-band mechanism • Web page, Content Server, etc.

• Hosts join a specific source within a group • Content identified by specific (S,G) • Dissimilar content sources can use same group “G” without fear of interfering with each other

• Last-hop router sends (S,G) join toward source • Only specified (S,G) flow is delivered to host

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 • This is where the Joins are to be 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.

Traffic to 232.1.1.1

Source 2.2.2.2

Receiver

Multicast Traffic

Traffic to 232.1.1.1

Source 2.2.2.2

IGMP “Join” (2.2.2.2, 232.1.1.1)

Receiver Forwarding State Multicast Traffic Mroute Entry

Traffic to 232.1.1.1

Source 2.2.2.2 PIM Join (2.2.2.2, 232.1.1.1)

Receiver Forwarding State Mroute Entry Multicast Traffic Mroute Entry

Traffic to 232.1.1.1

PIM Join (2.2.2.2, 232.1.1.1)

Source 2.2.2.2 Mroute Entry

Receiver Forwarding State Mroute Entry Multicast Traffic Mroute Entry

Traffic to 232.1.1.1

Source 2.2.2.2 Mroute Entry

Receiver Forwarding State Mroute Entry Multicast Traffic Mroute Entry

Traffic to 232.1.1.1 IGMP “Join” (2.2.2.2, 232.1.1.1)

Source Receiver 2.2.2.2 Mroute Entry Mroute Entry

Receiver Forwarding State Mroute Entry Multicast Traffic Mroute Entry

Traffic to 232.1.1.1

PIM Join (2.2.2.2, 232.1.1.1)

Source Receiver 2.2.2.2 Mroute Entry Mroute Entry

Receiver Forwarding State Mroute Entry Multicast Traffic Mroute Entry

Traffic to 232.1.1.1

Source Receiver 2.2.2.2 Mroute Entry Mroute Entry

Receiver Forwarding State Mroute Entry Multicast Traffic Mroute Entry

Mroute Entry

Traffic to show ip mroute 232.1.1.1 232.1.1.1 (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 0/1, Forward/Sparse, 3w1d/00:02:40 Ethernet 0/2, Forward/Sparse, 2w0d/00:02:33

Source Receiver 2.2.2.2 Mroute Entry Mroute Entry

Receiver Forwarding State Multicast Traffic Mroute Entry

Mroute Entry

Traffic to show ip mroute 232.1.1.1 232.1.1.1 (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 Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33

Source Receiver 2.2.2.2

Receiver Forwarding State Multicast Traffic This type of Multicast has a special name: Source Specific Multicast (SSM)

• Based on source address SRC 10.1.1.1 • Best path to source found in unicast route table A • Determines where to send join Join • Joins continue towards source to build multicast tree C • Multicast data flows down tree B

Join D

E0 E1 E E2 Unicast Route Table Network Interface R1 10.1.0.0/24 E0

• Based on source address SRC 10.1.1.1 • Best path to source found in unicast route table A • Determines where to send join Join

• Joins continue towards source to build multicast tree C • Multicast data flows down tree B Join R2 D

E0 E1 E E2

• What if we have equal-cost paths? SRC 10.1.1.1 • We can’t use both

• Tie-breaker A • Use highest next-hop IP address

B C

D E 1.1.1.1 Join 1.1.2.1 E0 E1 F Unicast Route Table E2 Network Intfc Nxt-Hop 10.1.0.0/24 E0 1.1.1.1 R1 10.1.0.0/24 E1 1.1.2.1

Multicast route entries are in (S,G) form. rtr-a#show ip mroute 232.1.1.1 (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 Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33 Incoming interface points upstream toward the root of the tree (i.e. Source)

OIL entries are refreshed by downstream Outgoing interface list (OIL) is where receivers receivers roughly every 3 minutes or the have joined downstream and where packets entry times out. [i.e. Soft State] will be replicated and forwarded downstream.

rtr-a#show ip mroute 232.1.1.1 (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 Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33

rtr-b#show ip route 232.1.1.109 % Network not in table

Multicast Group addresses are NEVER in the unicast route table.

POP QUIZ QUESTION #1!!

How is the Incoming Interface and RPF Neighbor determined?

ANSWER:

The best route to the Source IP Address is looked up in the route table and the RPF Neighbor is the next upstream PIM neighbor.

POP QUIZ QUESTION #2!!

What causes interfaces to be added to the Outgoing Interface List?

ANSWER:

IGMP “Joins” or PIM Joins that are received on that interface.

• Enable Multicast Routing on every router ip multicast routing

• Configure every interface for Multicast • IOS-XR – On by default • When ip multicast routing is configured • IOS – ip pim sparse mode

• Configure SSM for all Multicast groups ip pim ssm range 10 access-list 10 permit 224.0.0.0 15.255.255.255

• Use DNS SSM-Mapping for non-IGMPv3 compatible apps on edge interfaces ip igmp ssm-map enable • Static config-based SSM Mapping is also possible

DNS Record Format: 3.2.1.232 IN A 172.23.20.70 Reverse DNS lookup for PIM (S,G) join group G

PIM (S,G) join DNS response: Group G -> Source S

IGMPv2 join

Set Top Box (STB)

• 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.)

“Multicast is complicated, scary and hard to understand!”

See there . . .

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

But wait, my network has Many:Many Multicast applications!

How do I support them?

BRKIPM-1261 59 Bidirectional (BiDir) PIM Concepts Idea:

• Use a common “Shared” Tree to connect all Sources and Receivers.

• Root this “Shared” Tree at a point in the network called the Rendezvous Point (RP)

• Traffic flows up the tree from Sources to the RP and then down the tree to Receivers • 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

• This is like a constrained L3 Spanning-Tree for the Group • Constrained because it only “spans” to Sources and Receivers for the Group

BRKIPM-1261 62 IGMPv3 – Joining a Shared Tree for All Sources

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 Type: Exclude (2) H3 Group: 239.1.2.21 Source List: {} Report (224.0.0.22)

Router#sh ip igmp groups 239.1.2.21 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: 239.1.2.21 Flags: Uptime: 00:00:22 Group mode: EXCLUDE (Expires: 00:02:49) Last reporter: 192.168.102.11 Source list is empty

E0 (DF)

E0 E0

E F E1 (DF) E1 (DF)

E0 E0 E0 E0

A B C D IGMP (*,G) E1 (DF) E1 (DF) E1 (DF) E1 (DF) Join

Receiver 1

E0 (DF)

E0 E0

E F E1 (DF) E1 (DF)

E0 E0 E0 E0

A B C D E1 (DF) E1 (DF) E1 (DF) E1 (DF)

(*, 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 Outgoing interface list: Receiver 1 Ethernet0, Bidir-Upstream/Sparse-Dense, 00:00:04/00:00:00 Ethernet1, Forward/Sparse-Dense, 00:00:04/00:02:55 Bidir State created in “D”

E0 (DF)

E0 E0

E F PIM (*,G) E1 (DF) E1 (DF) Join

E0 E0 E0 E0

A B C D E1 (DF) E1 (DF) E1 (DF) E1 (DF)

(*, 224.1.1.1), 00:00:04/00:00:00, RP 172.16.21.1, flags: BC Bidir-Upstream: Ethernet0, RPF nbr 172.16.7.1 Outgoing interface list: Receiver 1 Ethernet0, Bidir-Upstream/Sparse-Dense, 00:00:04/00:00:00 Ethernet1, Forward/Sparse-Dense, 00:00:04/00:02:55 Bidir State created in “F”

RP PIM (*,G) E0 (DF) Join

E0 E0

E F E1 (DF) E1 (DF)

E0 E0 E0 E0

A B C D E1 (DF) E1 (DF) E1 (DF) E1 (DF)

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: B Bidir-Upstream: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Sparse-Dense, 00:00:04/00:02:55 Receiver 1

Branch of Shared Tree is now built from RP down to Receiver 1

E0 (DF)

E0 E0

E F E1 (DF) E1 (DF)

E0 E0 E0 E0

A B C D E1 (DF) E1 (DF) E1 (DF) E1 (DF)

(*, 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 Source Outgoing interface list: Receiver 1 Ethernet0, Bidir-Upstream/Sparse-Dense, 00:32:20/00:00:00 Arriving Traffic from Source causes Router “A” to create (*, G) State

E0 (DF)

E0 E0

E F E1 (DF) E1 (DF)

E0 E0 E0 E0

A B C D E1 (DF) E1 (DF) E1 (DF) E1 (DF)

(*, 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 Outgoing interface list: Source Ethernet0, Bidir-Upstream/Sparse-Dense, 00:32:20/00:00:00Receiver 1 Arriving Traffic Causes Router “E” to create (*, G) State

E0 (DF)

E0 E0 Bidir State in RP E (*, 224.1.1.1),F 00:32:20/00:02:59, RP 172.16.21.1, flags: B E1 (DF) E1 (DF) Bidir-Upstream: Null, RPF nbr 0.0.0.0 Outgoing interface list: E0 E0 Ethernet0,E0 Forward/SparseE0-Dense, 00:00:04/00:02:55

A B C D E1 (DF) E1 (DF) E1 (DF) E1 (DF)

Source Receiver 1 RP already has (*, G) State

E0 (DF)

E0 E0

E F E1 (DF) E1 (DF)

E0 E0 E0 E0

A B C D E1 (DF) E1 (DF) E1 (DF) E1 (DF)

Source Receiver 1 Traffic flows up the Shared Tree ...... and then back down the Shared Tree

• Configure every interface for Multicast • IOS-XR – On by default • When ip multicast routing is configured • IOS – ip pim sparse mode

• Enable Bidir Multicast Routing on every router ip pim bidir enable

• Configure address of Bidir RP for all Multicast groups ip pim rp-address bidir

Primary injecting RP Secondary injecting RP Phantom RP 1.1.1.1 ip multicast-routing ip multicast-routing interface Loopback0 interface Loopback0 ip address 11.0.0.1 255.255.255.255 ip address 11.0.0.2 255.255.255.255 ip pim sparse-mode ip pim sparse-mode router ospf 11 router ospf 11 redistribute static subnets redistribute static subnets ip route 1.1.1.1 255.255.255.255 Loopback0 ip route 1.1.1.0 255.255.255.254 Loopback0 ip pim bidir-enable ip pim bidir-enable ip pim rp-address 1.1.1.1 bidir ip pim rp-address 1.1.1.1 bidir

BRKIPM-1261 74 Biggest Multicast Complicating Factor Network-Based Source Discovery • 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

• 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 just BiDir Multicast?

BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 75 Multicast Complicating Factor 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 maybe just use Bidir Multicast (Bidir) • A bit more complicated than Source Specific Multicast but easier than ASM.

BRKIPM-1261 77 PIM-SM Shared Tree Join

(*, G) State Created Only (*, G) Join Along the Shared Tree Shared Tree

Receiver

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

RP Source

(S, G) Traffic Begins Arriving at Traffic Flow the RP via the Source Tree Shared Tree Source Tree RP Sends a Register-Stop Back (S, G) Register (unicast) Receiver to the First-Hop Router to Stop (S, G) Register-Stop (unicast) the Register Process

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

RP Source

Last-Hop Router Joins the Traffic Flow Source Tree Shared Tree Additional (S, G) State Is Source Tree Created Along New Part of the (S, G) Join Receiver Source Tree

RP Source

Traffic Begins Flowing Traffic Flow Down the New Branch of Shared Tree the Source Tree Source Tree Additional (S, G) State Is Created (S, G)RP-bit Prune Receiver Along the Shared Tree to Prune Off (S, G) Traffic

RP Source

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

RP Source

(S, G) Traffic Flow Is No Traffic Flow Longer Needed by the RP so It Shared Tree Prunes the Flow of (S, G) Source Tree Traffic (S, G) Prune Receiver

RP Source

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

• Configure every interface for Multicast • IOS-XR – On by default • When ip multicast routing is configured • IOS – ip pim sparse mode

• Configure address of ASM RP for all Multicast groups ip pim rp-address

BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 87 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.”

– PIM Frequently Forgotten Fact

“Fuggidaboudit“Fuggidaboudit!” !”

BRKIPM-1261 90 MP-BGP Overview MP-BGP: Multiprotocol BGP

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

• Separate BGP tables maintained • Unicast prefixes for Unicast forwarding • Unicast prefixes for Multicast RPF calculation

• 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 Multicast RPF calculation • Populated with BGP Multicast NLRI

• 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

Domain E MP-BGP Peering

Domain C Receiver Receiver Learns S and G Out of Domain B Band, i.e., Webpage

Domain D

Source in 232/8 Source “S” Domain A

Domain E MP-BGP Peering

Multicast Traffic Domain C Receiver Data flows natively along the interdomain Domain B source tree

Domain D

Source in 232/8 Source “S” Domain A

• Deciding who (what SP/ASN) owns RP was problematic.

• Some SP’s wanted their own RP.

• Other SP’s didn’t want RP’s in their network.

• No consensus was ever reached.

• Inter-domain Bidir never got off the ground.

• Don’t hold your breath looking for Inter-domain Bidir support from Vendors/SPs

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

• RFC 3618 - Multicast Source Discovery Protocol (MSDP)

• PIM ASM only solution • RPs knows about all Sources in their domain • Sources cause a “PIM Register” to the RP • RP tells RPs in other domains of it’s Sources • Uses “MSDP SA” (Source Active) messages

• RPs know about existence of Receivers in their domain • Receivers cause a “(*, G) Join” to the RP • RP can join the Source tree in the peer domain • Uses normal PIM “(S, G) Join”

MSDP Peers RP Join (*, 233.3.2.1) Receiver Domain C

RP Domain B

ASN770 Domain D GLOP: 233.3.2.0/24 RP

Domain A

MSDP Peers RP SA Source Active SA Receiver Messages Domain C

RP SA Domain B SA SA

SA RP

Domain D SA Message SA ASN770 SA Message GLOP: 233.3.2.0/24 8.1.1.1, 233.3.2.1 RP 8.1.1.1, 233.3.2.1

Source Domain A Register 8.1.1.1, 233.3.2.1

MSDP Peers RP

Receiver Domain C

RP Domain B

ASN770 Domain D GLOP: 233.3.2.0/24 RP

Source Domain A

MSDP Peers RP

Multicast Traffic Receiver Domain C

RP Domain B

ASN770 Domain D GLOP: 233.3.2.0/24 RP

Source Domain A

MSDP Peers RP

Multicast Traffic Receiver Domain C

RP Domain B

ASN770 Domain D GLOP: 233.3.2.0/24 RP

Source Domain A

MSDP Peers RP

Multicast Traffic Receiver Domain C

RP Domain B

ASN770 Domain D GLOP: 233.3.2.0/24 RP

Source Domain A

BRKIPM-1261 106 Auto-RP – From 10,000 Feet

MA MA

A B

Announce Announce

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

MA MA A B

C D 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

• Candidate RPs ip pim send-rp-announce scope [group-list ] [interval ] [ bidir ] • Primary address of is used as RP-address • If goes down, C-RP messages are not sent (use Loopback)

• Mapping Agents ip pim send-rp-discovery [] scope [interval ] • Configure as Loopback Interface. • Same reason recommended for C-RP

• Auto-RP Listeners ip pim autorp listener • Enable on all routers (even MA and C-RPs) • Enables all routers to listen to (and forward) RP-Announce and RP-Discover messages • Allowing us to move away from old IOS sparse-dense operation.

BSR Election Process

C-BSR C-BSR C-BSR A D F

B C

BSR Msgs E BSR Msgs Flooded Hop-by-Hop

Highest Priority C-BSR Is Elected as BSR

BSR

A D F

B C

BSR

A D F

C-RP B C C-RP

BSR

A D F

C-RP B C C-RP

BSR Msgs E BSR Msgs Containing RP-SET Flooded Hop-by-Hop

• Candidate-BSR (C-BSR) ip pim bsr-candidate [accept-rp-candidate ] • BSR election: • C-BSR with highest becomes BSR • Tie-breaker: Highest-IP-Address • Preemption by better C-BSR at any time

• Candidate RP (C-RP) ip pim rp-candidate [group-list | bidir | interval | priority ] • All parameters as in AutoRP C-RP – except

• Anycast-RP w/MSDP • 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 • First/Last hop Routers 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

Src Src

X RP1 MSDP RP2 A SA SA B 10.1.1.1 10.1.1.1

Rec Rec Rec Rec

Src Src

X RP1 RP2 A B 10.1.1.1 10.1.1.1

Rec Rec Rec Rec

Src Src

RP1 MSDP RP2 A (Established via TCP) B 10.1.1.1 10.1.1.1

interface Loopback1 interface Loopback1 description -> anycast RP description -> anycast RP ip address 10.1.1.1Rec255.255.255.255 ip addressRec 10.1.1.1 255.255.255.255 ip pim sparse-mode Rec ip pim sparse-dense-mode Rec

interface Loopback2 interface Loopback2 ip address 10.10.10.1 255.255.255.255 ip address 10.10.10.2 255.255.255.255

ip msdp peer 10.10.10.2 connect-source Loopback10 ip msdp peer 10.10.10.1 connect-source Loopback20 ip msdp originator-id Loopback2 ip msdp originator-id Loopback2

ip pim rp-address 10.1.1.1 ip pim rp-address 10.1.1.1

• RFC4610 – Anycast-RP w/PIM only • Redundant RP technique for ASM which uses PIM Registers for RP synchronization

• PIM Register messages exchanged between all RPs • Informs RPs of Sources in other parts of network • RPs join SPT to active Sources as necessary

Src

RP1 PIM Anycast RP Neighbors RP2 A PIM Register PIM Register Stop B 10.1.1.1 10.1.1.1

Rec Rec Rec Rec

Src Src

X RP1 PIM Anycast RP Neighbors RP2 A PIM Register Stop PIM Register B 10.1.1.1 10.1.1.1

Rec Rec Rec Rec

Src Src

X RP1 RP2 A B 10.1.1.1 10.1.1.1

Rec Rec Rec Rec

RP1 PIM Anycast RP Neighbors RP2 A B 10.1.1.1 10.1.1.1

interface Loopback1 interface Loopback1 description -> anycast RP description -> anycast RP ip address 10.1.1.1 255.255.255.255 ip address 10.1.1.1 255.255.255.255 ip pim sparse-mode ip pim sparse-mode

interface Loopback2 interface Loopback2 ip address 10.10.10.1 255.255.255.255 ip address 10.10.10.2 255.255.255.255

ip pim anycast-rp 10.1.1.1 10.10.10.1 ip pim anycast-rp 10.1.1.1 10.10.10.1 ip pim anycast-rp 10.1.1.1 10.10.10.2 ip pim anycast-rp 10.1.1.1 10.10.10.2

ip pim rp-address 10.1.1.1 ip pim rp-address 10.1.1.1

BRKIPM-1261 124 L2 Multicast Frame Switching

Problem: Layer 2 Flooding of Multicast Frames

• Typical L2 switches treat multicast traffic as unknown or broadcast and must “flood” the frame to every port PIM • 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 Multicast M

• L2 switches now “listen to” and intercept IGMP & PIM packets

Switch# show ip igmp snooping mrouter Type: S - Static, D – Dynamic

Vlan Router-port Type Uptime Expires 143 Eth8/11 D 4w1d 00:04:59 e8/11

Po1

• L2 switches now “listen to” and intercept IGMP & PIM packets

• Builds “multicast mac table”. Prevents flooding (like unicast) • Mrouter Ports: Ports connected to a PIM Router • Dynamically learned upon hearing IGMP Queries or PIM Hellos PIM • Forward IGMP joins, leaves & mcast data to this port towards PIM router • Member Ports: Ports that have received an IGMP join • Vlan: Vlan in which the above Member Port belongs • Multicast Group: Group the member port has joined.

e8/11 Switch# show ip igmp snooping groups Type: S - Static, D - Dynamic, R - Router port Vlan Group Address Ver Type Port list Po1 143 225.131.38.2 v2 D Po1

BRKIPM-1261 128 Multipoint Label Distribution Protocol – mLDP Why mLDP? • Customers running MPLS in their network want to run Multicast natively over MPLS

• MPLS forwarding plane is shared between unicast and multicast • i.e. unicast MPLS features are applied to multicast

• Separation of data plane and control plane has advantages

• MP2MP – Multi-Point to Multi-Point • Like a PIM Bidir tree

• MP LSP – Multi-Point LSP, either P2MP or MP2MP

• Label Mapping • Like a PIM Join

• Label Withdraw • Like a PIM Prune

• Simplification compared to PIM • No shared tree / source tree switchover • No (S,G,R) prune’s • No DR election • No PIM registers • No Asserts • No Periodic messaging • No Auto-RP/BSR

• mLDP is an extension to the IETF LDP RFC 3036.

• Procedures are documented in IETF RFC 6388

• Joined effort by multiple vendors and customers.

• mLDP reuses LDP protocol packets and neighbor adjacencies.

• mLDP is a client of the LDP infrastructure.

• mLDP allows the creation of P2MP and MP2MP LSPs • We refer to these as Multipoint LSPs (MP LSPs).

BRKIPM-1261 133 BIER history

• A team was formed to investigate solutions for multicast in the context of Segment Routing.

• Encoding a Sourced routed Multicast tree path using MPLS labels is difficult.

• The packet header would get very large, and its very hard to parse such header.

• Only encode the end-receivers in the packet header. • Not the intermediate nodes.

• Assign end-receivers a Bit Position from a Bit String. • The smallest identifier possible.

• Encode the Bit String in the packet header. • Using some sort of encapsulation.

• Create a Bit Forwarding Table on all BIER nodes to allow multicast packet forwarding using the Bit String in the packet. • Derived from the RIB, SPF based.

• We call it, Bit Indexed Explicit Replication (BIER).

A/32

B/32

BIER Domain

D/32 6 5 4 3 2 1

BitString/BFR-ID

C/32 F/32 E/32 1. Assign a unique Bit Position/BFR-ID1 from a BitString to each BFER2 in the domain.

A/32

B/32 LSA 6 - A/32

LSA LSA 5 – B/32 BIER Domain 1 – E/32 LSA D/32 6 5 4 3 2 1 LSA LSA 4 – C/32 3 – E/32 2 – D/32 BitString/BFR-ID

C/32 F/32 E/32 1. Assign a unique Bit Position/BFR-ID1 from a BitString to each BFER2 in the domain. 2. BFERs flood their BFR-Id/BFR Prefix to the Domain using the IGP (OSPF, ISIS)

A/32

B/32 BitMask Nbr 0011 A 0100 B 1000 C D/32

C/32 F/32 E/32 3. Each router in the BIER Domain builds Bit-Mask to BFR Prefix mapping table

1Bit-Position = BIER Forwarding Router-ID 2BFER = Bit-Forwarding Egress Router BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 138 BIER Bit-Mask Forwarding Table BIER Bit-Mask Forwarding Table is based on shortest path to each BFR-ID

BM Nbr BM Nbr BM Nbr 0111 B 0011 C 0001 D D 0100 E 0010 F BFR-ID 1 BS:0001 A B C

F E BFR-ID 2 BM Nbr BFR-ID 3 BS:0010 BS:0100 0011 C B

BM Nbr BM Nbr BM Nbr 0111 B 0011 C 0001 D AND D 0100 E 0010 F BFR-ID 1 0001 BS:0001 A B C

Suppose A leans about D’s interest, F in the blue multicast flow. E (via BGP, SDN, STATIC, etc…) BFR-ID 2 BM Nbr BFR-ID 3 BS:0010 BS:0100 0011 C B

BM Nbr BM Nbr BM Nbr 0111 B &0111 0011 C 0001 D AND D 0100 E 0010 F BFR-ID 1 0001 0001 BS:0001 A B C

• Result from the bitwise AND (&) between the Bit Mask in the packet and the Forwarding table is copied in the packet for F each neighbor. E • This is the key mechanism to prevent BFR-ID 2 duplication. BM Nbr BFR-ID 3 BS:0010 BS:0100 0011 C B

BM Nbr BM Nbr BM Nbr 0111 B &0111 0011 C &0011 0001 D &0001 AND AND AND D 0100 E 0010 F BFR-ID 1 0001 0001 0001 BS:0001 A B C

BM Nbr BM Nbr BM Nbr 0111 B 0011 C 0001 D AND D 0100 E 0010 F BFR-ID 1 0111 BS:0001 A B C

Suppose A leans about D, E and F’s interest, F in the blue multicast flow. E (via BGP, SDN, STATIC, etc…) BFR-ID 2 BM Nbr BFR-ID 3 BS:0010 BS:0100 0011 C B

Nbr Nbr Nbr 0111 B &0111 0011 C &0011 0001 D &0001 AND AND AND D 0100 E &0100 0010 F &0010 BFR-ID 1 0111 0111 0011 BS:0001 A B C

Nbr Nbr Nbr 0111 B &0111 0011 C &0011 0001 D &0001 AND AND AND D 0100 E &0100 0010 F &0010 BFR-ID 1 0111 0111 0111 BS:0001 A B C

Duplicate Packets!! 0111 F E BFR-ID 2 Nbr BFR-ID 3 BS:0010 BS:0100 0011 C AND B

BRKIPM-1261 146 IPv4 vs. 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 GBP4+ with v6 Mcast SAFI PIM-DM, PIM-SM: Forwarding PIM-SM: ASM, SSM, BiDir ASM, SSM, BiDir

Group Management IGMPv1, v2, v3 MLDv1, v2

Domain Control Boundary/Border Scope Identifier

MSDP Across Independent PIM Single RP Within Globally Shared Interdomain Source Discovery Domains Domains

1111 1111 Flags T or Lifetime, 0 if Permanent, 1 if Temporary P for Unicast-based Assignments F F R P T Scope Flags = R for Embedded RP Others Are Undefined and Must Be Zero 8 bits 8 bits 1 = interface-local 2 = link 4 = admin-local Note: Other scopes (6, 7, 9-D) Scope = 5 = site are unassigned but can be 8 = organization used E = global 0, 3, F = reserved

BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 148 IPv6 Layer 2 Multicast Addressing Mapping RFC 2464 IPv6 Multicast Address 112 Bits 8 4 4 80 32 FF Flags Scope High-Order Low-Order

80 Bits Lost • Similar to IPv4: 5 bits are lost • (28 significant L3 multicast bits are mapped into 23 L2 MAC bits) 33-33-xx-xx-xx-xx 48 Bits • More than 1 multicast address (in fact 2^80) will map to the Ethernet MAC Address same MAC address. • For example: FF02::1  33-33-00-00-00-01 FF3E::1  33-33-00-00-00-01

• Pick multicast group addresses that give distinct multicast MAC addresses

• RFC 3306 – Unicast-based Multicast Addresses – Similar to IPv4 GLOP Addressing (233/8 + ASN = 256 group addresses) – Solves IPv6 global address allocation problem. – Flags = 00PT P = 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)

• 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) • RFC5015 – Bidirectional PIM (BIDIR-PIM)

• Static RP assignment

• BSR

• Embedded RP

• No Auto-RP! • No current plans for Auto-RP at Cisco or IETF

• No Anycast RP w/MSDP! • Because MSDP is not supported in IPv6 • No current plans for IPv6 MSDP at Cisco or IETF

8 4 4 4 4 8 64 32 FF Flags Scope Rsvd RPadr Plen Network-Prefix Group-ID

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

8 4 4 4 4 8 64 32 FF Flags Scope Rsvd RPadr Plen Network-Prefix Group-ID

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

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

• 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 • RFC4541 – Considerations for IGMP & MLD Snooping Switches

BRKIPM-1261 156 Now You Know…

• Multicast Fundamentals

• Source-Specific Multicast (SSM)

• Bidirectional Multicast (Bidir)

• Any-Source Multicast (ASM)

• ASM Redundant RP Choices

• Multicast at Layer 2

• Multicast over MPLS – mLDP

• Bit-Indexed Explicit Replication – BIER

• Inter-domain IP Multicast

• IPv6 Multicast

• Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 gift card. • Complete your session surveys through the Cisco Live mobile app or on www.CiscoLive.com/us.

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

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Lunch & Learn

• Meet the Engineer 1:1 meetings

• Related sessions

BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 159 Please join us for the Service Provider Innovation Talk featuring: Yvette Kanouff | Senior Vice President and General Manager, SP Business Joe Cozzolino | Senior Vice President, Cisco Services

Thursday, July 14th, 2016 11:30 am - 12:30pm, In the Oceanside A room

What to expect from this innovation talk • Insights on market trends and forecasts • Preview of key technologies and capabilities • Innovative demonstrations of the latest and greatest products • Better understanding of how Cisco can help you succeed

BRKIPM-1261 Thank you

BRKIPM-1261