Introduction
Routing protocols define how routers communicate with each other to share information and determine the best paths between two nodes in a network.
Routing protocols are categorized based on their operational scope into two main types: i) Interior Gateway Protocols (IGP), such as RIP, IS-IS, EIGRP, and OSPF, which exchange routing information within a single Autonomous System (AS); and ii) Exterior Gateway Protocols (EGP), like BGP and EGP, which facilitate the exchange of routing information between different Autonomous Systems (AS).
Routing protocols are categorized into two types: static and dynamic, based on how routes between routers are determined Dynamic routing protocols are crucial for transit networks, consisting of two main components: the routing protocol, which facilitates the exchange of network information between routers, and the routing algorithm, which determines the optimal paths through the network While the routing protocol defines how a router communicates externally, the routing algorithm manages internal information processing within the router.
Two common types of dynamic routing protocols are: i) Distance Vector: Routes are calculated by each router and exchanged with its neighbors ii) Link State: Information about neighbors is shared among routers, which calculate routes based on a complete view of the network topology.
OSPF est le protocole de routage IP interne (IGP) qui est largement utilisé sur Internet
In this chapter, we will explore the Dijkstra routing algorithm utilized in OSPF We will also examine how information is disseminated among OSPF routers, specifically focusing on OSPF version 2 for IPv4.
Vue générale d'OSPF
OSPF, or Open Shortest Path First, is a link-state routing protocol where each interface of an OSPF router is assigned a metric that reflects the cost or weight of the link to other routers This metric varies for point-to-point and point-to-multipoint links OSPF routers communicate link states related to their interfaces with neighboring routers, ensuring efficient routing within the network.
An OSPF router constructs a comprehensive view of the network topology, which can be conceptualized as a connected, directed, and weighted graph In this graph, each vertex represents a router, while the edges symbolize the connections between neighboring routers Utilizing this graph and Dijkstra's algorithm, each router calculates a Shortest Path Tree (SPT) with itself as the root, determining the shortest paths to other destinations This SPT is subsequently used to build the router's routing table and its Forwarding Information Base (FIB).
Compared to RIP (Routing Information Protocol), which is a distance-vector internal routing protocol, OSPF (Open Shortest Path First) offers significantly faster convergence times, typically within a few seconds Additionally, OSPF is more bandwidth-efficient, as it only transmits HELLO packets and Link State Advertisements (LSAs) during periods of topology changes.
OSPF (Open Shortest Path First) is an internal routing protocol that operates on a link-state basis, similar to IS-IS (Intermediate System to Intermediate System), and utilizes Dijkstra's algorithm It requires routers to have ample memory to store the Link State Database (LSDB) and a powerful processor to compute the shortest path tree, especially in large topologies Additionally, OSPF configuration can be complex, particularly when the network is segmented into multiple areas.
OSPF pour IPv4 (OSPF version 2) est détaillé dans RFC 2328 [29].
Algorithme Dijkstra
The algorithm proposed by Edsger Dijkstra in 1959 calculates the shortest paths in a graph with non-negative link weights by constructing a Shortest Path Tree (SPT) Given a graph G(V, E), where V represents the set of N vertices and E the M edges, the SPT for a source node S is built using two subsets: P, which contains visited nodes, and Q, which holds the remaining nodes Each node is assigned a label consisting of the preceding node and the temporary distance from the source (S) Initially, P contains only S, while the labels for the remaining (N-1) nodes are set to (S, ∞) During each iteration, the temporary distances and labels for each node are recalculated according to a specific procedure.
/* nous balayons toutes les noeuds qui ne sont pas visités */
{ /* nous recalculons la distance minimale temporaire et l'étiquette de chaque nœud dans Q */
Si u is neighbor of c et tentative_distance(c)>tentative_distance(u)+distance(u,c) alors
/* la nouvelle étiquette de c */ label(c)=u;
/* label(c)={u}, au cas d'ECMP: il y a plusieurs plus courts chemins d'un routeur vers d'autres */
/* la nouvelle distance minimale temporaire de c */ tentative_distance(c)=tentative_distance d(u) +distance(u,c) }
Algorithme 2-1: L'assignation des étiquettes pour les nœuds à chaque itération de l'algorithme
Ensuite, les nœuds avec des distances temporaires minimales sont fixés et insérés dans P
Nous stockons également les étiquettes de ces nœuds Cette boucle se termine lorsque Q est vide
From the labels of the nodes, we can identify the edges of a Shortest Path Tree (SPT) This structure is an acyclic connected graph, as it features paths from the root to other nodes, ensuring it is directed and connected If a loop were present, the shortest distance from any node in the loop to itself (0) would equal the length of the loop, which confirms the acyclic nature of the tree.
Figure 2-1: Une topologie d'un réseau OSPF
In the network topology illustrated in Figure 2.1, there are five routers The router with the IP address 192.168.3.1 has two interfaces: 192.168.1.1/24 and 192.168.3.1/24 Meanwhile, the router at 192.168.1.2 connects to router 192.168.5.1 through its eth2 interface, which has the address 192.168.4.1/24, while the connecting interface on router 192.168.5.1 is 192.168.4.2/24.
La métrique de ce lien est 10 Nous pouvons représenter la topologie du réseau sous forme d'un graphe comme suivant (la figure 2.2)
Figure 2-2: La représentation sous forme d'un graphe de la topologie
En plus, ce graphe peut être représenté par une forme compréhensive pour l’ordinateur : une matrice des voisins (la figure 2.3)
Figure 2-3: La matrice des voisins
We utilize Dijkstra's algorithm to determine the shortest paths from router C to other routers The iterations of the algorithm are illustrated in Figure 2.4, while the fixed labels are shown in Figure 2.5.
Figure 2-4: Les itérations de l'algorithme Dijkstra
Figure 2-5: Les arêtes du SPT du routeur C
Notons que dans ce cas, il y a deux plus courts chemins de A vers D: ACBD et ACED
(nous l’appelons Equal Cost MultiPath, ECMP) Pour traiter ce cas, nous avons modifié l'algorithme Dijsktra pour que les étiquettes temporaires de chaque nœud soient stockées dans une liste (l’algorithme 2-1)
Avec les arêtes dans la figure 2.5, le SPT du routeur C est reconstruit comme dans la figure 2.6
Figure 2-6: L'arbre des plus courts chemins du routeur C
La constitution de FIB
The Forwarding Information Base (FIB) is a crucial component of a router that stores forwarding information It functions similarly to a routing table or information base, dynamically reflecting the forwarding data found in the routing table When there are changes in routing or network topology, the routing table is updated, and these modifications are subsequently reflected in the FIB Essentially, the FIB retains the next-hop address information based on the details from the routing table.
Le FIB d’un routeur OSPF se base sur l’arbre des plus courts chemins du routeur vers d’autres
Based on the shortest path tree illustrated in Figure 2-6, the Forwarding Information Base (FIB) for Router C in the topology shown in Figure 2.1 is depicted in Figure 2.7 In this FIB, to route packets to Router A (ID: 192.168.3.1), Router C forwards them to the address 192.168.3.1/24 (Router A's eth1 interface) through its eth0 interface Similarly, packets destined for Router D (ID: 192.168.5.1) are sent to either 192.168.2.1/24 (Router B's eth1 interface) via Router C's eth1 or to 192.168.6.1/24 (Router E's eth0 interface) through its eth2 interface.
(prochain hôte, via interface, distance)
Figure 2-7: Le FIB du routeur C de la topologie 2.1
Les zones
OSPF is utilized in Autonomous Systems (AS) managed by Internet Service Providers (ISPs) that are expanding their large networks To minimize the number of Link State Advertisements (LSAs) and the size of the Link State Database (LSDB) each router must maintain, OSPF introduces the concept of zones, enabling administrators to segment these extensive networks into smaller, more manageable areas.
Figure 2-8: La partition en zone d'OSPF [9]
In an OSPF network, areas are designated by an area-ID, with Area 0 (ID 0.0.0.0) serving as the backbone, as illustrated in Figure 2.8 This backbone connects five zones through border routers (BR) All other areas, including Area 1, 2, 3, and 4, must have a physical connection to Area 0 to ensure proper network functionality.
OSPF assigns each link to a single area, while routers with links in multiple areas are referred to as Border Routers (BR) Each router maintains a complete topology graph for each area its links belong to but does not have knowledge of the entire topology of remote areas However, through Border Routers, it can determine the total path cost from one or more BRs in each area to any router within that area Additionally, OSPF allows for the importation of routing information from other protocols, such as BGP (Border Gateway Protocol).
Le routeur qui importe les informations d'autres protocoles à OSPF est appelộ ôrouteur à la frontiốre d'ASằ (AS Border Router) [6]
OSPF calculates the shortest paths in three stages In the first stage, each router computes the Shortest Path Tree (SPT) for the internal area (intra-area stage) In the second stage, it determines routes for remote routers by selecting a border router as an intermediate node based on total weight information (inter-area stage) Finally, in the last stage, it calculates routes for each external node by choosing a border router of the Autonomous System (AS) as the intermediate node (external stage).
En réalité, pour réduire la complexité du calcul de SPT, la plupart des vendeurs des routeurs limitent la taille d'une zone entre 50 et 500 routeurs [8].
Types de LSAs (Link State Advertises)
Each OSPF router defines its local connectivity through a Link State Advertisement (LSA) These LSAs are disseminated to other routers within the network, enabling them to construct a complete view of the topology The collection of LSAs stored in a router's memory is referred to as the Link State Database (LSDB).
OSPF defines several types of Link-State Advertisements (LSAs) that play crucial roles in routing The Router LSA (Type 1-LSA) is generated by all routers and is flooded within a single area, detailing the router's interface information The Network LSA (Type 2-LSA) originates from a designated router (DR) and also floods within one area, listing the routers connected to a network The Network Summary LSA (Type 3-LSA), created by a border router (BR), is flooded in the associated area and describes routes to destinations outside the area within an Autonomous System (AS) The ASBR Summary LSA (Type 4-LSA) is also generated by border routers and outlines routes to an AS boundary router (ASBR) within its area Lastly, the AS External LSA (Type 5-LSA) is produced by ASBRs and describes routes to other ASs.
Types de réseaux
There are two types of OSPF networks: Point-to-Point and Multi-Access networks Within Multi-Access networks, three variations exist: Broadcast Network, Non-Broadcast Multi-Access Network (NBMA), and Point-to-Multipoint Network In a Broadcast Network, messages can be sent to all routers, such as in Ethernet LANs Conversely, NBMA networks, like ISDN, ATM, X25, and Frame Relay, do not support broadcasting Lastly, Point-to-Multipoint Networks are utilized in group mode within Frame Relay networks.
Conclusion
In this chapter, OSPF (Open Shortest Path First) is highlighted as a widely used link-state routing protocol on the Internet OSPF routers employ Dijkstra's algorithm to compute the Shortest Path Tree (SPT) to other routers within a given area Based on this SPT, the routes utilized for packet transfer from the router are formed in the Forwarding Information Base (FIB) OSPF routers utilize two types of Link-State Advertisements (LSAs): Router LSA and Network LSA, to share link state information within an area Different areas can exchange routes through Border Routers (BR), while the Autonomous System Border Router (ASBR) facilitates connections between routers within an Autonomous System (AS) and external networks.
Un routeur OSPF stocke les LSA dans une LSDB Il y a deux types de liens entre les routeurs OSPF: Point à Point et Point à MultiPoint
3 Boucle transitoire durant la convergence d’OSPF
Introduction
Routing loops have been a topic of discussion in literature for a long time, with two main types identified: persistent loops and transient loops Persistent loops can last for hours and are typically caused by configuration errors, while transient loops are shorter, lasting from seconds to minutes, and arise from inconsistencies in routing information Analyzing persistent loops is more challenging due to their rarity and the fact that they often occur across multiple Autonomous Systems (AS) Therefore, this work focuses on the analysis of transient loops.
In networks utilizing distance vector routing protocols like RIP, each node lacks a complete view of the network topology This can lead to a phenomenon known as "counting to infinity," where the metric of a route is repeatedly increased between two or more nodes until it reaches a maximum value.
Dans ce chapitre, nous étudierons le mécanisme des boucles transitoires durant la convergence d’OSPF lors du changement de la métrique des liens
Les boucles de routage peuvent être détectées par la trace de la répétition des instances
(replicas stream) d’un paquet dans un seul lien [23]
In this chapter, we will explore a method for detecting and enumerating all possible transient loops based on graph theory, examining the types of loops and their potential across various topologies.
Boucle transitoire durant la convergence OSPF
In OSPF, each router computes its Shortest Path Tree (SPT) based on its Link State Database (LSDB) When the network is stable, meaning there are no changes in link metrics, the Forwarding Information Bases (FIBs) of the routers remain consistent This stability ensures that there are no packet forwarding loops to any destination within the network, as the Shortest Path Tree from all routers to that destination will not contain any loops.
When a link metric changes, LSA exchanges do not allow routers to update their FIBs simultaneously Routers closer to the link update first, while those farther away follow They utilize new routes to forward their packets efficiently.
Ce trafic peut être envoyé vers les routeurs plus loin
While the routes of distant routers remain unchanged due to the lack of notification about the change, traffic is redirected to preceding routers This loop continues until the distant routers receive the change notification via a Link-State Advertisement (LSA) Once all routers in the network update their Forwarding Information Bases (FIBs), the loops cease to exist The process of achieving consistency in the routes across all routers is known as OSPF convergence, which typically lasts only a short duration, often around a minute Consequently, the loops are transient during this period.
Dans la topologie de la figure 2.1, supposons que la métrique du lien entre l'interface 192.168.2.1 du routeur 192.168.1.2 (B) et l'interface 192.168.2.2 du routeur 192.168.2.2 (C) est reconfigurée par 30
Figure 3-1: Le SPT du routeur B avant le changement
Figure 3-2: Le FIB de B avant le changement
Figure 3-3: Le SPT du routeur D avant le changement
Figure 3-4: Le FIB de D avant le changement
Before the reconfiguration, according to the Forwarding Information Base (FIB) of router D, packets intended for destination A are sent to router B From B, the packets are forwarded to router C, and then from C to A The routing paths in the FIBs of the routers are consistent.
Figure 3-5: Le SPT du routeur B si la métrique du lien B→C est 30
Figure 3-6: Le FIB de D après le changement
If the link metric from B to C is reconfigured to 30, B will update its Forwarding Information Base (FIB) before D because it receives the change notification first According to B's new FIB, it will forward packets to either C or D for the destination A Meanwhile, since D does not receive the change notification, it does not update its routing table and will send the packets it receives from B back to B, resulting in a loop between B and D.
Lorsque D reỗoit la notification de changement d'un LSA envoyộ de B ou E, les routes deviennent consistantes et la boucle sera disparue.
Détection des boucles transitoires
Dans cette section, nous utiliserons le théorie de graphe pour analyser des boucles transitoires dans les réseaux OSPF
Nous définissons, d'abord, l'arbre inversé des plus courts chemins rSPT (reverse Shortest
Given a connected and weighted graph G=(V,E), where V represents the set of nodes and E represents the set of edges, for a destination D within V, a link X → Y in E, the rSPT D (X→Y=m) is defined as the combination of the shortest paths from other routers to D in the graph when the metric of the link X → Y is set to m.
C'est un arbre parce que comme analysé dans la partie 2.3, il est orienté et il n'y a pas de boucles
We can utilize Dijkstra's algorithm to compute the tree on the graph by swapping the weights of each edge, meaning the metric of the link from X to Y becomes that of the link from Y to X, and vice versa.
As analyzed in section 3.2, transient loops occur only when both new and old routes are utilized within the network Theorem 3.3.1 facilitates the detection of loops for packet transfer to a destination.
Theorem 3.3.1 states that for a graph G=(V,E) with a destination D and a link X→Y, if a transient loop occurs in the network when the metric of link X→Y changes from m to M while other metrics remain unchanged, a cycle will form in the graph that represents the merging of the reverse Shortest Path Tree (rSPT) at destination D.
(X→Y=m) et rSPT D (X→Y=M) et vice-versa[1]
Un exemple est illustré dans les figures 3.4, 3.5, 3.6, 3.7
Figure 3-10: La fusion des rSPT et une boucle B→D→B
Dans ces figures, lorsque la métrique du lien B→C passe de 10 à 39, il y a une boucle entre B et D parce que B met à jour son FIB avant D Pour éviter cette boucle, il faut que
D le fasse avant B C'est l'idée d'un algorithme d'évitement des boucles qui s’appelle ô ordered FIB update ằ prộsentộ dans [1].
Destinations influencées par un changement de métrique d'un lien
Dans la partie 3.3, nous pouvons trouver les boucles possibles dans un réseau pour une destination D dans la fusion de deux rSPTD: avant le changement et après la convergence
Si nous balayons toutes destinations, nous détecterons toutes boucles dans un réseau
When there is a change in the metric of a link X→Y, only the paths utilizing this link to reach a destination Z are affected Consequently, Y is part of the shortest path from X to Z.
Conversely, if node Y is not part of the shortest path from node X to node Z, the routes to node Z from other nodes remain unchanged even when the metric of the link from X to Y is altered.
In Figure 3.11, node A is part of the shortest path from B to E, but not in the paths from B to C or D When the link metric from B to A changes, the routing paths rSPTD and rSPTC remain unaffected However, the routing path rSPTE may change if certain routes to E no longer utilize the link from B to A.
Cette idée est détaillée par la propriété 3.4.1
Property 3.4.1 states that for a graph G=(V,E), a link X→Y that belongs to E influences destinations affected by a change in the metric of the link X→Y These destinations are located in the subtree of the shortest path tree rooted at Y.
Figure 3-11: Destination influencée par un changement de la métrique du lien B→A: E
Analyse de topologie
Cette section étudie la potentialité d'occurrence des boucles transitoires durant la convergence d'OSPF aux topologies particulières
Tout d'abord, nous distinguons deux types de boucles transitoires: micro boucle et macro boucle
Micro boucle ne contient que deux routeurs (la boucle longueur-2) La longueur des macro boucles est plus de 2
A study investigated the occurrence of potential micro-loops across four topologies: Tier 1 A, Tier 1 B, ISP 1, and ISP 2, during link metric changes Tier 1 A comprises 200 nodes and 800 links, while Tier 1 B consists of 110 nodes and 400 links In contrast, ISP 1 and ISP 2 are smaller networks, with ISP 1 having 50 nodes and 200 links, and ISP 2 containing 30 nodes and 60 links.
The result indicates that all loops are of the micro type In Tier 1-A, micro loops can occur when 50% of the links are broken Additionally, with ISP 1, ISP 2, and Tier B, a change in the metric by 40% of the links can also lead to the formation of micro loops.
Figure 3-12: Topologies potentielles pour les boucles transitoire qui contiennent des carrés ou/et des anneaux
In network topologies, the number of loops is generally influenced by the number and length of rings, as illustrated in Figure 3.12 Specifically, longer rings tend to result in more transient loops This occurs because any change in the metric of a link X→Y within a ring can create a loop For any two nodes A and B located within the same ring, there are at least two paths connecting them: one that traverses the link and another that does not.
A vers B passe X→Y, A pourra changer son plus court chemin vers B lors du changement de la métrique de ce lien Le changement du chemin de A vers B peut provoquer une boucle.
Conclusion
In this chapter, we discussed routing loops, specifically persistent and transient loops Transient loops during OSPF convergence occur due to updates in the routers' Forwarding Information Bases (FIBs) when a link's metric changes These loops are identified through the merging of two inverted trees of the shortest paths to a destination Routing loops for all destinations can be detected by examining only those affected by the change in a link's metric Generally, topologies with long rings are likely to cause these loops.
4 Éviter des boucles transitoires par la reconfiguration des métriques
Introduction
Beaucoup de solutions d’évitement des boucles de routage ont été proposées dans littérature Les solutions précédentes utilisent les échanges des messages entre les routeurs
The DUAL (Diffusion Update Algorithm), a key component of Cisco's EIGRP protocol, is widely recognized for its effectiveness in preventing transient loops and the counting-to-infinity problem in distance-vector routing protocols This algorithm plays a crucial role during topology changes or metric adjustments, ensuring stable and efficient network routing.
The Condition-SNC defines the set of feasible successors as the neighbors whose current cost to the destination is lower than that known by the node A node can select any neighbor from the set of feasible successors as its next hop without notifying its neighbors or causing loops, provided that its neighbors adhere to this rule.
If the neighbor with the minimal cost towards a node's destination is within the set of feasible successors, it will be selected as the node's successor However, if this set is empty or does not include the optimal successor, the node will initiate a synchronous update procedure known as diffusing computation, by sending requests to all its neighbors and waiting for their acknowledgments before changing its successor.
The Loop Free Invariants Algorithm (LFI) introduces a pair of invariants based on the cost to reach a destination node and its neighbors The algorithm demonstrates that if nodes maintain these invariants, no loops will be formed.
In LFI, a mechanism is necessary to uphold the LFI condition, integrating two approaches suitable for both types of protocols: the Multiple-path Partial-topology Dissemination Algorithm (MPDA) for link-state protocols and the Multipath Distance Vector Algorithm (MDVA) for distance vector protocols.
Pourtant, l’efficacité de DUAL et de LFI dépend de la convergence des informations échangées entre les routeurs pour maintenir les conditions de faisabilité
Using graph theory, oFIB (ordered FIB Update) clearly defines the appropriate order for updating FIBs In link-state protocols like OSPF or IS-IS, nodes are organized in an inverted tree of shortest paths, with the root being the opposite side of the link To prevent transient loops when changing a link's metric, each node must update its FIB after its children.
Néanmoins, oFIB utilise la modification du cœur du protocole de routage pour que les nœuds puissent échanger des messages et négocier cet ordre
In this chapter, we will explore the LIF (Largest Increase First) technique, which helps prevent transient loops during OSPF convergence This method involves a gradual reconfiguration of link metrics that need to be altered for maintenance purposes.
LIF ne modifie pas le cœur du protocole, ni besoin d’échanges d’informations supplémentaires entre les routeurs
In this chapter, we introduce an alternative method known as LE&DKM (Loop Enumeration and Decisive Key Metric) for calculating the sequence of metrics to be applied, and we compare the theoretical complexity of these methods.
Reconfiguration des métriques
Métrique clefs
As analyzed in Chapter 3, in a graph G=(V,E), where a destination D is an element of V and a link X→Y is an element of E, changes in the metric of the link X→Y affect the shortest path from certain nodes, such as node C, to D The shortest path from C to D (denoted as r1) relies on the link X→Y to reach D If an alternative path from C to D (for example, r2) exists that does not utilize X→Y, a change in the metric of the link X→Y may compel C to opt for r2 instead of r1 to reach D The minimum metric of the link X→Y that triggers this alteration in the shortest path from C to D is referred to as the key metric of the link X→Y corresponding to C.
Consider a connected and weighted graph G=(V,E), where D is a vertex in V and X→Y is an edge in E When the link metric from X to Y changes from m to M, the key metric of the link X→Y corresponding to a node N in V can be expressed as: m + Distance D (N, X → Y = M) - Distance D (N, X → Y = m) [1] (1).
DistanceD (N, X→Y =m) est dans la notation 1) de la cette partie
In Section 3.3, we analyze destination A, where the key metrics for link B→C associated with nodes B, D, and E are 30, 10, and 10, respectively If the metric for link B→C increases to 30, node B will have two additional shortest paths available.
1 Si la métrique du lien B→C continue à augmenter (à partir de 31), B aura seulement un plus court chemin vers A, et celui-ci ne contient pas B→C
Notons que pour un nœud N et une reconfiguration de lien X→ Y donnés, il n'existe qu'une seule métrique clef.
Séquence des métriques de reconfiguration
The ordered sequence of key metrics corresponding to a change in the state of a link is known as the Key Metric Sequence (KMS) This sequence increases when there is an improvement in the link's metric and decreases when the metric declines For our analysis, we will focus solely on the increase in link metrics, as the techniques for managing decreases in metrics are quite similar to those used for increases.
Supposons un graphe connecté et pondéré G=(V,E), D Є V, X→Y Є E, l'ensemble des métriques clefs du lien X→Y pour chaque nœud du graphe constitue une séquence des métriques clefs [1]
Dans l'exemple de la partie 3.3, chapitre 3, nous avons :
Théorème 4.2.2.1 Étant donné G=(V,E), D Є V, X→Y Є E, si la métrique de ce lien est augmentée par 1, il n'y a pas de boucle transitoire dans le réseau [1]
According to Theorem 4.2.2.1, gradually increasing the metric of the link X→Y by 1 until reaching the terminal metric can help prevent transient loops However, this approach is impractical as the resulting sequence could be excessively lengthy.
Dans [1], il a été démontré que la séquence des métriques de reconfiguration composée des métriques clefs et des métriques clefs plus 1 est une séquence qui permet d'éviter les boucles
Dans l'exemple de la partie 3.3 du chapitre 3, nous avons :
KMSA (B→C:10, 39)={10,30,39}, la séquence de reconfiguration correspondante, notée pRMSA (B→C:10, 39), est égale à : pRMSA (B→C:10, 39)={10,11,30,31,39}
Définition 4.2.2.2 Étant donné un graphe G=(V,E), D Є V, X→Y Є E avec la métrique initiale m et la métrique terminale M, sa KMS correspondante
KMS X→Y (D)={km 1 , km 2 , ,km n }, la séquence des métriques reconfiguration du lien X→Y, nRMS D (X→Y:m, M) est
{rm 0 , rm 1 , rm 2 , , rm n , rm n+1 } ó rm 0 =km 0 =m, et rm n+1 =km n+1 =M et km i-1 KM X→Y (B): rSPT D(X→Y= KM X→Y (B)) est un sous ensemble de rSPT D(X→Y= KM X→Y (A)) (cfr point 2, Théorème 4.2.2.2)
2 Si PathBA(X→Y=KM X→Y (B)) Є rSPT D(X→Y= KM X→Y (B)), étant donné (1), on a: a) C=(PathAB(X→Y=m) U PathBA(X→Y=KM X→Y (B)) Є la fusion de rSPT
D(X→Y=m) et rSPT D(X→Y= KM X→Y (B) b) Étant donné a), KM X→Y (A) > KM X→Y (B) et la définition 4.3.1.1, KM X→Y
3 Si PathBA(X→Y=KM X→Y (B)) Є rSPT D(X→Y= KM X→Y (B)): a) Étant donné la définition 4.3.1.1, PathBA(X→Y=KM X→Y (B)) Є rSPT
D(X→Y= KM X→Y (A)) b) Étant donné a), on a que C=(PathAB(X→Y=m) U PathBA(X→Y=KM X→Y (B)) Є la fusion de rSPT D(X→Y=m) et rSPT D(X→Y= KM X→Y (A), KM X→Y
1 Étant donné KM X→Y (A) < KM X→Y (B), rSPT D(X→Y= KM X→Y (A)) est un sous ensemble de rSPT D(X→Y= KM X→Y (B)) (le point 2, Théorème 4.2.2.2)
2 Étant donné (1) et la définition 4.3.1.1, PathBA(X→Y=KM X→Y (B)) Є rSPT
3 Étant donné (2), C= (PathAB(X→Y=m) U PathBA(X→Y=KM X→Y (B)) Є la fusion de rSPT D(X→Y=m) et rSPT D(X→Y= KM X→Y (A), KM X→Y (A)
4 Étant donné la définition 4.4.2.1 et (3), KM X→Y (A) n'est pas décisive pour C
La propriété est donc prouvée !
The second property pertains to the key metric that is crucial for each macro-loop It indicates that if a cycle exists between cousin nodes—nodes that have no parental relationship in the graph—applying the highest metric among the metrics corresponding to the nodes in the loop, minus one, will prevent the transient loops associated with that cycle.
Propriété 4.3.2.2 Étant donné un graphe G=(V,E), D Є V, X→Y Є E avec la métrique initiale de X→Y=m et la métrique terminale de X→Y = M , tel que
A, B Є V dans un même cycle C Є Cycle X→Y (D), Path AB (X→Y=m) Є rSPT D (X→ Y =m) et Path BA (X→Y=m) Є rSPT D (X→ Y =m),
1 Si KM X→Y (A) < KM X→Y (B), KM X→Y (A) n'est pas décisive pour C
2 Si KM X→Y (B) < KM X→Y (A), KM X→Y (B) n'est pas décisive pour C
1 Étant donné KM X→Y (A) < KM X→Y (B), rSPT D(X→Y= KM X→Y (A)) est un sous ensemble de rSPT D(X→Y= KM X→Y (B)) (le point 2, Théorème 4.2.2.2)
2 Étant donné la definition 4.3.1.1, (1) et PathBA(X→Y=m) Є rSPTD (X→ Y =m), on a que PathBA(X→Y=m) Є rSPT D(X→Y= KM X→Y (A)),
3 Étant donné (2), C= (PathAB(X→Y=m) U PathBA(X→Y=KM X→Y (B)) Є la fusion de rSPT D(X→Y=m) et rSPT D(X→Y= KM X→Y (A), KM X→Y (A)
4 Étant donné la definition 4.4.2.1 et (3), KM X→Y (A) n'est pas décisive pour C
Cas 1: KM X→Y (A) < KM X→Y (B): similaire au cas 1
Cette propriété est donc prouvée !
Théorème 4.3.2.1 Étant donné un graphe G=(V,E), D Є V, X→Y Є avec la métrique initiale de X→Y=m et la métrique terminale de X→Y = M, tel que
KMS X→Y (D)={km 1 , km 2 , ,km n }, il y a une seule métrique clef décisive pour un cycle C Є Cycle X→Y (D)
1 Si PathBA(X→Y=m) Є rSPTD (X→ Y =m), selon Propriété 4.3.2.1, KM X→Y (B) n'est pas décisive
2 Si PathAB(X→Y=m) Є rSPTD (X→ Y =m) selon Propriété 4.3.2.1, KM X→Y (A) n'est pas décisive
3 Si PathAB(X→Y=m) Є rSPTD (X→ Y =m) et PathBA(X→Y=m) Є rSPTD (X→
Y =m) a) KM X→Y (A) < KM X→Y (B), selon Propriété 4.3.2.1, KM X→Y (A) n'est pas décisive pour C b) KM X→Y (B) < KM X→Y (A), selon Propriété 4.3.2.1, KM X→Y (B) n'est pas décisive pour C
Comme la partie 4.2, nous définissons la séquence des métriques clefs décisives
Définition 4.3.1.2 Étant donné un graphe G=(V,E), D Є V, X→Y Є E avec la métrique initiale de X→Y=m et la métrique terminale de X→Y = M,, Cycle X→Y (D), l'ensemble des métriques clefs décisives constitue la séquence des métriques clefs décisives
Ensuite, nous définissons la séquence des métriques clefs décisives de reconfiguration
Définition 4.3.1.3 Étant donné un graphe G=(V,E), D Є V, X→Y Є E avec la métrique initiale de X→Y=m et la métrique terminale de X→Y = M, Cycle X→Y (D),
DMS X→Y (D)={dm 0 , dm 1 , ,dm n+1 }, la séquence de métriques clefs décisives de reconfiguration est
DRMS X→Y (D)={ drm 0 ,drm 1 , drm 2 , ,drm n+1 } ó drm 0 =dm 0 =m, et drm n+1 =dm n+1 =M et drm i =dm i -1 pour i=1 n
Et nous prouvons que l'application de cette séquence sur le lien est sans boucle
Théorème 4.3.2.2 Étant donné un graphe G=(V,E), D Є V, X→Y Є E avec la métrique initiale de X→Y=m et la métrique terminale de X→Y = M, Cycle X→Y (D) En appliquant progressivement DRMS X→Y (D) sur le lien X→ Y, il n'y a pas de boucle transitoire dans le réseau représenté par G
Pour tout cycle C Є CycleX→Y (D) et la métrique clef décisive dmi
1 Étant donné dmi, la métrique clef décisive d'une boucle C Є CycleX→Y (D), dmi < drmi+1 ,
C est dans la fusion de rSPTD(X→Y= m) et rSPTD(X→Y= drmi+1), car dmi est la plus petite des métriques de KMS X→Y (D) qui peut créer une boucle transitoire (par définition)
2 Selon le théorème 4.2.2.1, il n'y a pas de boucle dans la transition de la métrique du lien X→ Y de drmi = dmi -1 et dmi, donc C n'est pas présent dans la fusion de rSPT D(X→Y= drmi ) et rSPT D(X→Y= dmi)
3 Étant donné (1) et (2), C n'est pas dans la fusion de rSPT D(X→Y= drmi ) et rSPT
Le théorème est donc prouvé !!
L'algorithme LE&DKM
Based on the two properties mentioned, we can develop an alternative algorithm to find a reconfiguration sequence of metrics that prevents transient loops This algorithm consists of four main steps: first, combine the two rooted Spanning Trees (rSPTs) to calculate the Key Metrics (KMS) for the nodes within each loop Second, enumerate the loops resulting from the fusion of the two rSPTs using a Depth First Search (DFS) approach Third, identify a Desired Key Metric (DKM) for each loop based on the two properties of the DKMS Finally, construct a Desired Reconfiguration Metric Sequence (DRMS) from the DKMS.
Nous allons montrer que l’application de la séquence produites par LE&DKM est sans boucle
Théorème 4.3.3.1 Étant donné un graphe G=(V,E), D Є V, X→Y Є avec la métrique initiale de X→Y=m et la métrique terminale de X→Y = M, l'algorithme LE&DKM produit une séquence des métriques de reconfiguration qui peut éviter toutes les boucles transitoires lors du changement de la métrique du lien X→Y de m à M
Selon la détection des boucles du chapitre 2, l'étape i) permet de détecter toutes les boucles possibles dans le réseau lors du changement de la métrique du lien X→Y de m à
The DFS algorithm is designed to enumerate cycles within a graph by traversing all nodes based on the graph's edges and storing them in a Last In First Out (LIFO) list, known as a stack Each entry in the stack is labeled with a combination of the current node and its predecessor on the path A cycle is detected when a node that is already present in the stack is encountered, and the cycle can be reconstructed by tracing back through the labels of the nodes.
Les cycles seront stockés dans une liste pour être utilisé dans la phase suivante DFS assure que nous pouvons trouver tous les cycles dans un graphe (l'étape ii))
Le Théorème 4.3.2.1 assure que chaque boucle aura une seule métrique clef décisive
Le théorème 4.2.2.2 assure qu’il n’y a pas de boucles transitoires lors de l'application de la séquence des métriques clefs décisives moins 1
Ce théorème est donc prouvé !!
Dans la partie suivant, nous présenterons l'implémentation de LE&DKM en pseudo code.
L'implémentation de LE&DKM en pseudo code
Dans cette partie, nous présentons la procédure pour calculer RMS selon LE&DKM pour une destination dest , un lien L avec la métrique initiale et terminale est m et M
Algorithme 4-5 : L’énumération des boucles selon l’algorithme DFS
Cycles énumérerCycles(Graph G, Link L avec métrique initiale, terminale m et M ) {
Initial_rSPT=calculer_rSPT(dest, L, m);
Target_rSPT= calculer_rSPT (dest, L,M); merge_RPST=combiner_rSPT(initialRSPT,targetRSPT);
/* énumère les boucles, l’algorithme DFS */
Set Cycles ={}; /* l'ensemble de cycles du graphe */
STACK LabelStack={}; /* le stack des étiquette */
/* insère un noeud quelconque dans le stack */ push(LabelStack, (AnyNode,Φ ));
Tant que LabelStack is not empty faire
/* prendre un nœud du stack */ varNode=pop(LabelStack);
Pour chaque P is neighbor of varNode faire
{ si P is in LabelStack alors
/* constitute une boucle en suivant les étiquettes */
/* ajoute cette boucle dans la liste */ ajouter (Cycles,C) ; }
Sinon { /* insère ce noeud dans le stack */
MetricSequence construireRMS (Graph G, Cycles, Link L Link L avec métrique initiale, terminale m et M)
BranchImpacted=Suivre une branche dont la racine est X dans l’arbre rSPT Y (X→ Y =m);
Pour chaque C in Cycles faire
Set Nodes={all nodes of C};
Set Cousins={}; /* stocke les cousins */
Set tempFamily={}; /* stocke une famille temporaire des noeuds */
Tant que Nodes is not empty faire
/* examine un noeud quelconque */ tempFamily={AnyNode of Nodes};
/* regroupe une famille des noeuds étant donné un noeud quelconque:
C’est un groupe des noeuds dans un même chemin de la racine ver une feuille
*/ regrouper_une_famille(tempFamily, C, BranchImpacted);
/* choisit le père de la famille: le noeud le plus proche de la racine */ fatherNode=pendrePère(tempFamily, BranchImpacted);
/* insère ce noeud dans l'ensemble des cousins */ ajouter(Cousins, (fatherNode, fatherNode.KeyMetric));
/* supprime la branche visitée */ supprimer(Nodes, tempFamily);
} /* cherche la métrique clef décisive pour un cycle */
Metric dkm=chercherKMMaximum(Cousins) ; ajouter(RMS, dkm-1) ;
Algorithme 4-6: La constitution de RMS pour une destination selon LE&DKM
Analyse de complexité
Consider a graph G=(V,E) where N represents the number of nodes, defined as N=|V| In the Depth-First Search (DFS) algorithm, we explore all edges of the merged two rooted spanning trees (rSPTs) and reconstruct a cycle upon detection The maximum length of a cycle in this context is N.
The complexity of the DFS algorithm in this scenario is O(|E| N) Each time we identify a key metric of a cycle, we examine all corresponding key metrics of the cycle's nodes and assess their relationships within the rSPTY tree (X→ Y = m) The maximum height of this tree is N, and the longest cycle also measures N Consequently, the complexity of this phase is O(N logN) For the LE&DKM algorithm, calculating the RMS for a single destination has a complexity of O(|E| N² logN), while for all destinations, it escalates to O(|E| N³ logN).
If the number of edges in the graph is limited to O(N), the complexity of the DFS algorithm is O(N²) The complexity for finding the key metric for each cycle is O(N log N) The computation time for DRMS to a single destination is O(N³ log N), while the time for all destinations is O(N⁴ log N).
En comparant à l'algorithme LIF (pour une destination O(N log 2 N) et pour toutes destinations est de O(N 2 log 2 N), LIF est plus rapide que LE&DKM
It is important to note that the computation time of LIF is influenced by the length of the KMS, while the calculation time of LE&DKM is determined by the shape of the loops, whether they are micro loops or macro loops.
When dealing with length-2 loops (micro-loops), the complexity of Depth-First Search (DFS) is O(N), while the search for the key metric essential for detecting a cycle operates at O(logN) The computation time for Destination Routing Metric System (DRMS) is O(N logN) for a single destination and O(N² logN) for all destinations, making it more efficient than Link-In-Forwarding (LIF).
Nous continuerons à évaluer la performance de deux algorithmes dans le chapitre 6.
Conclusion
Dans ce chapitre, nous pouvons nous baser sur des reconfigurations progressives des poids, afin de résoudre le problème sans devoir modifier la spécification du protocole
To reconfigure the metric of a link, it is essential to compute a sequence of metrics to apply Implementing these intermediate metrics ensures that the order of updates to the Forwarding Information Bases (FIBs) is maintained, thereby preventing the occurrence of loops.
LIF est utilisé pour optimiser la séquence des métriques de manière globale, tandis que
LE&DKM distingue deux types de boucles : micro et macro boucles, et se base sur une résolution des boucles cycle par cycle
LE&DKM ne produit pas une séquence optimisée et en théorie, LIF est plus rapide que
In the next chapter, we will demonstrate that, in practice, the computation time for LE&DKM is shorter than that for LIF when applied to representative graphs of real OSPF networks.
Introduction
XORP (eXtensible Open Router Platform) is the only open-source industrial router platform that implements both IPv4 and IPv6 routing protocols Its architecture allows for easy implementation of new features and protocols, providing a unified platform for configuration XORP is widely utilized by educational institutions and development communities.
[4] Par rapport à Quagga[2], le code source de XORP est beaucoup plus documenté
In this chapter, we will explore the feasibility of two reconfiguration algorithms, LIF and LE&DKM, within the XORP framework We will begin by outlining the architecture of XORP and the OSPF_LOOPFREE process Following this, we will detail our implementation and the various algorithmic variables within XORP Additionally, we will assess the impact of XORP commands related to OSPF that could potentially create transient loops, such as "set interface cost" and "disable interface."
Architecture de XORP
XORP implements a control plan for various routing protocols, including OSPF, to manage routing protocols and build the Forwarding Information Base (FIB) of its host The data plane is entirely managed by the host of the XORP instance In other words, while XORP constructs the routing and forwarding tables, the actual forwarding of packets is handled by the operating system supporting the XORP instance, as XORP does not process any packets in transit through the router.
XORP is designed based on a multi-process model, as illustrated in Figure 5.1 Among these processes, the Router Manager (detailed in section 5.4.1) is responsible for managing information related to all router components, including configurations It also monitors the status of all relevant processes.
CLI (Command Line Interface) permet à l'utilisateur d'accéder au routeur (via Router Manager) pour mettre à jour ou afficher les informations du routeur
OSPF, IS-IS, RIP, etc sont des processus indépendants qui jouent le rôle des protocoles de routage correspondants
The Routing Information Base (RIB) stores the router's routing tables and interacts with various routing processes such as OSPF, BGP, and RIP to retrieve routes It also communicates with the Forwarding Engine Abstraction (FEA) to create forwarding tables, which are essential for packet transfer across the network.
The IPC finder (Inter-Process Communication finder) is essential for the communication method utilized among all XORP components Each XORP component registers with the IPC finder, which facilitates communication between XRLs by knowing their locations Consequently, a XORP process does not need to explicitly know the locations of all other processes or how to communicate with them The Router Manager includes a finder, making the IPC finder necessary only when the Router Manager is not in use, such as during testing.
Architecture de l'implémentation en XORP
Nous avons implémentés les deux algorithmes évoqués plus haut dans le module
OSPF_LOOPFREE is responsible for calculating and storing the RMS corresponding to each interface (link) of the router The graph representing the router's topology is constructed from the LSDB, which is obtained through a call to OSPF.
(en plus détail, voir la partie 5.4)
Figure 5-2: L'architecture de l'implémentation des algorithmes en XORP
Il y a quatre options à configurer OSPF_LOOPFREE via CLI: graceful, lif, fast et interval
If graceful restart is enabled, the commands to set and disable an interface are handled by the OSPF_LOOPFREE module When an administrator does not specify these options, the commands are processed by OSPF's standard mechanisms.
Si lif est ộgale à ôtrueằ, LIF est utilisộ pour optimiser RMS, sinon LE&DKM est utilisộ
If the fast is equal to true, the RMS is calculated with a single destination, specifically the router on the opposite side of the examined link Otherwise, all destinations are considered The interval refers to the time (in ms) between two metric applications of the RMS during configuration changes.
The initial parameter values for OSPF_LOOPFREE (graceful, lif, fast, and interval) can be stored in a template file associated with the process These values can be automatically read from the OSPF_LOOPFREE configuration file (refer to section 5.4 for details).
RMS are recalculated when the graceful option is set to true and when a change in the LSDB is detected The OSPF_LOOPFREE module is automatically notified of this change through an XRL For more details, refer to section 5.4.
Développement d’OSPF_LOOPFREE
Le développement du processus OSPF_LOOPFREE en XORP [5][14] 57
a) Le fonctionnement du processus Router Manager (rtrmgr) [5]
RouterManager is the sole process that is explicitly initiated during the startup of an XORP router This process includes an IPC finder, eliminating the need for additional IPC finders.
La séquence des actions du processus est :
1 Le rtrmgr lit tous les fichiers ô template ằ dans le rộpertoire ô template ằ du routeur (xorp/etc/template) Normalement, il y a un fichier ô template ằ pour chaque processus Chaque fichier ô template ằ dộcrit les fonctionnalitộs fournies par le processus correspondant en terme que tous les paramètres de configuration sont mis Il décrit également les dépendances nécessaires avant le dộmarrage des processus Aprốs avoir lu les fichiers ô template ằ, rtrmgr connaợt tous les paramốtres de configuration supportables sur ce routeur et les stocke dans un arbre ô template ằ L’arbre ô template ằ est ensuite vộrifiộ pour trouver les erreurs Le rtrmgr quitte s’il y a une erreur durant la vérification des paramètres
2 Ensuite, le rtrmgr lit le contenu du répertoire des XRLs (xorp/xrl) pour découvrir tous les XRLs supportés par les processus du routeur Ces XRLs sont utilisộs pour vộrifier ceux correspondants dans l’arbre ô template ằ S’il y a une erreur durant la vérification des XRLs, le rtrmgr quitte
3 Ensuite, le rtrmgr lit le fichier de configuration du routeur (ce qui est fourni dans la commande lors du démarrage du routeur) Toutes les options de configuration doivent correspondre aux fonctionnalités configurables décrites dans le fichier ô template ằ Cette configuration est stockộe dans un arbre de configuration dont les nœuds sont marquộs comme ô not existing ằ : on ne communique pas encore avec les processus pour implémenter les fonctionnalités correspondantes à cette partie de configuration
4 Ensuite, le rtrmgr traverse l’arbre de configuration pour découvrir la liste des processus nécessaires à démarrer afin de fournir des fonctionnalités demandées Normalement, nous n’avons pas besoin de tous les logiciels disponibles pour une configuration spécifique
5 Le rtrmgr traverse l’arbre ô template ằ encore une fois pour dộcouvrir l’ordre des processus afin de satisfaire toutes les dépendances
6 Le rtrmgr fait fonctionner le premier processus dans la liste des processus à démarrer
7 S’il n’y pas d’erreur, le rtrmgr traverse l’arbre de configuration afin de construire la liste des commandes nécessaires à configurer pour le processus fonctionné
8 S’il n’y pas d’erreur dans l’étape précédente, le prochain processus sera démarré et configuré jusqu’à la fin de la liste des processus
9 Le routeur maintenant est disponible pour les opérations interactives et des connexions de CLI qui est lancé par la commande xorpsh b) Le fichier ô template ằ
The Router Manager reads the template file directory located at (xorp/etc/template) to identify the supported options of the router Figure 5.3 illustrates the template file for the OSPF_LOOPFREE process.
10: %help: short "Avoid OSPF transient loops";
12: %modinfo: path "ospf_loopfree/xorp_ospf_loopfree";
13: %modinfo: default_targetname "ospf_loopfree";
15: %user-hidden: "XRL target name";
16: %help: short "XRL target name";
%help: short "True: Tail-end destination; False: All Destinations";
%set:xrl "ospf_loopfree/ospf_loopfree/0.1/set_fast?fast:bool=$(@)";
%help: short "True:Infocom's Algorithm False: Adhoc Algorithm";
%set:xrl "ospf_loopfree/ospf_loopfree/0.1/set_lif?lif:bool=$(@)";
%help: short "Miliseconds between increment insertions upon application";
%set:xrl "ospf_loopfree/ospf_loopfree/0.1/set_interval?interval:u32=$(@)";
%help: short "On/Off graceful mode";
%set:xrl "ospf_loopfree/ospf_loopfree/0.1/set_graceful?graceful:bool=$(@)";
Figure 5-3: Le fichier ô template ằ du processus OSPF_LOOPFREE
Ce fichier ô template ằ se compose de deux parties principales pour dộclarer les paramètres et les XRLs du processus
In lines 2 to 7, we define the parameters, their data types, and initial values Line 12 specifies the path in the root directory to the executable file for the process, which is xorp/ospf_loopfree/xorp_ospf_loopfree.
The process utilized for calls via XRLs is referred to as ospf_loopfree In lines 18 to 27, we define the description and the XRL to update the value of each parameter of the process Additionally, the development of the OSPF_LOOPFREE XRL interface is discussed.
In this section, we declare the OSPF_LOOPFREE interface of XRLs to be registered in the Router Manager's IPC finder The file (ospf_loopfree.xif) is located in the xorp/xrl/interfaces directory and contains the procedure declarations necessary to implement the functionalities of OSPF_LOOPFREE (refer to Appendix 3 for details).
This file must be compiled into four separate files: ospf_loopfree_xif.cc, ospf_loopfree_xif.hh, ospf_loopfree_xif.lo, and ospf_loopfree_xif.o This can be accomplished using the clnt-gen tool from XORP, located in the xorp/xrl/scripts directory.
Sur Linux, nous pouvons taper la commande : python clnt-gen ospf_loopfree.xif
The file ospf_loopfree_xif.cc defines the format of XRL requests used by clients to instruct the OSPF_LOOPFREE process to perform specific tasks For instance, when the OSPF process needs to communicate changes in the LSDB to OSPF_LOOPFREE, it utilizes one of these requests.
Ces quatre fichiers doivent être présents dans le répertoire xorp/xrl/interface
Ensuite, nous créons un autre fichier ospf_loopfree.tgt dans le répertoire xorp/xrl/targets
Ce fichier contient la déclaration des interfaces que nous souhaitons implémenter dans OSPF_LOOPFREE (y compris ospf_loopfree.xif, voir l’annexe 4 pour le détail)
We utilize the tgt-gen tool located in the xorp/xrl/scripts directory to generate five files: ospf_loopfree.xrls, ospf_loopfree_base.cc, ospf_loopfree_base.hh, ospf_loopfree_base.lo, and ospf_loopfree_base.o.
Sur Linux, nous pouvons taper la commande : python tgt-gen ospf_loopfree.tgt
The file ospf_loopfree.xrls contains the location of OSPF_LOOPFREE procedures For instance, the procedure to update the fast parameter of OSPF_LOOPFREE can be found at finder://ospf_loopfree/ospf_loopfree/0.1/set_fast?fast:bool.
The file ospf_loopfree_base.hh includes the declaration of the class XrlOspfLoopfreeTargetBase, which contains virtual methods that align with the OSPF_LOOPFREE procedures The implementation of these methods will be completed during the development of the main loop of the process, which will be discussed in the following section.
Ces cinq fichiers doivent être présents dans le répertoire xorp/xrl/targets d) La boucle principale (Main loop) d’OSPF_LOOPFREE
Chaque processus possốde une boucle qui s’appelle ô event_loop ằ et un routeur virtuel pour traiter les requêtes XRL entrantes et sortantes du processus
Cette boucle (event_loop) se situe dans la fonction ô main ằ du fichier d’exộcution du processus (xorp_ospf_loopfree)
La classe qui implémente les procédures d’OSPF_LOOPFREE doit aussi implémenter la classe standard du routeur virtuel (voir l’annexe 5,6 pour le détail)
En ce moment, le code source de cette classe doit être rempli pour traiter les fonctionnalités d’OSPF_LOOPFREE.
La notification des changements de LSDB depuis OSPF
Nous utilisons un appel procédural à distance via XRL dans le processus OSPF pour notifier des changements de LSDB au processus OSPF_LOOPFREE
Error! 1:XrlOspfLoopfreeV0p1Client _xrl_ospf_loopfree_client;
2:XrlIO::notifyLSDBchange(const IPv4& router_id)
5: success=_xrl_ospf_loopfree_client.send_notify_lsdb_change
("ospf_loopfree",router_id, callback(this,&XrlIO::send_notify_lsdb_change_cb )); return success;
11: void XrlIO::send_notify_lsdb_change_cb(const XrlError& xrl_error)
{ if (xrl_error.error_code()==OKAY) return;
Figure 5-4: La notification des changements de LSDB à OSPF_LOOPFREE
We first declare an OSPF_LOOPFREE client to send XRL requests to this process (see Figure 5.4, line 1) The notifyLSDBchange procedure is responsible for sending the call via XRL with the router ID to the send_notify_lsdb_change procedure of OSPF_LOOPFREE (line 5 in Figure 5.4) The result of this call will be returned to the callback function of OSPF: send_notify_lsdb_change_cb (line 11 in Figure 5.4).
In our implementation, the notification procedure was utilized within the OSPF SPT calculation module, focusing exclusively on LSAs that result in changes to the LSDB.
La lecture de LSDB
OSPF provides access to the router's local LSDB through an XRL interface, offering procedures such as Get_Area() and Get_LSA() The Get_Area() function retrieves the Area_IDs of all areas within the OSPF network, while Get_LSA() returns a specific LSA based on a provided ID parameter OSPF_LOOPFREE can invoke these XRLs and receive results in its corresponding callback functions.
Two types of LSAs used to obtain the complete state of an area are Router-LSA and Network-LSA Router-LSAs provide information such as router IDs, interface addresses, and metrics, while Network-LSAs contain neighbor information of the routers Together, these LSAs enable the construction of a graph that represents the topology of an area.
In OSPF_LOOPFREE, the LSDB reading from OSPF is initiated when the graceful option is set to true, upon receiving a topology change notification from the OSPF module, and whenever the application of a sequence of metrics is completed.
Le calcul des RMS
We can calculate the RMS for all router interfaces, distinguishing between point-to-point and point-to-multipoint links, such as Ethernet Our implementation currently supports only point-to-point links Studies have shown that in over 90% of link maintenance cases, the RMS corresponding to the destination on the other side of the link is sufficient to prevent transient loops for all affected destinations across five studied ISP networks This approach eliminates the need to store rSPT information for all destinations impacted by the change, requiring only the rSPT related to the router on the opposite side of the link The RMS for all router interfaces is stored in memory.
L'application des métriques
Two commonly used commands during maintenance operations are "interface cost" to modify the interface metric and "disable interface" to deactivate the interface before shutting it down Adjusting the metrics of certain network links can help achieve traffic engineering objectives by favoring specific links over others, thereby increasing or decreasing traffic on those links Additionally, when a user needs to power down a router for repairs or software upgrades, all interfaces must be disabled first.
These commands are executed by altering the ospfv2.tp file in the CLI, which contains the configuration templates for OSPF IPv4 This modification allows the commands to be processed by OSPF_LOOPFREE instead of the standard OSPF.
OSPF_LOOPFREE retrieves interface information through an XRL, with the RMS stored in memory It subsequently sends XRLs to OSPF to sequentially apply each metric Meanwhile, if there is a notification of topology changes from other routers, OSPF_LOOPFREE switches to "fast convergence" mode, allowing the terminal metric to be applied immediately.