draft-ietf-mboned-routingarch-08.txt		draft-ietf-mboned-routingarch-09.txt
	Internet Engineering Task Force P. Savola		Internet Engineering Task Force P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Obsoletes: June 14, 2007		Obsoletes: August 3, 2007
	3913,2189,2201,1584,1585		3913,2189,2201,1584,1585
	(if approved)		(if approved)
	Intended status: Best Current		Intended status: Best Current
	Practice		Practice
	Expires: December 16, 2007		Expires: February 4, 2008
	Overview of the Internet Multicast Routing Architecture		Overview of the Internet Multicast Routing Architecture
	draft-ietf-mboned-routingarch-08.txt		draft-ietf-mboned-routingarch-09.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 38
	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 December 16, 2007.		This Internet-Draft will expire on February 4, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The lack of up-to-date documentation on IP multicast routing		This document describes multicast routing architectures that are
	protocols and procedures has caused a great deal of confusion. To		currently deployed on the Internet. This document briefly describes
	clarify the situation, this memo describes the routing protocols and		those protocols and references their specifications.
	techniques currently (as of this writing) in use. This memo also
	Obsoletes and reclassifies to Historic a number of older multicast		This memo also obsoletes and reclassifies to Historic several older
	protocols.		RFCs. These RFCs describe multicast routing protocols that were
			never widely 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 . . . . . . . . . . . . . . . . . . 6		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 . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 7		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 . . . . . . . . . . . . 8
	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 . . . . . . . . . 9
	2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 9		2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 10
	2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10		2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10
	2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10		2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 11
	2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11		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 . . . . . 12
	2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12		2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . . . . . . . 13
	2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13		2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14
	2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14		2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14
	2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14		2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14
	2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14		2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14
	2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 14		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 . . . . . . . . . . . . . . . . . 15
	2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15		2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15
	2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15		2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16
	2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15		2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16
	2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16		2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16
	2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16		2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17
	2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16		2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17
	2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17		2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18
	3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 18		5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 18		6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	6.2. Informative References . . . . . . . . . . . . . . . . . . 19		6.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A. Multicast Payload Transport Extensions . . . . . . . 22		Appendix A. Multicast Payload Transport Extensions . . . . . . . 23
	A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23		A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23
	A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23		A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . . . 24
	1. Introduction		1. Introduction
	Good, up-to-date documentation of IP multicast is close to non-		This document provides a brief overview of multicast routing
	existent. This issue is severely felt with multicast routing		architectures that are currently deployed on the Internet and how
	protocols and techniques. The consequence is that those who wish to		those protocols fit together. It also describes those multicast
	learn of IP multicast and how the routing works in the real world do		routing protocols that were never widely deployed or have fallen into
	not know where to begin. Multicast addressing is described in a		disuse. A companion document [I-D.ietf-mboned-addrarch] describes
	companion document [I-D.ietf-mboned-addrarch].		multicast addressing architectures.
	The aim of this document is to provide a brief overview of multicast
	routing protocols and techniques.
	This memo deals with:		Specifically, this memo deals with:
	o setting up multicast forwarding state (Section 2.1),		o setting up multicast forwarding state (Section 2.1),
	o distributing multicast topology information (Section 2.2),		o distributing multicast topology information (Section 2.2),
	o learning active sources (Section 2.3),		o learning active sources (Section 2.3),
	o configuring and distributing the PIM RP information (Section 2.4),		o configuring and distributing the PIM RP information (Section 2.4),
	o mechanisms for enhanced redundancy (Section 2.5),		o mechanisms for enhanced redundancy (Section 2.5),
	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] Border		This memo obsoletes and re-classifies to Historic [RFC2026] the
	Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast		following RFCs:
	OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and
	[RFC1585]. The purpose of the re-classification is to give the		o Border Gateway Multicast Protocol (BGMP) [RFC3913],
	readers (both implementors and deployers) an idea what the status of
	a protocol is; there may be legacy deployments of some of these		o Core Based Trees (CBT) [RFC2189] [RFC2201],
	protocols, which are not affected by this reclassification. See
	Section 2.1 for more on each protocol.		o Multicast OSPF (MOSPF) [RFC1584] and [RFC1585].
			For the most part, these protocols have fallen into disuse. There
			may be legacy deployments of some of these protocols, which are not
			affected by this reclassification. See Section 2.1 for more on each
			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
	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
	skipping to change at page 5, line 38		skipping to change at page 5, line 38
	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
	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.
			Certain protocols and configuration needs to be in place before
			multicast routing can work. Specifically, when ASM is employed, a
			router will need to know its RP address(es) (Section 2.4,
			Section 2.5). With IPv4, RPs need to be connected to other RPs using
			MSDP so information about sources connected to other RPs can be
			distributed (Section 2.3). Further, routers need to know if or how
			multicast topology differs from unicast topology, and routing
			protocol extensions can provide that information (Section 2.2).
	When a host wants to receive a transmission, it first needs to find		When a host wants to receive a transmission, it first needs to find
	out the multicast group address (and with SSM, source address) using		out the multicast group address (and with SSM, source address) using
	unspecified means. Then it will signal its interest to its router		unspecified means. Then it will signal its interest to its first-hop
	using IGMP or MLD (Section 2.6). To deliver a multicast		router using IGMP or MLD (Section 2.6). The router initiates setting
	transmission, the router will need to know how to build the		up hop-by-hop multicast forwarding state (Section 2.1) to the source
	distribution tree which includes all the sources (Section 2.3) and/or		(in SSM) or first through the RP (in ASM). Routers use an RP to find
	to locate the RP (Section 2.4) or one of RPs (Section 2.5). In		out all the sources for a group (Section 2.3). When multicast
	scenarios where multicast is routed via different topology than
	unicast, a means to distribute topology information is required
	(Section 2.2). Nonetheless, using whatever topology information is
	available, the first-hop router initiates setting up hop-by-hop
	multicast forwarding state (Section 2.1). 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
	port unless flooding reduction such as IGMP snooping is employed		port unless flooding reduction such as IGMP snooping is employed
	(Section 2.7).		(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. 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
	[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 a
	subset of PIM-SM. Most current routing platforms support PIM-SM.		subset of PIM-SM. Most current routing platforms support PIM-SM. It
			builds a unidirectional, group-specific distribution tree consisting
			of the interested receivers of a group.
	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 7, line 6		skipping to change at page 7, line 12
	used for configured multicast group ranges (such as Auto-RP in		used for configured multicast group ranges (such as Auto-RP in
	Section 2.4.3) only. Lately, many networks have transitioned away		Section 2.4.3) only. Lately, many networks have transitioned away
	from sparse-dense to only sparse mode.		from sparse-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] is a multicast forwarding		Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding
	protocol that establishes a common shared-path for all sources with a		protocol that establishes a common shared-path for all sources with a
	single root. It can be used as an alternative to PIM-SM inside a		single root. It can be used as an alternative to PIM-SM inside a
	single domain. It doesn't have data-driven events or data-		single domain. It doesn't have data-driven events or data-
	encapsulation. As it doesn't keep source-specific state, it may be a		encapsulation. As it doesn't keep source-specific state, it may be
	lucrative approach especially in sites with a large number of		an appealing approach especially in sites with a large number of
	sources.		sources.
	As of this writing, there is no inter-domain solution to configure a		As of this writing, there is no inter-domain solution to configure a
	group range to use bi-directional PIM.		group range to use 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
	skipping to change at page 8, line 34		skipping to change at page 8, line 42
	| Bi-dir PIM | No | Yes | Some uptake |		| Bi-dir PIM | No | Yes | Some uptake |
	| DVMRP | Not anymore | Stub only | Going out |		| DVMRP | Not anymore | Stub only | Going out |
	| MOSPF | No | Not anymore | Inactive |		| MOSPF | 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.
	This is partially result of not working on inter-domain RP/group
	configuration mechanisms since PIM-SM and MSDP (Section 2.3.2).
	2.2. Distributing Topology Information		2.2. Distributing Topology Information
	PIM has become the de-facto multicast forwarding protocol, but as its		PIM has become the de-facto multicast forwarding protocol, but as its
	name implies, it is independent of the underlying unicast routing		name implies, it is independent of the underlying unicast routing
	protocol. When unicast and multicast topologies are the same		protocol. When unicast and multicast topologies are the same
	("congruent"), i.e., use the same routing tables (routing information		("congruent"), i.e., use the same routing tables (routing information
	base, RIB), it has been considered sufficient just to distribute one		base, RIB), it has been considered sufficient just to distribute one
	set of reachability information to be used in conjunction with a		set of reachability information to be used in conjunction with a
	protocol that sets up multicast forwarding state (e.g., PIM-SM).		protocol that sets up multicast forwarding state (e.g., PIM-SM).
	skipping to change at page 9, line 37		skipping to change at page 9, line 44
	A number of significant multicast transit providers even require		A number of significant multicast transit providers even require
	this, by doing the RPF lookups solely based on explicitly advertised		this, by doing the RPF lookups solely based on explicitly advertised
	multicast address family.		multicast address 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 topologies, for example IS-IS multi-topology extensions		a differing topologies, for example IS-IS multi-topology extensions
	[I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast		[I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast
	topology that differs from unicast. Similar but not so widely		topology that differs from unicast. Similar but not so widely
	implemented work exists for OSPF [I-D.ietf-ospf-mt].		implemented work exists for OSPF [RFC4915].
	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 deployment of		intradomain incongruence isn't, so you see much more deployment 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.
	skipping to change at page 10, line 28		skipping to change at page 10, line 35
	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.
	Another implemented approach is to just look up the information in		Another implemented approach is to just look up the information in
	the unicast routing table, and provide the user capabilities to		the unicast routing table, and provide the user capabilities to
	change that as appropriate, using for example copying functions		change that as appropriate, using for example copying functions
	discussed above.		discussed above.
	2.2.4. Summary		2.2.4. Summary
	The following table summarizes the topology distribution approaches		A congruent topology can be deployed using unicast routing protocols
	described in this Section. In particular, it is recommended that if		that provide no support for a separate multicast topology. In intra-
	interdomain routing uses BGP, multicast-enabled sites should use MP-		domain that approach is often adequate. However, it is recommended
	BGP SAFI=2 for multicast and SAFI=1 for unicast even if the topology		that if interdomain routing uses BGP, multicast-enabled sites should
	was congruent.		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".
			The following table summarizes the approaches that can be used to
			distribute multicast topology information.
	+-------------+---------------+		+-------------+---------------+
	| Interdomain | Intradomain |		| Interdomain | Intradomain |
	+--------------------- +--------------+--------------+		+--------------------- +--------------+--------------+
	| Congruent topology | Yes | Yes |
	| BGP without SAFI | Not recomm. | Yes |
	| MP-BGP SAFI=1 only | Not recomm. | Not recomm. |
	| MP-BGP SAFI=2 | Recommended | Yes |		| MP-BGP SAFI=2 | Recommended | 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 | No | Yes |
	| OSPF multi-topology | No | Few implem. |		| OSPF multi-topology | No | Few implem. |
	+----------------------+--------------+--------------+		+----------------------+--------------+--------------+
	2.3. Learning (Active) Sources		2.3. Learning (Active) Sources
	Typically, multicast routing protocols must either assume that the		To build a multicast distribution tree, the routing protocol needs to
	receivers know the IP addresses of the (active) sources for a group		find out where the sources for the group are. In case of SSM, the
	in advance, possibly using an out-of-band mechanism (SSM), or the		user specifies the source IP address or it is otherwise learned out
	transmissions are forwarded to the receivers automatically (ASM).		of band. In ASM, RPs are used to find out the sources (which in turn
			requires a mechanism to find the RPs as discussed in Section 2.4).
	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 model		PIM-SM domain for the whole Internet is a completely unscalable model
	for many reasons. Therefore it is required to be able to split up		for many reasons. Therefore it is required to be able to split up
	the multicast routing infrastructures to smaller domains, and there		the multicast routing infrastructures to smaller domains, and there
	must be a way to share information about active sources using some		must be a way to share information about active sources using 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.
	skipping to change at page 11, line 43		skipping to change at page 12, line 4
	(and RPs) were needed in the network, and information about the		(and RPs) were needed in the network, and information about the
	active sources needed to be propagated between the PIM-SM domains		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]. The		RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The
	same can be achieved using PIM extensions [RFC4610]. See Section 2.5		same can be achieved using PIM extensions [RFC4610]. See Section 2.5
	for more information.		for more information.
	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 [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 address for a particular		The model works by defining a single RP address for a particular
	group for all of the Internet, so there is no need to share state		group for all of the Internet, so there is no need to share state
	skipping to change at page 14, line 34		skipping to change at page 14, line 46
	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.
	Recent PIM extensions [RFC4610] also provide this functionality. In		Recent PIM extensions [RFC4610] also provide this functionality. In
	contrast to MSDP, this approach works for both IPv4 and IPv6.		contrast to MSDP, this approach works for both IPv4 and 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		While Anycast RP shares state between RPs so that RP failure causes
	redundancy as Anycast RP, without sharing state between the RPs. A		only small disturbance, stateless approaches are also possible with a
	traditional mechanism has been to use Auto-RP or BSR (see		more limited resiliency. A traditional mechanism has been to use
	Section 2.4.3) to select another RP when the active one failed.		Auto-RP or BSR (see Section 2.4.3) to select another RP when the
	However, the same functionality could be achieved using a shared-		active one failed. However, the same functionality could be achieved
	unicast RP address ("anycast RP without state sharing") without the		using a shared-unicast RP address ("anycast RP without state
	complexity of a dynamic mechanism. Further, Anycast RP offers a		sharing") without the complexity of a dynamic mechanism. Further,
	significantly more extensive failure mitigation strategy, so today		Anycast RP offers a significantly more extensive failure mitigation
	there is actually very little need to use stateless failover		strategy, so today there is actually very little need to use
	mechanisms, especially dynamic ones, for redundancy purposes.		stateless failover mechanisms, especially dynamic ones, for
			redundancy purposes.
	2.5.3. Bi-directional PIM		2.5.3. Bi-directional PIM
	Because bi-directional PIM (see Section 2.1.3) does not switch to		Because bi-directional PIM (see Section 2.1.3) does not switch to
	shortest path tree (SPT), the final multicast tree is may be		shortest path tree (SPT), the final multicast tree is may be
	established faster. On the other hand, PIM-SM or SSM may converge		established faster. On the other hand, PIM-SM or SSM may converge
	more quickly especially in scenarios (e.g., unicast routing change)		more quickly especially in scenarios (e.g., unicast routing change)
	where bi-directional needs to re-do the Designated Forwarder		where bi-directional needs to re-do the Designated Forwarder
	election.		election.
	2.5.4. Summary		2.5.4. Summary
	The following table summarizes the techniques for enhanced		The following table summarizes the techniques for enhanced
	redundancy.		redundancy.
	+------+------+-----------------------+		+------+------+-----------------------+
	| IPv4 | IPv6 | Deployment |		| IPv4 | IPv6 | Deployment |
	+--------------------+------+------+-----------------------+		+--------------------+------+------+-----------------------+
	| Anycast RP w/ MSDP | Yes | No | De-facto approach |		| Anycast RP w/ MSDP | Yes | No | De-facto approach |
	| Anycast RP w/ PIM | Yes | Yes | New, simpler than MSDP|		| Anycast RP w/ PIM | Yes | Yes | Newer approach |
	| Stateless RP fail. | Yes | Yes | Causes disturbance |		| Stateless RP fail. | Yes | Yes | Causes disturbance |
	| Bi-dir PIM | Yes | Yes | Deployed at some sites|		| Bi-dir PIM | Yes | Yes | Deployed at some sites|
	+-------------+------+------+------------------------------+		+-------------+------+------+------------------------------+
	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.
	skipping to change at page 18, line 25		skipping to change at page 18, line 40
	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
	Chisholm, John Zwiebel, Dan Romascanu, and Thomas Morin provided good		Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, and Ron Bonica
	comments, helping in improving this document.		provided good comments, helping in improving this document.
	4. IANA Considerations		4. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	5. Security Considerations		5. Security Considerations
	This memo only describes different approaches to multicast routing,		This memo only describes different approaches to multicast routing,
	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 [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and		infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and
	PIM last-hop issues [I-D.ietf-pim-lasthop-threats].		PIM last-hop issues [I-D.ietf-pim-lasthop-threats].
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-ospf-mt]
	Psenak, P., "Multi-Topology (MT) Routing in OSPF",
	draft-ietf-ospf-mt-08 (work in progress), January 2007.
	[I-D.ietf-pim-bidir]		[I-D.ietf-pim-bidir]
	Handley, M., "Bi-directional Protocol Independent		Handley, M., "Bi-directional Protocol Independent
	Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in		Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in
	progress), February 2007.		progress), February 2007.
	[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.
	[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
	skipping to change at page 19, line 38		skipping to change at page 20, line 5
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for		[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
	IP", RFC 4607, August 2006.		IP", RFC 4607, August 2006.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760,
	January 2007.		January 2007.
			[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
			Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
			RFC 4915, June 2007.
	6.2. Informative References		6.2. Informative References
	[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol",		[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol",
	<http://www.ieee802.org/1/pages/802.1ak.html>.		<http://www.ieee802.org/1/pages/802.1ak.html>.
	[CGMP] "Cisco Group Management Protocol",		[CGMP] "Cisco Group Management Protocol",
	<http://www.javvin.com/protocolCGMP.html>.		<http://www.javvin.com/protocolCGMP.html>.
	[GMRP] "GARP Multicast Registration Protocol",		[GMRP] "GARP Multicast Registration Protocol",
	<http://www.javvin.com/protocolGMRP.html>.		<http://www.javvin.com/protocolGMRP.html>.
	skipping to change at page 20, line 39		skipping to change at page 21, line 10
	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, "Last-hop Threats to Protocol
	Independent Multicast (PIM)",		Independent Multicast (PIM)",
	draft-ietf-pim-lasthop-threats-00 (work in progress),		draft-ietf-pim-lasthop-threats-01 (work in progress),
	October 2006.		June 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-10 (work in progress),		draft-ietf-pim-sm-bsr-11 (work in progress), July 2007.
	February 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.
	[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap		[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap
	Analysis from the MBONED Working Group for the IESG		Analysis from the MBONED Working Group for the IESG
	[Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work		[Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work
	in progress), July 2002.		in progress), July 2002.
End of changes. 35 change blocks.
	95 lines changed or deleted		104 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/