Study on OSPF Algebraic Formal Modelling Using ACP

1 Abstract —OSPF is a commonly used link state routing protocol in order to interconnect network devices inside an Autonomous System. This paper focuses on achieving a detailed modelling for OSPF by performing manual algebraic derivations according to Algebra of Communicating Processes (ACP) axioms. The aim of this detailed model is to get a realistic approach of OSPF dynamics by applying the timers involved and by describing the full Link State Advertisement (LSA) exchange process.


I. INTRODUCTION
OSPF [1] is an Interior Gateway Protocol (IGP) which may most likely be the most widespread routing protocol nowadays, mainly due to its fast converging time and its easiness of configuration.
The aim of this paper is to get an algebraic formal model for OSPF, that meaning a formal protocol specification with mathematical notation.Formal Description Techniques (FDT) [2] are largely used for modelling protocols in order to check for design flaws and to facilitate automated protocol implementation.
Most FDT are implemented by means of software tools such as mCRL2 [3] or Spin [4], but in order to get algebraic formal models, the most convenient tools are process algebras, which allow to manually reason about processes following a set of axioms.
There are some kinds of process algebras [5], but the one fitting better for algebraic protocol modelling may be Algebra of Communicating Processes (ACP) [6].That is because ACP is the most abstract of all its counterparts [7], as it does not take into account the real nature of processes, hence allowing to just focus on their core properties [8].
Therefore, ACP is really suitable for the implementation of algebraic formal modelling, as it facilitates the study of concurrent and distributed systems [9], such as routing protocols being independently run by each particular router within certain routing domain.In addition to that, ACP may also provide algebraic tools for its further verification [10].
There is not much information concerning this area in the Manuscript received 30 December, 2017; accepted 28 April, 2018.
literature, therefore the design of a formal model of OSPF by using ACP has been undertaken, where algebraic derivations were manually performed so as to prove the correctness of the final outcome.A routing protocol performs three basic functions, being identifying their neighbours, managing the route paths to all destinations and making dynamic decisions about where to forward user traffic getting in.
A detailed model has been designed with the premise of making it as close to real as possible, hence considering the real LSA exchange process and taking into account timers involved in sending and receiving both OSPF hello packets and LSA refresh packets.
In this paper, we focus on studying that model with different design parameters, such as the different network types available for a network segment and the number of routers within the OSPF domain.
The organisation of this paper will be as follows: first, Section II introduces the OSPF network types, then, Section III describes the kind of relationships between routers within an OSPF domain, next, Section IV presents the OSPF detailed model, after that, Section V renders a practical example of that model, later, Section VI performs a verification of that model, and finally, Section VII draws the final conclusions.

II. OSPF NETWORK TYPES
Prior to working on the expression for the OSPF models, some considerations may be done regarding the network type.The OSPF v2 standard presents four kinds of networks to be distinguished, each one with its own characteristics, as it may be seen in Table I regarding network type and in Table II with hello and dead timers.
Each network type has its own independent TYPEid value, but they might be associated in two different ways, either according to the binary values of the variable NT, standing for Network Type, or otherwise regarding the binary values of the variable TT, related to Timer Type.
On the one hand, two network types share the need for categorising OSPF routers within a network segment as Designated Router (DR), Backup DR (BDR) or none of them (DROther), whereas the other two of them do not.As a matter of fact, network types with the value of 0 for the variable NT need to implement a DR and also a BDR as they are multiaccess networks, that meaning there might be more than two routers within a network segment.Those network types are Broadcast (BRC), which are the Ethernet networks, and Non Broadcast MultiAccess (NBMA), which are the Frame Relay and ATM networks with Meshed topology.
In such cases, DR is a router appointed to collect linkstate information from all devices within that network segment, and in turn redistribute it properly, in order for all those devices to share the same link-state advertisements.Additionally, BDR is another router elected to collect linkstate information along with DR just for backup purposes.
Alternatively, network types with NT value of 1 do not need to implement a DR and a BDR as they are peer to peer networks, that meaning there are just two routers within a network segment.Those network types are Point to Point (P2P), which are the Serial networks such as PPP or HDLC, and Point to MultiPoint (P2MP), which are Frame Relay or ATM networks with a Hub and Spoke topology.
However, on the other hand, another different group of two network types share the same values for the hello timers and dead timers whilst the other two of them do not.
Network types having broadcast capabilities like Ethernet or Serial point to point links share a hello timer of 10 seconds and a dead timer fourfold.This fact is reflected with the value of 0 for the variable TT.
On the contrary, network types with TT value of 1 are related to Frame Relay or ATM implementations, which do not have inherent broadcast or multicast capabilities, although this fact might be worked around through the proper configuration.They share a hello timer of 30 seconds and a dead timer four times greater.
Regarding arithmetic, the variable TYPEid defined in Table I takes values from 0 to 3 depending on the particular network type, but variables NT and TT may be calculated by means of the following expressions: Therefore, NT might be seen as the remainder of the integer division of TYPEid by 2, whereas TT might be considered as the quotient, or the integer part, of that same division.

III. OSPF NEIGHBOURHOOD -VS -OSPF ADJACENCY
It is crucial to understand both sorts of relationship present in OSPF domains.Some OSPF devices are neighbours if they are connected to the same subnet and share some configuration information such as subnet mask, authentication type, area ID and its type, hello and dead timers.
All OSPF neighbours will keep their neighbourhood relationship by means of exchanging hello packets but this fact does not imply an exchange of LSA, hence no routing information may not necessarily flow.On the contrary, some OSPF devices are adjacent if they do share LSA among them, so routing information does flow.
The requirements for a pair of OSPF neighbouring routers to be adjacent depend on the network type.This is, multiaccess networks such as BRC or NBMA need that, at least, one of them bears the role of DR or BDR, but otherwise, peer to peer networks such as P2P and P2MP need not.
In summary, an OSPF adjacency relationship will only be formed if Table III gives 1 between a particular sender, shown in rows, and a given receiver, shown in columns.This table is set up just for multiaccess networks, whilst peer to peer networks always form adjacency relationship between ends.Therefore, this table might also apply for the latter case, just considering that both ends are DR and BDR.
The aforesaid table may be implemented as an arithmetic expression just by assigning the appropriate values to the different router roles present in each OSPF network types, as shown in Table IV.Those values are assigned in a unidirectional fashion, hence each way is evaluated on its own.Therefore, for each direction within a channel, the aforesaid values are combined in the following expression, containing the addition of the integer part of a fraction with the role of the routers at both ends of a channel, where x represents the role of the sending end of the link and y is the role of the receiving end, and also containing the network type , 2 int .5 In a nutshell, coefficients ki,j capture the behaviour seen in Table III.Those coefficients carry binary values, thus being 1 or 0, depending on whether local router i and neighbouring router j form an OSPF adjacency relationship or otherwise.

IV. OSPF DETAILED MODELLING USING ACP
In order to achieve a detailed modelling for OSPF, the main requirements to be met are the use of the proper timers and the step by step LSA exchange process.
As per the action of timers, hello and dead timers depend on the network type and they are given in Table II.However, just as a reminder, variable NT, as stated in (1), is not to be confused with variable TT, as stated in (2).The former identifies whether a network type will need to appoint a DR and a BDR or otherwise, whereas the latter identifies the value of the aforesaid timers.
Both timers are related to the neighbour discovery function but they are applied to different actions, as hello timers state how long a router must wait for sending a hello packet to a neighbour router, thus considering it as up, whereas dead timers state how long a router must wait for receiving a dead packet from a neighbour router prior to considering it as down.
The same router might have different network types associated to its various interfaces, therefore, the aforesaid variables, and hence their related timers, will depend on the media that each particular neighbouring router is standing.
There are another couple of timers to be taken into consideration, such as the refresh LSA timer, whose default value is 30 minutes, thus 1800 seconds, although it might be adjusted from 5 minutes to 59 minutes, and the max age LSA timer, whose value is 1 hour, thus 3600 seconds.Those timers do not depend on the network type; therefore, they will be invariant with respect of it.
Those timers are related to the refreshment of LSA entries already present on the Link State Data Base (LSDB) but they are applied to different actions, as the refresh LSA timer states how long a router must wait for sending an LSA refreshment update packet to a neighbour, hence reoriginating that LSA and forwarding on to an adjacent router, whereas max age LSA timer states how long a router must wait for receiving an LSA refreshment update packet from an adjacent router prior to removing that LSA from its LSDB.
On the other hand, it is worth taking into account that there are five different OSPF types of packets, whose functions are described in Table V.
Therefore, hello messages will be carried within OSPF type 1 packets whereas LSA exchange process will involve the rest of OSPF packet types.
As per the actual LSA exchange process, a local router i sends an OSPF type 2 packet to its adjacent routers j in order to get its LSDB synchronised with those of its adjacent routers.They will, in turn, acknowledge such packets by echoing it to the local router i, whilst evaluating whether each LSA header is more updated than those present onto their own LSDB.If that is the case for any LSA header, an OSPF type 3 packet will be sent to the local router i in order to request the whole LSA from it, and upon receipt of it, an OSPF type 4 packet will be sent back from the local router i containing the LSA requested, which will in turn be acknowledged by sending an OSPF type 5 packet to the local router i.
Needless to say that the proper neighbouring router will be performing the complementary actions of those exposed, thus it will be receiving packets when the local router is sending them and vice versa.
In summary, terms depending on timers may be considered as synchronous, whereas terms related to LSA exchange process may be considered as asynchronous as they do not depend time.
The synchronous terms will be called Rs,i and they will need the implementation of a timing system, which will decrement the aforesaid timers and will reset to their default values when the proper actions may be performed.
On the contrary, the asynchronous terms will be called Ra,i and they will be time independent, so they will not need any timing system.
All those terms may be described using ACP syntax and semantics [11], where a product stands for a sequential operator, an addition stands for an alternate operator and a conditional operator is used such as True < |Boolean| > False.
Additionally, si,j(d) stands for sending a packet from i to j, whereas ri,j(d) stands for receiving that packet at j coming from i, and ci,j(d) stands for communication between them.
All of that is extended with the deployment of an appropriate timing system and some auxiliary functions to be defined later on.The different OSPF packet types will be expressed herein as PT followed by their type number (PTt): ( 5) | ( ) 1| .
( 3) ( 4) ( 5) It is to be noted that when a new route is first incorporated into the OSPF domain or any route gets updated, the LSA exchange process is asynchronous, as it gets triggered as soon as that network gets configured into the OSPF domain, regardless of the timing.However, when it comes to refreshing LSA, the process is synchronous as it depends on LSA refresh timer, as well as when any route gets deleted, it depends on max age LSA timer.
As per the timing system, it may be modelled in diverse ways, but it will herein be done by defining a variable ti, representing the total time in seconds that local router i has been alive within the OSPF domain.
In addition to it, the aforesaid four timers have also been defined, going down from the maximum values previously proposed for each one of them, as stated in ( 6)-( 9): _ , 10 20 , 4 (10 20 ), _ , 1800,
Those four timers may be decreased one unit at a time, meaning a second has elapsed, hence simulating the effect of time passing by.That may be modelled in the local router i by Algorithm 1, called time (i).
After executing this function, it returns the value 1 in order for the synchronous terms Rs,i to be executed, simulating the need of a positive clock edge for running those terms.Algorithm 1. time (i): time(i){ thello,i = thello,i -1; tdead,i = tdead,i -1; trefreshLSA,i = trefreshLSA,i -1; tmaxAgeLSA,i = tmaxAgeLSA,i -1; ti = ti + 1; return 1; } Besides, resetX (i) functions reassign the maximum value to a timer, where X represents the initial letter of the timer involved, as it is shown in Algorithms 2-5.
Algorithm 2. resetH (i): Furthermore, on the one hand, the init(i) function represents a router i joining the OSPF domain, which is represented by the variable ti = 0 and so is the hello timer so as to begin the neighbour discovery straight away, whilst the rest of the timers are set to infinite as they are useless at that point of time.All of that might be seen in Algorithm 6. Algorithm 6. init (i): As per the hello timer, a router i will be constantly sending hello packets on a regular basis through all of its OSPF interfaces every time the hello timer reaches zero value.Right after that, the resetH (i) function will be resetting it to its highest value and the time (i) function will be decreasing it at each simulated second until it reaches zero value the next time, repeating this cycle over and over again as long as router i remains into the OSPF domain.
Later on, when a router i starts receiving hello packets, its dead timer will be set to its maximum value, as a new neighbour relationship has been established.Therefore, that dead timer will start playing its part, increasing its value according to the resetD (i) function and decreasing it in line with the time (i) function, analogously as exposed for the hello timer.This cycle will go on over and over again until the router leaves the OSPF domain.Also, when a router i establishes a new adjacency relationship, it will start the process of sending and receiving LSA from its adjacent routers.At that point, the refresh LSA timer and the max age LSA timer will start playing their part when sending and receiving LSA, respectively.Both timers will be decreased by the time (i) function whereas the former will be increased to its maximum value by the resetR (i) function and the latter will be done by the resetM (i) function.
On the other hand, the kill (i) function represents a router i leaving the OSPF domain, which is represented by variable i t   and so are the rest of the timers, effectively blocking them all.This might be seen in Algorithm 7.
Algorithm 7. kill (i) Regarding LSA exchange process, an update (i) function has been added up in the Ra,i term in order to check whether each LSA header received by a local router i within an OSPF type 2 packet, also known as Description Data Base (DBD) packet, is more up to date than that of the corresponding LSA stored on its own LSDB copy.
For each incoming LSA headers meeting this condition, the local router i will be requesting the full LSA from the proper DBD sender in order to perform the LSA update out of its local LSDB.Furthermore, if the LSA is brand new, it does demand it as well.That might be seen in Algorithm 8.
For the purpose of keeping the update (i) function as simple as possible, both the incoming LSA header and the already existing full LSA within the local LSDB are solely identified by its LS ID field and the most up to date instance Simplifying the former expression by taking out the effect of algorithms and timers, it yields the following equation, which proves that all communications takes place as expected according to the OSPF v2 standard explained in this paper, either synchronous as in the first curly brackets or asynchronous as in the second ones ( 2) ( 3) ( 4)

VI. MODEL VERIFICATION
Taking into account that ACP is a sort of an abstract algebra, the verification of the model designed herein might be undertaken using proof by contradiction, in a way that if an initial proposition is stated and a logical contradiction arises whilst reasoning on that premise, then the aforesaid initial statement must be false, otherwise is true.
As stated before, the OSPF process relies on the exchange of type 1 packets for neighbor discovery and type 2 to 5 packets for LSA exchange, the former allowing neighbourhood relationships and the latter satisfying adjacency relationships.
Taking a look at the final expression at the end of the previous section, obtained for n = 2, although it might be extrapolated for any other number of routers by applying expressions (4) and (5), it is clear that exchanges of hello packets (PT1) among any pair of neighbouring routers are performed, as well as exchanges of new LSA (PT4) among any pair of adjacent routers, all of that according to the first pair of curly brackets.And by looking at the second pair of them, the synchronisation process of LSA is also performed.Hence the model designed mirrors the OSPF expected behaviour, related in the OSPFv2.
OSPF routing table depends on the correct LSA exchange.So if that process is performed properly, a couple of premises will apply, such as there will always be at least a path between any two routers located into the OSPF domain, as well as if a path goes down between a source and a destination and there is a redundant path to the same destination, then that other path may be used to get there.
According to the model, the first one is met because neighbour relationships will be established for each pair of neighbours within the OSPF domain, due to the exchange of PT1 packets.Additionally, the second one requires for the model to discover all paths from one source to one destination, and that is performed by establishing adjacency relationships for each pair of adjacent routers within the OSPF domain, due to the application of the ki,j coefficients and the exchange of PT2, PT3, PT4 and PT5 packets.

VII. CONCLUSIONS
In this paper, we have been working through the achievement of a formal detailed modelling of OSPF.For that purpose, ACP syntax and semantics have been used in order to perform manual algebraic derivations.
The main points taken into account to reach the aforesaid modelling have been the application of the timers involved in OSPF and the description of the LSA exchange process, as stated in the OSPF v2 standard.
A practical example has been proposed with a peer to peer network composed by 2 routers and after performing the proper algebraic derivations, its behaviour mirrors that of the real OSPF routing protocol.
That outcome may be replicated for any other kind of network with 2 routers, as an adjacency relationship will always be established, no matter the network type.
Eventually, that result might be extended for any type of multiaccess network with a higher number of routers, as the only difference will be adjacency relationships among them.
Therefore, the proposed ACP model for OSPF routing protocol meet the specifications of the standard OSPFv2.

TABLE I .
NETWORK TYPES.

TABLE II .
HELLO AND DEAD TIMERS.

TABLE III .
OSPF ADJACENCY RELATIONSHIP.

TABLE IV .
VALUES ASSIGNED TO ROUTER ROLES.

TABLE V .
OSPF PACKET TYPES.