Implementing MPLS on Your Network (Part 1): What You Should Know Before You Start

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.