Multicast over SRv6 networks

Segment Routing, as defined in , is a source-routing paradigm that simplifies network operations and enhances scalability. Segment routing is defined for unicast. The application of the source-route concept to Multicast is declared out-of-scope in . Since multicast distribution is orthogonal to segment routing, classic multicast solutions are leveraged to provide multicast services in a segment routing network. In SR-MPLS networks, operators traditionally leveraged solutions based on IPv4 or MPLS data planes for multicast distribution, as both data planes were available in these networks. However, with the advent of SRv6, network use a unifying IPv6 data plane end-to-end, replacing the need for MPLS or IPv4. While migrating the networks to SRv6, multicast services can still use the MPLS or IPv4 data planes, as ships-in-the-night. But the target is an IPv6-only SRv6 network. This document focuses on deploying multicast in IPv6-only networks and describes possible solutions. Key Topics Addressed: Leveraging IPv6’s native multicast capabilities for SRv6 networks. Distributed and centralized control planes for multicast. Overlay solutions for supporting multicast in IPv6-only networks.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . PIM: Protocol Independent Multicast PIM-SM: PIM Sparse Mode PIM-SSM: PIM Source Specific Multicast MVPN: Multicast Virtual Private Network MBGP: Multi-protocol Border Gateway Protocol IGMP: Internet Group Management Protocol MLD: Multicast Listener Discovery I-PMSI : Inclusive P-Multicast Service Interface S-PMSI: Selective P-Multicast Service Interface P(S,G) : Multicast flow (S,G) in provider network C(S,G) : Multicast flow (S,G) in customer network All the terminology from is also applicable in this draft.

Segment Routing over IPv6 micro-segments (SRv6 uSID) enables end-to-end service delivery across domains using the IPv6 protocol without additional shim layers or gateways. This makes the IPv6 protocol fully self-sufficient for unicast services. And its built-in multicast capabilities makes IPv6 also self-sufficient for multicast distribution.

To forward multicast packets, multicast forwarding state must be set up on the nodes in the multicast distribution trees. A typical IPv6 multicast route comprises: (Source Address, Group Address) or (S, G) Identifying the distribution tree Source (S): The IPv6 address of the streaming device, which can also be * (any source) Group (G): The multicast IPv6 group address Incoming interface : The interface receiving the multicast packets, also known as the Reverse Path Forwarding (RPF) interface Downstream interfaces : The set of interfaces where the multicast packets will be forwarded

Like IPv6 unicast routes, IPv6 multicast routes can be instantiated dynamically through control plane protocols (e.g., PIM) or north-bound APIs. This document focuses only on PIM instantiated multicast forwarding state and complimentary document will cover north bound API route instantiation.

Protocol Independent Multicast Sparse Mode (PIM-SM) is the most common multicast routing protocol, supporting both Any Source Multicast (ASM) and Source-Specific Multicast (SSM). PIM-SM builds multicast distribution trees by leveraging the RPF interface derived from unicast routing tables. PIM-SSM is a subset of PIM-SM that does not use the Rendezvous Points (RPs) but instead requires that receivers know the (source, group) pair and signal that explicitly. Most current routing platforms support PIM-SM. As its name implies, PIM is independent of the underlying unicast routing protocol and leverages the unicast routing tables to establish the multicast trees. It builds a distribution tree by joining the tree via the RPF interface, which is the interface that would be used to reach the source via unicast routing. For a detailed introduction to PIM-SM and PIM-SSM, refer to Sections 3 and 4.8 of .

By default, a multicast source advertised in the IGP is reachable via the IGP shortest-path (SPT algorithm 0). Therefore, by default, the distribution tree follows the IGP shortest-path tree. Flex-Algo (, ) enables using customized algorithms to compute IGP shortest paths. When a multicast source (S1) is advertised with a specific Flex-Algo (e.g., FA128), PIM-SM builds the distribution trees rooted at S1 along the shortest paths defined by the Flex-Algo FA128. This effectively traffic-engineers the path of the multicast packets streamed by S1. In an example use case, an operator uses FA128 to optimize the min-delay link metrics, providing low-delay paths. The multicast distribution trees using FA128 provide low-delay distribution, improving real-time applications like video streaming.

Certain multicast use cases require explicit control over distribution trees, beyond what is possible with PIM combined with Flex-Algo. Very specific or complex traffic-engineered distribution trees may not be practical or possible using PIM. Dynamic distributed protocols may be undesirable in a network where strict determinism is required. Or the network operator wants to avoid the PIM protocol mechanisms (such as messages and RPF selection). In these scenarios, a centralized controller can compute and instantiate multicast forwarding entries on the routers in the distribution trees. The controller maintains the IPv6 multicast forwarding entries and updates them when needed, e.g., following a topology change. These forwarding entries are explicitly instantiated native IPv6 multicast forwarding entries. They can be statically configured by the operator like static unicast routes or explicitly instantiated by a controller via a north-bound API. The benefits of centralized control are that it enables complex traffic-engineered multicast trees and it removes the dependence on PIM protocol mechanisms. On the data plane this solution still uses the well-know native IPv6 multicast forwarding entries. The explicitly instantiated distribution trees and PIM-created trees can coexist in the network by using different multicast sources and groups for both mechanisms.

Legacy IPv4 multicast implementations are often difficult or impossible to migrate to IPv6. Some services require multicast (IPv4 or IPv6) within a VPN, necessitating an overlay solution. These solutions leverage the native IPv6 multicast underlay by encapsulating the overlay IP multicast packets in IPv6 using IP-in-IPv6 encapsulation without intermediate shim layers. The native IPv6 underlay transport distribution trees can be established using any of the mechanisms described in sections 6 and 7. To deploy overlay IP multicast services in an IPv6-only network, existing solutions are used. There are no SRv6-specific requirements for these solutions. These solutions enable transporting overlay IP multicast (IPv4 and IPv6), in a Global Table Multicast (GTM) or MVPN context, over an IPv6-only network, encapsulated as IP-in-IPv6. As existing native IPv6 capabilities are leveraged, there are no SRv6 specific procedures for this solution. Specifically, the following RFCs are relevant in this context: specifies the architecture for Multicast Virtual Private Networks (MVPNs) in MPLS/BGP IP VPN environments. While it includes MPLS in its title, it also provides significant details relevant to IP-only solutions for MVPNs. The document describes how multicast traffic is transported over VPNs, how control plane signaling establishes the multicast forwarding paths, and the encapsulation mechanisms for data plane traffic. defines the specific BGP encodings and procedures for signaling multicast routing information in MVPNs as specified in . updates to ensure that service providers can use either IPv4 or IPv6 addresses for internal infrastructure (e.g., PE-to-PE or PE-to-P router communication) in the context of multicast VPNs. This is particularly relevant in IPv6-only transport networks. RFC 7716 extends the MVPN procedures defined in to support Global Table Multicast (GTM), i.e., multicast routing in the global routing table rather than within the context of VPNs. This is particularly relevant in IPv6-only networks that require IPv4 multicast services without using VPNs. addresses the challenge of advertising IPv4 NLRIs in BGP updates when the next hop is an IPv6 address. This is particularly relevant for enabling IPv4 routing in IPv6-only networks. As an example, the following solution could be used to provide an MVPN service in an SRv6 network. Note that other solutions may equally be possible. The native IPv6 multicast provider distribution trees (P-Multicast Service Interfaces (PMSIs) or P-tunnels) are build using PIM-SSM, signaling the PMSI A-D routes in MP-BGP. PIM is used to signal multicast participation between CE and PE. MP-BGP is used to signal the customer multicast routes between the MVPN PEs. The overlay customer multicast packets are transported over the network using IP-in-IPv6 encapsulation, traversing the underlay PMSI distribution trees.

IP in IP encapsulation is used when sending IPv4 multicast traffic though provider multicast tree. The following diagram shows the progression of the packet as it enters and leaves the service provider network.

Packet Received Packet in Transit Packet forwarded at Ingress PE in the service by egress PEs provider network +---------------------+ | P-IPv6 Header | +-------------------+ +---------------------+ +-------------------+ | C-IPv4 header | | C-IPv4 Header | | C-IPv4 header | +-------------------+ >>>>>>>>>> +---------------------+ >>>>>>>>>>>> +-------------------+ | C-Payload | | C-Payload | | C-Payload | +-------------------+ +---------------------+ +-------------------+ The “Next Header” field in the P-IP IPv6 Header MUST be set to 4 Since the C-IP header is an IPv4 header.

Packet Received Packet in Transit Packet forwarded at Ingress PE in the service by egress PEs provider network +---------------------+ | P-IPv6 Header | +-------------------+ +---------------------+ +-------------------+ | C-IPv6 header | | C-IPv6 Header | | C-IPv6 header | +-------------------+ >>>>>>>>>> +---------------------+ >>>>>>>>>>>> +-------------------+ | C-Payload | | C-Payload | | C-Payload | +-------------------+ +---------------------+ +-------------------+ The “Next Header” field in the P-IP IPv6 Header MUST be set to 41 Since the C-IP header is an IPv6 header.

Informational draft and nothing required from IANA.

There is no new security issue imposed by this draft on top of , . , , .

Kris Michielsen Anuj Budhiraja Zafar Ali Zubair Khan