RFC 7823

Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions

📅 published May 2016, from ietf

RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions 💖

Okay bestie, this one is from the Internet Engineering Task Force (IETF) and it's dated May 2016 🎀. The authors are A. Atlas (Juniper Networks), J. Drake (Juniper Networks), S. Giacalone (Microsoft), and S. Previdi (Cisco Systems). It's Informational 📚, which means it's published for information and is not an Internet Standards Track spec. The ISSN is 2070-1721. Its header doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Abstract ✨

Some networks really need to care about how well the network is performing when they pick a path for an explicitly routed RSVP-TE Label Switched Path (LSP) 🦋. The performance stuff can include latency, jitter, loss, and other signals like whether links meet their performance objectives or how much non-RSVP-TE traffic is on them. This spec explains how a path computation function can use network performance data, like what gets advertised through the OSPF and IS-IS TE metric extensions (which are defined outside this document), to make those path choices 💅.

Status of This Memo 🌸

Let's be clear: this document is not an Internet Standards Track specification. It's just published for information 📖.

It's a product of the IETF, and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🧐.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7823 🔗.

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Basic Requirements  . . . . . . . . . . . . . . . . . . .   4
  1.2.  Oscillation and Stability Considerations  . . . . . . . .   4
2.  Using Performance Data Constraints  . . . . . . . . . . . . .   5
  2.1.  End-to-End Constraints  . . . . . . . . . . . . . . . . .   5
  2.2.  Link Constraints  . . . . . . . . . . . . . . . . . . . .   6
  2.3.  Links out of Compliance with Link Performance Objectives    6
    2.3.1.  Use of Anomalous Links for New Paths  . . . . . . . .   7
    2.3.2.  Links Entering the Anomalous State  . . . . . . . . .   7
    2.3.3.  Links Leaving the Anomalous State . . . . . . . . . .   8
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  4.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
  4.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction 🌈

Okay so, in certain networks like financial information networks, network performance info is becoming just as critical to data-path selection as the metrics we already use 📈. You can get that performance info from the TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810], or from a management system. Like the rest of the TE info that gets flooded through OSPF or IS-IS, these TE metric extensions only flood within the local area or level 🏠.

This document describes how a path computation function, whether it sits in an ingress LSR or in a PCE [RFC4655], can use that info to pick paths for explicitly routed LSPs 🛤️. The chosen path can be signaled via RSVP-TE [RFC3209] [RFC3473], or the ingress can just use it directly with segment routing [SEG-ROUTE-MPLS] to forward the packet properly 🦋. Optimizing the path for multiple parameters is generally computationally complex 🤯. The good news is there are solid heuristics for the delay-constrained lowest-cost (DCLC) computation problem [k-Paths_DCLC], and they can consider both path cost and a maximum delay bound ✨. Some of the network performance info can also be used to prune links from the topology before the path gets computed ✂️.

The path selection mechanisms in this document apply to paths that the head-end of the LSP fully computes and then signals in an Explicit Route Object (ERO) where every sub-object is strict 💅. This lets the head-end look at the IGP-distributed performance data without needing to signal the performance constraints in an object of the RSVP Path message 🧚.

When you think about performance data, it's obvious there are more contributors to latency than just the links 🙈. End-to-end latency is a combo of router latency (like the latency of going through a router without any queueing delay), queuing latency, physical link latency, and other factors 💜. Traversing a router can add delay, but that router latency can be included in the advertised link delay. As described in [RFC7471] and [RFC7810], queuing delay must not be included in the measurements advertised by OSPF or IS-IS 🚫.

Queuing latency is specifically excluded, to make sure we avoid the oscillations and stability problems that wrecked earlier attempts to use delay as a routing metric 😭. If application traffic follows a path based on latency constraints, that same traffic might be in an Expedited Forwarding Per-Hop Behavior (PHB) [RFC3246] with minimal queuing delay, or in some other PHB with potentially huge per-hop queuing delay 📦. Only traffic that sees relatively low congestion, like Expedited Forwarding traffic, will see delays very close to the sum of the reported link delays 🎯.

This document doesn't specify how a router decides what values to advertise through the IGP. It does assume the constraints in [RFC7471] and [RFC7810] are followed 🙌. Also, the end-to-end performance computed for an LSP path should be built from the individual link data 🧱. Any end-to-end characterization used to decide an LSP's performance compliance should be fully reflected in the Traffic Engineering Database, so a path calculation can also tell whether a path under consideration would be compliant 👑.

1.1. Basic Requirements 📝

Here's the list of requirements for a path computation function that uses network performance criteria. Bestie, these are the non-negotiable vibes 🫶.

  1. Select a TE tunnel's path based on a combination of existing constraints plus link-latency, packet loss, jitter, conformance with link performance objectives, and bandwidth consumed by non-RSVP-TE traffic 🎀.
  2. Ability to define different end-to-end performance requirements for each TE tunnel, regardless of common use of resources 💅.
  3. Ability to periodically verify with the TE Link State Database (LSDB) that a TE tunnel's current LSP complies with its configured end-to-end performance requirements 🔍.
  4. Ability to move tunnels, using make-before-break, based on computed end-to-end performance that complies with constraints 🔀.
  5. Ability to move tunnels away from any link that is violating an underlying link performance objective 🏃‍♀️.
  6. Ability to optionally avoid setting up tunnels on any link that is violating a link performance objective, regardless of whether end-to-end performance would still meet requirements 🙅‍♀️.
  7. Ability to revert back, using make-before-break, to the best path after a configurable period ⏰.

1.2. Oscillation and Stability Considerations 🌀

Past attempts to use unbounded delay or loss as a metric suffered from severe oscillations 😱. The use of performance-based data must be such that undamped oscillations are not possible, and stability cannot be impacted 🛡️.

People often say timers are the cure. Oscillation that gets damped by timers is called "slosh" 🫠. If advertisement timers are very short compared to the jitter applied to RSVP-TE Constrained Shortest Path First (CSPF) timers, then a partial oscillation happens. If RSVP-TE CSPF timers are short compared to advertisement timers, a full oscillation can happen, where all the traffic moves back and forth 🎢. Even a partial oscillation causes unnecessary reordering, which is considered at least minimally disruptive 🙃.

Delay variation, or jitter, is affected by even small traffic levels 📉. At even tiny traffic levels, the probability of a queue occupancy of one can produce a measured jitter that is proportional to, or equal to, the packet serialization delay. Very low traffic levels can increase the probability of queue occupancies of two or three packets, which increases the measured jitter even more. Because jitter measurement is extremely sensitive to very low traffic levels, any use of jitter is likely to oscillate. However, there may be uses of a jitter measurement in path computation that can be considered free of oscillation 🤞.

Delay measurements that aren't sensitive to traffic loads may be safely used in path computation 💖. These include delay measurements made at the link layer, or measurements made at a queuing priority higher than any significant traffic. For example, Differentiated Services Code Point (DSCP) CS7 or CS6 [RFC4594] works, but not CS2 if traffic levels at CS3 and higher, or Expedited Forwarding and Assured Forwarding, can affect the measurement 🌸. Making delay measurements at the same priority as the traffic on affected paths is likely to cause oscillations 🙈.

2. Using Performance Data Constraints 🦋

2.1. End-to-End Constraints

okay so the per-link performance data living in the IGP [RFC7471] [RFC7810] includes three big vibes: unidirectional link delay, unidirectional delay variation, and link loss 📊✨ bestie, each one (or all of them!) can be used to build the path-level link-based parameter 💖

here's the lowkey genius part 🧠: you could run a CSPF using the link latency values instead of the TE metrics 🙈 that totally ignores the TE metrics and makes LSPs go hunting for the lowest-latency paths 🏃‍♀️💨 but honestly? In real life, latency is usually a bound constraint and NOT a minimization objective 🫶 an end-to-end latency upper bound just says "the path has to be no more than this number" and doesn't need to be the absolute fastest path 🌸 that fastest-path-under-a-bound thing is exactly the DCLC problem, and people have come up with good heuristics for it in the literature (e.g., [k-Paths_DCLC]) 👑

delay variation works in a similar way 🎀 you can use an end-to-end bound on it as a constraint when deciding which links to explore, where the path's delay variation is the sum of the used links' delay variations 🧚

link loss is the plot twist 😭 the path loss is NOT the sum of the used links' losses. instead it's 1 - (1 - loss_L1)(1 - loss_L2)...*(1 - loss_Ln), where the links along the path are L1 to Ln with loss_Li in fractions 💅 if you want the full nerdy details, check out Sections 5.1.4 and 5.1.5 in [RFC6049] 🌈 and yes, that end-to-end link loss bound (computed this way) can also be a constraint in the path computation 💜

one more thing 🦋 the heuristic algorithms for DCLC only handle ONE constraint bound at a time, but you can combine them with a CSPF that limits which paths get explored (like based on hop count) [hop-count_DCLC] ✨

2.2. Link Constraints

okay bestie, sometimes you don't just want to pick paths that meet a performance bound, you also want to AVOID links that don't meet a necessary constraint 🙅‍♀️💖 if the parameter were a known fixed value, you could use resource attribute flags to express that 🎀 but when a link's parameter can change dynamically, there isn't currently a configuration-time mechanism to enforce that behavior 😭 Section 2.3 has an example of this, where links move in and out of conformance for latency, delay variation, and link loss objectives 🌊

when you're doing path selection for TE tunnels, it hasn't been possible to know how much actual bandwidth is available once you include the bandwidth used by non-RSVP-TE traffic 🫠 [RFC7471] and [RFC7810] advertise the Unidirectional Available Bandwidth, and they also advertise the Residual Bandwidth 💅 when computing the path for a TE tunnel, only links with at least a minimum amount of Unidirectional Available Bandwidth might be permitted 🌸

same deal for loss: only links whose loss is under a configurable value might be acceptable 🍓 for these constraints, each link can be tested against the constraint and only explored in the path computation if it passes ✨ basically, a link that fails the constraint test is treated as if it had a resource attribute in the exclude-any filter 🧚‍♀️ it's giving "not invited to the party" energy 💀

2.3. Links out of Compliance with Link Performance Objectives

okay so link conformance to a link performance objective can change because of rerouting at lower layers 🦋 this could be due to optical regrooming or just rerouting of an FA-LSP 🌈 when this happens, there are two questions to ask:

  • a. Should the link be trusted and used for the setup of new LSPs?
  • b. Should LSPs using this link automatically be moved to a secondary path?

2.3.1. Use of Anomalous Links for New Paths

if the answer to (a) is no for link latency performance objectives, then any link that has the Anomalous bit set in the Unidirectional Link Delay sub-TLV [RFC7471] [RFC7810] SHOULD be removed from the topology before a path calculation is used to compute a new path 🙅‍♀️ in essence, the link should be treated exactly as if it fails the exclude-any resource attributes filter [RFC3209] 💅

similarly, if the answer to (a) is no for link loss performance objectives, then any link that has the Anomalous bit set in the Link Loss sub-TLV SHOULD be treated as if it fails the exclude-any resource attributes filter 🫶

2.3.2. Links Entering the Anomalous State

when the Anomalous bit transitions from clear to set, this means the associated link has entered the Anomalous state with respect to the associated parameter 🚨 similarly, a transition from set to clear means the Anomalous state has been exited for that link and parameter 🎉

when a link enters the Anomalous state with respect to a parameter, that's a sign that LSPs using that link might also no longer be in compliance with their performance bounds 😭 it can also be read as "something is changing that link, so it might not be trustworthy for performance-critical traffic right now" 🙈 which performance criteria matter for a particular LSP depends on that LSP's configuration, so the compliance of a link is indicated per performance criterion 💜

at the ingress of a TE tunnel, the tunnel may be configured to be sensitive to the Anomalous state of links for latency, delay variation, and/or loss 🎀 such a TE tunnel may also be configured to either verify continued compliance, switch immediately to a standby LSP, or move to a different path 🧚

when a sub-TLV is received with the Anomalous bit set when it was previously clear, the list of interested TE tunnels MUST be scanned 👀 each such TE tunnel SHOULD have its continued compliance verified, be switched to a hot standby, or do a make-before-break to a secondary path 💖

it's NOT enough to just look at the Anomalous bit to figure out when TE tunnels must have their compliance verified 🙅‍♀️ when it changes to set, the Anomalous bit only gives a hint that interested TE tunnels should have their continued compliance verified 🌸

2.3.3. Links Leaving the Anomalous State

when a link leaves the Anomalous state with respect to a parameter, that can be a signal that TE tunnels whose LSPs were changed due to administrative policy when the link entered the Anomalous state may want to reoptimize to a better path ✨ the hint from the Anomalous state change can help optimize when to recompute for a better path 🦋

  1. Security Considerations

okay this one is short and sweet bestie 🫶 this document is not currently believed to introduce new security concerns 🔒💖

  1. References

4.1. Normative References

4.2. Informative References

Acknowledgements

the authors want to thank Curtis Villamizar for his extensive detailed comments and suggested text in Sections 1 and 1.2 🙌 they also want to thank Dhruv Dhody for his useful comments and his care and persistence in making sure these important corrections weren't missed 🫶 and Xiaohu Xu and Sriganesh Kini get a shoutout for their reviews 💖

Contributors

Dave Ward and Clarence Filsfils contributed to this document 🌟

Authors' Addresses

Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States

Email: akatlas@juniper.net

John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States

Email: jdrake@juniper.net

Spencer Giacalone Microsoft

Email: spencer.giacalone@gmail.com

Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 00142 Italy

Email: sprevidi@cisco.com

📦 where this page comes from