Inter-area/AS TRAFFIC ENGINEERING
SUN Yugeng, HU Huadong, Liu Bin
School of Electrical Engineering and Automation
Tianjin University
Tianjin, P. R. China 300072
huhuadong@
Abstract
The existing architecture of internet traffic engineering (TE) can’t provide the
capability of deploying TE across multiple areas or Autonomous Systems (ASs). In
this paper, we firstly analyze the motivations for inter-area/AS TE. Then, the
difficulties of inter-area/AS TE are discussed. Finally, we summarize and compare
several mechanisms aimed to provide inter-area/AS TE.
Keywords: Traffic Engineering, MPLS, Autonomous System, QoS
1 Introduction
Traffic engineering techniques have emerged over the last decade in an attempt to optimize networks’
performance and ensure efficient use of their resources. Most of large ISPs have announced to support
TE in their infrastructures. The concept of deploying TE in internet has been accepted by almost all the
correlates in the field of network servic1e providing. [1]
But there are still some limitations in the existing TE architecture. Up to date, the primary use of TE has
been for optimizing traffic performance just within a network area or AS. The prevailed TE techniques
such as MPLS-TE, OSPF-TE and IS-IS-TE only validate in an area or AS mostly. [2][3][4]
In recent years, the motivation for deploying TE across multiple areas or ASs ascends with the
expanding of ISP’s networks, the growing end-to-end performance expectations of customers and the
increasing of the multi-homed large enterprise networks. In the other hand, the increasing inter-domain
tools and systems provide some supports to inter-area/AS TE. Even though, there still stand some kinds
of difficulties in deploying inter-area/AS TE. In this paper, we’ll discuss these issues and give a
summary of several proposed mechanisms aimed to provide TE in the inter-area/AS scenario.
2 Motivations for inter-area/AS TE
When ISP’s networks and the requirements of the customer transit to a new stage, it becomes more and
more stringent to provide TE capabilities in the inter-area/AS scenario just as that in the intra-area/AS
scenario. In the following sections, we’ll analyze the motivations for inter-area/AS TE from three
aspects: big ISP, small ISP or enterprise network and customer.
1基金项目：教育部博士学科点基金（20030056007）
2 .1 Ex pa ndi ng o f I SP’s netw o r k
With the increasing number of the network users, ISP’s networks grow to be more and more
complicated. It is necessary to divide it into several areas/ASs because it will be more scalable. BGP
acts between different ASs while OSPF/IS-IS runs in a single area/AS. Most of the current TE schemes
are realized via the extensions of OSPF/IS-IS.
At the same time, internet’s inter-area/AS traffic distributing becomes more and more unbalanced. A
few AS are responsible for a large proportion of traffic. As reported, 9% of AS pairs are responsible for
% of the total traffic [5]. So ISP must develop inter-area/AS TE techniques to get the load
balancing between different areas/ASs.
2 .2 I ncreas i ng of the mul t i -home d ne tw o r ks
With the transition of the network structure, more and more multi-homed networks (such as big
enterprise network and some small ISPs) emerge. Usually these networks are stub networks which
supply network access to internet only for its own users and don’t transmit any other network’s traffic
load. For these networks, the costly resource that needs to be optimized is their inter-domain
connectivity. So operator of these networks would like to balance the traffic between their inter-domain
connectivity. However, this depends on the deployment of the inter-area/AS TE.
2 .3 Cus tomers ’ gr ow i ng end- to - end perf o r mance expec ta t i o ns
Today, many operators have some or full deployment of DiffServ implementations in their networks
which can contribute to the enforcement of a set of QoS policies. But in situations where strict QoS
bounds are required, admission control inside the backbone of a network is in some cases required in
addition to current DiffServ mechanisms. MPLS-TE can be simply used with DiffServ to ensure strict
end-to-end QoS guarantees. As we all know, this scheme validates only within a single area/AS. To be
able to provide complete end-to-end QoS guarantees across multiple areas/ASs, the existing
mechanisms must be extended. [6]
3 Diff icult ies in inter-area/AS TE
Inter-area/AS TE is more difficult than that of intra-area/AS for some technical and administrative
reasons. Mainly, these reasons are: 1). lack of mechanism disclosing TE link information across
multiple areas/ASs. 2). lack of data collection and analysis tools.
3 .1 La ck o f mecha nis m d i s c lo s i ng TE-re l a t ed i nfo rma t i o n a cross a reas / As s
BGP is the most popular routing protocol running between different AS. It is a path vector routing
protocol whose decision is based on some manual policies. BGP can only provide reachability
information instead of any link-related information for the reason of scalability and confidentiality.
Internet is very big, so we must divide it into many ASs and areas. The exchange of link information is
strictly limited within the area/AS which can explicitly improve the scalability of internet. From the
administrative point of view, different areas/ASs are normally managed by different carriers which may
be business competitors. So every carrier will choose to keep their topology information a secret
instead of leaking it to other competitors. [7]
But, the deployment of TE needs accurate information of link status. From the above analysis, we know
that it is very difficult to achieve that.
3 .2 La c k o f data c ol l ec t i on and a na l ys i s t oo l s
Contrasted with the intra-area/AS TE, tools are still poor in network measurement. Nevertheless, large
networks are struggling to overcome this difficulty. Even though, The lack of data collection and of
analysis tools has contributed to inter-area/AS TE being viewed as more of an Art, practiced by the
most senior network engineers, rather than as a Science, supported by industry accepted techniques and
procedures.[8]
4 Inter-area/AS TE mechanisms
Many researchers are struggling with internet’s inter-area/AS TE now, and it has been recently a hot
topic in IETF’s traffic engineering working group too. Through their efforts, some proposals have been
proposed. As a whole, there are two types of mechanisms which are BGP policy based mechanisms and
MPLS based mechanisms.
4 .1 BG P po l i cy bas ed me c ha ni s ms
BGP4 is the most common protocol used in routing of internet traffic to other networks. It provides
complex rules and decision hierarchies for selecting the best path through the global internet
infrastructure. Initially, people studied inter-area/AS TE problem from BGP naturally.
BGP is a policy-based routing protocol. By setting particular policies, BGP can control the incoming
and outgoing traffic coarsely, and so it can control the traffic’s distributing in the network. To better
understand this character of BGP, it is useful to consider a simplified view of a BGP router as shown in
figure1. [9]
figure1. A simplified view of a BGP router
4 .1 . 1 contro l of o utg o i ng t ra f f i c
To control how the traffic leaves its network an AS must be able to choose which route will be used to
reach a particular destination through its peers. Since an AS controls the decision process on its BGP
routes, it can easily influence the selection of the best path. Two techniques are frequently used.
A first technique is to rely on the LOCAL-PREF attribute. This optional attribute is only distributed
inside an AS. It can be used to rank routes and is the first criteria of the BGP decision process (figure1).
A second technique, often used by large transit ISPs, is to rely on the intra-area/AS routing protocol to
influence how a packet crosses the transit ISP. As shown in figure 2, the BGP decision process will
select the nearest IGP neighbor when comparing several equivalent routes received via iBGP. [9]
4 .1 . 2 c on t r o l of i nc omi n g t ra f f i c
Because every AS has it’s own BGP policies that can’t be controlled by other AS, it is more harder to
control the incoming traffic. Even though, there still exists some methods we can use to achieve that.
The first method that can be used to control the traffic that enters an AS is to rely on selective
advertisements and announce different route advertisements on different links.
Another method would be to allow an AS to indicate a ranking among the various route advertisements
that it sends. Based on the utilization of the length of the AS-PATH as the third criteria in the BGP
decision process, a possible way to influence the selection of routes by a distant AS is to artificially
increase the length of the AS-Path attribute.
The last method to allow an AS to control its incoming traffic is to rely on the
MULTI-EXIT-DISCRIMINATOR (MED) attribute. This optional attribute can only be used by an AS
multi-connected to another AS to influence the link that should be used by the other AS to send packets
toward a specific destination. [9]
From above, BGP provides some methods we can use to engineer the traffic. However, we must be
extremely careful when we do that. Stability and scalability are the main challenges in the BGP policy
based inter-area/AS TE. Whatever BGP policy based technique we may use in the inter-area/AS TE, it
must achieve the following objectives: 1). Achieving predictable traffic changes. 2). Limiting the
influence of neighboring domains. 3). Reducing the overhead of routing changes. [10]
4 .2 M PLS ba s e d me c ha ni sms
MPLS provides some connectivity in today’s connectless internet which makes it a prevailing
technology in many new network applications. Because of MPLS’s ability for more value-added
services, it has been a fundamental component of many large providers’ infrastructures, such as Global
Crossing and Cable&Wireless. MPLS’s explicit routing makes it the dominant scheme to deploy TE.
But until now, MPLS-TE can only be configured within a single area/AS. To be able to support
inter-area/AS TE, the current design needs to be extended. Different mechanisms have different
enhancement methods. But whatever mechanism we may choose, enhancements are always required for
the traffic engineering database, path computation, signaling and protection/restoration. [11]
Just like MPLS intra-area/AS TE, MPLS inter-area/AS TE area highly designed to provide: 1).
Inter-area/AS resources optimization. 2). Strict inter-area/AS QoS guarantees. 3). Fast recovery across
areas/ASs. Basically, it may be desired to compute inter-area/AS shortest path that satisfy some
constraints ( Bandwidth), as currently possible within an Area/AS. [12][6]
According to the different path computation mechanisms used, there are two types of MPLS
inter-area/AS TE schemes: 1). Per-area/AS path computation. 2). End-to-end shortest path computation.
[13]
4 .2 . 1 Per -a rea / AS pa th co mputat i o n
In this mode, the next boundary LSR are determined per area/AS as the inter-area/AS TE LSP is being
signaled.
When an ABR/ASBR receives a Path message with a loose next-hop in the ERO, then it carries out the
following actions:
1). It checks if the loose next-hop is accessible via the TED. If the loose next-hop is not present in the
TED, then it will check if the next-hop at least has IP reachability (via IGP or BGP). If the next-hop is
not reachable, then the LSR will be unable to propagate the Path message any further and will send back
a Path Error upstream. If the next-hop is reachable, then it will find an ABR/ASBR to get to the
next-hop.
2). If the next-hop boundary LSR is present in the TED. the ABR/ASBR just performs an ERO
expansion after having computed the path to the next loose hop (ABR/ASBR) that obeys the set of
required constraints. If no path satisfying the set of constraints can be found then a Path Error must be
sent for the inter-area/AS TE LSP.
Figure2. Per-area/AS path computation (an inter-area example)
Of course, the above procedures do not apply when a boundary LSR receives a Path message with strict
next-hop.
4 .2 . 2 En d- to -end s ho r tes t path comput a t io n
In this mode, an end-to-end shortest path spanning multiple areas/ASs is computed out using a list of
distributed PCEs (Path Computation Element). This list of PCEs may be configured statically.
Notion of PCE: An LSR is said to be a PCE (Path Computation Element) when it has the ability to
compute an inter-area/AS TE LSP path for a TE LSP it is not the head-end of. Ideal candidates to
support a PCE function are ABRs in the context of inter-area TE (since each ABR has the view of two
of more areas in its TED) and ASBRs in the context of inter-AS TE.
Generally, there are 4 steps in the end-to-end shortest path computation:
1). Step 1: discovery by the head-end LSR of a PCE capable of serving its path computation request.
2). Step 2: a path computation request is sent to the selected PCE. This PCE relays this request to the
next PCE in the list iteratively until that the request reaches the PCE in the destination area/AS.
3). Step 3: the PCE in the destination area/AS computes the paths to the destination LSR in its own
area/AS and returns these paths to the last PCE in a path computation reply.
4). Step 4: The PCE receiving this reply will compute the paths from its own area/AS to the destination
LSR with the help of the received reply. After that, it will return these results too. This progress iterates
until the reply reach the head-end LSR which also means the path has been computed.
Figure3. End-to-end shortest path computation
Then once the optimal end-to-end path is computed, the head-end LSR sets up the inter-AS TE using a
complete list of ERO if the various PCEs have provided the list of ERO or some loose hops in the
contrary.
As opposed to the first scheme, an end-to-end shortest path obeying the set of required constraint is
computed. In that sense, the path is optimal.
4 .3 O t h er me c ha ni s ms
In [14], an inter-area TE scheme using hierarchical link state routing is proposed. In this scheme, the
hierarchical routing module provides a framework for aggregating and summarizing link state
information relating to a particular area, and advertising it to nodes in other areas. The route is
calculated in terms of the summarized topology advertised by the nodes running the hierarchical
routing protocol. PNNI is such a hierarchical routing protocol that has been deployed in many ATM
networks. [15]
However, there are some drawbacks in the hierarchical routing models. As discussed above, a summary
of the information in the higher level is passed down to the lower level nodes. In large networks, this
summary may be too large for some of the low-level nodes to maintain. On the other hand, lacking of
applications in IP network is another shortcoming of the hierarchical routing models.
4 .4 A s i mpl e c ompar i s on
BGP policy based mechanism is a coarse scheme which makes it unable to control the traffic accurately.
It will be a good plan to deploy this mechanism when we just want to balance the incoming or outgoing
traffic, because it only needs some policy configured.
MPLS per-area/AS mechanism is a good mechanism for its simple idea which extends current
MPLS-TE mechanism to support inter-area/AS TE. It is the most possible model which will be
deployed in the near future In spite of that it can’t provide the shortest path which is the advantage of
the MPLS end-to-end mechanism. Of course, MPLS end-to-end mechanism is far from perfect. This
mechanism may lead to long delay, and the PCE may be the bottleneck of the whole system. Even
though, it will be an excellent scheme if these problems have been resolved completely. Now most of
the researches focused on the MPLS-base scheme.
PNNI is good enough in ATM networks, but lack of experience in internet makes it not a feasible
scheme in the near future.
5 Conclusions
While intra-area/AS TE is relatively well defined, providing this function in an inter-area/AS scenario
is significantly more challenging. However, it is likely to become an increasing important issue as
carrier networks expand and customers’ end-to-end performance expectations grow.
As we have seen, there are several mechanisms which are proposed to tackle this issue. Different
mechanisms are based on different strategies, and each has its own advantages and drawbacks. So it is
possible that some of these solutions are likely to co-exist in the future and carriers may implement a
combined strategy.
Re f e re nce s
[1] Awduche, Overview and Principles of Internet Traffic Engineering, rfc3272, May 2002.
[2] Awduche, Requirement for Traffic Engineering over MPLS, rfc2702, September 1999.
[3] Katz, yeung, traffic engineering (TE) extensions to OSPF version 2, rfc3630, September 2003.
[4] Smit, li, IS-IS extensions for Traffic Engineering, rfc3847, January 2004.
[5] Steve. Uhlig, Implications of Interdomain Traffic Characteristics on Traffic Engineering, 2002
[6] JL le Roux, JP. Vasseur, Jim Boyle, requirements for inter-area MPLS Traffic Engineering,
, June 2004.
[7] Y. Rekhter, T. Li, A Border Gateway Protocol 4 (BGP-4), , November
2003.
[8] Tracie E. Monk, Inter-Domain Traffic Engineering: principles and case examples, IXIA, June 2002.
[9] B. Quoitin, Interdomain traffic engineering with BGP, 2002
[10] Nick. Feamster, guidelines for Interdomain Traffic Engineering, 2003.
[11] Inter-area traffic engineering, CISCO whitepaper, 2004.
[12] Raymond zhang, JP. Vasseur, MPLS inter-AS Traffic Engineering requirements, draft-ietf-tewg
, June 2004.
[13] JP. Vasseur, Arthi. Ayyangar, inter-area and inter-AS MPLS Traffic Engineering, draft-vasseur
, February 2004.
[14] Ben Wright, inter-area routing, path selection and traffic engineering, Data Connection Limited,
November 2003.
[15] ATM forum, Private Network-Network Interface specification, PNNI .
