Juniper Networks

2251 Corporate Park Drive Herndon VA 20171 United States of America lenny@juniper.net

Verizon

22001 Loudoun County Parkway Ashburn VA 20147 United States of America chris.lenart@verizon.com

GEANT

City House 126-130 Hills Road Cambridge CB2 1PQ United Kingdom richard.adam@geant.org

OPS mops multicast SSM AMT LISP CDN PIM-SSM As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 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 () 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Requirements Language
• .  Problem Statement
• .  Applicability
• .  Multicast Challenges in the Past
• .  TreeDN Architecture
  • .  TreeDN Overlays
  • .  TreeDN Native On-Net
• .  Replication-as-a-Service (RaaS)
• .  Decentralization/Democratization of Content Sourcing
• .  Transport-Layer-Related Differences between TreeDN and Traditional CDNs
  • .  Integration with Unicast
  • .  Reliability, Adaptive Bitrates, and Congestion Control
  • .  Authorization and Encryption
• . TreeDN Deployments
• . Operational Considerations
• . Security Consideration
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• .  Netverses
• Acknowledgements
• Authors' Addresses

Introduction As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Problem Statement Live streaming to mass audiences can impose unique demands on network resources. For example, live sporting events that broadcast over the Internet to end users have a much lower tolerance for long playout buffers than typical on-demand video streaming. Viewers of live sporting events have long been conditioned by broadcast television to expect to see the content in real time, with only very short buffers for broadcast delays to prevent profanity and other objectionable content from making on the air (this is known as the "seven-second delay" ). With micro-betting, even this 5 to 10 second delay can be too long. By comparison, when watching on-demand movies, an extra one- or two-minute playout buffer tends to be perfectly acceptable for viewers. If playout buffers for live sports are that long, viewers run the risk of being alerted to a game-winning score from text messages from friends or cheers from the bar across the street minutes before they view it themselves. Another unique characteristic of live streaming is the join rate. While on-demand video streaming can consume massive amounts of network resources, the viewing rates tend to be smooth and predictable. Service Providers (SPs) observe gradual levels of traffic increases over the evening hours corresponding to prime-time viewing habits. By comparison, viewing rates of live video streams can more closely resemble a step function with much less predictability as mass audiences of viewers tune in to watch the game at the same time. Previous efforts for more efficient network replication of multi-destination traffic have experienced mixed success in terms of adoption. IP multicast is widely deployed on financial networks, video distribution networks, L3VPN networks, and certain enterprises. However, most of these deployments are restricted to "walled-garden" networks. Multicast over the global Internet has failed to gain traction, as only a very small portion of the Internet is multicast enabled at this time. TreeDN is a tree-based CDN architecture that is the result of the evolution of network-based replication mechanisms and is based on lessons learned from what has and has not worked well in the past. TreeDN addresses the fundamental issues of what has hindered multicast from adoption on the global Internet and enables SPs the opportunity to deliver new Replication-as-a-Service (RaaS) offerings to content providers, while more efficiently utilizing network resources by eliminating duplicated traffic. Thus, this improves the experience of end users. TreeDN accomplishes this with the combination of a simplified model of native multicast along with network overlays to reach receivers on unicast-only parts of the Internet. By more efficiently supporting multi-destination traffic, TreeDN is an architecture that can enable new types of content (such as AR live streaming to mass audiences) that previously weren't possible or economically viable on the Internet due to the inefficiencies of unicast.

Applicability While the primary use case mentioned throughout this document is live streaming of multimedia content (e.g., audio, video, AR, and real-time telemetry data), the TreeDN architecture can provide efficient delivery for any content that needs to be replicated and delivered to multiple destinations. For example, large software file updates (e.g., OS upgrades) that need to be delivered to many end users in a very short window of time can cause significant strain on network resources. Using TreeDN, this use case can be handled much more efficiently by the network.

Multicast Challenges in the Past The following issues have been some of the primary challenges for deployment of IP multicast over the global Internet. This is not intended to be an exhaustive list but rather a list that provides context for the solution and how it addresses these primary challenges.

• The "All or Nothing" problem: IP multicast requires every Layer 3 hop between the source and receivers to be multicast enabled. To achieve ubiquitous availability on the global Internet, this essentially means that nearly every interface on every router and firewall between all end hosts must support a multicast routing protocol (such as Protocol Independent Multicast - Sparse Mode (PIM-SM) or the Multipoint Label Distribution Protocol (mLDP) ). This requirement creates a bar to deployment that is practically impossible to overcome.
• The "It's Too Complex" problem: Operators have long complained that multicast routing protocols like PIM-SM are simply too complex, making it costly to design, configure, manage, and troubleshoot IP multicast in the network.
• The "Chicken and Egg" problem: There's not much multicast content because there's not much of a multicast-enabled audience, but there's not much of a multicast-enabled audience because there's not much multicast content.

TreeDN is the evolution of network-based replication based on lessons learned over decades and is designed to address the problems listed above.

TreeDN Architecture TreeDN leverages a simplified model for multicast deployment combined with network overlays to deliver traffic to receiving hosts on unicast-only networks. With network overlays, a service can be achieved and delivered to end users while recognizing and tolerating the practical realities of what is possible over a network as diverse as the global Internet. That is, the replication service is available to users and applications across the global Internet regardless of what protocols may exist in the underlying networks that constitute the underlay.

TreeDN Provider Example TreeDN Provider +-------------------------------+ | | | Native Multicast On-Net | +----------+ | (PIM-SSM) | | Content/ |----+ | | Mcast | | | | Source | | +-----------+ +----------+ +---|-------|-------| AMT Relay | +--------------+ | | +----|------+ | Unicast-Only | +-+ +-+ . | Network | +-+ +-+ ..........|........ | Native Content AMT Tunnel +-------.------+ Receivers . AMT +-+ Gateway +-+ | Content Receiver

TreeDN Overlays One overlay technology that TreeDN leverages is Automatic Multicast Tunneling (AMT) . With AMT, end hosts on unicast-only networks (AMT Gateways) can dynamically build tunnels to routers on the multicast-enabled part of the network (AMT Relays) and receive multicast streams. The AMT Gateway is a thin software client that typically sits on the receiving end host and initiates the tunnel at an AMT Relay. The AMT Relay is a tunnel server that typically sits at the border of the multicast network. AMT allows any end host on the Internet to receive multicast content regardless of whether their local provider supports multicast (aka, "off-net receivers"), which addresses the "All or Nothing" problem. Links and devices that do not support multicast are simply tunneled over -- they no longer present a barrier to the overall replication service for end users. Those networks that do deploy and support multicast, as well as the content providers that serve up multicast content, are able to enjoy the benefits of efficient replication and delivery. Further, these benefits can serve as incentives for operators who do not yet support multicast to enable it on their networks, which is a key benefit of incremental deployment described in . Once the cost of carrying duplicated unicast tunnels is perceived by those operators to exceed the cost of deploying multicast, they are more likely to enable multicast on their networks. Thus, TreeDN effectively supports incremental deployment in a way that was not previously possible with traditional (non-overlay) multicast networking. Finally, AMT also addresses the "Chicken and Egg" problem, as all end hosts on the global Internet that have access to an AMT Relay are capable of becoming audience members. To support receiving on both native and non-native networks, receiving hosts can first attempt to join the traffic natively, and if no multicast traffic is received, they can fall back to AMT. This fallback mechanism can be handled by the application layer. In addition to AMT, other overlay technologies like the Locator/ID Separation Protocol (LISP) can be utilized to deliver content from multicast-enabled networks to end hosts that are separated by portions of the network (at the last/middle/first mile) that do not support multicast.

TreeDN Native On-Net Networks that support multicast provide the native on-net component of TreeDN. The primary requirement of the native on-net component is to support Source-Specific Multicast (SSM) . PIM-SSM, which is merely a subset of PIM-SM, is the multicast routing protocol typically used in SSM. However, any multicast routing protocol capable of supporting SSM can be used in the TreeDN native on-net component, such as mLDP, Global Table Multicast (GTM) , BGP-based Multicast , or even BGP Multicast VPN (BGP-MVPN) for those operators who carry the global routing table in a Virtual Routing and Forwarding (VRF) table. Likewise, any data plane technology that supports SSM, including Bit Index Explicit Replication (BIER) and Segment Routing (SR) Point-to-Multipoint (P2MP) , can be used. The key benefit of SSM as the native on-net component of TreeDN is that it radically simplifies the control plane needed to support replication in the network. This simplification comes by moving source discovery from the network layer to some sort of out-of-band mechanism, usually in the application layer. In SSM, the receiver uses the Internet Group Management Protocol Version 3 (IGMPv3) for IPv4 or the Multicast Listener Discovery Version 2 (MLDv2) protocol for IPv6 to specify both the source and group address of the multicast stream. This allows the last-hop router to immediately join the multicast stream along the shortest-path tree (SPT) without the need for shared trees. This benefit addresses the "It's Too Complex" problem. By eliminating the need for network-based source discovery, most of the complexity of multicast is then eliminated, which reduces the cost of deploying and operating a multicast network. Further rationale for this SSM-only approach can be found in Any-Source Multicast (ASM) Deprecation .

Replication-as-a-Service (RaaS) Content providers have traditionally used CDNs to distribute content that needs to be delivered to large audiences, essentially outsourcing the task of replication to CDN providers. Most CDNs utilize unicast delivery, as multicast is not an option due to its lack of general availability on the global Internet. TreeDN is a CDN architecture that leverages tree-based replication to more efficiently utilize network resources to deliver simultaneous multi-destination traffic. By leveraging overlay networking to address the "All or Nothing" and "Chicken and Egg" problems, and leveraging SSM to address the "It's Too Complex" problem, TreeDN avoids the practical issues that previously prevented multicast from being a viable option for CDN providers. TreeDN has several advantages over traditional unicast-based CDN approaches. First, the TreeDN functionality can be delivered entirely by the existing network infrastructure. Specifically, for operators with routers that support AMT natively, multicast traffic can be delivered directly to end users without the need for specialized CDN devices, which typically are servers that need to be racked, powered, cooled, and connected to ports on routers that otherwise could have been consumed by paying customers. In this way, SPs can offer new RaaS functionality to content providers at potentially zero additional cost in new equipment. Additionally, TreeDN is an open architecture that leverages mature, IETF-specified, and widely implemented network protocols. TreeDN also requires far less coordination between the content provider and the CDN operator. That is, there are no storage requirements for the data, nor group-key management issues, since a TreeDN provider merely forwards packets. A TreeDN provider simply needs to have enough accounting data (e.g., traffic data, number of AMT tunnels, etc.) to properly bill customers for the service. By contrast, traditional unicast-based CDNs often incorporate proprietary, non-interoperable technologies and require significant coordination between the content provider and the CDN to handle such things as file storage, data protection, and key management. TreeDN introduces a deployment model that requires new considerations for transport-layer mechanisms that are frequently relied upon by traditional unicast-based CDNs. A discussion on these considerations and differences can be found in .

Decentralization/Democratization of Content Sourcing TreeDN is an inherently decentralized architecture. This reduces the cost for content sourcing, as any host connected to a multicast-enabled network or on a source-capable overlay can send out a single data stream that can be reached by an arbitrarily large audience. By effectively reducing the marginal cost of reaching each additional audience member to zero, from the perspective of the source, TreeDN democratizes content sourcing on the Internet.

Transport-Layer-Related Differences between TreeDN and Traditional CDNs The focus of this document is on the network-layer components that comprise the TreeDN architecture. This section introduces some of the key transport-layer-related differences between TreeDN and traditional unicast-based CDNs that should be taken into consideration when deploying TreeDN-based services. In many cases, these issues are more related to differences between TCP and UDP than differences between unicast and multicast; thus, UDP-based solutions can be leveraged to address most gaps. The aim of this section is to point to some of the existing work to address these gaps, as well as to suggest further work that could be undertaken within the IETF. Further details of these transport-layer mechanisms are beyond the scope of this document.

Integration with Unicast Since SSM inherently implies unidirectional traffic flows from one to many, mechanisms that rely on bidirectional communication between receivers and the content provider (such as bespoke advertising, telemetry data from receivers detailing end-user experience, distribution of decryption keys, switching to higher or lower bandwidth streams, etc.) are not well suited to SSM delivery. As such, separate unicast streams between receivers and content providers may be used for this type of "out-of-band" function while SSM is used to deliver the actual content of interest. These "out-of-band" unicast streams SHOULD use the same congestion control and authentication mechanisms that are used today for mass audience unicast delivery. Generally speaking, this hybrid unicast-multicast approach is best handled by the application layer and further detail is beyond the scope of this document.

Reliability, Adaptive Bitrates, and Congestion Control Traditional unicast-based CDNs frequently rely on HTTPS over TCP transport; thus, they are able to leverage the granularity of TCP-based mechanisms for reliability, congestion control, and adaptive bitrate streaming. However, this granularity comes at a cost of sending a separate data stream to each viewer. Multicast transmissions usually employ UDP, which inherently lacks many of the aforementioned benefits of TCP but can scale much better for mass audiences of simultaneous viewers. Forward Error Correction (FEC) is a mechanism that has demonstrated full recovery for up to 5% packet loss and interruptions up to 400 ms for multicast data streams in . NACK-Oriented Reliable Multicast (NORM) leverages FEC-based repair and other Reliable Multicast Transport (RMT) building blocks to provide end-to-end reliable transport over multicast networks. QUIC is another popular transport used by traditional unicast-based CDNs. While QUIC does use UDP, it does not currently support multicast. Multicast extensions to QUIC have been proposed in . describes how a sender can distribute data across multiple multicast source-group channels so that each receiver can join the most appropriate channels for its own reception rate capability, thus providing adaptive bitrate capabilities for multicast streams. and extensively describe an architecture that enables reliability and dynamic bitrate adaptation. TreeDN deployments MUST follow the congestion control guidelines described in . A multicast application that is being distributed over TreeDN deployments SHOULD implement congestion control for its data transmission as described in . The AMT gateway SHOULD use the topologically closest AMT relay. describes a set of procedures for optimal relay selection.

Authorization and Encryption A multicast sender typically has little to no control or visibility about which end hosts may receive the data stream. Encryption can be used to ensure that only authorized receivers are able to access meaningful data. That is, even if unauthorized end hosts (e.g., non-paying end hosts) receive the data stream, without decryption keys, the data is useless. describes an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) for the purpose of group key management. and extensively describe an architecture that includes encryption of multicast streams.

TreeDN Deployments EUMETCast Terrestrial is a service from the European Organisation for the Exploitation of Meteorological Satellites (EUMETSAT) that delivers meteorological satellite data to end users for purposes such as operational monitoring of climates and detection of global climate changes. EUMETCast Terrestrial connects to the GEANT network, which provides TreeDN services to deliver this real-time data natively to end users on multicast-enabled networks and to end users on unicast-only networks via a global deployment of AMT relays. Details of the EUMETCast Terrestrial service over the GEANT TreeDN network are described in . Additional details on how this deployment uses encryption, authorization, reliability, and unicast feedback channels for end-to-end file delivery monitoring can be found in . The Multicast Menu is a web-based portal that can list and launch active multicast streams that are available on a global TreeDN network of various research and education networks. Details of this TreeDN network, as well as the Multicast Menu, are described in . The RARE network is a global testbed interconnecting several National Research and Education Networks (NRENs) via routers running BIER. AMT relays are deployed to deliver multicast traffic from sources on the RARE network to receivers on unicast-only networks across the Internet. Details of the RARE network are described in .

Operational Considerations TreeDN is essentially the synthesis of SSM plus overlay networking technologies like AMT. As such, any existing tools to manage, operate, and troubleshoot a PIM-SSM domain and an AMT deployment can be used to manage a TreeDN deployment. Protocol error handling for PIM-SSM can be found in and in ; for AMT, it can be found in . One potential operational benefit of a multicast-based approach like TreeDN over a traditional, unicast-based CDN is the visibility that multicast state provides in the routing infrastructure. That is, multicast routers maintain a forwarding cache of multicast flows that usually includes the source address, group address, incoming/outgoing interfaces, and forwarding rate. Generally speaking, such flow state information is not typically available in core networks for unicast, so additional tools outside the routing infrastructure are usually required for monitoring CDN performance and troubleshooting issues like packet loss location. Of course, this benefit comes at a cost of additional state being maintained in the routers for multicast. Additionally, since multicast leverages Reverse Path Forwarding (RPF), the source of the content can potentially have a greater influence over the path taken through the network from source to native receivers/AMT relays. That is, the BGP peer advertising the reachability of the source's subnet can do so in ways where a particular path through the network is preferred for multicast distribution; these methods are not as easy to accomplish with traditional, destination-based unicast routing.

Security Consideration Since TreeDN is essentially the synthesis of SSM plus overlay networking technologies like AMT, the TreeDN architecture introduces no new security threats that are not already documented in SSM and the overlay technologies that comprise it. In particular, candidly notes that AMT, like UDP, IGMP, and MLD, provides no mechanisms for ensuring message delivery or integrity, nor does it provide confidentiality, since sources/groups joined through IGMP/MLD could be associated with the particular content being requested. and describe the additional security benefits of using SSM instead of ASM.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK] IP version 4 (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 IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK] This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK] This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality. The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Wikipedia Juniper Networks Juniper Networks Arrcus Arrcus Cisco Systems EdwardJones This document specifies a BGP address family and related procedures that allow BGP to be used for setting up multicast distribution trees. This document also specifies procedures that enable BGP to be used for multicast source discovery, and for showing interest in receiving particular multicast flows. Taken together, these procedures allow BGP to be used as a replacement for other multicast routing protocols, such as PIM or mLDP. The BGP procedures specified here are based on the BGP multicast procedures that were originally designed for use by providers of Multicast Virtual Private Network service. This document also describes how various signaling mechanisms can be used to set up end-to-end inter-region multicast trees. Work in Progress IETF 112 Proceedings Wikipedia DVB Project DVB Document A176 Rev.3 (Fourth edition) IETF 115 Proceedings IETF 110 Proceedings ELVIS-PLUS Independent This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components are required for a GCKS (Group Controller/Key Server) to provide authorized Group Members (GMs) with IPsec group security associations. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. Work in Progress IBC2023 Tech Papers IETF 114 Proceedings Akamai Technologies, Inc. TU Berlin This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. Work in Progress This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. This memo provides information for the Internet community. This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK] In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK] RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast. The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. This document updates RFC 7450, "Automatic Multicast Tunneling" (or AMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined. This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM). This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document is a product of the Path Aware Networking Research Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers. This document contains that catalog and analysis. This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features. This document obsoletes RFC 6830. This document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes. Poetry Foundation

Netverses With inspiration from (and apologies to) Radia Perlman and Joyce Kilmer , the following poem is not intended to provide any normative or informative technical value on TreeDN beyond (mild) amusement for the reader who made it this far in the document: I think that I shall never see
A CDN more lovely than a tree. A tree whose crucial property
Is efficient mass-audience delivery. Using SSM for simplified operation
Of native branches that eliminate duplication. A tree extended by AMT,
Enabling unicast-only receivers full delivery. A tree that scales to reach millions of places
To viably support the highest of bitrate use cases. A CDN is built by folks like me,
But only end users can generate enough demand to necessitate a tree.

Acknowledgements Many thanks to those who have contributed to building and operating the first TreeDN network on the Internet, including , , , , , , , , , , , , , , , , , , and . The writing of this document to describe the TreeDN architecture was inspired by a conversation with and . Thanks also to , , , , and for their thoughtful reviews and suggestions, for his detailed shepherd review, and , , , , , , , , and for their last call reviews.

Authors' Addresses Juniper Networks

2251 Corporate Park Drive Herndon VA 20171 United States of America lenny@juniper.net

Verizon

22001 Loudoun County Parkway Ashburn VA 20147 United States of America chris.lenart@verizon.com

GEANT

City House 126-130 Hills Road Cambridge CB2 1PQ United Kingdom richard.adam@geant.org