draft-ietf-mboned-dc-deploy-01.txt		draft-ietf-mboned-dc-deploy-02.txt
	Internet Engineering Task Force M. McBride
	Internet-Draft Huawei Technologies		MBONED M. McBride
	Intended status: Informational August 23, 2013		Internet-Draft Huawei
	Expires: February 24, 2014		Intended status: Informational February 28, 2018
			Expires: September 1, 2018
	Multicast in the Data Center Overview		Multicast in the Data Center Overview
	draft-ietf-mboned-dc-deploy-01		draft-ietf-mboned-dc-deploy-02
	Abstract		Abstract
	There has been much interest in issues surrounding massive amounts of		There has been much interest in issues surrounding massive amounts of
	hosts in the data center. These issues include the prevalent use of		hosts in the data center. These issues include the prevalent use of
	IP Multicast within the Data Center. Its important to understand how		IP Multicast within the Data Center. Its important to understand how
	IP Multicast is being deployed in the Data Center to be able to		IP Multicast is being deployed in the Data Center to be able to
	understand the surrounding issues with doing so. This document		understand the surrounding issues with doing so. This document
	provides a quick survey of uses of multicast in the data center and		provides a quick survey of uses of multicast in the data center and
	should serve as an aid to further discussion of issues related to		should serve as an aid to further discussion of issues related to
	large amounts of multicast in the data center.		large amounts of multicast in the data center.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on February 24, 2014.		This Internet-Draft will expire on September 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Multicast Applications in the Data Center . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2.1. Client-Server Applications . . . . . . . . . . . . . . . . 3		2. Multicast Applications in the Data Center . . . . . . . . . . 3
	2.2. Non Client-Server Multicast Applications . . . . . . . . . 4		2.1. Client-Server Applications . . . . . . . . . . . . . . . 3
	3. L2 Multicast Protocols in the Data Center . . . . . . . . . . 6		2.2. Non Client-Server Multicast Applications . . . . . . . . 4
	4. L3 Multicast Protocols in the Data Center . . . . . . . . . . 7		3. L2 Multicast Protocols in the Data Center . . . . . . . . . . 5
	5. Challenges of using multicast in the Data Center . . . . . . . 7		4. L3 Multicast Protocols in the Data Center . . . . . . . . . . 6
	6. Layer 3 / Layer 2 Topological Variations . . . . . . . . . . . 9		5. Challenges of using multicast in the Data Center . . . . . . 7
	7. Address Resolution . . . . . . . . . . . . . . . . . . . . . . 9		6. Layer 3 / Layer 2 Topological Variations . . . . . . . . . . 8
			7. Address Resolution . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Solicited-node Multicast Addresses for IPv6 address		7.1. Solicited-node Multicast Addresses for IPv6 address
	resolution . . . . . . . . . . . . . . . . . . . . . . . . 9		resolution . . . . . . . . . . . . . . . . . . . . . . . 9
	7.2. Direct Mapping for Multicast address resolution . . . . . 9		7.2. Direct Mapping for Multicast address resolution . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	11. Informative References . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
			11.2. Informative References . . . . . . . . . . . . . . . . . 10
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Data center servers often use IP Multicast to send data to clients or		Data center servers often use IP Multicast to send data to clients or
	other application servers. IP Multicast is expected to help conserve		other application servers. IP Multicast is expected to help conserve
	bandwidth in the data center and reduce the load on servers. IP		bandwidth in the data center and reduce the load on servers. IP
	Multicast is also a key component in several data center overlay		Multicast is also a key component in several data center overlay
	solutions. Increased reliance on multicast, in next generation data		solutions. Increased reliance on multicast, in next generation data
	centers, requires higher performance and capacity especially from the		centers, requires higher performance and capacity especially from the
	switches. If multicast is to continue to be used in the data center,		switches. If multicast is to continue to be used in the data center,
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 5 ¶
	much interest in issues surrounding massive amounts of hosts in the		much interest in issues surrounding massive amounts of hosts in the
	data center. There was a lengthy discussion, in the now closed ARMD		data center. There was a lengthy discussion, in the now closed ARMD
	WG, involving the issues with address resolution for non ARP/ND		WG, involving the issues with address resolution for non ARP/ND
	multicast traffic in data centers. This document provides a quick		multicast traffic in data centers. This document provides a quick
	survey of multicast in the data center and should serve as an aid to		survey of multicast in the data center and should serve as an aid to
	further discussion of issues related to multicast in the data center.		further discussion of issues related to multicast in the data center.
	ARP/ND issues are not addressed in this document except to explain		ARP/ND issues are not addressed in this document except to explain
	how address resolution occurs with multicast.		how address resolution occurs with multicast.
			1.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119.
	2. Multicast Applications in the Data Center		2. Multicast Applications in the Data Center
	There are many data center operators who do not deploy Multicast in		There are many data center operators who do not deploy Multicast in
	their networks for scalability and stability reasons. There are also		their networks for scalability and stability reasons. There are also
	many operators for whom multicast is a critical protocol within their		many operators for whom multicast is a critical protocol within their
	network and is enabled on their data center switches and routers.		network and is enabled on their data center switches and routers.
	For this latter group, there are several uses of multicast in their		For this latter group, there are several uses of multicast in their
	data centers. An understanding of the uses of that multicast is		data centers. An understanding of the uses of that multicast is
	important in order to properly support these applications in the ever		important in order to properly support these applications in the ever
	evolving data centers. If, for instance, the majority of the		evolving data centers. If, for instance, the majority of the
	skipping to change at page 9, line 15 ¶		skipping to change at page 8, line 47 ¶
	Router (FHR). The IGMP-Snooping Switch will forward multicast		Router (FHR). The IGMP-Snooping Switch will forward multicast
	streams to router ports, and the PIM FHR must receive all multicast		streams to router ports, and the PIM FHR must receive all multicast
	streams even if there is no request from receiver. This often leads		streams even if there is no request from receiver. This often leads
	to waste of switch cache and link bandwidth when the multicast		to waste of switch cache and link bandwidth when the multicast
	streams are not actually required. [I-D.pim-umf-problem-statement]		streams are not actually required. [I-D.pim-umf-problem-statement]
	details the problem and defines design goals for a generic mechanism		details the problem and defines design goals for a generic mechanism
	to restrain the unnecessary multicast stream flooding.		to restrain the unnecessary multicast stream flooding.
	6. Layer 3 / Layer 2 Topological Variations		6. Layer 3 / Layer 2 Topological Variations
	As discussed in [I-D.armd-problem-statement], there are a variety of		As discussed in RFC6820, the ARMD problems statement, there are a
	topological data center variations including L3 to Access Switches,		variety of topological data center variations including L3 to Access
	L3 to Aggregation Switches, and L3 in the Core only. Further		Switches, L3 to Aggregation Switches, and L3 in the Core only.
	analysis is needed in order to understand how these variations affect		Further analysis is needed in order to understand how these
	IP Multicast scalability		variations affect IP Multicast scalability
	7. Address Resolution		7. Address Resolution
	7.1. Solicited-node Multicast Addresses for IPv6 address resolution		7.1. Solicited-node Multicast Addresses for IPv6 address resolution
	Solicited-node Multicast Addresses are used with IPv6 Neighbor		Solicited-node Multicast Addresses are used with IPv6 Neighbor
	Discovery to provide the same function as the Address Resolution		Discovery to provide the same function as the Address Resolution
	Protocol (ARP) in IPv4. ARP uses broadcasts, to send an ARP		Protocol (ARP) in IPv4. ARP uses broadcasts, to send an ARP
	Requests, which are received by all end hosts on the local link.		Requests, which are received by all end hosts on the local link.
	Only the host being queried responds. However, the other hosts still		Only the host being queried responds. However, the other hosts still
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 5 ¶
	multicast IPv4 address. Planning is required within an organization		multicast IPv4 address. Planning is required within an organization
	to select IPv4 groups that are far enough away from each other as to		to select IPv4 groups that are far enough away from each other as to
	not end up with the same L2 address used. Any multicast address in		not end up with the same L2 address used. Any multicast address in
	the [224-239].0.0.x and [224-239].128.0.x ranges should not be		the [224-239].0.0.x and [224-239].128.0.x ranges should not be
	considered. When sending IPv6 multicast packets on an Ethernet link,		considered. When sending IPv6 multicast packets on an Ethernet link,
	the corresponding destination MAC address is a direct mapping of the		the corresponding destination MAC address is a direct mapping of the
	last 32 bits of the 128 bit IPv6 multicast address into the 48 bit		last 32 bits of the 128 bit IPv6 multicast address into the 48 bit
	MAC address. It is possible for more than one IPv6 Multicast address		MAC address. It is possible for more than one IPv6 Multicast address
	to map to the same 48 bit MAC address.		to map to the same 48 bit MAC address.
	8. Acknowledgements		8. IANA Considerations
	The authors would like to thank the many individuals who contributed
	opinions on the ARMD wg mailing list about this topic: Linda Dunbar,
	Anoop Ghanwani, Peter Ashwoodsmith, David Allan, Aldrin Isaac, Igor
	Gashinsky, Michael Smith, Patrick Frejborg, Joel Jaeggli and Thomas
	Narten.
	9. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	10. Security Considerations		9. Security Considerations
	No new security considerations result from this document		No new security considerations result from this document
	11. Informative References		10. Acknowledgements
	[I-D.armd-problem-statement]		The authors would like to thank the many individuals who contributed
	Narten, T., Karir, M., and I. Foo,		opinions on the ARMD wg mailing list about this topic: Linda Dunbar,
	"draft-ietf-armd-problem-statement", February 2012.		Anoop Ghanwani, Peter Ashwoodsmith, David Allan, Aldrin Isaac, Igor
			Gashinsky, Michael Smith, Patrick Frejborg, Joel Jaeggli and Thomas
			Narten.
	[I-D.pim-umf-problem-statement]		11. References
	Zhou, D., Deng, H., Shi, Y., Liu, H., and I. Bhattacharya,
	"draft-dizhou-pim-umf-problem-statement", October 2010.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		11.1. Normative References
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for		11.2. Informative References
	IP", RFC 4607, August 2006.
	[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution
	"Bidirectional Protocol Independent Multicast (BIDIR-		Problems in Large Data Center Networks", RFC 6820,
	PIM)", RFC 5015, October 2007.		DOI 10.17487/RFC6820, January 2013,
			<https://www.rfc-editor.org/info/rfc6820>.
	Author's Address		Author's Address
	Mike McBride		Mike McBride
	Huawei Technologies		Huawei
	2330 Central Expressway
	Santa Clara, CA 95050
	USA
	Email: michael.mcbride@huawei.com		Email: michael.mcbride@huawei.com
End of changes. 21 change blocks.
	60 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/