< draft-dt-teas-rfc3272bis-01.txt   draft-dt-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) November 2, 2019 Obsoletes: 3272 (if approved) November 20, 2019
Intended status: Informational Intended status: Informational
Expires: May 5, 2020 Expires: May 23, 2020
Overview and Principles of Internet Traffic Engineering Overview and Principles of Internet Traffic Engineering
draft-dt-teas-rfc3272bis-01 draft-dt-teas-rfc3272bis-02
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 5, 2020. This Internet-Draft will expire on May 23, 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Context of Internet Traffic Engineering . . . . . . . . . 12 2.1. Context of Internet Traffic Engineering . . . . . . . . . 12
2.2. Network Context . . . . . . . . . . . . . . . . . . . . . 12 2.2. Network Context . . . . . . . . . . . . . . . . . . . . . 12
2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 14 2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 14
2.3.1. Congestion and its Ramifications . . . . . . . . . . 15 2.3.1. Congestion and its Ramifications . . . . . . . . . . 15
2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 16 2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Combating the Congestion Problem . . . . . . . . . . 18 2.4.1. Combating the Congestion Problem . . . . . . . . . . 18
2.5. Implementation and Operational Context . . . . . . . . . 21 2.5. Implementation and Operational Context . . . . . . . . . 21
3. Traffic Engineering Process Models . . . . . . . . . . . . . 21 2.6. High-Level Objectives . . . . . . . . . . . . . . . . . . 21
3.1. Components of the Traffic Engineering Process Model . . . 22 3. Traffic Engineering Process Models . . . . . . . . . . . . . 23
3.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 23 3.1. Components of the Traffic Engineering Process Model . . . 25
3.3. Modeling, Analysis, and Simulation . . . . . . . . . . . 23 3.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 25
3.4. Optimization . . . . . . . . . . . . . . . . . . . . . . 25 3.3. Modeling, Analysis, and Simulation . . . . . . . . . . . 26
4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 26 3.4. Optimization . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Historic Overview . . . . . . . . . . . . . . . . . . . . 26 4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 28
4.1.1. Traffic Engineering in Classical Telephone Networks . 26 4.1. Historic Overview . . . . . . . . . . . . . . . . . . . . 28
4.1.2. Evolution of Traffic Engineering in Packet Networks . 28 4.1.1. Traffic Engineering in Classical Telephone Networks . 28
4.2. Development of Internet Traffic Engineering . . . . . . . 31 4.1.2. Evolution of Traffic Engineering in Packet Networks . 30
4.2.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 31 4.2. Development of Internet Traffic Engineering . . . . . . . 33
4.2.2. Constraint-Based Routing . . . . . . . . . . . . . . 31 4.2.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 33
4.3. Overview of IETF Projects Related to Traffic Engineering 32 4.2.2. Constraint-Based Routing . . . . . . . . . . . . . . 33
4.3.1. Integrated Services . . . . . . . . . . . . . . . . . 32 4.3. Overview of IETF Projects Related to Traffic Engineering 34
4.3.2. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1. Integrated Services . . . . . . . . . . . . . . . . . 34
4.3.3. Differentiated Services . . . . . . . . . . . . . . . 34 4.3.2. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.3. Differentiated Services . . . . . . . . . . . . . . . 36
4.3.5. IP Performance Metrics . . . . . . . . . . . . . . . 36 4.3.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.6. Flow Measurement . . . . . . . . . . . . . . . . . . 37 4.3.5. Generalized MPLS . . . . . . . . . . . . . . . . . . 38
4.3.7. Endpoint Congestion Management . . . . . . . . . . . 37 4.3.6. IP Performance Metrics . . . . . . . . . . . . . . . 38
4.4. Overview of ITU Activities Related to Traffic Engineering 37 4.3.7. Flow Measurement . . . . . . . . . . . . . . . . . . 39
4.5. Content Distribution . . . . . . . . . . . . . . . . . . 39 4.3.8. Endpoint Congestion Management . . . . . . . . . . . 39
5. Taxonomy of Traffic Engineering Systems . . . . . . . . . . . 39 4.3.9. TE Extensions to the IGPs . . . . . . . . . . . . . . 39
4.3.10. Link-State BGP . . . . . . . . . . . . . . . . . . . 40
4.3.11. Path Computation Element . . . . . . . . . . . . . . 40
4.3.12. Segment Routing . . . . . . . . . . . . . . . . . . . 40
4.3.13. Network Virtualization and Abstraction . . . . . . . 40
4.3.14. Deterministic Networking . . . . . . . . . . . . . . 40
4.3.15. Network TE State Definition and Presentation . . . . 40
4.3.16. System Management and Control Interfaces . . . . . . 40
4.4. Overview of ITU Activities Related to Traffic Engineering 41
4.5. Content Distribution . . . . . . . . . . . . . . . . . . 42
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 . . . . . . . . . . . . . . . . . . . . . . . . 40 Dependent . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 41 5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 44
5.3. Centralized Versus Distributed . . . . . . . . . . . . . 42 5.3. Centralized Versus Distributed . . . . . . . . . . . . . 45
5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 42 5.3.1. Hybrid Systems . . . . . . . . . . . . . . . . . . . 45
5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 42 5.3.2. Considerations for Software Defined Networking . . . 45
5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 43 5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 45
5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 43 5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 46
6. Recommendations for Internet Traffic Engineering . . . . . . 43 5.5.1. Intent-Based Networking . . . . . . . . . . . . . . . 46
6.1. Generic Non-functional Recommendations . . . . . . . . . 44 5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 46
6.2. Routing Recommendations . . . . . . . . . . . . . . . . . 46 5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 46
6.3. Traffic Mapping Recommendations . . . . . . . . . . . . . 48 6. Objectives for Internet Traffic Engineering . . . . . . . . . 47
6.4. Measurement Recommendations . . . . . . . . . . . . . . . 49 6.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.5. Network Survivability . . . . . . . . . . . . . . . . . . 50 6.2. Traffic Mapping . . . . . . . . . . . . . . . . . . . . . 50
6.5.1. Survivability in MPLS Based Networks . . . . . . . . 52 6.3. Measurement . . . . . . . . . . . . . . . . . . . . . . . 50
6.5.2. Protection Option . . . . . . . . . . . . . . . . . . 53 6.4. Network Survivability . . . . . . . . . . . . . . . . . . 51
6.6. Traffic Engineering in Diffserv Environments . . . . . . 54 6.4.1. Survivability in MPLS Based Networks . . . . . . . . 53
6.7. Network Controllability . . . . . . . . . . . . . . . . . 56 6.4.2. Protection Option . . . . . . . . . . . . . . . . . . 55
6.8. Network TE State Definition and Presentation . . . . . . 56 6.5. Traffic Engineering in Diffserv Environments . . . . . . 55
6.9. System Management and Control Interfaces . . . . . . . . 57 6.6. Network Controllability . . . . . . . . . . . . . . . . . 57
7. Inter-Domain Considerations . . . . . . . . . . . . . . . . . 57 7. Inter-Domain Considerations . . . . . . . . . . . . . . . . . 58
8. Overview of Contemporary TE Practices in Operational IP 8. Overview of Contemporary TE Practices in Operational IP
Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 63 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 64
10. Security Considerations . . . . . . . . . . . . . . . . . . . 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65
14. Informative References . . . . . . . . . . . . . . . . . . . 67 14. Informative References . . . . . . . . . . . . . . . . . . . 68
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 74
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 21, line 26 skipping to change at page 21, line 35
characterized by constant change which occur at multiple levels of characterized by constant change which occur at multiple levels of
abstraction. The implementation context demands effective planning, abstraction. The implementation context demands effective planning,
organization, and execution. The planning aspects may involve organization, and execution. The planning aspects may involve
determining prior sets of actions to achieve desired objectives. determining prior sets of actions to achieve desired objectives.
Organizing involves arranging and assigning responsibility to the Organizing involves arranging and assigning responsibility to the
various components of the traffic engineering system and coordinating various components of the traffic engineering system and coordinating
the activities to accomplish the desired TE objectives. Execution the activities to accomplish the desired TE objectives. Execution
involves measuring and applying corrective or perfective actions to involves measuring and applying corrective or perfective actions to
attain and maintain desired TE goals. attain and maintain desired TE goals.
2.6. High-Level Objectives
The high-level objectives for Internet traffic engineering include:
usability, automation, scalability, stability, visibility,
simplicity, efficiency, reliability, correctness, maintainability,
extensibility, interoperability, and security. In a given context,
some of these recommendations may be critical while others may be
optional. Therefore, prioritization may be required during the
development phase of a traffic engineering system (or components
thereof) to tailor it to a specific operational context.
In the following paragraphs, some of the aspects of the high-level
objectives for Internet traffic engineering are summarized.
Usability: Usability is a human factor aspect of traffic engineering
systems. Usability refers to the ease with which a traffic
engineering system can be deployed and operated. In general, it is
desirable to have a TE system that can be readily deployed in an
existing network. It is also desirable to have a TE system that is
easy to operate and maintain.
Automation: Whenever feasible, a traffic engineering system should
automate as many traffic engineering functions as possible to
minimize the amount of human effort needed to control and analyze
operational networks. Automation is particularly imperative in large
scale public networks because of the high cost of the human aspects
of network operations and the high risk of network problems caused by
human errors. Automation may entail the incorporation of automatic
feedback and intelligence into some components of the traffic
engineering system.
Scalability: Contemporary public networks are growing very fast with
respect to network size and traffic volume. Therefore, a TE system
should be scalable to remain applicable as the network evolves. In
particular, a TE system should remain functional as the network
expands with regard to the number of routers and links, and with
respect to the traffic volume. A TE system should have a scalable
architecture, should not adversely impair other functions and
processes in a network element, and should not consume too much
network resources when collecting and distributing state information
or when exerting control.
Stability: Stability is a very important consideration in traffic
engineering systems that respond to changes in the state of the
network. State-dependent traffic engineering methodologies typically
mandate a tradeoff between responsiveness and stability. It is
strongly recommended that when tradeoffs are warranted between
responsiveness and stability, that the tradeoff should be made in
favor of stability (especially in public IP backbone networks).
Flexibility: A TE system should be flexible to allow for changes in
optimization policy. In particular, a TE system should provide
sufficient configuration options so that a network administrator can
tailor the TE system to a particular environment. It may also be
desirable to have both online and offline TE subsystems which can be
independently enabled and disabled. TE systems that are used in
multi-class networks should also have options to support class based
performance evaluation and optimization.
Visibility: As part of the TE system, mechanisms should exist to
collect statistics from the network and to analyze these statistics
to determine how well the network is functioning. Derived statistics
such as traffic matrices, link utilization, latency, packet loss, and
other performance measures of interest which are determined from
network measurements can be used as indicators of prevailing network
conditions. Other examples of status information which should be
observed include existing functional routing information
(additionally, in the context of MPLS existing LSP routes), etc.
Simplicity: Generally, a TE system should be as simple as possible.
More importantly, the TE system should be relatively easy to use
(i.e., clean, convenient, and intuitive user interfaces). Simplicity
in user interface does not necessarily imply that the TE system will
use naive algorithms. When complex algorithms and internal
structures are used, such complexities should be hidden as much as
possible from the network administrator through the user interface.
Interoperability: Whenever feasible, traffic engineering systems and
their components should be developed with open standards based
interfaces to allow interoperation with other systems and components.
Security: Security is a critical consideration in traffic engineering
systems. Such traffic engineering systems typically exert control
over certain functional aspects of the network to achieve the desired
performance objectives. Therefore, adequate measures must be taken
to safeguard the integrity of the traffic engineering system.
Adequate measures must also be taken to protect the network from
vulnerabilities that originate from security breaches and other
impairments within the traffic engineering system.
The remainder of this section will focus on some of the high level
functional recommendations for traffic engineering.
3. Traffic Engineering Process Models 3. Traffic Engineering Process Models
This section describes a generic process model that captures the high This section describes a generic process model that captures the high
level practical aspects of Internet traffic engineering in an level practical aspects of Internet traffic engineering in an
operational context. The process model is described as a sequence of operational context. The process model is described as a sequence of
actions that a traffic engineer, or more generally a traffic actions that a traffic engineer, or more generally a traffic
engineering system, must perform to optimize the performance of an engineering system, must perform to optimize the performance of an
operational network (see also [RFC2702], [AWD2]). The process model operational network (see also [RFC2702], [AWD2]). The process model
described here represents the broad activities common to most traffic described here represents the broad activities common to most traffic
engineering methodologies although the details regarding how traffic engineering methodologies although the details regarding how traffic
skipping to change at page 36, line 27 skipping to change at page 38, line 30
(ingress) node of the LSP. MPLS can use a signaling protocol such as (ingress) node of the LSP. MPLS can use a signaling protocol such as
RSVP or LDP to set up LSPs. RSVP or LDP to set up LSPs.
MPLS is a very powerful technology for Internet traffic engineering MPLS is a very powerful technology for Internet traffic engineering
because it supports explicit LSPs which allow constraint-based because it supports explicit LSPs which allow constraint-based
routing to be implemented efficiently in IP networks [AWD2]. The routing to be implemented efficiently in IP networks [AWD2]. The
requirements for traffic engineering over MPLS are described in requirements for traffic engineering over MPLS are described in
[RFC2702]. Extensions to RSVP to support instantiation of explicit [RFC2702]. Extensions to RSVP to support instantiation of explicit
LSP are discussed in [RFC3209]. LSP are discussed in [RFC3209].
4.3.5. IP Performance Metrics 4.3.5. Generalized MPLS
TBD
4.3.6. IP Performance Metrics
The IETF IP Performance Metrics (IPPM) working group has been The IETF IP Performance Metrics (IPPM) working group has been
developing a set of standard metrics that can be used to monitor the developing a set of standard metrics that can be used to monitor the
quality, performance, and reliability of Internet services. These quality, performance, and reliability of Internet services. These
metrics can be applied by network operators, end-users, and metrics can be applied by network operators, end-users, and
independent testing groups to provide users and service providers independent testing groups to provide users and service providers
with a common understanding of the performance and reliability of the with a common understanding of the performance and reliability of the
Internet component 'clouds' they use/provide [RFC2330]. The criteria Internet component 'clouds' they use/provide [RFC2330]. The criteria
for performance metrics developed by the IPPM WG are described in for performance metrics developed by the IPPM WG are described in
[RFC2330]. Examples of performance metrics include one-way packet [RFC2330]. Examples of performance metrics include one-way packet
loss [RFC7680], one-way delay [RFC7679], and connectivity measures loss [RFC7680], one-way delay [RFC7679], and connectivity measures
between two nodes [RFC2678]. Other metrics include second-order between two nodes [RFC2678]. Other metrics include second-order
measures of packet loss and delay. measures of packet loss and delay.
Some of the performance metrics specified by the IPPM WG are useful Some of the performance metrics specified by the IPPM WG are useful
for specifying Service Level Agreements (SLAs). SLAs are sets of for specifying Service Level Agreements (SLAs). SLAs are sets of
service level objectives negotiated between users and service service level objectives negotiated between users and service
providers, wherein each objective is a combination of one or more providers, wherein each objective is a combination of one or more
performance metrics, possibly subject to certain constraints. performance metrics, possibly subject to certain constraints.
4.3.6. Flow Measurement 4.3.7. Flow Measurement
The IETF Real Time Flow Measurement (RTFM) working group has produced The IETF Real Time Flow Measurement (RTFM) working group has produced
an architecture document defining a method to specify traffic flows an architecture document defining a method to specify traffic flows
as well as a number of components for flow measurement (meters, meter as well as a number of components for flow measurement (meters, meter
readers, manager) [RFC2722]. A flow measurement system enables readers, manager) [RFC2722]. A flow measurement system enables
network traffic flows to be measured and analyzed at the flow level network traffic flows to be measured and analyzed at the flow level
for a variety of purposes. As noted in RFC 2722, a flow measurement for a variety of purposes. As noted in RFC 2722, a flow measurement
system can be very useful in the following contexts: (1) system can be very useful in the following contexts: (1)
understanding the behavior of existing networks, (2) planning for understanding the behavior of existing networks, (2) planning for
network development and expansion, (3) quantification of network network development and expansion, (3) quantification of network
skipping to change at page 37, line 34 skipping to change at page 39, line 36
application, a host, a network, a group of networks, etc. A meter application, a host, a network, a group of networks, etc. A meter
reader gathers usage data from various meters so it can be made reader gathers usage data from various meters so it can be made
available for analysis. A manager is responsible for configuring and available for analysis. A manager is responsible for configuring and
controlling meters and meter readers. The instructions received by a controlling meters and meter readers. The instructions received by a
meter from a manager include flow specification, meter control meter from a manager include flow specification, meter control
parameters, and sampling techniques. The instructions received by a parameters, and sampling techniques. The instructions received by a
meter reader from a manager include the address of the meter whose meter reader from a manager include the address of the meter whose
date is to be collected, the frequency of data collection, and the date is to be collected, the frequency of data collection, and the
types of flows to be collected. types of flows to be collected.
4.3.7. Endpoint Congestion Management 4.3.8. Endpoint Congestion Management
[RFC3124] is intended to provide a set of congestion control [RFC3124] is intended to provide a set of congestion control
mechanisms that transport protocols can use. It is also intended to mechanisms that transport protocols can use. It is also intended to
develop mechanisms for unifying congestion control across a subset of develop mechanisms for unifying congestion control across a subset of
an endpoint's active unicast connections (called a congestion group). an endpoint's active unicast connections (called a congestion group).
A congestion manager continuously monitors the state of the path for A congestion manager continuously monitors the state of the path for
each congestion group under its control. The manager uses that each congestion group under its control. The manager uses that
information to instruct a scheduler on how to partition bandwidth information to instruct a scheduler on how to partition bandwidth
among the connections of that congestion group. among the connections of that congestion group.
4.3.9. TE Extensions to the IGPs
TBD
4.3.10. Link-State BGP
TBD
4.3.11. Path Computation Element
TBD
4.3.12. Segment Routing
TBD
4.3.13. Network Virtualization and Abstraction
ACTN goes here : TBD
4.3.14. Deterministic Networking
TBD
4.3.15. Network TE State Definition and Presentation
The network states that are relevant to the traffic engineering need
to be stored in the system and presented to the user. The Traffic
Engineering Database (TED) is a collection of all TE information
about all TE nodes and TE links in the network, which is an essential
component of a TE system, such as MPLS-TE [RFC2702] and GMPLS
[RFC3945]. In order to formally define the data in the TED and to
present the data to the user with high usability, the data modeling
language YANG [RFC7950] can be used as described in
[I-D.ietf-teas-yang-te-topo].
4.3.16. System Management and Control Interfaces
The traffic engineering control system needs to have a management
interface that is human-friendly and a control interfaces that is
programable for automation. The Network Configuration Protocol
(NETCONF) [RFC6241] or the RESTCONF Protocol [RFC8040] provide
programmable interfaces that are also human-friendly. These
protocols use XML or JSON encoded messages. When message compactness
or protocol bandwidth consumption needs to be optimized for the
control interface, other protocols, such as Group Communication for
the Constrained Application Protocol (CoAP) [RFC7390] or gRPC, are
available, especially when the protocol messages are encoded in a
binary format. Along with any of these protocols, the data modeling
language YANG [RFC7950] can be used to formally and precisely define
the interface data.
The Path Computation Element (PCE) Communication Protocol (PCEP)
[RFC5440] is another protocol that has evolved to be an option for
the TE system control interface. The messages of PCEP are TLV-based,
not defined by a data modeling language such as YANG.
4.4. Overview of ITU Activities Related to Traffic Engineering 4.4. Overview of ITU Activities Related to Traffic Engineering
This section provides an overview of prior work within the ITU-T This section provides an overview of prior work within the ITU-T
pertaining to traffic engineering in traditional telecommunications pertaining to traffic engineering in traditional telecommunications
networks. networks.
ITU-T Recommendations E.600 [ITU-E600], E.701 [ITU-E701], and E.801 ITU-T Recommendations E.600 [ITU-E600], E.701 [ITU-E701], and E.801
[ITU-E801] address traffic engineering issues in traditional [ITU-E801] address traffic engineering issues in traditional
telecommunications networks. Recommendation E.600 provides a telecommunications networks. Recommendation E.600 provides a
vocabulary for describing traffic engineering concepts, while E.701 vocabulary for describing traffic engineering concepts, while E.701
skipping to change at page 42, line 23 skipping to change at page 45, line 33
Centralized control may need high processing power and high bandwidth Centralized control may need high processing power and high bandwidth
control channels. control channels.
Distributed control determines route selection by each router Distributed control determines route selection by each router
autonomously based on the routers view of the state of the network. autonomously based on the routers view of the state of the network.
The network state information may be obtained by the router using a The network state information may be obtained by the router using a
probing method or distributed by other routers on a periodic basis probing method or distributed by other routers on a periodic basis
using link state advertisements. Network state information may also using link state advertisements. Network state information may also
be disseminated under exceptional conditions. be disseminated under exceptional conditions.
5.3.1. Hybrid Systems
TBD
5.3.2. Considerations for Software Defined Networking
TBD
5.4. Local Versus Global 5.4. Local Versus Global
Traffic engineering algorithms may require local or global network- Traffic engineering algorithms may require local or global network-
state information. state information.
Local information pertains to the state of a portion of the domain. Local information pertains to the state of a portion of the domain.
Examples include the bandwidth and packet loss rate of a particular Examples include the bandwidth and packet loss rate of a particular
path. Local state information may be sufficient for certain path. Local state information may be sufficient for certain
instances of distributed-controlled TEs. instances of distributed-controlled TEs.
skipping to change at page 43, line 9 skipping to change at page 46, line 28
be further categorized as either corrective or perfective. be further categorized as either corrective or perfective.
Corrective TE prescribes a course of action to address an existing or Corrective TE prescribes a course of action to address an existing or
predicted anomaly. Perfective TE prescribes a course of action to predicted anomaly. Perfective TE prescribes a course of action to
evolve and improve network performance even when no anomalies are evolve and improve network performance even when no anomalies are
evident. evident.
Descriptive traffic engineering, on the other hand, characterizes the Descriptive traffic engineering, on the other hand, characterizes the
state of the network and assesses the impact of various policies state of the network and assesses the impact of various policies
without recommending any particular course of action. without recommending any particular course of action.
5.5.1. Intent-Based Networking
TBD
5.6. Open-Loop Versus Closed-Loop 5.6. Open-Loop Versus Closed-Loop
Open-loop traffic engineering control is where control action does Open-loop traffic engineering control is where control action does
not use feedback information from the current network state. The not use feedback information from the current network state. The
control action may use its own local information for accounting control action may use its own local information for accounting
purposes, however. purposes, however.
Closed-loop traffic engineering control is where control action Closed-loop traffic engineering control is where control action
utilizes feedback information from the network state. The feedback utilizes feedback information from the network state. The feedback
information may be in the form of historical information or current information may be in the form of historical information or current
skipping to change at page 43, line 34 skipping to change at page 47, line 10
problems (such as hot-spots) that occur in the network from a problems (such as hot-spots) that occur in the network from a
tactical perspective, without consideration of overall strategic tactical perspective, without consideration of overall strategic
imperatives. Without proper planning and insights, tactical TE tends imperatives. Without proper planning and insights, tactical TE tends
to be ad hoc in nature. to be ad hoc in nature.
Strategic traffic engineering approaches the TE problem from a more Strategic traffic engineering approaches the TE problem from a more
organized and systematic perspective, taking into consideration the organized and systematic perspective, taking into consideration the
immediate and longer term consequences of specific policies and immediate and longer term consequences of specific policies and
actions. actions.
6. Recommendations for Internet Traffic Engineering 6. Objectives for Internet Traffic Engineering
This section describes high level recommendations for traffic
engineering in the Internet. These recommendations are presented in
general terms.
The recommendations describe the capabilities needed to solve a
traffic engineering problem or to achieve a traffic engineering
objective. Broadly speaking, these recommendations can be
categorized as either functional and non-functional recommendations.
Functional recommendations for Internet traffic engineering describe
the functions that a traffic engineering system should perform.
These functions are needed to realize traffic engineering objectives
by addressing traffic engineering problems.
Non-functional recommendations for Internet traffic engineering
relate to the quality attributes or state characteristics of a
traffic engineering system. These recommendations may contain
conflicting assertions and may sometimes be difficult to quantify
precisely.
6.1. Generic Non-functional Recommendations
The generic non-functional recommendations for Internet traffic
engineering include: usability, automation, scalability, stability,
visibility, simplicity, efficiency, reliability, correctness,
maintainability, extensibility, interoperability, and security. In a
given context, some of these recommendations may be critical while
others may be optional. Therefore, prioritization may be required
during the development phase of a traffic engineering system (or
components thereof) to tailor it to a specific operational context.
In the following paragraphs, some of the aspects of the non-
functional recommendations for Internet traffic engineering are
summarized.
Usability: Usability is a human factor aspect of traffic engineering
systems. Usability refers to the ease with which a traffic
engineering system can be deployed and operated. In general, it is
desirable to have a TE system that can be readily deployed in an
existing network. It is also desirable to have a TE system that is
easy to operate and maintain.
Automation: Whenever feasible, a traffic engineering system should
automate as many traffic engineering functions as possible to
minimize the amount of human effort needed to control and analyze
operational networks. Automation is particularly imperative in large
scale public networks because of the high cost of the human aspects
of network operations and the high risk of network problems caused by
human errors. Automation may entail the incorporation of automatic
feedback and intelligence into some components of the traffic
engineering system.
Scalability: Contemporary public networks are growing very fast with
respect to network size and traffic volume. Therefore, a TE system
should be scalable to remain applicable as the network evolves. In
particular, a TE system should remain functional as the network
expands with regard to the number of routers and links, and with
respect to the traffic volume. A TE system should have a scalable
architecture, should not adversely impair other functions and
processes in a network element, and should not consume too much
network resources when collecting and distributing state information
or when exerting control.
Stability: Stability is a very important consideration in traffic
engineering systems that respond to changes in the state of the
network. State-dependent traffic engineering methodologies typically
mandate a tradeoff between responsiveness and stability. It is
strongly recommended that when tradeoffs are warranted between
responsiveness and stability, that the tradeoff should be made in
favor of stability (especially in public IP backbone networks).
Flexibility: A TE system should be flexible to allow for changes in
optimization policy. In particular, a TE system should provide
sufficient configuration options so that a network administrator can
tailor the TE system to a particular environment. It may also be
desirable to have both online and offline TE subsystems which can be
independently enabled and disabled. TE systems that are used in
multi-class networks should also have options to support class based
performance evaluation and optimization.
Visibility: As part of the TE system, mechanisms should exist to
collect statistics from the network and to analyze these statistics
to determine how well the network is functioning. Derived statistics
such as traffic matrices, link utilization, latency, packet loss, and
other performance measures of interest which are determined from
network measurements can be used as indicators of prevailing network
conditions. Other examples of status information which should be
observed include existing functional routing information
(additionally, in the context of MPLS existing LSP routes), etc.
Simplicity: Generally, a TE system should be as simple as possible. This section describes high-level objectives for traffic engineering
More importantly, the TE system should be relatively easy to use in the Internet. These objectives are presented in general terms and
(i.e., clean, convenient, and intuitive user interfaces). Simplicity some advice is given as to how to meet the objectives.
in user interface does not necessarily imply that the TE system will
use naive algorithms. When complex algorithms and internal
structures are used, such complexities should be hidden as much as
possible from the network administrator through the user interface.
Interoperability: Whenever feasible, traffic engineering systems and Broadly speaking, these objectives can be categorized as either
their components should be developed with open standards based functional or non-functional.
interfaces to allow interoperation with other systems and components.
Security: Security is a critical consideration in traffic engineering Functional objectives for Internet traffic engineering describe the
systems. Such traffic engineering systems typically exert control functions that a traffic engineering system should perform. These
over certain functional aspects of the network to achieve the desired functions are needed to realize traffic engineering objectives by
performance objectives. Therefore, adequate measures must be taken addressing traffic engineering problems.
to safeguard the integrity of the traffic engineering system.
Adequate measures must also be taken to protect the network from
vulnerabilities that originate from security breaches and other
impairments within the traffic engineering system.
The remainder of this section will focus on some of the high level Non-functional objectives for Internet traffic engineering relate to
functional recommendations for traffic engineering. the quality attributes or state characteristics of a traffic
engineering system. These objectives may contain conflicting
assertions and may sometimes be difficult to quantify precisely.
6.2. Routing Recommendations 6.1. Routing
Routing control is a significant aspect of Internet traffic Routing control is a significant aspect of Internet traffic
engineering. Routing impacts many of the key performance measures engineering. Routing impacts many of the key performance measures
associated with networks, such as throughput, delay, and utilization. associated with networks, such as throughput, delay, and utilization.
Generally, it is very difficult to provide good service quality in a Generally, it is very difficult to provide good service quality in a
wide area network without effective routing control. A desirable wide area network without effective routing control. A desirable
routing system is one that takes traffic characteristics and network routing system is one that takes traffic characteristics and network
constraints into account during route selection while maintaining constraints into account during route selection while maintaining
stability. stability.
skipping to change at page 48, line 31 skipping to change at page 50, line 7
path (without affecting other traffic paths) allows traffic to be path (without affecting other traffic paths) allows traffic to be
moved from resource-poor network segments to resource-rich segments. moved from resource-poor network segments to resource-rich segments.
Path oriented technologies such as MPLS inherently support this Path oriented technologies such as MPLS inherently support this
capability as discussed in [AWD2]. capability as discussed in [AWD2].
Additionally, the routing subsystem should be able to select Additionally, the routing subsystem should be able to select
different paths for different classes of traffic (or for different different paths for different classes of traffic (or for different
traffic behavior aggregates) if the network supports multiple classes traffic behavior aggregates) if the network supports multiple classes
of service (different behavior aggregates). of service (different behavior aggregates).
6.3. Traffic Mapping Recommendations 6.2. Traffic Mapping
Traffic mapping pertains to the assignment of traffic workload onto Traffic mapping pertains to the assignment of traffic workload onto
pre-established paths to meet certain requirements. Thus, while pre-established paths to meet certain requirements. Thus, while
constraint-based routing deals with path selection, traffic mapping constraint-based routing deals with path selection, traffic mapping
deals with the assignment of traffic to established paths which may deals with the assignment of traffic to established paths which may
have been selected by constraint-based routing or by some other have been selected by constraint-based routing or by some other
means. Traffic mapping can be performed by time-dependent or state- means. Traffic mapping can be performed by time-dependent or state-
dependent mechanisms, as described in Section 5.1. dependent mechanisms, as described in Section 5.1.
An important aspect of the traffic mapping function is the ability to An important aspect of the traffic mapping function is the ability to
skipping to change at page 49, line 22 skipping to change at page 50, line 46
mitigate congestion. Thus, mechanisms that perform the traffic mitigate congestion. Thus, mechanisms that perform the traffic
mapping functions should complement existing congestion control mapping functions should complement existing congestion control
mechanisms. In an operational network, it is generally desirable to mechanisms. In an operational network, it is generally desirable to
map the traffic onto the infrastructure such that intra-class and map the traffic onto the infrastructure such that intra-class and
inter-class resource contention are minimized. inter-class resource contention are minimized.
When traffic mapping techniques that depend on dynamic state feedback When traffic mapping techniques that depend on dynamic state feedback
(e.g., MATE and such like) are used, special care must be taken to (e.g., MATE and such like) are used, special care must be taken to
guarantee network stability. guarantee network stability.
6.4. Measurement Recommendations 6.3. Measurement
The importance of measurement in traffic engineering has been The importance of measurement in traffic engineering has been
discussed throughout this document. Mechanisms should be provided to discussed throughout this document. Mechanisms should be provided to
measure and collect statistics from the network to support the measure and collect statistics from the network to support the
traffic engineering function. Additional capabilities may be needed traffic engineering function. Additional capabilities may be needed
to help in the analysis of the statistics. The actions of these to help in the analysis of the statistics. The actions of these
mechanisms should not adversely affect the accuracy and integrity of mechanisms should not adversely affect the accuracy and integrity of
the statistics collected. The mechanisms for statistical data the statistics collected. The mechanisms for statistical data
acquisition should also be able to scale as the network evolves. acquisition should also be able to scale as the network evolves.
skipping to change at page 50, line 14 skipping to change at page 51, line 39
Measured traffic statistics should provide reasonable and reliable Measured traffic statistics should provide reasonable and reliable
indicators of the current state of the network on the short-term indicators of the current state of the network on the short-term
scale. Some short term traffic statistics may reflect link scale. Some short term traffic statistics may reflect link
utilization and link congestion status. Examples of congestion utilization and link congestion status. Examples of congestion
indicators include excessive packet delay, packet loss, and high indicators include excessive packet delay, packet loss, and high
resource utilization. Examples of mechanisms for distributing this resource utilization. Examples of mechanisms for distributing this
kind of information include SNMP, probing techniques, FTP, IGP link kind of information include SNMP, probing techniques, FTP, IGP link
state advertisements, etc. state advertisements, etc.
6.5. Network Survivability 6.4. Network Survivability
Network survivability refers to the capability of a network to Network survivability refers to the capability of a network to
maintain service continuity in the presence of faults. This can be maintain service continuity in the presence of faults. This can be
accomplished by promptly recovering from network impairments and accomplished by promptly recovering from network impairments and
maintaining the required QoS for existing services after recovery. maintaining the required QoS for existing services after recovery.
Survivability has become an issue of great concern within the Survivability has become an issue of great concern within the
Internet community due to the increasing demands to carry mission Internet community due to the increasing demands to carry mission
critical traffic, real-time traffic, and other high priority traffic critical traffic, real-time traffic, and other high priority traffic
over the Internet. Survivability can be addressed at the device over the Internet. Survivability can be addressed at the device
level by developing network elements that are more reliable; and at level by developing network elements that are more reliable; and at
skipping to change at page 52, line 20 skipping to change at page 53, line 44
o It is generally desirable to have protection and restoration o It is generally desirable to have protection and restoration
schemes that are bandwidth efficient. schemes that are bandwidth efficient.
o Failure notification throughout the network should be timely and o Failure notification throughout the network should be timely and
reliable. reliable.
o Alarms and other fault monitoring and reporting capabilities o Alarms and other fault monitoring and reporting capabilities
should be provided at appropriate layers. should be provided at appropriate layers.
6.5.1. Survivability in MPLS Based Networks 6.4.1. Survivability in MPLS Based Networks
MPLS is an important emerging technology that enhances IP networks in MPLS is an important emerging technology that enhances IP networks in
terms of features, capabilities, and services. Because MPLS is path- terms of features, capabilities, and services. Because MPLS is path-
oriented, it can potentially provide faster and more predictable oriented, it can potentially provide faster and more predictable
protection and restoration capabilities than conventional hop by hop protection and restoration capabilities than conventional hop by hop
routed IP systems. This subsection describes some of the basic routed IP systems. This subsection describes some of the basic
aspects and recommendations for MPLS networks regarding protection aspects and recommendations for MPLS networks regarding protection
and restoration. See [RFC3469] for a more comprehensive discussion and restoration. See [RFC3469] for a more comprehensive discussion
on MPLS based recovery. on MPLS based recovery.
skipping to change at page 53, line 27 skipping to change at page 55, line 5
o Segment Protection: An MPLS domain may be partitioned into o Segment Protection: An MPLS domain may be partitioned into
multiple protection domains whereby a failure in a protection multiple protection domains whereby a failure in a protection
domain is rectified within that domain. In cases where an LSP domain is rectified within that domain. In cases where an LSP
traverses multiple protection domains, a protection mechanism traverses multiple protection domains, a protection mechanism
within a domain only needs to protect the segment of the LSP that within a domain only needs to protect the segment of the LSP that
lies within the domain. Segment protection will generally be lies within the domain. Segment protection will generally be
faster than path protection because recovery generally occurs faster than path protection because recovery generally occurs
closer to the fault. closer to the fault.
6.5.2. Protection Option 6.4.2. Protection Option
Another issue to consider is the concept of protection options. The Another issue to consider is the concept of protection options. The
protection option uses the notation m:n protection, where m is the protection option uses the notation m:n protection, where m is the
number of protection LSPs used to protect n working LSPs. Feasible number of protection LSPs used to protect n working LSPs. Feasible
protection options follow. protection options follow.
o 1:1: one working LSP is protected/restored by one protection LSP. o 1:1: one working LSP is protected/restored by one protection LSP.
o 1:n: one protection LSP is used to protect/restore n working LSPs. o 1:n: one protection LSP is used to protect/restore n working LSPs.
skipping to change at page 54, line 8 skipping to change at page 55, line 35
o 1+1: traffic is sent concurrently on both the working LSP and the o 1+1: traffic is sent concurrently on both the working LSP and the
protection LSP. In this case, the egress LSR selects one of the protection LSP. In this case, the egress LSR selects one of the
two LSPs based on a local traffic integrity decision process, two LSPs based on a local traffic integrity decision process,
which compares the traffic received from both the working and the which compares the traffic received from both the working and the
protection LSP and identifies discrepancies. It is unlikely that protection LSP and identifies discrepancies. It is unlikely that
this option would be used extensively in IP networks due to its this option would be used extensively in IP networks due to its
resource utilization inefficiency. However, if bandwidth becomes resource utilization inefficiency. However, if bandwidth becomes
plentiful and cheap, then this option might become quite viable plentiful and cheap, then this option might become quite viable
and attractive in IP networks. and attractive in IP networks.
6.6. Traffic Engineering in Diffserv Environments 6.5. Traffic Engineering in Diffserv Environments
This section provides an overview of the traffic engineering features This section provides an overview of the traffic engineering features
and recommendations that are specifically pertinent to Differentiated and recommendations that are specifically pertinent to Differentiated
Services (Diffserv) [RFC2475] capable IP networks. Services (Diffserv) [RFC2475] capable IP networks.
Increasing requirements to support multiple classes of traffic, such Increasing requirements to support multiple classes of traffic, such
as best effort and mission critical data, in the Internet calls for as best effort and mission critical data, in the Internet calls for
IP networks to differentiate traffic according to some criteria, and IP networks to differentiate traffic according to some criteria, and
to accord preferential treatment to certain types of traffic. Large to accord preferential treatment to certain types of traffic. Large
numbers of flows can be aggregated into a few behavior aggregates numbers of flows can be aggregated into a few behavior aggregates
skipping to change at page 56, line 11 skipping to change at page 57, line 37
An example of the class-type can be a low-loss class-type that An example of the class-type can be a low-loss class-type that
includes both AF1-based and AF2-based Ordering Aggregates. With such includes both AF1-based and AF2-based Ordering Aggregates. With such
a class-type, one may implement some priority policy which assigns a class-type, one may implement some priority policy which assigns
higher preemption priority to AF1-based traffic trunks over AF2-based higher preemption priority to AF1-based traffic trunks over AF2-based
ones, vice versa, or the same priority. ones, vice versa, or the same priority.
See [RFC4124] for detailed requirements on Diffserv-aware traffic See [RFC4124] for detailed requirements on Diffserv-aware traffic
engineering. engineering.
6.7. Network Controllability 6.6. Network Controllability
Off-line (and on-line) traffic engineering considerations would be of Off-line (and on-line) traffic engineering considerations would be of
limited utility if the network could not be controlled effectively to limited utility if the network could not be controlled effectively to
implement the results of TE decisions and to achieve desired network implement the results of TE decisions and to achieve desired network
performance objectives. Capacity augmentation is a coarse grained performance objectives. Capacity augmentation is a coarse grained
solution to traffic engineering issues. However, it is simple and solution to traffic engineering issues. However, it is simple and
may be advantageous if bandwidth is abundant and cheap or if the may be advantageous if bandwidth is abundant and cheap or if the
current or expected network workload demands it. However, bandwidth current or expected network workload demands it. However, bandwidth
is not always abundant and cheap, and the workload may not always is not always abundant and cheap, and the workload may not always
demand additional capacity. Adjustments of administrative weights demand additional capacity. Adjustments of administrative weights
skipping to change at page 56, line 44 skipping to change at page 58, line 22
vendor interoperability can be facilitated by developing and vendor interoperability can be facilitated by developing and
deploying standardized management systems (e.g., standard MIBs) and deploying standardized management systems (e.g., standard MIBs) and
policies (PIBs) to support the control functions required to address policies (PIBs) to support the control functions required to address
traffic engineering objectives such as load distribution and traffic engineering objectives such as load distribution and
protection/restoration. protection/restoration.
Network control functions should be secure, reliable, and stable as Network control functions should be secure, reliable, and stable as
these are often needed to operate correctly in times of network these are often needed to operate correctly in times of network
impairments (e.g., during network congestion or security attacks). impairments (e.g., during network congestion or security attacks).
6.8. Network TE State Definition and Presentation
The network states that are relevant to the traffic engineering need
to be stored in the system and presented to the user. The Traffic
Engineering Database (TED) is a collection of all TE information
about all TE nodes and TE links in the network, which is an essential
component of a TE system, such as MPLS-TE [RFC2702] and GMPLS
[RFC3945]. In order to formally define the data in the TED and to
present the data to the user with high usability, the data modeling
language YANG [RFC7950] can be used as described in
[I-D.ietf-teas-yang-te-topo].
6.9. System Management and Control Interfaces
The traffic engineering control system needs to have a management
interface that is human-friendly and a control interfaces that is
programable for automation. The Network Configuration Protocol
(NETCONF) [RFC6241] or the RESTCONF Protocol [RFC8040] provide
programmable interfaces that are also human-friendly. These
protocols use XML or JSON encoded messages. When message compactness
or protocol bandwidth consumption needs to be optimized for the
control interface, other protocols, such as Group Communication for
the Constrained Application Protocol (CoAP) [RFC7390] or gRPC, are
available, especially when the protocol messages are encoded in a
binary format. Along with any of these protocols, the data modeling
language YANG [RFC7950] can be used to formally and precisely define
the interface data.
The Path Computation Element (PCE) Communication Protocol (PCEP)
[RFC5440] is another protocol that has evolved to be an option for
the TE system control interface. The messages of PCEP are TLV-based,
not defined by a data modeling language such as YANG.
7. Inter-Domain Considerations 7. Inter-Domain Considerations
Inter-domain traffic engineering is concerned with the performance Inter-domain traffic engineering is concerned with the performance
optimization for traffic that originates in one administrative domain optimization for traffic that originates in one administrative domain
and terminates in a different one. and terminates in a different one.
Traffic exchange between autonomous systems in the Internet occurs Traffic exchange between autonomous systems in the Internet occurs
through exterior gateway protocols. Currently, BGP [RFC4271] is the through exterior gateway protocols. Currently, BGP [RFC4271] is the
standard exterior gateway protocol for the Internet. BGP provides a standard exterior gateway protocol for the Internet. BGP provides a
number of attributes and capabilities (e.g., route filtering) that number of attributes and capabilities (e.g., route filtering) that
skipping to change at page 60, line 34 skipping to change at page 61, line 26
and fault indicators are continually collected from the network. and fault indicators are continually collected from the network.
This empirical data is then analyzed and used to trigger various This empirical data is then analyzed and used to trigger various
traffic engineering mechanisms. Tools that perform what-if analysis traffic engineering mechanisms. Tools that perform what-if analysis
can also be used to assist the TE process by allowing various can also be used to assist the TE process by allowing various
scenarios to be reviewed before a new set of configurations are scenarios to be reviewed before a new set of configurations are
implemented in the operational network. implemented in the operational network.
Traditionally, intra-domain real-time TE with IGP is done by Traditionally, intra-domain real-time TE with IGP is done by
increasing the OSPF or IS-IS metric of a congested link until enough increasing the OSPF or IS-IS metric of a congested link until enough
traffic has been diverted from that link. This approach has some traffic has been diverted from that link. This approach has some
limitations as discussed in Section 6.2. Recently, some new intra- limitations as discussed in Section 6.1. Recently, some new intra-
domain TE approaches/tools have been proposed domain TE approaches/tools have been proposed
[RR94][FT00][FT01][WANG]. Such approaches/tools take traffic matrix, [RR94][FT00][FT01][WANG]. Such approaches/tools take traffic matrix,
network topology, and network performance objective(s) as input, and network topology, and network performance objective(s) as input, and
produce some link metrics and possibly some unequal load-sharing produce some link metrics and possibly some unequal load-sharing
ratios to be set at the head-end routers of some ECMPs as output. ratios to be set at the head-end routers of some ECMPs as output.
These new progresses open new possibility for intra-domain TE with These new progresses open new possibility for intra-domain TE with
IGP to be done in a more systematic way. IGP to be done in a more systematic way.
The overlay model (IP over ATM or IP over Frame relay) is another The overlay model (IP over ATM or IP over Frame relay) is another
approach which is commonly used in practice [AWD2]. The IP over ATM approach which is commonly used in practice [AWD2]. The IP over ATM
 End of changes. 29 change blocks. 
211 lines changed or deleted 257 lines changed or added

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