By Mike Gibbs and Jeffrey Carl
NOTE: For a background on
MPLS, please see the white paper “Using MPLS to Improve Performance” in the X January(?) 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?’” Technically, it is could
be, though some camps would disagree and say that the process is slower thenhere
is some debate over whether MPLS is really faster than current IP
routing implementations. – but
Tthe
only significant MPLS offers a speed gain is
thatbecause packets don’t need to enter
the layer three lookup queues of the routers they pass through, but
unless these routers are underpowered or overburdened, the time savings of
skipping this step is often less than a millisecond. butHowever, the packet
that initializes the MPLS tunnel never gets switched, and must be routed, so
this could cuase a brief stutter in the traffic flow. Unless
these routers are underpowered or overburdened, the time savings of skipping
this step is often less than a millisecond. While MPLS does couldcan provide
a speed benefit, the improvement is probably not enough by itself to
justify by itself the time and effort of
adopting MPLS.
* “There are fewer ‘hops’ on an MPLS network?” While Aan
MPLS network couldcan shows
fewer hops, when a traceroute is
performed across it if propaogation of packet
TTLs (Time To Live) hasve been turned on acrosson the MPLS network because of
the abovementioned skipping of layer-three lookups. However, while
these hops don’t show on a traceroute, they are still there in
the since
sense 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 doesMPLS can be considered “secure”
based–
depending on what you consider safe
– butyour understanding
of security, – but
thatit’s probably is in some ways it can
be 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” (addition)
to the headers of packets, and thus current “packet sniffers” looking for
routing headers on packets passing through backbone links can get confused and possiblywill
fail
to read or understand the packet. 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 , based(depending on your
definition of “clean”), since
MPLS’s traffic engineering capabilities potentially enable better network
traffic designs and provide better packet loss control than traditional
routing. By enabling Quality of Service (QoS) or Class of
Service (CoS) features in MPLS, it MPLS can also
decreases “jitter,” or differences in packet
delay, which that cause
packets to arrive out of order by enabling Quality of Service (QoS) or Class of
Service (CoS) features in MPLS. 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
especially helpful.
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 design and, planning,
plus regular maintenance and upkeeping.
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 and flows 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
network.
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
topology is not ring-baseddoes not lend itself well to
traffic engineering,
or fully meshed, logically, 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 LSPs LDP or RSVP databases should
effectively replace your IGP, right? While this is functionally true for
labeling, MPLS still requires you to use an IGP a.) so that MPLS
can “discover” your network and build its initial Label Switched
Paths, or 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 IGRP, EIGRP or RIP v1 or 2,
you’ve got problems (other than just your problems in general if
you’re using one of the above if you’re using EIGRP),
and you’ll need to change your IGP if you want MPLS. The only IGPs which that 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 arestates 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 as well as build a label databse for all known routes for each router. You can use RSVP (Resource Reservation Protocol), 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. It does this by creating an actual interface or tunnel on the router at the ingress and egress points of the path, allowing for all interface modifications (e.g., ACLs, CARs, etc.).
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, it will
build the path loosely, or dynamically, but there is then no good way to
traffic
manage that path, since it is built based on IGP
paths and not necessarily the best traffic untilizxation path.there simply
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. Again, if this is builtd loosely, that backup path will also be built
loosely, which could cuause unknown
congestion if it is not monitoered
well.
. This creates an actual interface or tunnel on the
router at the ingress and egress points os the path, allowing for all interface
modifications (aka ACLs, CARs, etc.).
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.
.LDP does not
reserve any form of bandwidth on the interfaces or routers, and relies on
offline traffic engineering for congestion issues;, it
also does not nor does it have a defined interface on
which you can to places ACLs, etc onto and
other interface modifications.
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 BAZan Jjuniper router currently made, these beingfrom
the M5/10/20/40/160 series. It is
recommended that JunOS 5.2 is used as the main OS for these routers.
Cisco routers have more of a restrictions, and it is
recommended to use the current IOS in
the S train to allow for any bug fixes and new features. The hardware
restrictions are as follows:
· Cisco 36x0 series (POS interfaces only)
· Cisco 45x0 series (POS interfaces only)
· Cisco 6900 series
· Cisco 7200 series
· Cisco 7500 series
· Cisco 7609 series (OSM interfaces only)
· Cisco 8800 series
· Cisco 12000 series
* MPLS-TE – This is MPLS designed specifically to enable traffic engineering and all its associated goodies. MPLS-TE also requires you to run RSVP-TE 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-TE signaling (not particularly difficult, but more complex).
Its hardware/software requirements are FOO, BAR and BAZ.the same as basic
MPLS, with the addition of needing RSVP-TE enabled
on the network. To enable RSVP-TE you will also
need the appropriate IGP hooks
(feature sets).
This would mean that For example, ifs you are using OSPF, you must
enable OPSF-TE to allow for the correct features for RSVP-TE.
* 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). As of this writing, iIt does not, yet, support IPSec
encryption in the classic nNetwork authentication scheme, but
there are plans by many vendors to resolve this issue. MPLS-2547
bis requires LDP signaling on your network.
Its hardware/software requirements,
beyond MPLS requirements, wiTo
use MPLS-2547 bis, you will need ll be to implement MP-BGP on the
network.
This entails building separate router reflectors just for RFC
2547 services and routes, and configuring VPNv4 on all of the BGP instances
that clients will have contact with for this service. 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 The requirements for
this, beyond the basic MPLS
requirements, would beare to enable
LDP on the edge of the network (assuming you did not already have it enabled
instead of RSVP) and then apply the correct designs (, based on your router vendor of
choice). Juniper
and Cisco have different ways to achieve the same thing. Cisco can support
Ethernet, and AAL5 through MPLS
today, with more to come., where as Juniper has used
their CCC technology to support all forms of Layer 2 technologies through MPLS.
Please find your friendly neighborhood Cisco
or Juniper Sales Engineer if
you need help configuring these features.are FOO, BAR and BAZ.