| Mboned | M. Abrahamsson |
| Internet-Draft | T-Systems |
| Intended status: Best Current Practice | T. Chown |
| Expires: May 3, 2018 | Jisc |
| L. Giuliano | |
| Juniper Networks, Inc. | |
| October 30, 2017 |
Deprecating ASM for Interdomain Multicast
draft-acg-mboned-multicast-models-01
This document provides a high-level overview of more commonly used multicast service models, principally the Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) models, and discusses the applicability of the models to certain scenarios. As a result, this document recommends that ASM is not used for interdomain scenarios, and the use of SSM is strongly recommended for all multicast scenarios.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 has been no strong recommendation made on the appropriateness of the models to certain scenarios. This document aims to fill that gap, and includes a BCP-level recommendation to both deprecate the use of interdomain ASM and to promote the use of SSM for all multicast scenarios.
The general IP multicast service model [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.
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. The principal advantage, in terms of bandwidth conservation will lie with the sender, i.e., at the head end.
A reserved range of IP addresses (for either IPv4 or IPv6) is used for multicast group communication.
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 only in a given multicast group address. In contrast, with Source-Specific Multicast (SSM) the specific source(s) that may send traffic to the group are known in advance. In SSM, receivers express interest both in a given multicast address and specific associated source address(es).
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 a specific sender IP address. They may discover the group (and sender IP) information in a number of different ways. They are also able to signal their desire to no longer receive multicast traffic for a given group (and sender IP).
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 onwhich interfaces to forward (and where necessary replicate) multicast packets.
Multicast packet forwarding is generally not considered a reliable service. It is typically unidirectional, but a bidirectional multicast delivery mechanism also exists.
In this section we describe general multicast building blocks that are applicable to both ASM and SSM deployment.
IANA has reserved specific ranges of IPv4 and IPv6 address space for multicast addressing.
Guidelines for IPv4 multicast address assignments can be found in [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).
Guidelines for IPv6 multicast address assignments can be found in [RFC2375] and [RFC3307]. The IPv6 multicast address format is described in [RFC4291]. An IPv6 multicast group address will lie within ff00::/8.
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.
For IPv4, a host may use Internet Group Management Protocol Version 2 (IGMPv2) [RFC2236] to signal interest in a given group. IGMPv3 [RFC3376] has the added capability of specifying interest in receiving multicast packets from specific sources.
For IPv6, a host may use Multicast Listener Discovery Protocol (MLD) [RFC2710] to signal interest in a given group. MLDv2 [RFC3810] has the added capability of specifying interest in receiving multicast packets from specific sources.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
In some cases, it is desirable to limit the propogation of multicast messages in a layer 2 network, typically through a layer 2 switch device. In such cases multicast snopping can be used, by which the switch device observes the IGMP/MLD traffic passing through it, and then attempts to make intelligent decisions on which physical ports to forward multicast. Typically, ports that have not expressed an interest in receiving multicast for a given group would not have traffic for that group forwarded through them. There is further discussion in [RFC4541].
PIM-DM is detailed in [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.
PIM-DM remains an Experimental protocol since its publication in 2005.
The most recent revision of PIM-SM is detailed in [RFC7761]. PIM-SM is, as the name suggests, was designed to be used in 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 whole network.
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 [RFC4610].
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.
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). [RFC3618].
Deployment scenarios for MSDP are given in [RFC4611]. MSDP remains an Experimental protocol since its publication in 2003. MSDP was not replicated for IPv6.
PIM-BIDIR is detailed in [RFC5015]. In contrast to PIM-SM, it can establish bi-directional multicast forwarding trees between multicast sources and receivers.
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 [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, simply by observing the RP address that is embedded (included) in the group address.
Embedded-RP allows PIM-SM operation across any IPv6 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 interdomain without the need for an explicit source discovery protocol (i.e. without MSDP for IPv6). It would generally be desirable that the RP would be located close to the sender(s) in the group.
PIM-SSM is detailed in [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.
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.
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.
PIM-DM remains an Experimental protocol, that appears to be rarely used in campus or enterprise environments.
In enterprise and campus scenarios, PIM-SM is in relatively common use. The configuration and management of an RP ithin a single domain 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, in no small part due to the complexity of operation and troubleshooting.
PIM-SM is a general purpose protocol that can handle all use cases. In particular, it was designed for cases where one or more sources may came and go during a multicast session. For cases where a single, persistent source is used, and receivers can be configured to know of that source, PIM-SM has unnecessary complexity.
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 can support 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.
BIDIR-PIM is designed, as the name suggests, for bidirectional use cases.
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 starts running. PIM-SSM is therefore very well-suited to applications such as classic linear broadcast TV over IP.
SSM requires hosts using it and (edge) routers with SSM receivers support the new(er) IGMPv3 and MLDv2 protocols. While delayed delivery of support in some OSes has meant that adoption of SSM has also been slower than might have been expected, or hoped, support for SSM is now widespread in common OSes.
This document recommends that the use of interdomain ASM is deprecated. It also recommends the use of SSM for all multicast scenarios.
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 reduced complexity makes SSM radically simpler to manage, troubleshoot and operate, particularly for network backbone operators; this is the main motivation for the recommendation to deprecate the use of ASM in interdomain scenarios. Interdomain ASM is widely viewed as complicated and fragile. By eliminating network-based source discovery for interdomain multicast, the vast majority of the complexity issues go away.
RFC 4607 includes details some benefits of SSM, for example:
Further discussion can also be found in [RFC3569].
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. This topic is expanded upon in [RFC4609].
The recommendation to deprecate the use of interdomain ASM applies to the use of ASM between domains, where either MSDP (IPv4) or Embedded-RP (IPv6) is required for sharing knowledge of remote sources.
If an organisation, or AS, wishes to use multiple multicast domains within its own network border, that is a choice for that organisation to make, and it may then use MSDP or Embedded-RP internally.
MSDP is an Experimental level standard; this document does not propose making it Historic, given there may be such residual intra-site use cases.
By implication, it is thus strongly recommended that SSM be the multicast protocol of choice for interdomain multicast. Best current practices for interdomain multicast using SSM are documented in [I-D.ietf-mboned-interdomain-peering-bcp].
The use of ASM within a single multicast domain, such as an enterprise or campus, is relatively common today, typically with anycast-RP or MSDP for RP resilience. This document does not preclude continued use of ASM in this scenario.
However, it is strongly recommended that sites using ASM internally conduct an audit of the multicast applications used, and begin planning a migration to using SSM wherever possible.
This document recommends that all host and router platforms supporting multicast also support IGMPv3 and MLDv2. The updated IPv6 Node Requirements RFC states that MLDv2 support is a MUST in all implementations [I-D.ietf-6man-rfc6434-bis]. Such support is now widespread in all common platforms.
A key benefit of SSM is that the multicast application does not need to be allocated a specific multicast group by the network, rather as SSM is inherently source-specific, it can use any group address, G, in the reserved range of IPv4 or IPv6 addresses for its own source address, S.
In principle, if interdomain ASM is deprecated, backbone operators could begin filtering the ranges of group addresses used by ASM. In practice, this is not recommended given there will be a transition period from ASM to SSM (as discussed further below) where some form of ASM-SSM mappings may be used, and filtering may preclude such operations.
There will be a wide range of applications today that only support ASM, whether as software packages, or code embedded in devices such as set top boxes.
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:
This, in theory, it should be possible to port ASM-only applications to be able to run using SSM, if an appropriate out-of-band mechanism can be chosen to convey the participant source addresses.
Given all common OSes support SSM, it is then down to the programming language and APIs used as to whether the necessary SSM APIs are available. SSM support is generally quite ubiquitous, with the current excpetion of websockets used in web-browser based applications.
It is desirable that applications also support appropriate congestion control, as described in [RFC8085], with appropriate codecs, to achieve the necessary rate adaption.
It is recommended that application developers choosing to use multicast, develop and engineer their applications to use SSM rather than ASM.
Some useful considerations for multicast applications can still be found in the relatively old [RFC3170].
In the case of existing ASM applications that cannot readily be ported to SSM, it may be possible to use some form of protocol mapping, i.e., to have a mechanism to translate a (*,G) join or leave to a (S,G) join or leave, for a specifci source, S. The general challenge in performing such mapping is determining where the configured source address, S, comes from.
There are some existing vendor-specific mechanisms to achieve this function, but none are documented in IETF standards. This may be an area for the IETF to ork on, but it should be noted that any such effort would only be an interim transition mechanism, and such mappings do not remove the requirement for applications to be allocated ASM group addresses for the communications.
It is generally considered better to work towards using SSM, and thus pushing the source discovery problem from the network to the application.
This document recommends that the use of interdomain ASM is deprecated. It also recommends the use of SSM for all multicast scenarios. Specific implications and considerations for the recommendation are discussed.
This document adds no new security considerations. RFC4609 describes the additional security benefits of using SSM instead of ASM.
This document currently makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as an RFC.
The authors would like to thank the following people for their contributions to the document: Hitoshi Asaeda, Toerless Eckert, Jake Holland, Mike McBride, Per Nihlen, Greg Shepherd, Stig Venaas, Nils Warnke, and Sandy Zhang.