Internet DRAFT - draft-ietf-idmr-igmpv3-and-routing
draft-ietf-idmr-igmpv3-and-routing
IDMR Working Group B. Haberman
Internet Draft J. Martin
draft-ietf-idmr-igmpv3-and-routing-01.txt Nortel Networks
July 2001
Expires January 2002
IGMPv3 and Multicast Routing Protocol Interaction
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC 2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The definition of IGMPv3 requires new behavior within the multicast
routing protocols. The additional source information contained in
IGMPv3 messages necessitates multicast routing protocols to manage
and utilize the information. This document will describe how IGMPv3
and multicast routing protocols interact.
1. Introduction
The definition of IGMPv3[IGMP3] requires new behavior within the
multicast routing protocols. The additional source information
contained in IGMPv3 messages necessitates multicast routing
protocols to manage and utilize the information. This document will
describe how IGMPv3 and multicast routing protocols interact.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Multicast Forwarding State
Haberman, Martin 1
Internet Draft IGMPv3 and Multicast Protocols July 2001
Existing multicast routing protocols utilize the IGMP database in
determining if local members exist for a particular group. In the
case of IGMPv3, these routing protocols must now build multicast
forwarding state based on the source filter information available
for each multicast group that has local membership.
The source filter state available in the IGMPv3 database should be
utilized when generating forwarding state for a multicast group. If
the source address in the multicast packet is included in the IGMPv3
database for the specified multicast group, the multicast routing
protocol should add the interface to the list of downstream
interfaces, otherwise it should not be added based on local group
membership.
3. IGMP Version Transitions and Routing Protocol Interaction
IGMP version 3 specifies that if at any point a router receives an
older version query message on an interface that it must immediately
switch into a compatibility mode with that earlier version. Since
none of the previous versions of IGMP are source aware, should this
occur and the interface switch to Version 1 or 2 compatibility mode,
any previously learned group memberships with specific sources
(learned via the INCLUDE or EXCLUDE mechanisms) MUST be converted to
non-source specific group memberships. The routing protocol will
then treat this as it would the receipt of an IGMPv3 report message
with a zero-length EXCLUDE list.
4. DVMRP/IGMPv3 Interaction
The DVMRP protocol[DVMRP] interaction with IGMPv3 is important in
two areas: multicast distribution tree pruning and multicast
distribution tree grafting. The following sections will describe
the behavior needed in DVMRP to interoperate with IGMPv3.
4.1 DVMRP Prunes
DVMRP prune messages are generated when a router determines that
there are no longer any interested downstream listeners. The DVMRP
protocol builds prune information that contains both destination
group address and source network information.
When DVMRP routers implement IGMPv3, the source filter information
in the IGMPv3 database must be used in the creation of DVMRP prune
messages. When IGMPv3 state changes (e.g. Report message received
with EXCLUDE state) and forwarding state exists for a particular
(S,G), DVMRP will create a prune containing the specified group and
source information.
4.2 DVMRP Grafts
DVMRP graft messages are generated when local group membership state
changes and a DVMRP prune is in place for the requested group
Haberman, Martin 2
Internet Draft IGMPv3 and Multicast Protocols July 2001
address. The graft message overrides the prune state and should
result in the resumption of multicast flow for the requested group.
When DVMRP routers implement IGMPv3, the source filter information
in the IGMPv3 database must be used in the creation of DVMRP graft
messages. State changes in the IGMPv3 database that renders
existing prune state obsolete must result in the creation of a DVMRP
graft message.
5. MOSPF/IGMPv3 Interaction
In MOSPF[MOSPF], the consideration of IGMPv3 source filter
information is limited to the building of forwarding state
(discussed above). This is due to the flooding of group-membership-
LSAs within MOSPF.
6. PIM-DM/IGMPv3 Interaction
Like DVMRP, PIM-DM[PIMDM] must utilize the IGMPv3 source filter
information when generating Prune and Graft messages. The following
sections describe the creation of these message types.
6.1 PIM-DM Prunes
PIM-DM prune messages are initiated when a PIM-DM router determines
that there are no entities interested in the data flowing on the
(S,G) forwarding state. If the multicast router is running IGMPv3,
this is determined by the source S being EXCLUDED in the source
filter for the destination G or all interest in G being terminated
by a Leave message for an existing (S,G) forwarding entry.
6.2 PIM-DM Grafts
PIM-DM graft messages are sent in order to override an existing PIM-
DM prune. In the case of IGMPv3, this occurs when prune state
exists for (S,G) and an IGMPv3 state change occurs in which the
source filter state for S changes to INCLUDE for the specified G.
7. PIM-SM/IGMPv3 Interaction
A PIM-SM/IGMPv3 interaction takes place when a PM-SM [PIMSM] router
receives an IGMP message regarding a group address that is in the
Any Source Multicast (ASM) range. This range is defined as the
entire Class D Multicast space excluding the global SSM range [SSM]
and any locally defined Source Specific space.
7.1 PIM-SM Joins (ASM Behavior)
PIM-SM join messages are initiated when a PIM-SM router determines
that there are entities interested in a specific group or a specific
source sending to the group. If this is due to a IGMPv3 report with
Haberman, Martin 3
Internet Draft IGMPv3 and Multicast Protocols July 2001
a zero-length EXCLUDE list, then the join is sent as a (*,G) join
towards the RP.
If the join is triggered by the reception of an IGMPv3 report that
contains source specific information, the join is sent as a (S,G)
join towards the specific source. This behavior optimizes the join
process, as well as facilitates the adoption of the SSM model. It
also can cause failures in some specific network architectures, and
thus, can be overridden by local policy. If this is the case, then
all IGMPv3 triggered joins are sent towards the RP as (*,G) joins.
The initiating router is responsible for filtering the data before
forwarding to the requesting network.
7.2 PIM-SM Prunes (ASM Behavior)
PIM-SM prune messages are initiated when a PIM-SM router determines
that there are no entities interested in a specific group, or a
specific source sending to the group. If this is triggered by either
receiving an IGMP report with an EXCLUDE or if a specific IGMP
derived Source/Group times out, then an (S,G) prune is sent towards
the upstream router. If all of the IGMP derived requests for a group
time out, then (S,G) and (*,G) prunes are sent upstream as needed to
stop all flow of traffic for that group.
8. PIM-SSM/IGMPv3 Interaction
A PIM-SSM/IGMPv3 interaction takes place when a PIM-SM router
receives an IGMP message regarding a group address that is in the
Source Specific Multicast range. This range is defined as the global
SSM range and any locally defined Source Specific space.
8.1 PIM-SM Joins (SSM Behavior)
PIM-SM join messages are initiated when a PIM-SM router determines
that there are entities interested in specific sources sending to
the group. If this is due to an IGMPv3 report with source specific
information, then a (S,G) join is sent towards the specific sources.
If an IGMPv3 report with a zero-length EXCLUDE list is received, it
MUST be ignored.
8.2 PIM-SM Prunes (SSM Behavior)
PIM-SM prune messages are initiated when a PIM-SM router determines
that there are no entities interested in specific sources sending to
the group. If this is triggered by either receiving an IGMP report
with an EXCLUDE or by an IGMP timeout, then a (S,G) prune is sent in
the direction of the source.
9. Outstanding Issues
The following is a list of open issues that need to be addressed:
- More detailed protocol descriptions
Haberman, Martin 4
Internet Draft IGMPv3 and Multicast Protocols July 2001
- SSM behavior in DVMRP, MOSPF, and PIM-DM?
- Security issues
10. Security Considerations
TBD.
11. Acknowledgements
The authors would like to thank Murali Brahmadesam, Leonard
Giuliano, and Hal Sandick for their feedback and suggestions.
12. Authors' Addresses
Brian Haberman
Nortel Networks
300 Perimeter Park
Morrisville, NC 27560
1-919-905-7484
haberman@nortelnetworks.com
Jim Martin
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95054
1-408-495-3792
jrm@nortelnetworks.com
13. References
[IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version
3", work in progress, March 2001.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol",
work in progress, August 2000.
[MOSPF] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March
1994.
[PIMDM] S. Deering, et al, "Protocol Independent Multicast - Dense
Mode Specification", work in progress, ???.
[PIMSM] B.Fenner, et al, "Protocol Independent Multicast -Sparse
Mode (PIM-SM): Protocol Specification (Revised)", work in
progress, March 2001.
[SSM] G. Shepard, et al, "Source-Specific Protocol Independent
Multicast in 232/8", work in progress, April 2001.
Haberman, Martin 5