MAGMA Working Group B. Haberman
Internet Draft Caspian Networks
draft-ietf-magma-igmpv3-and-routing-03.txt J. Martin
October 2002 Netzwert AG
Expires April 2003
IGMPv3/MLDv2 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 definitions of IGMPv3 and MLDv2 require new behavior within the
multicast routing protocols. The additional source information
contained in IGMPv3 and MLDv2 messages necessitates multicast
routing protocols to manage and utilize the information. This
document will describe how multicast routing protocols will interact
with these source-filtering group management protocols.
1. Introduction
The definitions of IGMPv3[IGMP3] and MLDv2[MLDv2] require new
behavior within the multicast routing protocols. The additional
source information contained in IGMPv3 and MLDv2 messages
necessitates multicast routing protocols to manage and utilize the
information. This document will describe how multicast routing
protocols will interact with these source-filtering group management
protocols.
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.
Haberman, Martin 1
Internet Draft IGMPv3/MLDv2 and Multicast Protocols October 2002
2. Multicast Forwarding State
Existing multicast routing protocols utilize the group management
database in determining if local members exist for a particular
group. In the case of IGMPv3 and MLDv2, these routing protocols may
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 group management database
should be utilized when generating forwarding state for a multicast
group. If the source address in the multicast packet is included in
the 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. Version Transitions and Routing Protocol Interaction
IGMP version 3 and MLD version 2 specify 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 are source
aware, should this occur and the interface switch to 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 or MLDv2 report
message with a zero-length EXCLUDE list.
4. DVMRP Interaction
The DVMRP protocol[DVMRP] interaction with source-filtering group
management protocols 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 and MLDv2.
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 a source-filtering group management
protocol, the source filter information in the group management
database must be used in the creation of DVMRP prune messages. When
group state changes (e.g. Report message received with EXCLUDE
state), and forwarding state exists for a particular (S,G), DVMRP
Haberman, Martin 2
Internet Draft IGMPv3/MLDv2 and Multicast Protocols October 2002
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
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 a source-filtering group management
protocol, the source filter information in the group management
database must be used in the creation of DVMRP graft messages.
State changes in the database that renders existing prune state
obsolete must result in the creation of a DVMRP graft message.
5. MOSPF Interaction
In MOSPF[MOSPF], the consideration of source filter information in
the group management database 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 Interaction
Like DVMRP, PIM-DM[PIMDM] must utilize the 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
or MLDv2, 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 or MLDv2, this occurs when prune
state exists for (S,G) and a state change occurs in which the source
filter state for S changes to INCLUDE for the specified G.
7. PIM-SM Interaction
A PIM-SM interaction takes place when a PM-SM [PIMSM] router
receives an IGMP or MLD message regarding a group address that is in
the Any Source Multicast (ASM) range. This range is defined as the
Haberman, Martin 3
Internet Draft IGMPv3/MLDv2 and Multicast Protocols October 2002
entire multicast address 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 or MLDv2
report with 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 or MLDv2
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 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 a report with an EXCLUDE or if a specific Source/Group
times out, then an (S,G) prune is sent towards the upstream router.
If all of the IGMPv3 or MLDv2 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 Interaction
A PIM-SSM interaction takes place when a PIM-SM router receives an
IGMPv3 or MLDv2 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. This
behavior is not defined in this document, but rather in [PIMSM].
9. Security Considerations
This document does not introduce any additional security issues
above and beyond those already discussed in [PIMSM], [IGMP3], and
[MLDv2].
10. Acknowledgements
The authors would like to thank Murali Brahmadesam, Leonard
Giuliano, and Hal Sandick for their feedback and suggestions.
11. Authors' Addresses
Haberman, Martin 4
Internet Draft IGMPv3/MLDv2 and Multicast Protocols October 2002
Brian Haberman
Caspian Networks
bkhabs@nc.rr.com
Jim Martin
Netzwert AG
An den Treptowers 1
D-12435 Berlin
jim@Netzwert.AG
+49.30/5 900 800-180
12. References
[IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version
3", work in progress.
[MLDv2] Vida, R., et al., ôMulticast Listener Discovery Version 2
(MLDv2) for IPv6ö, work in progress.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol",
work in progress.
[MOSPF] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March
1994.
[PIMDM] A. Adams, et al, "Protocol Independent Multicast - Dense
Mode: Protocol Specification (Revised)", work in progress.
[PIMSM] B.Fenner, et al, "Protocol Independent Multicast -Sparse
Mode (PIM-SM): Protocol Specification (Revised)", work in
progress.
[SSM] G. Shepard, et al, "Source-Specific Protocol Independent
Multicast in 232/8", work in progress.
Haberman, Martin 5