Performance Comparison of OSPF and IS-IS Routing Protocols in Dual-Stack Enterprise Networks. Paris Alexandros Roussinos

Transcription

1 Performance Comparison of OSPF and IS-IS Routing Protocols in Dual-Stack Enterprise Networks Paris Alexandros Roussinos Supervisor: Imed Romdhani Internal Examiner: Isam Wadhaj Submitted in partial fulfilment of the requirements of Edinburgh Napier University for the Degree of MSc in Advanced Networking School of Computing July 2014

2 Authorship declaration I, Paris Alexandros Roussinos, confirm that this dissertation and the work presented in it are my own achievement. 1. Where I have consulted the published work of others this is always clearly attributed; 2. Where I have quoted from the work of others the source is always given. With the exception of such quotations this dissertation is entirely my own work; 3. I have acknowledged all main sources of help; 4. If my research follows on from previous work or is part of a larger collaborative research project I have made clear exactly what was done by others and what I have contributed myself; 5. I have read and understand the penalties associated with Academic Misconduct. 6. I also confirm that I have obtained informed consent from all people I have involved in the work in this dissertation following the School's ethical guidelines Signed: Date: Matriculation no:

3 Data Protection declaration Under the 1998 Data Protection Act we cannot disclose your grade to an unauthorised person. However, other students benefit from studying dissertations that have their grades attached. Please sign your name against one of the options below to state your preference. The University may make this dissertation, with indicative grade, available to others. The University may make this dissertation available to others, but the grade may not be disclosed. The University may not make this dissertation available to others. 3

4 Abstract The aim of this dissertation project was to investigate the performance of the two most popular link-state routing protocols when configured in IPv4/IPv6 dual-stack enterprise networks. The paper intended to make the first step of scientific research in performance comparison of different routing protocols in IPv4-IPv6 coexistence environments that will become popular and dominant for a long time-space with the advent of IPv6. This intention was dictated by the lack of research regarding the performance of routing protocols in dual-stack environments, and by the need to further investigate the rife stereotype which states that OSPF is most appropriate for enterprise networks and IS-IS is preferred for ISP networks. Furthermore, under the scope of this work, OSPF and IS-IS were selected for the comparison, as they constitute two proven effective routing protocols with common routing function characteristics. The aim of the work was to provide proof-based advice for selecting the protocol that offers optimal performance in business enterprise networks, in the new developing network landscape, and recommend possible migration from one protocol to another. Under this framework, a detailed theoretical background of OSPF, IS-IS and their IPv6 versions and modifications were provided to facilitate the better understanding and comprehension of the research and experimental results. Moreover, dual-stack networks were selected among other IPv4 to IPv6 migration and coexistence techniques as the background of the practical experiments, after a careful and elaborated review of the recent academic research on the topic, and after following the scientific community recommendations and conducted performance comparisons. On the side, the limited already published work about the OSPF IS-IS debate in existing IPv4 networks was examined, in order to determine elements of their function, performance advantages and disadvantages that could be also present when configured in dual-stack networks. This comparison becomes of higher importance due to the fact that OSPF demands the configuration of two different routing instances for IPv4 and IPv6, where IS-IS can handle both types of traffic with the same protocol instance. For the practical part of the paper, experiments were conducted using the renowned OPNET Modeler network simulator. The configured OSPF and IS-IS basic enterprise topologies over a dual-stack network were selected this way, as to evaluate their performance regarding IPv4 and IPv6 traffic, as well as under different Transport Layer TCP and UDP traffic patterns. The results of the simulations revealed the superiority of IS-IS compared to OSPF, as far as it concerns convergence times, routing table sizes and throughput, where both protocols seemed to perform almost equally in terms of end-to-end delay times and jitter. Based on these findings, it can be assumed that IS-IS constitutes a more optimal solution for dual-stack enterprise networks than OSPF, and can be considered from companies as a migration option, given also the advantage of the single instance capability and the security benefits that it offers. 4

5 Table of Contents 1 Introduction Problem and Context Aims and Objectives Organization Literature Review Introduction Theoretical Background Routing and Routing Protocols Basics Categories OSPF History OSPFv Hierarchy Router Types Packet Types Network Types Operation OSPFv Basics Added Characteristics Packet Types Address Families IS-IS History Addressing Hierarchy Levels PDU Types Network Types Operation Sub-network Dependent Layer

6 Sub-network Independent Layer Integrated IS-IS IPv History Addressing Features IPv4-to-IPv6 Migration Mechanisms Dual-Stack Translation Tunnelling Conclusion Related Work IPv4-IPv6 Transition Scheme Comparison Research Recommendations Performance Comparison Critical IPv6 Transition Solution Selection OSPF IS-IS Comparison Considerations OSPF vs IS-IS on Dual-Stack Conclusion Implementation Simulation with OPNET Calculated Performance Metrics Simulation Scenarios Dual-Stack Baseline Topology Traffic Design OSPF Dual-Stack Topology IS-IS Dual-Stack Topology Node Failure Addition Simulation Parameters Results Introduction

7 No Traffic, Fully-Functional Scenarios General Metrics TCP Traffic, Fully-Functional Scenarios General Metrics IPv4 Traffic Metrics IPv6 Traffic Metrics TCP Traffic, Router 4 Failure Scenarios General Metrics UDP Traffic, Fully Functional Scenarios General Metrics IPv4 Traffic Metrics IPv6 Traffic Metrics UDP Traffic, Router 4 Failure Scenarios General Metrics Comprehensive Results Experimental Results Analysis Conclusion Conclusions Evaluation of the Project Overall Outcome Future Work References Appendix Project Proposal Appendix Project Time -Plan Appendix Simulation Scenarios IPv4 Addressing Simulation Scenarios IPv6 Addressing Appendix Indicative OSPF Backbone Router (4) Routing Tables Indicative OSPF ABR Router (3) Routing Tables Indicative OSPF Internal Router (1) Routing Tables

8 Indicative IS-IS Level 2 Router (4) Routing Tables Indicative IS-IS Level 1-2 Router (3) Routing Tables Indicative IS-IS Level 1 Router (1) Routing Tables

9 List of Tables Table 1 - IPv6 Transition Categories Comparison Table 2 - Comprehensive Results for the No-Traffic Simulations Table 3 - Comprehensive Results for the TCP-Traffic Simulations Table 4 - Comprehensive Results for the UDP-Traffic Simulations

10 List of Figures Figure 1 - IGP and EGP Purpose Figure 2 - Simple OSPFv2 Network Figure 3 - OSPFv2 Packet Header Figure 4 - OSPF Neighbour States Figure 5 - OSPFv3 Packet Header Figure 6 - NET Address Format and Simple Example Figure 7 - Simple IS-IS Network Figure 8 - Generic IS-IS PDU Header Figure 9 - IPv6 Unicast Address Format Figure 10 - IPv6 Multicast Address Format Figure 11 - IPv6 Anycast Address Format Figure 12 - IPv6 Packet Header Format Figure 13 - Dual-Stack Router Structure and Function Figure 14 - Translation Mechanisms General Function Figure 15 - Tunnelling Mechanisms General Function Figure 16 - OPNET Modeler 14.5 Opening Screen Figure 17 - Enterprise Network Topology Option Figure 18 - Object Palette Utility Figure 19 - Baseline Topology Figure 20 - Application Demand's Attributes Figure 21 - Application Demand Enabled Baseline Topology Figure 22 - Router OSPF Instances Configuration Figure 23 - OSPF Topology and Areas Figure 24 - Router IS-IS Instance Configuration Figure 25 - IS-IS Topology and Areas Figure 26 - Failure Recovery Option Figure 27 - Individual Statistics Selection Figure 28 - Simulation Parameters Figure 29 - OSPF and IS-IS Convergence Activity (No Traffic) Figure 30 - OSPF and IS-IS Convergence Duration (No Traffic) Figure 31 - Average Backbone/Level 2 Router Routing Table Size (No Traffic) Figure 32 - Average ABR/Level 1-2 Router Routing Table Size (No Traffic) Figure 33 - Average Internal/Level 1 Router Routing Table Size (No Traffic) Figure 34 - Average Backbone/Level 2 Router CPU Utilization (TCP Traffic) Figure 35 - IPv4 Throughput (TCP Traffic) Figure 36 - OSPF IPv4 Clients End-to-End Delay (TCP Traffic) Figure 37 - IS-IS IPv4 Clients End-to-End Delay (TCP Traffic) Figure 38 - OSPF IPv4 Clients End-to-End Delay Variation (TCP Traffic) Figure 39 - IS-IS IPv4 Clients End-to-End Delay Variation (TCP Traffic) Figure 40 - IPv6 Throughput (TCP Traffic) Figure 41 - OSPF IPv6 Clients End-to-End Delay (TCP Traffic) Figure 42 - IS-IS IPv6 Clients End-to-End Delay (TCP Traffic) Figure 43 - OSPF IPv6 Clients End-to-End Delay Variation (TCP Traffic) Figure 44 - IS-IS IPv6 Clients End-to-End Delay Variation (TCP Traffic) Figure 45 - OSPF and IS-IS Average Convergence Duration (TCP Traffic) Figure 46 - Average Backbone/Level 2 Router CPU Utilization (UDP Traffic) Figure 47 - IPv4 Throughput (UDP Traffic) Figure 48 - OSPF IPv4 Clients End-to-End Delay (UDP Traffic)

11 Figure 49 - IS-IS IPv4 Clients End-to-End Delay (UDP Traffic) Figure 50 - OSPF IPv4 Clients End-to-End Delay Variation (UDP Traffic) Figure 51 - IS-IS IPv4 Clients End-to-End Delay Variation (UDP Traffic) Figure 52 - IPv6 Throughput (UDP Traffic) Figure 53 - OSPF IPv6 Clients End-to-End Delay (UDP Traffic) Figure 54 - IS-IS IPv6 Clients End-to-End Delay (UDP Traffic) Figure 55 - OSPF IPv6 Clients End-to-End Delay Variation (UDP Traffic) Figure 56 - IS-IS IPv6 Clients End-to-End Delay Variation (UDP Traffic) Figure 57 - OSPF and IS-IS Average Convergence Duration (UDP Traffic)

12 Acknowledgements I would like to thank my supervisor Imed Romdhani for his valuable advice and support that facilitated the completion of the project, as well as for his lecturing that inspired me in the conception of the initial dissertation topic idea. Additionally, I would like to thank the internal examiner Isam Wadhaj for consistently being there to discuss any obstacles that came up in the progress of the dissertation project. Finally, I would like to thank my family for their multifaceted tolerance and support throughout the Masters studies period. 12

13 1 Introduction 1.1 Problem and Context The upcoming domination of global IPv6 configuration due to the exhaustion of IPv4 addresses will pass through a long period of IPv4-IPv6 coexistence in many enterprise networks and the whole Internet. Even if the IPv6 protocol is standardized and decided as the successor of IPv4, the Internet reconfiguration is a time consuming, painful and risky procedure. Thus, network engineers still attempt to make the most out of IPv4 by using IPv4 existence prolonging mechanisms. However, research on IPv6 deployment techniques is being conducted more and more by various working groups. For these reasons, it is believed that it is a matter of time for the scientific community to deepen the research on routing protocol performance comparison under the already proposed transition mechanisms, in order to bring it to the contemporary network trends. The change on the foundations of the Internet and enterprise networks will surely have an impact on the network performance, as networks will have to cope with two different types of traffic simultaneously and in most cases even run more than one routing protocol. As a constantly increasing number of IPv4 to IPv6 migration mechanisms is published and presented, it is expected that the routing protocol comparison under every single one of these environments will be a necessary, but long procedure. Thus, this project tries to set an initial point, by evaluating two renowned competing routing protocols, OSPF and IS-IS, over the most wide spread migration solution, namely dual-stack, in order to reflect the majority of modern IPv4-IPv6 coexistence networks. OSPF and IS-IS are both link-state protocols that make use of the same Dijkstra algorithm in order to calculate the lowest-cost routes to every available destination. However, they present prominent differences as they were built on different protocol stacks, namely OSPF is based on the TCP/IP stack, where IS-IS is based on OSI. Research shows that the dual-stack solution as well as other transition technologies can burden the network in means of CPU processing power, memory needs and may also add latency to the routing procedure. Specifically in dual-stack this is a result of the IPv4 and IPv6 stacks running simultaneously on every network device and host. This fact makes even more important the selection of an optimum performing routing protocol in order to mitigate the inevitable dual-stack negative effects. Additionally, nowadays network performance is of vital importance due to the continuously increasing use of real-time applications such as voice and video which demand high throughput and low round-trip delay values in order to work effectively. The project s aims and objectives are set, based on these assumptions. 1.2 Aims and Objectives Based on the main subject of the dissertation, this section intends to determine the aims and objectives of the project, so that its success can be evaluated by its completion. The main aims are listed as following: The first target point of the dissertation is to base its experiments on the most ubiquitous migration technology, so that its results will have a more extensive reflection in reality. This will be attempted to be achieved by reviewing the 13

14 published literature on the IPv4 to IPv6 migration topic and by advising the networking scientific community s recommendations and statistics. Secondly, it is aimed to present OSPF and IS-IS functions and any already performed comparison between the two on IPv4 networks, in order to enhance the arguments on the final recommendation. In addition to the theoretical comparison, the project aims to provide tangible performance evaluation results regarding network metrics such as convergence duration and activity, routing table sizes, CPU utilization, throughput, end-toend delay and jitter for both presented routing protocols. This will be achieved by emulating OSPF and IS-IS function on a dual-stack network by using network simulation software. Moreover, taking in consideration both the performed theoretical research and simulated experimental results, it is aimed to determine the most effective routing protocol on dual-stack environments, and thus to provide circumstantial suggestions and advice to companies and organizations, on the selection of the best performing routing protocol for their new networks, or recommendations on possible routing protocol migration benefits. Eventually, the objective of the current dissertation is to trigger further research on routing protocol performance in IPv4-IPv6 coexistence networks. 1.3 Organization The paper is divided in three major chapters: Chapter 1 contains the introduction of the dissertation and sets the aims and goals of the paper. Chapter 2 includes two important sub-sections: Firstly, the theoretical background related to OSPF and IS-IS functions, as well as to the IPv6 protocol and the various IPv4 to IPv6 migration techniques of the current bibliography. Secondly, the recent published research review about the two main topics of the paper, precisely, the IPv4-IPv6 transition techniques and the OSPF IS-IS theoretical and performance comparison. The personal view and perception of the author about the results of the research, along with conclusions about the progress of the project, is also included in this chapter. Chapter 3 includes the complete implementation part of the project. The network simulation tool used is presented, and the different OSPF and IS-IS topology and traffic scenarios that were emulated, are explained and justified. A theoretical overview of the various network performance metrics that were measured is given, and every used option is interpreted. In the end of the chapter, the results of the performed experiments are presented and commented. 14

15 Chapter 4 includes the evaluation of the conducted work, the conclusions that can be drawn out of the total research and implementation chapters, and the recommendations that derive from the collected results. Possible future work that is aimed to be done by the author and research ideas which it is believed that should be examined by the academic community are also presented. 15

16 2 Literature Review 2.1 Introduction The Literature Review part of the presented paper intends to accomplish two tasks. Firstly, a detailed overview of the theoretical background related to the discussed technologies is performed. It is believed that the in-depth explanation of the functions of the involved routing protocols and IP protocols offers a knowledge foundation that is absolutely necessary for the reader to comprehend with the presented research. Secondly, the conducted by the scientific community related work, related to the paper s topic is presented. Finally, the author of this paper introduces his personal view and critic on the related research and he s subjective opinion and conclusions on the subject. Both Theoretical Background and Related Work sections authorship was assisted by reviewing existing bibliography that is being cited accordingly. For the Theoretical Background part, published scientific and computer networking books were advised in order to give an as deep as possible understanding of the discussed technologies. These books were found at the author s personal library, on e-book form and in Edinburgh Napier University s online library. On the other hand, the Related Work part was based on published papers in scientific journals and presented papers on renowned computer science conferences. The IEEE library web-site ( and the scientific web databases and were profoundly researched in order to retrieve the most accurate and present scientific work related to the paper s subject. All publications chosen to be used during the review of the Related Work were published after 2010, in order to ensure that they are up-to-date with the current technology trends. Finally, IETF Requests for Comments were cited throughout the Literature Review chapter as they constitute reliable, valuable citations sources. 2.2 Theoretical Background Routing and Routing Protocols Basics In the computer networking field, routing is the process during which a data packet is transferred from a source device in one network, to a destination device in another network. This vital procedure is performed usually by a dedicated network device with specialized software the router. Routers perform on the Internet Layer of the TCP/IP protocol stack and are responsible for forwarding encapsulated data in the form of a packet. Each data packet includes the IP address of the device that sourced it, as well as the IP address of the device to which it is destined for. When routers receive a packet, they take decisions about what is the next hop device that they should forward them, in order to guarantee the delivery of the packet to the destination in the fastest and most optimal way. The procedures that are used by the routers to select the best route for each destination network, and the rules that are followed in order to exchange information with other routers about the networks that are reachable via them, are called routing protocols. (Doyle, 2005) Routing protocols are responsible for the creation of routing tables at the routers, the communication between them and therefore the procedure of learning new routes, and eventually the 16

17 selection of the best available path towards a destination according to protocol metrics. Nowadays there is a variation of routing protocols that are different regarding the purpose for which they have been created as well as their functions. Routing can be either static or dynamic. Generally in static routing, routes are added by the network administrator manually into the routers routing tables and so network changes cannot be reflected, and obviously static routing is not scalable for biggest networks. On the other hand, dynamic routing makes use of a dynamic routing protocol in order to automatically build routing tables via exchange of route update information between neighbor routers. This type of routing is the most common and can easily adapt network changes such as network additions or link failures, making it vital for large network infrastructures Categories Dynamic routing protocols fall under the three main categorization schemes that follow: IGPs and EGPs: IGPs (Interior Gateway Protocols) are used to distribute routes within an AS (Autonomous System), which is defined as a set of routers under the same administrative authority. Common IGPs are RIP, OSPF, EIGRP and IS-IS. On the other hand EGPs (Exterior Gateway Protocols) are used to discover routes from one AS to another AS. The most famous EGP is the BGP. EGPs are usually used by ISPs in order to define routing policies between their infrastructure and their client s networks. (Eiji Oki, 2012) The following figure displays the relationship between the ASs and the two types of protocols. Figure 1 - IGP and EGP Purpose Distance-Vector, Link-State and Path-Vector Protocols: IGPs are divided in two main categories. First, distance-vector protocols whose main characteristic is usually the distribution of the full routing table of a router to its neighbor routers, meaning the routers that share the same link. In this type of protocols, routers send those routing updates periodically, although triggered updates are also supported. This way, each router updates its routing table with new learned routes and broadcasts an update to the neighbors. The name of this protocol team is derived from the fact that the form of 17

18 routes resembles that of a vector consisted of a distance metric and a next-hop destination. Routers replace the route to a destination in their routing table, when they receive an update including a lower-metric route for the same destination. Distancevector routing protocols are generally easier to configure but they can suffer from rooting loops that are prevented by a mechanism called split-horizon rule. Their simplicity results to less resource utilization and less need for management, but also to slow convergence time, loops and non-complex metrics as hop-count. These facts make them more suitable for small networks as they have scalability issues. A common routing algorithm used by distance-vector protocols is Bellman-Ford and some well-known routing protocols are RIP, RIPv2 and IGRP. The second main IGP category consists of the link-state routing protocols. The main characteristic of these protocols is that every router constructs a database which contains a picture of the whole network. Differently from distance-vector protocols introduce a procedure during which every router informs its adjacent nodes with information regarding its directly connected neighbors and links, and also forwards the updates sent by other routers unchanged. The common function of a link-state protocol starts with the establishment of neighbor relationship between the participating routers by exchanging Hello packets. After these adjacencies have been made, the routers exchange packets containing the above mentioned information, commonly named Link-State Packets (LSPs), and forward the updates of other routers. Every such packet is copied in each router s database, and in the end of the procedure, all routers have the same map of the network. Eventually, the routing algorithm Dijkstra is run by every node to compute routes to every destination with source the router itself, creating this way the routing table. Link-state protocols are usually hierarchical by dividing the AS into areas in order to limit the flood of update information and make the protocol more efficient. Link-state offer faster convergence times, more specific metrics, fewer loops and are scalable into larger network infrastructure, although more complex and resource demanding. The most wellknown link-state protocols are OSPF and IS-IS which will be discussed thoroughly. (Doyle, 2005) Finally, the last category is that of path-vector routing protocols which belong to the EGP group. Although path-vector protocols have their basis on distance-vector protocols, there are different because of the fact that the route advertisement updates do not contain just the destination address and the next-hop node, but also the full path to the destination. Thus, each participating router has to maintain both a routing table and a path table to hold the paths to each destination. The definition of pathvector protocols is almost matching the BGP protocol. (Medhi, 2007) Classful and Classless Protocols: The last categorization divides routing protocols to classful and classless. Classful routing protocols carry only destination IP addresses and not their subnet masks. This means, that when a router receives an update which includes a new destination, it will associate this address with the initial subnet mask derived from the address range that the address comes from. This type of protocol group includes the older RIP and IGRP, which are being less and less popular due to the incapability to support VLSM. On the other hand, classless routing protocols support VLSM, and carry subnet masks within their advertisements, so that the receiver does not have to assume the subnet mask according to the address. This feature of classless routing protocols makes them more scalable and thus popular for 18

19 larger networks. Widely popular classless protocols include RIPv2, OSPF, EIGRP and IS-IS. (Malhotra, 2002) OSPF History The OSPF (Open Shortest Path First) protocol development started in 1987 by the IETF (Internet Engineering Task Force) as a replacement to the RIP protocol. During that period, the Internet was evolving and broadened, resulting in more and larger networks resulting in bigger routing tables. The RIP updates in the new network environment were also wasting a lot of bandwidth. The OSPF working group of IETF managed to create a new hierarchical, classless link-state protocol that achieved higher convergence to adapt to the network changes faster, used a more descriptive metric than hop-count, and supported security and Type of Service. The first version of OSPF, named OSPFv1 was published in 1989, in the RFC Problems regarding the deletion of information in the routing tables, the performance of the network being destroyed by endless routing update loops, and the motivation to enhance the protocol interval times and routing lookup process, lead to the publication of the OSPFv2 in 1991, in the RFC (Moy, 1998) Finally, OSPFv2 was modified to support the new IPv6. The new version named OSPFv3 was published in 2008, in RFC This paper will present the main characteristics of the two latest, as they have dominated in the networking world OSPFv Hierarchy OSPFv2 protocol is hierarchical. Due to this, the network infrastructure is divided into areas in order to increase manageability and improve the performance of the network by reducing the routing information that travel between the routers, as well as congestion. As in every link-state protocol, in OSPFv2 each router stores a topological map of the network. As in large networks this database can be extremely large and consume a lot of resources, the division into areas allows OSPFv2 routers to hold the database of only the area that they belong to. OSPFv2 includes the types of areas that are discussed below. Non-Backbone Areas: Each non-backbone area contains a set of contiguous networks and hosts, and it is obligated to be connected to area 0 (backbone area). Hosts in one area use inter-area routes to reach destinations within their area, and intra-area routes to reach destinations that belong to other areas. In the case of unusual situations, virtual-links can be used to connect a non-directly connected area to the backbone, until the network is correctly maintained and configured. Backbone Area: The area 0, or backbone area, constitutes the core of the OSPFv2 configured autonomous system. The main role of the backbone area (also often called area ) is to carry the routing information from one non-backbone area to another. As mentioned above, every non-backbone area must be connected physically or logically in extreme circumstances, to the backbone area. 19

20 Stub Areas: Stub areas were introduced into OSPFv2 in order to minimize the area s routing tables if needed, and therefore the memory requirements. Stub areas have only one exit-point to the rest of the AS, which means that a default route is injected to the routers routing tables, and every packet destined for another AS destination will follow that route. In packet type terms, the ABR of the stub-area doesn t allow Type 4 an Type 5 LSAs to be forwarded into the area. However, intra-area routes to other areas are allowed in, and therefore all other types of LSAs may pass through. Obviously, only non-backbone areas can be configured as stubs. A variation to the stub areas called totally-stubby area also exists. The only difference from the first is that the ABR also blocks Type 3 LSAs and therefore summary intra-area routes, and every packet is forwarded via the injected default route. Not-So-Stubby Areas: Not-so-stubby areas are similar to the stub areas but with the huge difference that they allow external route information, meaning routes to a different AS s destinations. This is accomplished with the introduction of Type 7 LSAs, and is useful for distributing RIP routes into a stub area where devices that cannot run OSPF exist. (Thomas, 2003) Router Types OSPFv2 protocol introduces three different router types depending on their placement in the network design and their function. This section presents the main characteristics for each group. Internal Routers: As internal routers, are described the routers that have all their interfaces in a single area, either that is a non-backbone area or the backbone. Each of those routers stores the Link-State Database meaning the topological map, only for the area they belong to. Backbone Routers: Backbone routers are the OSPFv2 routers that have all their interfaces into area 0, the backbone area. Nevertheless, they still are internal routers. Area Border Routers: ABRs (Area Border Routers) are the routers that have directly connected links to more than one OSPF area, commonly to a non-backbone and the backbone area. The ABRs are the gateway of the internal routers of an area, when they need to communicate with intra-area destinations. These routers store a topological map for every area they are attached to, and they are responsible for summarizing routing information and distributing them into the backbone via Type 3 LSAs. Every OSPFv2 area must have at least one ABR. Moreover, ABRs are responsible for performing route summarization, one of the most important reasons for using a multi-area OSPF network. By summarizing groups of destination into one single route, minimizing routing tables at the routers is achieved as long as fewer routes are written in the routing tables. Thus, the memory requirements and CPU usage of the routers is reduced and performance is optimized. Autonomous System Boundary Routers: As ASBRs (Autonomous System Boundary Routers) are described the routers that are directly connected to both an OSPFv2 area and another AS network that may even be running another IGP. Therefore, ASBRs have to run more than one routing protocol instances and are responsible for redistributing routes to external ASs into the AS running OSPFv2, via Type 4 LSAs. 20

21 (Thomas, 2003) The following diagram attempts to present a common OSPFv2 topology that can help in understanding the OSPF area and router types Packet Types Figure 2 - Simple OSPFv2 Network OSPFv2 protocol makes use of a variation of different packet types to support in functionality and each type plays a specific role in the routing process. Regardless of the type, all OSPFv2 packets contain the same packet header that is shown below. 8 bits 8 bits 8 bits 8 bits Version Type Packet Length Router ID Area ID Checksum Authentication Authentication Figure 3 - OSPFv2 Packet Header 21 AuType The Version field contains the OSPF protocol version and the Packet Length field the length of the packet in bytes. The following Router ID and Area ID fields contain the ID of the advertising router as well as the ID of the area that it belongs to, and the Checksum field - as its name implies - the calculated checksum for the packet. The AuType and Authentication fields contain information regarding authentication. OSPF supports three types of authentication: no-authentication, plaintext and MD5 authentication that are characterized with the values 0, 1 and 2 in the AuType field accordingly. The Authentication fields include information such as passwords and keys for the latest two types of authentication supported. Finally, the Type field takes values varying from 1 to 5 to characterize the packet as Hello Packet, Database Description Packet, LS Request, LS Update and LS Acknowledgement. The following section presents basic information about each group. Hello Packets: Hello packets are exchanged between OSPFv2 routers in order to discover each other and form neighbor adjacencies. They are part of the Hello Protocol and carry a set of parameters to be negotiated between routers in order to form the neighbor relations. Such parameters are the Hello and Dead interval times

22 that describe in seconds, the frequency that the Hello packets are sent and the time space that a router has to wait for a Hello packet before declaring a neighbor as dead. In broadcast networks, Hello packets play also a vital role in the election of the Designated Router and the Back-up Designated Router by using the relative Hello packet fields. Database Description: DD (Database Description) packets contain a shortened form of the topological map, the Link-State Database of each router, and are exchanged between OSPFv2 routers when forming an adjacency. By exchanging DD packets, the routers in the same area manage to build identical LSDBs. Link State Requests: During the neighbor discovery and adjacency forming process, LSRs (Link State Requests) might be sent from one router to another in order to request information that were included in the already received DD, that the receiving router doesn t have. Link State Updates: LSUs (Link State Updates) are the most important OSPFv2 packets and are used either to reply to an LSR or to distribute newly learned routing information to neighbor routers. Each LSU contains a list of LSAs (Link State Advertisement) that be under an umbrella of several types. The most usual LSA types are briefly discussed below. (Rick Graziani, 2008) Router LSA Type 1: Type 1 LSAs are created by every OSPFv2 router and flooded to every router within the same area and not outside it. Router LSAs contain a list that includes all the OSPF enabled interfaces of the router, their cost, the OSPF neighbor routers on each interface and the originating router s ID. Network LSA Type 2: Type 2 LSAs are produced only by the DR on a Broadcast Multi-Access Network. As the DR represents all other routers on the network, produces Network LSAs that contain a list of these routers together with the originating Router s ID, in order to reduce bandwidth utilization with unnecessary LSAs. Network Summary LSA Type 3: Type 3 LSAs are produced by the ABRs in order to distribute into one attached area destinations that belong to other areas. Moreover, Type 3 LSAs carry destination within the attached areas into the backbone, in order to be distributed afterwards in the other areas. Autonomous System Boundary Router Summary LSA Type 4: Type 4 LSAs are created by ABRs and are identical to Type 3 LSAs with the vital difference that distribute routes to ASBRs in AS. Autonomous System External LSA Type 5: Type 5 LSAs are created by the ASBRs and flood within the whole AS. These LSAs contain routes to destinations outside the AS or default routes to outside the AS. Not-So-Stubby Area External LSA Type 7: Type 7 LSAs belong to an LSA type that was introduced in order to bypass the main function of not-so-stubby Areas that ban the flood of outside destination advertising in the. ASBRs create this type of LSAs in order to distribute this type of routing information in the NSSA areas. Rest of LSAs: Some less popular Types of LSAs include Group Membership LSAs (Type 6), External Attributes LSAs (Type 8) and Opaque LSAs (Types 9, 10 and 11) that are facilitating extensions of OSPFv2. 22

23 LSAcks: The LSA Acknowledgment packet is just used to provide reliability acknowledging the receipt of an LSA or a group of LSAs. It is a simple packet consisting of the packet header and LSA packet headers. (Doyle, 2005) Network Types OSPFv2 protocol can support various network types. Depending on the network type, the Dead and Hello timers vary, as well as the way the protocol function. The explanation of these types follows below. Point-To-Point Networks: Point-to-point networks connect two single OSPF routers. The routers are discovered through dynamic discovery and listen for Hello packets at the multicast address On point-to-point networks, no DR or BDR is elected. The Hello interval is 10 seconds on these networks and it is the default network type for OSPF. The most common point-to-point network types are the serial lines. Broadcast Multi-Access Networks: Broadcast networks allow more than two routers connect on the same network. As mentioned above, a DR and BDR elections happens in every broadcast network in order to handle the LSA distribution for the whole network. The main characteristic of these networks is that a packet can be destined to all nodes using a broadcast MAC address. Moreover, the dynamic discovery of OSPF routers is accomplished by using the multicast address The most common example of broadcast networks is the Ethernet. Non-Broadcast Multi-Access Networks: NBMAs (Non-Broadcast Multi-Access Networks) allow multi-access like the broadcast networks, but do not allow broadcasts and there is no dynamic neighbor discovery so that the routers must be configured manually. However, an election of DR and BDR is present. Common examples of this type of networks are X.25 and Frame Relay. Point-To-Multipoint Networks: Point-to-multipoint networks consist of connections between an interface on a router, with many interfaces on other routers. In the opposition with the previous network type, point-to-multipoint networks use dynamic neighbor discovery but no election for DR and BDR is performed. (Lammle, 2013) Operation All routers in an OSPFv2 configured AS are identified by a unique identifier, the router ID. This ID has the form of an IPv4 address and can be configured manually, can take the value of the highest configured loopback address or at last the highest IP address of the router s active interfaces. Neighboring Process: The first step in the OSPFv2 operation is the establishment of neighbor relationships. Regarding on the network type, Hello packets are sent periodically to attached routers. In order for an adjacency to be formed, parameters as the Area ID, the Hello and Dead Intervals, the subnet mask for broadcast networks and the authentication values must match. In broadcast networks a Designated Router is elected in order to reduce excessive adjacencies as well as a Back-Up Designated Router to serve the DR s role in case it comes down. DR is elected the broadcast network with the highest priority value, which is contained in the Hello packets it 23

24 sends. It has to be noted here that routers with priority equal to zero can t be elected as either DR or BDR, and the default priority value is 1. In an OSPFv2 configuration, the strongest routers in means of memory and processing power are selected to be the DRs and can be configured manually to have a greater priority value. In case of matching priorities, the highest router ID is used to determine the DR and the second higher to determine the BDR. (Thomas, 2003) The previous explained procedures are performed on the DOWN, INIT and 2WAY states of the OSPFv2 routers. After neighbor recognition and bi-directional communication is established, the exchange of Link-State Databases of the routers follows. In the EXSTART state, the communicating routers establish a master-slave relationship where the master is the router with the higher router ID, in order to decide which router will start the LSDB distribution. The following EXCHANGE state includes the exchange of DD packets, and once this is accomplished, the routers pass to the LOADING state where any needed LSRs as well as the LSUs that include the appropriate LSAs are exchanged. The final state where the routers have formed the adjacency, are synchronized and the routing procedure can start, is called FULL state. The following diagram shows the above mentioned procedure. (Lammle, 2013) Figure 4 - OSPF Neighbour States Shortest-Path-First Algorithm: OSPFv2 uses the Dijkstra algorithm, also known as SPF (Shortest-Path-First) algorithm, as it is a link-state protocol. After the OSPFv2 routers have formed the adjacencies and built their Link-State Database, they run the SPF algorithm. According to this algorithm, the routers use the LSDB that contains all possible routes and destinations, and build a tree with themselves as root and destinations as the branches. By calculating the lowest cost for every destination the routing table is created. The SPF algorithm is executed after the LSDB is built for the first time or when it changes due to the reception of new LSAs. It has to be mentioned here the cost that OSPFv2 uses to calculate the shortest paths to destinations. Every network link is assigned a cost value that is related to the link s bandwidth. More specifically the cost is given from the mathematical type Cost = Reference Bandwidth / Interface Bandwidth in bps, where the Reference Bandwidth equals to 10 8 by default. 24

25 Obviously, a link with higher bandwidth has a lower cost and is preferred. The overall cost for each route is the sum of the cost for every link in the route to the destination. (Thomas, 2003) OSPFv Basics In order to accommodate the upcoming domination of IPv6, OSPF as one of the most popular protocols should be modified in terms of the form of LSAs. Instead, it was selected to introduce an improved OSPF version, OSPFv3, which supported IPv6 but did not offer backward compatibility with OSPFv2, at least in its initial form. The new protocol version was vastly based on its predecessor, using the same hierarchical architecture, identical timer, network types and Designated Router elections. The LSA flooding procedure is also identical, as is the routing algorithm used, namely SPF. Moreover, even though OSPFv3 is designed to be used with IPv6, the area IDs and router IDs are still represented by IPv4-address-formed values. However, as it constitutes a completely new protocol it presents also obvious differences Added Characteristics The added characteristics to OSPFv3 are there to adapt the IPv6 specificities. As in IPv6 routers attached to the same link can belong to different subnets, OSPFv3 allows the exchange of OSPF packets between them. Moreover, OSPFv3 uses the link-local addresses of the OSPF enabled interfaces as source addresses and introduces a new type of LSA, the Link LSA to distribute routing information only to the neighbor on the link. Instead of the multicast IPv4 addresses and of OSPFv2, it uses the IPv6 multicast addresses FF02::5 and FF02::6 respectively in order to facilitate neighbor adjacency forming. OSPFv3 also supports multiple OSPF instances and doesn t use protocol-specific authentication, as IPv6 supports authentication by default Packet Types The packet types of OSPFv3and their numbers in the Type field of the packet header, are the same as the main five packet types of OSPFv2 (Hello packets, DD, LSRs, LSUs and LSAcks). However, the OSPFv3 is slightly different with the Authentication and AuType fields not present in this version, and with an added Instance ID field to characterize the ID of the OSPF instance on the link. The rest of the packet header is identical. The form of the various packet types is also identical to the ones of the OSPFv2, with minor differences in DD and Hello packet forms (Option field is not present and LS-Type field is 16 bit long). The following figure shows the OSPFv3 packet header. 25

26 8 bits 8 bits 8 bits 8 bits Version Type Packet Length Router ID Area ID Checksum Instance ID 0x00 Figure 5 - OSPFv3 Packet Header Again, the functionalities of the LSA Types 1 to 7 are the same as OSPFv2, except the fact that Network Summary LSA is renamed to Inter-Area Prefix LSA, ASBR Summary LSA to Intra-Area Prefix LSA and NSSA External LSA to Type-7 LSA. The LS Type number is also changed from 1-7, to 0x2001-0x2009, including the two newly introduced LSAs. The first of the two is called Link LSA, and is produced on every OSPFv3 enabled interface of the routers. The scope of this packet is linklocal, meaning that the receiving router won t flood the packet further. The purpose of the Link LSA is to distribute the sender s link-local address and the IPv6 prefixes that characterize the link to neighbors, as well as to provide more capability options through the use of the Option field. The second newly introduced LSA, the Intra-Area Prefix LSA is used to flood routing information containing prefix changes within the OSPF area, without forcing the execution of the SPF algorithm, thus making the protocol more scalable for big networks with rapid prefix changes. (Doyle, 2005) Address Families In 2010, RFC 5838 was published in order to provide a way to OSPFv3 in order to be backward compatible with IPv4 addresses and networks. The modification presented, uses the capability of OSPFv3 to use more than one protocol instances per link which can take values from 0 to 255. More specifically, the RFC divides that space to five smaller spaces in order for them to be used with different Address Families (AF). The instance ID spaces 0 to 31 and 32 to 63 are set to be used for IPv6 unicast and multicast AFs, ID spaces 64 to 95 and 96 to 127 for IPv4 unicast and multicast AFs and the rest are let unassigned. The modification for IPv4 Address Families is enabled by setting the AF-bit and V6-bit of the packets Option field and only routers with AF-bit set can get adjacent. As far as it regards the IPv4 prefixes, they are distributed by using the Link LSAs. Summarizing, in new router software versions, a router can run OSPFv3 and manage to work both with IPv4 and IPv6 addresses. (A. Lindem, 2010) IS-IS History The IS-IS (Intermediate System to Intermediate System Routing Protocol) is also a link-state routing protocol with several similarities with OSPF protocol, such as the use of the same SPF algorithm. It was defined by ISO (International Organization for Standardization) and tagged as ISO 10589, in an attempt to implement DECnet Phase V of Digital Equipment Corporation for large networks. Although it was initially designed to work with CLNP (Connectionless Network Layer Protocol), it was later in 1990 modified to also route IP as defined in RFC 1195 by the name Integrated IS- IS. Opposite to all other IGPs that were created based on the TCP/IP protocol stack, 26

27 IS-IS is based on the primer OSI (Open System Interconnection) reference model. As a result IS-IS was not initially build to support the IP protocol but the OSI layer 3 CLNP protocol, which offers network services to the upper layers. More specifically, CLNP, IS-IS and ES-IS (End System to Intermediate System) routing protocol all lay on OSI s network layer and are being encapsulated in different frames at the data-link layers. Except this difference, IS-IS also uses a different terminology. Routers are defined as intermediate systems, hosts as end systems, routing as routeing and packets as PDUs. Nowadays, it is a less common protocol than OSPF but still is the favourite choice for many Internet Service Providers backbone networks. More than that, IS-IS doesn t need to be upgraded to a new version in opposition to OSPF, because it can easily adapt the carriage of IPv6 addresses as it will be discussed later on the paper. Generally, as a link-state protocol, IS-IS is considered to be an IGP with fast convergence time and stability, as well as low resources consumption. The frame under which the IS-IS protocol works, as well as its basic components, functions and characteristics will be presented at the following chapters. (Abe Martey, 2002) Addressing Either being used to route CLNP or IP, IS-IS remains an OSI protocol and demands the assignment of an OSI address on every Intermediate System, and not on interfaces. These addresses are called NSAPs (Network Service Access Points), their length varies from 8 to 20 bytes and are usually written in hexadecimal. They consist of three main fields: the Area ID which defines the IS-IS area where the IS resides, the System ID which is unique for every device and commonly is assigned the MAC address of the device, and the N-Selector (SEL). The latest field defines the user of the network service. At the most usual situation where an NSAP address is assigned to an IS, the N-Selector takes always the hex-value 0x00. Every such IS address is also called NET (Network Entity Title). ISs assigned with addresses including the same Area ID field value belong to the same area and moreover, a single IS can be assigned more than one NET addresses as long as the Area ID changes and the System ID stays identical. NET addresses always start and end with a single byte. It has to be noted that except this format, another two formats are present, the OSI and the GOSIP format. The first one adds to the address a Routing Domain Part, where the second adds six fields, namely AFI, ICD, DFI, AAI, Reserved and RDI. However the most easy to understand and most common format is the first and thus the following figure shows this NET format and an example NET address. (Doyle, 2005) Hierarchy Area ID System ID SEL a7.81b Figure 6 - NET Address Format and Simple Example Like OSPF and as a link-state protocol, IS-IS also uses the concept of splitting the entire IS to smaller areas. The motivation behind this technique is again to limit the consumption of CPU and memory resources at the ISs by minimizing their databases and give them a relief when executing the SPF algorithm. Additionally, dividing into areas facilitates route summarization at the areas edges in order to also minimize 27

28 routing tables. On the other hand, unlike OSPF, IS-IS only defines one type of area. The basic differentiate characteristic is the lack of a backbone area. More specifically, areas do not need to be connected physically or logically to a specific area. This specificity of IS-IS makes it more scalable to larger networks and easier to adapt to any subnet additions. However, as routing roles are not dependent on the area type, IS-IS includes another feature to define routing hierarchy and manage the way routing is performed. This is accomplished with the introduction of levels Levels IS-IS includes two levels of hierarchy, level 1 and level 2. The first is used to characterize intra-area routing where the second is used for inter-area routing. Level 1/2 is used for both types of routing. Every IS is defined by one of these levels, depending on its role in the topology, and so are its links. The level of every IS also defines the type of relationship that will be formed with the IS-IS configured ISs. Level 1: More specifically a level 1 IS contains only a level 1 Link-State Database including the topological information of its own area. Level 1 ISs must have the same Area ID to create an adjacency between them. The level 1 IS topology is very similar to an OSPF stub-area, as no inter-area routes are injected to level 1 ISs routing tables. Instead, a default route is injected in order for them to be able to reach destination outside their area. However, even that is the default behavior, IS-IS can be configured to leak inter-area routes inside a level 1 topology. Level 2: On the other hand, level 2 ISs contain a level 2 Link-State Database only. This means that level 2 IS s have knowledge of the topological information of other IS-IS areas but not from theirs. More than that, Area IDs of level 2 routers do not have to match in order to form an adjacency. However there is no way that a level 2 router is isolated from the other level 2 routers. An area containing only level 2 routers can be considered as similar to the OSPF backbone area, as far as it concerns its functionality that includes spreading routing information from one area to another. However, this theoretical backbone can be extended with the addition of another level 2 or level 1/2 IS, and any connection to it is not mandatory. It has to be noted here, that an area containing only level 2 routers can exist only in IP routing environments and not in solely OSI routing networks. Level 1/2: In IS-IS, an IS can belong to only one area so there is no ABR router concept in terms that it has interfaces to more than one area. However an IS can be configured as level 1/2. This means that such an IS stores both a level 1 and level 2 Link-State Databases and is able to form adjacencies with all level 1, level 2 and level 1/2 ISs. Therefore, a level 1/2 IS contains topological information of the area it resides in and also of other areas. Communication with a level 1 IS leads to the update of the level 1 database, communication with a level 2 IS leads to the update of the level 2 database and accordingly communication with another level 1/2 will update both Link-State Databases. This feature makes a level 1/2 IS simulate the behavior of an ABR in OSPF. The level 1/2 IS is usually placed at the edge of the area, and is responsible for forwarding packets from the area s level 1 ISs to inter-area destinations. (Hannes Gredler, 2005) The following figure shows a simple IS-IS configured AS example. 28

29 PDU Types Figure 7 - Simple IS-IS Network The IS-IS protocol makes use of three main categories of PDUs (Protocol Data Units) in order to establish neighbor relationships and manage the distribution of routing information between ISs. These three categories include Hello packets, Link-State Packets (LSPs) and Sequence Number Packets (SNPs). Each of these PDU categories has a slightly different header format but the first eight fields with eight byte length in total are identical for every one of them. Thus, every PDU consists of its header and various TLVs (Type, Length, Value). TLVs have variable length and depending on their numeric value, they describe the information that the PDU-packet carries. More specifically, the Type part consists of a numeric code to define the type of the TLV, the Length shows the actual length of the TLV and the Value part defines the content. The following figure shows the common header part for every PDU sub-category. The fields Intra-domain Routing Protocol Discriminator, Version/Protocol ID Extension, Version and Reserved are fixed and have the decimal values 131, 1, 1 and 0 accordingly. Length Indicator and ID Length fields define the header length and System ID length, where the PDU Type field shows the category that the PDU belongs to. Finally, the Maximum Area Addresses field defines the size of the IS-IS area. Intra-domain Routing Protocol Discriminator Length Indicator Version/Protocol ID Extension ID Length R R R PDU Type Version Reserved Maximum Area Addresses Additional Header Fields TLV Fields Figure 8 - Generic IS-IS PDU Header 29

30 Hello Packets: Hello packets are exchanged between ISs during neighbor discovery in order to start forming adjacencies, and vary depending on the type of the link as well as the type of the routing relationship. For broadcast links there are two subcategories. First, level 1 LAN IIHs (Intermediate System to Intermediate System Hello packets) are used in broadcast links which connect ISs in order to form a level 1 adjacency. On the other hand, level 2 LAN IIHs are exchanged on the same type of links but for level 2 adjacency establishment. On point-to-point links, point-to-point IIHs are used to form both level 1and level 2 adjacencies. Not to be confused by these categories, are the ESH (End System Hello) and ISH (Intermediate System Hello) packets, which are being sent and received between hosts and routers in order to discover each other. IS circuits can be configured to allow or ban a specific type of Hello packets in order to optimize performance. Link-State Packets: LSPs, referred also as Link-State PDUs, have exactly the same functionality that LSA packets have in OSPF. In IS-IS LSPs come in two versions, depending on the routing information that they carry, having however the same packet format. Specifically, level 1 LSPs are flooded by each IS within their area in order to inform the rest ISs about their adjacent routers, their attached IP subnets (when talking about Integrated IS-IS) and carry area, metric and authentication information. Level 1 Link-State Databases are built by them in the area and are identical at the time of convergence. The second category consists of level 2 LSPs which are exchanged between level 2 ISs by neighbor flooding, and carry information about the level 2 topology. Thus, the level 2 Link-State Database is updated by their facilitation on the communicating ISs. It has to be noted that level 1/2 ISs produce both types of LSPs. Sequence Number Packets: SNPs are used to facilitate the Link-State Database synchronization between ISs. They come in two forms, CNSPs (Complete Sequence Number Packets) and PNSPs (Partial Sequence Number Packets), and each one of them is divided in level 1 and level 2 sub-categories depending on which Link-State Database they are describing accordingly, just like LSPs. CNSPs contain a summary of every LSP in the Link-State Database that includes an LSP Identifier, a Sequence Number, a Checksum and a Remaining Lifetime field. CNSPs are exchanged once during the establishment of an adjacency and before any other LSPs have been exchanged. This way ISs are informed about the topological information that each one of them contains. For broadcast networks, CNSPs are only sent by the Designated IS of the network. On the other hand, PSNPs contain only summaries about a specific LSPs and facilitate the Link-State Database synchronization procedure, either as requests for missing LSPs or to acknowledge receive LSPs. (Abe Martey, 2002) Network Types In opposition to OSPF, IS-IS supports only two types of networks, point-to-point and broadcast. Adjacencies on NBMA networks can also be accomplished without problems, if configured as a series of point-to-point links. Point-to-Point Networks: Same as in OSPF, point-to-point links are used in IS-IS to connect a single pair of ISs. CNSPs are exchanged between the two ISs in order to synchronize their Link-State Databases that is maintained alive by the periodical exchange of Hello packets. 30

31 Broadcast Networks: Broadcast networks are multi-access networks that support both broadcasts and multicasts. In every broadcast network, a Designated IS (DIS) is elected, that plays a similar role to a DR in OSPF. The election process is based on link configured priorities that have a default value of 64, and in the case of a tie, the IS with the higher MAC address wins the election. In contradiction to OSPF, there is no Backup Designated IS, and a new election must be performed if the DIS goes down. In IS-IS, a Broadcast Network is considered a pseudonode in the Link-State Database and every IS in it has to advertise a link to it. The DIS has the role of flooding the LSPs and Hello Packets for the pseudonode except its own packets, and establishing and maintaining adjacencies. Of course, different DISs are elected for level 1 and level 2 topologies and the two may be the same or vary. (Gough, 2003) Operation As IS-IS is based on OSI model, its functions are divided to two categories that resemble the two sub-layers of the OSI network Layer, the sub-network dependent layer and the sub-network independent layer. The most vital functions of each sublayer are presented below Sub-network Dependent Layer Discovery: The first step in IS-IS operation is the discovery of the ISs by the hosts and vice versa, which is achieved as mentioned by the exchange of ESH and ISH packets. The next step is the establishment of adjacencies. Neighbouring Process: ISs send, every 10 seconds by default, Hello packets on their attached interfaces, declaring this way their identity and capabilities as well as the parameters of the link. If the two ISs agree on the parameters, they become adjacent. Unlike OSPF, it is not demanded for all capabilities to match in order to form an adjacency. For example Hello interval times may vary on the two ISs but the adjacency will be established. As described above, adjacencies are level 1 and level 2. For level 1, Area IDs must match where for level 2 that is not necessary. After the adjacency is established, Hello packets are still used to maintain it as keep-alive messages. Moreover, a Hold Time value is included in the Hello packets in order to inform neighbour about the time they need to wait until they should declare the sending IS as dead. Finally, two ISs are fully adjacent only when the Link-State Database synchronization is accomplished. Hello packets are multicasted to all neighbours even by ISs that belong to the same broadcast network, with the elected DIS sending the appropriate SNPs to ensure the reliable transfer of LSPs Sub-network Independent Layer Link-State Database Update: After the Hello packets have been exchanged and the agreement between the ISs is set, level 1 LSPs are flooded within the area and level 2 LSPs are sent to all level 2 adjacent ISs, so that the level 1 and level 2 IS Link-State Databases are updated. On point-to-point networks LSPs are sent directly to the corresponding ISs, where in broadcast networks, LSPs are multicasted to the multicast MAC addresses 0180.c and 0180.c for level 1 and level 2 respectively. LSPs contain a Sequence Number that starts from the value of 1 and is 31

32 incremented by one in every new instance of the LSP until it reaches the maximum value, where IS-IS stops for a period in order for the LSPs to age in Link-State Databases. They also contain a Checksum value, and a Remaining Lifetime field that starts from 0 and rises to a MaxAge value (1200 sec. by default), and defines when the LSP is going to be deleted from the Link-State Database if not refreshed. As mentioned in a prior section, CSNP summaries are sent periodically in order to synchronize the Databases with newer LSPs and PSNPs are sent for acknowledgement and request of needed LSPs. In a broadcast network the CSNPs are sent by the DIS. Shortest Path First Algorithm: IS-IS uses the same SPF algorithm as OSPF in order to build an SPF tree and calculate the shortest routes to the known destinations. After the Link-State Database update procedure has finished, the ISs run a separate instance of the SPF algorithm for the level 1 and level 2 databases, depending of course on which of them do they support. The difference with OSPF resides on the metric used to perform the calculations. More specifically, IS-IS uses a metric called default, which takes the default value of 10 for every link. It also supports three optional metrics, namely delay, expense and error that characterize the delay, the actual cost and the error rate of the link respectively. However, using all metrics is not recommended as the SPF algorithm has to be run separately for each one of them increasing this way the CPU and memory overload. By running the SPF algorithm, ISs calculate the level 1 and level 2 routes and inject them into their routing tables. (Doyle, 2005) Integrated IS-IS IPv4 Capability: As TCP/IP model dominated in the networking world over OSI model, and therefore IP is established as the most popular layer 3 routed protocol. As discussed in the beginning of the IS-IS sector in the paper, even if IS-IS was initially build to route CLNP, it was modified to also support IP in order to be useful in modern networks and was renamed to Integrated IS-IS, mostly referred simply IS-IS. More precisely, IS-IS protocol is capable to provide routing functions to OSI environments, IP environments and Dual environments. However, the routers have still to be configured with OSI addresses in every case. Integrated IS-IS routing operation has no difference from the initial IS-IS operation. However, IP routing information is also carried within the Hello Packets and the LSPs in order to distribute IP destinations so that they can be reached. This feature is achieved with the addition of new IP-specific TLVs to the routing packets. In more detail, Hello packets include a Protocol Supported field, in order to declare that the sending ISs support IP. More than that IS-IS Hello packets include the IP address of the interface of neighbor ISs because ICMP Redirect messages to end systems must include the next-hop address. Thus, every Hello packet includes the IP address of the interface where it is send on. Additionally, in order for the ISs to have knowledge of the attached IP networks for the rest ISs in their areas, LSPs are modified to contain a group or all of the IP interface addresses on the IS. As there are Level 1 and Level 2 LSPs, both of these types include the same IP addresses. The TLV including this information is called IP Interface Address TLV. Additionally, level 1 ISs learn routes for the attached IP subnets of other ISs in the area, and level 2 ISs know which IP addresses are reachable inside the level 1 topology. Except the IP address, IP reachability information also includes the Subnet Mask and a metric. Eventually, depending on the 32

33 level of the LSP, this information is carried either inside an IP Internal Reachability Information TLV for level 1 and inside an IP External Reachability Information TLV for level 2. (Callon, 1990) IPv6 Capability: The adaptability of the Hello packets and LSPs to be modified to include extra TLV fields, has given a huge advantage to IS-IS to the point that it can carry newer addressing schemes network addresses without changing at all the operation of the protocol. Therefore, the upcoming arrival of IPv6 found IS-IS almost ready, in contradiction to OSPF that needed to be extended to a completely new version. Specifically, another TLV was added to the IS-IS routing packets, equivalent to the ones for IPv4. This TLV is named IPv6 Reachability TLV and includes the global IPv6 addresses prefix, a metric and two bits to signify if the routing information comes from a higher Level or from another routing protocol. Finally, the IPv6 equivalent TLV for the IP Interface Address TLV is called IPv6 Interface Address TLV and it has identical format, except the fact that it is modified to contain 16-byte long IPv6 addresses. IPv6 TLVs can coexist with IPv4 TLVs for dual-stack networks (Hopps, 2008) For the rest of this paper, IS-IS and Integrated IS-IS definitions will be used interchangeably, as IP is the dominant protocol that the majority of the Internet uses IPv History The IPv6 protocol creation was initially motivated by the upcoming exhaustion of the IPv4 address space. Although IPv4 can theoretically offer 4.3 billion addresses, a variety of factors lead to the exhaustion of this space. Firstly, the initial allocation of IPv4 was divided to 60% of the space given to United States of America government organizations and 40% given for the rest of the world. The purchase of large unneeded blocks of IPv4 addresses (Class A addresses) by certain organizations further increased the IPv4 exhaustion problem while a redistribution strategy is not practical and implementable today. Moreover, an ever increasing number of devices such as laptops, tablets and smart-phones have need for Internet connectivity and therefore the need for an IP address. A characteristic example of the IPv4 shortage problem is that in 2006 with the available address space reaching exhaustion, only 14% of the total human population had access to Internet. More than that, in 2011 Internet Assigned Numbers Authority (IANA) allocated the last blocks of IPv4 addresses to the Regional Internet Registries (RIRs) and the reserve that RIRs hold is the last addresses that remain to be given to ISPs. Until now, many attempts and temporary solutions have been proposed and implemented in order to extend IPv4 lifetime. In more depth, in RFC 3022 published in 2001, NAT (Network Address Translation) was defined so that one or a small group of public IPv4 addresses could server many private-addressed hosts in the Internet. NAT is a widely implemented technology even if it suffers from a variety of problems regarding applications and protocols such as IPSec. VLSM (Variable Length Subnet Masking) and CIDR (Classless Interdomain Routing) have also facilitated in using the most out of each allocated address space without wasting addresses, and the wide use of private addresses have reduced the public IPv4 address allocation need in a great manner. However, the Internet scientific community was aware of the upcoming dead-end from the 1990s. IETF had created the IPng (Internet Protocol Next Generation) and ALE (Address Lifetime 33

34 Expectation) working groups in order to determine the available time space until the IPv4 addresses would be exhausted, as well as to suggest a solution to the problem. Eventually in 1995 and 1988 respectively, RFC 1883 and RFC 2460 were published to define the new IPv6 protocol which would replace IPv4 and would also include a variety of improvements. (Hagen, 2006) Addressing In IPv6 protocol there are three types of addresses depending on the way they behave during the routing procedure. Those types are namely unicast, multicast and anycast. As noticed the last category is new in comparison with IPv4. Additionally, broadcast addresses do not exist in IPv6 because it was estimated that they created problems in IPv4 that significantly affected network performance, and it was decided to be cleared and their functions to be undertaken by multicast and anycast. Unicast: The unicast address defines a specific interface, so that when a packet is destined to it, the packet will be sent to the characterized interface where the address is assigned. Depending on their scope, unicast addresses are divided to the following three sub-categories. Global Unicast: Global unicast IPv6 addresses are unique globally, routable in the Internet and assigned by an ISP. The range of the global unicast addresses includes the addresses starting with 2000::/3. Link-Local Unicast: Every IPv6 interface is also always assigned a link-local unicast address which is not routable and is used for neighbour discovery and auto-configuration functions. The range of the link-local unicast addresses includes the addresses starting with FE80::/10. Unique-Local Unicast: Unique-local unicast addresses, also called as sitelocal, were introduced in order to resemble the role of private IPv4 addresses although different scientists argue about the need of this group, as they introduce complexity to an already complex protocol. Unique-local unicast addresses are used to address packets that flow within an organization site and cannot be routed further than it. The range of the unique-local unicast addresses includes the addresses starting with FE80::/10. As discussed earlier, the most vital reason from moving to IPv6 was the exhaustion of IPv4 addresses. Therefore, the new IPv6 addressing scheme should have a format that would offer a vast number of addresses, so that exhaustion would not be a concern for the predictable future. Consequently, IPv6 addresses were designed to consist of 128 bits instead of the 32 bits of the IPv4 addresses. IPv6 addresses are represented as a row four 2-byte long hexadecimal values separated with a colon. Thus, the IPv6 address takes a form of XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX. For convenience an all-zero 2-byte field can be replaced with a double colon (::). Additionally, instead of a subnet mask, IPv6 supports a prefix notation (e.g. /64) that identifies the subnet prefix length. The IPv6 unicast format has been defined in several RFCs, however the one that dominated splits the 128 bits IPv6 address into 3 separate fields. The first n high-order bits consists a field called Global Routing Prefix, the next m high-order bits consist the Subnet ID and the last 128 n m bits consist the Interface ID. The following figure shows the default IPv6 address format. 34

35 n bits m bits 128 n m bits Global Routing Prefix Subnet ID Interface ID Figure 9 - IPv6 Unicast Address Format The Global Routing Prefix field bits are allocated to individuals or organizations that request a specific address space. Most commonly, those first n bits are assigned by the Internet Service Provider itself and represent a site, a group of networks, and can t be more than 48 bits. The Subnet ID bits define the subnet in which the address belong in the site and are used only for internal routing. Finally, the Interface ID field characterizes the network interface where it is assigned on, and for IPv6 global unicast addresses equals 64 bits. Multicast: A multicast address is assigned to a group of different interfaces commonly on different network devices, and when a packet is destined to it, it will be delivered to all of those interfaces. The IPv6 multicast address format consists of 4 fields. The first field includes 8 bits that are always set. The second field called Flags, includes 4 bits, the three first of which are reserved and the last specifies if the multicast address is a well-known defined address or a transient permanent one. Finally, the third 4 bits Scope field defines the size of the multicast domain and the last 112 bits Group ID field is used to characterize the multicast group. The following figure shows the multicast address format. 8 bits 4 bits 4 bits 112 bits Flags Scope Group ID Figure 10 - IPv6 Multicast Address Format The range of the multicast addresses includes the addresses starting with FF00::/8. Anycast: An anycast address is again assigned to a group of different interfaces, but a packet destined to it will be delivered only to the interface which is closer to the source in terms of routing metrics. As long as a unicast IPv6 address is assigned to more than one interfaces on routers that share some common network prefix, it becomes an anycast address. Moreover, anycast addresses can only be assigned on IPv6 enabled routers and not on hosts or other devices. The anycast address format consists of two fields. The first n-bit Subnet Prefix field defines a specific network link, where the second 128-n bit field that matches to an IPv6 unicast address Interface ID includes only 0 bits. The following figure shows the anycast address format. (Loshin, 2004) Features n bits 128 n bits Subnet Prefix Figure 11 - IPv6 Anycast Address Format Packet Header: The IPv6 packet header format is differentiated from the IPv4 one. The header is designed in order to be more simplified and also support the extra 35

36 features that IPv6 protocol offers. The first 4-bit Version field specifies the Version of the IP protocol and consequently equals 6. The second 8-bit Traffic Class field is used to provide QoS features, giving the ability to sourcing or forwarding routers to give priority to specific IPv6 packets. The default value of the 8 bits is zero, but that can change by routers on the way of the route. The next 20-bit Flow Label field has a default value of 0, is used again for providing QoS to packet flows and is commonly used for real-time application data. Following, the 16-bit Payload Length field contains the actual length of the IPv6 packet excluding the header, the 8-bit Next Header field defines the type of header that follows the actual IPv6 header and the 8- bit Hop Limit field includes a value that is decremented by one each time that the packet is forwarder by a router until reaching zero and being dropped. Finally, the IPv6 packet header includes the 128-bit Source and Destination IPv6 address of the packet. The following figure shows the format of the IPv6 packet header. (S. Deering, 1998) Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address Figure 12 - IPv6 Packet Header Format Autoconfiguration: A very beneficial attribute added to IPv4 is the concept of stateless autoconfiguration. IPv6 supports stateful autoconfiguration via the use of DHCPv6, where hosts are assigned addresses by a DHCP server. More than that, IPv6 supports stateless autoconfiguration, which means that hosts can auto-configure their own IPv6 address (EUI-64) without being configured manually. This is achieved by the host by receiving the advertised subnet prefix from the routers and generating a unique address based on their MAC address or a random ID in Microsoft systems. In order to assure that the generated address is unique a procedure called DAD (Duplicate Address Detection) is performed. Extension Headers: As mentioned on the previous section, the Next Header packet header field identifies the additional header that may follow the default IPv6 header. IPv6 protocol makes use of extension headers in order to add options which give improved processing to IPv6 traffic by the destination node. IPv6 supports the six different extension headers that follow. The Hop-by-Hop Options header is the only header that is processed by all nodes in the route and is mostly used for RSVP and MLD protocols, where the Routing Header defines a list of intermediate routers that should be visited in the route. Moreover, the Fragment header defines the way the packet is fragmented and the way it should be reassembled by the destination, as in IPv6 no fragmentation is performed by the intermediate routers, and the Destination Options header includes options to be processed by the destination and is especially useful in mobile IPv6. Finally, the Authentication and Encrypted Security Payload headers can be used to define the authentication and encryption methods that are implemented on the IPv6 packet. Neighbour Discovery: Eventually, another feature of IPv6 that improves it compared to the previous version is the Neighbour Discovery (ND). ND performs various functions with the most important being the exchange of Router Advertisement and 36

37 Router Solicitation packets between hosts and routers, and the exchange of Neighbour Advertisement and Neighbour Solicitation packets between routers and routers in order to advertise data-link layer addresses. This way ARP (Address Resolution Protocol) that suffered various security flaws is not needed in IPv6. Additionally, ND plays a vital role in stateless autoconfiguration, DAD and mobile IPv6. (Hagen, 2006) IPv4-to-IPv6 Migration Mechanisms As discussed in the previous section, the domination of IPv6 is inevitable although the exact time that this will happen cannot be predicted. However, more and more organizations and companies work towards establishing IPv6 capability in their network in order to be ready for the change. Even though the IPv6 protocol is a solution to the IPv4 address exhaustion problem as well as a huge improvement, its creators did not design it to be backward-compatible with the previous version. This disadvantage makes impossible the communication between IPv4 and IPv6 address configured devices. This issue has given a push to the scientific community in order to create a variety of migration strategies from IPv4 to IPv6. As the Internet and the global community consists of a vast number of networks, there will be a most likely long time period that networks configured with IPv4 will have to coexist and communicate with networks working on IPv6. It is predicted that in the beginning of the change there will be IPv6 islands in the IPv4 network ocean, but this fact is going to change periodically. Until the final IPv6 domination, practical solutions will have to be used in order to enable communication between heterogeneous networks and applications. There is a big amount of research being held to define the best IPv4- to-ipv6 migration and coexistence techniques. The solutions that have been proposed until now can be divided in three major categories, each one of which offer different mechanisms recommended for different migration situations. This section of the paper intends to give an overview of the most popular published techniques Dual-Stack The simplest IPv4-to-IPv6 technique is called dual-stack. This technique demands the configuration of routers and hosts so that they support both IPv4 and IPv6. This way, a dual-stack network is actually a pair of logical networks, one IPv4 and one IPv6 enabled, running over the same network infrastructure. Most specifically hosts, routers and other network devices have both IPv4 and IPv6 addresses configured, and use one or another depending of the network that they are communicating with. The correct protocol stack is selected based on the DNS types returned by DNS lookups. Consequently, a dual-stack router holds both IPv4 and IPv6 routing tables which are used according to the IP version that the router is about to forward. The following figure shows the logical structure of a dual-stack router that is communicating with an IPv4-only and an IPv6-only device. 37

38 Translation Figure 13 - Dual-Stack Router Structure and Function The second migration method proposed includes the translation of one protocol to another (IPv4 to IPv6 and vice versa), by both translating the packet header and payload. This mechanism is mostly used to enable communication between an IPv4 only network and an IPv6 only network. The translation category includes several different transition techniques with different functions. SIIT: Stateless Internet Protocol/Internet Control Messaging Protocol Translation (SIIT) enables the communication of an IPv4 host with and IPv6 host by using a bidirectional translation mechanism implemented on IP and ICMP packets of both versions. The SIIT algorithm translation process doesn t affect upper layer checksums except for some application like FTP that embed IP addresses in upper layers and make vital the use of Application Layer Gateways (ALGs). An IPv4 can easily be translated in a special IPv6 that embeds the original IPv4 address in the lowest 32 bits. In the opposite situation, a temporary IPv4 address is assigned to the IPv6 device in order to send packets to an IPv4 network. BIS: Bump in the Stack (BIS) is a mechanism based on SIIT that allows an IPv4 application on a host to communicate with an IPv6 application to a destination host. During this procedure, the first host gets the IPv6 address of the destination via a DNS lookup and associates this address with an IPv4 address gained from a pool. Eventually the SIIT algorithm is used for the translation of the IPv4 address to the mapped IPv6 address. BIA: Bump in the API (BIA) is designed to accomplish the same purpose as BIS, but this time for an IPv6 host with IPv4-onl supporting applications rather than for an IPv4-only host. The most discrete difference between BIA and BIS, is that the translator in BIA is placed between the application layer and the transport layer, where in BIS the translator functions in the Internet Layer. NAT-PT: Network Address Translation Protocol Translation (NAT-PT) employs the same logic that NAT is using in IPv4-only networks. In IPv4 NAT an IPv4 address is translated in another IPv4 address where in NAT-PT, an IPv4 address is translated in an IPv4 address and vice versa. Moreover NAT-PT requires no changes on the configuration of the hosts and 38

39 dynamically matches IPv4 addresses obtained from a public IPv4 addresses pool when a session is initiated between one IPv4 and one IPv4 host. TRT: Transport Relay Translator (TRT) is a translation mechanism performed at Layer 4. It is based on the ability of the Transport Layer relay to be divided into two parts, one working for IPv4 connections and one for IPv6 connections. Based on this technique, an IPv6-only host that needs to establish a TCP connection with an IPv4-only host, uses an IPv4 destination address which includes a special prefix and the IPv4 destination address as the 32 lower-bits. The TRT mechanism performs as a proxy, by ending the initiated IPv6 connection and establishing an IPv4 one with the final destination. The following figure shows the general function that responds to all translation mechanisms. IPvX and IPvY reenact the different versions of IP, and the H1 and H2 abbreviations reenact the Host 1 and the Host 2 on the figure Tunnelling Figure 14 - Translation Mechanisms General Function The last popular migration strategy is tunnelling. Tunnelling is mainly used to facilitate communication of IPv6 hosts that reside in different networks via an IPv4 network infrastructure. The opposite procedure is also supported. The main idea behind this concept is the encapsulation of IPv6 datagrams in IPv4 formed datagrams that can be transferred over IPv4 networks, and vice versa. Depending on their functions tunnelling is also subdivided in numerous technologies, the most important of which are described below. Static Tunnelling: Static tunnelling is a technique used to connect two IPv6 hosts over an IPv4 network with a permanent link. The source and the destination hosts are manually configured with IPv4 addresses. The hosts routing table on the tunnel s endpoints defines which packets will be tunnelled. Automatic IPv4 Tunnelling: Automatic IPv4 tunnels make use of the special IPv6 addresses with the fixed ::/96 prefix and the lower 32 bits resembling the destination node s IPv4 address. Thus, a node can send IPv6 packets to these destination addresses, which will be encapsulated in IPv4 packets and sent to the IPv4 address that is identified by the 32 lower bits of the IPv6 destination address. 39

40 6over4 Tunnelling: 6over4 tunnelling technique takes advantage of the IPv4 multicast capability in order to make the IPv4 network that resides between IPv6 hosts, to behave as a layer 2 link. Each 6over4 node is configures with an IPv6 unicast address, a link-local and a solicited-node multicast address, all derived from their IPv4 addresses. By using these addresses the 6over4 hosts can perform Neighbour Discovery as if they were on the same physical link. 6to4 Tunnelling: With 6to4 tunnelling, IPv6 domains can communicate with other isolated IPv6 domains over an IPv4 network that is treated like a pointto-point link. Based on this technique a border router on the IPv6 domain, the 6to4 router is configures with an IPv4 address which is a part of the IPv6 addresses configured on the hosts of the domain. The 2002::/16 space is specifically reserved for the configuration of 6to4 hosts. Finally, when a 6to4 host in one IPv6 domain wants to communicate with a 6to4 host in another IPv6 domain, it sends the packets to the border 6to4 router which encapsulates them in IPv4 headers including the IPv4 source and destination address derived from the special IPv6 source and destination addresses. ISATAP Tunnelling: Intra-site Automatic Tunnel Addressing Protocol (ISATAP) is a technique used to tunnel IPv6 host-to-host packets over an IPv4 network. Where 6to4 is used to enable communication between different domains, ISATAP is intra-site meaning that the goal is to connect IPv6 hosts in the same IPv4 site. Similar to other tunnelling mechanisms, ISATAP devices are configured with IPv6 addresses that contain an IPv4 address. Thus, the 32 lower bits of the IPv6 address resemble an IPv4 address, and between this portion and the prefix, there is always a 32-bit part that equals 0000:5EFE and identifies ISATAP. When an IPv6 packet is sent by the ISATAP host, it is encapsulated in IPv4 header which contains the IPv4 addresses derived from the relevant ISATAP addresses Teredo Tunnelling: Teredo tunnelling is used in the case that dual-stack hosts reside behind an IPv4 NAT. This technique is based on a Teredo client-server architecture where a Teredo client placed behind the NAT, is communicating with a Teredo server in order to facilitate the first with the IPv6 address configuration by offering information regarding the external IPv4 address and port number as well as the type of the NAT. The prefix of the IPv6 address configured is always 2001::/32. Eventually, the host behind the NAT can send IPv6 traffic to another Teredo client by using the retrieved address information for encapsulating the IPv6 packets in IPv4 UDP packets. (John J. Amoss, 2008) The following figure shows the general function that respond to all Tunneling mechanisms, including the encapsulation and decapsulation procedure. IPvX and IPvY reenact the different versions of IP, and the H1, H2, TE1 and TE2 abbreviations reenact the Host 1, Host 2, Tunnel Endpoint 1 and Tunnel Endpoint 2 on the figure. 40

41 Figure 15 - Tunnelling Mechanisms General Function Research in the IPv4-to-IPv4 migration and coexistence strategies is constantly ongoing. Other solutions that were not described above include DS-Lite, 6rd and Tunnel-Broker. As a part of this paper, a general comparison of the several mechanisms will be presented in the following chapters Conclusion The Theoretical Background part aimed to give a thorough overview of all subjects that this paper deals with. As the performance evaluation of two routing protocols is the center of the presented work, the definition of routing is given and the different routing protocol types are explained. In the sequel, the OSPF and IS-IS protocols, their structure and operation are described in order to give the reader a deep understanding of their functions and facilitate the drawing of inferences about their performance. Thereinafter, the framework in which the two routing protocols will be examined is presented. More precisely, the IPv6 protocol, its addresses and benefits are collocated, as it constitutes a vital part of the dual-stack networks under which the experiments will be taken. Additionally, a general review of the most popular IPv4 to IPv6 migration mechanisms is given in order to offer an overall view of their operations that expedites their comparison and contrast which leads to the selection of the appropriate mechanism for use in the experiments in this project. 41

42 2.3 Related Work IPv4-IPv6 Transition Scheme Comparison The present project intends to measure the performance of OSPF and IS-IS routing protocols for the predicted prolonged time space of the IPv4-IPv6 coexistence in modern organization and company networks and propose a solution. Α brief comparison of the IPv4-IPv6 coexistence strategies, their popularity and performance was inevitable in order to adapt the routing protocol comparison experiments and results to the recommended and dominant migration method. This way the results will contribute to the majority of networks for the predicted future. This chapter presents the resent published research on the subject and the reasons that leaded the author to implement the OSPF IS-IS comparison on dual-stack networks. As mentioned above the specific research done on this subject is very broad. Performance analysis and comparison tests have been performed between different tunneling and translation migration mechanisms, both from the group of schemes that were presented in this paper as well as new proposed solutions. The performance comparison of all available mechanisms is not on the scope of this paper. However, the method used to limit the research to draw the conclusions needed to facilitate the current project, was the review of the available research in order to discover the recommended solution, and the performance comparison of this solution against other mechanisms Research Recommendations The first part of the research reviewed was the RFC 6180 which proposes guidelines for the IPv6 transition. This RFC discusses the inevitability of the domination of IPv6 protocol and the difficulty for taking decisions by network managers due to the large amount of proposed migration solutions. According to the research paper, there is no single right solution for the migration but it is a fact that IPv4-IPv6 coexistence will have to be maintained for many years until IPv4 is eliminated, because of the existing IPv4 application and devices in the Internet. The proposed criteria that have to be taken into account in order to choose a migration technique include errorless connectivity, simplicity, scalability, interoperability and open provision of the solutions, with the performance having secondary importance. Based on that, RFC published solutions are reviewed. More specifically, the RFC suggests that tunneling should be mainly used when native connectivity cannot be established, meaning when devices configured with one version of the IP protocol have to communicate over a network configured with the other IP version. Problems as false IPv6 connectivity appearance are addressed and the 6rd tunneling technique is considered the most robust. Additionally, solutions for ISPs like IPv6 dominant deployment with use of tunnels when needed and DS-Lite technique facilitation are presented due to their simplicity and IPv4 address saving. Similarly, an IPv6-only model is proposed for corporate networks that offer only IPv6 services but their users still need connectivity to the IPv4 Internet with the use of proxies. Additionally, IPv6/IPv4 translation techniques are also considered a solution according to the paper, but they bare all the disadvantages of the IPv4 NAT such as application failures and security vulnerabilities. Moreover, specific protocols such as HTML may have problems on IPv6-only with translation designs, due to the IPv4-literals that it carries. Finally, the Native Dual-Stack solution is presented. This technique is described as the most 42

43 simple migration model as it only demands enabling IPv6 on the existing equipment, as well as the most applicable to corporate, ISP and home networks. The issues that appear on this strategy have to do with the ability of some application to switch to IPv4 when IPv6 connections are unreliable, and with the need to enable IPv6 on every device, fact that will require the advertising of the address to the DNS even if that is not broadly needed. Furthermore, dual-stack allows direct addressing of devices, bypassing this way the need of NAT. Eventually, the dual-stack mechanism is described as the recommended IETF specified approach as well as the most popular. (J. Arkko, 2011) Another conference presented paper reviewed attempts to present the three main IPv6 transition techniques, namely dual-stack, tunneling and translation. The paper describes the ability of dual-stack nodes to use either IPv4 or IPv6 stack depending on the traffic received and notes that it is effective as well as the basis for all other migration mechanisms, as they require at least a part of the nodes to be configured as dual-stack. Likewise, it presents the DSTM (Dual Stack Transition Mechanism) which allows dual-stack hosts to receive non-permanent addresses from a DSTM server in order to address the IPv4 shortage problem during the migration. Besides that, this research presents the tunneling solution as a simple solution for the first stage of the migration where IPv6 islands will have to communicate over the IPv4 ocean. As stated, the advantage of this technique is that modification is needed only at the tunnels end-points, but the disadvantage is the inability to establish direct communication between an IPv4 and an IPv6 host. Finally, different NAT-PT translation technologies are described. Specifically, Static NAT-PT achieves one-toone IPv6 to IPv4 address mapping where Dynamic NAT-PT makes use of a pool of IPv4 addresses (XiaoHong, 2013) The third part of this paper s reviewed research constitutes a comprehensive description of the most popular IPv6 transition techniques in the Internet. The research paper notes the necessity for communication between IPv6 and IPv4 nodes and thus presents the dual-stack solution. Although it points out the practical disadvantages of this method regarding the cost and the IPv4 address needs that it introduces in large scale networks, it admits that it is an effective solutions for part networks of the Internet and an inevitable element for the Internet IPv6 migration procedure. In addition, this survey discusses the limitations of several translation techniques. More specifically, it addresses the routing scalability and addressing problems of SIIT as well as the IPv4 address wastage by the improvement of SIIT, the IVI translator. More than that, the stateless translation NAT-PT identifies the effect of the address binding table to the processing speed, cost and capacity as the main reasons that it was discarded by IETF. NAT64, BIS and BIA solutions are also described as vulnerable to DoS attacks. In the case of the tunneling mechanisms, 6to4 tunnels are seen as vulnerable to spoofing attacks and not scalable because of the need to advertise all IPv6 prefixes to the glove IPv6 FIB and RIB. On the other hand a mechanism called Softwire Mesh and 6PE for MPLS are described as good performing and scalability offering solutions. Furthermore, tunneling mechanisms as 6over4, ISATAP and 6rd are considered to have a very complex control plane and to be vulnerable to spoofing attacks based on Neighbour Discovery mechanism. The Teredo tunneling mechanism that was built as an improvement to these techniques suffers also from complexity and vulnerability to DoS and Man-in-the-Middle attacks despite its improved performance. Same attacks are a threat in addition, to the DS- 43

44 Lite and 4over6 mechanisms, where the MAP-E technique used to address these issues lacks deployment flexibility. The eventual recommendation of this paper is the dual-stack configuration of the backbone network and a tunneling mechanism such as 6rd for the edge network of an ISP. (Peng Wu, 2013) Research has also been made to define the most appropriate IPv6 migration technique between dual-stack and tunneling solutions in the scope of a campus network. It is suggested that both techniques are useful in specific situations and they can be combined in order to achieve the most cost-effective result. Dual-stack is considered by the researchers to be the most understandable, direct and interoperable way that can be used to assure a smooth transition, although it adds cost, complexity and CPU overhead. On the other hand, the easy-to-use tunneling technique has the significant disadvantage of incapability to achieve communication between IPv6-only and IPv4- only hosts. The migration strategy that is recommended is starting with IPv6-only areas connected to the IPv4 network via tunnels and the gradual deployment of IPv6 and use of dual-stack for the IPv4 parts of the campus network. (Dai, 2011) Continuing the literature review regarding the comparison of the different IPv4-to- IPv6 migration procedure, a survey over their capability in MANs was also examined. The dual-stack mechanism in this research paper is described as the most direct solution for all network devices and applications. It is supposed to be the ideal solution giving the availability to dual-stack users to access either IPv4 or IPv6 networks. From a technical and investment point of you according to the research, dual-stack is considered to be the best migration technique, as there is no need for separate network configuration of the hosts and also the existing equipment can be used just by enabling IPv6, saving this way funds. On the other hand, in cases that the existing Layer 3 devices cannot support IPv6, the use of either 6to4 or ISATAP tunnels is proposed, although it is admitted that firstly they are not an ideal proposal and also need some dual-stack nodes to function. Eventually, dual-stack is recommended for the core network, with users connecting to backbone via the tunnels. (Zhonghua Guo, 2012) Finally, useful research regarding the election of the best transition technique has been conducted by University of Colorado students, which interviewed important people of the networking industry such as Fred Baker, Chris Tuska and Jason Weil. The paper discusses well-known migration technologies as well as some IPv4 Extension technologies that are not recommended as they don t encourage the evolution to IPv6. According to the results of this survey, dual-stack is considered to be the most popular in the networking world and the most broadly deployed, due to the rapidly introducing of IPv6 enabled devices. NAT64 translation technology on the other hand, is not recommended as several protocols like SIP and Skype can t be traversed because of lack of IPv6 support. 6rd tunneling technology is thought to be an inexpensive technique as it only demands upgrading of two devices, but is mostly preferred for the very early stages of IPv6 transition and also introduces latency. Furthermore, the DS-Lite tunneling mechanism facilitated by NAT44, although is used by some ISPs it is noted that it adds management cost and complexity. Eventually, the completed survey showed that dual-stack is the absolute winner among all techniques and the one experienced industry networking scientists recommend for companies willing to migrate to IPv6. (Jinesh Doshi, 2012) 44

45 Performance Comparison A part of the research done on the subject is focused on the comparison of the performance of a network using different IPv4-to-IPv6 migration mechanisms and targeted on the recommended dual-stack technology. The first presented research paper is concentrated in the performance comparison of dual-stack networks against IPv6/IPv4 tunnels, by comparing the round-trip delay and packet-loss metrics for each case scenario under different traffic intensity - capacity. The technique used to identify the precise network capacity used on an unchanged network is by counting the packet-loss between two nodes on a fixed capacity network, and by counting the capacity of the network with a fixed packet-loss. Additionally, the packet-loss measurements were based on the RFC 2681 proposed method. The measurements were taken by examining the packet flows between two hosts that resided on different subnets connected to two separate directly connected routers over 100Mbps links. The experiment was also implemented by two methods. The first method used the D-ITG traffic generator one end and the FLUKE protocol analyzer on the other in order to record the results of the received packet flows. The second method was based on the new NPT4/6 network performance tester that was described in the paper, and that consisted of a Master System responsible for 1-10 Mbps traffic generation, a Traffic Generation Sub-System for traffic generation rate up to 74 Mbps and a Response Subsystem for receiving the packets and making the measurements. The results of the experiment showed that the round-trip delay values for the dual-stack and IPv6/IPv4 tunnel solution are similar. On the other hand, packet loss is incrementing for both techniques when the traffic flow capacity increments. However, dual-stack network packet-loss remains in tolerable levels, where with the use of the IPv6/IPv4 tunnel is much higher and reaches 100% when the traffic rate is configured at 30Mbps. Thus, the paper recommends the use of dual-stack instead of the tunnel, bearing in mind the superiority in performance as well as the simplicity of configuration. (Ting Ting Zhang, 2012) The second research paper presented here intends to compare the performance of the dual-stack solution against the two most popular IPv6/IPv4 tunneling methods, namely 6to4 an ISATAP tunnels. The experiment and analysis of this research aim to give results about the network performance comparison for IPv4 and IPv6 traffic over networks configured with each one of the above mentioned migration methods. The metrics counted are round-trip delay and throughput. Additionally, the paper notes that the same network structure was used in all three scenarios. This structure consists of two Windows PCs residing in different subnets and each one connected with a separate router. The routers were connected over an IPv4 network for the 6to4 and ISATAP, where the routers are accordingly configured as 6to4 and ISATAP routers. Moreover, the hosts for the tunneling scenarios were IPv6 only. On the other hand, for the dual-stack scenario the network that connects the two routers, the routers themselves and the hosts are configured as dual-stack IPv6/IPv4. The experiment was implemented on real equipment although the routers were not real hardware routers but high-performance PCs that simulated routing functions. Furthermore, the method used for throughput measuring was accomplished by sending TCP packet with a payload varying between 64 and 1408 bytes, and the average was calculated for each scenario after 10 implemented tests. On the other hand, the method used for roundtrip delay was accomplished by sending ICMP and ICMPv6 packets with a 1024 bytes packet size, and the average was calculated for each scenario after

46 implemented tests. The diagrams produced from the experiments of these projects show that for IPv6 traffic 6to4 and ISATAP tunnels achieve similar throughput values where dual-stack solution offers higher throughput than both of them. Again, for the round-trip delay measurement using IPv6 traffic, 6to4 and ISATAP tunnels result in similar measurements, where dual-stack achieves lower round-trip delay than both of the tunneling methods. Eventually, this research shows that dual-stack networks have overall network performance than 6to4 and ISATAP tunnel networks, and also that IPv6 traffic performs better than IPv4 on dual-stack. (Yingjiao Wu, 2011) Critical IPv6 Transition Solution Selection The performed literature review regarding the IPv4-to-IPv6 migration techniques intended to facilitate the author of this paper to decide the most appropriate environment for the OSPF- IS-IS performance comparison research and experiment. As mentioned, the aim of the current project is the evaluation of those two link-state protocols in IPv4/IPv6 networks that become more and more common due to the need for IPv6 migration. Based on the conducted research review, the dual-stack mechanism was selected. Firstly, dual-stack is the recommended transition technology by both the IETF and people from the industry. The simplicity that it offers, the availability of direct connection between IPv4 and IPv6 hosts and the provision of connectivity between every type of network makes it an easy understandable migration technique from a network management point of view, as well as an effective mechanism with many connection capabilities. The main concern regarding this solution is that it demands the assignment of IPv4 addresses in all nodes, which will be very hard to find in the near future. However, it is believed that current technologies as private addressing and NAT as well as other auxiliary migration techniques that can be used outside a company s network may overcome this issue. Moreover, although some research papers imply that dual-stack is heavy in terms of resources consumption, experiments show that it achieves higher throughput, lower round-trip delay times and generally better performance than tunneling techniques. Additionally, the concern about investment needed for new IPv6 capable network equipment has no real foundation as most devices are already IPv6 enabled, as are all new released devices. Again, based on the research performed, other migration techniques are feasible but mostly preferred as facilitating to connect enterprise networks with the outside world. Except that, most of the translation and tunneling techniques suffer from several security vulnerabilities and lower performance and require at least some routers configured as dual-stack. Finally, tunneling techniques such as 6to4 tunnels cause problems on the neighbor adjacency establishment for OSPFv3 (because of the use of link-local addresses), defeating this way the purpose of the whole routing protocol comparison over a network configured with those mechanisms. For all the above reasons dual-stack is considered the ideal solution for company networks IPv6 migration, the easier to implement and the one that is predicted to dominate. Thus, dual-stack environments were selected to base the OSPF - IS-IS comparison on. The following table shows comprehensively the advantages, drawbacks and suitability of the three major IPv6 transition technology categories. 46

47 IPv6 Transition Categories Dual Stack Translation Tunneling Advantages Disadvantages Suitability Simple Easy to understand and configure Inexpensive Scalable Lower packet-loss rates Higher throughput rates Lower round-trip delay times Direct communication between nodes Recommended solution Connectivity between IPv4-only and IPv6-only devices Enables ISPs to change customers IPv4 global addresses with private Need of modification only at the tunnel s endpoints Inexpensive solution Simple Need for IPv4 addresses on every node Superfluous address advertisement to DNS More CPU-memory overhead Vulnerable to DoS attacks Performance depending on the address binding table size Low scalability Incapability to traverse IPv6 notsupported applications Bears all foibles of NAT Adds complexity and management cost No connectivity between IPv4-only and IPv6-only devices Vulnerable to DoS, spoofing and manin-the-middle attacks Need of dual-stack routers Introduces latency Table 1 - IPv6 Transition Categories Comparison Suitable for the backbone of enterprise, ISP and home networks Best for the main stage of migration Only for early stages of the migration Suitable for connecting islands of one IP version via an ocean of another IP version Suitable for ISP edge networks Best for the early stages of the migration OSPF IS-IS Comparison Considerations As discussed in previous sections, OSPF and IS-IS consist two link-state protocol with the same route calculation mechanism but based on different protocol stacks. Historically, IS-IS is selected by many ISPs for their core networks where OSPF is the most popular protocol for enterprise networks. OSPF seems to be the preferred protocol among the two, due to the fact that is a proven effective routing protocol and is based on the TCP/IP model. Most network engineers are more familiar to the dominant IP protocol rather than CLNP, making this way companies to select OSPF in order to facilitate their networks management. However, it is believed that for modern networks and applications that tend to be more and more demanding in terms of resource consumption and need of low latency, performance should be a vital factor when selecting a routing protocol. This gets even more important for dual-stack networks which will be the majority of the enterprise network world, and which by nature introduce additional performance overhead. This chapter intends to review the research that has been carried on the comparison of the two protocols when running over the existing IPv4 networks and on how they cope with IPv6 traffic. It is expected that this research part will produce some assumptions about the proficiency of OSPF 47

48 and IS-IS when configured on dual-stack networks, that can be compared with the project s experiment results, in order to lead to safer conclusions. The comparison of the two protocols has been a matter of debate through the years, but nowadays the subject still preoccupies the networking community. IS-IS, although used primarily in ISPs networks, is being reviewed by researchers about the possibility of a broader deployment. A recent publication has attempted to emphasize IS-IS advantages and why it should be considered as an alternative to OSPF. It is suggested that IS-IS is an extensible routing protocol that offer huge support to the global IPv6 deployment. Furthermore, as discussed in the Theoretical Background chapter its hierarchical structure helps to reduce the exchanged routing information. In terms of security, IS-IS is also strong, as it supports clear-text authentication by using specialized TLVs, and is extensible to new authentication forms that are being researched by IETF. Except that, in comparison to OSPF, IS-IS routing information is not carried over IP but is encapsulated in layer 2, making a possible attacker task difficult, as they should directly connect to an IS-IS router to start any malicious activities. Apart from the obvious advantages, researchers believe that IS-IS also has disadvantages that may have played a role in its reduced popularity. Notably, IS-IS level 1 adjacencies do not carry external route information and this can only be done by injecting these routes to the level 2 topology, in comparison to OSPF that can achieve this goal by using not-so-stubby-areas. Furthermore, it is noted that IS-IS does not support virtual links like OSPF. However, this is believed to be of less importance as IS-IS doesn t require to achieve connectivity with a backbone area. Back to IS-IS advantages, the LSP lifetime can grow up to 18.2 hours unlike OSPF that is limited to 1 hour, making this way IS-IS more scalable for bigger areas. Moreover, IS-IS can make use of the Overload bit to signal memory exhaustion of a router and also includes a feature that enables routers in full-mesh topologies to receive only one LSP copy, where OSPF has no such capabilities. Eventually, this research points out that IS-IS may be a more efficient solution as it can be extended for future needs by adding new TLVs in comparison to OSPF that needs the creation of new LSAs, by the most obvious example being that of the IPv4 and IPv6 coexistence capability. It is suggested that the above discussed characteristics should make the scientific and industry community reconsider IS-IS place in the networking world, especially for larger networks. (Singh, 2013) Even though several research paper signalize IS-IS superiority, the OSPF - IS-IS comparison topic is controversial and research papers that support the opposite also exist. Based on an example research paper, OSPF is compared with other IGPs, namely IGRP, EIGRP and OSPF and is suggested to be better than all of them. This research emphasizes on the advantages of OSPF due to its hierarchical structure that facilitates reducing the routing data traffic, as well as on the fast convergence times that it offers. Thereinafter, it attempts to build a comparative table with the characteristics of each mentioned IGP in order to conduct a comparison, and conclude to the most efficient of them. The paper suggests that OSPF s greater advantage is that it is open, making possible this way its deployment to networks that include routers and other network devices by various vendors. These characteristics are used by the research as arguments that lead to the conclusion that OSPF is superior to IGRP and EIGRP. (Neha Grang, 2013) However, the presented comparative table regarding the comparison with IS-IS only presents differences in the type of the hierarchy format, the Dead Timer times and the metric used, and no other supremacy 48

49 points are discussed. Thus, it is believed by the author of the current project, that this information is inadequate to lead to a conclusion about which protocol among OSPF and IS-IS is prime. More than that, another general research review paper about IGP and BGP protocols dedicates a part in the popular OSPF - IS-IS comparison. Except the disclosure of the main characteristics and differences of the two protocols, this research paper presents a brief comparison by showing some of their advantages and disadvantages. More specifically, the research suggests that in OSPF, routers may belong to multiple areas in comparison with IS-IS Intermediate Systems that belong to only one area, and this fact results in higher power consumption. Furthermore, it is noted that OSPF area boundaries fall on the routers where IS-IS area boundaries fall on the links, which could lead in higher delay times in the sending and receipt of the packets for the latter. Additionally, IS-IS is considered by the paper as more flexible because holding timers don t need to be identical on all routers. Finally, an argument is made which supports that OSPF is superior than IS-IS in security terms due to the fact that OSPF runs over IP. (Abdulrahman Alkandari, 2012) However, this statement is believed by the author of this project to be untrue, as IP is more vulnerable to various types of attacks and also is more popular and more hackers have better knowledge of it. Relatively recent research has been focused on the comparison of the OSPF and IS-IS protocols in terms of performance in ISPs IPv4 networks. This research notes the importance of selecting the right routing protocol to assure the temporal efficiency of a network in the distribution of data, as well as the superiority of dynamic routing protocols over static routing due to the fact that they are able to easily adapt network changes. The performance comparison of the two protocols has been conducted with the help of the OPNET modeler network simulator. More specifically, the same topology of 21 routers spread across different states of the USA, has been configured with each protocol one after the other in order to produce comparative metrics. The research aimed to produce results regarding the router and network and router convergence activities and duration times, as well as queuing delay times on point-topoint links. The results of the experiment showed that OSPF demands more network activity regarding the messages sent between the routers until the network has reached convergence, and also the network and router convergence duration times are 6 and 5 times higher than the ones of IS-IS respectively. In addition, in the specific experiment IS-IS presented much higher throughput than OSPF, with the second resulting in lower queuing delays than the first. (Thorenoor, 2010) The different metric results regarding convergence are possibly related to the hierarchical format that each protocol is using. More precisely, in OSPF internal routers in an area have to learn about routes to every possible destination, where internal IS-IS routers only need to know about the closest level 1/2 IS, speeding this way the network convergence procedure. Except that, IS-IS only requires the exchange of one LSP during the convergence procedure where OSPF demands many different LSA types to be exchanged between the routers. Although most of the research implies that IS-IS presents better characteristics and performance than OSPFv2, the performance of OSPFv3 should also be taken into account when comparing the two protocols, especially nowadays that IPv6 becomes a constant part of modern networks. One more motive for this research review, is that there is no published research about the IS-IS OSPFv3 performance in IPv6 49

50 networks. Based on this fact, researchers have conducted experiments to discover any performance improvements of OSPFv3 in comparison to OSPFv2. The experiments were implemented by using OPNET Modeler and by creating a simple OSPF topology including five areas, specifically two non-backbone areas and a backbone area, and five routers in total. Then, the same topology was configured separately with OSPFv2 on one occasion and OSPFv3 on the other, and performance metrics were calculated in order to compare the two protocols performance, by running 10 minutes simulations. In terms of convergence duration and amount of traffic sent, the two versions of OSPF presented similar results. As far as it concerns the LSDB size, measurements were taken according to the research on an internal router, and the results showed that OSPFv3 LSDB is 27% smaller than the OSPFv2 LSDB. Such behaviour can be explained due to the fact that OSPFv3 does not store any network addresses carried in Router LSAs in the LSDB. Moreover, even if IPv6 addresses are bigger than IPv4 ones, similar measurements were taken for memory consumption for both protocols, fact that may be explained by the facilitating role of the OSPFv3 Link LSA. However, OSPFv3 presents greater routing table sizes due to the inclusion of both global unicast and link-local unicast addresses, and it was also proved that it produces more updates than OSPFv2 in case of a router failure. (Chen Haihong, 2013) Eventually, this research suggests that OSPFv2 and OSPFv3 present similar performance and predicts that OSPFv3 will be one of the most popular routing protocols in the near future due to its effectiveness. Nevertheless, important metrics such as throughput and round-trip delay have not been measured in order to produce more clear results OSPF vs IS-IS on Dual-Stack As proved from the related research review of the previous section, the decision between selecting OSPF and IS-IS has been a matter that is puzzling the scientific and industry community for years. In terms of popularity it seems that IS-IS is mostly preferred by ISPs where OSPF is the most popular between the two in enterprise networks. Even though the topic is broadly discussed, it is believed that research has not focalized deeper into the subject. One explanation to this, is that both OSPF and IS-IS link-state routing protocols are considered effective so optimum performance comes of secondary priority. Another reason is possibly the fact that OSPF, being based on IP, is easier to understand by network engineers worldwide and thus technical education is giving weight to OSPF and supplants IS-IS. Therefore, in enterprise network deployments, companies prefer to use such a routing protocol for their networks, so that they can more easily recruit trained engineers to maintain them. As a result to these facts, although the academic research has given importance to the comparison of the structure, characteristics, pros and cons of OSPF and IS-IS, the actual experimental performance evaluation and comparison of the two is minimum, even for the present dominant IPv4 networks. It is believed that optimum performance should be one of the most important factors when selecting a routing protocol. As far as it concerns the results of the already curried out knowledge, opinions differ. However, IS-IS is mostly favored by researchers regarding its security, flexibility, scalability, power and resource consumption as well as its performance. On the other hand, in the opinion of the author of this paper, researchers that support OSPF s superiority over IS-IS, present rather poor arguments with the strongest being the capability of OSPF to inject external routes from any configured area. Nonetheless, further research should be carried under different networks, 50

51 topologies and traffic patterns in order to conclude to a rule for deciding between the protocols for different circumstances. The topic of the OSPF IS-IS battle becomes even more argumentative with the advent of IPv6, as the nature of the two protocols introduces more differences and benchmarks between the two. As mentioned in previous sections, OSPF had to be evolved to a brand new version OSPFv3. On the other hand, IS-IS only needed minor modifications, namely the addition of a couple of TLVs in order to support IPv6. This very contradiction can be the start of a brand new research circle regarding the two routing protocols performance. As far as it concerns OSPFv3 performance for IPv6 traffic, some research has been undertaken as well as comparison with other IGPs like EIGRPv6 and the older OSPFv2. However, as IPv6 is still under development regarding its deployment, research that could facilitate in the optimum decision between different IGPs is again in infancy. Especially, when it comes to IS-IS performance on IPv6, academic research approaches zero. This paper intends to trigger this kind of research, starting from the performance evaluation of the protocols in dual-stack environment. The time space until the complete domination of IPv6 may be vast and it is believed that scientific disquisition contribution should resonate to networks of the foreseeable future. Big companies that bestir themselves in the networking field, already organize seminars and publish white papers that discuss the comparison of OSPF and IS-IS under an IPv4/IPv6 coexistence environment and the considerations that should be taken when choosing between them. The two most important reasons that have revitalized the networking world s interest on this rather old debate, is firstly the improvements that OSPFv3 may offer and secondly the effect that the way of the two protocols deployment can have on performance and configuration ease. More precisely, there are two forms of deploying OSPF on dual-stack networks. The first one involves the configuration of OSPFv2 for processing IPv4 traffic and the exact configuration of OSPFv3 for IPv6 packets on the same network devices. The second form allows the use of OSPFv3 with Address Families capability, for processing both IPv4 and IPv6 traffic. This solution gives the advantage of running just one protocol in dual-stack networks. However, both those two ways of OSPF deployment on dual-stack, demands the implementation of two different routing instances running at the same time. As dual-stack networks are usually based on identical IPv4 and IPv6 topologies, the double instance solution leads to more CPU power demand, more bandwidth and memory utilization, as double sending of routing advertisement and double route calculation occurs. On the other hand, IS-IS configured on dual-stack networks, only employs one routing instance that is able to calculate both IPv4 and IPv6 routes simultaneously, saving this way resources. Similar considerations have already been made by networking groups in released Internet Drafts. (Manav Bhatia, 2006) Moreover, the Address Families OSPFv3 solution is still a new technique with limited vendor support. Although big networking companies such as Cisco and Juniper allow the configuration of Address Families, only brand new routing software versions are able to support the extension (e.g. Cisco IOS 15.1). This means that a company would need to update the routing software in all its routers to implement the solution, resulting in a possible non affordable cost. As a consequence, several companies nowadays reconsider the migration from OSPF to IS-IS in order to achieve bets performance, lower cost and take advantage of its benefits. 51

52 Within this framework, this paper intends to provide proof regarding the performance of the two protocols when configured on a dual-stack enterprise network. The results of this survey and experiments may be used as guidelines for companies in order to select the best performing protocol for their networks in the upcoming future. The paper also aims to bring again to the fore, the discussion on the subject, and lead to reconsideration regarding the old IS-IS for ISP networks OSPF for enterprise networks theorem Conclusion The Related Work chapter aimed to achieve a complete review of the research on the field, of the last five years. Firstly, scientific papers related to the different proposed IPv4 to IPv6 mechanisms were reviewed in order to draw conclusion about which is the most recommended solution by the scientific community and what are its advantages and disadvantages. As long as the dual-stack method was selected based on the general scientific opinion, its performance was compared to the one of other competitive mechanisms. Dual-stack performs better than them according to all performed recent research, thus it was selected as the background for the following experiments between the OSPF and IS-IS routing protocols. Review of the implemented academic research was also done for those protocols, by focusing on the strong - weak points and performance of them in IPv4 environments, with the general outcome of the review being the superiority of IS-IS. The lack of related research work on the comparison of OSPF and IS-IS in IPv6 and on IPv4-IPv6 coexistence networks was also noticed, and created the motivation for the network experiments that follow on the Implementation chapter. 52

53 3 Implementation 3.1 Simulation with OPNET This chapter of the paper is devoted to the performance evaluation and comparison of OSPF and IS-IS routing protocols in a dual-stack network. The method that was used to examine their functions and performance in a realistic environment was network simulation. More precisely, OPNET Modeler 14.5 was selected as the appropriate simulation program in order to conduct the experiments. OPNET Modeler and IT Guru are software programs created by OPNET Technologies Incorporation, a company that specializes in network simulator software used by universities and companies that need to simulate network environments and protocols for performance evaluation, testing and research. OPNET Modeler constitutes a network simulation program based on C and C++, which offers a convenient GUI in order to facilitate users to conduct network experiments. OPNET Modeler includes model libraries that represent various network hardware devices from many vendors and various communication protocols. Thus, the OPNET Modeler users are able to simulate large network environments with network devices and routing protocols of will, without the need of pursuing real equipment, saving this way cost. The specific program also gives the capability to add or modify existing models, and bases its simulations on the Discrete Event Simulation system which uses defined processes to model network events. Additionally, traffic patterns can be simulated by the use of network layer traffic flows, by well-defined applications or by transport layer application demands. The sequence of the needed acts needed for a network simulation, includes the design and configuration of the network topology, the selection of the desired measured metrics, the simulation run and the analysis of the calculated statistics. Eventually, OPNET Modeler is considered a reliable program when it comes to network evaluation, usually met on computer networking publications and also used by industry. These advantages of the program led the author to select it as the tool to facilitate the intended experiments. Figure 16 - OPNET Modeler 14.5 Opening Screen 53

54 3.2 Calculated Performance Metrics Using OPNET Modeler the performance of OSPF and IS-IS on a dual-stack network will be evaluated by calculating and comparing network performance metrics. Performance metrics are values that can be measured and give clues about the speed, the scalability, the adaptability to changes and the overall capacity and capability of the network. OPNET Modeler allows the measurement of several metrics and the production of statistics that can lead to conclusions regarding the performance of the network when using one or the other routing protocol. OPNET Modeler itself divides the available metrics to Global, Node and Link metrics, where the first concern the overall network function and the other two are measured on specific network nodes or links. For the needs of the experiments, the overall performance metrics that were measured were divided in two additional sub-categories, the pure network metrics and the end-to-end Quality of Service metrics. Both categories and the specific metrics that they include are deeper explained below. Pure Network Metrics: As pure network metrics are described in this paper the network performance metrics that are measured on the initial network topology when no traffic is implemented or when the traversing traffic does not have an effect on them. These metrics values remain the same regardless of the application and traffic rates that are running on the network. Metrics of this type can give an overall view of the performance of the configured routing protocols configured on the network, and depend on the specifically selected topology. During the experiment conduction of this project, the following pure network metrics were calculated: Convergence Duration: In routing protocol terms, convergence is the state that routers configured with a dynamic routing protocol reach, where they all have the same topological knowledge of the network or AS that they run on. Different routing protocols follow different procedures until they converge. In any case, the convergence state represents the phase where the appropriate information have been exchanged between participating routers, routing tables have been built, and thus, all routers are in stable state and can begin routing. The time needed for a network configured with a routing protocol in order to reach convergence is called convergence duration. Convergence duration can lead to conclusions about the protocol s speed, because the sooner convergence is achieved, the sooner data can be forwarded. Furthermore, convergence duration can indicate how fast a network can return to a functioning stable state after a link or router failure has occurred. Convergence Activity: Based on the above mentioned information, convergence activity can also be measured in order to show the timestamps during the experiment, where convergence procedure routing information is being exchanged between the network s nodes. The importance of this metric is similar to this of the convergence duration metric. Routing Table Size: Another metric that can be calculated on the initial pure network topology, is the routers routing table size. This metrics literally shows the number of route entries that a routing table holds. This specific value can also give a hint about the routing protocols speed. As routers search their routing tables sequentially when seeking an available route to forward a packet, a routing protocol that introduces less entries in the routing table, will self-evidently achieve a higher routing speed. Again, the routing table size is 54

55 depending on the size of the topology and not on the type or amount of sent traffic. End-to-End QoS Metrics: Apart from the pure network metrics, network performance evaluation demands the measurement of metrics that have to do with the actual performance of the network when transferring data. In order to achieve a realistic network simulation, traffic flows have to be emulated. The end-to-end QoS metrics concern the reaction, speed and efficiency of the routing protocol configured network, when specific type of traffic is forwarded from a source to a destination. During the experiment conduction of this project, the following end-to-end QoS metrics were calculated: Throughput: Throughput is one of the more important and common network performance metrics. Measured in bits/sec or in packets/sec, it represents the amount of bits or packets that are successfully transferred over a link. High throughput values indicate efficient network function as packets sent reach their destination without being dropped and retransmitted for various reasons. Low throughput on the other hand shows lower speed and more utilization of the network capacity. End-to-End Delay: Another metric exactly corresponding to network speed, is end-to-end delay. This metric is calculated for every client-server pair where a traffic flow is running between them. End-to-end delay is measured in seconds and represents the actual time passed from the creation of the packet until its receipt at the destination. Obviously, lower end-to-end delay values indicate a better network performance. The lower the end-to-end delay, the faster the receipt of a packet. End-to-End Delay Variation: This metric, also known as jitter, refers to the dispersion of delay between different IP packets of a traffic flow. An average value for this metric can be calculated for every client-server peer group. Obviously, high jitter is not desirable and it has a negative effect especially on UDP traffic and real-time applications. CPU Utilization: CPU utilization actually represents CPU overhead. A routing protocol can be evaluated based on this metric, according to the burden that it applies to the participating routers. The CPU utilization metric in OPNET Modeler shows the percentage of the CPU part that deals with IP packet forwarding. High CPU utilization values can lead to latencies as well as in dangers such as a router overload and failure. (Adarshpal S. Sethi, 2013) 3.3 Simulation Scenarios Dual-Stack Baseline Topology The network simulations performed in the within the scope of this paper aimed to emulate the function of an IPv4/IPv6 dual-stack network topology when configured separately with OSPF and IS-IS routing protocols. As discussed in previous chapters. OSPF was decided to run in two instances, OSPFv2 for IPv4 and OSPFv3 for IPv6, in order to correspond to the majority of the modern company networks, and the equipment and routing software version that they afford. IS-IS on the other hand was configured as a single instance for both IP protocols. Additionally, as general OSPF- IS-IS performance comparison research has been already performed in ISP networks, it seemed appropriate to conduct the experiments in an enterprise size network in 55

56 order to produce results that reflect to a large part of today s company networks. In addition, the enterprise network choice was dictated by the need to further investigate the convention of using IS-IS for ISP networks and OSPF for enterprise networks. Therefore, the Enterprise option was selected when deciding the size of the simulated network topology, with an actual area of 100 km 2. This option is showed in the following figure. Figure 17 - Enterprise Network Topology Option For the needs of the experiment a baseline small enterprise network topology was configured. As both OSPF and IS-IS are hierarchical routing protocols, a network topology consisting of three areas was designed, so that it could simulate a similar routing scenario for each one of them. The baseline topology obeyed to the commonly used in enterprise networks, Cisco three-layer hierarchical model, although the very specific functions of this model such as the security options of the distribution layer and the connectivity to the Internet by the core layer are not in the scope of this paper. Eight Cisco 7200 routers were selected for the simulation, as Cisco hardware is usually preferred by a large amount of businesses, and the connections between them were selected to be serial Digital Signal 3 (DS3) links supporting a 45 Mbps bandwidth. As is usual in enterprise networks, the access layer of the topology that is used to connect the end-devices to the main network was linked with the Distribution Layer by using Fast Ethernet 100Mbps links. Moreover, the two subnets in the first area of the baseline topology included four hosts each (OPNET ethernet_wkstn_adv model), and the two subnets of the second area included one Server each (OPNET ethernet_server_adv) for the needs of the experiments. All those end-devices were offered connectivity to the access layer routers by four simple Cisco Catalyst 2940 Layer 2 switches. OPNET Modeler makes able the addition of hardware by the use of its Object Palette that is shown in the following figure. Figure 18 - Object Palette Utility 56

57 Regardless, of the configured routing protocol, the concept of the experiments was based on the initial idea of designing a completely dual-stack network. Therefore, all participating routers and servers were configured manually with both IPv4 and IPv6 addresses. Regarding the IPv6 addresses, the link-local unicast addresses were assigned automatically, where the global unicast addresses were set manually in a non-eui64 format in order to facilitate the author s troubleshooting. On the other hand, the intention of the author regarding the hosts was different. In order to ensure that the produced results would reflect a dual-stack network in which both IPv4 and IPv6 traffic is transferred, and in order to be able to measure the QoS performance depending on the two types of IP traffic, one subnet was configured as IPv4-only and the other as IPv6-only. This specific design, gives the ability to produce pure IPv4 an IPv6 traffic running simultaneously through the network, and at the same time to examine separately the performance depending on the IP version. The following figure shows the baseline topology that was used for both OSPF and IS-IS experiment scenarios. As seen in the figure, OPNET Modeler offers various visualization options in order to facilitate understanding. Specifically, in the following figure, the different address type of each link is colored, namely IPv4-only links are colored blue, IPv6- only links are colored green and dual-stack links are colored orange Traffic Design Figure 19 - Baseline Topology Apart from the traffic-less network experiments that were conducted in order to measure the pure network metrics for each routing protocol scenario, the dual-stack network in each case had to be stress tested with data traversing its links. As the paper aims to give a general but thorough overview of the OSPF and IS-IS performance on a dual-stack network, it seemed appropriate to conduct simulations for both TCP and UDP traffic patterns. This way, possible differences in performance when different transport layer protocol data is used can be discovered, and moreover, the simulations can produce results that correspond to a bigger range of commonly used applications. For this reason, the application_demand option was selected from the Object Palette. This option allows the configuration of TCP or UDP traffic flows from a client to a 57

58 destination. The QoS of each one of them was measured for the IPv4 and IPv6 subnets respectively. In order to achieve this, application demand flows were configured from every single IPv4-only host to the first dual-stack server, and also from every IPv6-only host to the second dual-stack server. TCP and UDP flows were implemented in two separate scenarios on the baseline topology. This decision offered the ability to afterwards configure OSPF and IS-IS and examine the performance of IPv4 and IPv6 traffic as well as TCP and UDP traffic for each one of them. Eventually, the discussed application demands are also visualized by OPNET, as blue dotted lines. By editing their attributes, options such as the Transport Layer protocol, the Duration, Request, Response and Traffic parameters can be modified. Although the evaluation of all different applications is not in the scope of this paper, it was decided to generate traffic that mimics modern enterprise networks traffic patterns. Thus, research was advised in order to determine the TCP and UDP packet sizes and distribution functions. Based on the recent research, 44% of the total data packets in enterprise networks are smaller than 100 bytes and 37% of the total traffic consists of packets close to 1500 bytes. According to this statistic, traffic patterns follow a bimodal distribution with the majority of the packets having the mentioned sizes. As OPNET doesn t give the option of bimodal traffic distributions, half of the clients were set to constantly produce 100 bytes TCP or UDP requests, and the other half were set to produce 1500 bytes ones, in order to emulate the common traffic pattern. (David Murray, 2012) The responses of each server were sized to the mean 736 byte value. Furthermore, traffic transmissions were set to begin at the 100 th second and finish at the end of the simulation. As far as it concerns the TCP/UDP request creation rate, it was configured to be based on an exponential distribution with a mean value of 100 requests per hour, in order to evaluate the protocols performance when traffic keeps increasing. The following screenshots presents an example of an application demand s attributes. Figure 20 - Application Demand's Attributes In addition, the following figure shows the baseline topology when configured with TCP application demands including only discrete traffic, as explained above. The corresponding topology for UDP demands looks identical. 58

59 Figure 21 - Application Demand Enabled Baseline Topology OSPF Dual-Stack Topology Having designed the baseline topology and the traffic patterns, the two debated routing protocols were configured for every possible scenario. Firstly, OSPF was implemented on the network topology in three different scenarios: one for no traffic, one including only TCP traffic and one including only UDP traffic. For reasons explained on previous chapters, every network router was configured with two instances of OSPF, an OSPFv2 instance for creating the IPv4 stack and an OSPFv3 instance for the IPv6 stack. In order to assure this, the IPv4 Unicast Address Family was assigned to the OSPFv2 instance and the IPv6 Unicast Address Family to the OSPFv3 one. Although OPNET Modeler offers automatic routing protocol configuration options, it was decided to manually configure OSPF instances and areas in order to gain complete control and avoid machine misconfigurations. Router IDs however were left to be auto-assigned. An example of this activity is shown in the following figure that presents the OSPF attributes of one of the network s routers. Figure 22 - Router OSPF Instances Configuration 59

60 It has to be noted here that the router interface that connects the IPv4-only subnet was selected to run only OSPFv2 and the router interface that connects the IPv6-only subnet was selected to run only OSPFv3, so that no unnecessary traffic is sent to the subnets. This is the only modification made to the behavior of the protocol. Based on the aims of the project, OSPF and IS-IS were measured based on their default design with minimal tuning performed, for example the cost value was set to default. Appropriate modifications and tuning may result in better results on metrics for one or the other protocol and mislead to incorrect conclusions, so this option was avoided during the practical part of the project. As far as it concerns the OSPFv2 and OSPFv3 network configuration, it was assumed that they are set in identical topologies. According to this fact, the baseline topology was divided for both routing instances in three areas. The following figure captures the OSPF topology, and is sketched in order to visualize each area. More specifically, Routers 1, 2 belong to area 1, Routers 7, 8 belong to area 2 and Routers 4, 5 belong to the backbone area 0. Routers 3 and 6 are ABRs and thus belong to both areas 1, 0 and areas 2, 0 respectively IS-IS Dual-Stack Topology Figure 23 - OSPF Topology and Areas Similarly to the OSPF case, the baseline topology was also configured with one single instance of IS-IS. Again, three separate scenarios were created, one with no-traffic, one with TCP traffic demands and one with UDP ones. This time however, except the manual assignment of IPv4 and IPv6 addresses, NET addresses had to be assigned on all participating routers. Simple addresses such as were used in order to ease configuration. It is reminded here, that the area in which a router resides is based on its NET address. Based on this fact, Routers 1, 2, 3 belonged to area , Routers 4, 5 to area and Routers 6, 7, 8 to area Furthermore, each router had to be configured according to its role with a Level type. Thus, Routers 1, 2, 7, 8 which connect to end-devices were configured as Level 1, Routers 4, 5 were configured as Level 2, and Routers 3, 6 which connect areas and to the area were configured as Level 1-2. The following 60

61 figure shows OPNET window that allows the IS-IS parameters configuration on the routers. Figure 24 - Router IS-IS Instance Configuration The cost was set again to default for IS-IS, and the only modification done was to set the circuit type of the links to level 1 between level 1-2 and level 1 routers, and to level 2 between level 1-2 and level 2 routers in order to avoid unnecessary neighbor relationships between the routers. Below is presented the sketched IS-IS topology including the set areas Node Failure Addition Figure 25 - IS-IS Topology and Areas Having set the above mentioned scenarios, an extra utility was added in each OSPF and IS-IS TCP and UDP scenario in order to determine the behavior of the protocols in the case of a router failure. OPNET Modeler allows the user to set the exact 61

62 timestamps when a selected router fails and recovers. Therefore, for the needs of the experiments, Router 4 that belongs to the backbone OSPF area and IS-IS accordingly was set to fail at the 3600 th, th, and th second of the 24 hours total simulation. The failures were assumed to last 1 hour, so the timestamps when the router recovered from the failure were set to the 7200 th, th, and th second accordingly. Such simulation gave the opportunity to examine the time that the dualstack networks need to get back to stable functional state depending on the routing protocol and type of traffic, by measuring average convergence duration times. It is noted that the selection of Router 4 was made based on the fact that such a failure literally interrupts all traversing data flows. The OPNET utility is called Failure Recovery and can be found in the Object Palette. The following figure shows the mentioned tool Simulation Parameters Figure 26 - Failure Recovery Option After setting and configuring the appropriate simulation OSPF and IS-IS scenarios for no traffic, TCP and UDP traffic and router failure cases, the parameters of the simulation procedure were set. Firstly, the intended to measure Global, Node and Link metrics that were described previously, were selected from the DES Choose Individual Statistics menu, which is shown below. Figure 27 - Individual Statistics Selection Afterwards, the optimized simulation kernel which guarantees an optimized fast execution of the simulated scenarios was selected. Furthermore, the choice related to the simulation time was based on the desired measurements in each scenario. More 62

63 specifically, in the traffic-less scenarios the simulation time was set to 10 minutes, as the metrics calculated were convergence duration and activity as well as routing table sizes, which are determined clearly on the first few seconds of the simulation. On the other hand, for the TCP/UDP traffic scenarios, the simulation time was set to 24 hours. This choice was dictated by the fact that more accurate results would be gathered after a plausible time space, as QoS metrics values stabilize after the convergence procedure has finished. It is emphasized that a respectable number of simulations where run for every scenario. In every case, the produced results were identical, as the traffic patterns follow the same mathematical distribution, and thus, the results that are presented in the following chapter are derived from one experiment that is representative of all run simulations. The simulation parameters were chosen from the following menu. Figure 28 - Simulation Parameters Results Introduction This section presents the results that were produced by the simulations in all selected simulation scenarios. The presented diagrams derive from the exact OPNET Modeler output No Traffic, Fully-Functional Scenarios The following simulation results diagrams correspond to the OSPF and IS-IS identical fully-functional topology scenarios when configured with no traffic running the dualstack network. It is noted here that red colored lines reflect the OSPF scenarios results where blue lines reflect the IS-IS ones, in order to ease the results reading. As mentioned, these two scenarios were simulated for 10 minutes. 63

64 General Metrics Convergence Activity Figure 29 - OSPF and IS-IS Convergence Activity (No Traffic) The above diagram shows that the network activity that corresponds to the convergence procedure is completed in less than 10 seconds when IS-IS is configured, where in the OSPF scenario, it approaches 1 minute. The following diagram presented gives a more precise view on this fact. Convergence Duration Figure 30 - OSPF and IS-IS Convergence Duration (No Traffic) 64

65 This diagram confirms the convergence activity time results. More specifically, IS- IS s blue dot indicates that its convergence duration is 5.4 seconds, where the OSPF s red dot is set to 49 seconds. This means that OSPF converges in more than 800% increased time than IS-IS, which constitutes a massive difference. This result s reflection to the actual network performance, is that routing in a newly configured IS- IS network will be able to start 8 times faster than in a newly configured OSPF network, fact that adds to the overall speed of the routing protocol. Routing Tables Size Figure 31 - Average Backbone/Level 2 Router Routing Table Size (No Traffic) Figure 32 - Average ABR/Level 1-2 Router Routing Table Size (No Traffic) 65

66 Figure 33 - Average Internal/Level 1 Router Routing Table Size (No Traffic) During the traffic-less OSPF and IS-IS dual-stack network simulation scenarios, routing table sizes were also calculated. As shown in the above diagrams, measurements were taken in representative Backbone, ABR and Internal routers for OSPF, and in representative level 2, level 1-2 and level 1 routers for IS-IS accordingly. The metrics were measured in all different types of routers in order to draw conclusions for the overall behavior of the protocols regarding the routing table size, as each type of router contains a different number of route entries dictated by each protocol s foundational function. From the results it is obvious that the ABR and level 1-2 routers have similar routing table size, due to the fact that in both OSPF and IS-IS these types of routers have similar functions and shoulder the responsibility of storing each available route for other areas destinations. However, the OSPF backbone router presents a slightly higher average routing table size than the corresponding IS-IS level 2 one, and the OSPF Internal Router holds almost double route entries than the corresponding IS-IS level 1 router. The latter is explained by the default function of IS-IS areas that behave like OSPF totally stubby areas, as level 1 routers only have knowledge of the routes to destinations in their area. Although, the above presented results examine only the default OSPF and IS-IS network behavior, and although routing table size is not considered the metric which has the most effect in network comparison, IS-IS can be considered faster than OSPF depending on these values too. The importance of this advantage would me more obvious in a larger topology with a greater number of routes, as routers have to perform a top-down sequential check in their Routing Table in order to choose the appropriate next-hop destination when forwarding a packet. Due to this fact, searching a larger routing table can introduce latency. 66

67 TCP Traffic, Fully-Functional Scenarios The results presented in this chapter were based on two separate scenarios for each one of the debated routing protocols. More specifically, the first scenario was configured with all nodes being fully functional for the complete simulation time, where the second scenario introduced a backbone/level 2 router failure and recovery at specific timestamps as explained previously in the chapter. However, all those simulation scenarios included the same TCP-only traffic patterns and were run for 24 hours. Additionally, it is mentioned here that the measured metrics for the fullyfunctional-nodes case belong to the end-to-end QoS metrics category, with the design of the topology offering the ability to calculate different results for IPv4-only and IPv6-only traffic over the dual-stack network. As an addition to these, CPU utilization was measured on the backbone/level 2 routers that forward the total of the data traffic. On the other hand, on the node-failure scenarios, the author was interested only in the OSPF and IS-IS convergence duration accordingly in order to determine the time that each protocol needs to become operational after a node failure. For the facilitation of the results reading, it is noted that red lines correspond to the OSPF scenario and the blue lines correspond to the IS-IS scenario, except the cases that is stated different in the diagrams explanation General Metrics CPU Utilization Figure 34 - Average Backbone/Level 2 Router CPU Utilization (TCP Traffic) The above diagram shows the CPU utilization of Router 4, a backbone router in the OSPF scenario, and Level 2 router in the IS-IS one. As it can be seen, OSPF presents higher CPU utilization values than IS-Is in the start of the simulation, when convergence procedures are in progress. This may be based on the fact, that the OSPF backbone router, unlike IS-IS, runs two different routing instances, increasing this way the CPU overhead. However, after 24 hours of simulation the CPU utilization values for the two protocols seem to almost match, with the OSPF scenario presenting 67

68 slightly lower CPU utilization. In both cases the CPU utilization stabilizes to % for OSPF and to % for IS-IS, rather low values which would be much higher in a more realistic and traffic demanding network. However, OSPF seems to perform moderately better than IS-IS in terms of CPU utilization, in TCP traffic dual-stack environments. This OSPF advantage may be beneficial in larger and more stressed topologies, adding this way to speed and minimizing the danger of a node failure or overload. Nevertheless, according to the theoretical knowledge, these results are possibly reversed in larger networks with bigger amounts of traffic IPv4 Traffic Metrics The following results were measured at the Dual-Stack Server 1 which serves the IPv4-only clients of the network. Consequently, they reflect the dual-stack network performance for IPv4 TCP traffic flows, for each of the two routing protocols. Throughput Figure 35 - IPv4 Throughput (TCP Traffic) The above diagram reveals a huge differentiation between IS-IS and OSPF dual-stack network when running TCP traffic. Namely, in the long run, IS-IS achieves a throughput of more than 190 bps where OSPF touches 120 bps in the end of the simulation where stabilization has been reached. In percentages, this means that IS-IS presents at least 58% increased throughput than OSPF s one. As throughput constitutes a key metric when determining network performance, IS-IS can be considered to perform very much better than OSPF in terms of successfully delivered packets, fact that minimizes packet retransmissions and congestion, and improves the total network speed. 68

69 End-to-End Delay Figure 36 - OSPF IPv4 Clients End-to-End Delay (TCP Traffic) Figure 37 - IS-IS IPv4 Clients End-to-End Delay (TCP Traffic) The above results diagrams present end-to-end delay measurements for the four IPv4 hosts of the dual-stack network. The first diagram belongs to the OSPF scenario where the second belongs to the IS-IS one. From the produced results it can be seen that each host s traffic flows suffer from a different end-to-end delay value, in both scenarios. This behaviour is possibly based on the fact that the dual-stack networks are based on the Best-Effort QoS model, which functions with First-In-First-Out (FIFO) queues. Router FIFO queues give priority to the traffic that first reach them, so this end-to-end delay variation can be explained by the fact that each host sends traffic with a small time difference which defines the priority that they are offered. Another 69

70 reason for this differentiation is the configured of the TCP packets, as the 1500 bytes long ones may need to be fragmented, adding delay to the total end-to-end delay. Furthermore, after 24 hours of simulation, end-to-end delay values stabilize to constant value, allowing the author to calculate a mean value of the metric to facilitate the OSPF IS-IS comparison. More precisely, the mean IPv4 end-to-end delay for OSPF is calculated to approximately 1.6 ms, same as the IS-IS the mean value. From this measurements, it can be assumed that OSPF and IS-IS perform similarly in terms of end-to-end delay. End-to-End Delay Variation (Jitter) Figure 38 - OSPF IPv4 Clients End-to-End Delay Variation (TCP Traffic) Figure 39 - IS-IS IPv4 Clients End-to-End Delay Variation (TCP Traffic) 70

71 Similarly to the end-to-end delay results that were presented, the above diagrams show the jitter values for every IPv4 hosts in the OSPF configured dual-stack network firstly, and the IS-IS configured dual-stack network secondly. The same explanation as for end-to-end delay variation between different hosts, responds also for the jitter case. Again, mean values were calculated for the OSPF and IS-IS scenario. These computed mean jitter value for both OSPF and IS-IS equal approximately 0.4 ms. Consequently, both protocols seem to behave the same as far as it concerns IPv4 TCP traffic jitter IPv6 Traffic Metrics Similarly to the IPv4 hosts, identical metrics were measured for the IPv6 hosts of the dual-stack network. This time, the measurements were taken on the Dual-Stack Server 2 which is set to receive the TCP traffic flows of the four IPv6 hosts, so the results give a view of the dual-stack network when traversing IPv6-only traffic for the different configured routing protocols. Throughput Figure 40 - IPv6 Throughput (TCP Traffic) A similar picture to the one presented for the IPv4 traffic is also revealed for IPv6 traffic, when it comes to incoming throughput at the receiving server. Although both routing protocols have a lower throughput compared to the IPv4 one throughout simulation, the IS-IS throughput value tends to match with the presented IPv4 throughput value in the end of the experiment reaching 180 bps. On the other hand, OSPF presents significantly lower throughput with its value falling down to 70 bps. For the OSPF IS-IS comparison, this fact means that IS-IS has again 157% increased throughput compared to OSPF throughput for IPv6 TCP traffic flows, a much greater performance. 71

72 End-to-End Delay Figure 41 - OSPF IPv6 Clients End-to-End Delay (TCP Traffic) Figure 42 - IS-IS IPv6 Clients End-to-End Delay (TCP Traffic) Using the same method as with IPv4 traffic, end-to-end delay mean values were computed from the four IPv6 peer groups, for both OSPF and IS-IS protocols, by advising the stabilized values shown in the above diagrams. The resulting mean for both routing protocols equals 1.7 ms, leading to the conclusion that OSPF and IS-IS present similar performance regarding delays for IPv6 TCP traffic. 72

73 End-to-End Delay Variation (Jitter) Figure 43 - OSPF IPv6 Clients End-to-End Delay Variation (TCP Traffic) Figure 44 - IS-IS IPv6 Clients End-to-End Delay Variation (TCP Traffic) As seen in the above diagrams, jitter for every IPv6 client was also measured on the Dual-Stack Server 2 for OSPF and IS-IS scenarios. Computing the mean values of the four IPv6 clients for each case, it was found that the mean OSPF IPv6 jitter equals 0.39 ms and IS-IS IPv6 jitter equals 0.41 ms. Like the corresponding IPv4 measurements, it can be assumed OSPF performs insignificantly better than IS-IS in terms of jitter, and that IPv6 jitter in general close to IPv4 jitter. 73

74 TCP Traffic, Router 4 Failure Scenarios General Metrics Convergence Duration Figure 45 - OSPF and IS-IS Average Convergence Duration (TCP Traffic) The above presented results, show the OSPF and IS-IS convergence behaviour when a Backbone/Level 2 router fails and recovers three times during the simulation. From the experimental results it can be seen that both protocols tend to converge faster than their initial convergence duration, in the long run. Especially OSPF convergence duration decreases dramatically each time it needs to converge. Nevertheless, IS-IS achieves a minimum convergence duration of 1 second, where OSPF s one reaches a 20 seconds minimum value. In this case, OSPF still has a 1900% increased convergence duration time compared to IS-IS, so it can be considered to perform immensely worse than the latter even in realistic long term failure-recovery scenarios. 74

75 UDP Traffic, Fully Functional Scenarios In a similar fashion as presented in the TCP Traffic Scenarios chapter, identical experiments with the same simulation parameters where also conducted for UDP-only traffic patterns. The results of these simulation can give clues about the performance comparison of OSPF and IS-IS when UDP applications dominate the dual-stack network. This way, conclusions can be drawn about the availability of each routing protocol for modern real-time applications. Again, except stated otherwise, blue lines in the following diagrams reflect IS-IS scenarios and red lines reflect the OSPF ones. Additionally, it is mentioned that this chapter mimics the presentation sequence of the corresponding TCP traffic simulation chapter General Metrics CPU Utilization Figure 46 - Average Backbone/Level 2 Router CPU Utilization (UDP Traffic) As shown above, OSPF and IS-IS present almost identical CPU utilization on the backbone/level 2 Router 4 when running on a dual-stack network which forwards UDP traffic, reaching a % CPU utilization for the specific traffic loads. Approaching the TCP traffic scenarios, OSPF and IS-IS seem to perform similarly in terms of CPU utilization but safer results could be drawn in a more traffic stressed network IPv4 Traffic Metrics The following results were again measured at the Dual-Stack Server 1 which serves the IPv4-only clients of the network. Consequently, they reflect the dual-stack network performance for IPv4 UDP traffic flows, for each of the two routing protocols. 75

76 Throughput Figure 47 - IPv4 Throughput (UDP Traffic) The above diagram indicates that IS-IS dominates over OSPF in terms of throughput for IPv4 UDP traffic flows achieving again a 42% increased throughput value compared to OSPF. In numbers, IS-IS has a throughput of approximately 200 bps, where OSPF reaches 140 bps, corresponding to a much less percentage of successfully received packets. End-to-End Delay Figure 48 - OSPF IPv4 Clients End-to-End Delay (UDP Traffic) 76

77 Figure 49 - IS-IS IPv4 Clients End-to-End Delay (UDP Traffic) The above produced results indicate that IPv4 UDP end-to-end delay times for OSPF and IS-IS routing protocols are again almost identical. The mean end-to-end delay time computed from the values of the four different IPv4 hosts, equaled 1.9 ms for the OSPF and IS-IS scenarios. Consequently, it can be said that both protocols perform similarly regarding delay times. End-to-End Delay Variation (Jitter) Figure 50 - OSPF IPv4 Clients End-to-End Delay Variation (UDP Traffic) 77

78 Figure 51 - IS-IS IPv4 Clients End-to-End Delay Variation (UDP Traffic) Regarding jitter, which is a metric of high importance for UDP based applications, the mean values calculated from each one of the above diagrams equaled approximately ms for both OSPF and IS-IS. As seen, OSPF and IS-IS jitter values almost match in the long run of the simulation IPv6 Traffic Metrics This section presents the results when the same metrics were measured at the Dual- Stack 2 Server of the dual-stack network, in order to define OSPF and IS-IS performance for IPv6 UDP traffic patterns. Throughput Figure 52 - IPv6 Throughput (UDP Traffic) 78

79 From the above experimental results, the conclusion is that IS-IS achieves a 125% increased throughput compared to OSPF s respective value, having a value of 180 bps in comparison to OSPF s 80 bps. As concluded in all previous throughput measurements, IS-IS shows superiority over OSPF in terms of throughput. End-to-End Delay Figure 53 - OSPF IPv6 Clients End-to-End Delay (UDP Traffic) Figure 54 - IS-IS IPv6 Clients End-to-End Delay (UDP Traffic) As far as it concerns IPv6 UDP end-to-end delay, the mean values derived from the above diagrams equalled approximately 2 ms for OSPF and IS-IS. Like previous endto-end delay calculations, both protocols perform equally. 79

80 End-to-End Delay Variation (Jitter) Figure 55 - OSPF IPv6 Clients End-to-End Delay Variation (UDP Traffic) Figure 56 - IS-IS IPv6 Clients End-to-End Delay Variation (UDP Traffic) Finally, mean jitter values were calculated from the values derived from the quartet of IPv6 hosts for both routing protocols. OSPF s mean jitter value equalled 0.01 ms and the IS-IS s corresponding value equalled ms. As it is understood, OSPF and IS-IS protocols perform homogeneously as far as it regards UDP IPv6 traffic jitter on dual-stack networks, with IS-IS having a small precedence that could be indicative of an advantage in larger and more stressed networks. 80

81 UDP Traffic, Router 4 Failure Scenarios General Metrics Convergence Duration Figure 57 - OSPF and IS-IS Average Convergence Duration (UDP Traffic) As expected, in the Router 4 failure scenario, results are similar to the TCP traffic scenario, as the convergence activity is depending on the protocol fundamental functions and not on the traversing traffic. Thus, IS-IS converged again in almost 1900% faster time than OSPF Comprehensive Results The tables that follow are inclusive of all measured metrics for every simulated scenario and are introduced in order to facilitate conclusion exportation regarding OSPF and IS-IS performance comparison in dual-stack networks. Convergence Backbone/Level 2 ABR/Level 1-2 Internal/Level 1 Duration (sec) Routing Table Size (entries) Routing Table Size (entries) Routing Table Size (entries) OSPF IS-IS OSPF IS-IS OSPF IS-IS OSPF IS-IS No Traffic Fully Functional Scenario General Table 2 - Comprehensive Results for the No-Traffic Simulations TCP Traffic Minimum Convergence Backbone/Level 2 End-to-End Throughput (bps) Duration (sec) CPU Utilization (%) Delay (ms) Jitter (ms) OSPF IS-IS OSPF IS-IS OSPF IS-IS OSPF IS-IS OSPF IS-IS General Fully Functional IPv Scenario IPv Router Failure Scenario General 20 1 Table 3 - Comprehensive Results for the TCP-Traffic Simulations 81

82 UDP Traffic Minimum Convergence Backbone/Level 2 End-to-End Throughput (bps) Jitter (ms) Duration (sec) CPU Utilization (%) Delay (ms) OSPF IS-IS OSPF IS-IS OSPF IS-IS OSPF IS-IS OSPF IS-IS General Fully Functional IPv Scenario IPv Router Failure General 20 1 Scenario Table 4 - Comprehensive Results for the UDP-Traffic Simulations Experimental Results Analysis The previous chapter presented the results of the network simulations that were performed over a basic enterprise dual-stack network when configured with each one of the debated OSPF and IS-IS routing protocols. The network topologies and traffic patterns were designed in a way that could facilitate the measurement of various network performance metrics, for different Layer 3 packets (IPv4 and IPv6) as well as for different layer 4 segments (TCP and UDP), in order to have a detailed view on the performance of the routing protocols under different network conditions. Analyzing the results, it can be stated that the balance tilts in favor of IS-IS in almost all simulation scenarios. More precise considerations derived from the analysis of the produced experimental findings are presented below: Initial Convergence Duration and Activity: The produced initial convergence duration time of the dual-stack network when configured with OSPF, was found to be approximately 800% increased than the respective IS-IS value. A probable explanation to this fact is that IS-IS only uses a single Link-State PDU for each level, which carries the whole of the routing information during the convergence procedure. On the other hand, as written in the Theoretical Background part, OSPF demands the exchange of a series of LSAs in order to distribute route knowledge between routers, fact that introduces latency to the convergence activity. This disadvantage of OSPF becomes even greater in dual-stack networks, where different LSAs have to be sent for each of the OSPFv2 and OSPFv3 routing instances. Moreover, comparing these results to the ones of the published research on OSPF and IS-IS comparison in IPv4 ISP networks, it is realized that IS-IS has a fixed low convergence duration time of 5.4 seconds, where OSPF s corresponding metric is even higher in the current project simulations (49 seconds compared to 29 seconds of the related published work). (Thorenoor, 2010) The comparison with the previous research on the field can although be only indicative, as this paper is the first study on the performance of the protocols over dual-stack, and the topology size is also much smaller as it emulates an enterprise network. Eventually, based on the results, an IS-IS dual-stack enterprise network will be up and running in significantly less time than the corresponding OSPF network. Convergence Duration after a Router Failure: The time that a network needs to converge after a router or link failure is also a vital comparative measure, as failures happen continuously in real world networks. The effectiveness of a network to recover in a functional and ready to route state is a guarantee to minimum interruption of services. According to the produced simulation results, IS-IS achieves to converge up to 1900% faster than OSPF after a router failure, given the fact that both protocol convergence times are lower than the initial convergence duration times. The same explanation as in the previous metric implies here too. The reflection to real network 82

83 scenarios is that IS-IS manages to provide routing services much faster than OSPF when a router goes down. Routing Table Sizes: Regarding the Routing Tables Sizes, IS-IS demonstrated again lower values that could hasten the route lookup procedure and increase protocol speed. This originated from the fact that IS-IS areas have stub characteristics. Of course, this advantage reflects again only the default, without modification protocol functions. However, IS-IS performs better in this field too, especially in dual-stack where both routing protocols need to store routes for IPv4 and IPv6 destinations. CPU Utilization: The result of the CPU utilization measured metric was a surprise, as IS-IS and OSPF performed similarly for all TCP and UDP traffic scenarios. This was unforeseen, as OSPF was expected to demonstrate higher CPU overhead due to the fact that it runs an OSPFv2 protocol instance, as well as an OSPFv3 one, that should result in a double load on CPU. Nevertheless, results on CPU utilization may differ when larger topologies are implemented and larger amounts of traffic are traversed. End-to-End Delay and Jitter values: As far as it concerns end-to-end delay and jitter times, OSPF and IS-IS seem to be almost equally effective, for IPv4, IPv6, TCP and UDP traffic. Minor differences were presented in jitter for IPv6 traffic, as OSPF performs slightly better for TCP traffic and IS-IS performs slightly better for UDP traffic. Even from these small differentiations, IS-IS can be assumed to have a better potential performance, as low jitter is most important to UDP applications such as IP telephony and video conferencing. It is believed that IS-IS s potential advantage would be more obvious in larger network simulations with real-time application traffic emulation. Throughput: Regarding throughput, IS-IS dominated over OSPF on both TCP and UDP traffic experiments. In the first case, IS-IS achieved 58% higher throughput than OSPF for the IPv4 clients traffic flows, and 157% higher throughput for the IPv6 clients traffic flows. In the second case, OSPF seems to slightly minimize this difference but again, the corresponding IS-IS throughput values appear to be 42% and 125% increased to OSPF s values accordingly. These statistics give an important advantage to IS-IS compared to OSPF, as low throughput means a lower percentage of successfully delivered packets that can be interpreted to retransmissions, congestion and of course latency. It is noted, that analogous statistics were delivered from researchers when comparing the two protocols in larger IPv4 ISP networks, with the throughput values being different (more than 600 bps for IS-IS and less than 100 bps for OSPF), but with the same relative difference. In general, the produced simulation statistics show that IS-IS performs equally and in various metrics much better than OSPF when configured on a dual-stack enterprise network. This comes to add to the already published work about the two protocols comparison that favored IS-IS in most cases. The results of this paper s simulations should be taken under considerations by companies and organizations trying to create dual-stack networks in order to accommodate the IPv6 transition. Thorough conclusions will be included in the final chapter of the dissertation. 83

84 3.4 Conclusion The Implementation chapter was completely dedicated to the experimental practical work of the project. Initially, the simulation software that was used for the experiments was presented and its selection was justified. Subsequently, a theoretical background for the measured network performance metrics was given and the network topologies used during the simulations were presented. Moreover, a thorough presentation and justification of the different simulated network scenarios was reported, together with instructions on the way the simulation tool was exploited. Additionally, the exact result diagrams derived from the network simulator were presented along with a brief critical comment, and eventually, comprehensive tables including overall simulation results were created. Finally, explanation of the results impact in the OSPF and IS-IS dual-stack network performance was given in order to expedite the project s conclusions. 84

85 4 Conclusions 4.1 Evaluation of the Project Evaluating the dissertation project, it is believed that the main set aims and objectives were accomplished successfully, despite any obstacles that came up. Firstly, the recent published literature was reviewed in order to draw conclusions about the most used and recommended IPv6 transition strategy. Although, experiments were not performed on the different mechanisms performance, as this constitutes a research field of its own, research recommendations and performance comparisons were examined in order to produce a comparative table including the pros and cons of each technique, which lead to the conclusion that dual-stack is the most recommended, best performing and most wide-spread method. As far as it concerns the literature review about the OSPF and IS-IS performance evaluation, several difficulties were met during the project s research. One important barrier to the progress, was the fact that the research on routing protocols performance comparison over IPv4-IPv6 coexistence environments was minimal, and specifically research related to OSPF and IS- IS approached zero. Consequently published scientific work review on the OSPF IS-IS comparison was limited to studies regarding theoretical contrast of the two protocols based on their fundamental functions, and on a single paper that refers to the performance evaluation of the two protocols over IPv4 ISP networks. Nevertheless, the lack of similar research over IPv6, IPv4-IPv6 coexistence networks as well as over enterprise networks, confirms the importance of the project s conducted experiments and their contribution to the scientific research. Regarding the experimental part, configuration of the dual-stack topologies for OSPF and IS-IS protocols was implemented without issues. A large part of the simulation measured metrics analogy between the two protocols, matched the performance ratio discovered from previous research over IPv4 networks, fact that enhances the validity of this project s results. However, the supremacy of IS-IS in terms of end-to-end delay and CPU utilization that was assumed when examining the published literature, was not confirmed by the project s simulation, as OSPF and IS-IS demonstrated almost equal results. Especially, the CPU utilization should be much lower in IS-IS due to the fact OSPF employs two routing instances in order to work in dual-stack. Regarding this mismatch it is assumed that the simplified enterprise network topology that was used for the experiments may have introduced limitations that affect these metrics results, as differentiation between the two protocols may appear only in larger networks and more intensive traffic patterns. In general, IS-IS performed better than OSPF on the dual-stack network no matter the selected traffic, as expected from previous research. Based on the findings and the past research conclusions, IS-IS can be recommended for 85

86 either fresh configuration or migration from OSPF in enterprise dual-stack networks. Moreover, it is believed that this paper can be a starting point for further research on routing protocol comparison over IPv4/IPv6 or IPv6-only environments, as it presents original experimental results on a field where research is at its very beginning. 4.2 Overall Outcome Overall, this dissertation through literature review and experimental analysis proved that IS-IS should be reconsidered as a more efficient solution than OSPF in the near future, as it demonstrates several performance benefits compared to the latter when configured in dual-stack enterprise networks. The Literature Review of the dissertation showed that the dual-stack migration mechanism will be the most common, and an integral part of the evolution to IPv6. New application demands need to be accommodated by the IPv4 - IPv6 networks that will constitute the new networking world for a non-predictable time space until the complete prevalence of IPv6, and thus, the effectiveness of the configured routing protocol will be of great importance. In this framework, the project presented results which imply that IS-IS converges much faster and achieves much higher successful delivery of packets than the competing link-state protocol OSPF. The selected simulated network topology size, and the fact that the experiment results demonstrated same analogies and contrasts for IPv4-only and IPv6-only clients, as well as for both TCP and UDP traffic, enhances the idea that the dawn of the IPv6 era should bring reconsideration regarding the selection of IS-IS for enterprise networks as a first choice. It is believed that the performance and security vantages that IS-IS offers especially for the IPv4- IPv6 coexistence period outweigh the theoretical understanding difficulties, and should be elements integrated in educational networking programs in order to familiarize potential new engineers. 4.3 Future Work As mentioned, the current dissertation project intends to be a start line for further experiments and research on the field. For the near future, the specific project could be enhanced with simulations on bigger network topologies and emulation of specific applications common in enterprise networks, such as HTTP, FTP, Voice and Video Conferencing, in order to check the scalability of IS-IS and OSPF and if the produced results also apply under more realistic environments. Moreover, due to the fact that the two protocols were tested on their default configuration, tests could also be performed with tuning and optimizing both protocols under different scenarios. The next step on future work should be the conduct of identical simulations but with only OSPFv3 with different Address Families enabled. Although, the vendor support on this option is still limited, and despite the fact that two different instances of OSPFv3 will still have to run simultaneously, it is an alternative choice to the implemented OSPFv2-for-IPv4 and OSPFv3-for-IPv6 solution that maybe can compete IS-IS. In a more general framework, OSPF, IS-IS as well as other effective routing protocols such as EIGRP can be tested for dual-stack, but also for other IPv6 transition techniques or a combination of some of them, as it is believed that such mixed 86

87 environments will be wide spread too. Finally, for the future, research should focused on the performance of the protocols on IPv6-only environments in order to facilitate readiness in selecting and further developing the appropriate routing protocol on time. 87

88 References A. Lindem, S. M. (2010, April). Support of Address Families in OSPFv3. Internet Requests for Comments, RFC Abdulrahman Alkandari, I. F. (2012). An Anatomy of IGP and BGP Routing Protocols International Conference on Advanced Computer Science Applications and Technologies. Abe Martey, S. S. (2002). IS-IS Network Design Solutions. Cisco Press. Adarshpal S. Sethi, V. Y. (2013). The Practical OPNET User Guide forcomputer Network Simulation. CRC Press. Callon, R. W. (1990, December). Use of OSI IS-IS for Routing in TCP/IP and Dual Environments. Internet Requests for Comments, RFC Chen Haihong, S. X. (2013). Simulation and Research of OSPFv3 Performance International Conference on Computational and Information Sciences. Dai, K. (2011). IPv4 to IPv6 Transition Research Based on the Campus Network International Symposium on Intelligence Information Processing and Trusted Computing. David Murray, T. K. (2012). The State of Enterprise Network Traffic in th Asia-Pacific Conference on Communications (APCC) (pp ). Jeju Island : IEEE. Doyle, J. (2005). Routing TCP/IP, Volume I, Second Edition. Cisco Press. Eiji Oki, R. R.-C. (2012). Advanced Internet Protocols, Services, and Applications. Wiley. Gough, C. (2003). CCNP BSCI Exam Certification Guide. Cisco Press. Hagen, S. (2006). IPv6 Essentials, 2nd Edition. O'Reilly. Hannes Gredler, W. G. (2005). The Complete IS-IS Routing Protocol. Springer. Hopps, C. (2008, October). Routing IPv6 with IS-IS. Internet Requests for Comments, RFC J. Arkko, F. B. (2011, May). Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. Internet Requests for Comments, RFC Jinesh Doshi, R. C. (2012). A Comparative Study of IPv4/IPv6 Co-existence Technologies. Retrieved from 88

89 John J. Amoss, D. M. (2008). Handbook of IPv4 to IPv6 Transition: Methodologies for Institutional and Corporate Networks. Auerbach Publications. Lammle, T. (2013). CCNA Routing and Switching Study Guide. Sybex. Loshin, P. (2004). IPv6 : theory, protocol, and practice, Second Edition. Morgan Kaufmann. Malhotra, R. (2002). IP Routing. O'REILLY. Manav Bhatia, V. M. (2006, January). IS-IS and OSPF Difference Discussions. Internet Drafts. Medhi, D. (2007). Network Routing: Algorithms, Protocols, and Architectures. Morgan Kaufmann. Moy, J. T. (1998). OSPF: Anatomy of an Internet Routing Protocol. ADDISON- WESLEY. Neha Grang, A. G. (2013). Compare OSPF Routing Protocol with other Interior Gateway Routing Protocols. International Journal of Engineering, Business and Enterprise Applications (IJEBEA), 13(147), pp Peng Wu, Y. C. (2013). Transition from IPv4 to IPv6: A State-of-the-Art Survey. IEEE COMMUNICATIONS SURVEYS & TUTORIALS, 15(3). Rick Graziani, A. J. (2008). Routing Protocols and Concepts, CCNA Exploration Companion Guide. Cisco Press. S. Deering, R. H. (1998, December). Internet Protocol, Version 6 (IPv6) Specification. Internet Requests for Comments, RFC Singh, N. (2013, November). A Review of IS-IS Intrarouting Protocol. International Journal of Emerging Science and Engineering (IJESE), 2(1). Thomas, T. M. (2003). OSPF Network Design Solutions. Cisco Press. Thorenoor, S. G. (2010). Communication Service Provider s choice between OSPF and IS-IS Dynamic Routing Protocols and implementation criteria Using OPNET Simulator. Second International Conference on Computer and Network Technology. Ting Ting Zhang, J. C. (2012). A Research on IPv6/IPv4-Based Network Performance Test. Procedia Engineering, 29, pp XiaoHong, L. (2013). The Research of Network Transitional Technology from IPv4 to IPv Fourth International Conference on Digital Manufacturing & Automation. 89

90 Yingjiao Wu, X. Z. (2011). Research on the IPv6 Performance Analysis Based on Dual-Protocol Stack and Tunnel Transition. The 6th International Conference on Computer Science & Education (ICCSE 2011). SuperStar Virgo, Singapore. Zhonghua Guo, Z. Z. (2012). Analysis and Research on Transition Proposal from IPv4 to IPv6 in Metropolitan Area Network. Wireless Communications, Networking and Mobile Computing (WiCOM), 8th International Conference. 90

91 Appendix 1 Project Proposal EDINBURGH NAPIER UNIVERSITY SCHOOL OF COMPUTING MSc RESEARCH PROPOSAL 1. Student details Last (family) name ROUSSINOS First name PARIS - ALEXANDROS Napier matriculation number Details of your programme of study MSc Programme title MSc ADVANCED NETWORKING Year that you started your diploma modules 2013 Month that you started your diploma modules September Mode of study of diploma modules Full-time Date that you completed/will complete your 10/05/2014 diploma modules at Napier 3. Project outline details Please suggest a title for your proposed project. If you have worked with a supervisor on this proposal, please provide the name. NB you are strongly advised to work with a member of staff when putting your proposal together. Title of the proposed project Name of supervisor I do not have a member of staff lined up to supervise my work Performance Comparison of OSPF and IS-IS Routing Protocols in Dual-Stack Enterprise Networks Imed Romdhani 4. Brief description of the research area - background Please provide background information on the broad research area of your project in the box below. You should write in narrative (not bullet points). The academic/theoretical basis of your description of the research area should be evident through the use of references. Your description should be between half and one page in length. Routing is the term used to describe the transfer of a packet from a device in one network, to a device in another network by computing the best possible path, and is one of the core research topics in the Computer Networking science. (Lammle, 91

92 2013) Routing is facilitated by the use of Routing Protocols which are subdivided in two main categories: Distance vector and link-state Protocols. Link-state protocols are widely deployed in organizations due to the fact that they are more ressistant to bad routing decisions in opposition to Distance-vector protocols, as routers contain a complete topological map of the network. (Doyle, 1998) Among the Link-state protocol family, two protocols have been competing each other over time: OSPF and IS-IS. OSPF(Open Shortest Path First) runs on the dominant TCP/IP model and uses a hierarchical structure by dividing an Autonomous System into areas, in order to make routing more efficient, limiting the database of routers in the borders of each area. Therefore, a backbone area is defined so that every other area has to be connected with it via Area Border Routers (routers with interfaces both to the Backbone and to another area). Routers that participate in the OSPF scheme exchange Hello Packets with neighbors in order to establish routing relationships and synchronize their databases. At regular intervals, routers send Link-State Updates to other routers so that eventually all routers in each area hold the same topological information map of the local network. When the network map has been build, Dijkstra algorithm is used to calculate the shortest-path to each destination address. (Thorenoor, 2010) On the other hand, OSPF s competitor, IS-IS(Intermediate System to Intermediate System) protocol doesn t carry routing information over IP as it is itshelf a Layer 3 protocol, and is completely based on the older OSI model. IS-IS uses a completely different terminology by defining the devices that are participating in the routing process, as End Systems and Intermediate Systems. More than that, instead of using IP addressing, it uses the CLNP addressing scheme by assigning NSAP addresses to each node and not each interface. However, IS-IS is neutral regarding the type of addresses that it can carry, meaning that also carry IP addresses. Like OSPF, IS-IS is hierarchical, allthough the definition of areas is different, and no backbone area is needed in the design. Intermediate Systems that are participating in IS-IS routing, are defined as Level 1, Level 2 and Level 1/2 Intermediate Systems, and thus, the procedure of routing is devided to Routing within areas and Routing between areas. In IS-IS, Intermediate Systems form routing relationships with neighbors using Hello Packets, and synchronize their databases using Link-State Packets and Sequence Number Packets. (Shamim, 2002) Both OSPF and IS-IS have been successful and preferred by ISPs and organization for many years, and a lot of research has been made to determine which one is more efficient and scalable. However, the advent of IPv6 addressing has been anoher differentiating factor between the two, that can make one preffered than the other for enterprise networks too. On one hand, OSPF had to be completely redesigned to a new version (OSPFv3) in order to support IPv6. As far as it regards dual IPv4 and IPv6 enviroments, both OSPFv2 and OSPFv3 have to be used at the same time. On the other hand, IS-IS only needed to add another TLV(a parameter in the LSPs) to carry IPv6 prefixes (Kalogeras, 2007), making this way able to run efficiently in IPv4 and IPv6 networks. This project aims to investigate what impact the use of IPv6 has on both protocols performance, and determine if migration from one to another is recommended for the dual-stack networks, as IPv4-IPv6 coexistence environments will dominate for a long time until the final complete IPv6 reconfiguration. 92

93 5. Project outline for the work that you propose to complete Please complete the project outline in the box below. You should use the emboldened text as a framework. Your project outline should be between half and one page in length. The idea for this research arose from: A lecture for the module Routing Technology, regarding the IS-IS protocol. The aims of the project are as follows: Base experiments of the scientific community s recommended IPv6 migration mechanism. Comparison of the performance of OSPF and IS-IS protocols in dual-stack environments via research review and network simulations. Trigger further research on the routing protocol comparison over IPv4-IPv6 coexistence environments. The main research questions that this work will address include: Which protocol between OSPF and IS-IS is more efficient in terms of network performance metrics for IPv4/IPv6 networks. The software development/design work/other deliverable of the project will be: Comparative diagrams of the performance of the two protocols, which will be derived from the measured metrics of the simulation (end-to-end delay, throughput, jitter, convergence duration, CPU utilization, routing tables size). The project will involve the following research/field work/experimentation/evaluation: The project will include simulation of OSPF and IS-IS enterprise network topologies for IPv4/IPv6 coexistence networks by the use of OPNET Modeler network simulator. Network performance metrics will be calculated for IPv4, IPv6 as well as TCP and UDP traffic. This work will require the use of specialist software: No This work will require the use of specialist hardware: No The project is being undertaken in collaboration with: 6. References Please supply details of all the material that you have referenced in sections 6 and 7 above. You should include at least three references, and these should be to high quality sources such as refereed journal and conference papers, standards or white papers. Please ensure that you use a standardised referencing style for the presentation of your references, e.g. APA, as outlined in the yellow booklet available from the School of Computing office and pdf Doyle, J. (1998). Routing TCP/IP. Cisco Press. Kalogeras, D. (2007). Open Shortest Path First v3. 2nd South Eastern Europe 6DISS Workshop. Plovdiv,Bulgaria. Lammle, T. (2013). CCNA R&S Study Guide. Sybex. Shamim, F. (2002). Troubleshooting IP Routing Protocols. Cisco Press. Thorenoor, S. G. (2010). Communication Service Provider s choice between OSPF and IS-IS Dynamic Routing Protocols and implementation criteria Using OPNET Simulator. Second International Conference on Computer and Network Technology. 93

94 7. Ethics If your research involves other people, privacy or controversial research there may be ethical issues to consider (please see the information on the module website). If the answer below is YES then you need to complete a research Ethics and Governance Approval form (available on the website: Does this project have any ethical or NO governance issues related to working with, studying or observing other people? (YES/NO) 8. Supervision timescale Please indicate the mode of supervision that you are anticipating. If you expect to be away from the university during the supervision period and may need remote supervision please indicate. Weekly meetings over 1 trimester Meetings every other week over 2 trimesters Other YES 9. Submitting your proposal Please save this file using your surname, e.g. macdonald_proposal.doc, and it to the module leader in time for the next proposal deadline. 94

95 Appendix 2 Project Time -Plan ID Phase Name Start Date Finish Date 1 Familiarization with OPNET Modeler 09-May May Research on IPv4-IPv6 migration techniques published work Research on OSPF - IS-IS comparison published work 15-May May May Jun-14 4 Introduction part writing 07-Jun Jun-14 5 Theoretical Background part writing 09-Jun Jun-14 6 Related Work part writing 22-Jun Jul-14 7 Setting and testing simulation scenarios on OPNET Modeler 22-Jun Jul-14 8 Running simulations on OPNET Modeler 05-Jul Jul-14 9 Implementation part writing 10-Jul Jul Conclusions part writing 16-Jul Jul Cover, Abstract, Table of Contents, Figures and Tables writing 17-Jul Jul Final corrections 21-Jul Jul-14 95

96 Appendix 3 Simulation Scenarios IPv4 Addressing ID Network IPv4 Subnet Address Space 1 IPv4 Clients Subnet /24 2 IPv6 Clients Subnet 3 Router 1 - Router 3 Subnet /24 4 Router 2 - Router 3 Subnet /24 5 Router 3 - Router 4 Subnet /24 6 Router 4 - Router 5 Subnet /24 7 Router 5 - Router 6 Subnet /24 8 Router 6 - Router 7 Subnet /24 9 Router 6 - Router 8 Subnet /24 10 Dual Stack Server 1 Subnet /24 11 Dual Stack Server 2 Subnet /24 Simulation Scenarios IPv6 Addressing ID Network IPv6 Subnet Address Space 1 IPv4 Clients Subnet 2 IPv6 Clients Subnet 2005:0:0:9:0:0:0/64 3 Router 1 - Router 3 Subnet 2005:0:0:4:0:0:0/64 4 Router 2 - Router 3 Subnet 2005:0:0:3:0:0:0/64 5 Router 3 - Router 4 Subnet 2005:0:0:5:0:0:0/64 6 Router 4 - Router 5 Subnet 2005:0:0:7:0:0:0/64 7 Router 5 - Router 6 Subnet 2005:0:0:6:0:0:0/64 8 Router 6 - Router 7 Subnet 2005:0:0:2:0:0:0/64 9 Router 6 - Router 8 Subnet 2005:0:0:1:0:0:0/64 10 Dual Stack Server 1 Subnet 2005:0:0:A:0:0:0/64 11 Dual Stack Server 2 Subnet 2005:0:0:B:0:0:0/64 96

97 Appendix 4 Indicative OSPF Backbone Router (4) Routing Tables Indicative OSPF ABR Router (3) Routing Tables Indicative OSPF Internal Router (1) Routing Tables 97

98 Indicative IS-IS Level 2 Router (4) Routing Tables Indicative IS-IS Level 1-2 Router (3) Routing Tables Indicative IS-IS Level 1 Router (1) Routing Tables 98