Internet-Draft NSR-multicast June 2024
Zhang, et al. Expires 15 December 2024 [Page]
Workgroup:
mboned
Internet-Draft:
draft-zzhang-mboned-non-source-routed-sr-mcast-00
Published:
Intended Status:
Informational
Expires:
Authors:
Z. Zhang
Juniper Networks
I. Wijnands
Arrcus
H. Bidgoli
Nokia
Y. Liu
China Mobile

Non-source-routed Multicast in SR Networks

Abstract

With Segment Routing (SR) architecture, a unicast flow can be source-routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane.

Status of This Memo

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 15 December 2024.

Table of Contents

1. Introduction

With Segment Routing (SR) architecture [RFC8402], a unicast flow can be source-routed through an SR network following an explicit path specified in the packet, without the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network.

This document summarizes options for non-source-routed multicast in an SR network, including traditional multicast technologies, BIER, and various SR specific solutions. The pros and cons of each solution are listed for considerations by operators and vendors.

Source-routed multicast in an SRv6 network has also been discussed in IETF [https://datatracker.ietf.org/doc/bofreq-liu-multicast-source-routing-over-ipv6msr6/] and some work is ongoing. However, that is outside the scope of this document.

2. Traditional Multicast Technologies

Traditional multicast technologies include PIM [RFC7761], RSVP-TE P2MP [RFC4875], and mLDP [RFC6388]. They all require per-tree state on nodes on the tree, and the corresponding protocols to signal and maintain the state. An incoming packet's IP header or MPLS label is looked up, and the packet is forwarded according to the matched state.

While SR allows simplification of state, protocols and centralized SDN-control, the traditional methods of delivering multicast traffic run contrary to those SR goals.

An alternative is Ingress Replication (IR) - an upstream node of a multicast packet tunnels individual copies to some downstream nodes across some intermediate nodes. In an SR network, the unicast tunnels used for IR could be traditional IP/MPLS tunnels or could be SR tunnels (referred to as SR policies), which could be MPLS/SRv6-based.

While with IR there is no per-tree state on those intermediate nodes, multiple copies of the same packet may be sent over the same link. If efficient replication is required, PIM/mLDP/RSVP-TE P2MP can still be used for multicast even in an SR network. Deploying SR in the network does not mandate changing the solution that is in place for Multicast.

While mLDP uses the same LDP Session (and protocol packet encoding) as used by unicast and there is code sharing between LDP and mLDP with regards to neighbor discovery, session setup and Label allocation management, the protocol logic for setting up mLDP tunnel is completely different. It is understood that there is a desire to remove LDP from the network when SR is deployed, but there is really no problem to continue to run mLDP for Multicast. [RFC7473] documents a solution where LDP can be run in mLDP-Only mode by simply not exchanging any Unicast bindings.

Similarly, RSVP-TE P2MP tunnel setup is orthogonal from P2P tunnel setup as well. It can be used for multicast even in an SR network if bandwidth reservation and/or per-tunnel explicit path are required.

3. Bit Index Explicit Replication

Bit Index Explicit Replication (BIER) [RFC8279] is a new multicast technology that achieves efficient replication as with PIM tree or mLDP/RSVP-TE P2MP tunnels but without requiring per-tree/tunnel state in the transit nodes as with IR.

Even though BIER is designed and developed independent of SR, it is a perfect fit for an SR network because it shares with SR the number one principle of "no per-flow state". A BIER domain can be used as provider/underlay tunnels for MVPN/EVPN-BUM (just like traditional PIM tree or mLDP/RSVP P2MP tunnels), or can be part of end-to-end PIM trees [I-D.ietf-bier-pim-signaling] (similiar to mLDP inband signaling [RFC6826]).

However, BIER uses a new forwarding plane that cannot be implemented on many deployed routers. On the other hand, the entry point barrier is decreasing and BIER is becoming more realistic with the following developments:

4. Multicast Trees Set up by Other Means

Some operators may accept that they need to maintain per-tree state in their SR network for efficient multicast, and their applications do not require too much per-tree multicast state. However, since unicast no longer needs LDP or RSVP-TE protocol in an SR network, they really want to remove PIM/LDP/RSVP-TE protocol from their networks, and make use of controllers. In that case, the multicast trees could be set up statically from management plane (e.g., netconf), or dynamically via BGP/PCEP [I-D.ietf-bess-bgp-multicast] [I-D.ietf-bess-bgp-multicast-controller] [I-D.ietf-idr-sr-p2mp-policy] [I-D.ietf-pce-sr-p2mp-policy], as described in [I-D.ietf-pim-sr-p2mp-policy].

5. SR Specific Solutions

There are two multicast solutions that are specifically tied to SR technologies - "SR-P2MP" [I-D.ietf-pim-sr-p2mp-policy] and "Spray".

  1. SR-P2MP refers to tunnels setup not by mLDP or RSVP-TE. It could be statically configured, or instantiated from a controller.

  2. Spray is Ingress Replication with SRv6. Instead of regular IP/MPLS tunneling, an SRv6 header encodes the "tunnel end" and the original destination multicast address. When the packet arrives at the tunnel end, the original multicast address is restored from the SRv6 header.

The above methods are really no different from existing technologies. Spray is just IR with a different encapsulation (e.g. SRv6). While SR-P2MP does not use existing tree signaling protocol, it still requires per-tree forwarding state on the tree nodes (roots, leaves and branching points), and it is identical to mLDP/RSVP P2MP tunnels in the MPLS data plane on those tree nodes.

mLDP/PIM trees are typically hop-by-hop - the tree nodes are directly connected, though tunnels can be used between mLDP, PIM and SR-P2MP tree nodes to avoid tree states on the non-branching nodes between tree nodes. This is important in some deployment scenarios (e.g., mobile user plane transport) where the replication points are scattered with many non-replication points among them.

SR-P2MP can use both MPLS and SRv6 data plane. The next section discusses some SRv6 aspects of SR-P2MP.

6. IPv6 Considerations

Some operators run IPv6/SRv6 networks without using MPLS at all. As a result, Ingress Replication or SR-P2MP with MPLS data plane is not an option and IPv6 based forwarding must be used. There are two options in this case - traditional IPv6 multicast (signaled by either PIM or BGP [I-D.ietf-bess-bgp-multicast] [I-D.ietf-bess-bgp-multicast-controller]) and SRv6-P2MP (SR-P2MP with SRv6 data plane).

SR-P2MP with MPLS data plane (SRmpls-P2MP) is identical to mLDP/RSVP-P2MP in the data plane of the tree nodes, in that incoming multicast traffic carries a tree-identifing label and is replicated with outgoing label stacks. The label stack includes a label that identifies the tree to the downstream node, and optional labels that leads the traffic to the downstream node.

SRv6-P2MP is very similar to SRmpls-P2MP in the data plane. Multicast traffic has an IPv6 header and the destination address has the LOC:FUNCT:ARGS encoding format for SRv6 [RFC8986]. The FUNCT bits correspond to the tree-identifying label in SRmpls-P2MP, and the LOC bits get the traffic from an upstream node to a downstream node (which could be directly or indirectly connected).

SRv6-P2MP allows native tunneling of multicast traffic between indirectly connected upstream and downstream nodes, but at the cost of changing destination address at each tree node, which requires either programmable ASIC or new generation of non-programmable ASIC. It also requires a new control plane that involves controller-based calculation and signaling of the tree state.

On the other hand, traditional IPv6 multicast is mature in both control plane and data plane. PIM has been widely deployed for many years without platform restrictions, and the PIM-SSM protocol is very straightforward without the complexity of PIM-ASM.

Even if an operator wants to use controller based calculation and signaling, or does not want to run PIM protocol, traditional multicast can still be used with BGP/controller-based signaling as specified in [I-D.ietf-bess-bgp-multicast] and [I-D.ietf-bess-bgp-multicast-controller].

7. Summary

There is no one-for-all option when it comes to multicast in an SR network. Depending on specific deployment scenarios and requirements, the following could be considered in order when source-routing is not used:

In case of MPLS based P2MP, a Binding SID could be optionally used to direct traffic to the root of the tunnel.

8. Security Considerations

This informational document does not introduce new security risks.

9. Acknowledgements

The authors thank Eric Rosen, Tony Przygienda, and John Drake for their reviews, comments and suggestions.

10. Informative References

[I-D.ietf-bess-bgp-multicast]
Zhang, Z. J., Giuliano, L., Patel, K., Wijnands, I., Mishra, M. P., and A. Gulko, "BGP Based Multicast", Work in Progress, Internet-Draft, draft-ietf-bess-bgp-multicast-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-08>.
[I-D.ietf-bess-bgp-multicast-controller]
Zhang, Z. J., Raszuk, R., Pacella, D., and A. Gulko, "Controller Based BGP Multicast Signaling", Work in Progress, Internet-Draft, draft-ietf-bess-bgp-multicast-controller-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-12>.
[I-D.ietf-bier-multicast-as-a-service]
Zhang, Z. J., Rosen, E. C., Awduche, D. O., Shepherd, G., Zhang, Z., and G. S. Mishra, "Multicast/BIER As A Service", Work in Progress, Internet-Draft, draft-ietf-bier-multicast-as-a-service-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-multicast-as-a-service-03>.
[I-D.ietf-bier-php]
Zhang, Z. J., "BIER Penultimate Hop Popping", Work in Progress, Internet-Draft, draft-ietf-bier-php-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-php-11>.
[I-D.ietf-bier-pim-signaling]
Bidgoli, H., Xu, F., Kotalwar, J., Wijnands, I., Mishra, M. P., and Z. J. Zhang, "PIM Signaling Through BIER Core", Work in Progress, Internet-Draft, draft-ietf-bier-pim-signaling-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-pim-signaling-12>.
[I-D.ietf-bier-tether]
Zhang, Z. J., Warnke, N., Wijnands, I., and D. O. Awduche, "Tethering A BIER Router To A BIER incapable Router", Work in Progress, Internet-Draft, draft-ietf-bier-tether-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-tether-05>.
[I-D.ietf-idr-sr-p2mp-policy]
Bidgoli, H., Voyer, D., Stone, A., Parekh, R., Krier, S., and S. Agrawal, "Advertising p2mp policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-sr-p2mp-policy-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-p2mp-policy-00>.
[I-D.ietf-pce-sr-p2mp-policy]
Bidgoli, H., Voyer, D., Rajarathinam, S., Budhiraja, A., Parekh, R., and S. Sivabalan, "PCEP extensions for p2mp sr policy", Work in Progress, Internet-Draft, draft-ietf-pce-sr-p2mp-policy-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-p2mp-policy-06>.
[I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. J. Zhang, "Segment Routing Point-to-Multipoint Policy", Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-policy-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-09>.
[I-D.przygienda-bier-migration-options]
Przygienda, T. and Z. J. Zhang, "BIER Migration Frameworks", Work in Progress, Internet-Draft, draft-przygienda-bier-migration-options-00, , <https://datatracker.ietf.org/doc/html/draft-przygienda-bier-migration-options-00>.
[RFC4875]
Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, , <https://www.rfc-editor.org/info/rfc4875>.
[RFC6388]
Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, , <https://www.rfc-editor.org/info/rfc6388>.
[RFC6826]
Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6826, DOI 10.17487/RFC6826, , <https://www.rfc-editor.org/info/rfc6826>.
[RFC7473]
Raza, K. and S. Boutros, "Controlling State Advertisements of Non-negotiated LDP Applications", RFC 7473, DOI 10.17487/RFC7473, , <https://www.rfc-editor.org/info/rfc7473>.
[RFC7761]
Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, , <https://www.rfc-editor.org/info/rfc7761>.
[RFC8279]
Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, , <https://www.rfc-editor.org/info/rfc8279>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.

Authors' Addresses

Zhaohui Zhang
Juniper Networks
IJsbrand Wijnands
Arrcus
Hooman Bidgoli
Nokia
Yisong Liu
China Mobile