Chapter 10: Migration Strategies

More Cisco Press book chapters from new and classic Cisco Press books.

Rate your favorite Cisco Press books.

This chapter covers the following topics:

• Topics to consider for inclusion in RFP documents

• Turning the RFP into a joint planning document for implementation with selected vendors

• Defining the SLAs

• Training network operations staff on the new network

• Planning site installation

• Site handover requirements

• Case study selections

Having examined the options available for implementing provider-provisioned Layer 3 virtual private networks (VPNs) and how the technology affects the enterprise network after it’s implemented, we now consider how migrating from a traditional WAN to a Layer 3 VPN WAN can be managed. The procedures, mechanisms, and forms provided in this chapter are very similar to those used to successfully migrate the Cisco internal network from Frame Relay connectivity to a Layer 3 VPN with only the planned outages affecting end user service.

Network Planning

Assuming that the decision has been made (based on business, technical, and operational considerations, as outlined in previous chapters) to migrate to a Layer 3 VPN, planning is required to successfully implement that migration. This section examines the issues of writing Request for Proposal (RFP) documents, issues to discuss with the selected provider(s) and how these relate to service-level agreements (SLAs), training operators in the new network, and recommendations for how to project-manage the migration.

Writing the RFP

After the decision to implement a Layer 3 VPN has been made, the provider currently delivering WAN connectivity should be assessed to determine whether that provider has the service model, geographic coverage, SLA commitment, support infrastructure, and track record necessary to deliver the new network. In many cases, having an existing relationship with a provider may count against that provider. Undoubtedly, there will have been service issues in the past, and other providers won’t have that baggage associated with them. In other respects, the attitude of “better the devil you know than the one you don’t” prevails. Neither option is completely objective, so actually writing down the requirements and evaluating all potential providers equally is the best course of action.

The first job is to select a short list of potential providers for supplying WAN connectivity that you will invest time into, send an RFP to them, and fully evaluate their responses. You should send RFPs to a reasonable number to make sure that you are getting a good feel for what is competitive in the market at that time. What that number is will vary depending on requirements, but between 5 and 15 is reasonable.

The first thing to consider is what type of information will be put into the RFP. You can base your RFP on this comprehensive table of contents:

This table of contents is only a guideline; some elements may not apply to all networks. However, it is a good starting point for the things to consider that will be important to your network. For each of the technical issues previously described in this book, this framework allows you to identify what you want as a solution to fit your corporation’s needs and how you want the providers to respond to those needs.

---

Note – It is worthwhile to decide ahead of time how you will rate the providers’ responses by allocating some sort of marking or weighting scheme that places more importance on your corporate network needs than issues that are not so important. For example, you may determine that, because of operational reasons, you need the provider edge-customer edge (PE-CE) protocol to be Enhanced Interior Gateway Routing Protocol (EIGRP) rather than any alternative, so the marks awarded for offering this functionality may be greater than, say, multicast support if you do not make extensive use of multicast applications.

---

Architecture and Design Planning with the Service Providers

With the RFP written, responses gathered, and a selection made, a detailed design document must be created that documents the technical definition for the future WAN topology and services in the new network. This document forms the basis of the future design based on a peer-to-peer network architecture provided for by the new Layer 3 MPLS IP VPNs. This is a working document for both the VPN provider and those managing the network migration so that a common understanding of the technical requirements can be achieved. Clearly, this will closely resemble the requirements defined in the RFP. However, because compromises are always required in accepting proposals to RFPs, different trade-offs will be required when evaluating each provider’s offerings. After the provider(s) are selected, this document replaces the RFP as a source of technical description and takes into account what the chosen provider(s) can actually offer and how that will be implemented in the enterprise network to deliver the desired service. The following is a sample of a table of contents for a design document:

This list only suggests topics to consider for the working document that defines how the network will be designed and how it will operate. The implementation teams from both the provider and the corporation need intimate working knowledge of the network’s design and operations.

Should a systems integrator be used to manage the transition from frame-to-MPLS VPN connectivity, the systems integrator should be able to demonstrate to you a good understanding of these topics. Beyond basic understanding, a good systems integrator will be able to tell you about how different options that exist within each of these topics will affect your network after they are implemented.

Project Management

Converting a network from a Layer 1 time-division multiplexer (TDM), or from a Layer 2 offering, to a Layer 3 IP VPN is a significant task for any corporation. To successfully manage that transition, some minimal project management is advisable. Many project-management methods are available. A suitable one can efficiently do the following:

• Define the order process.

• Track orders against delivery dates.

• Track changes to designs and contractual commitments.

• Maintain reporting on risks to project success and provide an escalation path when needed.

• Provide an updated Gantt chart of planned activities and resource allocation.

• Track contracted to actual performance and keep track of project budgets.

SLAs with the Service Providers

This is one of the most contentious topics in negotiation between providers and their customers. It is natural that a customer paying for a service will want the delivered service to be measured against what is being paid for and will want a penalty to be in effect if the delivered service does not match what he paid for. With point-to-point Layer 2 connections, this is relatively simple. It’s relatively easy to measure the path’s availability and the delivered capacity on that path. However, after the any-to-any connectivity of an IP VPN is delivered, with support for multiple classes of service (CoSs), the situation is more complex.

The typical service provider SLA defines the loss latency and jitter that the provider’s network will deliver between PE points of presence (POPs) in its network. In almost all cases, this is an average figure, so POPs near each other compensate for the more remote POPs in terms of latency contribution. Some providers also offer different loss/latency/jitter for different CoSs. Again, this is normally for traffic between provider POPs. What is of interest to enterprise applications, and hence to enterprise network managers, is the service’s end-to-end performance, not just the bit in the middle. Specifically, the majority of latency and jitter (most commonly loss, too) is introduced on the access circuits because of the circuits’ constrained bandwidth and slower serialization times.

To solve this problem, you need SLAs that reflect the service required by the applications. By this, I mean that latency and jitter can be controlled by implementing a priority queuing (PQ) mechanism. For a PQ system, a loss of this kind is a function of the amount of traffic a user places in the queue, which the provider cannot control. For classes using something like the Cisco class-based weighted fair queuing (CBWFQ), the latency and jitter are a function of the load offered to the queuing mechanism. This is not surprising, because this mechanism is designed to allocate bandwidth to specific classes of traffic, not necessarily to deliver latency or jitter guarantees.

Some providers have signed up to deliver the Cisco Powered Network (CPN) IP Multiservice SLA, which provides 60-ms edge-to-edge latency, 20-ms jitter, and 0.5 percent loss between PE devices. With this strict delivery assured, designing the edge connectivity to meet end-to-end requirements is simplified.

With advances to the Cisco IP SLA, it will be possible to link the measuring of latency and jitter to class load. It is then reasonable for a provider to offer delay guarantees for CBWFQ classes, provided that the offered load is less than 100 percent of the class bandwidth. This then puts the CBWFQ’s latency and jitter performance under the enterprise’s control. If the enterprise does not overload the class, good latency and jitter should be experienced; however, if the class is overloaded, that will not be the case.

There should be more to an SLA than loss, latency, and jitter characteristics. The SLA should define the metrics for each service delivered, the process each side should follow to deliver the service, and what remedies and penalties are available. Here is a suggested table of contents to consider when crafting an SLA with a provider:

It is worth discussing each element in more detail. It is important to base performance characteristics on the requirements of the application being supported and to consider them from the point of view of end-to-end performance. Starting with PQ service, which will be used for voice, see Figure 10-1, which shows the results of ITU G.114 testing for voice quality performance. The E-model rating is simply a term given to a set of tests used to assess user satisfaction with the quality of a telephone call.

Figure 10-1

SLA Metrics: One-Way Delay (VoIP)

If you select a mouth-to-ear delay budget of 150 ms, you may determine that the codec and LAN delay may account for 50 ms, for example (this varies from network to network), leaving you 100 ms for the VPN. If the provider is managing the service to the CE, this is the performance statistic. However, if the provider is managing the service only to the PE, perhaps only 30 ms is acceptable to stay within the end-to-end budget. This more stringent requirement comes from the serialization times of the access link speed (for maximum-sized fragments), the PQ’s queue depth, and the size of the first in, first out (FIFO) transmit ring on the routers in use as a PE, all taking up 35 ms for the ingress link and 35 ms for the egress link.

Whether the provider manages from CE to CE or PE to PE, targets must be set for the connection type, and reports need to be delivered against contracted performance. From the enterprise perspective, it’s simplest to have the provider measure and report on performance from CE to CE; however, that does come with a drawback. To do so, the provider must be able to control the CE for the purposes of setting up IP SLA probes to measure the CE-to-CE performance and collect statistics. This is generally done by having the provider manage the CE device. However, not all enterprises want the IOS revision on the CE to be controlled by the provider, because the enterprise might want to upgrade its routers to take advantage of a new IOS feature. Clearly, this needs to be negotiated between the provider and enterprise to reach the optimum solution for the network in question.

For the data class, some research suggests that, for a user to retain his train of thought when using an application, the application needs to respond within one second (see Jakob Nielsen’s Usability Engineering, published by Morgan Kaufmann, 1994). To reach this, it is reasonable to budget 700 ms for server-side processing and to require the end-to-end round-trip time to be less than 300 ms for the data classes.

Jitter, or delay variation, is a concern for real-time applications. With today’s newest IP phones, adaptive jitter buffers compensate for jitter within the network and automatically optimize their settings. This is done by effectively turning a variable delay into a fixed delay by having the buffer delay all packets for a length of time that allows the buffer to smooth out any variations in packet delivery. This reduces the need for tight bounds on jitter to be specified, as long as the fixed delays plus the variable delays are less than the overall delay budget. However, for older jitter buffers, the effects of jitter above 30 or 35 ms can be catastrophic in terms of meeting user expectations for voice or other real-time applications. Clearly, knowledge of your network’s ability to deal with jitter is required to define appropriate performance characteristics for the WAN.

The effects of loss are evident in both real-time and CBWFQ classes. For real time, it is possible for jitter buffers to use packet interpolation techniques to conceal the loss of 30 ms of voice samples. Given that a typical sample rate for voice is 20 ms, this tells you that a loss of two consecutive samples or more will cause a blip to be heard in the voice con-versation that packet interpolation techniques cannot conceal. Assuming a random-drop distribution within a single voice flow, a 0.25-percent packet drop rate within the real-time class results in a loss every 53 minutes that cannot be concealed. The enterprise must decide whether this is acceptable or whether tighter, or less tight, loss characteristics are required.

For the data classes, loss affects the attainable TCP throughput, as shown in Figure 10-2.

In Figure 10-2, you can see the maximum attainable TCP throughput for different packet-loss probabilities given different round-trip time characteristics. As long as the throughput per class, loss, and round-trip time fall within the performance envelopes illustrated, the network should perform as required. The primary reporting concern with the data classes is how well they perform for delay and throughput, which depends almost entirely on the load offered to them by the enterprise. Should the enterprise send more than what is con-tracted for and set up within a data class, the loss and delay grow exponentially, and the provider can’t control this. Realistically, some sort of cooperative model between the provider and enterprise is required to ensure that data classes are not overloaded, or, if they are, that performance guarantees are expected only when the class is less than 100 percent utilized.

Figure 10-2

TCP Throughput

Other subjects listed in the SLA are more straightforward. Availability, MTTR, and installation and upgrade performance are mostly self-explanatory:

• Availability—Defines the hours that the service should be available and the per-centage of time within that availability window that the service must be available without the provider’s incurring penalties.

• MTTR—Refers to how quickly the provider will repair faults within the network and restore service.

• Installations and upgrade performance—Tells the provider how long it has to get a new site operational after the order has been delivered by the enterprise, or how long it has to upgrade facilities should the enterprise order that.

Network Operations Training

Clearly, with a new infrastructure to support, system administrators need appropriate training in the technology itself, the procedures to use to turn up or troubleshoot new sites, and the tools they will have to assist them in their responsibilities. The question of whether to train the enterprise operations staff in the operation of MPLS VPNs (with respect to the service operation within the provider’s network) is open. Some enterprises may decide that, because no MPLS encapsulation or MPLS protocols will be seen by the enterprise network operators, no training is necessary for this technology. However, experience to date has shown that when you troubleshoot issues with service provider staff, knowledge of MPLS VPN operation is helpful.

The following high-level topics were taught to a large enterprise that successfully migrated network operations to a provider-delivered MPLS VPN service. These topics can be used as a template to evaluate training offerings to see if all necessary topics are covered:

• Routing protocols (PE-to-CE and BGP)

• MPLS

• QoS

• Multicast

These topics can be covered with course outlines that are similar to the following:

Implementation Planning

To ensure a smooth transition to the new network service, each site requires careful planning. The following is provided as an example of how to identify tasks, assign owners, and track the progress of actual versus planned activities. This is offered as a starting point for when you consider what activities are necessary to ensure a proper working installation at each site. This documentation exists for the following phases of the network transition:

• Phase 1—Pre-cutover to ensure that all planning documents are complete and distributed

• Phase 2—Connecting major sites to the new network

• Phase 3—Cutover on a site-by-site basis

• Phase 4—Post-cutover activities and sign-off

Phase 1

Phase 1 contains documentation that resembles Table 10-1.

Table 10-1 Typical Phase 1 Implementation Planning Tasks

Phase 2

Phase 2, which is the stage of planning a major site (such as an IDC) connection to the new production network, must be completed. This could be monitored via a document like that shown in Table 10-2.

Table 10-2 Typical Phase 2 Implementation Planning Tasks

Phase 3

Phase 3 involves rolling out the network implementation to all locations. There may be many sets of procedures for sites of differing sizes and complexity; however, the aim is to produce a reasonable set of procedures that can be replicated in each site with similar requirements. Some suggested details for this phase appear in the section “On-Site Implementation.”

Phase 4

Phase 4, the final phase, defines the activities to be completed post-cutover and includes the items covered in Table 10-3. This phase should be executed as a rolling activity because the installation progresses through all geographies and sites the new network will reach.

Table 10-3 Typical Phase 4 Implementation Planning Tasks

On-Site Implementation

This section discusses the required tasks to survey a site ahead of installation and lists the tasks for a circuit activation check. Clearly, after all the communications testing and as soon as the new links and routers can be monitored by network management systems, a final check is required that checks all applications from the user’s perspective.

The site survey is important to plan what needs to be done during the installation for each site. The investment in a properly executed pre-installation survey is well worth the payback in terms of a smooth installation experience. Table 10-4 shows a list of things to consider.

Table 10-4 Typical Site Survey Requirements

After all this information is gathered and analyzed and has resulted in the appropriate orders and shipping of equipment, it’s time to install the equipment and verify its operation. Typically, the provider installs at least up to the demarc point, with likely installation of the routers themselves and the channel service unit/digital service unit (CSU/DSU) if it is not already built into the router.

The following addresses concepts for verifying circuit and communications activation. As stated previously, as soon as all communications are verified, a final user test of all applications’ operation is required before the site is considered complete in terms of migration and is accepted by the enterprise.

By whatever means the enterprise is comfortable using, the circuit must be deemed to be clean, which means that error rates on the line are within design limits. Typically, this is achieved by performing a Bit Error Rate Test (BERT) for several hours. A BERT ensures that the circuit is working properly by testing for the following:

• Packet loss across the carrier backbone must be what was contracted for all data classes.

• Latency characteristics, as defined in the SLA, must be met.

• New links need to deliver the expected bandwidth paid for.

In the event of a link or PVC failure of the new circuit, restoration has to be provided within the contracted guidelines via an alternative path within the provider’s network (if available).

Case Study Selections

For the case study used throughout this book, the forms and processes defined are close to those used by Acme. The RFP, detailed design document, site planning, and site completion milestones were the primary checkpoints in monitoring the migration progress.

The primary selection made during the early stages that affected the network design directly was when different providers were used in different geographies. In those situations, Acme decided to place its own router between the two providers to handle IP connectivity.

Interprovider solutions would allow multiple providers to collaborate and provide seamless service without requiring this additional handoff, but political issues seem to be the cause of preventing that from happening at this point.

Summary

Based on the information in this chapter, you now have a good idea of what to write up as a table of contents for your RFP, and you know how that relates to the SLAs you require for network, installation, and repair performance. You now also understand that, after vendors are selected, the critical document is the detailed design that specifies how both you and the service provider will deliver the end service. Finally, you understand the training require-ments for operations, and you have the suggested site planning and completion forms.

Copyright © 2007 Pearson Education. All rights reserved.