Multicast Traffic Engineering

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

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 when, and only when, they appear in all capitals, as shown here.

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

Overview

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

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

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.

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

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: 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: bandwidth (coming in to and going out of v) a list of phops of v a list of nhops of v, with corresponding load balancing shares

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.

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: the MCTET ID the junction node specification the tunnel type some flags After v parses this specification, installs FIB state for the junction.

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

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.

Message Types

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

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.

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.

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

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.

IANA Considerations None. The related protocol documents will have IANA requirements.

Security Considerations TBD

Acknowledgements