Download Multi-layer Traffic Engineering in Data-centric Optical

Multi-layer Traffic Engineering in Data-centric
Optical Networks
Illustration of concepts and benefits
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck, Ilse Lievens,
Mario Pickavet, Piet Demeester
Ghent University – IMEC, Department of Information Technology
Abstract:
Intelligent Optical Networks (IONs) allow setting up or tearing down
lightpaths dynamically. The logical topology in multi-layer networks (such as
IP-over-OTN scenarios) is supported by these lightpaths, and thus dynamically
configurable. Consequently, traffic engineering functionality is extended with
cross-layer capabilities, leading to multi-layer traffic engineering (MTE). This
paper explains the concepts behind MTE, how typical MTE strategies function
and what issues arise while developing such strategies. The benefits are
illustrated by means of the results from two case studies.
Key words:
Multi-layer TE, Dynamic Grooming, GMPLS, ASON, ION
1.
INTRODUCTION
The ever-increasing bandwidth demand in data networks poses a serious
challenge in the area of broadband networking. Also, traffic patterns are
rapidly evolving, caused by, for example, the rising popularity of new
applications such as peer to peer networking and real-time multimedia over
IP. New advances in optical networking technology such as Dense
Wavelength Division Multiplexing (DWDM) and Optical Cross-Connects
(OXCs) will bring both an increase in available bandwidth and an increase in
switching flexibility in Optical Transport Networks (OTNs). Properly
configuring the OXCs allows concatenating individual wavelength channels
on consecutive fibers into an end-to-end lightpath. A lightpath has a capacity
of 2.5 or 10 Gbps, as this is what single wavelength channels typically offer.
1
2
Multilayer Traffic Engineering in Data-centric Optical Networks
As manual intervention by the network operator is currently needed for
provisioning a lightpath, this can take up to a couple of weeks or even
months. The high dynamism of traffic patterns however will require that
OTNs react within a sufficiently short time frame. As such, research is
currently focussing on the development of Intelligent Optical Networks
(IONs) – which are standardized by the ITU as Automatic Switched Optical
Networks (ASONs) [1]. For example, in an IP-over-OTN scenario, these
lightpaths are used to create links in the logical IP network topology, which
is however completely independent of the physical optical topology. An
automatic circuit-switched optical network allows bypassing the manual
intervention, and setting up and tearing down lightpaths dynamically using
User Network Interface signaling, as standardized by the OIF [2]. This way
provisioning times can be reduced considerably to minutes or seconds.
Implementing this fast-responding ION functionality will allow the
logical IP network topology to be reconfigured dynamically according to the
traffic pattern at hand. Direct links can be created or removed in the logical
IP topology, when either extra capacity is needed, or existing capacity is no
longer required.
Reconfiguring the logical topology constitutes a new manner by which
Traffic Engineering (TE) can solve or avoid network congestion problems
and service degradations. As both IP and optical network layers are
involved, this is called Multi-layer Traffic Engineering (MTE).
In this paper, the following data-centric optical network scenario is
considered. The client layer is a Multi Protocol Label Switching (MPLS)
capable IP network: MPLS decouples routing and forwarding, and hereby
enhances TE flexibility. The server layer, an optical network, is controlled
by an MPLS-like protocol: the IETF Generalized MPLS (GMPLS) protocol
[3], which is inspired on the idea that the wavelength of an optical channel
can also be considered a label. Note that GMPLS allows integrating the
control plane of both client MPLS and server optical layer.
The goal of this paper is to show how Multi-layer TE can be realized. In
section 2 some operational aspects and issues of MTE and also its interaction
with existing TE mechanisms are discussed. A classification of MTE
strategies is made in section 3. Finally in section 4 we illustrate the benefits
of MTE with two case studies.
2.
MULTI-LAYER TRAFFIC ENGINEERING
In regular TE, problems, such as typically congestion, are solved by
rerouting traffic flows over the logical topology. Multi-layer traffic
engineering provides a valuable alternative to this, by reconfiguring the
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck
3
logical network topology as required. Sometimes this form of traffic
engineering is also called dynamic grooming [4]. In this section, we will
show how MTE strategies work, what issues arise and how they interact with
existing types of traffic engineering.
2.1
Decision phases in MTE
One can identify three phases in MTE decisions, each of them will be
discussed in this section. The decision taking process is of course the most
crucial, this is explained in subsection 2.1.2. This process is however
triggered by the detection of problems while measuring the load on the
network, see subsection 2.1.1. Once a decision has been taken, it is necessary
to act accordingly, as discussed in subsection 2.1.3.
2.1.1
Detecting problems and triggering MTE
Monitoring the traffic load in the network will allow triggering
reconfiguration of the logical topology. How to actually monitor traffic loads
in links and routers is out of the scope of this paper, although some issues
have to be considered when physically measuring the actual consumed
bitrate on each link [5]. An alternative could be to rely on the bandwidth
specifications provided in the signaling messages of, for example, the
Resource reSerVation Protocol – Traffic Engineering extensions (RSVPTE), used to set up and tear down Label Switched Paths (LSPs) through the
logical IP-MPLS network.
In Figure 1, part 1, a logical IP-MPLS topology is shown, with loads on
the links indicated as percentages of the bandwidth of lightpaths, since the
IP-MPLS link connections are supported by lightpaths in the optical layer.
An additional traffic flow a-f-c-d of 40% causes higher loads on some links.
As the resulting traffic of 180% (at router f) is balanced over both links
(lightpaths) between f and c, router f detects a traffic load on two of its
outgoing links of 90%, considers this a congestion and takes the initiative.
This is an example of a reactive strategy, where MTE actions react on, or
are triggered by the detection of problems. The proactive approach however,
tries to keep the network optimal at all times, triggering a reconfiguration
whenever optimizations are possible. Note that finding improvements of the
logical topology still requires sufficient knowledge gathered from
monitoring. The advantage of the proactive approach is that it avoids
unfavorable network conditions, while the reactive approach only reacts
when (and thus after) such conditions are detected. On the other hand, due to
the continuous reconfiguration of the logical topology, and subsequent
4
Multilayer Traffic Engineering in Data-centric Optical Networks
rerouting of some traffic flows, a proactive strategy may cause a temporary
impact on the Quality of Service (QoS) of these affected traffic flows.
2.1.2
Deciding what to reconfigure
Once a problem has been detected, appropriate decisions will lead to a
better configuration of the logical topology, for example resulting in the
selection of a new link to be set up. Furthermore, a decision must also be
made about how and which traffic flows to attract over newly established
links, as seen on part 2 of Figure 1. Here one tries to optimize the loads on
both candidate link (due to the attracted traffic flows) and the load of the
congested link (which will be lowered by deviating traffic). In fact, the
selection of a particular candidate link, will in part depend on the amount of
traffic that can be attracted over this link. More accurate decisions can be
taken if more information is available, e.g. when monitoring the route and
traffic specifications per traffic flow instead of just monitoring the average
bandwidth occupied per IP link. In subsection 2.2 we discuss some further
issues besides capacity efficiency that have to be solved when designing a
proper MTE strategy. In this case, the final decision is to set up a new IPMPLS link connection between routers a and d, offloading some of the
traffic on the congested f-c link. Again note that in this example, this
decision is initiated by router f.
2.1.3
Performing the MTE actions
Once the decision has been taken, the new configuration of the logical
topology should be realized. As the example in part 3 of Figure 1 requires a
new link connection (supported by a lightpath) to be set up between routers a
and d, the decision taking router f sends a suggestion signal to one or both in
order to inform them that they should start negotiating on setting up a direct
logical link. This means a lightpath has to be requested in the optical layer,
between these two routers. Several practical solutions exist for this purpose.
Through the OIF User-Network Interface (UNI) [2], the routers can signal
into the ION to request a lightpath. In GMPLS, typically a single integrated
control plane controls both IP-MPLS and optical layers. Also, RSVP-TE is
used as signaling protocol to establish lightpaths. Once the logical link has
been established, it should be advertised to all routers in the network and
traffic should be attracted over this link. Setting the routing weight smaller
than the length of the shortest path between the endpoints of the new link
before it was established, can be used to attract this traffic automatically.
However, MPLS requires explicitly setting up an LSP over this link to attract
traffic, since routing and forwarding are decoupled in MPLS.
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck
Initial situation
0%
14
60
%
%
70
%
30
f
e
70%
a
TE initiative
taken by router
detecting
congestion IP-MPLS
IP-MPLS
c
d
60
%
16
d
70%
%
%
a
b
60
20
Additional
traffic flow
a-f-c-d of 40%
0%
c
0%
b
IP flow routed by IP-MPLS layer STE
18
70%
0%
Detection
16
1
5
f
e
70%
Congestion
Decision
• Lower load on congested link f-c
c
14
40%
a
f
d
e
• Optimize attracted traffic on
candidate link
⇒ MTE decision
Perform decision
c
70%
60
%
d
f
70%
Confirm
B
D
C
A
E
Optical
e
IP-MPLS
C
A
F
0%
e
Request
B
40%
a
60
%
f
14
0%
d
IP-MPLS
c
%
30
%
70
Su
gg
es
t
Confirm
18
Request
70%
%
20
%
60
a
b
0%
70%
0%
b
16
3
• Find suitable candidate link (a-d)
0%
b
16
2
D
F
E
Optical
Lightpath routed by Optical STE
Provisioning of candidate link needs signaling. Once set up, attract traffic.
a
IP-MPLS capable router
Logical IP-MPLS link connection,
supported by a lightpath
A
Optical Cross-Connect
Optical fiber
Lightpath
Figure 1. Phases in MTE decisions
6
2.2
Multilayer Traffic Engineering in Data-centric Optical Networks
Further issues in MTE
Besides capacity efficiency, by which MTE provides an alternative for
overprovisioning, some other issues are of importance when designing a
proper MTE strategy, some of these conflict with each other, so a trade-off
has to be made.
As reconfigurations of the logical topology are performed dynamically
(i.e., while the network is in full service), each reconfiguration may lead to
short service interruptions. Although optimality may require a great number
of reconfigurations, this number has to be somewhat limited, so that service
interruptions do not occur too often. In the case of a rather stable traffic
pattern, the logical topology should be kept stable, and not reconfigured any
longer. I.e., one should avoid that short traffic bursts trigger the MTE
decision taking process, or that small reconfigurations themselves trigger
other reconfigurations (e.g. because a small congestion problem is moved
from one region of the network to another).
One way to assure this, is to introduce a certain amount of inertia [6] in
the MTE decision taking. This inertia leads to significantly less
reconfigurations, at the cost of a slightly suboptimal logical topology. Inertia
does not imply the usage of more physical resources. In [7] we have
investigated total network cost in case router failures are solved by
reconfigurations of the logical network. Simply rerouting traffic on the
existing logical topology and up- or down-grading capacity of existing links
turned out cheaper than optimizing for each failure condition.
Another important issue is that a cumulative memory effect has to be
avoided. Optimality of the logical topology should not deteriorate over time.
For example, in case of a repetitive traffic pattern, the resource usage should
remain about the same after several repetitions. Again, inertia does not imply
a degradation of the quality of the network over time, although it does imply
a slightly suboptimal logical topology at each moment in time.
2.3
Interaction with Single-layer Traffic Engineering
Besides multi-layer TE, both IP-MPLS and optical layers still need some
form of regular traffic engineering, called Single-layer Traffic Engineering
(STE). In the IP-MPLS network, it controls the (re)routing of traffic flows
over the existing logical topology, while in the optical layer this determines
how lightpaths are routed over the optical layer.
For example, in Figure 1 part 1, the STE routing of the additional traffic
flows eventually leads to congestion in router f, requiring a reconfiguration
of the logical topology. Equally, one has to keep the IP-MPLS STE in mind
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck
7
while deciding what MTE actions to perform, as precisely this STE is
responsible for attracting traffic to newly set up IP-MPLS link connections.
Also, in part 3 of the same figure, optical STE routes the new lightpath so
that fibers with heavier wavelength usage (e.g. f-c), are avoided. Again,
MTE decisions will in part depend on the situation in the optical layer. For
instance, if the bandwidth in the optical layer reaches saturation, IP-MPLS or
even optical rerouting will become more desirable than setting up even more
lightpaths (a course of action which may limit severely the number of
available future MTE actions).
3.
CLASSIFICATION OF MULTI-LAYER TRAFFIC
ENGINEERING STRATEGIES
A number of different types of MTE strategies exist, they can be
characterized, or classified in several ways, as depicted in Figure 2.
Architecture
Objective
• Online ↔ offline
• Resource ↔ QoS ↔ …
• Centralized ↔ distributed
• Keep network optimal ↔ fix problems
• Overlay ↔ peer (integrated)
Decision strategy
Multi-layer Survivability
• Number of possible alternatives
• Static ↔ dynamic provisioning of
• Interaction with STE decisions/actions
spare capacity in logical network
• Granularity: per flow ↔ per pair
Figure 2. Classification of MTE strategies
First of all, the architecture of the multi-layer network scenario heavily
influences the performance and capabilities of the MTE strategy. For
example, running the decision taking process offline will limit the strategy to
longer-term variations in the traffic pattern. While a distributed approach
typically offers more flexibility and scalability, much effort goes into
coordinating MTE actions of individual nodes. Finally, a network based on a
peer model (also called integrated model), offers a complete overview of the
network. This leads to better MTE decisions compared to the case of an
overlay model, where control over individual network layers is separated.
8
Multilayer Traffic Engineering in Data-centric Optical Networks
Secondly, MTE strategy objectives can vary also. Some strategies are
mainly aimed at capacity efficiency, while others try to maximize the QoS.
In the former case, QoS will be of less importance and thus this may result in
flows being operated at their limit. The difference between proactive and
reactive strategies, as discussed in subsection 2.1.1, is an objective-based
classification parameter. Proactive strategies have as objective continually
keeping the network optimal, while reactive ones only fix problems.
Next, there are several aspects concerning the decision strategy. The
number of considered alternatives has a great effect on the optimality of the
resulting logical topology. A trade-off has to be made though between
optimality and calculating time. One way to reduce this number is to only
consider local or incremental network reconfigurations. Also the interaction
with STE processes is very important. Although up till now we have
assumed that STE processes react passively to MTE actions, it may be more
rewarding to consider both STE and MTE actions on the same level. Finally,
the capabilities of the strategy are influenced by the granularity by which
grooming decisions are made [8]. With a per-flow granularity, each flow can
have a different path through the network, whereas with per-pair granularity,
all flows between the same source and destination follow the same path.
Finally, providing survivability is an important aspect of TE [7]. With a
multi-layer survivability strategy, either spare protection capacity can be
provided statically (in advance), or survivability can be handled dynamically
(on-demand). For example, if survivability is not handled separately (e.g.
having higher priority), the overall MTE process in the latter case should be
able to face abrupt changes in network status (such as faults) and react fast
accordingly.
4.
CASE STUDIES
Some of the issues in multi-layer TE discussed this far, will be illustrated
with two case studies.
4.1
Case study 1: benefits of MTE – applying a reactive
strategy
This first case study will confirm the benefits of multi-layer TE. A
reactive strategy is proposed, depicted in Figure 3. Two threshold values
Thigh and Tlow respectively indicating over- and underloaded links trigger the
decision taking process. Several candidate links are evaluated using a fitness
function. This function achieves increased stability, by trying to bring the
load on both the current congested link and the candidate link to a certain
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck
9
value Tmid, in the middle between the high and low thresholds. Also, a
maximum amount of traffic T is attracted, to reduce as much as possible the
load on routers along the current shortest path between the end-points of the
candidate link (note that shortest path routing is used in the IP layer). The
candidate link leading to the lowest fitness value is selected and set up.
Detect congested or underloaded link, with traffic Tcong
Tcong > Thigh (overloaded link)
Tcong < Tlow (underloaded link)
Tear down link
Choose fittest link
For each candidate link:
• calculate T (amount of attracted traffic)
• evaluate Fitness function:
2
Try to achieve that afterwards both currently
congested link and new link end up with a
load close to Tmid
(T cong −Tmid ) + Tmid 

2

T −
2
 = (T − Tcong / 2)
Fitness (T , # Hops) = 
T (# Hops − 1)
T (# Hops − 1)
Try to reduce the load on the
routers as much as possible
• keep track of candidate link with lowest fitness value as solution
Set up link & attract traffic
Figure 3. Concept of the proposed reactive MTE strategy
A realistic IP-over-optical network scenario is used as starting point. This
network has been dimensioned for a specific traffic forecast. However, we
let traffic load rise from 80% to 160% (of the forecast), in 20% increments
every 30 seconds, and examine how the network reacts. This case study
compares two cases: a first, static case (i.e. thin lines in Figure 4), in which
for each physical optical fiber a logical IP-MPLS link is foreseen; the optical
layer (and thus also the IP-MPLS layer) is dimensioned for 100% traffic
load. The second, dynamic case (thick lines) is based on the MTE strategy in
Figure 3. Note that the terms ‘average’ and ‘total’ in Figure 4 mean that
respectively the average and sum is taken over the whole network – over all
links or routers.
10
Multilayer Traffic Engineering in Data-centric Optical Networks
Figure 4 shows average packet loss ratio (PLR) and number of used
wavelength channels for both static and dynamic case. Since the logical
topology remains unchanged from its initial configurations in the static case,
the number of used wavelengths remains the same. The load on the network
reaches 120% on second 60, and keeps rising afterwards. As expected, QoS
degrades in the static case; this is visible in the rising PLR. Also, PLR in the
static case remains relatively stable during a period with equal traffic load.
The coarse granularity of the lightpaths leads to poor average IP-MPLS link
filling, which explains why a load of 160% only results in a PLR of
approximately 10%.
# wavelength channels: dynamic
PLR: dynamic
# wavelength channels: static
PLR: static
0,25
250
# channels: dynamic
200
175
0,20
# channels: static
0,15
150
125
PLR: static
100
0,10
75
0,05
50
25
Average packet loss ratio
Total # wavelength
channels
225
PLR: dynamic
0
0
30
60
90
120
0,00
150
Time (sec)
Figure 4. Packet loss ratio (PLR) versus number of used wavelength channels
However, PLR can be kept fairly constant in the dynamic case. At each
increment of the traffic loads, additional lightpaths are set up. During these
reconfigurations, PLR peaks for a short moment. The PLR however never
reaches values as high as in the static case, except at the very beginning.
Contrary to the static case, the dynamic case has no initial dimensioning of
the network, so much more reconfigurations are needed there, although these
are needed only once, and not at a time the network is in full service.
We can conclude that a MTE strategy (dynamic case) only occupies
physical resources when really needed and reduces stress on the routers
(constant low PLR). Of course, dimensioning in the static case is typically
more optimal, as can be seen in the time interval between 30 and 60 sec,
where the logical topology for a load of 100% proposed by the MTE strategy
uses slightly more channels than the statically dimensioned topology.
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck
4.2
11
Case study 2: designing a proactive strategy
The aim of the previous case study was mainly to illustrate the benefits of
deploying MTE. The case study in this subsection is more concerned with
the design of a MTE strategy. More precisely, as framework we have chosen
the proactive MTE strategy depicted in Figure 5 and the aim of this case
study is to design the cost function applied in this MTE strategy.
Consider full-mesh: for each link
• derive cost depending on its current load
• non-existing links: can be assigned a high penalty cost
70
High for heavy loads
60
High for light loads
Cost
50
40
Interesting for
‘average’ loads
30
20
10
0
0
20
40
60
80
100
Load (%)
Route traffic along shortest (i.e. cheapest) path
• If needed, set up not yet existing links
• Tear down unused links
Figure 5. The concept of the proposed proactive MTE strategy
This proactive MTE strategy tries to optimize continuously the routing in
the logical IP network. Whereas in the previous case study, optimizations
were clearly triggered by certain events, here the logical topology is adjusted
whenever a better route is found for some traffic flow. For this purpose, all
traffic is routed over a fictive full-mesh, along a shortest path. The ‘cost’
however to use a link depends on the utilization or load of that link. Note
that during the routing of a certain flow, the load of this flow will be taken
into account when assigning costs to links. Otherwise, if the traffic flow
would carry a significant percentage of the bandwidth of a full IP-MPLS
link, rerouting might in fact lead to less optimal situations, and thus to
instability. This means costs have to be calculated again for every flow
routed. Next, the logical network is reconfigured according to this route
calculation – as the route for some traffic flows may have changed. Links
utilized in the fictive full-mesh, but not yet physically available (as
lightpaths), will have to be set up before traffic flows can actually be
12
Multilayer Traffic Engineering in Data-centric Optical Networks
rerouted over them. Also, the rerouting may cause some existing links in the
logical network to be no longer used by any traffic flows, these will need to
be torn down, freeing the occupied capacity in the optical layer. As an
illustration of the suitability of the MTE strategy depicted in Figure 5, its
behavior when applying the designed cost function is shown in Figure 6.
Important phenomena:
•
40 sec:
Logical network suddenly underloaded
•
60-90 sec:
Gradual optimization of logical network
•
90 sec:
Logical network suddenly overloaded
70
60
a
number
50
# used IP-links
# rerouted connections
40
30
20
10
0
0
10
20
30
40
50
Time (sec)
140
60
80
90
100
80
100
c
Max. load
Avg. load
Min. load
120
Load (%)
70
b
a
60
40
20
0
0
10
20
30
40
50
Time (sec)
60
70
80
90
100
Figure 6. Performance study of the proposed MTE strategy
The upper part of the figure shows the number of used IP links (i.e.
lightpaths) and number of rerouted connections per second (i.e. traffic flows
for which the route calculation yields a changed route). The lower part
shows link utilizations in the network (maximal, minimal and average load
of links, in percentage of a lightpath). In this simulation the traffic pattern
changes substantially every 10 seconds.
The MTE strategy adapts the logical network to suit the new traffic
pattern. However, a sudden decrease of the traffic volume results in lower
link fillings (see a, sec. 40 to 50), which is solved by rerouting traffic flows
(connections) and removing superfluous links. In the case of minor changes
between consecutive traffic patterns (see b, sec. 60 to 90), the logical
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck
13
network is gradually optimized. But, the more specialized for one traffic
pattern, the harder it becomes to cope with another traffic pattern (see c, for
a very abrupt change of the traffic pattern). Note that the latter phenomenon
is a confirmation of the importance to introduce some inertia in the MTE
strategy, especially here, as reconfigurations can occur continually, and are
not triggered by certain events. This inertia is achieved by penalizing, with a
higher cost, links in the fictive full-mesh that are not physically set up – thus
reducing the number of lightpath operations. This leads to faster stabilization
of the logical topology, and also of the STE IP-MPLS routing (using the cost
function). The inertia makes sure that gradual specialization of the network
only occurs when consecutive traffic patterns vary only slightly (i.e., when
abrupt changes are less probable).
As mentioned above, the goal of this case study is to design a proper cost
function. It is trivial that this cost function should result in a high cost to use
overloaded links. If this cost is high enough, it will also make sure traffic
flows are deviated away from overloaded links. Also, lightly loaded links
should be penalized with a high cost, in order to avoid the establishment of
many and thus inefficiently used links. In other words, it is our intention to
reach a network with moderately loaded links.
A first intuitive idea could be that a parabolic cost function would realize
this. However, Figure 7 illustrates that a ‘plateau’ for light link loads in the
proposed cost function is needed to trap the load or utilization of the links in
a range around a moderate load. As can be seen, the simple parabolic
function is not able to meet this constraint when the traffic volume grows.
Indeed, flows are only multiplexed when the involved links can reach the
optimal load (i.e., small cost). However, growing flow sizes prevent this. As
we are using a shortest path algorithm, shorter paths (over non-optimally
loaded links, as optimal loads cannot be achieved) will then be preferred
over longer paths, resulting in a higher meshing (many direct links).
Broadening the range of optimal loads, while making sure that cost for links
with loads below a certain value (Light Load threshold) is still high, leads to
the cost function shown at the right of Figure 7. Note that the cost does not
have to fall steeply for loads below this value (as is the case with a parabolic
function). Since links with any load between 0% and this Light Load
threshold will typically only carry one traffic flow (i.e. a direct link for a
single traffic flow), routing traffic flows over such links should be avoided –
regardless of the actual load of the traffic flow.
Part a of Figure 8 shows that the height of this plateau for light loads
should be sufficiently high compared to the values for the ideal load range.
In order to guarantee that the link loads are trapped in this ideal load range,
the cost value for the ideal load range has to be at least n times lower than
the height of the plateau, where n is the typical number of hops taken by
14
Multilayer Traffic Engineering in Data-centric Optical Networks
multiplexed traffic flows. Otherwise direct links would be preferred over
multi-hop paths, and a similar phenomenon would occur as discussed for a
simple parabolic function.
Histogram: number of links per specified utilization range
b Proposed function
Traffic: 100%
20
100
80
60
10
40
15
20
40
60
80
30
20
10
0
0
0
40
5
20
0
0
0
100
20
20
40
60
20
100
40
5
20
40
60
80
30
20
5
10
0
0
0
40
10
20
0
0
0
100
20
Traffic: 200%
40
60
5
20
0
0
0
20
40
60
80
100
50
# links
40
60
cost
15
Cost
# links
60
10
70
# links
80
cost
100
Traffic: 300%
20
100
# links
15
80
Load (%)
Load (%)
20
50
# links
10
60
cost
15
Cost
# links
60
70
# links
80
cost
100
Traffic: 200%
# links
15
80
Load (%)
Load (%)
Traffic: 150%
50
10
Cost
5
60
cost
# links
# links
15
Cost
cost
70
# links
# links
40
10
30
Cost
Traffic: 100%
20
Cost
a Parabolic function
20
5
10
0
0
0
20
Load (%)
40
60
80
100
Load (%)
Figure 7. The shape of the cost function
The establishment of direct links happens whenever a single traffic flow
has a large enough bandwidth so that a link carrying only this flow, is
considered more optimal than routing the flow along existing links (carrying
some traffic). Of course, this means that direct links will typically be
established for high bandwidth flows. This greatly helps reduce the load on
routers, as transit traffic then consists largely of low bandwidth flows.
At the other side, part b of the figure shows that the gap between this
plateau and the slope for high loads also should be wide enough in order to
Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck
15
trap the link loads in the ideal load range. Otherwise, when this gap would
be too tight, there would simply be no room enough to come to a solution
that contains links with a load in this range. In this case, a Light Load
threshold at 20% load and an increase in cost for loads higher than 80% (to
minimize packet loss) was found to be optimal.
40
30
20
10
0
0
0
20
20
20
40
60
Load (%)
80
10
20
0
15
80
20
# links
cost
15
20
10
0
0
80
50
100
40
30
20
0
20
40
60
Load (%)
80
100
70
# links
cost
15
# links
5
60
60
20
30
Load (%)
70
# links
cost
10
60
40
40
100
10
0
0
50
20
80
5
70
10
0
40
60
Load (%)
100
# links
0
50
10
5
30
5
60
60
50
40
10
30
Cost
40
Cost
50
0
# links with this load
15
60
10
# links
cost
Cost
70
# links
15
70
20
80
# links
cost
Cost
# links with this load
20
b Light Load threshold
(= width of plateau)
Cost
a Height of plateau (compared to
height for ideal load
20
5
10
0
0
0
20
40
60
Load (%)
80
100
Figure 8. The plateau for light link loads
5.
CONCLUSIONS
The concept of multi-layer traffic engineering (MTE) has been
introduced and discussed. Section 2 explained the operational aspects and
issues of such MTE schemes, while section 3 dealt with the classification of
MTE strategies. The main conclusion is that the hardest issue in
implementing MTE is the strategy or the intelligence to be foreseen in the
network.
16
Multilayer Traffic Engineering in Data-centric Optical Networks
The case study presented in subsection 4.1 illustrated the importance of
MTE in data-centric optical networks. The considered MTE strategy was
able to reconfigure the logical network in such a way that the packet loss
ratio could be kept insignificantly low (by avoiding significant overloads of
the logical IP-MPLS links), while reducing the load in the IP-MPLS routers
and occupying physical resources only when really necessary.
The case study presented in subsection 4.2 designed (as basis for a
proactive MTE strategy) a cost function depending on the link loads to route
the traffic in the logical IP network. The conclusion is that this cost function
should incorporate a sufficiently high ‘plateau’ for light link loads, in
comparison with the cost in the ideal load range. The gap between this
plateau for light loads and the slope for high loads corresponds to the
acceptable link load range and should be wide enough to allow solutions that
have all link loads in this region.
6.
ACKNOWLEDGEMENTS
Part of this work has been supported by the European Commission
through the IST-project LION, and by the Flemish Government through the
IWT GBOU project Optical Networking and Node Architectures.
7.
REFERENCES
[1] ITU-T Rec. G.8080, “Architecture for the automatically switched optical network
(ASON)”, November 2001
[2] OIF2000.125.5 , “User Network Interface (UNI) 1.0 Signaling Specification”, June 2001
[3] E. Mannie et al., “Generalized Multi-protocol Label Switching (GMPLS) Architecture”,
Internet Draft, Network Working Group, 2002
[4] Special issue on “Telecommunication Grooming”, Optical Networks Magazine,
May/June 2001
[5] John Cleary et al., “High Precision Traffic Measurement”, IEEE Communications
Magazine, Vol. 40, No. 3, March 2002, pp. 167-173
[6] D. Colle et al., “Strategies for Multilayer Traffic Engineering in Data-centric Optical
Networks”, submitted to IEEE Network
[7] S. De Maesschalck et al., “Intelligent Optical Networking for Multilayer Survivability”,
IEEE Communications Magazine, feature topic on “Resilience in Communication
Networks”, Vol. 40, No. 1, January 2002, pp. 42-49
[8] Ying-Dar Lin, Nai-Bin Hsu, Ren-Hung Hwang, “QoS Routing Granularity in MPLS
Networks”, IEEE Communications Mag., Vol. 40, No. 6, June 2002, pp. 58-65