< draft-dt-teas-rfc3272bis-03.txt   draft-dt-teas-rfc3272bis-04.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) November 26, 2019 Obsoletes: 3272 (if approved) November 30, 2019
Intended status: Informational Intended status: Informational
Expires: May 29, 2020 Expires: June 2, 2020
Overview and Principles of Internet Traffic Engineering Overview and Principles of Internet Traffic Engineering
draft-dt-teas-rfc3272bis-03 draft-dt-teas-rfc3272bis-04
Abstract Abstract
This memo describes the principles of Traffic Engineering (TE) in the This memo describes the principles of Traffic Engineering (TE) in the
Internet. The document is intended to promote better understanding Internet. The document is intended to promote better understanding
of the issues surrounding traffic engineering in IP networks, and to of the issues surrounding traffic engineering in IP networks, and to
provide a common basis for the development of traffic engineering provide 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 IP networks are discussed throughout this document. of operational IP networks are discussed throughout this document.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 May 29, 2020. This Internet-Draft will expire on June 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is Internet Traffic Engineering? . . . . . . . . . . 4 1.1. What is Internet Traffic Engineering? . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Context of Internet Traffic Engineering . . . . . . . . . 12 2.1. Context of Internet Traffic Engineering . . . . . . . . . 11
2.2. Network Context . . . . . . . . . . . . . . . . . . . . . 13 2.2. Network Context . . . . . . . . . . . . . . . . . . . . . 12
2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 14 2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 13
2.3.1. Congestion and its Ramifications . . . . . . . . . . 16 2.3.1. Congestion and its Ramifications . . . . . . . . . . 15
2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 16 2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 15
2.4.1. Combating the Congestion Problem . . . . . . . . . . 18 2.4.1. Combating the Congestion Problem . . . . . . . . . . 17
2.5. Implementation and Operational Context . . . . . . . . . 21 2.5. Implementation and Operational Context . . . . . . . . . 20
2.6. High-Level Objectives . . . . . . . . . . . . . . . . . . 22 2.6. High-Level Objectives . . . . . . . . . . . . . . . . . . 21
3. Traffic Engineering Process Models . . . . . . . . . . . . . 24 3. Traffic Engineering Process Models . . . . . . . . . . . . . 23
3.1. Components of the Traffic Engineering Process Model . . . 25 3.1. Components of the Traffic Engineering Process Model . . . 24
3.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 24
3.3. Modeling, Analysis, and Simulation . . . . . . . . . . . 26 3.3. Modeling, Analysis, and Simulation . . . . . . . . . . . 25
3.4. Optimization . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Optimization . . . . . . . . . . . . . . . . . . . . . . 26
4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 28 4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 27
4.1. Historic Overview . . . . . . . . . . . . . . . . . . . . 29 4.1. Historic Overview . . . . . . . . . . . . . . . . . . . . 28
4.1.1. Traffic Engineering in Classical Telephone Networks . 29 4.1.1. Traffic Engineering in Classical Telephone Networks . 28
4.1.2. Evolution of Traffic Engineering in Packet Networks . 30 4.1.2. Evolution of Traffic Engineering in Packet Networks . 29
4.2. Development of Internet Traffic Engineering . . . . . . . 33 4.2. Development of Internet Traffic Engineering . . . . . . . 32
4.2.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 33 4.2.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 32
4.2.2. Constraint-Based Routing . . . . . . . . . . . . . . 34 4.2.2. Constraint-Based Routing . . . . . . . . . . . . . . 33
4.3. Overview of IETF Projects Related to Traffic Engineering 34 4.3. Overview of IETF Projects Related to Traffic Engineering 33
4.3.1. Integrated Services . . . . . . . . . . . . . . . . . 35 4.3.1. Integrated Services . . . . . . . . . . . . . . . . . 34
4.3.2. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.2. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.3. Differentiated Services . . . . . . . . . . . . . . . 37 4.3.3. Differentiated Services . . . . . . . . . . . . . . . 36
4.3.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.5. Generalized MPLS . . . . . . . . . . . . . . . . . . 39 4.3.5. Generalized MPLS . . . . . . . . . . . . . . . . . . 38
4.3.6. IP Performance Metrics . . . . . . . . . . . . . . . 39 4.3.6. IP Performance Metrics . . . . . . . . . . . . . . . 38
4.3.7. Flow Measurement . . . . . . . . . . . . . . . . . . 39 4.3.7. Flow Measurement . . . . . . . . . . . . . . . . . . 38
4.3.8. Endpoint Congestion Management . . . . . . . . . . . 40 4.3.8. Endpoint Congestion Management . . . . . . . . . . . 39
4.3.9. TE Extensions to the IGPs . . . . . . . . . . . . . . 40 4.3.9. TE Extensions to the IGPs . . . . . . . . . . . . . . 39
4.3.10. Link-State BGP . . . . . . . . . . . . . . . . . . . 40 4.3.10. Link-State BGP . . . . . . . . . . . . . . . . . . . 39
4.3.11. Path Computation Element . . . . . . . . . . . . . . 41 4.3.11. Path Computation Element . . . . . . . . . . . . . . 40
4.3.12. Application-Layer Traffic Optimization . . . . . . . 41 4.3.12. Application-Layer Traffic Optimization . . . . . . . 40
4.3.13. Segment Routing . . . . . . . . . . . . . . . . . . . 41 4.3.13. Segment Routing . . . . . . . . . . . . . . . . . . . 40
4.3.14. Network Virtualization and Abstraction . . . . . . . 41 4.3.14. Network Virtualization and Abstraction . . . . . . . 40
4.3.15. Deterministic Networking . . . . . . . . . . . . . . 41 4.3.15. Deterministic Networking . . . . . . . . . . . . . . 40
4.3.16. Network TE State Definition and Presentation . . . . 41 4.3.16. Network TE State Definition and Presentation . . . . 40
4.3.17. System Management and Control Interfaces . . . . . . 42 4.3.17. System Management and Control Interfaces . . . . . . 41
4.4. Overview of ITU Activities Related to Traffic Engineering 42 4.4. Overview of ITU Activities Related to Traffic Engineering 41
4.5. Content Distribution . . . . . . . . . . . . . . . . . . 43 4.5. Content Distribution . . . . . . . . . . . . . . . . . . 42
5. Taxonomy of Traffic Engineering Systems . . . . . . . . . . . 44 5. Taxonomy of Traffic Engineering Systems . . . . . . . . . . . 43
5.1. Time-Dependent Versus State-Dependent Versus Event 5.1. Time-Dependent Versus State-Dependent Versus Event
Dependent . . . . . . . . . . . . . . . . . . . . . . . . 45 Dependent . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 46 5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 45
5.3. Centralized Versus Distributed . . . . . . . . . . . . . 46 5.3. Centralized Versus Distributed . . . . . . . . . . . . . 45
5.3.1. Hybrid Systems . . . . . . . . . . . . . . . . . . . 47 5.3.1. Hybrid Systems . . . . . . . . . . . . . . . . . . . 46
5.3.2. Considerations for Software Defined Networking . . . 47 5.3.2. Considerations for Software Defined Networking . . . 46
5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 47 5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 46
5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 47 5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 46
5.5.1. Intent-Based Networking . . . . . . . . . . . . . . . 48 5.5.1. Intent-Based Networking . . . . . . . . . . . . . . . 47
5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 48 5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 47
5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 48 5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 47
6. Objectives for Internet Traffic Engineering . . . . . . . . . 48 6. Objectives for Internet Traffic Engineering . . . . . . . . . 47
6.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2. Traffic Mapping . . . . . . . . . . . . . . . . . . . . . 51 6.2. Traffic Mapping . . . . . . . . . . . . . . . . . . . . . 50
6.3. Measurement . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Measurement . . . . . . . . . . . . . . . . . . . . . . . 51
6.4. Network Survivability . . . . . . . . . . . . . . . . . . 53 6.4. Network Survivability . . . . . . . . . . . . . . . . . . 52
6.4.1. Survivability in MPLS Based Networks . . . . . . . . 55 6.4.1. Survivability in MPLS Based Networks . . . . . . . . 54
6.4.2. Protection Option . . . . . . . . . . . . . . . . . . 56 6.4.2. Protection Option . . . . . . . . . . . . . . . . . . 55
6.5. Traffic Engineering in Diffserv Environments . . . . . . 57 6.5. Traffic Engineering in Diffserv Environments . . . . . . 56
6.6. Network Controllability . . . . . . . . . . . . . . . . . 59 6.6. Network Controllability . . . . . . . . . . . . . . . . . 58
7. Inter-Domain Considerations . . . . . . . . . . . . . . . . . 59 7. Inter-Domain Considerations . . . . . . . . . . . . . . . . . 58
8. Overview of Contemporary TE Practices in Operational IP 8. Overview of Contemporary TE Practices in Operational IP
Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 66 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 65
10. Security Considerations . . . . . . . . . . . . . . . . . . . 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 67 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 66
14. Informative References . . . . . . . . . . . . . . . . . . . 70 14. Informative References . . . . . . . . . . . . . . . . . . . 69
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 75
1. Introduction 1. Introduction
This memo describes the principles of Internet traffic engineering. This memo describes the principles of Internet traffic engineering.
The objective of the document is to articulate the general issues and The objective of the document is to articulate the general issues and
principles for Internet traffic engineering; and where appropriate to principles for Internet traffic engineering; and where appropriate to
provide recommendations, guidelines, and options for the development provide recommendations, guidelines, and options for the development
of online and offline Internet traffic engineering capabilities and of online and offline Internet traffic engineering capabilities and
support systems. support systems.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
engineering. 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 current best practices for Internet traffic text in line with current best 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. the IETF.
1.1. What is Internet Traffic Engineering? 1.1. What is Internet Traffic Engineering?
The Internet exists in order to transfer information from source
nodes to destination nodes. Accordingly, one of the most significant
functions performed by the Internet is the routing 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 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 issue 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].
Enhancing the performance of an operational network, at both the Ultimately, it is the performance of the network as seen by end users
traffic and resource levels, are major objectives of Internet traffic of network services that is truly paramount. The characteristics
engineering. This is accomplished by addressing traffic oriented visible to end users are the emergent properties of the network,
performance requirements, while utilizing network resources which are the characteristics of the network when viewed as a whole.
economically and reliably. Traffic oriented performance measures A central goal of the service provider, therefore, is to enhance the
include delay, delay variation, packet loss, and throughput. emergent properties of the network while taking economic
considerations into account. This is accomplished by addressing
traffic oriented performance requirements, while utilizing network
resources economically and reliably. Traffic oriented performance
measures include delay, delay variation, packet loss, and throughput.
An important objective of Internet traffic engineering is to Internet traffic engineering responds at different temporal
resolution to network events. Certain aspects of capacity
management, such as capacity planning, respond at very coarse
temporal levels, ranging from days to possibly years. The
introduction of automatically switched optical transport networks
(e.g., based on GMPLS concepts, see Section 4.3.5) could
significantly reduce the lifecycle for capacity planning by
expediting provisioning of optical bandwidth. Routing control
functions operate at intermediate levels of temporal resolution,
ranging from milliseconds to days. Finally, the packet level
processing functions (e.g., rate shaping, queue management, and
scheduling) operate at very fine levels of temporal resolution,
ranging from picoseconds to milliseconds while responding to the
real-time statistical behavior of traffic.
Thus, the optimization aspects of traffic engineering can be viewed
from a control perspective and can be pro-active and/or reactive. In
the pro-active case, the traffic engineering control system takes
preventive action to obviate predicted unfavorable future network
states such as e.g. engineering a backup path. It may also take
perfective action to induce a more desirable state in the future. In
the reactive case, the control system responds correctively and
perhaps adaptively to events that have already transpired in the
network, such as routing after failure.
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 results in a minimization of the vulnerability
of the network to service outages arising from errors, faults, and of the network to service outages arising from errors, faults, and
failures occurring within the infrastructure. failures occurring within the infrastructure.
The Internet exists in order to transfer information from source
nodes to destination nodes. Accordingly, one of the most significant
functions performed by the Internet is the routing 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 the routing function, to steer
traffic through the network in the most effective way.
Ultimately, it is the performance of the network as seen by end users
of network services that is truly paramount. This crucial point
should be considered throughout the development of traffic
engineering mechanisms and policies. 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.
The importance of the above observation regarding the emergent
properties of networks is that special care must be taken when
choosing network performance measures to optimize. Optimizing the
wrong measures may achieve certain local objectives, but may have
disastrous consequences on the emergent properties of the network and
thereby on the quality of service perceived by end-users of network
services.
A subtle, but practical advantage of the systematic application of
traffic engineering concepts to operational networks is that it helps
to identify and structure goals and priorities in terms of enhancing
the quality of service delivered to end-users of network services.
The application of traffic engineering concepts also aids in the
measurement and analysis of the achievement of these goals.
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. As used 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. Likewise, as used in this document, traffic management
includes (1) nodal traffic control functions such as traffic includes (1) nodal traffic control functions such as traffic
conditioning, queue management, scheduling, and (2) other functions conditioning, queue management, scheduling, and (2) other functions
that regulate traffic flow through the network or that arbitrate that regulate traffic flow through the network or that arbitrate
access to network resources between different packets or between access to network resources between different packets or between
different traffic streams. different traffic streams.
The optimization objectives of Internet traffic engineering should be
viewed as a continual and iterative process of network performance
improvement and not simply as a one time goal. Traffic engineering
also demands continual development of new technologies and new
methodologies for network performance enhancement.
The optimization objectives of Internet traffic engineering may
change over time as new requirements are imposed, as new technologies
emerge, or as new insights are brought to bear on the underlying
problems. Moreover, different networks may have different
optimization objectives, depending upon their business models,
capabilities, and operating constraints. The optimization aspects of
traffic engineering are ultimately concerned with network control
regardless of the specific optimization goals in any particular
environment.
Thus, the optimization aspects of traffic engineering can be viewed
from a control perspective. The aspect of control within the
Internet traffic engineering arena can be pro-active and/or reactive.
In the pro-active case, the traffic engineering control system takes
preventive action to obviate predicted unfavorable future network
states. It may also take perfective action to induce a more
desirable state in the future. In the reactive case, the control
system responds correctively and perhaps adaptively to events that
have already transpired in the network.
The control dimension of Internet traffic engineering responds at
multiple levels of temporal resolution to network events. Certain
aspects of capacity management, such as capacity planning, respond at
very coarse temporal levels, ranging from days to possibly years.
The introduction of automatically switched optical transport networks
(e.g., based on the Multi-protocol Lambda Switching concepts) could
significantly reduce the lifecycle for capacity planning by
expediting provisioning of optical bandwidth. Routing control
functions operate at intermediate levels of temporal resolution,
ranging from milliseconds to days. Finally, the packet level
processing functions (e.g., rate shaping, queue management, and
scheduling) operate at very fine levels of temporal resolution,
ranging from picoseconds to milliseconds while responding to the
real-time statistical behavior of traffic. The subsystems of
Internet traffic engineering control include: capacity augmentation,
routing control, traffic control, and resource control (including
control of service policies at network elements). When capacity is
to be augmented for tactical purposes, it may be desirable to devise
a deployment plan that expedites bandwidth provisioning while
minimizing installation costs.
Inputs into the traffic engineering control system include network
state variables, policy variables, and decision variables.
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 a network's state, while
still maintaining stability. still maintaining stability of the network. Results from performance
evaluation assessing the effectiveness of traffic engineering methods
Another critical dimension of Internet traffic engineering is network can be used to identify existing problems, guide network re-
performance evaluation, which is important for assessing the optimization, and aid in the prediction of potential future problems.
effectiveness of traffic engineering methods, and for monitoring and However this process can also time consuming and may not be suitable
verifying compliance with network performance goals. Results from to act on sudden, ephemeral changes in the network.
performance evaluation can be used to identify existing problems,
guide network re-optimization, and aid in the prediction of potential
future problems.
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. When analytical methods or empirical methods based on measurements. The processs can be quite
simulation are used, network nodes and links can be modeled to complicated in practical network contexts. For example, simplifying
capture relevant operational features such as topology, bandwidth, concepts such as effective bandwidth and effective buffer [ELW95] may
buffer space, and nodal service policies (link scheduling, packet be used to approximate nodal behaviors at the packet level and
prioritization, buffer management, etc.). Analytical traffic models simplify the analysis at the connection level. A set of concepts
can be used to depict dynamic and behavioral traffic characteristics, known as network calculus [CRUZ] based on deterministic bounds may
such as burstiness, statistical distributions, and dependence. simplify network analysis relative to classical stochastic
techniques.
Performance evaluation can be quite complicated in practical network In many cases, Internet traffic engineering is about finding the
contexts. A number of techniques can be used to simplify the least bad action to take to enhance the performance of the network.
analysis, such as abstraction, decomposition, and approximation. For For this, it is necessary to reliably predict the impact of potential
example, simplifying concepts such as effective bandwidth and corrective actions in a networking context. Such a prediction often
effective buffer [ELW95] may be used to approximate nodal behaviors relies on the accuracy of a simulation model identifying root cause
at the packet level and simplify the analysis at the connection and duration of a bottleneck, as well as the effectiveness of
level. Network analysis techniques using, for example, queuing corrective actions and its side-effects over time.
models and approximation schemes based on asymptotic and
decomposition techniques can render the analysis even more tractable.
In particular, an emerging set of concepts known as network calculus
[CRUZ] based on deterministic bounds may simplify network analysis
relative to classical stochastic techniques. When using analytical
techniques, care should be taken to ensure that the models faithfully
reflect the relevant operational characteristics of the modeled
network entities.
Simulation can be used to evaluate network performance or to verify In genaral, traffic engineering comes in two flavours. Either as a
and validate analytical approximations. Simulation can, however, be background process that constantly monitors traffic and optimize the
computationally costly and may not always provide sufficient usage of resources to improve performance, or in form of a pre-
insights. An appropriate approach to a given network performance planned optimized traffic distribution that is considered optimal.
evaluation problem may involve a hybrid combination of analytical In the later case, any deviation from the optimum distribution (e.g.,
techniques, simulation, and empirical methods. caused by a fiber cut) is reverted upon repair without further
optimization. However, this form of traffic engineering heavily
relies upon the notion that the planned state of the network is
indeed optimal. Hence, in such a mode there are two levels of
traffic engineering: the TE-planning task to enable an optimum
traffic distribution, and the routing task keeping traffic flows
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. Optimizing the wrong measures
may achieve certain local objectives, but may have disastrous
consequences on the emergent properties of the network.
1.2. Scope 1.2. 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 will discuss 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.
skipping to change at page 68, line 46 skipping to change at page 67, line 46
XiPeng Xiao XiPeng Xiao
Redback Networks Redback Networks
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
Phone: 408-750-5217 Phone: 408-750-5217
EMail: xipeng@redback.com EMail: xipeng@redback.com
The first version of this document was produced by the TEAS Working The first version of this document was produced by the TEAS Working
Group's RFC3272bis Design Team. The team members are all Group's RFC3272bis Design Team. The team members are all
Contributors to this document. They were: Contributors to this document. The full list of contributors to this
document is:
Acee Lindem Acee Lindem
EMail: acee@cisco.com EMail: acee@cisco.com
Adrian Farrel Adrian Farrel
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Aijun Wang Aijun Wang
EMail: wangaijun@tsinghua.org.cn EMail: wangaijun@tsinghua.org.cn
Daniele Ceccarelli Daniele Ceccarelli
EMail: daniele.ceccarelli@ericsson.com EMail: daniele.ceccarelli@ericsson.com
Dieter Beller Dieter Beller
skipping to change at page 70, line 5 skipping to change at page 68, line 40
Martin Horneffer Martin Horneffer
EMail: Martin.Horneffer@telekom.de EMail: Martin.Horneffer@telekom.de
Tarek Saad Tarek Saad
EMail: tsaad@cisco.com EMail: tsaad@cisco.com
Xufeng Liu Xufeng Liu
EMail: xufeng.liu.ietf@gmail.com EMail: xufeng.liu.ietf@gmail.com
Gert Grammel
EMail: ggrammel@juniper.net
14. Informative References 14. Informative References
[ASH2] Ash, J., "Dynamic Routing in Telecommunications Networks", [ASH2] Ash, J., "Dynamic Routing in Telecommunications Networks",
Book McGraw Hill, 1998. Book McGraw Hill, 1998.
[AWD1] Awduche, D. and Y. Rekhter, "Multiprocotol Lambda [AWD1] Awduche, D. and Y. Rekhter, "Multiprocotol Lambda
Switching - Combining MPLS Traffic Engineering Control Switching - Combining MPLS Traffic Engineering Control
with Optical Crossconnects", Article IEEE Communications with Optical Crossconnects", Article IEEE Communications
Magazine, March 2001. Magazine, March 2001.
 End of changes. 20 change blocks. 
206 lines changed or deleted 161 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/