4
Traffic Engineering for
Multi-service IP Networks
Traffic engineering is a set of techniques and tools that can be
used to optimize the performance of an operational IP network.
An overarching concept, traffic engineering, broadly interpreted,
includes other topics discussed in this chapter: routing control
mechanisms such as MPLS, and an advanced configuration in the
form of policy-based management. These techniques can also be
used without deploying the complete traffic engineering frame-
work, but their optimal use benefits from it. For example, we shall
see that most efficient use of routing control is possible with proper
measurement technologies in the network.
Traffic engineering is also a cornerstone for the management of
a multi-service IP network in a cost-efficient manner. Supporting
services in the network in a commercial environment requires that
the status of the network is monitored, optimized and controlled.
The traffic engineering framework uses service level management
and monitoring techniques explained later in Chapters 6 and 7.
Especially in the presence of growing traffic volumes, the effec-
tiveness of traffic engineering also has implications on network
planning and – when used – admission control decisions, which
is why it can be said that traffic engineering also lays the foun-
dation for the application of techniques in Chapter 5 and Chap-
ter 8. Finally, traffic engineering typically makes use of the service
Implementing Service Quality in IP Networks Vilho R
¨
ais
¨
anen
 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

Traffic requirements, manifested to the end user in the form of
“emergent properties” of network performance, are to be opti-
mized subject to the constraints of the economic realm. Emergent
properties presumably correspond roughly to the end user quality
experienced discussed in Chapter 2. Further, traffic engineering is
intended to help in identifying and structuring goals and priori-
ties in enhancing the end user service experience. Reformulated,
4.1 TRAFFIC ENGINEERING 99
traffic engineering is a systematic means of analysing the network
state, drawing conclusions from it, and potentially performing a
network configuration. As is often the case with complex real-
time systems, creation of proper procedures to cope with data
acquisition and control procedures is at least half the work. Traffic
engineering is perceived as important already in the present-day
best-effort Internet, and it is even more so in the multi-service
Internet of tomorrow that is in the making at the moment.
Some reasons leading to the need for parameter optimiza-
tion are:
• change in local traffic volume, such as addition of a new major
customer in a PoP;
• change in the resourcing situation, such as change in provider
for leased line capacity;
• change in traffic aggregate distribution (locally or globally), for
example, due to adoption of a new service type;
• exceptional conditions such as malfunctioning of a router.
Other focuses areas of traffic engineering are improvement and
maintenance of reliable network operations in the face of excep-
tional situations, for example, resulting from equipment failure.
This requires the ability to detect network fault conditions and
the ability to act based on this information. In the case of a multi-

cation of solution requirements, and specification of desirable
features for the solutions. Congestion is named as an example
of a typical problem to be solved on the traditional Internet; in a
multi-service IP network, sub-optimal performance of a service
quality support class could be a further problem.
• Solution context defines how issues defined by problem con-
text are addressed. Solution context includes analysis, evalua-
tion of alternatives, prescription, and resolution. Examples of
solving the congestion problem at different timescales, reac-
tive/proactive as well as supply/demand alternatives are pro-
vided. In principle this phase is similar for best-effort Internet
and multi-service IP network, being only more complex in the
latter case.
• Implementation and operational context defines the methodological
application of solution context, including planning, organiza-
tion, and execution.
The network context must be able to express the essential factors of
traffic engineering in such a way that the problem context can be
applied to it. A multi-service network with heterogeneous service
quality support requirements can be represented as an aggregation
of network resources, traffic distribution offered, and the service
quality support mechanisms. Network resources include network
elements and the capacity and topology of the interconnecting
4.1 TRAFFIC ENGINEERING 101
network. The properties and configurability of network resources
are important. Service quality support mechanisms in a DiffServ
network include edge router functions, core router functions, and
optionally also routing control and admission control means. The
inter-operation of different service quality support mechanisms
is part of the network context, too. Specific to a DiffServ-based

Implementation and operative context are more administrative,
organizational, and executive in nature than the previous steps. This
102 TRAFFIC ENGINEERING FOR MULTI-SERVICE IP NETWORKS
aspect of traffic engineering is not central to this book, but some
related aspects will pop up sporadically in the following chapters.
The authors of [RFC3272] further note that the application of
the traffic engineering context – especially with congestion – can
be anticipatory or corrective. In the former case, the choice of
good measurement, analysis, and performance optimization tools
is especially important.
4.1.2 The traffic engineering process
The traffic engineering process is defined [RFC3272] as consisting
of the following parts:
• Definition of relevant control policies. This can be considered as
being outside of the actual traffic engineering loop, controlling
its progress. Naturally control policies can be and are adjusted
based on observed network performance.
• Feedback mechanisms for acquiring measurement data from pro-
duction network.
• Analysis of network state and characterization of traffic workload.
• Performance optimization of the network.
Thetrafficengineering processisiterative, as illustratedin Figure 4.1.
For readers familiar with the philosophy of science, the picture is
reminiscent of the idealized depiction of the induction/deduction
sequence in science [Old86]. An example of application of traffic
engineering in a large-scale production network can be found in
[FGL + 00].
The first phase is the definition of the control policies. Inputs
used for devising these may include the required service quality
support of different traffic types – related to business models of

Analysis can be either reactive or proactive. In reactive mode,
analysis attempts to identify possible locations in the network hav-
ing sub-optimal performance, to trace the root cause, and may also
test different ways of solving the problem. In proactive mode,
the goal is to identify optimization targets to prevent future per-
formance problems. The proactive mode is often important in
understanding and anticipating the effect of traffic volume growth
and changing traffic mix to the configuration of a multi-service
IP network. Possible tools for performing analysis include mod-
elling, simulation, and traffic matrices. Traffic analysis does not
have to produce the actual solution, but can also be limited to a
descriptive mode.
The optimization phase includes the means of selecting the
actual method to be used for optimizing network performance.
In this phase, the network operator can greatly benefit from using
a proactive network performance analysis mode, if the analysis
means are good enough. Optimally, the analysis machinery
104 TRAFFIC ENGINEERING FOR MULTI-SERVICE IP NETWORKS
can be used for benchmarking potential network configurations
in advance.
Automation of the above process is a challenge in the general
case. It requires finding the correct optimization tasks to be auto-
mated, and defining a correct interface for human supervision and
intervention. At the same time, instabilities due to control mecha-
nisms must be avoided.
4.1.3 Obtaining performance data from the
network and analysing it
Feedback from the network can be obtained from multiple sources
and on different levels of abstraction (see Figure 4.2). Starting
with the most detailed method, individual network elements can

NE
Endpoint
AD
Endpoint
Aggregate performance
Service performance
Figure 4.2 The relations between performance measures
Note
: The management system provides information about performance
of individual network elements within an AD, whereas aggregate perfor-
mance and service performance relate to measurements spanning multiple
elements. An AD may have multiple aggregate performance measures, for
example, relating to different DSCPs
Table 4.1 A comparison of network monitoring levels
Monitoring level Typical measured characteristics
Per network element Overall load and per- traffic aggregate statistics.
IP management system Network-wide data, averages, trend analysis.
Aggregate performance Delay, jitter, packet loss, and available bandwidth in
anetworkdomain.
Service level Service Level Specification components (see
Chapter 6).
example, Simple Network Management Protocol (SNMP). The
contents of the accessible information are defined in Management
Information Bases (MIBs). Some routers may use vendor-specific,
non-standard interfaces.
Two types of measurements relevant to traffic engineering will
be discussed in this chapter for purposes of concreteness. Traffic
aggregate performance measurements (Section 4.1.3.1) data is rele-
vant for optimizing the parameters of a DiffServ network domain.
They can also be used as an input for routing control. Traffic load

results must form a representative sample of network behaviour
in order for optimization techniques to be applicable. To this end,
the measurement point placement scenarios need to be defined
carefully [I.380]. Likewise, the treatment of error conditions such
as packets with bit errors need to be defined. Let us take a look
at the aggregate performance measurement methods next.
4.1.3.1.1 Passive measurements
Passive measurements do not require additional traffic to be injected
into the operational network. Instead, the normal traffic in an opera-
tional network can be monitored. One or more measurement points
canbeusedinasinglenetworkdomainpermonitoredtraffictype.
With one measurement point, traffic load and protocol statistics can
be monitored. In the case the monitored streams include timestamp-
ing and sequence numbering information, which is the case for the
RTP, also delay jitter and packet loss measurements can be made,
4.1 TRAFFIC ENGINEERING 107
but it must be noted that the results may include the effects of such
elements as TCP/IP stack implementation of the sending host oper-
ating system scheduling, and access network [RFC3432]. One way of
circumventing this is to combine passive and active measurements
by measuring a test stream such that the properties of the test stream
generator are well known.
With two measurement points, delay measurements are possi-
ble without timestamps, provided that a sufficiently high degree
of synchronization can be implemented between the measurement
points. Two-point delay variation measurements are described in
[I.380]. Controlled delay measurements with only a single mea-
surement point are in principle possible when a timestamped mea-
surement stream is sent by the endpoint. In addition to suffering
from the sending terminal-related problems listed above, it is also

ETSI [TIPHON-5]. To give an example of IETF work, the IPPM
working group has defined measurement metrics for delay mea-
surements using packets sent at Poisson-distributed intervals for
one-way [RFC2679] and round-trip [RFC2681] measurements. An
alternative approach suitable for measuring network performance
for periodic streams is described in [RFC3432]. The real differ-
ence between the Poisson sampling measurement and the periodic
stream measurement is only in sampling methodology.
With proper measurement packet format, delay, delay jitter,
packet loss and packet loss correlation performance for a traffic
aggregate can be directly measured with active measurements
[TIPHON-5]. Further, the IPPM working group is in the process
of defining a reordering metric. Furthermore, available bottleneck
bandwidth for the traffic aggregate in question can be estimated
using the packet pair method (see, for example, [LB99, HCY + 01]).
With active measurement, the type of measurement pack-
ets – population of interest – needs to be defined [I.380, RFC3432].
Spurious outcomes, or reception of packets matching the filter of
measurement packets which, however, are not part of the mea-
surement stream, need to be defined as well.
4.1.3.1.3 Piggybacking
Piggybacking is at the moment mostly a research-oriented
approach, where timestamping and sequence numbering infor-
mation are attached to traffic payload [JH00]. Overheads from the
measurement as well as required processing in the elements insert-
ing and removing measurement fields to payload data packets
need to be taken into account.
4.1.3.1.4 Comparison of aggregate performance measurement
methods
A comparison of aggregate performance measurement technolo-

examples show that the endpoint feedback or use of per-element
data does not necessarily provide service level performance infor-
mation directly. Furthermore, the endpoint performance is affected
by other factors, including those of the endpoint itself. Subse-
quently, it may be difficult to map endpoint performance to opti-
mization actions in the network.
Aggregate performance measurement yield information that is
network-specific, yet relates to end-to-end service performance is
shown in Figure 4.2. According to ITU-T’s definition [I.350], ser-
vice performance is measured at service access points, whereas
network performance is measured at connection element bound-
aries. What this definition boils down to is that domain-internal
110 TRAFFIC ENGINEERING FOR MULTI-SERVICE IP NETWORKS
network performance measurements often have different scope
than service level measurements.
Drawing conclusions of performance optimization actions based
on aggregate performance results requires the link between end-to-
end service performance and aggregate performances to be known.
OnetoolforthisistheuseofQoSbudgets[TIPHON-3].Asim-
ple application of QoS budgets to providing the aforementioned
link can be found in [LRR01]. In general, the link between net-
work domain-level performance and end-to-end performance can
be considered to be defined within a SLA between network oper-
ator and the provider and/or the user of the service. QoS budgets
for different service quality characteristics can be considered to be
a part of the SLA, as will be discussed in Chapter 5.
4.1.3.2 Obtaining data relevant for routing control
The data most important for routing control are load levels on
individual links and traffic aggregate performance characteristics.
Obtaining accurate information about traffic load in IP networks