Point-to-Multipoint Transport Using Chain Replication in Segment Routing

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 24 April 2021.¶

Copyright Notice

Copyright (c) 2020 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.¶

Table of Contents

1. Introduction

The Segment Routing Architecture [RFC8402] describes segment routing (SR) and its instantiation in two data planes, i.e. MPLS and IPv6. In SR, point-to-multipoint (P2MP) transport is currently achieved by using ingress replication, where a point-to-point (P2P) SR tunnel is constructed from a root node to each leaf node, and every ingress packet is replicated and sent via a bundle of such P2P SR tunnels to all the leaf nodes. Although this approach provides P2MP reachability, it does not consider traffic optimization across the tunnels, as the path of each tunnel is computed or decided independently.¶

An alternative approach would be to use P2MP-tree based transport. Such approach can achieve maximum traffic optimization, but it relies a controller or path computation element (PCE) to provision and manage "replication segments" on branch nodes. The replication segments are essentially P2MP-tree state (i.e. transport tunnel state) on transit routers. Therefore, this approach is not fully aligned with SR's principles of single-point provisioning (at ingress routers and border routers) and stateless core network.¶

This document introduces a new solution for P2MP transport in SR, based on "chain replication". In this solution, P2MP transport is achieved by constructing a set of "P2MP chain tunnels" (or simply "P2MP chains") from a root node to leaf nodes. Each P2MP chain is a single-path tunnel, with a leaf node at tail end and some transit leaf nodes along the path, resembling a chain. The leaf node at the tail end behaves as a normal receiver. Each transit leaf node replicates a packet once for local processing off the chain, and also forwards the original packet down the chain. The root node replicates and sends packets via the set of P2MP chains to all the leaf nodes.¶

As a P2MP chain can reach multiple leaf nodes, it is considered more optimal than the multiple P2P tunnels which would be needed by ingress replication. Compared with ingress replication and the P2MP-tree based approach, this solution can achieve transport efficiency in general, while maintaining the simplicity of SR, including single-point provisioning and stateless core.¶

3. Applicability

The P2MP transport mechanism in this document is generally applicable to all networks. However, it benefits more for certain types of topologies than others. These topologies include ring topologies, linear topologies, topologies with leaf nodes concentrated in geographical sites which can be modeled as leaf groups, etc.¶

The mechanism is stateless in the core of a network. It is transparent to all transit routers. Leaf nodes intended to take advantage of the mechanism will need to support the new forwarding behavior specified in this document. For other leaf nodes, the mechanism has a backward compatibility to allow them to be reached by P2P tunnels using ingress replication. Path computation and P2MP chain construction will need to be supported by a controller or root nodes, depending on where they are performed.¶

The mechanism is applicable to both SR-MPLS [RFC8660] and SRv6 [SRv6-SRH], [SRv6-Programming].¶

The mechanism does not create any state of P2MP tunnel or P2MP tree on routers. Therefore, if leaf nodes need to know the service level context (e.g. source, VPN) of a P2MP stream, they must rely on the information contained in packet headers (or inner headers). In SR-MPLS, service labels may be allocated from a domain-wide common block (DCB) to serve as globally unique context indicators. In SRv6, a root node's IP address or an upstream-assigned context indicator may be encoded in the source address of IPv6 header, or a downstream-assigned context indicator may be encoded in the ARG portion of a service SID.¶

This document introduces a new type of segments, called bud segments (Section 4.1). The segments are generic in nature. They may be used in cases other than P2MP transport, such as traffic mirroring and monitoring, OAM, etc. These use cases are out of the scope of this document.¶

4. P2MP Transport Using Chain Replication

In this document, a P2MP stream associated with a root node and a set of leaf nodes is denoted as {root node, leaf nodes}. It is achieved by using a bundle of P2MP chains covering all the leaf nodes. Each P2MP chain is a single-path tunnel starting from the root node and reaching one or multiple leaf nodes along the path. The tail-end node of the P2MP chain is a leaf node, called a "tail-end" leaf node. Each leaf node traversed by the P2MP chain is called a "transit" leaf node. As a special case, a P2MP chain may have no transit leaf node, but only a tail-end leaf node, essentially becoming a P2P tunnel of ingress replication.¶

R ------ R1 ------ R2 ------ L1 ------ R3 ------ L2 ------ L3



                   R  : root node
                   Li : leaf node
                   Ri : transit router

A tail-end leaf node and a transit leaf nodes have different behaviors when processing a received packet. In particular, a tail-end leaf node processes the packet as a normal receiver. A transit leaf node not only processes the packet as a receiver, but also forwards it downstream along the P2MP chain, hence acting as a "bud node". To achieve this, the transit leaf node needs to replicate the packet, producing two packets, one for forwarding and the other for local processing. Such packet replication happens on every transit leaf node along a P2MP chain. Therefore, it is called "chain replication".¶

This document introduces a new type of segments, called "bud segments", to facilitate the above packet processing on transit leaf nodes. The segment ID (SID) of a bud segment is a "bud-SID".¶

    R ------ R1 -------------------- R2 ------- L1
              |                       |      /
              |                       |    /
              |                       |  /
             R3 -------------------- R4 ------- L2
              |                       |
              |                       |
              |                       |
             R5 -------------------- R6 ------- L3
              |                       |      /
              |                       |    /
              |                       |  /
             R7 -------------------- R8 ------- L4

5. Path Computation for P2MP Chains

P2MP chain path computation for a P2MP stream {root node, leaf nodes} may be performed by a controller or the root node. P2MP chains are single-path tunnels. In general, any P2P path computation algorithm may be extended to serve the purpose. This document does not enforce a particular algorithm.¶

The path computation may consider general metric for shortest paths, or traffic engineering (TE) constraints for TE paths. In addition, this document also considers the following constraints:¶

• - Maximum hops per P2MP chain. This SHOULD be based on the maximum delay allowed for a packet to accumulate before reaching a tail-end leaf node.¶
• - Maximum length of SID list. This SHOULD be based on the maximum header size which a root node may apply to a packet. This is typically a limit of forwarding hardware. Note that a SID list is translated from a computed path. Hence, the SID list's length and the path's hop count are not necessarily the same.¶
• - Maximum leaf nodes per P2MP chain. This may be used to restrict the length of each P2MP chain.¶
• - Maximum hops between two consecutive leaf nodes. This may be used avoid a sparse chain, where an excessive distance between two consecutive leaf nodes will cause a P2MP chain's efficiency to degrade.¶
• - Maximum number of times that a node or link may be traversed by a P2MP chain. This may be used to prevent a node or link from being congested by duplicate traffic.¶

The path computation is generally deterministic in a ring or linear topology. In an arbitrary topology, the path computation may be more controllable by dividing leaf nodes into groups based on geographic location or policies, and computing a separate path for each group. A leaf group may be defined as a sequence (i.e. ordered) or set (i.e. unordered) of leaf nodes, which are treated as loose hops in path computation.¶

6. Protocol Extensions for Bud Segment

The protocol extensions of ISIS, OSPF, and BGP for bud segment advertisement will be specified in the next version of this document.¶

7. Special Purpose Bud Segments

So far, the discussion in this document has been focusing on bud segments that are created on a per SR-MPLS or SRv6 basis on each leaf node. These bud segments indicate generic local processing which is completely based on the inner header of a packet, i.e. after all the SIDs of a P2MP chain are removed by the instruction [3] in Section 4.1. They are applicable to common P2MP transport cases, and hence are considered as the default and general purpose bud segments.¶

The concept of bud segment can also be extended to other cases, where a transit leaf node needs to perform a special kind of local processing for packets, but cannot derive the context from the inner headers of the packets. For example, the node may need to forward the packets over a particular interface or tunnel to some device(s), or to process the packets based on a particular forwarding table or policy, and so on. In such cases, a dedicated bud segment may be created for each special local processing, indicating the context. The bud segment is called a special purpose bud segment.¶

Note that the scaling of special purpose bud segments per leaf node SHOULD be a consideration in network design, as well as the requirement for a controller or ingress router to learn all the special purpose bud segments in a network and apply them in P2MP chain construction.¶

8. IANA Considerations

This document requires IANA to allocate a value from the "Extended Special-Purpose MPLS Label Values" registry for the EoC label.¶

The document also requires IANA registration and allocation for the ISIS, OSPF and BGP extensions for bud segment advertisement. The details will be provided in the next version of this document.¶

9. Security Considerations

This document introduces bud segments for leaf nodes to act as both packet receivers and transit routers. A security attack may target on a leaf node by constructing malicious packets with the node's bud-SID. Such kind of attacks can be defeated by restricting bud segment distribution and P2MP chain construction within the scope of a controller and a given network.¶

10. Acknowledgements

This document leverages work done by Alexander Arseniev, Ron Bonica, and G Sri Karthik Goud.¶

Authors' Addresses