Formal Specification of Spanning Tree Protocol Using ACP

Spanning-Tree Protocol (STP) has nowadays been implemented by most manufacturers in order to avoid loops in bridged networks. IEEE 802.1D STP is the original standard and it is run as a distributed algorithm by every bridge. In this paper we propose a formal specification of that STP by using a Process Algebra named Algebra of Communicating Processes (ACP), following a manual approach. Furthermore, STP protocol verification has been performed, both in a formal and in an informal way.DOI: http://dx.doi.org/10.5755/j01.eie.23.2.18005


I. INTRODUCTION
Redundancy is a key feature in today's networks that provides fault tolerance topologies, thus cracking down on unplanned downtime, such as that caused by system or communication failures.
This concept may be modelled by using Formal Description Techniques so as to check whether some behavioural properties are met.In order to do that, a model is first designed as close to real as possible, then a formal specification is algebraically derived based on the aforesaid model, and eventually a verification procedure is performed to prove it right.
As far as redundancy in the networking field is concerned, we must focus on the OSI model [1], as it is necessary to distinguish between data link layer cases (OSI layer 2) and network layer cases (OSI layer 3).
The difference is that headers in layer 3 protocols have a TimeToLive field which is a reverse counter being decremented one unit at every hop, which lets the packet being discarded if it reaches zero.Therefore, a packet within a layer-3 loop will eventually be rejected and it will then disappear from the network.
Otherwise, headers in layer 2 protocols do not have such a field, so a frame within a layer-2 loop will never be rejected and will be forever into the network, thus consuming network resources, slowing down network performance and eventually bringing down the network segment.This fact is known as broadcast storm and it must obviously be avoided.
Therefore, extreme care should be taken when dealing with layer 2 loops, composed by bridges, as they could cause fatal consequences in the network performance if a bridging Manuscript received 29 September, 2016; accepted 17 January, 2017.loop is formed.
Regarding redundancy at data link layer in the OSI model, the most important methods are link aggregation allowing multiple physical links to be treated as a single logical one but letting the link up whether any of its components comes down and the Spanning Tree Protocol (STP) allowing the construction of a logical loop-free tree within a physical loop topology, the latter being the key player.
STP algorithm was first designed by Radia Perlman back in 1985 [2] but it was not until 1990 that the protocol got first standardised as an architecture for the interconnection of IEEE 802 Local Area Networks under the name IEEE 802.1d-1990, superseded later in 2004 by IEEE 802.1d-2004 [3].This one is usually called the original STP.
Some amendments were added up throughout the years to that original STP, resulting in the issue of a new standard in 2001, namely IEEE 802.1w.The main point of it was the dramatic reduction of the delay required in the switch to get into forwarding state, and that is why it is usually called rapid STP.
Both STP versions, the original one and the rapid one, build a unique STP tree within a physical loop in order to reach all bridges by conforming a path with the least cost among all the members of that physical loop.The effect of converting a loop into a tree is breaking the physical loop in a logical manner by blocking one of the ports within the loop whilst all of its members may still get to any other one.
In the meantime, some manufacturers implemented a per VLAN version of both protocols, allowing the implementation of a different STP instance for every VLAN deployed in the bridges within a loop.This allows the possibility of having a different blocking port in different VLANs, so permitting load balancing strategies within the physical loop.
This variation may initially seem fully beneficial, but there are a couple of drawbacks as more network resources are needed as the number of VLANs grows and additionally there are only two different paths to go through a loop.
In order to cope with that, a new standard was released in 2002, namely IEEE 802.1s, making possible to associate different VLANs to a single instance of STP, hence permitting the optimization of network resources consumption, as when many VLANs are defined, some of them will share the same STP structure, so the same port will be in blocking state.Because of this, it is usually called multiple STP.
The standard supporting the use of VLANs is IEEE 802.1Q, which also incorporates all STP implementations defined so far, all of them being backward compatible to each other, thus allowing the interconnection of bridges with different implementations of STP.
Regarding STP specification and verification using formal methods [4], there is a shortage of papers in the literature concerning this area.Among the few of them, two categories might be distinguished, namely, those working specifically with original STP and those doing it with distributed leader election algorithms.
On one hand, within the first group it is worth mentioning [5] and [6], although the model implemented in both papers is not the typical bridge loop seen in production networks, as the modelled loops therein are formed by an alternation of bridges and LAN segments whilst real production loops are usually formed just by bridges and LANs are connected to those bridges.
On the other hand, within the second group it is worth citing [7]- [9], where different leader election algorithms in a distributed fashion are presented and verified using various tools.STP-like implementations are built with those algorithms for diverse situations, even though none of them are particularly designed to fit the original STP algorithm specifications.
Therefore, the idea herein is to create an STP model whose behaviour is as close to the original STP specification as possible.Furthermore, a distributed algorithm will be designed following the aforesaid specification, which will be part of that overall STP model.
The organisation of this paper will be as follows: first, Section II introduces ACP, then, Section III presents an STP informal specification, next, Section IV shows an STP bridge model, after that, Section V works on STP formal specification, later, Section VI performs STP verification, and finally, Section VII will draw the final conclusions.

II. ALGEBRA OF COMMUNICATING PROCESSES
There are many ways to specify and verify communication protocols but maybe the most elegant and effective method is based on abstract algebras.They could be seen as the branch of algebra aimed at studying the algebraic structures, such as groups, rings or fields, along with their associated homomorphisms.
Communication protocols are usually composed of some processes executing in a concurrent manner, in a way that they interact with each other and at the same time with their environment.Therefore Process Algebras might be considered as a mathematical framework to work and reason with concurrent processes in a formal way [10], similar as abstract algebras do.
Process Algebras contain basic operators to label finite processes, communication operators to work with concurrency, recursion to outline infinite behaviour, encapsulation operators to force actions into communications and abstract operators to hide internal computations [11].
When working with Process Algebras, it is crucial the concept of bisimulation equivalence, or bisimilarity, meaning that two processes are bisimilar if they can execute the same string of actions and they have the same branching structure as well.This concept helps identify equivalent systems just according to the behaviours of their process terms, thus abstracting away from other details.As happens with abstract algebras, axiomatisation models have been created in order to prove that two process terms are bisimilar, meaning that they are behaviourally equivalent.
There are three main approaches to Process Algebras and concurrency [12], such as CSP (Communicating Sequential Processes), CCP (Calculus of Communicating Systems) and ACP (Algebra of Communicating Processes).
Among them, ACP aims to present a system of axioms in order to describe process theory without caring about the mathematical definition of a process, thus abstracting away from the real nature of those processes.
In this paper, we are going to focus on ACP, but this has a limitation as it just works with processes.Therefore, in order to add up data types to the models, there are some extensions, such as the software packages µCRL and its evolution mCRL2 [13], which also allows the introduction of time constraints, or alternatively the package CADP [14].

III. STP INFORMAL SPECIFICATION
The focus in this paper will be put on the operation of the original STP.This protocol is on by default in all ports of a bridge.
The premise to understand STP is to distinguish between control-plane traffic and data-plane traffic among bridges.On one hand, the former consists of device-generated frames required for the proper operation of a network, named BPDUs, an acronym standing for Bridge Protocol Data Unit, providing the path that the latter must follow.On the other hand, the latter consists of user-generated frames being forwarded to another user.Therefore, it may be said that the former shows the way that the latter follows.
The basic function of STP is to prevent loops in dataplane traffic, so it converts a physical bridge loop into a logical tree-like structure, where there is no loop.
In order to accomplish that, STP chooses a particular bridge to be the Root Bridge and assigns costs to each link within the loop.That way, the port belonging to a bridge within the loop whose path to the Root Bridge has got the largest cost will be blocked for user data traffic, thus effectively breaking the loop.
Regarding control-plane traffic, every link joining two bridges within a loop must have an end whose role is to be a Designated Port, which is the one sending BPDUs, whereas the other end may have a role as either a Root Port or a Non-Designated Port, which is the one receiving BPDUs.
Each bridge within a single loop has only two neighbours, hence the Root Bridge will have both of its ports within a loop when operating in Designated Port role.
Alternatively, the non-root bridges must have a port with the least cost to the Root Bridge within a loop when running STP in the Root Port role.The role of the other port in a non-root bridge may be Designated Port if it propagates along the BPDUs issued by the Root Bridge and received by its Root Port, or otherwise Non-Designated Port if it does not propagate them any further, and that will depend on the STP algorithm calculations.
Accordingly, BPDUs are sent from all Designated Ports to the other end of each link depending on the HelloTimer settings, which is 2 seconds by default.Those BPDUs are generated by the Root Bridge and will travel along the topology from bridge to bridge until they reach the only one Non-Designated Port, where they will stop.
In a way, STP might be compared like a double path starting at the Root Bridge and ending at the non-root bridge having the Non-Designated Port.Consequently, there must be just one Root Bridge and one Non-Designated Port within a bridge loop.
In relation to data-plane traffic, it follows the role ports to assign a state to each port.This is, Designated Ports and Root Ports will be set in Forwarding state, thus sending and receiving user data traffic, whereas the Non-Designated Port will be put in Blocking State, thus being the port breaking the loop as no user data traffic will be allowed.
In short, control-plane traffic is associated with role ports, whereas data-plane traffic is linked to state ports.All these information will be given by the outcome of the STP algorithm, which basically will appoint the Root Bridge and the Non-Designated Port within a non-root bridge.
As far as STP operation is concerned, when a bridge first gets connected to other bridges, it assumes it is the Root Bridge, therefore its ports are all in Designated role and they start sending BPDUs out to its neighbour bridges.
As long as those other bridges receive those BPDUs, they run the STP algorithm in order to check whether the values received are better than theirs referring to the election of the Root Bridge and all port roles within the bridge loop, including the Non-Designated Port.If this is the case, they will update the aforesaid values accordingly.
The STP algorithm makes tie-breaking decisions based on a sequence of four conditions: lowest BridgeID, lowest root path cost to Root Bridge, lowest sender BridgeID and lowest sender PortID.The first one gets the Root Bridge, whereas the other ones get the port roles for all bridges taking part in that loop in a tie-breaker fashion.
With regard to BridgeID, it is the concatenation of priority and MAC address, being the latter a unique value.This makes that attribute an ultimate tie-breaker in order to choose the Root Bridge.Furthermore, PortID is also unique, so that will be an eventual tie-breaker when dealing with port roles.In short, those sequential tie-breakers will assure that there will be only one Root Bridge and one Non-Designated Port in any bridge loop.This is an STP informal specification, but we are looking forward to implementing an STP formal specification that captures the protocol behaviour by getting some ACP bisimilar process terms.

IV. STP BRIDGE MODEL
The first step in order to formally specify the STP protocol is to get a model of the main tasks performed by a single bridge.For that purpose, it must be taken into account that a loop of bridges is formed by n bridges, so each one might be enumerated from 0 to 1 n  .
The proper mathematical structure to model this would be modular arithmetic, this is n Z , where integer numbers go around in a circular fashion according to the operator modulo n , being n a natural number.
Those integers modulo n are obtained as the remainders of the division of an integer by n and thanks to the congruence relation in modular arithmetic, the following properties apply: The next step is to get the proper expression in ACP for implementing a number of processes running concurrently.This equation is provided by the Expansion Theorem presented by Bergstra and Klop [15] and expands ACP axioms for parallelism to n objects executing simultaneously.
That equation is shown below where The aforesaid expression states that left merge (||_) and communication merge (|) are altogether able to cover the behaviour of concurrency (||), facilitating its mathematical treatment.Both operators will be defined at a later stage.
This fact makes possible to calculate the interaction of n concurrent processes, but regardless of how many bridges you have in a loop, each bridge will only interact with its two neighbour bridges.Therefore a bridge i   i B would have a connection with its predecessor bridge B  and another connection with its successor bridge 1 On the other hand, the connection getting to bridge i from its neighbour bridge 1 i  will be named as channel i whereas the connection going from bridge i to neighbour bridge 1 i  will be called channel Additionally, each bridge will have an associated timer signalling when the HelloTimer goes off   i T and the connection from that timer i to its corresponding bridge i is called i t .
Putting all together, we get a topology for a loop with n bridges as in Fig. 1, where all elements are enumerated following the modular arithmetic rules.
With this nomenclature in mind, the next step will be to define the diverse actions a bridge may perform.These actions may be:  sending BPDUs to its neighbour bridges, but only when the HelloTimer goes off and only if the port looking at a particular neighbour is in Designated role,  receiving BPDU from its neighbour bridges at any time and no matter what role the port looking at a particular neighbour is in,  killing the bridge after the MaxAgeTimer reaches its limit, which is usually α times the HelloTimer, being α a predefined constant value, holding 10 by default,  initialising the bridge, hence the STP protocol, when first connecting to a network, as all ports will go into blocking state at the beginning.In order to model those actions, first it is necessary to define the structure of a generic process i B , which is composed of a collection of fields.Some of those fields are built-in features, meaning they cannot be changed, such as the MACaddress and both PortNumbers, which will play the role of ultimate tiebreakers in STP algorithm.In order to simplify things in this model, the former will take the i value and the latter will get the values of the channels connected to it.
In relation to PortNumbers, they will be expressed in the array notation, where the array index will be used to distinguish them both.This way, index zero will be assigned for the one facing channel i and index one for the one facing channel 1 i  mod n .This notation will also be used in all fields related to ports.Some other fields are configurable features, meaning they have a default value, but that value might be set up when building up a new bridge, as BridgePriority and both PortCosts and PortPriorities.The default values assigned to them are 32768 to the first one and 4 to the second ones, simulating the default cost given by STP to GigabitEthernet links.As per the third values, it will be 128, simulating default STP values as well.
There are two composite fields formed by concatenating other two.One of them is called BridgeID and is obtained by joining the BridgePriority and the MACaddress.The other one is named PortID and is built by attaching the corresponding PortPriority and the PortNumber.Both values will be obtained when initialising the bridge and they contain the ultimate tie-breakers for the STP algorithm.
Also, there are other two fields for SupplierBridges that will be known during the first exchange of BPDUs, as neighbouring bridges do not change whilst they are on.
The rest of the fields will have changing values according to each execution of the STP algorithm.Those fields are RootID, RootPathCost, both PortRoles and BridgeFlag.
All those fields and its default values are set in Table I. 128.iPortID [1] PORTID [1] 128.(i+1 In order to initialise process i B , this is, providing the default values to all fields just described related to the bridge i , an algorithm called i INIT will be implemented.Default values will be assigned to those fields in order to simplify the implementation, as shown in Algorithm 1.However, it might be possible to customise any of the aforesaid configurable values just by adding up more arguments to the i INIT algorithm and checking up the number of arguments passed to the algorithm. An example of this would be an If-Then-Else-EndIf structure where if NumArgs==2, then the second argument might be assigned to the bridge priority, thus modifying its default value.This part has not been implemented for simplicity purposes.Algorithm 1. INIT(i): Regarding the sending BPDU action, it is necessary to define a variable showing which role a port is in.This variable has been named as , i j P , where i is the bridge identifier and j is the channel that port belongs to.In order to distinguish the different roles a port might be in, , i j P may hold the following values exhibited in Table II.If the value related to the port role is zero, that port will be sending BPDUs along the link and it might also be receiving them at early stages of the STP process, but it will not send them if that value is greater than zero, as it will only be receiving them.When used in equations, logical NOT ( P  ) will be applied in order to be 1 for Designated ports, or otherwise to be 0 for the rest of roles.
In other words, at the beginning every port within a bridge loop will be sending BPDUs, but after a number of BPDU exchanges among them, every link within that bridge loop will have an end where this variable holds zero and another end with a higher value, despite both sides having zero value at the very beginning.
At this point, it is time to define the algorithm called i BPDU , which will be the one to carry the values of some fields of a bridge i and passing them along to its neighbouring bridges.Those values included in BPDUs are BridgeID (BID), RootID (RID) and RootPathCost (RPATH) corresponding to ( ) ( )

V. STP FORMAL SPECIFICATION
Starting from the previous bridge model, and in order to simplify calculations, we are going to work with the most well-known loop topology for bridges, which is the triangular one, this is, three bridges forming a loop.The reasoning behind this case scenario may be analogous to a loop formed by n bridges, as each bridge will only interact with its two neighbouring bridges.
By adapting (5) to this case, we obtain the model for each of those three bridges:    ACP notation has been used herein, but as stated previously, that process algebra is only able to reason about process terms.However, these models use not only processes, but also data structures and time.Therefore, the aforesaid models must be rewritten accordingly, thus cancelling time-related variables and all the algorithms.
The resulting ACP model for each bridge will be reduced to the sending and receiving actions, whereas STP algorithm will be executed directly at the receiving end whenever there is communication in any channel and in any direction: Elsewhere, regarding ACP, it must be taken into account the various possible types of outcome given by the communication function.The point is that communication will happen whenever a bridge sends a message through a channel and its neighbour bridge at the end of that particular channel reads it.All other kind of combinations between sending and receiving bridges will result in deadlock (δ).
Therefore, these are the valid combinations leading to communication among bridges within our topology: BPDU sent out of any given channel or received from any given channel.Therefore, if an element within the encapsulation operator belongs to set H , the result of applying this operator to it will be δ (deadlock), whereas that same element will be invariant otherwise.
In addition to it, (4) must be adapted to this case with three concurrent bridges, which leads to Therefore, when running three processes concurrently, the outcome shows six terms, the first three of them starting with a left merge operator ( ||_ ) and the last three doing it with a communication operator ( | ).According to ACP axioms, the behaviour of the former is ( ) || _ ( || ) v x y v x y    and that of the latter has already been treated.So the terms starting with a left merge operator will become deadlock as all three processes are formed by terms starting by either sending or receiving actions, because when applying the encapsulation operator both actions belong to set H defined above.That means the only interesting terms are the ones starting with a communication operator.
With those points in mind, we proceed to derive (12), considering that at the very beginning all ports are in Designated role and will be sending BPDUs, therefore

TABLE I .
FIELDS WITHIN THE BRIDGE PROCESS.

TABLE III .
VALID COMMUNICATION ACTIONS..This must be taken into consideration as it will simplify calculations by cancelling terms.Furthermore, the encapsulation operator H  will be used to force atomic actions into communications, by hiding all sending and reading actions over all channels, thus leaving just allowed communications, as in TableIII.