3/14/2016multicast: protocol & implementation nasir faruk (i am grateful to jonathan couzens,...

05/14/23 Multicast: Protocol & Implementation

Nasir Faruk

(I am grateful to Jonathan Couzens, JANET(UK), and Cisco for the originals from which the PIM-SM diagrams were derived.)

Multicast:

Protocol and Implementation

Welcome to Week 12


IP Multicast: topics

• Flash back !• Isuues associated with multicast

– sparse & dense mode– group membership

• Single-domain multicast– RPF, RPB & RPM recap– PIM-DM– PIM-SM

• Inter-domain or multi-domain multicast– MSDP

Issues for multicast I

• Identifying group members– Neither unicast nor broadcast are adequate– Achieved with special addressing scheme for active participants

• Tracking current group membership– Uses a dynamic membership protocol– Not required for fixed groups

• Efficient distribution mechanism– To avoid multiple copies of same information traversing same part of

network– Network must be multicast-aware– Capable of packet replication and controlled flooding

• Multicast routing scheme to maintain fault-tolerant distribution topology


Issues for multicast II

• Scaling– how to deal with large numbers of users (100s, 1,000s, …)?– affects network and end stations– reliable unicast protocols need acknowledgements from receiver to

sender• reliable multicast cannot operate in the same way

• Timing– a much more complex set of issues in group communication since

there are more than two views of time– group aspects are primarily end host application concerns,

not network


Using replicated unicast

S

Rx Rx

Rx

Rx

Rx

Rx

Rx

Rx

Rx

R

R

R

R

9

3

2

2

1

1

Using multicast


An immediate scaling problem:-multipoint conference: all senders need to reach all receivers with each stream

–audio, video, shared applications (eg, whiteboard, powerpoint, excel)

Problems with using replicated unicast (recap.):─senders will (with large number of receivers) be overloaded─links near senders will also be overloaded─delay will increase: sender sends many copies sequentially─large conferences, TV distribution, etc., will be impossible

Solution:eliminate multiple copies of same packet on any link and from senderensure ‘best’ routes are used: much harder

[

Types of Multicast Tree

• SENDER-BASED (AS PREVIOUS DIAGRAM) ALSO CALLED SOURCE BASED TREE

– EACH ROUTER needs to have one shortest path tree for each group– If the number of the group is m, each router need s to have m SPTs, one for each group.– Sender based tree (SBT) is where the tree is routed at the sender – SBT is most economical way of doing isolated multicast in a network– SBT is not static like in the case of spanning tree protocol its changes as the number as

host changes so the router has to agile enough.– E.g. I got no people here I don’t need to send any packet here, I got many ppl here I

need to send more packet here

• CORE-BASED (GROUP SHARED TREE)– ONLY THE CORE ROUTER, which has a SPT for each group is

involved in multicasting– Instead of each router having m SPTs, only one router (i.e. center/core

or RENDEZOUS ROUTER takes responsibility for distributing multicast traffic.

– compromise


DM / SM Protocols

• There are two ways of distributing multicast:

• Dense Mode:• Dense Mode is sending the multicast packet to everyone in the group.• Periodically sending to everybody it important when you got a lot of people in

a company LAN but it wont woke in th IP internet u got periodic saturation

• Sparse Mode:– -in spare mode you send when someone sign on– Typified by ‘send on request’ behaviour

– group membership (though actually, it’s likely needed anyway).– End-system gets nothing unless it explicitly asks for it– Appropriate when:

– only some of hosts want to receive– scope is potentially worldwide


Taxonomy of Multicast protocols


Multicast routing

Source based Tree Core based Tree

MOSPF DVMRP

PIM

PIM-DM PIM-SM CBT

Reverse Path Forwarding

• Crucial to understanding wide-area multicasting• How a router determines whether to forward a multicast packet and, if

so, where to….• Unicast forwarding: recall

– works by looking up the destination address in a routing table and forwarding to the associated interface (for next-hop router)

• Multicast forwarding– look up the source address in the routing table– did the packet arrive on the interface to which a packet would have been sent if that

address had been the destination address?• this is the ‘RPF check’

– if so, forward it out of all the multicast-enabled interfaces except for the one on which it arrived

– if not, drop packet (silently)– Eliminate flooding and looping : Only one copy is forwarded; the other copies are

dropped

• Central idea for PIM: uses unicast routing tables, independently of how these are established and maintained


Concepts and terminology• RPF (Reverse Path Forwarding) applied to flooding

eliminates loops but still leaves the possibility of a subnet receiving multiple copies of packets: a feature of

delivery based on source instead of destination• RPB (Reverse Path Broadcast)

to cure above problem, for each source, choose a single router to be parent for delivery of multicast packets to a subnet: called designated parent router (DR)

still a broadcast procedure, no membership information used: reverse path broadcast

DR is that with smallest cost to sender, determined using link-state or poison-reverse with distance-vector (& lowest IP address if ‘tie’); PIM-SM has own election scheme

• TRPB (Truncated Reverse Path Broadcast) truncation uses membership info to avoid forwarding pkt to subnet with no members

• RPM (Reverse Path Multicast) to remove receipt of packets on unwanted multicast addresses, pruning may be used;

grafting may be used to resume receipt sometimes known as reverse path multicast pruning & grafting require use of a group membership protocol uses group membership info to construct genuine multicast tree

05/14/23


Group membership• IGMP is used for hosts to join a group.• Join and Report messages are sent to the multicast address of the group

which the host wishes to join.– a host does not need to know the address of a multicast router– a host responds to router membership Query messages by setting a

random timeout after which it transmits a Report about its membership– a host hears the Reports from other hosts on its subnet: if it hears a

Report about its own group in the interval, it does not need to respond to the router until another Query is heard

• Remember, IGMP is a host-router protocol. Exchange of information between routers is a matter for other (routing) protocols (if any).– IGMP Report and Join are sent with TTL=1: not forwarded by routers– strictly: it is only needed for:

• sparse-mode protocols • receivers: a host may send to any group without being a member

– dense-mode protocols assume all hosts receive all groups until told otherwise


Protocol-Independent Multicast (PIM)

• Terminology:– For each multicast flow, a router may need to keep state relating to:

• (S,G) - source S, sending to group G• (*,G) - all sources for group G

– Typically, needs to remember whether and where to forward packets• Router-to-router protocol• Protocol-independent

– uses existing - unicast - routing information– independent of underlying – unicast - routing protocol(s)

• Two flavours (at least!)– Dense-Mode: RFC3973 (January 2005)

• like a successor to DVMRP– Sparse-Mode: reworked: RFC2362 (August 2006) – standards track

• Single-source mode• Bi-directional-mode


PIM Dense-Mode: PIM-DM

• A dense-mode protocol

• Flood-and-prune

• Distribution tree for the traffic rooted at the source


PIM-DM - initial flooding

Source

Receiver

Multicast Packets(S, G) State created inevery every router in the network!


PIM-DM - pruning back

Source

Receiver

Multicast PacketsPrune Messages


PIM-DM - after pruning

Source

Receiver

Multicast Packets(S, G) State still exists inevery every router in the network,even after pruning back!


PIM-DM

• Appropriate if– scope is local, e.g., financial dealing rooms– virtually all want to receive the traffic

• Not so good if– few want the traffic– global transmission

• Undesirable!• Especially for sites with low-speed access


PIM Sparse-Mode: PIM-SM

• A sparse-mode protocol– traffic only received if explicitly requested– but have to know what to ask for….

• as with any sparse-mode, membership-based protocol, need to know which group to listen to: like knowing which radio or TV channel to select

• To avoid propagation of state throughout all routers, PIM-SM has the concept of a rendezvous point (RP)– indirectly, Receivers JOIN to the RP– and, also indirectly, Senders REGISTER with the RP– actually, member hosts just IGMP join to local last-hop router; it is last-

hop router which knows about and communicates with RP– strictly, Designated Router (DR): all rtrs receive join, only DR acts on it

• Two distribution trees involved:– Shared tree, rooted at the RP

• RP tree or RPT– Source-specific tree (SST), rooted at the source DR

• All last-hop routers in domain need to know RP location


PIM-SM – (receiver) join

Receiver

RP

(*, G) JoinShared Tree

(*, G) State only, created along the newbranch of the Shared Tree.


PIM-SM - sender registration & SST

Receiver

RP

(S, G) Join

Source

Shared TreeSource Tree branch

(S, G) State only,created along (part of) Source Specific Tree (SST).

Traffic Flow

(S, G) Register (unicast) Unicast Register includes encapsulated (tunnelled) multicast packet


PIM-SM - sender registration stop

Receiver

RPSource

Shared Tree RP sends a Register-Stop back to the first-hop DR (which is unaware Join originated by RP) to stop the Register process, since RP now receiving ‘natively’.

(S, G) Register-Stop (unicast)

Traffic Flow(S, G) traffic begins arriving at the RP via the SST.

(S, G) Register (unicast)

Source Tree branch


PIM-SM – ‘native’ multicast flow via RP

Receiver

RPSource

Shared TreeTraffic Flow

Source traffic flows nativelyalong (part of) SST to RP.From RP, traffic flows downthe Shared Tree to Receivers.Source Tree branch


PIM-SM - source-specific shortest path tree (SPT)

Receiver

RP

(S, G) Join

Source

SST / SPTShared Tree

Last-hop DR joins SST.

Additional (S, G) State is created along new part of the SST: SPT.

Traffic Flow


PIM-SM – switchover to SPT: creation and prune to RP

Receiver

RPSource

Source TreeShared Tree

(S, G) RP: Pruneby-passed partof Shared Tree

Traffic begins flowing down the new branch of the SST: SPT.

RPF check triggers dropping of packets from RP & additional (S, G) state creation along the RP Shared Tree to prune off (S, G) traffic.

Traffic Flow


PIM-SM – use of SPT

Receiver

RPSource


(S, G) traffic flow is now flowing to the Receiver via the SPT.

Traffic Flow

(S, G) traffic flow from RP has been pruned off the Shared Tree and ceases to flow.


PIM-SM - source tree switchover

Receiver

RPSource


(S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic.

Traffic Flow

(S, G) Prune


PIM-SM – RPT / SPT switchover completed

Receiver

RPSource


(S, G) Traffic flow is now only flowing to the Receiver via the SPT part of SST.

Traffic Flow

PIM-SSM


• Optimized delivery of common applications like IPradio and IPTV are provided by source-specific trees

• PIM-SM can construct SSTs but not under user control• Source-Specific Multicast provides support for user-requested use

of an SST for a specific sender– IGMP is augmented to enable a user to request connection to a

multicast address and sender using an SST – Minor changes to PIM-SM enable its existing capability to be triggered

by such requests, thus extending the service directly to users


PIM-SM - RPs & bootstraps

• Which is the best router to be the RP for a network?– Needs to be ‘well-connected’: in the ‘centre’ of a network?– But note that, if global multicast connectivity required, RP will need

efficient path to peer RPs: so, at the edge?– Depends on network configuration and traffic patterns.

• More than one RP possible– Dedicate one (or more) RP to local groups and place it (them) centrally– Have other(s) for global groups and placed nearer the edge

• Within a single network, all RPs are part of single network management domain

• A set of routers designated as candidate RPs• Bootstrap router:

– knowledge of which RPs are active, updated by regular messages– distributes this to domain routers, including RPs

• Set of candidate bootstrap routers– one elected: other bootstraps & RPs kept updated


IP Multicast: topics

• ‘Recap’– Mbone – sparse & dense mode– group membership

• Single-domain multicast– RPF, RPB & RPM recap– DVMRP– PIM-DM– PIM-SM

• Inter-domain or multi-domain multicast– MSDP


Multidomain Multicasting

• Domains are management domains

• Each domain has its own RP(s), known to routers in that domain

• RP is not generally known outside its own domain

• So, how does multicast traffic flow between domains?

• For PIM-SM to work, RPs need to know about membership of a given group

• It knows about those within its own domain, but how can it know about those in other domains?


Multidomain Multicasting

• Receivers?– RP waits for receiver to join

• then it establishes the shared tree to it

• Receivers in another domain?– Always dealt with by the (an) RP in the receiver’s own domain

• Senders?– RP will send join towards any sender, once RP knows about it

• Sender router only registers with its own RP• RPs need to know about senders in other domains,

i.e., need to exchange (S,G) state information– Currently, use Multicast Source Distribution Protocol (MSDP)

• has experienced problems; not necessarily long-term solution– BGP being extended to exchange routing information for multicast

sources as well as the usual interdomain unicast routes• Given that all RPs know about all (S, G)s, sender trees can be built.• This (BGP and MSDP) remains an active area of work.• NB: PIM-SSM works directly in a multi-domain context


Multicast protocol refs: books: DVRP, PIM-SM, MSDP

• Wittman & Zitterbart: Multicast Communication– Chapter 3.

• Forouzan: Data Communications and Networking (4th ed.)– Sections 21.3 & 21.4: reasonable introduction to IGMP: NB, it is IGMPv2-

based: IGMPv3 is published but not yet deployed everywhere. (IGMPv3 has some extra options such as source-specific join and leave/prune.)

– Sections 22.4 has a reasonable discussion but much is based on MOSPF, not discussed in this course. PIM-SM is mentioned but not covered.

• Peterson & Davie: Computer Networks (4th ed.)– Section 4.4: this has been expanded in this edition and includes a brief

description of PIM-SSM as well.• Stallings: High-Speed Networks (2nd ed.)

– Section 16.2: too brief, more detail needed.


Multicast protocol refs: IETF docs: DVRP, PIM-SM, MSDP

• RFC 1075: DVMRP– care: this is quite old (when Mbone was new): mixes Mbone tunnelling with

description of routing protocol.• RFC 4601: PIM-SM (Section 3 up to 3.3 inclusive.)

– This version is fairly recent. It fixes a number of problems associated with overlapping / intersecting trees and the fact that ALL the operations of tree building (registering/joining) and tear-down (register stopping/pruning) are asynchronous, so may occur in any order. It also enhances edge router functionality (not covered in the course).

– Where notations differ, this course uses that from this version of PIM-SM. • RFC 3618: MSDP (only recently deployed; complicated; only overview needed)• Internet drafts (see P00556 ‘supporting material’)

– draft-ietf-mboned-intro-multicast-03.txt: ‘Introduction to IP Multicast Routing’(Beware: this is now old wrt the status of multicast deployment and protocols in use; use only as technical introduction to protocols; uses Mbone to mean, roughly, ‘the multicast-enabled or -connected parts of the Internet’.)


Review topics for private study (1): PIM-SM

1. What is the purpose of the shared tree (RPT) in PIM-SM? 2. Which trees by-pass it?3. Is a ‘by-pass’ tree always built?4. Do all sources/receivers always use same RP?5. Why does designated router (DR) initially tunnel data from sender S to RP?6. How does it tunnel it, i.e., in what kind of (IP) packets?7. What other function do these encapsulating packets perform?8. What is the sequence of events which enables the DR to stop tunnelling S’s

multicast data to the RP?9. After (8), assuming the shared RP tree is still in use for S’s data to G, what

has been put in place in the intervening routers which enables (S,G) packets forwarded by the DR to reach the RP?


Review topics for private study (2)

10.What prevents an IGMP router query from causing the router to be overloaded by host reports in response? Explain.

11.How is the designated router (DR) selected for a subnet? Is it necessarily the same for all groups?

12.Do both senders and receivers have to join a group in a sparse-mode protocol?

13. In RPB (or RPM), what does having a DR achieve for delivery to that subnet?

3/14/2016multicast: protocol & implementation nasir faruk (i am grateful to jonathan couzens,...

Documents