This seems to be the favorite question that every newbie has! There is no unequivocal answer to this and it all depends upon the kind of network and the topology. Having said this, lets try to see how the two IGPs can be compared.
IS-IS
This protocol is limited by the maximum number of LSPs that each IS-IS router can issue. This is 256 as its LSP ID is 1 octet long. The total number of IP prefixes carried by IS-IS can be easily computed and it comes to O(31000). However, RFC 3786 describes mechanisms to relax the limit on the number of LSP fragments, thereby increasing the number of IP prefixes that can be carried within IS-IS.
I have however, not seen any network carrying more than O(30K) IP prefixes inside IS-IS. Please let me know if you're aware of one that does!
I say this because this is a reasonable number for any sane IS-IS deployment and it will not run out of space unless someone actually injects the entire BGP feed into the IGP. In that case we will run out of space at about 20% of the way into redistribution and not be able to advertise the rest. It is for this reason that this practice has now been deprecated and the RFC 1745 which lays down the rules for BGP- OSPF interaction, has been moved to the HISTORICAL status.
There are 8 bits to define a pseudonode number in the LSPID which means that a router can be DIS for only 256 LANs. Additionally there is also a limitation on the number of routers that can be advertised in pseudonode LSP of the DIS. Dont worry - RFC 3786 fixes this.
RFC 3373 OTOH proposes a new TLV thats carried in the HELLO PDUs that can increase the number of p2p adjacencies from 256 on a single router.
The "Remaining lifetime" field which gives the number of seconds before LSP is considered expired is 16 bits wide.
This gives the life time of the LSP as 2^16/60/60 Hrs = 18.7 Hrs
Thus each LSP needs to be refreshed after every 18.7 Hrs.
OSPF
In theory, OSPF topology is limited by the number of links that can be advertised in the Router LSA as each router gets only one Router LSA and it cant be bigger than 64K which is the biggest an IP packet can be. The same constraint applies to the Network LSA also.
Each link in the router can take up at most 24 bytes. Thus, number of links which can be supported is given by (64 * 1024) / 24 = 2370
However, if we take the minimum link size per link (12 bytes) then the maximum is about 2 * 2370 = O(5000) links
To be more specific, we can have O(2300) p2p and p2mp links (not considering virtual links, etc) and O(5000) broadcast/NMBA links described in OSPF's Router LSA and its Network LSA.
Thus each Router LSA can carry some 5000 links information in it. It is hard to imagine a router having 5000 neighbors but there are already routers with 400 neighbors in some ISPs, and it doesn't take long to reach the order of the magnitude limited by OSPF.
The Network LSAs are generated by the DR for each broadcast network it is connected to. To have scaling problems it should have 2730 * 6 times neighbors on that interface. This is even less probable and hence there are no scalability problems with OSPF per se.
All other LSAs apart from Type 1 and Type 2 hold single prefixes. Because there is no limit to the number of such LSAs, a large number of inter-area and externals can be generated depending upon the memory resources of the router.
Each LSA has an LS Age field which is counted upwards starting from zero. Its life is an architectural constant which says one hour. When an LSA's LS age field reaches MaxAge, it is reflooded in an attempt to flush the LSA from the routing domain. One hour seems like a long time but if one originates 50,000 LSAs then OSPF will be refreshing on an average of just 36ms!
Total number of LSAs to be refreshed = 50,000
Time by which all the LSAs must be refreshed = LSRefreshTime = 30mins = 1800 secs
Rate at which the LSAs need to be refreshed = 1800/50000 = 36ms
However, if the refreshes are perfectly spread out across time and perfectly batched, the actual update transmission rate may be on the order of one packet per second.
There is however a "do-not-age" LSA which in theory can be pressed into service and which never gets aged. 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. Moreover it is not backward compatible and if one deploys that in the network today with some routers not supporting this then the network can really get weird. So there isn't really much that can be done using these unless the whole network is changed!
Both the routing protocols are scalable and there should not be any scalability issues with any one of them if implemented properly. Both have similar stability and convergence properties.
Database Granularity in OSPF vs IS-IS ..
This post compares how the two protocols hold their routing information in their link state databases. The way these protocols encode the routing information in their database, affects their behavior in how they flood/distribute the change of routing information and the internal implementation complexity.
OSPF
- Organization of Routing Information
OSPF encodes the routing information into small chunks, which it calls Link State Advertisement (LSA). Each LSA has its own 20-byte header in order to be identified uniquely. This header is called the LSA Header. There is no limitation on the size of a LSA, though the actual LSA size is limited by IP packet size limitation: 65,535 bytes minus the LSA Header size and IP packet header size. The database access in OSPF is per LSA basis.
In OSPF routing, the information within an area is described by type 1 and type 2 LSAs (known as Router-LSA and Network-LSA respectively). These LSAs can become big depending upon the number of adjacencies to be advertised and prefixes to be carried inside an area. In other words, the routing information with respect to a single node (either router or network node) is encoded inside a single LSA. On the other hand, each inter-area or external prefix is advertised in a separate LSA (AS-External LSA).
An OSPFv2 router may originate only one Router-LSA for itself, while in OSPFv3, a router is allowed to originate multiple Router-LSAs. A router may originate a Network-LSA for each IP subnet on which the router acts as a DR. A router may originate one LSA for each inter-area and external prefix, with no limitations on the number of LSAs that it may originate.
Consequences
Originating a new and a unique LSA for each inter-area route and an external prefix implies that there is a LSA Header overhead involved while the information is kept in the database or is flooded to the neighbors. There is thus some extra memory and bandwidth consumed in total.
Carrying Routing Information
LSAs are carried in Link State Update packets (called LS Updates or LSUs). Each LS Update packet has its own header, consists of a 24 byte OSPF protocol header, and a 4-bytes field indicating the number of LSAs contained in the packet. Thus multiple LSAs can be packed into a single LS Update packet. Some implementations may not do this as its considered difficult achieving this during flooding.
Consequences
In the face of network changes, OSPF floods only the updated LSAs. Therefore, even if an implementation does not pack multiple LSAs into a single LS Update packet (and so bandwidth is consumed by LS Update header for each update of a single LSA), the bandwidth consumption for each network change can be considered adequately small.
IS-IS
Organization of the Routing Information
In IS-IS, protocol packets are called Protocol Data Units or PDUs. IS-IS encodes the link state information into the set of TLVs and packs these TLVs into one or more Link State PDUs (LSPs). The size limit of a LSP is configurable. The Routing database consists of these PDUs and the access to the database is per PDU basis. The original IS-IS specification places an upper bound on the number of LSPs a router can originate to 255. There are however techniques which enable a router to originate more than 255 LSPs, by using multiple system-id's for itself.
Consequences
Since routing information in IS-IS for each router is packed in fewer LSPs, the memory consumed for bookkeeping of the routing data within the database is less and is more efficient.
Carrying Routing Information
Each LSP is flooded independently, without being modified all the way from the originator through the routers till the very end. This results in all the routers having the same LSPs as that originated by the first router.
Consequences
Since LSPs are not modified in any way and are not allowed to be fragmented, in order to be flooded successfully over all links existing in the IS-IS network, great care must be ensured when configuring the size limit of LSP that routers can originate and receive.
If the size limit of the LSP is set without taking into account the minimum value of the MTUs throughout the network, or if the size limit of LSPs conflict among some the routers in the network, the database synchronization may not be achieved, and this can result in routing loops and/or blackholes.
When a change occurs to a LSP, the whole LSP needs to be flooded, and therefore the bandwidth usage can be non-optimal. There is however a solution which exists in theory. If an implementation finds some of the entities to be flapping, then they may be packed into smaller LSPs or may be isolated from the other stable entities. This way one needs to only advertise the unstable LSP/LSPs. I have not btw come across any implementation that does that. Leave a comment if you know one that does this!
Database granularity also affects when two routers need to synchronize their databases. In OSPF, because of its high database granularity there are a lot of items which it needs to synchronize and that process is somewhat complicated with a lot of DBD packets being exchanged back and forth. This gets worse if the router trying to sync is being inundated with a lot of other data traffic also. This is not much of an issue these days as any router worth its salt would prioritze the OSPF control packets.
This is however much simpler in case of IS-IS and there isn't any FSM that the neighbors need to go through to synchronize their databases. It just uses it regular flooding mechanism (a couple of CSNPs describe their entire topology information) to exchange its entire database. You plug in the new IS-IS router and before you realize the router is already sync'ed up with all the other IS-IS routers in the network!
OSPF
- Organization of Routing Information
OSPF encodes the routing information into small chunks, which it calls Link State Advertisement (LSA). Each LSA has its own 20-byte header in order to be identified uniquely. This header is called the LSA Header. There is no limitation on the size of a LSA, though the actual LSA size is limited by IP packet size limitation: 65,535 bytes minus the LSA Header size and IP packet header size. The database access in OSPF is per LSA basis.
In OSPF routing, the information within an area is described by type 1 and type 2 LSAs (known as Router-LSA and Network-LSA respectively). These LSAs can become big depending upon the number of adjacencies to be advertised and prefixes to be carried inside an area. In other words, the routing information with respect to a single node (either router or network node) is encoded inside a single LSA. On the other hand, each inter-area or external prefix is advertised in a separate LSA (AS-External LSA).
An OSPFv2 router may originate only one Router-LSA for itself, while in OSPFv3, a router is allowed to originate multiple Router-LSAs. A router may originate a Network-LSA for each IP subnet on which the router acts as a DR. A router may originate one LSA for each inter-area and external prefix, with no limitations on the number of LSAs that it may originate.
Consequences
Originating a new and a unique LSA for each inter-area route and an external prefix implies that there is a LSA Header overhead involved while the information is kept in the database or is flooded to the neighbors. There is thus some extra memory and bandwidth consumed in total.
Carrying Routing Information
LSAs are carried in Link State Update packets (called LS Updates or LSUs). Each LS Update packet has its own header, consists of a 24 byte OSPF protocol header, and a 4-bytes field indicating the number of LSAs contained in the packet. Thus multiple LSAs can be packed into a single LS Update packet. Some implementations may not do this as its considered difficult achieving this during flooding.
Consequences
In the face of network changes, OSPF floods only the updated LSAs. Therefore, even if an implementation does not pack multiple LSAs into a single LS Update packet (and so bandwidth is consumed by LS Update header for each update of a single LSA), the bandwidth consumption for each network change can be considered adequately small.
IS-IS
Organization of the Routing Information
In IS-IS, protocol packets are called Protocol Data Units or PDUs. IS-IS encodes the link state information into the set of TLVs and packs these TLVs into one or more Link State PDUs (LSPs). The size limit of a LSP is configurable. The Routing database consists of these PDUs and the access to the database is per PDU basis. The original IS-IS specification places an upper bound on the number of LSPs a router can originate to 255. There are however techniques which enable a router to originate more than 255 LSPs, by using multiple system-id's for itself.
Consequences
Since routing information in IS-IS for each router is packed in fewer LSPs, the memory consumed for bookkeeping of the routing data within the database is less and is more efficient.
Carrying Routing Information
Each LSP is flooded independently, without being modified all the way from the originator through the routers till the very end. This results in all the routers having the same LSPs as that originated by the first router.
Consequences
Since LSPs are not modified in any way and are not allowed to be fragmented, in order to be flooded successfully over all links existing in the IS-IS network, great care must be ensured when configuring the size limit of LSP that routers can originate and receive.
If the size limit of the LSP is set without taking into account the minimum value of the MTUs throughout the network, or if the size limit of LSPs conflict among some the routers in the network, the database synchronization may not be achieved, and this can result in routing loops and/or blackholes.
When a change occurs to a LSP, the whole LSP needs to be flooded, and therefore the bandwidth usage can be non-optimal. There is however a solution which exists in theory. If an implementation finds some of the entities to be flapping, then they may be packed into smaller LSPs or may be isolated from the other stable entities. This way one needs to only advertise the unstable LSP/LSPs. I have not btw come across any implementation that does that. Leave a comment if you know one that does this!
Database granularity also affects when two routers need to synchronize their databases. In OSPF, because of its high database granularity there are a lot of items which it needs to synchronize and that process is somewhat complicated with a lot of DBD packets being exchanged back and forth. This gets worse if the router trying to sync is being inundated with a lot of other data traffic also. This is not much of an issue these days as any router worth its salt would prioritze the OSPF control packets.
This is however much simpler in case of IS-IS and there isn't any FSM that the neighbors need to go through to synchronize their databases. It just uses it regular flooding mechanism (a couple of CSNPs describe their entire topology information) to exchange its entire database. You plug in the new IS-IS router and before you realize the router is already sync'ed up with all the other IS-IS routers in the network!
Shortest Path First (SPF) Calculation in OSPF and ISIS .. !
Both the protocols use Shortest Path First (SPF) algorithm to calculate the best path to all known destinations based on the information in their link state database. The SPF algorithm works by building the shortest path tree from a specific root node to all other nodes in the area and thereby computing the best route to every known destination from that particular source/node.
IS-IS
- SPF for a given level is computed in a single phase by taking all IS-IS LSP's TLV's together.
- IP routing is integrated into IS-IS by adding some new TLVs which carry IP reachability information in the LSPs. All IP networks are considered externals, and they always end up as leaf nodes in the shortest path tree when IS-IS does a SPF run.
- Used narrow (6 bits wide) metrics which helped in some SPF optimization. However such small bits proved insufficient for providing flexibility in designing IS-IS networks and other applications using IS-IS routing (MPLS-TE). "IS-IS extensions for Traffic Engineering" RFC introduced new TLVs which defined wider metrics to be used for IS-IS thus taking away this optimization.
But then CPU are fast these days and there are not many very big networks anyway.
- Performs only the less CPU intensive Partial Route Calculation (PRC) when network events do not affect the basic topology but only the IP prefixes.
OSPF
- SPF is calculated in three phases. The first is the calculation of intra-area routes by building the shortest path tree for each attached area. The second phase calculates the inter-area routes by examining the summary LSAs and the last one examines the AS-External-LSAs to calculate the routes to the external destinations.
- Is built around links, and any IP prefix change in an area will trigger a full SPF.
- Only changes in interarea and external routes result in partial SPF calculations and thus IS-IS's PRC is more pervasive than OSPF's partial SPF. This difference allows IS-IS to be more tolerant of larger single area domains whereas OSPF forces hierarchical designs for relatively smaller networks. However with the route leaking from L2 to L1 incorporated into IS-IS the apparent motivation for keeping large single area domains too goes away.
IS-IS
- SPF for a given level is computed in a single phase by taking all IS-IS LSP's TLV's together.
- IP routing is integrated into IS-IS by adding some new TLVs which carry IP reachability information in the LSPs. All IP networks are considered externals, and they always end up as leaf nodes in the shortest path tree when IS-IS does a SPF run.
- Used narrow (6 bits wide) metrics which helped in some SPF optimization. However such small bits proved insufficient for providing flexibility in designing IS-IS networks and other applications using IS-IS routing (MPLS-TE). "IS-IS extensions for Traffic Engineering" RFC introduced new TLVs which defined wider metrics to be used for IS-IS thus taking away this optimization.
But then CPU are fast these days and there are not many very big networks anyway.
- Performs only the less CPU intensive Partial Route Calculation (PRC) when network events do not affect the basic topology but only the IP prefixes.
OSPF
- SPF is calculated in three phases. The first is the calculation of intra-area routes by building the shortest path tree for each attached area. The second phase calculates the inter-area routes by examining the summary LSAs and the last one examines the AS-External-LSAs to calculate the routes to the external destinations.
- Is built around links, and any IP prefix change in an area will trigger a full SPF.
- Only changes in interarea and external routes result in partial SPF calculations and thus IS-IS's PRC is more pervasive than OSPF's partial SPF. This difference allows IS-IS to be more tolerant of larger single area domains whereas OSPF forces hierarchical designs for relatively smaller networks. However with the route leaking from L2 to L1 incorporated into IS-IS the apparent motivation for keeping large single area domains too goes away.
Flushing LSAs and LSPs in OSPF and IS-IS
An LSA/LSP is flushed (purged) when the contents carried by the LSA/LSP are no longer valid. In OSPF when an LSA is flushed the age is set to MaxAge and the LSA is flooded. In IS-IS when an LSP is purged (flushed) the header alone is flooded with the Remaining Lifetime set to 0, and the value of checksum set to 0.
OSPF only allows self originated LSA to be flushed, IS-IS spec allows in certain cases for non-self originated the LSP to be purged (though new implementations don't support this and the update RFC has changed it) which can lead to problems.
In OSPF a flushed LSA is not removed unless the LSA is not on any of the retransmit lists and none of the adjacencies on the router are in state Exchange or loading. This ensures that an LSA that an LSA is flooded to all its neighbors before it is removed from the domain. In IS-IS an LSP purged is kept for ZeroAge lifetime if the LSP purged is a self originated LSP and the LSP is kept for MaxAge if the LSP is non self-originated before the LSP is deleted.
When purging an IS-IS LSP the header and authentication data is kept while purging (certain OSPF implementations do the same). However for those LSP's that don't support authentication, because the checksum is set to 0 for purged LSP's, the integrity of the contents cannot be verified. In OSPF the entire content of the LSA is intact while flushing leading to unnecessary data sending.
OSPF only allows self originated LSA to be flushed, IS-IS spec allows in certain cases for non-self originated the LSP to be purged (though new implementations don't support this and the update RFC has changed it) which can lead to problems.
In OSPF a flushed LSA is not removed unless the LSA is not on any of the retransmit lists and none of the adjacencies on the router are in state Exchange or loading. This ensures that an LSA that an LSA is flooded to all its neighbors before it is removed from the domain. In IS-IS an LSP purged is kept for ZeroAge lifetime if the LSP purged is a self originated LSP and the LSP is kept for MaxAge if the LSP is non self-originated before the LSP is deleted.
When purging an IS-IS LSP the header and authentication data is kept while purging (certain OSPF implementations do the same). However for those LSP's that don't support authentication, because the checksum is set to 0 for purged LSP's, the integrity of the contents cannot be verified. In OSPF the entire content of the LSA is intact while flushing leading to unnecessary data sending.
Checks on HELLOs for OSPF/IS-IS Adjacency Formation ..
The HELLO protocol is responsible for formation of adjacencies. Forming adjacencies is an integral part of link state routing protocols as all protocol packets other than hellos are flooded only over these adjacencies. The rules for formation of such adjacencies however differ between IS-IS, OSPF v2 and OSPF v3.
IS-IS
Besides the basic checks to verify the integrity of the packet, IS-IS has a few checks to verify before formation of adjacencies when receiving hellos.
- The IS-IS protocol allows multiple area-address to be configured on a router. During the hello exchange the adjacency is formed only if atleast one of the area address matches. The advantage of having multiple areas is explained in the further posts. NOTE that Level 2 only adjacencies would be formed even if the area addresses are not matching.
- Besides to prevent the LSP's and CSNP's being dropped due to different values for originatingLSPBufferSize and ReceiveLSPBufferSize, all HELLOs are padded till the adjacency comes up again. This check verifies consistent settings between the adjacent routers. This is however not a sufficient check.
- Adjacencies are formed without regard to interface addressing or asymmetric in HOLD timer values. Values of HELLO interval are not sent in HELLO packets. While the IS-IS protocol provides sufficient routing information for relaying packets between adjacent routers, many implementations nonetheless require ARP support to do this. These implementations typically refuse to form an adjacency unless the neighbour interface IP address is on the local interface's IP subnet.
- IS-IS can carry addressing information of different protocols in TLV's. However, the protocol supported field must be sent in Dual and IP-Only routers. RFC1195 specifies no checks for the protocol supported field for adjacency formation. It places topology restrictions on multi-protocol networks. In networks that conform to these restrictions, neighboring routers will always have a protocol in common. Therefore, it does not state whether adjacency formation should take protocols supported into account. Many implementations however, do not form an adjacency with a neighbor unless they have at least one protocol in common.
- Not matching hold timer values has advantages wherein the administrator can set different hold times for different routers. This helps in cases where the going down of a DIS or some router needs to be detected faster. For such routers the hold timer can be set to a lower value.
OSPFv2
The checks for formation of adjacencies are stricter in OSPFv2 than IS-IS.
- The area-id of the received packet should always match the incoming interface (with the exception of virtual links). Area type is strictly checked by checking the E-bit (not set for non-default areas) and the N- bit (not-set for non-NSSA areas).
- The values of the HELLO interval, the Router Dead Interval and network mask received in HELLOs are matched with those on the configured interface. Any mismatch in the values causes the HELLO packet to be dropped and hence prevents formation of adjacencies. The disadvantages of this approach is that Hello Interval and Router Dead Interval changes need to be done within the Router Dead Interval, to prevent breaking adjacencies. The advantage is we would not form adjacency in case there is a router that has been mis-configured with a large value and which could cause problems later. The network mask check however does not apply to point to point links. That allows the two ends of a Point-to-Point link to have different addresses.
- MTU check is not done in the hellos. It is done in the during the DB Exchange process.
OSPFv3
Most of the checks for OSPFv3 are similar to that of OSPFv2.
- OSPFv3 runs on a per link basis instead of a per subnet basis. The check for network mask is not done.
- Instance ID field (non-existent in OSPFv2) on the link is matched with the incoming ID in Hellos. The adjacency is formed only if the Instance-ID matches. This allows multiple instances of OSPF to run on a single link.
IS-IS
Besides the basic checks to verify the integrity of the packet, IS-IS has a few checks to verify before formation of adjacencies when receiving hellos.
- The IS-IS protocol allows multiple area-address to be configured on a router. During the hello exchange the adjacency is formed only if atleast one of the area address matches. The advantage of having multiple areas is explained in the further posts. NOTE that Level 2 only adjacencies would be formed even if the area addresses are not matching.
- Besides to prevent the LSP's and CSNP's being dropped due to different values for originatingLSPBufferSize and ReceiveLSPBufferSize, all HELLOs are padded till the adjacency comes up again. This check verifies consistent settings between the adjacent routers. This is however not a sufficient check.
- Adjacencies are formed without regard to interface addressing or asymmetric in HOLD timer values. Values of HELLO interval are not sent in HELLO packets. While the IS-IS protocol provides sufficient routing information for relaying packets between adjacent routers, many implementations nonetheless require ARP support to do this. These implementations typically refuse to form an adjacency unless the neighbour interface IP address is on the local interface's IP subnet.
- IS-IS can carry addressing information of different protocols in TLV's. However, the protocol supported field must be sent in Dual and IP-Only routers. RFC1195 specifies no checks for the protocol supported field for adjacency formation. It places topology restrictions on multi-protocol networks. In networks that conform to these restrictions, neighboring routers will always have a protocol in common. Therefore, it does not state whether adjacency formation should take protocols supported into account. Many implementations however, do not form an adjacency with a neighbor unless they have at least one protocol in common.
- Not matching hold timer values has advantages wherein the administrator can set different hold times for different routers. This helps in cases where the going down of a DIS or some router needs to be detected faster. For such routers the hold timer can be set to a lower value.
OSPFv2
The checks for formation of adjacencies are stricter in OSPFv2 than IS-IS.
- The area-id of the received packet should always match the incoming interface (with the exception of virtual links). Area type is strictly checked by checking the E-bit (not set for non-default areas) and the N- bit (not-set for non-NSSA areas).
- The values of the HELLO interval, the Router Dead Interval and network mask received in HELLOs are matched with those on the configured interface. Any mismatch in the values causes the HELLO packet to be dropped and hence prevents formation of adjacencies. The disadvantages of this approach is that Hello Interval and Router Dead Interval changes need to be done within the Router Dead Interval, to prevent breaking adjacencies. The advantage is we would not form adjacency in case there is a router that has been mis-configured with a large value and which could cause problems later. The network mask check however does not apply to point to point links. That allows the two ends of a Point-to-Point link to have different addresses.
- MTU check is not done in the hellos. It is done in the during the DB Exchange process.
OSPFv3
Most of the checks for OSPFv3 are similar to that of OSPFv2.
- OSPFv3 runs on a per link basis instead of a per subnet basis. The check for network mask is not done.
- Instance ID field (non-existent in OSPFv2) on the link is matched with the incoming ID in Hellos. The adjacency is formed only if the Instance-ID matches. This allows multiple instances of OSPF to run on a single link.
Areas and Hierarchy in OSPF and IS-IS ..
This is required primarily for scalability issues wherein instabilities inside one small section of the network are hidden from the rest of the network. This also helps in reducing the size of the routing tables, etc. Both the protocols establish a two level hierarchy among the areas.
IS-IS
- Divides the whole routing domain into small areas and uses logical hierarchy based on routing levels called Level 1 and Level 2.
- Level 1 routing is within the area and L2 is between the areas.
- Original spec called for Level 1 routers to know only the topology inside their area and they were unaware of routers/destinations outside of their area. They simply forward all their traffic for outside their area to the nearest Level 2 router.
- Level 2 routers knew only the Level 2 topology and didn't know any topology inside the area. This forced strict hierarchal routing between the areas where all inter-area data traffic originating from one area followed a default route to the Level 2 sub-domain, where it was forwarded by L2 routing to the destination area.
- This has now changed and RFC 2966 allows leaking L2 information inside L1 for more optimal routing.
- There was some work done in IS-IS for multi-level hierarchies but it wasn't all that useful and was dropped in between. The idea was that if the networks use IDRP as well along with IS-IS then the 2 levels may not be enough.
- IS-IS routers are associated with a single area and the whole router then belongs to that particular area.
- Area boundaries intersect on links .
- can be extended to support higher levels of hierarchy based on the way routes are leaked in between the levels by setting the up/down bit, when routes are propagated down the hierarchy.
OSPF
- Divides the routing domain into regular areas and a backbone area that is designated as area 0.0.0.0 and all packets going from one area to the other must traverse through this backbone.
- The spec calls for the backbone to be contiguous and to be connected to all the areas through an ABR. There is however a provision to work with disconnected physically disparate backbone areas using virtual links
- Can be attached to multiple areas as its designed around links and uses a links based addressing scheme. It's the links which are assigned to the areas and not the routers themselves.
- Areas intersect on routers.
IS-IS
- Divides the whole routing domain into small areas and uses logical hierarchy based on routing levels called Level 1 and Level 2.
- Level 1 routing is within the area and L2 is between the areas.
- Original spec called for Level 1 routers to know only the topology inside their area and they were unaware of routers/destinations outside of their area. They simply forward all their traffic for outside their area to the nearest Level 2 router.
- Level 2 routers knew only the Level 2 topology and didn't know any topology inside the area. This forced strict hierarchal routing between the areas where all inter-area data traffic originating from one area followed a default route to the Level 2 sub-domain, where it was forwarded by L2 routing to the destination area.
- This has now changed and RFC 2966 allows leaking L2 information inside L1 for more optimal routing.
- There was some work done in IS-IS for multi-level hierarchies but it wasn't all that useful and was dropped in between. The idea was that if the networks use IDRP as well along with IS-IS then the 2 levels may not be enough.
- IS-IS routers are associated with a single area and the whole router then belongs to that particular area.
- Area boundaries intersect on links .
- can be extended to support higher levels of hierarchy based on the way routes are leaked in between the levels by setting the up/down bit, when routes are propagated down the hierarchy.
OSPF
- Divides the routing domain into regular areas and a backbone area that is designated as area 0.0.0.0 and all packets going from one area to the other must traverse through this backbone.
- The spec calls for the backbone to be contiguous and to be connected to all the areas through an ABR. There is however a provision to work with disconnected physically disparate backbone areas using virtual links
- Can be attached to multiple areas as its designed around links and uses a links based addressing scheme. It's the links which are assigned to the areas and not the routers themselves.
- Areas intersect on routers.
Designated Router (or DIS) Concepts ..
The DR concept is used by both IS-IS and OSPF on the broadcast media to limit the amount of link state information exchanged between the routers on such media. It helps to reduce the number of adjacencies formed on broadcast media to O(n) instead of O(n^2), where n is the number of nodes.
First things first. There are no routers in IS-IS; there are only Intermediate Systems. So the leader and the evangelist for a LAN in IS-IS is called a DIS - Designated Intermediate System.
IS-IS
- DIS election is deterministic.
- No concept of backup DIS.
- A new DIS is elected when the current goes down.
OSPF
- DR election is non-deterministic.
- Elects DR and BDR to conduct flooding on a LAN.
- All routers on the LAN are only synchronized with the DR and BDR.
- DRship is sticky.
(i) What is meant by a deterministic/non-deterministic election?
In IS-IS, deterministic DIS election makes the possibility of predicting the router that will be elected as DIS from the same set of routers. The router advertising the numerically highest priority wins, with numerically highest MAC address breaking the tie. In IS-IS, DIS can be pre-empted at any time by a different IS-IS node (or a router in plain-speak) with higher priority coming alive.
In OSPF, the DR election is sticky meaning that after a router has been elected, no other router can take over the position unless the original DR goes down. When a router comes up, it accepts the DR regardless of its own priority if a DR is already there. Otherwise the router itself becomes DR if it has the highest priority on the network (a LAN to be precise).
The above scheme makes it harder to predict the identity of the DR, but ensures that DR changes less often. The rationale behind this sticky nature of DRship in OSPF is that it is disruptive to have DR changes as DR keeps track of which routers have acknowledged which link state information and it would require a lot of time and protocol messages for another router to take over in case the DR went down.
Both the sticky and deterministic mechanisms of DR/DIS elections in OSPF and IS-IS can be modified to provide the functionality of the other with some simple modifications in the implementations.
(ii) Do we need a backup Designated router or an Intermediate System?
A backup DIS is redundant in IS-IS because all the routers are synchronized with each other and also because the shorter Hello interval used by the DIS allows for faster detection of failures and subsequent replacement of the DIS.
The presence of BDR in OSPF makes the replacement of the DR transparent in case the DR goes down. All routers on the LAN are only adjacent and synchronized with DR and BDR; and backup DR is fully synchronized with the DR. Forming adjacencies with only the DR/BDR is done to reduce the complexity of data exchange and minimize flooding.
First things first. There are no routers in IS-IS; there are only Intermediate Systems. So the leader and the evangelist for a LAN in IS-IS is called a DIS - Designated Intermediate System.
IS-IS
- DIS election is deterministic.
- No concept of backup DIS.
- A new DIS is elected when the current goes down.
OSPF
- DR election is non-deterministic.
- Elects DR and BDR to conduct flooding on a LAN.
- All routers on the LAN are only synchronized with the DR and BDR.
- DRship is sticky.
(i) What is meant by a deterministic/non-deterministic election?
In IS-IS, deterministic DIS election makes the possibility of predicting the router that will be elected as DIS from the same set of routers. The router advertising the numerically highest priority wins, with numerically highest MAC address breaking the tie. In IS-IS, DIS can be pre-empted at any time by a different IS-IS node (or a router in plain-speak) with higher priority coming alive.
In OSPF, the DR election is sticky meaning that after a router has been elected, no other router can take over the position unless the original DR goes down. When a router comes up, it accepts the DR regardless of its own priority if a DR is already there. Otherwise the router itself becomes DR if it has the highest priority on the network (a LAN to be precise).
The above scheme makes it harder to predict the identity of the DR, but ensures that DR changes less often. The rationale behind this sticky nature of DRship in OSPF is that it is disruptive to have DR changes as DR keeps track of which routers have acknowledged which link state information and it would require a lot of time and protocol messages for another router to take over in case the DR went down.
Both the sticky and deterministic mechanisms of DR/DIS elections in OSPF and IS-IS can be modified to provide the functionality of the other with some simple modifications in the implementations.
(ii) Do we need a backup Designated router or an Intermediate System?
A backup DIS is redundant in IS-IS because all the routers are synchronized with each other and also because the shorter Hello interval used by the DIS allows for faster detection of failures and subsequent replacement of the DIS.
The presence of BDR in OSPF makes the replacement of the DR transparent in case the DR goes down. All routers on the LAN are only adjacent and synchronized with DR and BDR; and backup DR is fully synchronized with the DR. Forming adjacencies with only the DR/BDR is done to reduce the complexity of data exchange and minimize flooding.
Difference in IS-IS and OSPF packet encapsulation ..
IS-IS is cool and runs directly over the data link alongside IP. On Ethernet, IS-IS packets are always 802.3 frames, with LSAP value 0xFEFE while IP packets are either Ethernet II frames or SNAP frames identified with the protocol number 0x800. OSPF runs over IP as protocol number 89.
IS-IS runs directly over layer 2 and hence
- cannot support virtual links unless some explicit tunneling is implemented.
- packets are intentionally kept small so that they don't require hop-by-hop fragmentation.
- uses ATM/SNAP encapsulation on ATM but there are hacks to make it use VcMux encapsulation.
- some OSs that support IP networking have been implemented to differentiate Layer 3 packets in kernel. Such OSs require a lot of kernel modifications to support IS-IS for IP routing. Ditto goes for any HW thats clever and tries to identify L3 control packets in the ASICs.
- can never be routed beyond the immediate next hop and hence shielded from IP spoofing and similar Denial of Service attacks.
- need to provide code points of access for each data link protocol types (Frame Relay, Ethernet, ATM, PPP, etc).
- doesnt need to rely on network layer protocols (like ARP) to communicate with the neighboring systems. Some implementations however, do rely on ARP or static routing to
communicate with the neighbors on LAN.
OSPF runs over IP and hence
- can support virtual links.
- can use IP fragmentation services.
- can use VcMux encapsulation on ATM.
- if an OS already supports IP, no it requires no changes to support OSPF.
- can be routed to a destination multiple hops away and thus vulnerable to DoS attacks and IP spoofing
- transmitted with additional IP header information, thereby increasing some packet overhead. I woudnt fret over this coz there arent many control packets running helter-skelter in a network anyways!
(i) IP Fragmentation
LSPs in IS-IS, unlike as in OSPF, are not regenerated hop-by-hop and so they must be small enough that they are guaranteed to be able to cross *any* media in the network and the value of the maxsized LSP should thus not be greater than the minimum link MTU size in the area.
If a router has more than maxsized LSP bytes of information to advertise into IS-IS, then this originating router must fragment its LSP before flooding.
In past, one area of concern regarding the scalability of the link state routing protocols was the way they would flood and it is believed that preventing fragmentation during flooding is the reason why IS-IS fragments only at the originating router.
OSPF does not provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly is used. OSPF protocol packets have been designed so that large protocol packets can be generally be split into several smaller protocol packets.
(ii) ATM Encapsulation
OSPF can run over ATM using VcMux encapsulation (which essentially assumes that all the packets carried are IP) while IS-IS requires LLC/SNAP encapsulation where ATM layer can distinguish between multiple Layer 3 protocols over the same VC. The disadvantage of using the LLC/SNAP encapsulation is that it has some additional bytes for the LLC-SNAP header which results in a packet size > 40 bytes.
Thus a simple TCP ACK message of 40 bytes along with the LLC-SNAP header adds enough bytes so that a single TCP ACK won't fit into one ATM cell. Much bandwidth is thus wasted because now each TCP ACK requires 2 ATM cells.
An IETF draft proposes a workaround to this issue in which both IS-IS and IP packets can be sent over an ATM VC using Vc Mux encapsulation by reading into the first byte of the L3 header to distinguish between IP and ISO family packets, such as IS-IS, CLNS and ES-IS. However this did not gain popularity because of the demise of ATM cores in the largest ISPs.
The first two fields in the IP header are the 4-bit version number and the 4-bit header length. The value of the first byte is normally 0x45. If there are IP header options attached to the IP header, the first byte can be between 0x46 and 0x4F. The first byte in an IS-IS packet is always 0x83. Thus by looking at the first byte of an incoming packet, the receiver can separate IP and IS-IS packets. Because of this feature one does not need to depend on the ATM layer anymore to help with the de-multiplexing. Routers an now send and receive both IS-IS and IP packets using Vc Mux encapsulation and thus avoid the ATM cell tax.
IS-IS runs directly over layer 2 and hence
- cannot support virtual links unless some explicit tunneling is implemented.
- packets are intentionally kept small so that they don't require hop-by-hop fragmentation.
- uses ATM/SNAP encapsulation on ATM but there are hacks to make it use VcMux encapsulation.
- some OSs that support IP networking have been implemented to differentiate Layer 3 packets in kernel. Such OSs require a lot of kernel modifications to support IS-IS for IP routing. Ditto goes for any HW thats clever and tries to identify L3 control packets in the ASICs.
- can never be routed beyond the immediate next hop and hence shielded from IP spoofing and similar Denial of Service attacks.
- need to provide code points of access for each data link protocol types (Frame Relay, Ethernet, ATM, PPP, etc).
- doesnt need to rely on network layer protocols (like ARP) to communicate with the neighboring systems. Some implementations however, do rely on ARP or static routing to
communicate with the neighbors on LAN.
OSPF runs over IP and hence
- can support virtual links.
- can use IP fragmentation services.
- can use VcMux encapsulation on ATM.
- if an OS already supports IP, no it requires no changes to support OSPF.
- can be routed to a destination multiple hops away and thus vulnerable to DoS attacks and IP spoofing
- transmitted with additional IP header information, thereby increasing some packet overhead. I woudnt fret over this coz there arent many control packets running helter-skelter in a network anyways!
(i) IP Fragmentation
LSPs in IS-IS, unlike as in OSPF, are not regenerated hop-by-hop and so they must be small enough that they are guaranteed to be able to cross *any* media in the network and the value of the maxsized LSP should thus not be greater than the minimum link MTU size in the area.
If a router has more than maxsized LSP bytes of information to advertise into IS-IS, then this originating router must fragment its LSP before flooding.
In past, one area of concern regarding the scalability of the link state routing protocols was the way they would flood and it is believed that preventing fragmentation during flooding is the reason why IS-IS fragments only at the originating router.
OSPF does not provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly is used. OSPF protocol packets have been designed so that large protocol packets can be generally be split into several smaller protocol packets.
(ii) ATM Encapsulation
OSPF can run over ATM using VcMux encapsulation (which essentially assumes that all the packets carried are IP) while IS-IS requires LLC/SNAP encapsulation where ATM layer can distinguish between multiple Layer 3 protocols over the same VC. The disadvantage of using the LLC/SNAP encapsulation is that it has some additional bytes for the LLC-SNAP header which results in a packet size > 40 bytes.
Thus a simple TCP ACK message of 40 bytes along with the LLC-SNAP header adds enough bytes so that a single TCP ACK won't fit into one ATM cell. Much bandwidth is thus wasted because now each TCP ACK requires 2 ATM cells.
An IETF draft proposes a workaround to this issue in which both IS-IS and IP packets can be sent over an ATM VC using Vc Mux encapsulation by reading into the first byte of the L3 header to distinguish between IP and ISO family packets, such as IS-IS, CLNS and ES-IS. However this did not gain popularity because of the demise of ATM cores in the largest ISPs.
The first two fields in the IP header are the 4-bit version number and the 4-bit header length. The value of the first byte is normally 0x45. If there are IP header options attached to the IP header, the first byte can be between 0x46 and 0x4F. The first byte in an IS-IS packet is always 0x83. Thus by looking at the first byte of an incoming packet, the receiver can separate IP and IS-IS packets. Because of this feature one does not need to depend on the ATM layer anymore to help with the de-multiplexing. Routers an now send and receive both IS-IS and IP packets using Vc Mux encapsulation and thus avoid the ATM cell tax.
IS-IS and OSPF Interface Types Supported ..
OSPF models networks as
- Broadcast links
- Point to Point (P2P)
- Point to Multi-Point (P2MP)
- Non-Broadcast multi-access Networks (NBMA)
IS-IS models networks as
- P2P
- Broadcast
- Unnumbered Broadcast
The key differences are the way OSPF provides support for NBMA networks and inherent protocol support for unnumbered broadcast by IS-IS
(i) Support for NBMA Networks
IS-IS has no direct support for connecting ISs over a NBMA network and it must be modeled as a LAN or treated as a set of P2P links. Modeling it as the latter involves a lot of configuration and if full connectivity is not configured, multiple hops might be required for traversing the NBMA cloud.
Experience with ATM LAN emulation has proven un-scalable and insufficiently reliable because of the single point where replication takes place to emulate multicast.
The best alternative for IS-IS is thus to treat each PVC as a point-to-point link. All PVC failures are handled by the protocol since each PVC is visible to the protocol.
IS-IS mesh groups may be used to address the scaling issues which may result from redundant flooding in the highly meshed environments.
In OSPF there is a "NBMA mode" in the original specification which makes the protocol aware that it is on a NBMA network.
Neighbours are discovered initially through configuration which is restricted to the ones eligible for the DR election. To make administration easier and to reduce the HELLO traffic, most of the other routers attached to the NBMA subnet are assigned a router priority of zero. It thus involves quite a bit of administration overhead and is prone to mis-configuration. Also the network will malfunction if one of the nodes loses its link to the DR.
In this mode, each node in the NBMA must have a PVC to the DR and BDR. Since adjacencies between non-DR nodes is not mandated, the order of the number of adjacencies is O(2n), rather than O(n^2) as required when running OSPF without NBMA mode.
NBMA networks are thus only as robust and reliable as the underlying data-link service. If for example, a PVC fails or is mis-configured or if an SVC cannot be established, due to capacity or policy reasons, routing over NBMA subnet will fail. And, unfortunately, often the reason for the failure will not be immediately obvious to the network operator.
The P2MP can be applied to rectify these problems, although at some loss of efficiency.
(ii) Point-to-Multipoint model
This model can be used on any data link technology that the NBMA model can be used on. In addition, the P2MP model doesn't require all the participating routers to be able to communicate directly to model a partial PVC mesh as a single P2MP networks. Dropping the full mesh requirement also allows the modeling of more exotic data link technologies, such as packet radio, as P2MP networks.
So if your favorite OS can't support virtual interfaces or if there's too much overhead involved in generating separate sub interfaces to each of the 500 ATM circuits then P2MP is good and can be your life saver!
However, when operating a full mesh Frame Relay or ATM network in P2MP mode, the work involved in neighbor maintenance, flooding, and database representation increases as O(n^2), where n is the number of OSPF routers attached to the subnet, instead of O(n)behavior that can be achieved with the original NBMA model.
(iii) Unnumbered broadcast
IS-IS supports unnumbered broadcast interfaces; however, most implementations do not! The protocol provides all necessary routing information without the aid of ARP, but doing this requires that each FIB entry contain a next-hop (circuit, SNAP address) pair for each path to a destination, and many routers are designed with FIB entries that contain only next-hop IP addresses instead, to reduce the size of the FIB and perhaps as a simplification.
For this reason, many implementations won't interoperate with an unnumbered broadcast interface, and won't interoperate with an implementation that doesn't support ARP.
- Broadcast links
- Point to Point (P2P)
- Point to Multi-Point (P2MP)
- Non-Broadcast multi-access Networks (NBMA)
IS-IS models networks as
- P2P
- Broadcast
- Unnumbered Broadcast
The key differences are the way OSPF provides support for NBMA networks and inherent protocol support for unnumbered broadcast by IS-IS
(i) Support for NBMA Networks
IS-IS has no direct support for connecting ISs over a NBMA network and it must be modeled as a LAN or treated as a set of P2P links. Modeling it as the latter involves a lot of configuration and if full connectivity is not configured, multiple hops might be required for traversing the NBMA cloud.
Experience with ATM LAN emulation has proven un-scalable and insufficiently reliable because of the single point where replication takes place to emulate multicast.
The best alternative for IS-IS is thus to treat each PVC as a point-to-point link. All PVC failures are handled by the protocol since each PVC is visible to the protocol.
IS-IS mesh groups may be used to address the scaling issues which may result from redundant flooding in the highly meshed environments.
In OSPF there is a "NBMA mode" in the original specification which makes the protocol aware that it is on a NBMA network.
Neighbours are discovered initially through configuration which is restricted to the ones eligible for the DR election. To make administration easier and to reduce the HELLO traffic, most of the other routers attached to the NBMA subnet are assigned a router priority of zero. It thus involves quite a bit of administration overhead and is prone to mis-configuration. Also the network will malfunction if one of the nodes loses its link to the DR.
In this mode, each node in the NBMA must have a PVC to the DR and BDR. Since adjacencies between non-DR nodes is not mandated, the order of the number of adjacencies is O(2n), rather than O(n^2) as required when running OSPF without NBMA mode.
NBMA networks are thus only as robust and reliable as the underlying data-link service. If for example, a PVC fails or is mis-configured or if an SVC cannot be established, due to capacity or policy reasons, routing over NBMA subnet will fail. And, unfortunately, often the reason for the failure will not be immediately obvious to the network operator.
The P2MP can be applied to rectify these problems, although at some loss of efficiency.
(ii) Point-to-Multipoint model
This model can be used on any data link technology that the NBMA model can be used on. In addition, the P2MP model doesn't require all the participating routers to be able to communicate directly to model a partial PVC mesh as a single P2MP networks. Dropping the full mesh requirement also allows the modeling of more exotic data link technologies, such as packet radio, as P2MP networks.
So if your favorite OS can't support virtual interfaces or if there's too much overhead involved in generating separate sub interfaces to each of the 500 ATM circuits then P2MP is good and can be your life saver!
However, when operating a full mesh Frame Relay or ATM network in P2MP mode, the work involved in neighbor maintenance, flooding, and database representation increases as O(n^2), where n is the number of OSPF routers attached to the subnet, instead of O(n)behavior that can be achieved with the original NBMA model.
(iii) Unnumbered broadcast
IS-IS supports unnumbered broadcast interfaces; however, most implementations do not! The protocol provides all necessary routing information without the aid of ARP, but doing this requires that each FIB entry contain a next-hop (circuit, SNAP address) pair for each path to a destination, and many routers are designed with FIB entries that contain only next-hop IP addresses instead, to reduce the size of the FIB and perhaps as a simplification.
For this reason, many implementations won't interoperate with an unnumbered broadcast interface, and won't interoperate with an implementation that doesn't support ARP.
Genesis ..
Both Integrated IS-IS and OSPF were specified in the latter part of the 1980s
In 1987 OSI adopted DECnet Phase V's routing algorithm with some modifications and named it IS-IS. Around 1988, the NSFnet deployed an IGP loosely based on an early draft of IS-IS. Around the same time, development on OSPF started which took most of the basic concepts from this early version of IS-IS but was designed to support only IPv4. In October 1989 the version 1 of OSPF was released as RFC 1131 and around the same time in December 1990, Integrated IS-IS was released and published as RFC 1195.
Version 2 of OSPF was first published in July 1991 as RFC 1247 and CISCO started shipping it. It released its implementation for Dual IS-IS in 1992. Till now numerous ISPs had deployed OSPF and very few IS-IS. In 1994 there were significant improvements done to CISCO's IOS implementation for in conjunction with support for Network Link Service Protocol (Novell's IPX protocol).
These enhancements improved the performance, resilience and robustness of CISCO's implementation which made a lot of ISPs to shift to IS-IS.
By 1995 most of the major ISPs had started deploying IS-IS. What helped this further was US government's interest in ISO CLNS suite, which was reflected in a requirement for CLNP routing support in the NSFnet project by the NSF. Interest in Dual IS-IS continued to grow, and most ISPs that sprung up in Europe chose to deploy ISO standards based on IS-IS instead of OSPF.
Unlike IS-IS which started as an ISO protocol, OSPF was inherently designed to support only IPv4 and was promoted by IETF as the referred IGP for IP networks. Additionally, because IS-IS support was not available on some major routers (noticeably Bay and 3com routers), OSPF automatically became the standard de-facto IGP for the reasonably large sized networks with multi-vendor platforms. An active IETF WG and evolving specifications also went a long way to help promote OSPF; and thus it started becoming more popular and more widely adopted compared to IS-IS.
There has been no major standardization effort in the ITU for a while, so ISO 10589 and RFC 1195 still remain the authoritative complete standards for IS-IS. The IETF IS-IS WG has been opened recently which is now working on standardizing newer applications like MPLS, Traffic Engineering, IPv6, etc for IS-IS.
To summarize, both the protocols have prevailed through the test of time and have established themselves as the IGPs of choice for ISPs. New extensions such as, MPLS TE, IPv6, have been deployed over the past 3 years, and with active working groups for either protocol in IETF, they continue to evolve in lock-step fashion.
In 1987 OSI adopted DECnet Phase V's routing algorithm with some modifications and named it IS-IS. Around 1988, the NSFnet deployed an IGP loosely based on an early draft of IS-IS. Around the same time, development on OSPF started which took most of the basic concepts from this early version of IS-IS but was designed to support only IPv4. In October 1989 the version 1 of OSPF was released as RFC 1131 and around the same time in December 1990, Integrated IS-IS was released and published as RFC 1195.
Version 2 of OSPF was first published in July 1991 as RFC 1247 and CISCO started shipping it. It released its implementation for Dual IS-IS in 1992. Till now numerous ISPs had deployed OSPF and very few IS-IS. In 1994 there were significant improvements done to CISCO's IOS implementation for in conjunction with support for Network Link Service Protocol (Novell's IPX protocol).
These enhancements improved the performance, resilience and robustness of CISCO's implementation which made a lot of ISPs to shift to IS-IS.
By 1995 most of the major ISPs had started deploying IS-IS. What helped this further was US government's interest in ISO CLNS suite, which was reflected in a requirement for CLNP routing support in the NSFnet project by the NSF. Interest in Dual IS-IS continued to grow, and most ISPs that sprung up in Europe chose to deploy ISO standards based on IS-IS instead of OSPF.
Unlike IS-IS which started as an ISO protocol, OSPF was inherently designed to support only IPv4 and was promoted by IETF as the referred IGP for IP networks. Additionally, because IS-IS support was not available on some major routers (noticeably Bay and 3com routers), OSPF automatically became the standard de-facto IGP for the reasonably large sized networks with multi-vendor platforms. An active IETF WG and evolving specifications also went a long way to help promote OSPF; and thus it started becoming more popular and more widely adopted compared to IS-IS.
There has been no major standardization effort in the ITU for a while, so ISO 10589 and RFC 1195 still remain the authoritative complete standards for IS-IS. The IETF IS-IS WG has been opened recently which is now working on standardizing newer applications like MPLS, Traffic Engineering, IPv6, etc for IS-IS.
To summarize, both the protocols have prevailed through the test of time and have established themselves as the IGPs of choice for ISPs. New extensions such as, MPLS TE, IPv6, have been deployed over the past 3 years, and with active working groups for either protocol in IETF, they continue to evolve in lock-step fashion.
IS-IS and OSPF .. What the heck?
The increasing popularity of IS-IS and OSPF over the years has drawn significant attention to the relative merits and demerits of one with respect to the other. The blog entries that follow would present an elaborate comparision between the two routing protocols to explain how the features and functionalities of one differs from the other.
Since both these routing protocols originated in different standard bodies, IS-IS in ISO and OSPF in the IETF, there exists some difference in the terminologies used.
IS-IS - OSPF
End System - Host
Intermediate System - Router
Circuit - An adjacency on one link
SNPA Address - Data link Address
Protocol Data Unit (PDU) - Packet
Designated Intermediate System (DIS) - Designated Router (DR)
IS to IS Hello PDU (IIH) - Hello Packet
Not Applicable - Backup Designated Router (BDR)
Link State Packet(LSP) - Link State Advertisement (LSA)
Link State Packet - Link State Update
Complete Sequence Number Packet(CSNP) - Database Description packet
Partial Sequence Number Packet(PSNP) - Link state ACK or Request Packet
Routing Domain - AS
Level 2 Subdomain - Backbone Area
Level 1 Area - Non Backbone Area
Level 1/2 IIH PDU - Simple Hello Packet
Level 1/2 LSP - No Distinction
L1L2 router - ABR System ID - Router ID
Link State Packet ID(LSPID) - Link State ID
Pseudonode LSP - Network LSA
Router LSAs, Summary LSAs, Network LSAs, ASBR Summaries, AS-external LSAs are equivalent of TLVs carried in LSPs in IS-IS. The difference is that each LSA has its own header whereas the TLVs share a common header.
IS-IS Terms with no OSPF equivalent:
TLV - Type-Length-Value tuple. These carry most of the information in IS-IS PDUs.
OSPF Terms with no IS-IS equivalent:
Advertising Router - Router that originated the advertisement. In IS-IS, this is the LSP's originator.
Backup Designated Router - Router which takes over in case the DR goes down. In IS-IS, there is no Backup DIS and the DIS election takes place again in case the former goes down or is no more available.
Since both these routing protocols originated in different standard bodies, IS-IS in ISO and OSPF in the IETF, there exists some difference in the terminologies used.
IS-IS - OSPF
End System - Host
Intermediate System - Router
Circuit - An adjacency on one link
SNPA Address - Data link Address
Protocol Data Unit (PDU) - Packet
Designated Intermediate System (DIS) - Designated Router (DR)
IS to IS Hello PDU (IIH) - Hello Packet
Not Applicable - Backup Designated Router (BDR)
Link State Packet(LSP) - Link State Advertisement (LSA)
Link State Packet - Link State Update
Complete Sequence Number Packet(CSNP) - Database Description packet
Partial Sequence Number Packet(PSNP) - Link state ACK or Request Packet
Routing Domain - AS
Level 2 Subdomain - Backbone Area
Level 1 Area - Non Backbone Area
Level 1/2 IIH PDU - Simple Hello Packet
Level 1/2 LSP - No Distinction
L1L2 router - ABR System ID - Router ID
Link State Packet ID(LSPID) - Link State ID
Pseudonode LSP - Network LSA
Router LSAs, Summary LSAs, Network LSAs, ASBR Summaries, AS-external LSAs are equivalent of TLVs carried in LSPs in IS-IS. The difference is that each LSA has its own header whereas the TLVs share a common header.
IS-IS Terms with no OSPF equivalent:
TLV - Type-Length-Value tuple. These carry most of the information in IS-IS PDUs.
OSPF Terms with no IS-IS equivalent:
Advertising Router - Router that originated the advertisement. In IS-IS, this is the LSP's originator.
Backup Designated Router - Router which takes over in case the DR goes down. In IS-IS, there is no Backup DIS and the DIS election takes place again in case the former goes down or is no more available.
Subscribe to:
Comments (Atom)
