Computer Networks (Graduate level)

Univ. of Tehran Computer Network 1

Computer Computer NetworksNetworks

(Graduate level)

University of TehranDept. of EE and Computer Engineering

By:Dr. Nasser Yazdani

Lecture 11: MulticastingMulticasting


Multicasting IP Multicast IGMP Multicast routing Assigned reading

[DC90] Multicast Routing in Datagram Internetworks and Extended LANs

Next Branch Multicast (NBM) routing protocol (2005)

Chapter 4, multicasting.


OutlineOutline

Multicasting Why? Problems, initial solutions. Multicast routing Application level multicast.


Why Multicast? Specify a set of receivers and only send

the data to them. Has a lot of applications:

Audio/video conferencing Distance lectures Internet TV Stock quotes and…

Can I just use broadcast?


Does not scale Imagine trying to broadcast packets to

everyone on Internet! Wastes network resources

We are sending packets to people who will ignore them.

We clearly need something different…

Problems with broadcast


Unicast Use unicast?

One sender, N receivers Sender sends N duplicated unicast

packets, one to each receiver.

S T1 T3 T4

R1

R2

T2

R4 R3Example: Multicast to Ri

by using unicast


Problems? Links carry multiple copies of the same

packet. The link closest to the source flooded with

packets. Server needs to know the list of receivers to

send the packet to. How to handle receivers joining and leaving?

- How to define/manage groups? Wastes bandwidth Introduces complexity – now the source needs

to handle receiver crashes, link failures, etc… Source will be “flooded” with messages if a lot

of receivers join at once.

Ideas?


More problem Imagine having an IP header of the form:

Any router along the way, forwards a packet if at least one of the destinations is downstream from it.

What if a group has 1000s of recipients? Routers will spend more time doing

forwarding lookup since they will need to search the forwarding table for each address.

R1R2R3R4……..Rn S

source destination


IP Multicast Model Main idea Multicast groups Receivers can join or leave at any time. Any host can send to any group at any time –

open architecture The routers duplicate the packets instead of

the source. Routers will need to:

Keep state of groups are there waiting packets from me?

Participate in IGMP* Keep a separate routing table*

Multicast Address Ssource

destination


Division of Responsibilities Host’s responsibility to register interest

with networks IGMP

Network’s responsibility to deliver packets to host

Multicast routing protocol Left unspecified:

Address assignment (random, MASC, etc.) Application-to-group mapping (session

directory, etc.)


Multicast = Efficient Data Distribution

Src Src


Multicast Address Allocation

Currently no standardized method for address allocation (even though an RFC exists about this)

There are a lot of proposed solutions to this Try searching for Multicast Address

Allocation on the net (MALLOC for short)


Logical Naming Single name/address maps to

logically related set of destinations Destination set = multicast group

How to scale? Single name/address independent of

group growth or changes


Multicast Groups Members are the intended receivers Senders may or may not be

members Hosts may belong to many groups Hosts may send to many groups Support dynamic creation of groups,

dynamic membership, dynamic sources


Scope Groups can have different scope

LAN (local scope) Campus/admin scoping TTL scoping

Concept of scope important to multipoint protocols and applications


Multicast Scope Control – Small TTLs

TTL expanding-ring search to reach or find a nearby subset of a group

s

1

2

3


Multicast Scope Control – Large TTLs

Administrative TTL Boundaries to keep multicast traffic within an administrative domain, e.g., for privacy or resource reasons

An administrative domain

TTL threshold set oninterfaces to these links,greater than the diameterof the admin. domain

The rest of the Internet


Multicast Scope Control Administratively-Scoped Addresses (RFC

1112 ) Uses address range 239.0.0.0 —

239.255.255.255 Supports overlapping (not just nested)

domains

An administrative domain

The rest of the Internet

address boundary set oninterfaces to these links


Multicast Backbone (MBone)

An overlay network of IP multicast-capable routers

Host/router

MBone router

Physical linkTunnelPart of MBone

R R

R

H R

H

R

RH


A method for sending multicast packets through multicast-ignorant routers

IP multicast packet is encapsulated in a unicast packet addressed to far end of tunnel:

Tunnel acts like a virtual point-to-point link Each end of tunnel is manually configured with

unicast address of the other end

MBone Tunnels

IP header,dest = unicast

IP header,dest = multicast

Transport headerand data…


Link Layer Multicast On LANs

Exploits the fact that LAN is a broadcast medium.

Ethernet multicast addresses:

01:00:5e:00:00:00 – 01:00:5e:7f:ff:ff

How would an application join a group? Just tell link layer not to discard packets

targeted at the group of interest.


Internet Multicast Group D addresses are used for multicast:

224.0.0.0 – 239.255.255.255

If you do an NSLOOKUP on these addresses you will see that they are registered as *.MCAST.NET

Set the highest 4 bits to 1110 use the remaining 28 Some well known addresses:

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): all multicast routers on

the subnet Need a suite of protocols to take care of the various

aspects of Multicast (membership management, routing, etc..)


Multicast Addressing multicast address a set of Internet hosts comprising a

multicast group. Senders : Dest. Address = multicast address IP multicast group Class D address Class D address : 1110 + 28 bit multicast group ID 224.0.0.0

to 239.255.255.255 0 1 2 3 ----------- 28 bits ---------- 1 1 1 0 Multicast Group ID 224.0.0.0 is reserved. 224.0.0.1 to 224.0.0.225 reserved for

permanent assignments to various uses, including routing protocols and other protocols that require a well-known permanent address.


Multicast Addressing Some of the well-known groups include :

“all systems on this subnet” 224.0.0.1“all routers on this subnet” 224.0.0.2“all DVMRP routers” 224.0.0.4“all OSPF routers” 224.0.0.5“all OSPF designated routers”224.0.0.6“all RIP2 routers” 224.0.0.9“all PIM routers” 224.0.0.13“all CBT routers” 224.0.0.15

The remaining groups are either permanently assigned to various multicast applications or are available for dynamic assignment (239.0.0.0 to 239.255.255.255 for “Administratively scoped” applications)


IP Multicast Protocol Suite A protocol that distributes

membership information – IGMP

A protocol that performs the routing – DVMRP, PIM-SM, PIM-DM, etc…

Protocols that deal with address allocation, reliability, congestion


IP Multicast Architecture

Hosts

Routers

Service model

Host-to-router protocol(IGMP)

Multicast routing protocols(various)


IP Multicast Service — Sending

Uses normal IP-Send operation, with an IP multicast address specified as the destination

Must provide sending application a way to: Specify outgoing network interface, if >1

available Specify IP time-to-live (TTL) on outgoing

packet Enable/disable loop-back if the sending host

is a member of the destination group on the outgoing interface


IP Multicast Service — Receiving

Two new operations Join-IP-Multicast-Group(group-address,

interface) Leave-IP-Multicast-Group(group-

address, interface) Receive multicast packets for joined

groups via normal IP-Receive operation


IGMPv2 Internet Group Management Protocol

RFC 2236 IGMP operates locally

between end hosts and their border router The goal is allowing the border router to learn what

groups are presented on the attached subnets.

S

R1

R2

A C

B

IGMPIGMP

<G1, G2, G3><G1, G2, G3>

<G1><G1>

<G1, G3><G1, G3>

Border RouterBorder Router<G1, G2, G3><G1, G2, G3>

<G1><G1>

<G1><G1>

Eth

ern

et/

Eth

ern

et/

Lan

Lan

IGMP Example


IGMP protocol A soft-state protocol with 3 types of messages:

membership_query (MQ): sent by the router Determines the set of joined multicast groups on the LAN

membership_report (MR): sent by the hosts When a host joins a group or When a host responds to a MQ

Leave_group (LG): sent by the hosts When a host leaves a group

All of these messages are broadcasted over the LAN

router

host

timelineMR:join

MQ

MR

MQ

MR

LG:leave


IGMP Protocol Border router does not need to know which

host(s) have joined a given multicast group. Only one host needs to report Why?

Potentially MR messages sent by the hosts could be problematic. How? Solution: Use feedback suppression

Each host waits randomly between 0 and max_resp_time

Send the report if no one else has sent in that period Leave Group message (LG) optional…

Why?


Multicast Routing Basic objective – build distribution

tree for multicast packets Multicast service model makes it

hard Why? Anonymity Dynamic join/leave


Routing Techniques Flood and prune

Begin by flooding traffic to entire network Prune branches with no receivers Examples: DVMRP, PIM-DM Unwanted state where there are no receivers

Link-state multicast protocols Routers advertise groups for which they have

receivers to entire network Compute trees on demand Example: MOSPF Unwanted state where there are no senders


Routing Techniques Core based protocols

Specify “meeting place” aka core Sources send initial packets to core Receivers join group at core Requires mapping between multicast

group address and “meeting place” Examples: CBT, PIM-SM


Shared vs. Source-based Trees

Source-based trees Separate shortest path tree for each

sender • DVMRP, MOSPF, PIM-DM, PIM-SM

Shared trees Single tree shared by all members Data flows on same tree regardless of

sender CBT, PIM-SM


Source-based TreesRouter

Source

Receiver

S

R

R

R

R

R

S

S


A Shared Tree

RP

Router

Source

Receiver

S

S

S

R

R

R

R

R


Shared vs. Source-Based Trees

Source-based trees Shortest path trees – low delay, better load

distribution More state at routers (per-source state) Efficient for in dense-area multicast

Shared trees Higher delay (bounded by factor of 2), traffic

concentration Choice of core affects efficiency Per-group state at routers Efficient for sparse-area multicast


DVMRP Builds a multicast routing table

By exchanging distance information amongst routers.

Gives consistent view of multicast tree among all routers

Stores ‘dependent routers’ info If there are multiple routers on the

same LAN lower IP address becomes the designated forwarder.


DVMRP Multicast packets are forwarded based on

Reverse Path Forwarding. coming on the next slide!

Leaf routers check and send prune message when no group member on the network.

Upstream router prune the interface with no downstream router.

Graft message sent to create a new routing branch for late members.

Restart forwarding after a set prune lifetime (typical value 12 hours)


Reverse Path Forwarding (RPF)

Procedure:1. A packet is received through interface I, from S

(source) to G (multicast group) - packet (S,G)2. A router looks into the routing table to find an

interface used to send packet to S, I (parent).3. If I != I (parent), I is a wrong interface to

receive (S,G).4. if I = I(parent), I is a correct interface to receive

(S, G). If the procedure succeeds, the datagram is

forwarded to all interfaces except I Otherwise, typically it is silently discarded. Packet is never forwarded back out I.


Reverse Path Flooding (RPF)

A router forwards a broadcast packet originating at source S if and only if it arrives via the shortest path from the router back to S (i.e., the “reverse path”). Otherwise the packet will be discarded

The router forwards the packet out all incident links except the one on which the packet arrived.

Disadvantage :

Any single broadcast packet may be transmitted more than once across any link, up to the number of routers that share the link.



RPF Check Fails!

Unicast Route TableUnicast Route Table

NetworkNetwork Interface Interface

151.10.0.0/16151.10.0.0/16 S1S1

198.14.32.0/24198.14.32.0/24 S0S0

204.1.16.0/24204.1.16.0/24 E0E0

A closer look: RPF Check FailsRPF Check Fails

Packet Arrived on Wrong Interface!

E0

S1

S0

S2

S1S1

Multicast Packet fromSource 151.10.3.21

XDiscard Packet!



A closer look: RPF Check SucceedsRPF Check Succeeds

RPF Check Succeeds!

Unicast Route TableUnicast Route Table

NetworkNetwork Interface Interface

151.10.0.0/16151.10.0.0/16 S1S1

198.14.32.0/24198.14.32.0/24 S0S0

204.1.16.0/24204.1.16.0/24 E0E0

E0

S1

S0

S2

Multicast Packet fromSource 151.10.3.21

Packet Arrived on Correct Interface!S1S1

Forward out all outgoing interfaces.(i. e. down the distribution tree)


Reverse Path Broadcasting (RPB)

Eliminates the duplicate broadcast packets generated by Reverse Path Forwarding

It is necessary for each router to identify which of its links are “child” links in the shortest reverse path tree rooted at any given source S.

When a broadcast packet originating at S arrives via the shortest path back to S, the router can forward it out only the child links for S.


Truncated Reverse Path Broadcasting (TRPB)

The previous algorithms used broadcasting and so were wasting the bandwidth on the links that had no group members.

In TRPB only non-member leaf networks are deleted from each broadcast tree.

Leaf networks are the networks which have no downstream router.

So the leaf networks must be found out and it must be determined if there is any member on the leaf network or not then.


Reverse Path Multicasting (RPM)

Provides on-demand pruning of shortest-path multicast trees. When a source first sends a multicast packet to a group, it

uses TRPB algorithm. When the packet reaches a router for whom all of the child

links are leaves and none of them have members of the destination group, a non-membership report (NMR) for that (source, group) pair is generated and sent back to the router that is one hop towards the source.

If the one-hop-back router receives NMRs from all of its child routers, and if its child links also have no members, it in turn sends an NMR back to its predecessor.

Subsequent multicast packets from the same source to the same group are blocked from traveling down the unnecessary branches by the NMRs sitting in intermediate routers.

A non-membership report includes an age field that is used to cancel the NMR effect after some time.


Reverse Path Multicasting (RPM)

S

R

R R

R RR

G

G

G G

1. Send based on TRPB2. Send Prune message3. Prune the branches


DVMRP in Action - 1

Source

Receiver 1

S

R1

DF

source tree

Forming a source tree


DVMRP in Action - 2

Source

Receiver 1

S

R1

DF

source tree

datagram

Broadcast/flood


DVMRP in Action - 3

Source

Receiver 1

S

R1

DF

source tree

datagram

IGMP DVMRP-Prune

prune


DVMRP in Action - 4

Source

Receiver 1

S

R1

DF X

Y

source tree

datagram

X and Y are Pruned


DVMRP in Action - 5

Source

Receiver 1

S

R1

DF X

Y

source tree

datagram

R2

Receiver 2

IGMP DVMRP-Graft

New Member


DVMRP in Action - 6

Source

Receiver 1

S

R1

DF X

Y

source tree

datagram

R2

Receiver 2

New branch


Possible Problems with IP Multicast

Doesn’t scale well with number of multicast groups Each router has to maintain state for every

“active” multicast group. Flooding in the beginning (bandwidth waste)

Open to DoS attacks by malicious senders. Multicast address assignment problems – how

to be globally consistent? Providing TCP-like reliability is hard Deployment problems as not all routers can

do multicast. Also, lack of business incentive as not clear how to make money on this.


Another Approach to Multicast Routing

PIM – Protocol Independent Multicast Protocol Designed to provide scalable interdomain routing across

internet Can be independent of the underlying unicast routing protocol.

DVMRP dependent on the unicast routing protocol to find the multicast source.

Optimizes traffic depending on the density of receivers in the region.

Two main modes: Dense Mode –

Similar to DVMRP, works with flooding Builds source rooted distribution tree

Sparse Mode – Introduces Rendezvous Points – receivers “meet” new sources at the

RPs Builds a shared tree


Shared Tree Example (PIM-SM)

S F1

F3

RP

F2 GR3

R5

R4

Sender registerswith RP

G sets up stateto RP


Shared Tree Example (PIM-SM)

S F1

F3

RP

F2 GR3

R5

R4S -> RP unicast

RP -> G multicast


IP Multicast Concepts

Host-to-router Protocol (IGMP): keep router up-to-date with group membership of

entire LAN

Multicast routing protocols (various): build distribution tree for multicast packets

senderreceivers

On-TreeLink

Branching router

On-Tree router

Designated Router


SPT vs. Steiner Tree

R2

R5

R4

R1

S1

1

2

1

4

1

1

12

1

3

1

1

R3

R2

R5

R4

R1

S1

1

2

1

4

1

1

12

1

3

1

1

R3

SPT (Shortest Path Tree) Steiner

Router SourceReceiver

S

R


Shared vs. Source-Based Trees

Router Source

Receiver

S

R

R

R

R

S

S

R

S

R

R

R

R

S

RP

Source-Based Tree Shared Tree


Tree types Shortest Path Tree

Simplicity of construction method Distributed solutions High cost Source Based Tree

low delay, better load distribution, Per-source state at routers

Shared trees Higher delay, traffic concentration, Per-group state at routers

Steiner trees Lowest cost, highest delay NP-complete, Centralized solutions


Basic Routing Techniques Flood & prune: DVMRP, PIM-DM

RSPT, Periodic Flooding, inter-domain routing difficulties,

Link-state multicast protocols: MOSPF SPT, High memory consumption, tree

calculation in every node. Core based protocols: CBT, PIM-SM

Comply well with the basic model, Sub-optimal tree, inter-domain routing difficulties, traffic concentration, sensitivity to core selection method, RSPT,


Alternative Routing Techniques Explicit Multicast: Xcast, Bcast

Deployment, stateless, scalable, waste of data space, processing overhead, small groups only.

Application Level Multicast: ESM, NICE Deployment, stateless, no control burden on

network, scalable, overlay construction difficulties, stress, sub-optimal trees, stretch, high failure rate of host, cheating

Branching Point Based: NHBH , REUNITE, HBH SPT, low memory requirement, incremental

deployment, using unicast forwarding, high availability, Superfluous lookups.


Two Main Problems of IP multicast State maintenance

Memory shortage when number of groups increase significantly

State invalidation due to routes changes

Need for complex inter-domain routing and management (PIM-SM/MSDP/MBGP)


NBM


Branching Point Idea Node types:

Member nodes Relay nodes Branching points

More than 80% of tree nodes are relay nodes.

H1S

R1

H2

R2 H4

R6 H3

r4

R4

R3

R5

r3

r5

r2

r1

R7

R9

R8

(a) Complete Tree

H1S

H2

H4

H3

r4

r3

r5

r2

r1

(b) Reduced Tree


Problems with current methods Unnecessary lookups for unicast and

multicast packets

Does Hi has acorresponding entry in

the MFT?

Network Processor

ParserUnicast Forwarding Engine

Forward the packet to allHx in MFT based on

unicast forwarding table

Multicast Forwarding Engine

Forward the packetbased on unicastforwarding table

No

Yes

...


Problems with current methods

REUNITE Asymmetries may result in creation of duplicate packets The departure of one receiver may change the route for others Route changes invalidate MCT Route change may disconnect a subset of receivers from the

tree even though all nodes and links work properly HBH

All relay nodes between every two adjacent BPs must keep MFT

Duplicate packets creation duo to asymmetries Route changes invalidate MCT

SEM The whole multicast tree must be constructed again if:

a new member joins the multicast session one of the existing members leaves the session

The number of receivers is inherently limited due to packet size limit


NBM Principals

NBM main ideas: Build message contains IP addresses

of: the new receiver the next BP in the tree

Children of a failed BP detect failure of their parent and repair it locally by asking their grandpa to find a new parent for them.


NBM Principals Seven Messages Type:

Join to announce receiver desire to join the tree

Leave to announce receiver desire to leave tree

Build to find associated BP of the new receiver

Replace To inform parent BP about creation of a new BP in the tree

Parent to inform a receiver or a BP about its parent and grandpa

Repair to locally repair the tree

Unlock To unlock parent BP


Tree construction: r1 join

s

B2

rn2rn3 JoinBuildParentReplace

rn1

B1

rn4

r3

r1

r2

rn6

rn5

MFT

r1



s

B2

rn2rn3 JoinBuildParentReplace

rn1

B1

rn4

r3

r1

r2

rn6

rn5

MFT

r1 r2

MFT

r1 r2

B1



s

B2

rn2rn3JoinBuildParentReplace

rn1

B1

rn4

r3

r1

r2

rn6

rn5

MFT

MFT

r2 r1

B1

MFT

r2 r3

B2


Tree Maintenance Each BP refresh its children periodically.

Refresh message contains IP address of grandpa Refresh rates of higher level BPs increase linearly

If a BP or a receiver misses three consecutive refresh (parent) messages: it sends a repair message toward the grandpa

Grandpa deal with repair requests in the same way as source do with receiver join messages: It sends a Build message toward the orphaned node or adds it to its MFT


Tree Maintenance

s

B3

rn2rn3

RepiarBuildParentReplace

rn1

rn4

r3

r1

r2

B2

rn5

MFT

MFT

r1

B1

MFT

r2 r3

rn7r4

B2

B1

rn6rn9

rn8

B3


Tree Maintenance

s

B3

rn2rn3

JoinBuildParentReplace

rn1

rn4

r3

r1

r2

B2

rn5

MFT

MFT

r1

B1

MFT

r2 r3

rn7r4

B3

B1

rn6rn9

rn8

MFT

B2 r4

rn6


Height estimation Dependent Receivers (DR)

A BP can estimate DR of a branch by counting the number of Build messages passing through it.

Height of the branch (in reduced tree) is approximately logXDR.

Each branch has a different refresh rate Refresh period = MTI/logXDR

Higher level BPs refresh their children more frequently.

NMTI=NMEM*X2/(X-1)2


Packet Forwarding in NBM

Node B received a packet with unicast destination H i

Is the Protocolfield = NBM_PROT ?

Network Processor

Parser

Unicast Forwarding Engine

Forward the packet toall Hx in MFT based on

unicast forwarding table

Multicast Forwarding Engine

B = Hi ?YesNo

Forward the packetbased on unicastforwarding table

No

Yes


Simulation Setup

myns: large-scale simulations GT-ITM: graph generation

Transit-Stub model (10100 nodes) 10 transit domains Each transit domain has 10 nodes Each transit domain has 5 stub domains Each stub domain has 20 nodes

Average node degree: 3.5 50 simulation runs for each point


Simulation Metrics Number of required table lookups

Multicast Forwarding Gain (MFG): the ratio between the number of required lookups in OBP and NBM

Overall Forwarding Gain (OFG): OFG takes unicast traffic into consideration as well

Number of required MFT entries SPT: NBP+NRN+NMEM RT: NBP+NMEM. MFT Reduction Gain (MRG): the ratio between SPT and

RT values. Tree availability

Tree Availability Gain (TAG): the ratio of non-leaf components of SPT to non-leaf components of RT or: NBP+NRN/NBP

Stress


Table Lookups

100

1100

2100

3100

4100

101 303 505 707 909 1111 1313 1515Number of Receivers

Num

ber

of U

nica

st L

ooku

ps

NBMOBP

1.3

1.4

1.5

1.6

1.7

1.8

1.9

2


Mul

ticas

t For

war

ding

Gai

n

MFG OFG-70%OFG-80% OFG-90%


Stress

1700

1800

1900

2000

2100

2200

2300

2400

0 2 4 6 8 10 12 14 16 18 20Link Stress (a)

Num

ber o

f Lin

ks

UnicastNBM 20%NBM 50%

2410

2430

2450

2470

2490

20 120 220 320 420 520 620 720 820 920 1020Link Stress (b)

Num

ber o

f Lin

ks

UnicastNBM 20%NBM 50%


Tree Characteristics

0

300

600

900

1200


Cou

nt

MEM-20% BP-20% RN-20%MEM-50% BP-50% RN-50%MEM-100% BP-100% RN-100%

0.03

0.08

0.13

0.18

0.23


Rat

io o

f BP

s to

all

tree

nod

es

BP-Ratio-100%BP-Ratio-20%BP-Ratio-50%


Branching Factor

0

2

4

6

8


Ave

rag

e B

ran

chin

g F

acto

r o

f B

Ps

X-20%X-50%X-100%


TAG & MRG

1

6

11

16

21


Tree

Ava

ilabi

lty G

ain

TAG-100%TAG-20%TAG-50%TAG-HBH

1.4

1.8

2.2

2.6

3

3.4


MFT

Red

uctio

n G

ain

MRG-100%MRG-20%MRG-50%MRG-HBH


Control Overhead

0

3000

6000

9000

12000

15000


Nu

mb

er o

f co

ntr

ol

mes

sag

es

Join BuildUnlock ReplaceParent

0

1000

2000

3000

4000

5000

6000


Nu

mbe

r o

f Par

ent m

essa

ges

Parent-Construction-3Parent-Maintenance-3Parent-Construction-2.3Parent-Maintenance-2.3


Application Level Multicast Is what Netmeeting does based on IP multicast?

The idea is – don’t mess with IP, let the applications handle the multicast.

Used very widely today: Sources send packets to a central server which forwards them to

all receivers for the group

Efficient application layer multicast Apps self-organize into a multicast distribution structure Data replication and management only performed by group

members.


Application Level Multicast Pros:

Easy to develop Pushes complexy towards the end systems No address assignment problems Can support a large number of groups

Cons Duplicate packets on the same link Higher delay due to distribution along longer

than optimal paths Longer reaction time to group joins Can potentially be complex


Current Status IP Multicast

Many IETF groups work on various multicast related protocols. New routers have implementations of DVMRP Only a few ISPs have multicast feature turned on in the

routers.

MBone (Multicast backBone) A transient infrastructure before IP Multicast is fully deployed. A virtual network of multicast-capable islands connected by

tunnels (unicast encapsulated between islands) Runs DVMRP

Some enterprise networks have deployed multicast.


Next-lecture: End to end Protocols

End to End issues UDP TCP

Different Version of TCP Assigned reading

Chapter 5 of the book

Documents

Computer Networks (Graduate level)