NOTE: For a background on
MPLS, please see the white paper “Using MPLS to Improve Performance” in the
X issue of Boardwatch or online at http://www.ispworld.com/src/WP_MPLS_121100a.htm.
You’ve heard all about the benefits of MPLS (Multi-Protocol Label Switching). Now, you’re eager to look at actually implementing it on your own network. So … what next?
The Wrong Reasons for Choosing MPLS
First, you’ll need to ask yourself why it is that you’re looking to implement MPLS on your network. Since moving to MPLS is a complicated and sometimes expensive procedure, it’s important to make sure that you’re not doing it to achieve something that can be implemented in some other way with less hassle. Some things that are advertised as benefits of the technology are either exaggerated or can be more trouble than they’re worth if that’s all you’re looking for.
For example, are you choosing MPLS because you think:
* “MPLS is faster?
’” T echnically, it is – but
only significant speed gain is
that packets don’t need to enter
the layer three lookup queues of the routers they pass through. Unless
these routers are underpowered or overburdened, the time savings of skipping
this step is often less than a millisecond. While MPLS does provide
a speed benefit, the improvement is probably not enough to
justify by itself the time and effort of
* “There are fewer ‘hops’ on an MPLS network?”
While a n
MPLS network show s
fewer hops because of
the abovementioned skipping of layer-three lookups. However, while
these hops don’t show on a traceroute, they are still there in
that the packets must pass
through each router (even if they aren’t staying there as long). MPLS doesn’t
automagically make your entire network physically meshed, so this alone
shouldn’t be enough justification for the switch to MPLS.
* “MPLS is more secure than other architectures?”
It currently does – but
that is in some ways a false sense of security. MPLS does not encrypt
packet streams in transit or provide authentication services as IPsec does. Its
security comes through the fact that it adds an MPLS “shim” will
fail. However, this “security through
obscurity” is by no means true security, and it is probably only a matter of
time before MPLS packet sniffers are available.
* “MPLS is ‘cleaner’ than routing?” This is true
MPLS’s traffic engineering capabilities potentially enable better network
traffic designs and provide better packet loss control than traditional
routing. MPLS also
decrease s “jitter,” or differences in packet
delay , which cause
packets to arrive out of order. Jitter is especially
problematic with real-time applications like VoIP or Internet video, so
technology like MPLS that acts like a traditional switched network is
However, if configured incorrectly or incompletely, MPLS (especially using the RSVP signaling protocol; see more on this later) can create very messy networks that may contain unintentionally asymmetric paths and even loops that effectively black-hole packets. While misconfigurations can create big problems with any network architecture, it is important to note that MPLS will not magically make networks clean without careful planning.
The Right Reasons for Choosing MPLS
However, there are a number of very good reasons to be considering MPLS – features and functionality that MPLS alone can provide, or that is makes much easier than alternate solutions. For example:
* Traffic engineering (TE) capabilities – MPLS can provide you with powerful TE capabilities, allowing you to explicitly direct packets through the paths of your choice and make the best use of your available bandwidth.
* Quality of Service (QoS) and Classes of Service (CoS) – MPLS offers the ability to implement QoS
guarantees by setting “hard” bandwidth reservations on circuits, allowing you
to guarantee a pre-set amount of bandwidth for a specific connection (although
reserving bandwidth does not also guarantee packet success). Classes of Service
can also be defined in MPLS by using the “experimental” (unused) bits of an
MPLS header to define priority levels for certain packets.
Another advantage is that
MPLS can also be configured to read ATM “precedence” bits, allowing the
seamless transitioning of priority levels from an ATM network to an MPLS-based
MPLS can also make use of Differentiated Service (Diff-Serv) technologies, allowing QoS/CoS based on layer-three criteria, such as source and/or destination addresses. In the future, MPLS should be able to use Integrated Services (Int-Serv) when standards for it are eventually codified and router hardware is built to take advantage of it. Int-Serv will provide the ability to differentiate traffic at the layer-four level and higher – potentially enabling QoS/CoS based on port or protocol (HTTP, SMTP, FTP, etc.) or other advanced criteria.
* ATM/LAN/Frame replacement – If you want or need to replace legacy technology networks with a scalable IP-based platform, MPLS is an excellent choice. The MPLS specification was largely based on ATM for its original design, and so offers nearly all of the functionality that ATM or Frame Relay provides, as well as its own unique new features.
Is it Worthwhile for Your Network?
After looking at the above, think carefully about whether your needs can be fulfilled by other, easier solutions. If you decide to move ahead with MPLS, you’ll also need to think about the size and topology of your network.
If your network has less than five nodes – or if its
is not ring-based, MPLS
probably won’t be worth the effort. For a small number of nodes, the advantage
in moving between them via MPLS paths is scarcely noticeable. Likewise, if your
network has a serial topology or is “hub-and-spoke” based, the path your
packets will take has largely already been determined by your physical
topology, and MPLS can’t do much to change that – so why bother?
One of primary drivers for the creation of MPLS was traffic engineering (TE), and that remains much of its focus today. If you have no real need for TE, you’ll be missing out on much of what MPLS offers. IP networks requiring the ability to direct packets along specific links throughout their network (which is fairly easy with ATM or Frame Relay but significantly harder with IP) will get by far the most benefits out of MPLS.
Assessing the Requirements
So, you’ve gone through all of the above considerations, and you’ve found that MPLS is a good match for your needs. Before moving ahead with MPLS implementation, you’ll want to take a close look at your network’s current internal architecture and equipment, and determine whether you’ll need to change that to implement MPLS (and hence how much it might cost).
First, take a look at the IGP (Interior Gateway Protocol)
that your network is currently using to make internal routing decisions,
because MPLS can’t be used with all of them. This may seem like a non-sequitur,
since the MPLS
effectively replace your IGP, right? While this is functionally true, MPLS still requires you to use an IGP a.) so that MPLS
can “discover” your network and build its initial LSPs
(if you aren’t using RSVP and explicit paths; see more on this below), and b.)
as a reference so that it can periodically refresh and update its view of your
internal network topology.
If your IGP is EIGRP or RIP v2,
you’ve got problems (other than just your problems in general
if you’re using EIGRP),
and you’ll need to change your IGP if you want MPLS. The only IGPs which currently
support MPLS (i.e., they know how to propagate labels and support MPLS’s
traffic engineering functions) are OSPF (Open Shortest Path First) and IS-IS
(Intermediate System-Intermediate System). Currently, the state of
vendor implementations of ISIS/MPLS are more mature and less potentially
problematic than OSPF/MPLS; but this should change over time.
At this point, we should take a brief detour and talk about your choices of signaling protocols in MPLS, and how they affect the services you can provide. MPLS signaling protocols are used to “signal” the LSPs from each router to the next. You can use RSVP, LDP (Label Distribution Protocol), or both.
RSVP uses “hard” signaling: it reserves resources along explicit paths set by you. This is essential for traffic engineering, since it allows you to reserve bandwidth and specify the exact router-to-router path that certain packets take to get from point A to point B.
However, it can also be tricky: since you are defining
explicit paths, you must fully mesh your network with RSVP. If you don’t
explicitly define a path for packets to get from point Z to point Q,
is no way for them to get there. Likewise,
you’ll want a backup path defined as well, or packets will otherwise be unable
to get there if their primary LSP fails.
LDP, however, uses “soft” signaling – it uses its knowledge
of your network to automatically compute a series of “best-path” LSPs across
your network, much as an IGP would
Next, you’ll need to determine which of the “flavors” of MPLS you want or need, since they provide varying functionality and have varying requirements.
* MPLS – “Plain Vanilla” MPLS, the setting up of Labels and Label-Switched Paths (LSPs), has pretty scant requirements. However, basic MPLS in and of itself provides very few benefits outside of a laboratory or learning environment. In a real-world situation, you’ll probably be looking at one or more (they can be used together) of the following options.
Its hardware/software requirements are
FOO, BAR and BAZ.
* MPLS-TE – This is MPLS designed specifically to enable traffic engineering and all its associated goodies. MPLS-TE also requires you to run RSVP as your signaling protocol; if you want any of the other MPLS versions as well, then you’ll need to piggyback LDP on top of your RSVP signaling (not particularly difficult, but more complex).
Its hardware/software requirements are
FOO, BAR and BAZ.
* MPLS Using RFC 2547 bis – Used to create IP VPNs over MPLS. These can be very desirable, since there is no need for employ additional VPN hardware (they use “virtual routing tables” at the edge between you and your VPN-using customer, and as a result don’t require your customer to have MPLS enabled although they do require the customer to be using BGP). MPLS-2547 bis requires LDP signaling on your network.
Its hardware/software requirements are FOO,
BAR and BAZ.
* MPLS (Martini and Kompella drafts) – These related MPLS versions allow the layering of layer two technologies (like ATM or Frame Relay) over MPLS. By doing this, you can build clouds to provide seamless ATM, Frame, etc. services on top of your IP network.
Its hardware/software requirements are FOO, BAR and BAZ.