Sunteți pe pagina 1din 57

Multicast routing protocols

IGMP – IP Group Management Protocol


PIM – Protocol Independent Multicast
MOSPF – Multicast OSPF
DVMRP – DV Multicast Routing Protocol

E7310-Multicast-2/Comnet 1
Multicast in local area networks and IGMP

E7310-Multicast-2/Comnet 2
Multicast addresses
32 bits

MSB(t) network host Class


1110 28 bits - multicast group address D
224.0.0.0 - 239.255.255.255
Flat address space
Reserved addresses:
224.0.0.1 - 224.0.0.255 Local network control (TTL=1)
224.0.0.1 All hosts
224.0.0.2 All routers
224.0.0.5 All OSPF routers
224.0.0.6 OSPF designated routers + backup designated r.
224.0.0.9 All RIP-2 routers
239.0.0.0 - 239.255.255.255 Administratively scoped multicast (=private)
239.192.0.0 - 239.195.255.255 Organization local scope

E7310-Multicast-2/Comnet 3
Sending multicast packets

•  The sender does not need to belong to the multicast group.


•  In broadcast networks only one copy of the multicast packet
should be sent
–  Multicast can be implemented as broadcast + filtering
–  Ethernet: broadcast = FF:FF:FF:FF:FF:FF
•  Point-to-point links need no special arrangements
•  ATM needs a centralized server, e.g. the Broadcast and
Unknown Server (BUS) in LAN Emulation (LANE)

E7310-Multicast-2/Comnet 4
Multicast in broadcast networks

•  Some broadcast networks (e.g. Ethernet) support


group addresses
–  The group address is based on the IP address
•  Place low-order 23 bits of IP multicast address into low-order 23
bits of MAC address 01-00-5E-00-00-00

1110 28 bit multicast group address

00000001 00000000 01011110 0 23 bits

•  Overlapping mapping ⇒ some filtering still required


•  No ARP required: Address Resolution Protocol (ARP) is a telecommunications
protocol used for resolution of network layer addresses into link layer addresses

E7310-Multicast-2/Comnet 5
Internet Group Management Protocol (IGMP)

•  Purpose: Let routers discover if there are multicast receivers


on the network
•  Routers do not need to know the exact members, only
whether there are members for a specific group
•  Used locally within a network
–  TTL=1 in all IGMP messages
•  Router with lowest IP address is active on a network
•  Runs directly over IP (protocol type 2)
•  Replaced by Multicast Listener Discovery (MLD) in IPv6
RFC
2236
E7310-Multicast-2/Comnet 6
IGMPv2 - Internet Group Management
Protocol
Type Max Resp Time Checksum
Group Address (GA)
à  Sent to “all systems” multicast address 224.0.0.1
à  ”Leave group” message sent to ”all routers” address 224.0.0.2

Host waits Host Router


random time
[0...Max Resp Membership Query (type 0x11)
Time] prior to [General (GA=0) / Group specific (GA≠0)]
response and
suppresses its V2 Membership Report (type 0x16) (v2) [Group]
response if it
sees another V1 Membership Report (type 0x12) (v1)
response to the
same group
Leave Group (type 0x17) Are there
Membership Query (type 0x11) [Group specific] other members
left?

E7310-Multicast-2/Comnet 7
IGMPv3 adds selective reception
from sources within a group
Type=0x11 Max Resp Time Checksum
Group Address
Reserved + Flags Number of Sources
Source Address
Source Address
Host Source Address
Router
Membership Query (type 0x11)
Variants:
•  General query (GA=0 and number of sources=0)
•  Group specific query (GA≠0 and number of sources=0)
•  Group and source specific query (GA≠0 and number of sources>0)
V3 Membership Report (type 0x22)
Can exclude listed sources within a group or include only listed RFC
sources within a group 3376
E7310-Multicast-2/Comnet 8
PIM – Protocol Independent Multicast

E7310-Multicast-2/Comnet 9
PIM – Protocol Independent Multicast

•  Most popular multicast protocol


•  Two modes
1.  Dense mode (PIM-DM)
2.  Sparse mode (PIM-SM)
•  Independent of any particular unicast routing protocol
•  Uses unicast routing table
⇒  Simple protocol
⇒  Assumes the links are symmetric
⇒  No tunnels
•  Messages sent in IGMP packets

E7310-Multicast-2/Comnet 10
PIM Dense Mode

•  For dense multicast groups


–  Dense: The probability is high that a small randomly picked area
contains at least a group member, e.g. LAN
•  Based on RPF with pruning, ”flood-and-prune”
•  Principle similar to DVMRP
–  Simpler
–  Less efficient
•  Messages implemented as extensions to IGMP:
–  Hello, Join/Prune, Assert, Graft

RFC
DVMRP: Distance Vector Multicast Routing Protocol 3973
E7310-Multicast-2/Comnet 11
PIM-DM implementation of RPF
Receive multicast packet P from
source S to group G on interface U

Received from router with


Equal-cost multipath yes largest IP address no X
no yes

U used to send packets to S no Send prune(S,G) message on U


yes

M(n,S,G)=1 for all n yes Send prune(S,G) message on U

no
M is a cache for prune messages:
For all n where M(n,S,G) ≠ 1: M(n, S, G) = 1 if a prune(S,G) has been
Forward P on interface n received on interface n
Least recently used entries may be dropped

E7310-Multicast-2/Comnet 12
PIM-DM – Pruning

A B R

prune

S C R D

prune
prune
E F

prune

G R = receiver

E7310-Multicast-2/Comnet 13
PIM-DM – Grafting

Graft messages are sent when


A B R
there is a new receiver on a
previously pruned branch

S C R D

graft

E F

graft

G R (new!) R = receiver

E7310-Multicast-2/Comnet 14
PIM-DM – Pruning on broadcast networks

Prune messages sent to ”all-routers” local multicast address


(224.0.0.2)
S

A 3. delay the prune


4. join 5. cancel the prune
1. multicast

2. prune Note: this is the only


B C situation when a join
message is sent in
D no members PIM-DM

member
E7310-Multicast-2/Comnet 15
PIM-DM – Resolving multicasts received
on multiple path
S

multicast

B
A and C see prune(S,G) if dother router < dmy distance:
packets for (S,G) prune interface
A from another router C
assert(S,G,dA) assert(S,G,dC)

D D receives duplicate packets

E7310-Multicast-2/Comnet 16
PIM Sparse Mode

•  Most popular PIM variant, e.g. in IPTV


•  Uses the center-based tree algorithm
•  Evolved from the Core-Based Tree (CBT) protocol
•  Uses the normal unicast routing table build by OSPF or
MBGP (both interior and exterior protocol)
•  Rendezvous point (=center) connects the receivers with the
senders
•  Receivers must explicitly join
•  Generates a shared unidirectional tree
•  Can switch to source based trees to optimize routes
RFC
4601
E7310-Multicast-2/Comnet 17
PIM-SM route entries

•  Route entry includes


–  source address (can be *)
–  group address (can be *)
–  incoming (upstream) interface
–  list of outgoing (downstream) interfaces
–  timers, flags
•  Packets match on the most specific entry
1.  (S,G) – a specific source in a specific group
2.  (*,G) – all sources in a specific group
3.  (*, *, RP) – all groups that hash to a specific RP
(Rendezvous point)

E7310-Multicast-2/Comnet 18
Messages

•  Join (*, G)
–  To join a group in order to receive traffic from all sources of the group
–  Adds a branch to a shared tree
•  Join (S, G)
–  To receive traffic from a given source of the group
–  Adds a branch to a source-specific tree
•  Prune (*, G)
–  Prunes a branch from the shared tree
•  Prune (S,G, RP)
–  Prunes a source from the shared tree (if the same packets are received on a source-
specific tree as well)
•  Register
–  To register a sender and send an encapsulated packet to the multicast group
•  Register stop
–  To ask a sender to stop sending Register messages (and instead use the multicast tree)

E7310-Multicast-2/Comnet 19
PIM-SM example (1)

•  Join packets are sent toward the RP (Rendezvous point)


–  Address=G, Join=RP, wildcard (WC) bit, RP-tree (RPT) bit,
Prune=(empty)
•  Intermediate routers set up (*, G) state and forward the join

A B C D E

F G H I J
RP
1.join (*,G)
K L M N
Receiver

E7310-Multicast-2/Comnet 20
PIM-SM example (2)

•  Senders send packets to RP encapsulated in register


messages, RP resends packets on the tree
•  RP may contruct a (S,G) entry, and send periodic joins to the
sender
Receiver

A B C D E
5.join (*,G)
4.register-stop (to M)

F G H I J
RP
1.join (*,G) 3.join (S,G) (to M)
2.register (to RP)
K L M N
Receiver Sender

E7310-Multicast-2/Comnet 21
PIM-SM example (3)

•  If the last-hop router (K and A) sees many packet from the


source, it can switch from a shared tree to a shortest path
tree for (S,G). It then sends a join directly to the source, and
prunes the previous path.
Receiver

A B C D E

F G H I J
prune
prune (S, G, RP) RP
join
(S,G)
K L M N
Receiver Sender

E7310-Multicast-2/Comnet 22
PIM-SM example (4)

•  Copies of the packets are still sent to RP


•  Join/prune messages are sent periodically for each route
entry so that they do not time out
Source based trees
Receiver + minimize delay
+ distribute traffic
A B C D E

F G H I J
RP
(S,G)
K L M N
Receiver Sender

E7310-Multicast-2/Comnet 23
Selection of Rendezvous Point

•  A small group of routers configured as bootstrap router candidates


•  One of them selected as bootstrap router (BSR) for the domain
•  BSR periodically sends Bootstrap messages through the domain
•  A set of routers are configured as candidate RPs for given groups
–  typically same as candidate BSRs
•  Candidate RPs periodically unicast Candidate-RP-Advertisements
to the BSR, which includes them in the Bootstrap message
–  Candidate RP’s own address
–  Optional group address and mask length
•  The RP is selected by a hash function from the valid candidate
RPs
–  All routers use the same hash functions, therefore all routers
select the same RP for a given group

E7310-Multicast-2/Comnet 24
PIM-SM can interoperate with DVMRP and
other multicast protocols
•  PIM Multicast Border Routers (PMBR) connect PIM-SM with
other multicast protocols
external receivers
external group Join/Prune (*, *, RP)
Register (G, External)
PMBR Register stop
PMBR

RP
RP

PMBR

E7310-Multicast-2/Comnet 25
Considerations

•  PIM can switch from sparse mode to dense mode


–  Controlled by a parameter, which defines when the group is dense
enough
•  Source specific routes require the use of IGMPv3
•  The RP may be a single point of failure
•  The RP may be a bottle-neck

E7310-Multicast-2/Comnet 26
Other variants (based on PIM-SM)

1.  Source-Specific Multicast (SSM) RFC


–  Defines “channels” in terms of source-group pairs 3569
⇒ several multicast groups can use the same group address
•  Avoids collisions of group addresses
•  Adds security and prevents spamming
2.  Bi-directional PIM (BIDIR-PIM)
–  Uses a bidirectional tree
–  Selects a Designated Forwarder (DF) that forwards data to the RP
without source-specific routes
•  The main responsibility of the designated forwarder is to decide what
packets need to be forwarded upstream toward the rendezvous point.
RFC
5015
E7310-Multicast-2/Comnet 27
MOSPF – Multicast extensions to OSPF

E7310-Multicast-2/Comnet 28
MOSPF – Multicast extensions to OSPF

•  Idea: if the location of receivers is known to all routers, multicast


should be possible to exactly the receivers only!
•  MOSPF is an extension of OSPF, allowing multicast to be
introduced into an existing OSPF unicast routing domain.
•  Unlike DVMRP, MOSPF is not susceptible to the normal
convergence problems of distance vector algorithms.
•  MOSPF limits the extent of multicast traffic to group members only
–  Desirable for high-bandwidth multicast applications or limited-
bandwidth network links (or both).
•  Unlike OSPF, MOSPF does not support multiple equal-cost paths
•  MOSPF calculates the source-based trees on demand

E7310-Multicast-2/Comnet 29
MOSPF can be deployed gracefully

•  Introduce multicast routing by


–  adding a new type of LSA to the OSPF link-state database
–  adding calculations for the paths of multicast packets
•  The introduction of MOSPF to an OSPF routing can be gradual
–  Multicast capability marked with a M-bit in the option flag
–  Routers without multicast capability are ignored in calculating
multicast routes ⇒ MOSPF will automatically route IP multicast
datagrams around routers incapable of multicast routing
–  No tunnels ⇒ there may be a unicast path, but no multicast path
•  MOSPF can be deployed in the MBONE.
–  A MOSPF domain can be attached to the edge of the MBONE, or can
be used as a transit routing domain within the MBONE’s DVMRP
routing system.

E7310-Multicast-2/Comnet 30
An MOSPF Routing Domain
S1 S2
128.186.1.0/24 128.186.2.0/24
3 3
10
A B
1 1
128.186.3.0/24 128.186.6.0/24
1 1
1
10 F 3
C D
3 G1
10 10 128.186.5.0/24
G1
E G
3 128.186.4.0/24 3
E.g. G1 = 226.1.7.6
G2 G1 Group m-LSA created and flooded when
e.g. host on 128.186.4.0 joins G1.
E7310-Multicast-2/Comnet 31
A Group-membership-LSA is created and flooded
when a user joins a multicast group using IGMP
LS Type 6 = Group Membership LSA

32 bits
6=Group Membership LSA LS age Options=E LS type=6

Common LS header
Advertised multicast group Link state ID = 226.1.7.6 (group G1)
MOSPF designated router Advertising router = 128.186.4.1 (router E)
LS sequence number = 0x80000001
LS checksum length
1=Router, 2=Network Referenced LS type = 2 (network)
Originating router's router ID Referenced Link State ID = 128.186.4.1

E7310-Multicast-2/Comnet 32
MOSPF calculates shortest-path trees on
demand •  A separate tree is calculated for each combination of
S1 group and source
128.186.1.0/24 •  Result is stored in Multicast Forwarding Cache Entry
3 •  Hierarchy reduces the number of calculations
A 1
B
B 128.186.6.0/24
B 128.186.3.0/24 1
1
1 1
F 3
C D
3 G1
B 10 10 128.186.5.0/24
G1
E G
A 3 128.186.4.0/24 3
•  Lines with label A are pruned when
G1 G1 removing redundant shortest paths.
•  Lines with label B are pruned when
removing links that do not lead to G1

E7310-Multicast-2/Comnet 33
On demand route calculations use Dijkstra’s
shortest path first algorithm

•  Calculation is rooted on the source


–  not in the current router as for unicast
•  The sources are not advertised in Group-Membership-LSAs,
only learned from the source addresses in multicast data
packets
•  For a new multicast, every router performs the same
calculation
•  Stub networks do not appear in MOSPF calculation
–  e.g., the stub networks behind router F
•  For equal cost routes, the previous hop router with the
highest address is chosen
–  e.g. G chosen instead of E

E7310-Multicast-2/Comnet 34
The Multicast Forwarding Cache Entry
stores multicast path routing info
•  For each source and group:

Router or network for multicast reception

List of interfaces, Metrics to nearest


multicasts must be sent group member

•  When network conditions change, paths are recalculated


•  Cache entries must be deleted, when changed LSAs are received
–  Router-LSA, Network-LSA (on router or link failure or cost change)
⇒ Delete all entries since it is not possible to tell which are affected
–  Group-Membership-LSA
⇒ Delete entries of that group
•  Hierarchy ⇒ The farther away the change is the fewer cache entries are
deleted.
•  When the first packet arrives in a multicast group, the routes are
recalculated

E7310-Multicast-2/Comnet 35
Inter-area multicast forwarders summarize
membership info to the backbone
S1 •  Area-border routers are called inter-
193.15.6.0/24 area multicast forwarders in MOSPF
Backbone A •  These summarize the memberships
193.18.3.0/24
of their area (e.g. router C lists
membership groups G1 and G2) to the backbone
B
Area C G1, G2
0.0.0.2
•  The inter-area multicast forwarder
193.16.1.0/24

193.16.3.0/24
Area does not advertise/forward
D 0.0.0.1
membership info from the backbone
G1 E
to their area
S2 G2 –  Non-backbone areas have no
knowledge of group members
outside of their own area.

E7310-Multicast-2/Comnet 36
For forwarding traffic to the backbone, the inter-
area multicast forwarders are members of all
groups
S1 •  Inter-area multicast forwarders
193.15.6.0/24 recieve traffic from all groups in their
Backbone A
areas (e.g. B from S2)
–  indicated with a W-bit (wildcard)
membership 193.18.3.0/24
of all groups in the router LSA
B
Area C •  The backbone knows the receivers
0.0.0.2
193.16.1.0/24

Area
193.16.3.0/24
and forwards to the following inter-
D 0.0.0.1 area multicast forwarder (e.g. traffic
G1 E
from S2 to router C)
S2 G2 •  Also inter-AS multicast forwarders
(=external routers) are considered
as member of all groups

E7310-Multicast-2/Comnet 37
Two level hierarchy aggregates both
S1 à G1 sources and group addresses
S1
193.15.6.0/24 •  In aggregation some info is lost
Area ⇒ sometimes multicasts are sent
Backbone A 0.0.0.0 needlessly: C à G: to G1
193.18.3.0/24 •  Presence of sources is reported
B C
by summary-LSA with MC-bit set:
Area
Area F to H à S3+S4 entry

193.16.3.0/24
0.0.0.2 0.0.0.1
193.16.1.0/24

VL •  Area border router advertise


H D G Group-m-LSAs to backbone
G1 VL (B:G1, D,E,F:G1, C,D,E:G2)
G2
S2 –  no exact location
F S3 E
•  Routers in non-backbone do not
Area 193.17.1.0/24
know location of group members
0.0.0.3
S4 I G1
193.17.2.0/24
x Wildcard multicast receiver receives all multicasts to all groups
E7310-Multicast-2/Comnet 38
MBone

E7310-Multicast-2/Comnet 39
MBone – an overlay multicast Internet

•  Multicast backbone (MBone) was deployed to support research


–  Enable multicast applications without waiting for full availability
of multicasting standards
•  Started in 1992
•  Overlay network
•  Uses tunnels to link multicast islands
–  Previously with source routing header option
–  Now with IP-in-IP encapsulation
R1→ R2, IP-in-IP S→G, UDP UDP-packet

•  Uses DVMRP and IGMP


[ http://www.savetz.com/mbone/ ]

E7310-Multicast-2/Comnet 40
MBone overlay is based on
workstations running DVMRP

G1 G1 Tunneling is used to bypass


unicast sections of the Internet
192.5.3/24
W1

128.5.2/24
W2 S3
S1

G1 128.5.1/24
192.7.1/24

E7310-Multicast-2/Comnet 41
Experimental routing protocols have
been developed for MBone

Tree type Shared tree Source based trees

Algorithm Center based tree Flood and prune Domain-wide reports

PIM Sparse* DVMRP


Protocols MOSPF
Core Based Tree* PIM Dense*

* These rely on unicast routing protocol to locate multicast sources.


(The other ones can route multicast on routes separate from the unicast
routes)

E7310-Multicast-2/Comnet 42
DVMRP – Distance Vector Multicast
Routing Protocol

E7310-Multicast-2/Comnet 43
DVMRP – Distance Vector Multicast Routing
Protocol
•  First multicast protocol in the Internet (1988)
•  Distance vector routing protocol similar to RIP
–  Except that sources are like destinations in RIP
•  Routers maintains separate multicast routing tables
•  Uses the reverse-path-forwarding (RPF) algorithm with pruning
•  Nodes exchange
–  Distance in hops (reverse path distance)
–  IP address and mask of source
•  Tunnels explicitly configured with
–  Destination router
–  Cost
–  Threshold
RFC
1075
E7310-Multicast-2/Comnet 44
DVMRP is used for multicast
routing in the MBone
•  DVMRP messages are IGMP messages (IP protocol=2=IGMP, TTL=1)
DVMRP header:
Version 3 presented here
Type=0x13 Code Checksum
Minor vers Major vers draft-ietf-idmr-dvmrp-v3-11
Reserved
=0xff =3

Router Router
DVMRP Probe [Code=1] – neighbor discovery
DVMRP Report [Code=2] – route exchange
DVMRP Prune [Code=7] – cut a branch of multicast tree
DVMRP Graft’ [Code=8] – add a branch of multicast tree
DVMRP Graft Ack [Code=9] – ack of graft reception

E7310-Multicast-2/Comnet 45
Probes are used for neighbor discovery

Router DVMRP Probe [àall-dvmrp-routers 224.0.0.4] Router

whole DVMRP routing table [àrouter’s address] Yes My address on


list first time
•  Probes are exchanged on tunnel and physical interfaces
•  Contains the list of neighbors on the interface
–  If empty, this is leaf network managed by IGMP
•  Multicasts are not exchanged until two-way neighbor relationship is
established
•  Routers see each others versions and capability flags ⇒ compatibility
•  Keepalive ⇒ fault detection, restart detection
–  sent each 10s, timeout set at 35s

E7310-Multicast-2/Comnet 46
DVMRP uses the concept of dependent
downstream routers
•  DVMRP uses the route exchange as a mechanism for
upstream routers to determine if any downstream routers
depend on them for forwarding from particular source
networks
–  Implemented with ”poison reverse”
–  If a downstream router selects an upstream router as the best next
hop to a source, it echoes back the route with a metric = original
metric + inf

E7310-Multicast-2/Comnet 47
Route reports are used to build the source
based trees
DVMRP Report
Router Router
Each DVMRP router periodically (60s) broadcasts to its neighbors
- the list of pairs (source, metric) Known
- source aggregation according to CIDR may be used neighbor
yes
•  The receiving MC router calculates the previous hop
on each sources multicast path = the DVMRP router that
reports shortest distance from the source
•  If equal distance ⇒ choose smallest IP address

DVMRP Report [inf < metric < 2*inf] Downstream


Designated (compare to poisonous reverse, inf=32) Dependent
forwarder
neighbor

E7310-Multicast-2/Comnet 48
Reports are processed:
Router
DVMRP Report Other interfaces
[S, metric]
Adjusted metric=metric+interface cost
If Metric<inf & Adjust metric≥inf
Set adjusted metric to inf
If Route is new and Adj metric<inf
Add route to RT
Delete prune state of more general route
Elseif Route exists
If Received metric < inf
Check if Designated forwarder status for (S,G) changes
If Adjusted metric > existing metric
From same neighbor: update metric, Schedule flash update for route
Elseif Adj.metric < existing metric
Update metric for the route
If sender was different, update RT, schedule flash updates
Elseif Adj.metric = existing metric: refresh route ...
Elseif Received metric =inf ...
Elseif Inf < Received Metric < 2 * inf ...
E7310-Multicast-2/Comnet 49
The multicast algorithm of DVMRP is based
on Reverse Path Forwarding (RPF)
Router
Multicast packet [from=S, to=G] “Reverse Path Forwarding check”
Received on interface u
No
u=RPFinterface(S,G) X
upstream Yes Multicast packets
downstream

•  At first multicast from RPF interface, a Forwarding Cache Entry [S,G]:


(u,list...) is created using the DVMRP routing table
–  The list contains all downstream routers that have reported dependency
on S
•  The router is designated forwarder for downstream nodes
•  If the designated forwarder becomes unreachable, another router assumes
the role of designated until it hears from a better candidate

E7310-Multicast-2/Comnet 50
List of dependent neighbors is used to
minimize the multicast tree
Router
Multicast packet [from=S, to=G]
Received on interface u
No
u=RPFinterface(S,G) X
Cache = [S,G]:(u,list)
Prune [S, G, lifetime] Multicast packet
Empty list
Yes No
Remove Cache Entry
•  Initially list may contain all multicast interfaces except the upstream interface
•  Downstream address is removed from the list if
–  It is a leaf network and G is not in IGMP DB for this phys. network
–  Downstream node has selected another designated forwarder
–  Prune received from all dependent neighbors on this interface

E7310-Multicast-2/Comnet 51
Prunes minimize the multicast tree
u Upstream Multicast packets Dependent Leaf
Router Prune [S,(netmask),G, Lifetime] Router network

If known dependent neighbor


If mask and mask=sent mask with (S,G)
Prune all sources in network (S, mask)
If Mcasts keep arriving (3s)
If prune is already active
Resend Prune with
reset timeout to new value
exponential backoff =
If all dependent neighbors have sent prunes
double interval each time
If no group members on the mc-interface
Remove Cache Entry
Remove u from all Forwarding Cache entries
If last u
Send prune
Prune[S,(m), G]

E7310-Multicast-2/Comnet 52
Grafts are used to grow the tree when a new
member joins the group
Router Router
Graft [S, G]
Upstream router
for [S,G] Graft Ack

•  The graft is always acknowledged


–  if no multicast, nobody is sending
•  If no ack is received, the graft is resent with exponential
backoff retransmissions
•  The graft is forwarded upstream if necessary
Exponential backoff is an algorithm that uses feedback to multiplicatively
Decrease the rate of some process, in order to gradually find an acceptable rate.

E7310-Multicast-2/Comnet 53
On probe timeout caches are flushed

DVMRP Probe Probe timeout


Router A X Router

•  All routes learned from A à hold-down


•  All downstream dependencies on A are removed
•  If A was designated forwarder, a new one is selected for each
(source, group) pair
•  Forwarding cache entries based on A are flushed
•  Graft acks to A are flushed.
•  Downstream dependencies are removed.
–  If the dependence is the last, send prune upstream

E7310-Multicast-2/Comnet 54
Route hold-down is a state prior
to deleting the route
•  Routes expire on report timeout or when an infinite metric is
received
•  An alternate route (that in RIP caused temporary loops) may
exist
•  Routers continue to advertise the route with inf metric for 2 report
intervals – this is the hold-down period
•  All forwarding cache entries for the route are flushed
•  During hold-down, the route may be taken back, if
–  metric <inf, and
–  metric = SAME, and
–  received from SAME router

E7310-Multicast-2/Comnet 55
Summary of Multicast Protocols for the
Internet
Tree type Shared tree Source based trees

Algorithm Center based tree Flood and prune Domain-wide reports

PIM Sparse* DVMRP


Protocols MOSPF
Core Based tree* PIM Dense*

* These rely on unicast routing protocol to locate multicast sources.


(The other ones can route multicast on routes separate from the unicast routes)

•  For shared tree protocols an additional step of finding the Core or Rendezvous
Point must be performed.
•  Directories are useful on service management level.

E7310-Multicast-2/Comnet 56
Questions about multicast

•  Does flood and prune conform to the idea of Carrier Grade?


•  Does the idea that anyone can send a mc to G conform to
the idea of Carrier Grade?
•  Is the principle of source specific MC IP-agnostic?
•  Can source addresses in multicast packets be spoofed?
•  Is multicast a secure communication method?

E7310-Multicast-2/Comnet 57

S-ar putea să vă placă și