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 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)
