Multi Cast Multicast Routing Protocols

8/12/2019 Multi Cast Multicast Routing Protocols

1/54

Multicast

Henning SchulzrinneDept. of Computer Science

Columbia University

Fall 2003


2/54

Overview

IP multicast service models

any source, source-specific multicast, Multicast protocol components

address assignment

local group management

intra- and inter-domain routing

Programming IP multicast applications


3/54

Multicast service models

Basic idea: same data needs to reach multiple

receivers avoid transmitting it once for each

receiver

particularly useful if access link has bandwidth limitations

can be implemented at link, network and application layer

e.g., mailing list as example

Variations: reach unknown destination bymembership (foo server) rather than address also anycast


4/54

*Cast

Broadcast = all nodes on (small, local)

network Directed broadcast = copies to all hosts on

remote network

DDOS not supported any more (RFC 2644)

Multicast = copies to >= 1 hosts (group)

Anycast = packet to 1 of Nhosts


5/54

Diversion: Anycast

RFC 1546 (Host Anycasting Service) RFC 2373 (IP Version 6 Addressing Architecture)

locate a host which supports a particular service but, if several servers support

the service, does not particularly care which server is used. Example uses:

DNS root servers (F.root-servers.net = 192.5.5.241 ); see http://www.isc.org root servers are hard-configured in DNS resolvers

272 million queries a day

all access routers providing Internet service

Anycast deliver to single host special form of unicast routing

deliver to nearest host (by routing metric)

Multicast deliver to >= 1 host (and maybe get answers from > 1 host)
http://www.isc.org/http://www.isc.org/


6/54

Anycast routing

Assign same address within subnet supernet is advertised either globally (global nodes) or

locally (local nodes) advertise whole prefix, not just single address avoid route

filtering

BGP automatically ensures routing to closest local orglobal node

Distributes (or localizes) denial-of-service traffic

Does not scale well due to address usage (unless allservices within the same subnet)


7/54

Multicast applications

audio-video distribution (1-to-many)

audio-video conferences (all-to-all)

distributed simulation (war gaming, multi-playerDoom, )

resource discovery (wheres the next time server?) instances of resource identified by multicast address

file distribution (stock market quotes, new softwarereleases, OS patches, )

network news (Usenet)


8/54

Multicast trees

spanning tree tree that connects allvertices vertices = hosts and routers

shared tree = single tree for all sources S minimum cost spanning tree (MST)

minimum-weight treein a weighted graphwhich contains all ofthe graph's vertices

cost = hops, delay, transmission cost ($),

does not minimize length of S to individual destination

all traffic concentrated on tree reservation failure

per-source tree build independently for each source
http://www.nist.gov/dads/HTML/vertex.htmlhttp://www.nist.gov/dads/HTML/vertex.htmlhttp://www.nist.gov/dads/HTML/tree.htmlhttp://www.nist.gov/dads/HTML/weightgraph.htmlhttp://www.nist.gov/dads/HTML/vertex.htmlhttp://www.nist.gov/dads/HTML/vertex.htmlhttp://www.nist.gov/dads/HTML/weightgraph.htmlhttp://www.nist.gov/dads/HTML/tree.html


9/54

Multicast treesSteiner trees

given a weighted graph in which a subsetofvertices are identified as terminals, find a minimum-

weight connected subgraph that includes all theterminals

Differs from MST in that Steiner vertices must be

identified

NP-complete problem (see traveling salesman)

unstable: small additions to graph large changes in traffic

flows


10/54

Finding MST via Prims algorithm

centralized, finds MST for G = (V,E)

U: set of vertices connected, start with one add lowest-cost edge (u,v) with uUand v

in V U

tree T T (u,v)

U U v


11/54

Connection-oriented multicast

enumerate sources explicitly source-based tree

examples:

ATM: explicitly add each end point to tree ST-II (IPv5): enumerate end points in setup message

End nodes can also attach themselves to tree

only connection-oriented enumeration only in setup message

source needs to know destinations

resource discovery not possible dynamic groups difficult

but: natural transition from 2-party to N-party

same routing algorithm


12/54

Host group model

Multicast service model

S. Deering, 1991 (RFC 1112)

senders need not be members

groups may have any number of members

there are no topological restrictions on group membership

membership is dynamic and autonomous

host groups may be dynamic or permanent

receiver-driven model

subscriptions


13/54

Local multicast

Some local networks are by (original) nature multicast orbroadcast: Ethernet: original coax contention (CDMA), 802.11 wireless

need to emulate in Ethernet switches

token ring

FDDI

wireless links (BlueTooth, cellular), powerline networks

Ethernet, token ring: broadcast: all-1 address

multicast: 01.xx.xx.xx.xx.xx

adapter hardware can filter dynamic list of addresses

ATM: point-to-point links ATM multicast server or replicationin switches


14/54

IP multicast: model & addresses

host-group model

network level: data packets remain same, only address changes

need help from routers to replicate and route

special IP addresses (class D): 224.0.0.0 through 239.255.255.255 (224/4) 28 bits 268 million groups

in addition, scoping

224.0.0.x: local network only 224.0.0.1: all hosts

224.0.0.2: all routers

224.0.1.x: internetwork control block

224.0.2.0-224.0.255.0: ad-hoc 224.2.0.0-224.2.255.255: SDP/SAP block

some pre-assigned by IANA

map into Ethernet: 01.00.5E.00.00.00 + lower 23 bits


15/54

IP multicast scope

Avoid accidental distribution to whole Internet

IP TTL value: 0 = host, 1 = network

Others to reach larger groups but split horizon problem (RFC 2907) pruning (see later) may fail: larger TTL later

Administrative scoping (RFC 2365) 239.0.0.0 to 239.255.255.255

RFC 1884 for IPv6 (16 scopes)

link-local scope

IPv4 local scope organization local scope

global scope

relative addresses (from top) for common applications within scope


16/54

IP multicast protocols

tree construction protocol PIM-SM, PIM-DM

advertise reverse paths towards sources

Multiprotocol Border Gateway Protocol (MBGP)

disseminate information about sources Multicast

Source Discovery Protocol (MSDP)

hosts dynamically join and leave multicast groups

Internet Group Management Protocol (IGMP)

IGMPv2: specify host group


17/54

Multicast model problems

Host group model now known as Any Source Multicast (ASM)

variant: source-filtered multicast (SFM)

hosts can request data for group G only for specific set of sources or exclude list of sources

IGMPv3 for IPv4 and MLD (listener discovery) for IPv6

host of problems have prevented large-scale deployment:

attacks against multicast groups by unauthorized transmitters

deployment complexity

problems of allocating scarce global class-D IP addresses

lack of inter-domain scalability

single point-of-failure problems

K. Almeroth, S. Bhattacharyya, C. Diot, Challenges of Integrating ASM and SSMIP Multicast Protocol Architectures


18/54

Source-Specific Multicast (SSM)

receiving host explicitly specifies the addressof the source it wants to receive from in addition to multicast group

support one-to-many multicast

address range 232/8, ff2x:: and ff3x::

IGMPv3: allow source specification remove complexity from network layer

application layer (where needed)


19/54

SSM, contd.

distribution tree for channel (S,G) rooted at S no shared tree infrastructure

no need for MSDP only a single source can transmit

avoid access control problem

avoid forwarding unwanted data (cf. SFM)

addresses local to each source

no global addressallocation needed

for large groups, often single source or dominated by single source


20/54

Xcast

providing for many groups of small conferences (a smallnumber of widely dispersed people) with global topologicalscope scales badly given the current multicast model (IABworkshop report)

Large number of small groups:

three-party calls

small interactive conferences

networked games

explicitly enumerate addresses in IP header

each router looks up all addresses

group by interface

remote addresses that dont apply (why?)


21/54

Xcast

Thus, sender-driven model

Advantages: no session setup needed

no address allocation

known set of destinations: simplifies accounting,

access control


22/54

RPFReverse path forwarding

Normal (unicast) routing:

look up destinationaddress

in routing table forward to listed outgoing

interface

RPF: look up source

addressin IP routing table

only forward if packetarrived on that interface

strictly correct only for

symmetric routes Cisco IP multicast technology overview


23/54

PIM-DM

Uses unicast routing protocols (unlikeDVMRP)

push model send traffic everywhere

non-receivers prune

time out after 3 minutes

only source trees good for networks where most subnets want

traffic


24/54

PIM-SM

pull model

join only (G,*)

initially, shared tree =

rendezvous point (RP) router closest to receiver

registers with RP

sources register with RP andthen initially send data via theshared tree

edge routers can force a sourcetree by sending (S,G)messages towards the source ifdistance to source is smallerthan distance to RP

see draft-ietf-pim-v2-dmCisco IP multicast technology overview


25/54

Dense Mode PIM Example

Source

Receiver 2Receiver 1

D F

I

B

C

A

E

G

H

Link

Data

Control

following slides by Salmani


26/54


Initial Flood of Data

and Creation of State

Source


D F

I

B

C

A

E

G

H


27/54


Prune to Non-RPF Neighbor

Source

Prune


D F

I

B

C

A

E

G

H


28/54


C and D Assert to Determine

Forwarder for the LAN, C Wins

Source

Asserts


D F

I

B

C

A

E

G

H


29/54


I Gets Pruned

Es Prune is Ignored

Gs Prune is Overridden

Source

Prune


Join Override

Prune

D F

I

B

C

A

E

G

H


30/54


Source

Graft


Receiver 1

New Receiver, I Sends Graft

D F

I

B

C

A

E

G

H


31/54


Source


Receiver 1

D F

I

B

C

A

E

G

H


32/54

Sparse Mode PIM Example

Receiver 1

B

E

A D

Source

C

Receiver 2

RP

Link

Data

Control


33/54


Receiver 1

B

E

A D

SourceReceiver 1 Joins Group G

C Creates (*, G) State, Sends(*, G) Join to the RP

C

Receiver 2

RP

Join


34/54


Receiver 1

B

E

A RP D

SourceRP Creates (*, G) State

C

Receiver 2


35/54


Receiver 1

B

E

A RP D

SourceSource Sends Data

A Sender Registers to theRP

C

Receiver 2

Register


36/54


Receiver 1

B

E

A RP D

SourceRP de-encapsulates Registers

Forwards Data Down the Shared TreeSends Joins Towards the Source

C

Receiver 2

Join Join


37/54


Receiver 1

B

E

A RP D

SourceRP Sends Register-Stop

OnceData Arrives Natively

C

Receiver 2

Register-Stop


38/54


Receiver 1

B

E

A RP D

SourceC Sends (S, G) Joins to Join

theShortest Path (SPT) Tree

C

Receiver 2

(S, G) Join


39/54


Receiver 1

B

E

A RP D

SourceWhen C Receives Data Natively,

It Sends Prunes Up the RP tree forthe Source. RP Deletes (S, G) OIF and

Sends Prune Towards the Source

C

Receiver 2

(S, G) RP Bit Prune

(S, G) Prune


40/54


Receiver 1

B

E

A RP D

SourceNew Receiver 2 Joins

E Creates State and Sends (*, G) Join

C

Receiver 2

(*, G) Join


41/54


Receiver 1

B

E

A RP D

SourceC Adds Link Towards E to the OIF

List of Both (*, G) and (S, G)Data from Source Arrives at E

C

Receiver 2


42/54


Receiver 1

B

E

A RP D

SourceNew Source Starts Sending

D Sends Registers, RP Sends JoinsRP Forwards Data to Receivers

through Shared Tree

C

Receiver 2

Source 2

Register


43/54

MBGP (Multiprotocol BGP)

RFC 2283 (Multiprotocol Extensions for

BGP-4)

RPF check for AS

path attributes MP_REACH_NLRI and

MP_UNREACH_NLRI two sets of routing

information non-congruent unicast andmulticast topologies


44/54

MSDP (Multicast source discovery

protocol)

Scaling different RPs foreach AS several PIM-SMdomains

each RP only knows localsources and receivers

RPs share sourceinformation via MSDP

TCP session mesh

first message from newsource sent to other RPs viaSource Active (SA) MSDPmessage


45/54

MSDP, contd.

If receiving router has (*,G) state, it joins other RP and creates(S,G) state

Encapsulated data sent down remote RP shared tree

Last-hop router may join shortest path to source directly

MSDP is complex and effectively broadcasts to every RP in theInternet

DOS attack by sending out flood of source announcements

Doesnt scale for large number of sourcesSA flood topology

& carry data


46/54

Multicast address allocation

two different sessions may pick same class-D address andinterfere with each other

solutions: dynamic allocation SAP (later), but doesnt fit all applications,

scaling problems

explicit request MALLOC

static delegation GLOP

interim solution: GLOP (RFC 2770) divides IPv4 multicastaddress space by AS

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 233 | 16 bits AS | local bits |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


47/54

IPv6 multicast address allocation

RFC 3306 (Unicast-Prefix-based IPv6 Multicast Addresses)

Like GLOP, unicast prefix based

| 8 | 4 | 4 | 112 |+--------+----+----+---------------------------------------------+|11111111|flgs|scop| group ID |+--------+----+----+---------------------------------------------+

| 8 | 4 | 4 | 8 | 8 | 64 | 32 |+--------+----+----+--------+--------+----------------+----------+|11111111|0011|scop|reserved| plen | network prefix | group ID |+--------+----+----+--------+--------+----------------+----------+

see RFC 3307:

permanent: e.g.,

0x40404040 for NTP

length of

network

prefix


48/54


RFC 2908 (Internet Multicast Address Allocation Architecture)

Instance of global identifier allocation problem:

hierarchical blocks (IEEE EUI, DNS, IP addresses, phonenumbers, SSN, ) local mechanism left unspecified

on-demand

centralized server (e.g., DHCP within domain)

distributed pools

usually, combination of both Two qualifiers:

scope (possibly global)

lifetime (possibly indefinite)


49/54


core requirements: robustness: work even if remote parts of the

networks dont timeliness: seconds

low probability of clashes

avoid fragmentation overhead

unfortunately, cant have all of them e.g., reliability fragmentation to warehouse

addresses or collisions


50/54


MAAS MAAS

MADCAP HTTP

prefixcoordinator

Layer 2

intra-domain coordinationLayer 1

or GLOP

prefix

coordinator

prefix

coordinator Layer 3

domain (AS)

MASC


51/54

MADCAP

Loosely based on DHCP

Client sends unicast or multicast request toserver (one of a group) DISCOVER to find servers

OFFER: lease time and multicast scope

REQUEST address

Client retransmits if no response

Leases can be renewed and released


52/54

PGM (Pragmatic General Multicast)

RFC 3208, PGM Reliable Transport Protocol

Specification

ordered, duplicate-free multicast data from multiplesources to multiple receivers

either receives all data packets or can detect

unrecoverable losses

sender retransmits after NAK

routers suppress duplicate NAKs and route

retransmissions to branches in need


53/54

Multicast summary

Relatively complete architecture

Difficulty of network service enhancements Difficult to meet higher-layer requirements:

Storage and time-shifting

Access control and billing

Heterogeneous networks

application-layer techniques (CDNs)


54/54

Multicast readings

Stephen A. Thomas, IPng and the TCP/IP

protocols, Wiley, 1996

Christian Huitema, Routing in the Internet,

Prentice Hall, 1995

J. Crowcroft, M. Handley, I. Wakeman,

Internetworking Multimedia, 2000.

Multi Cast Multicast Routing Protocols

Documents

Transcript of Multi Cast Multicast Routing Protocols