Traffic engineering for IP networks:
tools and challenges
ZORAN BOJKOVIC(1), DRAGORAD MILOVANOVIC(2)
(1)
Faculty of Transport and Traffic Engineering, University of Belgrade,
Vojvode Stepe 305, 11000 Belgrade
(2)
Faculty of Electrical Engineering, University of Belgrade,
Bulevar Revolucije 73, 11120 Belgrade, Serbia and Montenegro
Abstract:- This paper seeks to provide an overview of traffic engineering for IP networks taking into account
tools and future challenges. The key idea is to generate global views of the network on the basis of
configuration and usage data associated with the individual network elements. From the tool point of view, it
provides a sound framework for additional modules for network optimization. Also, the problem of capacity
management and routing policies for voice over IP traffic will be addressed. Because of the shortcomings
associated with current IP routing schemes the explicit routing feature of multiprotocol label switching (MPLS)
was introduced. Rapid growth in use of the Internet and away from the workplace has spurred tremendous
interest in the provision of anytime-anywhere network connectivity to mobile users. Commonly studied mobility
scenarios involve users equipped with portable data terminals roaming around at slow to moderate speeds
within a coverage area. Mobile IP and wireless ATM are examples of protocols designed for providing network
connectivity to such mobiles in IP and ATM networks.
Key-words: IP networks, traffic engineering
1 Introduction
Traffic engineering is concerned with performance
optimization of operational networks. The aim is to
optimize network performance through three
integrated activities: measuring traffic, modeling the
network and selecting mechanisms for controlling the
traffic. Unfortunately, large internet service providers
(ISPs) have few software systems and tools to
support traffic measurement and network modeling.
The objective is to help ISPs to improve the
perceived quality of network services by reducing
delay and packet losses and increasing throughput
experienced by end users, at the sometime
maintaining a high level of resource utilization to
maximize the return of investment in network assets.
Important issues in traffic engineering include
algorithms for resource optimization, design and
implementation of traffic engineering systems,
software tools, deployment, and operational
experience in real networks [1]. The tools allow
network operators to visualize network connectivity,
configuration, and traffic statistics to perform
experiments with configuration changes and traffic
optimization in a simulated environment.
In today’s Internet, IP routing is typically based on
the destination address and simple metrics such as
hop count or link cost. While the simplicity of this
approach allows IP routing to scale to very large
networks, it does not always make good use of
network resources. Part of the problem is the
destination-based routing [2]. Since all packets
whose destination addresses share the same prefix
have the same next hop, there is typically only one
path for each destination network, except in the case
where multiple equal-cost path exists. Thus, it is
often difficult to take advantage of the diverse
connections available in the network. The traffic
distribution in the network tends to be unbalanced,
which can cause unnecessary congestion hot spots.
Simple questions about topology, traffic, and routing
are surprisingly hard to answer in today’s IP
networks. A tremendous amount of work has gone
into developing mechanisms and protocols for
controlling traffic. Indeed, most of the work in the
Internet Engineering Task Force (IETF) concerns the
aspect of traffic engineering concerned with traffic
control. By comparison, little work has been done to
support traffic measurement and network modeling
in operational networks. Unless control mechanisms
are driven by the appropriate measurements, and
understanding from well-tested models, the benefit of
the controls will be limited.
The state of the art for managing IP networks
involves manual configuration of each IP router, and
traffic engineering based on limited measurements.
The network industry is lacking in software systems
that a large Internet service provider can use to
support traffic measurements and network modeling.
The key idea is to generate global views of the
network on the basis of configuration and usage data
associated with the individual network elements.
Having created an appropriate global view, we are
able to inter and visualize the networkwide
implications of local changes in traffic, configuration
and control.
First part of this work deals with tools overview in
Internet networks. Next, routing strategies for voice
over IP will be presented. Finally, mobile IP and
wireless asynchronous transfer mode (ATM) from
the mobile multi-user platform point of view are
considered, together with concluding remarks.
2 Tools overview
Managing the performance of a large Internet Service
Provider (ISP) backbone network requires advanced
tools to support operations, engineering, and design
[3]. The key components of the toolkit are shown in
Figure 1, through the network software architecture.
Figure 1. Network software architecture.
The configuration module extracts a networkwide
view that includes the topology, link capacities,
customer addresses, peering connections, route
configuration and layer two connectivity. This
information can be extracted from the configuration
files of each router, as well as the IP forwarding
tables and interdomain routing information, in an
operational ISP network.
Traffic demands are determined based on detailed
measurements at the periphery of the network, where
traffic enters and leaves backbone. These
measurements can be aggregated to the level that
permits efficient and accurate modeling of
intradomain and interdomain routing. The
measurement module associates the traffic demands
with the appropriate routers and links drawing on
information from the configuration module.
A novel feature of the network is that it combines
diverse network configuration information with
diverse network measurements in a joint data model.
Attributes of routers, links and traffic demands are
driven from the configuration and measurement
models. To facilitate experimentation with new
network designs and projected traffic demands, the
tool uses simple flat files as input to the data model.
The routing module combines the network topology
and traffic demands by modeling how traffic would
travel through the network, based on the intradomain
and interdomain routing protocols. The model
captures the selection of shortest paths to
multihomed customers and peers, the splitting of
traffic across multiple shortest path routes and the
multiplexing of layer three IP links on layer two
trunks [4].
The visualization module display the network’s layer
three and layer two connectivity and provides
convenient access to select network configuration
information and traffic statistics. The module
supports coloring and sizing of routers and links
based on a variety of statistics, and computers
histograms, tables, and time-series plots. In addition,
the environment allows traffic changes to the
network configuration.
The network topology and traffic statistics could be
extracted from configuration files and forwarding
tables, tracked in real time by monitoring routing
protocol traffic, or projected based on a proposed
network design. Similarly, the traffic data could be
derived from network measurements, customer
subscriptions, or projected demands.
The network is able to track change while
maintaining focus on the network features of interest
to network architects and operators. Routers, line
cards, and versions of the element control software
are regularly introduced. Higher-level modules of the
software above the line in Figure 1 can and must
evolve to accommodate basic architectural changes.
The lower-level modules of the software, below the
line in Figure 1, responsible for processing the row
data associated with network element and building
higher-level abstractions, are designed for simplicity
and extensibility to accommodate frequent
incremental change in the network. Extending these
modules to cope with new network features as they
become of interest to network architects is a much
easier task than building and maintaining a tool that
aims to handle all possible combinations of features
and policies.
In designing the network, particular ways of
representing, the network topology intradomain, and
interdomain routing and the offered traffic can be
introduced. The total does not support real-time
updates to configuration data at present. Such
changes do not occur very frequently, and hence it is
reasonable to expect some amount of stability of the
network between failures and reconfigurations.
Unlike the network model, Internet traffic does
fluctuate on a variety of timescales, with important
implications for traffic engineering. Congestion
control mechanisms, such as Transmission Control
Protocol (TCP), introduce variability on a user
demands introduces burstiness on multiple
timescales. Offered load typically changes with the
time of the day or day of the week, or in response to
a network failure or reconfiguration.
3 Internet networking
The Internet is divided into a collection of
autonomous systems (ASs). Routing through the
Internet depends on protocols for routing between
ASs called exterior gateway protocols and protocols
for routing within individual ASs, called interior
gateway protocols. Each AS is managed by an
Internet Service Provider (ISP) who operates a
backbone network that connects to customers and
other service providers. ISP backbone networks
consists of a collection of IP routers and bidirectional layer three links represented as nodes and
edges in Figure 2.
or transit provider. An ISP often has multiple peering
links to each neighboring provider, typically in
different geographic locations. Backbone links
connect routers inside the ISP backbone. A link is
configured by entering interface definitions on all
routers that are part of the link. The ISP has complete
control over the configuration and operation of
backbone links. Configuration of access and peering
links depends on interaction with the customers and
peers, respectively. Each router terminates a mixture
of access, peering and backbone links. All access
links terminate an access routers (ARs) and all
peering links at Internet gateway routers (IGRs), and
all remaining routers are backbone routers (BRs) that
only terminate backbone links. In an operational
network, this split in functionality simplifies the
requirements for each router. For example, an access
router (AR) should provide high port density to
connect to a large number of customers with various
access speeds and technologies. On the other hand, a
backbone router (BR) should provide high packet
forwarding performance. Finally, isolating peer
traffic to a small set of Internet gateway routers
(IGRs) simplifies the management of interdomain
routing.
Internet Service Provider (ISP) backbones run over
an underlying facility network. This introduce
multiple layers of connectivity and capacity, where
has implications for traffic engineering and
reliability. The layer three link between two adjacent
IP routers often corresponds to dedicated capacity at
the facility level. This holds for packet over
synchronous optical network (SONET) links.
However, some networking technologies such as
fiber distributed data interface (FDDI) and
synchronous transfer mode (ATM) introduce an
intermediate switching fabric at layer two [5]. For
example, a single layer three link may correspond to
a permanent virtual circuit (PVC) that transverses
one or more ATM links via switches. In fact,
multiple layer three links may share the capacity of a
single layer two link.
4 Routing strategies for voice over IP traffic
Figure 2. View of an IP backbone network.
Access links connect directly to customers. For
example, an access link could connect to a modern
bank for dialup udders, a Web hosting complex, or a
particular
business
or
university
campus.
Multihomed customers have two or more access
links for higher capacity, load balancing, or failure
tolerance. A peering link could connect to a public
Internet exchange point, or directly to a private peer
In comparison to the routing strategies for circuitswitched (voice) networks, routing in IP networks
has traditionally employed only a single forwarding
path at a time between a pair of IP routers. The
distance vector or link state routing protocols, such
as Border Gateway protocol (BGP) or Open Shortest
Path First (OSPF), used in IP networks assign a
weight (or cost metric) to each link and then route
traffic along the least weight path (shortest path)
between every source-destination pair [6]. In case the
available capacity on that path is lower than the
amount of traffic between the specified sourcedestination pair, packets will be dropped even if an
alternate path exists to route the overflow traffic. By
basing the weights/cost metric on the link capacities
along the path, it is possible to bias the routing
procedure to select higher-capacity path, which may
alleviate this problem, but there may exist situation
where no individual path has sufficient bandwidth to
carry all the traffic between a source-destination pair.
For capacity management and routing policies for a
VoIP service, the IP network is used for “linking”
voice traffic between teledistance toll switches. In
this configuration, a public switched telephone
network (PSTN) gateway acts as the interface
between the circuit-switched and IP network
segments, performing the analog-digital and circuitpacket conversions. These PSTN gateways are
connected to an edge router at an Internet Service
Provider (ISP) point of presence. Edge routers are
connected to backbone routers through an access
network. A backbone network segment interconnects
the backbone routers. Supporting high quality
telephony services over an IP network requires the
network to meet fairly stringent packet loss and delay
requirements. Typically, the end-to-end round-trip
delay has to be less than 300ms, while packet loss
rates needs to be 1 percent or lower. Meeting these
QoS requirements requires the use of bandwidth
management and admission control mechanisms in
the IP network to ensure that adequate capacity exists
before a new voice call is admitted [7].
5 Routing and traffic engineering
The explicit routing feature of multiprotocol label
switching (MPLS) was introduced to address the
shortcomings associated with current IP routing
schemes which are hampered by the requirement to
forward packets based only on destination address
along shortest paths computed using mostly static
and traffic characteristics in dependent link metrics.
While this shortest path routing is sufficient to
achieve connectivity, it does not always make good
use of available network resources and is not
satisfactory from a traffic engineering point of view.
A prime problem is that some links on the shortest
path between certain pairs may get congested while
links on possible alternate paths remain free. Even in
the best effort model this means that available
network resources are not being used well, resulting
in higher delays, and there is a potential for providing
better quality of service (QoS) with the same network
infrastructure. In multiprotocol label switching
(MPLS) networks, when bandwidth-guaranteed
label-switched paths (LSPs) are set up, shortest path
routing with fixed link metrics can cause LSP setup
requests to be rejected, even through these requests
may have been admissible using a different routing
scheme. Therefore, routing schemes that can make
better use of network infrastructure are needed. This
better use of network infrastructure while
maintaining QoS guarantees is the primary objective
of traffic engineering.
Traffic engineering is usually associated with traffic
routing. In offline routing, it is assumed that all
tunnels or LSPs to be routed and their resource
requests are known at the time routing is done. The
objective is to route all these requests while
minimizing total network resource usage cost. The
advantage of offline routing is that routing can be
very efficient since all requests are known at the time
of routing. In practice, it is likely that new requests
need to be set up after an initial batch of requests
have been set up, or the resource requiriments of
existing requests may change over time. Attempts to
route these new requests can be made using the seek
offline algorithm on the residual network or using a
different online algorithm. In either case, it may be
difficult to accommodate these new requests since in
the offline framework the initial routing objective
was to minimize the total resource usage with no
consideration of accommodating future requests.
This problem of accommodating new requests in the
offline framework can be avoided if it is possible to
reroute existing connections to accommodate newly
arriving requests. To be practical, online routing, can
only depend on information obtainable from routing
protocols, and in particular, link state routing protocols.
In building a software system that uses link state
information to compute label switched path LSP
routes, two distinct paradigms are of prime concern:
a centralized route server paradigm where each
ingress node solicits a route from a well known route
server, and a completely distributed paradigm where
ingress node computes a route using the link state
database by itself.
6 Mobile IP and wireless ATM
Continued growth in cellular telephony and use of
the Internet outside the work place have together
fueled a lot of interest in the provision of
internetwork connectivity to users who are on the
move. Numerous research efforts in the past few
years have focused on different on different aspects
of the problem and have led to the development of
mobile IP and wireless ATM protocols for extending
network connectivity to mobile terminals [8]. There
is a different applications scenario, involving mobile
multi-user platforms (MMUPs) equipped with
(onboard) private ATM networks. A distinguished
feature of MMUPs is the presence of an onboard
private data network that provides connectivity
between on board terminals and external networks.
Potential MMUP application scenarios include
aircraft-, ship-, and train-based commercial/military
operations. Characteristics that may be shared by
many future MMUP applications include:
 presence on multiple users on board
 moderate (tens of miles per hour) to very high
(hundreds of miles per hour) travel speeds
 predetermined-schedule-based travel.
The travel speed of mobiles is significant in the
architectural design of the underlying cellular
network. Most networks for terminal mobility
applications are microcellular (a few miles in radius)
by design. Such cell sizes are not suitable for fastmoving MMUPs since the rate of connection. The
private network-to-network interface (PNNI)
protocol, which is responsible for connection setup
and routing in ATM networks, is not capable of
handling mobile switches within its hierarchy.
Appropriate modifications to the protocol are
required to allow switches with MMUP subnetwork
to take up different positions within the hierarchy
over the course of travel [9, 10].
Location management of MMUPs within the cellular
coverage area is necessary to enable new connection
setups. It can be integrated within the routing
protocol or realized externally through a separate
mechanism. Mobility characteristics of MMUPs,
such speed and frequency of intercell moves, impact
the cost effectiveness of a location management
protocol and have to be considered while designing a
particular scheme. Connection handoff is the other
major component of a complete mobility
management solution [11].
An example of aircraft-based MMUP application
scenario, illustrating network configurations and
alternative modes of connectivity is shown in Figure 3.
All existing connections between the MMUP and
external terminals need to be rerouted from the
previous to the next point of attachment on every
intercell more of the mobile multi-user platforms
(MMUP). Successful hand off of all (or as many as
possible) connections within the shortest time period
is crucial to providing satisfactory quality of service
to users aboard the MMUP. The presence of multiple
users places extra demands on network resources
during connection handoffs.
7 Concluding remarks
The power of the tool stems from the integrated data
model which provides a networkwide view of
configuration information and traffic statistics
together with a routing model. The topology model
includes the network connectivity, link capacities and
the parameters controlling interdomain routing,
derived from the router configuration files. Traffic
demands are computed based on edge measurements,
and aggregated to the coarsest level that still permits
accurate modeling of interdomain and intradomain
routing. Drawing on the traffic demands the topology
model, the routing module determines the load
imported on layer three links and layer two links
under a variety of network configurations.
There has been substantial interest in the recent past
in migrating telephone service away from circuitswitched networks onto an IP-based packet-switched
network infrastructure. One critical issue to be
resolved in achieving this migration is how to
support the QoS requirements of a high-quality
telephone service over an IP network.
Deploying multiprotocol label switching (MPLS)
system for traffic engineering in a large Internet
Service Protocol (ISP) network is feasible. MPLS,
constraint-base routing (CBR) and enhanced link
state have to be deployed in every router that
participates in the MPLS system. Because everything
is done by software upgrade, such a wide-range
deployment turns out to be as difficult as many
people might think. MPLS system is very useful for
traffic engineering It automatically achieves desired
traffic behavior and significantly relieves network
administrations of the tedious work of manipulating
routing metrics. It is especially useful in regions of
irregular network topology or tight capacity.
An extension to the current wireless ATM initiative
within the ATM Forum are mechanisms for
provision of data services to users aboard a mobile
multi-user platform (MMUP), such as an aircraft,
ship or train. Typical characteristics and unique
requirements of MMVP applications scenarios are
contrasted with the commonly studied terminal
mobility applications under wireless ATM networks.
As a part of our future work, we are going to evolve
the tool to operate on a continuous and usage feed of
topology and traffic data, to track changes in the
network configuration and usage patterns. In addition
the statistical properties of the measured traffic
demands to determine how the load between access
and peering links fluctuates on variations timescales.
This traffic analysis is critical to determining the
appropriate timescale for existing control over the
network, such as changing the configuration of intra
or interdomain routing. We will also investigate how
the traffic domain would change after network
reconfiguration. For example, flows regulated by
congestion control mechanisms such as Transmission
Control Protocol (TCP) may be able to transmit
packets more aggressively if a routing change
alleviates congestion on bottlenecked links.
Generally speaking, the Internet traffic engineering
for IP networks serves as an introduction to this new
and important area of IP networking research.
References:
[1] W.Leland et al., On the self-similarity of Ethernet
traffic, IEEE/ACM trans. Net.vol.2, pp.1-15, 1994.
[2] B.Halabi, Internet routing architecture, (Cisco
Press, 1997.)
[3] A.Feldman et al., Netscape: traffic engineering for
IP networks, IEEE Network, vol.14, pp.11-19,
March/April 2000.
[4] K.R.Rao and Z.S.Bojkovic, Packet video
communications over ATM networks, (Prentice-Hall
PTR, 2000.)
[6] G.Ash, Dynamic routing in telecommunications
networks, (McGrow Hill, 1998.)
[7] X.Xiao and L.Ni, Internet QoS: a big picture, IEEE
Network, vol.3, pp.8-18, March/April 1999.
[8] K.R.Rao, Z.Bojkovic and D.Milovanovic,
Multimedia communication systems: Techniques,
standards and networks (Prentice-Hall, 2002.)
[9] D.Raychandhuri, Wireless ATM: an enabling
technology for multimedia personal communication,
Baltzer J. Wireless Networks, vol.2, pp.163-171,
March 1996.
[10] S.Ray, Network segment mobility in ATM
networks, IEEE Comm. Magazine, vol.37, pp.3845, March 1999.
[11] P.Kumar and L.Tassinles, Mobile multi-user ATM
platforms: architectures, design issues and
challenges, IEEE Comm. Magazine, vol.14, pp.4250, March/April 2000.
Figure 3. An example of mobile multi-user platform.