| Internet-Draft | MCTE | July 2026 |
| Kompella | Expires 7 January 2027 | [Page] |
Traffic Engineering (TE) offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. These benefits apply equally to unicast and multicast traffic.¶
This memo proposes multicast traffic-engineering (MCTE), allowing the use of TE for multicast traffic. MCTE is an alternative proposal to point-to-multipoint TE specified in [RFC4875]. The approach in [RFC4875] creates a separate "sub-LSP" from the source to each leaf, resulting in a considerable amount of signaling and state in the network. MCTE, on the other hand, uses the junction approach proposed in MPTE [I-D.kompella-teas-mpte] to create the multicast tree with less signaling and state. [RFC4875] proposes the use of RSVP-TE for signaling and an MPLS data plane for carrying traffic. MCTE allows the use of several control and data planes to signal tunnels and carry traffic.¶
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 7 January 2027.¶
Copyright (c) 2026 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 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.¶
Traffic Engineering (TE) offers a very rich toolkit for managing traffic flows and the paths they take in a network. An operator can assign various attributes such as colors, risk groups and alternate metrics to links in their network; nodes can also have attributes. The operator can then specify constraints on the path(s) through their network that a certain class of traffic ("traffic trunk") should take.¶
A TE path can use these attributes to include or avoid certain nodes or links, increase path diversity, manage resource reservations, improve service experience, and offer protection paths. These benefits apply equally to unicast and multicast traffic. This memo focuses on the latter.¶
In order to satisfy the constraints, TE often uses non-shortest paths. To do so without looplng packets, a tunnel is used. Such tunnels have to be signaled. [RFC2702] describes requirements for MPLS-based TE, and thus is somewhat relevant to this memo. However, that RFC focuses on unicast traffic, and the use of an MPLS tunnel to achieve TE. This memo uses many of the ideas in that RFC, but focuses on multicast traffic and the use of various tunnel types, including MPLS and IP.¶
This memo builds on the ideas introduced in MPTE [I-D.kompella-teas-mpte]. Three notions are of significance:¶
that of a Directed Acyclic Graph (DAG);¶
that of a junction: a junction J is a node in a DAG with previous hops and next hops; on receiving traffic from a previous hop, J forwards traffic to one of its next hops; and¶
that of direct signaling from the signaling source (SS) to each junction in the DAG to provision the tunnel.¶
One big difference:¶
In MPTE, traffic at a junction is load-balanced across the next hops, thus only one is used for any given packet. In MCTE, traffic is replicated across all next hops. In other words, MPTE is for unicast traffic; MCTE is for multicast traffic.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section provides definitions for terms and abbreviations that have a specific meaning to the MCTE protocol and that are used throughout this memo.¶
desired properties of paths between ingresses and egresses.¶
A modification to SPF to take into account TE constraints.¶
a directed graph that has no cycles. The result of a multipath SPF or CSPF computation is a DAG.¶
a set of nodes and directed links. A network is represented by a directed graph.¶
an end node of an MCTE DAG.¶
a starting node of an MCTE DAG.¶
an MPLS tunnel from an ingress to one or more egresses.¶
A (directed) edge between two nodes. A pair of nodes may have 0 or more links between them. A link between nodes u and v will be denoted by (u, v, i), where i is u's oif for the link. A link may have associated attributes, in particular, a metric.¶
a positive number describing the contribution of a link to the oveall path length.¶
MCTED computer: the entity computing the MCTED, typically the ingress (if there is a single ingress) or a Path Computation Element¶
multicast TE with path constraints from an ingress to one or more egresses, used for sending traffic from the ingress to all egresses.¶
an MCTE DAG resulting from CSPF-type computation on MCTE constraints.¶
MCTE protocol: the protocol used to signal MCTETs.¶
MCTE tunnel: the signaled (and hence, forwarding) entity associated with an MCTED.¶
a vertex of a graph. A node may have associated attributes.¶
a unique number (oif) assigned by a node for each outgoing link it has.¶
an entity capable of performing CSPF on behalf of another node, the path computation client.¶
the sum of the metrics of the links that constitute path p, denoted by len(p)¶
nodes and/or links that share "risk" (e.g., have a common power feed, or use a common fiber conduit)¶
a path between a pair of nodes u, v with minimum length. The set of shortest paths between u and v is a DAG, denoted by sp(u, v). The length of a shortest path from u to v is denoted by min(u, v)¶
an algorithm for computing the shortest path DAG from an ingress to an egress; typically refers to Dijkstra's algorithm for computing shortest paths between a given pair of nodes, or pairwise between all nodes.¶
an entity responsible for signaling an MCTET¶
a path p from u to v has slack s if len(p) = min(u, v) + s.¶
a methodology for mapping traffic trunks to given paths or DAGs across a network.¶
a unidirectional aggregate of traffic flows from an ingress to a set of egresses that is treated identically in the forwarding plane.¶
entity having the specifications of the MCTET¶
Constraints are an intent-based specification of acceptable paths that a traffic trunk may take from the ingress to the egresses. Constraints are thus an abstract way to control the resources that a particular traffic trunk uses.¶
One way to do this is to add "resource class attributes" or "colors" [RFC2702] to links, and then specify "include" and "exclude" sets. An include set means that all links that a path traverses must contain at least one element of the include set. An exclude set means that no link in the path can contain any color from the exclude set.¶
Another way is to specify the bandwidth that a traffic trunk is expected to carry. This means that all links in the path must have that much available capacity. Packets exceeding the bandwidth can be forwarded normally, marked as droppable, or dropped.¶
One very useful aspect of TE is the ability to specify that a path must be link- or node- or shared-risk-disjoint from another path. That means that the two paths do not have links or nodes or "shared risk groups". Additionally, one can build protection paths for an existing path to protect against link or node failures [RFC4090]. This is important since there is usually just a single path from ingress to egress, meaning that a link or node failure will result in dropped traffic until the path is restored.¶
The shortest path first algorithm is an easy-to-implement and very efficient algorithm whereby all routers in a network can agree on the path that a packet to a particular destination should take. That means if all routers are agreed (roughly) on the topology and metrics of the network, they will forward packets in a loop-free manner to all destinations -- without the need for signaling or tunnels. However, an MCTED will not contain the same paths -- some paths may be rejected as they don't satisfy the constraints; other paths may be used even though they are not shortest paths. Thus, to route packets in a traffic trunk over a computed MCTED, a tunnel is typically used. This tunnel will have to be signaled to the MCTED nodes. The tunnel may be MPLS- or IP-based.¶
In a later version of this memo, we will offer details of the types of tunnels to be used for MCTE.¶
Here are the steps to create an MCTE tunnel:¶
Define the traffic trunk for the MCTET. Examples include "multicast destination 224.x.y.z" or "gold class traffic belonging to MVPN foo".¶
Define the constraints of the traffic trunk, including:¶
the ingress, and the bandwidth entering the DAG at each ingress;¶
the egresses;¶
metric to minimize -- this could capture delay or fiber length;¶
criteria of acceptable nodes and links for the DAG, including link colors and shared risk groups (SRGs).¶
This information is given to the Tunnel Originator (TO).¶
The TO sends this information to the MCTE Computer (MC).¶
The MC computes a DAG that satisfies the constraints. The DAG consists of a set of junctions; these are sent to the Signaling Source (SS).¶
The SS instantiates the MCTET by sending signaling messages to all the junctions.¶
When ready, the SS tells the ingress that the MCTET meeting the DAG constraints is ready for traffic.¶
The ingresses map traffic matching the traffic trunk to the MCTET.¶
Computation (possibly using a variant of CSPF) of an MCTED is done by the MC, which may be an ingress or a PCE [RFC4655]. (This memo does not specify such an algorithm.) Signaling primarily occurs between the SS and each junction node. Auxiliary signaling may occur among junction nodes.¶
In this memo, a node is identified by its IP loopback address. A link from node u to node v is identified by u's loopback address and its (4-octet) outgoing interface index (oif), a unique identifier for the link allocated by u. oifs are usually exchanged in the TE extensions of an IGP. (A link also has a (4-octet) incoming interface index, the iif. For neighbors u and v, the correlation between u's oif and v's iif is typically done by the IGP. iifs are not used in this memo.) For now, this memo only deals with point-to-point links; a future revision will describe the use of multi-access links.¶
An MCTED is identified by a unique (4-octet) ID (the MID) assigned to the MCTED by the MC. As an MCTED can change over its lifetime, it is assigned a version number starting at 0 and incremented every time the MCTED is recomputed. Thus, a full MCTED ID (the FID) consists of <MC, MID, version>.¶
An MCTED consists of two or more "junction nodes". A junction node can have one of five types:¶
a pure ingress node has zero incoming links and one or more outgoing links in the MCTET. Traffic routed on a MCTET enters at the ingress.¶
a pure egress node has one or more incoming links and zero outgoing links in the MCTET. Traffic routed on a MCTET leaves at an egress.¶
a bud egress node where traffic can either exit the MCTET or go on to another egress node.¶
a "regular" junction node has one or more incoming links and one or more outgoing links. Traffic does not enter or leave at such a node: it comes from a phop and goes to an nhop.¶
A junction node v consists of v, its previous hops (phops) and its next hops (nhops). A phop is specified by an incoming link of v: (u, v, oif1); an nhop by an outgoing link of v: (v, w, oif2). Note that, since links are point-to-point, it is sufficient to specify (u, oif1) ((v, oif2)) for a phop (nhop, respectively). The nodes u (and w) are loosely referred to as a phop (and nhop) of v, although strictly speaking the link should be included. A pure ingress has no phops and a pure egress has no nhops.¶
The MCTED is broken down into a set of junction nodes. A junction node v is specified by:¶
A designated entity, the Tunnel Originator (TO), is given the specifications of the MCTET: the ingress, the egresses and the constraints. The TO is typically the tunnel ingress or a PCE. The TO sends the tunnel specification to the MC. The MC computes the MCTED (as a list of junctions) and returns this to the TO. The TO then sends the list of junctions to the Signaling Source (SS) which provisions the tunnel.¶
Note that TO, MC and SS are functional blocks; they may reside on separate nodes or co-reside on the same node. For example, a single node X may be the TO and SS but decide to delegate computation to a (remote) PCE. X then gets the results via PCEP and signals the tunnel. Other permutations are possible.¶
Several signaling protocols are being extended to provision MCTETs: RSVP-TE, PCEP and BGP. Details are forthcoming.¶
Provisioning messages (to create, update and delete a tunnel) are sent from the Signaling Source (SS) to each junction node. Notifications are sent from each junction node to the SS to send updates on the state of that node with respect to the MCTET. Label messages (when needed) are sent hop-by-hop from egresses to their phops and further upstream in an ordered fashion.¶
In special scenarios, a node may send a message to one or more of its nhops.¶
A MCJUNCTION message contains the following information elements:¶
a unique identifier for an MCTE tunnel. This usually consists of the TO ID and a unique ID in the namespace of the TO. It also includes a version number to distinguish among instances of a tunnel as it is undergoes updates. The companion signaling documents will describe the MCTET ID in more detail.¶
various types of tunnels are used, so each node must be told which type of tunnel this MCTET consists of.¶
provides details for the MCTET.¶
specifies the bandwidth incoming to the junction in Megabits per second (Mbps).¶
A LABEL message is used to let each junction know what to use to forward packets in the MCTET. A LABEL message is sent from an egress junction node to each of its phops. A pure ingress node never sends a LABEL message as it has no phops. The LABEL message carries the MCTET ID and a label, which can be an MPLS label or an IP destination address.¶
From a forwarding point of view, an ingress's job is to:¶
identify the traffic trunk, i.e., the set of packets that are to be sent via the MCTET;¶
encapsulate the packets into the signaled tunnel type;¶
forward the packet to all the ingress's next hops.¶
FIB entries have a lookup portion (the "routes") and a next hop portion. In all cases, the next hop at junction J consists of all of J's nhops as specified by the SS in the MCJUNCTION message. J's forwarding action is to replicate packets that match the incoming route, and forward them to all the next hops.¶
For an ingress node, the routes define the traffic trunk meant to be carried by the MCTET.¶
For a non-ingress node v, the routes identify the MCTET from its phop.¶
A node N is capable of Graceful Restart if a) it can maintain control plane state across restarts; and b) it can maintain forwarding state across restarts. If N is capable of Graceful Restart, an MCTE DAG going through N can continue functioning while N restarts. While N is restarting, new JUNCTION/LABEL messages will be dropped or ignored; new MCTE DAGs passing through N will not be established. Once restart is complete, N will send an OPEN message and re-establish connections will all its peers (or all the MCTEP Reflectors). Thereafter, N can participate in new DAGs passing through it by processing received JUNCTION messages.¶
More details will be described in a future version.¶
None. The related protocol documents will have IANA requirements.¶