multicast

29
Multicast Sources: Kurose and Ross http://www.hep.ucl.ac.uk/~ytl/multi- cast/addresstranslation_01.html

Upload: amadahy-mitchell

Post on 30-Dec-2015

23 views

Category:

Documents


1 download

DESCRIPTION

Multicast. Sources: Kurose and Ross http://www.hep.ucl.ac.uk/~ytl/multi-cast/addresstranslation_01.html. IP Multicast Addresses. First 4 bits: 1110 (Class D IP address) Range: 224.0.0.0 to 239.255.255.255 Some are reserved. 224.0.0.1 all hosts 224.0.0.2 all multicast routers - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Multicast

Multicast

Sources: Kurose and Ross

http://www.hep.ucl.ac.uk/~ytl/multi-cast/addresstranslation_01.html

Page 2: Multicast

IP Multicast Addresses

• First 4 bits: 1110 (Class D IP address)

• Range: 224.0.0.0 to 239.255.255.255

• Some are reserved. – 224.0.0.1 all hosts– 224.0.0.2 all multicast routers– 224.0.0.3 all DVMRP routers– 224.0.0.5 all OSPF routers

These are local multicasts (IP TTL=1)

Page 3: Multicast

Translation to 6 byte MAC address

• IP address must be translated to a MAC address so that NIC card will receive

• IANA reserved MAC addresses starting with 00:5e:00. There’s a reserved bit to indicate multicast/broadcast. 01:5e:00

• Half of IANA range was allocated for multicast (01:5e:00:00:00 – 01.5e.7f.ff.ff)

• 23 bits map to multicast IP address

Page 4: Multicast

• There is no network layer protocol that determines all the members of a multicast group.

• Multicast groups are receiver driven – not sender driven.

• Higher level protocols may “invite” receivers to listen in.

Page 5: Multicast

• IGMP – local network

• Within autonomous system multicast routing protocols (e.g. DVMRP, PIM-sparse mode, PIM-dense mode)

• Between autonomous systems– Problem agreeing– DVMRP was de facto standard now have

extensions to BGP

Page 6: Multicast

Internet Group Management Protocol

• Operates between host and directly attached router

• Host tells router it wants to listen to multicast group address

• Router participates in routing protocol in order to receive multicast packet sent to the group address

Page 7: Multicast

IGMP Messages

• Membership query – sent by router to all hosts on an interface to determine what groups have been joined

• Membership report – sent by hosts to routers in response to a query or when host first joins

• Leave group – optional, host sends to routers in order to stop listening

• Router specifies max response time

Page 8: Multicast

Multicast Routing Protocols

• Two approaches

– Group shared tree• In practice a center-based tree is used for all

senders

– Source-based tree• Each sender has own tree

Page 9: Multicast

R1

Figure 4.39 Source-duplication versus in-network duplication. (a) source duplication, (b) in-network duplication

R2

R3 R4

(a)

R1

R2

R3 R4

(b)

duplicatecreation/transmissionduplicate

duplicate

Page 10: Multicast

Figure 4.41: Broadcast along a spanning tree

A

B

G

DE

c

F

A

B

G

DE

c

F

(a) Broadcast initiated at A (b) Broadcast initiated at D

Spanning tree: a tree that contains each and every node in a connected graph

If each link has an associated cost and the cost of a tree is the sum of the link costs, then a spanning tree whose cost is the minimum of all the graph’s spanning trees is a minimum spanning tree.

Page 11: Multicast

Multicast Routing: Problem Statement

• Goal: find a tree (or trees) connecting routers having local mcast group members – tree: not all paths between routers used– shared-tree: same tree used by all group members– source-based: different tree from each sender to rcvrs

Shared tree Source-based trees

Page 12: Multicast

Approaches for building mcast trees

Approaches:

• source-based tree: one tree per source– shortest path trees– -reverse path forwarding

• group-shared tree: group uses one tree– minimal spanning – -center-based trees

1st look at basic approaches, then specific protocols adopting these approaches

Page 13: Multicast

Shortest Path Tree• mcast forwarding tree: tree of shortest path routes from

source to all receivers– Dijkstra’s algorithm constructs tree – know predecessor on

shortest path back

R1

R2

R3

R4

R5

R6 R7

21

6

3 4

5

i

router with attachedgroup member

router with no attachedgroup member

link used for forwarding,i indicates order linkadded by algorithm

LEGENDS: source

Page 14: Multicast

Reverse Path Forwarding

if (mcast datagram received on incoming link on shortest path back to sender)

then flood datagram onto all outgoing links

else ignore datagram

rely on router’s knowledge of unicast shortest path from it to sender

each router has simple forwarding behavior:

Page 15: Multicast

Reverse Path Forwarding: example

• result is a source-specific reverse SPT– may be a bad choice with asymmetric links

R1

R2

R3

R4

R5

R6 R7

router with attachedgroup member

router with no attachedgroup member

datagram will be forwarded

LEGENDS: source

datagram will be dropped by receiving router

Page 16: Multicast

Reverse Path Forwarding with pruning

• forwarding tree contains subtrees with no mcast group members– no need to forward datagrams down subtree– “prune” msgs sent upstream by router with

no downstream group members

R1

R2

R3

R4

R5

R6 R7

router with attachedgroup member

router with no attachedgroup member

prune message

LEGENDS: source

links with multicastforwarding

P

P

P

Page 17: Multicast

Shared-Tree: Steiner Tree

• Steiner Tree: minimum cost tree connecting all routers with attached group members

• not used in practice:– computational complexity– information about entire network needed– monolithic: rerun whenever a router needs to

join/leave

Page 18: Multicast

Center-based trees• single delivery tree shared by all• one router identified as “center” of tree• to join:

– edge router sends unicast join-msg addressed to center router

– join-msg “processed” by intermediate routers and forwarded towards center

– join-msg either hits existing tree branch for this center, or arrives at center

– path taken by join-msg becomes new branch of tree for this router

Page 19: Multicast

Center-based trees: an example

Suppose R6 chosen as center:

R1

R2

R3

R4

R5

R6 R7

router with attachedgroup member

router with no attachedgroup member

path order in which join messages generated

LEGEND

21

3

1

Page 20: Multicast

Internet Multicasting Routing: DVMRP• DVMRP: distance vector multicast routing

protocol, RFC1075• flood and prune: reverse path forwarding,

source-based tree– RPF tree based on DVMRP’s own routing tables

constructed by communicating DVMRP routers

– no assumptions about underlying unicast

– initial datagram to mcast group flooded everywhere via RPF

– routers not wanting group: send upstream prune msgs

Page 21: Multicast

DVMRP: continued…• soft state: DVMRP router periodically (1 min.)

“forgets” branches are pruned: – mcast data again flows down unpruned branch– downstream router: reprune or else continue to

receive data

• routers can quickly regraft to tree – following IGMP join at leaf

• odds and ends– commonly implemented in commercial routers– Mbone routing done using DVMRP

Page 22: Multicast

PIM: Protocol Independent Multicast

• not dependent on any specific underlying unicast routing algorithm (works with all)

• two different multicast distribution scenarios :Dense: group members

densely packed, in “close” proximity.

bandwidth more plentiful

Sparse: # networks with group

members small wrt # interconnected networks

group members “widely dispersed”

bandwidth not plentiful

Page 23: Multicast

Consequences of Sparse-Dense

Dichotomy: Dense• group membership by

routers assumed until routers explicitly prune

• data-driven construction on mcast tree (e.g., RPF)

• bandwidth and non-group-router processing profligate

Sparse:• no membership until

routers explicitly join• receiver- driven

construction of mcast tree (e.g., center-based)

• bandwidth and non-group-router processing conservative

Page 24: Multicast

PIM- Dense Mode

flood-and-prune RPF, similar to DVMRP but

underlying unicast protocol provides RPF info for incoming datagram

less complicated (less efficient) downstream flood than DVMRP reduces reliance on underlying routing algorithm

has protocol mechanism for router to detect it is a leaf-node router

Page 25: Multicast

PIM - Sparse Mode• center-based

approach• router sends join msg

to rendezvous point (RP)– intermediate routers

update state and forward join

• after joining via RP, router can switch to source-specific tree– increased performance:

less concentration, shorter paths

R1

R2

R3

R4

R5

R6R7

join

join

join

all data multicastfrom rendezvouspoint

rendezvouspoint

Page 26: Multicast

PIM - Sparse Mode

sender(s):• unicast data to RP,

which distributes down RP-rooted tree

• RP can extend mcast tree upstream to source

• RP can send stop msg if no attached receivers– “no one is listening!”

R1

R2

R3

R4

R5

R6R7

join

join

join

all data multicastfrom rendezvouspoint

rendezvouspoint

Page 27: Multicast

Multicast Routing Between Autonomous Systems

• Within AS all routers running the same multicast routing protocol

• Between AS there have been issues• RFC4271 defines extensions to BGP

(interdomain Border Gateway Protocol) to allow it to carry info for other protocols, including mcast info.

• MSDP Multicast Source Discovery Protocolcan be used to connect RPs in different PIM sparse mode domains

Page 28: Multicast

Tunneling

Q: How to connect “islands” of multicast routers in a “sea” of unicast routers?

mcast datagram encapsulated inside “normal” (non-multicast-addressed) datagram

normal IP datagram sent thru “tunnel” via regular IP unicast to receiving mcast router

receiving mcast router unencapsulates to get mcast datagram

physical topology logical topology

Page 29: Multicast

• Most streaming over Internet is done using overlays and tunnels to create application layer multicast.

• Then multicast occurs on local net or autonmous system