One document matched: draft-acg-mboned-multicast-models-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
<!ENTITY RFC2236 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2236.xml">
<!ENTITY RFC2365 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2365.xml">
<!ENTITY RFC2375 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2375.xml">
<!ENTITY RFC2710 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2710.xml">
<!ENTITY RFC3307 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml">
<!ENTITY RFC3376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
<!ENTITY RFC3618 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml">
<!ENTITY RFC3810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC3956 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3956.xml">
<!ENTITY RFC3973 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3973.xml">
<!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4541 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml">
<!ENTITY RFC4604 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml">
<!ENTITY RFC4607 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
<!ENTITY RFC4610 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml">
<!ENTITY RFC4611 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4611.xml">
<!ENTITY RFC5015 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5015.xml">
<!ENTITY RFC5771 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml">
<!ENTITY RFC6726 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6726.xml">
<!ENTITY RFC7346 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7346.xml">
<!ENTITY RFC7761 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
<!ENTITY I-D.ietf-mboned-interdomain-peering-bcp SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mboned-interdomain-peering-bcp.xml">
]>
<!-- Use with the following tips & tools:
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
http://xml.resource.org/authoring/README.html OR
http://xml.resource.org/authoring/README-dev.html
http://xml.resource.org/ OR
http://xml.resource.org/experimental.html
http://fenron.net/~fenner/ietf/xml2rfc-valid/ link appears to be broken :(
http://tools.ietf.org/tools/idnits/
http://tools.ietf.org/rfcdiff
-->
<!-- Then upload:
https://datatracker.ietf.org/idst/upload.cgi
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.35) -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="3"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr="trust200902" docName="draft-acg-mboned-multicast-models-00">
<front>
<title abbrev="Multicast Service Models">Multicast Service Models</title>
<author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
<organization> T-Systems </organization>
<address>
<postal>
<street> </street>
<city> Stockholm </city>
<country> Sweden </country>
</postal>
<email> mikael.abrahamsson@t-systems.se </email>
</address>
</author>
<author fullname="Tim Chown" initials="T." surname="Chown">
<organization> Jisc </organization>
<address>
<postal>
<street> Lumen House, Library Avenue </street>
<city> Harwell Oxford, Didcot</city>
<code> OX11 0SG </code>
<country> United Kingdom </country>
</postal>
<email> tim.chown@jisc.ac.uk </email>
</address>
</author>
<author fullname="Lenny Giuliano" initials="L." surname="Giuliano">
<organization> Juniper Networks, Inc. </organization>
<address>
<postal>
<street> 2251 Corporate Park Drive </street>
<city> Hemdon, Virginia</city>
<code> 20171 </code>
<country> United States </country>
</postal>
<email> lenny@juniper.net </email>
</address>
</author>
<date day="6" month="July" year="2016"/>
<area> Operations </area>
<workgroup> Mboned </workgroup>
<abstract>
<t>
The draft provides a high-level overview of multicast
service and deployment models, principally the Any-Source
Multicast (ASM) and Source-Specific Multicast (SSM) models,
and aims to provoke discussion of
applicability of the models to certain scenarios.
This initial draft is by no means comprehensive. Comments on the
initial content, and what further content would be appropriate,
or indeed whether the draft is of value, are welcomed.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
IP Multicast has been deployed in various forms, both within
private networks and on the wider Internet. While a number
of service
models have been published individually, and in many cases
revised over time, there is, we believe,
no high-level guidance in the form of an Informational RFC
documenting the models, their advantages and disadvantages,
and their appropriateness to certain scenarios.
This document aims to fill that gap.
</t>
<t>
This initial version of the document is not complete. There
are other topics that can be included. The aim of this
initial version is to determine whether this work is deemed
of value within the IETF mboned WG.
</t>
</section>
<section title="Multicast service models">
<t>
The general IP multicast service model
<xref target="RFC1112"/> is that
senders send to a multicast IP address, receivers express
an interest in traffic sent to a given multicast address,
and that routers figure out how to deliver traffic
from the senders to the receivers.
</t>
<t>
The benefit of IP multicast is that it enables delivery
of content such that any multicast packet sent from a
source to a given multicast group address appears once and
only once on any path between a sender and an interested
receiver that has joined that multicast group.
A reserved range of addresses (for either IPv4 or
IPv6) is used for multicast group communication.
</t>
<t>
Two high-level flavours of this service model have
evolved over time. In Any-Source Multicast (ASM), any
number of sources may transmit multicast packets,
and those sources may come and go over the course
of a multicast session without being known a priori.
In ASM, receivers express interest in a given multicast
group address.
In Source-Specific Multicast (SSM) the specific source(s)
that may send traffic to the group are known in advance.
In SSM, receivers express interest in a given multicast address
and specific source(s).
</t>
<t>
Senders transmit multicast packets without knowing where
receivers are, or how many there are.
Receivers are able to signal to on-link routers their desire to
receive multicast content sent to a given multicast group,
and in the case of SSM from specific sender IP addresses.
They may discover the group (and sender IP) information in a
number of different ways. They may also signal their
desire to no longer receive multicast traffic for a
given group (and sender IP).
</t>
<t>
Multicast routing
protocols are used to establish the multicast forwarding
paths (tree) between a sender and a set of receivers.
Each router would typically maintain multicast forwarding
state for a given group (and potentially sender IP),
such that it knows which interfaces to forward (and where
necessary replicate) multicast packets to.
</t>
<t>
Multicast packet forwarding is generally not considered
a reliable service. It is typically unidirectional, but
a bidirectional multicast delivery mechanism also exists.
</t>
</section>
<section title="Multicast building blocks">
<t>
In this section we describe general multicast building
blocks that are applicable to both ASM and SSM deployment.
</t>
<section title="Multicast addressing">
<t>
IANA has reserved specific ranges of IPv4 and IPv6 address
space for multicast addressing.
</t>
<t>
Guidelines for IPv4 multicast address assignments
can be found in <xref target="RFC5771"/>.
IPv4 has no explicit multicast address format;
a specific portion of the overall IPv4 address
space is reserved for multicast use (224.0.0.0/4).
</t>
<t>
Guidelines for IPv6 multicast address assignments
can be found in <xref target="RFC2375"/> and
<xref target="RFC3307"/>.
The IPv6 multicast address format is described
in <xref target="RFC4291"/>. An IPv6 multicast
group address will lie within ff00::/8.
</t>
</section>
<section title="Host signalling">
<t>
A host wishing to signal interest in receiving (or no
longer receiving) multicast to a given multicast
group (and potentially from a specific sender IP)
may do so by sending a packet using one of the
protocols described below on an appropriate interface.
</t>
<t>
For IPv4, a host may use Internet Group Management
Protocol Version 2 (IGMPv2) <xref target="RFC2236"/>
to signal interest in a given group.
IGMPv3 <xref target="RFC3376"/> has the added
capability of specifying interest in receiving multicast
packets from specific sources.
</t>
<t>
For IPv6, a host may use Multicast Listener Discovery
Protocol (MLD) <xref target="RFC2710"/>
to signal interest in
a given group. MLDv2 <xref target="RFC3810"/> has the added
capability of specifying interest in receiving multicast
packets from specific sources.
</t>
<t>
Further guidance on IGMPv3 and MLDv2 is given in
<xref target="RFC4604"/>.
</t>
</section>
<section title="Multicast snooping">
<t>
Is this appropriate in this document?
There is discussion in <xref target="RFC4541"/>.
</t>
</section>
</section>
<section title="ASM service model protocols">
<section title="Protocol Independent Multicast, Dense Mode (PIM-DM)">
<t>
PIM-DM is detailed in <xref target="RFC3973"/>. It operates by
flooding multicast messages to all routers within the network
in which it is configured. This ensures multicast data packets
reach all interested receivers behind edge routers. Prune messages
are used by routers to tell upstream routers to (temporarily)
stop forwarding multicast for groups for which they have no known
receivers.
</t>
<t>
PIM-DM remains an Experimental protocol since its publication in 2005.
</t>
</section>
<section title="Protocol Independent Multicast, Sparse Mode (PIM-SM)">
<t>
The most recent revision of PIM-SM is detailed in <xref target="RFC7761"/>.
PIM-SM is, as the name suggests, well-suited to scenarios
where the subnets with receivers are sparsely distributed throughout
the network.
PIM-SM supports any number of senders
for a given multicast group, which do not need to be known in advance,
and which may come and go through the session.
PIM-SM does not use a flooding phase, making it more scalable and
efficient than PIM-DM, but this means PIM-SM needs a mechanism
to construct the multicast forwarding tree (and associated forwarding
tables in the routers) without flooding the network.
</t>
<t>
To achieve this, PIM-SM introduces the concept of a Rendezvous
Point (RP) for a PIM domain. All routers in a PIM-SM domain
are then configured to use specific RP(s). Such configuration
may be performed by a variety of methods,
including Anycast-RP <xref target="RFC4610"/>.
</t>
<t>
A sending host's Designated Router encapsulates multicast
packets to the RP, and a receiving host's Designated
Router can forward PIM JOIN
messages to the RP, in so doing forming what is known as the
Rendezvous Point Tree (RPT). Optimisation of the tree may then happen
once the receiving host's router is aware of the sender's IP, and
a source-specific JOIN message may be sent towards it, in so
doing forming the Shortest Path Tree (SPT). Unnecessary RPT paths
are removed after the SPT is established.
</t>
<section title="Inter-domain PIM-SM, and MSDP">
<t>
PIM-SM can in principle operate over any network in which the
cooperating routers are configured with RPs. But in general, PIM-SM
for a given domain will use an RP configured for that domain. There
is thus a challenge in enabling PIM-SM to work between multiple
domains, i.e. to allow an RP in one domain to learn the existence
of a source in another domain, such that a receiver's router in
one domain can know to forward a PIM JOIN towards a
source's Designated Router in another domain. The solution to
this problem is to use an inter-RP signalling protocol known
as Multicast Source Discovery Protocol (MSDP).
<xref target="RFC3618"/>.
</t>
<t>
Deployment scenarios for MSDP are given in <xref target="RFC4611"/>.
MSDP remains an Experimental protocol since its publication in
2003. MSDP was not replicated for IPv6.
</t>
</section>
</section>
<section title="Bidirectional PIM (BIDIR-PIM)">
<t>
BIDIR-PIM is detailed in <xref target="RFC5015"/>. In contrast to
PIM-SM, it can establish bi-directional multicast forwarding trees
between multicast sources and receivers.
</t>
<t>
Add more...
</t>
</section>
<section title="IPv6 PIM-SM with Embedded RP">
<t>
Within a single PIM domain, PIM-SM for IPv6 works largely the
same as it does for IPv4. However, the size of the IPv6
address (128 bits) allows a different mechanism for multicast
routers to determine the RP for a given multicast group
address. Embedded-RP <xref target="RFC3956"/> specifies a
method to embed the unicast RP IP address in an IPv6
multicast group address, allowing routers supporting the
protocol to determine the RP for the group without any
prior configuration.
</t>
<t>
Embedded-RP allows PIM-SM operation across any network in
which there is an end-to-end path of routers supporting the
protocol. By embedding the RP address in this way,
multicast for a given group can operate inter-domain
without the need for an explicit source discovery
protocol (i.e. without MSDP for IPv6).
It would be desirable that the RP
would be located close to the sender(s) in the group.
</t>
</section>
</section>
<section title="SSM service model protocols">
<section title="Source Specific Multicast (PIM-SSM)">
<t>
PIM-SSM is detailed in <xref target="RFC4607"/>. In contrast
to PIM-SM, PIM-SSM benefits from assuming that source(s)
are known about in advance, i.e. the source IP address is
known (by some out of band mechanism), and thus the
receiver's router can
send a PIM JOIN directly towards the sender, without
needing to use an RP.
</t>
<t>
IPv4 addresses in the 232/8 (232.0.0.0 to
232.255.255.255) range are designated as source-specific multicast
(SSM) destination addresses and are reserved for use by
source-specific applications and protocols.
For IPv6, the address prefix
FF3x::/32 is reserved for source-specific multicast use.
</t>
</section>
</section>
<section title="Discussion">
<t>
In this section we discuss the applicability of the
ASM and SSM models described above, and their associated
protocols, to a range of deployment scenarios.
The context is
framed in a campus / enterprise environment, but the draft
could broaden its scope to other environments (thoughts?).
</t>
<section title="ASM Deployment">
<t>
PIM-DM remains an Experimental protocol, that appears to be
rarely used in campus or enterprise environments. Open question:
what are the use cases for PIM-DM today?
</t>
<t>
In campus scenarios, PIM-SM is in common use. The configuration and
management of an RP is not onerous. However, if interworking
with external PIM domains in IPv4 multicast deployments is needed,
MSDP is required to
exchange information between domain RPs about sources.
MSDP remains an Experimental protocol, and can be a complex and
fragile protocol to administer and troubleshoot. MSDP is
also specific to IPv4; it was not carried forward to IPv6.
</t>
<t>
PIM-SM is a general purpose protocol that can handle all
use cases. In particular, it is well-suited to cases where
one or more sources may came and go during a multicast
session. For cases where a single, persistent source is
used, PIM-SM has unnecessary complexity.
</t>
<t>
As stated above, MSDP was not taken forward to IPv6. Instead,
IPv6 has Embedded-RP, which allows the RP address
for a multicast group to be embedded in the group address,
making RP discovery automatic, if all routers on the path
between a receiver and a sender support the protocol.
Embedded-RP is well-suited for lightweight ad-hoc deployments.
However, it does
rely on a single RP for an entire group. Embedded-RP was run
successfully between European and US academic networks during
the 6NET project in 2004/05. Its usage generally remains
constrained to academic networks.
</t>
<t>
BIDIR-PIM is designed, as the name suggests, for bidirectional
use cases.
</t>
</section>
<section title="SSM Deployment">
<t>
As stated in RFC4607, SSM is particularly well-suited to
dissemination-style applications with one or more senders
whose identities are known (by some mechanism) before the
application begins. PIM-SSM is therefore very well-suited
to applications such as IP TV.
</t>
<t>
Some benefits of PIM-SSM are presented in RFC 4607:
<list style="empty">
<t>"Elimination of cross-delivery of traffic when two sources
simultaneously use the same source-specific destination address;</t>
<t>Avoidance of the need for inter-host coordination when choosing
source-specific addresses, as a consequence of the above;</t>
<t>Avoidance of many of the router protocols and algorithms that are
needed to provide the ASM service model."</t>
</list>
</t>
<t>
A significant benefit of SSM is its reduced complexity through
eliminating network-based source discovery. This means no RPs,
shared trees, SPT switchover, PIM registers, MSDP or data-driven
state creation. It is really just a small subset of PIM-SM,
plus IGMPv3. This makes it radically simpler to manage,
troubleshoot and operate.
</t>
<t>
SSM is considered more secure in that it supports access control,
i.e. you only get packets from the sources you explicitly ask
for, as opposed to ASM where anyone can decide to send traffic
to a PIM-SM group address.
</t>
<t>
It is often thought that ASM is required for multicast applications
where there are multiple sources. However,
RFC4607 also describes how SSM can be used instead of PIM-SM
for multi-party applications:
</t>
<t>
<list style="empty">
<t>"SSM can be used to
build multi-source applications where all participants' identities
are not known in advance, but the multi-source "rendezvous"
functionality does not occur in the network layer in this case. Just
like in an application that uses unicast as the underlying transport,
this functionality can be implemented by the application or by an
application-layer library."
</t>
</list>
</t>
<t>
A disadvantage of SSM is that it requires hosts using SSM and
(edge) routers with SSM receivers
to support the new(er) IGMPv3 and MLDv2 protocols. The slow
delivery of support in some OSes has meant that
adoption of SSM has also been slower than might have been
expected, or hoped.
</t>
</section>
<section title="Other considerations">
<section title="Scalability, and multicast domains">
<t>
One of the challenges in wider-scale multicast deployment
is its scalability, if it is expected that
multicast-enabled routers are required to hold state for large
numbers of multicast sources/groups.
</t>
<t>
In practice, the number of groups a given router needs to hold state
for is limited by the propagation of the multicast messages for any
given group, e.g. because only a specific connected set of
routers are multicast-enabled, or because multicast scope borders
have been configured between multicast-enabled routers
for access control purposes. Further, protocol policy/filters are
typically used to limit state, as well as access control.
</t>
<t>
IPv4 multicast has no explicit indication of scope boundaries within
its multicast address format. The prefix 239.0.0.0/8 is reserved for
private use within a network, as per <xref target="RFC2365"/>, and
is believed to be in common usage. Other scopes within this
range are defined, e.g. Organizational Local Scope, but whether
this is in common use is unclear.
</t>
<t>
In contrast, IPv6 has specific flag bits reserved to indicate the
scope of an address, e.g. link (0x2), site (0x5), organisation (0x8)
or global (0xe), as described in <xref target="RFC7346"/>. Such
explicit scoping makes configuration of scope boundaries a simpler,
cleaner process.
</t>
</section>
<section title="Reliable multicast">
<t>
Do we want to go here, and if so which protocols should we mention?
FLUTE <xref target="RFC6726"/> might be one example.
</t>
</section>
<section title="Inter-domain multicast peering">
<t>
Interdomain peering best practices are documented in
<xref target="I-D.ietf-mboned-interdomain-peering-bcp"/>.
</t>
</section>
<section title="Layer 2 multicast domains">
<t>
Open question - do we want to look at L2 models, e.g. as might be applied at an IXP?
</t>
</section>
<section title="Anything else?">
<t>
Anything else to add here?
</t>
</section>
</section>
</section>
<section title="Use case examples">
<t>
Aim to add 2-3 deployment examples here, if deemed useful.
Perhaps one PIM-SM/MSDP/Anycast-RP, one Embedded-RP, one SSM?
</t>
</section>
<section title="Conclusions">
<t>
Do we wish to make a very strong recommendation here for the
SSM service model, and thus for PIM-SSM,
even in multi-source applications?
</t>
<t>
Is this document Informational or BCP? Currently assumed Informational.
</t>
</section>
<section title="Security Considerations">
<t>
Do we need general text on multicast security here, or not?
</t>
</section>
<section title="IANA Considerations">
<t>This document currently makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed upon publication as an RFC.</t>
</section>
<section title="Acknowledgments">
<t>
TBC if draft progresses...
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1112;
&RFC2236;
&RFC2365;
&RFC2375;
&RFC2710;
&RFC3307;
&RFC3376;
&RFC3618;
&RFC3810;
&RFC3956;
&RFC3973;
&RFC4291;
&RFC4607;
&RFC4610;
&RFC5015;
&RFC5771;
&RFC6726;
&RFC7346;
&RFC7761;
</references>
<references title="Informative References">
&RFC4541;
&RFC4604;
&RFC4611;
&I-D.ietf-mboned-interdomain-peering-bcp;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:30:36 |