Network Working Group Vishwas Manral Internet Draft Motorola Inc. Expiration Date: February 2004 Manav Bhatia Samsung Electronics IS-IS and OSPF Difference Discussions draft-bhatia-manral-diff-isis-ospf-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Abstract 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. Table of Contents Bhatia and Manral [Page 1] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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...............10 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................................14 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..........................................18 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................................................23 15. Packet Alignment/Extensibility...............................23 16. MTU Limitations..............................................24 17. Security/Authentication Issues...............................25 18. IS-IS/OSPF for IPv6..........................................27 19. Current Deployments..........................................27 20. Metrics Size.................................................27 21. Database Granularity.........................................28 22. Separation of TE and topology information....................31 23. Convergence and Scalability Issues...........................32 24. Area Id Change Functionality.................................34 25. Backward Compatibility.......................................34 26. Hitless Restart Mechanisms...................................35 27. Demand Circuits..............................................37 28. Next Generation /* needs to be updated */....................37 Security Considerations..........................................38 References.......................................................38 Appendix.........................................................40 Editor's Addresses...............................................41 Bhatia and Manral [Page 2] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 Full Copyright Notice............................................41 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 Packet Routing Domain - AS Level 2 Subdomain - Backbone Area Level 1 Area - Non Backbone Area Level 1/2 IIH PDU - Simple Hello Packet Level 1/2 LSP - No Distinction L1L2 router - ABR System ID - Router ID Link State Packet ID(LSPID) - Link State ID Pseudonode LSP - Network LSA Router LSAs, Summary LSAs, Network LSAs, ASBR Summaries, AS-External LSAs are equivalent of TLVs carried in LSPs in IS-IS. The difference is that each LSA has its own header whereas the TLVs share a common header. IS-IS Terms with no OSPF equivalent: TLV - Type-Length-Value tuple. These carry most of the information in IS-IS PDUs. OSPF Terms with no IS-IS equivalent: Advertising Router - Router that originated the advertisement. In IS-IS, this is the LSP's originator. Bhatia and Manral [Page 3] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 Backup Designated Router - Router which takes over in case the DR goes down. In IS-IS, there is no Backup DIS and the DIS election takes place again in case the former goes down or is no more available. 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: Jeff Learman, Jonathan Sadler, Radia Perlman, Philip Christian, J.J. Syed, Satish Dattari, Sina Mirtorabi, Yasuhiro Ohara, Nabendu Das, Danny McPherson, Russ White, Alex Zinin and Venkata Naidu. The archives for the discussion are available at http://groups.yahoo.com/group/diff-ospf-isis/ 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, Bhatia and Manral [Page 4] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 which was reflected in a requirement for CLNP routing support in the NSFnet project by the NSF. Interest in Dual IS-IS continued to grow, and most ISPs that sprung up in Europe chose to deploy ISO standards based on IS-IS instead of OSPF. Unlike IS-IS which started as an ISO protocol, OSPF was inherently designed to support only IPv4 and was promoted by IETF as the preferred 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 IS-IS. 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 and Manral [Page 5] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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 operator. 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 and Manral [Page 6] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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 LSAPs 0xFEFE while IP packets are either Ethernet II frames or SNAP frames identified with the protocol number 0x800. OSPF runs over IP as protocol number 89. IS-IS runs directly over layer 2 and hence - cannot support virtual links unless some explicit tunneling is implemented - packets are 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 Bhatia and Manral [Page 7] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 shielded from IP spoofing and similar Denial of Service attacks. - need to provide code points of access for each data link protocol types (Frame Relay, Ethernet, ATM, PPP [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 OSPF - 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 packets. 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 and Manral [Page 8] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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 nodes. IS-IS - DR election is deterministic - No concept of backup DIS - A new DIS is elected when the current goes down. OSPF - DR election is non-deterministic. - Elects DR and BDR to conduct flooding on a LAN. - All routers on the LAN are only synchronized with the DR and BDR. - DRship is sticky Bhatia and Manral [Page 9] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 6.1 DR election deterministic/non-deterministic 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. IS-IS Bhatia and Manral [Page 10] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 - 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. OSPF - Divides the routing domain into regular areas and a backbone area that is designated as area 0.0.0.0 and all packets going from one area to the other must traverse through this backbone. - The spec calls for the backbone to be contiguous and to be connected to all the areas through an ABR. There is however a provision to work with disconnected physically disparate backbone areas using virtual links [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. Bhatia and Manral [Page 11] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 - Areas intersect on routers. 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: - IS-IS Besides the basic checks to verify the integrity of the packet, IS-IS has a few checks to verify before formation of adjacencies when receiving hellos. - The IS-IS protocol allows multiple area-address to be configured on a router. During the hello exchange the adjacency is formed only if atleast one of the area address matches. The advantages 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 subnet. - IS-IS can carry addressing information of different protocols in TLV's. However the protocol supported field must me sent in Dual[RFC1195] and IP-Only routers. RFC1195 specifies no checks for the protocol supported field for adjacency formation. RFC-1195 places topology restrictions on multi-protocol networks. In networks that conform to these restrictions, neighboring routers will always have a protocol in common. Therefore, RFC-1195 does not state whether adjacency formation should take protocols- supported into account. Many implementations do not form an adjacency with a neighbor unless they have at least one protocol Bhatia and Manral [Page 12] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 in common [, as described in ITU-T G.7712 and draft-ietf-IS-IS- auto-encap-02.txt.] Not matching hold timer values has advantages that we can have different hold times for different routers. This helps in case say the going down of a DIS is to be faster notified, it could be better to keep a lower value for this case. OSPFv2 The checks for formation of adjacencies are stricter in OSPFv2 than IS-IS. - The area-id of the received packet should always match the incoming interface(with the exception of virtual links), the idea of areas is better explained in [area-id change functionality - it shld explain area boundaries on links VS area boundaries on routers]. Area type is strictly checked by checking the E-bit(not set for non-default areas) and the N- bit(not-set for non-NSSA areas). - The values of the HELLO interval, the Router Dead Interval and network mask received in HELLOs are matched with those on the configured interface. Any mismatch in the values causes the HELLO packet to be dropped and hence prevents formation of adjacencies. The disadvantages of this approach is that Hello Interval and Router Dead Interval changes need to be done within the Router Dead Interval, to prevent breaking adjacencies. The advantage is we would not form adjacency in case there is a router that has been mis-configured with a large value and which could cause problems later. The network mask check however does not apply to point to point links. That allows the two ends of a Point-to-Point link to have different addresses. - MTU check is not done in the hellos. It is done in the during the DB Exchange process. OSPFv3 Most of the checks for OSPFv3 are similar to that of OSPFv2. 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. Only if the Instance- Id's match do we actually form adjacencies. This allows multiple instances of OSPF to run on a single link. Bhatia and Manral [Page 13] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 9. Database Exchange and Flooding 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. OSPF - 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 i.e. 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] IS-IS - 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. Bhatia and Manral [Page 14] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 The CNSP's are sent to reduce the actual flooding of all the LSP's between the neighbours. - 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: - OSPF - 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-transmittion 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-SPF-Routers. - 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 Asynch flooding procedures between OSPFv2 and OSPFv3. IS-IS - LSP's are flooded as is across the area. They are not packed into any other packets. - On broadcast links flooding is not done reliably. A changed LSP is Bhatia and Manral [Page 15] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 flooded to all IS-IS routers, however no retransmissions occur. - 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 the neighbour. 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 Bhatia and Manral [Page 16] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 other nodes in the area and thereby computing the best route to every known destination from that particular source/node. IS-IS - SPF 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. OSPF - SPF is calculated in three phases. The first is the calculation of intra-area routes by building the shortest path tree for each attached area. The second phase calculates the inter-area routes by examining the summary LSAs and the last one examines the AS- External-LSAs to calculate the routes to the external destinations. - Is built around links, and any IP prefix change in an area will trigger a full SPF. - Only changes in interarea and external routes result in partial SPF calculations and thus IS-IS's PRC is more pervasive than OSPF's partial SPF. This difference allows IS-IS to be more tolerant of larger single area domains whereas OSPF forces hierarchical designs for relatively smaller networks. However with the route leaking from L2 to L1 incorporated into IS-IS the apparent motivation for keeping large single area domains too goes away. 12. Area Types Abstract -------- Bhatia and Manral [Page 17] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 IS-IS: Leaking between levels/areas(how it is controlled) OSPF: NSSA/stub/default 12.1 Area Partitions 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) Bhatia and Manral [Page 18] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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 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). Bhatia and Manral [Page 19] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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 destination. 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 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 Bhatia and Manral [Page 20] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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 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. - MaxAge, Refresh values TBD 13.2 Synchronized Parameter Setting Bhatia and Manral [Page 21] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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ö 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 timers. - 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 parameter. - 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 Bhatia and Manral [Page 22] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 passwords so it is possible to migrate from one password to another without disrupting the operation. 14. Virtual Links IS-IS - 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. OSPF - Used for connecting physically separate area zeroes (0.0.0.0) 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 IS-IS - Does not require any particular alignment of packet fields. - Uses TLV (Tag-Length-Value) encoded packets to advertise routing information - 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. - 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). Bhatia and Manral [Page 23] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 OSPFv2 - 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 protocol. - 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 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 Extensions, GMPLS extn., etc) written for OSPF now support TLV encoding. OSPFv3 - 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 - IS-IS works over the link layer, which does not provide for Bhatia and Manral [Page 24] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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. OSPF - 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) Bhatia and Manral [Page 25] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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. 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 passwords. 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. Bhatia and Manral [Page 26] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 18. IS-IS/OSPF for IPv6 TBD 19. Current Deployments Both the protocols have been currently deployed in large scale IP networks. IS-IS - 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. OSPF - 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. IS-IS - 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(n log 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 while doing SPF. It also allows two types of metrics External and Internal. - 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 Bhatia and Manral [Page 27] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 Metrics. The MaxLinkMetric value is 0xFFFFFFand the MaxPathMetric is 0xFE00000. 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 - 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 - 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 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 information. Bhatia and Manral [Page 28] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 OSPF - Organization of Routing Information OSPF encodes the routing information into small chunks, which it calls Link State Advertisement (LSA). Each LSA has its own 20-byte header in order to be identified uniquely. This header is called the LSA Header. There is no limitation on the size of a LSA, though the actual LSA size is limited by IP packet size limitation: 65,535 bytes minus the LSA Header size and IP packet header size. The database access in OSPF is per LSA basis. In OSPF routing, the information within an area is described by type 1 and type 2 LSAs (known as Router-LSA and Network-LSA respectively). These LSAs can become big depending upon the number of adjacencies to be advertised and prefixes to be carried inside an area. In other words, the routing information with respect to a single node (either router or network node) is encoded inside a single LSA. On the other hand, each inter-area or external prefix is advertised in a separate LSA (AS-External LSA). An OSPFv2 router may originate only one Router-LSA for itself, while in OSPFv3, a router is allowed to originate multiple Router- LSAs. A router may originate a Network-LSA for each IP subnet on which the router acts as a DR. A router may originate one LSA for each inter-area and external prefix, with no limitations on the number of LSAs that it may originate. - Consequences Originating a new and a unique LSA for each inter-area route and an external prefix implies that there is a LSA Header overhead involved while the information is kept in the database or is flooded to the neighbors. There is thus some extra memory and bandwidth consumed in total. - Carrying Routing Information LSAs are carried in Link State Update packets (called LS Updates or LSUs). Each LS Update packet has its own header, consists of a 24-byte OSPF protocol header, and a 4-bytes field indicating the number of LSAs contained in the packet. Thus multiple LSAs can be packed into a single LS Update packet. Some implementations may not do this as its considered difficult achieving this during flooding. - Consequences In the face of network changes, OSPF floods only the updated LSAs. Bhatia and Manral [Page 29] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 Therefore, even if an implementation does not pack multiple LSAs into a single LS Update packet (and so bandwidth is consumed by LS Update header for each update of a single LSA), the bandwidth consumption for each network change can be considered adequately small. IS-IS - Organization of the Routing Information In IS-IS, protocol packets are called Protocol Data Units or PDUs. IS-IS encodes the link state information into the set of 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. 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 Bhatia and Manral [Page 30] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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. IS-IS - 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. OSPF - 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. - 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 Bhatia and Manral [Page 31] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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-IS - 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. OSPF - In theory, OSPF topology is limited by the number of links that can be advertised in the Router LSA as each router gets only one Router LSA and it cant be bigger than 64K which is the biggest an IP packet can be. The same constraint applies to the Network LSA also. Each link in the router can take up at most 24 bytes. Thus, number of links which can be supported is given by (64 * 1024) / 24 = 2370 Bhatia and Manral [Page 32] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 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 supporting this then the network can really get weird. So there isn't really much that can be done using these unless the Bhatia and Manral [Page 33] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 whole network is changed. Both the routing protocols are scalable and there should not be any scalability issues with any one of them if implemented properly. Both have similar stability and convergence properties. 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. IS-IS - 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. OSPF - 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. OSPFv2 Bhatia and Manral [Page 34] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 - 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 required. IS-IS - 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. OSPFv3 - 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 LSA. - 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 restarted/reloaded. Bhatia and Manral [Page 35] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 This functionality is termed as "graceful restart" or "non-stop forwarding". IS-IS - 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 - 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 restart. Bhatia and Manral [Page 36] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 27. Demand Circuits 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. IS-IS - 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. OSPF - 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 changes. - 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. Next Generation /* needs to be updated */ Based on the next gen networks requirements which protocol (OSPF or IS-IS) is moving ahead ? 1. MANETs - OSPFv3 is proposed for MANETs http://www.ietf.org/proceedings/02mar/slides/manet-1/sld001.htm Bhatia and Manral [Page 37] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 2. Multicasting OSPF is extended for Multicast Routing (MOSPF) What about IS-IS (is there MIS-IS for IP multicast ?) Though MOSPF is not popular (unlike DVMRP, PIM-SM), there has been some thoughts of supporting multicasting using OSPF. 3. MPLS Label Distributions None of the protocols are chosen for Label Distribution 4. MPLS-TE, DiffServ, GMPLS Both protocols are extended, implemented and tested. 5. OSPF stability issues are discussed in the below paper http://www.acm.org/sigcomm/sigcomm2001/p18-basu.pdf How many of these issues can be solved using IS-IS? 6. OSPF is used for O-NNI routing while no proposals exist for IS-IS right now. 7. OSPF is widely used for PE-CE interaction in the VPN deployments. Recently there has been a draft which proposed IS-IS also for the same. Security Considerations This document introduces no new security concerns to either of the specifications referenced in this document. References [OSPF] "OSPF Version 2", RFC 2328, J. Moy, April 1998 [OSPFv3] "OSPF for IPv6", RFC 2740, R. Coltun, D. Ferguson and J. Moy, December 1999 [MARTEY] ôIS-IS Network Design Solutionsö, Abe Martey, CISCO Publications, February 2002 [Moy] "OSPF: Anatomy of an Internet Routing Protocol", John T. Moy, Addison Wesley, February 1998 [MESH] Bhatia and Manral [Page 38] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 ôIS-IS Mesh Groupsö, RFC 2973, R. Balay, D. Katz and J. Parker, October 2000 [ARP] "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware", RFC 826, David C. Plummer, November 1982 [PPP] "The Point-to-Point Protocol (PPP)", RFC 1661, W. Simpson, July 1994 [OOB] ôOSPF Out-of-band LSDB resynchronizationö, A. Zinin, A. Roy and L. Nyugen, Work in Progress [TUNNEL] ôOSPF Tunnel Adjacencyö, S. Mirtorabi, P. Psenak, Work in Progress [RADIA] "A comparision between two routing protocols: OSPF and IS-IS", R. Perlman, IEEE Network, vol. 5, no. 5, pp. 18, 24, September 1991 [OPAQUE] "The OSPF Opaque LSA Option", RFC 2370, R. Coltun, July 1998 [OSPF-TE] "Traffic Engineering Extensions to OSPF Version 2", D. Katz, K. Kompella and D. Yeung, Work in Progress [INTER-OP] ôRecommendations for Interoperable Networks using IS-ISö, J. Parker, Work in Progress [IS-IS-TE] "IS-IS extensions for Traffic Engineering", Tony Li and H. Smit, Work in Progress [256LSP] "Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit" by Amir Hermelin, Stefano Previdi, Work in Progress [3WAY] "Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, D. Katz and R. Saluja, September 2002 [RFC 1745] "BGP4/IDRP for IP---OSPF Interaction", RFC 1745, K. Varadhan, S. Hares and Y. Rekhter, December 1994 Bhatia and Manral [Page 39] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 [LLS] "OSPF Link-local Signaling", A. Zinin, B. Friedman, Abhay Roy, L. Nguyen and D. Yeung, Work in Progress [GRACE-IS-IS] "Restart signaling for IS-IS", M. Shand and Les Ginsberg, Work in Progress [GRACE-OSPF] "Graceful OSPF Restart", J. Moy, Padma Pillay-Esnault and A. Lindem, Work in Progress [DEMAND] "Extending OSPF to Support Demand Circuits", RFC 1793, J. Moy, April 1995 [PROBE] "Detecting Inactive Neighbors over OSPF Demand Circuits", S. P. Rao, A. Zinin, Abhay Roy, Work in Progress 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. Bhatia and Manral [Page 40] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 The actual calculation is as follows: The total space available for TLVs in an LSP is TLVSpace = maxLSPsize - lspHeadersize = 1492 - 27 = 1465 bytes 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 Ú 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 prefixes. Editor's Addresses Vishwas Manral Motorola Inc. 189, Prashasan Nagar Road Number 72 Jubilee Hills Hyderabad, India Email: vishwas@motorola.com Manav Bhatia Samsung Electronics India Software Operations (SISO) J.P. Techno Park, 3/1 Millers Road Bangalore, India Email: manav@samsung.com Full Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and Bhatia and Manral [Page 41] INTERNET-DRAFT IS-IS and OSPF Difference Discussions September 2003 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an ôAS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bhatia and Manral [Page 42]