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/