Multicast Communications

Tarik Cicic

Head of Networks & Engineering

28.2.2020

Overview

• One-to-many communication, why and how

• Algorithmic approach:

• Steiner trees

• Practical algorithms

• Multicast tree types

• Basic concepts in multicast routing and protocols

• Recent development: BIER (RFC8279, Nov. 2017)

• Next week: Presentations 2

“Casts”

• Unicast: one-to-one

• Broadcast: one-to-all

• Multicast: one-to-group

• The group is a subset of “all”

• Most general notion

• Anycast: one-to-one-from-a-group

3

One-to-Many Communication

4

Router

Receiver 1

Receiver 2

Receiver 3

Sender

Sender needs to send the same information to all three receivers

3 transmissionsover the same link!

One-to-Many Communication

5

Router

Receiver 1

Receiver 2

Receiver 3

Sender

Sender needs to send the same information to all three receivers

Only onetransmission

IP Multicast Challenges

• Internet is designed for one-to-one communication• IP packet header contains one source and one destination

address•How to

• Identify a group of users wishing to receive same data• How the host tells the network it wishes to join a group• Route packets efficiently• Route between the networks

6

7

End-to-End Support

1. API– Multicast uses “Class D” addresses 224.0.0.0

– 239.255.255.255– Sessions are associated to these addresses

or “groups”

2. Host-network interface– Internet Group Management Protocol

(IGMP)

3. Network (routing)

Application

OS

Application

OS

Router

Router

Router

3 3Application

OS

1 1

1

2 2

2Main focus of this lecture

Graph-Algorithmic Background

1

Internal8

Problem Definition

• Network topology mapped to a graph G=(V, E)

• Problem:– Given a node set S Í V,– Create a spanning tree that

interconnects S

9

Steiner Trees

• Each link in the tree has an associated cost

• The minimal spanning tree we call Steiner tree

• Constructing this tree is a well-known NP-complete problem

10

3

1

3

32

3

1

2

1

2

2

1

1

11

4

1

4

22

3

Approximate Algorithms

11

3

1

3

32

3

1

2

1

2

2

1

1

11

4

1

4

22

3

7

6

10

7

7

5

6

7

51

1

Approximate Algorithms (2)

12

6

7

5

12

3

33

3 2

1

2

2

1

1

1

4

1

4

22

1

1

3

Cost:17

Optimal cost:14

Approximate Algorithms (3)

13

3

1

3

32

3

1

2

1

2

2

1

1

11

4

1

4

22

3

12

3

33

3 2

1

2

2

1

1

1

4

1

4

22

1

1

3

Optimal tree (cost 14) Heuristic tree (cost 17)

Spanning Trees in Practice

•Creating a minimal spanning tree is an NP-complete problem

•More than one metric adds to the complexity (cost/delay optimization)

•Research shows that “best effort trees” are often quite good (20% costlier on average)

14

Spanning Trees in Practice (2)

•Practical algorithm:• Use communication delay or # hops as metric• Find the (unicast) shortest path between a special node and

all other nodes in the group G•This special “root” node can be:

• An administratively assigned node:à Core Based Tree (CBT)• Data source:à Shortest Path Tree (SPT)

15

Core Based and Shortest Path Trees

16

3

1

3

32

3

1

2

1

2

2

1

1

11

4

1

4

22

3

3

1

3

32

3

1

2

1

2

2

1

1

11

4

1

4

22

3

2 2

CBT SPT (Only two showed)

Core

Practical Algorithms

2

Internal17

Building Multicast Trees

•Traffic flooding (“Flood-and-prune”)

• Include receivers by extending the tree until all reached

•Explicit messaging

• Receivers join the tree by sending control messages

18

Flood-and-Prune

19

Receivers

Sender

Senders start transmitting packets on all adjacent links

Flood-and-Prune

20

Receivers

Sender

Senders start transmitting packets on all adjacent links

Candidatebranch

Flood-and-Prune

21

Receivers

Sender

Routers forward data on all links except where the data arrived

Candidatebranch

Flood-and-Prune

22

Receivers

Sender

Routing loops must be avoided!

Candidatebranch

Flood-and-Prune

23

Receivers

Sender

Prune control messages are sent downstream on inactive links

Candidatebranch

Flood-and-Prune

24

Receivers

Sender

Prunes are also sent “downstream” if prunes arereceived on all “upstream” interfaces

Candidatebranch

Flood-and-Prune

25

Receivers

SenderCandidatebranchTree branch

Flood-and-Prune

26

Receivers

SenderCandidatebranchTree branch

Flood-and-Prune

27

Receivers

Sender

What if a new receiver wants to join? - Flooding is periodically repeated!

CandidatebranchTree branch

Flood-and-Prune Problem

•Can we flood the Internet in order to reach 5 receivers?

• NO!

•Flood-and-prune was used in the first Internet-wide multicast overlay (Mbone)

•This was the main reason why Mbone did not scale, collapsed under its own weight, and was abandoned

28

Reverse Path Forwarding

•Basis for explicit messaging protocols

•Utilizes the unicast routing tables

• Send control messages toward the known source (core)

•Reject data packets coming from directions other than the source

29

OK, add(S, G): 3 à1

1 2

34

R2

S

Join (S, G)

Discard multicastdata from S at any

interfaceexcept 3

• Multicast data is forwarded only in opposite direction of unicast data• Prevents looping

(S, G): 3 à{4}(S, G): 3 à{1, 4}R1Unicast path R2àS

G SData

Explicit Messaging

30

Receivers

Sender

Core

Receivers send a Join message to the group core (or source in SPT)

Explicit Messaging

31

Receivers

Sender

Core

Senders use unicast to reach the core in CBT

Tree branchp2p stream

123

(*, G): 1® {2, 3}

Taxonomy of Multicast Protocols

3

32

Categorization Dimensions

• Data driven vs. explicit messaging

• Tree type (CBT / SPT)

• Service model

• Unidirectional vs. bidirectional forwarding

• Intra- and inter-domain

• Protocol stack position

33

CBT vs. SPT

•Core Based Tree• Multiple sources use the same tree, but single point of failure

• Fewer routers involved

• More complex operation, less optimal paths

•Shortest Path Tree• Only one source

• Optimal path

• Scalability challenge due to increased amount of state information

34

Uni- or Bidirectional Forwarding

•Should the data flow along the multicast tree in one or both directions?

•Unidirectional: for each branch in the multicast tree, data is flowing in one direction only

•Simple

•Most used (PIM-SM) 35

12 3

4

Bidirectional Forwarding

• In multicast protocols with bidirectional forwarding, data flowing in both directions

•More complex, not widely used in practice

36

12 3

4

Only 1, 3 and 4 in the tree, do not send on 2

and the incoming

Service Models

•Single source (one-to-many)• simple, one-tree approach (SPT)• sufficient for most applications• E.g.: IPTV streaming

•Multiple sources (many-to-many)• general, powerful, but ...• problematic in many ways, security in particular

• E.g.: Conferencing

37

Multicast Addressing

• Class D address range in IPv4

• 224.0.0.0 – 239.255.255.255

• Last 28 bits is the group ID

• 224.0.0.0 – 224.0.0.255 reserved

• Never forwarded by routers

• E.g.

– 224.0.0.1 all hosts ( try to ping, UNINETT is multicast friendly)

– 224.0.0.2 all routers

39

Global IPv4 Address Assignment

• Is problematic if no global rules

• GLOP: allocates 256 addresses to each AS

• (GLOP was suggested before 4-byte AS numbers)

• PIM SSM introduces channel concept that prevents address collisions

• Requires knowledge of sender address

• Uses 232.0.0.0 - 232.255.255.25540

8 bits 8 bits 16 bits233 0-255 AS number

Inter-Network Multicast

• Multicast between network domains particularly challenging:

• scalability• policing

• payments• CBT core placement and

communication

• heterogeneous multicast protocols

41

Router

Router

Router

Router

Router

Router

?

Protocol Stack Position

•Multicast can be implemented from physical to application level

•Network Layer (L3) Multicast

• Very efficient

• Difficult to deploy

•Application Layer (L5-L7) Multicast

• Easy to deploy, no changes on lower layers

• Network system support not required, controlled by end-systems

42

Recent Developments

4

Internal43

General IP Multicast Issues

• Support only for unreliable datagram service

• Open service model

• Anyone can join, address collisions, prone to Denial of Service attacks

• Service billing

• Scalability

• Most approaches target only one application profile

• Patchy deployment

44

Bit Index Explicit Replication (BIER)

• Multicast state is a real issue, specially in large, transit networks.

• BIER does not require any state, nor explicit building of multicast distribution trees.

• Instead, multicast packets are encapsulated in “BIER header”, containing a bit string where each bit represents one egress router in BIER-domain.

• Each transit router in the BIER domain forwards the packets on one or more outgoing interfaces, shortest path to the domain egress, clearing the egress bits to prevent looping.

BIER in practice

46

Egress

Ingress

“Multicast Flow Overlay” used to inform ingress about egress routersfor any given multicast group.

1

2

3

4

5

6

7

8

9

10

12

13

11

14

15

[2, 6, 9, 15]

[6, 9]

[9]

[2] [15]

[a, b, c] – means thatbits a, b and c are set in the header, others 0

[2]

(IP multicast packet)

Summary: What Have We Learned?

• Algorithms:• Optimal multicast tree construction is an NP complete problem

• Good behavior in practice using simple means

• SPT and CBT

• Tree construction:• “Flood-and-Prune”

• Explicit messaging

• Reverse Path Forwarding• Uni- and bidirectional forwarding• Challenges, and some solutions

51