|
|
||||||||||||||||||||
| Home > Traffic engineering the service provider network | |
| Telecom Insights: |
|
||
In this guide:
Traditional service provider networks provided Layer 2 point-to-point virtual circuits with contractually predefined bandwidth. Regardless of the technology used to implement the service (X.25, Frame Relay or ATM), the traffic engineering (optimal distribution of load across all available network links) was inherent in the process. In most cases, the calculation of the optimum routing of virtual circuits was done off-line by a network management platform; advanced networks (offering Frame Relay or ATM switched virtual circuits) also offered real-time on-demand establishment of virtual circuits. However, the process was always the same:
Internet and most IP-based services, including IP-based virtual private networks (VPNs) implemented with MPLS VPN, IPsec or Layer 2 transport protocol (L2TP), follow a completely different service model:
Simplified to the extreme, the two paradigms could be expressed as follows:
The significant difference between the cost-per-switched-megabit of Layer 2 network (for example, ATM) and routed (IP) network has forced nearly all service providers to build next-generation networks exclusively on IP. Even in modern fiber-optics networks, however, bandwidth is not totally free, and there are always scenarios where you could use free resources of an underutilized link to ease the pressure on an overloaded path. Effectively, you would need traffic engineering capabilities in routed IP networks, but they are simply not available in the traditional hop-by-hop, destination-only routing model that most IP networks use. Various approaches (including creative designs, as well as new technologies) have been tried to bring the traffic engineering capabilities to IP-based networks. We can group them roughly into these categories:
The Layer 2 network core design was used extensively when the service providers were introducing IP as an additional service into their WAN networks. Many large service providers have already dropped this approach because it does not result in the cost reduction or increase in switching speed that pure IP-based networks bring.
Virtual circuits implemented with IP-over-IP tunnels (using a variety of technologies) are approximately as complex as routing protocol cost-tuning and so are better avoided (although they could still represent a valuable temporary fix). MPLS traffic engineering (MPLS TE), on the other hand, is a complete implementation of traffic engineering technology rivaling the features available in advanced ATM or Frame Relay networks. For example:
The support for MPLS TE is available in high-end and midlevel routers from multiple vendors. It's therefore highly advisable that you consider the requirements of MPLS TE (OSPF or IS-IS, for example) in your network design. If you implement the basic infrastructure needed by MPLS TE during the network deployment, you'll have it ready to use when you need to shift the traffic to cope with unexpected increases in bandwidth usage or delayed deployment of higher-speed links.
MPLS (Multi-protocol Label Switching) is the end result of the efforts to integrate Layer 3 switching, better known as routing, with Layer 2 WAN backbones, primarily ATM.. Even though the IP+ATM paradigm is mostly gone today because of the drastic shift to IP-only networks in the last few years, MPLS retains a number of useful features from Layer 2 technologies. One of the most notable is the ability to send packets across the network through a virtual circuit called Label Switched Path, or LSP, in MPLS terminology. NOTE: While the Layer 2 virtual circuits are almost always bidirectional (although the traffic contracts in each direction can be different), the LSPs are always unidirectional. If you need bidirectional connectivity between a pair of routers, you have to establish two LSPs. The LSPs in MPLS networks are usually established based on the contents of IP routing tables in core routers. However, there is nothing that would prevent LSPs being established and used through other means, provided that:
NOTE: The other routers along the LSP do not inspect the packets traversing the LSP and are thus oblivious to their content; they just need to understand the signaling protocol that is used to establish the LSP. With the necessary infrastructure in place, it was only a matter of time before someone would get the idea to use LSPs to implement MPLS-based traffic engineering -- and the first implementation in Cisco IOS closely followed the introduction of base MPLS (which at that time was called tag switching). The MPLS traffic engineering technology has evolved and matured significantly since then, but the concepts have not changed much since its introduction:
NOTE: The first MPLS TE implementations supported only static hop-by-hop definitions. These can still be used in situations where you need a very tight hop-by-hop control over the path the MPLS TE LSP will take or in networks using a routing protocol that does not have MPLS TE extensions.
The tight integration of MPLS traffic engineering with the IP routing protocols provides an important advantage over the traditional Layer 2 WAN networks. In the Layer 2 backbones, the operator had to establish all the virtual circuits across the backbone (using a network management platform or by configuring switched virtual circuits on edge devices), whereas the MPLS TE can automatically augment and enhance the mesh of LSPs already established based on network topology discovered by IP routing protocols. You can thus use MPLS traffic engineering as a short-term measure to relieve the temporary network congestion or as a network core optimization tool without involving the edge routers. In recent years, MPLS traffic engineering technology (and its implementation) has grown well beyond features offered by traditional WAN networks. For example:
NOTE: Thanks to RSVP-TE functionality, the reservations on the path segments common to old and new LSP are not counted twice.
As with any complex technology, network engineers, designers and consultants tend to misunderstand some nuances of MPLS traffic engineering, resulting in myths and half-truths that are propagated throughout the industry. Here I will address some of the more common ones. The analysis is based on MPLS TE technology as described in various Internet Engineering Task Force (IETF) documents, as well as the current implementation available in Cisco IOS releases 12.4T and 12.2S. 1. Myth: MPLS TE is a quality-of-service feature. While MPLS TE can be used to shift traffic from overloaded paths to alternate paths with free bandwidth, it contains no inherent quality-of-service (QoS) features like guaranteed bandwidth, policing or shaping. The quality-of-service features have to be designed and deployed separately on top of the MPLS TE infrastructure. The deployment of MPLS TE in a network does not (by itself) improve the quality of its services. 2. Half-truth: MPLS TE improves network convergence. The MPLS Fast Reroute functionality provides a temporary fix to a link or node failure by shifting the MPLS TE-encapsulated traffic to a preconfigured bypass (no rerouting is provided for regular IP traffic). The convergence and subsequent network topology re-optimization is still performed by the IP routing protocols. 3. Myth: MPLS TE has to be deployed throughout the network. You can use MPLS TE in tactical situations, for example, between a pair of routers to shift the traffic away from a congested link or to provide a fast reroute protection of a critical link in your network. 4. Half-truth: MPLS TE can solve the network congestion issues. MPLS TE does not create new bandwidth; it only allows you to use the existing bandwidth more efficiently. You can use the MPLS TE tunnels to shift the traffic from the lowest-cost path computed by IP routing protocols to an alternate less-utilized path, temporarily relieving the congested link. But that action might cause the congestion of the alternate path, resulting in a domino effect throughout the network. 5. Myth: Bandwidth reserved by an MPLS TE tunnel will be available to the tunneled traffic. Although the MPLS TE technology uses extensions to the Resource Reservation Protocol (RSVP), which was originally designed to provide end-to-end QoS in IP networks, the MPLS TE RSVP reservations serve solely as an accounting mechanism in the MPLS TE module. This prevents link oversubscription by MPLS TE paths. MPLS TE reservations do not result in any QoS actions on the intermediate nodes. Lacking manual configuration on intermediate nodes, MPLS TE traffic is treated indistinguishably from the regular IP or MPLS traffic. 6. Myth: To use MPLS TE, you have to deploy MPLS in your network. MPLS TE can work without network-wide MPLS deployment. Traffic can be sent across MPLS TE tunnels without a label distribution protocol (LDP or TDP).
7. Half-truth: MPLS TE only works with OSPF and IS-IS routing protocols. MPLS TE paths can be configured manually (specifying all hops in the path) and independently of the IP routing protocol deployed in the network. However, if you want to have automatic path calculations and automatic rerouting of IP traffic onto MPLS TE paths, you have to use OSPF or IS-IS. 8. If you use the MPLS TE Fast Reroute, the quality of service will not degrade following a network failure. The MPLS TE Fast Reroute shifts MPLS TE tunnels established across a failed link or node onto preconfigured backup tunnels. The overall quality-of-service will not degrade only if:
9. Half-truth: You can use MPLS TE only within a single OSPF area. Inter-area MPLS traffic engineering is available (see also detailed description), but has severe limitations:
Note: The same is true for IS-IS. Truly dynamic MPLS TE tunnels can be established within a single IS-IS level, but they can cross the level boundary if you manually configure the transition points. 10. No longer true: You can't differentiate customer traffic based on Class-of-Service if you use MPLS TE The technology itself never had this limitation, but Cisco IOS did not support multiple parallel tunnels carrying different traffic classes for a long time. About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html.
'); // -->
|
|||||||||||||||||||||||||||||||||||||||||||
| About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
| |
|
|||||||