RFC 2702

Requirements for Traffic Engineering Over MPLS

📅 published September 1999, from ietf

RFC 2702: Requirements for Traffic Engineering Over MPLS 🎀

okay bestie, let's get into it ✨ This is an Informational RFC from September 1999. It came from the Network Working Group, and the authors are D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, all from UUNET (MCI Worldcom) 💅. It doesn't list anything it obsoletes or updates.

Status of This Memo 📝

so this doc is just giving info to the Internet community 🫶 It is not a spec for any Internet standard. You can distribute it as much as you want, no limits 🦋

the Internet Society owns the copyright (1999), all rights reserved 💜

Abstract 🌸

this one is giving "here's the checklist for making MPLS do traffic engineering right" 🔥 It lays out a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It also names the functional capabilities you need in order to carry out policies that keep network operations efficient and reliable inside an MPLS domain. Those capabilities can help you make the most of your network resources and boost the performance of your traffic 🍓

Table of Contents 📑

   1.0   Introduction .............................................  2
   1.1   Terminology ..............................................  3
   1.2   Document Organization ....................................  3
   2.0   Traffic Engineering ......................................  4
   2.1   Traffic Engineering Performance Objectives ...............  4
   2.2   Traffic and Resource Control .............................  6
   2.3   Limitations of Current IGP Control Mechanisms ............  6
   3.0   MPLS and Traffic Engineering .............................  7
   3.1   Induced MPLS Graph .......................................  9
   3.2   The Fundamental Problem of Traffic Engineering Over MPLS .  9
   4.0   Augmented Capabilities for Traffic Engineering Over MPLS . 10
   5.0   Traffic Trunk Attributes and Characteristics   ........... 10
   5.1   Bidirectional Traffic Trunks ............................. 11
   5.2   Basic Operations on Traffic Trunks ....................... 12
   5.3   Accounting and Performance Monitoring .................... 12
   5.4   Basic Attributes of Traffic Trunks ....................... 13
   5.5   Traffic Parameter Attributes  ............................ 14
   5.6   Generic Path Selection and Management Attributes ......... 14
   5.6.1 Administratively Specified Explicit Paths ................ 15
   5.6.2 Hierarchy of Preference Rules for Multi-paths ............ 15
   5.6.3 Resource Class Affinity Attributes ....................... 16
   5.6.4 Adaptivity Attribute ..................................... 17
   5.6.5 Load Distribution Across Parallel Traffic Trunks ......... 18
   5.7   Priority Attribute ....................................... 18
   5.8   Preemption Attribute ..................................... 18
   5.9   Resilience Attribute ..................................... 19
   5.10  Policing Attribute  ...................................... 20
   6.0   Resource Attributes ...................................... 21
   6.1   Maximum Allocation Multiplier ............................ 21
   6.2   Resource Class Attribute  ................................ 22
   7.0   Constraint-Based Routing  ................................ 22
   7.1   Basic Features of Constraint-Based Routing ............... 23
   7.2   Implementation Considerations ............................ 24
   8.0   Conclusion   ............................................. 25
   9.0   Security Considerations .................................. 26
   10.0  References   ............................................. 26
   11.0  Acknowledgments .......................................... 27
   12.0  Authors' Addresses ....................................... 28
   13.0  Full Copyright Statement ................................. 29

1.0 Introduction 🦋

Okay so MPLS [1,2] basically mashes a label-swapping setup together with network layer routing 💖 The core idea is that at the ingress of an MPLS cloud, packets get short, fixed-length labels slapped on them (this is built on the concept of forwarding equivalence classes [1,2]). Once you're inside the MPLS domain, the forwarding decisions are made using those labels, and usually the original packet headers never get a look-in 👀

It's giving powerful, because this simple paradigm can be used to build a bunch of super useful constructs for the differentiated services Internet ✨ And one of the biggest early applications of MPLS is Traffic Engineering 🔥 People already know how important that is (see [1,2,3]).

This manuscript is all about the Traffic Engineering side of MPLS 💅 The big goal is to lay out the issues and requirements for Traffic Engineering in a large Internet backbone. The hope is that the MPLS specs, or any implementations based on them, will make these objectives happen 🌈 The doc also describes the basic capabilities and functions an MPLS implementation needs in order to meet those requirements.

Even though the focus is on Internet backbones, these capabilities work just as well for Traffic Engineering in enterprise networks 🧚 More generally, they can be applied to any label switched network that's under a single technical administration and has at least two paths between any two nodes.

Some recent papers have looked at Traffic Engineering and traffic management under MPLS, most notably the work of Li and Rekhter [3], among others 🍓 In [3], the authors propose an architecture that uses MPLS and RSVP to deliver scalable differentiated services and Traffic Engineering across the Internet. This manuscript builds on those efforts rather than replacing them, and it comes from the authors' hands-on experience running a large Internet backbone 🫶

1.1 Terminology 📖

You're expected to already know the MPLS terminology defined in [1] 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [11] 🔥

1.2 Document Organization 🗺️

here's the tour ✨ Section 2 covers the basic functions of Traffic Engineering in the Internet. Section 3 gives an overview of what MPLS can do for Traffic Engineering. Sections 1 to 3 are basically background, so don't stress if they feel like a warm-up 🌸 Section 4 gives an overview of the fundamental requirements for Traffic Engineering over MPLS. Section 5 describes the desirable attributes and characteristics of traffic trunks that matter for Traffic Engineering. Section 6 covers a set of attributes that can be tied to resources in order to constrain how traffic trunks and LSPs can be routed through them 🎀 Section 7 pushes for a "constraint-based routing" framework in MPLS domains. And Section 8 wraps everything up with concluding remarks 👑

2.0 Traffic Engineering 🌈

This section breaks down the basic functions of Traffic Engineering inside an Autonomous System in today's Internet 🧚 It calls out the limitations of current IGPs when it comes to traffic and resource control. Honestly, this section is the motivation for the requirements placed on MPLS, so it's the reason the rest of the doc exists 💖

Traffic Engineering (TE) is all about optimizing the performance of operational networks ✨ In general, it means applying technology and scientific principles to measuring, modeling, characterizing, and controlling Internet traffic. It also means using that knowledge and those techniques to hit specific performance objectives 🦋 The parts of Traffic Engineering that matter most for MPLS are measurement and control 🔥

A major goal of Internet Traffic Engineering is to keep network operations efficient and reliable, while also squeezing the most out of network resources and getting the best traffic performance possible 💅 Traffic Engineering has become essential in many large Autonomous Systems. That's because network assets are expensive, and the Internet is commercial and competitive. Those factors make maximal operational efficiency a must-have, not a nice-to-have 🍓

2.1 Traffic Engineering Performance Objectives ✨

okay so the key performance objectives for traffic engineering can be sorted into two buckets:

  1. traffic oriented, or
  2. resource oriented.

Traffic oriented objectives are all about making traffic streams feel their best (the QoS 💖). In a single class, best effort Internet service model, the big ones are: minimization of packet loss, minimization of delay, maximization of throughput, and enforcement of service level agreements. Under that single class best effort model, minimization of packet loss is one of the most important traffic oriented objectives 🫶. Statistically bounded traffic oriented objectives (such as peak to peak packet delay variation, loss ratio, and maximum packet transfer delay) might become useful in the forthcoming differentiated services Internet ✨.

Resource oriented objectives are about optimizing how resources get used 🧚. Efficient management of network resources is the vehicle for getting there. Specifically, it's generally desirable to make sure subsets of network resources don't become over utilized and congested while other subsets along alternate feasible paths stay underutilized 💀. Bandwidth is a crucial resource in contemporary networks, so a central function of Traffic Engineering is to efficiently manage bandwidth resources 👑.

Minimizing congestion is a primary traffic and resource oriented performance objective 🌸. We're interested in congestion that's prolonged, not transient congestion from instantaneous bursts. Congestion typically shows up in two scenarios:

  1. When network resources are insufficient or inadequate to accommodate offered load.
  2. When traffic streams are inefficiently mapped onto available resources; causing subsets of network resources to become over-utilized while others remain underutilized.

The first type can be handled by (i) expanding capacity, or (ii) applying classical congestion control techniques, or (iii) both 🎀. Classical congestion control tries to regulate demand so the traffic fits onto available resources. Classical techniques include: rate limiting, window flow control, router queue management, schedule-based control, and others; (see [8] and the references therein).

The second type, the ones caused by inefficient resource allocation, can usually be addressed through Traffic Engineering 🦋.

In general, congestion from inefficient resource allocation can be reduced by adopting load balancing policies. The goal is to minimize maximum congestion or, alternatively, to minimize maximum resource utilization, through efficient resource allocation. When congestion is minimized this way, packet loss decreases, transit delay decreases, and aggregate throughput increases. So the perception of network service quality for end users gets a serious glow-up ✨.

Clearly, load balancing is an important network performance optimization policy 💅. Still, the capabilities provided for Traffic Engineering should be flexible enough so network administrators can implement other policies that take into account the prevailing cost structure and the utility or revenue model 🍓.

2.2 Traffic and Resource Control

Performance optimization of operational networks is fundamentally a control problem 🧠. In the traffic engineering process model, the Traffic Engineer, or a suitable automaton, acts as the controller in an adaptive feedback control system. This system includes a set of interconnected network elements, a network performance monitoring system, and a set of network configuration management tools. The Traffic Engineer formulates a control policy, observes the state of the network through the monitoring system, characterizes the traffic, and applies control actions to drive the network to a desired state, in accordance with the control policy. This can happen reactively, by taking action in response to the current state of the network, or pro-actively, by using forecasting techniques to anticipate future trends and applying action to obviate the predicted undesirable future states 🔮.

Ideally, control actions should involve:

  1. Modification of traffic management parameters,
  2. Modification of parameters associated with routing, and
  3. Modification of attributes and constraints associated with resources.

The level of manual intervention involved in the traffic engineering process should be minimized whenever possible. This can be accomplished by automating aspects of the control actions described above, in a distributed and scalable fashion 🤖.

2.3 Limitations of Current IGP Control Mechanisms

This subsection reviews some of the well known limitations of current IGPs with regard to Traffic Engineering 📚.

The control capabilities offered by existing Internet interior gateway protocols are not adequate for Traffic Engineering. That makes it hard to actually put effective policies in place to fix network performance problems. Honestly, IGPs based on shortest path algorithms contribute significantly to congestion problems in Autonomous Systems within the Internet 😭. SPF algorithms generally optimize based on a simple additive metric. These protocols are topology driven, so bandwidth availability and traffic characteristics aren't factors in routing decisions. Consequently, congestion frequently occurs when:

  1. the shortest paths of multiple traffic streams converge on specific links or router interfaces, or
  2. a given traffic stream is routed through a link or router interface which does not have enough bandwidth to accommodate it.

These scenarios show up even when feasible alternate paths with excess capacity exist 🙈. This is the part of congestion problems (-- a symptom of suboptimal resource allocation) that Traffic Engineering aims to vigorously obviate 🔥. Equal cost path load sharing can be used to address the second cause above with some degree of success, but it's generally not helpful for the first cause, especially not in large networks with dense topology 💔.

A popular workaround is the overlay model, such as IP over ATM or IP over frame relay 🌈. The overlay model extends the design space by letting arbitrary virtual topologies be provisioned atop the network's physical topology. The virtual topology is built from virtual circuits that appear as physical links to the IGP routing protocols. The overlay model also provides important services for traffic and resource control, including: (1) constraint-based routing at the VC level, (2) support for administratively configurable explicit VC paths, (3) path compression, (4) call admission control functions, (5) traffic shaping and traffic policing functions, and (6) survivability of VCs. These capabilities enable a variety of Traffic Engineering policies. For example, virtual circuits can easily be rerouted to move traffic from over-utilized resources onto relatively underutilized ones 🦋.

For Traffic Engineering in large dense networks, it is desirable to equip MPLS with a level of functionality at least commensurate with current overlay models. Fortunately, this can be done in a fairly straight forward manner ✨.

3.0 MPLS and Traffic Engineering 🌟

This section gives an overview of how MPLS applies to Traffic Engineering. Later sections discuss the set of capabilities required to meet the Traffic Engineering requirements 🎀.

MPLS is strategically significant for Traffic Engineering because it can potentially provide most of the functionality available from the overlay model, in an integrated manner, and at a lower cost than the currently competing alternatives 💰. Equally importantly, MPLS offers the possibility to automate aspects of the Traffic Engineering function. This last consideration requires further investigation and is beyond the scope of this manuscript 🧐.

A note on terminology: The concept of MPLS traffic trunks is used extensively in the remainder of this document. According to Li and Rekhter [3], a traffic trunk is an aggregation of traffic flows of the same class which are placed inside a Label Switched Path. Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. It's useful to view traffic trunks as objects that can be routed; that is, the path a traffic trunk traverses can be changed. In this respect, traffic trunks are similar to virtual circuits in ATM and Frame Relay networks. It's important, though, to emphasize there's a fundamental distinction between a traffic trunk and the path, and indeed the LSP, it traverses. An LSP is a specification of the label switched path the traffic traverses. In practice, the terms LSP and traffic trunk are often used synonymously. Additional characteristics of traffic trunks as used in this manuscript are summarized in section 5.0 💅.

The attractiveness of MPLS for Traffic Engineering can be attributed to the following factors: (1) explicit label switched paths which are not constrained by the destination based forwarding paradigm can be easily created through manual administrative action or through automated action by the underlying protocols, (2) LSPs can potentially be efficiently maintained, (3) traffic trunks can be instantiated and mapped onto LSPs, (4) a set of attributes can be associated with traffic trunks which modulate their behavioral characteristics, (5) a set of attributes can be associated with resources which constrain the placement of LSPs and traffic trunks across them, (6) MPLS allows for both traffic aggregation and disaggregation whereas classical destination only based IP forwarding permits only aggregation, (7) it is relatively easy to integrate a "constraint-based routing" framework with MPLS, (8) a good implementation of MPLS can offer significantly lower overhead than competing alternatives for Traffic Engineering 🧚.

Additionally, through explicit label switched paths, MPLS permits a quasi circuit switching capability to be superimposed on the current Internet routing model. Many of the existing proposals for Traffic Engineering over MPLS focus only on the potential to create explicit LSPs. Although this capability is fundamental for Traffic Engineering, it is not really sufficient. Additional augmentations are required to foster the actualization of policies leading to performance optimization of large operational networks. Some of the necessary augmentations are described in this manuscript 🦄.

3.1 Induced MPLS Graph

okay bestie, this is the big idea 🧠✨ an induced MPLS graph is basically a virtual topology in an overlay model 🦋. It gets logically mapped onto the real network by picking which LSPs carry which traffic trunks 💅.

An induced MPLS graph has two parts. The nodes are a set of LSRs, and the links are a set of LSPs that give you logical point to point connectivity between those LSRs 🌸. Since the LSPs act as the links, the LSRs get connected in a way that's totally its own thing. it may be possible to build hierarchical induced MPLS graphs using label stacks (see [1]) 🎀 which is giving layers, ngl 😭.

Why does this matter so much? Because the basic problem of bandwidth management in an MPLS domain is figuring out how to efficiently map an induced MPLS graph onto the physical network topology 🔥. It's literally the whole game. Here's the formal version 🤓:

Let G = (V, E, c) be a capacitated graph depicting the physical topology of the network. V is the set of nodes in the network and E is the set of links. For v and w in V, the object (v,w) is in E if v and w are directly connected under G. The parameter c is a set of capacity and other constraints associated with E and V. We'll call G the "base" network topology 🌍.

Let H = (U, F, d) be the induced MPLS graph, where U is a subset of V representing the set of LSRs in the network. Or more precisely, the set of LSRs that are the endpoints of at least one LSP 💜. F is the set of LSPs, so for x and y in U, the object (x, y) is in F if there is an LSP with x and y as endpoints. The parameter d is the set of demands and restrictions associated with F. Evidently, H is a directed graph 🧚. It can be seen that H depends on the transitivity characteristics of G ✨.

3.2 The Fundamental Problem of Traffic Engineering Over MPLS

There are basically three fundamental problems that relate to Traffic Engineering over MPLS 💖.

  • The first problem concerns how to map packets onto forwarding equivalence classes.
  • The second problem concerns how to map forwarding equivalence classes onto traffic trunks.
  • The third problem concerns how to map traffic trunks onto the physical network topology through label switched paths.

This document is not focusing on the first two problems listed (even-though they are quite important) 🙈. Instead, the rest of this manuscript zooms in on the capabilities that let the third mapping function happen in a way that gives efficient and reliable network operations 🫶. This is really the problem of mapping an induced MPLS graph (H) onto the "base" network topology (G) 👑.

4.0 Augmented Capabilities for Traffic Engineering Over MPLS

The previous sections went over the basic functions of Traffic Engineering in the contemporary Internet, plus how MPLS fits into that activity 🌈. The remaining sections describe the functional capabilities required to fully support Traffic Engineering over MPLS in large networks 🔥.

The proposed capabilities are:

  1. A set of attributes associated with traffic trunks which collectively specify their behavioral characteristics.
  2. A set of attributes associated with resources which constrain the placement of traffic trunks through them. These can also be viewed as topology attribute constraints.
  3. A "constraint-based routing" framework which is used to select paths for traffic trunks subject to constraints imposed by items 1) and 2) above. The constraint-based routing framework does not have to be part of MPLS. However, the two need to be tightly integrated together 💅.

The attributes associated with traffic trunks and resources, as well as parameters associated with routing, collectively represent the control variables. Those can be changed either by admin action or by automated agents to steer the network into a desired state 🎀.

In an operational network, it is highly desirable that these attributes can be dynamically modified online by an operator without adversely disrupting network operations 🦋. Main character energy for uptime 👑.

5.0 Traffic Trunk Attributes and Characteristics

This section describes the desirable attributes which can be associated with traffic trunks to influence their behavioral characteristics ✨.

First, here are the basic properties of traffic trunks (as used in this manuscript) 📝:

  • A traffic trunk is an aggregate of traffic flows belonging to the same class. In some contexts, it may be desirable to relax this definition and allow traffic trunks to include multi-class traffic aggregates 🌸.
  • In a single class service model, such as the current Internet, a traffic trunk could encapsulate all of the traffic between an ingress LSR and an egress LSR, or subsets thereof 🧚.
  • Traffic trunks are routable objects (similar to ATM VCs) 🦋.
  • A traffic trunk is distinct from the LSP it traverses. In operational contexts, a traffic trunk can be moved from one path onto another 💖.
  • A traffic trunk is unidirectional ➡️.

In practice, a traffic trunk can be characterized by its ingress and egress LSRs, the forwarding equivalence class mapped onto it, and a set of attributes that determine its behavioral characteristics 💜.

Two basic issues are of particular significance: (1) parameterization of traffic trunks and (2) path placement and maintenance rules for traffic trunks 🔥.

5.1 Bidirectional Traffic Trunks

Traffic trunks are conceptually unidirectional, but in many practical contexts it's useful to simultaneously instantiate two traffic trunks with the same endpoints that carry packets in opposite directions 🔁. The two trunks are logically coupled together 🫶. One trunk, called the forward trunk, carries traffic from an originating node to a destination node. The other trunk, called the backward trunk, carries traffic from the destination node back to the originating node. We refer to the pairing of two such traffic trunks as one bidirectional traffic trunk (BTT) if the following two conditions hold 🎀:

  • Both traffic trunks are instantiated through an atomic action at one LSR, called the originator node, or through an atomic action at a network management station.
  • Neither of the composite traffic trunks can exist without the other. That is, both are instantiated and destroyed together 👯‍♀️.

The topological properties of BTTs should also be considered 🌈. A BTT can be topologically symmetric or topologically asymmetric. A BTT is said to be "topologically symmetric" if its constituent traffic trunks are routed through the same physical path, even though they operate in opposite directions 🪞. If, however, the component traffic trunks are routed through different physical paths, then the BTT is said to be "topologically asymmetric" 🔀.

It should be noted that bidirectional traffic trunks are merely an administrative convenience 📋. In practice, most traffic engineering functions can be implemented using only unidirectional traffic trunks 💅.

5.2 Basic Operations on Traffic Trunks

These are the basic operations on traffic trunks that matter for Traffic Engineering purposes 🧁.

  • Establish: To create an instance of a traffic trunk.
  • Activate: To cause a traffic trunk to start passing traffic. The establishment and activation of a traffic trunk are logically separate events. They may, however, be implemented or invoked as one atomic action ⚡.
  • Deactivate: To cause a traffic trunk to stop passing traffic.
  • Modify Attributes: To cause the attributes of a traffic trunk to be modified.
  • Reroute: To cause a traffic trunk to change its route. This can be done through administrative action or automatically by the underlying protocols 🛣️.
  • Destroy: To remove an instance of a traffic trunk from the network and reclaim all resources allocated to it. Such resources include label space and possibly available bandwidth 🗑️.

The above are considered the basic operations on traffic trunks. Additional operations are also possible, such as policing and traffic shaping 🌸.

5.3 Accounting and Performance Monitoring

Accounting and performance monitoring are super important for billing and traffic characterization 💰. Performance statistics from these systems can be used for traffic characterization, performance optimization, and capacity planning within the Traffic Engineering realm 📊.

Being able to get statistics at the traffic trunk level is so important that it should be considered an essential requirement for Traffic Engineering over MPLS 🔥💯.

5.4 Basic Traffic Engineering Attributes of Traffic Trunks

An attribute of a traffic trunk is a parameter assigned to it that influences its behavioral characteristics 🎀.

Attributes can be explicitly assigned to traffic trunks through administrative action, or implicitly assigned by the underlying protocols when packets are classified and mapped into equivalence classes at the ingress to an MPLS domain 🌊. No matter how the attributes were originally assigned, for Traffic Engineering purposes it should be possible to administratively modify them 🛠️.

The basic attributes of traffic trunks particularly significant for Traffic Engineering are listed below 💜.

  • Traffic parameter attributes
  • Generic Path selection and maintenance attributes
  • Priority attribute
  • Preemption attribute
  • Resilience attribute
  • Policing attribute

The combination of traffic parameters and policing attributes is analogous to usage parameter control in ATM networks 🦋. Most of the attributes listed above have analogs in well established technologies. Consequently, it should be relatively straight forward to map the traffic trunk attributes onto many existing switching and routing architectures 🧩.

Priority and preemption can be regarded as relational attributes, because they express certain binary relations between traffic trunks 🤝. Conceptually, these binary relations determine how traffic trunks interact with each other as they compete for network resources during path establishment and path maintenance ⚔️.

5.5 Traffic parameter attributes

Traffic parameters capture the characteristics of the traffic streams (or more precisely the forwarding equivalence class) to be carried through the traffic trunk 🌷. Those characteristics may include peak rates, average rates, permissible burst size, etc. From a traffic engineering perspective, traffic parameters matter because they indicate the resource requirements of the traffic trunk 💖. That's useful for resource allocation and congestion avoidance through anticipatory policies 🔮.

For the purpose of bandwidth allocation, a single canonical value of bandwidth requirements can be computed from a traffic trunk's traffic parameters 🧮. Techniques for performing these computations are well known. One example is the theory of effective bandwidth 🤓✨.

5.6. Generic Path Selection and Management Attributes 🛣️✨

okay so this section is all about how a traffic trunk picks its route 🗺️ and how it keeps that route once it's set up 💅. Generic path selection and management attributes write the rules for both. no cap, it's the main character of path stuff.

Paths can get worked out automatically by the underlying routing protocols, or a network operator can define them by hand 🧑‍💻. If a traffic trunk has no resource requirements or restrictions, a topology driven protocol can be used to select its path. BUT if there are resource requirements or policy restrictions, then a constraint-based routing scheme should be used for path selection 🔥.

In Section 7, there's a constraint-based routing framework that can automatically compute paths subject to a set of constraints 🤓. Explicit paths set up through administrative action get covered in Section 5.6.1 below 🫶.

Path management covers everything about maintaining the paths that traffic trunks travel on 🧹. In some operational contexts, it's desirable for an MPLS implementation to dynamically reconfigure itself so it can adapt to some notion of change in "system state" 🦋. Adaptivity and resilience are both aspects of dynamic path management, iykyk 💜.

To guide the path selection and management process, a set of attributes are required 📋. The basic attributes and behavioral characteristics tied to traffic trunk path selection and management are described in the rest of this sub-section 🎀.

5.6.1. Administratively Specified Explicit Paths

An administratively specified explicit path is one that gets configured through operator action 🧑‍🔧. It can be completely specified or partially specified. A path is completely specified if all of the required hops between the endpoints are indicated. A path is partially specified if only a subset of intermediate hops are indicated. In that case, the underlying protocols are required to complete the path ✨. Operator errors happen, so an administratively specified path can be inconsistent or illogical 🙈. The underlying protocols should be able to detect such inconsistencies and provide appropriate feedback 💅.

A "path preference rule" attribute should be associated with administratively specified explicit paths 💖. It's a binary variable that indicates whether the administratively configured explicit path is "mandatory" or "non-mandatory" 🍓.

If an administratively specified explicit path is selected with a "mandatory" attribute, then that path (and only that path) must be used 🔒. If a mandatory path is topological infeasible (e.g. the two endpoints are topologically partitioned), or if the path cannot be instantiated because the available resources are inadequate, then the path setup process fails 💀. In other words, if a path is specified as mandatory, an alternate path cannot be used regardless of prevailing circumstance 😭. A mandatory path that's successfully instantiated is also implicitly pinned. Once the path is instantiated, it cannot be changed except through deletion and instantiation of a new path 📌.

However, if an administratively specified explicit path is selected with a "non-mandatory" preference rule attribute value, then the path should be used if feasible. Otherwise, an alternate path can be chosen instead by the underlying protocols 🦋.

5.6.2. Hierarchy of Preference Rules For Multi-Paths

In some practical contexts, it can be useful to administratively specify a set of candidate explicit paths for a given traffic trunk and define a hierarchy of preference relations on those paths 🪜. During path establishment, the preference rules are applied to select a suitable path from the candidate list. Also, under failure scenarios, the preference rules are applied to select an alternate path from the candidate list 🛟.

5.6.3. Resource Class Affinity Attributes

Resource class affinity attributes associated with a traffic trunk can be used to specify the class of resources (see Section 6) which are to be explicitly included or excluded from the path of the traffic trunk 🎯. These are policy attributes that can impose additional constraints on the path traversed by a given traffic trunk. Resource class affinity attributes for a traffic can be specified as a sequence of tuples:

    <resource-class, affinity>; <resource-class, affinity>; ..

The resource-class parameter identifies a resource class for which an affinity relationship is defined with respect to the traffic trunk 🏷️. The affinity parameter indicates the affinity relationship, that is, whether members of the resource class are to be included or excluded from the path of the traffic trunk 💜. Specifically, the affinity parameter may be a binary variable that takes one of the following values: (1) explicit inclusion, and (2) explicit exclusion.

If the affinity attribute is a binary variable, it may be possible to use Boolean expressions to specify the resource class affinities associated with a given traffic trunk 🧠.

If no resource class affinity attributes are specified, then a "don't care" affinity relationship is assumed to hold between the traffic trunk and all resources. That is, there is no requirement to explicitly include or exclude any resources from the traffic trunk's path. This should be the default in practice 🌸.

Resource class affinity attributes are very useful and powerful constructs because they can be used to implement a variety of policies 👑. For example, they can be used to contain certain traffic trunks within specific topological regions of the network 🌈.

A "constraint-based routing" framework (see section 7.0) can be used to compute an explicit path for a traffic trunk subject to resource class affinity constraints in the following manner:

  1. For explicit inclusion, prune all resources not belonging to the specified classes prior to performing path computation.
  2. For explicit exclusion, prune all resources belonging to the specified classes before performing path placement computations.

5.6.4. Adaptivity Attribute

Network characteristics and state change over time 🔄. For example, new resources become available, failed resources become reactivated, and allocated resources become deallocated. In general, sometimes more efficient paths become available 🌟. So from a Traffic Engineering perspective, it's necessary to have administrative control parameters that can be used to specify how traffic trunks respond to this dynamism 🎛️. In some scenarios, it might be desirable to dynamically change the paths of certain traffic trunks in response to changes in network state. This process is called re-optimization. In other scenarios, re-optimization might be very undesirable 🙅‍♀️.

An Adaptivity attribute is a part of the path maintenance parameters associated with traffic trunks. The adaptivity attribute associated with a traffic trunk indicates whether the trunk is subject to re-optimization. That is, an adaptivity attribute is a binary variable which takes one of the following values: (1) permit re-optimization and (2) disable re-optimization 🎚️.

If re-optimization is enabled, then a traffic trunk can be rerouted through different paths by the underlying protocols in response to changes in network state (primarily changes in resource availability). Conversely, if re-optimization is disabled, then the traffic trunk is "pinned" to its established path and cannot be rerouted in response to changes in network state 📍.

Stability is a major concern when re-optimization is permitted. To promote stability, an MPLS implementation should not be too reactive to the evolutionary dynamics of the network. At the same time, it must adapt fast enough so that optimal use can be made of network assets. This implies that the frequency of re-optimization should be administratively configurable to allow for tuning 🎶.

It is to be noted that re-optimization is distinct from resilience. A different attribute is used to specify the resilience characteristics of a traffic trunk (see section 5.9). In practice, it would seem reasonable to expect traffic trunks subject to re-optimization to be implicitly resilient to failures along their paths. However, a traffic trunk which is not subject to re-optimization and whose path is not administratively specified with a "mandatory" attribute can also be required to be resilient to link and node failures along its established path 🛡️.

Formally, it can be stated that adaptivity to state evolution through re-optimization implies resilience to failures, whereas resilience to failures does not imply general adaptivity through re-optimization to state changes ✨.

5.6.5. Load Distribution Across Parallel Traffic Trunks

Load distribution across multiple parallel traffic trunks between two nodes is an important consideration 🧁. In many practical contexts, the aggregate traffic between two nodes may be such that no single link (hence no single path) can carry the load. However, the aggregate flow might be less than the maximum permissible flow across a "min-cut" that partitions the two nodes. In this case, the only feasible solution is to appropriately divide the aggregate traffic into sub-streams and route the sub-streams through multiple paths between the two nodes 🪄.

In an MPLS domain, this problem can be addressed by instantiating multiple traffic trunks between the two nodes, such that each traffic trunk carries a proportion of the aggregate traffic. Therefore, a flexible means of load assignment to multiple parallel traffic trunks carrying traffic between a pair of nodes is required 🎀.

Specifically, from an operational perspective, in situations where parallel traffic trunks are warranted, it would be useful to have some attribute that can be used to indicate the relative proportion of traffic to be carried by each traffic trunk. The underlying protocols will then map the load onto the traffic trunks according to the specified proportions. It is also, generally desirable to maintain packet ordering between packets belonging to the same micro-flow (same source address, destination address, and port number) 📦.

5.7. Priority attribute ⚡

The priority attribute defines the relative importance of traffic trunks 👑. If a constraint-based routing framework is used with MPLS, then priorities become very important because they can be used to determine the order in which path selection is done for traffic trunks at connection establishment and under fault scenarios 🥇.

Priorities are also important in implementations permitting preemption because they can be used to impose a partial order on the set of traffic trunks according to which preemptive policies can be actualized 🫧.

5.8 Preemption attribute

Okay bestie, the preemption attribute decides whether a traffic trunk is allowed to bump another traffic trunk off a given path, and whether another trunk is allowed to bump that specific trunk 💅. It matters for both traffic-oriented and resource-oriented performance goals 🎀. It can be used to make sure high priority trunks can always snag the relatively favorable paths inside a differentiated services environment 👑.

Preemption can also be used to set up different prioritized restoration policies after fault events 🔥, which is giving resilience energy 🦋.

The preemption attribute can be set to one of four preempt modes for a traffic trunk: (1) preemptor enabled, (2) non-preemptor, (3) preemptable, and (4) non-preemptable 🌸. A preemptor enabled trunk can preempt lower priority trunks that are marked preemptable ✨. A trunk marked non-preemptable cannot be preempted by any other trunk, no matter the relative priorities 🙈. A trunk marked preemptable can be preempted by higher priority trunks that are preemptor enabled 💜.

Some of the preempt modes are mutually exclusive, and that part is honestly so obvious 💀. Using the numbering scheme depicted above, the feasible preempt mode combinations for a given traffic trunk are (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be the default 🍓.

A traffic trunk, say "A", can preempt another traffic trunk, say "B", only if all of the following five conditions hold 👀:

  1. "A" has a relatively higher priority than "B".
  2. "A" contends for a resource utilized by "B".
  3. The resource cannot concurrently accommodate "A" and "B" based on certain decision criteria.
  4. "A" is preemptor enabled.
  5. "B" is preemptable.

Preemption is not considered a mandatory attribute under the current best effort Internet service model, although it is useful 🫶. But in a differentiated services scenario, the need for preemption becomes way more compelling 😭. Also, in the emerging optical internetworking architectures, some protection and restoration functions may be moved from the optical layer to data network elements (such as gigabit and terabit label switching routers) to cut costs 💰. In that setup, preemptive strategies can be used to reduce the restoration time for high priority traffic trunks under fault conditions ⭐.

5.9 Resilience Attribute

The resilience attribute determines how a traffic trunk behaves under fault conditions, meaning when a fault happens along the path the traffic trunk travels through 🦋. There are three basic problems to handle in that situation: (1) fault detection, (2) failure notification, and (3) recovery and service restoration 🎀. Obviously, an MPLS implementation will have to include mechanisms to deal with all of these 💅.

Many recovery policies can be specified for traffic trunks whose established paths get hit by faults 🌈. Here are some feasible schemes:

  1. Do not reroute the traffic trunk. For example, a survivability scheme may already be in place, set up through an alternate mechanism, that guarantees service continuity under failure scenarios without needing to reroute traffic trunks. One example of such an alternate scheme (certainly many others exist) is when multiple parallel label switched paths are provisioned between two nodes and act so that, if one LSP fails, the traffic trunk on it is mapped onto the remaining LSPs according to some well defined policy 🧚.
  2. Reroute through a feasible path with enough resources. If none exists, then do not reroute.
  3. Reroute through any available path regardless of resource constraints.
  4. Many other schemes are possible, including some which might be combinations of the above ✨.

A "basic" resilience attribute indicates the recovery procedure to be applied to traffic trunks whose paths are impacted by faults 💖. Specifically, a "basic" resilience attribute is a binary variable that determines whether the target traffic trunk is to be rerouted when segments of its path fail 🔥. "Extended" resilience attributes can be used to specify detailed actions to take under fault scenarios 👑. For example, an extended resilience attribute might specify a set of alternate paths to use under fault conditions, along with the rules that govern the relative preference of each specified path 🍓.

Resilience attributes mandate close interaction between MPLS and routing. This is non-negotiable, bestie 🚨.

5.10 Policing attribute

The policing attribute determines the actions the underlying protocols should take when a traffic trunk becomes non-compliant 🙅‍♀️. That means when a traffic trunk goes over its contract as specified in the traffic parameters 📈. Generally, policing attributes can indicate whether a non-conformant traffic trunk is to be rate limited, tagged, or simply forwarded without any policing action 🌸. If policing is used, adaptations of established algorithms such as the ATM Forum's GCRA [11] can be used to perform this function 🧠.

Policing is necessary in lots of operational scenarios, but it's quite undesirable in some others 😬. In general, it's usually desirable to police at the ingress to a network (to enforce compliance with service level agreements), and to minimize policing within the core, except when capacity constraints dictate otherwise 🏰.

So from a Traffic Engineering perspective, it's necessary to be able to administratively enable or disable traffic policing for each traffic trunk 🎀✨.

6.0 Resource Attributes

Resource attributes are part of the topology state parameters, and they're used to constrain the routing of traffic trunks through specific resources 💜.

6.1 Maximum Allocation Multiplier

The maximum allocation multiplier (MAM) of a resource is an administratively configurable attribute that determines the proportion of the resource available for allocation to traffic trunks 🦋. This attribute is mostly applicable to link bandwidth, but it can also be applied to buffer resources on LSRs 🌈. The concept of MAM is analogous to the concepts of subscription and booking factors in frame relay and ATM networks 🧁.

The MAM values can be chosen so that a resource is either under-allocated or over-allocated 🎀. A resource is under-allocated if the aggregate demands of all traffic trunks that can be allocated to it (as expressed in the trunk traffic parameters) are always less than the capacity of the resource 🌸. A resource is over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource 🔥.

Under-allocation can be used to bound the utilization of resources ✨. However, the situation under MPLS is more complex than in circuit switched schemes, because under MPLS some flows can be routed via conventional hop by hop protocols (and also via explicit paths) without any consideration for resource constraints 😵‍💫.

Over-allocation can be used to take advantage of the statistical characteristics of traffic and implement more efficient resource allocation policies 📊. In particular, over-allocation can be used in situations where the peak demands of traffic trunks do not coincide in time ⏰. Smart, bestie 🧠👑.

6.2 Resource Class Attribute

Resource class attributes are administratively assigned parameters that express some notion of "class" for resources 🎨. You can think of them as "colors" assigned to resources, so that the set of resources with the same "color" conceptually belongs to the same class 🌈. Resource class attributes can be used to implement a variety of policies 💅. The key resources of interest here are links, and when applied to links, the resource class attribute effectively becomes an aspect of the "link state" parameters 🔗.

The concept of resource class attributes is a seriously powerful abstraction 😭✨. From a Traffic Engineering perspective, it can be used to implement lots of policies regarding both traffic-oriented and resource-oriented performance optimization 🦋. Specifically, resource class attributes can be used to:

  1. Apply uniform policies to a set of resources that do not need to be in the same topological region.
  2. Specify the relative preference of sets of resources for path placement of traffic trunks.
  3. Explicitly restrict the placement of traffic trunks to specific subsets of resources.
  4. Implement generalized inclusion / exclusion policies.
  5. Enforce traffic locality containment policies. That is, policies that seek to contain local traffic within specific topological regions of the network 🏡.

Additionally, resource class attributes can be used for identification purposes 🪪.

A resource can be assigned more than one resource class attribute 🎀. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute 💖. The subsets of OC-48 links that exist within a given abstraction domain of the network may be assigned additional resource class attributes, in order to implement specific containment policies or to architect the network in a certain manner 🧩.

7.0 Constraint-Based Routing

This section talks about the issues around constraint-based routing in MPLS domains 🌸. In contemporary terminology, constraint-based routing is often called "QoS Routing", see [5,6,7,10] 📚.

This document uses the term "constraint-based routing" anyway, because it better captures the functionality envisioned, which generally covers QoS routing as a subset 💅.

Constraint-based routing lets a demand driven, resource reservation aware, routing paradigm co-exist with the current topology driven hop by hop Internet interior gateway protocols 🤝.

A constraint-based routing framework uses the following as input:

  • The attributes associated with traffic trunks.
  • The attributes associated with resources.
  • Other topology state information.

Based on this information, a constraint-based routing process on each node automatically computes explicit routes for each traffic trunk originating from that node 🗺️. In this case, an explicit route for each traffic trunk is a specification of a label switched path that satisfies the demand requirements expressed in the trunk's attributes, subject to constraints imposed by resource availability, administrative policy, and other topology state information 🦋.

A constraint-based routing framework can greatly reduce the level of manual configuration and intervention needed to actualize Traffic Engineering policies 🙌.

In practice, the Traffic Engineer, an operator, or even an automaton will specify the endpoints of a traffic trunk and assign a set of attributes to the trunk that encapsulate the performance expectations and behavioral characteristics of the trunk 🎯. The constraint-based routing framework is then expected to find a feasible path to satisfy those expectations 🔍. If necessary, the Traffic Engineer or a traffic engineering support system can then use administratively configured explicit routes to perform fine grained optimization 💎.

7.1. Basic Features of Constraint-Based Routing ✨

okay so a constraint-based routing framework should AT LEAST be able to automatically find a basic feasible solution to the traffic trunk path placement problem 💖 that's the baseline, bestie, no cap

in general the constraint-based routing problem is known to be intractable for most realistic constraints 💀 BUT in practice there's a super simple well known heuristic (see e.g. [9]) that can find a feasible path if one exists 🫶 it goes like this:

  • first prune the resources that don't satisfy the requirements of the traffic trunk attributes 🧹
  • next, run a shortest path algorithm on the residual graph 🛣️

clearly, if a feasible path exists for a single traffic trunk, the above simple procedure will find it 🦋 additional rules can be specified to break ties and do further optimizations ✨ in general, ties should be broken so that congestion is minimized 🌈 but when multiple traffic trunks need routing, it can be shown that the above algorithm may NOT always find a mapping, even when a feasible mapping exists 😭 the way that the math plays out is kinda messy ngl 🙈

7.2. Implementation Considerations 🎀

many commercial implementations of frame relay and ATM switches already support some notion of constraint-based routing 💅 for those devices, or for the novel MPLS centric contraptions devised from them, it should be relatively easy to extend the current constraint-based routing implementations to handle the peculiar requirements of MPLS 🔥

for routers that use topology driven hop by hop IGPs, constraint-based routing can be incorporated in at least one of two ways:

  1. by extending the current IGP protocols such as OSPF and IS-IS to support constraint-based routing 🧚 effort is already underway to provide such extensions to OSPF (see [5,7]) ✨
  2. by adding a constraint-based routing process to each router, which can co-exist with the current IGPs 🌸 this scenario is depicted in Figure 1 👑
     ------------------------------------------
    |          Management Interface            |
     ------------------------------------------
        |                 |                 |
 ------------     ------------------    --------------
|    MPLS    |<->| Constraint-Based |  | Conventional |
|            |   | Routing Process  |  | IGP Process  |
 ------------     ------------------    --------------
                       |                  |
         -----------------------    --------------
        | Resource  Attribute   |  | Link State   |
        | Availability Database |  | Database     |
         -----------------------    --------------

Figure 1. Constraint-Based Routing Process on Layer 3 LSR

there are MANY important details that go into implementing constraint-based routing on Layer 3 devices 🙈 we're not going to dig into them here, but they include the following:

  • mechanisms for exchanging topology state information (resource availability information, link state information, resource attribute information) between constraint-based routing processes 🔁
  • mechanisms for maintaining topology state information 🛠️
  • interaction between constraint-based routing processes and conventional IGP processes 🤝
  • mechanisms to accommodate the adaptivity requirements of traffic trunks 🌀
  • mechanisms to accommodate the resilience and survivability requirements of traffic trunks 🛡️

so in summary, constraint-based routing helps with performance optimization of operational networks by automatically finding feasible paths that satisfy a set of constraints for traffic trunks 🦋 it can drastically reduce the amount of administrative explicit path configuration and manual intervention needed to hit Traffic Engineering objectives 💜

8.0. Conclusion 🌈

this manuscript laid out a set of requirements for Traffic Engineering over MPLS 💖 lots of capabilities were described to make MPLS more applicable to Traffic Engineering in the Internet ✨

it should be noted that some of the issues described here can be addressed by putting a minimal set of building blocks into MPLS, and then using a network management superstructure to extend the functionality so the requirements get realized 🎀 also, the constraint-based routing framework does NOT have to be part of the core MPLS specifications 🧁 however, MPLS does require some interaction with a constraint-based routing framework in order to meet the requirements 🫶

9.0. Security Considerations 🔐

⚠️ this part is SERIOUS, bestie. Please read it carefully.

this document does NOT introduce new security issues beyond those inherent in MPLS, and it may use the same mechanisms proposed for this technology 🔒 it is, however, specifically important that manipulation of administratively configurable parameters be executed in a secure manner by authorized entities 🚨 like, locked down, authorized-only, no exceptions 💀

10.0. References 📚

  • [1] Rosen, E., Viswanathan, A. and R. Callon, "A Proposed Architecture for MPLS", Work in Progress. 💫
  • [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. and A. Viswanathan, "A Framework for Multiprotocol Label Switching", Work in Progress. 🌷
  • [3] Li, T. and Y. Rekhter, "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. 🍓
  • [4] Rekhter, Y., Davie, B., Katz, D., Rosen, E. and G. Swallow, "Cisco Systems' Tag Switching Architecture - Overview", RFC 2105, February 1997. 🧚
  • [5] Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley "Quality of Service Extensions to OSPF", Work in Progress. ✨
  • [6] Crawley, E., Nair, F., Rajagopalan, B. and H. Sandick, "A Framework for QoS Based Routing in the Internet", RFC 2386, August 1998. 🦋
  • [7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. and D. Williams, "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999. 🌸
  • [8] C. Yang and A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks," IEEE Network Magazine, Volume 9, Number 5, July/August 1995. 📖
  • [9] W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to Quality of Service Constraints in Integrated Communication Networks," IEEE Network, July 1995, pp 46-55. 📖
  • [10] ATM Forum, "Traffic Management Specification: Version 4.0" April 1996. 📖

11.0. Acknowledgments 🫶

the authors would like to thank Yakov Rekhter for his review of an earlier draft of this document 💖 they'd also like to thank Louis Mamakos and Bill Barns for their helpful suggestions, and Curtis Villamizar for providing some useful feedback 🌸

12.0. Authors' Addresses 💌

  • Daniel O. Awduche UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031

Phone: +1 703-208-5277 EMail: awduche@uu.net

  • Joe Malcolm UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031

Phone: +1 703-206-5895 EMail: jmalcolm@uu.net

  • Johnson Agogbua UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031

Phone: +1 703-206-5794 EMail: ja@uu.net

  • Mike O'Dell UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031

Phone: +1 703-206-5890 EMail: mo@uu.net

  • Jim McManus UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031

Phone: +1 703-206-5607 EMail: jmcmanus@uu.net

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈

this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works 💜 however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English 🧚

the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns 🦋

this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙈

Acknowledgement 🌷

funding for the RFC Editor function is currently provided by the Internet Society 💖

📦 where this page comes from