introduction to multicast network protocols october 5, 1999

Introduction to Multicast Network Protocols

October 5, 1999

Lawrence A. Rowe and Gordon ChaffeeUniversity of California, Berkeley

URL: http://www.BMRC.Berkeley.EDU/~larry

Multimedia Systems & Applications 2

Outline

• Multicast Application Models

• Multicast Routing

• Multicast and the ISP’s

• Problems

• Future Work on Multicast Applications


What is Multicast?

• 1 to N communicationCalled N-way communicationDynamic join/leave

• Network hardware efficiently supports multicast transport

Example: Ethernet allows one packet to be received by many hosts

• Many different protocols and service models Examples: IETF IP Multicast, ATM Multipoint


ATM Multipoint Service

• Single sender with multiple receiversMultipoint - essentially an N-to-1 unicast circuit

• N-way communication?Identify single multicast server that forwards all messagesOpen N multipoint circuits

• Early versions did not allow dynamic join/leave• Works well for interactive broadcast applications

I.e., applications where one sender dominant


IP Multicast• True N-way communication

Any participant can send at any time and everyone receives the message

• Unreliable deliveryAvoids hard problem (e.g., NACK explosion)

• Efficient deliveryPackets only traverse network links once (i.e., tree delivery)

• Location independent addressingOne IP address per multicast group

• Receiver-oriented service modelReceivers can join/leave at any timeSenders do not know who is listening


IP Multicast Details

• ServiceAll senders send at the same time to the same groupReceivers subscribe to any groupRouters find receivers

• Reserved IP addresses224.0.0.0 to 239.255.255.255 reserved for multicastPartitioned for different addressing models (e.g., administrative scoping, global/local scoping, etc.)Static addresses for popular services (e.g., SAP)


Internet Group Management Protocol

• Protocol for managing group membershipIP hosts report multicast group memberships to neighboring routersMessages in IGMPv2 (RFC 2236)

Membership Query (from routers)Membership Report (from hosts)Leave Group (from hosts)

• Announce-listen protocol with suppressionHost responds only if no other host has responded

• Soft-state protocol


IGMP Example (1)

Network 1

• Host 1 begins sending packetsNo IGMP messages sentPackets remain on Network 1

• Router periodically sends IGMP Membership Query

Network 2Router

1

2 4

3


IGMP Example (2)

Network 1

• Host 3 joins conferenceSends IGMP Membership Report message

• Router begins forwarding packets onto Network 2• Host 3 leaves conference

Sends IGMP Leave Group messageOnly sent if it was the last host to send an IGMP Membership Report message

Network 2Router

1

2 4

33

Membership Report

33

Leave Group


Distance Vector Routing

• First decentralized IP routing algorithm• Building routing tables

Routers know local links and distance to selfNeighbor routers exchange current distance vectorsNew distances computed using neighbors distance vectors

• Routing tablesNodes maintain distance from self to every destination


Distance Vector Example

A

B

D E

C

1. Begin with all distance vectors only knowingdistance to self. Assume link costs are 1.

2. Initial distance vectors are sent to neighbors,and nodes compute new distance vectors.

3. Send distance vectors; nodes re-compute vectors.

L1

L3

L2

L4

L5

AA 0 XX

BB 0 XX

CC 0 XX

DD 0 XX

EE 0 XX

EE 0 XXD 1 L4C 1 L5

AA 0 XXB 1 L1D 1 L3

BB 0 XXA 1 L1C 1 L2

CC 0 XXB 1 L2E 1 L5

DD 0 XXA 1 L3E 1 L4

AA 0 XXB 1 L1D 1 L3C 2 L1E 2 L3

BB 0 XXA 1 L1C 1 L2D 2 L1E 2 L2

CC 0 XXB 1 L2E 1 L5A 2 L2D 2 L5

DD 0 XXA 1 L3E 1 L4B 2 L3C 2 L4

EE 0 XXD 1 L4C 1 L5A 2 L4B 2 L5

4. Now, the network has converged. No changes willoccur in the distance vectors without a topologychange.

* Note: Routing updates sent at random intervals, not synchronously as shown in this example.


Distance Vector Problems

• ProblemsRouting tables slow to convergeRoute flappingCycles can occur after topology changes

• OptimizationsTriggered updatesSplit horizon with poison reverse

A B CL1 L2

Cycle in tables


Distance Vector Example 2

A

B

D E

CL1

L3

L2

L4

L5

AA 0 XXB 1 L1D 1 L3C 2 L1E 2 L3

BB 0 XXA 1 L1C 1 L2D 2 L1E 2 L2

CC 0 XXB 1 L2E 1 L5A 2 L2D 2 L5

DD 0 XXA 1 L3E 1 L4B 2 L3C 2 L4

EE 0 XXD 1 L4C 1 L5A 2 L4B 2 L5

1. Begin with the converged routing tables from the previous example.

2. Link L2 between B and C fails. B begins using link L1 to get to C. However, A uses link L1 to get to C, so there is now a cycle between A and B. There is also a cycle between C and E.

AA 0 XXB 1 L1D 1 L3C 2 L1E 2 L3

BB 0 XXA 1 L1C 3 L1D 2 L1E 2 L2

CC 0 XXB 3 L5E 1 L5A 2 L2D 2 L5

DD 0 XXA 1 L3E 1 L4B 2 L3C 2 L4

EE 0 XXD 1 L4C 1 L5A 2 L4B 2 L5

Temporary Cycle

3. Routing tables continue to be exchanged.A

A 0 XXB 1 L1D 1 L3C 3 L3E 2 L3

BB 0 XXA 1 L1C 3 L1D 2 L1E 2 L2

CC 0 XXB 3 L5E 1 L5A 2 L2D 2 L5

DD 0 XXA 1 L3E 1 L4B 2 L3C 2 L4

EE 0 XXD 1 L4C 1 L5A 2 L4B 3 L4

4. Routing tables converge after another exchange.

AA 0 XXB 1 L1D 1 L3C 3 L3E 2 L3

BB 0 XXA 1 L1C 4 L1D 2 L1E 2 L2

CC 0 XXB 4 L5E 1 L5A 2 L2D 2 L5

DD 0 XXA 1 L3E 1 L4B 2 L3C 2 L4

EE 0 XXD 1 L4C 1 L5A 2 L4B 3 L4


Path Vector Routing

• Distribute full paths to destinations• Simple• Converges quickly• Every node on network knows full network

topology• Used by the Border Gateway Protocol (BGP)


Multicast Routing Discussion

• What is the problem?Need to find all receivers in a multicast groupNeed to create spanning tree of receivers

• Design goalsMinimize unwanted trafficMinimize router stateScalabilityReliability


Tree Building Choices

• Flood and pruneDistance Vector Multicast Routing Protocol (DVMRP)Protocol Independent Multicast Dense Mode (PIM-DM)

• Explicit joinCore Based Trees (CBT)Protocol Independent Multicast Sparse Mode (PIM-SM)

• Flood network topology to all routersLink state protocolMOSPF


Data Flooding• Send data to all nodes in network• Problem

Need to prevent cyclesNeed to send only once to all nodes in networkCould keep track of every packet and check if it had previously visited node, but means too much state

Sender

R3R1

R2


Reverse Path Forwarding (RPF)

• Simple technique for building trees• Send out all interfaces except the one with

the shortest path to the sender• In unicast routing, routers send to the

destination via the shortest path• In multicast routing, routers send away from

the shortest path to the sender


Reverse Path Forwarding Example

R5 R6

R3R2

R1

R4 R7

Sender

2. Router R2 accepts packets sent from Router R1 because that is the shortest path to the Sender. The packet gets sent out all interfaces.

1. Router R1 checks: Did the data packet arrive on the interface with the shortest path to the Sender? Yes, so it accepts the packet, duplicates it, and forwards the packet out all other interfaces except the interface that is the shortest path to the sender (i.e the interface the packet arrived on).

Drop

Drop3. Router R2 drops packets that arrive from Router R3 because that is not the shortest path to the sender. Avoids cycles.


Data Distribution Choices

• Source rooted treesState in routers for each senderForms shortest path tree from each sender to receiversMinimal delays from sources to destinations

• Shared treesAll senders use the same distribution treeState in routers only for wanted groupsNo per sender state (until IGMPv3)Greater latency for data distribution


Source Rooted vs Shared Trees

B

A

C

D

B

A

C

D

Source Rooted Trees

Shared Tree

Traffic is heavily concentrated on some links while others get little utilization.

Routers maintain state for each sender in a group.

Often does not use optimal path from source to destination.


Distance Vector Multicast Routing (DVMRP [Deering88])• Source rooted spanning trees

Shortest path treeMinimal hops (latency) from source to receivers

• Extends basic distance vector routing• Flood and prune algorithm

Initial data sent to all nodes in network using RPFPrunes remove unwanted branchesState in routers for all unwanted groupsPeriodic flooding since prune state times out (soft state)


DVMRP Problems

• Problems of distance vector routing• State maintained for unwanted groups• Bandwidth intensive

Periodic data flooding per groupNo explicit joins, and prune state times out

Not suitable for heterogeneous networks

• Poorly handles large number of sendersScaling = O(Senders, Groups)


Multicast Tunneling

• ProblemNot all routers are multicast capableWant to connect domains with non-multicast routers between them

• SolutionEncapsulate multicast packets in unicast packetTunnel multicast traffic across non-multicast routers

• Internet MBONEMulticast capable virtual subnet of InternetNative multicast regions connection with tunnels


Multicast Tunneling Example (1)

UR1 UR2

MulticastRouter 1

MulticastRouter 2

Sender 1

EncapsulatedData Packet

Unicast Routers

Multicast Router 1 encapsulates multicast packets for groups that have receivers outside of network 1. It encapsulates them as unicast IP-in-IP packets.

Network 1

Receiver

Network 2

Multicast Router 2 decapsulates IP-in-IP packets. It then forwards them using Reverse Path Multicast.


Multicast Tunneling Example (2)

MR1 MR2

VirtualInterfaces

Virtual Network Topology


Multicast Problems

• Debugging is difficult

• Immature protocols and applications

• Interoperability

Flood and prune/explicit join

• Routing instability


Operational Problems

• Debugging is difficult

• Misconfigured routers inject unicast routing tables into multicast routing tables

• Black holesCisco to Cisco tunneling using DVMRP doesn’t work

Routes exchanged, but no data flows

RPF checks on different routers think multicast traffic should be coming from the other router

• Backchannel tunnelsImproper tunnels cause non-optimal routing behavior


Multicast Address Allocation

• ProblemMulticast addresses are a limited resourceCurrent multicast address allocation scheme does not scale and makes multicast routing more difficult

• SolutionUse dynamically allocated addressesLocation of address allocation determines root of shared treeHierarchical address allocation scales better and helps multicast routing


Multicast Address Allocation Architecture

• Multicast Address Set Claim (MASC)Protocol to allocate multicast address sets to domainsAlgorithm: Listen and claim with collision detectionMakes hierarchy available to routing infrastructure

• Address Allocation Protocol (AAP)Protocol for allocating multicast addresses within domainsUsed by Multicast Address Allocation Servers (MAAS)

• MDCHP (Multicast DHCP)Protocol for end hosts to request multicast addressExtension to DHCP (Dynamic Host Configuration Protocol)


Multicast Address Allocation Example

MAAS

MDHCP

MAAS

MDHCP

MAAS

MDHCP

MAAS

MASC MASC

Multicast AAP

MASC

TCP MASC Exchanges

Allocation Domain


Scoping Multicast Traffic

• TTL basedBased on Time to Live (TTL) field in IP headerOnly packets with a TTL > threshold cross boundary

• Administrative scopingSet of addresses is not forwarded past domainMore flexible than TTL based.

• Scoped addresses224.0.0.* never leaves subnet


TTL Scoping Example

R1 R3

Receiver 3

Receiver 1

Sender

R2

Receiver 2

Network 1Network 2

Network 3 Network 4TTL=1

TTL=2 TTL=3

R4

TTL=4

TTL=4 TTL=33

R4 blocks trafficwith TTL < 32


Administrative Scoping Example

R1 R2 R3 R4

Host

CAIRN High Speed Network UC Berkeley NetworkTo Rest

of WorldTo Rest

of World

• Administrative scoping allows traffic to be limited to a region based on its multicast group address, resulting in more flexible network configurations.

• The Host can send traffic that is limited to only the CAIRN High Speed Network, to only the UC Berkeley Network, to both, or to the rest of the world.

• 239.2.0.0 - 239.2.255.255: Traffic scoped to only the CAIRN High Speed Network• 239.3.0.0 - 239.3.255.255: Traffic scoped to only the UC Berkeley Network• 239.4.0.0 - 239.4.255.255: Traffic scoped to both the CAIRN and UC Berkeley Networks• 224.0.1.0 - 238.255.255.255: Traffic scoped to the rest of the world


ISP Concerns• Multicast causes high network utilization

One source can produce high total network loadExperimental multicast applications are relatively high bandwidth: audio and videoFlow control non-existent in many multicast apps

• Multicast breaks TELCO/ISP pricing modelCurrently, both sender and receiver pay for bandwidthMulticast allows sender to buy less bandwidth while reaching same number of receiversLoad on ISP network not proportional to source data rate


Economics of Multicast

• One packet sent to multiple receivers• Sender

+ Benefits by reducing network load compared to unicast+ Lower cost of network connectivity

• Network service provider- One packet sent can cause load greater than unicast packet load+ Reduces overall traffic that flows over network

• Receiver= Same number of packets received as unicast


Campus Network Operator Concerns

• Needs to control traffic distributionCampus has some networks with and without capacity to carry multicast trafficApplications produce multiple streams – different bit ratesWant to control where high bit rate streams are transmitted

• Needs stable protocol that works with different vendor equipment

Reduce the number of phone calls to netops


Multicast Problems

• Multicast is immatureTools are poor, difficult to useRouting protocols leave many issues unresolvedPIM support limited and does not interoperate

• Multicast development has focused on academic problems, not business concerns

• Routing did not address policyPIM, DVMRP, CBT do not address ISP policy concernsBGMP addresses some ISP concerns, but it is still under development


Current ISP Multicast Solution

• Restrict senders of multicast data• ISP’s beginning to support multicast

Customers are demanding serviceLong-term solution to traffic growth problem

• Multicast interchanges (MIX) being established

Similar to unicast exchange centers


What’s the Alternative

• Broadcast distribution networks (e.g., broadcast.com, real, etc.)

Build private network with traffic splitters in remote sitesClient connects to nearest traffic splitterBuild cache at remote sites

• <put your great idea here!>


Splitter Network

S

Streaming Server

S

S

S


Future Directions

• Improving applications and networks for distributed multimedia

Make applications more adaptiveMake protocols more resilient to lossMake algorithms more resilient to lossMake networks more responsive and flexible

• Develop new models/protocols for multicast services

• Fix routing problems

introduction to multicast network protocols october 5, 1999

Documents

multicast transportexample

ietf ip multicast

single multicast server

igmp membership querynetwork

hostsleave group

traverse network links

group messageonly

leaves conferencesends