multicast.ppt 912KB Jun 23 2011 12:10:54 PM

CS640

Introduction to Computer Networks

Multicast

Nov 29

th

, 1999

One to many communication

• Application level one to many communication

• multiple unicasts

• IP multicast

S S

R

R R

R

Why Multicast

• When sending same data to multiple receivers

– better bandwidth utilization – less host/router processing – quicker participation

• Application

– Video/Audio broadcast (TV, radio type) – Video conferencing

IP multicast service model

• RFC1112 : Host Extensions for IP Multicasting

• Transmission of an IP datagram to a "host group", • host group identified by a class D IP address

• Members of the group could be present anywhere in the Internet • Members join and leave the group and indicate this to the routers • Senders and receivers are distinct: i.e., a sender need not be a me

mber

IP multicast group address

• Class D address space

– high-order three 3bits are set – 224.0.0.0 ~ 239.255.255.255

• Well-known address designated by IANA

– RFC1700

– 224.0.0.0 ~ 224.0.0.25

– 224.0.0.1 (ALL-SYSTEMS.MCAST.NET)

• all multicast hosts on the subnet

– 224.0.0.2 (ALL-ROUTERS.MCAST.NET)

IGMP – Joining a group

R

Example : R joins to Group 224.2.0.1

• R sends IGMP Membership-Report to 224.2.0.1

• DR receives it. DR will start

forwarding packets for 224.2.0.1 to Network A

• DR periodically sends IGMP

Membership-Query to 224.0.0.1 (ALL-SYSTEMS.MCAST.NET) • R answers IGMP

Membership-Report to 224.2.0.1

IGMP – Leaving a group

R

DR

Example : R leaves from a Group 224.2.0.1 • R sends IGMP Leave-Group to 224.0.

0.2

(ALL-ROUTERS.MCAST.NET) • DR receives it.

• DR stops forwarding packets for 224.2. 0.1 to Network A if no more 224.2.0.1 gr oup members on Network A.

Challenges in this model

• How to select receivers by a sender ?

– need authentication, authorization

– encryption of data

– key distribution

IP multicast routing

• Purpose: share a Group information among

routers, to implement a better routing for da

ta distribution

• Distribution tree structure

– Source tree vs shared tree

• Data distribution policy

Source distribution tree

Receiver 1

E B

A D F

Source

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

C

Receiver 2 S

Shared distribution tree

Receiver 1

E B

A D F

Source

Notation: (*, G) * = all sources G = Group

C

Receiver 2 S1

R R

Shared Root

Source tree characteristics

• Source tree

– More memory O (G x S ) in routers

– optimal path from source to receiver, minimizes

delay

• good for

Shared tree characteristics

• Shared tree

– less memory O (G) in routers

– Sub-optimal path from source to receiver, may introduce e xtra delay (source to root)

– May have duplicate data transfer (possible duplication of a path from source to root and a path from root to receivers)

• good for

– Many senders with low bandwidth

Data distribution policy

• NACK type

– Start with “broadcasting” then prune brunches with no receivers, to create a distribution tree

– a lot of un-used traffic when small receivers in wide area

• ACK type

– forward only to the hosts which explicitly joined to the group

Protocol types

• Dense mode protocols

– assumes dense group membership

– Source distribution tree and NACK type

– DVMRP (Distance Vector Multicast Routing Protocol) – PIM-DM (Protocol Independent Multicast, Dense Mode)

• Sparse mode protocol

– assumes sparse group membership

– Shared distribution tree and ACK type

DVMRP

exchange distance vector

• Maintain ‘multicast routing table’ by exchanging distance vector information among routers

– consistent view of a tree among all routers

– convenient to have separate paths for unicast versus multicast data grams;( ie tunnelings)

• ‘Dependent routers’ information

– information about responsible downstream routers for a source – A downstream router send “poison Reverse” to a selected upstrea

m router to indicate the dependency. – Poison Reverse : metric + 32 (inf)

– entry will be removed from the list by prune message

• Designated Forwarder

– multiple routers on the same LAN

DVMRP

broadcast & prune

• Forward multicast packets based on RPF (Reverse path for warding) rule

• leaf routers check and sends prune message to upstream ro uter when no group member on the network

• upstream router prune the interface with no dependent dow nstream router.

• Graft message to create a new branch for late participants • Restart forwarding after prune lifetime (standard : 720 min

utes)

RPF(reverse path forwarding)

• RPF check

– A packet received through interface I, from S (source) to G (multica st group) – packet (S,G)

– A router looks into the routing table to find an interface used to send packet to S, I(parent).

– If I != I (parent), I is a wrong interface to receive (S,G). – if I = I(parent), I is a correct interface to receive (S, G).

• If the RPF check succeeds, the datagram is forwarded to all inter faces except I.

DVMRP (1)

form a source tree by exchanging metric

Source

Receiver 1

S

R1

DF

DVMRP (2)

broadcast

Source

Receiver 1

S

R1

DF

DVMRP (3)

prune

Source

Receiver 1

S

R1

DF

source tree datagram

DVMRP (4)

X and Y pruned

Source

Receiver 1

S

R1

DF X

Y

DVMRP (4)

New member

Source

Receiver 1

S

R1

DF X

Y

source tree datagram

R2

Receiver 2

DVMRP (4)

New branch

Source

Receiver 1

S

R1

DF X

Y

source tree datagram

R2

Receiver 2

PIM

• PIM : Protocol Independent Multicast

– independent of particular unicast routing protocol – Pros: simple, less overhead

– Cons: may cause more broadcast-and-prunes

• All routers in a domain support PIM • No multicast tunnel

PIM DM overview(1)

• Broadcast and prune ideal for dense group

• Source tree created on demand based on RP

F rule

• If the source goes inactive, the tree is torn d

own

• Easy plug-and-play

PIM DM overview(2)

• Grafts used to join existing source tree

• Uses Asserts to determine the forwarder for

multi-access LAN

• Prunes on non-RPF P2P links

PIM DM Forwarding

• PIM DM interfaces are placed on the “oilist” for a

multicast group if;

– PIM neighbor heard on interface

– Host on this interface has just joined the group

– Interface has been manually configured to join group

• Packets are “flooded” out all interfaces in “oilist”

PIM Assert Mechanism

• Routers receive packet on an interface in their “oil

ist”

– Only one router should continue sending to avid duplic ate packets.

• Routers sends “PIM assert” messages

– Compare distance and metric values – Router with best route to source wins

PIM DM State Maintenace

• State is maintained by the “flood and prune”

behavior of Dense mode.

– Received Multicast packets reset(S,G) entry “ex

piration” timers.

– When (S,G) entry “expiration” timers count dow

n to zero, the entry is deleted.

PIM-DM(1)

Initial flood of data

Source

Receiver 2 Receiver 1

S

R1

A

R2 B

C D F

G

H I

PIM-DM(2)

prune non-RPF p2p link

Source

Receiver 2 Receiver 1

S

R1

A

R2 B

C D F

G

H I

E

PIM-DM(3)

C and D Assert to Determine Forwarder for the LAN, C Wins

Source Receiver 2 Receiver 1 S R1 A R2 B

C D F

G

H I

E

IGMP PIM-Assert

PIM-DM(4)

I, E, G send Prune

H send Join to override G’s Prune

Source Receiver 2 Receiver 1 S R1 A R2 B

C D F

PIM-DM(5)

I Gets Pruned E’s Prune is Ignored G’s Prune is Overridden

Source Receiver 2 Receiver 1 S R1 A R2 B

C D F

G

H I

PIM-DM(6)

New Receiver, I send Graft

Source Receiver 2 Receiver 1 S R1 A R2 B

C D F

PIM-DM(6)

new branch Source Receiver 2 Receiver 1 S R1 A R2 B

C D F

PIM-SM overview (1)

• Shared Tree for a group with RP (Rendez-Vous Point) a

s a root

• Explicit Join Model

– Receivers send Join towards the RP – Sender Register with RP

– Last hop routers can join source tree if the data rate warrants by sending joins to the source

• RPF check depends on tree type

– For shared trees, uses RP address

PIM-SM overview(2)

• Only one RP is chosen for a particular group

• RP statically configured or dynamically learned

(Auto-RP, PIM v2 candidate RP advertisements)

• Data forwarded based on the source state (S, G)

if it exists, otherwise use the shared state (*, G)

• RFC2362 – “PIM Sparse Mode Protocol Spec”

(experimental)

• Internet Draft:

draft-ietf-pim-v2-sm-00.txt

PIM-SM Basics

• PIM Neighbor Discovery

• PIM SM Forwarding

• PIM SM Joining

• PIM SM REgistering

• PIM SM SPT-Swichover

• PIM SM Pruning

• PIM SM Bootstrap

PIM Neighbor Discovery

• PIM Hellos are multicast to the

“All-PIM-Routers” (224.0.0.13, ff02::d) multicast

group address periodically

• Highest IP address elected as “DR”

(Designated Router)

PIM SM Bootstrap

• A set of routers are configured as candidate Bootstra

p Router(BSR)s

– single BSR is selectd for the domain

• Candidate RPs periodically unicast Candidate-RP-A

dvertisement messages (C-RP-Advs) to BSR

• The BSR periodically sends Bootstrap messages cont

aining the set of Candidate-RPs

– Bootstrap message are flooded in the domain

PIM SM State Maintenance

• Periodic Join/Prunes are sent to all PIM nei

ghbors

• Periodic Joins refresh interfaces in a PIM ne

ighbor’s oilists

• Periodic Prunes refresh prune state in a PIM

neighbor

PIM-SM(1)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

PIM-SM(2)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

Receiver 1 Joins Group G C Creates (*, G) State, Sends (*, G) Join to the RP

PIM-SM(3)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

PIM-SM(4)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

Source Sends Data

A Sends Registers to the RP

Register

PIM-SM(5)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

RP de-encapsulates Registers

Forwards Data Down the Shared Tree Sends Joins Towards the Source

PIM-SM(6)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

RP Sends Register-Stop Once Data Arrives Natively

PIM-SM(7)

SPT

Switchover

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

C Sends (S, G) Joins to Join the Shortest Path (SPT) Tree

PIM-SM(8)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

PIM-SM(9)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

C Sends Prunes Up the RP tree for the Source. RP Deletes (S, G) OIF and Sends Prune Towards the Source

PIM-SM(10)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

PIM-SM(11)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2 join

New receiver2 joins

PIM-SM(12)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

C Adds Link Towards E to the OIF List of Both (*, G) and (S, G)

PIM-SM(13)

Receiver 1 Source

Receiver 2 S

R1

A B RP D

C E

R2

C Adds Link Towards E to the OIF List of Both (*, G) and (S, G)

Inter-Domain Multicast Routing

• BGP4+ (Multicast BGP) for short-term

solution

• MASC : Multicast Address Set and Claim

• BGMP : Border Gateway Multicast

MASC

• Hierarchical multicast address allocation

• dynamic allocation (lease) by “set and claim

with collision”

domain A

domain B _{domain C} domain E

MASC

• Assume Addr(A) is allocated to domain A, A notify to B C and E. • B selects Addr(B) , subset of Addr(A) and send Claim (addr(B))

message to A and C

• A forward it to all children except B.

• If A’s children is already using Addr(B), report collision to A. • A notify the collision to B to select other address space.

• B wait for a certain period before using it.

• Address space information is used to create distribution tree using BGMP.

BGMP

• Use a PIM-like protocol between domains (“BGP for multicas t”)

• BGMP builds shared tree of domains for a group

– So we can use a rendezvous mechanism at the domain level – Shared tree is bidirectional

– Root of shared tree of domains is at root domain

• Runs in routers that border a multicast routing domain • Runs over TCP like BGP

• Joins and prunes travel across domains • Can build unidirectional source trees

BGMP

A host in C joins to Group G

BGMP

Tree constructed, data goes to C

BGMP

Domain E joins to G

BGMP

tree constructed. Data goes to E

Multicast Routers

• mrouted (Xerox PARC) : DVMRP

• GateD (Merit) : DVMRP, PIM-DM, PIM-S

M

M-Bone

• Wide area IP multicast test bed using IP-in-IP tunneling technol ogy

• Routing protocol

– DVMRP is used

– Transition to PIM (DM, SM) is ongoing

• Started in March 1992 for audio broadcasting of IETF meeting (San Diego)

• Latest tolopology

– ftp://ftp.parcftp.xerox.com/pub/net-research/mbone/maps/mbone-map-big.ps – About 6000 (S,G) entries

Future Mulicast Service

• Current multicast service - latency and

packet drop

• Research for “Reliable multicast” is

actively going on for;

– large scale interactive game on the Internet

– Distributed database

Reliable multicast technology

• SRM ( scalable Reliable Multicast)

– multicast with re-transmit (with random back-off)

– All nodes can re-transmit datagram (Multicast/Unica

st)

• MTP (Multicast Transport Protocol: RFC1301)

• FEC (Forward Error Correction)

IPv6 Multicast Test

10sites in Japan

PIM-SM over IPv6 (KAME) Digital Video streaming