Internet DRAFT - draft-bhatia-manral-diff-isis-ospf


Network Working Group                                      Manav Bhatia 
Internet Draft                                      Riverstone Networks 
Expires: January 2006                                    Vishwas Manral 
Informational                                              SiNett Corp. 
                                                         Yasuhiro Ohara 
                                                        Keio University 
                   IS-IS and OSPF Difference Discussions 
Status of this Memo 
   By submitting this Internet-Draft, each author represents that any    
   applicable patent or other IPR claims of which he or she is aware   
   have been or will be disclosed, and any of which he or she becomes   
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-Drafts. 
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
   The list of current Internet-Drafts can be accessed at 
   The list of Internet-Draft Shadow Directories can be accessed at 
Copyright Notice 
   Copyright (C) The Internet Society (2005). 
   The increasing popularity of IS-IS [IS-IS] and OSPF [OSPF] over    
   the years has drawn significant attention to the relative merits and 
   de-merits of one with respect to the other. This draft presents an 
   elaborate comparison between the two routing protocols to explain how 
   the features and functionalities of one differs from the other. 
   Wherever applicable the differences between OSPFv2 and OSPFv3[OSPFv3] 
   have also been pointed out. 
Conventions used in this document 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
Bhatia, Manral and Ohara    Informational                    [Page 1] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   document are to be interpreted as described in RFC 2119 [KEYWORDS] 
Table of Contents 
   1. Terminologies..................................................3 
   2. Acknowledgements...............................................4 
   3. Evolution of the protocols.....................................4 
   4. Interface Types Supported......................................5 
      4.1 Support for NBMA Networks..................................5 
      4.2 Point-to-Multipoint model..................................6 
      4.3 Unnumbered broadcast.......................................7 
   5. Encapsulation..................................................7 
      5.1 IP Fragmentation...........................................8 
      5.2 ATM Encapsulation..........................................8 
   6. Designated Router (DR) concept.................................9 
      6.1 DR election deterministic/non-deterministic................9 
      6.2 Backup Designated Router/Intermediate System..............10 
   7. Areas/Hierarchy...............................................10 
   8. Checks on Hellos for adjacency formation......................12 
   9. Database Exchange and Flooding................................13 
      9.1 Initial Database Exchange.................................14 
      9.2 Asynchronous Flooding.....................................15 
   10. Flushing LSA/LSP.............................................16 
   11. SPF Calculation..............................................16 
   12. Area Types...................................................17 
      12.1 Area Partitions..........................................17 
      12.2 Level 2 Partitions (Backbone Area Connectivity)..........18 
      12.3 Injection of Level 2 Information.........................19 
      12.4 Stub Area................................................20 
      12.5 Not So Stub Area (NSSA)..................................20 
   13. Architectural Values.........................................21 
      13.1 Architectural Constants..................................21 
      13.2 Synchronized Parameter Setting...........................21 
   14. Virtual Links................................................22 
   15. Packet Alignment/Extensibility...............................23 
   16. MTU Limitations..............................................24 
   17. Security/Authentication Issues...............................25 
   18. IS-IS/OSPF for IPv6..........................................26 
   19. Current Deployments..........................................28 
   20. Metrics Size.................................................28 
   21. Database Granularity.........................................29 
   22. Separation of TE and topology information....................32 
   23. Convergence and Scalability Issues...........................33 
   24. Area Id Change Functionality.................................35 
   25. Backward Compatibility.......................................35 
   26. Hitless Restart Mechanisms...................................36 
   27. Demand Circuits..............................................37 
   28. IANA Considerations..........................................38 
   29. References...................................................38 
Bhatia, Manral and Ohara    Informational                    [Page 2] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   30. Author's Addresses...........................................40 
   31. Appendix.....................................................41 
   32. Intellectual Property Notice.................................42 
   33. Disclaimer of Validity.......................................42 
   34. Full Copyright Notice........................................43 
   35. Acknowledgment...............................................43 
1. Terminologies 
   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 
   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 
   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:   
Bhatia, Manral and Ohara    Informational                    [Page 3] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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 
   Backbone Area - In IS-IS, L2 routers appear in all areas, but must    
   all be interconnected to form a backbone (the L2 subdomain).. 
2. Acknowledgements 
   This document is a result of the extensive discussions in the diff-
   ospf-isis list and the following people have co-authored and 
   contributed to this draft, either directly or indirectly: 
   Danny McPherson, Jeff Learman, Jonathan Sadler, Radia Perlman, Philip 
   Christian, J.J. Syed, Satish Dattari, Sina Mirtorabi, Nabendu Das, 
   Russ White, Alex Zinin and Venkata Naidu.  
3. Evolution of the protocols  
   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 
Bhatia, Manral and Ohara    Informational                    [Page 4] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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 [MARTEY].   
   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. 
4. 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 
4.1 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 

Bhatia, Manral and Ohara    Informational                    [Page 5] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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 [MESH] 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 
   The P2MP can be applied to rectify these problems, although at some 
   loss of efficiency. 
4.2 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 [Moy].  

Bhatia, Manral and Ohara    Informational                    [Page 6] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   So if an Operating system 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 handy that way.   
   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. 
4.3 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 [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.  
5. Encapsulation  
   IS-IS 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 
   - 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 operating systems 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.   
   - can never be routed beyond the immediate next hop and hence 
   shielded from IP spoofing and similar Denial of Service attacks.   
Bhatia, Manral and Ohara    Informational                    [Page 7] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - need to provide code points of access for each data link protocol 
   types (Frame Relay, Ethernet, ATM, PPP [PPP], etc.)   
   - don't 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 
   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 changes are necessary to support 
   - can be routed to a destination multiple hops away and thus 
   vulnerable to Denial of Service attacks and IP spoofing  
   - transmitted with additional IP header information, thereby 
   increasing some packet overhead  
5.1 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.   
   One area of the concern regarding the scalability of the link state 
   routing protocols is the flooding 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 
5.2 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 
Bhatia, Manral and Ohara    Informational                    [Page 8] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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 (which were also among the few 
   running IS-IS).  
   [*] 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.  [*]  
6. Designated Router (DR) concept  
   The DR concept is used by both IS-IS and OSPF on the broadcast media 
   to limit the amount of LS 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 
   - DR election is deterministic   
   - No concept of backup DIS   
   - A new DIS is elected when the current goes down.   
   - 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  
6.1 DR election deterministic/non-deterministic  
Bhatia, Manral and Ohara    Informational                    [Page 9] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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 router 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. 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 nodes 
   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.  
6.2 Backup Designated Router/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.  
7. Areas/Hierarchy  
   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.  

Bhatia, Manral and Ohara    Informational                   [Page 10] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - 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 forwarded 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 a recent draft in IETF 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.   
   - Divides the routing domain into regular areas and a backbone area 
   that is designated as area 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 [Refer to section 13 for more details]  
   - 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.  
Bhatia, Manral and Ohara    Informational                   [Page 11] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
8. Checks on Hellos for 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. The main points 
   are: -   
   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 given in section 22. However Level 2 only 
   adjacencies can 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 
   - IS-IS can carry addressing information of different protocols inT 
   TLV's. However, the protocol supported field must be sent in 
   Dual[RFC1195] 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 [as described in 
   ITU-T G.7712 and draft-ietf-IS-IS-auto-encap-02.txt.]   
Bhatia, Manral and Ohara    Informational                   [Page 12] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - 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. 
   The checks for formation of adjacencies are stricter in OSPFv2 than 
   - 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 
   - MTU check is not done in the hellos. It is done in the during  the 
   DB Exchange process.   
   Most of the checks for OSPFv3 are similar to that of OSPFv2. The main 
   points of differences are: -   
   - 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.  
9. Database Exchange and Flooding  

Bhatia, Manral and Ohara    Informational                   [Page 13] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
9.1 Initial Database Exchange  
   For the SPF algorithm to work properly, all routers in the area 
   should have the same database information on which the SPF algorithm 
   works. The process of synchronization includes the "Initial Database 
   Exchange" which is done when the adjacency is coming up and the 
   asynchronous flooding when the Adjacencies are up.  
   - A master-slave relation is established to do the database exchange. 
   Besides the MTU is exchanged in the database description packets 
   before any database exchange starts.   
   - The database exchange begins once the adjacency state reaches 
   Exstart. On a broadcast links, the DR and BDR form adjacencies with 
   all other routers on the network.  
   - Only one DB Description packet can be unacknowledged at a time that 
   is, the window size is 1. Each DB Description packet from the master 
   is acknowledged by the slave. The slave sends its own DB Description 
   packet with similar identifiers as the masters.   
   - DB description packets containing the summary of LSA's at each end 
   are exchanged. Only when the entire summary is received by the 
   neighbour can it tell which instance of the LSA is not there in the 
   senders database.   
   - An adjacency in OSPF is declared FULL/UP, when the entire database 
   exchange is completed.   
   - OSPF does not allow routers to resynchronize their link state 
   database in the steady state. It is only done during the initial 
   database synchronization or when network topology changes. However, 
   there are techniques to do that. One such way is described in "OSPF 
   Out-of-band LSDB resynchronization" [OOB]  
   - The MTU check is done at the hello exchange time itself.   
   - CSNP's are sent by the DIS on a broadcast link. On a point-to-point 
   link both the neighbours exchange CSNP's with each other.    
   - On point-to-point link all the LSP's SRM flag is also set for the 
   circuit, to indicate the LSP's have to be sent over the circuit.   
   - The CNSP's are sent to reduce the actual flooding of all the LSP's 
   between the neighbours.   
Bhatia, Manral and Ohara    Informational                   [Page 14] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - Multiple CSNP's can be sent together. CSNP's unlike DB Descriptions 
   in OSPF are not acknowledged.   
   - As the CSNP's have a range of LSP-ID's, and contain all the LSP's 
   in the database falling in that range. A neigbour on receiving a CSNP 
   can know which LSP's in the neighbour are newer, which older and 
   which are absent. Based on this the neighbour can send newer LSP's to 
   the neighbour.   
   - Link state database is continuously refreshed and synchronized 
   because of the periodic CSNPs that are announced.  
9.2 Asynchronous Flooding  
   Whenever any information in an the database changes, the information 
   is to be exchanged with all other routers in the network. This is 
   done by the flooding process: -   
   - Uses reliable flooding mechanism for all link types.    
   - Changed LSA's are packed in LS Update packets and send over 
   adjacencies to the neighbour, which unpacks the LSA's. LS 
   Acknowledgement packets are sent by the receiver, which informs the 
   sender that the receiver has received the LSA.   
   - The sender retransmits the LSA's after the re-transmission interval 
   if it does not get acknowledgements for them.   
   - On a broadcast link LSUpdate packets are sent only to all-DR 
   routers multicast address. The DR floods the LSUpdate packets to All-
   - Whenever a new DR/BDR is elected, it has to form adjacencies with 
   all other routers in the network.   
   - There is no difference in the asynchronous flooding procedures 
   between OSPFv2 and OSPFv3.     
   - LSP's are flooded as is across the area. They are not packed inside 
   any other packet.   
   - On broadcast links flooding is not done reliably. A changed LSP is 
   flooded to all IS-IS routers, however no retransmissions occur.    
Bhatia, Manral and Ohara    Informational                   [Page 15] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - The reliability in database exchange on a broadcast link is 
   achieved by periodic database exchange. This is done as CSNP's are 
   sent periodically by the DIS, which initiates the entire database 
   exchange process all over again.   
   - As the DIS sends periodic CSNP, nothing different needs to be done 
   when a new DIS is exchanged.   
   - On a point-to-point link flooding is done reliably. LSP's are 
   flooded to the neighbour and if CSNP entry for the LSP is not 
   received in a particular time interval, the LSP is re-flooded to that 
10. Flushing LSA/LSP  
   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 draft 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.  
11. SPF Calculation  
   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.  
Bhatia, Manral and Ohara    Informational                   [Page 16] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - 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.  
   - Performs only the less CPU intensive Partial Route Calculation 
   (PRC) when network events do not affect the basic topology but only 
   the IP prefixes.   
   - 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" [X] draft 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.  
   - 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 [RFC 2966] incorporated into IS-IS the apparent motivation 
   for keeping large single area domains too goes away.  
12. Area Types  
    IS-IS: Leaking between levels/areas(how it is controlled)  OSPF: 
12.1 Area Partitions  
Bhatia, Manral and Ohara    Informational                   [Page 17] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   With hierarchical routing (look at Areas/Hierarchy), it is possible 
   for an area to partition so that level 1 routing cannot connect the 
   partitions. If both partitions contain level 2 routers, and the level 
   2 network is connected, the network as a whole is not physically 
   partitioned. There is a path between the partitions of the area. The 
   path is level 2 path. 
   The symptoms of a partitioned area can be difficult to diagnose and 
   annoying for the users. Not only is communication impossible between 
   nodes that should be in the same area, but are currently in different 
   partitions of the area, but communication between members of the area 
   and nodes outside the area can be disrupted since the traffic into 
   the area might enter the wrong partition and be undeliverable.  
   IS-IS has mechanisms in which level 2 routers residing in a 
   partitioned area automatically detect and repair the partition by 
   utilizing the level 2 path as a level 1 link. Routing control 
   messages as well as data packets are encapsulated with a network 
   layer header and transmitted over the virtual link. To the rest of 
   the nodes in the area, the area is no longer partitioned and level 1 
   routing proceeds normally within the area.  
   OSPF does not have any standard explicit area repair mechanisms. If 
   an area splits in such a way that a ABR in one partition announces an 
   address summary that includes an address reachable in a different 
   partition, then routing will not work, since a packet may be 
   delivered to the incorrect partition.  
   There are two methods by which OSPF can accomplish this:   
   - Someone might notice that the area has partitioned, and manually 
   reconfigures the ABR in the area, so ABRs in each partition do not 
   contain summary addresses for addresses reachable in other partitions.   
   - No summary address were used, and each ABR reports each IP address 
   individually. If summary addresses are not used, areas do not become 
   partitioned, they merely break into multiple areas.  
   However an on demand tunnel [TUNNEL] adjacency mechanism has been 
   recently proposed in the IETF which solves this problem by choosing 
   an inter-area path over an intra-area path.  
12.2 Level 2 Partitions (Backbone Area Connectivity)  
   IS-IS requires a connected level 2 network. This means there must be 
   a path from every level 2 router to every other level 2 router that 
   traverses only level 2 routers [RADIA].  
   OSPF similarly requires a connected backbone (level 2) area, but 
   allows a link between a pair of backbone routers to consist of a 
Bhatia, Manral and Ohara    Informational                   [Page 18] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   manually configured čvirtual link" that consists of a path through a 
   non-backbone area. Communication over a virtual link between backbone 
   routers A and B can be done in two ways:  
   - A can encapsulate traffic being forwarded to B in a network layer 
   header giving B as the destination.  
   - A can assume all non-backbone routers on the path towards B know 
   enough to forward traffic to the destination towards B.  
   Virtual link uses the second approach, this requires that all non-
   backbone routers in the transit area know about all destinations in 
   the backbone area, so they will be able to forward backbone traffic 
   in case they windup in the path of a virtual link. In other words 
   summarization of backbone area into the transit area is ignored.  
   Tunnel adjacency uses the first approach, further it can used for on 
   demand partition so that the adjacency will be established 
   dynamically once the backbone is partitioned.  
   Because of the possibility of manually configured virtual links in 
   OSPF, IS-IS has a topological restriction that OSPF does not.  
12.3 Injection of Level 2 Information  
   In IS-IS, level 1 routers only know information about their own area. 
   If a level 1 router R receives a packet with an address not reachable 
   within the area, R forwards the packet to the level 2 router nearest 
   to R. In OSPF, level 2 information is fed into the non-backbone areas. 
   Suppose there is an area A in some AS such that:  
   - n IP destination addresses are reachable within the AS, but outside 
   the area A   
   - m IP destinations are reachable outside the AS   
   - k ABRs in area A   
   - j ASBRs in the AS     
   Each of the "k" ABRs reports their own distance to the "n" IP 
   destination addresses and the "j" ASBRs. This information is 
   O(k*(j+n)). Each of the "j" border routers also reports its distance 
   to each of the "m" IP destinations reachable outside the AS. This 
   information is O(j*m).  
   Giving level 2 information to level 1 routers enables the routers to 
   choose the exit level 2 router that will give the best path to the 
   Thus, OSPF yields more optimal interarea routes than IS-IS. The cost 
   of providing more optimal routing is increased bandwidth usage by the 
   routing algorithm and increases memory and CPU requirements in level 
Bhatia, Manral and Ohara    Informational                   [Page 19] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   1 routers. Aside from increased bandwidth, CPU, and memory usage, 
   there is an additional issue raised as a result of the OSPF 
   requirement for level 1 routers to store level 2 information. In IS-
   IS where an area is independent of the rest of the network, database 
   sizes in level 1 routers can be calculated based on the size of the 
   area. If the area never changes, the level 1 routers will continue to 
   function. In contrast, as the entire network grows in OSPF, demand on 
   level 1 routers increases. One small area with small routers, cannot 
   be sheltered from the growth of the rest of the network.  
12.4 Stub Area  
   There is an option in OSPF, called "Stub Area." If an area is a stub 
   area, the information concerning destinations outside the AS is not 
   flooded into the area, saving O(j*m). Information about destinations 
   within the AS, but outside the area are still flooded within an area, 
   even if the area is configured as a stub area.     
   In other words, an OSPF stub area is a compromise between a nonstub 
   OSPF and an IS-IS area. OSPF stub areas require significantly less 
   storage than nonstub OSPF areas. Like IS-IS, OSPF does not attempt to 
   optimize the route from a stub area to a destination outside the AS, 
   but unlike IS-IS, OSPF does attempt to optimize routes from a stub 
   area to destinations within the AS, but outside the area.   
   In IS-IS, none of this information is seen by the level 1 routers. 
   The cost of not storing, propagating, and computing this information 
   in IS-IS is that some routes to other ASs will be less optimal than 
   those used in OSPF.  
12.5 Not So Stub Area (NSSA)  
   "not-so-stubby" area (or NSSA), which has the capability of importing 
   external routes in a limited fashion.   
   The OSPF specification defines two general classes of area 
   configuration. The first allows Type-5 LSAs to be flooded throughout 
   the area.  In this configuration, Type-5 LSAs may be originated by 
   routers internal to the area or flooded into the area by area border 
   routers.  These areas are distinguished by the fact that they can 
   carry transit traffic. The backbone is always a Type-5 capable area. 
   The second type of area configuration, called stub (described in  
   section 10.4) does not allow Type-5 LSAs to be propagated 
   into/throughout the area and instead depends on default routing to 
   external destinations.   
   NSSAs are defined in much the same manner as existing stub areas. 
   Type-7 LSAs provide for carrying external route information within an 
   NSSA. Type-7 LSAs have virtually the same syntax as Type-5 LSAs with 
Bhatia, Manral and Ohara    Informational                   [Page 20] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   the obvious exception of the link-state type. Both LSAs are 
   considered a type of OSPF AS-external-LSA.  There are two major 
   semantic differences between Type-5 LSAs and Type-7 LSAs.   
   - Type-7 LSAs may be originated by and advertised throughout an NSSA; 
   as with stub areas, Type-5 LSAs are not flooded into NSSAs and do not 
   originate there.   
   - Type-7 LSAs are advertised only within a single NSSA; they are not 
   flooded into the backbone area or any other area by border routers, 
   though the information that they contain may be propagated into the 
   backbone area.    
   In order to allow limited exchange of external information across an 
   NSSA border, NSSA border routers will translate selected Type-7 LSAs 
   received from the NSSA into Type-5 LSAs.  These Type-5 LSAs will be 
   flooded to all Type-5 capable areas.  NSSA border routers may be 
   configured with address ranges so that multiple Type-7 LSAs may be 
   aggregated into a single Type-5 LSA.  The NSSA border routers that 
   perform translation are configurable. In the absence of a configured 
   translator one is elected.   
   IS-IS does not have such capability of an area being a Not-So-Stubby 
   Area (NSSA).  
13. Architectural Values 
13.1 Architectural Constants  
   OSPF does have a large number of tunable parameters that can make 
   configuration seem complicated. However, most of these parameters 
   should be set to default values in an OSPF implementation.   
13.2 Synchronized Parameter Setting  
   In OSPF, there are several parameters that must be configured 
   identically in routers, or else the router will refuse to communicate 
   with each other. This creates a problem because it is virtually 
   impossible to change the parameter setting via network management. 
   Once a router's parameter setting is changed, it is cut off from the 
   rest of the network since no other routers will be able to 
   communicate with it. In contrast, there is always a way in IS-IS to 
   migrate from one setting to another by configuring routers one at a 
   time while the network is running.  
   The parameters in OSPF that must be set identically in neighboring 
   routers are the HelloTime and the DeadTime  

Bhatia, Manral and Ohara    Informational                   [Page 21] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   IS-IS reports only DeadTime in its Hello messages (not HelloTime). As 
   a result, the ratio between DeadTime and HelloTime is fixed in IS-IS, 
   but can be configured in different ways by OSPF. IS-IS uses the 
   information solely to determine how long to wait between receipt of 
   Hellos from a particular neighbor before declaring the link to that 
   neighbor down. There is no necessity for neighboring nodes to have 
   the same value.  
   Being able to change these timers in a running network is important. 
   As a LAN becomes larger it might be decided that the overhead from 
   hellos is too great. It also might be important in some 
   configurations to be able to run with different hello timers for 
   different routers. There might be some routers for which quick 
   deletion of failure would be very desirable, whereas for other 
   routers quick deletion of failure might not be as important. To lower 
   overhead these routers might be configured with a longer HelloTime. 
   This cannot be done in OSPF since all routers must have identical 
   - Stub Area Flag:  
   OSPF requires every router in an area to be configured with a flag 
   indicating whether the area is a stub area. If a level 2 router has a 
   stub area flag set, it will not flood type 5 LSPs into the area. The 
   "Stub Area" flag is reported in OSPF Hello messages. If a router 
   disagrees with a neighbor as to the setting of the "stub area" flag, 
   it will bring the link to the neighbor down. IS-IS has no such 
   - Authentication Password:   
   Both OSPF and IS-IS have the optional feature of providing 
   authentication. In OSPF, there is a single password per link. The 
   password a router transmits is the same as the password it will 
   accept on the link. IS-IS allows configuration of multiple receive 
   passwords so it is possible to migrate from one password to another 
   without disrupting the operation.  
14. Virtual Links  
   - IS-IS allows a Level-1 Area which is partitioned to be 
   automatically repaired, by electing Partition Designated Level 2 
   routers and having a virtual link between them. The mechanism is not 
   often implemented and requires an explicit tunnelling mechanism."   
   - Used in ISO IS-IS for connecting partitions of Level 1 Area over 
   the Level 2 backbone.   
Bhatia, Manral and Ohara    Informational                   [Page 22] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - Used for connecting physically separate area zeroes ( to 
   maintain contiguity of the backbone  
   - Used for connecting remote areas to the backbone through other 
   areas if direct physical connectivity is not possible. This enables 
   an OSPF packet to be sent from one part of an remote isolated site to 
   the main OSPF network.   
   - For Virtual links to work, OSPF accepts packets which are have 
   originated more than one hop away. This can lead to security concerns 
   if the packets at the edge of the domain are not properly filtered.  
15. Packet Alignment/Extensibility  
   - Does not require any particular alignment of packet fields.   
   - Uses TLV (Tag-Length-Value) encoded packets to advertise routing 
   - TLVs not supported/recognized are ignored by IS-IS routers   
   - LSPs are flooded intact with unrecognized TLV information making it 
   very extensible. Ipv6 support is provided by simply adding a few more 
   - TLVs can be nested as sub-TLVs providing even more flexibility for 
   future extensions. Though the base spec does not use them but the 
   newer drafts have started using them (TE extensions, etc).   
   - Uses fixed format packets with all fields aligned at 32-bit 
   boundaries for faster processing of the OSPF packets (doesn't really 
   matter anymore as the CPUs are really fast these days!). This was 
   also primarily done because OSPF was meant to be an IPv4 only 
   - The downside is that the packet formats are not at all extensible.   
   - It uses LSAs for advertising the routing information and the 
   original spec called for dropping any unrecognized LSA type.   
   - LSAs of type 9, 10 and 11 (Opaque LSAs) have been introduced for 
   advertising other application-specific information and enough vendors 
Bhatia, Manral and Ohara    Informational                   [Page 23] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   now support this so that they are likely to get from one side of the 
   network to the other.   
   - Since the unrecognized LSA types are not flooded to neighbors it 
   makes it very difficult to extend. It in turn means that all the OSPF 
   routers must be upgraded network-wide to make the new extensions work.   
   - The new drafts (TE, GMPLS extensions, etc) written for OSPF now 
   support TLV encoding.  
   - Exhibits implicit opaque LSA behaviour i.e. unrecognized LSA types 
   are flooded to the neighbors making it more extensible that OSPFv2  
   - Designed in a way which makes it easily extensible to any other 
   layer 3 protocol suite.  
16. MTU Limitations  
   The MTU of a sub-network is the largest size packet or frame, 
   specified in octets that can be sent over it. Both OSPF and IS-IS 
   require communicating routers to have matching MTU sizes in order to 
   form adjacencies. This is needed so that routers will not advertise 
   packets larger than a neighbor can receive and process. However, each 
   protocol uses a different mechanism to check against MTU mismatch. 
   For this discussion the term MTU is used for a links Maximum Receive 
   Unit (MRU) too.  
   - IS-IS works over the link layer, which does not provide for 
   fragmentation and reassembly.   
   - Hello's are sent padded to MTU size till an adjacency comes up. If 
   there is an MTU mismatch, the side having the lesser MTU would drop 
   the bigger than MTU hello. This would not allow adjacencies to be 
   formed between interfaces having different MTU's.   
   - The hello MTU match is an insufficient condition for IS-IS as LSP's 
   are flooded as is and not packed into any other packets. For the 
   LSP's to be successfully synchronized across the subdomain, all LSP's 
   need to be of a size lesser than the smallest link MTU in the 
   subdomain, else the flooding of the LSP on the link will fail 
   resulting in inconsistent routing tables.    
   - Mis-configuration of the maximum packet size that a router sends 
   out can cause problems across the subdomain as there is no way to 
   check the value between routers that are not adjacent.  
Bhatia, Manral and Ohara    Informational                   [Page 24] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - OSPF works over IP, so the fragmentation and reassembly of any OSPF 
   packet is taken care by the IP layer. However for some link 
   technologies where MTU is configurable but not negotiated, we can 
   have packet black-holes whenever packets larger than the receiving 
   sides MTU are sent.   
   - The MTU is exchanged in the database description packets. If the 
   value of MTU received in the first DB description packet is greater 
   than that can be accepted on an interface, the packet is rejected and 
   the adjacency is not formed. Retransmissions of DB description 
   packets occur because the packets are never acknowledged. The 
   adjacency therefore gets stuck in EXstart state.   
   - As LS Update's are assembled in each router, the MTU of another 
   link does not affect the size of the LS Update packet.   
   - As the MTU match is done at the database exchange state after the 
   DR election has been completed, in case the DR itself cannot form 
   adjacencies with the rest of the routers, it can cause the network to 
   become a stub.  
17. Security/Authentication Issues  
   OSPF: Replay protection/KeyId field   
   IS-IS: HMAC MD5/checksum not in all PDU's(optional)/ need to dig into   
          PDU's to find TLV/ LSP's checksum does not cover length field/   
          purging done with 0 checksum (contents can't be verified)   
   Both protocols have a field indicating the "type" of authentication. 
   There are however differences in the two protocols. In IS-IS, the 
   data associated with the authentication is a variable length. In OSPF 
   it is fixed at 64 bits. 64 bits is sufficient for a password scheme, 
   but would not suffice for a public key signature scheme, which would 
   need a field several hundreds of bits long.  
   In OSPF there is a single password per link. A router is configured 
   with a password for each link to which it is attached. It transmits 
   that password when it transmits OSPF messages on that link. It 
   expects all OSPF messages it receives on that link to have that 
   password. In IS-IS, a router is configured with a transmit password 
   on a link, which is the password it uses when it transmits IS-IS 
   messages, as well as a set of acceptable receive passwords.   

Bhatia, Manral and Ohara    Informational                   [Page 25] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   On a P2P link a password scheme in which the receive and transmit 
   passwords are different offers some security. If the passwords are 
   the same, the intruder need only wait for the other router to 
   transmit first, and the intruder will find out the password. Even 
   with two passwords, an intruder can, with effort, discover the 
   The reason IS-IS configures routers with a set of acceptable receive 
   passwords, rather than a single receive password, is so that a link, 
   such as a LAN, can be migrated from one password to another without 
   disrupting the network. Since OSPF has single password per link, it 
   is not possible to change the password in an operational network. The 
   routers would all have to be brought down and locally reconfigured.   
   One of the brought up issue with IS-IS proponents is apparently the 
   big advantage that IS-IS has over OSPF from a security point of view 
   as IS-IS protocol packets cannot be routed beyond the immediate next 
   hop or can never be sourced by non-border routers. This is claimed, 
   can prevent a variety of potential DoS attacks as anyone can launch 
   OSPF packet bombs in the others network. This apparent vulnerability 
   to DoS attacks is because OSPF rides over IP rather than directly 
   running on the link layer.    
   Since all OSPF packets can be authenticated using MD5, all spurious 
   OSPF packets can be dropped. But there can be times when MD5 can 
   itself be a part of a problem because it takes significant CPU to 
   check signatures and discard the packets. This is partly true but it 
   is to be noted however that even if OSPF encapsulation is changed to 
   L2, we would still have to support IP encapsulation for virtual links, 
   so we would still have to do MD5.   
   Moreover the system administrator can filter on the edges of the 
   network to pry away all the OSPF messages coming from the edges. This 
   will of course be done in addition to cryptography.  
18. IS-IS/OSPF for IPv6  
   - Designed to be protocol-agnostic using TLV encoding.  
   - Distinct TLVs used to encode topology information and reachability 
   (address prefix) information. As a direct consequence, extending ISIS 
   to support IPv6 is just a matter of introducing some new TLVs. The 
   existing TLVs continue to be used to advertise topology information 
   - An extension to ISIS has been proposed that calculated Ipv4 and   
   IPv6 topologies separately. This would still use a single instance of 
   ISIS for each network protocol. There are proposals to extend ISIS to 
Bhatia, Manral and Ohara    Informational                   [Page 26] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   enable multiple instances for each network layer protocol, thereby 
   applying the "Ships in the Night" model for ISIS. 
   - All routing information is advertised using LSAs, which are 
   identified by the LS Type, LS Identifier and the advertising Router.  
   - Adapting this to support IPv6 was difficult for the following 
   Many fields (LS Identifier, the DR/BDR field in the HELLO Message, 
   etc) in the OSPF packets are IPv4 specific. Thus adapting OSPFv2 to 
   support IPv6, which has an expanded address space, becomes impossible. 
   - OSPFv2 inherits IPv4's "subnet" restriction. Thus an OSPFv2 Router 
   denies to form an adjacency if the neighboring router's IPv4 address 
   does not match the router's IPv4 subnet. Further, OSPFv2 can 
   calculate only one IPv4 prefix for a LAN segment. These "subnet" 
   restrictions were removed in IPv6 specification, which makes OSPFv2 
   even more difficult to adapt to IPv6. 
   - Presents a "ship in the night" solution during the IPv6 migration. 
   This means that the operator needs to run OSPFv2 for IPv4 routing and 
   OSPFv3 for IPv6, as against an integrated solution provided by ISIS. 
   If using OSPF, then OSPFv2 and OSPFv3 will independently calculate 
   their network topology, routes, etc. This can lead to some redundancy 
   and duplication when IPv4 network topology is identical to the IPv6 
   topology. This leads to greater CPU, memory and bandwidth utilization 
   because of double computation and advertisement.  
   ISIS on the other hand, presents an integrated solution in the 
   presence of IPv4 and IPv6 network protocols. Since ISIS can calculate 
   IPv4 and IPv6 routes simultaneously it is relatively efficient with 
   respect to the utilization of resources. 
   However, most of the networks deploying IPv4 and IPv6 simultaneously 
   typically have different topologies and IPv4 and IPv6 networks are 
   constructed separately. This avoids a breakdown of one network 
   because of the failure in the other.  
   - Instead of putting hacks in OSPFv2 to support IPv6, OSPFv3 (also 
   referred to as "OSPF for IPv6") was laid out by the OSPF WG.  

Bhatia, Manral and Ohara    Informational                   [Page 27] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - The packet format was changed, calculation and representation of 
   address prefix information was separated from the topology 
   - OSPFv3 provides native support for opaque LSAs 
   - Other fundamental mechanisms of OSPF, like database synchronization, 
   etc remain unchanged. The DR/BDR field in the Hello packet described 
   above was simply changed to contain Router-ID of the DR/BDR. 
   - Extensions have been proposed to adapt OSPFv3 for an "Integrated    
   model" where OSPFv3 would be extended to calculate IPv4 routes 
19. Current Deployments  
   Both the protocols have been currently deployed in large scale IP 
   - used in most Tier 1 ISP networks and in single area configurations   
   - initally most large ISPs adopted IS-IS as it had a stable 
   implementation, coupled with U.S. government's mandate to support ISO 
   CLNS alongside IP.  
   - more widespread from medium to large IP networks.  
   - deployed in most IP based enterprise networks  
20. Metrics Size  
   Each interface in the link state protocols in given a metric, which 
   is advertised with the link state information in LSP/LSA. The SPF 
   algorithm uses this metric to calculate the cost and the nexthop to a 
   destination. Metrics used are generally the inverse of bandwidth. A 
   larger bandwith capacity link would have a lesser metric.   
   - ISO10589 specifies metric 6 bit in size. Therefore the metric value 
   can range from 0-63. The information is carried in neighbor 
   reachbility TLV and the IP reachability TLV. This is called the 
   Narrow metric. The maximum path metric MaxPathMetric supported is 
   1023. This in theory brought the complexity of the SPF from O(nlog n) 
   to O(n). But this isn't significant any more as the CPUs are really 
   fast these days. The metric size was kept small to optimize search 
Bhatia, Manral and Ohara    Informational                   [Page 28] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   while doing SPF. It also allows two types of metrics External and 
   - The Narrow metric range was however found to be too small for 
   certain networks. New TLV's(Extended IP and Extended neighbor 
   reachability TLV's) to carry larger metrics was added as part of the 
   traffic engineering document[IS-IS-TE]. This is called Wide Metrics. 
   The MaxLinkMetric value is 0xFFFFFFand the MaxPathMetric       is 
   The Extended IP reachability TLV allows for a 4 byte metric, while 
   the Extended Neighbor reachability TLV allows for 3 bytes metric size. 
   This is to enable the metric summarized across levels/domains to be 
   as large as 0xFFFFFFFF while the link metric itself is no larger than 
   0xFFFFFE. If a metric value of 0xFFFFFF is used the prefix is not 
   used in SPF calculations.   
   - Four kinds of narrow metrics are defined however only the default 
   metric is used in networks.  
   - OSPFv2 allows a link to have a 2 byte metric feild in the Router 
   LSA. This implies the maximum metric of 0xFFFF.    
   - The Summary, Summary-ASBR, AS-External and NSSA LSA's have a 3 byte 
   metric value. A cost of 0xFFFFFF (LSInfinity) is used to tell the 
   destination described in the LSA is unreachable.   
   - AS-External and NSSA LSA's allow two metric types, Type-1 and Type-
   2 which are equivalent to IS-IS Internal and External metrics. The 
   type 1 considers the cost to the ASBR in addition to the advertised 
   cost of the route while the latter uses just the advertised cost 
   while calculating the routes.   
   - The scheme thus allows for links to be configured with a metric no 
   larger than 0xFFFF, while allowing cost of destinations injected 
   across areas/levels to be as large as 0xFFFFFE.   
   - OSPFv3 allows similar metric size for the Router LSA's as in OSPFv2.   
   - OSPFv3 allows similar metric sizes for Intra Area Prefix LSA, Inter 
   Area Prefix LSA, AS-External LSA and NSSA LSA as in OSPFv2. The value 
   and significance of LS Infinity is valid here.  
21. Database Granularity   
Bhatia, Manral and Ohara    Informational                   [Page 29] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   This section 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 
   - 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 
   - 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 

Bhatia, Manral and Ohara    Informational                   [Page 30] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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.  
   - 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 Type-Length-
   Value tuples (called 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. [INTEROP] 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.   
Bhatia, Manral and Ohara    Informational                   [Page 31] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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.  
   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 is 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.  
22. Separation of TE and topology information  
   Traffic Engineering (TE) is defined as the aspect of Internet Network 
   Engineering concerned with the performance optimization of traffic 
   handling in operational networks. The Link State Routing protocols 
   transport traffic engineering information reliably by flooding 
   mechanisms, thus helping in TE.  
   - TE information is carried in Extended IS reachability TLV's which 
   are also used in normal routing table calculations. TE information is 
   carried as subTLV's.  
   - A new Router-Id TLV is defined for TE purposes.  
   - The Value field of the TLV length can only be 255 bytes, because of 
   the limitations SRLG is defined in a seperate TLV.  
   - TE extensions information is carried in TE LSA's. A TE LSA is an 
   opaque type-10 LSA [OPAQUE], with the first 8 bits of the LSA-ID 
   field value being 1 and the remaining 24-bits being used for type-
   specific data [OSPF-TE].  
   - The payload of the TE LSA consists of TLV's. There are two top 
   level TLV's defined though any LSA can carry only one TLV. The TLV's 
   defined are Router address TLV and Link Address TLV.  

Bhatia, Manral and Ohara    Informational                   [Page 32] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - The length of the value field is 16 bits, hence the maximum length 
   of the Value field in the TLV can be 2^16.  
   - The Router-Id field used for OSPF is used to identify the other end 
   of a point-to-point link. This Router-Id field is the same field used 
   for normal SPF calculations.  
23. Convergence and Scalability Issues  
   - 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 which comes to 
   O(31000). For actual calculations refer to the [APPENDIX]  
   This seems to be 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 moved to the HISTORICAL status [RFC1745].   
   - 8 bits are used for defining 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.   
   - There is however a recent IETF draft [256LSP] which describes a 
   mechanism that allows an IS-IS router to originate more than 256 LSP 
   fragments and RFC 3373 [3WAY] which proposes a method for new TLV 
   HELLO packets that increase the number of p2p adjacencies.   
   - 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.  
   - 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.   

Bhatia, Manral and Ohara    Informational                   [Page 33] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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   
   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.   
   - 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 [DEMAND] 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 
Bhatia, Manral and Ohara    Informational                   [Page 34] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   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 
   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.  
24. Area Id Change Functionality  
   Changing area-id for an area is useful for link state routing 
   protocols in order to merge two areas into one or to split an area 
   into several areas.  
   - An area address is a variable length quantity.  
   - An area can have multiple area addresses. Neighboring IS's will not 
   form an adjacency unless they have a single area address in common. 
   This is quite useful for IP networks that are transitioning from one 
   area address to another, merging two areas into one or even to split 
   an area into several pieces.   
   - Seamless transition of area addresses for an area is easier in IS-
   IS, e.g. initially an area can have area adress A, then the set {A, 
   B} and when the new area address B is recognized by all the routers 
   in the area, old area address A can be removed.   
   - In OSPF each area has a single ID, a 4-byte quantity.   
   - OSPF does not have the ability to merge and split areas dynamically 
   as IS-IS has, though partitioned backbone can be repaired by using 
   virtual link. But it should be ensured that the area through which 
   virtual link is configured is having full routing information, i.e. 
   it should not be a stub area.   
   - Area-id can not be changed dynamically in case of OSPF.  
25. Backward Compatibility  
   For a protocol to be extensible, it should have mechanisms to allow 
   changes in the protocol packets, without affecting backward 
   compatibility. OSPFv2, OSPFv3 as well as IS-IS allow for extending 
   the protocol in a backward compatible manner.   
Bhatia, Manral and Ohara    Informational                   [Page 35] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   - All IS-IS packets contain TLV's. Unrecognized TLV's are ignored or 
   receipt, this allows TLV types to be extended in a backward 
   compatible manner.   
   - TLV's can signal more information between neighbors than can option 
   bits. It is for this reason IS-IS was able to allow IS-IS for IP 
   extensions without any backward compatibility being lost.   
   - OSPFv2 has options bit in the Hello, Database description packets 
   as well as the LSA header filed, which can be used to signal to its 
   capabilities of the neighbor. Any change of capability can be 
   signaled and decision to form adjacency as well as the LSA's to 
   exchange can be based on the option bits   
   - There are only 8 bits in the options header most of which have 
   already been utilized. To allow for further extensions OSPF allows 
   the LLS option [LLS]. However this is not widely supported in 
   commercial routers.   
   - Any unrecognized LSA received is dropped. This does not allow new 
   LSA types to be defined and prevents OSPFv2 to be really extensible.    
   - Some fields in the OSPFv2 packets contain IPv4 specific information. 
   It is for this reason a different protocol for OSPF for IPv6 was 
   - OSPFv3 also allows options field like OSPFv2, however the options 
   field have been expanded to 24-bits allowing for more options to be 
   signaled. The options have been removed from LSA header and been 
   added into LSA body for Router, Network, Inter-area-router and link 
   - OSPFv3 LSA have a flooding scope in the upper three bits of the LSA 
   type field. Unrecognized LSA's are not ignored but flooded based on 
   the flooding scope of the 3 bits. This allows new LSA types to be 
   flooded in the domain  
26. Hitless Restart Mechanisms  
   If the control and forwarding functions in a router can be separated 
   independently, it is possible to maintain a router's data forwarding 
   capability intact while the router's control software is 

Bhatia, Manral and Ohara    Informational                   [Page 36] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   restarted/reloaded. This functionality is termed as "graceful 
   restart" or "non-stop forwarding".  
   - Restarting router does not re-compute its own routes until it has 
   achieved database synchronization with its neighbors [GRACE-IS-IS].    
   - IS-IS uses new type of TLV (restart TLV) in IIH to obtain the 
   graceful restart functionality. Grace period is decided as the 
   minimum of the Remaining times of received IIHs containing a restart 
   TLV with RA bit set.   
   - During grace period, restarting router does not transmit self-
   originated LSPs and self-LSPs are not purged or modified. These 
   restrictions are necessary to prevent premature removal of an own LSP 
   and hence churn in other routers.   
   - Restart mechanism in IS-IS allows to establish adjacency without 
   cycling through the normal operation of adjacency state machine.   
   - Proper database synchronization is achieved in situations where the 
   neighboring routers of the restarting router do not support the 
   restart TLV.   
   - OSPF routers can play either of two roles during graceful restart - 
   as a restarting router or as a helper neighbor [GRACE-OSPF].   
   - Restarting OSPF router originates new type of Grace-LSAs (link 
   local Opaque-LSA) specifying the 'grace period'.    
   - During graceful restart, the restarting router neither originates 
   LSAs with LS types 1-5,7 nor does modify or flush received self-
   originated LSAs.    
   - Router as helper neighbor advertises the restarting router in their 
   LSAs as if it were fully adjacent during the grace period and also 
   detects network topology changes.   
   - OSPF automatically reverts back to standard OSPF restart from 
   graceful restart if topological changes are detected or if one or 
   more of the restarting router's neighbors do not support graceful 
27. Demand Circuits  

Bhatia, Manral and Ohara    Informational                   [Page 37] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   Demand circuits are network segments whose costs vary with usage; 
   charges can be based both on connect time and on bytes/packets 
   transmitted. Examples of demand circuits include ISDN links, X.25 
   SVCs, dial-up lines,etc. It is thus desirable to use them only for 
   the user traffic and minimal control traffic.   
   - ISO 10589 provides very limited support for demand circuits called 
   "dynamically assigned circuits" wherein it supports sending data 
   traffic over them, but does not support running the routing protocol 
   over them. Thus there are no HELLO suppression/DNA schemes in IS-IS 
   for such circuits.   
   - A new optional capability is described in RFC 1793 which modifies 
   OSPF for supporting such circuits. In this, a router will set the DC 
   bit in the options field if it supports this capability. Routers that 
   support the capability will also set the high bit (known as the do-
   not-age bit), of the LS age field to indicating that the LSA should 
   not be aged. OSPF running on such circuits suppresses periodic HELLOs 
   and LSAs, but a topology change will still activate the demand 
   circuit since LSA updates will be sent which are required to keep the 
   LS database accurate [DEMAND].   
   - Demand circuits are generally defined in stub areas which have 
   limited topology database thus shielding them from frequent topology 
   - There is however a problem in detecting inactive OSPF neighbors 
   over such links as HELLO exchange is suppressed on these circuits. To 
   work out a solution for this there are solutions suggested in a 
   recent IETF draft [PROBE] which addresses this problem by the using 
   čneighbor probing" mechanisms.  
28. IANA Considerations  
   This document introduces no new security concerns to either of the 
   specifications referenced in this document.  
29. References 
   J. Moy, "OSPF Version 2", RFC 2328, April 1998  
Bhatia, Manral and Ohara    Informational                   [Page 38] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", RFC 2740, 
   December 1999  
   A. Martey, "IS-IS Network Design Solutions", CISCO Publications, 
   February 2002  
   John T. Moy, "OSPF: Anatomy of an Internet Routing Protocol", Addison  
   Wesley, February 1998  
   R. Balay, D. Katz and J. Parker, "IS-IS Mesh Groups", RFC 2973, 
   October 2000  
   D. C. Plummer, "Ethernet Address Resolution Protocol: or Converting 
   Network Protocol Addresses to 48.bit Ethernet Addresses for 
   Transmission on Ethernet Hardware", RFC 826, November 1982  
   W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994  
   A. Zinin, A. Roy and L. Nyugen, "OSPF Out-of-band LSDB 
   resynchronization", Work in Progress  
   S. Mirtorabi, P. Psenak, "OSPF Tunnel Adjacency", Work in Progress  
   R. Perlman, "A comparision between two routing protocols: OSPF and 
   IS-IS", IEEE Network, vol. 5, no. 5, pp. 18, 24, September 1991  
   R. Coltun, "The OSPF Opaque LSA Option", RFC 2370, July 1998  
   D. Katz, K. Kompella and D. Yeung, "Traffic Engineering Extensions to 
   OSPF Version 2", RFC 3630, September 2003  
   J. Parker, "Recommendations for Interoperable Networks using 
   Intermediate System to Intermediate System (IS-IS)", RFC 3719, 
   February 2004  
   H. Smit and T. Li, "Intermediate System to Intermediate System (IS-
   IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004  
Bhatia, Manral and Ohara    Informational                   [Page 39] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   A. Hermelin, S. Previdi and M. Shand, "Extending the Number of 
   Intermediate System to Intermediate System (IS-IS) Link State PDU 
   (LSP) Fragments Beyond the 256 Limit", RFC 3786, May 2004  
   D. Katz and R. Saluja, "Three-Way Handshake for Intermediate System 
   to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, 
   September 2002  
   [RFC 1745]  
   K. Varadhan, S. Hares and Y. Rekhter, "BGP4/IDRP for IP---OSPF 
   Interaction", RFC 1745, December 1994  
   A. Zinin, B. Friedman, A. Roy, L. Nguyen and D. Yeung, "OSPF Link-
   local Signaling", Work in Progress  
   M. Shand and L. Ginsberg, "Restart Signaling for Intermediate System 
   to Intermediate System (IS-IS)", RFC 3847, July 2004  
   J. Moy, P. Pillay-Esnault and A. Lindem, "Graceful OSPF Restart", RFC 
   3623, November 2003  
   J. Moy, "Extending OSPF to Support Demand Circuits", RFC 1793, April 
   S. Rao, A. Zinin and A. Roy, "Detecting Inactive Neighbors over OSPF 
   Demand Circuits (DC)", RFC 3883, October 2004  
30. Author's Addresses 
   Vishwas Manral 
   SiNett Corp, 
   Embassy Icon Annexe, 
   2/1, Infantry Road, 
   Bangalore, India 
   Manav Bhatia 
   Riverstone Networks, 
   3/1, J.P. Techno Parks, 
Bhatia, Manral and Ohara    Informational                   [Page 40] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   Millers Road, 
   Bangalore, India 
   Yasuhiro Ohara 
   Keio University, Shonan Fujisawa Campus 
   5322 Endo, Fujisawa 
   Kanagawa, Japan 252-8520 
   Phone: +81-(0)466-47-5111 
31. Appendix 
   The maximum size of an LSP is 1492 bytes.   
   Available space = 1492 - 27 (Header) = 1465 bytes for TLVs.   
   Thus an IS-IS router has theoretically up to 256*1465 of space to 
   pack IP reachability TLVs.   
   The following calculation enables us to determine the number of IP 
   prefixes that can be advertised in an LSP.   
   The following constraints are to be considered in the calculation:   
   The maximum size (maxLSPsize) of an LSP is 1492 bytes.   
   The LSP header (lspHeadersize) is 27 bytes.   
   The maximum length of a TLV (maxTLVlength) is 255 bytes.   
   Each TLV 128 consists of type (1 byte), length (1 byte), and IP 
   prefixes (n x 12 bytes) up to total of 255 bytes. The maximum number 
   of fragments of an LSP (maxLSPfragments) is 256.   
   The number of fragments is determined from the 1-byte LSP Number 
   field in the LSP identifier.   
   The first fragment contains other TLVs, and the remaining 255 
   fragments are packed with only TLV 128.   
   The actual calculation is as follows:   
   The total space available for TLVs in an LSP is   
   TLVSpace = maxLSPsize - lspHeadersize = 1492 - 27 = 1465 bytes   

Bhatia, Manral and Ohara    Informational                   [Page 41] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
   The number of TLVs that can fit into TLVSpace is 1465/255 = 5.7,    
   approximately 6   
   Assuming a 1-byte Type field and 1-byte Length field, overhead for 6  
   TLVs is 6 x 2 = 12 bytes.   
   Actual space available for prefixes is 1465 - 12 bytes overhead =    
   1453 bytes   
   Number of prefixes, each 12 bytes (address + subnet mask + metric) 
   that can fit into TLVSpace is 1453/12 = 121.08 (approximately 121 IP 
   prefixes per LSP)   
   Considering that few other TLVs can be generated by the router, the 
   number of IP prefixes that can be supported per IS-IS router is 256 
   fragments, each containing 121 prefixes, for a total of 30,976 
32. Intellectual Property Notice 
   The IETF takes no position regarding the validity or scope of any   
   Intellectual Property Rights or other rights that might be claimed to   
   pertain to the implementation or use of the technology described in  
   this document or the extent to which any license under such rights   
   might or might not be available; nor does it represent that it has   
   made any independent effort to identify any such rights.  Information   
   on the procedures with respect to rights in RFC documents can be   
   found in BCP 78 and BCP 79. 
   Copies of IPR disclosures made to the IETF Secretariat and any   
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
33. Disclaimer of Validity 
   This document and the information contained herein are provided on an   
Bhatia, Manral and Ohara    Informational                   [Page 42] 
Internet Draft  IS-IS and OSPF Difference Discussions       July 2005 
34. Full Copyright Notice 
   Copyright (C) The Internet Society (2004).  This document is subject   
   to the rights, licenses and restrictions contained in BCP 78, and   
   except as set forth therein, the authors retain all their rights. 
35. Acknowledgment 
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

Bhatia, Manral and Ohara    Informational                   [Page 43]