IntroductionThe last few years have seen the pace of Multiprotocol Label Switching (MPLS) deployments accelerate in all regions of the globe. MPLS is now a mature technology ready for prime time and able to meet the challenges of 21st century networks. Various factors have driven the adoption of this technology. Initially it provided a scalable architecture through which to deliver Layer 3 Virtual Private Networks (VPNs). More recently, with the surge of multimedia traffic (such as telephony and video) carried on the IP/MPLS backbone, the need for traffic engineering, fast recovery, and differentiated quality of service (QoS) has become apparent. Migration of existing Layer 2 services onto an IP/MPLS infrastructure has also garnered much interest. New MPLS applications such as ATM and Ethernet pseudowire services and Virtual Private LAN Service (VPLS) have emerged to round out a very broad portfolio of MPLS-related services and technologies. Given the widespread acceptance of the technology, MPLS has been integrated into a large set of very diverse service provider environments, including national telcos, IXCs, ILECs, CLECs, RBOCs, global service providers, and ISPs. The success of the Layer 3 VPN service offered by these operators is such that it is generally the benchmark for enterprises to evaluate and build their intranet solutions over. In addition, some large- and medium-sized enterprises are now also building and operating their own private MPLS infrastructures. The ability to combine Layer 2 and Layer 3 VPNs, traffic engineering, fast recovery, and tight QoS and to derive the benefits of each has led to the adoption of MPLS as the basis for the next-generation multiservice networks. These networks carry not only Internet best-effort data traffic but also mission-critical data, telephony, and video. They also deliver VPN, multicast, and IPv6 services and transport ATM, Ethernet, and Frame Relay traffic. This is facilitated by the fundamental decorrelation built into MPLS between application-related functions and transport functions. This allows multiservice MPLS networks to be architected with flexible edge devices that are customer-aware and application-nimble, attached to a high-performance, high-availability core infrastructure that is application- and customer-unaware. Network planners and architects have various sources to turn to when seeking information on the concepts and protocols involved in specific facets of MPLS, such as VPN, QoS, and traffic engineering. However, no single source illustrates how to actually design a network that combines those optimally for a specific environment and provides details on the latest technologies, services, and design techniques. The variety of environments and requirements found in production networks makes it difficult to provide a single set of one-size-fits-all design recommendations. The set of services to be offered by various network operators often vastly differs from one environment to another. For instance, one network operator may have to support multicast traffic within the Layer 3 VPN service. A second may need to offer a rich set of classes of service to address all the application requirements presented to it. A third may have to support IPv6 services. Another may have to trunk ATM switches over the packet network. Also, economic challenges greatly differ between network operators. Whereas one may own fiber and transmission assets and can easily overprovision its network, another may lease its network capacity and thus be pressured to strictly optimize bandwidth usage and make use of MPLS traffic engineering techniques in the core. To complicate matters, restoration requirements may be quite different. One network may target subsecond restoration times. Another network trunking Public Switched Telephony Network (PSTN) traffic may require extremely fast convergence on the order of tens of milliseconds. Another consideration is that although some deployments involve a single autonomous system, others involve multiple operators or force an operator's backbone to be split into multiple autonomous systems for operational, size, or historical reasons. Most features require very different designs, depending on whether they span a single autonomous system, multiple autonomous systems from a single provider, or multiple providers. Also, because of their specificities, different networks hit different scalability barriers and need different features or design alternatives to overcome these limitations. Finally, some MPLS technologies are closely intertwined and need to be designed together to operate in perfect synergy. DiffServ, DiffServ-aware MPLS traffic engineering, and MPLS Fast Reroute are excellent examples of features that need to be combined very thoughtfully because they tightly interact with each other. With so many considerations to take into account when designing a network, the possibilities may appear endless or overwhelming to a service provider or an enterprise moving over to an MPLS network. Definitive MPLS Network Designs aims to address these concerns. It provides you with a series of detailed design studies showing you how to combine key techniques and MPLS-related technologies at the heart of IP/MPLS networks. The design studies present designs of fictitious operators (as opposed to a blueprint for actual designs of existing commercial network operators or enterprises). Each design is representative of existing real-world network designs that have been deployed or are about to be deployed. Throughout the various design studies, sample configurations are given for illustrative purposes. Specific autonomous system numbers and/or public IP address blocks are used as references (these addresses are not attributed to any particular network operator). If these numbers were to be provided to any operator in the future, the design studies would not refer by any means to those operators. Each design study is based on a set of characteristics and objectives common to a given profile of network operators that deploy MPLS today (such as an Interexchange Carrier (IXC), a global provider, an enterprise, and so on) and discusses all the corresponding design aspects. However, the design aspects presented in the context of one operator profile to address a given set of requirements may be applicable in other environments sharing these requirements. Therefore, this book contains different combinations of ideas that, when taken as a whole, provide a reusable design toolkit.
 |