diff --git a/capacity/traffic.rst b/capacity/traffic.rst index 3f0e686..707397a 100644 --- a/capacity/traffic.rst +++ b/capacity/traffic.rst @@ -1,50 +1,54 @@ .. index:: TE: Traffic Engineering +.. index:: MPLS: Multiprotocol Label Switching + |Capacity|.5 Traffic Engineering ----------------------------------------- - -The idea of traffic engineering for packet-switched networks is almost -as old as packet switching itself, with some ideas of traffic-aware -routing having been tried in the ARPANET. However, traffic engineering -only became mainstream for the Internet backbone with the -advent of MPLS, which provides a set of tools to steer traffic to -balance load across different paths. The key idea is that when there -is more than one path between two points in the network, it would be -best to split the traffic among those paths in a way that avoids -overloading any one of them. That simple idea has proven challenging -to implement. - -Step zero of traffic engineering is to provision links between the -various points-of-presence (PoPs) or data centers that make up the -network. That operation usually happens at relatively long timescales, -since it might involve pulling fiber through conduits, or activating -wavelengths on a WDM (wavelength division multiplexing) -system. These links also need to be connected to switches and routers -of suitable capacities. The traffic engineering process, from the -perspective of those operating an IP network, takes an underlying -topology of links of various capacities as a given, and tries to map -the offered traffic onto that topology. - -One of the key challenges for traffic engineering is -that the offered traffic load varies at every timescale down to the -nanosecond, while changes to the underlying link capacities and -topology can be made only at much longer timescales. Traffic loads -often display daily patterns with peak hours separated by quieter -periods, but there can also be sudden shifts in load caused by the -behavior of applications and end users. Further complicating the -problem is the fact that links or routers may fail, removing some -capacity from the system. - -MPLS provides a convenient way to control the path of traffic through -the network that goes some way to address the challenges of traffic -engineering. The capability is often referred to as -*explicit routing* although it has some similarities to a feature in -IP known as *source routing*.\ [#]_ :numref:`Figure %s ` shows an -example of how the explicit routing capability of MPLS might be -applied. This sort of network is often called a *fish* network -because of its shape (the routers R1 and R2 form the tail; R7 is at -the head). +Traffic engineering (TE) for packet-switched networks is almost as old +as packet switching itself. But the term has taken on a range of +meanings over time, the only constant being that decisions about +traffic flows across a network are made based on observed traffic +patterns. One aspect of traffic engineering is about capacity planning +and provisioning. For example, when you see persistently high +utilization of a link between two sites, you might either provision a +higher speed link, or alternatively, add additional sites (and hence, +paths) to your overall network topology. + +Where definitions get murky is when those kinds of activities can be +carried out in a matter of seconds or minutes due to automation, for +example, by activating a new circuit or optical wavelength, as +describe in Section |Tech|.3. As another example, techniques that +balance load across two or more equally viable paths—as we saw in +Section |Routing|.5, with the use of ECMP—is sometimes described as a +kind of traffic engineering. Routing algorithms are viewed as distinct +from traffic engineering, although deciding how to set the link +metrics used by the algorithm is usually considered an aspect of TE. + +The ambiguity notwithstanding, today there is a widely accepted +interpretation of traffic engineering, focused on steering traffic +across different paths in an attempt to balance load. The key idea is +that when there is more than one path between two points in the +network, it would be best to split the traffic among those paths in a +way that avoids overloading any one of them. That simple idea has +proven challenging to implement for an equally simple reason: the +offered traffic load varies at every timescale down to the nanosecond, +while changes to the underlying link capacities and topology can be +made only at much longer timescales. Traffic loads often display daily +patterns with peak hours separated by quieter periods, but there can +also be sudden shifts in load caused by the behavior of applications +and end users. Further complicating the problem is the fact that links +or routers may fail, removing some capacity from the system. + +MPLS (Multiprotocol Label Switching) is a technology that provides a +convenient way to control the path of traffic through the network that +goes some way to address the challenges of traffic engineering. The +capability is often referred to as *explicit routing* although it has +some similarities to a feature in IP known as *source routing*.\ [#]_ +:numref:`Figure %s ` shows an example of how the explicit +routing capability of MPLS might be applied. This sort of network is +often called a *fish* network because of its shape (the routers R1 and +R2 form the tail; R7 is at the head). .. _fig-fish: .. figure:: capacity/figures/f04-22-9780123850591.png @@ -53,9 +57,10 @@ the head). A network requiring explicit routing. -.. [#] IP source routing is not widely used for several reasons, including the fact that - only a limited number of hops can be specified and because it is - processed outside the “fast path”, if it is handled at all, on most routers. +.. [#] IP source routing is not widely used for several reasons, + including the fact that only a limited number of hops can be + specified and because it is processed outside the “fast path”, + if it is handled at all, on most routers. Suppose that the operator of the network in :numref:`Figure %s ` has determined that any traffic flowing from R1 to R7 @@ -63,32 +68,32 @@ should follow the path R1-R3-R6-R7 and that any traffic going from R2 to R7 should follow the path R2-R3-R4-R5-R7. One reason for such a choice would be to make good use of the capacity available along the two distinct paths from R3 to R7. We can think of the R1-to-R7 traffic -as constituting one forwarding equivalence class (FEC), and the R2-to-R7 -traffic constitutes a second FEC. Forwarding traffic in these two -classes along different paths is difficult with normal IP routing, -because they might both contain traffic destined for the same IP -addresses. R3 doesn’t normally look at where traffic came *from* in making -its forwarding decisions. +as constituting one forwarding equivalence class (FEC), and the +R2-to-R7 traffic constitutes a second FEC. Forwarding traffic in +these two classes along different paths is difficult with normal IP +routing, because they might both contain traffic destined for the same +IP addresses. R3 doesn’t normally look at where traffic came *from* in +making its forwarding decisions. Unlike IP, MPLS uses label swapping to forward packets. Rather than looking at the destination address, an MPLS router looks at a label in the packet header and makes a forwarding decision based on the value of that label. Importantly, labels are swapped at every hop (usually) and have local scope, unlike IP addresses. So the packets from R1 to -R7 might have label *L1* in the header when they arrive at R3, while those from R2 to R7 have -label *L2* in the header, even though both sets of packets have the -same destination. We have created two distinct FECs, associating a -different label with each FEC, and this allows R3 to forward the -traffic in the two classes differently. +R7 might have label *L1* in the header when they arrive at R3, while +those from R2 to R7 have label *L2* in the header, even though both +sets of packets have the same destination. We have created two +distinct FECs, associating a different label with each FEC, and this +allows R3 to forward the traffic in the two classes differently. -The question that then arises is how do all the routers in the network +One question that then arises is how do all the routers in the network agree on what labels to use and how to forward packets with particular -labels? The protocol that was adopted and extended for -this task is the Resource Reservation Protocol (RSVP). For now it -suffices to say that it is possible to send an RSVP message along an -explicitly specified path (e.g., R1-R3-R6-R7) and use it to set up -label forwarding table entries all along that path. This is very -similar to the process of establishing a virtual circuit. +labels? The protocol that was adopted and extended for this task is +the Resource Reservation Protocol (RSVP). For now it suffices to say +that it is possible to send an RSVP message along an explicitly +specified path (e.g., R1-R3-R6-R7) and use it to set up label +forwarding table entries all along that path. This is very similar to +the process of establishing a virtual circuit. Once we have the mechanism of explicit routing, we can apply it to the task of traffic engineering. The most common approaches is @@ -102,7 +107,6 @@ SPF algorithm described in Section |Routing|.3 except that links which don't meet the constraints, e.g., because they lack sufficient capacity for the demand, are excluded from the calculation. - CSPF can work well, but as a distributed algorithm, it has some weaknesses. Central planning tools are commonly used to supplement CSPF, but the real-time management of MPLS paths is usually fully diff --git a/virtual/vpn.rst b/virtual/vpn.rst index 7c81c8e..b672df7 100644 --- a/virtual/vpn.rst +++ b/virtual/vpn.rst @@ -1,5 +1,4 @@ .. index:: VPN: Virtual Private Network -.. index:: MPLS: Multiprotocol Label Switching |Virt|.3 Virtual Private Networks (VPNs) -----------------------------------------------