< draft-ietf-magma-igmpv3-and-routing-04.txt   draft-ietf-magma-igmpv3-and-routing-05.txt >
MAGMA Working Group B. Haberman MAGMA Working Group B. Haberman
Internet Draft Caspian Networks Internet Draft Caspian Networks
draft-ietf-magma-igmpv3-and-routing-04.txt J. Martin draft-ietf-magma-igmpv3-and-routing-05.txt J. Martin
January 2003 Netzwert AG October 2003 Netzwert AG
Expires July 2003 Expires April 2004
IGMPv3/MLDv2 and Multicast Routing Protocol Interaction IGMPv3/MLDv2 and Multicast Routing Protocol Interaction
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC 2026]. all provisions of Section 10 of RFC2026 [RFC 2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 35 skipping to change at line 35
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The definitions of IGMPv3 and MLDv2 require new behavior within the The definitions of IGMPv3 and MLDv2 require new behavior within the
multicast routing protocols. The additional source information multicast routing protocols. The additional source information
contained in IGMPv3 and MLDv2 messages necessitates multicast contained in IGMPv3 and MLDv2 messages necessitates multicast
routing protocols to manage and utilize the information. This routing protocols to manage and utilize the information. This
document will describe how multicast routing protocols will interact document describes how multicast routing protocols will interact
with these source-filtering group management protocols. with these source-filtering group management protocols.
1. Introduction 1. Introduction
The definitions of IGMPv3[IGMP3] and MLDv2[MLDv2] require new The definitions of IGMPv3[IGMP3] and MLDv2[MLDv2] require new
behavior within the multicast routing protocols. The additional behavior within the multicast routing protocols. The additional
source information contained in IGMPv3 and MLDv2 messages source information contained in IGMPv3 and MLDv2 messages
necessitates multicast routing protocols to manage and utilize the necessitates multicast routing protocols to manage and utilize the
information. This document will describe how multicast routing information. This document will describe how multicast routing
protocols will interpret information learned from these source- protocols will interpret information learned from these source-
filtering group management protocols. filtering group management protocols.
2. Multicast Forwarding State 2. Multicast Forwarding State
Haberman, Martin 1 Haberman, Martin 1
Existing multicast routing protocols utilize the group management Existing multicast routing protocols utilize the group management
database in determining if local members exist for a particular database in determining if local members exist for a particular
group. In the case of IGMPv3 and MLDv2, these routing protocols may multicast group. With previous group management protocols, this
now build multicast forwarding state based on the source filter database had one type of record indicating the group for which there
information available for each multicast group that has local was interest and the associated local interfaces.
membership.
The source filter state available in the group management database In the case of IGMPv3 and MLDv2, these routing protocols may now
should be utilized when generating forwarding state for a multicast build multicast forwarding state based on the source filter
group. If the source address in the multicast packet is included in information available for each multicast group that has local
the database for the specified multicast group, the multicast membership. This requires the group management database to have four
routing protocol should add the interface to the list of downstream record types. Only one record may exist for a given interface and a
interfaces, otherwise it should not be added based on local group given multicast group.
membership.
3. Version Transitions and Routing Protocol Interaction 1. EXCLUDE <>
The 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.
IGMP version 3 and MLD version 2 specify that if at any point a The records in the group management database should be utilized when
router receives an older version query message on an interface that generating forwarding state for a multicast group. If the source
it must immediately switch into a compatibility mode with that address in the multicast packet exists in the database for the
earlier version. Since none of the previous versions are source specified multicast group and is in an INCLUDE list or is not listed
aware, should this occur and the interface switch to compatibility in an EXCLUDE list, the multicast routing protocol should add the
mode, any previously learned group memberships with specific sources interface to the list of downstream interfaces, otherwise it should
(learned via the INCLUDE or EXCLUDE mechanisms) is converted to non- not be added based on local group membership.
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 3. DVMRP Interaction
The DVMRP protocol[DVMRP] interaction with a source-filtering group The DVMRP protocol[DVMRP] interaction with a source-filtering group
management protocol is important in two areas: multicast management protocol is important in two areas: multicast
distribution tree pruning and multicast distribution tree grafting. distribution tree pruning and multicast distribution tree grafting.
The following sections will describe the behavior needed in DVMRP to The following sections will describe the behavior needed in DVMRP to
interoperate with IGMPv3 and MLDv2. interoperate with IGMPv3 and MLDv2.
4.1 DVMRP Prunes 3.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 Haberman, Martin 2
will create a prune containing the specified group and source DVMRP prune messages are initiated when a DVMRP router determines
information. that there are no entities interested in the data flowing on the
(S,G) forwarding state. If the multicast router is running IGMPv3
4.2 DVMRP Grafts or MLDv2, this is determined by the source S being in EXCLUDE state
in the source filter for the destination G or all interest in G
being terminated for an existing (S,G) forwarding entry.
DVMRP graft messages are generated when local group membership state 3.2 DVMRP Grafts
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 DVMRP graft messages are sent in order to override an existing DVMRP
protocol, the source filter information in the group management prune. In the case of IGMPv3 or MLDv2, this occurs when prune state
database must be used in the creation of DVMRP graft messages. exists for (S,G) and a state change occurs in which the source
State changes in the database that renders existing prune state filter state for S changes to INCLUDE for the specified G.
obsolete must result in the creation of a DVMRP graft message.
5. MOSPF Interaction 4. MOSPF Interaction
In MOSPF[MOSPF], the consideration of source filter information in In MOSPF[MOSPF], the consideration of source filter information in
the group management database is limited to the building of the group management database is limited to the building of
forwarding state (discussed above). This is due to the flooding of forwarding state (discussed above). This is due to the flooding of
group-membership-LSAs within MOSPF. group-membership-LSAs within MOSPF.
6. PIM-DM Interaction 5. PIM-DM Interaction
Like DVMRP, PIM-DM[PIMDM] must utilize the source filter information Like DVMRP, PIM-DM[PIMDM] must utilize the source filter information
when generating Prune and Graft messages. The following sections when generating Prune and Graft messages. The following sections
describe the creation of these message types. describe the creation of these message types.
6.1 PIM-DM Prunes 5.1 PIM-DM Prunes
PIM-DM prune messages are initiated when a PIM-DM router determines PIM-DM prune messages are initiated when a PIM-DM router determines
that there are no entities interested in the data flowing on the that there are no entities interested in the data flowing on the
(S,G) forwarding state. If the multicast router is running IGMPv3 (S,G) forwarding state. If the multicast router is running IGMPv3
or MLDv2, this is determined by the source S being EXCLUDED in the or MLDv2, this is determined by the source S being in EXCLUDE state
source filter for the destination G or all interest in G being in the source filter for the destination G or all interest in G
terminated by a Leave message for an existing (S,G) forwarding being terminated for an existing (S,G) forwarding entry.
entry.
6.2 PIM-DM Grafts 5.2 PIM-DM Grafts
PIM-DM graft messages are sent in order to override an existing PIM- 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 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 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. filter state for S changes to INCLUDE for the specified G.
Haberman, Martin 3 6. PIM-SM Interaction
7. PIM-SM Interaction
A PIM-SM interaction takes place when a PM-SM [PIMSM] router A PIM-SM interaction takes place when a PM-SM[PIMSM] router receives
receives an IGMP or MLD message regarding a group address that is in an IGMP or MLD message regarding a group address that is in the Any
the Any 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 PIM-SM Joins (ASM Behavior) 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.
6.1 PIM-SM Joins (ASM Behavior)
PIM-SM join messages are initiated when a PIM-SM router determines PIM-SM join messages are initiated when a PIM-SM router determines
that there are entities interested in a specific group or a specific 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 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 report with a zero-length EXCLUDE list, then the join is sent as a
(*,G) join towards the RP. (*,G) join towards the RP.
If the join is triggered by the reception of an IGMPv3 or MLDv2 If the join is triggered by an IGMPv3 or MLDv2 state change that
report that contains source specific information, the join is sent affects source information, the PIM-SM join is sent as a (S,G) join
as a (S,G) join towards the specific source. This behavior optimizes towards the specific source. This behavior optimizes the join
the join process, as well as facilitates the adoption of the SSM process, as well as facilitates the adoption of the SSM model. The
model. It also can cause failures in some specific network generation of this (S,G) join can cause failures in architectures
architectures, and thus, can be overridden by local policy. If this where leaf routers do not have global reachability, and thus, can be
is the case, then all triggered joins are sent towards the RP as overridden by local policy. If this is the case, then all triggered
(*,G) joins. The initiating router is responsible for filtering the joins are sent towards the RP as (*,G) joins. The router sending the
data before forwarding to the requesting network. (*,G) join is responsible for filtering the data as per the IGMPv3
database before forwarding.
7.2 PIM-SM Prunes (ASM Behavior) 6.2 PIM-SM Prunes (ASM Behavior)
PIM-SM prune messages are initiated when a PIM-SM router determines PIM-SM prune messages are initiated when a PIM-SM router determines
that there are no entities interested in a specific group, or a that there are no entities interested in a specific group, or a
specific source sending to the group. If this is triggered by either specific source sending to the group. If this is triggered by either
receiving a report with an EXCLUDE or if a specific Source/Group 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. 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, 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 then (S,G) and (*,G) prunes are sent upstream as needed to stop all
flow of traffic for that group. flow of traffic for that group.
8. PIM-SSM Interaction 7. PIM-SSM Interaction
A PIM-SSM interaction takes place when a PIM-SM router receives an 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 IGMPv3 or MLDv2 message regarding a group address that is in the
Source Specific Multicast range. This range is defined as the global Source Specific Multicast range. This behavior is not defined in
SSM range and any locally defined Source Specific space. This this document, but rather in [PIMSM].
behavior is not defined in this document, but rather in [PIMSM].
9. Security Considerations 8. Security Considerations
Haberman, Martin 4
This document does not introduce any additional security issues This document does not introduce any additional security issues
above and beyond those already discussed in [PIMSM], [IGMP3], and above and beyond those already discussed in [PIMSM], [IGMP3], and
[MLDv2]. [MLDv2].
10. Acknowledgements Haberman, Martin 4
9. Acknowledgements
The authors would like to thank Murali Brahmadesam, Leonard The authors would like to thank Murali Brahmadesam, Leonard
Giuliano, and Hal Sandick for their feedback and suggestions. Giuliano, and Hal Sandick for their feedback and suggestions.
11. Authors' Addresses 10. Authors' Addresses
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
1 Park Drive, Suite 300 753 Bridgewater Drive
Research Triangle Park, NC 27709 Sykesville, MD 21784
bkhabs@nc.rr.com brian@innovationslab.net
+1-919-949-4828 +1-410-552-1421
Jim Martin Jim Martin
Netzwert AG Netzwert AG
An den Treptowers 1 An den Treptowers 1
D-12435 Berlin D-12435 Berlin
jim@Netzwert.AG jim@Netzwert.AG
+49.30/5 900 800-180 +49.30/5 900 800-180
12. Normative References 11. References
11.1 Normative References
[IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version [IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[MLDv2] R. Vida, et al., ôMulticast Listener Discovery Version 2 [MLDv2] R. Vida, et al., “Multicast Listener Discovery Version 2
(MLDv2) for IPv6ö, work in progress. (MLDv2) for IPv6”, work in progress.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol",
work in progress. work in progress.
[MOSPF] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March [MOSPF] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March
1994. 1994.
[PIMDM] A. Adams, et al, "Protocol Independent Multicast - Dense [PIMDM] A. Adams, et al, "Protocol Independent Multicast - Dense
Mode: Protocol Specification (Revised)", work in progress. Mode: Protocol Specification (Revised)", work in progress.
[PIMSM] B.Fenner, et al, "Protocol Independent Multicast -Sparse [PIMSM] B.Fenner, et al, "Protocol Independent Multicast -Sparse
Mode (PIM-SM): Protocol Specification (Revised)", work in Mode (PIM-SM): Protocol Specification (Revised)", work in
progress. progress.
Haberman, Martin 5
[SSM] H. Holbrook, et al, "Source-Specific Multicast for IP", work [SSM] H. Holbrook, et al, "Source-Specific Multicast for IP", work
in progress. in progress.
Haberman, Martin 5
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 277 skipping to change at line 274
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document expires in July, 2003. This document expires in April, 2004.
Haberman, Martin 6 Haberman, Martin 6
 End of changes. 34 change blocks. 
97 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/