MPLS
DiffServ-aware
Traffic Engineering
Ina
Minei, Software
Engineer
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
408 745 2000 or 888 JUNIPER
www.juniper.net
Part Number: 200048-001
1. Executive
Summary Differentiated Services (DiffServ) enables
scalable network designs with multiple classes of service. MPLS traffic
engineering (TE) enables resource reservation, fault-tolerance, and
optimization of transmission resources. MPLS DiffServ-TE combines the
advantages of both DiffServ and TE. The result is the ability to give
strict Quality of Service (QoS) guarantees while optimizing use of
network resources. The QoS delivered by MPLS DiffServ-TE allows network
operators to provide services that require strict performance
guarantees such as voice and to consolidate IP and ATM/FR networks into
a common core.
2. Introduction
In today’s competitive market, service
providers seek to increase their revenues while at the same time
keeping capital and operational expenditures down. From a practical
point of view, this means (1) providing new revenue-generating
services, such as voice and guaranteed bandwidth for business-critical
applications and (2) migrating Layer 2 services from legacy networks
such as ATM and FR into the IP network infrastructure, thus eliminating
the need to maintain several physical networks. The challenge lies in
the fact that both the new and the legacy services usually require
strict service level agreements (SLAs).
The SLAs define the service quality experienced by
traffic transiting the network and are expressed in terms of latency,
jitter, bandwidth guarantees, resilience in the face of failure, and
downtime. The SLA requirements translate to two conditions: (1)
different scheduling, queuing, and drop behavior based on the
application type; and (2) bandwidth guarantees on a per-application
basis.
To date, service providers have rolled out
revenue-generating services in their networks using DiffServ alone. By
assigning applications to different classes of service and marking the
traffic appropriately, the first condition was met. However, to receive
strict scheduling guarantees, it is not enough to mark traffic
appropriately. If the traffic follows a path with inadequate resources
to meet performance characteristics such as jitter or latency
requirements, the SLAs cannot be met. In principle, service providers
could solve this problem by using overprovisioning to avoid congestion
altogether. Besides being wasteful with regards to resource
utilization, this approach of “throwing bandwidth at the
problem” cannot provide any guarantees when congestion is
caused by link and/or node failures.
MPLS traffic engineering (MPLS-TE) sets up
label-switched-paths (LSPs) along links with available resources, thus
ensuring that bandwidth is always available for a particular flow and
avoiding congestion both in the steady state and in failure scenarios.
Because LSPs are established only where resources are available,
overprovisioning is not necessary. Further optimization of transmission
resources is achieved by allowing LSPs not to follow the shortest path,
if the available resources along the shortest path are not sufficient.
An added benefit of MPLS is that built-in mechanisms such as link
protection and fast reroute provide resilience in the face of failure.
The catch is that MPLS-TE is oblivious of the class of service (CoS)
classification, operating on the available bandwidth at an aggregate
level across all classes.
MPLS DiffServ-TE makes MPLS-TE aware of CoS, allowing
resource reservation with CoS granularity and providing the
fault-tolerance properties of MPLS at a per-CoS level. By combining the
functionalities of both DiffServ and TE, MPLS DiffServ-TE delivers the
QoS guarantees to meet strict SLAs such as the ones required for voice,
ATM, and Frame Relay.
Note that even if resources are reserved on a per-CoS
basis, and even if traffic is properly marked to conform to the CoS
appropriate for the application, the SLAs still cannot be guaranteed
unless further mechanisms, such as policing and admission control, are
set in place to ensure that the traffic stays within the limits assumed
when the resource reservation was made.
Section 3 of this paper introduces DiffServ and TE,
presenting a few application scenarios and discussing how each of these
technologies alone cannot provide a satisfactory solution. Section 4
gives an in-depth view of the MPLS DiffServ-TE technology as defined in
the IETF standards. Section 5 highlights some of the advantages of the
JUNOS DiffServ-
TE implementation.
3. DiffServ and TE – The Current Tools
This section introduces the two building blocks of MPLS
DiffServ-TE, DiffServ and TE, and explains why it is necessary to
combine them in order to guarantee QoS in practical application
scenarios.
3.1 DiffServ
The initial efforts to provide quality of service (QoS)
in IP networks were based on a per-
application-flow model (IntServ), in which individual applications
requested QoS guarantees directly from the network. The RSVP signaling
protocol was used to distribute the requests to the nodes in the
network, and state needed to be maintained for each flow at every hop
along the way. With millions of flows traversing IP networks, this
approach proved to be unscalable and overly complex, and a more
“coarse-grained” model was developed in the form of
DiffServ. DiffServ approaches the problem of QoS by dividing traffic
into a small number of classes and allocating network resources on a
per-class basis. To avoid the need for a signaling protocol, the class
is marked directly on the packet, in the 6-bit DiffServ Code Point
(DSCP) field. The DSCP field is part of the original type of service
(ToS) field in the IP header. The IETF redefined the meaning of the
little-used ToS field, splitting it into the 6-
bit DSCP field and a 2-bit Explicit Congestion Notification (ECN)
field, as shown in figure 1.
Figure 1: ToS and
DSCP + ECN
The DSCP
determines the QoS behavior of a packet at a particular node in the
network. This is called the per-hop behavior (PHB) and is expressed in
terms of the scheduling and drop preference that a packet experiences.
From an implementation point of view, the PHB translates to the packet
queue used for forwarding, the drop probability in case the queue
exceeds a certain limit, the resources (buffers and bandwidth)
allocated to each queue, and the frequency at which a queue is
serviced. The IETF defined a set of 14 standard PHBs as follows:
- Best
effort (BE). Traffic receives no special
treatment.
- Expedited
forwarding (EF). Traffic encounters minimal delay and low
loss. From a
practical point of view, this means a queue dedicated to EF traffic for
which the arrival rate of packets is less than the service rate, so
delay, jitter and loss due to congestion is unlikely. Voice and video
streams are typical examples of traffic mapped to EF: they have
constant rates and require minimal delay and loss.
- Twelve assured
forwarding (AF) PHBs. Each PHB is defined by a queue
number and a drop
preference. The IETF recommends using four different queues with three
levels of preference each, yielding a total of twelve distinct AF PHBs.
The convention for naming the AF PHBs is AFxy, where x is the queue
number and y is the level of drop preference. Thus, all packets from
AF1y will be put in the same queue for forwarding, ensuring that
packets from a single application cannot be reordered if they differ
only in the drop preference. The AF PHBs are applicable for traffic
that requires rate assurance but that does not require bounds on delay
or jitter.
Although the IETF defined recommended DSCP values for
each
of the standard PHBs, vendors allow network operators to redefine the
mapping between the DSCP and the PHB, and to define non standard PHBs.
The important thing to keep in mind is that once the packet is marked
with a particular DSCP value, its QoS treatment is defined at each hop
it crosses. Thus, to ensure consistent QoS behavior, it is imperative
to maintain consistent DSCP-to-PHB mappings. This requirement brings us
to the notion of a DiffServ domain, which is a set of DiffServ capable
nodes with 1) a common set of defined PHBs, 2) the same DSCP-to-PHB
mappings, and 3) a unified service provisioning policy. Usually a
DiffServ domain operates under a single administrative authority. At
the edge of a DiffServ domain, the traffic is marked with the DSCP
values that yield the desired per hop behavior and ultimately the
desired QoS.
Figure 2: A DiffServ domain. Voice traffic is marked at
the entrance to the domain with EF, data traffic with BE. Every hop
examines the DSCP bits and maps the traffic to a different
queue.
To
summarize, DiffServ provides differential forwarding treatment to
traffic, thus enforcing QoS for different traffic flows. It is a
scalable solution that does not require per-
flow signaling and state maintenance in the core. However, it cannot
guarantee QoS if the path followed by the traffic does not have
adequate resources to meet the QoS requirements.
6. Conclusion
The DiffServ-TE technology defined by the
IETF provides
strict service guarantees for different traffic types. Such guarantees
allow service providers to deploy new services and achieve better
resource utilization for existing services. The JUNOS implementation
offers a standards-based, interoperable, and scalable implementation of
DiffServ-TE, along with unique tools for ensuring that traffic stays
within the limits of the resources that were reserved for it.
7.
References
[DSTE- MAM] - Le Faucheur F., Lai K., Maximum Allocation
Bandwidth Constraints Model for DS-TE -
draft-ietf-tewg-diff-te-mam-01.txt
DSTE-PROTO] - Le Faucheur F. et al,
Protocol extensions for support of DS-aware MPLS TE -
draft-ietf-tewg-diff-te-proto-05.txt
[DSTE-RDM] - Le Faucheur F. et al,
Russian Dolls Bandwidth Constraints Model for DS-TE -
draft-ietf-tewg-diff-te-russian-04.txt
[FRR] - Pan P. et al, Fast
Reroute Extensions to RSVP-TE for LSP Tunnels - draft-ietf-mpls-
rsvp-lsp-fastreroute-03.txt, work in progress
[ISIS-TE] –
Smit H., Li T., IS-IS extensions for Traffic Engineering -
draft-ietf-isis-traffic-05.txt
[MPLSTECH] – Davie B., Rekhter
Y. , MPLS Technology and Applications
[OSPF-TE] – Katz D.
Yeung D., Traffic Engineering Extensions to OSPF - draft-katz-yeung-
ospf-traffic-10.txt
[RFC2475] – Blake S. et al, An
Architecture for Differentiated Services – RFC 2475
[RFC2702]
- Awduche D. et al, Requirements for Traffic Engineering Over MPLS
– RFC 2702
[RFC3031] - Rosen E. et al, Multiprotocol Label
Switching Architecture – RFC 3031
[RFC3036] –
Anderson L. et al, LDP Specification – RFC 3036
[RFC3209] -
Awduche D. et al, RSVP-TE: Extensions to RSVP for LSP Tunnels - RFC
3209
[RFC3270] - Le Faucheur F. et al, MPLS Support of Diff-Serv - RFC
3270
[RFC3468] – Anderson L., Swallow G., The Multiprotocol
Label Switching (MPLS) Working Group decision on MPLS signaling
protocols – RFC 3468
[RFC3564]- Le Faucheur F. et al,
Requirements for Support of Differentiated Services-aware MPLS Traffic
Engineering - RFC 3564
Acknowledgements
The author would like to thank
Yakov Rekhter, Julian Lucek and Amir Tabdili for their comments,
suggestions and insight; Mike Capuano, Hannes Gredler, Nischal Sheth
and Chelian Pandian for their review; Aviva Garret for editing; and
Susan Lane for production support.
|