Algor lgorit ithms hms and and Prot otocols ocols for or IP - - PDF document

1

1

CMPE 252A: Computer Networks Set 10:

Algor lgorit ithms hms and and Prot

• tocols
• cols for
• r

IP Mult ulticas icasting ing

2

Multicasting

 Uses:

 Multimedia “broadcast”: IP radio, webcasts  Teleconferencing: multiparty videoconferencing with

(Mbone, CUSeeMe)

 Database replication  Distributed computing: immediate updates to all

members

 Real-time workgroups: multimedia collaboration  System management: concerted file updates to group of

hosts

 Stock ticker: low-bandwidth quotes to millions of hosts

(cf. Pointcast)

 Single LAN segment:

 straightforward (IEEE 802 includes provision for MAC-

layer multicast addresses)

3

Multicasting

 Purpose: Support one-to-many and many-to-many

communication needed for many applications across LANs and WANs.

 Problem: To minimize the communication and processing

• verhead entailed in disseminating the same data packets

to a group of receivers.

 Goal: Identify the receiver set in a convenient way and

distribute packets to the set efficiently.

 Approach:  Disseminate packets over a tree spanning all the

intended receivers.

 Identify the receivers with a group identifier or the set

• f receiver identifiers.

2

4

IP Multicast Architecture

 Based on Steve Deering’s original proposal

(SIGCOMM 88 Proceedings; his PhD thesis)

 The architecture expands LAN multicasting to the Internet.  It consists of three basic components:  Group addressing based on globally unique

identifiers (IP multicast addresses)

 Separation of senders and receivers with anonymous

receiver affiliation

 A tree-based routing and group structure  Advantages: Efficiency of packet forwarding and

simplicity

 Disadvantages: Scalability, difficult to adapt to group

dynamics, limited services

5

IP Multicast Idea



Addresses used: 224.0.0.0 through 239.255.255.255 (the former Class D addresses in IPv4)



Abstraction:

 multicast address associated with

multicast group

 host joins / leaves group and

receives address dynamically

 sender host sends packets to

multicast group (one or more destinations) not individuals!

 routers deliver to all hosts that

joined group address



To avoid unnecessary duplication of packets, routers must route packets using source and destination addresses, and an efficient routing structure must be built!

6

IP Internet Multicasting

R R R R G G G

R R R R R

R R R R R

3

7

Internet Group Management Protocol (IGMP)



RFC 1112 - used by hosts and routers to exchange multicast group membership information over LAN



Multicast routers use IGMP in conjunction with a multicast routing protocol, to support IP multicasting across the Internet.



Takes advantage of broadcast nature of LAN to updates - IGMP v1 - 3



Two kinds of packets: query / response

8

Constructing The Multicast Routing Structure

 If routers know the topology of the network, they

can compute a multicast routing tree locally.

 If routers maintain only distance or path

information to destinations, multicast routing tree must be computed in a distributed manner.

 Internet multicast routing protocols are based on

reverse path forwarding.

9

Link-State Multicast

 Goal: route packets to all hosts that joined multicast

group address

 Each host on a LAN periodically announces the groups to

which it belongs (IGMP).

 Each router uses link-state flooding to distribute

 cost of links to neighbors  multicast addresses it wants to receive (hosts joined group)

 Each router computes

 regular unicast routing (Dijkstra's algorithm to compute shortest-

path spanning tree for each source/group pair)

 spanning tree for M nodes joining to each active multicast address  Augment link-state update messages to include set of groups that

have members on a particular LAN.

 Each router caches tree for currently active source/group

pairs.

 Possible algorithm:

 find node with smallest host address among M  use Dijkstra to build tree, rooted at that host reaching all M nodes

4

10

Limitations of Link-State Multicasting

 Routers need to maintain too much state for

each multicast group.

 Routers need to send many more link-state

updates.

 Routers need to compute a multicast routing

tree for each source of a group in the worst case, in order to decide when to forward packets.

11

Multicast Extensions to Open Shortest Path First (MOSPF)

 RFC-1583: OSPFv2 - Interior Gateway Protocol (IGP) specifically

designed to distribute unicast topology information among routers belonging to a single Autonomous System

 RFC-1584: MOSPF routers maintain a current image of the network

topology through the unicast OSPF link-state routing protocol

 Extends OSPF by providing the ability to route multicast IP

traffic

 Extension is backward compatible so that routers running MOSPF

will interoperate with non-multicast OSPF routers when forwarding unicast IP data traffic.

12

Distributed Approaches for Building Multicast Trees

Approaches:

 Source-based tree: One tree per source

 shortest path trees  reverse path forwarding

 Group-shared tree: Entire group uses one

tree

 Minimal spanning (Steiner)  Center-based trees

5

13

Shortest Path Tree

 Multicast forwarding tree: tree of shortest

path routes from source to all receivers

 Dijkstra’s algorithm R1 R2 R3 R4 R5 R6 R7 2 1 3 4 i router with attached group member router with no attached group member link used for forwarding, i indicates order link added by algorithm LEGEND S: source

14

Reverse Path Forwarding

if (mcast datagram received on incoming link on shortest path back to “center”) then flood datagram onto all outgoing links else ignore datagram

q Rely on router’s knowledge of unicast

shortest path from it to sender

q Each router has simple forwarding behavior:

15

Reverse Path Forwarding: Example

• Additional signaling is needed to attain the desired tree.
• Use information about distance to source to avoid forwarding to

equidistant neighbors (R2 and R4, R3 and R6)

R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member datagram is forwarded LEGEND S: source datagram should not be forwarded

6

16

Reverse Path Forwarding: Pruning

 “Prune” messages sent to upstream neighbors other than parent

(eliminate chords).

 Forwarding tree contains subtrees with no mcast group members  No need to forward datagrams down “receiver empty”

subtree.

 “prune” msgs sent upstream by router with no downstream

group members

R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member prune message LEGEND S: source links with multicast forwarding P P P P

17

Distance-Vector Multicast Routing Protocol (DVMRP)

 Implemented by the mrouted program.  Specified in RFC-1075.  Implemented version differs in packet format,

different tunnel format, additional packet types.

 Maintains routing knowledge via a distance-

vector routing protocol:

 Much like RIP, described in RFC-1058  Routers maintain hop count to all possible multicast

sources.

18

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

7

19

DVMRP: continued…

 soft state: DVMRP router periodically (1 min.)

“forgets” branches are pruned:

 mcast data again flows down un-pruned branch  downstream router: re-prune or else continue to receive

data

 routers can quickly regraft to tree

 following IGMP join at leaf

 odds and ends

 Mbone routing was done using DVMRP  Replaced by PIM

20

Tunneling

How do we connect “islands” of multicast routers in a “sea” of unicast routers?

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

datagram

q normal IP datagram sent thru “tunnel” via regular IP unicast to receiving

mcast router

q receiving mcast router unencapsulates to get mcast datagram physical topology logical topology

21

Problems with Basic Approach

 Flooding the Internet to establish a multicast

routing tree is not an option!

 This is the key reason why multicasting (based on

DVMRP) cannot be deployed on a large scale.

 The problem stems from the lack of addressing

information in an IP multicast address!

 Where is a multicast group on the Internet?  The solution to this problem is to use

special nodes as the “address” of a group

8

22

Shared-Tree: Steiner Tree

 Steiner Tree: minimum cost tree connecting all

routers with attached group members

 Problem is NP-complete  Good heuristics exist  Not used in practice:

 Computational complexity  Information about entire network needed  Monolithic: rerun whenever a router needs to join/

leave

23

Core-Based Trees

 Single delivery tree shared by all  One router identified as “core” of tree  To join:

 Edge router sends unicast join-msg addressed to

center router

 join-msg “processed” by intermediate routers and

forwarded towards core

 join-msg either hits existing tree branch for this core,

• r arrives at core

 path taken by join-msg becomes new branch of tree

for this router

24

Example of Core-Based Trees

Suppose R6 chosen as core:

R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member path order in which join messages generated LEGEND 2 1 3 1

9

25

Core-Based Tree (CBT)

 Ballardi, Crowcroft, and Francis proposed CBT to solve the

problems found with Deering’s original scheme (DVMRP) based on RPF [Proc. ACM SIGCOMM 93]

 The basic idea consists of using a router, called the core,

as the de facto address for a multicast group.

 In addition, a single shared multicast routing tree is used

for the entire group, rather than one tree per source per group.

 The links in the tree are bidirectional, meaning that

multicast packets can flow between two neighbor members of the tree in either direction.

26

Core-Based Trees (CBT)



CBT is receiver-initiated, in that a router needs to send a

JOIN request towards the core of the group to become a group member.

 JOIN request is forwarded along the shortest path to the

core.

 Any router in the multicast tree receiving the JOIN replies

with an ACK that makes the router join the group.

 The ACK propagates back along the same path followed by

the JOIN.

27

Limitations of CBT

 Using a single core is a vulnerability, CBT does not work

correctly with multiple cores, and CBT can have temporary loops.

 Location of core is critical to performance  Paths over multicast tree can be much longer than the

shortest paths.

A B

10

28

PIM: Protocol Independent Multicast

 Not dependent on any specific underlying unicast routing

algorithm (works with all)

 Multiple multicast modes:

Sparse, dense, bidirectional, source-specific.

Dense:

q group members densely

packed, in “close” proximity.

q bandwidth more plentiful

Sparse:

q # networks with group members

small wrt # interconnected networks

q group members “widely

dispersed”

q bandwidth not plentiful

29

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

30

PIM Dense Mode

Flood-and-prune RPF, similar to DVMRP but

q underlying unicast protocol provides RPF info

for incoming datagram

q less complicated (less efficient) downstream

flood than DVMRP reduces reliance on underlying routing algorithm

q has protocol mechanism for router to detect it

is a leaf-node router

11

31

PIM Sparse Mode

 Center (core)-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 R6 R7 join join join

All data are multicast from rendezvous point!

rendezvous point

32

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 R6 R7 join join join all data multicast from rendezvous point rendezvous point

33

IP Multicast Addressing Issues

 There are plenty of IPv4 and IPv6 addresses for globally

unique multicast addresses, if done carefully

 The problem is how to assign these addresses

permanently or temporarily to multicast groups.

 Using globally unique multicast addresses requires

Internet-wide coordination/rules in the assignment of identifiers to groups.

 Publish subscribe solution based on directory services?  Check: http://en.wikipedia.org/wiki/Multicast_address

12 Other Ways to Provide Multicast Support

 Why do we need a multicast routing

protocol at all?

 How can we support IP multicast in the

data plane?

 An on-demand approach to building

multicast forwarding trees rooted at cores.

34