Evolutionary Change of Enterprise Networks

These shifting business climates have forced the enterprise network architect to look at new architectures for the network. What was once a simple star architecture based from the corporate HQ location now needs to address peer-to-peer applications. Instead of almost every user endpoint in the network communicating with a central resource, user endpoints are now talking to each other in the form of voice over IP (VoIP), videoconferencing, instant messaging (IM), and document sharing.

To address these demands, the architect must look at alternative network designs that optimize the network. Imagine a scenario in which an enterprise is based in Washington, D.C., and has branch offices in San Francisco and Los Angeles. With a traditional network, the enterprise would likely have a Frame Relay PVC between Washington, D.C. and Los Angeles and between Washington, D.C. and San Francisco. A user in Los Angeles communicating with a user in San Francisco would result in a communications path from Los Angeles, across the U.S. to Washington, D.C., and back across the U.S. to San Francisco, which may result in lower-quality communications. To address this, the enterprise network architect must look at how to optimize latency such that the communications traffic from the Los Angeles office to the San Francisco office can take a much shorter path.

Typical enterprise networks have been built without the quality of service (QoS) capabilities necessary to support delay-sensitive and drop-sensitive traffic, such as VoIP and videoconferencing. The architect must ensure that his or her network can provide support for these real-time applications. This requires increased focus on the part of the enterprise network architect, ensuring that the network has not only optimal latency, but also the proper QoS guarantees.

The typical enterprise would like to be able to reduce the amount of effort and time it takes to build an optimized network. To reduce and optimize latencies, as previously mentioned, the enterprise architect must work with the service provider to understand the basic backbone network, or fiber paths, that the service provider uses. With a map in hand, the enterprise architect can lay out a series of small hubs located where fiber maps meet, form a backbone between the hubs, and then connect each branch office into one of these hubs based on the service provider's access.

For example, the map shown in Figure 1-2 shows how the enterprise architect for the network shown in Figure 1-1 may reorganize his or her network to optimize latency. Note that in contrast with Figure 1-1, in which each site connects all the way back to corporate HQ in San Francisco, each satellite office is now connected to its nearest hub location.

Figure 1-2. Latency-Optimized Network Architecture

In this case, the enterprise IT department may find that there is considerable bandwidth savings or very little additional bandwidth cost in optimizing the network in this way. In this specific example, the average length of a circuit was reduced to 15 percent of its original value, and the bandwidth was increased by 500 percent. In a real-world pricing scenario, this was all accomplished with a very minimal (less than 5 percent) price increase.

The number of hubs, their locations, and their interconnection points depend on the service provider capabilities, the number of enterprise branch offices that may be connected to a hub, and the equipment and circuit costs to establish a hub location. Facilities for hub locations must be considered, whether the hub is established in local branch offices or the enterprise leases space in service provider facilities.

The process of studying fiber maps, establishing hub locations, determining hub facilities, mapping branch offices, and identifying bandwidths can be overwhelming and time-consuming.

One option the architect has is to look at outsourcing the network design to a systems integrator or the professional services organization within his or her chosen service provider. Although this addresses any potential lack of technical skills in the enterprise's IT department, it requires the outsourcer to spend some time understanding the enterprise's business objectives and requirements. The outsourcers may not be able to fully understand the enterprise's business goals and therefore may not be able to play a strategic part in advancing the enterprise's business. Once the learning process is complete, the outsourcer can build a custom, optimized network for the enterprise based on the enterprise's locations and service provider's fiber paths.

Another alternative is the use of IP/MPLS virtual private network (VPN) technology. IP/MPLS VPNs allow enterprises to outsource, effectively, the network's core. Instead of requiring you to spend significant time building a plan for hubs and branches, the technology allows the enterprise to leverage a network with built-in latency optimization. As service providers build out their IP/MPLS network, all enterprise customers using the IP/MPLS VPN service take advantage of the build-out. It also fully meshes the sites on the network, which optimizes for latency beyond a regionally distributed hub-and-spoke network.

The net result is a significant economy of scale, from network engineering to core network capacity planning to managing and monitoring customer networks.

This book describes key enterprise aspects of IP/MPLS VPN technology and how Acme, Inc., a sample global manufacturing enterprise, can leverage IP/MPLS VPNs to reduce its operational expense and increase capabilities for its applications on the enterprise network. This and subsequent chapters discuss the general issues that an enterprise network manager needs to consider. Recommendations specific to Acme are identified and justified in the Summary section at the end of each chapter.