draft-ietf-mboned-dc-deploy-03.txt   draft-ietf-mboned-dc-deploy-04.txt 
MBONED M. McBride MBONED M. McBride
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational O. Komolafe Intended status: Informational O. Komolafe
Expires: December 31, 2018 Arista Networks Expires: August 11, 2019 Arista Networks
June 29, 2018 February 07, 2019
Multicast in the Data Center Overview Multicast in the Data Center Overview
draft-ietf-mboned-dc-deploy-03 draft-ietf-mboned-dc-deploy-04
Abstract Abstract
The volume and importance of one-to-many traffic patterns in data The volume and importance of one-to-many traffic patterns in data
centers is likely to increase significantly in the future. Reasons centers is likely to increase significantly in the future. Reasons
for this increase are discussed and then attention is paid to the for this increase are discussed and then attention is paid to the
manner in which this traffic pattern may be judiously handled in data manner in which this traffic pattern may be judiously handled in data
centers. The intuitive solution of deploying conventional IP centers. The intuitive solution of deploying conventional IP
multicast within data centers is explored and evaluated. Thereafter, multicast within data centers is explored and evaluated. Thereafter,
a number of emerging innovative approaches are described before a a number of emerging innovative approaches are described before a
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 https://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 December 31, 2018. This Internet-Draft will expire on August 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Reasons for increasing one-to-many traffic patterns . . . . . 3 2. Reasons for increasing one-to-many traffic patterns . . . . . 3
2.1. Applications . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Applications . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Overlays . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Overlays . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Protocols . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Protocols . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Handling one-to-many traffic using conventional multicast . . 5 3. Handling one-to-many traffic using conventional multicast . . 6
3.1. Layer 3 multicast . . . . . . . . . . . . . . . . . . . . 6 3.1. Layer 3 multicast . . . . . . . . . . . . . . . . . . . . 6
3.2. Layer 2 multicast . . . . . . . . . . . . . . . . . . . . 6 3.2. Layer 2 multicast . . . . . . . . . . . . . . . . . . . . 6
3.3. Example use cases . . . . . . . . . . . . . . . . . . . . 8 3.3. Example use cases . . . . . . . . . . . . . . . . . . . . 8
3.4. Advantages and disadvantages . . . . . . . . . . . . . . 9 3.4. Advantages and disadvantages . . . . . . . . . . . . . . 9
4. Alternative options for handling one-to-many traffic . . . . 9 4. Alternative options for handling one-to-many traffic . . . . 9
4.1. Minimizing traffic volumes . . . . . . . . . . . . . . . 9 4.1. Minimizing traffic volumes . . . . . . . . . . . . . . . 10
4.2. Head end replication . . . . . . . . . . . . . . . . . . 10 4.2. Head end replication . . . . . . . . . . . . . . . . . . 10
4.3. BIER . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. BIER . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Segment Routing . . . . . . . . . . . . . . . . . . . . . 12 4.4. Segment Routing . . . . . . . . . . . . . . . . . . . . . 12
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The volume and importance of one-to-many traffic patterns in data The volume and importance of one-to-many traffic patterns in data
skipping to change at page 4, line 19 skipping to change at page 4, line 19
gathering pace. A possible outcome of this transition will be the gathering pace. A possible outcome of this transition will be the
building of IP data centers in broadcast plants. Traffic flows in building of IP data centers in broadcast plants. Traffic flows in
the broadcast industry are frequently one-to-many and so if IP data the broadcast industry are frequently one-to-many and so if IP data
centers are deployed in broadcast plants, it is imperative that this centers are deployed in broadcast plants, it is imperative that this
traffic pattern is supported efficiently in that infrastructure. In traffic pattern is supported efficiently in that infrastructure. In
fact, a pivotal consideration for broadcasters considering fact, a pivotal consideration for broadcasters considering
transitioning to IP is the manner in which these one-to-many traffic transitioning to IP is the manner in which these one-to-many traffic
flows will be managed and monitored in a data center with an IP flows will be managed and monitored in a data center with an IP
fabric. fabric.
Arguably one of the (few?) success stories in using conventional IP One of the few success stories in using conventional IP multicast has
multicast has been for disseminating market trading data. For been for disseminating market trading data. For example, IP
example, IP multicast is commonly used today to deliver stock quotes multicast is commonly used today to deliver stock quotes from the
from the stock exchange to financial services provider and then to stock exchange to financial services provider and then to the stock
the stock analysts or brokerages. The network must be designed with analysts or brokerages. The network must be designed with no single
no single point of failure and in such a way that the network can point of failure and in such a way that the network can respond in a
respond in a deterministic manner to any failure. Typically, deterministic manner to any failure. Typically, redundant servers
redundant servers (in a primary/backup or live-live mode) send (in a primary/backup or live-live mode) send multicast streams into
multicast streams into the network, with diverse paths being used the network, with diverse paths being used across the network.
across the network. Another critical requirement is reliability and Another critical requirement is reliability and traceability;
traceability; regulatory and legal requirements means that the regulatory and legal requirements means that the producer of the
producer of the marketing data must know exactly where the flow was marketing data must know exactly where the flow was sent and be able
sent and be able to prove conclusively that the data was received to prove conclusively that the data was received within agreed SLAs.
within agreed SLAs. The stock exchange generating the one-to-many The stock exchange generating the one-to-many traffic and stock
traffic and stock analysts/brokerage that receive the traffic will analysts/brokerage that receive the traffic will typically have their
typically have their own data centers. Therefore, the manner in own data centers. Therefore, the manner in which one-to-many traffic
which one-to-many traffic patterns are handled in these data centers patterns are handled in these data centers are extremely important,
are extremely important, especially given the requirements and especially given the requirements and constraints mentioned.
constraints mentioned.
Many data center cloud providers provide publish and subscribe Many data center cloud providers provide publish and subscribe
applications. There can be numerous publishers and subscribers and applications. There can be numerous publishers and subscribers and
many message channels within a data center. With publish and many message channels within a data center. With publish and
subscribe servers, a separate message is sent to each subscriber of a subscribe servers, a separate message is sent to each subscriber of a
publication. With multicast publish/subscribe, only one message is publication. With multicast publish/subscribe, only one message is
sent, regardless of the number of subscribers. In a publish/ sent, regardless of the number of subscribers. In a publish/
subscribe system, client applications, some of which are publishers subscribe system, client applications, some of which are publishers
and some of which are subscribers, are connected to a network of and some of which are subscribers, are connected to a network of
message brokers that receive publications on a number of topics, and message brokers that receive publications on a number of topics, and
skipping to change at page 5, line 48 skipping to change at page 5, line 48
Furthermore, when these protocols are running within an overlay Furthermore, when these protocols are running within an overlay
network, then it essential to ensure the messages are delivered to network, then it essential to ensure the messages are delivered to
all the hosts on the emulated layer 2 segment, regardless of physical all the hosts on the emulated layer 2 segment, regardless of physical
location within the data center. The challenges associated with location within the data center. The challenges associated with
optimally delivering ARP and ND messages in data centers has optimally delivering ARP and ND messages in data centers has
attracted lots of attention [RFC6820]. Popular approaches in use attracted lots of attention [RFC6820]. Popular approaches in use
mostly seek to exploit characteristics of data center networks to mostly seek to exploit characteristics of data center networks to
avoid having to broadcast/multicast these messages, as discussed in avoid having to broadcast/multicast these messages, as discussed in
Section 4.1. Section 4.1.
There are networking protocols that are being modified/developed to
specifically target working in a data center CLOS environment. BGP
has been extended to work in these type of DC environments and well
supports multicast. RIFT (Routing in Fat Trees) is a new protocol
being developed to work efficiently in DC CLOS environments and also
is being specified to support multicast addressing and forwarding.
3. Handling one-to-many traffic using conventional multicast 3. Handling one-to-many traffic using conventional multicast
3.1. Layer 3 multicast 3.1. Layer 3 multicast
PIM is the most widely deployed multicast routing protocol and so, PIM is the most widely deployed multicast routing protocol and so,
unsurprisingly, is the primary multicast routing protocol considered unsurprisingly, is the primary multicast routing protocol considered
for use in the data center. There are three potential popular for use in the data center. There are three potential popular
flavours of PIM that may be used: PIM-SM [RFC4601], PIM-SSM [RFC4607] flavours of PIM that may be used: PIM-SM [RFC4601], PIM-SSM [RFC4607]
or PIM-BIDIR [RFC5015]. It may be said that these different modes of or PIM-BIDIR [RFC5015]. It may be said that these different modes of
PIM tradeoff the optimality of the multicast forwarding tree for the PIM tradeoff the optimality of the multicast forwarding tree for the
amount of multicast forwarding state that must be maintained at amount of multicast forwarding state that must be maintained at
routers. SSM provides the most efficient forwarding between sources routers. SSM provides the most efficient forwarding between sources
 End of changes. 10 change blocks. 
27 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/