|
MPLS and
multilayer routing techniques in general allow efficient packet
forwarding to enable high-speed data transfer. Although in the
case of MPLS the link layer is not specified, the approaches all
provide a scenario where it is possible to fully integrate and
couple traditional datagram routing concepts with link-layer
switching devices supported within the telecommunications industry.
MPLS functionality is now being supported directly within hardware,
with routing and switching mechanisms combined at the chip level in
order to provide integration at high speeds, thus increasing its
viability.
MPLS-capable
devices are able to provide additional functionality beyond the
best-effort packet forwarding found within a gigabit router. This
flexibility means that in principle it is possible to support ideas
such as QoS differentiation. The fundamental separation between
forwarding class and label assignment provides a great deal of
flexibility. While packets within a class are to be processed in the
same way, this approach means that traffic can be engineered to
varying extents.
Alone, IP does
not lend itself to the idea of traffic engineering, that is, the
ability to manage bandwidth and routes in order to provide equal
loading of resources within the network. Until now, it has been
reliant on other technologies (e.g., ATM) and associated
encapsulation techniques in order to offer this functionality. MPLS
provides support for traffic engineering through the deployment of
constraint-based routing. Stemming from the idea of QoS routing,
constraint-based routing not only provides routes that are able to
meet the QoS requirements of a flow, but also considers other
constraints including network policy and usage. Label distribution
protocols supporting label switching for end-to-end constraint-based
paths allow traffic characteristics to be described in terms of peak
rate and committed rate bandwidth constraints, along with a
specified service granularity (which can be used to define the delay
variation constraint).
Explicit routing
(a subset of constraint-based routing) allows the specification of
the route to be taken across the network. This is enabled within
MPLS by allowing a label to represent a route, without the overhead
of source routing found within normal IP forwarding (making it too
resource-intensive for use in most circumstances). Different paths
can be selected in order to allow traffic engineering to be carried
out effectively, allowing network load to be balanced in a far more
flexible manner than manually configuring virtual circuits (as with
other primitive approaches to engineering IP traffic). The
engineering of paths in such a way implies a simple mechanism for
measuring traffic between edge network devices making use of an LSP.
In Internet
service provider (ISP) environments where service differentiation is
likely to mean users will be charged in terms of the network QoS
exploited, the ability within the MPLS architecture to specify
per-host and per-user label assignment is likely to be very useful
for billing purposes.
Figure 14 - The
traffic engineering required to override the shortest path route.
Figure 15 -
Explicitly routed LSPs as tunnels enable traffic engineering.
One service
currently delivered using a connection-oriented network is a virtual
private network (VPN). Such networks are useful in providing the
internal network to a distributed organization. A typical example is
the interconnection of several remote field offices with a corporate
headquarters. Such a network may not have Internet access and has
stringent privacy requirements on its traffic. This application is
frequently addressed today using frame relay/ATM.
In an MPLS
network, a VPN service could be delivered in a variety of ways. One
way would be direct emulation of frame relay, ATM. Another approach
would be to deliver the service using MPLS-aware subscriber
equipment. Either approach allows a service provider to deliver this
popular service in an integrated manner on the same infrastructure
they use to provide Internet services.
Figure 16 - An IP
VPN ingress LER.
|
