The Complete IS-IS Routing Protocol- P40 pptx

390 13. IS-IS Extensions RFC 3847 describes the optional Restart Signaling TLV #211 that can be used to sig- nal a grace period until adjacency formation is completed. Figure 13.20 illustrates the 3-byte fixed length TLV. The first byte contains the Restart Request and the Restart Acknowledge Flag. The remaining 16-bits contain the hold time that a node sets itself for performing the reboot. Both IOS and JUNOS generate the Restart Signaling TLVs per default to indicate to remote neighbours that they support graceful restart in general. Tcpdump output TLV #211 under normal working conditions has the RR and RA Bits cleared and the remaining Hold timer set to 0s. 02:00:08.223369 Out OSI, IS-IS, length: 82 point-to-point IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1027, holding time: 27s, circuit-id: 0x01, Flags: [L1L2] [… ] Restart Signaling TLV #211, length: 3 Restart Request bit clear, Restart Acknowledgement bit clear Remaining holding time: 0s In both IOS and JUNOS the restart capability is indicated in the detailed adjacency output. IOS command output The show clns neighbors detail command shows if the neighbour supports graceful restart. London# show clns neighbors detail System Id Interface SNPA State Holdtime Type Protocol Frankfurt POS2/0 PPP Up 25 L2 M-ISIS Area Address(es): 49.0001 IP Address(es): 172.16.33.213* IPv6 Address(es): FE80::2A0:A5FF:FE12:3398 Uptime: 00:15:41 NSF capable Topology: IPv4, IPv6 Type Length Reserved 211 Bytes 1 1 1 3 Remaining Holdtime 2 RA RR FIGURE 13.20. The Restart Signaling TLV is used for requesting an granting a new Hold timer Graceful Restart 391 In the IOS terminology Non Stop Forwarding (NSF) is an alternative term for graceful restart. JUNOS command output hannes@Frankfurt> show isis adjacency detail [… ] London Interface: so-1/2/0.0, Level: 2, State: Up, Expires in 23 secs Priority: 0, Up/Down transitions: 11, Last transition: 00:24:12 ago Circuit type: 3, Speaks: IP, IPv6 Topologies: Unicast, IPV6-Unicast Restart capable: Yes IP addresses: 172.16.33.29 IPv6 addresses: fe80::203:fdff:fec8:3c00 [… ] Graceful restart will be the foundation for higher availability in core networks. It is not a single technology, but rather a concept that allows a node to still forward during con- trol plane failure or intended downtime like router software upgrades. Because graceful restart is a cooperative technology (that means it needs to rely on the fact that all of its neighbours support it) it is recommended to deploy it on a broad scale on every network. 13.7 Summary The last 10 years were filled with extensions to the IS-IS protocol. Deficits like missing checksums in certain PDU types got fixed. TLV #10, one of the original ISO 10589 TLVs, is used as an envelope to convey HMAC-MD5 strong authentication information. IPv6 routing has been introduced albeit with the same deployment restriction that RFC 1195 suffered from. Multi topology IS-IS attempts to solve that problem by defining extra TLVs and introduction per-protocol SPF runs. However, due to broad MPLS deployment, IPv6 for control plane purposes may become obsolete. BGP in conjunction with MPLS as a forwarding magic carpet may finally make MT-ISIS obselete. Finally, IS-IS got the ability for gracefully restarting a control plane processor without churning the network at all. Extensions like this are the prerequisite for the Internet becoming the dominant public infrastructure some day (soon). 14 Traffic Engineering and MPLS 393 At the end of the 1990s, the Internet was expanding at a breathtaking speed. Both capacity and geographic spread grew by factors of 2 to 4 per year. It appeared that capacity could not be provisioned in time and the network could suffer congestion anytime. Service providers needed to re-route traffic onto paths in the network that had been underutilized in order to take some of the load off the congested links. It quickly became evident that the IP world until this time lacked a sound load-balancing tool to adapt the traffic to the underlying topology in the most rational manner. MPLS provided for the first time source routing intelligence to the Internet and, due to its path orientation, the necessary control to guide traffic. However, provisioning the label switched paths manually proved to be a daunting task and service providers and router vendors co-developed a kind of distributed traffic control system whereby MPLS paths can be brought up, loaded with traffic, and torn down based on constraints like bandwidth and hop count limits between POPs. The network service provider is now, for the first time, fully in control about the flow of transit traffic, based on high-level constraints likes hop-count, bandwidth utilization, and so on. In this chapter the original motivations and problems for Internet traffic engineering, the limits of IGP metric balancing the rise of MPLS and the role that IS-IS plays in the distributed traffic control system will be highlighted. In addition, this chapter covers more advanced topics like DiffServ traffic engineering and forwarding adjacencies. 14.1 Traffic Engineering by IGP Metric Tweaking In the IP world, routing protocols try to compute the shortest path between a pair of sub-nets. A common sense example from the real world says that the shortest path may not be the best path, as everybody getting stuck in the Monday morning and Friday evening traffic jams on the highways knows. The shortest path from a distance perspective means nothing if the load on that path is too high and therefore causes queuing delays. Consider Figure 14.1, where we have one “hot” link between Frankfurt and London suffering from 110 per cent loading and so dropping traffic. Historically network engineers tried to load balance traf- fic by modifying the IGP costs of the links to try and get some of the load off the “hot” link. IGPs calculate their topology in a highly distributed fashion. If a single link cost is modified, this may have global impact in the IGP domain. This is not that much of a prob- lem in small networks. On a small network, even a human brain can process the topology and estimate all the consequences resulting from an IGP link cost change manually. 394 Area 49.0001 Level 2-only oc-48 metric 4 70% load oc-48 metric 6 60% load oc-48 metric 4 Frankfurt London Washington New York Paris oc-48 metric 4 oc-48 metric 4 70% load oc-48 metric 4 40% load 20% load 110% load F IGURE 14.1. The segment between Frankfurt and London is congested Traffic Engineering by Layer-2 Overlay Networks 395 However, in moderately sized networks where the number of routers and links exceeds the processing capability of human operators, the IGP acts as a complex system and therefore produces undesired side effects during route calculations. A change in the IGP cost may result in a too drastic change of load patterns across the network. It is almost like people jumping from one side of the bus to the other and almost tipping the bus over. Consider Figure 14.2, where the traffic engineer tries to offload some traffic on the Frankfurt to London link by changing the link-metric from 4 to 11. Now three links (Frankfurt–Paris, Frankfurt–London, Frankfurt–Washington) become unattractive for many routers in the network, and the traffic jumps onto the Washington–London path. In the end, nothing is gained, as there is still an imbalance, however, this time on a different link in the core network. In this example the change resulted in an even worse overall utili- zation because now two network segments are congested. The main problem here is the granularity in controlling the traffic. Often the only granu- larity the IGP gives to the traffic engineers is loading or unloading an entire trunk line. Loading and unloading in smaller increments, for example, in 5 per cent incremental steps would be much better. Network operators need a tool where traffic engineering does not interfere with routing decisions. The first solution for decoupling routing and traffic engineering was achieved using so called Layer-2 overlay network, a popular technique during the mid-1990s. 14.2 Traffic Engineering by Layer-2 Overlay Networks Figure 14.3 shows the basic structure of a Layer-2 overlay network. The core of the net- work is composed of a set of circuit-oriented Layer-2 switching devices (for example, ATM or Frame Relay switches). Routers sitting at the edge of the network surround the overlay network core. In the mid-1990s, when this type of network was popular, there was relatively little Layer-3 forwarding power. This was the heydays of the Cisco 7500 Series, which could forward at best 200 MBit/s of traffic. Therefore there was a lot of interest to keep the traffic as long as possible in the Layer-2 switching domain. Consequently, a full- mesh of VCs between the routers was built up. Now, traffic engineering is relatively easy: the traffic engineer simply needs to rearrange the VCs of the core network if a trunk is becoming congested, or in service provider speak, getting hot. The bottom of Figure 14.3 shows the router’s viewpoint from a logical perspective. Basically, each router sees each other router. This in turn severely stresses the flooding sub-system of link-state routing protocols enormously. Chapter 6, “Generating, Flooding and Ageing LSPs”, presented more details as to the catastrophic effects such full-mesh setups have during re-routing conditions. Ultimately, the flooding-explosion described in Chapter 6 were solved by a technique called mesh-groups. What remained was not a technical but an administrational problem. In order to manage the router network, service providers needed to run two teams. The ATM team running the core network was responsible for traffic engineering, and the IP team was responsible for running the router infrastructure. Unfortunately, those two responsibilities cannot be strictly separated. Traffic engineering in the core is one thing, the other (and more important) aspect is interdomain traffic engineering, which controls the entrance point where traffic enters the 396 Area 49.0001 Level 2-only 180% load oc-48 metric 6 0% load oc-48 metric 4 0% load oc-48 metric 11 0% load oc-48 metric 4 Frankfurt London Washington NewYork Paris 90% load oc-48 metric 4 170% load oc-48 metric 4 F IGURE 14.2. A change of a single IGP cost may have a global impact on the utilization of other trunks in the netw ork IP Network. Consider Figure 14.4, where router New York becomes very attractive by advertising a lower MED value than router London, and now large traffic volumes are relayed to router New York. As soon as the traffic arrives at New York, it may become a prob- lem because the only thing left to do is balancing over the existing, internal VC infrastruc- ture. In order to balance traffic efficiently, traffic engineers need to also control the external link with regard to how much traffic is flowing into the network. This is not an unsolvable problem; it is a matter of coordination between departments inside a service provider. But experience has shown that even this level of minimal coordination is often lacking or just did not work out very well. Aside from those coordination issues, service providers wanted to have an integrated solution so that they could perform both traffic engineering and routing on a single platform if for no other reason than cost. The lack of router knowledge of the underlying topology also causes sometimes weird re-routing behaviour. Consider Figure 14.5, where the direct VC between Paris and Frankfurt fails. In the IGP topology every VC has a cost of 1. Because there is no direct alternate path (cost 1) available, the network takes the next best path which is at a cost of 2. Unfortunately, there are now a whole set of feasible paths available: • Via Washington DC • Via New York • Via London Traffic Engineering by Layer-2 Overlay Networks 397 Physical Topology Logical Topology Seattle San Fran Atlanta Seattle San Fran Atlanta FIGURE 14.3. In overlay networks all routers are directly connected to each other from a network layer perspective Depending on the Paris router configuration, either a random single path or limited set of paths will be picked. In the example, New York has been elected as the backup path, which causes an additional trans-Atlantic delay. The customers were used to having delays of about 5 ms between Paris and Frankfurt, and not the resulting 40 ms. And the 398 14. Traffic Engineering and MPLS AS 65001 Area 49.0001 Level 2-only AS 1239 Frankfurt London Washington NewYork Paris NewYork London 105% load oc-48 MED 4 20% load oc-48 MED 6 FIGURE 14.4. Interdomain traffic engineering cannot be done using local VC path changes and hence the IP group of a Network Service Provider still has traffic engineering responsibilities Area 49.0001 Level 2-only 1 1 1 1 1 1 1 1 1 Frankfurt Washington NewYork Paris London 1 F IGURE 14.5. Because of lack of topological insight a single failing VC may impose additional delay trans-Atlantic routes are, by the way, very expensive because this capacity comes at a premium. The other constraint is that routers limit the number of equal cost paths that they use for path calculation. IOS used to limit this to six equal cost paths, and JUNOS limits it to 16 equal cost paths. Now, consider a full-mesh between 40 POPs and only the first 6 or 16 equal cost paths are being considered once a single VC fails. This results in completely unpredictable backup behaviour and is a capacity planner’s nightmare. In addition to those cost and delay problems, there is also the problem of the Layer-2 overhead in ATM networks. An ATM cell consists of a 5-byte header and a 48-byte pay- load. IP packets need to get chopped into pieces to fit in those ATM payload bytes. A sequencing scheme which numbers the fragments and detects the start and end of an IP packet is needed to reassemble the packet at the end of the cell-switching domain. In the ATM world those functions are performed by the ATM Adaptation Layer 5 (AAL-5). Before the IP packet is passed to the segmentation and reassembly (SAR) chip for gen- eration of an ATM AAL-5 compliant cell-stream, a Layer-2 header has to be prepended for Layer-2 demultiplexing. Recall that at least two protocols are necessary in the net- work: IPv4 and OSI (for conveying the non-IP IS-IS packets). Typically, Layer-2 is implemented by prepending a Sub Network Access Protocol (SNAP) header for mux- ing/demuxing purposes. A SNAP header ensures that the receiver can differentiate between IPv4 and IS-IS packets on the wire. The SNAP, plus the AAL-5 information, represents a certain level of static overhead. However, there is also a dynamic overhead that results from inefficient packaging of IP packets into cells. Figure 14.6 shows a histogram of the packet size distribution on the Internet as measured by probes on pub- lic peering points. There is a peak of 35.5 per cent at the 40 bytes mark, which accounts for all the TCP Acknowledgements (ACKs). This is no big surprise as the majority of IP applications (and hence the majority of traffic) are based on TCP as the transport proto- col. And that is where the problem begins. Figure 14.7 shows a very good example of the inefficiencies resulting from the dynamic overhead contribution. Consider a TCP ACK of 40 bytes (20 bytes IP header plus 20 bytes of TCP header) that needs to have a SNAP header prepended, an AAL-5 trailer appended, and finally packaged in ATM cells. A single 40-byte packet with the entire static overhead contributed by the SNAP header and AAL-5 trailer cannot be squeezed into a single cell, and therefore has to use a second cell. However, in the second cell the majority of infor- mation is padding information. Clearly this is an extreme situation, in the sense that a single 40-byte packet consumes 106 bytes on the carrying media, which is an overhead of 63 per cent! However, there are dynamic overhead peaks resulting from “cell-ification” every 48 bytes across the entire packet size distribution histogram. Common experience is that the nominal overhead on an Internet traffic mix is about 20 per cent. In other words, only 115 MBit/s out of the potential channel capacity of an 148.5 MBit/s SONET/SDH pipe can only be used for transporting IP data. Extrapolating those numbers shows that on an OC-48/STM-16 trunk, roughly 500 MBits of capacity is burned due to cell-ification. That represents a lot of extra traffic, and also a lot of extra money that service providers could earn, if they could transport that traffic and not needing to purchase higher-speed trans- mission links, ATM and router equipment. The third big problem resulting from ATM overlay cores is the reality that router vendors did not make ATM-interfaces with speeds higher than OC-12/STM-4 available. Traffic Engineering by Layer-2 Overlay Networks 399 Although ATM engineers often claim that this is purely the result of a conspiracy from the router vendors (!); the reality is that on the semiconductor supplier market today there are still no SAR chips available that can segment and reassemble IP packets/cell-streams with a speed higher than OC-12/STM-4. The main reason for ATM SAR chips trailing behind the Internet growth curve is due to the technical complexity of generating AAL-5 frames at higher wire-speeds. From an overhead and speed reality point of view, service providers quickly decided that the ATM road was a dead-end and provisioned their cores mainly using IP over SONET/SDH technology, thus making the ATM layer essentially obsolete. Somewhat ironically, Layer-2 overlay networks were not that bad from a control perspective. The nicest feature was the level of granularity available to control traffic flow in the core. The service provider could easily relay a single portion of City A to City B traffic, without hav- ing any impact on the AS-wide traffic distribution. This can be mainly accounted for by the path-orientation of ATM VC and Frame Relay DLCIs. It was now clear from this experience that any potential integrated traffic engineering solution for IP had to have a path orientation as well. 400 14. Traffic Engineering and MPLS Internet traffic mix Packet size (Bytes) Proportion of total Bandwidth (Load) 28 1,20% 0,08% 40 35,50% 3,51% 44 2,00% 0,22% 48 2,00% 0,24% 52 3,50% 0,45% 552 0,80% 1,10% 576 11,50% 16,40% 628 1,00% 1,50% 1420 3,00% 10,50% 1500 10,00% 37,10% Internet packet size/Bandwidth distribution 0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00% 28 40 44 48 52 552 576 628 1420 1500 Proportion of Total Bandwidth (Total) FIGURE 14.6. The majority of packets in the Internet are 40-byte sized . side of the bus to the other and almost tipping the bus over. Consider Figure 14.2, where the traffic engineer tries to offload some traffic on the Frankfurt to London link by changing the link-metric. numbers the fragments and detects the start and end of an IP packet is needed to reassemble the packet at the end of the cell-switching domain. In the ATM world those functions are performed by the. evident that the IP world until this time lacked a sound load-balancing tool to adapt the traffic to the underlying topology in the most rational manner. MPLS provided for the first time source routing