Transcript No Slide Title

IP Multicast
Part I: Fundamentals
Carl Harris
Communications Network Services
Virginia Tech
Game Plan
• Part I: IP Multicast Fundamentals
• Part II: Protocol Independent Multicast,
Sparse Mode (PIM-SM).
• Part III: Interdomain Multicast, MulticastOnly Topologies.
• Part IV: Layer 2 Optimizations and Other
Oddities. PIM-DM, DVMRP Overview.
Part I Agenda
• Multicast IP addressing.
• Multicast forwarding states (routes) and
associated terminology, notation.
• Group membership
– Internet Group Management Protocol (IGMP).
• Multicast sources and packet forwarding.
Multicast Group Addressing
• IP addresses from 224.0.0.0 to
239.255.255.255 are designated as multicast
addresses.
• A multicast IP packet reaches a subset of all
hosts on the network; those hosts that have
indicated an interest in the multicast group
address.
Multicast Group Addressing
• Group addresses have inherent scope:
– Link scope:
224.0.0.0 -- 224.0.0.255
These are never forwarded by any router.
– Global scope:
224.0.1.0 -- 238.255.255.255
Can be delivered throughout the Internet.
– Administrative scope: 239.0.0.0 -- 239.255.255.255
Not forwarded beyond an organization’s intranet.
Multicast Packet Format
128.173.12.15
224.2.153.83
RTP or UDP packet payload
• Source is always a unicast
address.
• Destination is a multicast
group address.
• Packet payload is typically
– Real Time Protocol (RTP)
– User Datagram Protocol
(UDP)
• Need to map multicast
group addresses to layer 2
(e.g Ethernet) multicast
addresses. Later...
Multicast Forwarding States
• We use the term state to refer to an entry in
the IP multicast forwarding table of a router.
• A state is used to determine how a multicast
packet will be forwarded.
• You may also see the term mroute (as in the
IOS command show ip mroute) -- this term
is dangerously overloaded:
– can refer to a forwarding state
– can refer to a RPF table entry
Multicast Forwarding States
• A forwarding state (or simply “state”)
consists of several elements:
–
–
–
–
–
source address
group address
incoming interface
outgoing interface list
various timers (needed to deal with aging
entries out of the forwarding table)
– flags (needed later for PIM-SM)
Forwarding State Maintenance
• Forwarding states are created, modified, and
deleted dynamically
– Created when receivers join a multicast group
and when sources send packets addressed to the
group.
– Deleted after receivers leave a multicast group
or senders stop sending packets addressed to
the group.
Forwarding State Maintenance
• Every forwarding state has a fixed lifetime.
– The entry timer for a forwarding state is set to
its maximum value when the state is created.
– The timer counts down toward zero as long as
the state exists. When the timer reaches zero,
the state is deleted.
– Certain events cause the timer to be refreshed
(set to its maximum value), deferring deletion
of the associated forwarding state for at least
one more full lifetime.
Forwarding States: Notation
• In general, we won’t use literal IP source or
group addresses. Instead we’ll use S to
refer to some arbitrary source and G to refer
to an arbitrary group.
• When more than one source is of interest,
we’ll use S1, S2, Si, Sj, etc. On the rare
occasions when we’re interested in more
than one group we’ll likewise use G1, G2,
etc.
Forwarding States: Notation
• The notation (S,G) is used to indicate a state
specific to some source S sending packets to
a group G.
• Every state (S,G) has an incoming interface.
We denote this with the abbreviation iif.
• In our examples, we will use small integers
to identify router interfaces (e.g. iif=2).
• In some cases iif=NULL.
Forwarding States: Notation
• Every (S,G) state has an outgoing interface
list. This list may be null, or may contain
one or more interface identifiers. This list is
denoted with the abbreviation oif.
• Examples:
– (S,G) iif=2 oif=NULL
– (S1,G) iif=1 oif=2
– (S2,G) iif=1 oif=2,4,5
Forwarding States: Notation
• We use the notation (*,G) to denote a state
that matches any source sending to group G.
– created and updated whenever receivers appear
for group G.
– deleted when no more receivers for group G
exist.
• The oif for the (*,G) state is used to
initialize the oif for the (S,G) state created
when source S begins to send packets to
group G.
OIF List Maintenance
• Every entry in the outgoing interface list of
a forwarding state has a fixed lifetime.
– The timer for a particular interface is set to its
maximum value when it is added to the list.
– This timer counts down toward zero as long as
the interface is in the list. When it reaches zero,
the interface is removed from the list.
– Certain events cause the timer to be reset to its
maximum value, thus deferring removal of the
interface from the list.
Multicast Group Membership
• Internet Group Management Protocol
(IGMP) is used by hosts to indicate their
interest in receiving packets addressed to a
particular multicast group G.
– IGMP version 1 is described in RFC 1112
– IGMP version 2 is described in RFC 2236 and
is backward-compatible with version 1.
• IGMP messages aren’t forwarded by
routers.
IGMP Overview
• Periodically, a router attached to a particular
subnet sends a General Membership Query
to determine what group addresses have
members on the subnet.
– These queries are sent to multicast address
224.0.0.1 (the all systems group). All hosts
(and routers) listen to this group.
IGMP Overview
• One router on every subnet is designated as
the IGMP Querier.
– The querier is responsible for sending
membership queries to the subnet to determine
group membership.
– Other routers on the subnet listen to the
membership reports sent by hosts and maintain
forwarding states accordingly, regardless of
which router is the querier.
IGMP Overview
• The “election” of a querier is carried out as
routers overhear each other’s membership
queries.
– When a router first starts up, it assumes it is the
querier for each of its interfaces.
– If the router overhears a query on an interface
for which it believes itself to be the querier, and
the IP address of the source of the query is
numerically smaller than its own IP address on
that interface, the router stops sending queries.
IGMP Overview
• When a host receives a general membership
query, it does not respond immediately.
– The host sets a timer for every group G for
which it is a member, using a random value
between zero and D seconds.
– If the timer for a group G expires, the host
sends a Membership Report addressed to G.
– While the timer for a group G is non-zero, if the
host overhears a report from another member of
G, it clears the timer and does not send a report.
IGMP Overview
• The maximum value of the query response
timer D depends on the version of IGMP:
– version 1: D = 10 seconds
– version 2: the membership query contains a
field that specifies the value of D, in tenths of a
second.
IGMP Overview
• When a host wishes to join a group G it
immediately sends an unsolicited Group
Membership Report
– Speeds up the join process when the host is the
first on the subnet to join group G.
IGMP Overview
• When any router on a subnet receives a
membership report for group G
– if there are no states for group G, the router
creates (*,G) state, and sets the oif to the
interface on which the report was received.
– if one or more states exist for group G, the oif
list for every state involving G is updated to
include the interface on which the report was
received. If the interface is already in the oif
list, its timer is refreshed.
IGMP Example
Hosts join group G
1. Host H1 joins group G
by sending an IGMP
membership report to G.
2. Create (*,G) iif=NULL oif=1
4. Update (*,G) iif=NULL oif=1,2
H1
6. Refresh the outgoing interface
timer for interface 1.
H3
1
R
2
5. Host H3 joins group G.
H2
3. Host H2 joins group G
IGMP Example
2. H1 and H3 both receive
the query and set their timers
for group G. Assume H3’s
delay time is smaller.
R sends a Membership Query
4. H1 receives the report, clears the timer for
group G, and sends nothing. R receives the
report and refreshes the outgoing interface
timer for interface 1.
H1
3. H3’s timer
expires and
the membership
report is sent.
(*,G) iif=NULL oif=1,2
H3
1
R
2
1. R sends a membership
query on interface 1.
H2
IGMP Overview
• When an IGMPv2 host wishes to leave a
group G it may send a Leave Group
message.
– Sent to 224.0.0.2 (all routers) since other hosts
don’t care when any particular host leaves.
– Not required if the host wasn’t the last
membership reporter for G.
– Can be sent even if the host wasn’t the last
reporter for G.
IGMP Overview
• When a host sends a leave group message
for a group G, the router sends a GroupSpecific Membership Query.
– Addressed to the group, G.
– Hosts follow the same rules as for the general
query (i.e. delay before replying, and don’t
reply if someone else does first).
IGMP Overview
• When a router does not receive any reply on
an interface for a group G for which
forwarding states exist:
– The outgoing interface timer for every state
involving G continues to count down.
– When the timer for that interface in a G state
expires, the interface is removed from the oif
list for that state.
IGMP Example
H2 leaves group G
3. The timer for responding to the
query for group G expires, and since
no report was received, the timer for
interface 2 is not updated.
H1
(*,G) iif=NULL oif=1,2
H3
1
(*,G) iif=NULL oif=1
R
2
2. R receives the Leave
Group G from H2, and
sends a Group-Specific
membership query on
the same interface.
4. Later, the outgoing interface
timers for interface 2 in all G
states expire, and the interface is
removed from the respective oif lists.
H2
1. H2 sends a Leave Group
message for G, and stops
listening to the group.
IGMP Example
H1 leaves group G
1. H1 vanishes from
the network.
4. R receives the report and refreshes the
outgoing interface timer for interface 1 in every
state involving G.
3. H3 receives
the membership
query, sets the
timer for G, and
when the timer
expires, sends
a report for G.
(*,G) iif=NULL oif=1
H1
H3
1
R
2
2. Later, R sends a general
membership query.
An Optimization?
• Why not immediately delete an interface
from the oif list for all G states when no
report for G is received in response to a
membership query?
What if the interface in question leads to
downstream receivers and downstream routers,
e.g. PIM routers that don’t participate in IGMP?
Multicast Sources
• A source S that sends packets addressed to
group G need not be a member of group G.
– S doesn’t need to join group G unless S is
interested in receiving packets addressed to
group G.
• We will often refer to packets sent by S to
group G as (S,G) packets.
TTL Scope
• As in unicast IP forwarding, the TTL field
of a multicast IP packet is decremented by
every router that forwards it.
• A source can choose any TTL for multicast
packets that it transmits.
• When a router decrements the TTL of a
packet to zero, the packet is dropped.
• TTL controls how far multicast packets
travel before being dropped.
TTL Scope
• Router interfaces can be configured to drop
multicast packets with a TTL less than some
arbitrary (positive) value, rather than
allowing the TTL to count down to zero.
– Cisco IOS interface configuration command:
ip multicast ttl-threshold 16
– These thresholds create TTL scope boundaries
E.g. packets must start with a TTL of at least 16 to be
forwarded beyond the campus network.
Reverse Path Forwarding (v1)
• When a multicast packet with source
address S is received by a router, the packet
will be forwarded only if it arrived on the
interface to which the router would forward
a (unicast) packet with destination address
S. Otherwise, the packet is dropped.
– We refer to this as the RPF test.
– Plays a role in preventing forwarding loops.
Multicast Packet Forwarding
• When a packet is received by a router from
a directly connected source S addressed to a
group G:
– If neither (S,G) nor (*,G) state exists, the packet
is dropped. We make an exception when PIMSM is the multicast routing protocol.
– If (S,G) state exists, its entry timers is refreshed
and the packet will be forwarded using the oif
list for the (S,G) state.
Multicast Packet Forwarding
– If no (S,G) state exists and the packet matches
(*,G) state, the (S,G) state is created.
• iif is set to the interface on which the packet was
received
• oif is copied from the (*,G) state.
• the entry timer for (*,G) is refreshed. Bull.
– The packet will be forwarded to an interface in
the oif list of the matching forwarding state
only if the TTL threshold for that interface is
less than the TTL of the packet.
Forwarding Example
Source S sends a packet to group
2. R receives the packet, and
verifies that the packet passes
the RPF test.
S
1. S sends a packet
addressed to G, with TTL=2.
What if this state doesn’t
exist when R receives the
packet?
H1
3
(*,G) iif=NULL oif=1,2
H3
1
R
2
4. R decrements the TTL of the
packet (now TTL=1). Assuming
that neither interface 1 nor 2 has
a TTL threshold set, R forwards
the packet according to the
created (S,G) state.
3. The packet matches only (*,G).
R creates (S,G) iif=3 oif=1,2.
R refreshes the entry timer for (*,G).
Bull.
H2
What if the TTL
threshold for interface
2 is set to 16?
Forwarding Example
Preventing a Loop
2. A and B both
receive the packet
RPF passes, and
each router forwards a
copy of the packet
to segment 2.
1. S sends a packet
to group G, TTL=2.
S
1
1
1
A
(*,G) iif=NULL oif=2
(S,G) iif=1 oif=2
2
B
(*,G) iif=NULL oif=2
(S,G) iif=1 oif=2
2
2
R
4. Each router receives
the packet sent by the
other router, RPF fails
and each router drops
the packet, preventing
the possibility of a loop.
3. R receives two copies
of the packet.
RPF does not prevent
packet duplication.
We’ll need something more
sophisticated to solve that
problem.
Reverse Path Forwarding (v2)
• When a router R receives a multicast packet on
interface I addressed to group G from a directly
connected source S, forwarding states will be
created and/or updated and the packet will be
eligible for forwarding only if interface I would
be used by R to forward unicast packets
addressed to S.
Exercises
• What additional forwarding rule(s) is (are) needed if a
router has both a source and a receiver on the same
interface? Consider the case where all receivers are
located on the same subnet as a source and the case where
some receivers are on other subnets connected to R.
• IGMP could be used as a primitive multicast routing
protocol. Consider the case of two routers interconnected
on a backbone, each with some local subnets that have
active receivers for a group G. Place a source on a subnet
connected to one of the routers. What additional IGMP
actions will need to take place between the routers to
forward the source to all receivers?
Recommended Reading
•
•
•
•
Deering, S. Host Extensions for IP Multicasting. RFC 1112, IETF Network
Working Group, August 1988.
Fenner, W. Internet Group Management Protocol , Version 2. RFC 2236,
IETF Network Working Group, November 1997.
Estrin, D. et. al. Protocol Independent Multicast - Sparse Mode (PIM-SM):
Motivation and Architecture. Internet Draft, IETF Interdomain Multicast
Routing Working Group, October 1996. http://catarina.usc.edu/pim.
Estrin, D. et. al. Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Description. RFC 2362, IETF Network Working Group, June 1998.
Interesting URLs
•
•
•
•
http://www.cisco.com/warp/public/674/4.html
http://www.cisco.com/warp/public/cc/cisco/mkt/ios/mcastip/tech/ipcas_dg.htm
http://www.ietf.org/html.charters/idmr-charter.html
http://www.ipmulticast.com/
End of Part I