Side_1_360

(Dana P.) #1

3.2.4 Routing QoS and Best-effort Traffic
QoS routed and best-effort traffic will coexist in
most networks, and this may cause a conflict of
interest between the two. If QoS traffic were
supported, a goal would be to admit as many
QoS flows into the network as possible. At the
same time, another goal would be to optimize
the throughput and responsiveness of best-effort
traffic. Generally speaking, QoS traffic is not
affected by best-effort traffic due to resource
reservation. However, if the overall traffic in the
network is misjudged, the throughput of best-
effort traffic will suffer. Links with light QoS
traffic may for example have heavy best-effort
traffic. These links will often be considered good
candidates for additional QoS flows, causing the
congested best-effort traffic to become even
more congested.


3.3 Policy-based Routing

Policy-based routing is regarded as another sub-
set of the more general constraint-based routing
concept.


The most common reason to do policy routing is
to accommodate “acceptable-use policies” and to
select providers.


The requirement for policy routing appeared
with the “commercialisation” of the Internet.
Users of the early Internet did not care much
about the route that was used for carrying their
packets. The network was perceived “free”, a
“public good” that should simply be shared
evenly. But commercial users should not benefit
from public subsidies, and thus could not use
the “default” route through the “academic” back-
bones. They had to alter the shortest path to take
a policy requirement into account.


The requirement for policies then became more
and more sophisticated. Merely finding one
acceptable route is not enough when the users
are charged for their traffic. A user may e.g.
want to switch to another provider between 1:00
PM and 3:00 PM to benefit from better rates.


The principles of policy-based routing are quite
similar to those of QoS routing, with differences
in the service requirements.


The past attempts at policy routing have not
been successful. There are lots of business and
technical difficulties that are still not solved.
MPLS, which we discuss in Chapter 4, could
be a good candidate to implement policy routing
successfully.


4 Routing in MPLS


MPLS is a technique promoted by the IETF that
integrates the label-swapping paradigm with net-
work layer routing. A label switched path (LSP)
is the route that data follows between the ingress
and egress of an MPLS domain.

Assigning IP traffic to MPLS hop-by-hop LSPs
may improve IP performance since label switch-
ing requires less processing than traditional IP
forwarding. However, it is the MPLS ability to
provide for constraint-based routed LSPs that is
expected to be most important to IP traffic engi-
neering. The general concept of constraint-based
routing is described in Chapter 3.

In [RFC2702] the “traffic trunk” concept is used.
A traffic trunk is an aggregation of traffic flows
of the same class, which are placed inside an
LSP. A traffic trunk is an abstract representation
of traffic to which specific characteristics can be
associated. Traffic trunks are routable objects
(similar to e.g. ATM VCs). There is a distinction
between a traffic trunk and the path (LSP)
through which the traffic traverses. A traffic
trunk can be moved from one path to another.
In practice, the terms LSP and traffic trunk are
often used synonymously. The term LSP tunnel
is commonly used to refer to the combination of
traffic trunk and explicit LSPs in MPLS. In this
chapter, the terms LSP and ER-LSP are used,
although the term LSP tunnel might be more
appropriate in some places.

An MPLS traffic engineering model consists of
four basic functional components:


  • Network state information dissemination;

  • Path management;

  • Traffic assignment;

  • Network management.


Network state information dissemination and the
path selection component of path management
are the parts that constitute the routing aspect of
MPLS TE.

4.1 Network State Information

Dissemination

In support of constraint-based routing, IETF is
defining IGP traffic engineering extensions that
include link attributes as part of each router’s
LSA, see e.g. [OSPF-TE] and [ISIS-TE]. Rele-
vant link attributes include:


  • Link type;

  • Traffic engineering metric;

  • Maximum bandwidth;

  • Maximum reservable bandwidth;

  • Unreserved bandwidth;

  • Resource class/colour.

Free download pdf