Keywords: Intermediate temperature solid oxide fuel cell (IT-SOFC), Cathode materials, Sr 1.5 La x MnO 4, Electrode reaction

A-site non-stoichiometric materials Sr 1.5 La x MnO 4 (x = 0.35, 0.40, 0.45) are prepared via solid state reaction. The structure of these materials is determined to be tetragonal. Both the lattice volume and the thermal expansion coefficient reduce with the decrease of lanthanum content. On the contrary, the conductivity increases and the maximum value of 13.9 S cm -1 is found for Sr 1.5 La 0.35 MnO 4 at 750 °C in air. AC impedance spectroscopy and DC polarization measurements are used to study the electrode performance. The optimum composition of Sr 1.5 La 0.35 MnO 4 results in 0.25 Ω cm 2 area specific resistance (ASR) at 750 °C in air. The oxygen partial pressure measurement indicates that the charge transfer process is the ratelimiting step of the electrode reactions. K Ke ey yw wo or rd

(1) *

(2) †

(2)

I. Introduction

Solid oxide fuel cells (SOFCs) attracted more and more substantial interests in recent years, due to their high energy conversion efficiency, ability to use low cost non-precious metal catalysts, fuel flexibility and system compactness compared to other types of fuel cells [1] and [2]. Nowadays, one of the most important research goals is to develop intermediatetemperature solid oxide fuel cell (IT-SOFC). IT-SOFC will solve various problems associated with the high operation temperature (900-1000 °C), such as sealing and thermal degradation. However, a key obstacle to reduced-temperature operation of SOFCs is the poor activity of traditional cathode materials for electrochemical reduction of oxygen [3], [4] and [5]. Therefore, it is critical to develop advanced cathode materials with favorable electrochemical performance at reduced operation temperature.

Recently, many investigations on mixed ionic electronic conductors (MIECs) with K 2 NiF 4 structure were reported [6], [7], [8], [9], [10], [11], [12], [13], [14], [15] and [16]. These oxides are usually formulated as A 2 BO 4 , which can be described as a series combination of ABO 3 perovskite layers alternating with AO rock-salt layers along the c-direction [17]. These compounds can accommodate a significant amount of oxygen non-stoichiometry, due to their unique crystal structure characteristics. It is generally accepted that oxygen ionic conduction in K 2 NiF 4 -type compounds may occur via a vacancy mechanism in the perovskite layers or via diffusion of interstitial oxygen in the rock-salt layers, whereas the electronic conduction behavior comes from the p-type electronic conductivity in the perovskite layers [18], [19], [20] and [21]. Previous studies have shown that A 2 BO 4 oxides possess good thermochemical stability, compatible thermal expansion coefficient with traditional electrolytes, and improved oxygen diffusion and surface exchange coefficients compared with perovskite oxides [22], [23], [20] and [24]. These desirable properties mentioned above make A 2 BO 4 oxide a promising candidate of cathode material for IT-SOFC. It is known that the content of interstitial oxygen and the oxygen ionic conductivity in these compounds are mainly determined by A-site cations, and the electrical, magnetic and catalytic properties are mainly determined by B-site cations. We consider that this kind of materials will exhibit excellent performance as cathode for SOFC through pertinently choice of A-site and/or B-site elements.

Up to now, the researches based on K2NiF4type cathode materials are mainly focused on Ni, Cu, Co and other rear transition elements on B-site [25] and [26]. Few attentions have been paid to fore transition elements, such as Mn. ) ) p po ow wd de er r Sr 1.5 La x MnO 4 powders were prepared by conventional solid state reaction method. The precursors were La 2 O 3 , SrCO 3 and MnCO 3 . All of the starting materials were analytical reagent. La 2 O 3 was preheated to 1000 °C to remove any possible hydroxide and carbonate. SrCO 3 and MnCO 3 were heated to evaporate the adsorbed water. Stoichiometric amounts of La 2 O 3 , SrCO 3 and MnCO 3 powders were intimately mixed with absolute alcohol in an agate mortar and grinded with pestle for 2 h. Then the mixture was calcined at 1000 °C for 12 h and subsequently pressed (220 MPa) into pellets and calcined at 1300 °C for 24 h. The pellets were then crushed and followed by repeated grinding and calcining until complete reaction and uniform composition were achieved. I II I. .2 2. . P Pr re ep pa ar ra at ti io on n o of f c ca at th ho od de e Three electrodes system was fabricated to test the electrochemical properties. Ce 0.9 Gd 0.1 O 1.95 (CGO) powder was obtained from Rhodia Courbevoie (France). The CGO powders were pressed uniaxially at 220 MPa and then sintered at 1400 °C for 10 h to form densified pellet. About 200 mg Sr 1.5 La x MnO 4 powders were mixed with 0.5 mL terpineol to form a slurry, and subsequently painted on one side of the CGO pellet, to form working electrode (WE) area of 1.0 cm 2 . Platinum paste was painted on the other side of the CGO pellet in symmetric configuration, as the counter electrode (CE). A Pt wire was used as reference electrode (RE) and painted on the same side that of the working electrode. The cathode was first heated at 400 °C for 2 h to eliminate organic binders, followed by sintering at 1000 °C for 4 h in air, with a heating/cooling rate of 3 °C min -1 . The scheme of the cell was illustrated in Reference [28]. The microstructure of the cathode was investigated by scanning electron microscopy (SEM) (Hitachi, S-4700 FEG). I II I. .3 3. . C Ch ha ar ra ac ct te er ri iz za at ti io on n The phase identification of the synthesized powders was performed with X-ray diffraction instrument (Rigaku, D/MAX-3B). Structure refinements were carried out by the Rieltveld method. The electrical conductivity of the Sr 1.5 La x MnO 4 materials was measured by the standard four-probe DC method. Measurements were performed from room temperature to 750 °C with a heating rate of 5 °C min -1 . The thermal expansion of the rectangular specimens was measured from room temperature to 900 °C in air, using TMA system (SETSYS Evolution) with a heating rate of 5 °C min -1 . The impedance spectra were recorded over the frequency range 1 MHz to 0.1 Hz using Autolab PGStat30. The measurements were performed at OCV as a function of temperature (550-750 °C) and oxygen partial pressure (in an N 2 /O 2 mixed atmosphere). The DC polarization experiments were performed by the chronoampermetry methods, as that explained in Reference [29]. III. Results and discussion I II II I. .1 1. . X XR RD D a an na al ly ys si is s Figure 1 shows the room temperature XRD patterns of Sr 1.5 La x MnO 4 (x = 0.30, 0.35, 0.40, 0.45). The refined cell parameters are listed in Table 1. All the diffraction peaks can be well indexed as K 2 NiF 4 tetragonal structure with the space group I4/mmm. It was observed that the main diffraction peaks of Sr 1.5 La x MnO 4 shifted gradually to higher values of 2θ with the increases of La cation deficiency, which indicates the shrinkage of cell lattice parameters. When the value of x decreased to 0.30, however, some impurity phases were detected. This result suggests that La cation deficiency fraction is limited to approximately 0.35 for Sr 1.5 La x MnO 4 material. The lattice shrinkage can be attributed to the following two factors: (1) with the increase of La cation deficiency, part of the Mn valence changed from Mn 3+ to Mn 4+ due to the electroneutrality condition. According to the valence-bond theory, the Mn-O bond strength will increase and bond-length decrease in this case; (2) the loss of lattice oxygen and the formation of oxygen vacancies are enhanced with the increase of La cation deficiency. , respectively. This can be understood by considering the inversely proportional relationship between TEC and the bonding energy of ions in the lattice [30]. According to the refinement results (Table 1), both the cell volume and lattice parameters decrease with the increase of La cation deficiency. This will strengthen the M-O bond and result in the increase of bonding energy. It is clear that the TEC values of Sr 1.5 La x MnO 4 decrease with the increase of La cation deficiency and the TEC value of Sr 1.5 La 0.35 MnO 4 is much closer to that of CGO (∼13.1 × 10 -6 K -1 ). This implies that Sr 1.5 La 0.35 MnO 4 might be more suitable as a cathode based on CGO electrolyte for IT-SOFC. I II II I. .3 3. . E El le ec ct tr ri ic ca al l c co on nd du uc ct ti iv vi it ty y Arrhenius plots for the electrical conductivity of Sr 1.5 La x MnO 4 (x = 0.35, 0.40, 0.45) are given in Figure 4. A linear relationship between ln(σT) and 1/T was found for all samples. The calculated Ea values ranged between 0.2 and 0.3 eV, indicating a small polaron hopping mechanism. As shown in Figure 4, the electrical conductivity increased and the activation energy decreased with the increase of La cation deficiency. This phenomenon can be ascribed not only to the steady increase of p-type charge carriers with La cation deficiency, but also to the increased overlapping of the atomic orbits between adjacent Mn atoms. Based on XRD refinement, cell parameters a and c decrease with increasing La cation deficiency. As a result, the bond length of Mn 3+ -O 2--Mn 4+ reduced and the overlapping of the atomic orbits between the adjacent Mn was promoted, which subsequently increased the liability of the migration of the charge carriers. The highest electrical conductivity 13.9 S cm -1 was obtained at 750 °C in air for Sr 1.5 La 0.35 MnO 4 , which is much higher than that of the stoichiometric Sr 2-x La x MnO 4+δ oxides [27]. I II II I. .4 4. . M Mi ic cr ro os st tr ru uc ct tu ur re e o of f c ca at th ho od de e The microstructure of the sintered electrode is one of the most important factors to influence cathode performance. Figure 5 shows surface and cross-section morphologies of Sr 1.5 La 0.35 MnO 4 cathode on CGO electrolyte after sintered at 1000 °C for 4 h in air. It can be seen (Figure 5a) that Sr 1.5 La 0.35 MnO 4 electrode exhibits a homogeneous porous microstructure. The electrode particles (500 nm in average grain size) appear to form continuous network, which is beneficial for the gas transportation and formation of the electronic conducting network within the cathode. From the cross-sectional view (Figure 5b), it can be seen that CGO electrolyte and cathode adhered well to each other with a cathode thickness of about 15 μm. No delamination occurs at the electrolyte-cathode interface after cell testing. I II II I. .5 5. . E El le ec ct tr ro oc ch he em mi ic ca al l p pe er rf fo or rm ma an nc ce e The performance of Sr 1.5 La x MnO 4 cathode for oxygen reduction was studied by EIS in three electrode system. Figure 6 shows the temperature dependence of the electrode polarization resistance of Sr 1.5 La x MnO 4 cathode. The polarization resistance values reduced with the increase of La cation deficiency over the entire examined temperature range. Sr 1.5 La 0.35 MnO 4 gave the lowest polarization resistance value ( 0.25 Ω cm 2 ) at 750 °C in air, which is about 1/6 that of Sr 1.4 La 0.6 MnO 4 . The superior electrochemical performance of Sr 1.5 La 0.35 MnO 4 cathode is ascribed to the following reasons. It is proved that the oxygen vacancies were indeed beneficial to the oxygen reduction reaction (ORR) [31] and [32]. The creation of oxygen vacancies with the increase of La cation deficiencies in Sr 1.5 La x MnO 4 facilitated oxygen ion both diffusion within the oxide bulk and surface diffusion of the diassociative adsorbed oxygen on the electrode; In addition, the conductivity of the cathode material was improved, which will improve the cathodic electrochemical performance as well. In order to further understand the ORR mechanism on the electrodes, impedance measurements were done as a function of oxygen partial pressure. Figure 7 shows the impedance spectra of Sr 1.5 La 0.35 MnO 4 cathode measured at 750 °C under various oxygen partial pressures (P O2 ). The value between the high frequency x-axis intercept and the low frequency one is attributed to the total polarization resistance (R p ) of Sr 1.5 La 0.35 MnO 4 cathode. As can be seen, the impedance spectra contain two separable depressed arcs, suggesting that at least two different electrode processes limited the oxygen reduction reactions. In order to separate the different contributions, an equivalent circuit with two distributed elements was used to fit the data. As shown in Figure 7, R el is the combination of electrolyte resistance, electrode ohmic resistance, lead resistance and contact resistance between cell and Pt mesh, CPE is the constant phase element in parallel with a resistance (R), R H and R L are the resistance corresponding to the high-frequency and low-frequency arc, respectively. The dependence of polarization resistance on oxygen partial pressure was shown in Figure 8. As we know, the ASR of the electrode varied with the oxygen partial pressure according to the following law:

[ ] [ ] 2 0 ( ) n O

ASR ASR P =

For different process, there is a unique n value. A value of 0, 0.25, 0.5 and 1 is associated with the following reactions, respectively [33]. Our results indicated a complex relationship between the polarization resistance and the oxygen partial pressure. At low oxygen partial pressure (less than 3.03 kPa), n value is near zero for R H (n = 0.01), which is associated with the oxygen ion transfer from the TPB to the electrolyte; for R L the value is 0.24, which is related to charge-transfer reaction at the triplephase boundary (see Figure 8). When the oxygen partial pressure is above 3.03 kPa, however, n value is 0.22 for R H , which is associated with the charge-transfer reaction, and 0.51 for R L , which is related to surface diffusion of the dissociative adsorbed oxygen at the TPBs (see Figure 8). Compared with the fitting results of Figure 7 and Figure 8, we found that at low oxygen partial pressure (less than 3.03 kPa), the magnitude of R L is larger than R H ; at high oxygen partial pressure (higher than 3.03 kPa) however, the magnitude of R H is larger than R L . So we can draw a conclusion that the charge transfer reaction is the major rate-limiting step in the whole range of measuring oxygen partial pressure. Compared to the previous result of the stoichiometric compound Sr 2-x La x MnO 4 (x = 0.4, 0.5, 0.6), with which the charge transfer reaction is the rate limiting step (Reference 27), it was found that the generation of La cation deficiency promoted the ORR reaction, whereas the reaction mechanism remain unchanged. Cathodic overpotential is an important component of electrode performance. Figure 9 presents the typical overpotential curves of Sr 1.5 La 0.35 MnO 4 cathode as a function of current density measured at different temperatures in air. It was observed that the cathodic overpotential decreased with an increase of the measurement temperature, indicating that the catalysis property was improved with the temperature. The polarization overpotential, 49 mV was obtained for Sr 1.5 La 0.35 MnO 4 cathode at a current density of 100 mA cm -2 at 750 °C in air. This value is better than that of the reported Sr 1.4 La 0.6 MnO 4+δ materials in literature [27]. This result is understandable, considering the presence of large amount of oxygen vacancies generated by the A-site La cation deficiencies in the lattice. Oxygen vacancies can promote the mobility of the oxygen ions. Therefore, the amount of absorbed oxygen on the electrode surface and the migration of oxygen to the TPB or diffusion to the electrode/electrolyte interface can be strongly enhanced.

IV. Conclusions

F

  Fi ig gu ur re e 1 1: :. . X XR RD D p pa at tt te er rn ns s o of f S Sr r1.5 1.5L La ax xM Mn nO O4 4The high temperature chemical stability of Sr 1.5 La x MnO 4 material was investigated. Figure 2 presents the XRD patterns of Sr 1.5 La 0.35 MnO 4 and CGO mixtures after heat-treated at 1000 °C for 4 h. Obviously the CGO and Sr 1.5 La 0.35 MnO 4 remained their structures unchanged. There were no new peaks identifiable or shift of XRD peaks observed in the patterns, indicating that there is no reaction and/or inter-diffusion of elements occurred between Sr 1.5 La 0.35 MnO 4 and CGO. Thus, it is reasonable to conclude that Sr 1.5 La 0.35 MnO 4 is a chemically stable cathode material for CGO electrolyte.

I

  II II I. .2 2. . T Th he er rm ma al l e ex xp pa an ns si io on n The thermal expansion behaviors of Sr 1.5 La x MnO 4 (x = 0.35, 0.40, 0.45) specimens at 300-900 °C in air are shown in Figure 3. The dilatometric curves of these oxides can be adequately approximated by linear dependences in this temperature range. The average thermal expansion coefficient (TEC) value was found to decrease with the increase of La cation deficiency. The TEC values for Sr 1.5 La 0.45 MnO 4 , Sr 1.5 La 0.40 MnO 4 and Sr 1.5 La 0.35 MnO 4 are 16.1 × 10 -6 , 15.5 × 10 -6 and 14.5 × 10 -6 K -1

F 4 F

 4 Fi ig gu ur re e 3 3: : Thermal expansion curves of Sr La MnO materials. Thermal expansion curves of Sr1.5Lax 1.5 xMnO4 materials. Fi ig gu ur re e 4 4: : Temperature dependence of the electrical conductivity for Sr La MnO (x = 0.35, 0.40, 0.45, 0.5) in air. Temperature dependence of the electrical conductivity for Sr1.5Lax 1.5 xMnO4 ( = 0.35, 0.40, 0.45, 0.5) in x 4 air.

F

  Fi ig gu ur re e 5 5: : The SEM images of Sr La MnO electrode sintered at 1000 °C (a) and the cross-section image of the test cell (b). The SEM images of Sr1.5La0.35MnO4 electrode sintered at 1000 °C (a) and the cross-section image of the 1

  n=1

.

F

  Fi ig gu ur re e 6 6: : Arrhenius plot of the polarization resistances of Sr La MnO (x = 0.35, 0.40, 0.45, 0.5) electrodes. Arrhenius plot of the polarization resistances of Sr1.5Lax 1.5 xMnO4 ( = 0.35, 0.40, 0.45, 0.5) electrodes.x4

F

  Fi ig gu ur re e 9 9: : The overpotential-current density curves for Sr La MnO electrode measured at various temperatures in air. The overpotential-current density curves for Sr1.5La0.35MnO4 electrode measured at various 1

Sr 1 . 5

 15 La x MnO 4 (x = 0.35, 0.40, 0.45) oxides have been synthesized by solid state reaction and assessed for possible use in SOFCs. The conductivity of Sr 1.5 La 0.35 MnO 4 is about 13.9 S cm -1 at 750 °C in air. Sr 1.5 La 0.35 MnO 4 cathode forms good contact with CGO electrolyte after sintering at 1000 °C for 4 h. No chemical reaction was found between Sr 1.5 La 0.35 MnO 4 electrode and CGO electrolyte. The reaction rate limiting step for oxygen reduction on the electrode is the charge transfer process. The lowest Rp value was achieved for Sr 1.5 La 0.35 MnO 4 (0.25 Ω cm 2 ) at 750 °C and the highest current density is 100 mA cm -2 at overpotential of 49 mV.

Table 1 .

 1 Structural parameters of Sr La MnO obtained from Rietveld refinements of powder X-ray diffraction data.

Table 1 .

 1 Structural parameters of Sr1.5Lax 1.5 xMnO4 obtained from Rietveld refinements of powder X-ray diffraction

	4

F Fi ig gu ur re e 2 2: : XRD patterns of Sr La MnO , CGO and Sr La MnO -CGO powders. XRD patterns of Sr1.5La0.35MnO4, CGO and Sr1.5La0.35MnO4-CGO powders.

  Impedance spectra of Sr1.5La0.35MnO4 cathode on CGO electrolyte measured at 750 °C under various

	1.5	0.35	4
	oxygen partial pressures. .
			1.5	0.35	4

F Fi ig gu ur re e 7 7: : Impedance spectra of Sr La MnO cathode on CGO electrolyte measured at 750 °C under various oxygen partial pressures F Fi ig gu ur re e 8 8: : Curves of polarization resistances vs. . P P O2 Curves of polarization resistances vs O2 for Sr La MnO electrode at 750 °C. for Sr1.5La0.35MnO4 electrode at 750 °C.

Acknowledgements

The Project was supported by National Natural Science Foundation of China (51072048), Research Project of New Century Excellent Talents in University (NCET-06-0349), Heilongjiang Educational Department (GZ09A204, 1152G027, 11531274, 11531285).


A Critical Evaluation of the "IPv6 Routing Protocol for Low Power and Lossy Networks" (RPL)

Keywords: Réseaux de capteurs, RPL, Routage, Evaluation

RPL -le protocole de routage IPv6 des réseaux des capteurs (LLN) -émerge comme "Proposed Standard" "Request For Comment" (RFC) dans l'Internet Engineering Task Force (IETF) après un cycle de développement d'environ deux ans. Ce rapport présente une évaluation du protocole de routage et de son applicabilité et ses limites. Ce rapport présente une sélection d'observations des caractéristiques du protocole, expose des expériences acquises en produisant une implémentation de RPL, et présente des résultats obtenus en testant le protocole dans un simulateur de réseaux et dans un testbed des capteurs sans-fil. Le rapport vise à fournir une meilleure compréhension des éventuelles faiblesses et limites de RPL, notamment des directions possibles pour des futurs développements du protocole afin de mitiger ces faiblesses et limites.

Introduction

RPL -the "Routing Protocol for Low Power and Lossy Networks" (RPL) [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF] -is a proposal for an IPv6 routing protocol for Low-power Lossy Networks (LLNs), by the ROLL Working Group in the Internet Engineering Task Force (IETF). This routing protocol is intended to be the IPv6 routing protocol for LLNs and sensor networks, applicable in all kinds of deployments and applications of LLNs. The unofficial goal, of the ROLL Working Group, is to prevent fragmentation in the sensor networking market by providing an IP-based routing standard, and solicit broad industrial support behind that standard.

The objective of RPL and ROLL is to target networks which "comprise up to thousands of nodes", where the majority of the nodes have very constrained resources, where the network to a large degree is "managed" by a (single or few) central "supernodes", and where handling mobility is not an explicit design criteria. Supported traffic patterns include multipoint-to-point, point-to-multipoint and point-to-point traffic. The emphasis among these traffic patterns is to optimize for multipoint-to-point traffic, to reasonably support point-to-multipoint traffic and to provide basic features for point-to-point traffic, in that order.

As of early 2011, RPL has been deemed "ready" by the IETF, for publication as a "Proposed Standard" RFC (Request for Comments). The implication of a protocol being labeled "Proposed Standard" is that it is considered generally stable: well-understood and community reviewed, no known design issues pending, and with some community support. "Proposed Standard" is, however, only the first step on what is called the Standards Track1 -experiences with the protocol, from testing and operational deployments, as well as detailed studies of its characteristics and behaviors, may result in protocol changes or retraction.

It is thus opportune to consider the protocol, at its current level of specification, in order to understand which aspects of it necessitate further investigations, and in order to identify possibly weak points which may restrict the deployment scope of the protocol. This memorandum has as objective to provide a critical evaluation of RPL, in the spirit of better understanding its characteristics and limits.

Memorandum Outline

The remainder of this memorandum is organized as follows: section 2 provides an overview of the functional parts of RPL -the algorithms for constructing the basic forwarding structures, as well as protocol signaling. Sections 3-12 each explore a specific aspect of RPL, and provide a critical analysis of the impact of the underlying hypotheses made by the designers of RPL. Where possible, abstract reflections on the protocol are complemented by simulation results and results from experiments in a test-bed with real sensor devices. Section 13 concludes this memorandum by providing both a summary of the observations made, as well as the authors position regarding the applicability of RPL and the possible directions that protocol development should take, in order that IPv6 routing protocols for LLNs can progress -both on the IETF Standards Track and in wide-scale real world deployments.

RPL Overview

The basic construct in RPL is a "Destination Oriented Directed Acyclic Graph" (DODAG), depicted in figure 1. In a converged LLN, each RPL router has identified a stable set of parents, each of which is a potential next-hop on a path towards the "root" of the DODAG, as well as a preferred parent. Each router, which is part of a DODAG (i.e. has selected parents) will emit DODAG Information Object (DIO) messages, using link-local multicast, indicating its respective rank in the DODAG (i.e. distance to the DODAG root according to some metric(s), in the simplest form hop-count). Upon having received a (number of such) DIO messages, a router will calculate its own rank such that it is greater than the rank of each of its parents, select a preferred parent and then itself start emitting DIO messages.

The DODAG formation thus starts at the DODAG root (initially, the only router which is part of a DODAG), and spreads gradually to cover the whole LLN as DIOs are received, parents and preferred parents are selected and further routers participate in the DODAG. The DODAG root also includes, in DIO messages, a DODAG Configuration Object, describing common configuration attributes for all RPL routers in that network -including their mode of operation, timer characteristics etc. RPL routers in a DODAG include a verbatim copy of the last received DODAG Configuration Object in their DIO messages, permitting also such configuration parameters propagating through the network. A Distance Vector protocol, RPL [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF] restricts the ability for a router to change rank. A router can freely assume a smaller rank than previously advertised (i.e. logically move closer to the root) if it discovers a parent advertising a lower rank, and must then disregard all previous parents of higher ranks. The ability for a router to assume a greater rank (i.e. logically move farther from the root) than previously advertised is restricted, to avoid count-to-infinity problems. The root can trigger "global recalculation" of the DODAG by increasing a sequence number, DODAG version, in DIO messages.

The DODAG so constructed is used for installing routes: the "preferred parent" of an RPL router can serve as a default route towards the root, or the root can embed in its DIO messages the destination prefixes, included by DIOs generated by RPL routers through the LLN, to which connectivity is provided by the root. Thus, RPL by way of DIO generation provides "upward routes" or "multipoint-to-point routes" from the sensors inside the LLN and towards the root.

INRIA inria-00597036, version 1 -31 May 2011

"Downward routes" are enabled by having sensors issue Destination Advertisement Object (DAO) messages, propagating as unicast via parents towards the DODAG root. These describe which prefixes belong to, and can be reached via, which RPL router. In a network, all RPL routers must operate in either of storing-mode or non-storing-mode, specified by way of a "Mode of Operation" (MOP) flag in the DODAG Configuration Object from the root. Depending on the MOP, DAO messages are forwarded differently towards the root:

• In non-storing-mode, an RPL router originates DAO messages, advertising one or more of its parents, and unicast it to the DODAG root. Once the root has received DAOs from an RPL router, and from all routers on the path between it and the root, it can use source routing for reaching advertised destinations inside the LLN.

• In storing-mode, each RPL router on the path between the originator of a DAO and the root records a route to the prefixes advertised in the DAO, as well as the next-hop towards these (the router, from which the DAO was received), then forwards the DAO to its preferred parent.

"Point-to-point routes", for communication between devices inside the LLN and where neither of the communicating devices are the DODAG root, are as default supported by having the source sensor transmit via its default route to the DODAG root (i.e., using the upward routes) which will then, depending on the "Mode of Operation" for the DODAG, either add a source-route to the received data for reaching the destination sensor (downward routes in nonstoring-mode) or simply use hop-by-hop routing (downward routes in storingmode). In the case of storing-mode, if the source and the destination for a pointto-point communication share a common ancestor other than the DODAG root, a downward route may be available (and used) before reaching the DODAG root.

RPL Message Emission Timing -Trickle Timers

RPL message generation is timer-based, with the root able to configure back-off of message emission intervals using Trickle [START_REF] Levis | Trickle: A self-regulating algorithm for code propagation and maintenance in wireless sensor networks[END_REF], specified in [START_REF] Levis | RFC6206: The Trickle Algorithm[END_REF]. Trickle, as used in RPL, stipulates that a RPL router transmits a DIO "every so often" -except if receiving a number of DIOs from neighbor routers, enabling the router to determine if its DIO transmission is redundant.

When an RPL router transmits a DIO, there are two possible outcomes: either every neighbor router that hears the message finds that the information contained is consistent with its own state (i.e., the received DODAG version number received corresponds with that which the RPL router has recorded and no better rank is advertised than that which is recorded in the parent set) -or, a recipient RPL router detects that either the sender of the DIO or itself has outof-date information. If the sender has out-of-date information, then the recipient RPL router schedules transmission of a DIO to update this information. If the recipient RPL router has out-of-date information, then it updates based on the information received in the DIO.

With Trickle, an RPL router will schedule emission of a DIO at some time, t, in the future. When receiving a DIO containing information consistent with its own information, the RPL router will record that "redundant information has been received" by incrementing a redundancy counter, c. At the time t, if RR n°7633 inria-00597036, version 1 -31 May 2011 c is below some "redundancy threshold", then it transmits its DIO. Otherwise, transmission of a DIO at this time is suppressed, c is reset and a new t is selected to twice as long time in the future -bounded by a pre-configured maximum value for t. If, on the other hand, the RPL router has received an out-of-date DIO from one of its neighbors, t is reset to a pre-configured minimum value and c is set to zero. In both cases, at the expiration of t, the RPL router will verify if c is below the "redundancy threshold" and if so transmit -otherwise, increase t and stay quiet.

RPL Data Traffic Flows

RPL makes a-priori assumptions of traffic patterns: sensor-to-root traffic (multipointto-point) is predominant, root-to-sensor traffic (point-to-multipoint) is rare and sensor-to-sensor traffic is somewhat esoteric.

An RPL router selects from among its parents a "preferred parent", to serve as a default route towards the root (and to prefixes advertised by the root). Thus, RPL provides "upward routes" or "multipoint-to-point routes" from the sensors towards the root. An RPL router which wishes to act as a destination for traffic ("downward routes" or "point-to-multipoint") issues DAOs upwards in the DODAG towards the root, describing which prefixes belong to, and can be reached via, that RPL router. Sensor-to-sensor routes are supported by having the source sensor transmit, via its default route, towards the root. In non-storing mode, the data will reach the root, which will send the data packet downward towards the destination sensor. In storing mode, the source and the destination may have a common ancestor other than the DODAG root, which may provide a downward route to the destination.

Why This Is A Critical Point

The data traffic characteristics assumed by RPL do not represent a universal distribution of traffic patterns in LLNs:

• There are scenarios where sensor-to-sensor traffic is a more common occurrence, documented e.g. in [START_REF] Martocci | Building Automation Routing Requirements in Low Power and Lossy Networks[END_REF].

• There are scenarios, where all traffic is bi-directional, e.g. in case sensor devices in the LLN are, in majority, "actively read": a request is issued by the root to a specific sensor, and the sensor value is expected returned.

For the former, all sensor-to-sensor paths include the root, possibly causing congestion on the communications medium near the root, and draining energy from the intermediate RPL routers on an unnecessarily long path. If sensor-tosensor traffic is common, RPL routers near the root will be particularly solicited as relays, especially in non-storing mode. For the latter, all RPL routers are required to generate DAOs, which generates a considerable control traffic overhead.

INRIA inria-00597036, version 1 -31 May 2011 4 Fragmentation

Fragmentation of IP packets appears when the size of the IP datagram is larger than the Maximum Transmission Unit (MTU) supported by the link layer. When an IP packet is fragmented, all fragments of that IP packet must be successfully received by a router, in order that the IP packet is successfully received -otherwise, the whole IP packet is lost. Moreover, the additional linklayer frame overhead for each of the fragments increases the capacity required from the medium, and may consume more energy for transmitting a higher number of frames on the network interface.

RPL is an IPv6 routing protocol, designed to operate on constrained link layers, such as 802.15.4 [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802.15.4 Networks[END_REF], with a maximum MTU of 127 bytes -a deviation from the otherwise specified minimum MTU of 1280 bytes for IPv6 [START_REF] Deering | RFC2460: Internet Protocol, Version 6 (IPv6) Specification[END_REF]. Reducing the need of fragmentation of packets on such a link layer, compression adaptation layers exist [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802.15.4 Networks[END_REF][START_REF] Hui | Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)[END_REF], reducing the overhead of the IPv6 header from at least 40 octets to a minimum of 2 octets. With a physical layer packet size of 127 octets, a maximum frame overhead of 25 octets and 21 octets for link layer security [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802.15.4 Networks[END_REF], 81 octets remain for L2 payload. Further subtracting 2 octets for the compressed IPv6 header leaves 79 octets for L3 data payload.

The second L in LLN indicating Lossy [START_REF]ROLL Charter[END_REF], higher loss rates than typically seen in IP networks are expected, rendering fragmentation important to avoid.

DIO messages consist of a mandatory base object, facilitating DODAG formation, and additional options for e.g. autoconfiguration and network management. The base object contains two unused octets, reserved for future use, resulting in two bytes of unnecessary zeros, sent with each DIO message. The Prefix Information option, used for automatic configuration of address, is even worse: it carries four unused octets to be compatible with IPv6 neighbor discovery.

Why This Is A Critical Point

While 79 octets may seem to be sufficient to carry RPL control messages, consider the following: RPL control messages are carried in ICMP66, and the mandatory ICMPv6 header consumes 4 octets. The DIO base another 24 octets. If link metrics are used, that consumes at least another 8 octets 2 . The DODAG Configuration Object consumes up to a further 16 octets, for a total of 52 octets. Adding a Prefix Information Object for address configuration consumes another 32 octets, for a total of 84 octets -thus exceeding the 79 octets available for L3 data payload and causing fragmentation of such a DIO. As a point of reference, the ContikiRPL [START_REF] Tsiftes | Low-Power Wireless IPv6 Routing with ContikiRPL[END_REF] implementation includes both the DODAG Configuration option and the Prefix Information option in all DIO message. Any other options, e.g. Route Information options indicating prefixes reachable through the root, worsen this situation.

RPL may further increase the probability of fragmentation of also user data traffic: for non-storing-mode, RPL employs source-routing for all downward traffic. [START_REF] Hui | An IPv6 Routing Header for Source Routes with RPL[END_REF] specifies the RPL Source Routing header, which imposes a fixed overhead of 8 octets per IP packet leaving 71 octets remaining from the MTU -from which must be deducted a variable number of octets, depending on 2 Using a hop count metric; other metrics may require more.

RR n°7633

inria-00597036, version 1 -31 May 2011 the length of the route. With fewer octets available for data payload, RPL thus increases the probability for fragmentation of also data packets. This, in particular, for longer paths, e.g. in point-to-point traffic between sensors inside the LLN, where data packets transit through the DODAG root and are then source-routed to the destination.

DAO Mechanism

RPL specifies two distinct and incompatible "modes of operation" for downward traffic: storing mode, where each RPL router is assumed to maintain routes to all destinations in its sub-DODAG, i.e. routers that are "deeper down" in the DAG, and non-storing mode, where only the root stores routes to destinations in the LLN.

Why This Is A Critical Point

In addition to possible fragmentation, as discussed in section 4, the maximum length of the source routing header [START_REF] Hui | An IPv6 Routing Header for Source Routes with RPL[END_REF] is limited to 136 octets, including an 8 octet long header. As each IPv6 address has a length of 16 octets, not more than 8 hops from the source to the destination are possible for "raw IPv6". Using address compression [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802.15.4 Networks[END_REF], the maximum path length may not exceed 64 hops. This excludes scenarios with long "chain-like" topologies, such as traffic lights along a street.

In storing mode, each RPL router has to store routes for destinations in its sub-DODAG. This implies that, for RPL routers near the root, the required storage is only bounded by the number of paths to all other destinations in the network. As RPL targets constrained devices with little memory, but also has as ambition to be operating networks consisting of thousands of routers, the storing capacity on these RPL routers may not be sufficient. Aggregation / summarization of addresses may be advanced as a possible argument that this issue is of little significance -section 6 will discuss why such an argument does not apply.

In short, the mechanisms in RPL force the choice between requiring all RPL routers to have sufficient memory to store route entries for all destinations (storing-mode) -or, suffer increased risk of fragmentation, and thus loss of data packets, while consuming network capacity by way of source routing through the DODAG root.

In RPL, the "mode of operation" stipulate that either downward routes are not supported (MOP=0), or that they are supported by way of either storing or non-storing mode. In case downward routes are supported, RPL does not provide any mechanism for discriminating between which routes should or should not be maintained. In particular, in order to calculate paths to a given destination, all intermediaries between the DODAG root and that destination must themselves be reachable -effectively rendering downward routes in RPL an "all-or-none" situation. In case a destination is unreachable, all the DODAG root may do is require all destinations to re-issue their DAOs3 , possibly provoking a broadcast-storm-like situation. This, in particular, as [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF] does not specify DAO message transmission constraints, in particular specifies no mechanism for adapting DAO emission to the network capacity.

A final point on the DAO mechanism: RPL supports point-to-point traffic only by way of relaying through the DODAG root. In networks where pointto-point traffic is no rare occasion, this causes unduly long paths (with possibly increased energy consumption, increased probability of packet losses) as well as possibly congestion around the DODAG root.

Aggregation

As indicated in section 5, in storing mode, a RPL router is expected to be able to store routing entries for all destinations in its "sub-DODAG", i.e., routing entries for all destinations in the network where the path to the DODAG root includes that RPL router.

In the Internet, no single router stores explicit routing entries for all destinations -no router has a routing table with 2 32 entries for IPv4 routing. Rather, IP addresses are assigned hierarchically, such that an IP address does not only uniquely identify a network interface, but also its topological location in the network, as illustrated in figure 2. Colloquially speaking, all addresses with the same prefix are reachable by way of the same router -which can, therefore, advertise only that prefix. Other routers need only record a single routing entry for that prefix, knowing that as the IP packet reaches the router advertising that prefix, more precise routing information is available.

Why This Is A Critical Point

In RPL, each RPL router acquires a number of parents, as described in section 2, from among which it selects one as its preferred parent and, thus, next-hop on the path to the DODAG root. RPL routers maintain a parent set containing possibly more than a single parent so as to be able to rapidly select an alternative preferred parent, should the previously selected such become unavailable. Thus expected behavior is for an RPL router to be able to change its point of attachment towards the DODAG root. If IP addresses are assigned in a strictly hierarchical fashion, and if scalability of the routing state maintained in storing mode is based on this hierarchy, then this entails that each time a RPL router changes its preferred parent, it must also change its own IP address -as well as

RR n°7633

inria-00597036, version 1 -31 May 2011 cause RPL routers in its "sub-DODAG" to do the same. RPL does not specify signaling for reconfiguring addresses in a sub-DODAG.

A slightly less strict hierarchy can be envisioned, where a router can change its preferred parent without necessarily changing addresses of itself and of its sub-DODAG, provided that its former and new preferred parents both have the same preferred parent, and have addresses hierarchically assigned from thatfrom the "preferred grandparent". With reference to figure 1, this could be e changing its preferred parent from d to c, provided that both d and c have b as preferred parent. Doing so would impose a restriction on the parentset selection, admitting only parents which have themselves the same parent -thus, no longer having a DODAG but a simple tree, loosing redundancy in the network connectivity. RPL does not specify rules for admitting only parents with identical grand-parents into the parent set -although such is not prohibited either, if the loss of redundancy from constructing a tree is acceptable.

The DODAG root incrementing the DODAG version number is the mechanism by which RPL enables global reconfiguration of the network, reconstructing the DODAG with (intended) more optimal paths. In case of addressing hierarchies being enforced, so as to enable aggregation, this will either restrict the ability for an optimal DODAG construction, or will trigger global address autoconfiguration so as to ensure addressing hierarchies.

Finally, with IP addresses serving a dual role of an identifier of both an endpoint for communication and a topological location in the network, changing the IP address of a device, so as to reflect a change in network topology, also entails interrupting ongoing communication to or through that device. Additional mechanisms (e.g. a DNS-like system) mapping "communications identifies" and "IP addresses" is required -a topic investigated, but not resolved, in the Internet4 .

Bidirectionality Hypothesis

Parents (and the preferred parent) are selected based on receipt of DIOs, without verification of the ability for a RPL router to successfully communicate with the parent -i.e. without any bidirectionality check of links. However, the basic use of links is for "upward" routes, i.e. for the RPL router to use a parent (the preferred parent) as relay towards the DODAG root -in the opposite direction of the one in which the DIO was received.

Why This Is A Critical Point

Unidirectional links are no rare occurrence, such as is known from wireless multihop networks. If an RPL router receives a DIO on such a unidirectional link, and selects the originator of the DIO as parent, that would be a bad choice: unicast traffic in the upward direction would be lost. If the router had verified the bidirectionality of links, it might have selected a better parent, to which it has a bidirectional link.

8 Why NUD is NOT a Solution [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF] suggests using Neighbor Unreachability Detection (NUD) [START_REF] Narten | Neighbor Discovery for IP version 6 (IPv6)[END_REF] to detect and recover from the situation of unidirectional links between a RPL router and its (preferred) parent(s). When, e.g., a router a tries (and fails) to actually use router b for forwarding traffic, NUD is supposed engaged to detect and prompt corrective action, e.g. by way of selecting an alternative preferred parent.

NUD is based upon observing if a data packet is making forward progress towards the destination, either by way of indicators from upper-layer protocols (such as TCP) 5 or -failing that -by unicast probing by way of transmitting a unicast Neighbor Solicitation message and expecting that a solicited Neighbor Advertisement message be returned.

Why This Is A Critical Point

An RPL router may receive, transiently, a DIO from a router, closer (in terms of rank) to the root than any other router from which a DIO has been received. Some, especially wireless, link layers may exhibit different transmission characteristics between multicast and unicast transmissions 6 , leading to a (multicast) DIO being received from farther away than a unicast transmission can reach. DIOs are sent (downward) using link-local multicast, whereas the traffic flowing in the opposite direction (upward) is unicast. Thus, a received (multicast) DIO may not be indicative of useful unicast connectivity -yet, RPL might cause this RPL router to select this attractive router as its preferred parent. This may happen both at initialization or at any time during the LLN lifetime, as RPL allows attachment to a "better parent" at any time.

A DODAG so constructed may appear stable and converged until such time that unicast traffic is to be sent and, thus, NUD invoked. Detecting only at that point that unicast connectivity is not maintained, and causing local (and possibly global) repairs exactly at that time, may lead to traffic not being deliverable. As indicated in section 6, if scalability is dependent on addresses being assigned hierarchically, changing point-of-attachment may entail more than switching preferred parent.

Also, absent all RPL routers consistently advertising their reachability through DAO messages, a protocol requiring bi-directional flows between the communicating devices, such as TCP, will be unable to operate.

Finally, upon having been notified by NUD that the "next hop" is unreachable, an RPL router must discard the preferred parent and select anotherhoping that this time, the preferred parent is actually reachable. Also, if NUD indicates "no forward progress" based on an upper-layer protocol, there is no guarantee that the problem stems exclusively from the preferred parent being unreachable. Indeed, it may be a problem farther ahead, possibly outside the LLN, thus changing preferred parent will do nothing to alleviate the situation.

RPL Implementability and Complexity

RPL is designed to operate on "RPL routers [...] with constraints on processing power, memory, and energy (battery power)" [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF]. However, the 163 pages long specification of RPL7 , describes complex mechanisms (e.g. the upwards and downward data flows, a security solution, manageability of RPL routers, auxiliary functions for autoconfiguration of RPL routers, etc.), and provides no less than 9 message types, and 10 different message options.

To give one example, the ContikiRPL implementation 8 , which provides only storing-mode and no security features, consumes about 50 KByte of memory. Sensor hardware, such as MSP430 sensor platforms, does not contain much more memory than that, i.e. there may not be much space left to deploy any application on the RPL router.

Why This Is A Critical Point

Since RPL is designed to be the routing protocol for LLNs, which covers all the diverse applications requirements listed in [START_REF] Martocci | Building Automation Routing Requirements in Low Power and Lossy Networks[END_REF][START_REF] Pister | Industrial Routing Requirements in Low-Power and Lossy Networks[END_REF][START_REF] Brandt | Home Automation Routing Requirements in Low-Power and Lossy Networks[END_REF][START_REF] Dohler | Routing Requirements for Urban Low-Power and Lossy Networks[END_REF], it is possible that (i) due to limited memory capacity of the RPL routers, and (ii) due to expensive development cost of the routing protocol implementation, many RPL implementations will only support a partial set of features from the specification, leading to non-interoperable implementations.

RPL Underspecification

While [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF] is verbose in many parts, as described in section 9, some mechanisms are underspecified.

While for DIOs, the Trickle timer specifies an efficient and easy-to-understand timing for message transmission, the timing of DAO transmission is not explicit. As each DAO may have a limited lifetime, one "best guess" for implementers would be to send DAO periodically, just before the life-time of the previous DAO expires. Since DAOs may be lost, another "best guess" would be to send several DAOs shortly one after the other in order to increase probability that at least one DAO is successfully received.

The same underspecification applies for DAO-ACK messages: optionally, on reception of a DAO, an RPL router may acknowledge successful reception by returning a DAO-ACK. Timing of DAO-ACK messages is unspecified by RPL.

Why This Is A Critical Point

By not specifying details about message transmission intervals and required actions when receiving DAO and DAO-ACKs, implementations may exhibit a bad performance if not carefully implemented. Some examples are:

1. If DAO messages are not sent in due time before the previous DAO expires (or if the DAO is lost during transmission), the routing entry will expire before it is renewed, leading to a possible data traffic loss.

2. RPL does not specify to use jitter [START_REF] Clausen | Jitter Considerations in Mobile Ad Hoc Networks (MANETs)[END_REF] (i.e. small random delay for message transmissions). If DAOs are sent periodically, adjacent routers may transmit DAO messages at the same time, leading to link layer collisions.

3. In non-storing mode, the "piece-wise calculation" of routes to a destination from which a DAO has been received, relies on previous reception of DAOs from intermediate routers along the path. If not all of these DAOs from intermediate routers have been received, route calculation is not possible, and DAO-ACKs or data traffic cannot be sent to that destination.

Other examples of underspecification include the local repair mechanism, which may lead to loops and thus data traffic loss, if not carefully implemented: a router discovering that all its parents are unreachable, may -according to the RPL specification -"detach" from the DODAG, i.e. increase its own rank to infinity. It may then "poison" its sub-DODAG by advertising its infinite rank in its DIOs. If, however, the router receives a DIO before it transmits the "poisoned" DIO, it may attach to its own sub-DODAG, creating a loop. If, instead, it had waited some time before processing DIOs again, chances are it would have succeeded in poisoning its sub-DODAG and thus avoided the loop.

Trickle Convergence

Trickle [START_REF] Levis | RFC6206: The Trickle Algorithm[END_REF] is used by RPL to schedule transmission of DIO messages, with the objective to minimize the amount of transmitted DIOs while ensuring a low convergence time of the network. The theoretical behavior of Trickle is well understood, and the convergence properties are well studied [START_REF] Levis | Trickle: A self-regulating algorithm for code propagation and maintenance in wireless sensor networks[END_REF]. Simulations of the mechanism, such as [START_REF] Herberg | Study of Multipoint-to-Point and Broadcast Traffic Performance in the 'IPv6 Routing Protocol for Low Power and Lossy Networks' (RPL)[END_REF], confirm these theoretical studies.

In real-world environments, however, varying link qualities may cause the algorithm to converge less well: frequent message losses entail resets of the Trickle timer and more frequent and unpredicted message emissions. This has been observed in an experimental testbed: 69 RPL routers 9 were positioned in a fixed grid topology. This resulted in DODAGs being constructed with an average of 2.45 children per RPL router and an average rank 10 of 3.58.

Figure 3 shows the number of DIO messages that are emitted (counting each retransmission at intermediate routers) per interval of 10 seconds, in both the test bed and an identical scenario simulated in Ns2. The Ns2 simulation parameters were chosen to match the testbed environment, as far as possible (80 routers, 1265x1265m area, 1800s simulation time, 802.11, two-ray-ground model, 250m transmission range, no mobility, JRPL implementation [START_REF] Herberg | JRPL web site[END_REF]).

While the number of DIOs, emitted per 10 second interval in the whole network, rapidly drops in the simulation, a constant number of about 70 DIOs per 10 second interval was observed in the testbed experiment.

Why This Is A Critical Point

The varying link quality in real-world environments results in frequent changes of the best parent, which triggers a reset of the Trickle timer and thus the 9 MSP430-based wireless sensor routers with IEEE 802.15.4, using [START_REF] Tsiftes | Low-Power Wireless IPv6 Routing with ContikiRPL[END_REF] IPv6 stack and RPL without downward routes; the parameters of the Trickle timer were set to the implementation defaults (minimum DIO interval: 4 s, DIO interval doublings: 8, redundancy constant: 10). 10 Hop count. The resulting higher control overhead due to frequent DIO emission, leads to higher bandwidth and energy consumption as well as possibly to an increased number of collisions of frames, as observed in [START_REF] Herberg | Study of Multipoint-to-Point and Broadcast Traffic Performance in the 'IPv6 Routing Protocol for Low Power and Lossy Networks' (RPL)[END_REF].

12 Loops Section 7.1. describes one way in which routing loops can occur in RPL. [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF] states that it "guarantees neither loop free path selection nor tight delay convergence times, but can detect and repair a loop as soon as it is used. RPL uses this loop detection to ensure that packets make forward progress [...] and trigger repairs when necessary". This implies that a loop may only then be detected and fixed when data traffic is sent through the network.

In order to trigger a local repair, RPL relies on the "direction" information (with values "up" or "down"), contained in an IPv6 hop-by-hop option header [START_REF] Hui | RPL Option for Carrying RPL Information in Data-Plane Datagrams[END_REF] of a data packet. If an "upward" data packet is received by a RPL router, but the previous hop of the packet is listed with a lower rank in the neighbor set, the RPL router concludes that there must be a routing loop and it may therefore trigger a local repair. For downward traffic in non-storing mode, the root can detect loops if the same router identifier (i.e. IP address) appears at least twice in the path towards a destination.

Why This Is A Critical Point

The reason for RPL to repair loops only when detected by a data traffic transmission is to reduce control traffic overhead. However, there are two problems in repairing loops only when so triggered: (i) the triggered local repair mechanism delays forward progress of data packets, increasing end-to-end delays, and (ii) the data packet has to be buffered during repair.

(i) may seem as the lesser of the two problems, since in a number of applications, such as data acquisition in smart metering applications, an increased delay may be acceptable. However, for applications such as alarm signals or in home automation (e.g. a light switch), increased delay may be undesirable.

As for (ii), RPL is supposed to run on LLN routers with "constraints on [...] memory" [START_REF] Winter | RPL: IPv6 Routing Protocol for Low power and Lossy Networks[END_REF]; buffering incoming packets during the route repair may not be possible for all incoming data packets, leading to dropped packets. Depending on the transport protocol, these data packets must be retransmitted by the source or are definitely lost.

If carefully implemented with respect to avoiding loops before they occur, the impact of the loop detection in RPL may be minimized. However, it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur frequently. During the experiments described in section 11, a snapshot of the DODAG was taken every ten seconds. In 74.14 % of the 4114 snapshots, at least one loop was observed. Further investigation revealed that in all these cases the DODAG was partitioned, and the loop occurred in the sub-DODAG that no longer had a connection to the DODAG root. When the link to the only parent of a router breaks, the router may increase its rank and -when receiving a DIO from a router in its sub-DODAG -attach itself to its own sub-DODAG, thereby creating a loop -as detailed in section 10.

While it can be argued that the observed loops are harmless since they occur in a DODAG partition that has no connection to the root anyway, they show that the state of the network is inconsistent. Even worse, when the broken link re-appears, it is possible that in certain situations the loop is only then repaired when data traffic is sent, possibly leading to data loss (as described above). This can occur if the link to the previous parent is reestablished, but the rank of that previous parent has increased in the meantime.

Another problem with the loop repair mechanism arises in non-storing mode when using only downward traffic: while the root can easily detect loops (as described above), it has no direct means to trigger a local repair where the loop occurs. Instead, it can only trigger a global repair by increasing the DODAG version number, leading to a Trickle timer reset and increased control traffic overhead in the network caused by DIO messages, and therefore a possible energy drain of the routers and congestion of the channel.

Conclusion and Position

Modulo the issues presented regarding bi-directionality of links and the possibility of loops, DODAG formation, and so the multipoint-to-point route provisioning mechanism, is elegant and relatively well understood, although the difference in convergence between theory/simulation and real-world sensor network behaviors necessitates further exploration. DIO message generation/processing rules RR n°7633 inria-00597036, version 1 -May 2011 and the Trickle timers [START_REF] Levis | RFC6206: The Trickle Algorithm[END_REF] are relatively straight-forward to implement, and the state required in each router is minimal and bounded.

The DAO mechanism is what enables downward routes, bi-directional traffic flows and sensor-to-sensor flows by way of dog-leg-routing through the root, is less elegant. Problems include "underspecification", e.g. of the proper behavior with respect to DAO-ACKs and DAO retransmissions and message generation intervals, as well as two incompatible modes-of-operation: storing mode, wherein all LLN routers are expected to have "unbounded" memory (or, at least, enough to store complete routing tables), and non-storing mode necessitating sourcerouting thus possibly more fragmentation and higher probability of IP packets being lost. Both of these appear to be challenging in Low-power Lossy Networks with resource-constrained devices -as does addressing scalability concerns by way of address aggregation appear unfeasible in a such self-forming network.

Loops are a real problem in RPL, confirmed experimentally. Even in nonstoring mode, where the DODAG root performs source-routing to destinations inside the LLN, loops are a problem: while they can be detected when constructing the source route, the only corrective measure that the DODAG root can take is to trigger global reconstructions of the DODAG -a complete "reboot" of the LLN.

Figure 1 :

 1 Figure 1: RPL Basic Construct: DODAGs

Figure 2 :

 2 Figure 2: Addressing hierarchies in the Internet

Figure 3 :

 3 Figure 3: Trickle convergence for simulation and real world experiment

  INRIAinria-00597036, version 1 -31 May 2011

The Standards Track in the IETF consists of "Proposed Standard", "Draft Standard", and "Internet Standard", in increasing order of maturity.RR n°7633inria-00597036, version 1 -31 May

By issuing a DIO with an increased DODAG version number. INRIA

The IETF LISP working group, https://datatracker.ietf.org/wg/lisp/charter/, is chartered to address this issue.

Though not called out in[START_REF] Narten | Neighbor Discovery for IP version 6 (IPv6)[END_REF], also from lower-layer protocols (such as Link Layer ACKs).

Such is the case for some implementations of IEEE 802.11b, where multicast/broadcast transmissions are sent at much lower bit-rates than are unicast. IEEE 802.11b is, of course, not suggested as a viable interface for LLNs, but serves to illustrate that such asymmetric designs exist.RR n°7633inria-00597036, version 1 -31 May 2011

Plus additional specifications for routing headers[START_REF] Hui | An IPv6 Routing Header for Source Routes with RPL[END_REF], Trickle timer[START_REF] Levis | RFC6206: The Trickle Algorithm[END_REF], routing metrics[START_REF] Vasseur | Routing Metrics used for Path Calculation in Low Power and Lossy Networks[END_REF] and objective function[START_REF] Thubert | RPL Objective Function 0[END_REF].

http://www.sics.se/contiki INRIA

RR n°7633

http://www.inria.fr ISSN 0249-6399