The Complete IS-IS Routing Protocol- P52 potx

512 17. Future of IS-IS TDM Topology Optical Topology IP Topology Paris Amsterdam Madrid Frankfurt London oc-48 metric 4 Paris Amsterdam Madrid London 4 Frankfurt London Paris Amsterdam Madrid 2 3 1 FIGURE 17.6. Each provisioned tunnel in the switching hierarchy N is represented as a forwarding adjacency of switching capability N ϩ 1 isolated because there have been no paths established for them by the lower-layer switching layers. Forwarding adjacencies are powerful tools for bringing up the network incrementally. Note that in the previous example a packet-over TDM-over lambda switching path has been used to illustrate the concept of multiple switching hierarchies. A network does not need to support all switching layers. If network service providers want to eliminate their SONET/SDH TDM network, one could also make (for example) the routers signal the lambdas directly. 17.2.5 IS-IS G-MPLS Extensions The G-MPLS extensions to IS-IS are sub-TLVs to the extended IS Reach TLV #22. The sub-TLVs are listed in Table 17.1. The first (sub-TLV 4) is a redefinition. Originally defined in Internet Draft draft-ietf-isis-traffic-05, sub-TLV 4 was intended as a link-local identi- fier that should carry a unique number to identify unambiguously a link in the traffic engineering database. The sub-TLV is intended for unnumbered interfaces (those lacking IP addresses) and used to carry a 4-byte value. Most implementations used to fill that sub-TLV with their loopback address. There is one problem with using a loopback address as link-identifier: the loopback address does not uniquely identify a link between a pair of routers. The current G-MPLS Internet draft draft-ietf-isis-gmpls-extensions-19 extends that sub-TLV to 8 bytes. Now, the combination of the loopback addresses between a given pair of routers can be used to uniquely identify the link between the two. The Link Protection Type sub-TLV #20 tells other routers how risky it is to use a cer- tain link. It does that by advertising the protection switching scheme of the underlying media. Values indicating that the underlying topology runs over a shared fibre, that other circuits run unprotected, as well as full blown 1:1 protection schemes, can be expressed. Table 17.2 lists the allocated protection scheme code points. G-MPLS 513 TABLE 17.1. Sub-TLVs that are used for conveying G-MPLS data inside IS-IS. Sub-TLV Length Name 4 8 Link Local/Remote Identifier 20 2 Link Protection Type 21 36 Interface Switching Capability Descriptor TABLE 17.2. Protection codes that may be announced for a G-MPLS link. Code Protection method 0x01 Extra Traffic 0x02 Unprotected 0x04 Shared 0x08 Dedicated 1:1 0x10 Dedicated 1 ϩ 1 0x20 Enhanced 0x40 Reserved 0x80 Reserved The most important sub-TLV, as far as G-MPLS is concerned, is the Interface Capability Switching Descriptor sub-TLV #21. Figure 17.7 shows the structure of that sub-TLV. First, it has some information about the level of the underlying link in the optical hierarchy. Table 17.3 shows the most common switching codes. There are values for virtually every switching technology defined. Ranging from packets to TDM, and from lambdas to even raw fibres, every interface in the optical hierarchy can be expressed. 17.2.6 G-MPLS Summary Large parts of the standardization work for IS-IS G-MPLS have been finalized as of 2003. However, neither of the two big router vendors has yet shipped routing software 514 17. Future of IS-IS subTLV Type subTLV Length 21 Bytes 1 1 Max LSP Bandwidth at priority 0 4 Max LSP Bandwidth at priority 1 4 Max LSP Bandwidth at priority 2 4 Max LSP Bandwidth at priority 3 4 Max LSP Bandwidth at priority 4 Max LSP Bandwidth at priority 5 Max LSP Bandwidth at priority 6 Max LSP Bandwidth at priority 7 4 4 4 4 Switching Capability Encoding Res. 4 36 Switching Capability-specific information variable (0–219) FIGURE 17.7. The Interface Switching Capability Descriptor sub-TLV #21 TABLE 17.3. The Switching type indicates the multiplexing and de-multiplexing capabilities of the link. Code Switching type 1 Packet-Switch Capable-1 2 Packet-Switch Capable-2 3 Packet-Switch Capable-3 4 Packet-Switch Capable-4 51 Layer-2 Switch Capable 100 Time-Division-Multiplex Capable 150 Lambda-Switch Capable 200 Fiber-Switch Capable that supports G-MPLS Extensions for IS-IS. Cisco has not shipped IOS routing software with G-MPLS extensions. Juniper Networks started (in JUNOS 5.6) G-MPLS support for OSPF, which seems to be the favourite IGP for the optical vendors for some reason. There seems to be sentiment in the optical community that IS-IS, because of its encoding style (Ethernet LLC, PPP-OSI) and the required operating systems infrastructure (most operating systems lack kernel support for OSI), was tied to OSI and therefore they stayed away from IS-IS. The router vendors, on the other hand, did not feel any pressure from the market to support G-MPLS extensions due to lack of implementation on the optical side. So one side was saying “Here’s G-MPLS for OSPF to start” and the other was saying “Don’t bother! We run IS-IS!” Neither side can figure out why the other doesn’t get it. G-MPLS is built around the idea of an integrated environment and common routing and signalling protocols for all equipment types. The ironic thing is that today, although G-MPLS extensions have been specified for all protocols, there is no common denom- inator yet. The majority of packet switching networks are based on IS-IS, but all that the optical infrastructure could support is OSPF. The authors believe that service providers are not willing to make a radical change in the core IGP, mostly because of the efforts and investments being made of maturing IS-IS to this point. So unless the optical vendors clean off their glasses and provide G-MPLS IS-IS implementations, there will not be any great progress in the G-MPLS idea. At best, we expect first production deployments in the 2005, 2006 timeframe. There have always been concerns about the scalability and suitability of a 2-level rout- ing hierarchy. The next section discusses a proposal on how to extend the 2-level to a multi-level (8-level) routing hierarchy. 17.3 Multi-level (8-level) IS-IS ISO 10589 offers two distinct levels as a tool for splitting up a topological domain into a smaller one in order to scale the network. Today the two levels are sufficient for even large networks with thousands of routers. However, emerging technologies like the G-MPLS peer model, where the topology of transmission and SONET/SDH networks will be exposed to IS-IS, seriously pose the question if the two topology levels of IS-IS are enough. Until now, no Internet drafts have been published for introducing a higher number of topological levels to IS-IS. There has been just some remarks on the ISIS-WG mailing list that this would be relatively easy to do. Figure 17.8 shows the structure of the IS-IS com- mon header. A key to the easy extension of IS-IS is the 8-bit wide PDU-Type field, which may be used to indicate up to 256 distinct PDU types. Today, the three most significant bits (MSB) are reserved for future use and could be used for specifying further PDU types. Only the lower 5 bits are used today for encoding the existing PDU types. Figure 17.8 shows a list of the PDU types used by IS-IS today. Table 17.4 has a listing of hypothetical code points that could be used for an 8-level IS-IS protocol. Note that there are four code points per level that need to be allocated for packaging Hellos, LSPs, CSNPs and PSNPs. There is no need to make a differentiation between point-to-point (p2p) Hellos and LAN Hellos like 2-Level IS-IS does today. Proposals like running p2p PDUs over Multi-level (8-level) IS-IS 515 516 17. Future of IS-IS Intra-domain Routing Protocol Discriminator Header Length Indicator Version/Protocol ID Extension 0x83 Bytes 1 1 1 1 1 1 1 1 1 ID Length PDU Type R 0 R 0 R 0 PDU Version Reserved Maximum Area Addresses 6 (0) 1 3 (0) 0 PDU specific fields 17–33 TLV section 0–1467 15 16 17 18 20 24 25 26 27 Level 1 LAN Hello Level 2 LAN Hello p2p Hello Level 1 Link State PDU Level 2 Link State PDU Level 1 CSNP Level 2 CSNP Level 1 PSNP Level 2 PSNP Type Name FIGURE 17.8. The PDU-Type field in the IS-IS common header has room for 256 distinct PDU types LAN circuits for pseudonode elimination, as described in draft-ietf-isis-igp-p2p-over-lan- 02.txt, heavily dilutes the usefulness of separating the two different Hello types. So the draft proposes sending a p2p Hello inside an Ethernet frame. Even worse: the one-time optimization of running distinct p2p Hellos over a media turns out to be a legacy that now causes more problems than it solves. For example, because of this Hello separation, things like multi-level authentication are not possible today over p2p circuits. The low- est Level (Level 1) always contributes the authentication string for any occurrence of the Authentication TLV #10. So the best thing would be to avoid that problematic PDU type once and for all and create a new common Hello PDU type that can be used for all levels and for all circuit Figure 17.19 list such a hyptothetical PDU the LAN Hello format has TABLE 17.4. A list of hypothetical code points that could be used for an 8-level enhancement of the IS-IS protocol. PDU type PDU name 32–39 Reserved 40 Level 3 Hello 41 Level 3 LSP 42 Level 3 CSNP 43 Level 3 PSNP 44 Level 4 Hello 45 Level 4 LSP 46 Level 4 CSNP 47 Level 4 PSNP …… 60 Level 8 Hello 61 Level 8 LSP 62 Level 8 CSNP 63 Level 8 PSNP Multi-level (8-level) IS-IS 517 all the necessary fields to run both over a LAN and a p2p infrastructure. Certain fields like the Priority and DIS LAN-ID do not make any sense on p2p circuits and hence should be set to zero, but they do no harm by just being there. Today there is no draft even describing a multi-level IS-IS. Just the idea that it can be done in general exists, along with some excerpts taken from the IETF ISIS-WG Mailing List. There is not even any serious discussion about multi-level IS-IS. Offloading virtually all of the IP reachability information to BGP has made scaling efforts to reduce the amount of IP reachability information with the introduction of additional hierarchy levels a point- less exercise. The authors have discussed the 8-level IS-IS proposal for three reasons: 1. Showing that it can be done without any major protocol rework 2. Educational purposes (everybody was reminded that the PDU-type field is 8 bits wide) 3. Showing protocol engineers that it is always a good idea to leave some spare bits in the protocol headers (some actually object to this practice) The first point is increasingly important, and once again OSPF is an example of how not to engineer a protocol. For the third time, OSPF ran out of bits again, because the Intra-domain Routing Protocol Discriminator Header Length Indicator Version/Protocol ID Extension 0x83 Bytes 1 1 1 1 1 1 1 1 1 ID Length PDU Type R 0 R 0 R 0 PDU Version Reserved Maximum Area Addresses 6 (0) 1 3 (0) 0 TLV section 0–1467 15,16 27 Circuit type 1–255 Source ID Holding Time PDU Length PriorityR Designated IS LAN-ID 1 ID Length (6) 2 2 1 ID Length (6) ϩ 1 FIGURE 17.9. A common Hello PDU that can be used for all levels and all circuits types which shares the semantics of the LAN Hello PDU 518 17. Future of IS-IS architects failed to add enough spare bits which were later required to evolve and extend the protocol further. The next future extension to IS-IS deals with the amount of information that an indi- vidual System-ID can originate for the LSP database, and how to scale it up further. 17.4 Extended Fragments Now, at the end of the big Internet “gloom and doom age”, service providers have begun exploring almost every aspect of how to save costs in their router infrastructure. A still open issue is the question of: “How do I eliminate intra-POP links and keep the cost per managed device the lowest possible?” The best answer today is to collapse different router functionalities into a bigger, consolidated router. Collapsing core transport and access functionality into a single box is often called vertical pooling as opposed to the horizon- tal pooling approach which combines different edge (access) services separate from the core. Figure 17.10 shows how an existing POP infrastructure is collapsed both horizon- tally and vertically to a single, large POP router. From a logical point of view, the smaller routers with a few links are consolidated towards one big router with many links, repre- senting the entire POP. Because the consolidated POP router has to terminate all the core circuits, there was some fear in the IS-IS community that the distributed LSP storage space that each router can originate (approximately 350 Kbytes) might get exhausted due to all the IS-Reach TLVs that need to get stored in the LSP fragments. In Chapter 6, “Generation, Flooding and Ageing LSPs”, there was a more detailed explanation of the term distributed LSP storage space and a breakdown of how much information an individual router can ori- ginate. What can be done to avoid exhausting the LSP transport space is to make the sin- gle big router appear as multiple routers in the IS-IS topology by issuing smaller LSPs with different System-IDs. The different System-IDs are then connected using a simple star topology, and the IS Reach cost between those aliased systems is always zero. "Classical" POP Core Rouer 1 Core Router 2 Public Peering Router VPN Router Customer Peering Router BRAS Consolidated POP FIGURE 17.10. The traditional POP layout gets replaced by a big all-in-one router which terminates the whole set of edge services Extended Fragments 519 Draft RFC 3786 increases the breadth of a single collapsed router by making the sin- gle router appear as a set of routers, as shown in Figure 17.11. Ironically, the result from a logical perspective looks a bit like the original topology before the consolidation took place. The draft describes a method for a collapsed router to express zero cost adjacen- cies. However, according to ISO 10589, zero cost adjacencies are illegal for non-pseudon- ode fragments and so must not be issued in IS Reach TLV #2 and the IS-Extended Reach TLV #22. In order to stay backwards compatible, a new IS-Alias TLV #24 is defined which can issue zero cost adjacencies. The TLV format is illustrated in Figure 17.12. The format is almost identical to the IS-Reach TLV #22 (See Chapter 12, Figure 12.8) except the Metric field is missing, which is no big surprise because the Metric is implicitly zero. If the router needs to originate a non-zero adjacency, then the sender originates this adjacency using a regular Extended IS-Reach TLV #22. Today there is no support in IOS and JUNOS for the IS Alias TLV #24, mainly because even in the largest core routers, the typical amount of IS adjacencies easily fits in 1 or 2 out of the 256 possible fragments. This may change when router vendors ship their multi- shelf systems like the HFR (Cisco) or TX (Juniper) for the first time. Given today’s router hardware, there is no space-related problem at all for storing the adjacencies of large routers. However, there is another place where the limit of 255 fragments may become a problem, which is the L2L1 router in combination with route leaking. When route leaking is configured, the L2L1 router has to re-package all the /32 prefixes from the core into a Level 1 LSP. More about route leaking was covered in Chapter 123 “IP Reachability Information”. In large networks today, 5000–6000 prefixes are advertised, and that takes 30–40 fragments in the Level 1 LSPs. If the 256 fragment limit is crossed some day (around 42,000 prefixes), which is unlikely, then an L2L1 speaker could issue the IS Alias TLV #24 for scaling the IP reachability information. Today, the extended fragments draft does not solve a real problem. However, it is nice to know that, due to the flexibility of IS-IS, even the 256 fragments limit is not a dead-end for the protocol. Multiple System-IDsSingle System-ID 0 0 0 00 0 1921.6800.1001 1921.6800.1001 1921.6800.1002 1921.6800.1003 1921.6800.1004 1921.6800.1005 1921.6800.1006 1921.6800.1007 FIGURE 17.11. A single router generates several System-IDs and connects them through zero-cost adjacencies 520 17. Future of IS-IS In recent years IS-IS has become a topology discovery tool. There is now an extension under discussion which would add also service discovery capabilities to IS-IS, which allows setting up iBGP routing automatically. 17.5 iBGP Peer Auto-discovery Because of the current lack of IS-IS applicability for transporting the bulk amount of Internet routes, the Border Gateway Protocol (BGP) is heavy utilized to convey routing reachability information of all kinds. Except in MPLS environments, where you have BGP-free cores by design, BGP is configured on every router. Larger networks have about 500–1500 BGP routers which need to be connected through a mesh of iBGP (inter- nal BGP) connections. Applying the good-old full-mesh is certainly not an option for networks of that size. The two techniques used to scale the number of paths and iBGP sessions in the network today are route reflection and confederations. Figure 17.13 illus- trates that both approaches achieve the goal of session and path reduction by splitting up larger domains into smaller ones. In a confederation, the large Autonomous System is split into smaller sub-ASs. In a route reflection environment, the flat iBGP mesh gets divided into clusters. The sub-domains in turn may or may not be full-meshed internally all over again. In a confederation environment one could further divide the sub-domain TLV Type TLV Length Neighbour-ID optional subTLV Value 24 Bytes 1 1 ID Length (6) ϩ1 3–245 1 1 1–243 subTLVs Length optional subTLV Type optional subTLV Length Neighbour-ID optional subTLV Value ID Length (6) ϩ1 3–* 1 1 1–* subTLVs Length optional subTLV Type optional subTLV Length FIGURE 17.12. The IS-Alias TLV #24 looks almost identical to the IS-Reach TLV #22 Full mesh iBGP Route Reflection Cluster 0.0.0.1 Cluster 0.0.0.3 Cluster 0.0.0.2 Top Level Full Mesh Confederation subAS 65001 subAS 65002 subAS 65003 RR RR RR RR F IGURE 17.13. Both confederations and route reflectors reduce the overall number of paths in the netw ork by splitting the big routing mesh into smaller domains 521 . start” and the other was saying “Don’t bother! We run IS-IS! ” Neither side can figure out why the other doesn’t get it. G-MPLS is built around the idea of an integrated environment and common routing and. and therefore they stayed away from IS-IS. The router vendors, on the other hand, did not feel any pressure from the market to support G-MPLS extensions due to lack of implementation on the optical side eliminate their SONET/SDH TDM network, one could also make (for example) the routers signal the lambdas directly. 17.2.5 IS-IS G-MPLS Extensions The G-MPLS extensions to IS-IS are sub-TLVs to the extended