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/