draft-ietf-mboned-routingarch-01.txt		draft-ietf-mboned-routingarch-02.txt
	Internet Engineering Task Force P. Savola		Internet Engineering Task Force P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Obsoletes: July 11, 2005		Obsoletes: October 12, 2005
	3913,2189,2201,1584,1585 (if		3913,2189,2201,1584,1585 (if
	approved)		approved)
	Expires: January 12, 2006		Expires: April 15, 2006
	Overview of the Internet Multicast Routing Architecture		Overview of the Internet Multicast Routing Architecture
	draft-ietf-mboned-routingarch-01.txt		draft-ietf-mboned-routingarch-02.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 36		skipping to change at page 1, line 36
	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 January 12, 2006.		This Internet-Draft will expire on April 15, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The lack of up-to-date documentation on IP multicast routing		The lack of up-to-date documentation on IP multicast routing
	protocols and procedures has caused a great deal of confusion. To		protocols and procedures has caused a great deal of confusion. To
	clarify the situation, this memo describes the routing protocols and		clarify the situation, this memo describes the routing protocols and
	techniques currently (as of this writing) in use.		techniques currently (as of this writing) in use.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 4		1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 4
	2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4		2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4
	2.1 Setting up Multicast Forwarding State . . . . . . . . . . 4		2.1. Setting up Multicast Forwarding State . . . . . . . . . . 4
	2.1.1 PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.2 PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.3 Bi-directional PIM . . . . . . . . . . . . . . . . . . 5		2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 5
	2.1.4 DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.5 MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.6 BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.7 CBT . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.8 Interactions and Summary . . . . . . . . . . . . . . . 6		2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 6
	2.2 Distributing Topology Information . . . . . . . . . . . . 7		2.2. Distributing Topology Information . . . . . . . . . . . . 7
	2.2.1 Multi-protocol BGP . . . . . . . . . . . . . . . . . . 7		2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 7
	2.2.2 OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 7		2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 7
	2.2.3 Issue: Overlapping Unicast/multicast Topology . . . . 8		2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 8
	2.3 Learning (Active) Sources . . . . . . . . . . . . . . . . 8		2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 8
	2.3.1 SSM . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.2 MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.3 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9		2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9
	2.4 Configuring and Distributing PIM-SM RP Information . . . . 10		2.4. Configuring and Distributing PIM-SM RP Information . . . . 10
	2.4.1 Manual Configuration with an Anycast Address . . . . . 10		2.4.1. Manual Configuration with an Anycast Address . . . . . 10
	2.4.2 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10		2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10
	2.4.3 BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 11		2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 11
	2.5 Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 11		2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 11
	2.5.1 Anycast RP . . . . . . . . . . . . . . . . . . . . . . 11		2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 11
	2.5.2 Stateless RP Failover . . . . . . . . . . . . . . . . 11		2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 11
	2.5.3 Bi-directional PIM . . . . . . . . . . . . . . . . . . 12		2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 12
	2.6 Interactions with Hosts . . . . . . . . . . . . . . . . . 12		2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 12
	2.6.1 Hosts Sending Multicast . . . . . . . . . . . . . . . 12		2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 12
	2.6.2 Hosts Receiving Multicast . . . . . . . . . . . . . . 12		2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 12
	2.7 Restricting Multicast Flooding in the Link Layer . . . . . 12		2.7. Restricting Multicast Flooding in the Link Layer . . . . . 12
	2.7.1 Router-to-Router Flooding Reduction . . . . . . . . . 13		2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 13
	2.7.2 Host/Router Flooding Reduction . . . . . . . . . . . . 13		2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13
	3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6.1 Normative References . . . . . . . . . . . . . . . . . . . 14		6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	6.2 Informative References . . . . . . . . . . . . . . . . . . 15		6.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. Multicast Payload Transport Extensions . . . . . . . 18
	A. Multicast Payload Transport Extensions . . . . . . . . . . . . 18		A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18
	A.1 Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18		A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 18
	A.2 Multicast Group Security . . . . . . . . . . . . . . . . . 18		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
	Intellectual Property and Copyright Statements . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Good, up-to-date documentation of IP multicast is close to non-		Good, up-to-date documentation of IP multicast is close to non-
	existent. This issue is severely felt with multicast routing		existent. This issue is severely felt with multicast routing
	protocols and techniques. The consequence is that those who wish to		protocols and techniques. The consequence is that those who wish to
	learn of IP multicast and how the routing works in the real world do		learn of IP multicast and how the routing works in the real world do
	not know where to begin.		not know where to begin.
	The aim of this document is to provide a brief overview of multicast		The aim of this document is to provide a brief overview of multicast
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	This memo obsoletes and re-classifies to Historic [RFC2026] Border		This memo obsoletes and re-classifies to Historic [RFC2026] Border
	Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast		Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast
	OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and		OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and
	[RFC1585]. The purpose of the re-classification is to give the		[RFC1585]. The purpose of the re-classification is to give the
	readers (both implementors and deployers) an idea what the status of		readers (both implementors and deployers) an idea what the status of
	a protocol is; there may or may not be legacy deployments of these		a protocol is; there may or may not be legacy deployments of these
	protocols, which are not affected by this reclassification. See		protocols, which are not affected by this reclassification. See
	Section 2.1 for more on each protocol.		Section 2.1 for more on each protocol.
	1.1 Multicast-related Abbreviations		1.1. Multicast-related Abbreviations
	ASM Any Source Multicast		ASM Any Source Multicast
	BGMP Border Gateway Multicast Protocol		BGMP Border Gateway Multicast Protocol
	BSR Bootstrap Router		BSR Bootstrap Router
	CBT Core Based Trees		CBT Core Based Trees
	CGMP Cisco Group Management Protocol		CGMP Cisco Group Management Protocol
	DR Designated Router		DR Designated Router
	DVMRP Distance Vector Multicast Routing Protocol		DVMRP Distance Vector Multicast Routing Protocol
	GARP Group Address Resolution Protocol		GARP Group Address Resolution Protocol
	IGMP Internet Group Management Protocol		IGMP Internet Group Management Protocol
	skipping to change at page 4, line 32		skipping to change at page 4, line 32
	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) Sparse Mode		PIM-SSM PIM - (Source-specific) Sparse Mode
	RGMP (Cisco's) Router Group Management Protocol		RGMP (Cisco's) Router Group Management Protocol
	RP Rendezvous Point		RP Rendezvous Point
	SSM Source-specific Multicast		SSM Source-specific Multicast
	2. Multicast Routing		2. Multicast Routing
	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. This section describes the protocols
	commonly used for this purpose.		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
	[I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any		[I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any
	Source Multicast (ASM) and Source-Specific Multicast (SSM)		Source Multicast (ASM) and Source-Specific Multicast (SSM)
	functionality; PIM-SSM is a subset of PIM-SM. Most current routing		functionality; PIM-SSM is a subset of PIM-SM. Most current routing
	platforms support PIM-SM.		platforms support PIM-SM.
	2.1.2 PIM-DM		2.1.2. PIM-DM
	Whereas PIM-SM is designed to avoid unnecessary flooding of multicast		Whereas PIM-SM is designed to avoid unnecessary flooding of multicast
	data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode,		data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode,
	flooding the multicast transmissions throughout the network ("flood		flooding the multicast transmissions throughout the network ("flood
	and prune") unless the leaf parts of the network periodically		and prune") unless the leaf parts of the network periodically
	indicate that they are not interested in that particular traffic.		indicate that they are not interested in that particular traffic.
	PIM-DM may be some fit in small and/or simple networks, where setting		PIM-DM may be some fit in small and/or simple networks, where setting
	up an RP would be unnecessary, and possibly in cases where a large		up an RP would be unnecessary, and possibly in cases where a large
	number of users is expected to be able to wish to receive the		number of users is expected to be able to wish to receive the
	skipping to change at page 5, line 24		skipping to change at page 5, line 24
	potential for loops, and the over-reliance of the complex Assert		potential for loops, and the over-reliance of the complex Assert
	mechanism. Further, it was a non-starter with high-bandwidth		mechanism. Further, it was a non-starter with high-bandwidth
	streams.		streams.
	Many implementations also support so-called "sparse-dense" mode,		Many implementations also support so-called "sparse-dense" mode,
	where Sparse mode is is used by default, but Dense is used for		where Sparse mode is is used by default, but Dense is used for
	configured multicast group ranges (such as Auto-RP in Section 2.4.3)		configured multicast group ranges (such as Auto-RP in Section 2.4.3)
	only. Lately, many networks have been transitioned away from sparse-		only. Lately, many networks have been transitioned away from sparse-
	dense to only sparse mode.		dense to only sparse mode.
	2.1.3 Bi-directional PIM		2.1.3. Bi-directional PIM
	Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined		Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined
	PIM-SM operation, without data-driven events and data-encapsulation,		PIM-SM operation, without data-driven events and data-encapsulation,
	inside a PIM-SM domain. The usage of bi-dir PIM may be on the		inside a PIM-SM domain. The usage of bi-dir PIM may be on the
	increase especially inside sites leveraging multicast.		increase especially inside sites leveraging multicast.
	As of this writing, in IPv6 or inter-domain multicast there is no		As of this writing, in IPv6 or inter-domain multicast there is no
	standards based mechanism for alerting routers that a group range is		standards based mechanism for alerting routers that a group range is
	to be used for bi-directional PIM.		to be used for bi-directional PIM.
	2.1.4 DVMRP		2.1.4. DVMRP
	Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075]		Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075]
	[I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first		[I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first
	protocol designed for multicasting, and to get around initial		protocol designed for multicasting, and to get around initial
	deployment hurdles, it also included tunneling capabilities which		deployment hurdles, it also included tunneling capabilities which
	were part of its multicast topology functions.		were part of its multicast topology functions.
	Currently, DVMRP is used only very rarely in operator networks,		Currently, DVMRP is used only very rarely in operator networks,
	having been replaced with PIM-SM. The most typical deployment of		having been replaced with PIM-SM. The most typical deployment of
	DVMRP is at a leaf network, to run from a legacy firewall only		DVMRP is at a leaf network, to run from a legacy firewall only
	supporting DVMRP to the internal network. However, GRE tunneling		supporting DVMRP to the internal network. However, GRE tunneling
	[RFC2784] seems to have overtaken DVMRP in this functionality, and		[RFC2784] seems to have overtaken DVMRP in this functionality, and
	there is relatively little use for DVMRP except in legacy		there is relatively little use for DVMRP except in legacy
	deployments.		deployments.
	2.1.5 MOSPF		2.1.5. MOSPF
	MOSPF [RFC1584] was implemented by several vendors and has seen some		MOSPF [RFC1584] was implemented by several vendors and has seen some
	deployment in intra-domain networks. However, since it does not		deployment in intra-domain networks. However, since it does not
	scale to the inter-domain case, operators have found it is easier to		scale to the inter-domain case, operators have found it is easier to
	deploy a single protocol for use in both intra-domain and inter-		deploy a single protocol for use in both intra-domain and inter-
	domain networks and so it is no longer being actively deployed.		domain networks and so it is no longer being actively deployed.
	2.1.6 BGMP		2.1.6. BGMP
	BGMP [RFC3913] did not get sufficient support within the service		BGMP [RFC3913] did not get sufficient support within the service
	provider community to get adopted and moved forward in the IETF		provider community to get adopted and moved forward in the IETF
	standards process. There were no reported production implementations		standards process. There were no reported production implementations
	and no production deployments.		and no production deployments.
	2.1.7 CBT		2.1.7. CBT
	CBT [RFC2201] was was an academic project that provided the basis for		CBT [RFC2201] was was an academic project that provided the basis for
	PIM sparse mode shared trees. Once the shared tree functionality was		PIM sparse mode shared trees. Once the shared tree functionality was
	incorporated into PIM implementations, there was no longer a need for		incorporated into PIM implementations, there was no longer a need for
	a production CBT implemention. Therefore, CBT never saw production		a production CBT implemention. Therefore, CBT never saw production
	deployment.		deployment.
	2.1.8 Interactions and Summary		2.1.8. Interactions and Summary
	It is worth noting that is it is possible to run different protocols		It is worth noting that is it is possible to run different protocols
	with different groups ranges (e.g., treat some groups as dense mode		with different groups ranges (e.g., treat some groups as dense mode
	in an other-wise PIM-SM network; this typically requires manual		in an other-wise PIM-SM network; this typically requires manual
	configuration of the groups) or interact between different protocols		configuration of the groups) or interact between different protocols
	(e.g., use DVMRP in the leaf network, but PIM-SM upstream). The		(e.g., use DVMRP in the leaf network, but PIM-SM upstream). The
	basics for interactions among different protocols have been outlined		basics for interactions among different protocols have been outlined
	in [RFC2715].		in [RFC2715].
	The following figure gives a concise summary of the deployment status		The following figure gives a concise summary of the deployment status
	skipping to change at page 7, line 8		skipping to change at page 7, line 8
	| Bi-dir PIM | No | Yes | Wait & see |		| Bi-dir PIM | No | Yes | Wait & see |
	| DVMRP | Not anymore | Stub only | Going out |		| DVMRP | Not anymore | Stub only | Going out |
	| MOSF | No | Not anymore | Inactive |		| MOSF | No | Not anymore | Inactive |
	| CBT | No | No | Never deployed |		| CBT | No | No | Never deployed |
	| BGMP | No | No | Never deployed |		| BGMP | No | No | Never deployed |
	+------------+-------------+-------------+----------------+		+------------+-------------+-------------+----------------+
	From this table, it is clear that PIM-Sparse Mode is the only		From this table, it is clear that PIM-Sparse Mode is the only
	multicast routing protocol that is deployed inter-domain and,		multicast routing protocol that is deployed inter-domain and,
	therefore, is most frequently used within multicast domains as well.		therefore, is most frequently used within multicast domains as well.
	2.2 Distributing Topology Information		2.2. Distributing Topology Information
	When unicast and multicast topologies are the same ("congruent"),		When unicast and multicast topologies are the same ("congruent"),
	i.e., use the same routing tables (routing information base, RIB), it		i.e., use the same routing tables (routing information base, RIB), it
	has been considered sufficient just to distribute one set of		has been considered sufficient just to distribute one set of
	reachability information.		reachability information.
	However, when PIM -- which by default built multicast topology based		However, when PIM -- which by default built multicast topology based
	on the unicast topology -- gained popularity, it became apparent that		on the unicast topology -- gained popularity, it became apparent that
	it would be necessary to be able to distribute also non-congruent		it would be necessary to be able to distribute also non-congruent
	multicast reachability information in the regular unicast protocols.		multicast reachability information in the regular unicast protocols.
	This was previously not an issue, because DVMRP built its own		This was previously not an issue, because DVMRP built its own
	reachability information.		reachability information.
	The topology information is needed to perform efficient distribution		The topology information is needed to perform efficient distribution
	of multicast transmissions and to prevent transmission loops by		of multicast transmissions and to prevent transmission loops by
	applying it to the Reverse Path Forwarding (RPF) check.		applying it to the Reverse Path Forwarding (RPF) check.
	This subsection introduces these protocols.		This subsection introduces these protocols.
	2.2.1 Multi-protocol BGP		2.2.1. Multi-protocol BGP
	Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as		Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as
	"MBGP"; however, it is worth noting that "MBGP" does *not* stand for		"MBGP"; however, it is worth noting that "MBGP" does *not* stand for
	"Multicast BGP") specifies a mechanism by which BGP can be used to		"Multicast BGP") specifies a mechanism by which BGP can be used to
	distribute different reachability information for unicast and		distribute different reachability information for unicast and
	multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP		multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP
	has been widely deployed for years, and is also needed to route IPv6.		has been widely deployed for years, and is also needed to route IPv6.
			Note that SAFI=3 was originally specified for "both unicast and
			multicast" but has been deprecated [I-D.ietf-idr-rfc2858bis].
	These extensions are in widespread use wherever BGP is used to		These extensions are in widespread use wherever BGP is used to
	distribute unicast topology information. Those having multicast		distribute unicast topology information. Those having multicast
	infrastructure and using BGP should use Multiprotocol BGP to		infrastructure and using BGP should use Multiprotocol BGP to
	distribute multicast reachability information explicitly even if the		distribute multicast reachability information explicitly even if the
	topologies are congruent (using SAFI=3). A number of significant		topologies are congruent. A number of significant multicast transit
	multicast transit providers even require this, by doing the RPF		providers even require this, by doing the RPF lookups solely based on
	lookups solely based on explicitly advertised multicast address		explicitly advertised multicast address family.
	family.
	2.2.2 OSPF/IS-IS Multi-topology Extensions		2.2.2. OSPF/IS-IS Multi-topology Extensions
	Similar to BGP, some IGPs also provide the capability for signalling		Similar to BGP, some IGPs also provide the capability for signalling
	a differing multicast topology, for example IS-IS multi-topology		a differing multicast topology, for example IS-IS multi-topology
	extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists		extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists
	for OSPF [I-D.ietf-ospf-mt].		for OSPF [I-D.ietf-ospf-mt].
	It is worth noting that interdomain incongruence and intradomain		It is worth noting that interdomain incongruence and intradomain
	incongruence are orthogonal, so one doesn't require the other.		incongruence are orthogonal, so one doesn't require the other.
	Specifically, interdomain incongruence is quite common, while		Specifically, interdomain incongruence is quite common, while
	intradomain incongruence isn't, so you see much more deployments of		intradomain incongruence isn't, so you see much more deployments of
	MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well		MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well
	without protocols handling intradomain incongruence. However, the		without protocols handling intradomain incongruence. However, the
	availability of multi-topology mechanisms may in part replace the		availability of multi-topology mechanisms may in part replace the
	typically used workarounds such as tunnels.		typically used workarounds such as tunnels.
	2.2.3 Issue: Overlapping Unicast/multicast Topology		2.2.3. Issue: Overlapping Unicast/multicast Topology
	An interesting case occurs when some routers do not distribute		An interesting case occurs when some routers do not distribute
	multicast topology information explicitly while others do. In		multicast topology information explicitly while others do. In
	particular, this happens when some multicast sites in the Internet		particular, this happens when some multicast sites in the Internet
	are using plain BGP while some use MBGP.		are using plain BGP while some use MBGP.
	Different implementations deal with this using different means.		Different implementations deal with this using different means.
	Sometimes, multicast RPF mechanisms first look up the multicast		Sometimes, multicast RPF mechanisms first look up the multicast
	routing table, or RIB ("topology database") with a longest prefix		routing table, or RIB ("topology database") with a longest prefix
	match algorithm, and if they find any entry (including a default		match algorithm, and if they find any entry (including a default
	skipping to change at page 8, line 41		skipping to change at page 8, line 42
	routing table. The important point to remember here, though, is to		routing table. The important point to remember here, though, is to
	not override the multicast-only routes; if the longest prefix match		not override the multicast-only routes; if the longest prefix match
	would find both a (copied) unicast route and a multicast-only route,		would find both a (copied) unicast route and a multicast-only route,
	the latter should be treated as preferable.		the latter should be treated as preferable.
	One implemented approach is to just look up the information in the		One implemented approach is to just look up the information in the
	unicast routing table, and provide the user capabilities to change		unicast routing table, and provide the user capabilities to change
	that as appropriate, using for example copying functions discussed		that as appropriate, using for example copying functions discussed
	above.		above.
	2.3 Learning (Active) Sources		2.3. Learning (Active) Sources
	Typically, multicast routing protocols must either assume that the		Typically, multicast routing protocols must either assume that the
	receivers know the IP addresses of the (active) sources for a group a		receivers know the IP addresses of the (active) sources for a group a
	priori, possibly using an out-of-band mechanism (SSM), or the sources		priori, possibly using an out-of-band mechanism (SSM), or the sources
	must be discovered by the network protocols automatically (ASM).		must be discovered by the network protocols automatically (ASM).
	Learning active sources is a relatively straightforward process with		Learning active sources is a relatively straightforward process with
	a single PIM-SM domain and with a single RP, but having a single		a single PIM-SM domain and with a single RP, but having a single
	PIM-SM domain for the whole Internet is a completely unscalable		PIM-SM domain for the whole Internet is a completely unscalable model
	model for many reasons. Therefore it is required to be able to split		for many reasons. Therefore it is required to be able to split up
	up the multicast routing infrastructures to smaller domains, and		the multicast routing infrastructures to smaller domains, and there
	there must be a way to share information about active sources using		must be a way to share information about active sources using some
	some mechanism if the ASM model is to be supported.		mechanism if the ASM model is to be supported.
	This section discusses the options.		This section discusses the options.
	2.3.1 SSM		2.3.1. SSM
	Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also		Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also
	referred to as "single-source Multicast") does not count on learning		referred to as "single-source Multicast") does not count on learning
	active sources in the network; it is assumed that the recipients know		active sources in the network; it is assumed that the recipients know
	these using out of band mechanisms, and when subscribing to an (S,G)		these using out of band mechanisms, and when subscribing to an (S,G)
	channel indicate toward which source(s) the multicast routing		channel indicate toward which source(s) the multicast routing
	protocol should send the Join messages.		protocol should send the Join messages.
	As of this writing, there are attempts to analyze and/or define out-		As of this writing, there are attempts to analyze and/or define out-
	of-band source discovery functions which would help SSM in particular		of-band source discovery functions which would help SSM in particular
	[I-D.lehtonen-mboned-dynssm-req].		[I-D.lehtonen-mboned-dynssm-req].
	2.3.2 MSDP		2.3.2. MSDP
	Multicast Source Discovery Mechanism [RFC3618] was invented as a		Multicast Source Discovery Mechanism [RFC3618] was invented as a
	stop-gap mechanism, when it became apparent that multiple PIM-SM		stop-gap mechanism, when it became apparent that multiple PIM-SM
	domains (and RPs) were needed in the network, and information about		domains (and RPs) were needed in the network, and information about
	the active sources needed to be propagated between the PIM-SM domains		the active sources needed to be propagated between the PIM-SM domains
	using some other protocol.		using some other protocol.
	MSDP is also used to share the state about sources between multiple		MSDP is also used to share the state about sources between multiple
	RPs in a single domain for, e.g., redundancy purposes [RFC3446].		RPs in a single domain for, e.g., redundancy purposes [RFC3446].
	There is also work in progress to achieve the same using PIM		There is also work in progress to achieve the same using PIM
	extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more.		extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more.
	There is no intent to define MSDP for IPv6, but instead use only SSM		There is no intent to define MSDP for IPv6, but instead use only SSM
	and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues].		and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues].
	2.3.3 Embedded-RP		2.3.3. Embedded-RP
	Embedded-RP [RFC3956] is an IPv6-only technique to map the address of		Embedded-RP [RFC3956] is an IPv6-only technique to map the address of
	the RP to the multicast group address. Using this method, it is		the RP to the multicast group address. Using this method, it is
	possible to avoid the use of MSDP while still allowing multiple		possible to avoid the use of MSDP while still allowing multiple
	multicast domains (in the traditional sense).		multicast domains (in the traditional sense).
	The model works by defining a single RP for a particular group for		The model works by defining a single RP for a particular group for
	all of the Internet, so there is no need to share state about that		all of the Internet, so there is no need to share state about that
	with any other RPs (except, possibly, for redundancy purposes with		with any other RPs (except, possibly, for redundancy purposes with
	Anycast-RP using PIM).		Anycast-RP using PIM).
	2.4 Configuring and Distributing PIM-SM RP Information		2.4. Configuring and Distributing PIM-SM RP Information
	For PIM-SM, configuration mechanisms exist which are used to		For PIM-SM, configuration mechanisms exist which are used to
	configure the RP addresses and which groups are to use those RPs in		configure the RP addresses and which groups are to use those RPs in
	the routers. This section outlines the approaches.		the routers. This section outlines the approaches.
	2.4.1 Manual Configuration with an Anycast Address		2.4.1. Manual Configuration with an Anycast Address
	It is often easiest just to manually configure the RP information on		It is often easiest just to manually configure the RP information on
	the routers when PIM-SM is used.		the routers when PIM-SM is used.
	Originally, static RP mapping was considered suboptimal since it		Originally, static RP mapping was considered suboptimal since it
	required explicit configuration chages every time the RP address		required explicit configuration chages every time the RP address
	changed. However, with the advent of anycast RP addressing, the RP		changed. However, with the advent of anycast RP addressing, the RP
	address is unlikely to ever change. Therefore, the administrative		address is unlikely to ever change. Therefore, the administrative
	burden is generally limited to initial configuration. Since there is		burden is generally limited to initial configuration. Since there is
	usually a fair amount of multicast configuration required on all		usually a fair amount of multicast configuration required on all
	skipping to change at page 10, line 35		skipping to change at page 10, line 35
	Section 2.5) without the complexity found in dynamic mechanisms like		Section 2.5) without the complexity found in dynamic mechanisms like
	Auto-RP and Bootstrap Router (BSR).		Auto-RP and Bootstrap Router (BSR).
	With such design, an anycast RP uses a "portable" address, which is		With such design, an anycast RP uses a "portable" address, which is
	configured on a loopback interfaces of the routers currently acting		configured on a loopback interfaces of the routers currently acting
	as RPs, as described in [RFC3446].		as RPs, as described in [RFC3446].
	Using this technique, each router might only need to be configured		Using this technique, each router might only need to be configured
	with one, portable RP address.		with one, portable RP address.
	2.4.2 Embedded-RP		2.4.2. Embedded-RP
	Embedded-RP provides the information about the RP's address in the		Embedded-RP provides the information about the RP's address in the
	group addresses which are delegated to those who use the RP, so		group addresses which are delegated to those who use the RP, so
	unless no other ASM than Embedded-RP is used, one only needs to		unless no other ASM than Embedded-RP is used, one only needs to
	configure the RP routers themselves.		configure the RP routers themselves.
	While Embedded-RP in many cases is sufficient for IPv6, other methods		While Embedded-RP in many cases is sufficient for IPv6, other methods
	of RP configuration are needed if one needs to provide ASM service		of RP configuration are needed if one needs to provide ASM service
	for other than Embedded-RP group addresses. In particular, service		for other than Embedded-RP group addresses. In particular, service
	discovery type of applications may need hard-coded addresses that are		discovery type of applications may need hard-coded addresses that are
	not dependent on local RP addresses.		not dependent on local RP addresses.
	As the RP's address is exposed to the users and applications, it is		As the RP's address is exposed to the users and applications, it is
	very important to ensure it does not change often, e.g., by using		very important to ensure it does not change often, e.g., by using
	manual configuration of an anycast address.		manual configuration of an anycast address.
	2.4.3 BSR and Auto-RP		2.4.3. BSR and Auto-RP
	BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP		BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP
	address for groups. It may no longer be in as wide use with IPv4 as		address for groups. It may no longer be in as wide use with IPv4 as
	it was ealier, and for IPv6, Embedded-RP will in many cases be		it was ealier, and for IPv6, Embedded-RP will in many cases be
	sufficient.		sufficient.
	Cisco's Auto-RP is an older, proprietary method for distributing		Cisco's Auto-RP is an older, proprietary method for distributing
	group to RP mappings, similar to BSR. Auto-RP has little use today.		group to RP mappings, similar to BSR. Auto-RP has little use today.
	Both Auto-RP and BSR require some form of control at the routers to		Both Auto-RP and BSR require some form of control at the routers to
	skipping to change at page 11, line 30		skipping to change at page 11, line 30
	using, for example if a router (maybe in customer's control) is		using, for example if a router (maybe in customer's control) is
	advertising itself inappropriately. All in all, while BSR and		advertising itself inappropriately. All in all, while BSR and
	Auto-RP provide easy configuration, they also provide very		Auto-RP provide easy configuration, they also provide very
	significant configuration and management complexity.		significant configuration and management complexity.
	It is worth noting that both Auto-RP and BSR were deployed before the		It is worth noting that both Auto-RP and BSR were deployed before the
	use of a manually configured anycast-RP address became relatively		use of a manually configured anycast-RP address became relatively
	commonplace, and there is actually relatively little use for them		commonplace, and there is actually relatively little use for them
	today.		today.
	2.5 Mechanisms for Enhanced Redundancy		2.5. Mechanisms for Enhanced Redundancy
	A couple of mechanisms, already described in this document, have been		A couple of mechanisms, already described in this document, have been
	used as a means to enhance redundancy, resilience against failures,		used as a means to enhance redundancy, resilience against failures,
	and to recover from failures quickly. This section summarizes these		and to recover from failures quickly. This section summarizes these
	techniques explicitly.		techniques explicitly.
	2.5.1 Anycast RP		2.5.1. Anycast RP
	As mentioned in Section 2.3.2, MSDP is also used to share the state		As mentioned in Section 2.3.2, MSDP is also used to share the state
	about sources between multiple RPs in a single domain for, e.g.,		about sources between multiple RPs in a single domain for, e.g.,
	redundancy purposes [RFC3446]. The purpose of MSDP in this context		redundancy purposes [RFC3446]. The purpose of MSDP in this context
	is to share the same state information on multiple RPs for the same		is to share the same state information on multiple RPs for the same
	groups to enhance the robustness of the service.		groups to enhance the robustness of the service.
	There is also work in progress to achieve the same using PIM		There is also work in progress to achieve the same using PIM
	extensions [I-D.ietf-pim-anycast-rp]. This is a required method to		extensions [I-D.ietf-pim-anycast-rp]. This is a required method to
	be able to use Anycast RP with IPv6.		be able to use Anycast RP with IPv6.
	2.5.2 Stateless RP Failover		2.5.2. Stateless RP Failover
	It is also possible to use some mechanisms for smaller amount of		It is also possible to use some mechanisms for smaller amount of
	redundancy as Anycast RP, without sharing state between the RPs. A		redundancy as Anycast RP, without sharing state between the RPs. A
	traditional mechanism has been to use Auto-RP or BSR (see		traditional mechanism has been to use Auto-RP or BSR (see
	Section 2.4.3) to select another RP when the active one failed.		Section 2.4.3) to select another RP when the active one failed.
	However, the same functionality could be achieved using a shared-		However, the same functionality could be achieved using a shared-
	unicast RP address ("anycast RP without state sharing") without the		unicast RP address ("anycast RP without state sharing") without the
	complexity of a dynamic mechanism. Further, Anycast RP offers a		complexity of a dynamic mechanism. Further, Anycast RP offers a
	significantly more extensive failure mitigation strategy, so today		significantly more extensive failure mitigation strategy, so today
	there is actually very little need to use stateless failover		there is actually very little need to use stateless failover
	mechanisms, especially dynamic ones, for redundancy purposes.		mechanisms, especially dynamic ones, for redundancy purposes.
	2.5.3 Bi-directional PIM		2.5.3. Bi-directional PIM
	Bi-directional PIM (see Section 2.1.3) uses less state than PIM-SM,		Bi-directional PIM (see Section 2.1.3) uses less state than PIM-SM,
	implying a better total convergence. On the other hand, PIM-SM or		implying a better total convergence. On the other hand, PIM-SM or
	SSM may be faster especially in scenarios where bi-directional needs		SSM may be faster especially in scenarios where bi-directional needs
	to re-do the Designated Forwarder election.		to re-do the Designated Forwarder election.
	2.6 Interactions with Hosts		2.6. Interactions with Hosts
	Previous sections have dealt with the components required by routers		Previous sections have dealt with the components required by routers
	to be able to do multicast routing. Obviously, the real users of		to be able to do multicast routing. Obviously, the real users of
	multicast are the hosts: either sending or receiving multicast. This		multicast are the hosts: either sending or receiving multicast. This
	section describes the required interactions with hosts.		section describes the required interactions with hosts.
	2.6.1 Hosts Sending Multicast		2.6.1. Hosts Sending Multicast
	Hosts don't need to do any signalling prior to sending multicast to a		Hosts don't need to do any signalling prior to sending multicast to a
	group; they just send the packets to the link-layer multicast		group; they just send the packets to the link-layer multicast
	address, and the designated router will receive all the multicast		address, and the designated router will receive all the multicast
	packets and start forwarding them as appropriate.		packets and start forwarding them as appropriate.
	2.6.2 Hosts Receiving Multicast		2.6.2. Hosts Receiving Multicast
	Hosts signal their interest in receiving a multicast group or channel		Hosts signal their interest in receiving a multicast group or channel
	by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are		by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are
	also commonplace, but most new deployments support the latest		also commonplace, but most new deployments support the latest
	specifications.		specifications.
	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
	Ethernet switches between routers, or between routers and hosts, to		Ethernet switches between routers, or between routers and hosts, to
	limit the flooding.		limit the flooding.
	These options are discussed in this section.		These options are discussed in this section.
	2.7.1 Router-to-Router Flooding Reduction		2.7.1. Router-to-Router Flooding Reduction
	A proprietary solution, Cisco's RGMP [RFC3488] has been developed to		A proprietary solution, Cisco's RGMP [RFC3488] has been developed to
	reduce the amount of router-to-router flooding on a LAN. This is		reduce the amount of router-to-router flooding on a LAN. This is
	typically only considered a problem in some Ethernet-based Internet		typically only considered a problem in some Ethernet-based Internet
	Exchange points.		Exchange points.
	There have been proposals to snoop PIM messages [I-D.tsenevir-pim-sm-		There have been proposals to snoop PIM messages [I-D.tsenevir-pim-sm-
	snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect.		snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect.
	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. IPv6 is not supported.		receive a group. IPv6 is not supported.
	IEEE specifications mention Group Address Resolution Protocol (GARP)		IEEE specifications mention Group Address Resolution Protocol (GARP)
	skipping to change at page 14, line 23		skipping to change at page 14, line 24
	and this has no security considerations; the security analysis of the		and this has no security considerations; the security analysis of the
	mentioned protocols is out of scope of this memo.		mentioned protocols is out of scope of this memo.
	However, there has been analysis of the security of multicast routing		However, there has been analysis of the security of multicast routing
	infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley-		infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley-
	magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop-		magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop-
	threats].		threats].
	6. References		6. References
	6.1 Normative References		6.1. Normative References
	[I-D.ietf-idmr-dvmrp-v3]		[I-D.ietf-idmr-dvmrp-v3]
	Pusateri, T., "Distance Vector Multicast Routing		Pusateri, T., "Distance Vector Multicast Routing
	Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress),		Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress),
	December 2003.		December 2003.
	[I-D.ietf-idmr-dvmrp-v3-as]		[I-D.ietf-idmr-dvmrp-v3-as]
	Pusateri, T., "Distance Vector Multicast Routing Protocol		Pusateri, T., "Distance Vector Multicast Routing Protocol
	Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01		Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01
	(work in progress), May 2004.		(work in progress), May 2004.
	skipping to change at page 15, line 17		skipping to change at page 15, line 21
	[I-D.ietf-pim-sm-v2-new]		[I-D.ietf-pim-sm-v2-new]
	Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode PIM-SM):		"Protocol Independent Multicast - Sparse Mode PIM-SM):
	Protocol Specification (Revised)",		Protocol Specification (Revised)",
	draft-ietf-pim-sm-v2-new-11 (work in progress),		draft-ietf-pim-sm-v2-new-11 (work in progress),
	October 2004.		October 2004.
	[I-D.ietf-ssm-arch]		[I-D.ietf-ssm-arch]
	Holbrook, H. and B. Cain, "Source-Specific Multicast for		Holbrook, H. and B. Cain, "Source-Specific Multicast for
	IP", draft-ietf-ssm-arch-06 (work in progress),		IP", draft-ietf-ssm-arch-07 (work in progress),
	September 2004.		October 2005.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.		3", BCP 9, RFC 2026, October 1996.
	[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,		[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
	"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.		"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol, Version
	3", RFC 3376, October 2002.		3", RFC 3376, October 2002.
	skipping to change at page 15, line 40		skipping to change at page 15, line 44
	[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery		[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
	Protocol (MSDP)", RFC 3618, October 2003.		Protocol (MSDP)", RFC 3618, October 2003.
	[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery		[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
	[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous		[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
	Point (RP) Address in an IPv6 Multicast Address",		Point (RP) Address in an IPv6 Multicast Address",
	RFC 3956, November 2004.		RFC 3956, November 2004.
	6.2 Informative References		6.2. Informative References
	[CGMP] "Cisco Group Management Protocol",		[CGMP] "Cisco Group Management Protocol",
	<http://www.javvin.com/protocolCGMP.html>.		<http://www.javvin.com/protocolCGMP.html>.
	[GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study		[GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study
	of IEEE 802.1p GARP/GMRP Timer Values", 1997.		of IEEE 802.1p GARP/GMRP Timer Values", 1997.
	[I-D.daley-magma-smld-prob]		[I-D.daley-magma-smld-prob]
	Daley, G. and G. Kurup, "Trust Models and Security in		Daley, G. and G. Kurup, "Trust Models and Security in
	Multicast Listener Discovery",		Multicast Listener Discovery",
	draft-daley-magma-smld-prob-00 (work in progress),		draft-daley-magma-smld-prob-00 (work in progress),
	July 2004.		July 2004.
			[I-D.ietf-idr-rfc2858bis]
			Bates, T., "Multiprotocol Extensions for BGP-4",
			draft-ietf-idr-rfc2858bis-07 (work in progress),
			August 2005.
	[I-D.ietf-magma-igmp-proxy]		[I-D.ietf-magma-igmp-proxy]
	Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/		Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
	MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",		MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
	draft-ietf-magma-igmp-proxy-06 (work in progress),		draft-ietf-magma-igmp-proxy-06 (work in progress),
	April 2004.		April 2004.
	[I-D.ietf-magma-mrdisc]		[I-D.ietf-magma-mrdisc]
	Haberman, B. and J. Martin, "Multicast Router Discovery",		Haberman, B. and J. Martin, "Multicast Router Discovery",
	draft-ietf-magma-mrdisc-07 (work in progress), May 2005.		draft-ietf-magma-mrdisc-07 (work in progress), May 2005.
	skipping to change at page 16, line 34		skipping to change at page 16, line 44
	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-mboned-mroutesec]		[I-D.ietf-mboned-mroutesec]
	Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast		Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
	Routing Security Issues and Enhancements",		Routing Security Issues and Enhancements",
	draft-ietf-mboned-mroutesec-04 (work in progress),		draft-ietf-mboned-mroutesec-04 (work in progress),
	October 2004.		October 2004.
	[I-D.ietf-pim-anycast-rp]		[I-D.ietf-pim-anycast-rp]
	Farinacci, D., "Anycast-RP using PIM",		Farinacci, D. and Y. Cai, "Anycast-RP using PIM",
	draft-ietf-pim-anycast-rp-03 (work in progress),		draft-ietf-pim-anycast-rp-04 (work in progress),
	April 2005.		August 2005.
	[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-05 (work in progress),		draft-ietf-pim-sm-bsr-05 (work in progress),
	February 2005.		February 2005.
	[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.
	[I-D.savola-pim-lasthop-threats]		[I-D.savola-pim-lasthop-threats]
	Savola, P., "Last-hop Threats to Protocol Independent		Savola, P., "Last-hop Threats to Protocol Independent
	Multicast (PIM)", draft-savola-pim-lasthop-threats-01		Multicast (PIM)", draft-savola-pim-lasthop-threats-01
	(work in progress), January 2005.		(work in progress), January 2005.
	[I-D.serbest-l2vpn-vpls-mcast]		[I-D.serbest-l2vpn-vpls-mcast]
	Serbest, Y., "Supporting IP Multicast over VPLS",		Serbest, Y., "Supporting IP Multicast over VPLS",
	draft-serbest-l2vpn-vpls-mcast-02 (work in progress),		draft-serbest-l2vpn-vpls-mcast-03 (work in progress),
	February 2005.		July 2005.
	[I-D.tsenevir-pim-sm-snoop]		[I-D.tsenevir-pim-sm-snoop]
	Senevirathne, T. and S. Vallepali, "Protocol Independent		Senevirathne, T. and S. Vallepali, "Protocol Independent
	Multicast-Sparse Mode (PIM-SM) Snooping",		Multicast-Sparse Mode (PIM-SM) Snooping",
	draft-tsenevir-pim-sm-snoop-00 (work in progress),		draft-tsenevir-pim-sm-snoop-00 (work in progress),
	April 2002.		April 2002.
	[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance		[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
	Vector Multicast Routing Protocol", RFC 1075,		Vector Multicast Routing Protocol", RFC 1075,
	November 1988.		November 1988.
	skipping to change at page 18, line 16		skipping to change at page 18, line 26
	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.
	[RITVANEN]		[RITVANEN]
	Ritvanen, K., "Multicast Routing and Addressing", HUT		Ritvanen, K., "Multicast Routing and Addressing", HUT
	Report, Seminar on Internetworking, May 2004,		Report, Seminar on Internetworking, May 2004,
	<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.		<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
	Author's Address
	Pekka Savola
	CSC - Scientific Computing Ltd.
	Espoo
	Finland
	Email: psavola@funet.fi
	Appendix A. Multicast Payload Transport Extensions		Appendix A. Multicast Payload Transport Extensions
	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 experimental
	specifications so that applications requiring reliable delivery		specifications so that applications requiring reliable delivery
	characteristics, instead of simple unreliable UDP, could use		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 as helpers delivering missing data.		may act as helpers delivering missing data.
	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].
	Intellectual Property Statement		Author's Address
			Pekka Savola
			CSC - Scientific Computing Ltd.
			Espoo
			Finland
			Email: psavola@funet.fi
			Full Copyright Statement
			Copyright (C) The Internet Society (2005).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 19, line 29		skipping to change at page 20, line 11
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 53 change blocks.
	121 lines changed or deleted		127 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/