D 4

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
Performance Comparison of OSPF and IS-IS Routing Protocols in Dual-Stack Enterprise Networks
Paris – Alexandros Roussinos – 40134490 – MSc Advanced Networking
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: 40134490
2
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
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
Table of Contents
1 Introduction ............................................................................................................. 13
1.1 Problem and Context ....................................................................................... 13
1.2 Aims and Objectives......................................................................................... 13
1.3 Organization ..................................................................................................... 14
2 Literature Review ................................................................................................... 16
2.1 Introduction ...................................................................................................... 16
2.2 Theoretical Background .................................................................................. 16
2.2.1 Routing and Routing Protocols ................................................................. 16
2.2.1.1 Basics ..................................................................................................... 16
2.2.1.2 Categories .............................................................................................. 17
2.2.2 OSPF............................................................................................................ 19
2.2.2.1 History ................................................................................................... 19
2.2.2.2 OSPFv2.................................................................................................. 19
2.2.2.2.1 Hierarchy ........................................................................................ 19
2.2.2.2.2 Router Types................................................................................... 20
2.2.2.2.3 Packet Types ................................................................................... 21
2.2.2.2.4 Network Types ................................................................................ 23
2.2.2.2.5 Operation ........................................................................................ 23
2.2.2.3 OSPFv3.................................................................................................. 25
2.2.2.3.1 Basics ............................................................................................... 25
2.2.2.3.2 Added Characteristics ................................................................... 25
2.2.2.3.3 Packet Types ................................................................................... 25
2.2.2.3.4 Address Families ............................................................................ 26
2.2.3 IS-IS ............................................................................................................. 26
2.2.3.1 History ................................................................................................... 26
2.2.3.2 Addressing ............................................................................................ 27
2.2.3.3 Hierarchy .............................................................................................. 27
2.2.3.4 Levels ..................................................................................................... 28
2.2.3.5 PDU Types ............................................................................................ 29
2.2.3.6 Network Types ...................................................................................... 30
2.2.3.7 Operation .............................................................................................. 31
2.2.3.7.1 Sub-network Dependent Layer ..................................................... 31
5
2.2.3.7.2 Sub-network Independent Layer .................................................. 31

2.2.3.8 Integrated IS-IS .................................................................................... 32
2.2.4 IPv6 .............................................................................................................. 33
2.2.4.1 History ................................................................................................... 33
2.2.4.2 Addressing ............................................................................................ 34
2.2.4.3 Features ................................................................................................. 35
2.2.5 IPv4-to-IPv6 Migration.............................................................................. 37
2.2.5.1 Mechanisms........................................................................................... 37
2.2.5.1.1 Dual-Stack ....................................................................................... 37
2.2.5.1.2 Translation ...................................................................................... 38
2.2.5.1.3 Tunnelling ....................................................................................... 39
2.2.6 Conclusion ................................................................................................... 41
2.3 Related Work .................................................................................................... 42
2.3.1 IPv4-IPv6 Transition Scheme Comparison ............................................. 42
2.3.1.1 Research Recommendations................................................................ 42
2.3.1.2 Performance Comparison.................................................................... 45
2.3.1.3 Critical IPv6 Transition Solution Selection ....................................... 46
2.3.2 OSPF – IS-IS Comparison ......................................................................... 47
2.3.2.1 Considerations ...................................................................................... 47
2.3.2.2 OSPF vs IS-IS on Dual-Stack .............................................................. 50
2.3.3 Conclusion ................................................................................................... 52
3 Implementation ....................................................................................................... 53
3.1 Simulation with OPNET .................................................................................. 53
3.2 Calculated Performance Metrics .................................................................... 54
3.3 Simulation Scenarios ........................................................................................ 55
3.3.1 Dual-Stack Baseline Topology .................................................................. 55
3.3.2 Traffic Design ............................................................................................. 57
3.3.3 OSPF Dual-Stack Topology ...................................................................... 59
3.3.4 IS-IS Dual-Stack Topology ........................................................................ 60
3.3.5 Node Failure Addition ............................................................................... 61
3.3.6 Simulation Parameters .............................................................................. 62
3.3.7 Results ......................................................................................................... 63
3.3.7.1 Introduction .......................................................................................... 63
6
3.3.7.2 No Traffic, Fully-Functional Scenarios .............................................. 63

3.3.7.2.1 General Metrics .............................................................................. 64
3.3.7.3 TCP Traffic, Fully-Functional Scenarios ........................................... 67
3.3.7.3.1 General Metrics .............................................................................. 67
3.3.7.3.2 IPv4 Traffic Metrics ....................................................................... 68
3.3.7.4 TCP Traffic, Router 4 Failure Scenarios ........................................... 74
3.3.7.4.1 General Metrics .............................................................................. 74
3.3.7.5 UDP Traffic, Fully Functional Scenarios ........................................... 75
3.3.7.5.1 General Metrics .............................................................................. 75
3.3.7.6 UDP Traffic, Router 4 Failure Scenarios ........................................... 81
3.3.7.6.1 General Metrics .............................................................................. 81
3.3.7.5 Comprehensive Results ........................................................................ 81
3.3.7.6 Experimental Results Analysis............................................................ 82
3.4 Conclusion ......................................................................................................... 84
4 Conclusions .............................................................................................................. 85
4.1 Evaluation of the Project ................................................................................. 85
4.2 Overall Outcome .............................................................................................. 86
4.3 Future Work ..................................................................................................... 86
References ................................................................................................................... 88
Appendix 1 .................................................................................................................. 91
Project Proposal ..................................................................................................... 91
Appendix 2 .................................................................................................................. 95
Project Time -Plan ................................................................................................. 95
Appendix 3 .................................................................................................................. 96
Simulation Scenarios’ IPv4 Addressing ............................................................... 96
Simulation Scenarios’ IPv6 Addressing ............................................................... 96
Appendix 4 .................................................................................................................. 97
Indicative OSPF Backbone Router (4) Routing Tables ...................................... 97
Indicative OSPF ABR Router (3) Routing Tables .............................................. 97
Indicative OSPF Internal Router (1) Routing Tables ......................................... 97
7
Indicative IS-IS Level 2 Router (4) Routing Tables ............................................ 98

Indicative IS-IS Level 1-2 Router (3) Routing Tables ........................................ 98
Indicative IS-IS Level 1 Router (1) Routing Tables ............................................ 98
8
List of Tables
Table 1 - IPv6 Transition Categories Comparison ...................................................... 47
Table 2 - Comprehensive Results for the No-Traffic Simulations .............................. 81
Table 3 - Comprehensive Results for the TCP-Traffic Simulations ............................ 81
Table 4 - Comprehensive Results for the UDP-Traffic Simulations ........................... 82
9
List of Figures
Figure 1 - IGP and EGP Purpose ................................................................................. 17
Figure 2 - Simple OSPFv2 Network ............................................................................ 21
Figure 3 - OSPFv2 Packet Header ............................................................................... 21
Figure 4 - OSPF Neighbour States............................................................................... 24
Figure 5 - OSPFv3 Packet Header ............................................................................... 26
Figure 6 - NET Address Format and Simple Example ................................................ 27
Figure 7 - Simple IS-IS Network ................................................................................. 29
Figure 8 - Generic IS-IS PDU Header ......................................................................... 29
Figure 9 - IPv6 Unicast Address Format ..................................................................... 35
Figure 10 - IPv6 Multicast Address Format ................................................................ 35
Figure 11 - IPv6 Anycast Address Format .................................................................. 35
Figure 12 - IPv6 Packet Header Format ...................................................................... 36
Figure 13 - Dual-Stack Router Structure and Function ............................................... 38
Figure 14 - Translation Mechanisms General Function .............................................. 39
Figure 15 - Tunnelling Mechanisms General Function ............................................... 41
Figure 16 - OPNET Modeler 14.5 Opening Screen ..................................................... 53
Figure 17 - Enterprise Network Topology Option ....................................................... 56
Figure 18 - Object Palette Utility ................................................................................. 56
Figure 19 - Baseline Topology .................................................................................... 57
Figure 20 - Application Demand's Attributes .............................................................. 58
Figure 21 - Application Demand Enabled Baseline Topology .................................... 59
Figure 22 - Router OSPF Instances Configuration ...................................................... 59
Figure 23 - OSPF Topology and Areas........................................................................ 60
Figure 24 - Router IS-IS Instance Configuration ......................................................... 61
Figure 25 - IS-IS Topology and Areas ......................................................................... 61
Figure 26 - Failure Recovery Option ........................................................................... 62
Figure 27 - Individual Statistics Selection ................................................................... 62
Figure 28 - Simulation Parameters .............................................................................. 63
Figure 29 - OSPF and IS-IS Convergence Activity (No Traffic) ................................ 64
Figure 30 - OSPF and IS-IS Convergence Duration (No Traffic) ............................... 64
Figure 31 - Average Backbone/Level 2 Router Routing Table Size (No Traffic)....... 65
Figure 32 - Average ABR/Level 1-2 Router Routing Table Size (No Traffic) ........... 65
Figure 33 - Average Internal/Level 1 Router Routing Table Size (No Traffic) .......... 66
Figure 34 - Average Backbone/Level 2 Router CPU Utilization (TCP Traffic) ......... 67
Figure 35 - IPv4 Throughput (TCP Traffic) ................................................................ 68
Figure 36 - OSPF IPv4 Clients End-to-End Delay (TCP Traffic) ............................... 69
Figure 37 - IS-IS IPv4 Clients End-to-End Delay (TCP Traffic) ................................ 69
Figure 38 - OSPF IPv4 Clients End-to-End Delay Variation (TCP Traffic) ............... 70
Figure 39 - IS-IS IPv4 Clients End-to-End Delay Variation (TCP Traffic) ................ 70
Figure 40 - IPv6 Throughput (TCP Traffic) ................................................................ 71
Figure 41 - OSPF IPv6 Clients End-to-End Delay (TCP Traffic) ............................... 72
Figure 42 - IS-IS IPv6 Clients End-to-End Delay (TCP Traffic) ................................ 72
Figure 43 - OSPF IPv6 Clients End-to-End Delay Variation (TCP Traffic) ............... 73
Figure 44 - IS-IS IPv6 Clients End-to-End Delay Variation (TCP Traffic) ................ 73
Figure 45 - OSPF and IS-IS Average Convergence Duration (TCP Traffic) .............. 74
Figure 46 - Average Backbone/Level 2 Router CPU Utilization (UDP Traffic) ........ 75
Figure 47 - IPv4 Throughput (UDP Traffic)................................................................ 76
Figure 48 - OSPF IPv4 Clients End-to-End Delay (UDP Traffic) .............................. 76
10
Figure 49 - IS-IS IPv4 Clients End-to-End Delay (UDP Traffic) ............................... 77

Figure 50 - OSPF IPv4 Clients End-to-End Delay Variation (UDP Traffic) .............. 77
Figure 51 - IS-IS IPv4 Clients End-to-End Delay Variation (UDP Traffic) ............... 78
Figure 52 - IPv6 Throughput (UDP Traffic)................................................................ 78
Figure 53 - OSPF IPv6 Clients End-to-End Delay (UDP Traffic) .............................. 79
Figure 54 - IS-IS IPv6 Clients End-to-End Delay (UDP Traffic) ............................... 79
Figure 55 - OSPF IPv6 Clients End-to-End Delay Variation (UDP Traffic) .............. 80
Figure 56 - IS-IS IPv6 Clients End-to-End Delay Variation (UDP Traffic) ............... 80
Figure 57 - OSPF and IS-IS Average Convergence Duration (UDP Traffic) ............. 81
11
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
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
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-to-
end 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
 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
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
(http://ieeexplore.ieee.org) and the scientific web databases http://dl.acm.org/ and
http://www.sciencedirect.com/ 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
2.2.1 Routing and Routing Protocols
2.2.1.1 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
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.
2.2.1.2 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
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. Distance-
vector 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 well-
known 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 path-
vector 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
larger networks. Widely popular classless protocols include RIPv2, OSPF, EIGRP
and IS-IS. (Malhotra, 2002)
2.2.2 OSPF
2.2.2.1 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 1131. 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 1247. (Moy, 1998) Finally, OSPFv2 was modified
to support the new IPv6. The new version named OSPFv3 was published in 2008, in
RFC 5340. This paper will present the main characteristics of the two latest, as they
have dominated in the networking world.
2.2.2.2 OSPFv2
2.2.2.2.1 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 0.0.0.0) 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
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)
2.2.2.2.2 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
(Thomas, 2003) The following diagram attempts to present a common OSPFv2

topology that can help in understanding the OSPF area and router types.
Figure 2 - Simple OSPFv2 Network
2.2.2.2.3 Packet Types

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 AuType
Authentication
Authentication
Figure 3 - OSPFv2 Packet Header
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
21
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
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)
2.2.2.2.4 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 224.0.0.5. 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 224.0.0.6. 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)
2.2.2.2.5 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
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 108 by default.
24
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)
2.2.2.3 OSPFv3
2.2.2.3.1 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.
2.2.2.3.2 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 224.0.0.5 and 224.0.0.6 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.
2.2.2.3.3 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

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 link-
local, 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)
2.2.2.3.4 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)
2.2.3 IS-IS
2.2.3.1 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
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)
2.2.3.2 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)
Area ID System ID SEL
10. 00a7.81b0.0030. 00
Figure 6 - NET Address Format and Simple Example
2.2.3.3 Hierarchy
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
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.
2.2.3.4 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
Figure 7 - Simple IS-IS Network

2.2.3.5 PDU Types
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
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)
2.2.3.6 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
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)
2.2.3.7 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 sub-
layer are presented below.
2.2.3.7.1 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.
2.2.3.7.2 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.c200.0014 and 0180.c200.0015 for level 1 and level 2
respectively. LSPs contain a Sequence Number that starts from the value of 1 and is
31
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)
2.2.3.8 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
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.
2.2.4 IPv6
2.2.4.1 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 un-
needed 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 Inter-
domain 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
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)
2.2.4.2 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 site-
local, 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
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.

11111111 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)
n bits 128 –n bits

Subnet Prefix 00000000000000000
Figure 11 - IPv6 Anycast Address Format
2.2.4.3 Features
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
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
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)
2.2.5 IPv4-to-IPv6 Migration
2.2.5.1 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.
2.2.5.1.1 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
Figure 13 - Dual-Stack Router Structure and Function
2.2.5.1.2 Translation
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
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.
Figure 14 - Translation Mechanisms General Function
2.2.5.1.3 Tunnelling
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
 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 point-
to-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
Figure 15 - Tunnelling Mechanisms General Function
Research in the IPv4-to-IPv4 migration and coexistence strategies is constantly on-

going. 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.
2.2.6 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
2.3 Related Work
2.3.1 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.
2.3.1.1 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
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-to-
one 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
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
2.3.1.2 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 Sub-
system 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 round-
trip delay was accomplished by sending ICMP and ICMPv6 packets with a 1024
bytes packet size, and the average was calculated for each scenario after 100
45
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)
2.3.1.3 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
IPv6 Transition
Advantages Disadvantages Suitability
Categories
 Simple  Need for IPv4  Suitable for the
 Easy to understand and configure addresses on every backbone of
 Inexpensive node enterprise, ISP and
 Scalable  Superfluous address home networks
 Lower packet-loss rates advertisement to  Best for the main
Dual – Stack  Higher throughput rates DNS stage of migration
 Lower round-trip delay times  More CPU-memory
 Direct communication between overhead
nodes
 Recommended solution
 Connectivity between IPv4-only and  Vulnerable to DoS  Only for early
IPv6-only devices attacks stages of the
 Enables ISPs to change customers’  Performance migration
IPv4 global addresses with private depending on the
address binding
table size
 Low scalability
 Incapability to
Translation traverse IPv6 not-
supported
applications
 Bears all foibles of
NAT
 Adds complexity
and management
cost
 Need of modification only at the  No connectivity  Suitable for
tunnel’s endpoints between IPv4-only connecting
 Inexpensive solution and IPv6-only “islands” of one IP
 Simple devices version via an
 Vulnerable to DoS, “ocean” of another
Tunneling spoofing and man- IP version
in-the-middle  Suitable for ISP
attacks edge networks
 Need of dual-stack  Best for the early
routers stages of the
 Introduces latency migration
Table 1 - IPv6 Transition Categories Comparison
2.3.2 OSPF – IS-IS Comparison
2.3.2.1 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
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
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-to-
point 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
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.
2.3.2.2 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
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
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.
2.3.3 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
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
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
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
3.3.1 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
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 km2. 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
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.
Figure 19 - Baseline Topology
3.3.2 Traffic Design

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
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 100th 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
Figure 21 - Application Demand Enabled Baseline Topology
3.3.3 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
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.
Figure 23 - OSPF Topology and Areas
3.3.4 IS-IS Dual-Stack Topology

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 49.0001.3333.3333.3333.00 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 49.0001, Routers 4, 5 to area 49.0010 and Routers 6, 7, 8 to area 49.0002.
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
49.0001 and 49.0002 to the 49.0010 area were configured as Level 1-2. The following
60
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.
Figure 25 - IS-IS Topology and Areas
3.3.5 Node Failure Addition

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
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 49.0010 IS-IS
accordingly was set to fail at the 3600th, 36000th, and 72000th 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 7200th, 39600th, and 75600th second
accordingly. Such simulation gave the opportunity to examine the time that the dual-
stack 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.
Figure 26 - Failure Recovery Option
3.3.6 Simulation Parameters

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
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
3.3.7 Results
3.3.7.1 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.
3.3.7.2 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 dual-
stack 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
3.3.7.2.1 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
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
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
3.3.7.3 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 fully-
functional-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.

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
slightly lower CPU utilization. In both cases the CPU utilization stabilizes to
0.0004% for OSPF and to 0.00045% 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.
3.3.7.3.2 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
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
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
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.

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
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
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
3.3.7.4 TCP Traffic, Router 4 Failure Scenarios

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
3.3.7.5 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.

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 0.0003% 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.

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
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
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.
Figure 50 - OSPF IPv4 Clients End-to-End Delay Variation (UDP Traffic)
77
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
0.00375 ms for both OSPF and IS-IS. As seen, OSPF and IS-IS jitter values almost
match in the long run of the simulation.

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
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 end-
to-end delay calculations, both protocols perform equally.
79
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 0.00725 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
3.3.7.6 UDP Traffic, Router 4 Failure Scenarios

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.
3.3.7.5 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
Fully Functional
No Traffic
Scenario
General 49 5.4 11.7 10.2 14.5 14.5 11.4 5.7
Table 2 - Comprehensive Results for the No-Traffic Simulations
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 0.0004 0.00045
Fully Functional IPv4 120 190 1.6 1.6 0.4 0.4
TCP Traffic Scenario IPv6 70 180 1.7 1.7 0.39 0.41
Router Failure
Scenario
General 20 1
Table 3 - Comprehensive Results for the TCP-Traffic Simulations
81
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 0.0003 0.0003
Fully Functional IPv4 140 200 1.9 1.9 0.0038 0.0038
UDP Traffic Scenario IPv6 80 180 2 2 0.01 0.0073
Router Failure
Scenario
General 20 1
Table 4 - Comprehensive Results for the UDP-Traffic Simulations
3.3.7.6 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
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
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
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
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
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
References
A. Lindem, S. M. (2010, April). Support of Address Families in OSPFv3. Internet
Requests for Comments, RFC 5838.
Abdulrahman Alkandari, I. F. (2012). An Anatomy of IGP and BGP Routing

Protocols. 2012 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 1195.
Chen Haihong, S. X. (2013). Simulation and Research of OSPFv3 Performance. 2013

International Conference on Computational and Information Sciences.
Dai, K. (2011). IPv4 to IPv6 Transition Research Based on the Campus Network.
2011 International Symposium on Intelligence Information Processing and Trusted
Computing.
David Murray, T. K. (2012). The State of Enterprise Network Traffic in 2012. 18th
Asia-Pacific Conference on Communications (APCC) (pp. 179 - 184 ). 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 5308.
J. Arkko, F. B. (2011, May). Guidelines for Using IPv6 Transition Mechanisms

during IPv6 Deployment. Internet Requests for Comments, RFC 6180.
Jinesh Doshi, R. C. (2012). A Comparative Study of IPv4/IPv6 Co-existence

Technologies.
Retrieved from http://morse.colorado.edu/~tlen5710/12s/IPv4v6Coexistence.pdf
88
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. 166-170.
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 2460.
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. 1573-1577.
XiaoHong, L. (2013). The Research of Network Transitional Technology from IPv4

to IPv6. 2013 Fourth International Conference on Digital Manufacturing &
Automation.
89
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
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 40134490
2. 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 Performance Comparison of OSPF and

IS-IS Routing Protocols in Dual-Stack
Enterprise Networks
Name of supervisor Imed Romdhani
I do not have a member of staff lined up
to supervise my work
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
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
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
http://www.soc.napier.ac.uk/~cs104/mscdiss/moodlemirror/d2/2005_hall_referencing.
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
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:
http://www.ethics.napier.ac.uk).
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 YES

Meetings every other week over 2
trimesters
Other
9. Submitting your proposal
Please save this file using your surname, e.g. macdonald_proposal.doc, and e-mail it
to the module leader in time for the next proposal deadline.
94
Appendix 2
Project Time -Plan
ID Phase Name Start Date Finish Date

1 Familiarization with OPNET Modeler 09-May-14 20-May-14
Research on IPv4-IPv6 migration techniques
2 15-May-14 30-May-14
published work
Research on OSPF - IS-IS comparison
3 31-May-14 10-Jun-14
published work
4 Introduction part writing 07-Jun-14 08-Jun-14
5 Theoretical Background part writing 09-Jun-14 21-Jun-14
6 Related Work part writing 22-Jun-14 02-Jul-14

Setting and testing simulation scenarios on
7 22-Jun-14 04-Jul-14
OPNET Modeler
8 Running simulations on OPNET Modeler 05-Jul-14 09-Jul-14
9 Implementation part writing 10-Jul-14 16-Jul-14
10 Conclusions part writing 16-Jul-14 19-Jul-14

Cover, Abstract, Table of Contents, Figures
11 17-Jul-14 20-Jul-14
and Tables writing
12 Final corrections 21-Jul-14 23-Jul-14
95
Appendix 3
Simulation Scenarios’ IPv4 Addressing
ID Network IPv4 Subnet Address Space

1 IPv4 Clients Subnet 190.0.0.0/24
2 IPv6 Clients Subnet
3 Router 1 - Router 3 Subnet 192.0.1.0/24
10 Dual Stack Server 1 Subnet 192.0.8.0/24
11 Dual Stack Server 2 Subnet 192.0.9.0/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
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
Appendix 4
Indicative OSPF Backbone Router (4) Routing Tables
Indicative OSPF ABR Router (3) Routing Tables
Indicative OSPF Internal Router (1) Routing Tables
97
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
99

D 4

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

D 4

Загружено:

Авторское право:

Доступные форматы

Performance Comparison of

OSPF and IS-IS Routing Protocols in

Paris – Alexandros Roussinos

Supervisor: Imed Romdhani

Submitted in partial fulfilment of

Matriculation no: 40134490

Data Protection declaration

The University may not make this dissertation available to others.

2.2.3.7.2 Sub-network Independent Layer .................................................. 31

3.3.7.2 No Traffic, Fully-Functional Scenarios .............................................. 63

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

Figure 49 - IS-IS IPv4 Clients End-to-End Delay (UDP Traffic) ............................... 77

1.2 Aims and Objectives

 In addition to the theoretical comparison, the project aims to provide tangible

 Moreover, taking in consideration both the performed theoretical research and

 Eventually, the objective of the current dissertation is to trigger further

 Chapter 2 includes two important sub-sections: Firstly, the theoretical

 Chapter 3 includes the complete implementation part of the project. The

2.2 Theoretical Background

2.2.1 Routing and Routing Protocols

selection of the best available path towards a destination according to protocol

Figure 1 - IGP and EGP Purpose

Distance-Vector, Link-State and Path-Vector Protocols: IGPs are divided in two

routes resembles that of a vector consisted of a distance metric and a next-hop

Non-Backbone Areas: Each non-backbone area contains a set of contiguous networks

2.2.2.2.2 Router Types

Autonomous System Boundary Routers: As ASBRs (Autonomous System Boundary

(Thomas, 2003) The following diagram attempts to present a common OSPFv2

Figure 2 - Simple OSPFv2 Network

2.2.2.2.3 Packet Types

8 bits 8 bits 8 bits 8 bits

Database Description: DD (Database Description) packets contain a shortened form

LSAcks: The LSA Acknowledgment packet is just used to provide reliability

2.2.2.2.4 Network Types

Point-To-Point Networks: Point-to-point networks connect two single OSPF routers.

Non-Broadcast Multi-Access Networks: NBMAs (Non-Broadcast Multi-Access

Point-To-Multipoint Networks: Point-to-multipoint networks consist of connections

Figure 4 - OSPF Neighbour States

Shortest-Path-First Algorithm: OSPFv2 uses the Dijkstra algorithm, also known as

2.2.2.3.2 Added Characteristics

2.2.2.3.3 Packet Types

8 bits 8 bits 8 bits 8 bits

2.2.2.3.4 Address Families

Area ID System ID SEL

Level 1: More specifically a level 1 IS contains only a level 1 Link-State Database

Figure 7 - Simple IS-IS Network

Intra-domain Routing Protocol Discriminator

Figure 8 - Generic IS-IS PDU Header

2.2.3.6 Network Types

Point-to-Point Networks: Same as in OSPF, point-to-point links are used in IS-IS to

2.2.3.7.1 Sub-network Dependent Layer

2.2.3.7.2 Sub-network Independent Layer

2.2.3.8 Integrated IS-IS

n bits m bits 128 –n –m bits

Multicast: A multicast address is assigned to a group of different interfaces

8 bits 4 bits 4 bits 112 bits

Anycast: An anycast address is again assigned to a group of different interfaces, but a

n bits 128 –n bits

Version Traffic Class Flow Label

Autoconfiguration: A very beneficial attribute added to IPv4 is the concept of

Neighbour Discovery: Eventually, another feature of IPv6 that improves it compared

2.2.5 IPv4-to-IPv6 Migration

Figure 13 - Dual-Stack Router Structure and Function