OSPF and Integrated IS–IS
In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
Ross Callon (RFC1925)
Abstract
In this chapter, we present two important link state routing protocols: Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS–IS). They are interior gateway protocols (IGPs) used in an autonomous system (AS). They are often deployed by large Internet service providers within their networks. For each of these protocols, general operations and message structures are presented. Their differences are also highlighted.
Keywords
OSPFv2; OSPFv3; LSA types; equal-cost multipath (ECMP); multitopology routing; integrated IS–IS
In this chapter, we consider two important link state routing protocols: Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS–IS). They are interior gateway protocols (IGPs) used in an autonomous system (AS). They are often deployed by large Internet service providers within their networks. The currently used version of OSPF in IPv4 networks is known as OSPF, version 2 (OSPFv2). OSPF for IPv6 networks is known as OSPFv3. Most of the discussions here are for OSPFv2. Unless we mention OSPFv3 explicitly, it is safe to assume that any mention of OSPF is for OSPFv2. While OSPF is exclusively designed for IP networks, IS–IS was designed for the connection-less network protocol (CLNP) in the OSI reference model. For use in IP networks, an integrated IS–IS or dual IS–IS protocol has been used to support both CLNP and IP, thus allowing an OSI routing protocol in IP networks. Most of our discussion will focus on the OSPF protocol; at the same time, we will highlight a few key features of integrated IS–IS; however, as of now, there are no fundamental differences between OSPF and IS–IS. In any case, we will highlight certain similarities and differences between OSPF and Integrated IS–IS.
6.1 From a Protocol Family to an Instance of a Protocol
OSPF is an instance of a link state protocol based on hop-by-hop communication of routing information, specifically designed for intra-domain routing in an IP network. Recall from our earlier discussion in Section 3.4.1 that such a routing protocol requires information about the state (e.g., cost) of a link, and the ability to advertise this link state reliably through in-band (in-network) communication. Furthermore, a link state protocol uses two sub-protocols, one to establish a neighborhood relationship through a hello protocol and another for database synchronization.
Going from a basic understanding of a protocol concept to an instance applicable in a specific networking environment requires certain customization, including provision for flexibility to handle various possible variations. Consider the following examples/scenarios:
• Flooding a link state advertisement is not always necessary since a network may have different types of transmission media. For example, if N routers in a network are, say, in the same local-area network (LAN), it unnecessarily creates 
links while a single-link definition is sufficient; furthermore, it also results in unnecessary shortest path computation in each router without any gain. Thus, some summarization is desirable.
• Besides LAN, are there other types of networks for which any customization is needed?
• An intra-domain network may consist of a large number of routers, possibly geographically spread out; thus, scalability is an important issue. Therefore, from the point of view of manageability and scalability, it is desirable to have the ability to cluster the entire domain into several sub-domains by introducing hierarchy. This, in turn, raises the possibility that an entire link state advertisement from one sub-domain to another may not need to be distributed, especially if two sub-domains are connected by just a link; some form of summarization is sufficient since all traffic would need to use this link after all. A major benefit of this hierarchy is that the shortest path computation at a router needs to consider links only within its sub-domain.
• How can flooding of a link state advertisement be accomplished in an IP network?
From the above discussion, we can see that a protocol intended for use in practice is required to address many functionalities and features. In the following section, we describe primary key features of OSPF, a commonly deployed link state protocol in IP networks.
6.2 OSPF: Protocol Features
OSPF provides many features. We will highlight the key features below. The packet format for various OSPF packets and the key fields are described later in Section 6.4. For clarity, any packet that carries OSPF routing information or is used for an OSPF protocol will be referred to as an OSPF packet, to distinguish it from packets for user traffic.
6.2.1 Network Hierarchy
OSPF provides the functionality to divide an intra-domain network (an autonomous system) into sub-domains, commonly referred to as areas. Every intra-domain must have a core area, referred to as a backbone area; this is identified with Area ID 0. Areas are identified through a 32-bit area field; thus, Area ID 0 is the same as 0.0.0.0.
Usually, areas (other than the backbone) are sequentially numbered as Area 1 (i.e., 0.0.0.1), Area 2, and so on. OSPF allows a hierarchical set up with the backbone area as the top level while all other areas, connected to the backbone area, are referred to as low-level areas; this also means that the backbone area is in charge of summarizing the topology of one area to another area and vice versa. In Figure 6.1, we illustrate network hierarchy using low-level areas.
6.2.2 Router Classification
With the functionality provided to divide an OSPF network into areas, the routers are classified into four different types (Figure 6.1):
• Area Border Routers: These are the routers that sit on the border between the backbone and the low-level areas. Each area-border router must have at least one interface to the backbone; it also has at least one interface to each area to which it is connected.
• Internal Routers: These are the routers in each low-level area that have interfaces only to other internal routers in the same area.
• Backbone Routers: These are the routers located in Area 0 with at least one interface to other routers in the backbone. Area-border routers can also be considered as backbone routers.
• AS Boundary Routers: These routers are located in Area 0 with connectivity to other AS; they must be able to handle more than one routing protocol. For example, to exchange information with another AS, they must be able to speak the Border Gateway Protocol (BGP). These routers also have internal interfaces for connectivity to other backbone routers.
The above terminologies, as described, are OSPF specific; however, it is also common to use names such as backbone routers in general. You will see such usage throughout this book; such usage should not be confused with Backbone Routers as used in the context of OSPF.
6.2.3 Network Types
OSPF is designed to address five different types of networks: 1) point-to-point networks, 2) broadcast networks, 3) non-broadcast multiaccess (NBMA) networks, 4) point-to-multipoint networks, and 5) virtual links.
Point-to-point networks refer to connecting a pair of routers directly by an interface/link such as OC-3. A router may be connected to multiple different routers by such point-to-point interfaces. Point-to-point links are typically used when an OSPF domain is spread out in a geographically distributed region.
Broadcast networks refer to networks such as LANs connected by a technology such as Ethernet. Broadcast networks, by nature, are multiaccess where all routers in a broadcast network can receive a single transmitted packet. In such networks, a router is elected as a Designated Router (DR) and another as a Backup Designated Router (BDR).
Non-broadcast multiaccess networks use technologies such as ATM or Frame Relay where more than two routers may be connected without broadcast capability. Thus, an OSPF packet is required to be explicitly transmitted to each router in the network. Such networks require an extra configuration to emulate the operation of OSPF on a broadcast network. Like broadcast networks, NBMA networks elect a DR and a BDR.
Point-to-multipoint networks are also non-broadcast networks much like NBMA networks; however, OSPF's mode of operation is different and is in fact similar to point-to-point links.
Virtual links are used to connect an area to the backbone using a non-backbone (transit) area. Virtual links are configured between two Area Border Routers. Virtual links can also be used if a backbone is partitioned into two parts due to a link failure; in such a case, virtual links are tunneled through a non-backbone area. Consider again Figure 6.1.
Here, Area 3 is connected to the backbone area using transit Area 2 through a virtual link that connects router R5 to router R13. Also note that if the link between routers R3 and R4 in the backbone area goes down, Area 0 becomes partitioned; to avoid that, a virtual link between Area-Border Routers R6 and R8 is established through Area 1.
Finally, an important point to understand about OSPF networks is that the neighborhood relation is not based on routers or networks connected by physical links, but is based on the logical adjacencies established.
6.2.4 Flooding
OSPF uses in-network functionality to flood routing information such as link state advertisements. In-network means OSPF packets are carried in the same network as user traffic. From the discussion above, we note that there are different possible network types. Thus, transmission of OSPF packets requires some tailoring.
First note that multiple link state advertisements can be combined into an OSPF link state update packet. Flooding is required for link state update packets as well as for link state advertisement packets (for a discussion about different packet types, see Section 6.4); the protocol type field in an IP packet header is set to 89 for OSPF packets. Also note that flooding is selective in that a router forwards an update only if it is not stale; for this, it relies on checking the age and the sequence number field, discussed earlier in Section 3.4.1.
On point-to-point networks, updates use the IP multicast address 224.0.0.5, referred to as AllSPFRouters. A router on receiving an update forwards it to other routers, if needed (after checking the sequence number), again using the same multicast address.
On broadcast networks, all non-DR and non-BDR routers send link state update and link state acknowledgment packets using the IP multicast address 224.0.0.6, referred to as AllDRouters. Any OSPF packets that originates from a DR or a BDR, however, use the IP multicast address 224.0.0.5.
In NBMA networks, link state advertisements are sent as unicast from non-DR/non-BDR routers to the DR and the BDR. DR, in turn, sends a copy of the link state advertisement (LSA) as unicast to all adjacent neighbors. On point-to-multipoint networks and virtual link networks, updates are sent as unicast using the interface's IP address of the adjacent neighbor.
Regardless of the network type, OSPF flooding must be reliable. Since OSPF sits directly on top of IP in the TCP/IP stack, OSPF is required to provide its own reliable mechanism, instead of being able to use a reliable transport protocol such as TCP. OSPF addresses reliable delivery of packets through use of either an implicit or explicit acknowledgment. An implicit acknowledgment means that a duplicate of the LSA as an update is sent back to the router from which it received the update. An explicit acknowledgment means that the receiving router sends a link state acknowledgment packet on receiving a link state update. Since a router may not receive acknowledgment from its neighbor to whom it sent a link state update message, a router is required to track a link state retransmission list of outstanding updates. An LSA is retransmitted, always as unicast, on a periodic basis (based on the value RxmtInterval) until an acknowledgment is received, or the adjacency is no longer available.
Finally, OSPF defines three global parameters in regard to flooding of LSAs. LSRefreshTime indicates the maximum acceptable time between generation of any particular LSA, regardless of whether the content of the LSA such as the metric value has changed; this time window is set to 30 min. MinLSInterval reflects the minimum time between generation of any particular LSA; this is set to 5 sec. Finally, MinLSArrival is the minimum time between reception of new LSAs during flooding, set to 1 sec; this parameter serves as the hold-down timer.
6.2.5 Link State Advertisement (LSA) Types
From the discussion about network hierarchy and network types, it is clear that an OSPF network requires different link state advertisement types. The five most commonly known LSA types are: Router LSA (type code=1), Network LSA (type code=2), Network Summary LSA (type code=3), AS Border Router (ASBR) Summary LSA (type code=4), and AS External LSA (type code=5).
A Router LSA is the most basic or fundamental link state advertisement that is generated for each interface. Such LSAs are generated for point-to-point links. Router LSAs are recorded in the link state database and are used by the routing computation module. Flooding of Router LSAs is restricted to the area where they originate.
Network LSAs are applicable in multiaccess networks where they are generated by the DR. All attached routers and the DR are listed in the Network LSA. Flooding of Network LSAs is also restricted to the area where they originate.
Area Border Routers generate Network Summary LSAs that are used for advertising destinations outside an area. In other words, Network Summary LSAs allow advertising IP prefixes between areas. Area Border Routers also generate ASBR Summary LSAs; in this case, they advertise AS Border Routers external to an area.
AS External LSAs are generated by AS Border Routers. Destinations external to an OSPF AS are advertised using AS external LSAs.
There are several additional LSA types; they are described later in Section 6.2.8.
6.2.6 Sub-Protocols
In our discussion of a link state protocol earlier in Section 3.4.1, we mentioned that sub-protocol mechanisms are also used for the operation of a link state protocol besides the main function of link state advertisement through flooding. Two key sub-protocols are: the hello protocol and the database synchronization protocol. It should be noted that to accomplish these protocols, various packet types such as the hello packet, database description packet, link state request packet, and link state update packet have been defined as part of the OSPF protocol; these packet types are outlined in detail later in Section 6.4.
Hello Protocol
While its name seems to imply that the hello protocol is just for initialization, it is actually much more than that. Recall that the OSPF protocol is designed for several different types of networks as discussed earlier in Section 6.2.3. First, during initialization/activation, the hello protocol is used for neighbor discovery as well as to agree on several parameters before two routers become neighbors; this means that using the hello protocol, logical adjacencies are established; this is done for point-to-point, point-to-multipoint, and virtual link networks. For broadcast and NBMA networks, not all routers become logically adjacent; here, the hello protocol is used for electing Designated Routers and Backup Designated Routers. After initialization, for all network types, the hello protocol is used to keep alive connectivity, which ensures bidirectional communication between neighbors; this means, if the keep alive hello messages are not received within a certain time interval that was agreed upon during initialization, the link/connectivity between the routers is assumed to be not available.
To accomplish the various functions described above, a separate hello packet is defined for OSPF. Details about the field are described in Section 6.4.
Database Synchronization Process
Beyond basic initialization to discover neighbors, two adjacent routers need to build adjacencies. This is important more so after a failed link is recovered between two neighboring routers. Since the link state database maintained by these two routers may become out of sync during the time the link was down, it is necessary to synchronize them again. While a complete link state advertisement of all links in the database of each router can be exchanged, a special database description process is used to optimize this step. For example, during the database description phase, only headers of link state advertisements are exchanged; headers serve as adequate information to check if one side has the latest LSA. Since such a synchronization process may require exchange of header information about many LSAs, the database synchronization process allows for such exchanges to be split into multiple chunks. These chunks are communicated using database description packets by indicating whether a chunk is an initial packet (using I-bit), or a continuation/more packet or last packet (using M-bit). Furthermore, one side needs to serve as a master (MS-bit) while the other side serves as a slave—this negotiation is allowed as well; typically, the neighbor with the lower router ID becomes the slave. It is not hard to see that the database synchronization process is a stateful process.
In Figure 6.2, we illustrate the database synchronization process, starting with initialization through the hello packet, adapted from [598]. After initialization, this process goes through several states: from exchange start to exchange using database description packets to synchronizing their respective databases by handling one outstanding database description packet at a time, followed by a loading state when the last step of synchronization is done; after that, for link state requests and updates for the entire LSA for which either side requires updated information, the communication takes place in the full state until there are no more link state requests.
6.2.7 Routing Computation and Equal-Cost MultiPath
First note that LSAs are flooded throughout an area; this allows every router in an area to build link state databases with identical topological information. Shortest path computation based on Dijkstra's algorithm (see Section 2.3) is performed at each router for every known destination based on the directional graph determined from the link state database; the link cost used for each link is the metric value advertised for the default type of service in the link state advertisement packet; see Figure 6.11 presented later for the metric field. Originally, it was envisioned that there will be different types of services that might require different metrics. Thus, a type of service (TOS) field was created. The default type of service (TOS) is indicated by setting the field, Number of TOS, to 0. The metric field allows the value to be between 1 and 
, both inclusive. If additional types of services are defined and supported by routers in an area, then for each type of service the shortest path can be computed separately. While the default metric is dimensionless, additional types of services are identified based on attributes such as monetary cost, reliability, throughput, and delay. At the same time, the default metric being dimensionless provides the flexibility to not explicitly consider metrics for other types of services in an operational environment since, through IP traffic engineering, the link metric/cost can be determined and set just under the default TOS, which can still take into account diverse goals of a network and the network provider. We discuss link cost determination for IP intra-domain traffic engineering in Chapter 7.
A nice feature of Dijkstra's algorithm computed at each router is that the entire shortest path from a source to a destination (in fact, for all destinations) is available at the end. OSPF allows a source routing option that can be used by user traffic on the path determined by Dijkstra's algorithm. Certainly, OSPF allows the default next hop option commonly deployed in IP networks; thus, once the path is computed, the next hop is also extracted from the shortest path computation to update the routing table and subsequently, the forwarding table. Note that routing table entries are for destinations identified through hosts or subnets or simply IP prefixes (with CIDR notation), not in terms of end routers. Thus, once the shortest path first computation is performed from a router to other reachable routers, reachable addresses from each destination router, as learned through link state advertisements, are identified, and the routing table entries are accordingly created for all such addresses. Because of CIDR, multiple similar route entries are possible. For example, there might be an entry for 10.1.64.0/24, and another for 10.1.64.0/18, where the difference is in the netmask. To select the route preferred by an arriving packet, OSPF uses a best route selection process. According to this process, the route(s) with the most specific match to the destination is selected, which is the one with the longest match. As an example, 10.1.64.0/24 would be preferred over 10.1.64.0/18. In case, there are multiple paths available after this step, the second step selects the route where an intra-area path is given preference over an inter-area path, which in turn gives preference over external paths for routers learned externally (refer to Section 6.2.8).
ECMP
An important feature of OSPF routing computation is the equal-cost multipath (ECMP) option; that is, if two paths have the same lowest cost, then the outgoing link (next hop) for both can be listed in the routing table so that traffic can be equally split. It may be noted the original Dijkstra's algorithm generates only one shortest path even if multiple shortest paths are available. To capture multiple shortest paths, where available, Dijkstra's algorithm is slightly modified. In line-23 of Algorithm 2.5 in Chapter 2, if the greater-than sign (>) is changed to the greater-than-or-equal-to sign (≥), it is possible to capture multiple shortest paths by identifying the next hops; in this case, line-25 is then updated to collect all next hops that meet the minimum, instead of just one when the strictly greater-than sign is used. Thus, more than one outgoing link in the case of multiple shortest paths would need to be stored, instead of just one.
It is important to note that ECMP is based on the number of outgoing interfaces (links) involved on the shortest path at the node level along the path, not at the source-destination path level. Consider the seven-router network shown in Figure 6.3. Assuming the hop count as the link cost metric, we can see that the paths between router 1 and router 5 are of equal cost. Thus, traffic from router 1 to router 5 can presumably be equally split at router 1 along the two directional links 1→2 and 1→7; traffic from router 1 that arrived at router 2 will be equally split further along its two outgoing links 2→3 and 2→4. Thus, of the traffic from router 1 destined for router 5, 25% will arrive at router 5 on each of the links 3→5 and 4→5 while one-half will arrive on link 6→5. This illustrates the meaning of equal-cost being interface-based. Since OSPF routing is directional, the traffic splitting for this example will be different for traffic going the other direction from router 5 to router 1. Since router 5 has three outgoing links, traffic will be split equally among the links 5→3, 5→4, and 5→6. Note that the traffic sent on the first two links will be combined at router 2; thus, two-thirds of the traffic from router 5 destined for router 1 will arrive at router 1 through link 2→1 while one-third will arrive on link 7→1.
It may be noted that the OSPF specification does not exactly say how ECMP is to be accomplished from an implementation point of view. In concept, packets that arrive for the same destination router can be equally split among outgoing links of ECMP paths. However, this is not desirable for several reasons. For instance, for a single TCP session (microflow), if the packets are sent on different ECMP paths that might consist of links with different link bandwidths, packets can arrive with different delays; this can then affect TCP throughput. If packets for this session are alternated across each link, then packet reordering can occur that then requires the destination host to re-assemble the reordered packets. Thus, router implementation handles the ECMP path selection on a per microflow basis. In most implementations, the ECMP path selection is based on the hash of certain fields of the IP packet without having to maintain states at routers. Yet, implementation at a per microflow choice level at a router can have an affect as well. If every router in the network makes identical decisions because of the way flows are processed by the router implementation, for example, due to destination prefix matching, microflows that arrive at router 1 destined for router 5 that are directed to link 1-2 would use only one of the paths 2→3→5 or 2→4→5 (see Figure 6.3). For instance, choosing a simple hash (say, exclusive-or the bytes) of the source-destination places a particular flow on a particular link, which is not desirable. Thus, any sophisticated router implementation addresses randomization of microflows to different ECMP outgoing links so that such situations do not occur. In summary, ECMP is accomplished by approximate split through randomization at a per microflow level (or at a destination address level) from a practical point of view.
The ECMP feature was designed to be helpful in load balancing traffic, but may not be helpful when troubleshooting a network. Thus, it is sometimes preferable to avoid using ECMP [797,816]. Furthermore, for large networks, the benefit of multipath routing diminishes as illustrated in Example 4.6 that is based on Result 4.1. More specifically, see Result 4.2 for the load balancing objective. For a comprehensive analysis, see also [501]. Thus, the true benefit of ECMP in large networks remains questionable.
Inter-Area Routing Computation
It is important to note that the Dijkstra-based shortest path computation using link state information is applied only within an area. For routing updates between areas, information from one area is summarized using Summary LSAs without providing detailed link information; thus, inter-area routing computation in OSPF is similar to the distance vector flavor. Since OSPF employs only a two-level hierarchy, a looping problem typically known to occur with a distance vector approach is not conceptually possible. Yet, due to aggregation and hierarchy, in certain situations, it is possible to create a scenario where looping can occur [699].
6.2.8 Additional Features
OSPF has the functionality to authenticate packet exchanges between two routers. As of RFC 5709 [107], Hashed Message Authentication Code-Secure Hash Algorithms (HMAC-SHA) standards are supported: HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. Furthermore, extensions to OSPF, to add digital signature authentication to LSA data and to provide ad certification mechanism for router data, have been addressed in RFC 2154 [607]. We highlight here a few additional features in OSPF.
Stub Areas and Stub Networks
Recall that we discussed backbone and low-level areas earlier. OSPF provides additional ways to define low-level areas. A low-level area is considered to be a regular area if all types of LSAs are permitted into this area; thus, all routers in a regular area can determine the best path to a destination. A stub area is an area where information about external routes, communicated through AS External LSAs, is not sent; the area border router on this stub area creates a default external route for use by the stub area. Consider Figure 6.1 again; here, Area-3 is a stub area.
A not-so-stubby area (NSSA) is a stub area that can import AS external routes—this means that this stub area has an unusual connectivity to another AS. Since routes/networks from this AS would need to be known to the rest of the Internet, this information needs to be imported. To accomplish this, an additional LSA type called NSSA-LSA (type code=7) is defined so that routes from an AS connected to a not-so-stubby area can be imported to an area border router where they can be converted to a type 5 LSA (AS-external-LSA) for flooding. For example, if you imagine such an area connected to Area 3 in Figure 6.1 (not shown in figure) that is outside the OSPF domain, then this area would be a not-so-stubby area. In addition, another area type called a totally stubby area is being used in practice; this type of area is useful for a large OSPF network since such an area can use a default route for all destinations outside this area (in addition to external routes), thereby saving on the memory requirement of routers in the area.
There is another term, stub networks, that should not to be confused with stub areas. A stub network is a network identified by an IP prefix that is connected to only one router within an area.
Additional LSA Types
In addition to the LSA types described earlier in Section 6.2.5, and the one described above, there are a few more LSA types that have been defined so far. For example, the Group Membership LSA (type code=6) is used in multicast OSPF (see Section 8.6 for a discussion on multicast OSPF). External Attributes (type code=8) has been deprecated; in its place, three new LSA types, known as the Opaque LSA option, has been defined. The role of the opaque LSA is to carry information that is not used by the SPF calculation, but can be useful for other types of routing calculations such as widest path routing. Three types of opaque LSA options have been defined to indicate the scope of propagation of information, i.e., whether it is link-local, area-local, or AS scope. Traffic engineering extensions to OSPF utilize the opaque LSA option; see Section 22.3.4.
Route Redistribution
In Section 5.7, we discussed route redistribution, especially for distance vector protocols. Route redistribution is similarly possible with OSPF and IS–IS; for example, one side can be EIGRP while the other side is OSPF. For OSPF that learns a route from another protocol such as EIGRP, NSS External LSA (type=7) can be used. To allow for route redistribution and metric compatibility, NSSS External LSA has an E-bit field to indicate whether to use the cost that is the external cost plus the cost of the path to the AS border router (“E1 type external path”), or simply the external cost (“E2 type external path”), and External Route Tag field for help in external route management. For the purpose of path selection for external routes, an E1 type external path is given preference over an E2 type external path.
6.3 Multitopology Routing in OSPF
OSPF, as originally defined, is meant for a single topology for which a single routing table is created. What if we want to have different routing tables for different service classes, or a different one for a failure state in the network? OSPF multitopology (MT) extension allows this possibility and is described in the proposed standard RFC 4915 [678]. The multitopology routing extension is also available for IS-IS, which is described in RFC 5120 [677].
With the MT-extension, a provider can create multiple topologies. For instance, each topology may not have the same links defined as in the native topology. Secondly, the link metrics may be different in different topologies for the same link. Then, routing computation is performed separately on each topology. Thus, different service classes may be put on different topologies by taking advantage of the MT-extension. Another important benefit of the MT-extension functionality is that it allows the functionality for network virtualizaiton.
To be able to distinguish different topologies, this extension defines MT-ID. This tag actually uses the old TOS field in LSAs that have been deprecated. With this, MT-ID set to 0 is considered the default topology (see Figure 6.11 shown later in this chapter). That is, the native topology serves as the default topology. Two other values of MT-ID are for specific purposes. MT-ID set to 1 is reserved for advertising the metrics associated with the default multicast topology, while MT set to 2 is for IPv4 in-band management.
The default topology is generally assumed to include all the links of the native topology; however, this is not necessary. The OSPF MT extension allows the possibility that some links in the default topology are to be excluded.
6.4 OSPF Packet Format
m
In this section, we describe packet formats for several key OSPF packet types for IPv4.
Common Header
The common header has the following key fields (Figure 6.4):
• Version: This field represents the OSPF version number; the current version is 2.
• Type: This field specifies the type of packet to follow by assigning a number to each type. OSPF has five packet types: hello (1), database description (2), link state request (3), link state update (4), and link state acknowledgment (5).
• Packet Length: This indicates the length of the OSPF packet.
• Router ID: This field indicates the ID of the originating router. Since a router has multiple interfaces, there is no definitive way to determine which interface IP address should be the router ID. According to RFC 2328 [598], it could be either the largest or the smallest IP address among all the interfaces. It may be noted that if a router is brought up without any interface connected, then it has no ability to acquire a router ID. To avoid this scenario, a loopback interface, being a virtual interface, can be used to acquire a router ID. In general, a router ID that is based on a loopback interface provides much more flexibility to network operators in terms of management than a physical interface based address.
• Area ID: This is the ID of the area where the OSPF packet originated. Value 0.0.0.0 is reserved for the backbone area.
• Checksum: This is the IP checksum over the entire OSPF packet.
• AuType and Authentication Field: AuType works with the Authentication field for authentication. There are three authentication types:
| AuType | Meaning | Authentication Field |
| 0 | No authentication | Can be anything |
| 1 | Simple, clear text password-based authentication | An 8-byte password |
| 2 | Cryptographic authentication | 8-byte is divided as shown in Figure 6.5 |
Note that when AuType is 2, it contains a KeyID, an Authentication Data Length and a Cryptographic Sequence Number. When cryptographic authentication is activated, the algorithm used can be MD5, HMAC-SHA-1, or anything else defined in RFC 5709. The actual algorithm chosen is based on KeyID.
Hello Packet
The primary purpose of the hello packet (Figure 6.6) is to establish and maintain adjacencies. This means that it maintains a link with a neighbor that is operational. The hello packet is also used in the election process of the Designated Router and Backup Designated Router in broadcast networks. The hello packet is also used for negotiating optional capabilities.
• Network Mask: This is the address mask of the router interface from which this packet is sent.
• Hello Interval: This field designates the time difference in seconds between any two hello packets. The sending and the receiving routers are required to maintain the same value; otherwise, a neighbor relationship between these two routers is not established. For point-to-point and broadcast networks, the default value is 10 sec, while for non-broadcast networks the default value used is 30 sec.
• Options: Options fields allow compatibility with a neighboring router to be checked.
• Priority: This field is used when electing the designated router and the backup designated router.
• Router Dead Interval: This is the length of time in which a router will declare a neighbor to be dead if it does not receive a hello packet. This interval needs to be larger than the hello interval. Also note that the neighbors need to agree on the value of this parameter. This way, a routing packet, that is received and does not match this field on a receiving router's interface folder, is dropped. The default value is typically four times the default value for the hello interval; thus, in point-to-point networks and broadcast networks, the default value used is 40 sec while in non-broadcast networks, the default value used is 120 sec.
• Designated Router (DR) (Backup Designated Router (BDR)): DR (BDR) field lists the IP address of the interface of the DR (BDR) on the network, but not its router ID. If the DR (BDR) field is 0.0.0.0, then this means there is no DR (BDR).
• Neighbor: This field is repeated for each router from which the originating router has received a valid Hello recently, meaning in the past RouterDeadInterval.
Database Description Packet
The OSPF database description packet has the following key features (Figure 6.7):
• Interface Maximum Transmission Unit (MTU): This field indicates the size of the largest transmission unit the interface can handle without fragmentation.
• Options: Options fields consist of several bit-level fields. The most critical one is the E-bit that is set when the attached area is capable of processing AS-external-LSAs.
• I/M/MS bits: I-bit (initial-bit) is initialized to 1 for the initial packet that starts a database description session; for other packets for the same session, this field is set to 0. M-bit (more-bit) is used to indicate that this packet is not the last packet for the database description session by setting it to 1; the last packet for this session is set to 0. MS-bit (master-slave bit) is used to indicate that the originator is the master by setting this field to 1, while the slave sets this field to 0. This was illustrated earlier in Figure 6.2.
• DD Sequence number: This field is used for incrementing the sequence numbers of packets from the side of the master during a database description session; the master sets the initial value for the sequence number.
• LSA Header: This field lists headers of the link state advertisements in the originator's link state database; it may list some or all of them.
Link State Request Packet
The link state request packet is used for pulling information. For example, based on the database description received from a neighbor, a router might want to know link state information from its neighbor. The link state request packet has the following fields that are repeated for each unique entry (Figure 6.8):
• Link State Type: This field identifies a link state type such as a router or network.
• Link State ID: This field is dictated by the link state type.
• Advertising Router: This is the address of the router that has generated this LSA.
Link State Update Packet
This packet (Figure 6.9) contains the first field to be the number of LSAs followed by information on LSAs that follow the LSA packet format. Thus, a link state update packet can contain one or more LSAs.
Link State Acknowledgment Packet
The link state acknowledgment packet is used in acknowledging each link state advertisement received from a neighboring router. This includes the LSA headers that follow the OSPF packet header where the type field is set to 5.
OSPF Link State Advertisement (LSA)
In some sense, this is the heart of the link state protocol concept. A link state advertisement packet consists of a header, followed by data for different link state types. Here, we will present packet formats for the Router LSA and Network LSA. First, the common LSA header has the following fields:
• Age: This field reflects the time in seconds since the LSA was originated. The originating router sets this value to 0. Through a global parameter, MaxAge, the maximum life of an LSA is set to 1 hour. When the age field for an LSA reaches MaxAge, LSA is flooded again regardless of changes in the link state of this LSA.
• Options: This is used to identify optional capabilities supported by the OSPF routing domain.
• Type: This field indicates the LSA type: 1 for Router LSA, 2 for Network LSA, and so on. This type field is not to be confused with the OSPF packet type discussed earlier.
• Link State ID: This field uniquely identifies an LSA.
• Advertising router: This is the OSPF router ID of the originating router.
• Sequence number: This field is incremented each time a new link state advertisement is generated by the originating router.
• Checksum and Length: The checksum is over the entire packet except for the age field. Length is counted in bytes for the entire LSA including the header.
Router LSA:
A Router LSA consists of the LSA header (Figure 6.10) followed by the content of the Router LSA (Figure 6.11). Every router generates a Router LSA that lists all the routers outgoing interfaces (links); for each interface, the state and cost of the link are included. In addition to the LSA header, a Router LSA has the following fields:
• N/W/V/E/B-bits: N-bit indicates that the router is an NSSA border router that translates Type-7 LSAs to Type-5 LSAs (see RFC 3101 [605]). W-bit is to indicate if the router is a wild-card multicast received (see RFC 1584 [596]). V-bit indicates if it is a virtual link; E-bit indicates an AS boundary router and B-bit indicates an area border router (see RFC 2328 [598]).
• Number of Links: This field indicates the total number of router interfaces.
• Link ID, Link Data and Link type: Link ID and Link data are better understood in the context of Link Type (see [239], [598]); this is summarized in Table 6.1.
Table 6.1
Router LSA: Link Type, Link ID, and Link Data.
| LinkType | Description | Link ID | Link Data |
| 1 | Point-to-point link | Neighboring router's Router ID | Interface IP address of originating router |
| 2 | Link to transit network | Interface IP address of Designated Router | Interface IP address of originating router |
| 3 | Link to stub network | IP network or subnet address | Network's IP address |
| 4 | Virtual link | Neighboring router's Router ID | Interface IP address |
• Metric: This is the cost of an interface/link. The value is in the range 1 to 65,535 (=
). The OSPF specification does not specify what values are to be used here. Rather, this is left to the network service provider to decide. In Chapter 7, we will discuss how values might be chosen for the purpose of traffic engineering of a network.
• Number of MT-ID, MT-ID, and MT-ID Metric: These fields are used to indicate TOS, which is now deprecated. Originally, the Number of TOS field indicated the different number of Type of Service; if this field is zero, then TOS and TOS Metric fields were not applicable. If the Number of TOS was 2, then TOS and TOS Metric fields were repeated twice; here TOS would then refer to a particular type such as normal service, maximize reliability, or minimize delay while the TOS Metric field would then include the cost for the associated TOS field. Note that the TOS-based routing that was originally defined was later deprecated. These fields have now been proposed to be used for a multitopology (MT) routing option. Thus, TOS is replaced by MT-ID so that metrics for multiple topologies can be advertised for each link.
Network LSA:
Network LSAs are generated by Designated Routers. In addition to the LSA header, a Network LSA has the following fields (Figure 6.12):
• Network Mask: This is the standard subnet mask information.
• Attached Router: This field is repeated once for each router that is fully adjacent to the DR.
6.5 Examples of Router LSA and Network LSA
In this section, we will illustrate router and network LSAs through an example, adapted from [598]. We will use private IP address space in this illustration. In Figure 6.13, we show two areas: Area 0 and Area 1. In Area 1, there are three stub networks: N1 identified by IP prefix 192.168.1.0, N2 by 192.168.2.0, and N3 by 192.168.3.0, which are off routers R1, R2, and R3, respectively. The transit network N4 is identified by 192.168.4.0 with R4 as the DR, while having IP interfaces to R1, R2, and R3, as noted. Both R3 and R4 area border routers are connected to Area 0. In our discussion, we will identify the router ID of a router by the highest IP address of all its interfaces. For example, router ID of R1 is 192.168.4.1 since this address is higher than its other interface to network N1 (192.168.1.0). For simplicity, we will assume all metric values to be 1.
Router R3 will generate two Router LSAs: one for Area 1 and the other for Area 0. For Area 1, it is necessary to identify two Link IDs: one for the transit network identified by DR 192.168.4.4 and the other for stub network 192.168.3.0. Now you can see how networks/IP prefixes are communicated to other routers in the network. Thus, when a router computes the shortest path tree, it first computes it for all the routers in its area; then, any networks it learns about from any of the Router LSAs of various routers can add a leaf for a route to such networks; this means that once completed, a routers routing table contains entries for all other routers as well as for destination networks. The information content of Router LSA for R3 for Area 1 is shown in Figure 6.14.
Router LSAs within Area 1 generated by routers R1 and R2 will be similar. Since R4 is the DR in Area 1, it will generate a network LSA for transit network N4 (Figure 6.15), which also identifies all the attached routers.
Now consider Area 0. R3 is connected to router R6 by a point-to-point link in Area 0; Router LSA for R3 would be different than when it sends to Area 1, as shown in Figure 6.16. Router LSA for R4, which is connected to router R5, will be similar.
6.6 Integrated IS–IS
Integrated IS–IS for both CLNP and IP protocols is described in RFC1195 [139] while the original IS–IS protocol was described in [385] and updated in [386]. IS–IS has its own terminology that is different from OSPF. For example, routers are referred to as intermediate systems; thus, the name intermediate systems-to-intermediate systems means router-to-router. We will use the term routers and intermediate systems interchangeably. LSAs are called link state protocol data units, or LSPs, for short. A broadcast network is referred to as a pseudonode; a designated intermediate system is elected from all the ISes to represent a broadcast network. An address to identify an intermediate system is called a network service access point (NSAP). Unlike OSPF that runs over IP, IS–IS can run directly over a layer-2 protocol; for example, on IEEE 802 (Ethernet), IS–IS is assigned Ether Type 0x22F4. Integrated IS–IS may be configured to run also over IP with the IP protocol type field set to 124. Similar to OSPF, IS–IS has also been extended to provide the same capabilities such as multitopology routing, strong authentication, and traffic engineering. In particular, traffic engineering capabilities are discussed in Section 22.3.4.
6.6.1 Key Features
We now highlight the main features of IS–IS protocols.
Areas
IS–IS provides two-level network hierarchy using areas that are similar to OSPF. The routers in the backbone area are called L2 routers; the internal routers in the low-level areas are called L1 routers. A network that has any low-level (L1) areas, must also have at least one L1/L2 router that sits in the L1 area but is connected to the L2 (backbone) area by a link. Note that in IS–IS, a router is entirely within an area, unlike OSPF, where a router can sit on the border between two areas; connectivity between areas is only through a link.
Addressing in IS–IS
Addressing in IS–IS is based on OSI-NSAP addressing and is compatible with USA GOSIP version 2.0 NSAP address format. GOSIP stands for Government Open Systems Interconnection Profile, the federal standard for network systems procurement that was standardized in the early 1990s. The OSI-NSAP addressing has the following key fields:
| Field | Size | Value |
| AFI (Authority and Format Identifier) | 1 byte | “47” |
| ICD (International Code Designator) | 2 bytes | “00 05” |
| DFI (Domain-Specific Path Format Identifier) | 1 byte | “xx” |
| AAI (Administrative Authority Identifier) | 3 bytes | “xx xx xx” |
| Reserved | 2 bytes | Must be “00 00” |
| RDI (Routing Domain Identifier) | 2 bytes | Contains autonomous system number |
| Area | 2 bytes | Assigned by the authorities responsible for the routing domain to uniquely identify areas |
| System ID | 6 bytes | Use either 1) “02 00” perpended to the 4-byte IP address of the router, or 2) IEEE 802 48-bit MAC address |
| N-Selector (Upper Layer Identifier) | 1 byte | Set to zero |
As you can see, several fields are used for setup in IP networks. The important ones are: RDI, Area, and System ID. When the last byte, N-selector, is set to zero, there is no upper-layer user, and the address is meant purely for routing; such network layer only NSAP addresses are called Network Entity Titles (NET). In effect, IS–IS for IP networks uses NET addressing. It is important to note that NET is a router identifier, not an interface identifier.
Pseudonodes and Non-Pseudonodes
IS–IS allows handling of different network types. For example, a broadcast network is treated as a pseudonode where one of the routers serves as the pseudonode, which is labeled the designated intermediate system (DIS), with links to each attached router.
For links that are not for broadcast networks but are for point-to-point networks and stub networks, a non-pseudonode is created. Essentially, a non-pseudonode is similar to a router LSA in OSPF.
Shortest Path Calculation
Shortest path calculation is based on Dijkstra's algorithm. Once a router receives a new LSP, it waits for 5 sec before running the shortest path calculation. There is a 10 sec hold-down timer between two consecutive shortest-path calculations within the same area. However, L1/L2 routers that reside in L1 areas must run separate shortest path calculations, one for the L1 area and the other for the L2 area.
Link metric in IS–IS has been originally limited to 6 bits and, thus, the value ranges from 0 to 63 and the total path cost in an IS–IS domain can have a maximum value of 1023. This 6-bit metric is known as a narrow metric. A wide metric extension is now available through traffic engineering extensions to IS–IS that permits a 24-bit metric, thus allowing a range of 0 to 16,777,215 (=
).
There are, however, significant differences in how the shortest path first calculation is done in IS–IS compared to OSPF; for details, see [112,113].
Categorization of Packets
IS–IS defines four categories of protocol packets, or protocol data units (PDUs): hello packet, link state PDUs (LSP), complete sequence number PDUs (CSNP), and partial sequence number PDUs (PSNP).
The purpose of the hello packet is similar to the hello packet for OSPF. IS–IS defines three types of hello packets; they are for 1) point-to-point interfaces, 2) L1 routers, and 3) L2 routers.
There are two types of LSPs—one for level 1 and the other for level 2. Each LSP contains three key information: LSP ID (8 bytes), the sequence number (4 bytes), and the remaining lifetime (2 bytes). LSP ID is system ID (6 bytes) followed by pseudonode ID; if the first byte of the pseudonode ID field is non-zero, then this LSP originated from a DIS in a broadcast network; the last byte is used for identification in case the LSP needs to be fragmented because it exceeds the maximum transmission unit of an interface. The remaining lifetime field is the same as the age field in an OSPF LSA; the difference is that the lifetime field value is set at the maximum age of 1200 sec (20 min) at the beginning and then decreases unlike OSPF where it is set to zero at the beginning and then increases. In addition to this, an LSP uses a Type-Length-Value (TLV) format to include information such as a list of connected IP prefixes along with subnet masks. This makes it possible to determine destination networks to which the domain is connected so that the routing table can properly list such destinations.
CSNPs are like database description packets in OSPF and are used for link state database synchronization. A router creates CSNPs with all LSPs in its local link state database. A PSNP is created when upon receiving a CSNP from a neighbor, it realizes that some parts are missing; this means that this router has received certain other LSPs that are in its location link state database but the neighbor's CSNP did not include them. Thus, the receiving router generates a PSNP to request a newer copy of the missing LSPs. In essence, PSNPs are similar to the link state request packet in OSPF.
Packet Format and Information Encoding Through TLV
The first eight bytes of IS–IS PDUs form the common header that includes fields such as version number, header length, and PDU types. After the common header, PDU specific fields are included followed by variable length fields. For example, PDU specific fields in the hello packet include fields equivalent to the Router Dead Interval in the OSPF hello packet. IS–IS Link state PDUs are similar to OSPF LSAs. A subtle difference is that while OSPF LSAs start with the age field set to zero and the counter is incremented until MaxAge to indicate the expiry of time, the IS–IS link state PDUs start with a remaining lifetime and the counter is decremented until zero to indicate that the lifetime has expired. Since there are two types of routers in IS–IS, L1 and L2, a field is included to indicate the originating router type.
The variable length field that follows the header is encoded using TLV encoding where one byte is assigned for code type (T), one byte for length (L), and a variable length value (V) field not to exceed 255 bytes since one byte is assigned for the length field. A representative set of well known types is listed in Table 6.2; note that many types are as originally described in ISO 10589 [385] while for IP environments several additional types were added in RFC 1195 [139] and in recent RFCs such as RFC 3784 [766]. There are types recently added for multitopology routing with IS–IS, as defined in RFC 5120 [677].
Table 6.2
TLV codes for Integrated IS–IS protocol.
| Type | TLV |
| 1 | Area Addresses (ISO 10589 [385]) |
| 2 | IS Neighbors (LSPs) (ISO 10589 [385]) |
| 3 | ES Neighbors (ISO 10589 [385]) |
| 4 | Partition Designated level 2 IS (ISO 10589 [385]) |
| 5 | Prefix Neighbors (ISO 10589 [385]) |
| 6 | IS Neighbors (Hellos) (ISO 10589 [385]) |
| 8 | Padding (ISO 10589 [385]) |
| 9 | LSP Entries (ISO 10589 [385]) |
| 10 | Authentication Information (ISO 10589 [385]) |
| 14 | LSP Buffersize (ISO 10589 [385]) |
| 22 | Extended IS Reachability (RFC 3784 [766]) |
| 128 | IP Internal Reachability Information (RFC 1195 [139]) |
| 129 | Protocols Supported (RFC 1195 [139]) |
| 130 | IP External Reachability Information (RFC 1195 [139]) |
| 131 | Inter-Domain Routing Protocol Information (RFC 1195 [139]) |
| 132 | IPv4 Interface Address (RFC 1195 [139]) |
| 133 | Authentication Information (RFC 1195 [139]) |
| 134 | Traffic Engineering router ID TLV (RFC 3784 [766]) |
| 135 | Extended IP Reachability TLV (RFC 3784 [766]) |
| 138 | Shared Risk Link Group (RFC 4205 [454]) |
| 142 | IPv6 Network Layer Protocol Identifier (NLPID) (RFC 5308 [363]) |
| 229 | Multitopology (RFC 5120 [677]) |
| 232 | IPv6 Interface Address (RFC 5308 [363]) |
| 235 | Multitopology Reachable IPv4 Prefixes (RFC 5120 [677]) |
| 236 | IPv6 Reachability (RFC 5308 [363]) |
| 237 | Multitopology Reachable IPv6 Prefixes (RFC 5120 [677]) |
For routing IPv6 with IS–IS, three new TLVs have been defined as follows: IPv6 Reachability, IPv6 Interface Address, and an IPv6 network layer protocol (NLP) identifier. While reachability for IPv4 in IS–IS was accomplished through two TLV types 128 and 130 for internal and external, respectively, this was done with one TLV for IPv6 in IS–IS and an external origin bit; the new TLV has been assigned type 236. IPv6 Interface Address is assigned type 232, which is analogous for the 132 for an IPv4 Interface Address. The type for IPv6 NLPID is 142.
An up-to-date list of all types assigned is maintained at [395].
6.7 Similarities and Differences Between IS–IS and OSPF
It is helpful to consider the similarities and differences between IS–IS and OSPF. First, it should be noted that fundamentally there is little difference between OSPF and IS–IS. Thus, the differences center more on how certain things are done and are mostly stylistic differences.
Similarities
There are several similarities between IS–IS and OSPF:
• Both protocols provide network hierarchy through two-level areas.
• Both protocols use Hello packets to initially form adjacencies and then continue to maintain them.
• Both protocols have the ability to do address summarization between areas.
• Both protocols maintain a link state database, and shortest path computation performed using Dijkstra's algorithm.
• Both protocols have the provision to elect a designated router for representing a broadcast network.
Differences
While there are similarities as noted above, there are several differences:
• With OSPF, an area border router can sit on the boundary between the backbone area and a low-level area with some interfaces in the area while other interfaces are in the other area. In IS–IS, routers are entirely within one or the other areas—the area borders are on links, not on routers.
• While OSPF packets are encapsulated in IP datagrams, IS–IS packets can be directly encapsulated in link layer frames.
• The OSPF dimensionless link metric value is in the range 1 to 65,535 while IS–IS allows the metric value to be in the range 0 to 63 (narrow metric), which has been extended to the range 0 to 16,777,215 (wide metric).
• IS–IS being run directly over layer-2 is relatively safer than OSPF from spoofs or attacks.
• IS–IS keepalive messages can be used for MTU detection since the messages are MTU-sized TLVs that are explicitly checksummed and need to be verified.
• IS–IS allows overload declaration through an overload bit by a router to other routers. This is used, for example, by other routers to not consider an overloaded router in path computation.
• Since OSPF runs over IP, it can support virtual links.
While the overload bit feature of IS–IS is not directly available in OSPF, it can be indirectly induced in OSPF by setting the link metric to the highest value (65,535) on the relevant links to an overloaded router, so that this router is avoided in the short path calculation. Certainly, this requires extra work with OSPF in terms of configuration.
Along with similarities and differences, it is helpful to also consider a time line of the evolution of OSPF and IS–IS in their early years as outlined in Table 6.3. Today, their differences are minimal. A provider can choose either protocol, depending mostly on the in-house expertise of one or the other protocols, and how they perceive their own configuration and change costs in actual deployment of these protocols based on the vendors' implementations.
Table 6.3
IS–IS and OSPF development/deployment timeline (adapted from [438]).
| Year | Note |
| 1987 | IS–IS (CLNP) chosen as the OSI intra-domain protocol from DECnet proposal |
| 1988 | NSFnet deployed; routing protocol uses an early draft of IS–IS |
| Work on OSPF started | |
| IP extensions to IS–IS defined | |
| 1989 | OSPFv1 (RFC 1131) published |
| Proteon ships OSPF implementation | |
| IS–IS becomes ISO proposed standard | |
| 1990 | Integrated IS–IS (RFC 1195) published |
| 1991 | OSPF v2 (RFC 1247) published |
| Cisco ships its OSPF implementation | |
| Cisco ships its OSI-only IS–IS implementation | |
| 1992 | Cisco ships dual IS–IS implementation |
| Many deployment of OSPF | |
| 1993 | Novell publishes NLSP |
| 1994 | Cisco ships NLSP, rewriting IS–IS as well |
| IS–IS is recommended for large ISPs due to recent rewrite and OSPF field experience, and CLNP mandate by NSF | |
| 1995 | ISPs begin deployment of IS–IS |
| 1996–1998 | IS–IS niche popularity continues to grow (some ISPs switch to it from OSPF) |
| IS–IS becomes barrier to entry for router vendors targeting large ISPs | |
| Juniper and other vendors ship IS–IS capable routers | |
| 1999–present | Extensions continue for both protocols in parallel (e.g., Traffic Engineering) |
6.8 OSPFv3 and IS–IS for IPv6
OSPF for IPv6 is known as OSPFv3 [192]. Certainly, the address space going from IPv4 to IPv6 requires some necessary changes in OSPFv3 compared to OSPFv2. Yet, there are a number of features that remain unchanged. We first briefly summarize the unchanged features:
• Both of them have the same packet types: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets.
• The same link types, point-to-point, broadcast, NBMA, point-to-multipoint, and virtual link, continue to be on OSPFv3.
• When it comes to neighbor relationships (discovery and maintenance) and adjacencies (selection and establishment), there is no change.
• The interface state machine and the neighbor state machine remain the same.
• Aging of the link state database is the same in OSPFv3 as it was in OSPFv2.
Here are a few notable changes in OSPFv3 compared to OSPFv2:
• As opposed to the IPv4 network or subnet used in OSPFv2, OSPFv3 uses the term “link”. An advantage is that multiple IPv6 subnets can be associated with a link. Consequently, OSPFv3 runs per-link as opposed to per-subnet with IPv4 in OSPFv2. Another important change, because of this, is in the content of Hello packets and network-LSAs and receiving of OSPF protocol packets.
• Addressing semantics has been removed in OSPFv3. That is, OSPF packets do not include IPv6 addresses, except in LSA payloads with link state updates. Also, router-LSAs and network-LSAs contain topology information, not network addresses. Another important distinction is that OSPF Router ID, Area IDs, and LSA Link State IDs still use a 32-bit address, not an IPv6 address. A neighboring router is now identified by the Router ID; this, however, impacts how OSPFv3 does its shortest path computation; see [112] for details.
• There is no authentication in OSPFv3. Instead, authentication and integrity are based on the IPv6 Authentication Header (AH) and Encapsulating Security Payload (ESP). To authenticate packets, OSPFv3) relies on IPSec, which has its own difficulties in terms of configuration and maintenance. As an alternative option to IPSec, an Authentication Trailer has been proposed; see RFC 7166 [108].
In addition, going from OSPFv2 to OSPFv3 requires changing the OSPF packet format (such as the version number value) and the LSA format. For details on all changes, see [192].
In regard to IPv6 for IS–IS [363], the basic structure of IS–IS remains the same since it uses TLV for encoding. The extension is relatively simple; it requires two new TLVs, a reachability TLV (assigned TLV type 236) and an interface address TLV (assigned TLV type 232), and a new IPv6 Network Layer Protocol ID (NLPID) (assigned the value 142).
6.9 Additional Extensions to OSPF and IS–IS
There have been a number of extensions to the original OSPF and IS–IS. We discussed a few of them above such as for multitopology routing and the extension for IPv6.
An important extension to OSPF and IS–IS is for traffic engineering. They are commonly referred to as OSPF-TE and IS–IS-TE. These extensions are for multiprotocol label switching (MPLS) networks. They are discussed in Sections 22.3.4 and 22.4.4 in Chapter 22.
Another extension is for multicast support for OSPF; this is discussed in Section 8.6 in Chapter 8. An OSPF extension has been proposed for quality-of-service routing; see Section 21.7.1 in Chapter 21.
6.10 Summary
In this chapter, we have presented the OSPF protocol discussing its main features at length. We have also described packet formats for certain key packets in OSPF. Furthermore, we have presented examples of LSAs for OSPF networks. We also presented the integrated IS–IS protocol through a summary of its key features. Both OSPF and IS–IS are stateful protocols. Note that both OSPF and IS–IS allow route redistribution capability (refer to Section 5.7).
We also provided a brief summary on the similarities and differences between the OSPF and the IS–IS protocols. It may be noted that, as of now, there are no fundamental differences between OSPF and IS–IS. In retrospect, it can be said that market competition made both protocols as robust as possible. Thus, the choice of routing protocol for deployment in an ISP's network is based on issues such as configuration management, maintainability of large networks, in-house expertise, and so on. Typically, medium to large-scale ISPs use either OSPF or IS–IS protocol while small providers or campus networks use routing protocols such as EIGRP. Finally, while OSPF defines the concept of areas, many providers deploy their networks configured simply with a single area (Area 0); in many instances, a single area is found to be easy to manage since all routers see the same view, which can be helpful in troubleshooting any routing problem. In practice, it appears that IS–IS is mostly deployed in a single large area without any hierarchy; there is a perception that OSPF does not scale well for such a large non-hierarchical network.
Further Lookup
While the link state routing protocol goes back to ARPANET when the “new” ARPANET routing was introduced [555], this approach gained significance during the early days of OSI protocol development. IS–IS was introduced in 1987. Factors including NSFnet deployment were key drivers in creating the first version of the OSPF protocol [595]. It was also recognized in the late 1980s that the IS–IS protocol can be tweaked to work in an IP environment [139].
The OSPF standard, known as version 2, for IPv4 is described in RFC 2328 [598]; also, see [597] for a detailed discussion of OSPF. For the IS–IS standard, see [385] and [386]; now, RFC 1142 [635] is designated as historic [750]. For a comparative discussion on OSPF and IS–IS, see [438]. For additional discussions on the similarities and differences between OSPF and IS–IS, see [109], [112], [239], [259], [661]. For details on command line level configuration of OSPF and IS–IS, there are several books available; for example, see [239].
For security and authentication mechanisms for OSPFv2, see RFC 5709 [107] and RFC 7474 [106].
OSPF has been extended for use with IPv6 addressing, referred to as OSPFv3; for details, see RFC 5340 [192].
For the latest discussions on routing related issues, you might want to read the blog posts [111]. At this link, you will also find a recent discussion on differences (rather lack of differences) between OSPF and IS–IS in today's environment.
Exercises
6.1 Review questions:
(a) What are the different OSPF packet types?
(b) What is the range of allowable metric values in OSPF and IS–IS?
(c) What is a database description packet?
(d) What is a link state advertisement?
(e) What is a designated router?
(f) What is a network entity title?
6.2 Describe a use of a not-so-stubby area.
6.3 Explore route redistribution between OSPF and EIGRP.
6.4 Identify the functionality in OSPF that allows a static route to be injected into an OSPF domain.
6.5 Consider a five-router OSPF network. How many entries will be in the routing table at each router?
6.6 Consider a fully-connected N-router OSPF network. Suppose one of the routers goes down. Estimate how many total link state messages would be generated before the network converges.
6.7 Why are different types of LSAs defined in OSPF?
6.8 How is the router ID determined in OSPF? How about IS–IS?
6.9 How is an OSPF area different from an IS–IS area?
6.10 Can you redistribute a route learned from OSPF to IS–IS and vice-versa?
6.11 Refer to the discussion about the generic link state routing protocol framework in Section 3.4. Present a comparative assessment between the basic framework and OSPF/IS–IS.
6.12 Explore how the shortest path first calculation is performed differently between OSPF and IS–IS (hint: [112,113]).