243194

512 17. Future of IS-IS

TDM Topology

Optical Topology

IP Topology

Paris Amsterdam

Madrid

Frankfurt

London

oc-48metric 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 forwardingadjacency of switching capability N � 1

isolated because there have been no paths established for them by the lower-layerswitching 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 hasbeen used to illustrate the concept of multiple switching hierarchies. A network does notneed to support all switching layers. If network service providers want to eliminate theirSONET/SDH TDM network, one could also make (for example) the routers signal thelambdas directly.

17.2.5 IS-IS G-MPLS ExtensionsThe G-MPLS extensions to IS-IS are sub-TLVs to the extended IS Reach TLV #22. Thesub-TLVs are listed in Table 17.1. The first (sub-TLV 4) is a redefinition. Originally definedin 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 trafficengineering database. The sub-TLV is intended for unnumbered interfaces (those lackingIP addresses) and used to carry a 4-byte value. Most implementations used to fill thatsub-TLV with their loopback address. There is one problem with using a loopbackaddress as link-identifier: the loopback address does not uniquely identify a link betweena pair of routers. The current G-MPLS Internet draft draft-ietf-isis-gmpls-extensions-19extends that sub-TLV to 8 bytes. Now, the combination of the loopback addresses betweena 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 underlyingmedia. Values indicating that the underlying topology runs over a shared fibre, that othercircuits 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 Identifier20 2 Link Protection Type21 36 Interface Switching Capability Descriptor

TABLE 17.2. Protection codes that may be announced for a G-MPLS link.Code Protection method

0x01 Extra Traffic0x02 Unprotected0x04 Shared0x08 Dedicated 1:10x10 Dedicated 1 � 10x20 Enhanced0x40 Reserved0x80 Reserved

The most important sub-TLV, as far as G-MPLS is concerned, is the Interface CapabilitySwitching 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 virtuallyevery switching technology defined. Ranging from packets to TDM, and from lambdasto even raw fibres, every interface in the optical hierarchy can be expressed.

17.2.6 G-MPLS SummaryLarge parts of the standardization work for IS-IS G-MPLS have been finalized as of2003. However, neither of the two big router vendors has yet shipped routing software


subTLV Type

subTLV Length

21

Bytes

1

1

Max LSP Bandwidth at priority 0 4




Max LSP Bandwidth at priority 4




4

4

4

4

SwitchingCapability

Encoding Res. 4

36

Switching Capability-specificinformation

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-12 Packet-Switch Capable-23 Packet-Switch Capable-34 Packet-Switch Capable-451 Layer-2 Switch Capable100 Time-Division-Multiplex Capable150 Lambda-Switch Capable200 Fiber-Switch Capable

that supports G-MPLS Extensions for IS-IS. Cisco has not shipped IOS routing softwarewith G-MPLS extensions. Juniper Networks started (in JUNOS 5.6) G-MPLS supportfor 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 encodingstyle (Ethernet LLC, PPP-OSI) and the required operating systems infrastructure (mostoperating systems lack kernel support for OSI), was tied to OSI and therefore they stayedaway from IS-IS. The router vendors, on the other hand, did not feel any pressure fromthe market to support G-MPLS extensions due to lack of implementation on the opticalside. 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 routingand signalling protocols for all equipment types. The ironic thing is that today, althoughG-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 theoptical infrastructure could support is OSPF. The authors believe that service providersare not willing to make a radical change in the core IGP, mostly because of the efforts andinvestments being made of maturing IS-IS to this point. So unless the optical vendorsclean off their glasses and provide G-MPLS IS-IS implementations, there will not be anygreat progress in the G-MPLS idea. At best, we expect first production deployments inthe 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 amulti-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 asmaller one in order to scale the network. Today the two levels are sufficient for even largenetworks with thousands of routers. However, emerging technologies like the G-MPLSpeer model, where the topology of transmission and SONET/SDH networks will be exposedto 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 oftopological levels to IS-IS. There has been just some remarks on the ISIS-WG mailing listthat 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, whichmay be used to indicate up to 256 distinct PDU types. Today, the three most significantbits (MSB) are reserved for future use and could be used for specifying further PDUtypes. Only the lower 5 bits are used today for encoding the existing PDU types. Figure17.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-levelIS-IS protocol. Note that there are four code points per level that need to be allocated forpackaging Hellos, LSPs, CSNPs and PSNPs.

There is no need to make a differentiation between point-to-point (p2p) Hellos andLAN Hellos like 2-Level IS-IS does today. Proposals like running p2p PDUs over

Multi-level (8-level) IS-IS 515


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 TypeR0

R0

R0

PDU Version

Reserved

Maximum Area Addresses

6 (0)

1

3 (0)

0

PDU specific fields 17–33

TLV section 0–1467

151617182024252627

Level 1 LAN HelloLevel 2 LAN Hello p2p HelloLevel 1 Link State PDULevel 2 Link State PDULevel 1 CSNPLevel 2 CSNPLevel 1 PSNPLevel 2 PSNP

Type Name

FIGURE 17.8. The PDU-Type field in the IS-IS common header has room for 256 distinct PDUtypes

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 thedraft proposes sending a p2p Hello inside an Ethernet frame. Even worse: the one-timeoptimization of running distinct p2p Hellos over a media turns out to be a legacy thatnow 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 theAuthentication TLV #10. So the best thing would be to avoid that problematic PDU typeonce and for all and create a new common Hello PDU type that can be used for all levelsand for all circuit Figure 17.19 list such a hyptothetical PDU the LAN Hello format has

TABLE 17.4. A list of hypothetical code pointsthat could be used for an 8-level enhancementof the IS-IS protocol.PDU type PDU name

32–39 Reserved40 Level 3 Hello41 Level 3 LSP42 Level 3 CSNP43 Level 3 PSNP44 Level 4 Hello45 Level 4 LSP46 Level 4 CSNP47 Level 4 PSNP… …60 Level 8 Hello61 Level 8 LSP62 Level 8 CSNP63 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 likethe Priority and DIS LAN-ID do not make any sense on p2p circuits and hence should beset 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 bedone in general exists, along with some excerpts taken from the IETF ISIS-WG MailingList. There is not even any serious discussion about multi-level IS-IS. Offloading virtuallyall of the IP reachability information to BGP has made scaling efforts to reduce the amountof 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 rework2. 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 TypeR0

R0

R0

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 whichshares the semantics of the LAN Hello PDU


architects failed to add enough spare bits which were later required to evolve and extendthe 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 begunexploring almost every aspect of how to save costs in their router infrastructure. A stillopen issue is the question of: “How do I eliminate intra-POP links and keep the cost permanaged device the lowest possible?” The best answer today is to collapse different routerfunctionalities into a bigger, consolidated router. Collapsing core transport and accessfunctionality 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 thecore. 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 smallerrouters 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 wassome fear in the IS-IS community that the distributed LSP storage space that each routercan originate (approximately 350 Kbytes) might get exhausted due to all the IS-ReachTLVs that need to get stored in the LSP fragments. In Chapter 6, “Generation, Floodingand Ageing LSPs”, there was a more detailed explanation of the term distributed LSPstorage 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 LSPswith different System-IDs. The different System-IDs are then connected using a simplestar topology, and the IS Reach cost between those aliased systems is always zero.

"Classical" POP

Core Rouer 1 Core Router 2

PublicPeeringRouter

VPNRouter

CustomerPeeringRouter

BRAS

Consolidated POP

FIGURE 17.10. The traditional POP layout gets replaced by a big all-in-one router which terminatesthe whole set of edge services

243194

Documents

Transcript of 243194