Description des architectures simples

Définition 2 (Architecture simple). Une architecture multi-piles est dite simple

quand, pour chaque paquet, une seule pile protocolaire est utilisée pour l’achemine-ment de bout en bout.

Le concept d’architecture simple repose sur un concept que nous appelons

multi-layering [ERGM11*], qui permet à plusieurs protocoles différents de coexister au sein

d’une même couche. Ce concept est différent de celui du cross-layering, qui permet à des protocoles de couches non adjacentes de communiquer. Multi-layering et

cross-layering sont complémentaires, le multi-cross-layering permettant d’ailleurs d’augmenter

les possibilités d’interactions entre protocoles (et donc le cross-layering), puisqu’il augmente le nombre de protocoles impliqués.

Dans la description qui suit, nous ferons deux hypothèses pour simplifier la dis-cussion. Tout d’abord, nous supposerons que les piles protocolaires ont des protocoles

MAC différents (ce qui est le cas dans Ocari)23 : chaque pile protocolaire i est ainsi caractérisée par un ensemble24 de protocoles applicatifs A_i, un protocole réseau R_i et un protocole d’accès au médium M_i. Ensuite, nous supposerons que les piles protocolaires suivent un calendrier d’activation, ce qui permet à chaque protocole d’accès au médium de gérer le temps pendant un intervalle dédié.

3.2.1.1 Calendrier d’activation des piles

Une architecture simple utilisant n piles protocolaires et ayant des couches MAC différentes est basée sur un calendrier composé de n périodes p_i qui se répètent (généralement cycliquement). Pendant chaque période p_i, tous les nœuds du réseau utilisent la combinaison, notée (R_i, M_i), d’un protocole de routage R_i et d’un proto-cole MAC M_i. La cohérence des visions du temps de chacun des nœuds est garantie par un mécanisme de synchronisation. Nous supposerons que ce mécanisme de syn-chronisation, exécuté par tous les nœuds, se répète lui aussi (cela nous permet de considérer que la période de synchronisation est la première période du calendrier). Un protocole MAC commun à toutes les piles, M^r, est chargé de réaliser cette syn-chronisation entre tous les nœuds, et de s’assurer que les nœuds connaissent l’instant de début du calendrier25. Mr est aussi chargé de construire et de communiquer à tous les nœuds le calendrier, ce qui inclut l’identification de chaque période p_i, leur instant de début et leur durée. Finalement, Mr est chargé de faire la liaison entre tous les protocoles M_i et la couche physique (notamment, Mr redirige les trames reçues de la couche physique au protocole M_i adéquat, par exemple en fonction de leur instant de réception). Il peut exister des périodes d’inactivité pour tous les nœuds dans le calendrier. Certains nœuds peuvent aussi dormir pendant certaines périodes p_i, sous la responsabilité du protocole M_i correspondant.

La figure 3.15 présente un exemple d’architecture simple, utilisant trois piles protocolaires. Chaque pile protocolaire i dispose de ses applications, de son protocole de routage, et de son protocole MAC. Le protocole MAC commun Mr permet la coexistence des piles, et le respect du calendrier d’activation des piles.

La figure 3.16 présente un calendrier pour n = 3 périodes (sans compter la période de synchronisation). Sur cet exemple, on peut remarquer que les périodes

p₁, p₂ et p₃ n’ont pas la même durée.

La construction du calendrier (réalisée par un nœud ayant des ressources impor-tantes, comme le CPAN) peut prendre plusieurs paramètres en compte : le choix des protocoles MAC et réseau en fonction de leurs propriétés, la durée allouée à chaque

23. Des exemples d’architectures simples où les piles protocolaires ont des protocoles MAC iden-tiques sont mentionnés dans 3.2.1.2.

24. On pourrait se dire que la coexistence de plusieurs protocoles par couche existe au niveau applicatif dans les piles protocolaires traditionnelles. Toutefois, la différence entre la coexistence des protocoles applicatifs et la coexistence des protocoles des autres couches est importante. Chaque protocole applicatif fournit un service différent, tandis que les protocoles des couches inférieures fournissent des services définis lors du découpage en couches, et ces services nécessitent des respon-sabilités qui ne sont pas supposées être partagées (comme la gestion du routage, du temps ou du médium).

25. Nous ne détaillons pas le mécanisme de synchronisation utilisé, qui peut s’appuyer sur plu-sieurs protocoles existants, comme RBS [EGE02], TPSN [GKS03], l’intervalle [T₀; T₁] de Macari, ADCF [LvdBC11] ou SISP [vdBVD11].

pile 1 pile 2 pile 3 A1 A2 A3 R1 R2 R3 M1 M2 M3 Mr PHY couches supérieures couche réseau sous-couche MAC couche physique

Figure 3.15 – Architecture multi-piles simple. La réunion des trois piles se fait par le protocole Mr au niveau de la sous-couche MAC.

synch.

synch. pile 1 pile 2 pile 3 pile 1 pile 2

temps Figure 3.16 – Calendrier dans lequel se répètent n = 3 périodes, correspondant à trois piles protocolaires différentes.

combinaison de protocoles, la quantité estimée de trafic par période et les proprié-tés de ce trafic, ou encore les besoins de synchronisation des protocoles MAC (les protocoles nécessitant une grande précision de synchronisation doivent être placés tôt dans le calendrier). Il est important de remarquer que le choix des combinaisons de protocoles et la durée allouée à chaque combinaison ont un impact important sur les performances de la solution finale.

3.2.1.2 Exemples d’architectures multi-piles simples Multi-piles ayant des protocoles MAC différents.

IEEE 802.15.4 en mode suivi de balises peut être considéré comme une architec-ture multi-piles ayant des protocoles MAC différents. Pour s’en convaincre, on peut noter que IEEE 802.15.4 en mode suivi de balises utilise un calendrier cadencé par l’envoi de balises (ces balises correspondent au protocole de synchronisation, intégré à M_r). À la réception d’une balise ou à la fin de l’envoi d’une balise, les nœuds entrent dans la période CAP (dont la durée peut être calculée à partir des informa-tions de la balise) pendant laquelle l’accès au médium est géré par CSMA/CA slotté (ce qui correspond au protocole MAC M₁). Puis, les nœuds entrent dans la période CFP (dont la durée est connue et peut être variable) pendant laquelle l’accès au médium est géré par des GTS (ce qui correspond au protocole MAC M₂).

Multi-piles ayant le même protocole MAC.

La pile duale IPv4-IPv6 [RFC 4213] (présentée dans la partie 2.2.2.1) est une architecture multi-piles dans laquelle la séparation se fait au niveau réseau (et donc, le même protocole MAC est utilisé par les deux piles). Une pile duale IPv4-IPv6 correspond à une implémentation conjointe des protocoles IPv4 (correspondant au protocole réseau R₁) et IPv6 (correspondant au protocole réseau R₂), ce qui permet d’éviter dans de nombreux cas les encapsulations d’IPv6 dans IPv4 ou d’IPv4 dans IPv6. Lorsqu’un paquet est reçu par la couche réseau, l’entête de ce paquet est examiné : si le champ version vaut 4, le paquet est transmis à la pile IPv4, et si ce champ vaut 6, le paquet est transmis à la pile IPv6.

Dans [MHJ+12] (décrit dans la partie 2.2.2.3), les auteurs proposent une autre architecture multi-piles dans laquelle la séparation se fait au niveau réseau. Ils dé-taillent l’utilisation d’une stratégie de routage nommée R_e+d qui permet de combiner la réduction de l’énergie consommée et du délai. Deux types de paquets sont générés au niveau applicatif : les paquets urgents sont acheminés selon la stratégie de routage

R_d (correspondant au protocole réseau R₁) qui réduit le délai, et les paquets non urgents sont acheminés selon la stratégie de routage R_e (correspondant au protocole réseau R₂) qui réduit l’énergie consommée.

3.2.1.3 Problèmes des architectures simples

Dans les architectures simples, c’est l’application du nœud source qui détermine la pile qui est utilisée pour acheminer chaque paquet. L’acheminement des paquets est donc imposé par un nœud qui a une vision limitée du réseau, ce qui peut être pénalisant.

Dans les architectures simples ayant des protocoles MAC différents, qui sont donc basées sur un calendrier, des problèmes supplémentaires apparaissent. Le premier problème est le dimensionnement de chaque période du calendrier, qui a un impact important sur les performances de l’architecture. En effet, quand une période est sous-dimensionnée, certaines trames doivent attendre la prochaine période pour être traitées, ce qui augmente leur délai, et quand une période est sur-dimensionnée, du temps est inutilement perdu. Le second problème est le délai induit par les périodes : une trame ne peut pas être traitée hors de la période pour laquelle elle est marquée, même si cette trame est prioritaire.