Deploying MPLS for Enterprise Networks - United States · The Essential Guide to Deploying MPLS for Enterprise Networks ... MPLS network and to use the capabilities of the network

White Paper

The Essential Guide to Deploying MPLS for Enterprise Networks

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408 745 2000 or 888 JUNIPER www.juniper.net Part Number: 200183-001 May, 2006

Daniel Backman Systems Engineer Troy Herrera Sr. Field Solutions Manager


2 Copyright © 2006, Juniper Networks, Inc.

Contents

Contents...................................................................................................................................................2 Executive Summary ...............................................................................................................................3 Where and Why is MPLS Appropriate in the Enterprise?................................................................3 MPLS: Build or Buy?..............................................................................................................................4

Private MPLS Networks...............................................................................................................5 Public MPLS Networks ................................................................................................................5 Hybrid Private and Public MPLS Networks .............................................................................6

MPLS Network Design Principles .......................................................................................................7 Basic Network Design ..................................................................................................................7 Traffic Separation and Engineering ............................................................................................9 Six Process Steps for Migrating to MPLS .................................................................................11

Step #1: Upgrade IP to MPLS Capable............................................................................11 Step #2: Build the MPLS Layer.........................................................................................11 Step #3: Configure MPLS VPNs.......................................................................................12 Step #4: Fold Networks into the MPLS VPNs................................................................15 Step #5: Traffic Engineer the Network............................................................................16

Application Considerations .......................................................................................................17 Security Requirements.......................................................................................................17 Data Center Considerations..............................................................................................18 Application Performance ..................................................................................................18 Mapping IP QoS in the LAN to MPLS QoS ....................................................................19 VoIP and Video QoS and Performance ...........................................................................20 Compliance Requirements................................................................................................20

Routing Protocol Considerations: Migrating EIRGP to OSPF...............................................21 When to Use IS-IS...............................................................................................................22

MPLS based resiliency and Fast Re-Route...............................................................................22 MPLS Provisioning and Management......................................................................................23

Provisioning Planning for MPLS Deployment...............................................................23 Management Planning.......................................................................................................24

Connecting to a Service Provider.......................................................................................................25 Using VPLS ..................................................................................................................................25 Tunneling over IP with GRE......................................................................................................26 Carrier’s Carrier Architecture....................................................................................................26 Terminating LSPs and Connecting to an MPLS WAN...........................................................27

Summary ...............................................................................................................................................27


Copyright © 2006, Juniper Networks, Inc. 3

Executive Summary MPLS has received broad market attraction in service provider networks and now enterprises are increasingly connecting the distributed and extended enterprise via MPLS-based Wide Area Networks (WANs) or deploying their own private MPLS networks. MPLS brings the benefits of circuits to packet based IP communications providing consolidation, control, and network resiliency. Perceived as complex, MPLS actually serves to simplify the network, reduce cost, and enables network convergence with greater control and resiliency for the enterprise.

This Application Paper provides a guide for the enterprise in making network design considerations and to deploy Private MPLS or to connect to a service provider’s MPLS-based WAN offering. The guide takes into consideration several enterprise networking requirements such as service quality based upon applications, operational and management considerations, scaling, cost and regulatory compliance factors to assist any enterprise network engineer or manager in making the appropriate decisions for building a Private MPLS network or connecting to a public MPLS-based WAN.

The guide enables business unit and network managers to plan appropriately to migrate to an MPLS network and to use the capabilities of the network to better serve the business. Rather than having the network guide the direction of the business, the methodology presented allows business and network planners to asses their business needs and enables the network to be designed to meet these needs. Planers can take into account the geographical reach of the organization, applications, department or user group needs, business compliance requirements, network security and special network policy needs for the organization that can be supported by a properly deployed MPLS network.

After reading this guide you should have a clear view as to how to translate business requirements into network deployment considerations for your MPLS network. If it isn’t already, it will become clear how to enable security through MPLS-based network virtualization and which types of VPNs are required for your organization. Furthermore, this guide will assist you in considering routing protocols, MPLS label distribution protocols, your requirements for traffic engineering and MPLS-based fast re-route, how to assign and support IP QoS to MPLS QoS mapping, and how best to interconnect your network with one of the many available service provider options for regional and global transport. When properly considered before the initial deployment, these MPLS design considerations for deployment will help you to think through and address the many design considerations upfront to ensure a successful deployment which aligns with the business needs of your organization.

Where and Why is MPLS Appropriate in the Enterprise? MPLS is generally appropriate as a Wide Area Network (WAN) and core networking technology. In a converged core or converged WAN, MPLS can provide virtualized networks to segment traffic based upon applications and user groups, provide differentiated and guaranteed qualities of service, and security through virtual network separation. In addition, through MPLS traffic engineering, MPLS can intelligently route around congestion in the core or WAN and can be employed as a business strategy to reduce core and WAN bandwidth requirements and associated cost. Furthermore, while many services being converged in the core may require real-time application performance, MPLS can meet these requirements with capabilities such as MPLS Fast Re-Route (FRR) and fast link and node error detection with Bidirectional Forwarding Detection (BFD).



Migrating the core or WAN to MPLS allows the enterprise to preserve the investments made at the edge of the MPLS network while lowering cost and improving performance of a converged WAN or core network. Given the ability of MPLS to support both, Layer 2 and Layer 3 VPNs, networks and services such as ATM, Frame Relay, and Voice can be folded into and converged with IP, yet their unique qualities of service and security requirements are supported within the core and WAN. Voice and video networks as well as the LAN and Data Center do not have to change or upgrade to support the migration of MPLS, thus preserving the investments in technology and equipment while providing the cost savings of a converged network that can support the varied application performance and security requirements of the enterprise.

Considering the scale, cost, and performance requirements of the large enterprise core and WAN, this portion of the network requires significant equipment and operational cost. As a result, this portion of the network has the most to gain by the benefits enabled with MPLS and offers the large enterprise a significant return on investment in most applications based upon scale, performance requirements, and the cost savings enabled by convergence while enabling network performance to meet the requirements of the most demanding applications.

MPLS: Build or Buy? The decision for building a network or subscribing to a Wide Area Network (WAN) service should not be based solely upon technology. If you have built a private WAN or outsourced your WAN today, you have done so for fundamental business, competitive, and cost-based reasons. MPLS as a technology does little to change these fundamental business drivers. MPLS benefits are not dependent upon whether you build your own network or use a service provider’s offering. In reality MPLS enables superior networking performance as well as capital and operational cost benefits for both types of networking solutions, those which are built and managed by the enterprise and those which are outsourced to a WAN service provider. MPLS enables network consolidation, convergence and improved network security with its ability to virtualize the network and provide greater availability and resiliency than many legacy networking technologies. When leveraged as a virtual networking technology, one physical network can actually provide multiple segmented networks through virtualization.

Figure 1: Where MPLS is Appropriate in the Enterprise



Private MPLS Networks Owning and managing a private WAN involves a great deal of management and required capital equipment as well as additional operational cost to maintain the network. For some large enterprises, the ownership and management of a private WAN is justified based upon the business model and cost structure of the organization. For these organizations to realize the networking benefits and cost advantages of MPLS; they should not change their fundamental business model. An organization that owns and operates a private WAN today should most likely continue to own and operate the WAN as the network is migrated to an MPLS enabled WAN.

The best way to migrate into an MPLS network and to realize the benefits of MPLS is to create and implement a smooth migration strategy. You may have a variety of WAN technologies inter-connected and multiple parallel WANs in place today. You’ve likely been running your applications on the legacy networks for several years, therefore a short time of continuing to run these applications on the legacy networks is not going to hurt as you plan for a successful migration to MPLS. However, the faster you are able to migrate to an MPLS-enabled WAN, the sooner you will be able to take advantage of functionality, scalability and cost savings offered by MPLS. This guild will help you to consider several important aspects for making the “best” choices in planning and deploying your MPLS-based WAN.

Public MPLS Networks If you’re organization is like the majority of businesses today, you do not own and manage a private WAN, but rather connect main offices to branch and remote offices, teleworkers, suppliers, partners and customers over carrier provided WAN services. A wide variety of WAN services are available to meet the many diverse needs of the applications deployed within a typical enterprise ranging from voice to confidential data to electronic mail and Internet traffic. The Public Switched Telephone Network (PSTN) is most commonly used for voice while ATM or Frame Relay for private WAN applications. More recently, there has been a shift to reduce private WAN cost by migrating to Virtual Private Networks (VPNs) over IP or the Internet supporting a growing number of file sharing, electronic mail, and web-based applications across the WAN.

If your organization has completely outsourced WAN and Internet access to one or more service providers, this has most likely been done for business competitiveness and cost reasons. By migrating to an MPLS-based WAN the fundamental business drivers of your business do not change, therefore you will most likely continue to be best served by

Figure 2: Private MPLS Network Diagram



outsourcing your WAN services. Whether you own or outsource your WAN, your business can benefit by migrating to an MPLS-based WAN.

Many organizations that plan or wish to converge their networks and consolidate WANs to a single network may actually require an MPLS-based WAN service offering to support “true” convergence and the wide range of applications deployed and used within the enterprise today. IP enables convergence in the enterprise, but it doesn’t deliver the security through network separation and application specific QoS to efficient utilize the converged network resources and guarantee application performance.

Even if you are not planning to converge multiple data WANs, but plan a migration to Voice over IP (VoIP) within the enterprise and plan to transport intra-office VoIP calls over the data network, your VoIP application will be well served by a migration to MPLS. Not only will network performance be enabled to support a demanding range of applications over a converged MPLS network, but MPLS-network based services are typically more affordable than ATM-based WAN and can be engineered for comparable service performance characteristics and availability.

For the greater majority of enterprises which do not own and manage a private WAN this application guide will help you to asses design considerations for how to optimize your LAN and WAN access to take full advantage of a service provider’s MPLS-based services. The LAN and WAN access configuration requirements for connection and proper utilization of a public MPLS service is a key factor that is often overlooked by many enterprises. Furthermore, the guide will provide helpful information to determine which service provider may be the best equipped to provide your organization with an MPLS-based WAN service offering.

Hybrid Private and Public MPLS Networks For a majority of large enterprise that built and owns a private WAN or campus network, the WAN or campus network is regionalized and inter-connected with WAN services provided by carriers having a larger or even global reach. In this instance, it’s often a competitive enabler and lowers cost for the large enterprise to build a campus or regional WAN, but the cost model for the private WAN does not scale globally where oceanic fiber connections may be required. By in large, most enterprise private WANs are inter-connected today via public WAN services. Similarly, universities and business campuses may inter-connect a large number of building in what looks very much like a regional WAN. This campus and the many buildings which make up the campus are then connected to the Internet via dedicated and consolidated access. In addition, one campus or group of buildings may be connected to another campus network via Virtual Private Network (VPN) tunnels over the Internet and/or

Figure 3: Public MPLS Network Diagram



over a Frame Relay (FR) WAN service offering.

For enterprises that are comprised of private regional or campus networks, the network has been built in this fashion based upon geography, available access to buildings, cost and business model drivers. As you look to migrate towards MPLS and take advantage of the networking benefits provided by MPLS, these fundamental drivers remain constant. Therefore, it is likely that you will be best served by migrating your private regional or campus networks to a private MPLS implementation and inter-connecting these private networks via public WAN services. However, as you migrate to a hybrid MPLS network model that requires an inter-connection of private MPLS networks to public services, the best choice for inter-connecting these private networks requires careful consideration as well. This application guide will help you to make design and deployment considerations for your regional private MPLS network deployment as well as the best choice for inter-connecting your regional or campus MPLS networks via public services.

MPLS Network Design Principles One of the great things about MPLS is its ability to virtualize the network, consolidate, and simplify management of the WAN. The benefit for the enterprise is that you have multiple virtualized networks while building and managing one physical network. Each of the virtualized networks can be configured with the QoS requirements, user requirements, and security requirements to meet specific application demands being supported independently. This allows you to make the most efficient use of your converged network resources. In addition, MPLS adds the benefits of being able to traffic engineer the network based upon applications, users, bandwidth demands, time of day dependencies, and cost of transport routes. When planning your MPLS deployment, the best way to start is by planning and appropriately designing the Layer 2 and Layer 3 MPLS-based VPNs that your enterprise will require.

Basic Network Design To start, if your environment is like the typical large enterprise, you may very likely have multiple WAN networks within your enterprise supporting a wide variety of applications. These multiple networks, being physically separate, have natural boundaries through separation providing security, policy, and QoS designed specifically for the applications being supported. When migrating to MPLS, the first step is to plan to maintain these natural separations of boundaries with MPLS-based VPNs. Therefore, at a minimum, it is likely that you will have as many MPLS-based VPNs as you have multiple WAN networks operating

Figure 4: Hybrid MPLS Network Diagram



today. The WAN count should include voice on the PSTN if it is part of your plan to migrate a portion of this voice to the MPLS network.

If you wish to converge networks onto an MPLS network, you will need to build a network that has the combined reach of the networks you wish to converge. For example, the Frame Relay network may be parallel with the IP network yet the ATM network may reach locations where neither your IP nor Frame Relay networks reach today. To converge all of these networks, you will want to build out an IP/MPLS network that has the combined geographical reach of the ATM, IP, Frame Relay WANs and any other networks you plan to converged onto the IP/MPLS WAN.

Consider the existing networks further and asses where there are additional network-based boundaries or where boundaries should be added. Perhaps there are firewall-based zones on the IP network today that separate Finance, Human Resources, and the remainder of the organization. Some of these firewall boundaries may be designed to secure information protected by Sarbanes-Oxley, HIPAA, and/or the VISA Payment Card Industry (PCI) compliance requirements. MPLS VPNs may be deployed to improve security between these departments while lowering cost through virtual network separation. In this example, it may be possible to remove several firewalls from the network that had previously provided network-based separation and leverage a centralized firewall to appropriately grant access to and from separate IP networks on a converged MPLS network. This MPLS enabled redesign of the firewall architecture not only reduces the complexity of protecting network segments with firewalls, but can also go a long way in reducing cost of network security through firewall centralization.

A challenge with converging applications and networks becomes: “Who owns and manages the network going forward?” This can be especially difficult when one organization managed the voice network, while another managed the private data network, and a third managed the IP network or even when one group manages the network for one subsidiary while another group manages the network for another subsidiary within a large multi-subsidiary enterprise. This is where the virtualization capabilities of MPLS can further differentiate itself from existing technologies. Through virtualization of the network enabled by MPLS, IT management over specific networks as well as within differing subsidiaries can maintain control and ownership of their virtualized networks over a single converged MPLS network. Furthermore, for the organization that is frequently acquiring or divesting business units, this makes it convenient from an implementation point of view to “fold in” or “peel out” new networks.

Interconnecting your MPLS network or simply interconnecting sites via a Provider-Provisioned Virtual Private Network (PPVPN) can greatly simplify your core routing design. With a PPVPN, there’s no need to worry about Permanent Virtual Circuits (PVCs)/link

Figure 5: Example Application Specific Networks



topology between sites, routing protocol scale or design. When leveraging a managed PPVPN for interconnecting sites or MPLS clouds, all you need to do is peer with the Provider Edge (PE) router and you’re all set. Consider and incorporate these inherent MPLS-based benefits into your overall network design.

Now that you’ve considered the existing physical network boundaries, existing boundaries within common networks, and existing boundaries for network management, and the benefits of PPVPN, a fifth consideration should be the addition of new network-based boundaries. Emerging compliance requirements may require compliance protected information to be sectioned off and kept separate from other traffic and users on the network. In addition, the adoption of VoIP in the enterprise may require a new MPLS-based VPN to provide the appropriate QoS, security, and policy for this application. Consider new applications that your enterprise may deploy as well as dynamics within your company and external industry impacts such as compliance regulation as a whole and how this may influence your future WAN needs.

Although MPLS has the capability of subsuming many of the networks you have in place today, it is not necessary to completely converge all networks. Frequently, a preferred approach is to converge the core and maintain the legacy networks on the edge of the core. This allows you to maximize the cost savings by converging the core and allows the enterprise to take a gradual and phased approach in migration for the legacy technologies to MPLS. Simplification and cost savings are enabled immediately in the core where the complexity and cost of the network is the greatest.

Traffic Separation and Engineering Traffic separation and engineering enables the network segmented such network traffic associated with applications and user groups can remain separate, have a unique CoS, and remain secure from other traffic on the network. In addition, the benefits of traffic engineering can be leveraged to balance traffic across diverse paths in the network, off-load congested links, and lower WAN cost by lowering bandwidth requirements on the most costly links and routing network traffic around less costly alternative links. The cost savings of WAN traffic engineering can be substantial, yet must be evaluated on an individual business by business user case.

At this point you’ve hopefully assessed of the networks you have in place today, which facilities access these networks, where the points of presence are, who accesses these networks, and what applications are supported on the various networks. In addition, you’ve considered new applications anticipated at any time in the future, who will use these applications and what level of QoS and security is required to appropriately support these applications. Keep in mind that you will want to design the network such that unanticipated

Figure 6: IP QoS without MPLS Virtualization



applications, users, and/or acquisitions or divestitures can easily be added to or taken off the network as needed.

The range of Class of Service (CoS) currently supported by ATM, IP, and Frame Relay, and other legacy networks in place today must be considered. As each network can support multiple classes of service, the full range of CoS supporting traffic on these networks should be considered. In some cases, it may be possible to provide a common CoS on the MPLS network for ranges of CoS in the ATM, IP, FR and other networks. In addition, you must consider the CoS that will be required of any new applications that will be converged into this IP/MPLS WAN, such as video or voice and video if they are to be supported or added in the future. MPLS label headers support 8 unique classes of service with the EXP bits (“Experimental” bits of the MPLS header). These classes include 4 queues, each with two drop priorities.

For most enterprises and large service providers that are converging several QoS networks, the 4 queues with 2 drop priorities are more than adequate to define the wide range of CoS requirements supporting a full range of converged network services. The EXP bits support a range of QoS equal to the range of QoS supported in enterprise Ethernet-based networks today. Being that this is adequate for the majority of large enterprise, we will assume you will be implementing E-LSPs (“EXP-inferred” – Label Switched Paths). E-LSPs use the EXP bits to define the range of QoS supported in LSPs. However, if E-LSPs can not support the wide range of QoS required by your MPLS network, you should plan to utilize L-LSPs (“Label-inferred” – Label Switched Paths). L-LSPs use the EXP bits and a portion of the MPLS label to define and set QoS requirements on the MPLS network. Each of the existing services and new services to be converged should be mapped to an MPLS CoS. Yet, many applications require a common QoS and can be mapped according to a common MPLS CoS. The MPLS CoS setting will define Per Hop Behavior (PHB) from router to router within the MPLS network.

Using the cost of WAN links as a weighting factor, existing traffic loads across the WAN should be considered. Are there links that are at or over capacity? Where do underutilized links in the WAN exist? Can traffic be routed along alternative paths to avoid a costly bandwidth upgrade that may be required based upon usage demands? Can the bandwidth requirements on the most costly links be reduced by moving a portion of the traffic on these links to less costly links? The answers to these questions will help guide the MPLS network planning process and implementation to enable potential cost reduction through the use of MPLS traffic engineering across the WAN.

Figure 7: MPLS Network Virtualization per Application



Six Process Steps for Migrating to MPLS Perhaps the easiest way to migrate to MPLS is to take the following phased step approach. Note that this is a generalized approach for most enterprises, however special circumstances may dictate a different approach for migrating to MPLS.

1. Upgrade the IP network to MPLS, yet continue to run it as an IP network. Use this step to verify network stability.

2. Build the MPLS network parallel to the IP network and expand the MPLS network to necessary locations where Frame Relay, ATM, or other networks exist today.

3. Configure MPLS VPNs needed to migrate your network(s) to MPLS.

4. One-by-one, starting with the IP network, fold the existing networks into their respective MPLS VPNs.

5. If planning to traffic engineer portions of the network and configure MPLS-based features such as Fast Re-Route (FRR), you should do this as the service(s) requiring traffic engineering and FRR are folded into the MPLS network.

6. Monitor and manage traffic loads based on applications, users, and time of day requirements, and modify traffic engineering as appropriate to improve efficiencies of the network.

Step #1: Upgrade IP to MPLS Capable

To initiate step one, upgrade all WAN routers to MPLS capable routers, yet configure the network as an IP network without MPLS. Use this time to verify a stable and properly performing IP WAN. This will provide the opportunity to have the MPLS network in place and to be sure routers are configured and working correctly to support IP connectivity. If you’re presently running EIGRP, use this opportunity to migrate to OSPF as a routing protocol or one of the other protocols that will perform better with the MPLS network. We’ll investigate routing protocols that work well with MPLS in further detail to assist in making the best routing protocol decision for your network. Once you’ve migrated to OSPF and/or IS-IS on the network, it is a good time to enable BGP in the WAN core as well. BGP can be used for automatic MPLS label distribution.

Step #2: Build the MPLS Layer

Once the IP WAN has migrated to an MPLS capable network and you have tested and verified IP WAN performance, activate the MPLS overlay and build LSPs to reach all locations on the network. If your intention is to create a fully meshed network, you will need to construct LSPs from every ingress Label Edge Router (LER) to every other LER on the network. Fortunately, label distribution is significantly automated with the use of Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP) with extensions to support the creation and maintenance of LSPs and to create associated bandwidth reservations on LSPs (RFC 3209), or Border Gateway Protocol (BGP). The protocol of choice for label distribution implementation on your network depends on the needs of your organization and applications supported by the MPLS network.

For those of you who do not anticipate a need to traffic engineer the network or support MPLS-based Fast Re-Route and want to simplify network management and provisioning as much as possible, we recommend the use of Label Distribution Protocol (LDP) for label distribution. However, if you require traffic engineering or fast re-route capabilities on your network you must use RSVP with extensions for MPLS label distribution. It is the decision of



whether or not you plan to traffic engineer the network or require FRR that frequently makes the decision between use of LDP or RSVP for MPLS label distribution.

RSVP is required for and supports MPLS-based traffic engineering and Fast Re-Route (FRR). Generally, if you have “real-time” or other “quality of service” applications running on the network, you will need to use RSVP not only for label distribution but for traffic engineering of the network as well. If neither traffic engineering (TE) or FRR are needed, meaning you will not place real-time traffic on the network nor do you have the need to TE the network to accommodate application loads and available bandwidth, then you will have greater flexibility among control plane protocol choices. Using RSVP, you will need to configure each ingress router on the network and the protocol will automate the provisioning of LSPs through the network.

Layer 2 services such as Frame Relay and ATM network services qualify as “quality of service” applications and need RSVP for DiffServ aware traffic engineering. In addition, voice, video and other real-time applications that also require Fast Re-Route dictate use of RSVP on your network. If you do not need to carry ATM or FR emulation over the WAN, but prefer to interconnect ATM and/or FR with IP, you can use Layer 3 MPLS VPNs to do this. In this instance, you may prefer to give ATM and FR traffic across the WAN a higher CoS than traditional best effort IP to provide priority routing of IP traffic carrying ATM or FR data.

If the MPLS network does not require Traffic Engineering (TE) or the Fast Re-Route (FRR) capabilities of MPLS, LDP is usually chosen as the default protocol for label distribution as its use can simplify the automation of LSP configuration over RSVP. In many cases there may be portions of the network that do not require traffic engineering, Layer 2 services and FRR capabilities and other areas of the network that do. In this instance, you may configure your MPLS network to utilize LDP in locations where appropriate and RSVP in other locations where necessary. This deployment model if mixing LDP and RSVP allows the network manager to limit and control the scaling of RSVP-TE sessions. This model allows the network designer to place the complexity in the network where it is needed for traffic engineering and to eliminate the complexity where it is simply not necessary.

Step #3: Configure MPLS VPNs

MPLS Virtual Private Networks (VPNs) can segregate traffic based upon departments, groups, or users as well as by applications or any combination of user group and application. Let’s take a step back and look at why we call MPLS virtualized networks, “VPNs”: They are networks because they provide connectivity between separate defined locations, they are private because they have the same properties and guarantees as a private network in terms of network operations and in terms of traffic forwarding, and lastly, they are virtual because they may use the same transport links and routers to provide these separated transport services. Since each network to be converged onto the newly built network has its own set of QoS, security and policy requirements, you will want to define MPLS-based VPNs that map to the legacy networks already built. Additional MPLS-based VPNs will be defined as follows:

By Department, Business Unit, or Other Function

Where you have logical separation of traffic that goes to a more granular level than the network, perhaps down to the department or business unit, application, or have specific security requirements, you will want to define VPNs on the MPLS network, each to support the logical separation required for a unique QoS, security, and application support combination. In many instances, process-based security requirements are driven by compliance requirements, such as Sarbanes-Oxley, which impact the security requirements



and design considerations of the network as a whole. Separating the network by department, business unit, or subsidiary can enable greater security between these groups, aid in meeting compliance requirements, and allow department, business unit, or subsidiary management and provisioning control of the network to be segmented and assigned appropriately.

Each logically separated area has its own Virtual Route Forwarding (VRF) instance providing a routed security boundary. These boundaries provide true logical separation of the network eliminating the possibility of routing packets from one logical boundary to another. In this manner, sensitive and protected information on one VRF can remain hidden and secure from users on another VRF. Policy can be defined by centralized firewalls which act as gateways and enforce policy of the VRF for those who access the domain through the firewall. This design methodology typically enables a consolidation of firewalls and cost savings within the organization. Just as a VRF can be defined to secure the department, business unit or other functional groups, it can be defined to support QoS policies unique to the user groups being supported as well.

By Service Requirements

If your network is one which will require support for multiple services, such as a combination of Layer 3 VPNs, Layer 2 VPNs, and/or VPLS, multiple MPLS headers or an MPLS tunnel hierarchy may be required. By stacking MPLS labels, many services can be multiplexed and de-multiplexed into a common LSP. The egress LER needs to know which service and which instance of that service the packet belongs. To do this, an additional MPLS header is applied by the ingress LER to notify the egress LER of the specific service requirements once the packet arrives. The functionality of stacking headers is essential to enabling your MPLS implementation to support multiplexing and hierarchical properties over a single LSP between two points. This is one way that once your MPLS LSPs are built, your LERs can leverage them to carry and add multiple services at will.

Layer 3 VPNs (RFC 2547bis) are the most commonly deployed VPNs today. These VPNs support IP services with a wide range of QoS requirements. The routing domain, IP addressing, and policy can be defined per VPN, making it secure and specifically tailored towards the locations, applications, and users supported by each VPN.

Layer 2 MPLS VPNs are required to converge and transport ATM and/or Frame Relay services and provide “like” network –based attributes. Because ATM and Frame Relay services typically have specific and demanding service requirements, you will want to configure Layer 2 MPLS VPNs for Fast Re-Route and traffic engineer the LSPs such that service guarantees can be met. In addition, to provide advanced detection and correction of link or node failures, it is ideal to configure Bidirectional Forwarding Detection (BFD) for all links/nodes supporting Layer 2 MPLS VPNs to optimize detection of link or node failures. As a complement to BFD, it is important and necessary to implement MPLS-based FRR to support service level guarantees on the order of those available with ATM and FR services.

Virtual Private LAN Service (VPLS) makes the WAN transparent to users and IP devices on the LAN, making it appear as though you have one large LAN extended across the enterprise. VPLS can be used on your network for IP services or it can be used to interconnect with a VPLS service provider to seamlessly network your enterprise across the WAN. IP QoS in the LAN can be carried over the VPLS service with proper Forwarding Equivalence Class (FEC) mapping and VPN configuration. If connecting to a service provider’s VPLS service, you will either need to collocate with the service provider or leverage a metro Ethernet service as VPLS requires an Ethernet hand-off from the enterprise to the service provider.



By QoS needs

Many existing applications within your enterprise may run on separate networks today. To be properly supported, these applications and their users have specific and unique security and quality demands of the network. This is why we suggest as above, you start by creating VPNs that support the existing networks. This is the minimum number of VPNs you will need. Next, you may be supporting multiple virtual networks within your ATM network or within your IP network today. It is more than likely that by migrating to MPLS, you will still have a need to support these existing VPNs with their unique QoS, security, and performance characteristics.

The significant question to ask is whether 8 distinct Per Hop Behaviors (PHBs) are sufficient or whether more will be necessary to support your long-term networking plans and applications for the MPLS network. This will determine the use of “EXP-inferred” LSPs (E-LSPs) or “Label-inferred” LSPs (L-LSPs) for the Forwarding Equivalency Class (FEC) designation.

There are two methods to provide CoS within MPLS. The first is to use “EXP” bits or what is also known as the Experimental bits in the MPLS header. The EXP bits provide 4 queues and 2 drop priorities for assigning CoS. Along with queuing traffic, high priority “real-time” traffic can be expedited without queuing. MPLS EXP bits provide eight classes of services just as Ethernet’s 802.1p specification. Each class of service can define specific per-hop behaviors such as queue prioritization, policing and drop profiles.

In most instances, the EXP bits are sufficient for establishing MPLS CoS in enterprise applications. Therefore, for the majority of applications, we recommend the use of E-LSPs. In special applications we recommend you discuss your needs with a Juniper engineer to consider the applicability of L-LSPs for your network.

A single LSP which defines the path from ingress LER to egress LER can support multiple CoS. Therefore, it is not mandatory to configure multiple LSPs for end-to-end paths across the MPLS network that are intended to support multiple CoS. Typically, one LSP defines an end-to-end path through the network and multiple FECs exist on that path to support a wide range of QoS requirements.

For special considerations and for further information regarding whether your network will be best served with the use of L-LSPs or E-LSPs for FEC designations, it is recommend that you consult with your Juniper Systems Engineer or certified Juniper networking partner.

By Security requirements

The only place where data can be injected into an MPLS tunnel is at the ingress Label Edge Router (LER) where the head end of the MPLS tunnel is established. This protects the transmissions against manipulation and spoofing of data. MPLS can provide this high level of security across the WAN and in a campus as well as in a LAN environment. Within the LAN environment, MPLS can scale, provide a better level of security, and better troubleshooting as compared to typical VLAN deployments.

Security requirements may be defined by user groups such as those working on sensitive and confidential projects, by compliance requirements to protect confidential information, and by application to protect special applications such as VoIP. The advantages of MPLS to separate and secure traffic are available to the enterprise to segment and secure the network. Each “special” security zone can be sectioned off with enhanced security via MPLS VPNs.



By Performance Requirements

Fortunately, the MPLS encapsulation overhead is relatively low at 4 bytes per MPLS header. Consideration should be taken to design for MPLS-based traffic engineering and fast re-route on LERs where needed by design. Typically, the applications and available bandwidth will determine traffic engineering and fast re-route requirements, however users and business needs may impact these considerations as well. The shortest path may not be the fastest or most cost effective path for your enterprise network. Consider cost as well as use demand and available bandwidth to switch traffic on MPLS VPNs for optimal performance.

Additional Network Virtualization

Now that you’ve engineered your MPLS-based VPNs to support the existing networks, user groups, QoS and Security requirements, you should consider additional and new VPNs that may be needed. For example, if you are planning a migration to VoIP, you may wish to design a VoIP VPN for intra-office calling across your MPLS network. In addition, evolving compliance processes supporting requirement such as Sarbanes-Oxley or HIPAA may require new and secure VPNs. Furthermore, a future acquisition of a business unit may require network integration and this can easily be performed on the network with the addition of a VPN to accommodate the acquisition.

If you have multiple IP networks, you may have overlapping IP addresses which would conflict in a converged IP network. Creating MPLS VPNs that are segmented by the existing network structure eliminates the concern for overlapping IP addresses while maintaining security through VPN separation in a converged environment. Furthermore, this is convenient when acquiring organizations as it eliminates the need to re-assign IP addresses; rather the network can be folded into the MPLS network and remain on it’s own VPN providing a method of avoiding IP addressing conflicts and enhancing the security of the network.

Step #4: Fold Networks into the MPLS VPNs

All of the required VPNs do not have to be defined before initiating the process of migrating your networks to MPLS. In fact, you may wish to build the 1st VPN and then migrate the related network, then build the second VPN and migrate the next network and so on. As you begin to converge these networks to your MPLS network, monitor network performance and traffic loads to verify expected transport demands are being met. If for some reason, performance or traffic loads vary from expected results, you should investigate further as MPLS can provide deterministic traffic characteristics, and resulting performance should not vary greatly from the expected results. Based upon findings, you may identify opportunities to further optimize your network for cost and performance gains.

VRFs designed to support specific departments, user groups, applications, security requirements, QoS, and other network virtualization needs can be designed and deployed one by one. Each of these separated VRFs can be interconnected with centralized firewalls that manage policy and police use of network resources in any one VRF. This design approach makes it very easy and convenient to integrate a new business unit and/or acquisition into the organization while supporting the unique policy, security, and QoS requirements as mentioned above. Furthermore, as the WAN is converged supporting the new acquisition, the cost of supporting an additional overlay network and additional access facilities is eliminated.



Step #5: Traffic Engineer the Network

Step 5 does not require steps 3 or 4 above to be completed before initiating this step. You may traffic engineer the network as soon as the MPLS network plane is established. However, we recommend that you first migrate some of your traffic to the MPLS plane before configuring traffic engineering. This will allow you to experience first hand the benefits and granular level of control you have over the network through traffic engineering of an MPLS network.

Start by assessing the existing traffic demand of applications at WAN access points, data centers, and other potential “bottle neck” points in the network. Group traffic demand into priority categories, for instance, voice and video may be gathered into a “real time” priority category while private data is grouped into a second and Internet traffic is grouped into a third category. Consider the impacts of network convergence and estimate the increased traffic demand that may occur. An example of this is the migration to VoIP: A majority of intra-office voice traffic that presently traverses the PSTN can begin to traverse the private MPLS-based WAN and may greatly increase the demand of bandwidth from “real-time” applications as a percentage of total bandwidth allocated.

Combine the analysis of application and bandwidth demands on the network with cost of WAN links and current utilization of these links as performed in the planning stages of you MPLS deployment. With this analysis performed you can implement MPLS-based traffic engineering to adjust the appropriate level of bandwidth at each WAN access point, data center, and choke point in the network. This approach allows the enterprise to reduce costly capacities where appropriate and yet ensure an adequate amount of bandwidth based upon usage demands. Given the work that you’ve done in assessing “priority” categories and bandwidth demand by grouping applications into categories, you should provision appropriately a percentage of traffic type for each CoS at the MPLS router interfaces up to 100% of the available bandwidth. As the network converges, continue

Figure 8: MPLS-TE to Optimize Bandwidth Utilization

Figure 9: MPLS Network Virtualization per Application



to asses application demand as a percentage of traffic and capacity used at the choke points of the network and re-configure or adjust bandwidth percentage allocations of CoS as necessary and as demands change over time.

When desired, configure FRR and BFD as appropriate to provide fast re-routing of traffic along pre-provisioned alternate paths and advanced detection of link or node failures. Use FRR to re-route “real-time” and other latency sensitive traffic around secondary switched paths in the event of a failure. This feature in MPLS enables deterministic traffic characteristics with near 50-msec failure corrections of link and node failures. Consider the entire network and lower the required investment in bandwidth by improving utilization of existing resources where possible with traffic engineering.

Step #6: Monitor and Manage

As with any network, once deployed and running, you must continue to monitor and manage the network while supporting new service loads and demands. An advantage MPLS provides above and beyond IP is its capability to traffic engineer based upon utilization and application demands as the business evolves. With MPLS traffic engineering, you can adjust primary paths and alternate paths in the network for supporting traffic. Split traffic over multiple paths, and optimize network resources for the virtualized networks being supported. Upon occasion, as network traffic grows, it may be necessary to add transport capacity and upgrade router interfaces to support new services as well as to deploy new routers to extend the reach of the network.

If your enterprise is using a common network management platform, you may wish to integrate this management platform into the MPLS network as well. Given that you MPLS platform support standardized application programming interfaces, this integration can usually be achieved allowing for the integration of common management platforms and custom applications. Such integration of “Best-in-Class” solutions can provide greater visibility into the network and make it easier to provision and monitor for large scale deployments.

Application Considerations MPLS enables you to design and deploy your network with the support requirements of applications in mind. Specifically, multiple MPLS VPNs can be established over common LSPs. Each MPLS-based VPN can be configured with the correct policy, security, and network-based performance in mind to support a dedicated application or user community.

Security Requirements

Legacy dedicated and separate networks provide security of their applications through physical separation. As such, voice on the PSTN is separate and secure from hackers, viruses, worms and spyware on the Internet. On a converged network where voice and data share the same physical network, security through separation becomes a reason for concern as there is no longer physical separation of the networks. In this instance MPLS provides virtual separation through the use of MPLS-based VPNs. As such, each application that is secured through physical separation today should maintain that level of physical separation through MPLS-based virtualization of the network. Furthermore, within common applications, MPLS VPNs should be created and leveraged to improve security of your network. In this example, private IP data should remain confidential and secure from “public” IP data and Internet access. To add this level of security, multiple MPLS-based VPNs can be implemented to



secure private IP from “public” IP.

Within the enterprise LAN, VLANs are a common technology used to segment the LAN and provide a level of security. Yet, even with VLANs, routers in the LAN maintain a common routing table which can facilitate security breaches across VLANs. Furthermore, as a Layer 2 technology, VLANs are notorious for poor troubleshooting and don’t scale well. MPLS VPNs can provide completely separate routing domains to enhance security and provide better scalability. Furthermore, better troubleshooting capabilities are provided with MPLS VPNs at Layer 3 than VLANs which operate at Layer 2.

Data Center Considerations

The data center is a very demanding and critical networking environment for any large enterprise. Typically, the data center must have 24 by 7 always on availability supported with a fully redundant architecture. Fast Re-Route for disaster recovery to a secondary data center is typically a requirement rather than a “beneficial” feature. In addition, bandwidth demands are typically quite high and because of the wide variety of applications with costly bandwidth, fine grained QoS is essential to lowering operating cost. In many cases, multicast is an important feature to efficiently support broadcast services from the data center.

Current Layer 2/3 switching technologies designed for the LAN do not scale well with the appropriate levels of re-routing, availability, security, QoS, and multicast capabilities. As a result, when re-designing or upgrading the data center, the upgrade to MPLS for this environment is frequently appropriate and justified via business operational demands and cost constraints. MPLS can actually simplify the network for the data center, removing costly network equipment and potential failure points while providing complete network redundancy and fast re-routing.

When fine grained QoS is required with traffic engineering for the data center, RSVP should be used to establish bandwidth reservations based upon priorities, available bandwidth, and server performance capacities. MPLS-based traffic engineering is a tool made available to the data center network administrators which is not presently available in common IP networks. Furthermore, MPLS virtualization capabilities can be leveraged to segment and secure server access, becoming a very important part of maintaining a secure data center environment.

Application Performance

As multiple virtual circuits can be established with ATM or with Frame Relay via Data Link Connection Identifiers (DLCIs), MPLS supports Label Switched Paths (LSP) with a range of Forward Equivalence Classes (FECs). The LSP defines the specific path through the MPLS network from ingress LER to egress LER. The FEC defines the special treatment each stream or application is given as it traverses the LSP. For instance, all best effort IP traffic may be assigned to one FEC while all voice applications are assigned to another FEC which prioritizes the voice transport over best effort applications. As with a traditional virtual circuit, each LSP and FEC combination can be configured uniquely for the locations, applications or users it is supporting. Being logically separate, information in one LSP and FEC is kept secure from information in other FECs as well as other LSPs

With standard IP, you have little control over the specific paths that both best effort and high priority packets traverse. Links typically subject to delay, jitter, packet loss, and highly variable capacity demands can not necessarily be engineered around. MPLS enables the network designer to consider both the application and the network to effectively design optimized paths for different types of traffic. This is a significant advantage of MPLS over traditional IP and should be employed in the network traffic engineering design methodology



to support application performance requirements and to minimize networking cost by reducing or eliminating capacity demands on expensive links.

Mapping IP QoS in the LAN to MPLS QoS

You will want to forward “real-time” applications with minimal queuing delay using high priority queues. For other applications, you can map IP QoS traffic into high, medium, and low priority queues, each with two drop priorities using the EXP bits in the MPLS header. Care should be taken to reserve traffic commitment capacities as a percentage of port to maintain a minimum level of throughput for each queue.

Assigning IP QoS at the end-point device does not scale well from a management perspective and may allow for potential abuse by sophisticated users who can set their own priorities for applications. As such, it is best to set the priority of applications in Layer 3 devices either at the router or an application aware firewall. The choice of platform for setting QoS on the LAN to be carried across the WAN depends upon the granularity of QoS setting ability needed.

For course flow setting, the LAN and WAN access routers function fine in setting IP QoS for applications and mapping this to the CoS in the MPLS network. When using routers for this function however, it is important to use a router platform that has separation between forwarding, services, and control planes. This is required such that the router can support QoS setting without inhibiting forwarding performance at scale. In addition, the design makes the critical WAN access routers very robust in withstanding Distributed Denial of Services (DDoS) attacks.

Juniper J, M, and T-Series routers are built with this design methodology. Separation of forwarding, control, and services planes makes these routers very robust in terms of performance and their ability to withstand attacks. Because Juniper maintains a common software train for JUNOS, the award wining code base for our MPLS enabled routers, the only decision point among which routers to choose for specific locations is not based upon MPLS feature capabilities, but rather upon capacity need for locations within the network. Juniper’s routers scale from the J-series at ISDN and T1/E1 and DS3 to the M-Series and on up to the T-Series at OC-768 capacities.

When a granular level of QoS setting is required, such that it is necessary to analyze the protocol, source, and destination to make intelligent decisions on IP QoS settings, a firewall performs much better in providing this detailed analysis and setting QoS as appropriate. Furthermore, this allows the router to focus on routing while the firewall can focus on analyzing IP flows and making intelligent decisions with regards to security and QoS settings. Management of setting QoS in the firewall scales well and the MPLS LER can easily map QoS set by the firewalls to pre-defined FECs in the MPLS network, providing a guaranteed CoS.

Providing the greatest control for mapping services to LSPs is Juniper application aware firewalls with deep packet inspection. Juniper firewalls are built on a fully integrated software and hardware platform. As such, Juniper firewalls can apply deep packet inspection at fast speeds to scale and support real-time traffic with security features enabled in the Application Specific Integrated Circuit (ASIC). By performing deep packet inspection, the Juniper firewalls can take into account QoS requirements needed for the application as well as user and device information to provide delivery control. In providing delivery control, IP QoS using ToS bit setting or a Differentiated Service Code Point (DSCP) implementation are mapped to LSPs that are matched with the QoS to provide the proper level of service while efficiently using available WAN resources.

In many enterprise environments, WAN acceleration may be required to accelerate applications that are designed for the LAN, but used across the WAN. In this instance, the



WX (Juniper’s WAN acceleration platform) can accelerate the performance of applications across the WAN from office-to-office and from data center to the extended enterprise and complement the performance improvements of an MPLS network. In addition, when the WX is deployed, you may choose to use this platform to set IP QoS for application performance across the WAN.

Like Juniper’s firewalls, the WX can identify applications based on protocols. In addition, the WX can be configure to set QoS based upon a combination of metrics including originating IP addresses and destination IP addresses. With the WX, application acceleration of key applications is provided along with the mapping of applications and user groups to specific LSPs for transport across the WAN. The WX will typically sit behind the WAN access router, so it acts as a centralized platform at any location to set IP QoS for all traffic entering the WAN.

Furthermore, the WX can monitor and report on WAN performance characteristics. This can be an important tool and managing and properly configuring your own WAN or a valuable tool to verify that you are obtaining the Service Level Agreements (SLAs) provided by your WAN service provider.

VoIP and Video QoS and Performance

Real-time application such as voice and video should be placed in the high priority routers queues on the MPLS network. These packets must be assigned an IP QoS that maps accordingly to MPLS for assured forwarding. As described above, QoS for these applications can be set at in the WAN access router, at the firewall, or at the WX platform when deployed for application acceleration and WAN performance monitoring. All LSPs supporting voice and video applications should be configured for high availability with FRR and BFD.

Compliance Requirements

Independent of whether you are addressing compliance requirements for Sarbanes-Oxley to protect confidential corporate information, HIPAA to protect Private Health Information (PHI), or another compliance process, best practices for internal controls to support the compliance process generally require guaranteed level of appropriate security for the protected information and detail auditing.

The best way to provide this heightened security and detailed auditing capability is to place the relevant protected information and frequent users of this information on their own secure network. However, this is not necessarily feasible, therefore MPLS-based VPNs are a cost effective alternative for separating and protecting sensitive and confidential compliance-related information. This provides complete isolation and protection of guarded information.

At times, it may be necessary and appropriate for users and other entities outside of this secured VPN to access the protected information. To allow for such access with granular auditing capabilities, a centralized application-aware firewall should provide the gateway for users that are external to this VPN. The application aware firewall should be configured to support the compliance process and provide detailed auditing for compliance verification. In this case, rather that routing through the router to access secured and highly guarded information, you are routing through a firewall which is designed to defend against network intruders and provide detailed event logging to support the audit process.



Routing Protocol Considerations: Migrating EIRGP to OSPF Although your organization may have deployed EIGRP initially for faster IP routing table convergence times and the ability to scale, enterprises planning to migrate to MPLS can gain superior performance and scale over what is offered by EIGRP with OSPF. As a distance vector routing protocol, EIGRP is not intelligent in calculating network topologies and making good routing decisions. Furthermore, the protocol does not handle far end failures well. Troubleshooting EIGRP-based routing problems can be complex and very time consuming as well. In addition, EIGRP being a proprietary routing protocol, has been successfully used as a vendor “lock-in” technique to demand and garner high margins on subsequent equipment and service fees.

One of the great things about MPLS with OSPF is that it overcomes the reasons you migrated to EIGRP in the first place and does this better than EIGRP. With features such as Fast Re-Route and support to scale efficiently, MPLS provides superior advantages to EIGRP without the many problems introduced and proprietary nature of EIGRP. In addition, MPLS, being an open and standards-based protocol mitigates the risk of vendor “lock-in” previously established by EIGRP. Additional reasons for migrating from EIGRP to OSPF besides the planned adoption of MPLS are to support IPv6, best practices, and a standards-based approach. Lastly, EIGRP does not communicate traffic engineering data used for MPLS-based dynamic traffic engineering, making OSPF or IS-IS an absolute requirement any time you need MPLS-based traffic engineering.

OSPF for use with MPLS has advantages over EIGRP far exceeding the fact that it is not a proprietary protocol. OSPF is superior as a routing protocol in using intelligence to “draw a picture of the network” and determine shortest paths. In addition, OSPF allows you to get away from the legacy influences of a pre-CIDR world with EIGRP and methods such as Poison Reverse, Hold Down Timers, Split Horizon and Triggered Updates to avoid layer-3 loops given EIGRP deficiencies. For the majority of applications, we recommend the use of OSPF as a routing protocol for enterprise MPLS networks although given special considerations, IS-IS may be a preferred choice.

Obviously, if you are running EIGRP, you have a Cisco routed network given EIGRP is a Cisco proprietary protocol. This being the case, for the deployment of MPLS, we suggest you migrate to OSPF first, and then subsequently begin the migration to MPLS. You can begin the migration to OSPF prior to replacing your Cisco routers to plan for the migration to MPLS. After or during the process of migrating to OSPF, you can replace the Cisco routers for your migration to MPLS.

Start by laying out the architectural plan for OSPF on your existing network. OSPF is a hierarchical protocol, where the backbone of the network is typically defined as OSPF “area 0”. Subtending areas are made to connect out of area 0 in a hierarchical order. For configuration and management of the OSPF network, it is ideal and recommended to keep the number of routers in a particular area to a small number, usually a maximum of 30 to 50 per area. In designing OSPF areas, another significant consideration is the speeds of the links connecting routers, such as GbE, Fast Ethernet, Ethernet, OC-n, T3, T1, and xDSL. The core of the network may be connected with GbE or OC-n while branch and remote offices are connected via T3, T1 and/or xDSL access links. Define the architectural topology of the network based upon groupings of the core, regional offices, and remote sites, limiting the maximum number of routers in any one area to a range of 30 to 50 routers.

Once the architectural plan for OSPF is defined, start by activating OSPF on the routers. Cisco routers can normally support multiple simultaneous routing protocols. Start by configuring



the backbone routers for OSPF first. Network statements are used to configure an interface on Cisco routers. Routers that participate in multiple OSPF areas are called Area Border Routers (ABRs) and typically require the more complex configurations on Cisco routers. When configuring OSPF on Cisco routers, a Process ID or PID is used. This number is locally significant to the router and does not act in the same way as an EIGRP AS number. For OSPF, in order for a router to peer with a neighbor, routers should share the following on common links: 1) Area ID, 2) Hello and Dead Timers, 3) Stub Flag, 4) Authentication Flag, and 5) MTU.

Because EIGRP has a lower administrative distance of 90 where as OSPF is 110, EIGRP will continue to route packets and no changes will be noticed with OSPF enabled on all routers. For OSPF, a default route is usually advertised from the Internet gateway router in the core. This route is propagated automatically downstream. The command to configure this under OSPF on a Cisco router is “default-information originate”. In doing so, a default router will propagate downstream to all OSPF configured routers. The EIGRP route will be re-distributed with an administrative distance of 170 for making OSPF the default route with an administrative distance of 110. Congratulations, with this step, you have effectively migrated your network from EIGRP to OSPF.

Given that OSPF is configured and the default route is established, the last step in migrating from EIGRP to OSPF is to take EIRGP off the network. It is easiest to start from the edge of the network and move towards the core. Start with the remote sites moving towards hub sites and the core of the network. Being that OSPF is an RFC standardized protocol, you can now easily replace the legacy routers in your network which will not support the MPLS migration with MPLS enabled routers configured with OSPF.

When to Use IS-IS

IS-IS and OSPF share many common features in addition to their link state algorithms and their support for classless route prefixes. Those in the enterprise may be more familiar with OSPF and hence have a preference for OSPF. On the other hand, IS-IS as layer 2 protocol may offer some security advantages over OSPF at the cost of perhaps being a bit more complex to troubleshoot. For all but extreme cases, the differences between OSPF and IS-IS are not significant, yet if subtle differences make a significant impact for your routing protocol choice, you should investigate these options further. Stability and scalability are largely artifacts of implementation, not protocol design. The biggest factor in choosing between IS-IS and OSPF for your routing protocol choice is familiarity and comfort in engineering and operations. Further analysis of IS-IS versus OSPF are beyond the scope of this white paper.

MPLS based resiliency and Fast Re-Route When supporting “real time” applications and other low latency application requirements on the network, we recommend that you configure MPLS-based Fast Re-Route with Bidirectional Forwarding Detection (BFD). BFD will give you the earliest possible detection of a link or node failure. Fast Re-Route will immediately enable traffic traversing a failed link or node to be re-routed to a pre-provisioned and alternate path. Fast Re-Route can allow your network to maintain “real-time” application performance for voice and video applications in the event of a network failure.



MPLS Provisioning and Management Provisioning and management requires visibility and control. Management Information Bases (MIBs) are significant to provide standardized visibility into the network. MIBs are available for all protocols and applications developed by the IETF and are used to manage the network. Is some cases, the tools provided by your MPLS network will provide the provisioning and management solutions you desire. In other cases you may want to supplement what you have with third party tools or custom developed solutions to aid in provisioning and management of your MPLS network. To do this, you should plan your deployment with an MPLS network solution that offers standardized Application Programming Interfaces (APIs) to enable both, third party and custom application integration. For provisioning and management of your MPLS network, you should plan for deployment with tools that minimize the chance for errors, provide corrective actions, support third party solution integration, and assist in detecting, troubleshooting, and resolving failures.

Provisioning Planning for MPLS Deployment

In planning for provisioning, you will plan to provision routers, service blades, MPLS-based features and so on. However, you should also plan your deployment to prevent and design to minimize, detect, and report configuration errors. As a fundamental process to minimizing errors, you should seek to simplify automate the provisioning process to reduce the potential for errors.

The methodology of preventing configuration errors is rather straight forward. To reduce errors sophisticated network equipment vendors have reduced and simplified the configuration statements to enable MPLS-based features on the network. In deploying MPLS, consider your configuration options and plan to take the easier approach available, as quite often, there may be two or more configuration options to achieve your networking goal.

Furthermore, automate the provisioning process where at all possible. For instance, if you must configure many MPLS VPNs across the network, leverage BGP to automate the provisioning process. With BGP, rather than configuring every router end-to-end in the VPN path, you can configure the ingress and egress router of the MPLS VPN and allow BGP to auto-provision the VPN through the MPLS network, greatly reducing the chance for human configuration errors and reducing the amount of effort involved to configure every router in the path.

The advanced capabilities of JUNOS will allow you to apply common configurations in multiple places, thus reducing the chance of making a configuration error by repeating the wrong configuration. For example, when you have a configuration which applies to a large number of interfaces, apply this configuration across all of the applicable interfaces rather than applying the configuration separately to each interface. In addition, JUNOS can be leveraged to eliminate configurations when not necessary. For example, bypass tunnels for link protection can be dynamically computed. Rather than forcing a manual configuration which increases the potential for errors, take advantage of dynamic configurations to provisions with less chance of errors and to make the provisioning process more efficient across the network.

You may choose to integrate third party of custom provisioning tools. JUNOS excels with an API and in its ease to provide third party or custom tool integration. In your deployment plans, take advantage of this ease in interoperability to simplify the provisioning process. Third party applications can further automate the provisioning process and even tie external business demands to provisioning and configuration changes of the MPLS network. As these



tools can be deployed to further automate provisioning, the opportunity for configuration errors is reduced.

Lastly, use configuration prompts which verify a configuration change before making the change and that allow for “roll-back” to previous configurations should something go awry with the network after making a configuration change. Again, this is an area where JUNOS excels as a provisioning platform and can become a strategic part of you deployment plans to improve overall configuration reliability and error recovery.

Management Planning

In management planning for deployment, you should preemptively plan to detect, troubleshoot, and resolve failures. A well designed network is the first step in reducing the potential for failures. In addition, you will most likely want to configure your network for high availability and as a fully redundant network so in the event a failure does occur, your network can continue to support applications and the business in real-time while corrective measures are taken to troubleshoot and resolve network problems.

Look for and deploy solutions that improve your visibility of the network and help you to identify problems. There are two types of failures you should plan for, silent and non-silent. Silent failures occur without any alarm notification. These types of failures may include loss of packets in the data plane, discarded by a router in the forwarding path. Non-silent alarms are those which trigger a severity alarm with indication as to origins of the problem.

For identifying and isolating both, silent and non-silent alarms, you should plan to deploy common and standardized troubleshooting tools. These tools include Label Switched Path Ping (LSPing), Bidirectional Forwarding Detection for MPLS LSPs, LSP Traceroute, and ICMP Ping with and without VRF context. Some of these are standard tools used across the industry and others are unique tools designed specifically to troubleshoot and support the management of MPLS networks. JUNOS is an excellent operating system that will provide you with the widest range of tools and solutions for fault identification, troubleshooting, and fault resolution.

Beyond what is available in JUNOS, you may plan to deploy a third party or custom applications to assist in the day-to-day management of your MPLS network. Likewise, JUNOS excels by enabling application integration with ease and flexibility. This supports a “Best-in-Class” approach to enabling effective management for the way you wish to manage your business and supporting networks.



Connecting to a Service Provider In many instances, your private WAN will not reach all remote locations and branch offices and you will need to interconnect your private WAN with a service providers WAN offerings. And if your enterprise is one which outsources all of the WAN to a service provider, you will always be connecting at each location where WAN services are provided to a service provider. In either case, depending upon locations and service providers, you may have a wide variety of WAN service options to choose from. Making the appropriate decision in WAN service selection is a critical choice in meeting your WAN application performance objectives while lowering your operational cost.

Four implementations stand out as practical for interconnecting regional MPLS networks over public services. The first is to use MPLS-based Virtual Private LAN Services (VPLS), the second is to interconnect regional Private WANs with GRE tunneling over IP, the third is the Carrier’s Carrier architecture of interconnecting MPLS networks and the forth is to terminate private MPLS as regional private networks and interconnect without end-to-end QoS guarantees. The choice between these four models for interconnecting regional MPLS WANs and/or campus networks is based upon the your unique business needs, available resources, cost, and public service availability.

Using VPLS VPLS provides any-to-any network connectivity. As a networking methodology, this is great for scale, network resiliency of a mesh architecture, and management. However, VPLS requires an Ethernet hand-off to the service provider. Because not many service providers presently offer VPLS over Metro-Ethernet services, this model may require collocation of the enterprise router (Customer Edge or CE) at the service provider’s Point of Presence in a central office of collocation facility. At this point, the enterprise can connect to a service provider’s VPLS service offering and connect their many regions or campus environments just as if they were connecting these remote sites via a single, high capacity Ethernet switch as depicted in the diagram below.

VPLS services are beneficial in that they give the appearance of having a transparent WAN.

“Best-in-Class” Service Providers for MPLS

Juniper works closely and has many service provider partners as MPLS customers. These service providers have differentiated their network and services offering with the most advanced and powerful routers in the World enabled by Juniper Networks and our MPLS technology.

To obtain assistance in coordinating your MPLS deployment with a service provider, feel free to contact Juniper Networks for assistance and recommendations based upon your unique networking needs.

Figure 10: Service Provider MPLS Interconnection



Interconnecting via VPLS makes your network look and function like one large LAN. The difficulty with VPLS is that you must connect to the service provided via Ethernet and metro Ethernet has limited availability in most markets. However, VPLS offerings and Metro-Ethernet service are increasing, so check with your local service providers on up to date availability. For many large enterprises, the benefits are worth the cost of collocating the enterprise WAN access router at the service provider Point of Presence (POP) and connecting via Ethernet to the service provider’s VPLS services where metro-Ethernet services are not available.

Tunneling over IP with GRE For those organizations that prefer not to collocate equipment with a service provider and do not have Ethernet-based VPLS services available in their markets, the preferred method of interconnecting regionalized MPLS networks is to interconnect over IP with GRE tunneling. The great thing about interconnecting with IP-based services is the ubiquitous availability of IP in markets to provide interconnection of regional private MPLS implementations in the more remote areas of the world.

GRE tunneling over IP presents an n-squared management issue of creating a mesh network of GRE tunnels across an IP network, however, once configured; you have your distributed MPLS networks cost effectively interconnected over IP with GRE tunnels which predominately remain static.

Carrier’s Carrier Architecture The carrier’s carrier architecture, supported in MPLS standards, allows large enterprise and carriers to share MPLS control plane information and carry MPLS traffic end-to-end “as if” the multiple networks are one large network. Because of the detailed coordination and configuration required between large enterprise and carriers to implement this Carrier’s Carrier architecture, large enterprise that wish to implement this deployment model must work closely with their carrier partners for a successful implementation.

Figure 11: Tunneling over IP with GRE

Figure 12: Carrier’s Carrier Architecture



Terminating LSPs and Connecting to an MPLS WAN The fourth option is to terminate each regional MPLS network and connect to a service provider’s WAN service offering. This option can be limiting however as it does not allow for MPLS-based CoS and FRR to be carried across autonomous systems (service provider’s WAN). As the MPLS network is terminated there is no tunneling of services or MPLS end-to-end architecture supporting in this environment. However, course QoS from the private network can be mapped to SLAs offered by the service provider at the WAN access point. At the egress point of the network, the mapping can be extended to provide prioritized WAN traffic with the appropriate priority on the far end of the network.

Summary It should be clear how your MPLS deployment can better enable your business, enhance operations within the organization to improve application performance heighten security, and lower your operational cost of supporting the networking needs of the organization. By conducting the business needs assessment from a department or user group perspective as well as by applications, geography, security, compliance and other relevant business factors, these business requirements can be used to dictate the necessary deployment decisions for your MPLS network.

As outlined above, MPLS can be used to secure areas of the network and to consolidate policy with MPLS-based VPNs. In addition, it can be configured if necessary to support end-to-end QoS, Fast Re-Route, and traffic engineering for application performance and optimal use of costly network links. It’s the business drivers that will determine the choice of configurations and protocol implementations on the MPLS network to best meet the needs of the organization. Where different groups provide management of applications, departments, or geographies, the network can be virtualized to accommodate the organization structure of the business on a cost effective converged network.

In addition to the deployment plans for MPLS, considering custom and third party application integration of the MPLS management plane can greatly assist with day to day management operations and enable a “best-in-class” approach to managing such a critical business infrastructure. As a leader in providing MPLS-based networking solutions to service providers and large enterprise, Juniper is best positioned with strengths and leading MPLS feature capabilities to help your organization to successfully deploy MPLS and to leverage this network as a competitive advantage in the marketplace.

Figure 13: Terminating LSPs and Connecting to an MPLS WAN



Copyright © 2006, Juniper Networks, Inc. All rights reserved. Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks in this document are the property of Juniper Networks or their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

Documents

Deploying MPLS for Enterprise Networks - United States · The Essential Guide to Deploying MPLS for Enterprise Networks ... MPLS network and to use the capabilities of the network