< draft-ietf-teas-rfc3272bis-01.txt   draft-ietf-teas-rfc3272bis-02.txt >
TEAS Working Group A. Farrel, Ed. TEAS Working Group A. Farrel, Ed.
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Obsoletes: 3272 (if approved) July 13, 2020 Obsoletes: 3272 (if approved) November 2, 2020
Intended status: Informational Intended status: Informational
Expires: January 14, 2021 Expires: May 6, 2021
Overview and Principles of Internet Traffic Engineering Overview and Principles of Internet Traffic Engineering
draft-ietf-teas-rfc3272bis-01 draft-ietf-teas-rfc3272bis-02
Abstract Abstract
This document describes the principles of Traffic Engineering (TE) in This document describes the principles of traffic engineering (TE) in
the Internet. The document is intended to promote better the Internet. The document is intended to promote better
understanding of the issues surrounding traffic engineering in IP understanding of the issues surrounding traffic engineering in IP
networks and the networks that support IP networking, and to provide networks and the networks that support IP networking, and to provide
a common basis for the development of traffic engineering a common basis for the development of traffic engineering
capabilities for the Internet. The principles, architectures, and capabilities for the Internet. The principles, architectures, and
methodologies for performance evaluation and performance optimization methodologies for performance evaluation and performance optimization
of operational networks are discussed throughout this document. of operational networks are also discussed.
This work was first published as RFC 3272 in May 2002. This document 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 obsoletes RFC 3272 by making a complete update to bring the text in
line with best current practices for Internet traffic engineering and line with best current practices for Internet traffic engineering and
to include references to the latest relevant work in the IETF. to include references to the latest relevant work in the IETF.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What is Internet Traffic Engineering? . . . . . . . . . . 4 1.1. What is Internet Traffic Engineering? . . . . . . . . . . 4
1.2. Components of Traffic Engineering . . . . . . . . . . . . 7 1.2. Components of Traffic Engineering . . . . . . . . . . . . 6
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Context of Internet Traffic Engineering . . . . . . . . . 12 2.1. Context of Internet Traffic Engineering . . . . . . . . . 11
2.2. Network Context . . . . . . . . . . . . . . . . . . . . . 13 2.2. Network Domain Context . . . . . . . . . . . . . . . . . 12
2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 15 2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 14
2.3.1. Congestion and its Ramifications . . . . . . . . . . 16 2.3.1. Congestion and its Ramifications . . . . . . . . . . 15
2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 17 2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 15
2.4.1. Combating the Congestion Problem . . . . . . . . . . 19 2.4.1. Combating the Congestion Problem . . . . . . . . . . 17
2.5. Implementation and Operational Context . . . . . . . . . 22 2.5. Implementation and Operational Context . . . . . . . . . 21
3. Traffic Engineering Process Models . . . . . . . . . . . . . 23 3. Traffic Engineering Process Models . . . . . . . . . . . . . 21
3.1. Components of the Traffic Engineering Process Model . . . 23 3.1. Components of the Traffic Engineering Process Model . . . 22
4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 24 4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 22
4.1. Overview of IETF Projects Related to Traffic Engineering 24 4.1. Overview of IETF Projects Related to Traffic Engineering 23
4.1.1. Constraint-Based Routing . . . . . . . . . . . . . . 24 4.1.1. Constraint-Based Routing . . . . . . . . . . . . . . 23
4.1.2. Integrated Services . . . . . . . . . . . . . . . . . 25 4.1.2. Integrated Services . . . . . . . . . . . . . . . . . 23
4.1.3. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1.3. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. Differentiated Services . . . . . . . . . . . . . . . 27 4.1.4. Differentiated Services . . . . . . . . . . . . . . . 25
4.1.5. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.5. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.6. Generalized MPLS . . . . . . . . . . . . . . . . . . 28 4.1.6. Generalized MPLS . . . . . . . . . . . . . . . . . . 27
4.1.7. IP Performance Metrics . . . . . . . . . . . . . . . 29 4.1.7. IP Performance Metrics . . . . . . . . . . . . . . . 27
4.1.8. Flow Measurement . . . . . . . . . . . . . . . . . . 29 4.1.8. Flow Measurement . . . . . . . . . . . . . . . . . . 28
4.1.9. Endpoint Congestion Management . . . . . . . . . . . 30 4.1.9. Endpoint Congestion Management . . . . . . . . . . . 28
4.1.10. TE Extensions to the IGPs . . . . . . . . . . . . . . 30 4.1.10. TE Extensions to the IGPs . . . . . . . . . . . . . . 29
4.1.11. Link-State BGP . . . . . . . . . . . . . . . . . . . 30 4.1.11. Link-State BGP . . . . . . . . . . . . . . . . . . . 29
4.1.12. Path Computation Element . . . . . . . . . . . . . . 31 4.1.12. Path Computation Element . . . . . . . . . . . . . . 29
4.1.13. Application-Layer Traffic Optimization . . . . . . . 31 4.1.13. Application-Layer Traffic Optimization . . . . . . . 30
4.1.14. Segment Routing with MPLS encapsuation (SR-MPLS) . . 32 4.1.14. Segment Routing with MPLS encapsuation (SR-MPLS) . . 30
4.1.15. Network Virtualization and Abstraction . . . . . . . 33 4.1.15. Network Virtualization and Abstraction . . . . . . . 31
4.1.16. Deterministic Networking . . . . . . . . . . . . . . 34 4.1.16. Deterministic Networking . . . . . . . . . . . . . . 32
4.1.17. Network TE State Definition and Presentation . . . . 34 4.1.17. Network TE State Definition and Presentation . . . . 32
4.1.18. System Management and Control Interfaces . . . . . . 34 4.1.18. System Management and Control Interfaces . . . . . . 32
4.2. Content Distribution . . . . . . . . . . . . . . . . . . 34 4.2. Content Distribution . . . . . . . . . . . . . . . . . . 33
5. Taxonomy of Traffic Engineering Systems . . . . . . . . . . . 35 5. Taxonomy of Traffic Engineering Systems . . . . . . . . . . . 33
5.1. Time-Dependent Versus State-Dependent Versus Event 5.1. Time-Dependent Versus State-Dependent Versus Event
Dependent . . . . . . . . . . . . . . . . . . . . . . . . 36 Dependent . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 37 5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 35
5.3. Centralized Versus Distributed . . . . . . . . . . . . . 37 5.3. Centralized Versus Distributed . . . . . . . . . . . . . 36
5.3.1. Hybrid Systems . . . . . . . . . . . . . . . . . . . 38 5.3.1. Hybrid Systems . . . . . . . . . . . . . . . . . . . 36
5.3.2. Considerations for Software Defined Networking . . . 38 5.3.2. Considerations for Software Defined Networking . . . 36
5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 38 5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 36
5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 38 5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 37
5.5.1. Intent-Based Networking . . . . . . . . . . . . . . . 39 5.5.1. Intent-Based Networking . . . . . . . . . . . . . . . 37
5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 39 5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 37
5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 39 5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 37
6. Recommendations for Internet Traffic Engineering . . . . . . 39 6. Recommendations for Internet Traffic Engineering . . . . . . 38
6.1. Generic Non-functional Recommendations . . . . . . . . . 40 6.1. Generic Non-functional Recommendations . . . . . . . . . 38
6.2. Routing Recommendations . . . . . . . . . . . . . . . . . 42 6.2. Routing Recommendations . . . . . . . . . . . . . . . . . 40
6.3. Traffic Mapping Recommendations . . . . . . . . . . . . . 44 6.3. Traffic Mapping Recommendations . . . . . . . . . . . . . 43
6.4. Measurement Recommendations . . . . . . . . . . . . . . . 45 6.4. Measurement Recommendations . . . . . . . . . . . . . . . 43
6.5. Network Survivability . . . . . . . . . . . . . . . . . . 46 6.5. Network Survivability . . . . . . . . . . . . . . . . . . 44
6.5.1. Survivability in MPLS Based Networks . . . . . . . . 48 6.5.1. Survivability in MPLS Based Networks . . . . . . . . 46
6.5.2. Protection Option . . . . . . . . . . . . . . . . . . 49 6.5.2. Protection Option . . . . . . . . . . . . . . . . . . 48
6.6. Traffic Engineering in Diffserv Environments . . . . . . 50 6.6. Traffic Engineering in Diffserv Environments . . . . . . 48
6.7. Network Controllability . . . . . . . . . . . . . . . . . 52 6.7. Network Controllability . . . . . . . . . . . . . . . . . 50
7. Inter-Domain Considerations . . . . . . . . . . . . . . . . . 53 7. Inter-Domain Considerations . . . . . . . . . . . . . . . . . 51
8. Overview of Contemporary TE Practices in Operational IP 8. Overview of Contemporary TE Practices in Operational IP
Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 59 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 57
10. Security Considerations . . . . . . . . . . . . . . . . . . . 59 10. Security Considerations . . . . . . . . . . . . . . . . . . . 58
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 61 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 60
14. Informative References . . . . . . . . . . . . . . . . . . . 62 14. Informative References . . . . . . . . . . . . . . . . . . . 61
Appendix A. Historic Overview . . . . . . . . . . . . . . . . . 71 Appendix A. Historic Overview . . . . . . . . . . . . . . . . . 70
A.1. Traffic Engineering in Classical Telephone Networks . . . 71 A.1. Traffic Engineering in Classical Telephone Networks . . . 70
A.2. Evolution of Traffic Engineering in Packet Networks . . . 72 A.2. Evolution of Traffic Engineering in Packet Networks . . . 71
A.2.1. Adaptive Routing in the ARPANET . . . . . . . . . . . 73 A.2.1. Adaptive Routing in the ARPANET . . . . . . . . . . . 72
A.2.2. Dynamic Routing in the Internet . . . . . . . . . . . 73 A.2.2. Dynamic Routing in the Internet . . . . . . . . . . . 72
A.2.3. ToS Routing . . . . . . . . . . . . . . . . . . . . . 74 A.2.3. ToS Routing . . . . . . . . . . . . . . . . . . . . . 73
A.2.4. Equal Cost Multi-Path . . . . . . . . . . . . . . . . 74 A.2.4. Equal Cost Multi-Path . . . . . . . . . . . . . . . . 73
A.2.5. Nimrod . . . . . . . . . . . . . . . . . . . . . . . 75 A.2.5. Nimrod . . . . . . . . . . . . . . . . . . . . . . . 74
A.3. Development of Internet Traffic Engineering . . . . . . . 75 A.3. Development of Internet Traffic Engineering . . . . . . . 74
A.3.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 75 A.3.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 74
Appendix B. Overview of Traffic Engineering Related Work in Appendix B. Overview of Traffic Engineering Related Work in
Other SDOs . . . . . . . . . . . . . . . . . . . . . 76 Other SDOs . . . . . . . . . . . . . . . . . . . . . 75
B.1. Overview of ITU Activities Related to Traffic Engineering 76 B.1. Overview of ITU Activities Related to Traffic Engineering 75
Appendix C. Summary of Changes Since RFC 3272 . . . . . . . . . 77 Appendix C. Summary of Changes Since RFC 3272 . . . . . . . . . 76
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
This memo describes the principles of Internet traffic engineering. This document describes the principles of Internet traffic
The objective of the document is to articulate the general issues and engineering (TE). The objective of the document is to articulate the
principles for Internet traffic engineering; and where appropriate to general issues and principles for Internet traffic engineering, and
provide recommendations, guidelines, and options for the development where appropriate to provide recommendations, guidelines, and options
of online and offline Internet traffic engineering capabilities and for the development of online and offline Internet traffic
support systems. engineering capabilities and support systems.
This document can aid service providers in devising and implementing
traffic engineering solutions for their networks. Networking
hardware and software vendors will also find this document helpful in
the development of mechanisms and support systems for the Internet
environment that support the traffic engineering function.
This document provides a terminology for describing and understanding This document provides a terminology and taxonomy for describing and
common Internet traffic engineering concepts. This document also understanding common Internet traffic engineering concepts.
provides a taxonomy of known traffic engineering styles. In this
context, a traffic engineering style abstracts important aspects from
a traffic engineering methodology. Traffic engineering styles can be
viewed in different ways depending upon the specific context in which
they are used and the specific purpose which they serve. The
combination of styles and views results in a natural taxonomy of
traffic engineering systems.
Even though Internet traffic engineering is most effective when Even though Internet traffic engineering is most effective when
applied end-to-end, the focus of this document is traffic engineering applied end-to-end, the focus of this document is traffic engineering
within a given domain (such as an autonomous system). However, within a given domain (such as an autonomous system). However,
because a preponderance of Internet traffic tends to originate in one because a preponderance of Internet traffic tends to originate in one
autonomous system and terminate in another, this document provides an autonomous system and terminate in another, this document also
overview of aspects pertaining to inter-domain traffic engineering. provides an overview of aspects pertaining to inter-domain traffic
engineering.
This work was first published as [RFC3272] in May 2002. This This work was first published as [RFC3272] in May 2002. This
document obsoletes [RFC3272] by making a complete update to bring the document obsoletes [RFC3272] by making a complete update to bring the
text in line with best current practices for Internet traffic text in line with best current practices for Internet traffic
engineering and to include references to the latest relevant work in engineering and to include references to the latest relevant work in
the IETF. It is worth noting around three fifths of the RFCs the IETF. It is worth noting around three fifths of the RFCs
referenced in this document post-date the publication of RFC 3272. referenced in this document post-date the publication of RFC 3272.
Appendix C provides a summary of changes between RFC 3272 and this Appendix C provides a summary of changes between RFC 3272 and this
document. document.
1.1. What is Internet Traffic Engineering? 1.1. What is Internet Traffic Engineering?
The Internet exists in order to transfer information from source One of the most significant functions performed by the Internet is
nodes to destination nodes. Accordingly, one of the most significant the routing of traffic from ingress nodes to egress nodes.
functions performed by the Internet is the routing of traffic from Therefore, one of the most distinctive functions performed by
ingress nodes to egress nodes. Therefore, one of the most Internet traffic engineering is the control and optimization of the
distinctive functions performed by Internet traffic engineering is routing function, to steer traffic through the network.
the control and optimization of the routing function, to steer
traffic through the network.
Internet traffic engineering is defined as that aspect of Internet Internet traffic engineering is defined as that aspect of Internet
network engineering dealing with the issue of performance evaluation network engineering dealing with the issues of performance evaluation
and performance optimization of operational IP networks. Traffic and performance optimization of operational IP networks. Traffic
Engineering encompasses the application of technology and scientific engineering encompasses the application of technology and scientific
principles to the measurement, characterization, modeling, and principles to the measurement, characterization, modeling, and
control of Internet traffic [RFC2702], [AWD2]. control of Internet traffic [RFC2702], [AWD2].
Ultimately, it is the performance of the network as seen by end users It is the performance of the network as seen by end users of network
of network services that is truly paramount. The characteristics services that is paramount. The characteristics visible to end users
visible to end users are the emergent properties of the network, are the emergent properties of the network, which are the
which are the characteristics of the network when viewed as a whole. characteristics of the network when viewed as a whole. A central
A central goal of the service provider, therefore, is to enhance the goal of the service provider, therefore, is to enhance the emergent
emergent properties of the network while taking economic properties of the network while taking economic considerations into
considerations into account. This is accomplished by addressing account. This is accomplished by addressing traffic oriented
traffic oriented performance requirements, while utilizing network performance requirements while utilizing network resources
resources economically and reliably. Traffic oriented performance economically and reliably. Traffic oriented performance measures
measures include delay, delay variation, packet loss, and throughput. include delay, delay variation, packet loss, and throughput.
Internet traffic engineering responds to network events. Aspects of Internet traffic engineering responds to network events. Aspects of
capacity management respond at intervals ranging from days to years. capacity management respond at intervals ranging from days to years.
Routing control functions operate at intervals ranging from Routing control functions operate at intervals ranging from
milliseconds to days. Packet level processing functions operate at milliseconds to days. Packet level processing functions operate at
very fine levels of temporal resolution, ranging from picoseconds to very fine levels of temporal resolution, ranging from picoseconds to
milliseconds while responding to the real-time statistical behavior milliseconds while reacting to the real-time statistical behavior of
of traffic. traffic.
Thus, the optimization aspects of traffic engineering can be viewed Thus, the optimization aspects of traffic engineering can be viewed
from a control perspective and can be pro-active and/or reactive. In from a control perspective, and can be both pro-active and reactive.
the pro-active case, the traffic engineering control system takes In the pro-active case, the traffic engineering control system takes
preventive action to obviate predicted unfavorable future network preventive action to protect against predicted unfavorable future
states such as e.g. engineering a backup path. It may also take network states, for example, by engineering backup paths. It may
perfective action to induce a more desirable state in the future. In also take action that will lead to a more desirable future network
the reactive case, the control system responds correctively and state. In the reactive case, the control system responds to correct
perhaps adaptively to events that have already transpired in the issues and adapt to network events, such as routing after failure.
network, such as routing after failure.
Another important objective of Internet traffic engineering is to Another important objective of Internet traffic engineering is to
facilitate reliable network operations [RFC2702]. Reliable network facilitate reliable network operations [RFC2702]. Reliable network
operations can be facilitated by providing mechanisms that enhance operations can be facilitated by providing mechanisms that enhance
network integrity and by embracing policies emphasizing network network integrity and by embracing policies emphasizing network
survivability. This results in a minimization of the vulnerability survivability. This reduces the vulnerability of services to outages
of the network to service outages arising from errors, faults, and arising from errors, faults, and failures occurring within the
failures occurring within the infrastructure. network infrastructure.
The optimization aspects of traffic engineering can be achieved The optimization aspects of traffic engineering can be achieved
through capacity management and traffic management. As used in this through capacity management and traffic management. In this
document, capacity management includes capacity planning, routing document, capacity management includes capacity planning, routing
control, and resource management. Network resources of particular control, and resource management. Network resources of particular
interest include link bandwidth, buffer space, and computational interest include link bandwidth, buffer space, and computational
resources. Likewise, as used in this document, traffic management resources. In this document, traffic management includes:
includes (1) nodal traffic control functions such as traffic
conditioning, queue management, scheduling, and (2) other functions 1. nodal traffic control functions such as traffic conditioning,
that regulate traffic flow through the network or that arbitrate queue management, scheduling
access to network resources between different packets or between
different traffic streams. 2. other functions that regulate traffic flow through the network or
that arbitrate access to network resources between different
packets or between different traffic streams.
One major challenge of Internet traffic engineering is the One major challenge of Internet traffic engineering is the
realization of automated control capabilities that adapt quickly and realization of automated control capabilities that adapt quickly and
cost effectively to significant changes in a network's state, while cost effectively to significant changes in network state, while still
still maintaining stability of the network. Results from performance maintaining stability of the network. Performance evaluation can
evaluation assessing the effectiveness of traffic engineering methods assess the effectiveness of traffic engineering methods, and the
can be used to identify existing problems, guide network re- results of this evaluation can be used to identify existing problems,
optimization, and aid in the prediction of potential future problems. guide network re-optimization, and aid in the prediction of potential
However this process can also be time consuming and may not be future problems. However, this process can also be time consuming
suitable to act on sudden, ephemeral changes in the network. and may not be suitable to act on short-lived changes in the network.
Performance evaluation can be achieved in many different ways. The Performance evaluation can be achieved in many different ways. The
most notable techniques include analytical methods, simulation, and most notable techniques include analytical methods, simulation, and
empirical methods based on measurements. empirical methods based on measurements.
In genaral, traffic engineering comes in two flavors. Either as a Traffic engineering comes in two flavors: either a background process
background process that constantly monitors traffic and optimize the that constantly monitors traffic and optimizes the use of resources
usage of resources to improve performance, or in form of a pre- to improve performance; or a form of a pre-planned optimized traffic
planned optimized traffic distribution that is considered optimal. distribution that is considered optimal. In the later case, any
In the later case, any deviation from the optimum distribution (e.g., deviation from the optimum distribution (e.g., caused by a fiber cut)
caused by a fiber cut) is reverted upon repair without further is reverted upon repair without further optimization. However, this
optimization. However, this form of traffic engineering heavily form of traffic engineering relies upon the notion that the planned
relies upon the notion that the planned state of the network is state of the network is optimal. Hence, in such a mode there are two
indeed optimal. Hence, in such a mode there are two levels of levels of traffic engineering: the TE-planning task to enable optimum
traffic engineering: the TE-planning task to enable an optimum
traffic distribution, and the routing task keeping traffic flows traffic distribution, and the routing task keeping traffic flows
attached to the pre-planned distribution attached to the pre-planned distribution.
As a general rule, traffic engineering concepts and mechanisms must As a general rule, traffic engineering concepts and mechanisms must
be sufficiently specific and well-defined to address known be sufficiently specific and well-defined to address known
requirements, but simultaneously flexible and extensible to requirements, but simultaneously flexible and extensible to
accommodate unforeseen future demands. accommodate unforeseen future demands.
1.2. Components of Traffic Engineering 1.2. Components of Traffic Engineering
As mentioned in Section 1.1, Internet Traffic Engineering provides As mentioned in Section 1.1, Internet traffic engineering provides
performance optimization of operational IP networks while utilizing performance optimization of operational IP networks while utilizing
network resources economically and reliably. Such optimization is network resources economically and reliably. Such optimization is
supported at the control/controller level and within the data/ supported at the control/controller level and within the data/
forwarding plane. forwarding plane.
The key elements required in any TE solution are as follows. Some TE The key elements required in any TE solution are as follows:
solutions rely on these elements to a lesser or greater extent.
Debate remains about whether a solution can truly be called Traffic
Engineering that 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.
1. Policy 1. Policy
2. Path steering 2. Path steering
3. Resource management 3. Resource management
Some TE solutions rely on these elements to a lesser or greater
extent. Debate remains about whether a solution can truly be called
traffic engineering 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.
Policy allows for the selection of next hops and paths based on Policy allows for the selection of next hops and paths based on
information beyond basic reachability. Early definitions of routing information beyond basic reachability. Early definitions of routing
policy, e.g., [RFC1102] and [RFC1104], discuss routing policy being policy, e.g., [RFC1102] and [RFC1104], discuss routing policy being
applied to restrict access to network resources at an aggregate applied to restrict access to network resources at an aggregate
level. BGP is an example of a commonly used mechanism for applying level. BGP is an example of a commonly used mechanism for applying
such policies, see [RFC4271] and [RFC5575]. In the Traffic such policies, see [RFC4271] and [I-D.ietf-idr-rfc5575bis]. In the
Engineering context, policy decisions are made within the control traffic engineering context, policy decisions are made within the
plane or by controllers, and govern the selection of paths. Examples control plane or by controllers, and govern the selection of paths.
of such can be found in [RFC4655] and [RFC5394]. Standard TE Examples can be found in [RFC4655] and [RFC5394]. Standard TE
solutions may cover the mechanisms to distribute and/or enforce solutions may cover the mechanisms to distribute and/or enforce
polices, but specific policy definition is generally unspecified. polices, but specific policy definition is generally unspecified.
Path steering is the ability to forward packets using information Path steering is the ability to forward packets using more
beyond the next hop. Examples of path steering include IPv4 source information than just knowledge of the next hop. Examples of path
routes [RFC0791], RSVP-TE explicit routes [RFC3209], and Segment steering include IPv4 source routes [RFC0791], RSVP-TE explicit
Routing [RFC8402]. Path steering for TE can be supported via control routes [RFC3209], and Segment Routing [RFC8402]. Path steering for
plane protocols or by encoding in the data plane headers or any TE can be supported via control plane protocols, by encoding in the
combination of the two. This includes when control is provided via a data plane headers, or by a combination of the two. This includes
controller and some southbound, i.e., controller to router, control when control is provided by a controller using a southbound (i.e.,
protocol. controller to router) control protocol.
Resource management provides resource aware control and, in some Resource management provides resource aware control and, in some
cases, forwarding. Examples of resources are bandwidth, buffers and cases, forwarding. Examples of resources are bandwidth, buffers, and
queues, which in turn can be managed to control loss and latency. queues, which in turn can be managed to control loss and latency.
Resources reservation is the control aspect of resource management.
It provides for network domain-wide consensus on which network
(including node and link) resources are to be used by a particular
flow. This determination may be done on a very course or very fine
level. Note that this consensus exists at the network control or
controller level, not the data plane level. It may be purely
composed of accounting/bookkeeping. It typically includes an ability
to admit, reject or reclassify a flow based on policy. Such
accounting can be done based on a static understanding of resource
requirements, or using dynamic mechanisms to collect requirements
(e.g., via [RFC3209]) and resource availability (e.g., via
[RFC4203]), or any combination of the two.
Resource allocation is the data plane aspect of resource management. Resource reservation is the control aspect of resource management.
It provides for the allocation of specific node and link resources to It provides for domain-wide consensus about which network
specific flows. Example resources include buffers, policing and resources are to be used by a particular flow. This determination
rate-shaping mechanisms which are typically supported via queuing. may be done on a very course or very fine level. Note that this
It also includes the matching of a flow, i.e., flow classification, consensus exists at the network control or controller level, not
to a particular set of allocated resources. The method for flow within the data plane. It may be purely composed of accounting/
classification and granularity of resource management is technology bookkeeping, but it typically includes an ability to admit, reject
specific. Examples include DiffServ with dropping and remarking or reclassify a flow based on policy. Such accounting can be done
[RFC4594], MPLS-TE [RFC3209] and GMPLS [RFC3945] based LSPs, and based on a static understanding of resource requirements, or using
controller-based solutions implementing [RFC8453]. This level of dynamic mechanisms to collect requirements (e.g., via [RFC3209])
resource control, while optional, is important in networks that wish and resource availability (e.g., via [RFC4203]), or any
to support congestion management policies to control or regulate the combination of the two.
offered traffic to deliver different levels of service and alleviate
congestion problems, or those networks that wish to control latencies Resource allocation is the data plane aspect of resource
experienced by specific traffic flows. 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 also includes the matching of a flow
(i.e., flow classification) to a particular set of allocated
resources. The method for flow classification and granularity of
resource management is technology specific. Examples include
DiffServ with dropping and remarking [RFC4594], MPLS-TE [RFC3209],
and GMPLS based label switched paths [RFC3945], as well as
controller-based solutions implementing [RFC8453]. 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 networks that
wish to control latencies experienced by specific traffic flows.
1.3. Scope 1.3. Scope
The scope of this document is intra-domain traffic engineering; that The scope of this document is intra-domain traffic engineering. That
is, traffic engineering within a given autonomous system in the is, traffic engineering within a given autonomous system in the
Internet. This document will discuss concepts pertaining to intra- Internet. This document discusses concepts pertaining to intra-
domain traffic control, including such issues as routing control, domain traffic control, including such issues as routing control,
micro and macro resource allocation, and the control coordination micro and macro resource allocation, and the control coordination
problems that arise consequently. problems that arise consequently.
This document describes and characterize techniques already in use or This document describes and characterizes techniques already in use
in advanced development for Internet traffic engineering. The way or in advanced development for Internet traffic engineering. The way
these techniques fit together will be discussed and scenarios in these techniques fit together is discussed and scenarios in which
which they are useful will be identified. they are useful will be identified.
While this document considers various intra-domain traffic
engineering approaches, it focuses more on traffic engineering with
MPLS and GMPLS. Traffic engineering based upon manipulation of IGP
metrics is not addressed in detail. This topic may be addressed by
other working group documents.
Although the emphasis is on intra-domain traffic engineering, in Although the emphasis in this document is on intra-domain traffic
Section 7, an overview of the high level considerations pertaining to engineering, in Section 7, an overview of the high level
inter-domain traffic engineering will be provided. Inter-domain considerations pertaining to inter-domain traffic engineering will be
Internet traffic engineering is crucial to the performance provided. Inter-domain Internet traffic engineering is crucial to
enhancement of the global Internet infrastructure. the performance enhancement of the global Internet infrastructure.
Whenever possible, relevant requirements from existing IETF documents Whenever possible, relevant requirements from existing IETF documents
and other sources will be incorporated by reference. and other sources are incorporated by reference.
1.4. Terminology 1.4. Terminology
This subsection provides terminology which is useful for Internet This section provides terminology which is useful for Internet
traffic engineering. The definitions presented apply to this traffic engineering. The definitions presented apply to this
document. These terms may have other meanings elsewhere. document. These terms may have other meanings elsewhere.
Baseline analysis: A study conducted to serve as a baseline for
comparison to the actual behavior of the network.
Busy hour: A one hour period within a specified interval of time Busy hour: A one hour period within a specified interval of time
(typically 24 hours) in which the traffic load in a network or (typically 24 hours) in which the traffic load in a network or
sub-network is greatest. sub-network is greatest.
Bottleneck: A network element whose input traffic rate tends to be
greater than its output rate.
Congestion: A state of a network resource in which the traffic Congestion: A state of a network resource in which the traffic
incident on the resource exceeds its output capacity over an incident on the resource exceeds its output capacity over an
interval of time. interval of time.
Congestion avoidance: An approach to congestion management that Congestion avoidance: An approach to congestion management that
attempts to obviate the occurrence of congestion. attempts to obviate the occurrence of congestion.
Congestion control: An approach to congestion management that Congestion control: An approach to congestion management that
attempts to remedy congestion problems that have already occurred. attempts to remedy congestion problems that have already occurred.
skipping to change at page 10, line 5 skipping to change at page 9, line 25
well as flows. It is a generalization of QoS routing. well as flows. It is a generalization of QoS routing.
Demand side congestion management: A congestion management scheme Demand side congestion management: A congestion management scheme
that addresses congestion problems by regulating or conditioning that addresses congestion problems by regulating or conditioning
offered load. offered load.
Effective bandwidth: The minimum amount of bandwidth that can be Effective bandwidth: The minimum amount of bandwidth that can be
assigned to a flow or traffic aggregate in order to deliver assigned to a flow or traffic aggregate in order to deliver
'acceptable service quality' to the flow or traffic aggregate. 'acceptable service quality' to the flow or traffic aggregate.
Egress traffic: Traffic exiting a network or network element.
Hot-spot: A network element or subsystem which is in a state of Hot-spot: A network element or subsystem which is in a state of
congestion. congestion.
Ingress traffic: Traffic entering a network or network element.
Inter-domain traffic: Traffic that originates in one Autonomous Inter-domain traffic: Traffic that originates in one Autonomous
system and terminates in another. system and terminates in another.
Loss network: A network that does not provide adequate buffering for
traffic, so that traffic entering a busy resource within the
network will be dropped rather than queued.
Metric: A parameter defined in terms of standard units of Metric: A parameter defined in terms of standard units of
measurement. measurement.
Measurement methodology: A repeatable measurement technique used to Measurement methodology: A repeatable measurement technique used to
derive one or more metrics of interest. derive one or more metrics of interest.
Network survivability: The capability to provide a prescribed level Network survivability: The capability to provide a prescribed level
of QoS for existing services after a given number of failures of QoS for existing services after a given number of failures
occur within the network. occur within the network.
skipping to change at page 10, line 40 skipping to change at page 10, line 5
exists outside of the network. exists outside of the network.
Online traffic engineering: A traffic engineering system that exists Online traffic engineering: A traffic engineering system that exists
within the network, typically implemented on or as adjuncts to within the network, typically implemented on or as adjuncts to
operational network elements. operational network elements.
Performance measures: Metrics that provide quantitative or Performance measures: Metrics that provide quantitative or
qualitative measures of the performance of systems or subsystems qualitative measures of the performance of systems or subsystems
of interest. of interest.
Performance management: A systematic approach to improving
effectiveness in the accomplishment of specific networking goals
related to performance improvement.
Performance metric: A performance parameter defined in terms of Performance metric: A performance parameter defined in terms of
standard units of measurement. standard units of measurement.
Provisioning: The process of assigning or configuring network Provisioning: The process of assigning or configuring network
resources to meet certain requests. resources to meet certain requests.
QoS routing: Class of routing systems that selects paths to be used QoS routing: Class of routing systems that selects paths to be used
by a flow based on the QoS requirements of the flow. by a flow based on the QoS requirements of the flow.
Service Level Agreement (SLA): A contract between a provider and a Service Level Agreement (SLA): A contract between a provider and a
skipping to change at page 11, line 22 skipping to change at page 10, line 31
as a way of avoiding disputes between the two parties based on as a way of avoiding disputes between the two parties based on
misunderstanding. misunderstanding.
Stability: An operational state in which a network does not Stability: An operational state in which a network does not
oscillate in a disruptive manner from one mode to another mode. oscillate in a disruptive manner from one mode to another mode.
Supply-side congestion management: A congestion management scheme Supply-side congestion management: A congestion management scheme
that provisions additional network resources to address existing that provisions additional network resources to address existing
and/or anticipated congestion problems. and/or anticipated congestion problems.
Transit traffic: Traffic whose origin and destination are both
outside of the network under consideration.
Traffic characteristic: A description of the temporal behavior or a Traffic characteristic: A description of the temporal behavior or a
description of the attributes of a given traffic flow or traffic description of the attributes of a given traffic flow or traffic
aggregate. aggregate.
Traffic engineering system: A collection of objects, mechanisms, and Traffic engineering system: A collection of objects, mechanisms, and
protocols that are used conjunctively to accomplish traffic protocols that are used conjunctively to accomplish traffic
engineering objectives. engineering objectives.
Traffic flow: A stream of packets between two end-points that can be Traffic flow: A stream of packets between two end-points that can be
characterized in a certain way. A micro-flow has a more specific characterized in a certain way. A micro-flow has a more specific
definition A micro-flow is a stream of packets with the same definition A micro-flow is a stream of packets with the same
source and destination addresses, source and destination ports, source and destination addresses, source and destination ports,
and protocol ID. and protocol ID.
Traffic intensity: A measure of traffic loading with respect to a
resource capacity over a specified period of time. In classical
telephony systems, traffic intensity is measured in units of
Erlangs.
Traffic matrix: A representation of the traffic demand between a set Traffic matrix: A representation of the traffic demand between a set
of origin and destination abstract nodes. An abstract node can of origin and destination abstract nodes. An abstract node can
consist of one or more network elements. consist of one or more network elements.
Traffic monitoring: The process of observing traffic characteristics Traffic monitoring: The process of observing traffic characteristics
at a given point in a network and collecting the traffic at a given point in a network and collecting the traffic
information for analysis and further action. information for analysis and further action.
Traffic trunk: An aggregation of traffic flows belonging to the same Traffic trunk: An aggregation of traffic flows belonging to the same
class which are forwarded through a common path. A traffic trunk class which are forwarded through a common path. A traffic trunk
may be characterized by an ingress and egress node, and a set of may be characterized by an ingress and egress node, and a set of
attributes which determine its behavioral characteristics and attributes which determine its behavioral characteristics and
requirements from the network. requirements from the network.
2. Background 2. Background
The Internet must convey IP packets from ingress nodes to egress The Internet must convey IP packets from ingress nodes to egress
nodes efficiently, expeditiously, and economically. Furthermore, in nodes efficiently, expeditiously, and economically. Furthermore, in
a multiclass service environment (e.g., Diffserv capable networks), a multiclass service environment (e.g., Diffserv capable networks -
the resource sharing parameters of the network must be appropriately see Section 4.1.4), the resource sharing parameters of the network
determined and configured according to prevailing policies and must be appropriately determined and configured according to
service models to resolve resource contention issues arising from prevailing policies and service models to resolve resource contention
mutual interference between packets traversing through the network. issues arising from mutual interference between packets traversing
Thus, consideration must be given to resolving competition for through the network. Thus, consideration must be given to resolving
network resources between traffic streams belonging to the same competition for network resources between traffic streams belonging
service class (intra-class contention resolution) and traffic streams to the same service class (intra-class contention resolution) and
belonging to different classes (inter-class contention resolution). traffic streams belonging to different classes (inter-class
contention resolution).
2.1. Context of Internet Traffic Engineering 2.1. Context of Internet Traffic Engineering
The context of Internet traffic engineering pertains to the scenarios The context of Internet traffic engineering includes:
where traffic engineering is used. A traffic engineering methodology
establishes appropriate rules to resolve traffic performance issues
occurring in a specific context. The context of Internet traffic
engineering includes:
1. A network context defining the universe of discourse, and in 1. A network domain context that defines the scope under
particular the situations in which the traffic engineering consideration, and in particular the situations in which the
problems occur. The network context includes network structure, traffic engineering problems occur. The network domain context
network policies, network characteristics, network constraints, includes network structure, network policies, network
network quality attributes, and network optimization criteria. characteristics, network constraints, network quality attributes,
and network optimization criteria.
2. A problem context defining the general and concrete issues that 2. A problem context defining the general and concrete issues that
traffic engineering addresses. The problem context includes traffic engineering addresses. The problem context includes
identification, abstraction of relevant features, representation, identification, abstraction of relevant features, representation,
formulation, specification of the requirements on the solution formulation, specification of the requirements on the solution
space, and specification of the desirable features of acceptable space, and specification of the desirable features of acceptable
solutions. solutions.
3. A solution context suggesting how to address the issues 3. A solution context suggesting how to address the issues
identified by the problem context. The solution context includes identified by the problem context. The solution context includes
analysis, evaluation of alternatives, prescription, and analysis, evaluation of alternatives, prescription, and
resolution. resolution.
4. An implementation and operational context in which the solutions 4. An implementation and operational context in which the solutions
are methodologically instantiated. The implementation and are instantiated. The implementation and operational context
operational context includes planning, organization, and includes planning, organization, and execution.
execution.
The context of Internet traffic engineering and the different problem The context of Internet traffic engineering and the different problem
scenarios are discussed in the following subsections. scenarios are discussed in the following subsections.
2.2. Network Context 2.2. Network Domain Context
IP networks range in size from small clusters of routers situated IP networks range in size from small clusters of routers situated
within a given location, to thousands of interconnected routers, within a given location, to thousands of interconnected routers,
switches, and other components distributed all over the world. switches, and other components distributed all over the world.
Conceptually, at the most basic level of abstraction, an IP network At the most basic level of abstraction, an IP network can be
can be represented as a distributed dynamical system consisting of: represented as a distributed dynamic system consisting of:
o a set of interconnected resources which provide transport services o a set of interconnected resources which provide transport services
for IP traffic subject to certain constraints for IP traffic subject to certain constraints
o a demand system representing the offered load to be transported o a demand system representing the offered load to be transported
through the network through the network
o a response system consisting of network processes, protocols, and o a response system consisting of network processes, protocols, and
related mechanisms which facilitate the movement of traffic related mechanisms which facilitate the movement of traffic
through the network (see also [AWD2]). through the network (see also [AWD2]).
The network elements and resources may have specific characteristics The network elements and resources may have specific characteristics
restricting the manner in which the demand is handled. Additionally, restricting the manner in which the traffic demand is handled.
network resources may be equipped with traffic control mechanisms Additionally, network resources may be equipped with traffic control
superintending the way in which the demand is serviced. Traffic mechanisms managing the way in which the demand is serviced. Traffic
control mechanisms may, for example, be used to: control mechanisms may be used to:
o control various packet processing activities within a given o control packet processing activities within a given resource
resource
o arbitrate contention for access to the resource by different o arbitrate contention for access to the resource by different
packets packets
o regulate traffic behavior through the resource. o regulate traffic behavior through the resource.
A configuration management and provisioning system may allow the A configuration management and provisioning system may allow the
settings of the traffic control mechanisms to be manipulated by settings of the traffic control mechanisms to be manipulated by
external or internal entities in order to exercise control over the external or internal entities in order to exercise control over the
way in which the network elements respond to internal and external way in which the network elements respond to internal and external
stimuli. stimuli.
The details of how the network provides transport services for The details of how the network carries packets are specified in the
packets are specified in the policies of the network administrators policies of the network administrators and are installed through
and are installed through network configuration management and policy network configuration management and policy based provisioning
based provisioning systems. Generally, the types of services systems. Generally, the types of service provided by the network
provided by the network also depends upon the technology and also depend upon the technology and characteristics of the network
characteristics of the network elements and protocols, the prevailing elements and protocols, the prevailing service and utility models,
service and utility models, and the ability of the network and the ability of the network administrators to translate policies
administrators to translate policies into network configurations. into network configurations.
Contemporary Internet networks have three significant Internet networks have three significant characteristics:
characteristics:
o they provide real-time services o they provide real-time services
o they have become mission critical o they are mission critical
o their operating environments are very dynamic. o their operating environments are very dynamic.
The dynamic characteristics of IP and IP/MPLS networks can be The dynamic characteristics of IP and IP/MPLS networks can be
attributed in part to fluctuations in demand, to the interaction attributed in part to fluctuations in demand, to the interaction
between various network protocols and processes, to the rapid between various network protocols and processes, to the rapid
evolution of the infrastructure which demands the constant inclusion evolution of the infrastructure which demands the constant inclusion
of new technologies and new network elements, and to transient and of new technologies and new network elements, and to transient and
persistent impairments which occur within the system. persistent faults which occur within the system.
Packets contend for the use of network resources as they are conveyed Packets contend for the use of network resources as they are conveyed
through the network. A network resource is considered to be through the network. A network resource is considered to be
congested if, for an interval of time, the arrival rate of packets congested if, for an interval of time, the arrival rate of packets
exceed the output capacity of the resource. Congestion may result in exceed the output capacity of the resource. Congestion may result in
some of the arrival packets being delayed or even dropped. some of the arriving packets being delayed or even dropped.
Congestion increases transit delays, delay variation, packet loss,
and reduces the predictability of network services. Clearly,
congestion is highly undesirable.
Combating congestion at a reasonable cost is a major objective of Congestion increases transit delay, delay variation, may lead to
Internet traffic engineering. packet loss, and reduces the predictability of network services.
Clearly, congestion is highly undesirable. Combating congestion at a
reasonable cost is a major objective of Internet traffic engineering.
Efficient sharing of network resources by multiple traffic streams is Efficient sharing of network resources by multiple traffic streams is
a basic operatoinal premise for packet switched networks in general a basic operational premise for the Internet. A fundamental
and for the Internet in particular. A fundamental challenge in challenge in network operation is to increase resource utilization
network operation, especially in a large scale public IP network, is while minimizing the possibility of congestion.
to increase the efficiency of resource utilization while minimizing
the possibility of congestion.
The Internet will have to function in the presence of different The Internet has to function in the presence of different classes of
classes of traffic with different service requirements. RFC 2475 traffic with different service requirements. RFC 2475 provides an
provides an architecture for Differentiated Services and makes this architecture for Differentiated Services (DiffServ) and makes this
requirement clear [RFC2475]. The RFC allows packets to be grouped requirement clear [RFC2475]. The RFC allows packets to be grouped
into behavior aggregates such that each aggregate has a common set of into behavior aggregates such that each aggregate has a common set of
behavioral characteristics or a common set of delivery requirements. behavioral characteristics or a common set of delivery requirements.
Delivery requirements of a specific set of packets may be specified Delivery requirements of a specific set of packets may be specified
explicitly or implicitly. Two of the most important traffic delivery explicitly or implicitly. Two of the most important traffic delivery
requirements are capacity constraints and QoS constraints. requirements are capacity constraints and QoS constraints.
Capacity constraints can be expressed statistically as peak rates, Capacity constraints can be expressed statistically as peak rates,
mean rates, burst sizes, or as some deterministic notion of effective mean rates, burst sizes, or as some deterministic notion of effective
bandwidth. QoS requirements can be expressed in terms of: bandwidth. QoS requirements can be expressed in terms of:
o integrity constraints such as packet loss o integrity constraints such as packet loss
o in terms of temporal constraints such as timing restrictions for o temporal constraints such as timing restrictions for the delivery
the delivery of each packet (delay) and timing restrictions for of each packet (delay) and timing restrictions for the delivery of
the delivery of consecutive packets belonging to the same traffic consecutive packets belonging to the same traffic stream (delay
stream (delayvariation). variation).
2.3. Problem Context 2.3. Problem Context
There are several large problems in association with operating a There are several large problems associated with operating a network
network described by the simple model of the previous subsection. described in the previous section. This section analyzes the problem
This subsection analyze the problem context in relation to traffic context in relation to traffic engineering. The identification,
engineering. abstraction, representation, and measurement of network features
relevant to traffic engineering are significant issues.
The identification, abstraction, representation, and measurement of
network features relevant to traffic engineering are significant
issues.
A particular challenge is to explicitly formulate the problems that A particular challenge is to formulate the problems that traffic
traffic engineering attempts to solve. For example: engineering attempts to solve. For example:
o how to identify the requirements on the solution space o how to identify the requirements on the solution space
o how to specify the desirable features of good solutions o how to specify the desirable features of solutions
o how to actually solve the problems o how to actually solve the problems
o how to measure and characterize the effectiveness of the o how to measure and characterize the effectiveness of solutions.
solutions.
Another class of problems is how to measure and estimate relevant Another class of problems is how to measure and estimate relevant
network state parameters. Effective traffic engineering relies on a network state parameters. Effective traffic engineering relies on a
good estimate of the offered traffic load as well as a view of the good estimate of the offered traffic load as well as a view of the
underlying topology and associated resource constraints. A network- underlying topology and associated resource constraints. A network-
wide view of the topology is also a must for offline planning. wide view of the topology is also a must for offline planning.
Still another class of problems is how to characterize the state of Still another class of problem is how to characterize the state of
the network and how to evaluate its performance under a variety of the network and how to evaluate its performance. The performance
scenarios. The performance evaluation problem is two- fold. One evaluation problem is two-fold: one aspect relates to the evaluation
aspect of this problem relates to the evaluation of the system-level of the system-level performance of the network; the other aspect
performance of the network. The other aspect relates to the relates to the evaluation of resource-level performance, which
evaluation of the resource-level performance, which restricts restricts attention to the performance analysis of individual network
attention to the performance analysis of individual network
resources. resources.
In this document, we refer to the system-level characteristics of the In this document, we refer to the system-level characteristics of the
network as the "macro-states" and the resource-level characteristics network as the "macro-states" and the resource-level characteristics
as the "micro-states." The system-level characteristics are also as the "micro-states." The system-level characteristics are also
known as the emergent properties of the network. Correspondingly, we known as the emergent properties of the network. Correspondingly, we
shall refer to the traffic engineering schemes dealing with network refer to the traffic engineering schemes dealing with network
performance optimization at the systems level as "macro-TE" and the performance optimization at the systems level as "macro-TE" and the
schemes that optimize at the individual resource level as "micro-TE." schemes that optimize at the individual resource level as "micro-TE."
Under certain circumstances, the system-level performance can be Under certain circumstances, the system-level performance can be
derived from the resource-level performance using appropriate rules derived from the resource-level performance using appropriate rules
of composition, depending upon the particular performance measures of of composition, depending upon the particular performance measures of
interest. interest.
Another fundamental class of problems concerns how to effectively Another fundamental class of problem concerns how to effectively
optimize network performance. Performance optimization may entail optimize network performance. Performance optimization may entail
translating solutions to specific traffic engineering problems into translating solutions for specific traffic engineering problems into
network configurations. Optimization may also entail some degree of network configurations. Optimization may also entail some degree of
resource management control, routing control, and/or capacity resource management control, routing control, and capacity
augmentation. augmentation.
As noted previously, congestion is an undesirable phenomena in
operational networks. Therefore, the next subsection addresses the
issue of congestion and its ramifications within the problem context
of Internet traffic engineering.
2.3.1. Congestion and its Ramifications 2.3.1. Congestion and its Ramifications
Congestion is one of the most significant problems in an operational Congestion is one of the most significant problems in an operational
IP context. A network element is said to be congested if it IP context. A network element is said to be congested if it
experiences sustained overload over an interval of time. Congestion experiences sustained overload over an interval of time. Congestion
almost always results in degradation of service quality to end users. almost always results in degradation of service quality to end users.
Congestion control schemes can include demand-side policies and Congestion control schemes can include demand-side policies and
supply-side policies. Demand-side policies may restrict access to supply-side policies. Demand-side policies may restrict access to
congested resources and/or dynamically regulate the demand to congested resources or dynamically regulate the demand to alleviate
alleviate the overload situation. Supply-side policies may expand or the overload situation. Supply-side policies may expand or augment
augment network capacity to better accommodate offered traffic. network capacity to better accommodate offered traffic. Supply-side
Supply-side policies may also re-allocate network resources by policies may also re-allocate network resources by redistributing
redistributing traffic over the infrastructure. Traffic traffic over the infrastructure. Traffic redistribution and resource
redistribution and resource re-allocation serve to increase the re-allocation serve to increase the 'effective capacity' of the
'effective capacity' seen by the demand. network.
The emphasis of this document is primarily on congestion management The emphasis of this document is primarily on congestion management
schemes falling within the scope of the network, rather than on schemes falling within the scope of the network, rather than on
congestion management systems dependent upon sensitivity and congestion management systems dependent upon sensitivity and
adaptivity from end-systems. That is, the aspects that are adaptivity from end-systems. That is, the aspects that are
considered in this document with respect to congestion management are considered in this document with respect to congestion management are
those solutions that can be provided by control entities operating on those solutions that can be provided by control entities operating on
the network and by the actions of network administrators and network the network and by the actions of network administrators and network
operations systems. operations systems.
2.4. Solution Context 2.4. Solution Context
The solution context for Internet traffic engineering involves The solution context for Internet traffic engineering involves
analysis, evaluation of alternatives, and choice between alternative analysis, evaluation of alternatives, and choice between alternative
courses of action. Generally the solution context is based on making courses of action. Generally the solution context is based on making
reasonable inferences about the current or future state of the reasonable inferences about the current or future state of the
network, and subsequently making appropriate decisions that may network, and making decisions that may involve a preference between
involve a preference between alternative sets of action. More alternative sets of action. More specifically, the solution context
specifically, the solution context demands reasonable estimates of demands reasonable estimates of traffic workload, characterization of
traffic workload, characterization of network state, deriving network state, derivation of solutions which may be implicitly or
solutions to traffic engineering problems which may be implicitly or
explicitly formulated, and possibly instantiating a set of control explicitly formulated, and possibly instantiating a set of control
actions. Control actions may involve the manipulation of parameters actions. Control actions may involve the manipulation of parameters
associated with routing, control over tactical capacity acquisition, associated with routing, control over tactical capacity acquisition,
and control over the traffic management functions. and control over the traffic management functions.
The following list of instruments may be applicable to the solution The following list of instruments may be applicable to the solution
context of Internet traffic engineering. context of Internet traffic engineering.
o A set of policies, objectives, and requirements (which may be o A set of policies, objectives, and requirements (which may be
context dependent) for network performance evaluation and context dependent) for network performance evaluation and
performance optimization. performance optimization.
o A collection of online and possibly offline tools and mechanisms o A collection of online and possibly offline tools and mechanisms
for measurement, characterization, modeling, and control of for measurement, characterization, modeling, and control traffic,
Internet traffic and control over the placement and allocation of and control over the placement and allocation of network
network resources, as well as control over the mapping or resources, as well as control over the mapping or distribution of
distribution of traffic onto the infrastructure. traffic onto the infrastructure.
o A set of constraints on the operating environment, the network o A set of constraints on the operating environment, the network
protocols, and the traffic engineering system itself. protocols, and the traffic engineering system itself.
o A set of quantitative and qualitative techniques and methodologies o A set of quantitative and qualitative techniques and methodologies
for abstracting, formulating, and solving traffic engineering for abstracting, formulating, and solving traffic engineering
problems. problems.
o A set of administrative control parameters which may be o A set of administrative control parameters which may be
manipulated through a Configuration Management (CM) system. The manipulated through a Configuration Management (CM) system. The
CM system itself may include a configuration control subsystem, a CM system itself may include a configuration control subsystem, a
configuration repository, a configuration accounting subsystem, configuration repository, a configuration accounting subsystem,
and a configuration auditing subsystem. and a configuration auditing subsystem.
o A set of guidelines for network performance evaluation, o A set of guidelines for network performance evaluation,
performance optimization, and performance improvement. performance optimization, and performance improvement.
Determining traffic characteristics through measurement and/or Determining traffic characteristics through measurement or estimation
estimation is very useful within the realm the traffic engineering is very useful within the realm the traffic engineering solution
solution space. Traffic estimates can be derived from customer space. Traffic estimates can be derived from customer subscription
subscription information, traffic projections, traffic models, and information, traffic projections, traffic models, and from actual
from actual measurements. The measurements may be performed at measurements. The measurements may be performed at different levels,
different levels, e.g. the traffic-aggregate level or at the flow e.g., at the traffic-aggregate level or at the flow level.
level. Measuring at different levels is done in order to aquire Measurements at the flow level or on small traffic aggregates may be
traffic statistics at more or less detail. Measurements at the flow performed at edge nodes, when traffic enters and leaves the network.
level or on small traffic aggregates may be performed at edge nodes, Measurements for large traffic-aggregates may be performed within the
when traffic enters and leaves the network. Measurements for large core of the network.
traffic-aggregates may be performed within the core of the network.
To conduct performance studies and to support planning of existing To conduct performance studies and to support planning of existing
and future networks, a routing analysis may be performed to determine and future networks, a routing analysis may be performed to determine
the paths the routing protocols will choose for various traffic the paths the routing protocols will choose for various traffic
demands, and to ascertain the utilization of network resources as demands, and to ascertain the utilization of network resources as
traffic is routed through the network. The routing analysis should traffic is routed through the network. Routing analysis captures the
capture the selection of paths through the network, the assignment of selection of paths through the network, the assignment of traffic
traffic across multiple feasible routes, and the multiplexing of IP across multiple feasible routes, and the multiplexing of IP traffic
traffic over traffic trunks (if such constructs exists) and over the over traffic trunks (if such constructs exist) and over the
underlying network infrastructure. A network topology model is a underlying network infrastructure. A model of network topology is
necessity for routing analysis. A network topology model may be necessary to perform routing analysis. A network topology model may
extracted from: be extracted from:
o network architecture documents o network architecture documents
o network designs o network designs
o information contained in router configuration files o information contained in router configuration files
o routing databases o routing databases
o routing tables o routing tables
o automated tools that discover and depict network topology o automated tools that discover and collate network topology
information. information.
Topology information may also be derived from servers that monitor Topology information may also be derived from servers that monitor
network state, and from servers that perform provisioning functions. network state, and from servers that perform provisioning functions.
Routing in operational IP networks can be administratively controlled Routing in operational IP networks can be administratively controlled
at various levels of abstraction including the manipulation of BGP at various levels of abstraction including the manipulation of BGP
attributes and IGP metrics. For path oriented technologies such as attributes and IGP metrics. For path oriented technologies such as
MPLS, routing can be further controlled by the manipulation of MPLS, routing can be further controlled by the manipulation of
relevant traffic engineering parameters, resource parameters, and relevant traffic engineering parameters, resource parameters, and
administrative policy constraints. Within the context of MPLS, the administrative policy constraints. Within the context of MPLS, the
path of an explicitly routed label switched path (LSP) can be path of an explicitly routed label switched path (LSP) can be
computed and established in various ways including: computed and established in various ways including:
o manually o manually
o automatically online using constraint-based routing processes o automatically, online using constraint-based routing processes
implemented on label switching routers implemented on label switching routers
o automatically offline using constraint-based routing entities o automatically, offline using constraint-based routing entities
implemented on external traffic engineering support systems. implemented on external traffic engineering support systems.
2.4.1. Combating the Congestion Problem 2.4.1. Combating the Congestion Problem
Minimizing congestion is a significant aspect of Internet traffic Minimizing congestion is a significant aspect of Internet traffic
engineering. This subsection gives an overview of the general engineering. This subsection gives an overview of the general
approaches that have been used or proposed to combat congestion approaches that have been used or proposed to combat congestion.
problems.
Congestion management policies can be categorized based upon the Congestion management policies can be categorized based upon the
following criteria (see e.g., [YARE95] for a more detailed taxonomy following criteria (see [YARE95] for a more detailed taxonomy of
of congestion control schemes): congestion control schemes):
o Response time scale which can be characterized as long, medium, or
short
o reactive versus preventive which relates to congestion control and
congestion avoidance
o supply side versus demand side congestion management schemes.
These aspects are discussed in the following paragraphs.
1. Congestion Management based on Response Time Scales 1. Congestion Management based on Response Time Scales
* Long (weeks to months): Expanding network capacity by adding * Long (weeks to months): Expanding network capacity by adding
new equipement, routers and links, takes time and is new equipement, routers, and links, takes time and is
comparatively costly. Capacity planning needs to take this comparatively costly. Capacity planning needs to take this
into consideration. Network capacity is expanded based on into consideration. Network capacity is expanded based on
estimates or forcasts of future traffic development and estimates or forcasts of future traffic development and
traffic distribution. These upgrades are typically carried traffic distribution. These upgrades are typically carried
out over weeks or months, or maybe even years. out over weeks or months, or maybe even years.
* Medium (minutes to days): Several control policies fall within * Medium (minutes to days): Several control policies fall within
the medium timescale category. Examples include: the medium timescale category. Examples include:
a. Adjusting IGP and/or BGP parameters to route traffic away a. Adjusting routing protocol parameters to route traffic
or towards certain segments of the network away or towards certain segments of the network.
b. Setting up and/or adjusting some explicitly routed LSPs in b. Setting up or adjusting explicitly routed LSPs in MPLS
MPLS networks to route some traffic trunks away from networks to route traffic trunks away from possibly
possibly congested resources or toward possibly more congested resources or toward possibly more favorable
favorable routes routes.
c. Re-configuring the logical topology of the network to make c. Re-configuring the logical topology of the network to make
it correlate more closely with the spatial traffic it correlate more closely with the spatial traffic
distribution using for example some underlying path- distribution using, for example, an underlying path-
oriented technology such as MPLS LSPs or optical channel oriented technology such as MPLS LSPs or optical channel
trails. trails.
Many of these adaptive medium time scale response schemes rely Many of these adaptive medium time scale response schemes rely
on a measurement system. The measurement system monitors on a measurement system. The measurement system monitors
changes in traffic distribution, traffic shifts, and network changes in traffic distribution, traffic shifts, and network
resource utilization. The measurement system then provides resource utilization. The measurement system then provides
feedback to the online and/or offline traffic engineering feedback to the online and/or offline traffic engineering
mechanisms and tools which employ this feedback information to mechanisms and tools which employ this feedback information to
trigger certain control actions to occur within the network. trigger certain control actions to occur within the network.
The traffic engineering mechanisms and tools can be The traffic engineering mechanisms and tools can be
implemented in a distributed or centralized fashion, and may implemented in a distributed or centralized fashion, and may
have a hierarchical or flat structure. The comparative merits have a hierarchical or flat structure. The comparative merits
of distributed and centralized control structures for networks of distributed and centralized control structures for networks
are well known. A centralized scheme may have global are well known. A centralized scheme may have global
visibility into the network state and may produce potentially visibility into the network state and may produce potentially
more optimal solutions. However, centralized schemes are more optimal solutions. However, centralized schemes are
prone to single points of failure and may not scale as well as prone to single points of failure and may not scale as well as
distributed schemes. Moreover, the information utilized by a distributed schemes. Moreover, the information utilized by a
centralized scheme may be stale and may not reflect the actual centralized scheme may be stale and may not reflect the actual
state of the network. It is not an objective of this memo to state of the network. It is not an objective of this document
make a recommendation between distributed and centralized to make a recommendation between distributed and centralized
schemes. This is a choice that network administrators must schemes. This is a choice that network administrators must
make based on their specific needs. make based on their specific needs.
* Short (picoseconds to minutes): This category includes packet * Short (picoseconds to minutes): This category includes packet
level processing functions and events on the order of several level processing functions and events on the order of several
round trip times. It includes router mechanisms such as round trip times. It includes router mechanisms such as
passive and active buffer management. These mechanisms are passive and active buffer management. These mechanisms are
used to control congestion and/or signal congestion to end used to control congestion and/or signal congestion to end
systems so that they can adaptively regulate the rate at which systems so that they can adaptively regulate the rate at which
traffic is injected into the network. One of the most popular traffic is injected into the network. One of the most popular
skipping to change at page 63, line 17 skipping to change at page 62, line 17
2000. 2000.
[FT01] Fortz, B. and M. Thorup, "Optimizing OSPF/IS-IS Weights in [FT01] Fortz, B. and M. Thorup, "Optimizing OSPF/IS-IS Weights in
a Changing World", n.d., a Changing World", n.d.,
<http://www.research.att.com/~mthorup/PAPERS/papers.html>. <http://www.research.att.com/~mthorup/PAPERS/papers.html>.
[HUSS87] Hurley, B., Seidl, C., and W. Sewel, "A Survey of Dynamic [HUSS87] Hurley, B., Seidl, C., and W. Sewel, "A Survey of Dynamic
Routing Methods for Circuit-Switched Traffic", Routing Methods for Circuit-Switched Traffic",
Article IEEE Communication Magazine, September 1987. Article IEEE Communication Magazine, September 1987.
[I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-27 (work in progress), October
2020.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE) O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-22 (work in Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019. progress), June 2019.
[I-D.ietf-tewg-qos-routing] [I-D.ietf-tewg-qos-routing]
Ash, G., "Traffic Engineering & QoS Methods for IP-, ATM-, Ash, G., "Traffic Engineering & QoS Methods for IP-, ATM-,
& Based Multiservice Networks", draft-ietf-tewg-qos- & Based Multiservice Networks", draft-ietf-tewg-qos-
routing-04 (work in progress), October 2001. routing-04 (work in progress), October 2001.
skipping to change at page 68, line 10 skipping to change at page 67, line 15
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
DOI 10.17487/RFC5394, December 2008, DOI 10.17487/RFC5394, December 2008,
<https://www.rfc-editor.org/info/rfc5394>. <https://www.rfc-editor.org/info/rfc5394>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>. February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
 End of changes. 94 change blocks. 
413 lines changed or deleted 339 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/