draft-ietf-mboned-routingarch-09.txt		draft-ietf-mboned-routingarch-10.txt
	Internet Engineering Task Force P. Savola		Internet Engineering Task Force P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Obsoletes: August 3, 2007		Obsoletes: September 25, 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: February 4, 2008		Expires: March 28, 2008
	Overview of the Internet Multicast Routing Architecture		Overview of the Internet Multicast Routing Architecture
	draft-ietf-mboned-routingarch-09.txt		draft-ietf-mboned-routingarch-10.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 February 4, 2008.		This Internet-Draft will expire on March 28, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes multicast routing architectures that are		This document describes multicast routing architectures that are
	currently deployed on the Internet. This document briefly describes		currently deployed on the Internet. This document briefly describes
	those protocols and references their specifications.		those protocols and references their specifications.
	skipping to change at page 2, line 40		skipping to change at page 2, line 40
	2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12		2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12
	2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12		2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12
	2.4. Configuring and Distributing PIM RP Information . . . . . 12		2.4. Configuring and Distributing PIM RP Information . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 14		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 . . . . . . . . . . . . . . . . 15
	2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15		2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15
	2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15		2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
	2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15		2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15
	2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15		2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15
	2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16		2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16
	2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16		2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16
	2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16		2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16
	2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17		2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17
	2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17		2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17
	2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18		2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18
	3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 19		5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 19		6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	6.2. Informative References . . . . . . . . . . . . . . . . . . 20		6.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A. Multicast Payload Transport Extensions . . . . . . . 23		Appendix A. Multicast Payload Transport Extensions . . . . . . . 23
	A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23		A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 24
	A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23		A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 24
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . . . 25
	1. Introduction		1. Introduction
	This document provides a brief overview of multicast routing		This document provides a brief overview of multicast routing
	architectures that are currently deployed on the Internet and how		architectures that are currently deployed on the Internet and how
	those protocols fit together. It also describes those multicast		those protocols fit together. It also describes those multicast
	routing protocols that were never widely deployed or have fallen into		routing protocols that were never widely deployed or have fallen into
	disuse. A companion document [I-D.ietf-mboned-addrarch] describes		disuse. A companion document [I-D.ietf-mboned-addrarch] describes
	multicast addressing architectures.		multicast addressing architectures.
	Specifically, 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 rendezvous point (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
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto.		MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto.
	MOSPF Multicast OSPF		MOSPF Multicast OSPF
	MSDP Multicast Source Discovery Protocol		MSDP Multicast Source Discovery Protocol
	PGM Pragmatic General Multicast		PGM Pragmatic General Multicast
	PIM Protocol Independent Multicast		PIM Protocol Independent Multicast
	PIM-DM PIM - Dense Mode		PIM-DM PIM - Dense Mode
	PIM-SM PIM - Sparse Mode		PIM-SM PIM - Sparse Mode
	PIM-SSM PIM - Source-Specific Multicast		PIM-SSM PIM - Source-Specific Multicast
	RGMP (Cisco's) Router Group Management Protocol		RGMP (Cisco's) Router Group Management Protocol
	RP Rendezvous Point		RP Rendezvous Point
			SAFI Subsequent Address Family Identifier
			SDP Session Description Protocol
	SSM Source-specific Multicast		SSM Source-specific Multicast
	2. Multicast Routing		2. Multicast Routing
	In order to give a simplified summary how each of these class of		In order to give a simplified summary how each of these class of
	mechanisms fits together, consider the following multicast receiver		mechanisms fits together, consider the following multicast receiver
	scenario.		scenario.
	Certain protocols and configuration needs to be in place before		Certain protocols and configuration needs to be in place before
	multicast routing can work. Specifically, when ASM is employed, a		multicast routing can work. Specifically, when ASM is employed, a
	router will need to know its RP address(es) (Section 2.4,		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		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		MSDP so information about sources connected to other RPs can be
	distributed (Section 2.3). Further, routers need to know if or how		distributed (Section 2.3). Further, routers need to know if or how
	multicast topology differs from unicast topology, and routing		multicast topology differs from unicast topology, and routing
	protocol extensions can provide that information (Section 2.2).		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 first-hop		various means (e.g., SDP description file [RFC4566] or manually).
	router using IGMP or MLD (Section 2.6). The router initiates setting
	up hop-by-hop multicast forwarding state (Section 2.1) to the source		Then it will signal its interest to its first-hop router using IGMP
	(in SSM) or first through the RP (in ASM). Routers use an RP to find		(IPv4) or MLD (IPv6) (Section 2.6). The router initiates setting up
	out all the sources for a group (Section 2.3). When multicast		hop-by-hop multicast forwarding state (Section 2.1) to the source (in
			SSM) or first through the RP (in ASM). Routers use an RP to find out
			all the sources for a group (Section 2.3). When multicast
	transmission arrives at the receiver's LAN, it is flooded to every		transmission arrives at the receiver's LAN, it is flooded to every
	port unless flooding reduction such as IGMP snooping is employed		Ethernet switch port unless flooding reduction such as IGMP snooping
	(Section 2.7).		is employed (Section 2.7).
	2.1. Setting up Multicast Forwarding State		2.1. Setting up Multicast Forwarding State
	The most important part of multicast routing is setting up the		The most important part of multicast routing is setting up the
	multicast forwarding state. This section describes the protocols		multicast forwarding state. 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
	skipping to change at page 6, line 36		skipping to change at page 6, line 40
	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.
	PIM-DM may be an acceptable fit in small and/or simple networks,		PIM-DM may be an acceptable fit in small and/or simple networks,
	where setting up an RP would be unnecessary, and possibly in cases		where setting up an RP would be unnecessary, and possibly in cases
	where a large percentage of users is expected to want to receive the		where a large percentage of users are expected to want to receive the
	transmission so that the amount of state the network has to keep is		transmission so that the amount of state the network has to keep is
	minimal.		minimal.
	PIM-DM was used as a first step in transitioning away from DVMRP. It		PIM-DM was used as a first step in transitioning away from DVMRP. It
	also became apparent that most networks would not have receivers for		also became apparent that most networks would not have receivers for
	most groups, and to avoid the bandwidth and state overhead, the		most groups, and to avoid the bandwidth and state overhead, the
	flooding paradigm was gradually abandoned. Transitioning from PIM-DM		flooding paradigm was gradually abandoned. Transitioning from PIM-DM
	to PIM-SM was easy as PIM-SM was designed to use compatible packet		to PIM-SM was easy as PIM-SM was designed to use compatible packet
	formats and dense-mode operation could also be satisfied by a sparse		formats and dense-mode operation could also be satisfied by a sparse
	protocol. PIM-DM is no longer in widespread use.		protocol. PIM-DM is no longer in widespread use.
	skipping to change at page 7, line 23		skipping to change at page 7, line 26
	an appealing 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. To get around initial deployment
	deployment hurdles. It also included tunneling capabilities which		hurdles, it also included tunneling capabilities which were part of
	were part of its multicast topology functions.		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, Generic Routing
	[RFC2784] seems to have overtaken DVMRP in this functionality, and		Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP
	there is relatively little use for DVMRP except in legacy		in this functionality, and there is relatively little use for DVMRP
	deployments.		except in legacy 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 is based on		deployment in intra-domain networks. However, since it is based on
	intra-domain OSPF it does not scale to the inter-domain case,		intra-domain Open Shortest Path First (OSPF) it does not scale to the
	operators have found it is easier to deploy a single protocol for use		inter-domain case, operators have found it is easier to deploy a
	in both intra-domain and inter-domain networks and so it is no longer		single protocol for use in both intra-domain and inter-domain
	being actively deployed.		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
	skipping to change at page 9, line 40		skipping to change at page 9, line 41
	distribute unicast topology information. Multicast-enabled networks		distribute unicast topology information. Multicast-enabled networks
	that use BGP should use Multiprotocol BGP to distribute multicast		that use BGP should use Multiprotocol BGP to distribute multicast
	reachability information explicitly even if the topologies are		reachability information explicitly even if the topologies are
	congruent to make an explicit statement about multicast reachability.		congruent to make an explicit statement about multicast reachability.
	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 Interior Gateway Protocols (IGPs) also provide
	a differing topologies, for example IS-IS multi-topology extensions		the capability for signalling differing topologies, for example IS-IS
	[I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast		multi-topology extensions [I-D.ietf-isis-wg-multi-topology]. These
	topology that differs from unicast. Similar but not so widely		can be used for a multicast topology that differs from unicast.
	implemented work exists for OSPF [RFC4915].		Similar but not so widely 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 12, line 16		skipping to change at page 12, line 23
	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
	about that with any other RPs. If necessary, RP redundancy can still		about that with any other RPs. If necessary, RP redundancy can still
	be achieved with Anycast-RP using PIM.		be achieved with Anycast-RP using PIM [RFC4610].
	2.3.4. Summary		2.3.4. Summary
	The following table summarizes the source discovery approaches and		The following table summarizes the source discovery approaches and
	their status.		their status.
	+------+------+------------------------------+		+------+------+------------------------------+
	| IPv4 | IPv6 | Status |		| IPv4 | IPv6 | Status |
	+----------------------+------+------+------------------------------+		+----------------------+------+------+------------------------------+
	| Bi-dir single domain | Yes | Yes | OK but for intra-domain only |		| Bi-dir single domain | Yes | Yes | OK but for intra-domain only |
	| PIM-SM single domain | Yes | Yes | OK |		| PIM-SM single domain | Yes | Yes | OK |
	| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |		| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
	| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |		| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
	| SSM | Yes | Yes | No major uptake yet |		| SSM | Yes | Yes | No major uptake yet |
	+----------------------+------+------+------------------------------+		+----------------------+------+------+------------------------------+
	2.4. Configuring and Distributing PIM RP Information		2.4. Configuring and Distributing PIM RP Information
	PIM-SM and Bi-dir PIM configuration mechanisms exist which are used		PIM-SM and Bi-dir PIM configuration mechanisms exist which are used
	to configure the RP addresses and which groups are to use those RPs		to configure the RP addresses and the groups that are to use those
	in the routers. This section outlines the approaches.		RPs in the routers. This section outlines the approaches.
	2.4.1. Manual RP Configuration		2.4.1. Manual RP Configuration
	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 changes every time the RP address		required explicit configuration changes 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
	skipping to change at page 14, line 28		skipping to change at page 14, line 33
	| IPv4 | IPv6 | Deployment |		| IPv4 | IPv6 | Deployment |
	+--------------------+------+------+-----------------------+		+--------------------+------+------+-----------------------+
	| Static RP | Yes | Yes | Especially in ISPs |		| Static RP | Yes | Yes | Especially in ISPs |
	| Auto-RP | Yes | No | Legacy deployment |		| Auto-RP | Yes | No | Legacy deployment |
	| BSR | Yes | Yes | Some, anycast simpler |		| BSR | Yes | Yes | Some, anycast simpler |
	| Embedded-RP | No | Yes | Growing |		| Embedded-RP | No | Yes | Growing |
	+--------------------+------+------+-----------------------+		+--------------------+------+------+-----------------------+
	2.5. Mechanisms for Enhanced Redundancy		2.5. Mechanisms for Enhanced Redundancy
	A couple of mechanisms, already described in this document, have been		Having only one RP in a PIM-SM domain would be a single point of
	used as a means to enhance redundancy, resilience against failures,		failure for the whole multicast domain. As a result, a number of
	and to recover from failures quickly. This section summarizes these		mechanisms have been developed to either eliminate the RP
	techniques explicitly.		functionality or to enhance RPs' redundancy, resilience against
			failures, and to recover from failures quickly. This section
			summarizes these 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.
	Recent PIM extensions [RFC4610] also provide this functionality. In		Recent PIM extensions [RFC4610] also provide this functionality. In
	skipping to change at page 15, line 12		skipping to change at page 15, line 22
	using a shared-unicast RP address ("anycast RP without state		using a shared-unicast RP address ("anycast RP without state
	sharing") without the complexity of a dynamic mechanism. Further,		sharing") without the complexity of a dynamic mechanism. Further,
	Anycast RP offers a significantly more extensive failure mitigation		Anycast RP offers a significantly more extensive failure mitigation
	strategy, so today there is actually very little need to use		strategy, so today there is actually very little need to use
	stateless failover mechanisms, especially dynamic ones, for		stateless failover mechanisms, especially dynamic ones, for
	redundancy purposes.		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 may be established
	established faster. On the other hand, PIM-SM or SSM may converge		faster. On the other hand, PIM-SM or SSM may converge more quickly
	more quickly especially in scenarios (e.g., unicast routing change)		especially in scenarios (e.g., unicast routing change) where bi-
	where bi-directional needs to re-do the Designated Forwarder		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 |
	skipping to change at page 15, line 44		skipping to change at page 16, line 4
	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
	After choosing a multicast group through a variety of means, hosts		After choosing a multicast group through a variety of means, hosts
	just send the packets to the link-layer multicast address, and the		just send the packets to the link-layer multicast address, and the
	designated router will receive all the multicast packets and start		designated router will receive all the multicast packets and start
	forwarding them as appropriate.		forwarding them as appropriate. A host does not need to be a member
			of the group in order to send to it [RFC1112].
	In intra-domain or Embedded-RP scenarios, ASM senders may move to a		In intra-domain or Embedded-RP scenarios, ASM senders may move to a
	new IP address without significant impact on the delivery of their		new IP address without significant impact on the delivery of their
	transmission. SSM senders cannot change the IP address unless		transmission. SSM senders cannot change the IP address unless
	receivers join the new channel or the sender uses an IP mobility		receivers join the new channel or the sender uses an IP mobility
	technique that is transparent to the receivers.		technique that is transparent to the receivers.
	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
	skipping to change at page 18, line 40		skipping to change at page 18, line 46
	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, Thomas Morin, and Ron Bonica		Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, and
	provided good comments, helping in improving this document.		Prashant Jhingran provided good comments, helping in improving this
			document.
	4. IANA Considerations		4. IANA Considerations
	This memo includes no request to IANA.		IANA is requested to update the following registries by adding a
			reference to this document:
			o OSPFv2 Option registry: MC-bit
			o OSPFv2 Link state type: Group-membership-LSA
			o OSPFv2 Router properties registry: W-bit (0x08)
			o OSPFv3 Option registry: MC-bit
			o OSPFv3 LSA function code registry: Group-membership-LSA
			o OSPFv3 Prefix Options Registry: MC-bit
			(To be removed prior to publication as an RFC: IANA is also requested
			to correct a typo in OSPFv2 Router properties registry: The first
			W-bit (0x02) entry should be renamed to 'E-bit' as described in RFC
			2328 section A.4.2.)
	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].
	skipping to change at page 21, line 15		skipping to change at page 21, line 38
	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-01 (work in progress),		draft-ietf-pim-lasthop-threats-01 (work in progress),
	June 2007.		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-11 (work in progress), July 2007.		draft-ietf-pim-sm-bsr-12 (work in progress), August 2007.
	[I-D.lehtonen-mboned-dynssm-req]		[I-D.lehtonen-mboned-dynssm-req]
	Lehtonen, R., "Requirements for discovery of dynamic SSM		Lehtonen, R., "Requirements for discovery of dynamic SSM
	sources", draft-lehtonen-mboned-dynssm-req-00 (work in		sources", draft-lehtonen-mboned-dynssm-req-00 (work in
	progress), February 2005.		progress), February 2005.
	[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.
	skipping to change at page 21, line 37		skipping to change at page 22, line 11
	[IMRP-ISSUES]		[IMRP-ISSUES]
	Meyer, D., "Some Issues for an Inter-domain Multicast		Meyer, D., "Some Issues for an Inter-domain Multicast
	Routing Protocol [Expired]",		Routing Protocol [Expired]",
	draft-ietf-mboned-imrp-some-issues-01 (work in progress),		draft-ietf-mboned-imrp-some-issues-01 (work in progress),
	September 1997.		September 1997.
	[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.
			[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
			RFC 1112, August 1989.
	[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast		[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast
	Protocols", RFC 1458, May 1993.		Protocols", RFC 1458, May 1993.
	[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,		[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
	March 1994.		March 1994.
	[RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585,		[RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585,
	March 1994.		March 1994.
	[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast		[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast
	skipping to change at page 22, line 44		skipping to change at page 23, line 21
	Specification (Revised)", RFC 3973, January 2005.		Specification (Revised)", RFC 3973, January 2005.
	[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",		[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
	RFC 4286, December 2005.		RFC 4286, December 2005.
	[RFC4541] Christensen, M., Kimball, K., and F. Solensky,		[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
	"Considerations for Internet Group Management Protocol		"Considerations for Internet Group Management Protocol
	(IGMP) and Multicast Listener Discovery (MLD) Snooping		(IGMP) and Multicast Listener Discovery (MLD) Snooping
	Switches", RFC 4541, May 2006.		Switches", RFC 4541, May 2006.
			[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
			Description Protocol", RFC 4566, July 2006.
	[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,		[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
	"Internet Group Management Protocol (IGMP) / Multicast		"Internet Group Management Protocol (IGMP) / Multicast
	Listener Discovery (MLD)-Based Multicast Forwarding		Listener Discovery (MLD)-Based Multicast Forwarding
	("IGMP/MLD Proxying")", RFC 4605, August 2006.		("IGMP/MLD Proxying")", RFC 4605, August 2006.
	[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol		[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
	Independent Multicast - Sparse Mode (PIM-SM) Multicast		Independent Multicast - Sparse Mode (PIM-SM) Multicast
	Routing Security Issues and Enhancements", RFC 4609,		Routing Security Issues and Enhancements", RFC 4609,
	October 2006.		October 2006.
End of changes. 26 change blocks.
	52 lines changed or deleted		84 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/