doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

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,
+              <http://www.rfc-editor.org/info/rfc3209>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7471>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7810>.
+
+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,
+              <http://ieeexplore.ieee.org/xpl/
+              articleDetails.jsp?arnumber=4276447>.
+
+
+
+
+
+
+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, <http://dx.doi.org/10.1109/TAC.2006.872827>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3246>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3473>.
+
+   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
+              Guidelines for DiffServ Service Classes", RFC 4594,
+              DOI 10.17487/RFC4594, August 2006,
+              <http://www.rfc-editor.org/info/rfc4594>.
+
+   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
+              Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <http://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC6049]  Morton, A. and E. Stephan, "Spatial Composition of
+              Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
+              <http://www.rfc-editor.org/info/rfc6049>.
+
+   [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]
+