512

17. Future of IS-IS

Paris

Amsterdam

IP Topology

Madrid

oc-48
metric 4

London

Frankfurt

Paris

Amsterdam

London

Madrid

TDM Topology

Amsterdam

Paris

1
Madrid

London
Frankfurt

Optical Topology

FIGURE 17.6. Each provisioned tunnel in the switching hierarchy N is represented as a forwarding
adjacency of switching capability N
1

G-MPLS

513

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 rst (sub-TLV 4) is a redenition. Originally dened
in Internet Draft draft-ietf-isis-trafc-05, sub-TLV 4 was intended as a link-local identier that should carry a unique number to identify unambiguously a link in the trafc
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 ll that
sub-TLV with their loopback address. There is one problem with using a loopback
address as link-identier: 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 certain link. It does that by advertising the protection switching scheme of the underlying
media. Values indicating that the underlying topology runs over a shared bre, 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.
TABLE 17.1. Sub-TLVs that are used for conveying G-MPLS data inside IS-IS.
Sub-TLV
4
20
21

Length
8
2
36

Name
Link Local/Remote Identier
Link Protection Type
Interface Switching Capability Descriptor

TABLE 17.2. Protection codes that may be

announced for a G-MPLS link.
Code
0x01
0x02
0x04
0x08
0x10
0x20
0x40
0x80

Protection method
Extra Trafc
Unprotected
Shared
Dedicated 1:1
Dedicated 1
1
Enhanced
Reserved
Reserved

514

17. Future of IS-IS

Bytes
subTLV Type

21

subTLV Length

36

Switching
Encoding
Capability

Res.

Max LSP Bandwidth at priority 0

Max LSP Bandwidth at priority 1

Max LSP Bandwidth at priority 2

Max LSP Bandwidth at priority 3

Max LSP Bandwidth at priority 4

Max LSP Bandwidth at priority 5

Max LSP Bandwidth at priority 6

Max LSP Bandwidth at priority 7

Switching Capability-specific
information

variable (0219)

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
1
2
3
4
51
100
150
200

Switching type
Packet-Switch Capable-1
Packet-Switch Capable-2
Packet-Switch Capable-3
Packet-Switch Capable-4
Layer-2 Switch Capable
Time-Division-Multiplex Capable
Lambda-Switch Capable
Fiber-Switch Capable

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 dened. Ranging from packets to TDM, and from lambdas
to even raw bres, 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 nalized as of
2003. However, neither of the two big router vendors has yet shipped routing software

Multi-level (8-level) IS-IS

515

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 Heres G-MPLS for OSPF to start and the other was saying
Dont bother! We run IS-IS! Neither side can gure out why the other doesnt 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 specied for all protocols, there is no common denominator 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 rst production deployments in
the 2005, 2006 timeframe.
There have always been concerns about the scalability and suitability of a 2-level routing 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 sufcient 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 common header. A key to the easy extension of IS-IS is the 8-bit wide PDU-Type eld, which
may be used to indicate up to 256 distinct PDU types. Today, the three most signicant
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

516

17. Future of IS-IS

Bytes
Intra-domain Routing Protocol Discriminator

0x83

Version/Protocol ID Extension
ID Length
R

6 (0)

1
1

PDU Type
PDU Version
Reserved

Maximum Area Addresses

1
1

Header Length Indicator

3 (0)

PDU specific fields

1733

TLV section

01467

Type

Name

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

FIGURE 17.8. The PDU-Type eld in the IS-IS common header has room for 256 distinct PDU
types
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
3239
40
41
42
43
44
45
46
47

60
61
62
63

PDU name
Reserved
Level 3 Hello
Level 3 LSP
Level 3 CSNP
Level 3 PSNP
Level 4 Hello
Level 4 LSP
Level 4 CSNP
Level 4 PSNP

Level 8 Hello
Level 8 LSP
Level 8 CSNP
Level 8 PSNP

LAN circuits for pseudonode elimination, as described in draft-ietf-isis-igp-p2p-over-lan02.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 lowest 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

Multi-level (8-level) IS-IS

517

Bytes
0x83

27

6 (0)

15,16

PDU Version

Reserved

3 (0)

1255

Intra-domain Routing Protocol Discriminator

Header Length Indicator
Version/Protocol ID Extension
ID Length
R

PDU Type

Maximum Area Addresses

Circuit type

Source ID

ID Length (6)

Holding Time

PDU Length

Priority

Designated IS LAN-ID

ID Length (6)
1

TLV section

01467

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

all the necessary elds to run both over a LAN and a p2p infrastructure. Certain elds 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. Ofoading 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 pointless 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 eld 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 rst 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

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 individual 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 horizontal pooling approach which combines different edge (access) services separate from the
core. Figure 17.10 shows how an existing POP infrastructure is collapsed both horizontally 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, representing 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 originate. What can be done to avoid exhausting the LSP transport space is to make the single 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.

Core Rouer 1

Public
Peering
Router

Core Router 2

VPN
Router

Customer
Peering
Router

"Classical" POP

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