draft-ietf-mboned-auto-multicast-06.txt		draft-ietf-mboned-auto-multicast-07.txt
	Network Working Group D. Thaler		Network Working Group D. Thaler
	Internet-Draft M. Talwar		Internet-Draft M. Talwar
	Expires: December 22, 2006 A. Aggarwal		Expires: May 20, 2007 A. Aggarwal
	Microsoft Corporation		Microsoft Corporation
	L. Vicisano		L. Vicisano
	Cisco Systems		Cisco Systems
	T. Pusateri		T. Pusateri
	!j		!j
	June 20, 2006		November 16, 2006
	Automatic IP Multicast Without Explicit Tunnels (AMT)		Automatic IP Multicast Without Explicit Tunnels (AMT)
	draft-ietf-mboned-auto-multicast-06		draft-ietf-mboned-auto-multicast-07
	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 39		skipping to change at page 1, line 39
	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 22, 2006.		This Internet-Draft will expire on May 20, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	Automatic Multicast Tunneling (AMT) allows multicast communication		Automatic Multicast Tunneling (AMT) allows multicast communication
	amongst isolated multicast-enabled sites or hosts, attached to a		amongst isolated multicast-enabled sites or hosts, attached to a
	network which has no native multicast support. It also enables them		network which has no native multicast support. It also enables them
	skipping to change at page 3, line 14		skipping to change at page 3, line 14
	6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19		6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19
	6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19		6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19
	6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20		6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20
	6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20		6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20		6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20
	6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20		6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20
	6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21		6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21
	6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21		6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21
	6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21		6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21
	6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21		6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22		6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 21
	6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22		6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22
	7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23		7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23
	7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23		7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23
	7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23		7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23
	7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24		7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24		7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24		7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24
	7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25		7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25
	7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26		7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26
	7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26		7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26
	skipping to change at page 5, line 18		skipping to change at page 5, line 18
	configured multicast tunnel for high traffic flow. Unicast		configured multicast tunnel for high traffic flow. Unicast
	replication is required to reach multiple receivers that are not part		replication is required to reach multiple receivers that are not part
	of the native multicast infrastructure. Unicast replication is also		of the native multicast infrastructure. Unicast replication is also
	required by non-native sources to different parts of the native		required by non-native sources to different parts of the native
	multicast infrastructure. However, this is no worse than regular		multicast infrastructure. However, this is no worse than regular
	unicast distribution of streams and in most cases much better.		unicast distribution of streams and in most cases much better.
	The following problems are addressed:		The following problems are addressed:
	1. Allowing isolated sites/hosts to receive the SSM flavor of		1. Allowing isolated sites/hosts to receive the SSM flavor of
	multicast ([I-D.ietf-ssm-arch]).		multicast ([RFC4607]).
	2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor		2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor
	of multicast.		of multicast.
	3. Allowing isolated sites/hosts to receive general multicast (ASM		3. Allowing isolated sites/hosts to receive general multicast (ASM
	[RFC1112]).		[RFC1112]).
	This document does not address allowing isolated sites/hosts to		This document does not address allowing isolated sites/hosts to
	transmit general multicast. We expect that other solutions (e.g.,		transmit general multicast. We expect that other solutions (e.g.,
	Tunnel Brokers, a la [RFC3053]) will be used for sites that desire		Tunnel Brokers, a la [RFC3053]) will be used for sites that desire
	skipping to change at page 9, line 52		skipping to change at page 9, line 52
	Each relay, plus the set of all gateways using the relay, together		Each relay, plus the set of all gateways using the relay, together
	are thought of as being on a separate logical NBMA link. This		are thought of as being on a separate logical NBMA link. This
	implies that the AMT recipient-list is a list of "link layer"		implies that the AMT recipient-list is a list of "link layer"
	addresses which are (IP address, UDP port) pairs.		addresses which are (IP address, UDP port) pairs.
	Since the number of gateways using a relay can be quite large, and we		Since the number of gateways using a relay can be quite large, and we
	expect that most sites will not want to receive most groups, an		expect that most sites will not want to receive most groups, an
	explicit-joining protocol is required for gateways to communicate		explicit-joining protocol is required for gateways to communicate
	group membership information to a relay. The two most likely		group membership information to a relay. The two most likely
	candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the		candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the
	PIM-Sparse Mode protocol [I-D.ietf-pim-sm-v2-new]. Since an AMT		PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a
	gateway may be a host, and hosts typically do not implement routing		host, and hosts typically do not implement routing protocols,
	protocols, gateways will use IGMP/MLD as described in Section 7		gateways will use IGMP/MLD as described in Section 7 below. This
	below. This allows a host kernel (or a pseudo device driver) to		allows a host kernel (or a pseudo device driver) to easily implement
	easily implement AMT gateway behavior, and obviates the relay from		AMT gateway behavior, and obviates the relay from the need to know
	the need to know whether a given gateway is a host or a router. From		whether a given gateway is a host or a router. From the relay's
	the relay's perspective, all gateways are indistinguishable from		perspective, all gateways are indistinguishable from hosts on an NBMA
	hosts on an NBMA leaf network.		leaf network.
	5.1.1. Scalability Considerations		5.1.1. Scalability Considerations
	It is possible that millions of hosts will enable AMT gateway		It is possible that millions of hosts will enable AMT gateway
	functionality and so an important design goal is not to create		functionality and so an important design goal is not to create
	gateway state in each relay until the gateway joins a multicast		gateway state in each relay until the gateway joins a multicast
	group. But even the requirement that a relay keep group state per		group. But even the requirement that a relay keep group state per
	gateway that has joined a group introduces potential scalability		gateway that has joined a group introduces potential scalability
	concerns.		concerns.
	skipping to change at page 14, line 14		skipping to change at page 14, line 14
	per relay from which membership reports have been sent, and forward		per relay from which membership reports have been sent, and forward
	multicast traffic from the site to all relays from which membership		multicast traffic from the site to all relays from which membership
	reports have been received. The choice of whether this state and		reports have been received. The choice of whether this state and
	replication is done at the link-layer (i.e., by the tunnel interface)		replication is done at the link-layer (i.e., by the tunnel interface)
	or at the network-layer is implementation dependent.		or at the network-layer is implementation dependent.
	If there are multiple relays present, this ensures that data from the		If there are multiple relays present, this ensures that data from the
	AMT site is received via the closest relay to the receiver. This is		AMT site is received via the closest relay to the receiver. This is
	necessary when the routers in the native multicast infrastructure		necessary when the routers in the native multicast infrastructure
	employ Reverse-Path Forwarding (RPF) checks against the source		employ Reverse-Path Forwarding (RPF) checks against the source
	address, such as occurs when PIM Sparse-Mode [I-D.ietf-pim-sm-v2-new]		address, such as occurs when PIM Sparse-Mode [RFC4601] is used by the
	is used by the multicast infrastructure.		multicast infrastructure.
	The solution above will scale to an arbitrary number of relays, as		The solution above will scale to an arbitrary number of relays, as
	long at the number of relays requiring multicast traffic from a given		long at the number of relays requiring multicast traffic from a given
	AMT site remains reasonable enough to not overly burden the site's		AMT site remains reasonable enough to not overly burden the site's
	gateway.		gateway.
	A source at or behind an AMT gateway requires the gateway to do the		A source at or behind an AMT gateway requires the gateway to do the
	replication to one or more relays and receiving gateways. If this		replication to one or more relays and receiving gateways. If this
	places too much of a burden on the sourcing gateway, the source		places too much of a burden on the sourcing gateway, the source
	should join the native multicast infrastructure through a permanent		should join the native multicast infrastructure through a permanent
	skipping to change at page 21, line 36		skipping to change at page 21, line 36
	The UDP source and destination port numbers should be the same ones		The UDP source and destination port numbers should be the same ones
	sent in the original Query. The UDP checksum SHOULD be 0 in the AMT		sent in the original Query. The UDP checksum SHOULD be 0 in the AMT
	IP Multicast Data message.		IP Multicast Data message.
	The payload of the UDP packet contains the following fields.		The payload of the UDP packet contains the following fields.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=0x6 | Reserved |		| Type=0x6 | Reserved | IP Multicast Data ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP Multicast Data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fields:		Fields:
	6.6.1. Type		6.6.1. Type
	The type of the message.		The type of the message.
	6.6.2. Reserved		6.6.2. Reserved
	A 24-bit reserved field. Sent as 0, ignored on receipt.		An 8-bit reserved field. Sent as 0, ignored on receipt.
	6.6.3. IP Multicast Data		6.6.3. IP Multicast Data
	The original IP Multicast data packet that is being replicated by the		The original IP Multicast data packet that is being replicated by the
	relay to the gateways including the original IP header.		relay to the gateways including the original IP header.
	7. AMT Gateway Details		7. AMT Gateway Details
	This section details the behavior of an AMT Gateway, which may be a		This section details the behavior of an AMT Gateway, which may be a
	router serving an AMT site, or the site may consist of a single host,		router serving an AMT site, or the site may consist of a single host,
	skipping to change at page 23, line 26		skipping to change at page 23, line 26
	note the unicast address (which is treated as a link-layer address to		note the unicast address (which is treated as a link-layer address to
	the encapsulation interface) from the AMT Relay Advertisement		the encapsulation interface) from the AMT Relay Advertisement
	message. This discovery SHOULD be done periodically (e.g., once a		message. This discovery SHOULD be done periodically (e.g., once a
	day) to re-resolve the unicast address of a close relay. The gateway		day) to re-resolve the unicast address of a close relay. The gateway
	also SHOULD initialize a timer used to send periodic membership		also SHOULD initialize a timer used to send periodic membership
	reports to a random value from the interval [0, [Query Interval]]		reports to a random value from the interval [0, [Query Interval]]
	before sending the first periodic report, in order to prevent startup		before sending the first periodic report, in order to prevent startup
	synchronization (e.g., after a power outage).		synchronization (e.g., after a power outage).
	If the gateway is serving as a local router, it SHOULD also function		If the gateway is serving as a local router, it SHOULD also function
	as an IGMP/MLD Proxy, as described in [I-D.ietf-magma-igmp-proxy],		as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD
	with its IGMP/MLD host-mode interface being the AMT pseudo-interface.		host-mode interface being the AMT pseudo-interface. This enables it
	This enables it to translate group memberships on its downstream		to translate group memberships on its downstream interfaces into
	interfaces into IGMP/MLD Reports. Hosts receiving multicast packets		IGMP/MLD Reports. Hosts receiving multicast packets through an AMT
	through an AMT gateway acting as a proxy should ensure that their		gateway acting as a proxy should ensure that their M-RIB accepts
	M-RIB accepts multicast packets from the AMT gateway for the sources		multicast packets from the AMT gateway for the sources it is joining.
	it is joining.
	7.2. Gateway Group and Source Addresses		7.2. Gateway Group and Source Addresses
	To support sourcing traffic to SSM groups by a gateway with a global		To support sourcing traffic to SSM groups by a gateway with a global
	unicast address, the AMT Subnet Anycast Prefix is treated as the		unicast address, the AMT Subnet Anycast Prefix is treated as the
	subnet prefix of the AMT pseudo-interface, and an anycast address is		subnet prefix of the AMT pseudo-interface, and an anycast address is
	added on the interface. This anycast address is formed by		added on the interface. This anycast address is formed by
	concatenating the AMT Subnet Anycast Prefix followed by the high bits		concatenating the AMT Subnet Anycast Prefix followed by the high bits
	of the gateway's global unicast address.		of the gateway's global unicast address.
	skipping to change at page 34, line 9		skipping to change at page 34, line 9
	Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John		Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John
	Zwiebel, and Lenny Giuliano.		Zwiebel, and Lenny Giuliano.
	Juniper Networks was instrumental in funding several versions of this		Juniper Networks was instrumental in funding several versions of this
	draft as well as an open source implementation.		draft as well as an open source implementation.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-magma-igmp-proxy]
	Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
	MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
	draft-ietf-magma-igmp-proxy-06 (work in progress),
	April 2004.
	[I-D.ietf-ssm-arch]
	Holbrook, H. and B. Cain, "Source-Specific Multicast for
	IP", draft-ietf-ssm-arch-07 (work in progress),
	October 2005.
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, September 1981.		RFC 792, September 1981.
	[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.
	[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.
	13.2. Informative References		[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
			"Internet Group Management Protocol (IGMP) / Multicast
			Listener Discovery (MLD)-Based Multicast Forwarding
			("IGMP/MLD Proxying")", RFC 4605, August 2006.
	[I-D.ietf-pim-sm-v2-new]		[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
	Fenner, B., "Protocol Independent Multicast - Sparse Mode		IP", RFC 4607, August 2006.
	(PIM-SM): Protocol Specification (Revised)",
	draft-ietf-pim-sm-v2-new-12 (work in progress),		13.2. Informative References
	March 2006.
	[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,		[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
	RFC 1112, August 1989.		RFC 1112, August 1989.
	[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host		[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
	Anycasting Service", RFC 1546, November 1993.		Anycasting Service", RFC 1546, November 1993.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	February 1997.		February 1997.
	skipping to change at page 36, line 5		skipping to change at page 35, line 5
	[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6		[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
	Tunnel Broker", RFC 3053, January 2001.		Tunnel Broker", RFC 3053, January 2001.
	[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains		[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
	via IPv4 Clouds", RFC 3056, February 2001.		via IPv4 Clouds", RFC 3056, February 2001.
	[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",		[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
	RFC 3068, June 2001.		RFC 3068, June 2001.
			[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
			"Protocol Independent Multicast - Sparse Mode (PIM-SM):
			Protocol Specification (Revised)", RFC 4601, August 2006.
	Authors' Addresses		Authors' Addresses
	Dave Thaler		Dave Thaler
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	USA		USA
	Phone: +1 425 703 8835		Phone: +1 425 703 8835
	Email: dthaler@microsoft.com		Email: dthaler@microsoft.com
End of changes. 15 change blocks.
	44 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/