From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7823.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc7823.txt (limited to 'doc/rfc/rfc7823.txt') diff --git a/doc/rfc/rfc7823.txt b/doc/rfc/rfc7823.txt new file mode 100644 index 0000000..b1f4f15 --- /dev/null +++ b/doc/rfc/rfc7823.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Atlas +Request for Comments: 7823 J. Drake +Category: Informational Juniper Networks +ISSN: 2070-1721 S. Giacalone + Microsoft + S. Previdi + Cisco Systems + May 2016 + + + Performance-Based Path Selection for +Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions + +Abstract + + In certain networks, it is critical to consider network performance + criteria when selecting the path for an explicitly routed RSVP-TE + Label Switched Path (LSP). Such performance criteria can include + latency, jitter, and loss or other indications such as the + conformance to link performance objectives and non-RSVP TE traffic + load. This specification describes how a path computation function + may use network performance data, such as is advertised via the OSPF + and IS-IS TE metric extensions (defined outside the scope of this + document) to perform such path selections. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7823. + + + + + + + + + + + +Atlas, et al. Informational [Page 1] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 + + In certain networks, such as financial information networks, network + performance information is becoming as critical to data-path + selection as other existing metrics. Network performance information + can be obtained via either the TE Metric Extensions in OSPF [RFC7471] + or IS-IS [RFC7810] or via a management system. As with other TE + information flooded via OSPF or IS-IS, the TE metric extensions have + a flooding scope limited to the local area or level. This document + describes how a path computation function, whether in an ingress LSR + or a PCE [RFC4655], can use that information for path selection for + explicitly routed LSPs. The selected path may be signaled via RSVP- + TE [RFC3209] [RFC3473] or simply used by the ingress with segment + + + +Atlas, et al. Informational [Page 2] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + + routing [SEG-ROUTE-MPLS] to properly forward the packet. Methods of + optimizing path selection for multiple parameters are generally + computationally complex. However, there are good heuristics for the + delay-constrained lowest-cost (DCLC) computation problem + [k-Paths_DCLC] that can be applied to consider both path cost and a + maximum delay bound. Some of the network performance information can + also be used to prune links from a topology before computing the + path. + + The path selection mechanisms described in this document apply to + paths that are fully computed by the head-end of the LSP and then + signaled in an Explicit Route Object (ERO) where every sub-object is + strict. This allows the head-end to consider IGP-distributed + performance data without requiring the ability to signal the + performance constraints in an object of the RSVP Path message. + + When considering performance-based data, it is obvious that there are + additional contributors to latency beyond just the links. Clearly + end-to-end latency is a combination of router latency (e.g., latency + from traversing a router without queueing delay), queuing latency, + physical link latency, and other factors. While traversing a router + can cause delay, 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 insure freedom from + oscillations and stability issues that have plagued prior attempts to + use delay as a routing metric. If application traffic follows a path + based upon latency constraints, the same traffic might be in an + Expedited Forwarding Per-Hop Behavior (PHB) [RFC3246] with minimal + queuing delay or another PHB with potentially very substantial per- + hop queuing delay. Only traffic that experiences relatively low + congestion, such as Expedited Forwarding traffic, will experience + delays very close to the sum of the reported link delays. + + This document does not specify how a router determines what values to + advertise by the IGP; it does assume that the constraints specified + in [RFC7471] and [RFC7810] are followed. Additionally, the end-to- + end performance that is computed for an LSP path should be built from + the individual link data. Any end-to-end characterization used to + determine an LSP's performance compliance should be fully reflected + in the Traffic Engineering Database so that a path calculation can + also determine whether a path under consideration would be in + compliance. + + + + + + +Atlas, et al. Informational [Page 3] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + +1.1. Basic Requirements + + The following are the requirements considered for a path computation + function that uses network performance criteria. + + 1. Select a TE tunnel's path based upon a combination of existing + constraints as well as on 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 upon + computed end-to-end performance complying 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 using 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. + + The use of timers is often cited as a cure. Oscillation that is + damped by timers is known as "slosh". If advertisement timers are + very short relative to the jitter applied to RSVP-TE Constrained + Shortest Path First (CSPF) timers, then a partial oscillation occurs. + If RSVP-TE CSPF timers are short relative to advertisement timers, + full oscillation (all traffic moving back and forth) can occur. Even + a partial oscillation causes unnecessary reordering that is + considered at least minimally disruptive. + + + + + + +Atlas, et al. Informational [Page 4] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + + 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 proportional to or equal to the + packet serialization delay. Very low levels of traffic can increase + the probability of queue occupancies of two or three packets enough + to further increase the measured jitter. 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 are not sensitive to traffic loads may be + safely used in path computation. Delay measurements made at the link + layer or measurements made at a queuing priority higher than any + significant traffic (such as Differentiated Services Code Point + (DSCP) CS7 or CS6 [RFC4594], 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 + + The per-link performance data available in the IGP [RFC7471] + [RFC7810] includes: unidirectional link delay, unidirectional delay + variation, and link loss. Each (or all) of these parameters can be + used to create the path-level link-based parameter. + + It is possible to compute a CSPF where the link latency values are + used instead of TE metrics; this results in ignoring the TE metrics + and causing LSPs to prefer the lowest-latency paths. In practical + scenarios, latency constraints are typically a bound constraint + rather than a minimization objective. An end-to-end latency upper + bound merely requires that the path computed be no more than that + bound and does not require that it be the minimum latency path. The + latter is exactly the DCLC problem to which good heuristics have been + proposed in the literature (e.g., [k-Paths_DCLC]). + + An end-to-end bound on delay variation can be used similarly as a + constraint in the path computation on what links to explore where the + path's delay variation is the sum of the used links' delay + variations. + + For link loss, the path loss is not the sum of the used links' + losses. Instead, the path loss fraction is 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. This computation is discussed in + + + +Atlas, et al. Informational [Page 5] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + + more detail in Sections 5.1.4 and 5.1.5 in [RFC6049]. The end-to-end + link loss bound, computed in this fashion, can also be used as a + constraint in the path computation. + + The heuristic algorithms for DCLC only address one constraint bound + but having a CSPF that limits the paths explored (i.e., based on hop + count) can be combined [hop-count_DCLC]. + +2.2. Link Constraints + + In addition to selecting paths that conform to a bound on performance + data, it is also useful to avoid using links that do not meet a + necessary constraint. Naturally, if such a parameter were a known + fixed value, then resource attribute flags could be used to express + this behavior. However, when the parameter associated with a link + may vary dynamically, there is not currently a configuration-time + mechanism to enforce such behavior. An example of this is described + in Section 2.3, where links may move in and out of conformance for + link performance objectives with regards to latency, delay variation, + and link loss. + + When doing path selection for TE tunnels, it has not been possible to + know how much actual bandwidth is available that includes the + bandwidth used by non-RSVP-TE traffic. In [RFC7471] and [RFC7810], + the Unidirectional Available Bandwidth is advertised as is 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. + + Similarly, 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 + the link passes. In essence, a link that fails the constraint test + is treated as if it contained a resource attribute in the exclude-any + filter. + +2.3. Links out of Compliance with Link Performance Objectives + + Link conformance to a link performance objective can change as a + result of rerouting at lower layers. This could be due to optical + regrooming or simply rerouting of an FA-LSP. When this occurs, there + are two questions to be asked: + + 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? + + + + +Atlas, et al. Informational [Page 6] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + +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 indicates + that the associated link has entered the Anomalous state with respect + to the associated parameter; similarly, a transition from set to + clear indicates that the Anomalous state has been exited for that + link and associated parameter. + + When a link enters the Anomalous state with respect to a parameter, + this is an indication that LSPs using that link might also no longer + be in compliance with their performance bounds. It can also be + considered an indication that something is changing that link and so + it might no longer be trustworthy to carry performance-critical + traffic. Naturally, which performance criteria are important for a + particular LSP is dependent upon the LSP's configuration; thus, the + compliance of a link with respect to a particular link performance + objective is indicated per performance criterion. + + At the ingress of a TE tunnel, a TE tunnel may be configured to be + sensitive to the Anomalous state of links in reference to latency, + delay variation, and/or loss. Additionally, such a TE tunnel may be + configured to either verify continued compliance, to switch + immediately to a standby LSP, or to move to a different path. + + When a sub-TLV is received with the Anomalous bit set when previously + it was 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 is not sufficient to just look at the Anomalous bit in order to + determine when TE tunnels must have their compliance verified. When + changing to set, the Anomalous bit merely provides a hint that + + + + +Atlas, et al. Informational [Page 7] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + + 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, + this can serve as an indication that those 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 + provided by the Anomalous state change may help optimize when to + recompute for a better path. + +3. Security Considerations + + This document is not currently believed to introduce new security + concerns. + +4. References + +4.1. Normative References + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + . + + [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. + Previdi, "OSPF Traffic Engineering (TE) Metric + Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, + . + + [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and + Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", + RFC 7810, DOI 10.17487/7810, May 2016, + . + +4.2. Informative References + + [hop-count_DCLC] + Agrawal, H., Grah, M., and M. Gregory, "Optimization of + QoS Routing", 6th IEEE/AACIS International Conference on + Computer and Information Science, + DOI 10.1109/ICIS.2007.144, July 2007, + . + + + + + + +Atlas, et al. Informational [Page 8] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + + [k-Paths_DCLC] + Jia, Z. and P. Varaiya, "Heuristic methods for delay + constrained least cost routing using k-shortest-paths", + IEEE Transactions on Automatic Control, vol. 51, no. 4, + April 2006, . + + [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, + J., Courtney, W., Davari, S., Firoiu, V., and D. + Stiliadis, "An Expedited Forwarding PHB (Per-Hop + Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, + . + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE) Extensions", RFC 3473, + DOI 10.17487/RFC3473, January 2003, + . + + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + DOI 10.17487/RFC4594, August 2006, + . + + [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation + Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + . + + [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of + Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, + . + + [SEG-ROUTE-MPLS] + Filsfils, C., Ed., Previdi, S., Ed., Bashandy, A., + Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., + Tantsura, J., and E. Crabbe, "Segment Routing with MPLS + data plane", Work in Progress, draft-ietf-spring-segment- + routing-mpls-04, March 2016. + +Acknowledgements + + The authors would like to thank Curtis Villamizar for his extensive + detailed comments and suggested text in Sections 1 and 1.2. The + authors would like to thank Dhruv Dhody for his useful comments and + his care and persistence in making sure that these important + corrections weren't missed. The authors would also like to thank + Xiaohu Xu and Sriganesh Kini for their reviews. + + + + +Atlas, et al. Informational [Page 9] + +RFC 7823 Path Selection with TE Metric Extensions May 2016 + + +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 + + + + + + + + + + + + + + +Atlas, et al. Informational [Page 10] + -- cgit v1.2.3