draft-ietf-mboned-routingarch-10.txt   draft-ietf-mboned-routingarch-11.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: September 25, 2007 Obsoletes: 3913,2189,2201,1584 October 13, 2007
3913,2189,2201,1584,1585
(if approved) (if approved)
Intended status: Best Current Intended status: Best Current
Practice Practice
Expires: March 28, 2008 Expires: April 15, 2008
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-10.txt draft-ietf-mboned-routingarch-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 page 1, line 38 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on March 28, 2008. This Internet-Draft will expire on April 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes multicast routing architectures that are This document describes multicast routing architectures that are
currently deployed on the Internet. This document briefly describes currently deployed on the Internet. This document briefly describes
those protocols and references their specifications. those protocols and references their specifications.
This memo also obsoletes and reclassifies to Historic several older This memo also reclassifies to Historic several older RFCs. These
RFCs. These RFCs describe multicast routing protocols that were RFCs describe multicast routing protocols that were never widely
never widely deployed or have fallen into disuse. deployed or have fallen into disuse.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5
2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6
2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 7 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 7
2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8
2.2. Distributing Topology Information . . . . . . . . . . . . 8 2.2. Distributing Topology Information . . . . . . . . . . . . 9
2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9
2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 9 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 10
2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 10 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 10
2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 11 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 11
2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12
2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Configuring and Distributing PIM RP Information . . . . . 12 2.4. Configuring and Distributing PIM RP Information . . . . . 13
2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 13
2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13
2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 14
2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 15
2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 15 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 15
2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15
2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 16
2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 16
2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16
2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 17
2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17
2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17
2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 19
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Multicast Payload Transport Extensions . . . . . . . 23 Appendix A. Multicast Payload Transport Extensions . . . . . . . 24
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 24 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 24
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 24 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
This document provides a brief overview of multicast routing This document provides a brief overview of multicast routing
architectures that are currently deployed on the Internet and how architectures that are currently deployed on the Internet and how
those protocols fit together. It also describes those multicast those protocols fit together. It also describes those multicast
routing protocols that were never widely deployed or have fallen into routing protocols that were never widely deployed or have fallen into
disuse. A companion document [I-D.ietf-mboned-addrarch] describes disuse. A companion document [I-D.ietf-mboned-addrarch] describes
multicast addressing architectures. multicast addressing architectures.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
o interacting with hosts (Section 2.6), and o interacting with hosts (Section 2.6), and
o restricting the multicast flooding in the link layer o restricting the multicast flooding in the link layer
(Section 2.7). (Section 2.7).
Section 2 starts by describing a simplistic example how these classes Section 2 starts by describing a simplistic example how these classes
of mechanisms fit together. Some multicast data transport issues are of mechanisms fit together. Some multicast data transport issues are
also introduced in Appendix A. also introduced in Appendix A.
This memo obsoletes and re-classifies to Historic [RFC2026] the This memo re-classifies to Historic [RFC2026] the following RFCs:
following RFCs:
o Border Gateway Multicast Protocol (BGMP) [RFC3913], o Border Gateway Multicast Protocol (BGMP) [RFC3913],
o Core Based Trees (CBT) [RFC2189] [RFC2201], o Core Based Trees (CBT) [RFC2189] [RFC2201],
o Multicast OSPF (MOSPF) [RFC1584] and [RFC1585]. o Multicast OSPF (MOSPF) [RFC1584].
For the most part, these protocols have fallen into disuse. There For the most part, these protocols have fallen into disuse. There
may be legacy deployments of some of these protocols, which are not may be legacy deployments of some of these protocols, which are not
affected by this reclassification. See Section 2.1 for more on each affected by this reclassification. See Section 2.1 for more on each
protocol. protocol.
Further historical perspective may be found in, for example, Further historical perspective may be found in, for example,
[RFC1458], [IMRP-ISSUES], and [IM-GAPS]. [RFC1458], [IMRP-ISSUES], and [IM-GAPS].
1.1. Multicast-related Abbreviations 1.1. Multicast-related Abbreviations
skipping to change at page 5, line 30 skipping to change at page 5, line 30
MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto. MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto.
MOSPF Multicast OSPF MOSPF Multicast OSPF
MSDP Multicast Source Discovery Protocol MSDP Multicast Source Discovery Protocol
PGM Pragmatic General Multicast PGM Pragmatic General Multicast
PIM Protocol Independent Multicast PIM Protocol Independent Multicast
PIM-DM PIM - Dense Mode PIM-DM PIM - Dense Mode
PIM-SM PIM - Sparse Mode PIM-SM PIM - Sparse Mode
PIM-SSM PIM - Source-Specific Multicast PIM-SSM PIM - Source-Specific Multicast
RGMP (Cisco's) Router Group Management Protocol RGMP (Cisco's) Router Group Management Protocol
RP Rendezvous Point RP Rendezvous Point
RPF Reverse Path Forwarding
SAFI Subsequent Address Family Identifier SAFI Subsequent Address Family Identifier
SDP Session Description Protocol SDP Session Description Protocol
SSM Source-specific Multicast SSM Source-specific Multicast
2. Multicast Routing 2. Multicast Routing
In order to give a simplified summary how each of these class of In order to give a simplified summary how each of these class of
mechanisms fits together, consider the following multicast receiver mechanisms fits together, consider the following multicast receiver
scenario. scenario.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
hop-by-hop multicast forwarding state (Section 2.1) to the source (in hop-by-hop multicast forwarding state (Section 2.1) to the source (in
SSM) or first through the RP (in ASM). Routers use an RP to find out SSM) or first through the RP (in ASM). Routers use an RP to find out
all the sources for a group (Section 2.3). When multicast all the sources for a group (Section 2.3). When multicast
transmission arrives at the receiver's LAN, it is flooded to every transmission arrives at the receiver's LAN, it is flooded to every
Ethernet switch port unless flooding reduction such as IGMP snooping Ethernet switch port unless flooding reduction such as IGMP snooping
is employed (Section 2.7). is employed (Section 2.7).
2.1. Setting up Multicast Forwarding State 2.1. Setting up Multicast Forwarding State
The most important part of multicast routing is setting up the The most important part of multicast routing is setting up the
multicast forwarding state. This section describes the protocols multicast forwarding state. State maintenance requires periodic
commonly used for this purpose. messaging because forwarding state has a timeout. This section
describes the protocols commonly used for this purpose.
2.1.1. PIM-SM 2.1.1. PIM-SM
By far, the most common multicast routing protocol is PIM-SM By far, the most common multicast routing protocol is PIM-SM
[RFC4601]. The PIM-SM protocol includes both Any Source Multicast [RFC4601]. The PIM-SM protocol includes both Any Source Multicast
(ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a (ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is
subset of PIM-SM. Most current routing platforms support PIM-SM. It a subset of PIM-SM that does not use the RPs but instead requires
builds a unidirectional, group-specific distribution tree consisting that receivers know the (source,group) pair and signal that
of the interested receivers of a group. explicitly. Most current routing platforms support PIM-SM.
PIM routers elect a designated router on each LAN and the DR is
responsible for PIM messaging and source registration on behalf of
the hosts. The DR encapsulates multicast packets sourced from the
LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional,
group-specific distribution tree consisting of the interested
receivers of a group. Initially the multicast distribution tree is
rooted at the RP but later the DRs have the option of optimizing the
delivery by building (source,group)-specific trees.
A more lengthy introduction to PIM-SM can be found in Section 3 of
[RFC4601].
2.1.2. PIM-DM 2.1.2. PIM-DM
Whereas PIM-SM has been designed to avoid unnecessary flooding of Whereas PIM-SM has been designed to avoid unnecessary flooding of
multicast data, PIM-DM [RFC3973] assumed that almost every subnet at multicast data, PIM-DM [RFC3973] assumed that almost every subnet at
a site had at least one receiver for a group. PIM-DM floods a site had at least one receiver for a group. PIM-DM floods
multicast transmissions throughout the network ("flood and prune") multicast transmissions throughout the network ("flood and prune")
unless the leaf parts of the network periodically indicate that they unless the leaf parts of the network periodically indicate that they
are not interested in that particular group. are not interested in that particular group.
skipping to change at page 11, line 5 skipping to change at page 11, line 12
A congruent topology can be deployed using unicast routing protocols A congruent topology can be deployed using unicast routing protocols
that provide no support for a separate multicast topology. In intra- that provide no support for a separate multicast topology. In intra-
domain that approach is often adequate. However, it is recommended domain that approach is often adequate. However, it is recommended
that if interdomain routing uses BGP, multicast-enabled sites should that if interdomain routing uses BGP, multicast-enabled sites should
use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the
topology was congruent to explicitly signal "yes, we use multicast". topology was congruent to explicitly signal "yes, we use multicast".
The following table summarizes the approaches that can be used to The following table summarizes the approaches that can be used to
distribute multicast topology information. distribute multicast topology information.
+-------------+---------------+ +----------------+---------------+
| Interdomain | Intradomain | | Interdomain | Intradomain |
+--------------------- +--------------+--------------+ +--------------------- +----------------+--------------+
| MP-BGP SAFI=2 | Recommended | Yes | | MP-BGP SAFI=2 | Yes | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work | | MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | No | Yes | | IS-IS multi-topology | Not applicable | Yes |
| OSPF multi-topology | No | Few implem. | | OSPF multi-topology | Not applicable | Few implem. |
+----------------------+--------------+--------------+ +----------------------+----------------+--------------+
"Not applicable" refers to the fact that IGP protocols can't be used
in interdomain routing. "Doesn't work" means that while MP-BGP
SAFI=3 was defined and could apply, that part of the specification
has not been implemented and can't be used in practice. "Yes" lists
the mechanisms which are generally applicable and known to work.
"Few implem." means that the approach could work but is not commonly
available.
2.3. Learning (Active) Sources 2.3. Learning (Active) Sources
To build a multicast distribution tree, the routing protocol needs to To build a multicast distribution tree, the routing protocol needs to
find out where the sources for the group are. In case of SSM, the find out where the sources for the group are. In case of SSM, the
user specifies the source IP address or it is otherwise learned out user specifies the source IP address or it is otherwise learned out
of band. In ASM, RPs are used to find out the sources (which in turn of band.
requires a mechanism to find the RPs as discussed in Section 2.4).
Learning active sources is a relatively straightforward process with In ASM, the RPs know about all the active sources in a local PIM
a single PIM-SM domain and with a single RP, but having a single domain. As a result, when PIM-SM or bi-dir PIM is used in intra-
PIM-SM domain for the whole Internet is a completely unscalable model domain the sources are learned as a feature of the protocol itself.
for many reasons. Therefore it is required to be able to split up
the multicast routing infrastructures to smaller domains, and there
must be a way to share information about active sources using some
mechanism if the ASM model is to be supported.
This section discusses the options. Having a single PIM-SM domain for the whole Internet is an
insufficient model for many reasons, including scalability,
administrative boundaries and different technical tradeoffs.
Therefore it is required to be able to split up the multicast routing
infrastructures to smaller domains, and there must be a way to share
information about active sources using some mechanism if the ASM
model is to be supported.
This section discusses the options of learning active sources that
apply in an inter-domain environment.
2.3.1. SSM 2.3.1. SSM
Source-specific Multicast [RFC4607] (sometimes also referred to as Source-specific Multicast [RFC4607] (sometimes also referred to as
"single-source Multicast") does not count on learning active sources "single-source Multicast") does not count on learning active sources
in the network. Recipients need to know the source IP addresses in the network. Recipients need to know the source IP addresses
using an out of band mechanism which are used to subscribe to the using an out of band mechanism which are used to subscribe to the
(source, group) channel. The multicast routing uses the source (source, group) channel. The multicast routing uses the source
address to set up the state and no further source discovery is address to set up the state and no further source discovery is
needed. needed.
skipping to change at page 16, line 27 skipping to change at page 17, line 5
still commonplace, but are also often used in new deployments. Some still commonplace, but are also often used in new deployments. Some
vendors also support SSM mapping techniques for receivers which use vendors also support SSM mapping techniques for receivers which use
an older IGMP/MLD version where the router maps the join request to an older IGMP/MLD version where the router maps the join request to
an SSM channel based on various, usually complex means of an SSM channel based on various, usually complex means of
configuration. configuration.
2.6.3. Summary 2.6.3. Summary
The following table summarizes the techniques host interaction. The following table summarizes the techniques host interaction.
+-------+------+----------------------+ +-------+------+----------------------------+
| IPv4 | IPv6 | Notes | | IPv4 | IPv6 | Notes |
+--------------------+-------+------+----------------------+ +--------------------+-------+------+----------------------------+
| Host sending | Yes | Yes | No support needed | | Host sending | Yes | Yes | No support needed |
| Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version |
| Host receiving SSM | IGMPv3| MLDv2| Also SSM-mapping | | Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping |
+--------------------+-------+------+----------------------+ +--------------------+-------+------+----------------------------+
2.7. Restricting Multicast Flooding in the Link Layer 2.7. Restricting Multicast Flooding in the Link Layer
Multicast transmission in the link layer, for example Ethernet, Multicast transmission in the link layer, for example Ethernet,
typically includes some form of flooding the packets through a LAN. typically includes some form of flooding the packets through a LAN.
This causes unnecessary bandwidth usage and discarding unwanted This causes unnecessary bandwidth usage and discarding unwanted
frames on those nodes which did not want to receive the multicast frames on those nodes which did not want to receive the multicast
transmission. transmission.
Therefore a number of techniques have been developed, to be used in Therefore a number of techniques have been developed, to be used in
skipping to change at page 17, line 28 skipping to change at page 18, line 5
messages [I-D.ietf-l2vpn-vpls-pim-snooping]. messages [I-D.ietf-l2vpn-vpls-pim-snooping].
2.7.2. Host/Router Flooding Reduction 2.7.2. Host/Router Flooding Reduction
There are a number of techniques to help reduce flooding both from a There are a number of techniques to help reduce flooding both from a
router to hosts, and from a host to the routers (and other hosts). router to hosts, and from a host to the routers (and other hosts).
Cisco's proprietary CGMP [CGMP] provides a solution where the routers Cisco's proprietary CGMP [CGMP] provides a solution where the routers
notify the switches, but also allows the switches to snoop IGMP notify the switches, but also allows the switches to snoop IGMP
packets to enable faster notification of hosts no longer wishing to packets to enable faster notification of hosts no longer wishing to
receive a group. Fast leave behaviour support for IGMPv3 hasn't been receive a group. Implementations of CGMP do not support fast leave
implemented. Due to IGMP report suppression in IGMPv1 and IGMPv2, behaviour with IGMPv3. Due to IGMP report suppression in IGMPv1 and
multicast is still flooded to ports which were once members of a IGMPv2, multicast is still flooded to ports which were once members
group as long as there is at least one receiver on the link. of a group as long as there is at least one receiver on the link.
Flooding restrictions are done based on multicast MAC addresses. Flooding restrictions are done based on multicast MAC addresses.
IPv6 is not supported. Implementations of CGMP do not support IPv6.
IEEE 802.1D-2004 specification describes Generic Attribute IEEE 802.1D-2004 specification describes Generic Attribute
Registration Protocol (GARP), and GARP Multicast Registration Registration Protocol (GARP), and GARP Multicast Registration
Protocol (GMRP) [GMRP] is a link-layer multicast group application of Protocol (GMRP) [GMRP] is a link-layer multicast group application of
GARP that notifies switches about MAC multicast group memberships. GARP that notifies switches about MAC multicast group memberships.
If GMRP is used in conjunction with IP multicast, then the GMRP If GMRP is used in conjunction with IP multicast, then the GMRP
registration function would become associated with an IGMP "join." registration function would become associated with an IGMP "join."
However, this GMRP-IGMP association is beyond the scope of GMRP. However, this GMRP-IGMP association is beyond the scope of GMRP.
GMRP requires support at the host stack and it has not been widely GMRP requires support at the host stack and it has not been widely
implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete
being replaced by Multiple Registration Protocol (MRP) and Multicast being replaced by Multiple Registration Protocol (MRP) and Multicast
Multiple Registration Protocol (MMRP) that are being specified in Multiple Registration Protocol (MMRP) that are being specified in
IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between
bridges. Some further information about GARP/GMRP is also available bridges. Some further information about GARP/GMRP is also available
in Appendix B of [RFC3488]. in Appendix B of [RFC3488].
IGMP snooping [RFC4541] appears to be the most widely implemented IGMP snooping [RFC4541] appears to be the most widely implemented
technique. IGMP snooping requires that the switches implement a technique. IGMP snooping requires that the switches implement a
significant amount of IP-level packet inspection; this appears to be significant amount of IP-level packet inspection; this appears to be
something that is difficult to get right, and often the upgrades are something that is difficult to get right, and often the upgrades are
also a challenge. also a challenge. Snooping support is commonplace for IGMPv1 and
IGMPv2, but fewer switches support IGMPv3 or MLD (any version)
snooping. In the worst case, enabling IGMP snooping on a switch that
does not support IGMPv3 snooping breaks multicast capabilities of
nodes using IGMPv3.
Snooping switches also need to identify the ports where routers Snooping switches also need to identify the ports where routers
reside and therefore where to flood the packets. This can be reside and therefore where to flood the packets. This can be
accomplished using Multicast Router Discovery protocol [RFC4286], accomplished using Multicast Router Discovery protocol [RFC4286],
looking at certain IGMP queries [RFC4541], looking at PIM Hello and looking at certain IGMP queries [RFC4541], looking at PIM Hello and
possibly other messages, or by manual configuration. An issue with possibly other messages, or by manual configuration. An issue with
PIM snooping at LANs is that PIM messages can't be turned off or PIM snooping at LANs is that PIM messages can't be turned off or
encrypted, leading to security issues [I-D.ietf-pim-lasthop-threats]. encrypted, leading to security issues [I-D.ietf-pim-lasthop-threats].
IGMP proxying [RFC4605] is sometimes used either as a replacement of IGMP proxying [RFC4605] is sometimes used either as a replacement of
a multicast routing protocol on a small router, or to aggregate IGMP/ a multicast routing protocol on a small router, or to aggregate IGMP/
MLD reports when used with IGMP snooping. MLD reports when used with IGMP snooping.
2.7.3. Summary 2.7.3. Summary
The following table summarizes the techniques for multicast flooding The following table summarizes the techniques for multicast flooding
reduction inside a single link for router-to-router and last-hop reduction inside a single link for router-to-router and last-hop
LANs. LANs.
+--------+-----+---------------------------+ +--------+-----+----------------------------+
| R-to-R | LAN | Notes | | R-to-R | LAN | Notes |
+-----------------------+--------+-----+---------------------------+ +-----------------------+--------+-----+----------------------------+
| Cisco's RGMP | Yes | No | Replaced by PIM snooping | | Cisco's RGMP | Yes | No | Replaced by PIM snooping |
| PIM snooping | Yes | No | Security issues in LANs | | PIM snooping | Yes | No | Security issues in LANs |
| IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD bad | | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare |
| Multicast Router Disc | No | Yes | Few if any implem. yet | | Multicast Router Disc | No | Yes | Few if any implem. yet |
| IEEE GMRP and MMRP | No | No | No host/router deployment | | IEEE GMRP and MMRP | No | No | No host/router deployment |
| Cisco's CGMP | No | Yes | Replaced by other snooping| | Cisco's CGMP | No | Yes | Replaced by other snooping|
+-----------------------+--------+-----+---------------------------+ +-----------------------+--------+-----+----------------------------+
3. Acknowledgements 3. Acknowledgements
Tutoring a couple multicast-related papers, the latest by Kaarle Tutoring a couple multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that up-to-date multicast Ritvanen [RITVANEN] convinced the author that up-to-date multicast
routing and address assignment/allocation documentation is necessary. routing and address assignment/allocation documentation is necessary.
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer,
Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat
Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon
skipping to change at page 21, line 31 skipping to change at page 22, line 16
Savola, P., "Overview of the Internet Multicast Addressing Savola, P., "Overview of the Internet Multicast Addressing
Architecture", draft-ietf-mboned-addrarch-05 (work in Architecture", draft-ietf-mboned-addrarch-05 (work in
progress), October 2006. progress), October 2006.
[I-D.ietf-mboned-ipv6-multicast-issues] [I-D.ietf-mboned-ipv6-multicast-issues]
Savola, P., "IPv6 Multicast Deployment Issues", Savola, P., "IPv6 Multicast Deployment Issues",
draft-ietf-mboned-ipv6-multicast-issues-02 (work in draft-ietf-mboned-ipv6-multicast-issues-02 (work in
progress), February 2005. progress), February 2005.
[I-D.ietf-pim-lasthop-threats] [I-D.ietf-pim-lasthop-threats]
Savola, P. and J. Lingard, "Last-hop Threats to Protocol Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", Independent Multicast (PIM)",
draft-ietf-pim-lasthop-threats-01 (work in progress), draft-ietf-pim-lasthop-threats-03 (work in progress),
June 2007. October 2007.
[I-D.ietf-pim-sm-bsr] [I-D.ietf-pim-sm-bsr]
Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM",
draft-ietf-pim-sm-bsr-12 (work in progress), August 2007. draft-ietf-pim-sm-bsr-12 (work in progress), August 2007.
[I-D.lehtonen-mboned-dynssm-req] [I-D.lehtonen-mboned-dynssm-req]
Lehtonen, R., "Requirements for discovery of dynamic SSM Lehtonen, R., "Requirements for discovery of dynamic SSM
sources", draft-lehtonen-mboned-dynssm-req-00 (work in sources", draft-lehtonen-mboned-dynssm-req-00 (work in
progress), February 2005. progress), February 2005.
skipping to change at page 22, line 20 skipping to change at page 23, line 5
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast [RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast
Protocols", RFC 1458, May 1993. Protocols", RFC 1458, May 1993.
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994. March 1994.
[RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585,
March 1994.
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast
Routing -- Protocol Specification --", RFC 2189, Routing -- Protocol Specification --", RFC 2189,
September 1997. September 1997.
[RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing
Architecture", RFC 2201, September 1997. Architecture", RFC 2201, September 1997.
[RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999. Protocols", RFC 2715, October 1999.
skipping to change at page 23, line 9 skipping to change at page 23, line 39
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group
Management Protocol (RGMP)", RFC 3488, February 2003. Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP):
Protocol Specification", RFC 3913, September 2004. Protocol Specification", RFC 3913, September 2004.
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005. Specification (Revised)", RFC 3973, January 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005. RFC 4286, December 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
skipping to change at page 24, line 7 skipping to change at page 24, line 38
A couple of mechanisms have been, and are being specified, to improve A couple of mechanisms have been, and are being specified, to improve
the characteristics of the data that can be transported over the characteristics of the data that can be transported over
multicast. multicast.
These go beyond the scope of multicast routing, but as reliable These go beyond the scope of multicast routing, but as reliable
multicast has some relevance, these are briefly mentioned. multicast has some relevance, these are briefly mentioned.
A.1. Reliable Multicast A.1. Reliable Multicast
Reliable Multicast Working Group has been working on experimental Reliable Multicast Working Group has been working on mostly
specifications so that applications requiring reliable delivery experimental specifications so that applications requiring reliable
characteristics, instead of simple unreliable UDP, could use delivery characteristics, instead of simple unreliable UDP, could use
multicast as a distribution mechanism. multicast as a distribution mechanism.
One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208].
This does not require support from the routers, bur PGM-aware routers This does not require support from the routers, bur PGM-aware routers
may act in router assistance role in the initial delivery and may act in router assistance role in the initial delivery and
potential retransmission of missing data. potential retransmission of missing data. Another mechanism is
Negative-acknowledgment (NACK)-Oriented Reliable Multicast Protocol
(NORM) [RFC3940] where routers may as an optional feature provide a
more efficient repair functionality.
A.2. Multicast Group Security A.2. Multicast Group Security
Multicast Security Working Group has been working on methods how the Multicast Security Working Group has been working on methods how the
integrity, confidentiality, and authentication of data sent to integrity, confidentiality, and authentication of data sent to
multicast groups can be ensured using cryptographic techniques multicast groups can be ensured using cryptographic techniques
[RFC3740]. [RFC3740].
Author's Address Author's Address
 End of changes. 44 change blocks. 
81 lines changed or deleted 113 lines changed or added

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