IS-IS Versus OSPF-A Closer Look

IS-IS Versus OSPF ”A Closer Look

Table 7-2 provides concise point-by-point highlights of the differences between Integrated IS-IS and OSPF. The following section discusses in detail these differences and their relative merits between the two protocols. Where necessary, achitectural details are provided to elaborate the discussions. The discussions are organized in the following topics:

• Encapsulation

• Packet Formats and Encoding Issues

• Neighbor Discovery and Adjacency Maintenance

• Distribution of Routing Information

• Route Characteristics and Metric Information

• Robustness and Reliability Issues

• Network Architecture

• Stabilility, Convergence, and Scalability

• Security

• Operations: Maintenance and Troubleshooting

• Conclusions: Which Protocol Is Better?

Encapsulation

Integrated IS-IS runs directly over the data link alongside IP as a network layer (Layer 3) protocol. ISIS packets are recognized at the data-link layer as belonging to the ISO network layer protocol family and on Ethernet by the protocol type 0xFEFE. The corresponding protocol type for IP is 0x0800. Even though IS-IS is a network layer protocol, it is essentially a routing application and does not provide complete datagram transmission services as in the case of IP, CLNP, or Novell's Internet Packet Exchange (IPX).

One benefit of running IS-IS over the data link is that it is shielded from IP packet spoofing and similar denial of service (DoS) attacks. The downside, however, is that IS-IS cannot be used over ATM virtual circuits (VC) with the type of encapsulation known as VC Multiplexing (AAL5MUX). This is because this method of encapsulation supports only one Layer 3 protocol per VC. For most practical purposes, however, when IS-IS is used for IP routing, IS-IS packets must be sent over the same ATM VC. This, therefore, restricts use of IS-IS for IP routing in ATM environments to only alternate ATM encapsulation methods , such as LLC/SNAP (also referred to as AAL5SNAP) or AAL5NLPID encapsulation, where the ATM layer can distinguish between multiple Layer 3 protocols over the same VC. An IETF draft proposes a workaround to this issue in which both IS-IS and IP packets can be sent over an ATM VC with AAL5MUX encapsulation but the ATM layer is not relied on to demultiplex the IS-IS and IP streams. This workaround suggests routers should read into the first byte of the Layer 3 header to distinguish between IP and ISO family packets, such as IS-IS, CLNP, and ES-IS packets. Another issue associated with the Layer 2 encapsulation of IS-IS is that some operating systems that support IP networking have been implemented to differentiate Layer 3 packets in the kernel, requiring arduous kernel modifications to support IS-IS for IP routing in these operating systems.

OSPF runs over IP as protocol number 89. TCP and UDP are similarly encapsulated in IP, with protocol numbers 6 and 17, respectively. Encapsulating OSPF in IP means OSPF packets are transmitted with additional IP header information, thereby increasing packet overhead. This also subjects OSPF packets to IP packet spoofing and denial of service attacks. However, because OSPF is encapsulated in IP, there are no issues with using it for IP routing over ATM VCs with AAL5MUX encapsulation. Also, if an operating system already supports IP, no changes are necessary to support OSPF.

Packets Types and Encoding Issues

Table 7-3 lists IS-IS packet types and their corresponding analogies in the OSPF world. There is striking similarity ”even each protocol uses a significantly different encoding schemes.

Table 7-3. IS-IS and OSPF Packet Types

IS-IS	OSPF	Comments
Hello packets	Hello packets
Link-State packets (LSPs)	Link-State Update packets	IS-IS carries routing information in TLVs within LSP. OSPF uses LSAs that are transmitted in Link-State Update packets. LSAs also have headers.
Complete Sequence Number packets	Database Description packets
Partial Sequence Number packets	Link-State Request packets Link-State Acknowledgment packets

Variable Length Fields

IS-IS uses variable length packets extensively to advertise information about the routing environment. TLVs are used in all IS-IS packets making each of the IS-IS packet types extensible. IS-IS routers are supposed to ignore unsupported TLVs. LSPs are flooded intact with unsupported TLV information. This provides flexibility for extending the entire protocol with new capabilities, such as MPLS Traffic Engineering, IPv6. TLVs can be nested as sub-TLVs, providing even more flexibility for current and potential future extensions. IS-IS does not require any particular alignment of packet fields.

OSPF uses fixed format packets with fields aligned in 32-bit boundaries. This efficient encoding makes it easier for routers to parse OSPF packets. The disadvantage to this, though, is that the packet formats are not extensible. OSPF uses various types of link-state advertisements (LSAs) for advertising routing information. LSAs are advertised to neighbors in link-state update packets. LSAs are however extensible. OSPF uses opaque LSAs for protocol extensions. For example, LSA types 9, 10, and 11 are used for advertising application-specific information, such as MPLS Traffic Engineering attributes. Unlike IS-IS, LSA types that are not recognized on receipt are not flooded to neighbors. This means that all OSPF routers must recognize extensions network-wide for that new capability to work. However, IS-IS allows routers to ignore unrecognized TLVs.

MTU Matching

Both OSPF and IS-IS require communicating routers to have matching maximum transmission unit (MTU) sizes in order to form adjacencies. This is needed so that routers will not advertise packets larger than a neighbor can receive and process. However, each protocol uses a different mechanism to check against MTU mismatch. IS-IS pads hellos to the MTU size while OSPF advertises the interface MTU in database description packets. Recent enhancements to the IS-IS protocol allow hello-padding to be disabled to save link bandwidth. The rational behind this is that most media have consistent default MTUs that are matched on all connected devices. Another reason is that network operators have control over the MTU setting and can ensure matching configurations on all connected interfaces during physical set up of the link.

Fragmentation

Because of the obvious toll of fragmentation and reassembly on routers, both IS-IS and OSPF employ various mechanisms to avoid hop-by-hop conventional fragmentation and reassembly of large packets. The method used by either protocol involves sending small self-contained independent LS packet fragments that are transmitted faster and more efficiently . For example, only a fragment that is lost needs to be retransmitted out of the set representing the original information. The difference in the approach to handling fragmentation between the two protocols is that an IS-IS router fragments a large LSP to the MTU or LSP buffersize at the source. The maximum size of an LSP is 1492 bytes. A set of TLVs are appended to a header that has an LSP ID that differs from that of the other fragments by the LSP fragment number. Also, all the LSP fragments have different sequence numbers and checksum numbers that make them independent units and are flooded independently. A list of TLVs are provided in Chapter 3, "Integrated IS-IS Routing Protocol Concepts," (Table 3-1 and Table 3-2). Chapter 5, "The IS-IS Link-State Database," features additional recently specified TLVs.

In contrast, OSPF controls fragmentation by using different types of self-contained LSAs for advertising different kinds of information. Five LSA types are defined by the base OSPF specification, and additional specifications (Opaque LSAs, and so on) are specified for extensions (see Table 7-4). This approach is equally effective, except that it has the potential of introducing overhead that would adversely impact available network resources, such as bandwidth and memory. Each LSA has its own header containing information such as source router ID, sequence number, checksum, and age. In addition, LSA types 3, 4, and 5 hold only a single prefix per LSA, the overhead can be substantial. Type 1, 2 LSAs can hold multiple prefixes per LSA, however, because there are no size limits for these LSA conventional hop-by-hop fragmentations, and reassembly will be used if they grow large. Table 7-4 lists currently defined OSPF LSA types.

The many different LSAs supported by OSPF have good design protocol intentions, such as limiting fragmentation and reducing bandwidth consumption by providing granular link-state information. This means that potential small-size packets and only the specific information would be advertised in response to any event. However, this undoubtedly introduces complexity into the management of link-state information. On the contrary, IS-IS LSPs are larger and fewer in a network of comparable size. This implies less complexity in managing the IS-IS LS database; however, a lot of redundant information is retransmitted with a regenerated LSP in response to network events wasting bandwidth.

Table 7-4. OSPF LSA Types

Type	Name	Description
1	Router	Originated by a router to describe its set of active interfaces and neighbors. It lists the IP prefixes associated with each of the attached links and the state and cost associated with each neighbor.
2	Network	Generated by the Designated Router on a broadcast link and lists all attached routers. It also describes the link type, broadcast, NBMA, and so on.
3	IP Network Summary	Generated by the area border routers (ABRs) in hierachical topologies. Used for reporting interarea routes within the same AS.
4	AS Border Router (ASBR) Summary	Generated by the ABR to provide information about known ASBRs, which import external routes into the AS.
5	AS External	Generated by ASBRs to describe known destinations outside of the AS.
6	Group Membership	Supports multicast extensions to OSPF (MOSPF). Not supported in Cisco IOS Software.
7	NSSA	Used to inject external routes from a stub area into the OSPF domain. Generated by the Not-So-Stubby Area (NSSA) ASBR. Converted into type 5 LSAs by the ABR when exporting to the rest of the OSPF domain.
8	External-attributes	Proposed for interaction with BGP.
9-11	Opaque	Used for extended capabilities such as MPLS Traffic Engineering.

Neighbor Discovery and Adjacency Maintenance

Neighbor discovery and adjacency maintenance are performed by means of periodic transmission and reception of hellos in both IS-IS and OSPF. In both cases, hello packets also serve as vehicles for detecting and negotiating common and extended capabilities.

Because IS-IS runs over the data link, IS-IS hellos are advertised to Layer 2 broadcast addresses (allL1ISs and allL2ISs). On multipoint links such as Ethernet, the corresponding broadcast addresses are 0180.C200.0014 and 0180.C200.0015. Because of their encapsulation in IP packets, OSPF hellos are advertised to Layer 3 multicast addresses AllSPFRouters (224.0.0.5) and AllDRouters (224.0.0.6).

Table 7-5, shows the default values of corresponding hello-related timers in IS-IS and OSPF. An interesting difference between IS-IS and OSPF regarding hello-related timers is that IS-IS does not require the hello interval and holdtime to match between adjacent neighbors. Rather, each hello packet contains a hold-time value that is used to reset the hold timer at the receiver. In contrast, OSPF requires all hello- related timer values (Hello interval, Dead timer) to match on all routers on the same subnet. The downside of this requirement for OSPF is that modifying the hello timers is intrusive , whereas in IS-IS this is not.

The following subsections highlight significant differences in adjacency formation processes between the two protocols.

Table 7-5. Default Values of Hello-Related Timers

Type of Interface	IS-IS	OSPF	Comments
Point-to-point	Hello “ 10s Holdtime “ 30s	Hello “ 10s Dead “ 40s Wait “ 40s	Wait timer specifies how long to wait if DR fails before starting DR election process.
Broadcast	Hello “ 10s Holdtime “ 30s	Hello “ 10s Dead “ 40s Wait “ 40s
NBMA	N/A	Hello “ 30s Dead “ 120s Wait “ 120s

Link Types

IS-IS and OSPF support multiacess broadcast media, such as Ethernet or similar media, in the same way. The same goes for point-to-point links. OSPF additionally supports nonbroadcast multiaccess (NBMA) media, such as ATM and Frame Relay. OSPF can also model NBMA media as point-to-multipoint. Table 7-6 shows a comparison of the link types supported by the two protocols. IS-IS does not provide direct support for NBMA media. When used in IS-IS networks, NBMA media must be configured as Broadcast media if all nodes are fully meshed. Alternatively, the individual PVCs can be configured as point-to-point links. If the NBMA cloud is highly meshed, IS-IS meshed groups can be used in conjunction with point-to-point configuration to control excessive flooding.

Table 7-6. IS-IS and OSPF Network Link Types

IS-IS	OSPF	Comments
Broadcast	Broadcast
N/A	nonbroadcast multiaccess	NBMA links can be configured as broadcast media, or pvcs can be configured as point-to-point links in IS-IS environments.
Point-to-point	Point-to-point
N/A	Point-to-multipoint
N/A	Demand Circuits

Forming Adjacencies

The essence of forming adjacencies with regards to link-state protocols is to build a stateful relationship that is leveraged by other protocol mechanisms to ensure consistency of relevant link-state information between communicating neighbor routers. The process of exchanging link-state information is also known as database synchronization. There are significant differences between IS-IS and OSPF in how routers form adjacencies. IS-IS adjacencies are formed after 2-way (point-to-point links) or 3-way (broadcast links) communication has been established through the exchange of hellos. A recently published IETF draft proposes a mechanism for 3-way handshake over point-to-point links. A 3-way adjacency handshake is available in Cisco IOS 12.0 S and other releases. IS-IS routers proceed to synchronize their LS databases after they have become adjacent. The potential for transient routing problems when adjacency formation precedes database synchronization can be resolved through the use of the IS-IS overload bit.

OSPF follows a complex multistage progressive process that requires routers to synchronize their databases before establishing adjacencies. This is intended to prevent transient routing problems that occur when adjacent routers not having complete forwarding intelligence attract transit traffic. One of the early stages in the OSPF adjacency process involves establishing 2-way communication between neighbors.

Designated Routers

The designated router concept is used by both IS-IS and IS-IS on broadcast media to limit the magnitude of LS state information exchanged between routers on such media. The DR concept helps reduces the number of adjacencies formed on broadcast media to order N instead of order NxN, where N is the number of nodes. Each protocol uses different mechanisms to realize this concept.

For example, IS-IS elects only one designated router (Designated IS) without a backup. The IS-IS DIS can be preempted at any time by a router with a higher priority. A new DIS must be elected when the current DIS is lost. Because the DIS advertises hellos faster (three times faster by default) than other nodes on the LAN, DIS failure detection is fast, so the potential for disruption is minimized. In the DIS election process, IS-IS uses the highest data-link address (MAC) as tie breaker when interface priorities are the same. The priority field available in LAN hello packets is 6 bits, so the range of interface priority for IS-IS routers is 0 “127 with 64 as default on Cisco routers. Also on LANs, all IS-IS nodes become adjacent to each other by broadcasting hellos and going through the 3-way handshake. The many-to-many adjacencies through hello broadcast are straightforward because reliable database synchronization is not required to complete adjacency establishment. LSPs are also broadcast to everyone, and the DIS assists with database synchronization by periodically broadcasting CSNPs that contain summaries off all known LSPs.

In contrast, OSPF elects DR and a backup DR (BDR) to conduct flooding on a LAN. The DR cannot be preempted and the BDR takes over the DR; the first active router on the LAN segment usually assumes the DR role. The availability of a BDR makes replacement of the DR transparent in case of a failure. All other nodes on the LAN can be adjacent to only the DR and BDR. This is necessary because OSPF requires databases to be reliably synchronized before adjacencies are established. Forming adjacencies with only the DR and BDR is designed to reduce complexity of data exchange and mininize flooding.

In summary, IS-IS solves the NxN adjacency problem by choosing a simple process that uses periodic sychronization to achieve reliability and a deterministic DIS election process in which the DIS is preemptible. OSPF solves the same problem but uses a slightly more complex process that makes DR election nondeterministic but guarantees reliable flooding on broadcast media.

Distribution of Routing Information

IS-IS and OSPF are link-state routing protocols and, therefore, require routers to obtain accurate information about the network topology that is subsequently used to calculate the best paths to all known destinations in the network at each router. The topology information is also referred to as link-state information, and it is spread from router to router by a mechanism known as flooding.

IS-IS routers use link-state packets to organize a variety of link-state information. LSPs constitute the units of information stored in IS-IS LS database. An LSP is flooded from one node to the next intact. The maximum size of an LSP (LSP Maximum Transmission Unit) is specified as 1492 bytes and should be supported by all links in the IS-IS network. When there is any topology change, a router floods a new copy of its entire LSP with the updated information.

OSPF uses link-state advertisements (LSAs) for distributing routing information. LSAs are the smallest units of information stored in the OSPF LS database. LSAs are generally small fixed-size packets. Type 1 and Type 2 LSAs can have many prefixes per LSA. Other LSAs do not. LSAs are grouped and advertised in LS Update packets. Because LS updates are generated locally at any router, they do not carry a consistent set of LSAs. In contrast, IS-IS link-state packets are always flooded intact as originated at the source.

Flooding

Flooding is the method used by link-state protocols to distribute link-state information in a network. Sharing link-state information in this manner allows routers to have consistent views of the network's topology and, therefore, calculate loop free optimal paths to destinations in the network. Link-state protocols use various mechanisms to compare their databases to ensure consistency. The process of exchanging link-state information to ensure consistent views of the network across routers is known as database synchronization. To support synchronization, routers compare their databases by exchanging summary headers of all known LSPs or LSAs.

IS-IS performs reliable flooding on only point-to-point links where explicit acknowledgment of received LSPs is required. On LANs, IS-IS nodes broadcast their LSPs to all attached devices. The DIS then periodically multicasts a CSNP that contains a summary of every known LSP in the LS database to help synchronize databases between routers connected to the LAN.

OSPF performs reliable flooding on both point-to-point links and LANs and, therefore, requires acknowledgment of all LSAs flooded out. On LANs, ordinary routers pass on their LSAs to the DR and BDR. The DR then refloods the LSAs to all other nodes on the LAN and receives acknowledgment from them.

Because in OSPF every destination outside an area (interarea and external) is stored in individual LSAs (Type 3 and Type 5), summarizing the LS database might require a packets larger than the MTU of the outgoing interface. In such cases, OSPF uses IP fragmentation and reassembly. Each of the resulting fragments is assigned a sequence number and advertised sequentially after each fragment is acknowleged by the receiving end.

One advantage of IS-IS that has already been mentioned is that individual interarea and external routes do not need their own LSP headers, and multiple prefixes are packed into TLVs (types 128, 130, and 135), which share the same LSP header. In general, there are fewer LSPs in an IS-IS environment than there are in a comparable OSPF network. Therefore, a change in topology might trigger an update of many different OSPF LSAs, whereas a similar event in IS-IS might trigger fewer LSPs to be flooded.

IS-IS LSP and OSPF LSA Aging

Link-state routing protocols provide mechanisms to remove stale information from the Link-State database. Both IS-IS and OSPF provide aging timers in link-state packets for this purpose. The Remaining Lifetime field (LSP Holdtime on Cisco routers) in IS-IS is a down-counting timer that starts from 1200 seconds (default) and indicates how many more seconds before the LSP will expire. OSPF uses an up-counting counter that indicates the number of seconds since the LSA was originated. The maximum time an LSP/LSA can exist before it expires is known as maxage. For IS-IS, the default is 1200 seconds (20 minutes). For OSPF, the default is 60 minutes. IS-IS allows Maxage to be configurable up to a maximum of 18.7 hours. The OSPF Maxage is fixed at 1 hour .

To purge an LSP from the network before it expires, an IS-IS router sets the remaining lifetime field to 0 and then floods it. IS-IS allows any router to purge corrupted LSPs from the network. This could lead to LSP corruption storms, where one router purges an LSP and the originator reissues the LSP, and it is again corrupted by some intervening device. The router level command ignore-lsp-errors prevents a router from purging a corrupted LSP. OSPF allows routers to prematurely purge only unexpired LSAs that they originated. This prevents situations similar to LSP corruption storms that can occur in IS-IS environments.

To ensure continuity of operation, IS-IS and OSPF routers regenerate new copies of their LSPs to refresh existing copies periodically even before they expire. For IS-IS, this occurs every 15 minutes. OSPF routers refresh their LSAs every 30 minutes. OSPF LSAs with the DoNotAge bit set are not aged while stored in a router's Link-State database. Therefore, they do not need to be refreshed every 30 minutes. However, such LSAs will be eventually purged from the LS database if they become stale after being held for at least 60 minutes and the originator not reachable for the same period.

The periodic interval at which LSPs/LSAs are regenerated is known as the Refresh Interval. Table 7-6 lists related timers for IS-IS and OSPF and their default values.

Table 7-7. IS-IS and OSPF Maxage and Refresh Timers

Timer	IS-IS	OSPF	Comments
Maxage	20 minutes (default)	60 minutes	Configurable 16-bit field in IS-IS allows up to 18.7 hours. The OSPF value is fixed.
Refresh Interval	15 minutes (default)	30 minutes	Configurable up to 18.7 hours for IS-IS.

Route Characteristics and Metric Information

Various types of routes are recognized by both IS-IS and OSPF. In IS-IS, there are Internal routes (TLV type 128 and 135) and External routes (TLV type 130). Internal routes are further categorized into intra-area (Level 1) and interarea (Level 2). By specification, external routes can be introduced into the IS-IS domain only through Level 1-2 routers by redistributing from an external routing source. Cisco IOS Software, however, provides a software knob that allows redistribution of external routes by Level 1-only routers. This is allowed for operation convenience.

Similarly, OSPF supports intra-area routes (Type 1 and Type 2 LSAs) and interarea routes (Type 3 LSAs and external routes (Type 5 LSAs). External routes are not advertised into OSPF stub areas. Not-So-Stubby Areas (NSSA) allow limited introduction of external routes into the rest of the OSPF domain by means of Type 7 LSAs, which are converted to Type 5 by the NSSA. IS-IS routes carry metric information. Out of the four types of metrics specified, only the default type is supported in Cisco IOS Software. IS-IS metrics have an inverse bandwidth intepretation, with smaller values associated with bigger bandwidth. The 7 bits used for narrow metrics allow only values between 0 and 63 per interface and up to 1023 per path . Wide metrics allow larger and flexible metric values, 32 bits in TLV type 135 for extended IP reachability information and 24 bits in TLV type 22 for extended IS reachability information. Cisco IOS Software does not automatically assign metrics on interfaces based on the bandwidth. A default value of 10 is assigned on all interfaces, even though different values can be manually assigned. IS-IS metrics can be tagged as Internal or External based on the setting of the I/E bit. When the I/E bit is set (External), 64 is added to the advertised value of the metric. (Some Cisco IOS releases add 128 instead.)

OSPF also uses a metric (cost) that is inversely proportional to bandwidth. The cost on an interface is automatically assigned based on a default reference bandwidth of 100Mb/s. The cost is calcuated as (Reference Bandwidth)/(Interface Bandwidth). A cost of 1 is assigned if the calculated value is more than 1. The reference bandwidth is configurable. Also, interface cost can be manually assigned. OSPF allows assignment of large costs because of the wide metric fields in LSAs. The metric field is 16 bits in Type 1 LSAs and 24 bits in Types 3, 4, 5, and 7 LSAs. OSPF also recognizes two types of metrics for external routes: Type 1 (E1) and Type 2 (E2). Type 1 considers the cost to the ASBR in addition to the advertised cost of the route. Type 2 uses only the advertised cost.

Robustness and Reliability Issues

Robustness and reliability are introduced in IS-IS and OSPF in various forms. For example, either protocol uses age timers in LSPs/LSAs so that they can be periodically refreshed to ensure their integrity. The age timers also allow stale link-state information to eventually expire so that they can be purged from the network. Flooding loops are prevented by decrementing the Remaining Lifetime in IS-IS LSP at each flooding hop. OSPF also enforces similar robustness by increasing the LS age field. The use of checksums also helps ensure the entegrity of LSPs and LSAs.

IS-IS enforces reliable flooding on point-to-point links requiring every LSP flooded to be acknowledged. LSPs flooded on broadcast media are not acknowledged , but the DIS, which simplifies flooding on an IS-IS LAN, periodically broadcasts CSNPs with summaries of known LSPs to ensure consistency of link-state information across routers. Reliable flooding is achieved through simple periodic updates. Routers that are missing LSPs or have stale information after comparing their databases with contents of the CNSPs can request complete copies with PSNPs.

OSPF requires flooded LSP to be acknowledged on all links. Also, OSPF has a DR and a BDR to ensure the undisruptive operation of the LAN in case the DR fails.

Network Architecture

This section discusses contraints imposed by IS-IS and OSPF on network topologies and explains any differences between the two protocols in this regard.

Hierarchy

Hierarchy is required primarily for the network to contain the perils of growth and expansion while scaling to larger number of nodes. Hierarchy allows the network to be divided into smaller sections. Each section can then operate independently at one level and yet be linked together at a higher level. This type of organization of the network allows routing information to be manageable at the lower level. It also helps by constraining regional problems, thereby hiding instabilities from the rest of the network. Both IS-IS and OSPF support two levels of hierarchy.

IS-IS uses a logical hierarchy based on routing levels, referred to as Level 1 and Level 2. Level 1 routing occurs within a physical area. Level 2 routing occurs between the border routers from the respective areas in the IS-IS domain. All IS-IS routers must belong to a single physical area as defined by the area ID in the NSAP address. The border routers, which are also known as Level 1-2 routers, glue the areas together by exhanging routing information from their respective areas. The collection of Level 1-2 routers is also known as the IS-IS backbone. The IS-IS backbone consists of interconnected Level 2 capable routers, some of which may be Level 1-2 routers. The IS-IS backbone must be contiguous. For IS-IS, this also means that the Level 2 routers must be interconnected through other Level 2 routers. Because IS-IS is designed around a node-based addressing scheme and each router must belong to a single area even though it may be a Level 1-2 router, IS-IS areas, therefore, form boundaries on links as shown in Figure 7-15.

Figure 7-15. Area topology in Integrated IS-IS.

OSPF also supports a two-level hierarchy ”regular areas and a backbone area that is designated as area 0 in the Cisco implementation. Because OSPF is designed around links and the link-based IP addressing scheme, area assignment is by links and, therefore, router interfaces. This means that OSPF areas form boundaries on the routers themselves and not the links as in IS-IS. Figure 7-16 shows how OSPF areas are carved out. The backbone glues ordinary areas together. OSPF routers that interconnect more than one area are referred to as area border routers (ABRs). In the Cisco implementation, one of these areas must be area 0 for exchange of interarea information. OSPF also requires the backbone to be contiguous and that all areas connect to the backbone through an ABR. OSPF allows use of virtual links to connect remote areas to the backbone through other areas if direct physical connectivity is not possible. OSPF also allows a virtual link to connect physically separate area 0s to maintain contiguity of the backbone. In contrast, IS-IS virtual links are specified for connecting partitions of a Level 1 area over the Level 2 backbone. Cisco implementation of IS-IS does not support virtual links.

Figure 7-16. Area topology in OSPF.

IS-IS and OSPF Areas

OSPF areas can be one of several types, such as ordinary, stub, totally stubby, not-so-stubby, and totally-not-so-stubby. However, IS-IS areas were originally designed to be stubs with the Level 1 areas relying on a default to forward traffic out of the area. According to the original specification, ISO 10589, IS-IS areas are similar to OSPF totally stubby areas (no interarea routes, no externals). However, Cisco IOS Software allows redistribution of external routes into Level 1, making IS-IS areas behave like OSPF totally-not-so-stubby areas (externals allowed, no interarea routes). Recent enhancements published in RFC 2966 and supported in Cisco IOS additionally allow interarea routes to be advertised into IS-IS Level 1, making IS-IS areas look more like ordinary OSPF areas, whereby both externals and interarea routes are broadly allowed.

An interesting difference between IS-IS and OSPF is that IS-IS requires routers on the same segment with mismatched area IDs to form only Level 2 adjacencies, making them Level 1-2 routers connected to the backbone while still identified with their respective areas. Two IS-IS routers in the same area can also form both Level 2 adjacencies, even though they are not required to as in the previous case. If such routers are directly connected, the interconnecting link will be in both the Level 1 area as well as the Level 2 backbone. In contrast, an OSPF link can be associated with only one area, and routers on the same link segment must agree on a common area ID to be adjacent.

This section discussed basic IS-IS functionality and did not consider the IS-IS multiarea feature supported in IOS. IS-IS multiarea functionality enables IS-IS routers to assign interfaces to mutiple Level 1 areas and the backbone, making them behave in the same way as OSPF routers. IS-IS multi-area support is currently not standardized and was designed for ISO CLNS environments to optimize routers usage in such environments. This feature requires running multiple IS-IS processes on the Cisco routers and defining a unique area ID for each process. One of the processes must be Level 1-2 to interconnect the Level 1 areas. The processes can then be applied to interfaces as necessary.

Area ID and Router ID

IS-IS defines the area ID as part of a router's NSAP, which is also known as the Network Entity Title (NET). Integrated IS-IS distinguishes three components in an NSAP: area ID, system ID, and N-Selector (see Chapter 4, for further details). The system ID component plays the role of a unique router ID. LSPs are also differentiated by the system ID component in the LSPID. This is true for both IP and ISO routing. RFC 1195 defines TLV Type 132 for specifying an associated IP interface address when IS-IS is used for IP routing, but this is only for informational purposes and has only operational significance in maintenance and troubleshooting situations. If available, the highest loopback address is entered into the IP Interface Address TLV. An IP Router ID TLV (Type 134) has been specified for MPLS TE applications of IS-IS. Only the area ID and the system ID are relevant for basic routing functionality and both are defined in the NSAP.

OSPF version 2 for IPv4 routing explicitly defines two separate 32-bit numbers for area ID and router ID. In Cisco IOS Software, the area ID is configured as part of network statements. The router ID is usually the highest loopback address or the highest IP address on any interface on the router.

Stability, Convergence, and Scalability

In general, IS-IS and OSPF have comparable stability and convergence characteristics. Apart from the architectural differences discussed in the preceding sections, the two protocols are functionally the same and have few advantages over each other when configured and used properly. Often, stability and fast convergence are opposing virtues. Hello packets are used to detect adjacency failures in situations where the failure is not detected at the lower layers . Because the actual time required for protocol mechanisms to select an alternate path and route-around failures is generally small, the time taken to detect failures becomes critical for fast might result in network instabilities, impacting network resources, such as bandwith, processing capacity, and memory. Adjustible timers, such as the hello-interval , IS-IS holdtime, and OSPF Dead interval, provides trade-offs between stability, fast convergence, and conservation of network resources. In summary, important factors that affect network stability and convergence are the speed at which failures are detected and propagated throughout the network, the size of the network, and the processing capabilities of the routers.

Route Calculation

Both IS-IS and OSPF use the same SPF algorithm for route computation, so they should have comparable convergence times, everything being equal. However, because IS-IS propagates IP routes within an architectural framework designed for the ISO node-based addressing scheme, IP prefixes end up as leaf nodes in the SPF tree. This provides greater opportunities for IS-IS to perform only the less CPU- intensive partial route calculation when network events do not affect the basic topology but only IP prefixes. OSPF is built around links, and any IP prefix change in an area will trigger a full SPF. With OSPF, only changes in interarea and external routes result in partial SPF calculations. Consequently, IS-IS PRC is more pervasive than OSPFs partial SPF runs. This difference allows IS-IS to be more tolerant of larger single area domains whereas OSPF forces hierarchical designs for relatively smaller networks. This seeming advantage allowed ISP network operators to deploy large single IS-IS domains to overcome problems with suboptimal routing with hierarchical designs. Of course, use of areas and hierarchy in networks is good design practice that prepares the network for future growth and helps prevent problems associated with large flat topologies. While areas and hierarchy are good for scalabilty, on the downside, they also add complexity.

Managing Stability and Convergence

Even though not widely deployed, Cisco offers IS-IS exponential back-off mechanisms in recent IOS releases; see the section on "Improving Convergence" earlier in this chapter. These mechanisms allow aggressive timer values to be configured for LSP generation; the SPF and PRC processes in order to achieve responsive reaction to network changes but backs off to less aggressive parameters when the churn persists. Currently, OSPF allows only pacing of flooding and SPF calculations to maintain stability of the network. In the future, IOS will support exponential back-off algorithms for OSPF, as well as other intelligent event dampening capabilities for link flaps and LSA generation.

Cisco's implementations of IS-IS and OSPF are both sensitive to bandwidth consumption and use pacing mechanisms to enforce this bandwidth conservation. For example, IS-IS throttles updates on interfaces with low bandwidths in the T1 range to only a maximun of 50 percent of the bandwidth, and OSPF uses the LSA group pacing feature to ensure that routers do not periodically refresh their LSAs at the same time.

A current IOS implementation advantage of IS-IS over OSPF is the use of the overload bit to prevent undue loss of traffic during BGP convergence. OSPF doesn't support the concept of overload bit that enables a router to signal memory overload, real or fictitiously, in order to deflect potential transit packets before the router is ready to forward them. However, a feature that allows OSPF link-cost manipulation during BGP convergence should provide simlilar functionality, preventing unnecessary blackholing of traffic in certain transient situations. In this application, a router advertises Router LSAs with large cost values so that it is not preferred for transit traffic until it is ready.

Scaling in NBMA Environments

IS-IS can use mesh groups (RFC 2973) to control redundant LSP flooding in highly meshed NBMA environments when PVCs are configured as point-to-point links. OSPF doesn't have an exactly comparable feature but can use per interface LSA blocking to prevent LSA transmission over a link.

Size Limitations of IS-IS LSPs and OSPF LSAs

In IS-IS, an LSP ID contains an 8-bit fragment number field. Therefore, an IS-IS router can allow up to 256 fragments of its LSP. The maximum size of an LSP is 1492 bytes. Taking out header bytes of 27 bytes leaves 1465 bytes for TLVs. This means that an IS-IS router has theoretically up to 256*1465 of space to pack IP reachability TLVs. A couple of other TLVs will be stored in the first fragment. In Chapter 5, a theoretical estimate indicated that the maximum number of IP routes IS-IS can support is approximately 31,000 prefixes. Another issue is that IS-IS uses an 8-bit field for point-to-point circuit IDs limiting the number of point-to-point adjacencies to 256 for each router. Also, 8 bits are used for defining a pseudonode number in the LSPID, which means a router can be DIS for only 256 LANs. There is also a limit to the number of routers that can be advertised in pseudonode LSP by the DIS. Most of these limitations are being addressed by various IETF draft proposals. For example, the RFC draft "draft-ietf-isis-3way-01.txt" proposes a method for new TLV hello packets that increase the maximum number of point-to-point adjacencies.

OSPF has similar limits imposed by the maximum 64K bytes size of Router and Network LSAs. This figure allows approximately 5000 Links for Type 1 and Type 2 LSAs. Consider, for example, Type 1 LSAs. Using 24 bytes for fixed fields, 12 bytes results in a little more than 5400 Entries, as this figure is close to the 65535 maximum number of links that is supported by the 16-bit link field specified in the Router LSA. Note also that all other LSAs apart from Types 1 and 2 hold single prefixes. Because there is no limit to the number of such LSAs, a large number of interarea routes or externals will be demanding on the memory resources of a router. This a good reason why BGP routes held in the Internet route tables should not be distributed into any IGP. There are also practical limitations on how many routes a router can effectively support in an efficient manner.

How Large Can IS-IS and OSPF Areas Be?

How large an area a specific routing protocol can support has always been an intriguing question for many network architects and operators. This issue was discussed earlier in the chapter for IS-IS in the "IS-IS Scaling Issues" section. The size of an area is a function of many factors, including available network resources, such as memory, CPU speed of the routers, bandwidth, and so on, and stability of the links. The larger the area, the more resource required to support it. Also, unstable areas place undue processing burden on the routers. Continuous flooding of link-state information chews up network bandwidth, ultimately leading to network congestion, which makes the network unusable. It is speculated that some IS-IS domains have deployed approximately 1000 routers with any significant problems. This might seem to be true because most of the tier 1 ISPs that use IS-IS currently deploy on single area domains with more than 500 routers.

Approximately, 350 OSPF routers have also been reported in some networks. There are various vendor recommendation regarding maximum tested area sizes. Some vendors recommend 50 routers per area and a maximum of 3 areas per ABR. In reality, numbers are not absolutes. What matters most is network stability and available resources. IS-IS tends to support larger networks mainly because the IP prefixes are leaves in the SPF tree, meaning full SPF is not run in most cases where a link failure does not impact the core nodal topology. In OSPF, all IP link failures in an area trigger LSA updates, which, in turn , cause full SPF runs. Therefore, a large OSPF area would be more demanding on processing resources on the average than an IS-IS network of comparable size.

Security

Integrated IS-IS standards, ISO 10589 and RFC 1195, specifiy only plain-text passwords for authentication of IS-IS packets. Current releases of IOS support only simple passwords IOS. MD5 authentication for IS-IS packets has been proposed in the IETF for standardization and will soon be available in Cisco IOS Software. Because IS-IS packets are not encapsuated in IP packets but rather over the data link, they are harder to spoof and, therefore, less susceptible to common denial of service attacks. OSPF supports plain-text, as well as MD5 authentication. As discussed previously, OSPF packets are encapsulated over IP and are, therefore, subject to spoofing and other denial of service attacks. Use of MD5 authentication is, therefore, strongly advised for OSPF deployments.

Operations: Configuring, Maintenance, and Troubleshooting

Both the Integrated IS-IS and OSPF protocols have been widely deployed and have been in use for some time for most implementations to be matured and well hardened . However, for a long time, only Cisco seemed to have a usable implementation of IS-IS. Currently, there are IS-IS implementations from other router vendors that are interoperable with the Cisco implementation. Of the two protocols, OSPF has evolved the most since inception, under the auspices of IETF OSPF Working Group. It is, therefore, not by coincidence that OSPF is also the most complex of the two protocols from both protocol design and operations perpective. However, Integrated IS-IS hasn't seen much standardization since ISO10589 and RFC 1195 were published. Most of IS-IS implementation experience and feature evolution were developed by Cisco Systems. IS-IS was first implemented as an ISO only protocol at Cisco before later enhanced with IP capabilities. IS-IS's ties with ISO CLNP is obvious from its nonconventional configuration for IP routing, which requires ISO NSAP to be configured in place of IP network statements as found in RIP, OSPF, and EIGRP/IP.

OSPF has a MIB that consists of over 100 management variables . The OSPF MIB is available in Cisco IOS Software and presents itself as a convenient resource for OSPF configuration and general protocol maintenance. A significant number of the OSPF MIB variables are designed for monitoring puposes. IS-IS MIB is still an IETF draft, and it is currently not supported in IOS even though support is imminent.

Conclusion: Which Protocol Is Better?

IS-IS and OSPF have been established as practical IGPs for deployment in large scale IP networks. They are both effective and, for the most part, are functionally identical. The original design of IS-IS was optimized for large LANs (periodic synchronization, simple LAN flooding) and SPF computation performance (small metrics). OSPF was optimized for efficient bandwidth utilization and reliability. High-speed routing technology has significantly evolved since inception of these protocols, obsoleting most of these original design criteria; yet, both protocols have withstood the tests of time and have emerged as the only viable IGP options for large scale routing.

Both protocols have been widely deployed. OSPF is more widespread from medium to large networks. IS-IS is used in most Tier 1 ISP networks and in single area configurations proving itself as very scalable.

It is widely speculated that most of the large ISPs adopted IS-IS because at one time it had the most stable implementation coupled with a U.S. government mandate to support ISO CLNS alongside IP. Having had a lot of success with IS-IS, these large ISPs haven't seen any good reason to switch to OSPF.

OSPF has a larger number of vendor implementations but there are few matured and stable IS-IS implementations. IS-IS is more extensible, even though OSPF can also be extended by using opaque LSAs. OSPF is more of a full Internet standard, better documented and more widely understood . Most IP-based enterprise networks have deployed OSPF whereas IS-IS remains largely deployed in the service provider space. That OSPF is a full Internet standard might explain its complexity. With the exception of the arcane language used in current IS-IS standards and ties to ISO and NSAP addressing, IS-IS is a fairly simple protocol. IS-IS has recently attracted a lot of interest in the IEFT, and there is considerable ongoing effort for its advancement. Many vendors and large ISPs are backing IS-IS efforts in the IETF.

Both protocols continue to evolve and currently provide support for IPv6. IS-IS supports IPv6 through extensions to the original protocol whereas OSPF provides support by means of a new protocol, OSPF version 3. Both protocols continue to cross features and capabilities and seem to be advancing in lock-step. With route-leaking available in IS-IS, any architectural gap between IS-IS and OSPF has further been bridged.

It is completely unrealistic to say one protocol is better than the other. They are both the best in their class to do the job. Consider factors such as the following to help you select one over the other:

• Dual IP and CLNS support requirement

• Technical familiarity of the network engineering and operations staff

• Technical knowledge of vendor support staff

• Coherent standards and maturity

• Maturity of vendor implementation

• Multivendor interoperability requirements

• Need to build flat network or large areas