<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml"> nbsp    "&#160;">
  <!ENTITY RFC1102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1102.xml"> zwsp   "&#8203;">
  <!ENTITY RFC1104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1104.xml"> nbhy   "&#8209;">
  <!ENTITY RFC2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY RFC2330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2330.xml">
<!ENTITY RFC2386 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2386.xml">
<!ENTITY RFC2474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC2475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC2597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2597.xml">
<!ENTITY RFC2678 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2678.xml">
<!ENTITY RFC2702 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2702.xml">
<!ENTITY RFC2722 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2722.xml">
<!ENTITY RFC2753 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2753.xml">
<!ENTITY RFC2961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2961.xml">
<!ENTITY RFC2998 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2998.xml">
<!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3086.xml">
<!ENTITY RFC3124 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3124.xml">
<!ENTITY RFC3168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3175 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3175.xml">
<!ENTITY RFC3198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3198.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3270 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3270.xml">
<!ENTITY RFC3272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3272.xml">
<!ENTITY RFC3469 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3469.xml">
<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY RFC3945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC4124 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4124.xml">
<!ENTITY RFC4203 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4203.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4461 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4461.xml">
<!ENTITY RFC4594 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4594.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC4872 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4872.xml">
<!ENTITY RFC4873 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4873.xml">
<!ENTITY RFC4875 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4875.xml">
<!ENTITY RFC5151 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5151.xml">
<!ENTITY RFC5250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5250.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5329 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5329.xml">
<!ENTITY RFC5331 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5331.xml">
<!ENTITY RFC5357 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC5394 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5394.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC5470 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5470.xml">
<!ENTITY RFC5472 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5472.xml">
<!ENTITY RFC5541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5541.xml">
<!ENTITY RFC5557 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5557.xml">
<!ENTITY RFC5559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5559.xml">
<!ENTITY RFC5623 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5623.xml">
<!ENTITY RFC5664 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5664.xml">
<!ENTITY RFC5671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5671.xml">
<!ENTITY RFC5693 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5693.xml">
<!ENTITY RFC6107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6107.xml">
<!ENTITY RFC6119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6119.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6372 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6372.xml">
<!ENTITY RFC6374 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC6601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6601.xml">
<!ENTITY RFC6805 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6805.xml">
<!ENTITY RFC7011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7011.xml">
<!ENTITY RFC7149 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7149.xml">
<!ENTITY RFC7285 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7285.xml">
<!ENTITY RFC7390 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7390.xml">
<!ENTITY RFC7426 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY RFC7471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7471.xml">
<!ENTITY RFC7491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7491.xml">
<!ENTITY RFC7551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7551.xml">
<!ENTITY RFC7567 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7567.xml">
<!ENTITY RFC7679 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7679.xml">
<!ENTITY RFC7680 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7680.xml">
<!ENTITY RFC7665 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7665.xml">
<!ENTITY RFC7752 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7752.xml">
<!ENTITY RFC7923 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7923.xml">
<!ENTITY RFC7926 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7926.xml">
<!ENTITY RFC7950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7950.xml">
<!ENTITY RFC8033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8033.xml">
<!ENTITY RFC8034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8034.xml">
<!ENTITY RFC8040 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8040.xml">
<!ENTITY RFC8051 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8051.xml">
<!ENTITY RFC8189 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8189.xml">
<!ENTITY RFC8231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231.xml">
<!ENTITY RFC8259 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8259.xml">
<!ENTITY RFC8279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8279.xml">
<!ENTITY RFC8281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281.xml">
<!ENTITY RFC8283 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8283.xml">
<!ENTITY RFC8290 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8290.xml">
<!ENTITY RFC8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC8453 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8453.xml">
<!ENTITY RFC8570 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8570.xml">
<!ENTITY RFC8571 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8571.xml">
<!ENTITY RFC8655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8655.xml">
<!ENTITY RFC8664 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8664.xml">
<!ENTITY RFC8684 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8684.xml">
<!ENTITY RFC8685 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8685.xml">
<!ENTITY RFC8795 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8795.xml">
<!ENTITY RFC8803 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8803.xml">
<!ENTITY RFC8896 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8896.xml">
<!ENTITY RFC8938 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8938.xml">
<!ENTITY RFC8955 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8955.xml">
<!ENTITY RFC8972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8972.xml">
<!ENTITY RFC9000 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9000.xml">
<!ENTITY RFC9023 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9023.xml">
<!ENTITY RFC9040 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9040.xml">
<!ENTITY RFC9113 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9113.xml">
<!ENTITY RFC9256 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9256.xml">
<!ENTITY RFC9262 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9262.xml">
<!ENTITY RFC9298 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9298.xml">
<!ENTITY RFC9315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9315.xml">
<!ENTITY RFC9332 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9332.xml">
<!ENTITY RFC9350 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9350.xml">
<!ENTITY RFC9439 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9439.xml">

<!ENTITY I-D.ietf-bess-evpn-unequal-lb SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-unequal-lb">
<!ENTITY I-D.ietf-idr-performance-routing SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-performance-routing">
<!ENTITY I-D.ietf-idr-segment-routing-te-policy SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-segment-routing-te-policy">
<!ENTITY I-D.ietf-lsr-ip-flexalgo SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-ip-flexalgo">
<!ENTITY I-D.ietf-quic-multipath SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-quic-multipath">
<!ENTITY I-D.ietf-rtgwg-segment-routing-ti-lfa SYSTEM  "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa">
<!ENTITY I-D.ietf-teas-enhanced-vpn SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-enhanced-vpn">
<!ENTITY I-D.ietf-tewg-qos-routing SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tewg-qos-routing">
<!ENTITY I-D.ietf-tsvwg-multipath-dccp SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-multipath-dccp">
<!ENTITY I-D.ietf-teas-ietf-network-slices SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-ietf-network-slices"> wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-teas-rfc3272bis-27" number="9522" submissionType="IETF" category="info" consensus="true" obsoletes="3272" ipr="trust200902"> ipr="trust200902" updates="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="Overview and Principles of Internet TE">Overview and Principles of Internet Traffic Engineering</title>
    <seriesInfo name="RFC" value="9522"/>
    <author initials="A." surname="Farrel" fullname="Adrian Farrel" role="editor">
      <organization>Old Dog Consulting</organization>
      <address>
        <email>adrian@olddog.co.uk</email>
      </address>
    </author>
    <date year="2023" />

<workgroup>TEAS Working Group</workgroup> year="2024" month="January"/>
    <area>rtg</area>
    <workgroup>teas</workgroup>

<keyword>Policy</keyword>
<keyword>Path steering</keyword>
<keyword>Resource management</keyword>
<keyword>Network engineering</keyword>
<keyword>Network performance optimization</keyword>

    <abstract>
      <t>This document describes the principles of traffic engineering (TE) in
      the Internet.  The document is intended to promote better understanding
      of the issues surrounding traffic engineering in IP networks and the
      networks that support IP networking, networking and to provide a common basis for
      the development of traffic engineering traffic-engineering capabilities for the Internet.
      The principles, architectures, and methodologies for performance
      evaluation and performance optimization of operational networks are also
      discussed.</t>
      <t>This work was first published as RFC 3272 in May 2002.  This document
      obsoletes RFC 3272 by making a complete update to bring the text in line
      with best current practices for Internet traffic engineering and to
      include references to the latest relevant work in the IETF.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document describes the principles of Internet traffic
      engineering (TE).  The objective of the document is to articulate the
      general issues and principles for Internet TE, and TE and, where appropriate appropriate, to
      provide recommendations, guidelines, and options for the development of
      preplanned (offline) and dynamic (online) Internet TE capabilities and
      support systems.</t>
      <t>Even though Internet TE is most effective when applied end-to-end,
      the focus of this document is TE within a given domain (such as an autonomous system).
      Autonomous System (AS)).  However, because a preponderance of Internet
      traffic tends to originate in one autonomous
     system AS and terminate in
      another, this document also provides an overview of aspects pertaining
      to inter-domain TE.</t>
      <t>This document provides a terminology and a taxonomy for describing and
     understanding common Internet TE concepts.</t>
      <t>This work was first published as <xref target="RFC3272"/> target="RFC3272"
      format="default"/> in May 2002.  This document obsoletes <xref target="RFC3272"/>
      target="RFC3272" format="default"/> by making a complete update to bring
      the text in line with best current practices for Internet TE and to
      include references to the latest relevant work in the IETF.  It is worth
      noting around three fifths three-fifths of the RFCs referenced in this document post-date
      postdate the publication of RFC 3272. <xref target="RFC3272" format="default"/>.
      <xref target="CHANGES" /> format="default"/> provides a summary of changes
      between RFC 3272 <xref target="RFC3272" format="default"/> and this document.</t>
      <section anchor="WHATTE" title="What numbered="true" toc="default">
        <name>What is Internet Traffic Engineering?"> Engineering?</name>
        <t>One of the most significant functions performed in the Internet is
        the routing and forwarding of traffic from ingress nodes to egress
        nodes.  Therefore, one of the most distinctive functions performed by
        Internet traffic engineering is the control and optimization of these
        routing and forwarding functions, to steer traffic through the
        network.</t>
        <t>Internet traffic engineering is defined as that aspect of Internet
        network engineering dealing with the issues of performance evaluation
        and performance optimization of operational IP networks.  Traffic
        engineering encompasses the application of technology and scientific
        principles to the measurement, characterization, modeling, and control
        of Internet traffic <xref target="RFC2702"/>, target="RFC2702" format="default"/> <xref target="AWD2"/>.</t>
        target="AWD2" format="default"/>.</t>
        <t>It is the performance of the network as seen by end users of
        network services that is paramount.  The characteristics visible to
        end users are the emergent properties of the network, which are the
        characteristics of the network when viewed as a whole.  A central goal
        of the service provider, therefore, is to enhance the emergent
        properties of the network while taking economic considerations into
        account.  This is accomplished by addressing traffic oriented traffic-oriented
        performance requirements while utilizing network resources without
        excessive waste and in a reliable way.  Traffic oriented  Traffic-oriented performance
        measures include delay, delay variation, packet loss, and
        throughput.</t>
        <t>Internet TE responds to network events (such as link or node
        failures, reported or predicted network congestion, planned
        maintenance, service degradation, planned changes in the traffic
        matrix, etc.).  Aspects of capacity management respond at intervals
        ranging from days to years.  Routing control functions operate at
        intervals ranging from milliseconds to days.  Packet level  Packet-level processing
        functions operate at very fine levels of temporal resolution (up to
        milliseconds) while reacting to statistical measures of the real-time
        behavior of traffic.</t>
        <t>Thus, the optimization aspects of TE can be viewed from a control perspective,
        perspective and can be both proactive and reactive.  In the proactive
        case, the TE control system takes preventive action to protect against
        predicted unfavorable future network states, for example, by
        engineering backup paths.
It may also take action that will lead to a
        more desirable future network state.  In the reactive case, the
        control system responds to correct issues and adapt to network
        events, such as routing after failure.</t>
        <t>Another important objective of Internet TE is to facilitate
        reliable network operations <xref target="RFC2702"/>. target="RFC2702" format="default"/>.
        Reliable network operations can be facilitated by providing mechanisms
        that enhance network integrity and by embracing policies emphasizing
        network survivability.  This reduces the vulnerability of services to
        outages arising from errors, faults, and failures occurring within the
        network infrastructure.</t>
        <t>The optimization aspects of TE can be achieved
       through capacity management and traffic management.  In this
       document, capacity management includes capacity planning, routing
       control, and resource management.  Network resources of particular
       interest include link bandwidth, buffer space, and computational
       resources.  In this document, traffic management includes:
       <list style="numbers">
         <t>Nodal
        </t>
        <ol spacing="normal">
	  <li>Nodal traffic control functions functions, such as traffic conditioning,
	  queue management, and scheduling.</t>
         <t>Other scheduling.</li>
          <li>Other functions that regulate the flow of traffic through
          the network or that arbitrate access to network resources between
          different packets or between different traffic flows.</t>
       </list></t> flows.</li>
        </ol>
        <t>One major challenge of Internet TE is the realization of automated
        control capabilities that adapt quickly and
       cost effectively cost-effectively to
        significant changes in network state, while still maintaining
        stability of the network.  Performance evaluation can assess the
        effectiveness of TE methods, and the results of this evaluation can be
        used to identify existing problems, guide network re-optimization, reoptimization, and
        aid in the prediction of potential future problems.  However, this
        process can also be time consuming time-consuming and may not be suitable to act on
        short-lived changes in the network.</t>
        <t>Performance evaluation can be achieved in many different ways.  The
       most notable techniques include analytic methods, simulation, and
       empirical methods based on measurements.</t>
        <t>Traffic engineering comes in two flavors:
       <list style="symbols">
         <t>A
        </t>
        <ul spacing="normal">
          <li>A background process that constantly monitors traffic and
          network
            conditions, conditions and optimizes the use of resources to
          improve performance.</t>
         <t>A performance.</li>
          <li>A form of a pre-planned traffic distribution that is considered optimal.</t>
       </list>
       In
          optimal.</li>
        </ul>

        <t>In the latter case, any deviation from the optimum distribution
        (e.g., caused by a fiber cut) is reverted upon repair without further
        optimization.  However, this form of TE relies upon the notion that
        the planned state of the network is optimal.  Hence,
       in such a mode
        there are two levels of TE: the TE in such a mode: </t>
<ul spacing="normal">
	<li>The TE-planning task to enable optimum traffic distribution, and the distribution.</li>
	<li>The routing and forwarding tasks that keep traffic flows
	  attached to the pre-planned distribution.</t> distribution.</li>
	</ul>
        <t>As a general rule, TE concepts and mechanisms must be sufficiently
        specific and well-defined to address known requirements, requirements but
        simultaneously flexible and extensible to accommodate
        unforeseen future demands (see <xref target="HIGHOBJ" />).</t>
        format="default"/>).</t>
      </section>
      <section anchor="COMPONENTS" title="Components numbered="true" toc="default">
        <name>Components of Traffic Engineering"> Engineering</name>
        <t>As mentioned in <xref target="WHATTE" />, format="default"/>, Internet
        traffic engineering provides performance optimization of IP networks
        while utilizing network resources economically and reliably.  Such
        optimization is supported at the control/controller level and within
        the data/forwarding plane.</t>
        <t>The key elements required in any TE solution are as follows:
       <list style="numbers">
          <t>Policy</t>
          <t>Path steering</t>
          <t>Resource management</t>
       </list></t>
        </t>
        <ol spacing="normal" type="1"><li>Policy</li>
          <li>Path steering</li>
          <li>Resource management</li>
        </ol>
        <t>Some TE solutions rely on these elements to a lesser or greater
        extent.  Debate remains about whether a solution can truly be
        called TE "TE" if it does not include all of these elements.  For the sake
        of this document, we assert that all TE solutions must include some
        aspects of all of these elements.  Other solutions can be classed as
        "partial TE" and also fall in scope of this document.</t>
        <t>Policy allows for the selection of paths (including next hops)
        based on information beyond basic reachability.  Early definitions of
        routing policy, e.g., <xref target="RFC1102" /> format="default"/> and
        <xref target="RFC1104" />, format="default"/>, discuss routing policy
        being applied to restrict access to network resources at an aggregate
        level.  BGP is an example of a commonly used mechanism for applying
        such policies, policies; see <xref target="RFC4271" /> format="default"/> and <xref
        target="RFC8955" />. format="default"/>.  In the TE context, policy
        decisions are made within the control plane or by controllers in the
        management plane, plane and govern the selection of paths.  Examples can be
        found in <xref target="RFC4655" /> format="default"/> and <xref
        target="RFC5394" />. format="default"/>.  TE solutions may cover the
        mechanisms to distribute and/or enforce policies, but definition of
        specific policies is left to the network operator.</t>
        <t>Path steering is the ability to forward packets using more
        information than just knowledge of the next hop.  Examples of path
        steering include IPv4 source routes <xref target="RFC0791" />,
        format="default"/>, RSVP-TE explicit routes <xref target="RFC3209" />,
        format="default"/>, Segment Routing (SR) <xref target="RFC8402" />,
        format="default"/>, and Service Function Chaining <xref
        target="RFC7665" />. format="default"/>.  Path steering for TE can be
        supported via control plane protocols, by encoding in the data plane
        headers, or by a combination of the two.  This includes when control
        is provided by a controller using a network-facing control
        protocol.</t>
        <t>Resource management provides resource-aware control and forwarding.
        Examples of resources are bandwidth, buffers, and queues, all of which
        can be managed to control loss and latency.
       <list style="none"> latency.</t>
        <t>Resource reservation is the control aspect of resource management.
        It provides for domain-wide consensus about which network resources
        are used by a particular flow.  This determination may be made at a
        very coarse or very fine level.  Note that this consensus exists at
        the network control or controller level, level but not within the data plane.
        It may be composed purely of accounting/bookkeeping, but it typically
        includes an ability to admit, reject, or reclassify a flow based on
        policy. Such accounting can be done based on any combination of a
        static understanding of resource requirements, requirements and the use of dynamic
        mechanisms to collect requirements (e.g., via RSVP-TE <xref
        target="RFC3209" />) format="default"/>) and resource availability (e.g.,
        via OSPF extensions for GMPLS <xref target="RFC4203" />).</t>
        format="default"/>).</t>
          <t>Resource allocation is the data plane aspect of resource
          management.  It provides for the allocation of specific node and
          link resources to specific flows.  Example resources include
          buffers, policing, and rate-shaping mechanisms that are typically
          supported via queuing.  It  Resource allocation also includes the matching of a flow (i.e.,
          flow classification) to a particular set of allocated resources.
          The method of flow classification and granularity of resource
          management is technology-specific. Examples include Diffserv with
          dropping and remarking <xref target="RFC4594" />, format="default"/>,
          MPLS-TE <xref target="RFC3209" />, and GMPLS based label switched paths format="default"/>, GMPLS-based Label
          Switched Paths (LSPs) <xref target="RFC3945" />, format="default"/>, as
          well as controller-based solutions <xref target="RFC8453" />.
          format="default"/>.  This level of resource control, while optional,
          is important in networks that wish to support network congestion
          management policies to control or regulate the offered traffic to
          deliver different levels of service and alleviate network
          congestion problems, or those problems. It is also important in networks that wish to control the
          latency experienced by specific traffic flows.</t>
       </list></t>

      </section>
      <section anchor="SCOPE" title="Scope"> numbered="true" toc="default">
        <name>Scope</name>
        <t>The scope of this document is intra-domain TE because this is the
        practical level of TE technology that exists in the Internet at the
        time of writing.  That is, it this document describes TE within a given autonomous system
        AS in the Internet.  This document discusses concepts
        pertaining to intra-domain traffic control, including such issues as
        routing control, micro and macro resource allocation, and the control
        coordination problems that arise consequently.</t>
        <t>This document describes and characterizes techniques already in use
        or in advanced development for Internet TE.  The way these techniques
        fit together is discussed and scenarios in which they are useful will be are
        identified.</t>
        <t>Although the emphasis in this document is on intra-domain traffic
        engineering, an overview of the high-level considerations pertaining
        to inter-domain TE is provided in <xref target="INTER" />.
        format="default"/>.  Inter-domain Internet TE is crucial to the
        performance enhancement of the world-wide Internet infrastructure.</t>
        <t>Whenever possible, relevant requirements from existing IETF
        documents and other sources are incorporated by reference.</t>
      </section>
      <section anchor="TERMS" title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
	<t>This section provides terminology which that is useful for Internet TE.
        The definitions presented apply to this document.  These terms may
        have other meanings elsewhere.</t>

    <t><list style="hanging">
         <t hangText='Busy hour:'>
           A one hour
        <dl newline="false" spacing="normal">
          <dt>Busy hour:</dt>
          <dd>A one-hour period within a specified interval of time (typically
          24 hours) in which the traffic load in a network or sub-network is greatest.</t>
         <t hangText='Congestion:'>
           A
          greatest.</dd>
          <dt>Congestion:</dt>
          <dd>A state of a network resource in which the traffic incident on
          the resource exceeds its output capacity over an interval of time.
          A small amount of congestion may be beneficial to ensure that
          network resources are run at full capacity, and this may be
          particularly true at the network edge where it is desirable to
          ensure that user traffic is served as much as possible.  Within the
          network, if congestion is allowed to build (such as when input
          traffic exceeds output traffic in a sustained way) way), it will have a
          negative effect on user
           traffic.</t>
         <t hangText='Congestion avoidance:'>
           An traffic.</dd>
          <dt>Congestion avoidance:</dt>
          <dd>An approach to congestion management that attempts to obviate
          the occurrence of congestion.  Chiefly  It is chiefly relevant to network congestion
          congestion, although it may form a part of demand-side congestion management.</t>
         <t hangText='Congestion response:'>
           An
          management.</dd>
          <dt>Congestion response:</dt>
          <dd>An approach to congestion management that attempts to remedy
          congestion problems that have already occurred.</t>
         <t hangText='Constraint-based routing:'>
           A occurred.</dd>
          <dt>Constraint-based routing:</dt>
          <dd>A class of routing protocols that take takes specified traffic
          attributes, network constraints, and policy constraints into account
          when making routing decisions.  Constraint-based routing is
          applicable to traffic aggregates as well as flows.  It is a
          generalization of QoS-based routing.</t>
         <t hangText='Demand-side routing.</dd>
          <dt>Demand-side congestion management:'>
           A management:</dt>
          <dd>A congestion management scheme that addresses congestion
          problems by regulating or conditioning the offered load.</t>
         <t hangText='Effective bandwidth:'>
           The load.</dd>
          <dt>Effective bandwidth:</dt>
          <dd>The minimum amount of bandwidth that can be assigned to a flow
          or traffic aggregate in order to deliver &apos;acceptable "acceptable service quality&apos;
          quality" to the flow or traffic aggregate.  See <xref target="KELLY" />
          format="default"/> for a more mathematical definition.</t>
         <t hangText='Egress node:'>
           The definition.</dd>
          <dt>Egress node:</dt>
          <dd>The device (router) at which traffic leaves a network toward a
          destination (host, server, etc.) or to another network.</t>
         <t hangText='End-to-end:'>
           This network.</dd>
          <dt>End-to-end:</dt>
          <dd>This term is context-dependent and often applies to the life of
          a traffic flow from original source to final destination.
In contrast, edge-to-edge is often used to describe the traffic flow from the
entry to of a domain or network, network to the exit from of that domain or network.  In  However,
in some contexts, however, for example contexts (for example, where there is a service interface between a
network and the client of that network, network or where a path traverses multiple
domains under the control of a single process, process), end-to-end is used to refer to
the full operation of the service that may be composed of concatenated
edge-to-edge operations.  Thus, in the context of TE, the term end-to-end "end-to-end"
may refer to the full TE path, path but not to the complete path of the traffic from
source application to ultimate destination.</t>
         <t hangText='Hot-spot:'>
           A destination.</dd>
          <dt>Hotspot:</dt>
          <dd>A network element or subsystem which that is in a considerably higher
          state of congestion than others.</t>
         <t hangText='Ingress node:'>
           The others.</dd>
          <dt>Ingress node:</dt>
          <dd>The device (router) at which traffic enters a network from a
          source (host) or from another network.</t>
         <t hangText='Metric:'>
           A network.</dd>
          <dt>Metric:</dt>
          <dd>A parameter defined in terms of standard units of
           measurement.</t>
         <t hangText='Measurement methodology:'>
          measurement.</dd>
          <dt>Measurement methodology:</dt>
          <dd>
           A repeatable measurement technique used to derive one or
           more metrics of interest.</t>
         <t hangText='Network congestion:'> interest.</dd>
          <dt>Network congestion:</dt>
          <dd>
           Congestion within the network at a specific node or a specific link
           that is sufficiently extreme that it results in
           unacceptable queuing delay or packet loss.  Network congestion can
           negatively impact end-to-end or edge-to-edge traffic flows, so TE
           schemes may be deployed to balance traffic in the network and
           deliver congestion avoidance.</t>
         <t hangText='Network survivability:'> avoidance.</dd>
          <dt>Network survivability:</dt>
          <dd>
           The capability to provide a prescribed level of QoS for
           existing services after a given number of failures occur
           within the network.</t>
         <t hangText='Offered load:'>
           The offered network.</dd>
          <dt>Offered load:</dt>
          <dd>Offered load or offered is also sometimes called "offered traffic load load". It
          is a measure of the amount of traffic being presented to be carried
          across a network compared to the capacity of the network to carry
          it. This term derives from queuing theory theory, and an offered load of 1
          indicates that the network can carry, but only just manage to carry,
          all of the traffic presented to it.</t>
         <t hangText='Offline it.</dd>
          <dt>Offline traffic engineering:'> engineering:</dt>
          <dd>
           A traffic engineering system that exists outside of the
           network.</t>
         <t hangText='Online
           network.</dd>
          <dt>Online traffic engineering:'> engineering:</dt>
          <dd>
           A traffic engineering traffic-engineering system that exists within the network,
           typically implemented on or as adjuncts to operational
           network elements.</t>
         <t hangText='Performance measures:'> elements.</dd>
          <dt>Performance measures:</dt>
          <dd>
           Metrics that provide quantitative or qualitative measures of
           the performance of systems or subsystems of interest.</t>
         <t hangText='Performance metric:'> interest.</dd>
          <dt>Performance metric:</dt>
          <dd>
           A performance parameter defined in terms of standard units
           of measurement.</t>
         <t hangText='Provisioning:'> measurement.</dd>
          <dt>Provisioning:</dt>
          <dd>
           The process of assigning or configuring network resources to
           meet certain requests.</t>
         <t hangText='Quality requests.</dd>
          <dt>Quality of Service (QoS):'> (QoS):</dt>
          <dd>
           QoS (<xref <xref target="RFC3198" />) format="default"/> refers to the
           mechanisms used within a network to achieve specific goals for the
           delivery of traffic for a particular service according to the
           parameters specified in a Service Level Agreement.  "Quality"
           is characterized by service availability, delay, jitter, throughput throughput,
           and packet loss ratio.  At a network resource level, "Quality of
           Service" refers to a set of capabilities that allow a service
           provider to prioritize traffic, control bandwidth, and network
           latency.</t>
         <t hangText='QoS routing:'>
           latency.</dd>
          <dt>QoS routing:</dt>
          <dd>
           Class of routing systems that selects paths to be used by a
           flow based on the QoS requirements of the flow.</t>
         <t hangText='Service flow.</dd>
          <dt>Service Level Agreement (SLA):'> (SLA):</dt>
          <dd>
           A contract between a provider and a customer that guarantees
           specific levels of performance and reliability at a certain
           cost.</t>
         <t hangText='Service
           cost.</dd>
          <dt>Service Level Objective (SLO):'> (SLO):</dt>
          <dd>
           A key element of an SLA between a provider and a customer.  SLOs
           are agreed upon as a means of measuring the performance of the
           Service Provider
           service provider and are outlined as a way of avoiding disputes
           between the two parties based on misunderstanding.</t>
         <t hangText='Stability:'> misunderstanding.</dd>
          <dt>Stability:</dt>
          <dd>
           An operational state in which a network does not oscillate
           in a disruptive manner from one mode to another mode.</t>
         <t hangText='Supply-side mode.</dd>
          <dt>Supply-side congestion management:'> management:</dt>
          <dd>
           A congestion management scheme that provisions additional
           network resources to address existing and/or anticipated
           congestion problems.</t>
         <t hangText='Traffic characteristic:'> problems.</dd>
          <dt>Traffic characteristic:</dt>
          <dd>
           A description of the temporal behavior or a description of
           the attributes of a given traffic flow or traffic aggregate.</t>
         <t hangText='Traffic engineering system:'> aggregate.</dd>
          <dt>Traffic-engineering system:</dt>
          <dd>
           A collection of objects, mechanisms, and protocols that are
           used together to accomplish traffic engineering objectives.</t>
         <t hangText='Traffic flow:'> traffic-engineering objectives.</dd>
          <dt>Traffic flow:</dt>
          <dd>
           A stream of packets between two end-points endpoints that can be
           characterized in a certain way.  A common classification for a
           traffic flow selects packets with the "five-tuple" five-tuple of source
           and destination addresses, source and destination ports, and
           protocol ID.  Flows may be very small and transient, ranging to
           very large.  The TE techniques described in this document are
           likely to be more effective when applied to large flows.  Traffic
           flows may be aggregated and treated as a single unit in some
           forms of TE TE, making it possible to apply TE to the smaller flows
           that comprise the aggregate.</t>
         <t hangText='Traffic mapping:'> aggregate.</dd>
          <dt>Traffic mapping:</dt>
          <dd>
           Traffic mapping is the assignment of traffic workload onto (pre-
           established)
           (pre-established) paths to meet certain requirements.</t>
         <t hangText='Traffic matrix:'> requirements.</dd>
          <dt>Traffic matrix:</dt>
          <dd>
           A representation of the traffic demand between a set of
           origin and destination abstract nodes.  An abstract node can
           consist of one or more network elements.</t>
         <t hangText='Traffic monitoring:'> elements.</dd>
          <dt>Traffic monitoring:</dt>
          <dd>
           The process of observing traffic characteristics at a given
           point in a network and collecting the traffic information
           for analysis and further action.</t>
         <t hangText='Traffic trunk:'> action.</dd>
          <dt>Traffic trunk:</dt>
          <dd>
           An aggregation of traffic flows belonging to the same class
           which
           that are forwarded through a common path.  A traffic trunk
           may be characterized by an ingress and egress node, node and a
           set of attributes which that determine its behavioral
           characteristics and requirements from the network.</t>
         <t hangText='Workload:'>
           The workload or traffic workload network.</dd>
          <dt>Workload:</dt>
          <dd>Workload is also sometimes called "traffic workload".  It is an
          evaluation of the amount of work that must be done in a network in
          order to facilitate the traffic demand. Colloquially, it is the
          answer to, "How busy is the network?"</t>
       </list></t> network?"</dd>
        </dl>
      </section>
    </section>
    <section anchor="BG" title="Background"> numbered="true" toc="default">
      <name>Background</name>
      <t>The Internet aims to convey IP packets from ingress nodes to egress nodes
     efficiently, expeditiously, and economically.  Furthermore, in a
     multiclass
     multi-class service environment (e.g., Diffserv capable networks - networks; see
     <xref target="DIFFSERV" />), format="default"/>), the resource sharing resource-sharing parameters of the
     network must be appropriately determined and configured according to
     prevailing policies and service models to resolve resource contention
     issues arising from mutual interference between packets traversing
     the network.  Thus, consideration must be given to resolving
     competition for network resources between traffic flows belonging to
     the same service class (intra-class contention resolution) and traffic
     flows belonging to different classes (inter-class contention
     resolution).</t>
      <section anchor="CONTEXT" title="Context numbered="true" toc="default">
        <name>Context of Internet Traffic Engineering"> Engineering</name>
        <t>The context of Internet traffic engineering includes the following sub-contexts:</t>

     <t><list style="numbers">
         <t>A
        <ol spacing="normal" type="1">
	  <li>A network domain context that defines the scope under consideration,
            and
	  consideration and, in particular particular, the situations in which the TE
	  problems occur.  The network domain context includes network
	  structure, policies, characteristics, constraints, quality
	  attributes, and optimization criteria.</t>
         <t>A criteria.</li>
          <li>A problem context defining the general and concrete issues that
          TE addresses.  The problem context includes identification,
          abstraction of relevant features, representation, formulation,
          specification of the requirements on the solution space, and
          specification of the desirable features of acceptable solutions.</t>
         <t>A
          solutions.</li>
          <li>A solution context suggesting how to address the issues
          identified by the problem context.  The solution context includes
          analysis, evaluation of alternatives, prescription, and resolution.</t>
         <t>An
          resolution.</li>
          <li>An implementation and operational context in which the
            solutions are instantiated.  The implementation and operational
            context includes planning, organization, and execution.</t>
     </list></t> execution.</li>
        </ol>
        <t>The context of Internet TE and the different problem
       scenarios are discussed in the following subsections.</t>
      </section>
      <section anchor="NWCTXT" title="Network numbered="true" toc="default">
        <name>Network Domain Context"> Context</name>
        <t>IP networks range in size from small clusters of routers situated
        within a given location, location to thousands of interconnected routers,
        switches, and other components distributed all over the world.</t>
        <t>At the most basic level of abstraction, an IP network can be
        represented as a distributed dynamic system consisting of:
       <list style="symbols">
         <t>a
        </t>
        <ul spacing="normal">
          <li>a set of interconnected resources which that provide transport
          services for IP traffic subject to certain constraints</t>
         <t>a constraints</li>
          <li>a demand system representing the offered load to be transported
          through the network</t>
         <t>a network</li>
          <li>a response system consisting of network processes, protocols,
          and related mechanisms which that facilitate the movement of traffic
          through the network (see also <xref target="AWD2"/>).</t>
       </list></t> target="AWD2"
          format="default"/>)</li>
        </ul>
        <t>The network elements and resources may have specific
        characteristics restricting the manner in which the traffic demand is
        handled.  Additionally, network resources may be equipped with traffic
        control mechanisms managing the way in which the demand is serviced.
        Traffic control mechanisms may be used to:
       <list style="symbols">
         <t>control
        </t>
        <ul spacing="normal">
          <li>control packet processing activities within a given resource</t>
         <t>arbitrate
          resource</li>
          <li>arbitrate contention for access to the resource by different
            packets</t>
         <t>regulate
          packets</li>
          <li>regulate traffic behavior through the resource.</t>
       </list></t> resource</li>
        </ul>
        <t>A configuration management and provisioning system may allow the
        settings of the traffic control mechanisms to be manipulated by
        external or internal entities in order to exercise control over the
        way in which the network elements respond to internal and external
        stimuli.</t>
        <t>The details of how the network carries packets are specified in the
        policies of the network administrators and are installed through
        network configuration management and policy-based provisioning
        systems.  Generally, the types of service provided by the network also
        depend upon the technology and characteristics of the network elements
        and protocols, the prevailing service and utility models, and the
        ability of the network administrators to translate policies into
        network configurations.</t>
        <t>Internet networks have two significant characteristics:
       <list style="symbols">
         <t>they characteristics:</t>
        <ul spacing="normal">
          <li>They provide real-time services</t>
         <t>their services.</li>
          <li>Their operating environments are very dynamic.</t>
       </list></t> dynamic.</li>
        </ul>
        <t>The dynamic characteristics of IP and IP/MPLS networks can be
        attributed in part to fluctuations in demand, to the interaction between
        various network protocols and processes, to the rapid evolution of the
        infrastructure
       which that demands the constant inclusion of new technologies
        and new network elements, and to the transient and persistent faults which that
        occur within the system.</t>
        <t>Packets contend for the use of network resources as they are
        conveyed through the network.  A network resource is considered to be
        congested if, for an interval of time, the arrival rate of packets
        exceeds the output capacity of the resource.  Network congestion may
        result in some of the arriving packets being delayed or even
        dropped.</t>
        <t>Network congestion increases transit delay and delay variation, may
        lead to packet loss, and reduces the predictability of network
        services.  Clearly, while congestion may be a useful tool at ingress
        edge nodes, network congestion is highly undesirable.  Combating
        network congestion at a reasonable cost is a major objective of
        Internet TE TE, although it may need to be traded with other objectives to
        keep the costs reasonable.</t>
        <t>Efficient sharing of network resources by multiple traffic flows is
        a basic operational premise for the Internet.  A fundamental challenge
        in network operation is to increase resource utilization while
        minimizing the possibility of congestion.</t>
        <t>The Internet has to function in the presence of different classes
        of traffic with different service requirements.  This requirement is
        clarified in the architecture for Differentiated Services (Diffserv)
        <xref target="RFC2475" />. format="default"/>.  That document describes
        how packets can be grouped into behavior aggregates such that each
        aggregate has a common set of behavioral characteristics or a common
        set of delivery requirements.  Delivery requirements of a specific set
        of packets may be specified explicitly or implicitly.  Two of the most
        important traffic delivery requirements are:

       <list style="symbols">

          <t>Capacity are:</t>
        <ul spacing="normal">
          <li>Capacity constraints can be expressed statistically as peak
          rates, mean rates, burst sizes, or as some deterministic notion of
          effective
             bandwidth.</t>

          <t>QoS bandwidth.</li>
          <li><t>QoS requirements can be expressed in terms of:

             <list style="symbols">

               <t>integrity constraints of:</t>
            <ul spacing="normal">
              <li>integrity constraints, such as packet loss</t>

               <t>temporal constraints loss</li>
              <li>temporal constraints, such as timing restrictions for the
              delivery of each packet (delay) and timing restrictions for the
              delivery of consecutive packets belonging to the same traffic
              stream (delay
                  variation).</t>

             </list></t>

       </list></t> variation)</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="PRBCTXT" title="Problem Context"> numbered="true" toc="default">
        <name>Problem Context</name>
        <t>There are several problems associated with operating a
       network like those described in the previous section.  This section analyzes
       the problem context in relation to TE.  The
       identification, abstraction, representation, and measurement of
       network features relevant to TE are significant
       issues.</t>
        <t>A particular challenge is to formulate the problems that traffic
       engineering attempts to solve.  For example:
       <list style="symbols">
         <t>How
        </t>

        <ul spacing="normal">
          <li>How to identify the requirements on the solution space?</t>
         <t>How space</li>
          <li>How to specify the desirable features of solutions?</t>
         <t>How solutions</li>
          <li>How to actually solve the problems?</t>
         <t>How problems</li>
          <li>How to measure and characterize the effectiveness of
            solutions?</t>
       </list></t>
            solutions</li>
        </ul>
        <t>Another class of problems is how to measure and estimate
       relevant network state parameters.  Effective TE
       relies on a good estimate of the offered traffic load as well as a
       view of the underlying topology and associated resource constraints.
       Offline planning requires a full view of the topology of the network
       or partial network that is being planned.</t>
        <t>Still another class of problem is how to characterize the state of
        the network and how to evaluate its performance.  The performance
        evaluation problem is two-fold: one aspect relates to the evaluation
        of the system-level performance of the network; network, and the other aspect
        relates to the evaluation of resource-level performance, which
        restricts attention to the performance analysis of individual network
        resources.</t>
        <t>In this document, we refer to the system-level characteristics of
        the network as the "macro-states" and the resource-level
        characteristics as the "micro-states."  The system-level
        characteristics are also known as the emergent properties of the
        network.  Correspondingly, we refer to the TE schemes dealing with
        network performance optimization at the systems level as "macro-TE"
        and the schemes that optimize at the individual resource level as
        "micro-TE."  Under certain circumstances, the system-level performance
        can be derived from the resource-level performance using appropriate
        rules of composition, depending upon the particular performance
        measures of interest.</t>
        <t>Another fundamental class of problem concerns how to effectively
       optimize network performance.  Performance optimization may entail
       translating solutions for specific TE problems into
       network configurations.  Optimization may also entail some degree of
       resource management control, routing control, and capacity
       augmentation.</t>
        <section anchor="CONGEST" title="Congestion numbered="true" toc="default">
          <name>Congestion and its Ramifications"> Its Ramifications</name>
          <t>Network congestion is one of the most significant problems in an operational
         IP context.  A network element is said to be congested if it
         experiences sustained overload over an interval of time.  Although congestion
         at the edge of the network may be beneficial in ensuring that the network
         delivers as much traffic as possible, network congestion
         almost always results in degradation of service quality to end users.
         Congestion avoidance and response schemes can include demand-side policies and
         supply-side policies.  Demand-side policies may restrict access to
         congested resources or dynamically regulate the demand to alleviate
         the overload situation.  Supply-side policies may expand or augment
         network capacity to better accommodate offered traffic.  Supply-side
         policies may also re-allocate reallocate network resources by redistributing
         traffic over the infrastructure.  Traffic redistribution and resource
         re-allocation
         reallocation serve to increase the 'effective capacity' effective capacity of the network.</t>
          <t>The emphasis of this document is primarily on congestion management
         schemes falling within the scope of the network, rather than on
         congestion management systems dependent upon sensitivity and
         adaptivity from end-systems. end systems.  That is, the aspects that are
         considered in this document with respect to congestion management are
         those solutions that can be provided by control entities operating on
         the network and by the actions of network administrators and network
         operations systems.</t>
        </section>
      </section>
      <section anchor="SLNCTXT" title="Solution Context"> numbered="true" toc="default">
        <name>Solution Context</name>
        <t>The solution context for Internet TE involves analysis,
        evaluation of alternatives, and choice between alternative courses
        of action.  Generally, the solution context is based on making
        inferences about the current or future state of the
       network, network and making
        decisions that may involve a preference between alternative sets of
        action.  More specifically, the solution context demands reasonable
        estimates of traffic workload, characterization of network state,
        derivation of solutions which that may be implicitly or explicitly
        formulated, and possibly instantiating instantiation of a set of control
        actions.  Control actions may involve the manipulation of parameters
        associated with routing, control over tactical capacity acquisition,
        and control over the traffic management functions.</t>
        <t>The following list of instruments may be applicable to the solution
       context of Internet TE.</t>

    <t><list style="symbols">
        <t>A TE:</t>
        <ul spacing="normal">
          <li>A set of policies, objectives, and requirements (which may be
          context dependent) for network performance evaluation and
          performance optimization.</t>
        <t>A optimization.</li>
          <li>A collection of online and and, in some cases cases, possibly offline tools
          and mechanisms for measurement, characterization, modeling, and
          control of traffic,
           and control over the placement and allocation of
          network resources, as well as control over the mapping or
          distribution of traffic onto the infrastructure.</t>
        <t>A infrastructure.</li>
          <li>A set of constraints on the operating environment, the network
          protocols, and the TE system itself.</t>
        <t>A itself.</li>
          <li>A set of quantitative and qualitative techniques and
          methodologies for abstracting, formulating, and solving TE
           problems.</t>
        <t>A
          problems.</li>
          <li>A set of administrative control parameters which that may be
          manipulated through a configuration management system.  Such a
          system may, itself, may itself include a configuration control subsystem, a
          configuration repository, a configuration accounting subsystem, and
          a configuration auditing subsystem.</t>
        <t>A subsystem.</li>
          <li>A set of guidelines for network performance evaluation,
          performance optimization, and performance improvement.</t>
    </list></t> improvement.</li>
        </ul>
        <t>Determining traffic characteristics through measurement or
        estimation is very useful within the realm of the TE solution space.
        Traffic estimates can be derived from customer subscription
        information, traffic projections, traffic models, and
       from actual
        measurements.  The measurements may be performed at different levels,
        e.g., at the traffic-aggregate level or at the flow level.
        Measurements at the flow level or on small traffic aggregates may be
        performed at edge nodes, when traffic enters and leaves the network.
        Measurements for large traffic-aggregates traffic aggregates may be performed within the
        core of the network.</t>
        <t>To conduct performance studies and to support planning of existing
        and future networks, a routing analysis may be performed to determine
        the paths the routing protocols will choose for various traffic
       demands,
        demands and to ascertain the utilization of network resources as
        traffic is routed through the network.  Routing analysis captures the
        selection of paths through the network, the assignment of traffic
        across multiple feasible routes, and the multiplexing of IP traffic
        over traffic trunks (if such constructs exist) and over the underlying
        network infrastructure.  A model of network topology is necessary to
        perform routing analysis.  A network topology model may be extracted
        from:
       <list style="symbols">
         <t>network
        </t>
        <ul spacing="normal">
          <li>network architecture documents</t>
         <t>network designs</t>
         <t>information documents</li>
          <li>network designs</li>
          <li>information contained in router configuration files</t>
         <t>routing files</li>
          <li>routing databases such as the link state link-state database of an interior
            gateway protocol (IGP)</t>
         <t>routing tables</t>
         <t>automated Interior
          Gateway Protocol (IGP)</li>
          <li>routing tables</li>
          <li>automated tools that discover and collate network topology
            information.</t>
       </list></t>
          information</li>
        </ul>
        <t>Topology information may also be derived from servers that monitor
        network state, state and from servers that perform provisioning
        functions.</t>
        <t>Routing in operational IP networks can be administratively
        controlled at various levels of abstraction abstraction, including the manipulation
        of BGP attributes and IGP metrics.  For path-oriented technologies
        such as MPLS, routing can be further controlled by the manipulation of
        relevant TE parameters, resource parameters, and administrative policy
        constraints.  Within the context of MPLS, the path of an explicitly
        routed label switched path (LSP) LSP can be computed and established in
        various
       ways ways, including:
       <list style="symbols">
         <t>manually</t>
         <t>automatically,
        </t>
        <ul spacing="normal">
          <li>manually</li>
          <li>automatically and online using constraint-based routing processes
          implemented on label switching routers</t>
         <t>automatically, Label Switching Routers (LSRs)</li>
          <li>automatically and offline using constraint-based routing entities
          implemented on external TE support systems.</t>
       </list></t> systems</li>
        </ul>
        <section anchor="COMBAT" title="Combating numbered="true" toc="default">
          <name>Combating the Congestion Problem"> Problem</name>
          <t>Minimizing congestion is a significant aspect of Internet traffic
          engineering.  This subsection gives an overview of the general
          approaches that have been used or proposed to combat congestion.</t>
          <t>Congestion management policies can be categorized based upon the
          following criteria (see <xref target="YARE95" /> format="default"/> for
          a more detailed taxonomy of congestion control schemes):

         <list style="numbers"> schemes):</t>
          <ol spacing="normal" type="1"><li>
              <t>Congestion Management Based on Response Timescales
              <list style="symbols">

                <t>Long </t>
              <ul spacing="normal">
                <li>Long (weeks to months): Expanding network capacity by
                adding new equipment, routers, and links takes time and is
                comparatively costly.  Capacity planning needs to take this
                into consideration.  Network capacity is expanded based on
                estimates or forecasts of future traffic development and
                traffic distribution.  These upgrades are typically carried
                out over weeks or weeks, months, or maybe even years.</t>

                <t>Medium years.</li>
                <li><t>Medium (minutes to days): Several control policies fall
                within the medium timescale category.  Examples include:
                   <list style="letters">
                     <t>Adjusting include:</t>
                  <ol spacing="normal" type="a">
		    <li>Adjusting routing protocol parameters to route traffic
		    away from or towards certain segments of the network.</t>
                     <t>Setting network.</li>
                    <li>Setting up or adjusting explicitly routed LSPs in MPLS
                    networks to route traffic trunks away from possibly
                    congested resources or toward possibly more favorable routes.</t>
                     <t>Re-configuring
                    routes.</li>
                    <li>Reconfiguring the logical topology of the network to
                    make it correlate more closely with the spatial traffic
                    distribution using, for example, an underlying
                    path-oriented technology such as MPLS LSPs or optical
                    channel trails.</t>
                   </list>
                   When trails.</li>
                  </ol>
                  <t>When these schemes are adaptive, they rely on measurement
                  systems.  A measurement system monitors changes in traffic
                  distribution, traffic loads, and network resource
                  utilization and then provides feedback to the online or
                  offline TE mechanisms and tools so that they can trigger
                  control actions within the network.  The TE mechanisms and
                  tools can be implemented in a distributed or centralized
                  fashion.  A centralized scheme may have full visibility into
                  the network state and may produce more optimal solutions.
                  However, centralized schemes are prone to single points of
                  failure and may not scale as well as distributed schemes.
                  Moreover, the information utilized by a centralized scheme
                  may be stale and might not reflect the actual state of the
                  network.  It is not an objective of this document to make a
                  recommendation between distributed and centralized
                   schemes: schemes;
                  that is a choice that network administrators must make based
                  on their specific needs.</t>

                <t>Short
                </li>
                <li>Short (minutes or less): This category includes packet level
                packet-level processing functions and events that are recorded
                on the order of several round-trip times.  It also includes
                router mechanisms such as passive and active buffer
                management.  All of these mechanisms are used to control
                congestion or signal congestion to end systems so that they
                can adaptively regulate the rate at which traffic is injected
                into the network.  A well-known active queue management
                scheme, especially for responsive traffic such as TCP, is
                Random Early Detection (RED) <xref target="FLJA93"/>. target="FLJA93"
                format="default"/>.  During congestion (but before the queue
                is filled), the RED scheme chooses arriving packets to "mark"
                according to a probabilistic algorithm
                   which that takes into account
                the average queue size.  A router that does not utilize explicit congestion notification
                Explicit Congestion Notification (ECN) <xref target="RFC3168" />
                format="default"/> can simply drop marked packets to alleviate
                congestion and implicitly notify the receiver about the
                congestion.  On the other hand, if the router and the end
                hosts support ECN, they can set the ECN field in the packet
                header, and the end host can act on this information.  Several
                variations of RED have been proposed to support different drop
                precedence levels in multi-class environments <xref target="RFC2597"/>.
                target="RFC2597" format="default"/>.  RED provides congestion
                avoidance
                   which that is better than or equivalent to traditional Tail-Drop (TD)
                queue management (drop arriving packets only when the queue is
                full).  Importantly, RED reduces the possibility of
                retransmission bursts becoming synchronized within the network, network
                and improves fairness among different responsive traffic
                sessions.  However, RED by itself cannot prevent congestion
                and unfairness caused by sources unresponsive to RED, e.g.,
                some misbehaved greedy connections.  Other schemes have been
                proposed to improve performance and fairness in the presence
                of unresponsive traffic.  Some of those schemes (such as
                Longest Queue Drop (LQD) and Dynamic Soft Partitioning with
                Random Drop (RND) <xref target="SLDC98"/>) target="SLDC98" format="default"/>)
                were proposed as theoretical frameworks and are typically not
                available in existing commercial products, while others (such
                as Approximate Fairness Through Differential Fair Dropping (AFD) <xref target="AFD03" />
                format="default"/>) have seen some implementation.  Advice on
                the use of Active Queue Management (AQM) schemes is provided
                in <xref target="RFC7567" />. format="default"/>.  <xref
                target="RFC7567" /> format="default"/> recommends self-tuning AQM
                algorithms like those that the IETF has published in <xref
                target="RFC8290" />, format="default"/>, <xref target="RFC8033" />,
                format="default"/>, <xref target="RFC8034" />, format="default"/>,
                and <xref target="RFC9332" />, format="default"/>, but RED is
                still appropriate for links with stable bandwidth, if
                configured carefully.</t>
              </list></t>

           <t>Reactive Versus carefully.</li>
              </ul>
            </li>
            <li><t>Reactive versus Preventive Congestion Management Schemes
              <list style="symbols">
                <t>Reactive
            </t>
              <ul spacing="normal">
                <li>Reactive (recovery) congestion management policies react
                to existing congestion problems.  All the policies described
                above for the short and medium timescales can be categorized
                as being reactive.  They are based on monitoring and
                identifying congestion problems that exist in the network, network and
                on the initiation of relevant actions to ease a situation.
                Reactive congestion management schemes may also be preventive.</t>

                <t>Preventive
                preventive.</li>
                <li>Preventive (predictive/avoidance) policies take proactive
                action to prevent congestion based on estimates and
                predictions of future congestion problems (e.g., traffic
                matrix forecasts).  Some of the policies described for the
                long and medium timescales fall into this category.
                Preventive policies do not necessarily respond immediately to
                existing congestion problems.  Instead, forecasts of traffic
                demand and workload distribution are considered, and action
                may be taken to prevent potential future congestion problems.
                The schemes described for the short timescale can also be used
                for congestion avoidance because dropping or marking packets
                before queues actually overflow would trigger corresponding
                responsive traffic sources to slow down.  Preventive
                congestion management schemes may also be reactive.</t>
              </list></t>

           <t>Supply-Side Versus reactive.</li>
              </ul>
            </li>
            <li><t>Supply-Side versus Demand-Side Congestion Management Schemes
              <list style="symbols">
                <t>Supply-side
            Schemes</t>
              <ul spacing="normal">
                <li>Supply-side congestion management policies increase the
                effective capacity available to traffic in order to control or
                reduce congestion.  This can be accomplished by increasing
                capacity or by balancing distribution of traffic over the
                network.
Capacity planning aims to provide a physical
                topology and associated link bandwidths that match or exceed
                estimated traffic workload and traffic
                   distribution distribution, subject to
                traffic forecasts and budgetary or other (or other) constraints.  If the
                actual traffic distribution does not fit the topology derived
                from capacity planning, then the traffic can be mapped onto
                the topology by using routing control mechanisms, by applying path
                   oriented
                path-oriented technologies (e.g., MPLS LSPs and optical
                channel trails) to modify the logical topology, topology or by
                employing some other load redistribution
                   mechanisms.</t>

                <t>Demand-side mechanisms.</li>
                <li>Demand-side congestion management policies control or
                regulate the offered traffic to alleviate congestion problems.
                For example, some of the short timescale mechanisms described
                earlier as well as policing and rate-shaping mechanisms
                attempt to regulate the offered load in various ways.</t>
              </list></t>
         </list></t> ways.</li>
              </ul>
            </li>
          </ol>

        </section>
      </section>
      <section anchor="IMPCTXT" title="Implementation numbered="true" toc="default">
        <name>Implementation and Operational Context"> Context</name>
        <t>The operational context of Internet TE is
       characterized by constant changes that occur at multiple levels of
       abstraction.  The implementation context demands effective planning,
       organization, and execution.  The planning aspects may involve
       determining prior sets of actions to achieve desired objectives.
       Organizing involves arranging and assigning responsibility to the
       various components of the TE system and coordinating
       the activities to accomplish the desired TE objectives.  Execution
       involves measuring and applying corrective or perfective actions to
       attain and maintain desired TE goals.</t>
      </section>
    </section>
    <section anchor="TEPROC" title="Traffic Engineering numbered="true" toc="default">
      <name>Traffic-Engineering Process Models"> Models</name>
      <t>This section describes a generic process model that captures the
      high-level practical aspects of Internet traffic engineering in an
      operational context.  The process model is described as a sequence of
      actions that must be carried out to optimize the performance of an
      operational network (see also <xref target="RFC2702" />, format="default"/>
      and <xref target="AWD2"/>). target="AWD2" format="default"/>).  This process model may be
      enacted explicitly or implicitly, by a software process or by a
      human.</t>
      <t>The TE process model is iterative <xref target="AWD2" />.
      format="default"/>.  The four phases of the process model described
      below are repeated as a continual
     sequence.

     <list style="symbols">

        <t>Define sequence:</t>
      <ol spacing="normal" type="1">
        <li>Define the relevant control policies that govern the operation of
        the network.</t>

        <t>Acquire network.</li>
        <li>Acquire measurement data from the operational network.</t>

        <t>Analyze network.</li>
        <li>Analyze the network state and characterize the traffic workload.
        Proactive analysis identifies potential problems that could manifest
        in the future.  Reactive analysis identifies existing problems and
        determines their causes.</t>

        <t>Optimize causes.</li>
        <li>Optimize the performance of the network.  This involves a decision
        process which that selects and implements a set of actions from a set of
        alternatives given the results of the three previous steps.
        Optimization actions may include the use of techniques to control the
        offered traffic and to control the distribution of traffic across the
           network.</t>

      </list></t>
        network.</li>
      </ol>
      <section anchor="COMPONENT" title="Components numbered="true" toc="default">
        <name>Components of the Traffic Engineering Traffic-Engineering Process Model"> Model</name>
        <t>The key components of the traffic engineering traffic-engineering process model are as follows.

        <list style="numbers">

           <t>Measurement
        follows:</t>
        <ol spacing="normal" type="1"><li>Measurement is crucial to the TE
        function.  The operational state of a network can only be conclusively
        determined through measurement.  Measurement is also critical to the
        optimization function because it provides feedback data which that is used
        by TE control subsystems.  This data is used to adaptively optimize
        network performance in response to events and stimuli originating
        within and outside the network.  Measurement in support of the TE
        function can occur at different levels of abstraction.  For example,
        measurement can be used to derive packet level packet-level characteristics, flow level flow-level characteristics,
              user user- or customer level customer-level characteristics, traffic aggregate traffic-aggregate characteristics, component level component-level characteristics, and
        network-wide
              characteristics.</t>

           <t>Modeling, characteristics.</li>
          <li>Modeling, analysis, and simulation are important aspects of
          Internet TE.  Modeling involves constructing an abstract or physical
          representation which that depicts relevant traffic characteristics and
          network attributes.  A network model is an abstract representation
          of the network which that captures relevant network features, attributes,
          and characteristics.  Network simulation tools are extremely useful
          for TE.  Because of the complexity of realistic quantitative
          analysis of network behavior, certain aspects of network performance
          studies can only be conducted effectively using simulation.</t>

           <t>Network simulation.</li>
          <li>Network performance optimization involves resolving network
              issues by transforming such issues into concepts that enable a
              solution, identification of a solution, and implementation of the
              solution.  Network performance optimization can be corrective or
              perfective.  In corrective optimization, the goal is to remedy a
              problem that has occurred or that is incipient.  In perfective
              optimization, the goal is to improve network performance even
              when explicit problems do not exist and are not anticipated.</t>

        </list></t> anticipated.</li>
        </ol>
      </section>
    </section>
    <section anchor="TAXI" title="Taxonomy numbered="true" toc="default">
      <name>Taxonomy of Traffic Engineering Systems"> Traffic-Engineering Systems</name>
      <t>This section presents a short taxonomy of traffic engineering traffic-engineering
     systems constructed based on TE styles and views
     as listed below and described in greater detail in the following
     subsections of this document.</t>

  <t><list style="symbols">
       <t>Time-dependent versus State-dependent versus Event-dependent</t>
       <t>Offline versus Online</t>
       <t>Centralized versus Distributed</t>
       <t>Local versus Global Information</t>
       <t>Prescriptive versus Descriptive</t>
       <t>Open Loop versus Closed Loop</t>
       <t>Tactical versus Strategic</t>
     </list></t> document:</t>
      <ul spacing="normal">
        <li><xref target="TIME" format="title"/></li>
        <li><xref target="OFFON" format="title"/></li>
        <li><xref target="CENTRAL" format="title"/></li>
        <li><xref target="LOCAL" format="title"/> Information</li>
        <li><xref target="SCRIPT" format="title"/></li>
        <li><xref target="LOOP" format="title"/></li>
        <li><xref target="TACTIC" format="title"/></li>
      </ul>
      <section anchor="TIME" title="Time-Dependent Versus numbered="true" toc="default">
        <name>Time-Dependent versus State-Dependent Versus Event-Dependent">

    <t>Traffic engineering versus Event-Dependent</name>
        <t>Traffic-engineering methodologies can be classified as time-
       dependent,
        time-dependent, state-dependent, or event-dependent.  All TE schemes
        are considered to be dynamic in this document.  Static TE implies that
        no TE methodology or algorithm is being applied - -- it is a feature of
        network planning, planning but lacks the reactive and flexible nature of
        TE.</t>
        <t>In time-dependent TE, historical information based on periodic
        variations in traffic (such as time of day) is used to pre-program
        routing and other TE control mechanisms.  Additionally, customer
        subscription or traffic projection may be used.  Pre-programmed
        routing plans typically change on a relatively long time
       scale timescale (e.g.,
        daily).  Time-dependent algorithms do not attempt to adapt to
        short-term variations in traffic or changing network conditions.  An
        example of a time-dependent algorithm is a centralized optimizer where
        the input to the system is a traffic matrix and multi-class QoS
        requirements as described in <xref target="MR99"/>. target="MR99" format="default"/>.
        Another example of such a methodology is the application of data
        mining to Internet traffic <xref target="AJ19"/> target="AJ19" format="default"/>,
        which enables the use of various machine learning algorithms to
        identify patterns within historically collected datasets about
        Internet traffic, traffic and to extract information in order to guide decision-making,
        decision-making and to improve efficiency and productivity of
        operational processes.</t>
        <t>State-dependent TE adapts the routing plans based on the current
        state of the network network, which provides additional information on
        variations in actual traffic (i.e., perturbations from regular
        variations) that could not be predicted using historical information.
        Constraint-based routing is an example of state-dependent TE operating
        in a relatively long timescale.  An example of operating in a
        relatively short timescale is a load-balancing algorithm described in
        <xref target="MATE"/>. target="MATE" format="default"/>.  The state of the network can
        be based on parameters flooded by the routers.  Another approach is
        for a particular router performing adaptive TE to send probe packets
        along a path to gather the state of that path.  <xref target="RFC6374" />
        format="default"/> defines protocol extensions to collect performance
        measurements from MPLS networks.  Another approach is for a management
        system to gather the relevant information directly from network
        elements using telemetry data collection "publication/subscription" publication/subscription
        techniques <xref target="RFC7923" />. format="default"/>.  Timely
        gathering and distribution of state information is critical for
        adaptive TE.  While time-dependent algorithms are suitable for
        predictable traffic variations, state-dependent algorithms may be
        needed to increase network efficiency and to provide resilience to
        adapt to changes in network state.</t>
	<t>Event-dependent TE methods can also be used for TE path selection.
	Event-dependent TE methods are distinct from time-dependent and
	state-dependent TE methods in the manner in which paths are selected.
	These algorithms are adaptive and distributed in nature, and they
	typically use learning models to find good paths for TE in a network.
	While state-dependent TE models typically use available-link-bandwidth
	(ALB) flooding <xref target="E.360.1" /> flooding format="default"/> for TE path
	selection, event-dependent TE methods do not require ALB flooding.
	Rather, event-dependent TE methods typically search out capacity by
	learning models, as in the success-to-the-top (STT) method <xref
	target="RFC6601" />. format="default"/>. ALB flooding can be resource
	intensive, since it requires link bandwidth to carry routing protocol link state
       advertisements,
	link-state advertisements and processor capacity to process those advertisements,
       and
	advertisements; in addition, the overhead of the ALB advertisements and
	their processing can limit
       area/Autonomous System (AS) size. the size of the area and AS.  Modeling
	results suggest that event-dependent TE methods could lead to a
	reduction in ALB flooding overhead without loss of network throughput
	performance <xref target="I-D.ietf-tewg-qos-routing"/>.</t> target="I-D.ietf-tewg-qos-routing"
	format="default"/>.</t>
        <t>A fully functional TE system is likely to use all aspects of
        time-dependent, state-dependent, and event-dependent methodologies as
        described in <xref target="HYBRID" />.</t> format="default"/>.</t>
      </section>
      <section anchor="OFFON" title="Offline Versus Online"> numbered="true" toc="default">
        <name>Offline versus Online</name>
        <t>Traffic engineering requires the computation of routing plans.  The
        computation may be performed offline or online.  The computation can
        be done offline for scenarios where routing plans need not be executed
        in real time.  For example, routing plans computed from forecast
        information may be computed offline.  Typically, offline computation
        is also used to perform extensive searches on multi-
       dimensional multi-dimensional
        solution spaces.</t>
        <t>Online computation is required when the routing plans must adapt to
        changing network conditions as in state-dependent algorithms.  Unlike
        offline computation (which can be computationally demanding), online
        computation is geared toward relatively simple and fast calculations
        to select routes, fine-tune the allocations of resources, and perform
        load balancing.</t>
      </section>
      <section anchor="CENTRAL" title="Centralized Versus Distributed"> numbered="true" toc="default">
        <name>Centralized versus Distributed</name>
        <t>Under centralized control control, there is a central authority which that
        determines routing plans and perhaps other TE control parameters on
        behalf of each router.  The central authority periodically collects
        network-state information from all routers, routers and sends routing
        information to the routers.  The update cycle for information exchange
        in both directions is a critical parameter directly impacting the
        performance of the network being controlled.  Centralized control may
        need high processing power and high bandwidth control channels.</t>
        <t>Distributed control determines route selection by each router
        autonomously based on the router&apos;s router's view of the state of the network.
        The network state information may be obtained by the router using a
        probing method or distributed by other routers on a periodic basis
        using link state link-state advertisements.  Network state information may also
        be disseminated under exception conditions.  Examples of protocol
        extensions used to advertise network link state link-state information are
        defined in <xref target="RFC5305"/>, target="RFC5305" format="default"/>, <xref target="RFC6119"/>,
        target="RFC6119" format="default"/>, <xref target="RFC7471"/>, target="RFC7471"
        format="default"/>, <xref target="RFC8570"/>, target="RFC8570" format="default"/>, and
        <xref target="RFC8571"/>. target="RFC8571" format="default"/>.  See also <xref
        target="IGPTE" />.</t> format="default"/>.</t>
        <section anchor="HYBRID" title="Hybrid Systems"> numbered="true" toc="default">
          <name>Hybrid Systems</name>
          <t>In practice, most TE systems will be a hybrid of central and
          distributed control.  For example, a popular MPLS approach to TE is
          to use a central controller based on an active, stateful Path
          Computation Element (PCE), (PCE) but to use routing and signaling protocols
          to make local decisions at routers within the network.  Local
          decisions may be able to respond more quickly to network events, events but
          may result in conflicts with decisions made by other routers.</t>
          <t>Network operations for TE systems may also use a hybrid of
          offline and online computation.  TE paths may be precomputed based
          on stable-state network information and planned traffic demands, demands but
          may then be modified in the active network depending on variations
          in network state and traffic load.  Furthermore, responses to
          network events may be precomputed offline to allow rapid reactions
          without further computation, computation or may be derived online depending on
          the nature of the events.</t>

      <t>Lastly, note that a fully functional TE system is likely to use all aspects of
         time-dependent, state-dependent, and event-dependent methodologies as described in
         <xref target="TIME" />.</t>
        </section>
        <section anchor="SDN" title="Considerations numbered="true" toc="default">
          <name>Considerations for Software Defined Networking"> Software-Defined Networking</name>
          <t>As discussed in <xref target="ACTN" />, format="default"/>, one of
          the main drivers for
         SDN Software-Defined Networking (SDN) is a
          decoupling of the network control plane from the data plane <xref
          target="RFC7149" />. format="default"/>. However, SDN may also combine
          centralized control of resources, resources and facilitate
          application-to-network interaction via an application programming interface (API) Application Programming
          Interface (API), such as the one described in <xref target="RFC8040" />.
          format="default"/>. Combining these features provides a flexible
          network architecture that can adapt to the network requirements of a
          variety of higher-layer applications, a concept often referred to as
          the "programmable network" <xref target="RFC7426" />.</t>
          format="default"/>.</t>
          <t>The centralized control aspect of SDN helps improve network
          resource utilization compared with distributed network control,
          where local policy may often override network-wide optimization
          goals.  In an SDN environment, the data plane forwards traffic to
          its desired destination. However, before traffic reaches the data
          plane, the logically centralized SDN control plane often determines
          the path the application traffic will take in the network.
          Therefore, the SDN control plane needs to be aware of the underlying
          network topology, capabilities capabilities, and current node and link resource
          state.</t>
          <t>Using a PCE-based SDN control framework <xref target="RFC7491" />,
          format="default"/>, the available network topology may be discovered
          by running a passive instance of OSPF or IS-IS, or via BGP-LS BGP Link
          State (BGP-LS) <xref target="RFC7752" />, target="RFC9552" format="default"/>), to
          generate a Traffic Engineering Database (TED, see (TED) (see <xref
          target="STATE" />). format="default"/>).  The PCE is used to compute a
          path (see <xref target="PCE" />) format="default"/>) based on the TED
          and available bandwidth, and further path optimization may be based
          on requested objective functions <xref target="RFC5541" />.
          format="default"/>.  When a suitable path has been computed computed, the
          programming of the explicit network path may be either performed
          using either a signaling protocol that traverses the length of the path
          <xref target="RFC3209" /> format="default"/> or performed per-hop with
          each node being directly programmed <xref target="RFC8283" />
          format="default"/> by the SDN controller.</t>
          <t>By utilizing a centralized approach to network control,
          additional network benefits are also available, including Global
          Concurrent Optimization (GCO) <xref target="RFC5557" />.
          format="default"/>.  A GCO path computation request will
          simultaneously use the network topology and a set of new path
          signaling requests, along with their respective constraints, for
          optimal placement in the network.  Correspondingly, a GCO-based
          computation may be applied to recompute existing network paths to
          groom traffic and to mitigate congestion.</t>
        </section>
      </section>
      <section anchor="LOCAL" title="Local Versus Global">

     <t>Traffic engineering numbered="true" toc="default">
        <name>Local versus Global</name>
        <t>Traffic-engineering algorithms may require local and global network-
        state
        network-state information.</t>
        <t>Local information is the state of a portion of the domain.
        Examples include the bandwidth and packet loss rate of a particular path,
        path or the state and capabilities of a network link.  Local state
        information may be sufficient for certain instances of distributed
        control TE.</t>
        <t>Global information is the state of the entire TE domain.  Examples
        include a global traffic matrix, matrix and loading information on each link
        throughout the domain of interest.  Global state information is
        typically required with centralized control.  Distributed TE systems
        may also need global information in some cases.</t>
      </section>
      <section anchor="SCRIPT" title="Prescriptive Versus Descriptive"> numbered="true" toc="default">
        <name>Prescriptive versus Descriptive</name>
        <t>TE systems may also be classified as prescriptive or descriptive.</t>
        <t>Prescriptive traffic engineering evaluates alternatives and
        recommends a course of action.  Prescriptive TE can be further
        categorized as either corrective or perfective.  Corrective TE
        prescribes a course of action to address an existing or predicted
        anomaly.  Perfective TE prescribes a course of action to evolve and
        improve network performance even when no anomalies are evident.</t>
        <t>Descriptive traffic engineering, on the other hand, characterizes
        the state of the network and assesses the impact of various policies
        without recommending any particular course of action.</t>
        <section anchor="INTENT" title="Intent-Based Networking"> numbered="true" toc="default">
          <name>Intent-Based Networking</name>
          <t>One way to express a service request is through "intent".
          Intent-Based Networking aims to produce networks that are simpler to
          manage and operate, requiring only minimal intervention.  Intent is
          defined in <xref target="RFC9315" /> format="default"/> as a follows:</t>
<blockquote>
	  A set of operational goals (that a network should meet) and outcomes
	  (that a network is supposed to deliver), deliver) defined in a declarative
	  manner without specifying how to achieve or implement them.</t>
	  them.</blockquote>
          <t>Intent provides data and functional abstraction so that users and
          operators do not need to be concerned with low-level device
          configuration or the mechanisms used to achieve a given intent.
          This approach can be conceptually easier for a user, user but may be less
          expressive in terms of constraints and guidelines.</t>
          <t>Intent-Based Networking is applicable to TE because many of the
          high-level objectives may be expressed as "intent."  For intent (for example,
          load balancing, delivery of services, and robustness against failures.
          failures).  The intent is converted by the management system into TE
          actions within the network.</t>
        </section>
      </section>
      <section anchor="LOOP" title="Open-Loop Versus Closed-Loop"> numbered="true" toc="default">
        <name>Open-Loop versus Closed-Loop</name>
        <t>Open-loop traffic engineering traffic-engineering control is where control action does
        not use feedback information from the current network state.  The  However,
        the control action may use its own local information for accounting
       purposes, however.</t>
        purposes.</t>
        <t>Closed-loop traffic engineering traffic-engineering control is where control action
        utilizes feedback information from the network state.  The feedback
        information may be in the form of current measurement or recent
        historical records.</t>
      </section>
      <section anchor="TACTIC" title="Tactical numbered="true" toc="default">
        <name>Tactical versus Strategic"> Strategic</name>
        <t>Tactical traffic engineering aims to address specific performance
       problems (such as hot-spots) hotspots) that occur in the network from a
       tactical perspective, without consideration of overall strategic
       imperatives.  Without proper planning and insights, tactical TE tends
       to be ad hoc in nature.</t>
        <t>Strategic traffic engineering traffic-engineering approaches the TE problem from a more
       organized and systematic perspective, taking into consideration the
       immediate and longer-term consequences of specific policies and
       actions.</t>
      </section>
    </section>
    <section anchor="REVIEW" title="Review numbered="true" toc="default">
      <name>Review of TE Techniques"> Techniques</name>
      <t>This section briefly reviews different TE-related approaches proposed
      and implemented in telecommunications and computer networks using IETF
      protocols and architectures.  These approaches are organized into three categories:
      <list style="symbols">
        <t>TE
      categories:</t>
      <ul spacing="normal">
        <li>TE mechanisms which that adhere to the definition provided in <xref
        target="COMPONENTS" />.</t>
        <t>Approaches format="default"/></li>
        <li>Approaches that rely upon those TE mechanisms.</t>
        <t>Techniques mechanisms</li>
        <li>Techniques that are used by those TE mechanisms and approaches.</t>
      </list></t>
        approaches</li>
      </ul>
      <t>The discussion is not intended to be comprehensive.  It is primarily
      intended to illuminate existing approaches to TE in the Internet.  A
      historic overview of TE in telecommunications networks was provided in Section 4 of
      <xref target="RFC3272" />, sectionFormat="of" section="4"/>, and Section 4.6
      <xref target="RFC3272" sectionFormat="bare" section="4.6"/> of that
      document presented an outline of some early approaches to TE conducted
      in other standards bodies.  It is out of the scope of this document to
      provide an analysis of the history of TE or an inventory of TE-related
      efforts conducted by other SDOs.</t> Standards Development Organizations
      (SDOs).</t>
      <section anchor="OTHER" title="Overview numbered="true" toc="default">
        <name>Overview of IETF Projects Related to Traffic Engineering"> Engineering</name>
        <t>This subsection reviews a number of IETF activities pertinent to
        Internet traffic engineering.  Some of these technologies are widely
        deployed, others are mature but have seen less
        deployment, and some are unproven or are still under
        development.</t>
        <section anchor="TEMech" title="IETF numbered="true" toc="default">
          <name>IETF TE Mechanisms"> Mechanisms</name>
          <section anchor="INTSERV" title="Integrated Services"> numbered="true" toc="default">
            <name>Integrated Services</name>
            <t>The IETF developed the Integrated Services (Intserv) model that
            requires resources, such as bandwidth and buffers, to be reserved
            a priori for a given traffic flow to ensure that the quality of service QoS requested
            by the traffic flow is satisfied.  The Integrated Services Intserv model includes
            additional components beyond those used in the best-effort model
            such as packet classifiers, packet schedulers, and admission
            control.  A packet classifier is used to identify flows that are
            to receive a certain level of service.  A packet scheduler handles
            the scheduling of service to different packet flows to ensure that
            QoS commitments are met.  Admission control is used to determine
            whether a router has the necessary resources to accept a new
            flow.</t>
            <t>The main issue with the Integrated Services Intserv model has been scalability
            <xref target="RFC2998"/>, target="RFC2998" format="default"/>, especially in large
            public IP networks which that may potentially have millions of active
            traffic flows in transit concurrently.  Pre-Congestion
            Notification (PCN) <xref target="RFC5559" /> format="default"/>
            solves the scaling problems of Intserv by using measurement-based
            admission control (and flow termination to handle failures)
            between edge-nodes. edge nodes.  Nodes between the edges of the internetwork
            have no per-flow operations operations, and the edge nodes can use the
            Resource Reservation Protocol (RSVP) per-flow or
            per-aggregate.</t>
            <t>A notable feature of the Integrated Services Intserv model is that it requires
            explicit signaling of QoS requirements from end systems to routers
            <xref target="RFC2753"/>. target="RFC2753" format="default"/>.  RSVP performs this
            signaling function and is a critical component of the Integrated Services Intserv
            model.  RSVP is described in <xref target="RSVP" />.</t>
            format="default"/>.</t>
          </section>
          <section anchor="DIFFSERV" title="Differentiated Services"> numbered="true" toc="default">
            <name>Differentiated Services</name>
            <t>The goal of Differentiated Services (Diffserv) within the IETF
            was to devise scalable mechanisms for categorization of traffic
            into behavior aggregates, which ultimately allows each behavior
            aggregate to be treated differently, especially when there is a
            shortage of
           resources resources, such as link bandwidth and buffer space
            <xref target="RFC2475"/>. target="RFC2475" format="default"/>.  One of the primary
            motivations for Diffserv was to devise alternative mechanisms for
            service differentiation in the Internet that mitigate the
            scalability issues encountered with the Intserv model.</t>
            <t>Diffserv uses the Differentiated Services field in the IP
            header (the DS field) consisting of six bits in what was formerly
            known as the Type of Service (TOS) octet.  The DS field is used to
            indicate the forwarding treatment that a packet should receive at
            a transit node <xref target="RFC2474"/>. target="RFC2474" format="default"/>.
            Diffserv includes the concept of Per-Hop Behavior (PHB) groups.
            Using the PHBs, several classes of services can be defined using
            different classification, policing, shaping, and scheduling
            rules.</t>
            <t>For an end-user end user of network services to utilize Differentiated
           Services Diffserv
            provided by its Internet Service Provider (ISP), it may
            be necessary for the user to have an SLA with the ISP.  An SLA may
            explicitly or implicitly specify a Traffic Conditioning Agreement
            (TCA) which that defines classifier rules as well as metering, marking,
            discarding, and shaping rules.</t>
            <t>Packets are classified, classified and possibly policed and shaped at the
            ingress to a Diffserv network.  When a packet traverses the
            boundary between different Diffserv domains, the DS field of the
            packet may be re-marked according to existing agreements between
            the domains.</t>

        <t>Differentiated Services
            <t>Diffserv allows only a finite number of service
            classes to be specified by the DS field.  The main advantage of
            the Diffserv approach relative to the Intserv model is
            scalability.  Resources are allocated on a per-class basis basis, and the
            amount of state information is proportional to the number of
            classes rather than to the number of application flows.</t>
            <t>Once the network has been planned and the packets have been
            marked at the network edge, the Diffserv model deals with traffic
            management issues on a per hop per-hop basis.  The Diffserv control model
            consists of a collection of micro-TE control mechanisms.  Other TE
            capabilities, such as capacity management (including routing
            control), are also required in order to deliver acceptable service
            quality in Diffserv networks.  The concept of Per Domain Behaviors "Per-Domain
            Behaviors" has been introduced to better capture the notion of Differentiated Services
            Diffserv across a complete domain <xref target="RFC3086"/>.</t> target="RFC3086"
            format="default"/>.</t>
            <t>Diffserv procedures can also be applied in an MPLS context.  See
           <xref target="TEDIFFSRV" /> format="default"/> for more information.</t>
          </section>
          <section anchor="SRPolicy" title="Segment Routing Policy"> numbered="true" toc="default">
            <name>SR Policy</name>
            <t>SR Policy <xref target="RFC9256" /> format="default"/> is an
            evolution of Segment Routing SR (see <xref target="SR" />)
            format="default"/>) to enhance the TE capabilities of SR.  It is a
            framework that enables instantiation of an ordered list of
            segments on a node for implementing a source routing policy with a
            specific intent for traffic steering from that node.</t>
	    <t>An SR Policy is identified through the tuple &lt;head-end, &lt;headend,
	    color, end-point&gt;. endpoint&gt;. The head-end headend is the IP address of the node
	    where the policy is instantiated.  The endpoint is the IP address
	    of the destination of the policy.  The color is an index that
	    associates the SR Policy with an intent (e.g., low latency).</t>
            <t>The head-end headend node is notified of SR Policies and associated SR
            paths via configuration or by extensions to protocols such as PCEP the Path Computation Element Communication Protocol (PCEP)
            <xref target="RFC8664" /> format="default"/> or BGP <xref
            target="I-D.ietf-idr-segment-routing-te-policy" />.
            format="default"/>.  Each SR path consists of a Segment-List segment list (an
            SR source-routed path), and the head-end headend uses the endpoint and
            color parameters to classify packets to match the SR policy Policy and so
            determine along which path to forward them.  If an SR Policy is
            associated with a set of SR paths, each is associated with a
            weight for weighted load balancing.  Furthermore, multiple SR
            Policies may be associated with a set of SR paths to allow
            multiple traffic flows to be placed on the same paths.</t>
            <t>An SR Binding SID (BSID) may also be associated with each
            candidate path associated with an SR Policy, Policy or
            with the SR Policy itself.  The
            head-end headend node installs a
            BSID-keyed entry in the forwarding plane and assigns it the action
            of steering packets that match the entry to the selected path of
            the SR Policy.  This steering can be done in various ways:
            <list style="symbols">
              <t>SID Steering: Incoming ways:</t>
            <dl newline="false" spacing="normal">
              <dt>SID Steering:</dt><dd>Incoming packets have an active SID Segment Identifier (SID) matching a local BSID at
	      the head-end.</t>
              <t>Per-destination Steering: headend.</dd>
              <dt>Per-destination Steering:</dt><dd>
	      Incoming packets match a BGP/Service route route, which indicates
	      an SR Policy.</t>
              <t>Per-flow Steering: Policy.</dd>
              <dt>Per-flow Steering:</dt><dd>
	      Incoming packets match a forwarding array (for example, the
	      classic 5-tuple) 5-tuple), which indicates an SR Policy.</t>
              <t>Policy-based Steering: Policy.</dd>
              <dt>Policy-based Steering:</dt><dd>
	      Incoming packets match a routing policy policy, which directs them
	      to an SR Policy.</t>
            </list></t> Policy.</dd>
            </dl>
          </section>
          <section anchor="QUIC" title="Layer numbered="true" toc="default">
            <name>Layer 4 Transport-Based TE"> TE</name>
            <t>In addition to IP-based TE mechanisms, layer Layer 4 transport-based
            TE approaches can be considered in specific deployment contexts
            (e.g., data centers, centers and multi-homing).  For example, the 3GPP defines
            the Access Traffic Steering, Switching, and Splitting (ATSSS)
            <xref target="ATSSS" /> format="default"/> service functions as follows.
           <list style="hanging">
              <t hangText='Access
            follows:
            </t>
            <dl newline="false" spacing="normal">
              <dt>Access Traffic Steering:'> This Steering:</dt>
              <dd>This is the selection of an access network for a new flow
              and the transfer of the traffic of that flow over the selected
              access network.</t>

              <t hangText='Access network.</dd>
              <dt>Access Traffic Switching:'> This Switching:</dt>
              <dd>This is the migration of all packets of an ongoing flow from
              one access network to another access network.  Only one access
              network is in use at a time.</t>

              <t hangText='Access time.</dd>
              <dt>Access Traffic Splitting:'> This Splitting:</dt>
              <dd>This is about forwarding the packets of a flow across
              multiple access networks simultaneously.</t>
           </list></t> simultaneously.</dd>
            </dl>
            <t>The control plane is used to provide hosts and specific network
            devices with a set of policies that specify which flows are
            eligible to use the ATSSS service.  The traffic that matches an
            ATSSS policy can be distributed among the available access
            networks following one of the following four modes.
           <list style="hanging">
              <t hangText='Active-Standby:'> The modes:</t>
            <dl newline="false" spacing="normal">
              <dt>Active-Standby:</dt>
              <dd>The traffic is forwarded via a specific access (called
              "active access") and switched to another access (called "standby
              access") when the active access is unavailable.</t>

              <t hangText='Priority-based:'> Network unavailable.</dd>
              <dt>Priority-based:</dt>
              <dd>Network accesses are assigned priority levels that indicate
              which network access is to be used first.  The traffic
              associated with the matching flow will be steered onto the
              network access with the highest priority until congestion is detected, then
              detected. Then, the overflow will be forwarded over the next
              highest priority access.</t>

              <t hangText='Load-Balancing:'> The access.</dd>
              <dt>Load-Balancing:</dt>
              <dd>The traffic is distributed among the available access
              networks following a distribution ratio (e.g., 75% - 25%).</t>

              <t hangText='Smallest Delay:'> The to 25%).</dd>
              <dt>Smallest Delay:</dt>
              <dd>The traffic is forwarded via the access that presents the
              smallest
                 round-trip-time (RTT).</t>
           </list></t> round-trip time (RTT).</dd>
            </dl>
            <t>For resource management purposes, hosts and network devices
            support means such as congestion control, RTT measurement, and
            packet scheduling.</t>
            <t>For TCP traffic, Multipath TCP <xref target="RFC8684" />
            format="default"/> and the 0-RTT Convert Protocol <xref
            target="RFC8803" /> format="default"/> are used to provide the ATSSS
            service.</t>
            <t>Multipath QUIC <xref target="I-D.ietf-quic-multipath" />
            format="default"/> and Proxying UDP in HTTP
            <xref target="RFC9298" /> format="default"/> are used to provide the
            ATSSS service for UDP traffic.  Note that QUIC <xref
            target="RFC9000" /> natively
           support format="default"/> supports the
            switching and steering functions.  Indeed, QUIC supports a
            connection migration procedure that allows peers to change their layer
            Layer 4 transport coordinates (IP addresses, port numbers) without
            breaking the underlying QUIC connection.</t>
            <t>Extensions to the Datagram Congestion Control Protocol (MP-DCCP)
            (DCCP) <xref target="RFC4340" /> format="default"/> to support
            multipath operations are defined in <xref
            target="I-D.ietf-tsvwg-multipath-dccp" />.</t> format="default"/>.</t>
          </section>
          <section anchor="DETNET" title="Deterministic Networking"> numbered="true" toc="default">
            <name>Deterministic Networking</name>
            <t>Deterministic Networking (DetNet) <xref target="RFC8655" /> format="default"/> is an
            architecture for applications with critical timing and reliability
            requirements.  The layered architecture particularly focuses on
            developing DetNet service capabilities in the data plane <xref
            target="RFC8938" />. format="default"/>.  The DetNet service sub-layer
            provides a set of Packet Replication, Elimination, and Ordering
            Functions (PREOF) to provide end-to-end service assurance.  The
            DetNet forwarding sub-layer provides corresponding forwarding
            assurance (low packet loss, bounded latency, and in-order
            delivery) functions using resource allocations and explicit route
            mechanisms.</t>
            <t>The separation into two sub-layers allows a greater flexibility
            to adapt DetNet capability over a number of TE data plane mechanisms
            mechanisms, such as IP, MPLS, and Segment Routing. SR.  More importantly
            importantly, it interconnects IEEE 802.1 Time Sensitive Networking
            (TSN) <xref target="RFC9023" /> format="default"/> deployed in
            Industry Control and Automation Systems (ICAS).</t>
            <t>DetNet can be seen as a specialized branch of TE, since it sets
            up explicit optimized paths with allocation of resources as
            requested.  A DetNet application can express its QoS attributes or
            traffic behavior using any combination of DetNet functions
            described in sub-layers.  They are then distributed and
            provisioned using well-
            established well-established control and provisioning
            mechanisms adopted for traffic engineering.</t>
            <t>In DetNet, a considerable amount of state information is
            required to maintain per-flow queuing disciplines and resource
            reservation for a large number of individual flows.  This can be
            quite challenging for network operations during network events events,
            such as faults, change in traffic volume volume, or re-provisioning. reprovisioning.
            Therefore, DetNet recommends support for aggregated flows, flows;
            however, it still requires a large amount of control signaling to
            establish and maintain DetNet flows.</t>
            <t>Note that DetNet might suffer from some of the scalability
            concerns described for Intserv in <xref target="INTSERV" />,
            format="default"/>, but the scope of DetNet&apos;s DetNet's deployment scenarios
            is smaller and so therefore less exposed to scaling issues.</t>
          </section>
        </section>
        <section anchor="TEapproach" title="IETF numbered="true" toc="default">
          <name>IETF Approaches Relying on TE Mechanisms"> Mechanisms</name>
          <section anchor="ALTO" title="Application-Layer numbered="true" toc="default">
            <name>Application-Layer Traffic Optimization"> Optimization</name>
            <t>This document describes various TE mechanisms available in the
            network.  However, in general, distributed applications in general and, in particular,
            (particularly, bandwidth-greedy P2P applications that are used,
            for example, used for
            file sharing, for example) cannot directly use those techniques.
            As per <xref target="RFC5693" />, format="default"/>, applications
            could greatly improve traffic distribution and quality by
            cooperating with external services that are aware of the network
            topology.  Addressing the Application-Layer Traffic Optimization
            (ALTO) problem means, on the one hand, deploying an ALTO service
            to provide applications with information regarding the underlying
            network (e.g., basic network location structure and preferences of
            network paths) and, on the other hand, enhancing applications in
            order to use such information to perform better-than-random
            selection of the endpoints with which they establish
            connections.</t>

            <t>The basic function of ALTO is based on abstract maps of a
            network.  These maps provide a simplified view, yet enough
            information about a network for applications to effectively
            utilize them.  Additional services are built on top of the maps.
            <xref target="RFC7285" /> format="default"/> describes a protocol
            implementing the ALTO services as an information-publishing
            interface that allows a network to publish its network information
            to network applications.  This information can include network
            node locations, groups of node-to-node connectivity arranged by
            cost according to configurable granularities, and end-host
            properties.  The information published by the ALTO Protocol should
            benefit both the network and the applications.  The ALTO Protocol
            uses a REST-ful design and encodes its requests and responses
            using JSON <xref target="RFC8259" /> format="default"/> with a
            modular design by dividing ALTO information publication into
            multiple ALTO services (e.g., the Map service, Service, the Map-Filtering
            Service, the Endpoint Property Service, and the Endpoint Cost
            Service).</t>
            <t><xref target="RFC8189" /> format="default"/> defines a new service
            that allows an ALTO Client to retrieve several cost metrics in a
            single request for an ALTO filtered cost map and endpoint cost
            map.  <xref target="RFC8896" /> format="default"/> extends the ALTO
            cost information service so that applications decide not only 'where'
            "where" to connect, connect but also 'when'. "when".  This is useful for
            applications that need to perform bulk data transfer and would
            like to schedule these transfers during an off-peak hour, for
            example.  <xref target="RFC9439" /> format="default"/> introduces
            network performance metrics, including network delay, jitter,
            packet loss rate, hop count, and bandwidth.  The ALTO server may
            derive and aggregate such performance metrics from BGP-LS (see
            <xref target="BGPLS" />) or format="default"/>), IGP-TE (see <xref
            target="IGPTE" />), format="default"/>), or management tools, tools and then
            expose the information to allow applications to determine 'where' "where"
            to connect based on network performance criteria.  The ALTO WG
            Working Group is evaluating the use of network TE properties while
            making application decisions for new use cases such as Edge edge
            computing and Datacenter data-center interconnect.</t>
          </section>
          <section anchor="ACTN" title="Network numbered="true" toc="default">
            <name>Network Virtualization and Abstraction"> Abstraction</name>
            <t>One of the main drivers for Software Defined Networking (SDN) SDN
            <xref target="RFC7149" /> format="default"/> is a decoupling of the
            network control plane from the data plane.  This separation has
            been achieved for TE networks with the development of MPLS/GMPLS MPLS and GMPLS
            (see Sections <xref target="MPLS" /> format="counter"/> and <xref
            target="GMPLS" />) format="counter"/>, respectively) and the PCE (<xref (see <xref target="PCE" />).
            format="default"/>).  One of the advantages of SDN is its
            logically centralized control regime that allows a full view of
            the underlying networks.  Centralized control in SDN helps improve
            network resource utilization compared with distributed network
            control.</t>
            <t>Abstraction and Control of TE Networks (ACTN) <xref
            target="RFC8453" /> format="default"/> defines a hierarchical SDN
            architecture which that describes the functional entities and methods
            for the coordination of resources across multiple domains, to
            provide composite traffic-engineered services.  ACTN facilitates
            composed, multi-domain connections and provides them to the user.
            ACTN is focused on:
            <list style="symbols">
              <t>Abstraction
            </t>
            <ul spacing="normal">
              <li>Abstraction of the underlying network resources and how they
              are provided to higher-layer applications and customers.</t>
              <t>Virtualization customers.</li>
              <li>Virtualization of underlying resources for use by the
              customer, application, or service.  The creation of a
              virtualized environment allows operators to view and control
              multi-domain networks as a single virtualized network.</t>
              <t>Presentation network.</li>
              <li>Presentation to customers of networks as a virtual network
              via open and programmable interfaces.</t>
            </list></t> interfaces.</li>
            </ul>
            <t>The ACTN managed infrastructure is built from
            traffic-engineered network resources, which may include
            statistical packet bandwidth, physical
            forwarding plane forwarding-plane sources
            (such as wavelengths and time slots), and forwarding and cross-connect
            capabilities.  The type of network virtualization seen in ACTN
            allows customers and applications (tenants) to utilize and
            independently control allocated virtual network resources as if
            they were physically their own resource.  The ACTN network is "sliced",
            sliced, with tenants being given a different partial and
            abstracted topology view of the physical underlying network.</t>
          </section>
          <section anchor="SLICE" title="Network Slicing"> numbered="true" toc="default">
            <name>Network Slicing</name>
            <t>An IETF Network Slice is a logical network topology connecting
            a number of endpoints using a set of shared or dedicated network
            resources <xref target="I-D.ietf-teas-ietf-network-slices" />.
            format="default"/>.  The resources are used to satisfy specific Service Level Objectives (SLOs)
            SLOs specified by the consumer.</t>
            <t>IETF network slices Network Slices are not, of themselves, TE constructs.
            However, a network operator that offers IETF network slices Network Slices is
            likely to use many TE tools in order to manage their network and
            provide the services.</t>
            <t>IETF Network Slices are defined such that they are independent
            of the underlying infrastructure connectivity and technologies
            used.  From a customer&apos;s customer's perspective, an IETF Network Slice looks
            like a VPN connectivity matrix with additional information about
            the level of service that the customer requires between the
            endpoints.  From an operator&apos;s operator's perspective, the IETF Network Slice
            looks like a set of routing or tunneling instructions with the
            network resource reservations necessary to provide the required
            service levels as specified by the SLOs.  The concept of an IETF network slice
            Network Slice is consistent with an enhanced VPN (VPN+) <xref
            target="I-D.ietf-teas-enhanced-vpn" />.</t> format="default"/>.</t>
          </section>
        </section>
        <section anchor="TEtech" title="IETF numbered="true" toc="default">
          <name>IETF Techniques Used by TE Mechanisms"> Mechanisms</name>
          <section anchor="CSPF" title="Constraint-Based Routing"> numbered="true" toc="default">
            <name>Constraint-Based Routing</name>
            <t>Constraint-based routing refers to a class of routing systems that
           compute routes through a network subject to the satisfaction of a set
           of constraints and requirements.  In the most general case,
           constraint-based routing may also seek to optimize overall network
           performance while minimizing costs.</t>
            <t>The constraints and requirements may be imposed by the network itself
           or by administrative policies.  Constraints may include bandwidth,
           hop count, delay, and policy instruments such as resource class
           attributes.  Constraints may also include domain-specific attributes
           of certain network technologies and contexts which that impose
           restrictions on the solution space of the routing function.  Path
           oriented  Path-oriented technologies such as MPLS have made constraint-based routing
           feasible and attractive in public IP networks.</t>

            <t>The concept of constraint-based routing within the context of MPLS
           TE
            MPLS-TE requirements in IP networks was first described in <xref target="RFC2702"/>
            target="RFC2702" format="default"/> and led to developments such
            as MPLS-TE <xref target="RFC3209"/> target="RFC3209" format="default"/> as described
            in <xref target="MPLS"/>.</t> target="MPLS" format="default"/>.</t>
            <t>Unlike QoS-based routing (for example, see <xref target="RFC2386"/>,
            target="RFC2386" format="default"/>, <xref target="MA"/>, target="MA"
            format="default"/>, and <xref target="I-D.ietf-idr-performance-routing"/>)
           which
            target="I-D.ietf-idr-performance-routing" format="default"/>) that
            generally addresses the issue of routing individual traffic flows
            to satisfy prescribed flow-based QoS requirements subject to
            network resource availability, constraint-based routing is
            applicable to traffic aggregates as well as flows and may be
            subject to a wide variety of constraints which that may include policy
            restrictions.</t>
            <section anchor="FLEX" title="IGP numbered="true" toc="default">
              <name>IGP Flexible Algorithms (Flex-Algos)"> Algorithms</name>
              <t>The traditional normal approach to routing in an IGP network relies
              on the IGPs deriving "shortest paths" over the network based
              solely on the IGP metric assigned to the links.  Such an
              approach is often limited: traffic may tend to converge
              toward the destination, possibly causing congestion; congestion, and it is
              not possible to steer traffic onto paths depending on the
              end-to-end qualities demanded by the applications.</t>
              <t>To overcome this limitation, various sorts of TE have been
              widely deployed (as described in this document), where the TE
              component is responsible for computing the path based on
              additional metrics and/or constraints.  Such paths (or tunnels)
              need to be installed in the routers&apos; routers' forwarding tables in
              addition to, or as a replacement for for, the original paths computed
              by IGPs.  The main drawback drawbacks of these TE approaches is are the
              additional complexity of protocols and management, management and the state
              that may need to be maintained within the network.</t>

              <t>IGP flexible algorithms (flex-algos) Flexible Algorithms <xref target="RFC9350" />
              format="default"/> allow IGPs to construct constraint-based
              paths over the network by computing constraint-
              based constraint-based next hops.
              The intent of flex-algos Flexible Algorithms is to reduce TE complexity by letting
              an IGP perform some basic TE computation capabilities.  Flex-algo
              Flexible Algorithm includes a set of extensions to the IGPs that enable a
              router to send TLVs that:
              <list style="symbols">
                 <t>describe that:</t>
              <ul spacing="normal">
                <li>describe a set of constraints on the topology</t>
                 <t>identify calculation-type</t>
                 <t>describe topology</li>
                <li>identify calculation-type</li>
                <li>describe a metric-type that is to be used to compute the
                best paths through the constrained topology.</t>
              </list>
              A topology</li>
              </ul>
              <t>A given combination of calculation-type, metric-type, and
              constraints is known as a
              "Flexible Flexible Algorithm Definition" (or FAD). Definition
              (FAD).  A router that sends such a set of TLVs also assigns a
              specific identifier (the Flexible Algorithm) to the specified
              combination of calculation-type, metric-type, and
              constraints.</t>
              <t>There are two use cases for flex-algo: Flexible Algorithm: in IP networks <xref target="I-D.ietf-lsr-ip-flexalgo" />
              target="RFC9502" format="default"/> and in Segment Routing SR
              networks <xref target="RFC9350" />. format="default"/>.  In the
              first case,
              flex-algo Flexible Algorithm computes paths to an IPv4 or IPv6 address, address;
              in the second case, flex-algo Flexible Algorithms computes paths to a prefix Prefix SID
              (see <xref target="SR" />).</t> format="default"/>).</t>
              <t>Examples of where flex-algo Flexible Algorithms can be useful include:
              <list style="symbols">
                 <t>Expansion include:</t>
              <ul spacing="normal">
                <li>Expansion of the function of IP Performance performance metrics <xref
                target="RFC5664" /> format="default"/> where specific
                constraint-based routing (flex-algo) (Flexible Algorithm) can be instantiated
                within the network based on the results of performance measurement.</t>
                 <t>The
                measurement.</li>
                <li>The formation of an 'underlay' "underlay" network using flex-algo, Flexible Algorithms,
                and the realization of an 'overlay' "overlay" network using TE
                techniques.  This approach can leverage the nested combination
                of flex-algo Flexible Algorithm and TE extensions for IGP (see <xref
                target="IGPTE" />).</t>
                 <t>Flex-algo format="default"/>).</li>
                <li>Flexible Algorithms in SR-MPLS (<xref target="SR" />)
                format="default"/>) can be used as a base to easily build a
                TE-like topology without TE components on routers or the use
                of a PCE (see <xref target="PCE" />).</t>
                 <t>The format="default"/>).</li>

                <li>The support for network slices <xref
                target="I-D.ietf-teas-ietf-network-slices" /> format="default"/>
                where the SLOs of a particular IETF network slice Network Slice can be
                guaranteed by a flex-algo, Flexible Algorithm or where a Filtered Topology <xref
                target="I-D.ietf-teas-ietf-network-slices" /> format="default"/>
                can be created as a TE-like topology using a flex-algo.</t>
              </list></t> Flexible Algorithm.</li>
              </ul>
            </section>
          </section>
          <section anchor="RSVP" title="RSVP"> numbered="true" toc="default">
            <name>RSVP</name>
            <t>RSVP is a soft-state signaling protocol <xref target="RFC2205"/>. target="RFC2205"
            format="default"/>.  It supports receiver-initiated establishment
            of resource reservations for both multicast and unicast flows.
            RSVP was originally developed as a signaling protocol within the
            Integrated Services framework (see <xref target="INTSERV" />)
            format="default"/>) for applications to communicate QoS
            requirements to the network and for the network to reserve
            relevant resources to satisfy the QoS requirements <xref target="RFC2205"/>.</t>
            target="RFC2205" format="default"/>.</t>
            <t>In RSVP, the traffic sender or source node sends a PATH Path message
            to the traffic receiver with the same source and destination
            addresses as the traffic which that the sender will generate.  The PATH Path
            message contains:
           (1) a contains:</t>
	    <ul spacing="normal">
	      <li>A sender traffic specification describing the
	      characteristics of the
           traffic, (2) a traffic</li>
	      <li>A sender template specifying the format of the traffic, and
           (3) an traffic</li>
	      <li>An optional advertisement specification which that is used
	      to support the concept of One Pass With Advertising (OPWA) <xref target="RFC2205"/>.
           Every
	      target="RFC2205" format="default"/></li>
	    </ul>
	    <t>Every intermediate router along the path forwards the PATH Path
	    message to the next hop determined by the routing protocol.  Upon
	    receiving a PATH Path message, the receiver responds with a RESV Resv
	    message which that includes a flow descriptor used to request resource
	    reservations.  The RESV Resv message travels to the sender or source
	    node in the opposite direction along the path that the PATH Path
	    message traversed.  Every intermediate router along the path can
	    reject or accept the reservation request of the RESV Resv message.  If
	    the request is rejected, the rejecting router will send an error
	    message to the receiver receiver, and the signaling process will terminate.
	    If the request is accepted, link bandwidth and buffer space are
	    allocated for the flow flow, and the related flow state information is
	    installed in the router.</t>
            <t>One of the issues with the original RSVP specification <xref
            target="RFC2205" format="default"/> was scalability.  This was
            because reservations were required for micro-
           flows, micro-flows, so that the
            amount of state maintained by network elements tended to increase
            linearly with the number of traffic flows.  These issues are
            described in <xref target="RFC2961"/> target="RFC2961" format="default"/>, which also
            modifies and extends RSVP to mitigate the scaling problems to make
            RSVP a versatile signaling protocol for the Internet.  For
            example, RSVP has been extended to reserve resources for
            aggregation of flows <xref target="RFC3175" />, format="default"/>, to
            set up MPLS explicit label switched paths LSPs (see <xref target="MPLS" />),
            format="default"/>), and to perform other signaling functions
            within the Internet.  <xref target="RFC2961"/> target="RFC2961" format="default"/>
            also describes a mechanism to reduce the amount of Refresh
            messages required to maintain established RSVP sessions.</t>
          </section>
          <section anchor="MPLS" title="Multiprotocol Label Switching (MPLS)"> numbered="true" toc="default">
            <name>MPLS</name>
            <t>MPLS is a forwarding scheme which that also includes extensions to
            conventional IP control plane protocols.  MPLS extends the
            Internet routing model and enhances packet forwarding and path
            control <xref target="RFC3031"/>.</t> target="RFC3031" format="default"/>.</t>
            <t>At the ingress to an MPLS domain, Label Switching Routers (LSRs)
            LSRs classify IP packets into Forwarding Equivalence Classes
            (FECs) based on a variety of factors, including, e.g., a
            combination of the information carried in the IP header of the
            packets and the local routing information maintained by the LSRs.
            An MPLS label stack entry is then prepended to each packet
            according to their forwarding equivalence
           classes. FECs.  The MPLS label
            stack entry is 32 bits long and contains a 20-bit label field.</t>
            <t>An LSR makes forwarding decisions by using the label prepended
            to packets as the index into a local next hop label forwarding entry Next Hop Label Forwarding
            Entry (NHLFE).  The packet is then processed as specified in the
            NHLFE.  The incoming label may be replaced by an outgoing label
            (label swap), and the packet may be forwarded to the next LSR.
            Before a packet leaves an MPLS domain, its MPLS label may be
            removed (label pop).  A
           Label Switched Path (LSP)  An LSP is the path between an ingress LSR
            and an egress LSR through which a labeled packet traverses.  The
            path of an explicit LSP is defined at the originating (ingress)
            node of the LSP.  MPLS can use a signaling protocol such as RSVP
            or the Label Distribution Protocol (LDP) to set up LSPs.</t>
            <t>MPLS is a powerful technology for Internet TE because it
            supports explicit LSPs which that allow constraint-based routing to be
            implemented efficiently in IP networks <xref target="AWD2"/>. target="AWD2"
            format="default"/>.  The requirements for TE over MPLS are
            described in <xref target="RFC2702"/>. target="RFC2702" format="default"/>.
            Extensions to RSVP to support instantiation of explicit LSP are
            discussed in <xref target="RFC3209"/> target="RFC3209" format="default"/> and <xref target="RSVP-TE"/>.</t>
            target="RSVP-TE" format="default"/>.</t>
          </section>
          <section anchor="RSVP-TE" title="RSVP-TE"> numbered="true" toc="default">
            <name>RSVP-TE</name>
            <t>RSVP-TE is a protocol extension of RSVP (<xref target="RSVP"/>) target="RSVP"
            format="default"/>) for traffic engineering.  The base
            specification is found in <xref target="RFC3209"/>. target="RFC3209"
            format="default"/>.  RSVP-TE enables the establishment of
            traffic-engineered MPLS LSPs (TE LSPs), using loose or strict paths,
            paths and taking into consideration network constraints such as
            available bandwidth.  The extension supports signaling LSPs on
            explicit paths that could be administratively
           specified, specified or
            computed by a suitable entity (such as a PCE, <xref target="PCE"/>) target="PCE"
            format="default"/>) based on QoS and policy requirements, taking
            into consideration the prevailing network state as advertised by the
            IGP extension for IS-IS in <xref target="RFC5305" />,
            format="default"/>, for OSPFV2 OSPFv2 in <xref target="RFC3630" />,
            format="default"/>, and for OSPFv3 in <xref target="RFC5329" />.
            format="default"/>.  RSVP-TE enables the reservation of resources
            (for example, bandwidth) along the path.</t>
            <t>RSVP-TE includes the ability to preempt LSPs based on priorities,
            priorities and uses link affinities to include or exclude links
            from the LSPs. The protocol is further extended to support Fast
            Reroute (FRR) <xref target="RFC4090"/>, target="RFC4090" format="default"/>, Diffserv
            <xref target="RFC4124"/>, target="RFC4124" format="default"/>, and bidirectional LSPs
            <xref target="RFC7551"/>. target="RFC7551" format="default"/>.  RSVP-TE extensions for
            support for GMPLS (see <xref target="GMPLS"/>) target="GMPLS" format="default"/>)
            are specified in <xref target="RFC3473"/>.</t> target="RFC3473" format="default"/>.</t>
            <t>Requirements for point-to-multipoint (P2MP) MPLS TE MPLS-TE LSPs are
            documented in <xref target="RFC4461"/>, target="RFC4461" format="default"/>, and
            signaling protocol extensions for setting up P2MP MPLS TE MPLS-TE LSPs via
            RSVP-TE are defined in <xref target="RFC4875"/> target="RFC4875" format="default"/>,
            where a P2MP LSP comprise comprises multiple source-to-leaf (S2L) sub-LSPs.
            To determine the paths for P2MP LSPs, selection of the branch
            points (based on capabilities, network state, and policies) is
            key <xref target="RFC5671" /></t> format="default"/></t>
            <t>RSVP-TE has evolved to provide real time real-time dynamic metrics for
            path selection for low latency low-latency paths using extensions to IS-IS
            <xref target="RFC8570" /> format="default"/> and OSPF <xref
            target="RFC7471" /> format="default"/> based on STAMP performance
            measurements for the Simple Two-Way Active
            Measurement Protocol (STAMP) <xref target="RFC8972" />
            format="default"/> and TWAMP the Two-Way Active Measurement Protocol (TWAMP)
            <xref target="RFC5357" /> performance measurements.</t> format="default"/>.</t>
            <t>RSVP-TE has historically been used when bandwidth was constrained,
            constrained; however, as bandwidth has increased, RSVP-TE has
            developed into a bandwidth management tool to provide bandwidth
            efficiency and proactive resource management.</t>
          </section>
          <section anchor="GMPLS" title="Generalized numbered="true" toc="default">
            <name>Generalized MPLS (GMPLS)"> (GMPLS)</name>

            <t>GMPLS extends MPLS control protocols to encompass time-division
            (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy
            (SONET/SDH), Plesiochronous Digital Hierarchy (PDH), and Optical
            Transport Network (OTN)), wavelength (lambdas), and spatial
            switching (e.g., incoming port or fiber to outgoing port or fiber) as well as continuing
            and continues to support packet switching.  GMPLS
            provides a common set of control protocols for all of these layers
            (including some technology-specific extensions) extensions), each of which has
            a distinct data or forwarding plane.  GMPLS covers both the
            signaling and the routing part of that control plane and is based
            on the TE extensions to MPLS (see <xref target="RSVP-TE"/>).</t> target="RSVP-TE"
            format="default"/>).</t>
            <t>In GMPLS <xref target="RFC3945" />, format="default"/>, the
            original MPLS architecture is extended to include LSRs whose
            forwarding planes rely on circuit switching, switching and therefore cannot
            forward data based on the information carried in either packet or
            cell headers.  Specifically, such LSRs include devices where the
            switching is based on time slots, wavelengths, or physical ports.
            These additions impact basic LSP properties: how labels are
            requested and communicated, the unidirectional nature of MPLS
            LSPs, how errors are propagated, and information provided for
            synchronizing the ingress and egress LSRs <xref target="RFC3473" />.</t>
            format="default"/>.</t>
          </section>
          <section anchor="IPPM" title="IP numbered="true" toc="default">
            <name>IP Performance Metrics"> Metrics (IPPM)</name>
            <t>The IETF IP Performance Metrics (IPPM) working group Working Group has
            developed a set of standard metrics that can be used to monitor
            the quality, performance, and reliability of Internet services.
            These metrics can be applied by network operators, end-users, end users, and
            independent testing groups to provide users and service providers
            with a common understanding of the performance and reliability of
            the Internet component &apos;clouds&apos; clouds they use/provide <xref target="RFC2330"/>.
            target="RFC2330" format="default"/>.  The criteria for performance
            metrics developed by the IPPM working group Working Group are described in <xref target="RFC2330"/>.
            target="RFC2330" format="default"/>.  Examples of performance
            metrics include one-way packet loss <xref target="RFC7680"/>, target="RFC7680"
            format="default"/>, one-way delay <xref target="RFC7679"/>, target="RFC7679"
            format="default"/>, and connectivity measures between two nodes
            <xref target="RFC2678"/>. target="RFC2678" format="default"/>.  Other metrics include
            second-order measures of packet loss and delay.</t>
            <t>Some of the performance metrics specified by the IPPM working group Working
            Group are useful for specifying SLAs.  SLAs are sets of service level objectives SLOs
            negotiated between users and service providers,
            wherein each objective is a combination of one or more performance
            metrics, possibly subject to certain constraints.</t>
            <t>The IPPM working group Working Group also designs measurement techniques and
            protocols to obtain
           thwse these metrics.</t>
          </section>
          <section anchor="RTFM" title="Flow Measurement"> numbered="true" toc="default">
            <name>Flow Measurement</name>
            <t>The IETF Real Time Flow Measurement (RTFM) working group Working Group
            produced an architecture that defines a method to specify traffic
            flows as well as a number of components for flow measurement
            (meters, meter readers, manager) and managers) <xref target="RFC2722"/>. target="RFC2722"
            format="default"/>.  A flow measurement system enables network
            traffic flows to be measured and analyzed at the flow level for a
            variety of purposes.  As noted in RFC 2722, <xref target="RFC2722"
            format="default"/>, a flow measurement system can be very useful
            in the following contexts:
           <list style="symbols">
             <t>understanding
            </t>
            <ul spacing="normal">
              <li>understanding the behavior of existing networks</t>
             <t>planning networks</li>
              <li>planning for network development and expansion</t>
             <t>quantification expansion</li>
              <li>quantification of network performance</t>
             <t>verifying performance</li>
              <li>verifying the quality of network service</t>
             <t>attribution service</li>
              <li>attribution of network usage to users.</t>
           </list></t> users</li>
            </ul>
            <t>A flow measurement system consists of meters, meter readers,
            and managers.  A meter observes packets passing through a
            measurement point, classifies them into groups, accumulates usage
            data (such as the number of packets and bytes for each group), and
            stores the usage data in a flow table.  A group may represent any
            collection of user applications, hosts, networks, etc.  A meter
            reader gathers usage data from various meters so it can be made
            available for analysis.  A manager is responsible for configuring
            and controlling meters and meter readers.  The instructions
            received by a meter from a manager include flow specifications,
            meter control parameters, and sampling techniques.  The
            instructions received by a meter reader from a manager include the
            address of the meter whose data are to be collected, the frequency
            of data collection, and the types of flows to be collected.</t>
            <t>IP Flow Information Export (IPFIX) <xref target="RFC5470" />
            format="default"/> defines an architecture that is very similar to
            the RTFM architecture and includes Metering, Exporting, and
            Collecting Processes.  <xref target="RFC5472" /> format="default"/>
            describes the applicability of IPFIX and makes a comparison with
            RTFM, pointing out that, architecturally, while RTM talks about
            devices, IPFIX deals with processed processes to clarify that multiple of
            those processes may be co-located on the same machine.  The IPFIX
            protocol <xref target="RFC7011" /> format="default"/> is widely
            implemented.</t>
          </section>
          <section anchor="ECM" title="Endpoint numbered="true" toc="default">
            <name>Endpoint Congestion Management"> Management</name>
            <t><xref target="RFC3124" /> format="default"/> provides a set of
            congestion control mechanisms for the use of transport protocols.
            It also allows the development of mechanisms for unifying
            congestion control across a subset of an endpoint&apos;s endpoint's active unicast
            connections (called a congestion group). "congestion group").  A congestion manager
            continuously monitors the state of the path for each congestion
            group under its control.  The manager uses that information to
            instruct a scheduler on how to partition bandwidth among the
            connections of that congestion group.</t>
            <t>The concepts described in <xref target="RFC3124" />
            format="default"/> and the lessons that can be learned from that
            work found a home in HTTP/2 <xref target="RFC9113" />
            format="default"/> and QUIC <xref target="RFC9000" />,
            format="default"/>, while <xref target="RFC9040" />
            format="default"/> describes TCP control block interdependence which
            that is a core construct underpinning the congestion manager
            defined in <xref target="RFC3124" />.</t> format="default"/>.</t>
          </section>
          <section anchor="IGPTE" title="TE numbered="true" toc="default">
            <name>TE Extensions to the IGPs"> IGPs</name>
            <t><xref target="RFC5305" /> format="default"/> describes the
            extensions to the Intermediate System to Intermediate System
            (IS-IS) protocol to support TE, similarly TE. Similarly, <xref target="RFC3630" />
            format="default"/> specifies TE extensions for OSPFv2, and <xref
            target="RFC5329" /> format="default"/> has the same description for
            OSPFv3.</t>
            <t>IS-IS and OSPF share the common concept of TE extensions to
            distribute TE parameters parameters, such as link type and ID, local and
            remote IP addresses, TE metric, maximum bandwidth, maximum
            reservable
           bandwidth and bandwidth, unreserved bandwidth, and admin group.
            The information distributed by the IGPs in this way can be used to
            build a view of the state and capabilities of a TE network (see
            <xref target="STATE" />).</t> format="default"/>).</t>
            <t>The difference between IS-IS and OSPF is in the details of how
            they encode and transmit the TE parameters:
           <list style="symbols">
             <t>IS-IS parameters:</t>
            <ul spacing="normal">
              <li>IS-IS uses the Extended IS Reachability TLV (type 22), the
              Extended IP Reachability TLV (type 135), and the TE Router Traffic
              Engineering router ID TLV (type 134).  These TLVs use specific Sub-TLVs
              sub-TLVs described in <xref target="RFC8570" /> format="default"/>
              to carry for the TE parameters.</t>
             <t>OSPFv2 parameters.</li>
              <li>OSPFv2 uses Opaque LSA <xref target="RFC5250" />
              format="default"/> type 10 10, and OSPFv3 uses the
              Intra-Area-TE-LSA.  In both OSPF cases, two top-level TLVs are
              used (Router Address and Link TLVs), and these use Sub-TLVs sub-TLVs to
              carry the TE parameters (as defined in <xref target="RFC7471" />
              format="default"/> for OSPFv2 and <xref target="RFC5329" />
              format="default"/> for OSPFv3.</t>
           </list></t> OSPFv3).</li>
            </ul>
          </section>
          <section anchor="BGPLS" title="BGP Link-State"> numbered="true" toc="default">
            <name>BGP - Link State</name>
            <t>In a number of environments, a component external to a network
            is called upon to perform computations based on the network
            topology and current state of the connections within the network,
            including TE information.  This is information typically
            distributed by IGP routing protocols within the network (see <xref
            target="IGPTE" />).</t>

         <t>The Border Gateway Protocol (BGP) format="default"/>).</t>
            <t>BGP (see also <xref target="INTER" />) format="default"/>) is
            one of the essential routing protocols that glue glues the Internet
            together.  BGP Link
            State (BGP-LS)  BGP-LS <xref target="RFC7752" /> target="RFC9552" format="default"/> is a
            mechanism by which link-state and TE information can be collected
            from networks and shared with external components using the BGP
            routing protocol.  The mechanism is applicable to physical and
            virtual IGP
            links, links and is subject to policy control.</t>
            <t>Information collected by BGP-LS can be used, for example, to
            construct the TED (<xref target="STATE" />) format="default"/>) for
            use by the
            Path Computation Element (PCE, see PCE (see <xref target="PCE" />),
            format="default"/>) or may be used by Application-Layer Traffic Optimization (ALTO) ALTO servers (see <xref target="ALTO" />).</t>
            format="default"/>).</t>
          </section>
          <section anchor="PCE" title="Path numbered="true" toc="default">
            <name>Path Computation Element"> Element </name>
            <t>Constraint-based path computation is a fundamental building
            block for TE in MPLS and GMPLS networks.  Path computation in
            large, multi-domain networks is complex and may require special
            computational components and cooperation between the elements in
            different domains.  The Path Computation Element (PCE) PCE <xref target="RFC4655"/> target="RFC4655"
            format="default"/> is an entity (component, application, or
            network node) that is capable of computing a network path or route
            based on a network graph and applying computational
            constraints.</t>
            <t>Thus, a PCE can provide a central component in a TE system
            operating on the TE Database (TED, see TED (see <xref target="STATE" />)
            format="default"/>) with delegated responsibility for determining
            paths in MPLS, GMPLS, or
            Segment Routing SR networks.  The PCE uses
            the Path Computation Element Communication Protocol (PCEP) <xref
            target="RFC5440" /> format="default"/> to communicate with Path
            Computation Clients (PCCs), such as MPLS LSRs, to answer their
            requests for computed paths or to instruct them to initiate new
            paths <xref target="RFC8281" /> format="default"/> and maintain state
            about paths already installed in the network <xref
            target="RFC8231" />.</t> format="default"/>.</t>
            <t>PCEs form key components of a number of TE systems.  More
            information about the applicability of PCE PCEs can be found in <xref target="RFC8051"/>,
            target="RFC8051" format="default"/>, while <xref target="RFC6805" />
            format="default"/> describes the application of PCE PCEs to determining
            paths across multiple domains.  PCE  PCEs also has have potential use uses in
            Abstraction and Control of TE Networks (ACTN) (see <xref
            target="ACTN" />), format="default"/>), Centralized Network Control
            <xref target="RFC8283" />, format="default"/>, and Software Defined Networking (SDN)
            SDN (see <xref target="SDN" />).</t>
            format="default"/>).</t>
          </section>
          <section anchor="SR" title="Segment Routing">

         <t>The Segment numbered="true" toc="default">
            <name>Segment Routing (SR) (SR)</name>
            <t>The SR architecture <xref target="RFC8402" /> format="default"/>
            leverages the source routing and tunneling paradigms.  The path a
            packet takes is defined at the ingress ingress, and the packet is tunneled
            to the egress.</t>
            <t>In a protocol realization, an ingress node steers a packet
            using a set of instructions, called segments, "segments", that are included in
            an SR header prepended to the packet: a label stack in MPLS case,
            and a series of 128-bit segment identifiers SIDs in the IPv6 case.</t>
            <t>Segments are identified by Segment Identifiers (SIDs). SIDs.  There
            are four types of SID SIDs that are relevant for TE.

            <list style="symbols">
               <t>Prefix TE.</t>
            <ul>
              <li>Prefix SID:
	      A SID that is unique within the routing domain and is used
	      to identify a prefix.</t>
               <t>Node prefix.</li>
              <li>Node SID:
	      A Prefix SID with the 'N' "N" bit set to identify a node.</t>
               <t>Adjacency node.</li>
              <li>Adjacency SID:
	      Identifies a unidirectional adjacency.</t>
               <t>Binding adjacency.</li>
              <li><t>Binding SID:
	      A Binding SID has two purposes:
                    <list style="numbers">
                      <t>To purposes:</t>
              <ol spacing="normal" type="1">
		<li>To advertise the mappings of prefixes to SIDs/Labels.</t>
                      <t>To SIDs/Labels</li>
                <li>To advertise a path available for a Forwarding Equivalence Class.</t>
                    </list></t>
               </list></t>
                Class (FEC)</li>
              </ol></li>
            </ul>
            <t>A segment can represent any instruction, topological or
            service-based.  SIDs can be looked up in a global context (domain wide)
            (domain-wide) as well as in some other
            context contexts (see, for example,
            "context labels" in Section 3 of <xref target="RFC5331" />).</t> sectionFormat="of"
            section="3"/>).</t>
            <t>The application of "policy" policy to Segment Routing SR can make SR into
            a TE mechanism mechanism, as described in <xref target="SRPolicy" />.</t>
            format="default"/>.</t>
          </section>
          <section anchor="BIER-TE" title="Bit numbered="true" toc="default">
            <name>Tree Engineering for Bit Index Explicit Replication Tree Engineering">
            </name>
            <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> target="RFC8279"
            format="default"/> specifies an encapsulation for multicast
            forwarding that can be used on MPLS or Ethernet transports.  A
            mechanism known as Tree Engineering for Bit Index Explicit
            Replication (BIER-TE) <xref target="RFC9262"/> target="RFC9262" format="default"/>
            provides a component that could be used to build a
            traffic-engineered multicast system.  BIER-TE does not of itself
            offer full traffic engineering, and the abbreviation "TE" does
            not, in this case, refer to traffic engineering.</t>
            <t>In BIER-TE, path steering is supported via the definition of a
            bitstring attached to each packet that determines how the packet
            is forwarded and replicated within the network.  Thus, this
            bitstring steers the traffic within the network and forms an
            element of a traffic engineering traffic-engineering system.  A central controller
            that is aware of the capabilities and state of the network as well
            as the demands of the various traffic flows, flows is able to select
            multicast paths that take account of the available resources and
            demands.  This controller, therefore,  Therefore, this controller is responsible for the
            policy elements of traffic engineering.</t>
            <t>Resource management has implications for the forwarding plane
            beyond the steering of packets defined for BIER-TE.  These include
            the allocation of buffers to meet the requirements of admitted
            traffic,
            traffic and may include policing and/or rate-shaping mechanisms
            achieved via various forms of queuing.  This level of resource
            control, while optional, is important in networks that wish to
            support congestion management policies to control or regulate the
            offered traffic to deliver different levels of service and
            alleviate congestion problems, or those problems. It is also important in networks that
            wish to control latencies experienced by specific traffic
            flows.</t>
          </section>
          <section anchor="STATE" title="Network numbered="true" toc="default">
            <name>Network TE State Definition and Presentation"> Presentation</name>
            <t>The network states that are relevant to TE need to be stored in
            the system and presented to the user.  The Traffic
           Engineering Database (TED) TED is a
            collection of all TE information about all TE nodes and TE links
            in the network.  It is an essential component of a TE system, such
            as MPLS-TE <xref target="RFC2702" /> format="default"/> or GMPLS
            <xref target ="RFC3945" />. target="RFC3945" format="default"/>.  In order to formally
            define the data in the TED and to present the data to the user,
            the data modeling language YANG <xref target="RFC7950" />
            format="default"/> can be used as described in <xref
            target="RFC8795" />.</t> format="default"/>.</t>
          </section>
          <section anchor="SYSMAN" title="System numbered="true" toc="default">
            <name>System Management and Control Interfaces"> Interfaces</name>

            <t>The TE control system needs to have a management interface that
            is human-friendly and a control interface that is programmable for
            automation.  The Network Configuration Protocol (NETCONF) <xref
            target="RFC6241" /> or format="default"/> and the RESTCONF Protocol protocol
            <xref target="RFC8040" /> format="default"/> provide programmable
            interfaces that are also human-friendly.  These protocols use XML XML-
            or JSON encoded JSON-encoded messages.  When message compactness or protocol
            bandwidth consumption needs to be optimized for the control
            interface, other protocols, such as Group Communication for the
            Constrained Application Protocol (CoAP) <xref target="RFC7390" />
            format="default"/> or gRPC <xref target="GRPC" />, format="default"/>,
            are available, especially when the protocol messages are encoded
            in a binary format.  Along with any of these protocols, the data
            modeling language YANG <xref target="RFC7950" /> format="default"/>
            can be used to formally and precisely define the interface
            data.</t>

        <t>The Path Computation Element Communication Protocol (PCEP)
            <t>PCEP <xref target="RFC5440" /> format="default"/> is another
            protocol that has evolved to be an option for the TE system
            control interface.  The messages of PCEP messages are TLV based; they are TLV-based, not
            defined by a data modeling data-modeling language such as YANG.</t>
          </section>
        </section>
      </section>
      <section anchor="CDN" title="Content Distribution"> numbered="true" toc="default">
        <name>Content Distribution</name>
        <t>The Internet is dominated by client-server interactions,
        principally
       Web web traffic and multimedia streams, although in the
        future, more sophisticated media servers may become dominant.  The
        location and performance of major information servers has have a
        significant impact on the traffic patterns within the Internet as well
        as on the perception of service quality by end users.</t>
        <t>A number of dynamic load-balancing techniques have been devised to
        improve the performance of replicated information servers.  These
        techniques can cause spatial traffic characteristics to become more
        dynamic in the Internet because information servers can be dynamically
        picked based upon the location of the clients, the location of the
        servers, the relative utilization of the servers, the relative
        performance of different networks, and the relative performance of
        different parts of a network.  This process of assignment of
        distributed servers to clients is called traffic
       directing. "traffic directing".  It is an application layer
        application-layer function.</t>

    <t>Traffic directing
        <t>Traffic-directing schemes that allocate servers in multiple
        geographically dispersed locations to clients may require empirical
        network performance statistics to make more effective decisions.  In
        the future, network measurement systems may need to provide this type
        of information.</t>
        <t>When congestion exists in the network, traffic directing traffic-directing and traffic
       engineering
        traffic-engineering systems should act in a coordinated manner.  This
        topic is for further study.</t>
        <t>The issues related to location and replication of information
        servers, particularly web servers, are important for Internet traffic
        engineering because these servers contribute a substantial proportion
        of Internet traffic.</t>
      </section>
    </section>
    <section anchor="RECO" title="Recommendations numbered="true" toc="default">
      <name>Recommendations for Internet Traffic Engineering"> Engineering</name>
      <t>This section describes high-level recommendations for traffic
      engineering in the Internet in general terms.</t>
      <t>The recommendations describe the capabilities needed to solve a TE
      problem or to achieve a TE objective.  Broadly speaking, these
      recommendations can be categorized as either functional or
      non-functional recommendations.

     <list style="symbols">
       <t>Functional recommendations:  </t>
      <ul spacing="normal">
        <li>Functional recommendations describe the functions that a traffic
          engineering traffic-engineering system
        should perform.  These functions are needed to realize TE objectives
        by addressing traffic
          engineering problems.</t>

       <t>Non-functional traffic-engineering problems.</li>
        <li>Non-functional recommendations relate to the quality attributes or
        state characteristics of a TE system.  These recommendations may
        contain conflicting assertions and may sometimes be difficult to
        quantify precisely.</t>
      </list></t> precisely.</li>
      </ul>
      <t>The subsections that follow first summarize the non-functional
      requirements,
      requirements and then detail the functional requirements.</t>
      <section anchor="HIGHOBJ" title="Generic numbered="true" toc="default">
        <name>Generic Non-functional Recommendations"> Recommendations</name>
        <t>The generic non-functional recommendations for Internet traffic
        engineering are listed in the paragraphs that follow.  In a given
        context, some of these recommendations may be critical while others
        may be optional.  Therefore, prioritization may be required during the
        development phase of a TE system to tailor it to a specific
        operational context.</t>

    <t><list style="hanging">
         <t hangText='Automation:'>
           Whenever
        <dl newline="false" spacing="normal">
          <dt>Automation:</dt>
          <dd>Whenever feasible, a TE system should automate as many TE
          functions as possible to minimize the amount of human effort needed
          to analyze and control operational networks.  Automation is
          particularly important in large-scale public networks because of the
          high cost of the human aspects of network operations and the high
          risk of network problems caused by human errors.  Automation may
          additionally benefit from feedback from the network that indicates
          the state of network resources and the current load in the network.
          Further, placing intelligence into components of the TE system could
          enable automation to be more dynamic and responsive to changes in
          the network.</t>

         <t hangText='Flexibility:'>
           A network.</dd>
          <dt>Flexibility:</dt>
          <dd>A TE system should allow for changes in optimization policy.  In
          particular, a TE system should provide sufficient configuration
          options so that a network administrator can tailor the system to a
          particular environment.  It may also be desirable to have both
          online and offline TE subsystems which that can be independently enabled
          and disabled.  TE systems that are used in multi-class networks
          should also have options to support class-based performance
          evaluation and optimization.</t>

         <t hangText='Interoperability:'>
           Whenever optimization.</dd>
          <dt>Interoperability:</dt>
          <dd>Whenever feasible, TE systems and their components should be
          developed with open standards-based interfaces to allow
          interoperation with other systems and components.</t>

         <t hangText='Scalability:'>
           Public components.</dd>
          <dt>Scalability:</dt>
          <dd>Public networks continue to grow rapidly with respect to
          network size and traffic volume.  Therefore, to remain applicable as
          the network evolves, a TE system should be scalable.  In particular,
          a TE system should remain functional as the network expands with
          regard to the number of routers and
           links, links and with respect to the
          number of flows and the traffic volume.  A TE system should have a
          scalable architecture, should not adversely impair other functions
          and processes in a network element, and should not consume too many
          network resources when collecting and distributing state information,
          information or when exerting control.</t>

         <t hangText='Security:'>
           Security control.</dd>
          <dt>Security:</dt>
          <dd>Security is a critical consideration in TE systems.  Such
          systems typically exert control over functional aspects of the
          network to achieve the desired performance objectives.  Therefore,
          adequate measures must be taken to safeguard the integrity of the TE
          system.  Adequate measures must also be taken to protect the network
          from vulnerabilities that originate from security breaches and other
          impairments within the TE system.</t>

         <t hangText='Simplicity:'>
           A system.</dd>
          <dt>Simplicity:</dt>
          <dd>A TE system should be as simple as possible.  Simplicity in
          user interface does not necessarily imply that the TE system will
          use naive algorithms.  When complex algorithms and internal
          structures are used, the user interface should hide such
          complexities from the network administrator as much as possible.</t>

         <t hangText='Stability:'>
            Stability
          possible.</dd>
          <dt>Stability:</dt>
          <dd>Stability refers to the resistance of the network to oscillate
          (flap) in a disruptive manner from one state to another, which may
          result in traffic being routed first one way and then another
          without satisfactory resolution of the underlying TE issues, issues and
          with continued changes that do not settle down.  Stability is a very
          important consideration in TE systems that respond to changes in the
          state of the network.  State-dependent TE methodologies typically
          include a trade-off between responsiveness and stability.  It is
          strongly recommended that when a trade-off between responsiveness
          and stability is needed, it should be made in favor of stability
          (especially in public IP backbone networks).</t>

         <t hangText='Usability:'>
           Usability networks).</dd>
          <dt>Usability:</dt>
          <dd>Usability is a human aspect of TE systems.  It refers to the
          ease with which a TE system can be deployed and operated.  In
          general, it is desirable to have a TE system that can be readily
          deployed in an existing network.  It is also desirable to have a TE
          system that is easy to operate and maintain.</t>

         <t hangText='Visibility:'>
           Mechanisms maintain.</dd>
          <dt>Visibility:</dt>
          <dd>Mechanisms should exist as part of the TE system to collect
          statistics from the network and to analyze these statistics to
          determine how well the network is functioning.  Derived statistics such
          (such as traffic matrices, link utilization, latency, packet loss,
          and other performance measures of interest which interest) that are determined from
          network measurements can be used as indicators of prevailing network
          conditions.  The capabilities of the various components of the
          routing system are other examples of status information which that should
          be observable.</t>

    </list></t> observable.</dd>
        </dl>
      </section>
      <section anchor="ROUTEREC" title="Routing Recommendations"> numbered="true" toc="default">
        <name>Routing Recommendations</name>
        <t>Routing control is a significant aspect of Internet traffic
       engineering.  Routing impacts many of the key performance measures
       associated with networks, such as throughput, delay, and utilization.
       Generally, it is very difficult to provide good service quality in a
       wide area network without effective routing control.  A desirable TE
       routing system is one that takes traffic characteristics and network
       constraints into account during route selection while maintaining
       stability.</t>
        <t>Shortest path first Path First (SPF) IGPs are based on shortest path
        algorithms and have limited control capabilities for TE <xref target="RFC2702"/>,
        target="RFC2702" format="default"/> <xref target="AWD2"/>. target="AWD2"
        format="default"/>.  These limitations include:

       <list style="numbers">
         <t>Pure include:</t>
        <ol spacing="normal" type="1">
	  <li><t>Pure SPF protocols do not take network constraints and
	  traffic characteristics into account during route selection.  For
	  example, IGPs always select the shortest paths based on link metrics
	  assigned by administrators, so load sharing cannot be performed
	  across paths of different costs.  Note that link metrics are
	  assigned following a range of operator-selected policies that might
	  reflect preference for the use of some links over others, and others; therefore,
	  "shortest" might not, therefore, not be purely a measure of distance.  Using
	  shortest paths to forward traffic may cause the following problems:
            <list style="symbols">
              <t>If
	  problems:</t>
            <ul spacing="normal">
              <li>If traffic from a source to a destination exceeds the
              capacity of a link along the shortest path, the link (and hence
              the shortest path) becomes congested while a longer path between
              these two nodes may be under-utilized.</t>
              <t>The under-utilized.</li>
              <li>The shortest paths from different sources can overlap at
              some links.  If the total traffic from the sources exceeds the
              capacity of any of these links, congestion will occur.</t>
              <t>Problems occur.</li>
              <li>Problems can also occur because traffic demand changes over
              time, but network topology and routing configuration cannot be
              changed as rapidly.  This causes the network topology and
              routing configuration to become sub-optimal over time, which may
              result in persistent congestion problems.</t>
            </list></t>
         <t>The problems.</li>
            </ul>
          </li>
          <li>The Equal-Cost Multi-Path Multipath (ECMP) capability of SPF IGPs supports
          sharing of traffic among equal-cost paths.  However, ECMP attempts
          to divide the traffic as equally as possible among the equal-cost
          shortest paths.  Generally, ECMP does not support configurable load sharing
          load-sharing ratios among equal cost equal-cost paths.  The result is that one
          of the paths may carry significantly more traffic than other paths
          because it may also carry traffic from other sources.  This
          situation can result in congestion along the path that carries more
          traffic.  Weighted ECMP (WECMP) (see, for example, <xref
          target="I-D.ietf-bess-evpn-unequal-lb" />) format="default"/>) provides
          some mitigation.</t>
         <t>Modifying mitigation.</li>
          <li>Modifying IGP metrics to control traffic routing tends to have
          network-wide effects.  Consequently, undesirable and unanticipated
          traffic shifts can be triggered as a result.  Work described in
          <xref target="PRACTICE"/> target="PRACTICE" format="default"/> may be capable of better
          control <xref target="FT00"/>, target="FT00" format="default"/> <xref target="FT01"/>.</t>
       </list></t> target="FT01"
          format="default"/>.</li>
        </ol>
        <t>Because of these limitations, capabilities are needed to enhance
        the routing function in IP networks.  Some of these capabilities are
        summarized below.</t>

    <t><list style="symbols">
       <t>Constraint-based below:</t>
        <ul spacing="normal">
          <li>Constraint-based routing computes routes to fulfill requirements
          subject to constraints.  This can be useful in public IP backbones
          with complex topologies.  Constraints may include bandwidth, hop
          count, delay, and administrative policy instruments instruments, such as resource
          class attributes <xref target="RFC2702"/>, target="RFC2702" format="default"/> <xref target="RFC2386"/>.
          target="RFC2386" format="default"/>.  This makes it possible to
          select routes that satisfy a given set of requirements.  Routes
          computed by constraint-based routing are not necessarily the
          shortest paths.  Constraint-based routing works best with
          path-oriented technologies that support explicit routing, such as MPLS.</t>
    </list></t>
    <t><list style="none">
       <t>Constraint-based
          MPLS.</li>
          <li>Constraint-based routing can also be used as a way to distribute
          traffic onto the infrastructure, including for best effort best-effort traffic.
          For example, congestion problems caused by uneven traffic
          distribution may be avoided or reduced by knowing the reservable
          bandwidth attributes of the network links and by specifying the
          bandwidth requirements for path selection.</t>
    </list></t>

    <t><list style="symbols">
       <t>A selection.</li>
          <li>A number of enhancements to the link state link-state IGPs allow them to
          distribute additional state information required for
          constraint-based routing.  The extensions to OSPF are described in
          <xref target="RFC3630"/>, target="RFC3630" format="default"/>, and the extensions to
          IS-IS are described in <xref target="RFC5305"/>. target="RFC5305" format="default"/>.
          Some of the additional topology state information includes link attributes
          attributes, such as reservable bandwidth and link resource class
          attribute (an administratively specified property of the link).  The
          resource class attribute concept is defined in <xref target="RFC2702"/>.
          target="RFC2702" format="default"/>.  The additional topology state
          information is carried in new TLVs and sub-TLVs in IS-IS, IS-IS <xref
          target="RFC5305" format="default"/> or in the Opaque LSA in OSPF
          <xref target="RFC5305"/>, <xref target="RFC3630"/>.</t>
    </list></t>
    <t><list style="none">
       <t>An target="RFC3630" format="default"/>.</li>

          <li>An enhanced link-state IGP may flood information more frequently
          than a normal IGP.  This is because even without changes in
          topology, changes in reservable bandwidth or link affinity can
          trigger the enhanced IGP to initiate flooding.  A trade-off between
          the timeliness of the information flooded and the flooding frequency
          is typically implemented using a threshold based on the percentage
          change of the advertised resources to avoid excessive consumption of
          link bandwidth and computational resources, resources and to avoid instability
          in the TED.</t>
    </list></t>

    <t><list style="symbols">
       <t>In TED.</li>
          <li>In a TE system, it is also desirable for the routing subsystem
          to make the load splitting load-splitting ratio among multiple paths (with equal
          cost or different cost) configurable.  This capability gives network
          administrators more flexibility in the control of traffic
          distribution across the network.  It can be very useful for
          avoiding/relieving congestion in certain situations.  Examples can
          be found in <xref target="XIAO"/> target="XIAO" format="default"/> and <xref
          target="I-D.ietf-bess-evpn-unequal-lb" />.</t>

       <t>The format="default"/>.</li>
          <li>The routing system should also have the capability to control
          the routes of subsets of traffic without affecting the routes of
          other traffic if sufficient resources exist for this purpose.  This
          capability allows a more refined control over the distribution of
          traffic across the network.  For example, the ability to move
          traffic away from its original path to another path (without
          affecting other traffic paths) allows the traffic to be moved from
          resource-poor network segments to resource-rich segments.  Path oriented technologies
          Path-oriented technologies, such as
          MPLS-TE MPLS-TE, inherently support this
          capability as discussed in <xref target="AWD2"/>.</t>

       <t>Additionally, target="AWD2"
          format="default"/>.</li>
          <li>Additionally, the routing subsystem should be able to select
          different paths for different classes of traffic (or for different
          traffic behavior aggregates) if the network supports multiple
          classes of service (different behavior aggregates).</t>
    </list></t> aggregates).</li>
        </ul>
      </section>
      <section anchor="MAPREC" title="Traffic numbered="true" toc="default">
        <name>Traffic Mapping Recommendations"> Recommendations</name>
        <t>Traffic mapping is the assignment of traffic workload onto
        (pre-established) paths to meet certain requirements.  Thus, while
        constraint-based routing deals with path selection, traffic mapping
        deals with the assignment of traffic to established paths which that may
        have been generated by constraint-based routing or by some other
        means.  Traffic mapping can be performed by time-dependent or state-
       dependent
        state-dependent mechanisms, as described in <xref target="TIME"/>.</t>

    <t>An target="TIME"
        format="default"/>.</t>
        <t>Two important aspect aspects of the traffic mapping function is are the
        ability to establish multiple paths between an originating node and a
        destination
       node, node and the capability to distribute the traffic between the two
       nodes across the
        those paths according to configured policies.  A precondition for this
        scheme is the existence of flexible mechanisms to partition traffic
        and then assign the traffic partitions onto the parallel paths
        (described as "parallel traffic trunks" in <xref target="RFC2702"/>). target="RFC2702"
        format="default"/>).  When traffic is assigned to multiple parallel
        paths, it is recommended that special care should be taken to ensure
        proper ordering of packets belonging to the same application (or
        traffic flow) at the destination node of the parallel paths.</t>
        <t>Mechanisms that perform the traffic mapping functions should aim to
        map the traffic onto the network infrastructure to minimize
        congestion.  If the total traffic load cannot be accommodated, or if
        the routing and mapping functions cannot react fast enough to changing
        traffic conditions, then a traffic mapping system may use short
        timescale congestion control mechanisms (such as queue management,
        scheduling, etc.) to mitigate congestion.  Thus, mechanisms that
        perform the traffic mapping functions complement existing congestion
        control mechanisms.  In an operational network, traffic should be
        mapped onto the infrastructure such that intra-class and inter-class
        resource contention are minimized (see <xref target="BG" />).</t>
        format="default"/>).</t>
        <t>When traffic mapping techniques that depend on dynamic state
        feedback (e.g., MATE MPLS Adaptive Traffic Engineering (MATE) <xref target="MATE" /> format="default"/> and
        suchlike) are used, special care must be taken to guarantee network
        stability.</t>
      </section>
      <section anchor="MSRREC" title="Measurement Recommendations"> numbered="true" toc="default">
        <name>Measurement Recommendations</name>
        <t>The importance of measurement in TE has been discussed throughout
        this document.  A TE system should include mechanisms to measure and
        collect statistics from the network to support the TE function.
        Additional capabilities may be needed to help in the analysis of the
        statistics.  The actions of these mechanisms should not adversely
        affect the accuracy and integrity of the statistics collected.  The
        mechanisms for statistical data acquisition should also be able to
        scale as the network evolves.</t>
        <t>Traffic statistics may be classified according to long-term or
        short-term timescales.  Long-term traffic statistics are very useful
        for traffic engineering.  Long-term traffic statistics may
        periodically record network workload (such as hourly, daily, and
        weekly variations in traffic profiles) as well as traffic trends.
        Aspects of the traffic statistics may also describe class of service
        characteristics for a network supporting multiple classes of service.
        Analysis of the long-term traffic statistics may yield other
        information such as busy-hour characteristics, traffic growth
        patterns, persistent congestion problems, hot-spot, hotspots, and imbalances in
        link utilization caused by routing anomalies.</t>
        <t>A mechanism for constructing traffic matrices for both long-term
        and short-term traffic statistics should be in place.  In
        multi-service IP networks, the traffic matrices may be constructed for
        different service classes.  Each element of a traffic matrix
        represents a statistic about the traffic flow between a pair of
        abstract nodes.  An abstract node may represent a router, a collection
        of routers, or a site in a VPN.</t>
        <t>Traffic statistics should provide reasonable and reliable
        indicators of the current state of the network on the short-term
        scale.  Some short term short-term traffic statistics may reflect link
        utilization and link congestion status.  Examples of congestion
        indicators include excessive packet delay, packet loss, and high
        resource utilization.  Examples of mechanisms for distributing this
        kind of information include SNMP, probing tools, FTP, IGP link state link-state
        advertisements, and NETCONF/RESTCONF, etc.</t>
      </section>
      <section anchor="POLICE" title="Policing, numbered="true" toc="default">
        <name>Policing, Planning, and Access Control"> Control</name>
        <t>The recommendations in Sections <xref target="ROUTEREC" /> format="counter"/>
        and <xref target="MAPREC" /> format="counter"/> may be sub-optimal or
        even ineffective if the amount of traffic flowing on a route or path
        exceeds the capacity of the resource on that route or path.  Several
        approaches can be used to increase the performance of TE systems.

       <list style="symbols">

          <t>The systems:</t>
        <ul spacing="normal">
          <li>The fundamental approach is some form of planning where traffic
          is steered onto paths so that it is distributed across the available
          resources.  This planning may be centralized or distributed, distributed and
          must be aware of the planned traffic volumes and available
          resources.  However, this approach is only of value if the traffic
          that is presented conforms to the planned traffic volumes.</t>

          <t>Traffic volumes.</li>
          <li>Traffic flows may be policed at the edges of a network.  This is
          a simple way to ensure that the actual traffic volumes are
          consistent with the planned volumes.  Some form of measurement (see
          <xref target="MSRREC" />) format="default"/>) is used to determine the
          rate of arrival of traffic, and excess traffic could be discarded.
          Alternatively, excess traffic could be forwarded as best-effort
          within the network.  However, this approach is only completely
          effective if the planning is stringent and
             network-wide, network-wide and if a
          harsh approach is taken to disposing of excess traffic.</t>

          <t>Resource-based traffic.</li>
          <li>Resource-based admission control is the process whereby network
          nodes decide whether to grant access to resources.  The basis for
          the decision on a packet-by-packet basis is the determination of the
          flow to which the packet belongs.  This information is combined with
          policy instructions that have been locally configured, configured or
          installed through the management or control planes.  The end result
          is that a packet may be allowed to access (or use) specific
          resources on the node if if, and only if if, the flow to which the packet
          belongs conforms to the policy.</t>

       </list></t> policy.</li>
        </ul>
        <t>Combining some element elements of all three of these measures is advisable
        to achieve a better TE system.</t>
      </section>
      <section anchor="SURVIVE" title="Network Survivability"> numbered="true" toc="default">
        <name>Network Survivability</name>
        <t>Network survivability refers to the capability of a network to
        maintain service continuity in the presence of faults.  This can be
        accomplished by promptly recovering from network impairments and
        maintaining the required QoS for existing services after recovery.
        Survivability is an issue of great concern within the Internet
        community due to the demand to carry mission-critical traffic,
        real-time traffic, and other high
       priority high-priority traffic over the Internet.
        Survivability can be addressed at the device level by developing
        network elements that are more reliable; reliable and at the network
        level by incorporating redundancy into the architecture, design, and
        operation of networks.  It is recommended that a philosophy of
        robustness and survivability should be adopted in the architecture,
        design, and operation of TE used to control IP networks (especially
        public IP networks).  Because different contexts may demand different
        levels of survivability, the mechanisms developed to support network
        survivability should be flexible so that they can be tailored to
        different needs.
A number of tools and techniques have been developed
        to enable network survivability survivability, including MPLS Fast Reroute <xref
        target="RFC4090" />, format="default"/>, Topology Independent Loop-free
        Alternate Fast Re-route Reroute for Segment Routing <xref
        target="I-D.ietf-rtgwg-segment-routing-ti-lfa" /> format="default"/>,
        RSVP-TE Extensions in Support of End-to-End GMPLS Recovery <xref
        target="RFC4872" />, format="default"/>, and GMPLS Segment Recovery <xref
        target="RFC4873" />.</t> format="default"/>.</t>
        <t>The impact of service outages varies significantly for different
        service classes depending on the duration of the outage outage, which can vary
        from milliseconds (with minor service impact) to seconds (with
        possible call drops for IP telephony and session timeouts for
        connection-oriented transactions) to minutes and hours (with
        potentially considerable social and business impact).  Outages of
        different durations have different impacts depending on the nature of
        the traffic flows that are interrupted.</t>
        <t>Failure protection and restoration capabilities are available in
        multiple layers as network technologies have continued to evolve.
        Optical networks are capable of providing dynamic ring and mesh
        restoration functionality at the wavelength level.  At the SONET/SDH layer
        layer, survivability capability is provided with Automatic Protection
        Switching (APS) as well as self-healing ring and mesh architectures.
        Similar functionality is provided by layer Layer 2 technologies such as
        Ethernet.</t>
        <t>Rerouting is used at the IP layer to restore service following link
        and node outages.  Rerouting at the IP layer occurs after a period of
        routing convergence convergence, which may require seconds to minutes to complete.
        Path-oriented technologies such as MPLS
       (<xref target="RFC3469"/>) <xref target="RFC3469"
        format="default"/> can be used to enhance the survivability of IP
        networks in a potentially cost-effective manner.</t>
        <t>An important aspect of multi-layer survivability is that
        technologies at different layers may provide protection and
        restoration capabilities at different granularities in terms of time
       scales
        timescales and at different bandwidth granularity granularities (from the level of
        packets to that of wavelengths).  Protection and restoration
        capabilities can also be sensitive to different service classes and
        different network utility models.  Coordinating different protection
        and restoration capabilities across multiple layers in a cohesive
        manner to ensure network survivability is maintained at reasonable
        cost is a challenging task.  Protection and restoration coordination
        across layers may not always be feasible, because networks at different
        layers may belong to different administrative domains.</t>

    <t>The following paragraphs present some
        <t>Some of the general
        recommendations for protection and restoration coordination.</t>

    <t><list style="symbols">
         <t>Protection coordination are as follows:</t>
        <ul spacing="normal">
          <li>Protection and restoration capabilities from different layers
          should be coordinated to provide network survivability in a flexible
          and cost-effective manner.  Avoiding duplication of functions in
          different layers is one way to achieve the coordination.  Escalation
          of alarms and other fault indicators from lower to higher layers may
          also be performed in a coordinated manner.  The order of timing of
          restoration triggers from different layers is another way to
          coordinate multi-layer
            protection/restoration.</t>
         <t>Network protection/restoration.</li>
          <li>Network capacity reserved in one layer to provide protection and
          restoration is not available to carry traffic in a higher layer: it
          is not visible as spare capacity in the higher layer.  Placing
          protection/restoration functions in many layers may increase
          redundancy and robustness, but it can result in significant
          inefficiencies in network resource utilization.  Careful planning is
          needed to balance the tradeoff trade-off between the desire for survivability
          and the optimal use of resources.</t>
         <t>It resources.</li>
          <li>It is generally desirable to have protection and restoration
          schemes that are intrinsically bandwidth efficient.</t>
         <t>Failure efficient.</li>
          <li>Failure notifications throughout the network should be timely
          and reliable if they are to be acted on as triggers for effective
          protection and restoration actions.</t>
         <t>Alarms actions.</li>
          <li>Alarms and other fault monitoring and reporting capabilities
          should be provided at the right network layers so that the
          protection and restoration actions can be taken in those layers.</t>
       </list></t>
          layers.</li>
        </ul>
        <section anchor="SRVMPLS" title="Survivability numbered="true" toc="default">
          <name>Survivability in MPLS Based Networks"> MPLS-Based Networks</name>
          <t>Because MPLS is path-oriented, it has the potential to provide
          faster and more predictable protection and restoration capabilities
          than conventional hop-by-hop routed IP systems.  Protection types
          for MPLS networks can be divided into four categories.</t>

      <t><list style="symbols">
           <t>Link Protection: categories:</t>
<dl newline="false" spacing="normal">
            <dt>Link Protection:</dt><dd>
	    The objective of link protection is to protect an LSP from the
	    failure of a given link.  Under link protection, a protection or
	    backup LSP (the secondary LSP) follows a path that is disjoint
	    from the path of the working or operational LSP (the primary LSP)
	    at the particular link where link protection is required.  When
	    the protected link fails, traffic on the working LSP is switched
	    to the protection LSP at the head-end headend of the failed link.  As a
	    local repair method, link protection can be fast.  This form of
	    protection may be most appropriate in situations where some
	    network elements along a given path are known to be less reliable
	    than others.</t>
           <t>Node Protection: others.</dd>
            <dt>Node Protection:</dt><dd>
	    The objective of node protection is to protect an LSP from the
	    failure of a given node.  Under node protection, the secondary LSP
	    follows a path that is disjoint from the path of the primary LSP
	    at the particular node where node protection is required.  The
	    secondary LSP is also disjoint from the primary LSP at all links
	    attached to the node to be protected.  When the protected node
	    fails, traffic on the working LSP is switched over to the
	    protection LSP at the upstream LSR directly connected to the
	    failed node.  Node protection covers a slightly larger part of the
	    network compared to link protection, protection but is otherwise
	    fundamentally the same.</t>
           <t>Path Protection: same.</dd>
            <dt>Path Protection:</dt><dd>
	    The goal of LSP path protection (or end-to-end protection) is
	    to protect an LSP from any failure along its routed path.  Under
	    path protection, the path of the protection LSP is completely
	    disjoint from the path of the working LSP.  The advantage of path
	    protection is that the backup LSP protects the working LSP from
	    all possible link and node failures along the path, except for
	    failures of ingress or egress LSR.  Additionally, path protection
	    may be more efficient in terms of resource usage than link or node
	    protection applied at every hop along the path.  However, path
	    protection may be slower than link and node protection because the
	    fault notifications have to be propagated further.</t>
           <t>Segment Protection: further.</dd>
            <dt>Segment Protection:</dt><dd>
	    An MPLS domain may be partitioned into multiple subdomains
	    (protection domains).  Path protection is applied to the path of
	    each LSP as it crosses the domain from its ingress to the domain
	    to where it egresses the domain.  In cases where an LSP traverses
	    multiple protection domains, a protection mechanism within a
	    domain only needs to protect the segment of the LSP that lies
	    within the domain.  Segment protection will generally be faster
	    than end-to-end path protection because recovery generally occurs
	    closer to the fault fault, and the notification doesn&apos;t doesn't have to propagate
	    as far.</t>
      </list></t> far.</dd>
          </dl>
          <t>See <xref target="RFC3469" /> format="default"/> and <xref
          target="RFC6372" /> format="default"/> for a more comprehensive
          discussion of MPLS
         based MPLS-based recovery.</t>
        </section>
        <section anchor="PROTECT" title="Protection Options"> numbered="true" toc="default">
          <name>Protection Options</name>
          <t>Another issue to consider is the concept of protection options.
          We use notation such as "m:n protection", where m is the number of
          protection LSPs used to protect n working LSPs.  In all cases
          except 1+1 protection, the resources associated with the protection
          LSPs can be used to carry preemptable best-effort traffic when the
          working LSP is functioning correctly.</t>

      <t><list style="symbols">
           <t>1:1 protection: One
          <dl spacing="normal" newline="false">
            <dt>1:1 protection:</dt>
	    <dd>One working LSP is protected/restored by one protection LSP.
	    Traffic is sent only on the protected LSP until the
	    protection/restoration event switches the traffic to the
	    protection LSP.</t>
           <t>1:n protection: One LSP.</dd>
            <dt>1:n protection:</dt>
	    <dd>One protection LSP is used to protect/restore n working LSPs.
	    Traffic is sent only on the n protected working LSPs until the
	    protection/restoration event switches the traffic from one failed
	    LSP to the protection LSP.  Only one failed LSP can be restored at
	    any time.</t>
           <t>n:1 protection: One time.</dd>
            <dt>n:1 protection:</dt>
	    <dd>One working LSP is protected/restored by n protection LSPs,
	    possibly with load splitting across the protection LSPs.  This may
	    be especially useful when it is not feasible to find one path for
	    the backup that can satisfy the bandwidth requirement of the
	    primary LSP.</t>
           <t>1+1 protection: Traffic LSP.</dd>
            <dt>1+1 protection:</dt>
	    <dd>Traffic is sent concurrently on both the working LSP and a
	    protection LSP.  The egress LSR selects one of the two LSPs based
	    on local policy (usually based on traffic integrity).  When a
	    fault disrupts the traffic on one LSP, the egress switches to
	    receive traffic from the other LSP.  This approach is expensive in
	    how it consumes network but recovers from failures most rapidly.</t>
      </list></t>
	    rapidly.</dd>
          </dl>
        </section>
      </section>
      <section anchor="ML" title="Multi-Layer numbered="true" toc="default">
        <name>Multi-Layer Traffic Engineering"> Engineering</name>
        <t>Networks are often implemented as layers.  A layer relationship may
        represent the interaction between technologies (for example, an IP
        network operated over an optical network), network) or the relationship between
        different network operators (for example, a customer network operated
        over a service provider&apos;s provider's network).  Note that a multi-layer network
        does not imply the use of multiple technologies, although some form of
        encapsulation is often applied.</t>
        <t>Multi-layer traffic engineering presents a number of challenges
        associated with scalability and confidentiality.  These issues are
        addressed in <xref target="RFC7926" /> format="default"/>, which
        discusses the sharing of information between domains through policy
        filters, aggregation, abstraction, and virtualization.  That document
        also discusses how existing protocols can support this scenario with
        special reference to BGP-LS (see <xref target="BGPLS" />).</t>
        format="default"/>).</t>
        <t>PCE (see <xref target="PCE" />) format="default"/>) is also a useful
        tool for multi-layer networks as described in <xref target="RFC6805" />,
        format="default"/>, <xref target="RFC8685" />, format="default"/>, and
        <xref target="RFC5623" />. format="default"/>.  Signaling techniques for
        multi-layer TE are described in <xref target="RFC6107" />.</t>
        format="default"/>.</t>
        <t>See also <xref target="SURVIVE" /> format="default"/> for examination
        of multi-layer network survivability.</t>
      </section>
      <section anchor="TEDIFFSRV" title="Traffic numbered="true" toc="default">
        <name>Traffic Engineering in Diffserv Environments"> Environments</name>
        <t>Increasing requirements to support multiple classes of traffic in
        the Internet, such as
       best effort best-effort and mission critical mission-critical data, call for
        IP networks to differentiate traffic according to some criteria and to
        give preferential treatment to certain types of traffic.  Large
        numbers of flows can be aggregated into a few behavior aggregates
        based on some criteria based on common performance requirements in
        terms of packet loss ratio, delay, and jitter, jitter or in terms of common
        fields within the IP packet headers.</t>
        <t>Differentiated Services (Diffserv) <xref target="RFC2475"/> target="RFC2475"
        format="default"/> can be used to ensure that SLAs defined to
        differentiate between traffic flows are met.  Classes of service (CoS) can
        be supported in a Diffserv environment by concatenating per-hop behaviors Per-Hop
        Behaviors (PHBs) along the routing path.  A PHB is the forwarding
        behavior that a packet receives at a Diffserv-
       compliant Diffserv-compliant node, and it
        can be configured at each router.  PHBs are delivered using buffer
       management
        buffer-management and packet scheduling packet-scheduling mechanisms and require that
        the ingress nodes use traffic classification, marking, policing, and
        shaping.</t>
        <t>TE can complement Diffserv to improve utilization of network
        resources.  TE can be operated on an aggregated basis across all
        service classes <xref target="RFC3270"/>, target="RFC3270" format="default"/> or on a per-service class
        per-service-class basis.  The former is used to provide better
        distribution of the traffic load over the network resources (see <xref target="RFC3270"/>
        target="RFC3270" format="default"/> for detailed mechanisms to support
        aggregate TE).  The latter case is discussed below since it is
        specific to the Diffserv environment, with so called so-called Diffserv-aware
        traffic engineering <xref target="RFC4124"/>.</t> target="RFC4124" format="default"/>.</t>
        <t>For some Diffserv networks, it may be desirable to control the
        performance of some service classes by enforcing relationships between
        the traffic workload contributed by each service class and the amount
        of network resources allocated or provisioned for that service class.
        Such relationships between demand and resource allocation can be
        enforced using a combination of, for example:
       <list style="symbols">
         <t>TE
        </t>
        <ul spacing="normal">
          <li>TE mechanisms on a per service class per-service-class basis that enforce the
          relationship between the amount of traffic contributed by a given
          service class and the resources allocated to that class.</t>
         <t>Mechanisms class.</li>
          <li>Mechanisms that dynamically adjust the resources allocated to a
          given service class to relate to the amount of traffic contributed
          by that service class.</t>
       </list></t> class.</li>
        </ul>
        <t>It may also be desirable to limit the performance impact of
        high-priority traffic on relatively low-priority traffic.  This can be
        achieved, for example, by controlling the percentage of high-priority
        traffic that is routed through a given link.  Another way to
        accomplish this is to increase link capacities appropriately so that
        lower-priority traffic can still enjoy adequate service quality.  When
        the ratio of traffic workload contributed by different service classes
        varies significantly from router to router, it may not be enough to
        rely on conventional IGP routing protocols or on TE mechanisms that
        are not sensitive to different service classes.  Instead, it may be
        desirable to perform TE, especially routing control and mapping
        functions, on a per-service class per-service-class basis.  One way to accomplish this
        in a domain that supports both MPLS and Diffserv is to define
        class-specific LSPs and to map traffic from each class onto one or
        more LSPs that correspond to that service class.  An LSP corresponding
        to a given service class can then be routed and protected/restored in
        a class-dependent manner, according to specific policies.</t>
        <t>Performing TE on a per-class basis may require per-class parameters
        to be distributed.  It is common to have some classes share some
        aggregate constraints (e.g., maximum bandwidth requirement) without
        enforcing the constraint on each individual class.  These classes can
        be grouped into class-types, class types, and per-class-type parameters can be
        distributed to improve scalability.  This also allows better bandwidth
        sharing between classes in the same class-type. class type.  A class-type class type is a set
        of classes that satisfy the following two conditions:

       <list style="symbols">

         <t>Classes conditions:</t>
        <ul spacing="normal">
          <li>Classes in the same class-type class type have common aggregate
          requirements to satisfy required performance levels.</t>

         <t>There levels.</li>
          <li>There is no requirement to be enforced at the level of an
          individual class in the class-type. class type.  Note that it is, nevertheless,
          still possible to implement some priority policies for classes in
          the same class-type class type to permit preferential access to the class-type class type
          bandwidth through the use of preemption priorities.</t>

       </list></t> priorities.</li>
        </ul>
        <t>See <xref target="RFC4124"/> target="RFC4124" format="default"/> for detailed requirements on Diffserv-aware TE.</t>
      </section>
      <section anchor="CONTROL" title="Network Controllability"> numbered="true" toc="default">
        <name>Network Controllability</name>
        <t>Offline and online (see <xref target="OFFON" />) format="default"/>) TE
        considerations are of limited utility if the network cannot be
        controlled effectively to implement the results of TE decisions and to
        achieve the desired network performance objectives.</t>
        <t>Capacity augmentation is a coarse-grained solution to TE issues.
        However, it is simple, may be applied through creating parallel links
        that form part of an ECMP scheme, and may be advantageous if bandwidth
        is abundant and cheap.  However, bandwidth is not always abundant and
        cheap, and additional capacity might not always be the best solution.
        Adjustments of administrative weights and other parameters associated
        with routing protocols provide finer-grained control, but this
        approach is difficult to use and imprecise because of the way the
        routing protocols interactions occur interact across the network.</t>
        <t>Control mechanisms can be manual (e.g., static configuration), partially-automated
        partially automated (e.g., scripts), or
       fully-automated fully automated (e.g., policy based
        policy-based management systems).  Automated mechanisms are
        particularly useful in large-scale networks.  Multi-vendor
        interoperability can be facilitated by standardized management tools
        (e.g., YANG models) to support the control functions required to
        address TE objectives.</t>
        <t>Network control functions should be secure, reliable, and stable as
        these are often needed to operate correctly in times of network
        impairments (e.g., during network congestion or attacks).</t>
      </section>
    </section>
    <section anchor="INTER" title="Inter-Domain Considerations"> numbered="true" toc="default">
      <name>Inter-Domain Considerations</name>
      <t>Inter-domain TE is concerned with performance optimization for
      traffic that originates in one administrative domain and terminates in a
      different one.</t>
      <t>BGP <xref target="RFC4271"/> target="RFC4271" format="default"/> is the standard
      exterior gateway protocol used to exchange routing information between autonomous systems (ASes)
      ASes in the Internet.  BGP includes a decision
      process that calculates the preference for routes to a given destination
      network.  There are two fundamental aspects to inter-domain TE using
      BGP:</t>

  <t><list style="symbols">
       <t>Route Propagation: Controlling
<dl newline="false" spacing="normal">
        <dt>Route Propagation:</dt>
	<dd>Controlling the import and export of routes between ASes, ASes and
	controlling the redistribution of routes between BGP and other
	protocols within an AS.</t>
       <t>Best-path selection: Selecting AS.</dd>
        <dt>Best-path selection:</dt>
	<dd>Selecting the best path when there are multiple candidate paths to
	a given destination network.
This is performed by the BGP decision
	process, selecting which selects the preferred exit points out of an AS towards toward specific
	destination networks by taking a number of different considerations into
	account.  The BGP path selection process can be influenced by
	manipulating the attributes associated with the process, including
	NEXT_HOP, LOCAL_PREF, AS_PATH, ORIGIN, MULTI_EXIT_DISC (MED), IGP
	metric, etc.</t>
     </list></t> etc.</dd>
      </dl>
      <t>Most BGP implementations provide constructs that facilitate the
      implementation of complex BGP policies based on pre-configured logical
      conditions. These can be used to control import and export of
      incoming and outgoing routes, control redistribution of routes
      between BGP and other protocols, and influence the selection of best
      paths by manipulating the attributes (either
     standardized, standardized or local to
      the implementation) associated with the BGP decision process.</t>
      <t>When considering inter-domain TE with BGP, note that the outbound
      traffic exit point is controllable, whereas the interconnection point
      where inbound traffic is received typically is not.  Therefore, it is up
      to each individual network to implement TE strategies that deal with the
      efficient delivery of outbound traffic from its customers to its peering
      points.  The vast majority of TE policy is based on a "closest exit"
      strategy, which offloads inter-domain traffic at the nearest outbound
      peering point towards the destination AS.  Most methods of manipulating
      the point at which inbound traffic enters are either ineffective, ineffective or
      not accepted in the peering community.</t>
      <t>Inter-domain TE with BGP is generally effective, but it is usually
      applied in a trial-and-error fashion because a TE system usually only
      has a view of the available network resources within one domain (an AS
      in this case).  A systematic approach for inter-domain TE requires
      cooperation between the domains.  Further, what may be considered a good
      solution in one domain may not necessarily be a good solution in
      another.  Moreover, it is generally considered inadvisable for one
      domain to permit a control process from another domain to influence the
      routing and management of traffic in its network.</t>

  <t>MPLS TE-tunnels
      <t>MPLS-TE tunnels (LSPs) can add a degree of flexibility in the
      selection of exit points for inter-domain routing by applying the
      concept of relative and absolute metrics.  If BGP attributes are defined
      such that the BGP decision process depends on IGP metrics to select exit
      points for inter-domain traffic, then some inter-domain traffic destined
      to a given peer network can be made to prefer a specific exit point by
      establishing a TE-tunnel TE tunnel between the router making the selection and the
      peering point via a TE-tunnel TE tunnel and assigning the TE-tunnel TE tunnel a metric which
      that is smaller than the IGP cost to all other peering points.  RSVP-TE
      protocol extensions for inter-domain MPLS and GMPLS are described in
      <xref target="RFC5151" />.</t> format="default"/>.</t>
      <t>Similarly to intra-domain TE, inter-domain TE is best accomplished
      when a traffic matrix can be derived to depict the volume of traffic
      from one AS to another.</t>
      <t>Layer 4 multipath transport protocols are designed to move traffic
      between domains and to allow some influence over the selection of the
      paths.  To be truly effective, these protocols would require visibility
      of paths and network conditions in other domains, and but that
      information may not be available, might not be complete, and is not
      necessarily trustworthy.</t>
    </section>
    <section anchor="PRACTICE" title="Overview numbered="true" toc="default">
      <name>Overview of Contemporary TE Practices in Operational IP Networks"> Networks</name>
      <t>This section provides an overview of some TE practices in IP
      networks.  The focus is on aspects of control of the routing function in
      operational contexts.  The intent here is to provide an overview of the
      commonly used practices: practices; the discussion is not intended to be
      exhaustive.</t>
      <t>Service providers apply many of the TE mechanisms described in this
      document to optimize the performance of their IP networks, although
      others choose to not use any of them.  These techniques include capacity planning
      planning, including adding ECMP options options, for long timescales; routing
      control using IGP metrics and MPLS, as well as path planning and path
      control using MPLS and Segment Routing SR for medium timescales; and
      traffic management mechanisms for short timescale.</t>

  <list style="symbols">

     <t>Capacity timescales.</t>
      <ul spacing="normal">
        <li>Capacity planning is an important component of how a service
        provider plans an effective IP network.  These plans may take the
        following aspects into account: location of any new links or nodes,
        WECMP algorithms, existing and predicted traffic patterns, costs, link
        capacity, topology, routing design, and survivability.</t>

     <t>Performance survivability.</li>
        <li>Performance optimization of operational networks is usually an
        ongoing process in which traffic statistics, performance parameters,
        and fault indicators are continually collected from the network.  This
        empirical data is analyzed and used to trigger TE mechanisms.  Tools
        that perform what-if analysis can also be used to assist the TE
        process by reviewing scenarios before a new set of configurations are
        implemented in the operational network.</t>

     <t>Real-time network.</li>
        <li>Real-time intra-domain TE using the IGP is done by increasing the
        OSPF or IS-IS metric of a congested link until enough traffic has been
        diverted away from that link.  This approach has some limitations as
        discussed in <xref target="ROUTEREC"/>. target="ROUTEREC" format="default"/>.  Intra-domain
        TE approaches (<xref target="RR94"/> <xref target="FT00"/> target="RR94" format="default"/> <xref
        target="FT00" format="default"/> <xref target="FT01"/> target="FT01"
        format="default"/> <xref target="WANG"/>) target="WANG" format="default"/> take
        traffic matrix, network topology, and network performance objectives
        as input, input and produce link metrics and load-sharing ratios.  These
        processes open the possibility for intra-domain TE with IGP to be done
        in a more systematic way.</t>

  </list> way.</li>
      </ul>

      <t>Administrators of MPLS-TE networks specify and configure link
      attributes and resource constraints such as maximum reservable bandwidth
      and resource class attributes for the links in the domain.  A link
     state link-state
      IGP that supports TE extensions (IS-IS-TE or OSPF-TE) is used to
      propagate information about network topology and link attributes to all
      routers in the domain.  Network administrators specify the LSPs that are
      to originate at each router.  For each LSP, the network administrator
      specifies the destination node and the attributes of the LSP which that
      indicate the requirements that are to be satisfied during the path
      selection process.  The attributes may include an explicit path for the
      LSP to follow, or the originating router may use a local
      constraint-based routing process to compute the path of the LSP.
      RSVP-TE is used as a signaling protocol to instantiate the LSPs.  By
      assigning proper bandwidth values to links and LSPs, congestion caused
      by uneven traffic distribution can be avoided or mitigated.</t>
      <t>The bandwidth attributes of an LSP relate to the bandwidth
      requirements of traffic that flows through the LSP.  The traffic
      attribute of an LSP can be modified to accommodate persistent shifts in
      demand (traffic growth or reduction).  If network congestion occurs due
      to unexpected events, existing LSPs can be rerouted to alleviate the
      situation, or the network administrator can configure new LSPs to divert
      some traffic to alternative paths.  The reservable bandwidth of the
      congested links can also be reduced to force some LSPs to be rerouted to
      other paths.  A traffic matrix in an MPLS domain can also be estimated
      by monitoring the traffic on LSPs.  Such traffic statistics can be used
      for a variety of purposes including network planning and network
      optimization.</t>
      <t>Network management and planning systems have evolved and assumed a
      lot of the responsibility for determining traffic paths in TE networks.
      This allows a network-wide view of resources, resources and facilitates
      coordination of the use of resources for all traffic flows in the
      network.  Initial solutions using a PCE to perform path computation on
      behalf of network routers have given way to an approach that follows the
      SDN architecture.  A stateful PCE is able to track all of the LSPs in
      the network and can redistribute them to make better use of the
      available resources.  Such a PCE can form part of a network orchestrator
      that uses PCEP or some other configuration and management interface to
      instruct the signaling protocol or directly program the routers.</t>

  <t>Segment Routing
      <t>SR leverages a centralized TE controller and either an
      MPLS or IPv6 forwarding plane, plane but does not need to use a signaling
      protocol or management plane protocol to reserve resources in the
      routers.  All resource reservation is logical within the controller, controller and
      is not distributed to the routers.  Packets are steered through the
      network using Segment Routing, SR, and this may have configuration and
      operational scaling benefits.</t>
      <t>As mentioned in <xref target="INTER"/>, target="INTER" format="default"/>, there is
      usually no direct control over the distribution of inbound traffic to a
      domain.  Therefore, the main goal of inter-domain TE is to optimize the
      distribution of outbound traffic between multiple inter-domain links.
      When operating a geographically widespread network (such as for a
      multi-national or global network provider), maintaining the ability to
      operate the network in a regional fashion where desired, while
      continuing to take advantage of the benefits of a globally
      interconnected network, also becomes an important objective.</t>

      <t>Inter-domain TE with BGP begins with the placement of multiple
      peering interconnection points that are in close proximity to traffic sources/destination,
      sources/destinations and offer lowest-cost paths across the network
      between the peering points and the sources/destinations.  Some
      location-decision problems that arise in association with inter-domain
      routing are discussed in <xref target="AWD5"/>.</t> target="AWD5" format="default"/>.</t>
      <t>Once the locations of the peering interconnects have been determined
      and implemented, the network operator decides how best to handle the
      routes advertised by the peer, as well as how to propagate the peer&apos;s peer's
      routes within their network.  One way to engineer outbound traffic flows
      in a network with many peering interconnects is to create a hierarchy of
      peers.  Generally, the shortest AS paths will be chosen to forward traffic
      traffic, but BGP metrics can be used to prefer some peers and so favor
      particular paths.  Preferred peers are those peers attached through
      peering interconnects with the most available capacity.  Changes may be
      needed, for example, to deal with a "problem peer" who is difficult to
      work with on upgrades or is charging high prices for connectivity to
      their network.  In that case, the peer may be given a reduced
      preference.  This type of change can affect a large amount of traffic, traffic
      and is only used after other methods have failed to provide the desired
      results.</t>
      <t>When there are multiple exit points toward a given peer, and only one
      of them is congested, it is not necessary to shift traffic away from the
      peer entirely, but only from the one congested connections. connection. This can be
      achieved by using passive IGP metrics, AS_PATH filtering, or prefix
      filtering.</t>
    </section>
    <section anchor="SECURE" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>In general, TE mechanisms are security-neutral, security neutral, and this document
      does not introduce new security issues.</t>
      <t>Network security is, of course, an important issue, and TE mechanisms
      can have benefits and drawbacks.</t>

  <list style="symbols">

     <t>TE drawbacks:</t>
      <ul spacing="normal">
        <li>TE may use tunnels which that can slightly help protect traffic from
        inspection and which, that, in some cases, can be secured using encryption.</t>

     <t>TE
        encryption.</li>
        <li>TE puts traffic onto predictable paths within the network that may
        make it easier to find and attack.</t>

     <t>TE attack.</li>
        <li>TE often increases the complexity of operation and management of
        the network network, which may lead to errors that compromise security.</t>

     <t>TE security.</li>
        <li>TE enables traffic to be steered onto more secure links or
        to more secure parts of the network.</t>

     <t>TE network.</li>
        <li>TE can be used to steer traffic through network nodes that are
        able to provide additional security
        functions.</t>

  </list> functions.</li>
      </ul>
      <t>The consequences of attacks on the control and management protocols
      used to operate TE networks can be significant:
     traffic significant:</t>
      <ul spacing="normal">
      <li>Traffic can be hijacked
      to pass through specific nodes that perform inspection, inspection or even to be
      delivered to the wrong place; traffic place.</li>
      <li>Traffic can be steered onto paths that
      deliver quality that is below the desired quality; and, networks quality.</li>
      <li>Networks can be
      congested or have resources on key links consumed.  Thus, consumed.</li>
      </ul>
      <t>Thus, it is
      important to use adequate protection mechanisms, such as authentication,
      on all protocols used to deliver TE.</t>
      <t>Certain aspects of a network may be deduced from the details of the
      TE paths that are used.  For example, the link connectivity of the network,
      network and the quality and load on individual links may be inferred
      from knowing the paths of traffic and the requirements they place on the
      network (for example, by seeing the control messages or through path-
     trace
      path-trace techniques).  Such knowledge can be used to launch targeted
      attacks (for example, taking down critical links) or can reveal
      commercially sensitive information (for example, whether a network is
      close to capacity).  Network  Therefore, network operators may, therefore, may choose techniques
      that mask or hide information from within the network.</t>
      <t>External control interfaces that are introduced to provide additional
      control and management of TE systems (see <xref target="TEapproach" />)
      format="default"/>) provide flexibility to management and to customers,
      but they do so at the risk of exposing the internals of a network to
      potentially malicious actors.  The protocols used at these interfaces
      must be secured to protect against snooping and modification, and use of
      the interfaces must be authenticated.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This draft makes document has no requests for IANA action.</t> actions.</t>
    </section>

<section anchor="ACKN" title="Acknowledgments">

  <t>Much of the text in this document is derived from RFC 3272.  The editor and contributors to this
     document would like to express their gratitude to all involved in that work.
     Although the source text has been edited in the production of this document, the
     original authors should be considered as Contributors to this work.  They were:</t>

  <figure><artwork><![CDATA[
   Daniel O. Awduche
   Movaz Networks

   Angela Chiu
   Celion Networks

   Anwar Elwalid
   Lucent Technologies

   Indra Widjaja
   Bell Labs, Lucent Technologies

   XiPeng Xiao
   Redback Networks
  ]]></artwork></figure>

  <t>The acknowledgements in RFC3272 were as below.  All people who helped
     in the production of that document also need to be thanked for the
     carry-over into this new document.</t>

  <figure><artwork><![CDATA[
   The authors would like

  </middle>
  <back>

<displayreference target="I-D.ietf-bess-evpn-unequal-lb" to="EVPN-UNEQUAL-LB"/>
<displayreference target="I-D.ietf-idr-performance-routing" to="PERFORMANCE-ROUTING"/>
<displayreference target="I-D.ietf-idr-segment-routing-te-policy" to="SR-TE-POLICY"/>
<displayreference target="I-D.ietf-quic-multipath" to="QUIC-MULTIPATH"/>
<displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="SR-TI-LFA"/>
<displayreference target="I-D.ietf-teas-enhanced-vpn" to="ENHANCED-VPN"/>
<displayreference target="I-D.ietf-tewg-qos-routing" to="TE-QoS-ROUTING"/>
<displayreference target="I-D.ietf-teas-ietf-network-slices" to="NETWORK-SLICES"/>
<displayreference target="I-D.ietf-tsvwg-multipath-dccp" to="MULTIPATH-DCCP"/>

    <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1102.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1104.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2386.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2597.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2678.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2702.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2722.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2753.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2961.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2998.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3086.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3124.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3175.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3198.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3272.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3469.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3945.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4124.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4461.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4873.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5151.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5250.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5331.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5394.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5470.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5472.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5557.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5559.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5623.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5664.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5671.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5693.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6107.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6372.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6601.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6805.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7149.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7390.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7491.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7551.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7926.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7923.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8033.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8034.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8189.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8290.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8571.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8684.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8685.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8795.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8803.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8896.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8972.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9023.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9040.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9262.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9298.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9315.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9332.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9439.xml"/>

<reference anchor="Err309" quote-title="false" target="https://www.rfc-editor.org/errata/eid309">
   <front>
      <title>Erratum ID 309</title>
      <author>
         <organization>RFC Errata</organization>
      </author>
   </front>
   <refcontent>RFC 3272</refcontent>
</reference>

<!-- [I-D.ietf-bess-evpn-unequal-lb] IESG state	I-D Exists. Updated to thank Jim Boyle long version because missing editor role for inputs on the
   recommendations section, Francois Le Faucheur Malhotra and contains extra initials for inputs on
   Diffserv aspects, Blaine Christian Lingala-->

<reference anchor="I-D.ietf-bess-evpn-unequal-lb">
<front>
<title>Weighted Multi-Path Procedures for inputs on measurement,
   Gerald Ash EVPN Multi-Homing</title>
<author initials="N." surname="Malhotra" fullname="Neeraj Malhotra" role="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco Systems</organization>
</author>
<author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper</organization>
</author>
<author initials="A." surname="Lingala" fullname="Avinash Lingala">
<organization>ATT</organization>
</author>
<author initials="S." surname="Thoria" fullname="Samir Thoria">
<organization>Cisco Systems</organization>
</author>
<date month="December" day="7" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-unequal-lb-21"/>
</reference>

<!-- [I-D.ietf-idr-performance-routing] IESG state Expired. Updated to long version because showing wrong date -->

<reference anchor="I-D.ietf-idr-performance-routing" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-performance-routing-03">
<front>
<title>Performance-based BGP Routing Mechanism</title>
<author initials="X." surname="Xu" fullname="Xiaohu Xu">
<organization>Alibaba, Inc</organization>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar">
<organization>Cisco</organization>
</author>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="C." surname="Jacquenet" fullname="Christian Jacquenet">
<organization>France Telecom</organization>
</author>
<date month="December" day="22" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-performance-routing-03"/>
</reference>

<!-- [I-D.ietf-idr-segment-routing-te-policy] IESG state AD is watching. Updated to long version because missing editor role for inputs on routing Talaulikar -->

<reference anchor="I-D.ietf-idr-segment-routing-te-policy">
<front>
<title>Advertising Segment Routing Policies in telephone networks and for
   text on event-dependent TE methods, Steven Wright for inputs
   on network controllability, BGP</title>
<author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization>Huawei Technologies</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Mattes" fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Jain" fullname="Dhanendra Jain">
<organization>Google</organization>
</author>
<date month="October" day="23" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-segment-routing-te-policy-26"/>
</reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9502.xml"/>

<!-- [I-D.ietf-quic-multipath] IESG state I-D Exists. Updated to long version because missing editor roles and Jonathan Aufderheide fix name for
   inputs on inter-domain TE with BGP.  Special thanks to
   Randy Bush Y. Ma-->

<reference anchor="I-D.ietf-quic-multipath" target="https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-06">
<front>
<title>Multipath Extension for proposing the TE taxonomy based on "tactical versus
   strategic" methods.  The subsection describing an "Overview QUIC</title>
<author initials="Y." surname="Liu" fullname="Yanmei Liu" role="editor">
<organization>Alibaba Inc.</organization>
</author>
<author initials="Y." surname="Ma" fullname="Yunfei Ma" role="editor">
<organization>Uber Technologies Inc.</organization>
</author>
<author initials="Q." surname="De Coninck" fullname="Quentin De Coninck" role="editor">
<organization>University of
   ITU Activities Related to Traffic Engineering" was adapted from
   a contribution by Waisum Lai.  Useful feedback Mons (UMONS)</organization>
</author>
<author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure">
<organization>UCLouvain and pointers to
   relevant materials were provided by J. Noel Chiappa.
   Additional comments were provided by Glenn Grotefeld during
   the working last call process.  Finally, the authors would like Tessares</organization>
</author>
<author initials="C." surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus Inc.</organization>
</author>
<author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind" role="editor">
<organization>Ericsson</organization>
</author>
<date month="October" day="23" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-multipath-06"/>
</reference>

<!-- [I-D.ietf-rtgwg-segment-routing-ti-lfa] IESG state	I-D Exists -->

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-enhanced-vpn.xml"/>

<!-- [I-D.ietf-tewg-qos-routing] IESG state Expired (IESG: Dead). Updated to thank Ed Kern, the TEWG co-chair, long version because showing wrong date -->

<reference anchor="I-D.ietf-tewg-qos-routing" target="https://datatracker.ietf.org/doc/html/draft-ietf-tewg-qos-routing-04">
<front>
<title>Traffic Engineering &amp; QoS Methods for his comments and
   support.
  ]]></artwork></figure>

  <t>The early versions of this document were produced by the TEAS Working Group&apos;s
     RFC3272bis Design Team.  The full list of members of this team is:</t>

  <figure><artwork><![CDATA[
    Acee Lindem
    Adrian Farrel
    Aijun Wang
    Daniele Ceccarelli
    Dieter Beller
    Jeff Tantsura
    Julien Meuric
    Liu Hua
    Loa Andersson
    Luis Miguel Contreras
    Martin Horneffer
    Tarek Saad
    Xufeng Liu
  ]]></artwork></figure>

  <t>The production of this document includes a fix IP-, ATM-, &amp; Based Multiservice Networks</title>
<author initials="G." surname="Ash" fullname="Gerald Ash"> </author>
<date month="October" year="2001"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tewg-qos-routing-04"/>
</reference>

<!-- [I-D.ietf-teas-ietf-network-slices] IESG state IESG Evaluation::AD Followup. Updated to the original text
     resulting from an Errata Report by Jean-Michel Grimaldi.</t>

  <t>The long version because missing editor of this document would also like to thank Dhruv Dhody, Gyan Mishra,
     Joel Halpern, Dave Taht, John Scudder, Rich Salz, Behcet Sarikaya, Bob Briscoe,
     Erik Kline, Jim Guichard, Martin Duke, and Roman Danyliw, roles -->

<reference anchor="I-D.ietf-teas-ietf-network-slices">
<front>
<title>A Framework for review comments.</t>

  <t>This work is partially supported by the European Commission under
     Horizon 2020 grant agreement number 101015857 Secured autonomic
     traffic management Network Slices in Networks Built from IETF Technologies</title>
<author initials="A." surname="Farrel" fullname="Adrian Farrel" role="editor">
<organization>Old Dog Consulting</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake" role="editor">
<organization>Juniper Networks</organization>
</author>
<author initials="R." surname="Rokui" fullname="Reza Rokui">
<organization>Ciena</organization>
</author>
<author initials="S." surname="Homma" fullname="Shunsuke Homma">
<organization>NTT</organization>
</author>
<author initials="K." surname="Makhijani" fullname="Kiran Makhijani">
<organization>Futurewei</organization>
</author>
<author initials="L. M." surname="Contreras" fullname="Luis M. Contreras">
<organization>Telefonica</organization>
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<organization>Nvidia</organization>
</author>
<date month="September" day="14" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slices-25"/>
</reference>

<!-- [I-D.ietf-tsvwg-multipath-dccp] IESG state I-D Exists. Updated to long version because missing editor role -->

<reference anchor="I-D.ietf-tsvwg-multipath-dccp">
<front>
<title>DCCP Extensions for a Tera Multipath Operation with Multiple Addresses</title>
<author initials="M." surname="Amend" fullname="Markus Amend" role="editor">
<organization>Deutsche Telekom</organization>
</author>
<author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
<organization>Karlstad University</organization>
</author>
<author initials="A." surname="Kassler" fullname="Andreas Kassler">
<organization>Karlstad University</organization>
</author>
<author initials="V." surname="Rakocevic" fullname="Veselin Rakocevic">
<organization>City University of SDN flows (Teraflow).</t>

</section>

<section anchor="CONTRIB" title="Contributors">

  <t>The following people contributed substantive text to this document:</t>

  <figure><artwork><![CDATA[
    Gert Grammel
    EMail: ggrammel@juniper.net

    Loa Andersson
    EMail: loa@pi.nu

    Xufeng Liu
    EMail: xufeng.liu.ietf@gmail.com

    Lou Berger
    EMail: lberger@labn.net

    Jeff Tantsura
    EMail: jefftant.ietf@gmail.com

    Daniel King
    EMail: daniel@olddog.co.uk

    Boris Hassanov
    EMail: bhassanov@yandex-team.ru

    Kiran Makhijani
    Email: kiranm@futurewei.com

    Dhruv Dhody
    Email: dhruv.ietf@gmail.com

    Mohamed Boucadair
    Email: mohamed.boucadair@orange.com
  ]]></artwork></figure>

</section>

</middle>

<back>

<references title='Informative References'>

  &RFC0791;
  &RFC1102;
  &RFC1104;
  &RFC2205;
  &RFC2330;
  &RFC2386;
  &RFC2474;
  &RFC2475;
  &RFC2597;
  &RFC2678;
  &RFC2702;
  &RFC2722;
  &RFC2753;
  &RFC2961;
  &RFC2998;
  &RFC3031;
  &RFC3086;
  &RFC3124;
  &RFC3168;
  &RFC3175;
  &RFC3198;
  &RFC3209;
  &RFC3270;
  &RFC3272;
  &RFC3469;
  &RFC3473;
  &RFC3630;
  &RFC3945;
  &RFC4090;
  &RFC4124;
  &RFC4203;
  &RFC4271;
  &RFC4340;
  &RFC4461;
  &RFC4594;
  &RFC4655;
  &RFC4872;
  &RFC4873;
  &RFC4875;
  &RFC5151;
  &RFC5250;
  &RFC5305;
  &RFC5329;
  &RFC5331;
  &RFC5357;
  &RFC5394;
  &RFC5440;
  &RFC5470;
  &RFC5472;
  &RFC5541;
  &RFC5557;
  &RFC5559;
  &RFC5623;
  &RFC5664;
  &RFC5671;
  &RFC5693;
  &RFC6107;
  &RFC6119;
  &RFC6241;
  &RFC6372;
  &RFC6374;
  &RFC6601;
  &RFC6805;
  &RFC7011;
  &RFC7149;
  &RFC7285;
  &RFC7390;
  &RFC7426;
  &RFC7471;
  &RFC7491;
  &RFC7551;
  &RFC7567;
  &RFC7665;
  &RFC7679;
  &RFC7680;
  &RFC7752;
  &RFC7926;
  &RFC7923;
  &RFC7950;
  &RFC8033;
  &RFC8034;
  &RFC8040;
  &RFC8051;
  &RFC8189;
  &RFC8231;
  &RFC8259;
  &RFC8279;
  &RFC8281;
  &RFC8283;
  &RFC8290;
  &RFC8402;
  &RFC8453;
  &RFC8570;
  &RFC8571;
  &RFC8655;
  &RFC8664;
  &RFC8684;
  &RFC8685;
  &RFC8795;
  &RFC8803;
  &RFC8896;
  &RFC8938;
  &RFC8955;
  &RFC8972;
  &RFC9000;
  &RFC9023;
  &RFC9040;
  &RFC9113;
  &RFC9256;
  &RFC9262;
  &RFC9298;
  &RFC9315;
  &RFC9332;
  &RFC9350;
  &RFC9439;

  &I-D.ietf-bess-evpn-unequal-lb;
  &I-D.ietf-idr-performance-routing;
  &I-D.ietf-idr-segment-routing-te-policy;
  &I-D.ietf-lsr-ip-flexalgo;
  &I-D.ietf-quic-multipath;
  &I-D.ietf-rtgwg-segment-routing-ti-lfa;
  &I-D.ietf-teas-enhanced-vpn;
  &I-D.ietf-tewg-qos-routing;
  &I-D.ietf-teas-ietf-network-slices;
  &I-D.ietf-tsvwg-multipath-dccp; London</organization>
</author>
<author initials="S." surname="Johnson" fullname="Stephen Johnson">
<organization>BT</organization>
</author>
<date month="October" day="12" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-multipath-dccp-11"/>
</reference>

      <reference anchor="AFD03" target="https://dl.acm.org/doi/10.1145/956981.956985">
        <front>
          <title>Approximate fairness through differential dropping</title>
          <author initials="R." surname="Pan" fullname="Rong Pan">
        <organization></organization>
            <organization/>
          </author>
          <author initials="L." surname="Breslau" fullname="Lee Breslau">
        <organization></organization>
            <organization/>
          </author>
          <author initials="B." surname="Prabhakar" fullname="Balaji Prabhakar">
        <organization></organization>
            <organization/>
          </author>
          <author initials="S." surname="Shenker" fullname="Scott Shenker">
        <organization></organization>
            <organization/>
          </author>
          <date month="April" year="2003"/>
        </front>
    <seriesInfo name="Article" value="ACM
        <refcontent>ACM SIGCOMM Computer Communication Review, Volume 33,
        Issue 2, April 2003, pp 23-39"/> Pages 23-39</refcontent>
	<seriesInfo name="DOI" value="10.1145/956981.956985"/>
      </reference>

      <reference anchor="AJ19" target="https://journalofbigdata.springeropen.com/track/pdf/10.1186/s40537-019-0176-5.pdf">
        <front>
          <title>Data mining approach for predicting the daily Internet data
          traffic of a smart university</title>
          <author initials="A." surname="Adekitan" fullname="A. Adekitan">
        <organization></organization>
            <organization/>
          </author>
          <author initials="J." surname="Abolade" fullname="J. Abolade">
        <organization></organization>
            <organization/>
          </author>
          <author initials="O." surname="Shobayo" fullname="O. Shobayo">
        <organization></organization>
            <organization/>
          </author>
          <date year="1998"/> month="February" year="2019"/>
        </front>
    <seriesInfo name="Article" value="Journal
        <refcontent>Journal of Big Data, 2019, Volume 6, Number 1, Page 1"/> 1</refcontent>
	<seriesInfo name="DOI" value="10.1186/s40537-019-0176-5"/>
      </reference>

      <reference anchor="ATSSS" target="https://www.3gpp.org/ftp//Specs/archive/23_series/23.793/23793-g00.zip">
        <front>
          <title>Study on access traffic steering, switch and splitting
          support in the 5G System (5GS) architecture</title>
      <author >
        <organization></organization>
          <author>
            <organization>3GPP</organization>
          </author>
          <date year="2018" month="December"/>
        </front>
    <seriesInfo name="Specification" value="3GPP Technical Report 23.793 Release 16"/>
	<refcontent>Release 16</refcontent>
        <refcontent>3GPP TR 23.793</refcontent>
      </reference>

      <reference anchor="AWD2" target="https://ieeexplore.ieee.org/document/809383">
        <front>
          <title>MPLS and Traffic Engineering traffic engineering in IP Networks</title> networks</title>
          <author initials="D." surname="Awduche" fullname="Daniel Awduche">
        <organization></organization>
            <organization/>
          </author>
          <date year="1999" month="December"/>
        </front>
    <seriesInfo name="Article" value="IEEE
        <refcontent>IEEE Communications Magazine"/> Magazine, Volume 37, Issue 12, Pages
        42-47</refcontent>
	<seriesInfo name="DOI" value="10.1109/35.809383"/>
      </reference>

      <reference anchor="AWD5" target="https://ieeexplore.ieee.org/document/998795">
        <front>
          <title>An Approach approach to Optimal Peering Between Autonomous Systems optimal peering between autonomous systems in
          the Internet</title>
          <author initials="D." surname="Awduche" fullname="Daniel Awduche">
        <organization></organization>
            <organization/>
          </author>
          <date year="1998" month="October"/>
        </front>
    <seriesInfo name="Paper" value="International
        <refcontent>Proceedings 7th International Conference on Computer
        Communications and Networks (ICCCN'98)"/> (Cat. No. 98EX226)</refcontent>
	<seriesInfo name="DOI" value="10.1109/ICCCN.1998.998795"/>
      </reference>

      <reference anchor="E.360.1" target="https://www.itu.int/rec/T-REC-E.360.1-200205-I/en">
        <front>
      <title>E.360.1: Framework
          <title>Framework for QoS routing and related traffic
          engineering methods for IP-, ATM-, and TDM-based multiservice
          networks</title>
          <author>
        <organization>International Telecommunication Union - Telecommunication Standardization Sector</organization>
            <organization>ITU-T</organization>
          </author>
          <date year="2002" month="May" day="16" /> month="May"/>
        </front>
        <seriesInfo name="Recommendation" value="ITU-T Recommendation E.360.1" /> name="ITU-T Recommendation" value="E.360.1"/>
      </reference>

      <reference anchor="FLJA93" target="https://www.icir.org/floyd/papers/early.twocolumn.pdf">
        <front>
          <title>Random Early Detection Gateways for Congestion Avoidance</title>
          <author initials="S." surname="Floyd">
        <organization></organization>
            <organization/>
          </author>
          <author initials="V." surname="Jacobson">
        <organization></organization>
            <organization/>
          </author>
          <date year="1993" month="November"/> month="August"/>
        </front>
    <seriesInfo name="Article" value="IEEE/ACM
        <refcontent>IEEE/ACM Transactions on Networking, Vol. Volume 1, p. 387-413"/>
       Issue 4, Pages 397-413</refcontent>
       <seriesInfo name="DOI" value="10.1109/90.251892"/>
      </reference>

      <reference anchor="FT00" target="https://www.cs.cornell.edu/courses/cs619/2004fa/documents/ospf_opt.pdf">
        <front>
          <title>Internet Traffic Engineering by Optimizing OSPF Weights</title>
          <author initials="B." surname="Fortz">
        <organization></organization>
            <organization/>
          </author>
          <author initials="M." surname="Thorup">
        <organization></organization>
            <organization/>
          </author>
          <date year="2000" month="March"/>
        </front>
    <seriesInfo name="Article" value="IEEE
	<refcontent>Proceedings IEEE INFOCOM 2000"/> 2000</refcontent>
	<seriesInfo name="DOI" value="10.1109/INFCOM.2000.832225"/>
      </reference>

      <reference anchor="FT01" target="http://www.research.att.com/~mthorup/PAPERS/papers.html"> target="https://ieeexplore.ieee.org/document/1003042">
        <front>
          <title>Optimizing OSPF/IS-IS Weights in a Changing World</title>
          <author initials="B." surname="Fortz">
        <organization></organization>
            <organization/>
          </author>
          <author initials="M." surname="Thorup">
        <organization></organization>
            <organization/>
          </author>
          <date year="n.d."/> month="May" year="2002"/>
        </front>
        <refcontent>IEEE Journal on Selected Areas in Communications</refcontent>
        <seriesInfo name='DOI' value='10.1109/JSAC.2002.1003042' />
      </reference>

      <reference anchor="GRPC" target="https://grpc.io">
        <front>
      <title>gPPC:
          <title>gRPC: A high performance, open source universal RPC
          framework</title>
          <author>
        <organization>Cloud Native Computing Foundation</organization>
            <organization>gRPC Authors</organization>
          </author>
      <date year="n.d."/>
          <date></date>
        </front>
      </reference>

      <reference anchor="KELLY">
        <front>
          <title>Notes on effective bandwidths. In Stochastic Networks: Theory and Applications</title> bandwidths</title>
          <author initials="F." surname="Kelly">
	  </author>
          <date year="1996"/>
        </front>
    <seriesInfo name="Book" value="Oxford
	<refcontent>Oxford University Press"/> Press</refcontent>
      </reference>

      <reference anchor="MA" target="https://apps.dtic.mil/sti/pdfs/ADA352299.pdf">
        <front>
      <title>Quality of Service
          <title>Quality-of-Service Routing in Integrated Services Networks</title>
          <author initials="Q." surname="Ma">
        <organization></organization>
            <organization/>
          </author>
          <date month="January" year="1998"/>
        </front>
    <seriesInfo name="Ph.D." value="PhD
        <refcontent>Ph.D. Dissertation, CMU-CS-98-138, CMU"/> Carnegie Mellon University,
        CMU-CS-98-138</refcontent>
      </reference>

      <reference anchor="MATE" target="https://www.yumpu.com/en/document/view/35140398/mate-mpls-adaptive-traffic-engineering-infocom-ieee-xplore/8">
        <front>
      <title>MATE -
          <title>MATE: MPLS Adaptive Traffic Engineering</title>
          <author initials="A." surname="Elwalid">
        <organization></organization>
            <organization/>
          </author>
          <author initials="C." surname="Jin">
        <organization></organization>
            <organization/>
          </author>
          <author initials="S." surname="Low">
        <organization></organization>
            <organization/>
          </author>
          <author initials="I." surname="Widjaja">
        <organization></organization>
            <organization/>
          </author>
          <date year="2001" month="April"/> year="2002" month="August"/>
        </front>
	<refcontent>Proceedings IEEE INFOCOM 2001, Conference on Computer
	Communications, Twentieth Annual Joint Conference of the IEEE Computer
	and Communications Society (Cat. No. 01CH37213)</refcontent>
        <seriesInfo name="Proceedings" value="INFOCOM'01"/> name="DOI" value="10.1109/INFCOM.2001.916625"/>
      </reference>

      <reference anchor="MR99" target="https://ieeexplore.ieee.org/document/830281">
        <front>
          <title>A Case Study case study of Multiservice, Multipriority Traffic Engineering Design multiservice, multipriority traffic engineering design for Data Networks</title> data networks</title>
          <author initials="D." surname="Mitra">
        <organization></organization>
            <organization/>
          </author>
          <author initials="K.G." surname="Ramakrishnan">
        <organization></organization>
            <organization/>
          </author>
          <date year="1999" month="December"/>
        </front>
	<refcontent>Seamless Interconnection for Universal Services, Global
	Telecommunications Conference, GLOBECOM'99,
	(Cat. No. 99CH37042)</refcontent>
        <seriesInfo name="Proceedings" value="Globecom'99"/> name="DOI" value="10.1109/GLOCOM.1999.830281"/>
      </reference>

      <reference anchor="RR94" target="https://onlinelibrary.wiley.com/doi/abs/10.1002/bltj.2267">
        <front>
          <title>Optimal Routing routing in Shortest Path Data Networks</title> shortest-path data networks</title>
          <author initials="M.A." initials="M." surname="Rodrigues">
        <organization></organization>
            <organization/>
          </author>
          <author initials="K.G." surname="Ramakrishnan">
        <organization></organization>
            <organization/>
          </author>
          <date year="1994"/> month="August" year="2002"/>
        </front>
	<refcontent>Bell Labs Technical Journal, Volume 6, Issue 1, Pages
	117-138</refcontent>
        <seriesInfo name="Proceedings" value="ITS'94, Rio de Janeiro, Brazil"/> name="DOI" value="10.1002/bltj.2267"/>
      </reference>

      <reference anchor="SLDC98" target="https://ieeexplore.ieee.org/document/659666">
        <front>
          <title>Design Considerations considerations for Supporting supporting TCP with Per-flow Queueing</title> per-flow queueing</title>
          <author initials="B." surname="Suter">
        <organization></organization>
            <organization/>
          </author>
          <author initials="T." initials="T.V." surname="Lakshman">
        <organization></organization>
            <organization/>
          </author>
          <author initials="D." surname="Stiliadis">
        <organization></organization>
            <organization/>
          </author>
          <author initials="A." initials="A.K." surname="Choudhury">
        <organization></organization>
            <organization/>
          </author>
          <date month="April" year="1998"/>
        </front>
	<refcontent>Proceedings IEEE INFOCOM '98
	</refcontent>
        <seriesInfo name="Proceedings" value="INFOCOM'98, p. 299-306"/> name="DOI" value="10.1109/INFCOM.1998.659666"/>
      </reference>

      <reference anchor="WANG" target="https://ieeexplore.ieee.org/document/916782">
        <front>
          <title>Internet traffic engineering without full mesh overlaying</title>
          <author initials="Y." surname="Wang">
        <organization></organization>
            <organization/>
          </author>
          <author initials="Z." surname="Wang">
        <organization></organization>
            <organization/>
          </author>
          <author initials="L." surname="Zhang">
        <organization></organization>
            <organization/>
          </author>
          <date year="2001" month="April"/>
        </front>
	<refcontent>Proceedings IEEE INFOCOM 2001
		</refcontent>
        <seriesInfo name="Proceedings" value="INFOCOM'2001"/> name="DOI" value="10.1109/INFCOM.2001.916782"/>
      </reference>

      <reference anchor="XIAO" target="https://courses.cs.washington.edu/courses/cse561/02au/papers/xiao-mpls-net00.pdf">
        <front>
          <title>Traffic Engineering with MPLS in the Internet</title>
          <author initials="X." surname="Xiao">
        <organization></organization>
            <organization/>
          </author>
          <author initials="A." surname="Hannan">
        <organization></organization>
            <organization/>
          </author>
          <author initials="B." surname="Bailey">
        <organization></organization>
            <organization/>
          </author>
          <author initials="L." surname="Ni">
        <organization></organization>
            <organization/>
          </author>
          <date year="2000" month="March"/>
        </front>
	<refcontent>IEEE Network, Volume 14, Issue 2, Pages 28-33</refcontent>
	<seriesInfo name="Article" value="IEEE Network Magazine"/> name="DOI" value="10.1109/65.826369"/>
      </reference>

      <reference anchor="YARE95" target="http://www.cs.uccs.edu/~zbo/teaching/CS522/Projects/Taxonomy_Network1995.pdf"> target="https://ieeexplore.ieee.org/document/397042">
        <front>
          <title>A Taxonomy for Congestion Control Algorithms in Packet
          Switching Networks</title>
          <author initials="C." surname="Yang">
        <organization></organization>
            <organization/>
          </author>
          <author initials="A." surname="Reddy">
        <organization></organization>
            <organization/>
          </author>
          <date month="August" year="1995"/>
        </front>
	<refcontent>IEEE Network, Pages 34-45</refcontent>
	<seriesInfo name="Article" value="IEEE Network Magazine, p. 34-45"/> name="DOI" value="10.1109/65.397042"/>
      </reference>

    </references>

    <section anchor="CHANGES" title="Summary numbered="true" toc="default">
      <name>Summary of Changes Since since RFC 3272"> 3272</name>
      <t>The changes to this document since RFC 3272 <xref target="RFC3272"
      format="default"/> are substantial and not easily summarized as
      section-by-section changes.  The material in the document has been moved
      around considerably, some of it removed, and new text added.</t>
      <t>The approach taken here is to list the table of content contents of both the previous
     RFC <xref target="RFC3272"
      format="default"/>
      and this document saying, respectively, where the text has
      been placed and where the text came from.</t>
      <section anchor="OLD" title="RFC 3272">
     <t><list style="hanging">
        <t hangText="1.0 Introduction:">Edited numbered="true" toc="default">
        <name>RFC 3272</name>

        <ul spacing="normal">
          <li><t>Section <xref target="RFC3272" sectionFormat="bare"
          section="1.0">"Introduction"</xref>: Edited in place in <xref
          target="INTRO" />.
           <list style="hanging">
              <t hangText="1.1 What format="default"/>.</t>
            <ul spacing="normal">
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="1.1">"What is Internet Traffic Engineering?:">Edited Engineering?"</xref>: Edited in place
              in <xref target="WHATTE" />.</t>
              <t hangText="1.2 Scope:">Moved format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="1.2">"Scope"</xref>: Moved to <xref target="SCOPE" />.</t>
              <t hangText="1.3 Terminology:">Moved
              format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="1.3">"Terminology"</xref>: Moved to <xref target="TERMS" />
              format="default"/> with some obsolete terms removed and a little editing.</t>
           </list></t>

        <t hangText="2.0 Background:">Retained
              editing.</li>
            </ul>
          </li>
          <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="2.0">"Background"</xref>: Retained as <xref target="BG" />
          format="default"/> with some text removed.
           <list style="hanging">
              <t hangText="2.1 Context removed.</t>
            <ul spacing="normal">
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="2.1">"Context of Internet Traffic Engineering:">Retained Engineering"</xref>: Retained as
              <xref target="CONTEXT" />.</t>
              <t hangText="2.2 Network Context:">Rewritten format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="2.2">"Network Context"</xref>: Rewritten as <xref target="NWCTXT" />.</t>
              <t hangText="2.3 Problem Context:">Rewritten
              format="default"/>.</li>
              <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="2.3">"Problem Context"</xref>: Rewritten as <xref target="PRBCTXT" />.
                 <list style="hanging">
                    <t hangText="2.3.1 Congestion
              format="default"/>.</t>
	        <ul spacing="normal">
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="2.3.1">"Congestion and its Ramifications:">Retained Ramifications"</xref>: Retained as
                  <xref target="CONGEST" />.</t>
                 </list></t>
              <t hangText="2.4 Solution Context:">Edited format="default"/>.</li>
		</ul>
	      </li>
              <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="2.4">"Solution Context"</xref>: Edited as <xref target="SLNCTXT" />.
                 <list style="hanging">
                    <t hangText="2.4.1 Combating
              format="default"/>.</t>
	      	<ul spacing="normal">
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="2.4.1">"Combating the Congestion Problem:">Reformatted Problem"</xref>: Reformatted as
                  <xref target="COMBAT" />.</t>
                 </list></t>
              <t hangText="2.5 Implementation format="default"/>.</li>
                </ul>
	      </li>
	      <li>Section <xref target="RFC3272" sectionFormat="bare" section="2.5">"Implementation and Operational Context:">Retained Context"</xref>: Retained as
	      <xref target="IMPCTXT" />.</t>
           </list></t>

        <t hangText="3.0 Traffic format="default"/>.</li>
            </ul>
	  </li>
          <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="3.0">"Traffic Engineering Process Model:">Retained Model"</xref>: Retained as <xref
          target="TEPROC" />.
           <list style="hanging">
              <t hangText="3.1 Components format="default"/>.</t>
	  <ul spacing="normal">
	    <li>Section <xref target="RFC3272" sectionFormat="bare" section="3.1">"Components of the Traffic Engineering Process Model:">Retained Model"</xref>:
	    Retained as <xref target="COMPONENT" />.</t>
              <t hangText="3.2 Measurement:">Merged
	    format="default"/>.</li>
	    <li>Section <xref target="RFC3272" sectionFormat="bare" section="3.2">"Measurement"</xref>: Merged into <xref target="COMPONENT" />.</t>
              <t hangText="3.3 Modeling,
	    format="default"/>.</li>
	    <li>Section <xref target="RFC3272" sectionFormat="bare" section="3.3">"Modeling, Analysis, and Simulation:">Merged Simulation"</xref>: Merged into
	    <xref target="COMPONENT" />.</t>
              <t hangText="3.4 Optimization:">Merged format="default"/>.</li>
	    <li>Section <xref target="RFC3272" sectionFormat="bare" section="3.4">"Optimization"</xref>: Merged into <xref target="COMPONENT" />.</t>
           </list></t>

        <t hangText="4.0 Historical
	    format="default"/>.</li>
	  </ul>
          </li>
          <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="4.0">"Historical Review and Recent Developments:">Retained Developments"</xref>: Retained as
          <xref target="REVIEW" />, format="default"/>, but the very historic
          aspects have been deleted.
           <list style="hanging">
              <t hangText="4.1 Traffic deleted.</t>
	  <ul spacing="normal">
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.1">"Traffic Engineering in Classical Telephone Networks:">Deleted.</t>
              <t hangText="4.2 Evolution Networks"</xref>: Deleted.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.2">"Evolution of Traffic Engineering in the Internet:">Deleted.</t>
              <t hangText="4.3 Overlay Model:">Deleted.</t>
              <t hangText="4.4 Constraint-Based Routing:">Retained Internet"</xref>: Deleted.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.3">"Overlay Model"</xref>: Deleted.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.4">"Constraint-Based Routing"</xref>: Retained as <xref
              target="CSPF" />, format="default"/>, but moved into <xref
              target="OTHER" />.</t>
              <t hangText="4.5 Overview format="default"/>.</li>
              <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="4.5">"Overview of Other IETF Projects Related to Traffic Engineering:">Retained
              Engineering"</xref>: Retained as <xref target="OTHER" /> format="default"/>
              with many new subsections.
                 <list style="hanging">
                    <t hangText="4.5.1 Integrated Services:">Retained subsections.</t>
	      	  <ul spacing="normal">
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.5.1">"Integrated Services"</xref>: Retained as <xref
                  target="INTSERV" />.</t>
                    <t hangText="4.5.2 RSVP:">Retained format="default"/>.</li>
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.5.2">"RSVP"</xref>: Retained as <xref target="RSVP" />
                  format="default"/> with some edits.</t>
                    <t hangText="4.5.3 Differentiated Services:">Retained edits.</li>
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.5.3">"Differentiated Services"</xref>: Retained as <xref
                  target="DIFFSERV" />.</t>
                    <t hangText="4.5.4 MPLS:">Retained format="default"/>.</li>
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.5.4">"MPLS"</xref>: Retained as <xref target="MPLS" />.</t>
                    <t hangText="4.5.5 IP
                  format="default"/>.</li>
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.5.5">"IP Performance Metrics:">Retained Metrics"</xref>: Retained as <xref
                  target="IPPM" />.</t>
                    <t hangText="4.5.6 Flow Measurement:">Retained format="default"/>.</li>
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.5.6">"Flow Measurement"</xref>: Retained as <xref target="RTFM" />
                  format="default"/> with some reformatting.</t>
                    <t hangText="4.5.7 Endpoint reformatting.</li>
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.5.7">"Endpoint Congestion Management:">Retained Management"</xref>: Retained as <xref
                  target="ECM" />.</t>
                 </list></t>
              <t hangText="4.6 Overview format="default"/>.</li>
                  </ul>
              </li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.6">"Overview of ITU Activities Related to Traffic Engineering:">Deleted.</t>
              <t hangText="4.7 Content Distribution:">Retained
              Engineering"</xref>: Deleted.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="4.7">"Content Distribution"</xref>: Retained as <xref target="CDN" />.</t>
           </list></t>

        <t hangText="5.0 Taxonomy
              format="default"/>.</li>
            </ul>
          </li>
          <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="5.0">"Taxonomy of Traffic Engineering Systems:">Retained Systems"</xref>: Retained as
          <xref target="TAXI" />.
           <list style="hanging">
              <t hangText="5.1 Time-Dependent format="default"/>.</t>
            <ul spacing="normal">
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="5.1">"Time-Dependent Versus State-Dependent:">Retained State-Dependent"</xref>: Retained as <xref
              target="TIME" />.</t>
              <t hangText="5.2 Offline format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="5.2">"Offline Versus Online:">Retained Online"</xref>: Retained as <xref target="OFFON" />.</t>
              <t hangText="5.3 Centralized
              format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="5.3">"Centralized Versus Distributed:">Retained Distributed"</xref>: Retained as <xref
              target="CENTRAL" /> format="default"/> with additions.</t>
              <t hangText="5.4 Local additions.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="5.4">"Local Versus Global:">Retained Global"</xref>: Retained as <xref target="LOCAL" />.</t>
              <t hangText="5.5 Prescriptive
              format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="5.5">"Prescriptive Versus Descriptive:">Retained Descriptive"</xref>: Retained as <xref
              target="SCRIPT" /> format="default"/> with additions.</t>
              <t hangText="5.6 Open-Loop additions.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="5.6">"Open-Loop Versus Closed-Loop:">Retained Closed-Loop"</xref>: Retained as <xref
              target="LOOP" />.</t>
              <t hangText="5.7 Tactical format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="5.7">"Tactical vs Strategic:">Retained Strategic"</xref>: Retained as <xref target="TACTIC" />.</t>
           </list></t>

        <t hangText="6.0 Recommendations
              format="default"/>.</li>
            </ul>
          </li>
          <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="6.0">"Recommendations for Internet Traffic Engineering:">Retained Engineering"</xref>:
          Retained as <xref target="RECO" />.
           <list style="hanging">
              <t hangText="6.1 Generic format="default"/>.</t>
            <ul spacing="normal">
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.1">"Generic Non-functional Recommendations:">Retained Recommendations"</xref>: Retained as
              <xref target="HIGHOBJ" />.</t>
              <t hangText="6.2 Routing Recommendations:">Retained format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.2">"Routing Recommendations"</xref>: Retained as <xref
              target="ROUTEREC" /> format="default"/> with edits.</t>
              <t hangText="6.3 Traffic edits.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.3">"Traffic Mapping Recommendations:">Retained Recommendations"</xref>: Retained as <xref
              target="MAPREC" />.</t>
              <t hangText="6.4 Measurement Recommendations:">Retained format="default"/>.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.4">"Measurement Recommendations"</xref>: Retained as <xref
              target="MSRREC" />.</t>
              <t hangText="6.5 Network Survivability:">Retained format="default"/>.</li>
              <li><t>Section <xref target="RFC3272" sectionFormat="bare" section="6.5">"Network Survivability"</xref>: Retained as <xref
              target="SURVIVE" />.
                 <list style="hanging">
                    <t hangText="6.5.1 Survivability format="default"/>.</t>
                <ul spacing="normal">
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.5.1">"Survivability in MPLS Based Networks:">Retained Networks"</xref>: Retained as
                  <xref target="SRVMPLS" />.</t>
                    <t hangText="6.5.2 Protection Option:">Retained format="default"/>.</li>
                  <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.5.2">"Protection Option"</xref>: Retained as <xref
                  target="PROTECT" />.</t>
                 </list></t>
              <t hangText="6.6 Traffic format="default"/>.</li>
                </ul>
              </li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.6">"Traffic Engineering in Diffserv Environments:">Retained Environments"</xref>: Retained
              as <xref target="TEDIFFSRV" /> format="default"/> with edits.</t>
              <t hangText="6.7 Network Controllability:">Retained edits.</li>
              <li>Section <xref target="RFC3272" sectionFormat="bare" section="6.7">"Network Controllability"</xref>: Retained as <xref
              target="CONTROL" />.</t>
           </list></t>

        <t hangText="7.0 Inter-Domain Considerations:">Retained format="default"/>.</li>
            </ul>
          </li>
          <li>Section <xref target="RFC3272" sectionFormat="bare" section="7.0">"Inter-Domain Considerations"</xref>: Retained as <xref
          target="INTER" />.</t>
        <t hangText="8.0 Overview format="default"/>.</li>
	  <li>Section <xref target="RFC3272" sectionFormat="bare" section="8.0">"Overview of Contemporary TE Practices in Operational IP Networks:">Retained
	  Networks"</xref>: Retained as <xref target="PRACTICE" />.</t>
        <t hangText="9.0 Conclusion:">Removed.</t>
        <t hangText="10.0 Security Considerations:">Retained format="default"/>.</li>
          <li>Section <xref target="RFC3272" sectionFormat="bare" section="9.0">"Conclusion"</xref>: Removed.</li>
	  <li>Section <xref target="RFC3272" sectionFormat="bare" section="10.0">"Security Considerations"</xref>: Retained as <xref target="SECURE" />
	  format="default"/> with considerable new text.</t>
     </list></t> text.</li>
        </ul>

      </section>
      <section anchor="NEW" title="This Document">

     <t><list style="symbols"> numbered="true" toc="default">
        <name>This Document</name>
        <ul spacing="normal">
          <li>
            <t><xref target="INTRO" />: format="default"/>: Based on Section 1 of RFC 3272.
           <list style="symbols">
           <t><xref <xref
            target="RFC3272" sectionFormat="of" section="1"/>. </t>
            <ul spacing="normal">
              <li>
                <xref target="WHATTE" />: format="default"/>: Based on Section 1.1 of RFC 3272.</t>
           <t><xref <xref
                target="RFC3272" sectionFormat="of" section="1.1"/>.</li>
              <li>
                <xref target="COMPONENTS" />: format="default"/>: New for this document.</t>
           <t><xref document.</li>
              <li>
                <xref target="SCOPE" />: format="default"/>: Based on Section 1.2 of RFC 3272.</t>
           <t><xref <xref
                target="RFC3272" sectionFormat="of" section="1.2"/>.</li>
              <li>
                <xref target="TERMS" />: format="default"/>: Based on Section 1.3 of RFC 3272.</t>
        </list></t> <xref
                target="RFC3272" sectionFormat="of" section="1.3"/>.</li>
            </ul>
          </li>
          <li>
            <t><xref target="BG" />: format="default"/>: Based on Section 2. of RFC 3272.
           <list style="symbols">
              <t><xref <xref
            target="RFC3272" sectionFormat="of" section="2"/>.
            </t>
            <ul spacing="normal">
              <li>
                <xref target="CONTEXT" />: format="default"/>: Based on Section 2.1 of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="2.1"/>.</li>
              <li>
                <xref target="NWCTXT" />: format="default"/>: Based on Section 2.2 of RFC 3272.</t> <xref
                target="RFC3272" sectionFormat="of" section="2.2"/>.</li>
              <li>
                <t><xref target="PRBCTXT" />: format="default"/>: Based on Section 2.3 of RFC 3272.
              <list style="symbols">
                 <t><xref <xref
                target="RFC3272" sectionFormat="of" section="2.3"/>.
                </t>
                <ul spacing="normal">
                  <li>
                    <xref target="CONGEST" />: format="default"/>: Based on Section 2.3.1 of RFC 3272.</t>
              </list></t> <xref
                    target="RFC3272" sectionFormat="of"
                    section="2.3.1"/>.</li>
                </ul>
              </li>
              <li>
                <t><xref target="SLNCTXT" />: format="default"/>: Based on Section 2.4 of RFC 3272.
              <list style="symbols">
                 <t><xref <xref
                target="RFC3272" sectionFormat="of" section="2.4"/>.</t>
                <ul spacing="normal">
                  <li>
                    <xref target="COMBAT" />: format="default"/>: Based on Section 2.4.1 of RFC 327</t>
              </list></t>
              <t><xref <xref
                    target="RFC3272" sectionFormat="of" section="2.4.1"/>.</li>
                </ul>
              </li>
              <li>
                <xref target="IMPCTXT" />: format="default"/>: Based on Section 2.5 of RFC 3272.</t>
           </list></t> <xref
                target="RFC3272" sectionFormat="of" section="2.5"/>.</li>
            </ul>
          </li>
          <li>
            <t><xref target="TEPROC" />: format="default"/>: Based on Section 3 of RFC 3272.
           <list style="symbols">
              <t><xref <xref
            target="RFC3272" sectionFormat="of" section="3"/>.
            </t>
            <ul spacing="normal">
              <li><xref target="COMPONENT" />: format="default"/>: Based on
              Sections 3.1, 3.2, 3.3, <xref target="RFC3272" sectionFormat="bare"
              section="3.1"/>, <xref target="RFC3272" sectionFormat="bare"
              section="3.2"/>, <xref target="RFC3272" sectionFormat="bare"
              section="3.3"/>, and 3.4 <xref target="RFC3272" sectionFormat="bare"
              section="3.4"/> of RFC 3272.</t>
           </list></t> <xref target="RFC3272"
              format="default"/>.</li>
            </ul>
          </li>
          <li>
            <t><xref target="TAXI" />: format="default"/>: Based on Section 5 of RFC 3272.
           <list style="symbols">
              <t><xref <xref
            target="RFC3272" sectionFormat="of" section="5"/>.
            </t>
            <ul spacing="normal">
              <li>
                <xref target="TIME" />: format="default"/>: Based on Section 5.1 of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="5.1"/>.</li>
              <li>
                <xref target="OFFON" />: format="default"/>: Based on Section 5.2 of RFC 3272.</t> <xref
                target="RFC3272" sectionFormat="of" section="5.2"/>.</li>
              <li>
                <t><xref target="CENTRAL" />: format="default"/>: Based on Section 5.3 of RFC 3272.
              <list style="symbols">
                 <t><xref <xref
                target="RFC3272" sectionFormat="of" section="5.3"/>.
                </t>
                <ul spacing="normal">
                  <li>
                    <xref target="HYBRID" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="SDN" />: format="default"/>: New for this document.</t>
              </list></t>
              <t><xref document.</li>
                </ul>
              </li>
              <li>
                <xref target="LOCAL" />: format="default"/>: Based on Section 5.4 of RFC 3272.</t> <xref
                target="RFC3272" sectionFormat="of" section="5.4"/>.</li>
              <li>
                <t><xref target="SCRIPT" />: format="default"/>: Based on Section 5.5 of RFC 3272.
              <list style="symbols">
                 <t><xref <xref
                target="RFC3272" sectionFormat="of" section="5.5"/>.
                </t>
                <ul spacing="normal">
                  <li>
                    <xref target="INTENT" />: format="default"/>: New for this document.</t>
              </list></t>
              <t><xref document.</li>
                </ul>
              </li>
              <li>
                <xref target="LOOP" />: format="default"/>: Based on Section 5.6 of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="5.6"/>.</li>
              <li>
                <xref target="TACTIC" />: format="default"/>: Based on Section 5.7 of RFC 3272.</t>
           </list></t> <xref
                target="RFC3272" sectionFormat="of" section="5.7"/>.</li>
            </ul>
          </li>
          <li>
            <t><xref target="REVIEW" />: format="default"/>: Based on Section 4 of RFC 3272.
           <list style="symbols"> <xref
            target="RFC3272" sectionFormat="of" section="4"/>.
            </t>
            <ul spacing="normal">
              <li>
                <t><xref target="OTHER" />: format="default"/>: Based on Section 4.5 of RFC 3272.
              <list style="symbols">
                 <t><xref <xref
                target="RFC3272" sectionFormat="of" section="4.5"/>.
                </t>
                <ul spacing="normal">
                  <li>
                    <xref target="INTSERV" />: format="default"/>: Based on Section 4.5.1 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="4.5.1"/>.</li>
                  <li>
                    <xref target="DIFFSERV" />: format="default"/>: Based on Section 4.5.3 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="4.5.3"/>.</li>
                  <li>
                    <xref target="SRPolicy" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="QUIC" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="DETNET" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="ALTO" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="ACTN" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="SLICE" />: format="default"/>: New for this document.</t> document.</li>
                  <li>
                    <t><xref target="CSPF" />: format="default"/>: Based on Section 4.4 of RFC 3272.
                 <list style="symbols">
                    <t><xref <xref
                    target="RFC3272" sectionFormat="of" section="4.4"/>.
                    </t>
                    <ul spacing="normal">
                      <li>
                        <xref target="FLEX" />: format="default"/>: New for this document.</t>
                 </list></t>
                 <t><xref document.</li>
                    </ul>
                  </li>
                  <li>
                    <xref target="RSVP" />: format="default"/>: Based on Section 4.5.2 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="4.5.2"/>.</li>
                  <li>
                    <xref target="MPLS" />: format="default"/>: Based on Section 4.5.4 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="4.5.4"/>.</li>
                  <li>
                    <xref target="RSVP-TE" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="GMPLS" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="IPPM" />: format="default"/>: Based on Section 4.5.5 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="4.5.5"/>.</li>
                  <li>
                    <xref target="RTFM" />: format="default"/>: Based on Section 4.5.6 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="4.5.6"/>.</li>
                  <li>
                    <xref target="ECM" />: format="default"/>: Based on Section 4.5.7 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="4.5.7"/>.</li>
                  <li>
                    <xref target="IGPTE" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="BGPLS" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="PCE" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="SR" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="BIER-TE" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="STATE" />: format="default"/>: New for this document.</t>
                 <t><xref document.</li>
                  <li>
                    <xref target="SYSMAN" />: format="default"/>: New for this document.</t>
              </list></t>
              <t><xref document.</li>
                </ul>
              </li>
              <li>
                <xref target="CDN" />: format="default"/>: Based on Section 4.7 of RFC 3272.</t>
           </list></t> <xref
                target="RFC3272" sectionFormat="of" section="4.7"/>.</li>
            </ul>
          </li>
          <li>
            <t><xref target="RECO" />: format="default"/>: Based on Section 6 of RFC 3272.
           <list style="symbols">
              <t><xref <xref
            target="RFC3272" sectionFormat="of" section="6"/>.
            </t>
            <ul spacing="normal">
              <li>
                <xref target="HIGHOBJ" />: format="default"/>: Based on Section 6.1 of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="6.1"/>.</li>
              <li>
                <xref target="ROUTEREC" />: format="default"/>: Based on Section 6.2 of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="6.2"/>.</li>
              <li>
                <xref target="MAPREC" />: format="default"/>: Based on Section 6.3 of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="6.3"/>.</li>
              <li>
                <xref target="MSRREC" />: format="default"/>: Based on Section 6.4 of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="6.4"/>.</li>
              <li>
                <xref target="POLICE" />: format="default"/>: New for this document.</t> document.</li>
              <li>
                <t><xref target="SURVIVE" />: format="default"/>: Based on Section 6.5 of RFC 3272.
              <list style="symbols">
                 <t><xref <xref
                target="RFC3272" sectionFormat="of" section="6.5"/>.
                </t>
                <ul spacing="normal">
                  <li>
                    <xref target="SRVMPLS" />: format="default"/>: Based on Section 6.5.1 of RFC 3272.</t>
                 <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="6.5.1"/>.</li>
                  <li>
                    <xref target="PROTECT" />: format="default"/>: Based on Section 6.5.2 of RFC 3272.</t>
              </list></t>
              <t><xref <xref
                    target="RFC3272" sectionFormat="of"
                    section="6.5.2"/>.</li>
                </ul>
              </li>
              <li>
                <xref target="ML" />: format="default"/>: New for this document.</t>
              <t><xref document.</li>
              <li>
                <xref target="TEDIFFSRV" />: format="default"/>: Based on Section 6.6. of RFC 3272.</t>
              <t><xref <xref
                target="RFC3272" sectionFormat="of" section="6.6"/>.</li>
              <li>
                <xref target="CONTROL" />: format="default"/>: Based on Section 6.7 of RFC 3272.</t>
           </list></t>

        <t><xref <xref
                target="RFC3272" sectionFormat="of" section="6.7"/>.</li>
            </ul>
          </li>
          <li>
            <xref target="INTER" />: format="default"/>: Based on Section 7 of RFC 3272.</t>

        <t><xref <xref
            target="RFC3272" sectionFormat="of" section="7"/>.</li>
          <li>
            <xref target="PRACTICE" />: format="default"/>: Based on Section 8 of RFC 3272.</t>

        <t><xref <xref
            target="RFC3272" sectionFormat="of" section="8"/>.</li>
          <li>
            <xref target="SECURE" />: format="default"/>: Based on Section 10 <xref
            target="RFC3272" sectionFormat="of" section="10"/>.</li>
        </ul>
      </section>
    </section>

    <section anchor="ACKN" numbered="false" toc="default">
      <name>Acknowledgments</name>

      <t>Much of RFC 3272.</t>

     </list></t> the text in this document is derived from <xref
      target="RFC3272" format="default"/>.  The editor and contributors to
      this document would like to express their gratitude to all involved in
      that work.  Although the source text has been edited in the production
      of this document, the original authors should be considered as
      contributors to this work.  They were:</t>

      <contact fullname="Daniel O. Awduche">
        <organization>Movaz Networks</organization>
      </contact>

      <contact fullname="Angela Chiu">
        <organization>Celion Networks</organization>
      </contact>

      <contact fullname="Anwar Elwalid">
        <organization>Lucent Technologies</organization>
      </contact>

      <contact fullname="Indra Widjaja">
        <organization>Bell Labs, Lucent Technologies</organization>
      </contact>

      <contact fullname="XiPeng Xiao">
        <organization>Redback Networks</organization>
      </contact>

      <t>The acknowledgements in <xref target="RFC3272" format="default"/>
      were as below.  All people who helped in the production of that document
      also need to be thanked for the carry-over into this new document.</t>

      <blockquote><t>The authors would like to thank <contact fullname="Jim
      Boyle"/> for inputs on the recommendations section, <contact
      fullname="Francois Le Faucheur"/> for inputs on Diffserv aspects,
      <contact fullname="Blaine Christian"/> for inputs on measurement,
      <contact fullname="Gerald Ash"/> for inputs on routing in telephone
      networks and for text on event-dependent TE methods, <contact
      fullname="Steven Wright"/> for inputs on network controllability, and
      <contact fullname="Jonathan Aufderheide"/> for inputs on inter-domain TE
      with BGP.  Special thanks to <contact fullname="Randy Bush"/> for
      proposing the TE taxonomy based on "tactical vs strategic" methods.  The
      subsection describing an "Overview of ITU Activities Related to Traffic
      Engineering" was adapted from a contribution by <contact
      fullname="Waisum Lai"/>.  Useful feedback and pointers to relevant
      materials were provided by <contact fullname="J. Noel Chiappa"/>.
      Additional comments were provided by <contact fullname="Glenn
      Grotefeld"/> during the working last call process.  Finally, the authors
      would like to thank <contact fullname="Ed Kern"/>, the TEWG co-chair,
      for his comments and support.</t></blockquote>

      <t>The early draft versions of this document were produced by the TEAS Working
      Group's RFC3272bis Design Team.  The full list of members of this team
      is:</t>
      <ul empty="true" spacing="compact" bare="false" indent="3">
	<li><t><contact fullname="Acee Lindem"/></t></li>
	<li><t><contact fullname="Adrian Farrel"/></t></li>
	<li><t><contact fullname="Aijun Wang"/></t></li>
	<li><t><contact fullname="Daniele Ceccarelli"/></t></li>
	<li><t><contact fullname="Dieter Beller"/></t></li>
	<li><t><contact fullname="Jeff Tantsura"/></t></li>
	<li><t><contact fullname="Julien Meuric"/></t></li>
	<li><t><contact fullname="Liu Hua"/></t></li>
	<li><t><contact fullname="Loa Andersson"/></t></li>
	<li><t><contact fullname="Luis Miguel Contreras"/></t></li>
	<li><t><contact fullname="Martin Horneffer"/></t></li>
	<li><t><contact fullname="Tarek Saad"/></t></li>
	<li><t><contact fullname="Xufeng Liu"/></t></li>
      </ul>
      <t>The production of this document includes a fix to the original text
      resulting from an errata report #309 <xref target="Err309"/> by <contact fullname="Jean-Michel
      Grimaldi"/>.</t>
      <t>The editor of this document would also like to thank <contact
      fullname="Dhruv Dhody"/>, <contact fullname="Gyan Mishra"/>, <contact
      fullname="Joel Halpern"/>, <contact fullname="Dave Taht"/>, <contact
      fullname="John Scudder"/>, <contact fullname="Rich Salz"/>, <contact
      fullname="Behcet Sarikaya"/>, <contact fullname="Bob Briscoe"/>,
      <contact fullname="Erik Kline"/>, <contact fullname="Jim Guichard"/>,
      <contact fullname="Martin Duke"/>, and <contact fullname="Roman
      Danyliw"/> for review comments.</t>
      <t>This work is partially supported by the European Commission under
      Horizon 2020 grant agreement number 101015857 Secured autonomic traffic
      management for a Tera of SDN flows (Teraflow).</t>
    </section>

    <section anchor="CONTRIB" numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people contributed substantive text to this
      document:</t>

      <contact fullname="Gert Grammel">
        <address>
          <email>ggrammel@juniper.net</email>
        </address>
      </contact>

      <contact fullname="Loa Andersson">
        <address>
          <email>loa@pi.nu</email>
        </address>
      </contact>

      <contact fullname="Xufeng Liu">
        <address>
          <email>xufeng.liu.ietf@gmail.com</email>
        </address>
      </contact>

      <contact fullname="Lou Berger">
        <address>
          <email>lberger@labn.net</email>
        </address>
      </contact>

      <contact fullname="Jeff Tantsura">
        <address>
          <email>jefftant.ietf@gmail.com</email>
        </address>
      </contact>

      <contact fullname="Daniel King">
        <address>
          <email>daniel@olddog.co.uk</email>
        </address>
      </contact>

      <contact fullname="Boris Hassanov">
        <address>
          <email>bhassanov@yandex-team.ru</email>
        </address>
      </contact>

      <contact fullname="Kiran Makhijani">
        <address>
          <email>kiranm@futurewei.com</email>
        </address>
      </contact>

      <contact fullname="Dhruv Dhody">
        <address>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </contact>

      <contact fullname="Mohamed Boucadair">
        <address>
          <email>mohamed.boucadair@orange.com</email>
        </address>
      </contact>

    </section>

  </back>
</rfc>