Multicast Traffic Engineering
draft-kompella-teas-mcte-00

TEAS WG                                                      K. Kompella
Internet-Draft                                                       HPE
Intended status: Standards Track                             6 July 2026
Expires: 7 January 2027

                     Multicast Traffic Engineering
                      draft-kompella-teas-mcte-00

Abstract

   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.

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 7 January 2027.

Kompella                 Expires 7 January 2027                 [Page 1]
Internet-Draft                    MCTE                         July 2026

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Definition of Commonly Used Terms . . . . . . . . . .   4
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Constraints . . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Protection  . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Tunnels . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  MCTED . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Tunnel Provisioning . . . . . . . . . . . . . . . . . . .   9
     3.3.  Signaling Overview  . . . . . . . . . . . . . . . . . . .   9
   4.  Signaling . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Message Flow  . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Message Types . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  MCJUNCTION  . . . . . . . . . . . . . . . . . . . . .  10
       4.2.2.  MCLABEL . . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.3.  MCNOTIFY  . . . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Forwarding State  . . . . . . . . . . . . . . . . . . . .  11
   5.  Graceful Restart  . . . . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

Kompella                 Expires 7 January 2027                 [Page 2]
Internet-Draft                    MCTE                         July 2026

1.  Introduction

   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:

   1.  that of a Directed Acyclic Graph (DAG);

   2.  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

   3.  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.

Kompella                 Expires 7 January 2027                 [Page 3]
Internet-Draft                    MCTE                         July 2026

1.1.  Terminology

   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.

1.1.1.  Definition of Commonly Used Terms

   This section provides definitions for terms and abbreviations that
   have a specific meaning to the MCTE protocol and that are used
   throughout this memo.

   constraints:  desired properties of paths between ingresses and
      egresses.

   constrained shortest path first (CSPF):  A modification to SPF to
      take into account TE constraints.

   directed acyclic graph (DAG):  a directed graph that has no cycles.
      The result of a multipath SPF or CSPF computation is a DAG.

   directed graph:  a set of nodes and directed links.  A network is
      represented by a directed graph.

   egress:  an end node of an MCTE DAG.

   ingress:  a starting node of an MCTE DAG.

   label-switched path (LSP):  an MPLS tunnel from an ingress to one or
      more egresses.

   link:  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.

   metric:  a positive number describing the contribution of a link to
      the oveall path length.

   MC:  MCTED computer: the entity computing the MCTED, typically the
      ingress (if there is a single ingress) or a Path Computation
      Element

   MCTE:  multicast TE with path constraints from an ingress to one or
      more egresses, used for sending traffic from the ingress to all
      egresses.

Kompella                 Expires 7 January 2027                 [Page 4]
Internet-Draft                    MCTE                         July 2026

   MCTED:  an MCTE DAG resulting from CSPF-type computation on MCTE
      constraints.

   MCTEP:  MCTE protocol: the protocol used to signal MCTETs.

   MCTET:  MCTE tunnel: the signaled (and hence, forwarding) entity
      associated with an MCTED.

   node:  a vertex of a graph.  A node may have associated attributes.

   outgoing interface (oif):  a unique number (oif) assigned by a node
      for each outgoing link it has.

   Path Computation Element (PCE):  an entity capable of performing CSPF
      on behalf of another node, the path computation client.

   path length:  the sum of the metrics of the links that constitute
      path p, denoted by len(p)

   shared risk group (SRG):  nodes and/or links that share "risk" (e.g.,
      have a common power feed, or use a common fiber conduit)

   shortest path:  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)

   shortest path first (SPF):  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.

   signaling source (SS):  an entity responsible for signaling an MCTET

   slack:  a path p from u to v has slack s if len(p) = min(u, v) + s.

   traffic engineering (TE):  a methodology for mapping traffic trunks
      to given paths or DAGs across a network.

   traffic trunk:  a unidirectional aggregate of traffic flows from an
      ingress to a set of egresses that is treated identically in the
      forwarding plane.

   tunnel originator (TO):  entity having the specifications of the
      MCTET

2.  Overview

Kompella                 Expires 7 January 2027                 [Page 5]
Internet-Draft                    MCTE                         July 2026

2.1.  Constraints

   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.

2.2.  Protection

   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.

2.3.  Tunnels

   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.

Kompella                 Expires 7 January 2027                 [Page 6]
Internet-Draft                    MCTE                         July 2026

3.  Operation

   Here are the steps to create an MCTE tunnel:

   1.  Define the traffic trunk for the MCTET.  Examples include
       "multicast destination 224.x.y.z" or "gold class traffic
       belonging to MVPN foo".

   2.  Define the constraints of the traffic trunk, including:

       1.  the ingress, and the bandwidth entering the DAG at each
           ingress;

       2.  the egresses;

       3.  metric to minimize -- this could capture delay or fiber
           length;

       4.  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).

   3.  The TO sends this information to the MCTE Computer (MC).

   4.  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).

   5.  The SS instantiates the MCTET by sending signaling messages to
       all the junctions.

   6.  When ready, the SS tells the ingress that the MCTET meeting the
       DAG constraints is ready for traffic.

   7.  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.

Kompella                 Expires 7 January 2027                 [Page 7]
Internet-Draft                    MCTE                         July 2026

3.1.  MCTED

   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:

   1.  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.

   2.  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.

   3.  a bud egress node where traffic can either exit the MCTET or go
       on to another egress node.

   4.  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:

Kompella                 Expires 7 January 2027                 [Page 8]
Internet-Draft                    MCTE                         July 2026

   1.  bandwidth (coming in to and going out of v)

   2.  a list of phops of v

   3.  a list of nhops of v, with corresponding load balancing shares

3.2.  Tunnel Provisioning

   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.

3.3.  Signaling Overview

   The SS signals the creation or update of an MCTE tunnnel by sending
   to each junction node v a JUNCTION message consisting of:

   1.  the MCTET ID

   2.  the junction node specification

   3.  the tunnel type

   4.  some flags

   After v parses this specification, installs FIB state for the
   junction.

4.  Signaling

   Several signaling protocols are being extended to provision MCTETs:
   RSVP-TE, PCEP and BGP.  Details are forthcoming.

Kompella                 Expires 7 January 2027                 [Page 9]
Internet-Draft                    MCTE                         July 2026

4.1.  Message Flow

   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.

4.2.  Message Types

4.2.1.  MCJUNCTION

   A MCJUNCTION message contains the following information elements:

   MCTET ID:  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.

   Tunnel Type:  various types of tunnels are used, so each node must be
      told which type of tunnel this MCTET consists of.

   Tunnel Information:  provides details for the MCTET.

   Junction Bandwidth:  specifies the bandwidth incoming to the junction
      in Megabits per second (Mbps).

4.2.2.  MCLABEL

   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.

4.2.3.  MCNOTIFY

   A MCNOTIFY is sent from a junction node to the SS to let the SS know
   the state of the MCTET at that node.  This could be the labels it
   assigned to its phops, or error conditions.

Kompella                 Expires 7 January 2027                [Page 10]
Internet-Draft                    MCTE                         July 2026

4.3.  Forwarding State

   From a forwarding point of view, an ingress's job is to:

   1.  identify the traffic trunk, i.e., the set of packets that are to
       be sent via the MCTET;

   2.  encapsulate the packets into the signaled tunnel type;

   3.  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.

5.  Graceful Restart

   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.

6.  IANA Considerations

   None.  The related protocol documents will have IANA requirements.

7.  Security Considerations

   TBD

8.  Acknowledgements

Kompella                 Expires 7 January 2027                [Page 11]
Internet-Draft                    MCTE                         July 2026

9.  References

9.1.  Normative References

   [I-D.kompella-teas-mpte]
              Kompella, K., Jalil, L., Khaddam, M., and A. Smith,
              "Multipath Traffic Engineering", Work in Progress,
              Internet-Draft, draft-kompella-teas-mpte-03, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-kompella-
              teas-mpte-03>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

9.2.  Informative References

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, DOI 10.17487/RFC2702, September 1999,
              <https://www.rfc-editor.org/rfc/rfc2702>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <https://www.rfc-editor.org/rfc/rfc4090>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/rfc/rfc4655>.

   [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, May 2007,
              <https://www.rfc-editor.org/rfc/rfc4875>.

Author's Address

Kompella                 Expires 7 January 2027                [Page 12]
Internet-Draft                    MCTE                         July 2026

   Kireeti Kompella
   HPE
   Sunnyvale, California 94089
   United States of America
   Email: kireeti.ietf@gmail.com

Kompella                 Expires 7 January 2027                [Page 13]