Here are steps you might follow to implement MPLS.
1. Number of sites and bandwidth to each.
2. Devices and device configurations.
3. Your applications. How many applications do you have? What are they? How often are they used, and by whom?
4. Application characteristics. Describe the network characteristics of your applications. Are they store-and-forward (i.e., latency insensitive)? Or interactive? How “chatty” are they? In typical usage scenarios, how much bandwidth do they consume? How does that vary by time of day/week/month/year?
5. Other networks. Be sure to include applications that may be on other networks — particularly video and voice). You’ll want to document your current and planned voice, video and conferencing use.
6. Future plans. Network capacity requirements may change dramatically when that new ERP application rolls into production in 2009. Be sure to include any upcoming application .
7. Document to the best of your abilities your current availability and service guarantees. You’ll need them to craft meaningful SLAs with your providers downstream.
Step 2: The RFP
When developing the request for proposals, there are a few key issues that are specific to MPLS-based services, including:
* Timing. How far in advance you should start this process depends on the number of sites, the number of geographies and your starting state. But any comprehensive RFP process should be started a minimum of six months before the desired circuit turn-up. Eight months is better. Very early MPLS adopters invested several years in discussions with their carriers, but that’s no longer necessary.
* Service and access types. As noted, there are many different “flavors” of MPLS-based services. From a user perspective, the biggest distinction lies in the access technologies: Are services provided over copper or optical connections? What about wireless options? Is the carrier delivering native Ethernet, IP, or legacy services such as frame relay and ATM? Can remote users be connected in via VPNs? Ask service providers to offer details of each service they propose, including the specs they’re based on and the gear they’re using.
* Network-to-network interfaces (NNIs). As much as possible, try to keep your sites on a single carrier’s network (with the possible exception of having multiple carriers link to critical sites for redundancy). Ask about your carriers’ NNI strategies, because few providers will offer end-to-end SLAs to offnet sites. Ask providers if they have a “short list” of other providers with whom they’ve established effective NNIs. Have them describe the certification process for adding providers to this list, what service guarantees can be made, and how they’re enforced, and how cross-NNI troubleshooting is handled. The more you know, the more effectively you can manage cross-carrier connections.
* Also ask about (and budget for) ongoing monitoring. Your carrier will assure you that the provider will monitor ‘everything you need.’ Trust, but verify — you’ll want tools of your own to keep the carrier honest.
* Assess your backup options — in many cases, backup for frame networks is provided by the same ISDN network that doubles as a videoconferencing infrastructure. With MPLS, not only is your overall bandwidth increasing, but your ISDN network may be going away. Ask carriers to discuss backup options in detail.
*Make sure you ask for details about quality of service and service-level guarantees. Most providers try to brush you off on these details — don’t let them.
Step 3: Implementation
Once you’ve received responses to your RFP, plan to roll up your sleeves and dig into the details. You’ll want to prune down the responses to a “short list” of two to three carriers who can address your requirements, and work with them to craft agreements that meet your technical, financial and operational goals. Be sure to take into consideration the fact that use will change as bandwidth becomes available and that it may affect contract terms and conditions, particularly minimum annual revenue commitments. Eschew mini-MARCs (commitments to purchase particular amounts of particular types of service, such as voice) in favor of an overall combined MARC.
Plan to focus on the following:
* Mapping your application requirements to the appropriate class of service. The carrier’s techs won’t necessarily understand that your ERP app is mission-critical and needs real-time performance — so you’ll need to work with them to define and price a network that offers the appropriate services to your current and planned applications.
* Contractual support for your go-forward strategy. If you’re planning to migrate to VoIP, you’ll want to be sure your contract doesn’t penalize you for doing so. Specifically, if you need to increase bandwidth to accommodate voice and video traffic, make sure your access circuits can handle the load, and that your contract doesn’t include clauses that make increases prohibitively expensive.
* Capacity planning and expansion. Nail down the terms and conditions under which the carriers will expand your network, either by adding new sites or by growing the bandwidth to existing sites. What will it cost? How long will it take? And how much advance notice must you provide?
Do as much of this “predesign” work before you sign the contract, and make sure you understand exactly what you’re committing to.
If you’ve done all of the above, the actual service turn-up process should be fairly straightforward, if not entirely painless. Keep in mind a few operational strategies that will help minimize the angst:
If you’re planning to converge voice and data via VoIP, at the same time you’re rolling out MPLS, tackle each project separately. I wouldn’t say you need to actively hold off on VoIP while launching your MPLS network, but make sure to devote enough resources to both.
Your carrier may urge you to upgrade equipment, particularly CPE and branch-office WAN routers. If possible, take them up on it. The time and energy consumed by reconfiguring and upgrading older WAN gear is generally much greater than you’d think — and technology has advanced fairly significantly in the past two to three years, particularly for branch-office equipment.
Finally, think seriously about how your MPLS migration will affect the need for tech talent. As carriers assume responsibility for many of the architecture, configuration and management functions, enterprises are finding they can get away with fewer hard-core techies. The need doesn’t go away entirely — you’ve always got to have someone who understands routing protocols — but you’ll need five such people, not 20.
That doesn’t necessarily mean massive reductions-in-force, because companies are increasingly forming groups that focus on data centers, which have unique requirements for bandwidth and availability (not to mention server, storage and facilities). And branch offices, which are growing at an average of 9% year over year, pose special challenges, particularly when it comes to handling security, support and service.
Is MPLS right for you? Take this quiz | Next: MPLS explained >
