wdiff draft-ietf-magma-igmpv3-and-routing-04.txt draft-ietf-magma-igmpv3-and-routing-05.txt

MAGMA Working Group B. Haberman
Internet Draft Caspian Networks
draft-ietf-magma-igmpv3-and-routing-04.txt
draft-ietf-magma-igmpv3-and-routing-05.txt J. Martin
January
October 2003 Netzwert AG
Expires July 2003 April 2004

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 describes 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 interpret information learned from these source-
filtering group management protocols.

2. Multicast Forwarding State

Haberman, Martin 1
Existing multicast routing protocols utilize the group management
database in determining if local members exist for a particular
multicast group. With previous group management protocols, this
database had one type of record indicating the group for which there
was interest and the associated local interfaces.

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. This requires the group management database to have four
record types. Only one record may exist for a given interface and a
given multicast group.

1. EXCLUDE <>
The source filter state available EXCLUDE <> record indicates interest in all sources
destined to this group address for a set of local interfaces.
It is equivalent to the single record type existing in previous
versions of the group management protocols.
2. INCLUDE <>
The INCLUDE <> record indicates that there is no interest in
any sources destined to this group address for a set of local
interfaces.
3. EXCLUDE <list>
The EXCLUDE <list> record indicates that there is interest in
only the specifically listed sources for a set of local
interfaces.
4. INCLUDE <list>
The INCLUDE <list> record indicates that there is interest in
only the specifically listed sources for a set of local
interfaces.

The records 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 exists in the database for the
specified multicast group, group and is in an INCLUDE list or is not listed
in an EXCLUDE list, 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) is 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 a source-filtering group
management protocol 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

3.1 DVMRP Prunes

Haberman, Martin 2
DVMRP prune messages are generated initiated when a DVMRP router determines
that there are no longer any entities 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 data flowing on the creation of DVMRP prune messages. When
group state changes (e.g. Report message received with EXCLUDE
state), and
(S,G) forwarding state. If the multicast router is running IGMPv3
or MLDv2, this is determined by the source S being in EXCLUDE state exists for a particular (S,G), DVMRP

Haberman, Martin 2
will create a prune containing
in the specified group and source
information.

4.2 filter for the destination G or all interest in G
being terminated for an existing (S,G) forwarding entry.

3.2 DVMRP Grafts

DVMRP graft messages are generated when local group membership state
changes and a DVMRP prune is sent in place for the requested group
address. The graft message overrides order to override an existing DVMRP
prune. In the case of IGMPv3 or MLDv2, this occurs when prune state and should
result in the resumption of multicast flow
exists for the requested group.

When DVMRP routers implement (S,G) and a source-filtering group management
protocol, state change occurs in which 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 for S changes to INCLUDE for the creation of a DVMRP graft message.

5. specified G.

4. 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.

5. 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

5.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 EXCLUDE state
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

5.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.

Haberman, Martin 3
7.

6. PIM-SM Interaction

A PIM-SM interaction takes place when a PM-SM [PIMSM] PM-SM[PIMSM] router receives
an IGMP or MLD message regarding a group address that is in the Any

Haberman, Martin 3
Source Multicast (ASM) range. This range is defined as the entire
multicast address space excluding the global SSM range [SSM] and any
locally defined Source Specific space.

7.1

6.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 state change that contains
affects source specific information, the PIM-SM 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 The
generation of this (S,G) join can cause failures in some specific network
architectures, architectures
where leaf routers do not have global reachability, 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 sending the
(*,G) join is responsible for filtering the data before forwarding to as per the requesting network.

7.2 IGMPv3
database before forwarding.

6.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.

7. 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].

8. Security Considerations

Haberman, Martin 4

This document does not introduce any additional security issues
above and beyond those already discussed in [PIMSM], [IGMP3], and
[MLDv2].

10.

Haberman, Martin 4
9. Acknowledgements

The authors would like to thank Murali Brahmadesam, Leonard
Giuliano, and Hal Sandick for their feedback and suggestions.

11.

10. Authors' Addresses

Brian Haberman
Caspian Networks
1 Park Drive, Suite 300
Research Triangle Park, NC 27709

bkhabs@nc.rr.com
+1-919-949-4828
753 Bridgewater Drive
Sykesville, MD 21784

brian@innovationslab.net
+1-410-552-1421

Jim Martin
Netzwert AG
An den Treptowers 1
D-12435 Berlin

jim@Netzwert.AG
+49.30/5 900 800-180

12.

11. References
11.1 Normative References
[IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.

[MLDv2] R. Vida, et al., �Multicast �Multicast Listener Discovery Version 2
(MLDv2) for IPv6�, 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.

Haberman, Martin 5

[SSM] H. Holbrook, et al, "Source-Specific Multicast for IP", work
in progress.

Haberman, Martin 5
Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

This document expires in July, 2003. April, 2004.

Haberman, Martin 6