4.2 Implementation
6.2.3 LSA processing & flooding
Each LSA belonging to the received LSU is processed independently by call- ing the ospf6 receive lsaospf6 flood.c function in the MPR-OSPF version
(only enabled if the label OSPF6 MANET MPR RETRANS OSPF MPR is on). In first term, new verifications are performed, corresponding to checksum check (step 2.1, by calling the ospf6 lsa checksumospf6 lsa.c), type verification17
(step 2.2, AS-scope LSA discarded in stub areas), scope analysis (step 2.3, LSA is discarded if its scope is reserved), age update and evaluation (via ospf6 is maxage lsa dropospf6 neighbor.c, which lets the LSA, in case it is up
to date or any neighbor belonging to the area is in adjacency-forming state, to be after processed in the way that step 2.4 details).
Second part of LSA processing includes look-up in the local link state database (LSDB). The LSA is stored in the acknowledge-pending list for the transmitting neighbor (function ospf6 store mackospf6 neighbor.c), and three
scenarios are considered depending on the search results. In each of them, the list of requests from the neighbor to the main interface is examined, the received LSA is looked up. If the request is equal or older than the received LSA, the corresponding request is removed from the list.
1st scenario The received LSA contains new information not stored in the local LSDB (that is, there is no instance in the database or the instance is older). If the time interval between the two last receptions is less that MinLSArrival, then the new LSA is flooded (if non self-originated18
and sent by a MPR selector), installed and acknowledged.
Flooding procedure is initiated in ospf6 floodospf6 flood.c function and
follows the diagram in figure 13.
16
The OSPF6 instance has only a link-local meaning, so that different protocol instances can be running over the same link (defined in section A.3.1 [RFC2740]).
17
According to [RFC2740], section 3.5.1, step (2), the LSA type evaluation should discard the LSA in case of unknown type, stub area and AS scope or U-bit on, which is not imple- mented.
18
Self-originated LSA are those whose transmitting router is the same that the one process- ing it, according to new definition of section 3.6 [RFC2740].
Figure 13: Flooding process functions in the GTNetS MPR-OSPF implemen- tation
The process involves the OSPF6 instance that is running over the router of the receiving interface. The flooding process in extended to those areas connected to router’s interfaces, and, in each area, the attached router interfaces manage its own flooding policy, detailed in ospf6 flood interface ospf mprospf6 flood.cfor MPR-OSPF extension.
This function discards for flooding the receiving router interfaces having received the LSA in state BDR or from an DR/BDR transmitting inter- face19
.
LSA is decided to be flooded over the receiving router interfaces’ neighbors. For each of them, some checks are developed and the request list for the neighbor is examined in order to avoid flooding in the following cases:
There are requests for the LSA that are newer than or equal to the
LSA in the request list for the neighbor (if the request is older or equal, it is removed).
The neighbor relationship is lower than EXCHANGE (not adjacency
forming), substep 2.5.2.1 (a).
The neighbor has generated or already transmitted the LSA. The LSA has been already acknowledged.
Excluding these cases, the neighbor is added to the LSA retransmission list for the neighbor (ospf6 retrans lsa addospf6 top.c) and the LSA is
signalized to be acknowledged (neighborShouldAck). Finally, the LSA
19
It is not clear that these decisions make sense in MPR-OSPF extension, in which DR/BDR status has no place in the whole design. Moreover, the same steps are repeated at the end of the function, so either the first, either the last, either both are unneeded and could be removed.
is scheduled for retransmission (if the list is non-empty) and flooding out the interface (ospf6 lsdb addospf6 lsdb.c).
Install process is deployed in the ospf6 install lsaospf6 lsa.c function,
which also includes removal of the current database instance in the re- transmission lists (steps 2.5.3 and 2.5.4). Acknowledgement policy (step 2.5.5) will be detailed in next section. And self-originated LSAs, which have been prevented from flooding, generate a new instance of the LSA to be flooded20
(step 2.5.6).
2nd scenario LSA and LSDB instance have the same age. LSA does not con- tain useful information to be flooded, so it is acknowledged and discarded without further processing.
3rd scenario Database instance is more recent than the received LSA. The received LSA is likely to be in SeqNumber wrapping21
, in this case the LSA is discarded. Otherwise, the local copy is more recent than the received LSA, and it is consequently flooded over the transmitting neighbor, if it is within an adjacency-forming LSDB exchange process (EXCHANGE or LOADING) state22
.
7
Link State Acknowledgments
7.1
Specification (IETF-03)
MPR-OSPF acknowledge policy relies on the principle that nodes belonging to the adjacency set have to acknowledge every Link State Advertisement (LSA), either explicitly or implicitly. According to this main rule, the protocol is ex- pected to behave in the way that the flux diagram in figure 14 indicates.
20
Flooding a new instance is one of the possible alternatives (following section 13.4 [RFC2328]), the other one is to flush the packet; in any of these cases the self-originated LSA should be flooded.
21
The SeqNumber parameter is higher than the maximum allowed value and it has been reinitialized.
22
2nd and 3rd scenarios seem to be collapsed in the specification; both of them are ex- pected to imply an acknowledgment without further processing (step 2.6). Does not MPR- OSPF needs to manage SeqNumber wrapping events, for instance? In that case, this should be removed from ospf6 receive lsaospf6 flood.c for MPR-OSPF. Otherwise, this should be
Figure 14: Acknowledge diagram in MPR-OSPF (draft IETF-03)
If an LSA has not been received from an adjacent neighbor, it should not be acknowledged. If the transmitting neighbor is adjacent, then the LSA should be acknowledged. The way it is acknowledged depends on whether the LSA is received for the first time. If not (that is, if other neighbor has sent the same LSA before), the receiving neighbor is not going to perform retransmission of the LSA through the neighborhood, so no implicit acknowledges (due to retrans- missions) are going to be deployed. In that case, the receiving neighbor should acknowledge explicitly the LSA by means of an Link State Acknowledgment (LSAck) packet.
In contrast, if the LSA has been received for the first time, the neighbor will sent an LSAck in the case that no retransmissions are foreseen according to the flooding policy. If the node retransmits the LSA, then it works as an implicit acknowledgment for the transmitting neighbor.
LSAck packets may be delayed so that they can be aggregated in multiple- acks transmissions. Jitter features can also be implemented in order to reduce collision likelihood.
7.2
Implementation
Acknowledge policy is cen-
tralized in the ospf6 acknowledge lsaospf6 flood.c function, which derives to
two different subfunctions (ospf6 acknowledge lsa bdrouterospf6 flood.c and
ospf6 acknowledge lsa allotherospf6 flood.c) depending on the OSPF6-like
state of the acknowledging interface. Since MPR-OSPF extensions does not take care of DR/BDR/DROther interface states, their specific acknowledging mechanisms are only deployed in the function referring to allother (neither DR nor BDR) interfaces, ospf6 acknowledge lsa allotherospf6 flood.c).
This function mainly implements the decisions detailed in the ”All-other states” column on table 19 (section 13.5) [RFC2328], with some minor modifi- cations due to MPR-OSPF and OSPF-MDR particularities.
If LSA has been flooded back out the receiving interface, it should not be
acknowledged, according to [RFC2328]. In fact, the draft does not provide special behavior for flooded-back LSAs, though OSPF6 LSA FLOODBACK flag is enabled for packets in which the processing interface is the same to the LSA generating interface. To be consistent with the specifications, both flag activation and acknowledgement floodback processing should be supressed, except that this is expected to be added to the specific policy of MPR-OSPF.
If LSA is more recent than the instance in the LSDB, but it was not flooded
back to the receiving interface (so previous step has been avoided), the interface should send a delayed acknowledgement. It is consistent with the theorical behavior (see previous subsection) on MPR-OSPF extension: in the case that the retransmission (equivalent to floodback in a wireless medium) is avoided, then the packet needs to be explicitly acknowledged, as stated in step 2.5.5 of subsection 5.1.3 of this report.
No implied acknowledgement
flags are enabled in MPR-OSPF-based routers when processing an LSA (function ospf6 receive lsaospf6 flood.c). In case of duplicate LSA (flag
OSPF6 LSA DUPLICATEenabled), that is, the received LSA is the same as the LSDB instance, the packet should be acknowledged, according to the draft (IETF-03).
If LSA age reaches MaxAge, no instance is found in the LSDB and any
of the router’s neighbors is in forming-adjacency state (EXCHANGE or LOADING), then the LSA should be acknowledged. This is implemented directly in ospf6 receive lsaospf6 flood.c (and not in specific acknowl-
edgement processing function), after age check.
With all these mechanisms, the main algorithm detailed in previous sub- section is basically respected. In addition, it is worth reminding that ac- knowledge is restricted (in the acknowledgment handling part of function ospf6 receive lsaospf6 flood.c) to LSAs coming from neighbors in state higher-
or-equal than EXCHANGE, following the specification (section 5.4.2, point 1).
8
Routing table and SPT calculation
Each network node is expected to maintain a unique routing table. This ta- ble maps packet destination with next hop identity, and permits each node to forward correctly a packet when it is received and addressed to a further desti- nation.
8.1
Specification (IETF-03)
There are not explicit references to routing table construction in the current specification. According to classic OSPF policies23
, the routing table is com- puted taking into account the information collected by the node from the differ- ent received LSA messages24
. The Dijkstra algorithm is run to determine the shortest path tree of every area attached to the computing node25
.
After the SPT calculation, the routing table is filled by routing entries, one per destination. Each entry stores the shortest path(s) to the corresponding destination, their (minimum) cost and the next hop(s) to reach it.
In MPR-OSPF, Router-LSAs of MANET routers contain the set of Path MPR and Path MPR selectors of the originating node. Consequently, the SPT is calculated over the Path MPR sets of each node in the network. Since Path MPR peers are selected to be intermediate nodes in the min-cost links from the 1- (when possible) and 2-hop neighbors of the computing node, the outgoing routing entries from the SPT algorithm are expected to cover at least every destination 2-hops away or further from the computing node. They are excluded, however, these 1-hop neighbors whose shortest path to the computing node is the direct link. Thus, routing entries to these 1-hop nodes are required (at least) to complete the routing table with every possible destination in the network.
Actually, MPR-OSPF nodes include neighbors belonging to N and N2 to the Shortest Path Tree calculation: this should be included in the specification, since it is a specific feature from MPR-OSPF not considered (not required) in the classic OSPF documentation.
8.2
Implementation
The SPF and routing tables of a router attached to a certain area are stored inside an ospf6 areaospf6 area.h structure, in the ospf6 route table-like vari-
ables spf table and route table. The routing table struct consists of a set of entries, each of them stored in a ospf6 routeospf6 route.h-like variable. Aux-
iliary data structures for the routing entries handling and the SPF algorithm are detailed in ospf6 route.h and ospf6 spf.h, and the procedures for SPT calculation and routes management are deployed in the corresponding C files.
In particular, the Shortest Path Tree calculation procedure, which adapts the Dijkstra algorithm, is implemented in ospf6 spf calculationospf6 spf.c. The
calculation is done is two steps. In the first one, the tree root (computing router), the 1- and 2-hop neighbors of the root’s interfaces in the area are added as candidates (vertices) to the tree, calculating the cost to the root26
, the number of hops and the next hop from the root. The second step iterates over the candidate list: for each candidate node, it is installed (if there is no better route) in the route table (in ospf6 spf installospf6 spf.c), removed from the candidate
list and they are explored the link-state descriptions of its corresponding LSA. If these links are bidirectional, the involved neighbors are also added to the candidate list. When the iteration is finished (that is, no more candidates
23
Sections 11 and 16 [RFC2328] and sections 3.3 and 3.8 [RFC2740].
24
Router-LSAs for intra-area routes, summary-LSAs (inter-area-prefix-LSAs and inter-area- router-LSA, in OSPFv3 terminology) for inter-area routes, AS-external-routes for routes to external destinations and intra-area-prefix-LSA for prefix information.
25
Section 16, step (2) [RFC2328].
26
exist), the route table of the calculating router associated to the area contains the shortest paths to every destination in the area.
9
References
[RFC2328] J. Moy: RFC 2328, OSPF Version 2. Internet Society (ISOC). April 1998. [RFC2740] R. Coltun, D. Ferguson, J. Moy: RFC 2740, OSPF for IPv6. Internet
Society (ISOC). December 1999.
[RFC4813] B. Friedman, L. Nguyen, A. Roy, D. Young: RFC 4813, OSPF Link-local Signaling. Internet Society (ISOC). February 2007.
[IETF-03] E. Baccelli, P. Jacquet, D. Nguyen: Internet-Draft, OSPF MPR Extension for Ad Hoc Networks. OSPF WG of the Internet Engineering Task Force (IETF). draft-ietf-ospf-mpr-ext-03.txt. November 2008. (work in progress)
[Baccelli-04] E. Baccelli, P. Jacquet, D. Nguyen: Internet-Draft, OSPF MPR Exten- sion for Ad Hoc Networks. OSPF WG of the Internet Engineering Task Force (IETF). draft-baccelli-ospf-mpr-ext-04.txt. October 2007. (expired)
[Quagga] K. Ishiguro et al.: Quagga. A routing software for TCP/IP networks. Quagga v0.98.6. http://www.quagga.net/docs/quagga.pdf. June 2005. [Evaluation] J.A. Cordero: Evaluation of OSPF extensions in MANET routing. Master Thesis. ´Equipe HIPERCOM, Laboratoire d’Informatique (LIX) - ´Ecole Polytechnique. September 2007.
[GTNetS] G. F. Riley: The Georgia Tech Network Simulator. Proceedings of the ACM SIGCOMM 2003 Workshops. August 2003.
Centre de recherche INRIA Bordeaux – Sud Ouest : Domaine Universitaire - 351, cours de la Libération - 33405 Talence Cedex Centre de recherche INRIA Grenoble – Rhône-Alpes : 655, avenue de l’Europe - 38334 Montbonnot Saint-Ismier Centre de recherche INRIA Lille – Nord Europe : Parc Scientifique de la Haute Borne - 40, avenue Halley - 59650 Villeneuve d’Ascq
Centre de recherche INRIA Nancy – Grand Est : LORIA, Technopôle de Nancy-Brabois - Campus scientifique 615, rue du Jardin Botanique - BP 101 - 54602 Villers-lès-Nancy Cedex
Centre de recherche INRIA Rennes – Bretagne Atlantique : IRISA, Campus universitaire de Beaulieu - 35042 Rennes Cedex Centre de recherche INRIA Saclay – Île-de-France : Parc Orsay Université - ZAC des Vignes : 4, rue Jacques Monod - 91893 Orsay Cedex
Centre de recherche INRIA Sophia Antipolis – Méditerranée : 2004, route des Lucioles - BP 93 - 06902 Sophia Antipolis Cedex
Éditeur
INRIA - Domaine de Voluceau - Rocquencourt, BP 105 - 78153 Le Chesnay Cedex (France)