ECE544: Communication Networks-II Spring 2010 D. Raychaudhuri Lecture 6 Includes teaching materials...

ECE544: Communication Networks-II Spring 2010

D. RaychaudhuriLecture 6

Includes teaching materials from L. Peterson, J. Kurose, K. Almeroth

IP Multicast

•Introduction •Internet Group Management Protocol (IGMP)

•Routing Protocols–Intra-domain (DVMRP, MOSPF, PIM)–Inter-domain (MBGP, MSDP)

Multicast: one sender to many receivers

• Multicast: act of sending datagram to multiple receivers with single “transmit” operation– One-to-many, many-to-many

• Question: how to achieve multicast

Multicast via unicast• source sends N unicast

datagrams, one addressed to each of N receivers– Redundant traffic

around sender– Keep track of all the IP

addresses to send tomulticast receiver (red)

not a multicast receiver

Routers forward unicast datagrams




Network multicast (IP Multicast)• Routers actively

participate in multicast, making copies of packets as needed and forwarding towards multicast receivers

Multicast routers (red) duplicate and forward multicast datagrams




Application-layer multicast (P2P)

• end systems (“hosts”) involved in multicast copy and forward unicast datagrams among themselves

• “host” becomes routerP2P hosts duplicate and forward multicast datagrams

Internet Multicast Service Model

multicast group concept: – Each group has its own IP multicast address– A host can join or leave freely– Routers forward multicast datagrams (with destination address

of the group’s multicast address) to hosts that have “joined” that multicast group

128.119.40.186

128.59.16.12

128.34.108.63

128.34.108.60

multicast group

226.17.30.197

Multicast groupsclass D Internet addresses reserved for

multicast:

host group semantics:o anyone can “join” (receive) or leave multicast groupo anyone (not even a member) can send to multicast

groupo no network-layer identification of hosts members

needed: infrastructure to deliver mcast-addressed datagrams to all hosts that have joined that multicast group

Mapping IP Multicast Address to Ethernet Address

• Ethernet MAC Addresses: 48 bits– broadcast: all 1s, ff:ff:ff:ff:ff:ff– multicast: multicast flag (the lowest bit of the 1st

octet)= 1• 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF for IP

multicast• IP multicast group address mapped to the

lower order 23 bits of MAC address • not one-to-one mapping, one Ethernet mcast

addr 32 IP mcast addrs

IPv6 Multicast Addresses (RFC 2375)

• low-order flag indicates permanent / transient group; three other flags reserved

• scope field: 1 - node local–2 - link-local–5 - site-local–8 - organization-local–B - community-local–E - global–(all other values reserved)

4 112 bits8

group IDscopeflags11111111

4

Joining a mcast group: two-step process

• local: host informs local mcast router of desire to join group: IGMP (Internet Group Management Protocol)

• wide area: local router interacts with other routers to receive mcast datagram flow– many protocols (e.g., DVMRP, MOSPF, PIM)

IGMPIGMP

IGMP

wide-areamulticast

routing

IGMP: Internet Group Management Protocol

• host: sends IGMP report when application joins mcast group– IP_ADD_MEMBERSHIP socket option– host need not explicitly “unjoin” group when

leaving • router: sends IGMP query at regular intervals

– host belonging to a mcast group must reply to query

query report

How IGMP Works

• on each link, one router is elected the “querier”• querier periodically sends a Membership Query message

to the all-systems group (224.0.0.1), with TTL = 1• on receipt, hosts start random timers (between 0 and 10

seconds) for each multicast group to which they belong

Qrouters:

hosts:

How IGMP Works (cont.)

• when a host’s timer for group G expires, it sends a Membership Report to group G, with TTL = 1

• other members of G hear the report and stop their timers• routers hear all reports, and time out non-responding groups

Q

G G G G

Source Specific Multicast

• Source Specific Multicast: a receiving host specifies (source, mcast group) to join– receive multicast packets addressed

to the group and only if they are from the specific sender (one-to-many)

• Any source multicast (ASM): many-to-many

IGMPIGMP version 1• router: Host

Membership Query msg broadcast on LAN to all hosts

• host: Host Membership Report msg to indicate group membership– randomized delay

before responding– implicit leave via no

reply to Query

• RFC 1112

IGMP v2: additions include

• group-specific Query• Leave Group msg

– last host replying to Query can send explicit Leave Group msg

– router performs group-specific query to see if any hosts left in group

– RFC 2236

IGMP v3: – Join/Leave specific S in G– RFC 3376

Multicast Routing: Problem Statement

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

Source-based trees Shared tree

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 (Steiner) – center-based trees

…we first look at basic approaches, then specific protocols adopting these approaches

Shortest Path Tree

• mcast forwarding tree: tree of shortest path routes from source to all receivers– Dijkstra’s algorithm

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

Reverse Path Forwarding

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

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:

source

Building the Reverse Path

source

Building a Reverse Path Tree

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



datagram will be forwarded

LEGENDS: source

datagram will not be forwarded

Reverse Path Forwarding: 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



prune message

LEGENDS: source

links with multicastforwarding

P

P

P

Shared-Tree: Steiner Tree

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

• problem is NP-complete• excellent heuristics exists• not used in practice:

– computational complexity– information about entire network needed– monolithic: rerun whenever a router needs to

join/leave

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

Center-based trees: an example

Suppose R6 chosen as center:

R1

R2

R3

R4

R5

R6 R7



path order in which join messages generated

LEGEND

21

3

1

Current Intra-Domain Multicast Routing

ProtocolsDVMRP — Distance-Vector Multicast Routing Protocol

flood-and-prune,unidirectional per-source trees,builds own routing table

MOSPF — Multicast Extensions to Open Shortest-Path First Protocol

broadcast membership,unidirectional per-source trees,uses OSPF routing table

Current Intra-Domain Multicast Routing Protocols

(cont.)PIM-DM — Protocol-Independent Multicast, Dense-Mode

broadcast-and-prune,unidirectional per-source trees,uses unicast routing table (Protocol Independent)

PIM-SM — Protocol-Independent Multicast, Sparse-Modeuses meeting places (“rendezvous points”),unidirectional per-group or shared trees,uses unicast routing table (Protocol Independent)

CBT — Core-Based Treesuses meeting places (“cores”),bidirectional shared trees,uses unicast routing table

The First Intra-Domain Routing Protocol:

DVMRP

Distance-Vector Multicast Routing Protocol (DVMRP)

DVMRP consists of two major components:(1)a conventional distance-vector routing protocol (like RIP) which builds, in each router, a routing table like this:

(2) a protocol for determining how to forward multicast packets, based on the routing table and routing messages

Subnet(Destination)

shortest dist(cost)

via interface(NextHop)

a 1 i1

b 5 i1

c 3 i2… … …

Example Topology

g g

s

g

Phase 1: Truncated Broadcast

g g

s

g

flood iff the packet arrives over the link that is on the shortest path to S

Phase 2: Pruning

g g

s

prune (s,g)

prune (s,g)

g

Steady State

g g

s

g

g

graft (s,g)

graft (s,g)

Grafting on New Receivers

g g

s

g

g

report (g)

Steady State after Grafting

g g

s

g

g

Multicast Routing: MOSPF

Multicast OSPF (MOSPF)

• an extension to OSPF (Open Shortest-Path First),a link-state, intra-domain routing protocolspecified in RFCs 1584 & 1585

• multicast-capable routers indicate that capability with a flag in their link-state messages

• routers include in their link-state messages a list of all groups that have members on the router’s directly-attached links (as learned through IGMP)

S1

R1

R2

X

Y

Link state: each router floods link-state advertisementMulticast: add membership information to “link state”

Each router then has a complete map of the topology, includingwhich links have members of which multicast groups

Z

S1

R1

R2

X

Y

Z has network map, including membership at X and YZ computes shortest path tree from S1 to X and YZ builds multicast entry with one outgoing interfaceW, Q, R, each build multicast entries

Z

W

Q

R

R1

R2

X

Y

Z

W

Q

R

S1

Link-state advertisement with new topology (may be due to link failure) may require recomputation of tree and forwarding entry.Link WZ failed in the diagram below.

R1

R2

X

Y

Z

W

Q

R

S1

T

R3

Link state advertisement (T) with new membership (R3) may require incremental computation and addition of interface to outgoing interface list (Z) (Similarly, disappearance of a membership may cause deletionan interface from an outgoing interface list). Link WZ is back to normal.

Multicast Routing: PIM

Protocol Independent Multicast (PIM)

• “Protocol Independent”– does not perform its own routing information

exchange – uses unicast routing table made by any of the existing

unicast routing protocols

• PIM-DM (Dense Mode) - similar to DVMRP, but:– without the routing information exchange part– differs in some minor details

• PIM-SM (Sparse Mode), or just PIM - instead of directly building per-source, shortest-path trees:– initially builds a single (unidirectional) tree per group

, shared by all senders to that group – once data is flowing, the shared tree can be converted to a

per-source, shortest-path tree if needed

PIM Protocol Overview• Basic protocol steps

– routers with local members send Join messages towards a Rendezvous Point (RP) to join shared tree

– routers with local sources encapsulate data to RP

– routers with local members may initiate data-driven switch to source-specific, shortest-path tree

RP

R1

R2 R3

R4

Join messagetoward RP

Shared tree after R1,R2,R3 join

Phase 1: Build Shared Tree

Join G

Phase 2: Sources Send to RP

RP

R1

R2 R3

R4

S1

unicast encapsulateddata packet to RP

RP decapsulates,forwards downShared treeS2

PIMRegister

Phase 3: Stop Encapsulation

RP

R1

R2 R3

R4

S1

Join G for S1Join G for S2

S2

(S1,G)

(S1,G)

(*.G)

(S2,G)

Phase 4: Switch to Shortest Path Tree

R1

R2 R3

R4

Join messagestoward S2

shared tree

S1

S2

RP

Phase 5: Prune (S2 off) Shared Tree

R1

R2 R3

R4

S1

S2 distribution treeShared tree

Prune S2 off Shared tree where iif of S2 andRP entries differS2

RP

Bidirectional Trees (BIDIR-PIM)

RP Address’s Link

Join

Join

Bidirectional Trees (BIDIR-PIM)• Bidirectional PIM (BIDIR-PIM): Enhancement to

PIM for many-to-many• A router in shared tree:

– Receive a mcast packet from a down-stream branch– Forward it both up the tree and down other branches

• BIDIR-PIM vs. PIM-SM shared tree– more direct but more state information

• BIDIR-PIM vs. PIM-SM source tree– Longer than PIM-SM source tree, but less state (no

source-specific tree)• What to optimize: bandwidth usage, router

state, path length, etc.• What sort of application to support: one-to-

many, many-to-many, etc.

Inter-domain Multicast Routing

What Exactly is Needed?

• inter-domain route exchange protocol

• mechanism for connecting domains– two models:

• discover sources using “source announcing” protocol

• know the source(s) a priori

Inter-Domain Route Exchange

• Exchange multicast reachability between Autonomous Systems (AS)– Just like unicast routes are exchanged with BGP– Protocol is “Multiprotocol extensions to BGP” (RFC

2283)• Also known as “Multicast” BGP (MBGP)• Also known as BGP4+

• MBGP is available and deployed today.– Multiple vendors: Juniper, Cisco, Nortel, etc.





• know the source(s) a priori

The Internet Solution

• Re-use existing protocols/solutions– Use PIM-SM in the inter-domain

• The challenge is to avoid “root dependencies”– A root/RP/core is one domain but no active

group participants (sources or receivers) in the domain

– Root dependencies can lead to political problems and inefficiencies

The Internet Solution (cont)

• The key: Establish a root/RP/core per domain– No “root dependencies”

• Remember the problem:– Connecting sources and receivers– Solution: Multicast Source Discovery Protocol

(MSDP)

• MSDP is the last piece of the puzzle; is simple to implement; and yields an interim solution to inter-domain multicast

MSDP -- Basic Idea

• MSDP advertises multicast sources to other domains

• Other domains decide if group members are active and find a way to get the data

• “MSDP connects shared-trees together”

• MSDP typically runs in the RP

MSDP - Elements of Operation

• Receivers in a domain join the shared-tree

• The RP is known only to routers in the domain

• When a source goes active in a domain, it’s packets get to the RP in that domain

• The RP sends a Source-Active (SA) message identifying the source and group it sends to

MSDP - Elements of Operation (cont)

• How to get SA messages to all MSDP peers?

– Need MSDP topology flooding protocol

– The RP’s address is also in the SA message to accommodate “peer-RPF” like flooding

– Each MSDP peer receives SA message and forwards away from the originating RP

MSDP - Elements of Operation (cont)

• Each MSDP speaking RP will examine SA message to see if any local members are joined to the group

• If so, the RP joins to source described in SA message

• Otherwise, the SA message is ignored (Flood-and-Join model)

How MSDP works with PIM-SM

RP

RP

RP

RP

MSDP peer

Physical link

A

B

C D

Receiver

Source

PIM message

MSDP message

2b: SA

2b: SA

2b: SA

3:Join3:Join3:Join

3:Join

1: Register

2a:Join





•know the source(s) a priori—SSM model

Source Specific Multicast (SSM)

• Basic idea:– Assumes receiver knows the

source(s)– Reverse SPT join to source

• No RPs or MSDP

– About as straightforward as you can get!

How SSM Works

Physical link

A

B

C D

Receiver

Source

PIM message

Join

JoinJoin

Join

Join

Join

Source Specific Multicast

• Advantages– Minor changes to existing infrastructure—still use

PIM-SM– No PIM-SM RP, or MSDP

• Limitations– Requires modifications (last hop routers) and

IGMPv3– May be difficult to support some applications

• Thoughts– Works for 9x% of killer-apps -- need mechanism

(WWW) to let receivers know who sources are– Success will depend on seamless migration strategy

75

Today’s Homework• Peterson & Davie, Chap 4

4.464.564.61

Due Friday 3/5Reminder: Midterm 3/12

ECE544: Communication Networks-II Spring 2010 D. Raychaudhuri Lecture 6 Includes teaching materials...

Documents

Transcript of ECE544: Communication Networks-II Spring 2010 D. Raychaudhuri Lecture 6 Includes teaching materials...