2. La pile d'étiquettes
- La pile d'étiquettes
2.1. Encodage de la pile d'étiquettes
La pile d'étiquettes est représentée comme une séquence d'"entrées de pile d'étiquettes". Chaque entrée de pile d'étiquettes est représentée par 4 octets. Ceci est montré dans la Figure 1.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Étiquette | Label | Exp |S| TTL | Pile +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entrée
Label: Valeur de l'étiquette, 20 bits
Exp: Utilisation expérimentale, 3 bits
S: Bas de la pile, 1 bit
TTL: Time to Live, 8 bits
Figure 1
Les entrées de la pile d'étiquettes apparaissent APRÈS les en-têtes de la couche de liaison de données, mais AVANT tout en-tête de la couche réseau. Le sommet de la pile d'étiquettes apparaît le plus tôt dans le paquet, et le bas apparaît le plus tard. Le paquet de la couche réseau suit immédiatement l'entrée de la pile d'étiquettes qui a le bit S défini.
Chaque entrée de la pile d'étiquettes est décomposée en champs suivants :
1. Bas de la pile (S)
Ce bit est défini à un pour la dernière entrée de la pile d'étiquettes (c'est-à-dire pour le bas de la pile), et à zéro pour toutes les autres entrées de la pile d'étiquettes.
2. Time to Live (TTL)
Ce champ de huit bits est utilisé pour encoder une valeur de durée de vie. Le traitement de ce champ est décrit dans la section 2.4.
3. Utilisation expérimentale
Ce champ de trois bits est réservé à une utilisation expérimentale.
4. Valeur de l'étiquette
Ce champ de 20 bits porte la valeur réelle de l'étiquette.
Lorsqu'un paquet étiqueté est reçu, la valeur de l'étiquette au sommet de la pile est recherchée. À la suite d'une recherche réussie, on apprend :
a) le prochain saut vers lequel le paquet doit être transmis ;
b) l'opération à effectuer sur la pile d'étiquettes avant la transmission ; cette opération peut consister à remplacer l'entrée supérieure de la pile d'étiquettes par une autre, ou à extraire (pop) une entrée de la pile d'étiquettes, ou à remplacer l'entrée supérieure de la pile d'étiquettes puis à pousser (push) une ou plusieurs entrées supplémentaires sur la pile d'étiquettes.
En plus d'apprendre le prochain saut et l'opération de pile d'étiquettes, on peut également apprendre l'encapsulation de la liaison de données sortante, et éventuellement d'autres informations nécessaires pour transmettre correctement le paquet.
Il existe plusieurs valeurs d'étiquettes réservées :
i. Une valeur de 0 représente l'"étiquette NULL explicite IPv4". Cette valeur d'étiquette n'est légale qu'au bas de la pile d'étiquettes. Elle indique que la pile d'étiquettes doit être extraite et que la transmission du paquet doit ensuite être basée sur l'en-tête IPv4.
ii. Une valeur de 1 représente l'"étiquette d'alerte de routeur". Cette valeur d'étiquette est légale n'importe où dans la pile d'étiquettes sauf au bas. Lorsqu'un paquet reçu contient cette valeur d'étiquette au sommet de la pile d'étiquettes, il est remis à un module logiciel local pour traitement. La transmission réelle du paquet est déterminée par l'étiquette située en dessous dans la pile. Cependant, si le paquet est transmis plus loin, l'étiquette d'alerte de routeur doit être repoussée sur la pile d'étiquettes avant la transmission. L'utilisation de cette étiquette est analogue à l'utilisation de l'"option d'alerte de routeur" dans les paquets IP [5]. Puisque cette étiquette ne peut pas apparaître au bas de la pile, elle n'est pas associée à un protocole de couche réseau particulier.
iii. Une valeur de 2 représente l'"étiquette NULL explicite IPv6". Cette valeur d'étiquette n'est légale qu'au bas de la pile d'étiquettes. Elle indique que la pile d'étiquettes doit être extraite et que la transmission du paquet doit ensuite être basée sur l'en-tête IPv6.
iv. Une valeur de 3 représente l'"étiquette NULL implicite". C'est une étiquette qu'un LSR peut attribuer et distribuer, mais qui n'apparaît jamais réellement dans l'encapsulation. Lorsqu'un LSR remplacerait autrement l'étiquette au sommet de la pile par une nouvelle étiquette, mais que la nouvelle étiquette est "NULL implicite", le LSR extraira la pile au lieu de faire le remplacement. Bien que cette valeur puisse ne jamais apparaître dans l'encapsulation, elle doit être spécifiée dans le protocole de distribution d'étiquettes, donc une valeur est réservée.
v. Les valeurs 4 à 15 sont réservées.
2.2. Détermination du protocole de couche réseau
Lorsque la dernière étiquette est extraite de la pile d'étiquettes d'un paquet (résultant en une pile vide), le traitement ultérieur du paquet est basé sur l'en-tête de la couche réseau du paquet. Le LSR qui extrait la dernière étiquette de la pile doit donc être capable d'identifier le protocole de la couche réseau du paquet. Cependant, la pile d'étiquettes ne contient aucun champ identifiant explicitement le protocole de la couche réseau. Cela signifie que l'identité du protocole de la couche réseau doit pouvoir être déduite de la valeur de l'étiquette qui est extraite du bas de la pile, éventuellement avec le contenu de l'en-tête de la couche réseau lui-même.
Par conséquent, lorsque la première étiquette est poussée sur un paquet de couche réseau, soit l'étiquette doit être celle qui est utilisée UNIQUEMENT pour les paquets d'une couche réseau particulière, soit l'étiquette doit être celle qui est utilisée UNIQUEMENT pour un ensemble spécifié de protocoles de couche réseau, où les paquets des couches réseau spécifiées peuvent être distingués par inspection de l'en-tête de la couche réseau. De plus, chaque fois que cette étiquette est remplacée par une autre valeur d'étiquette pendant le transit d'un paquet, la nouvelle valeur doit également être celle qui répond aux mêmes critères. Si ces conditions ne sont pas remplies, le LSR qui extrait la dernière étiquette d'un paquet ne pourra pas identifier le protocole de la couche réseau du paquet.
Le respect de ces conditions ne permet pas nécessairement aux nœuds intermédiaires d'identifier le protocole de la couche réseau d'un paquet. Dans des conditions ordinaires, ce n'est pas nécessaire, mais il existe des conditions d'erreur dans lesquelles cela est souhaitable. Par exemple, si un LSR intermédiaire détermine qu'un paquet étiqueté n'est pas livrable, il peut être souhaitable pour ce LSR de générer des messages d'erreur spécifiques à la couche réseau du paquet. Le seul moyen dont dispose le LSR intermédiaire pour identifier la couche réseau est l'inspection de l'étiquette supérieure et de l'en-tête de la couche réseau. Donc, si les nœuds intermédiaires doivent pouvoir générer des messages d'erreur spécifiques au protocole pour les paquets étiquetés, toutes les étiquettes de la pile doivent répondre aux critères spécifiés ci-dessus pour les étiquettes qui apparaissent au bas de la pile.
Si un paquet ne peut pas être transmis pour une raison quelconque (par exemple, il dépasse le MTU de la liaison de données), et que son protocole de couche réseau ne peut pas être identifié, ou qu'il n'y a pas de règles spécifiques au protocole pour gérer la condition d'erreur, alors le paquet DOIT être rejeté silencieusement.
2.3. Génération de messages ICMP pour les paquets IP étiquetés
La section 2.4 et la section 3 discutent des situations dans lesquelles il est souhaitable de générer des messages ICMP pour les paquets IP étiquetés. Pour qu'un LSR particulier puisse générer un paquet ICMP et faire envoyer ce paquet à la source du paquet IP, deux conditions doivent être remplies :
1. il doit être possible pour ce LSR de déterminer qu'un paquet étiqueté particulier est un paquet IP ;
2. il doit être possible pour ce LSR de router vers l'adresse IP source du paquet.
La condition 1 est discutée dans la section 2.2. Les deux sous-sections suivantes discutent de la condition 2. Cependant, il y aura des cas où la condition 2 ne tient pas du tout, et dans ces cas, il ne sera pas possible de générer le message ICMP.
2.3.1. Tunneling à travers un domaine de routage de transit
Supposons que l'on utilise MPLS pour "tunneler" à travers un domaine de routage de transit, où les routes externes ne sont pas divulguées dans les routeurs intérieurs du domaine. Par exemple, les routeurs intérieurs peuvent exécuter OSPF et ne savoir comment atteindre que des destinations au sein de ce domaine OSPF. Le domaine peut contenir plusieurs routeurs de bordure de système autonome (ASBR), qui parlent BGP entre eux. Cependant, dans cet exemple, les routes de BGP ne sont pas distribuées dans OSPF, et les LSR qui ne sont pas des ASBR n'exécutent pas BGP.
Dans cet exemple, seul un ASBR saura comment router vers la source d'un paquet arbitraire. Si un routeur intérieur doit envoyer un message ICMP à la source d'un paquet IP, il ne saura pas comment router le message ICMP.
Une solution consiste à faire injecter par un ou plusieurs des ASBR une route "par défaut" dans l'IGP. (N.B. : cela NE nécessite PAS qu'il y ait une route "par défaut" transportée par BGP.) Cela garantirait alors que tout paquet non étiqueté qui doit quitter le domaine (tel qu'un paquet ICMP) soit envoyé à un routeur qui dispose d'informations de routage complètes. Les routeurs disposant d'informations de routage complètes étiquetteront les paquets avant de les renvoyer à travers le domaine de transit, de sorte que l'utilisation du routage par défaut au sein du domaine de transit ne provoque aucune boucle.
Cette solution ne fonctionne que pour les paquets qui ont des adresses globalement uniques, et pour les réseaux dans lesquels tous les ASBR ont des informations de routage complètes. La sous-section suivante décrit une solution qui fonctionne lorsque ces conditions ne sont pas remplies.
2.3.2. Tunneling d'adresses privées à travers une dorsale publique
Dans certains cas où MPLS est utilisé pour tunneler à travers un domaine de routage, il peut ne pas être possible de router vers l'adresse source d'un paquet fragmenté du tout. Ce serait le cas, par exemple, si les adresses IP transportées dans le paquet étaient des adresses privées (c'est-à-dire non globalement uniques), et que MPLS était utilisé pour tunneler ces paquets à travers une dorsale publique. Le routage par défaut vers un ASBR ne fonctionnera pas dans cet environnement.
Dans cet environnement, afin d'envoyer un message ICMP à la source d'un paquet, on peut copier la pile d'étiquettes du paquet d'origine vers le message ICMP, puis commuter par étiquette le message ICMP. Cela fera avancer le message dans la direction de la destination du paquet d'origine, plutôt que vers sa source. À moins que le message ne soit commuté par étiquette jusqu'à l'hôte de destination, il finira, non étiqueté, dans un routeur qui sait comment router vers la source du paquet d'origine, point auquel le message sera envoyé dans la bonne direction.
Cette technique peut être très utile si le message ICMP est un message "Time Exceeded" ou un message "Destination Unreachable because fragmentation needed and DF set".
Lors de la copie de la pile d'étiquettes du paquet d'origine vers le message ICMP, les valeurs des étiquettes doivent être copiées exactement, mais les valeurs TTL dans la pile d'étiquettes doivent être définies sur la valeur TTL qui est placée dans l'en-tête IP du message ICMP. Cette valeur TTL doit être suffisamment longue pour permettre l'itinéraire détourné que le message ICMP devra suivre.
Notez que si l'expiration du TTL d'un paquet est due à la présence d'une boucle de routage, alors si cette technique est utilisée, le message ICMP peut également boucler. Puisqu'un message ICMP n'est jamais envoyé à la suite de la réception d'un message ICMP, et puisque de nombreuses implémentations limitent le taux auquel les messages ICMP peuvent être générés, cela ne devrait pas poser de problème.
2.4. Traitement du champ Time to Live (TTL)
2.4.1. Définitions
Le "TTL entrant" d'un paquet étiqueté est défini comme la valeur du champ TTL de l'entrée supérieure de la pile d'étiquettes lorsque le paquet est reçu.
Le "TTL sortant" d'un paquet étiqueté est défini comme le plus grand des deux :
a) un de moins que le TTL entrant,
b) zéro.
2.4.2. Règles indépendantes du protocole
Si le TTL sortant d'un paquet étiqueté est 0, alors le paquet étiqueté NE DOIT PAS être transmis plus loin ; la pile d'étiquettes ne peut pas non plus être retirée et le paquet transmis en tant que paquet non étiqueté. La durée de vie du paquet dans le réseau est considérée comme ayant expiré.
Selon la valeur de l'étiquette dans l'entrée de la pile d'étiquettes, le paquet PEUT être simplement rejeté, ou il peut être transmis à la couche réseau "ordinaire" appropriée pour le traitement des erreurs (par exemple, pour la génération d'un message d'erreur ICMP, voir la section 2.3).
Lorsqu'un paquet étiqueté est transmis, le champ TTL de l'entrée de la pile d'étiquettes au sommet de la pile d'étiquettes DOIT être défini sur la valeur TTL sortante.
Notez que la valeur TTL sortante est uniquement fonction de la valeur TTL entrante, et est indépendante du fait que des étiquettes soient poussées ou extraites avant la transmission. Il n'y a aucune signification à la valeur du champ TTL dans une entrée de pile d'étiquettes qui n'est pas au sommet de la pile.
2.4.3. Règles dépendantes d'IP
Nous définissons le champ "IP TTL" comme la valeur du champ TTL IPv4, ou la valeur du champ Hop Limit IPv6, selon le cas.
Lorsqu'un paquet IP est étiqueté pour la première fois, le champ TTL de l'entrée de la pile d'étiquettes DOIT ÊTRE défini sur la valeur du champ IP TTL. (Si le champ IP TTL doit être décrémenté, dans le cadre du traitement IP, il est supposé que cela a déjà été fait.)
Lorsqu'une étiquette est extraite, et que la pile d'étiquettes résultante est vide, alors la valeur du champ IP TTL DEVRAIT ÊTRE remplacée par la valeur TTL sortante, telle que définie ci-dessus. Dans IPv4, cela nécessite également la modification de la somme de contrôle de l'en-tête IP.
Il est reconnu qu'il peut y avoir des situations où une administration réseau préfère décrémenter le TTL IPv4 de un lorsqu'il traverse un domaine MPLS, au lieu de décrémenter le TTL IPv4 du nombre de sauts LSP au sein du domaine.
2.4.4. Traduction entre différentes encapsulations
Parfois, un LSR peut recevoir un paquet étiqueté sur, par exemple, une interface ATM contrôlée par commutation d'étiquettes (LC-ATM) [9], et peut avoir besoin de l'envoyer sur une liaison PPP ou LAN. Alors le paquet entrant ne sera pas reçu en utilisant l'encapsulation spécifiée dans ce document, mais le paquet sortant sera envoyé en utilisant l'encapsulation spécifiée dans ce document.
Dans ce cas, la valeur du "TTL entrant" est déterminée par les procédures utilisées pour transporter les paquets étiquetés sur, par exemple, les interfaces LC-ATM. Le traitement du TTL se poursuit ensuite comme décrit ci-dessus.
Parfois, un LSR peut recevoir un paquet étiqueté sur une liaison PPP ou LAN, et peut avoir besoin de l'envoyer sur, disons, une interface LC-ATM. Alors le paquet entrant sera reçu en utilisant l'encapsulation spécifiée dans ce document, mais le paquet sortant ne sera pas envoyé en utilisant l'encapsulation spécifiée dans ce document. Dans ce cas, la procédure pour transporter la valeur du "TTL sortant" est déterminée par les procédures utilisées pour transporter les paquets étiquetés sur, par exemple, les interfaces LC-ATM.