---

We need Your Support. Make a Donation now! or

---

Option d'alerte des routeurs IP

Résumé

Le présent mémoire décrit un nouveau type d'option IP qui alerte les routeurs de transit pour qu'ils examinent de plus près le contenu d'un paquet IP. Ceci est utile, sans leur être limité, pour de nouveaux protocoles qui sont adressés à une destination mais exigent un traitement relativement complexe dans les routeurs le long du chemin.

1.0   Introduction

Une tendance récente des protocoles d'acheminement est de coupler de façon lâche de nouvelles fonctionnalités d'acheminement à un acheminement en envoi individuel existant. La motivation en est simple et élégante – cela permet le déploiement de nouvelles fonctionnalités d'acheminement sans avoir à réinventer toutes les fonctions de base de protocole d'acheminement, réduisant largement la complexité des spécifications et des mises en œuvre.

La contrepartie de cela est que la nouvelle fonctionnalité ne peut alors dépendre que du plus petit dénominateur commun dans l'acheminement en envoi individuel, le prochain bons vers la destination. Aucune hypothèse ne peut être faite sur l'existence d'une information plus détaillée (comme celle d'une base de données d'état de liaison).

Il est aussi souhaitable d'être capable de déployer graduellement la nouvelle technologie, spécifiquement pour éviter d'avoir à mettre à niveau tous les routeurs sur le chemin entre la source et la destination. Cet objectif est quelque peu malmené avec le lus petit dénominateur commun des informations disponibles, car un routeur qui n'est pas immédiatement adjacent à un autre routeur qui prend en charge le nouveau protocole n'a aucun moyen de déterminer la localisation ou l'identité de ces autres routeurs (sauf si quelque chose comme un algorithme d'arrosage est mis en œuvre sur la transmission en envoi individuel, ce qui est en conflit avec l'objectif de simplicité).

Une approche évidente pour contrebalancer l'envoi individuel est de faire une transmission bond par bond des paquets du nouveau protocole le long du chemin vers la destination ultime. Chaque système qui met en œuvre le nouveau protocole serait responsable de l'adressage du paquet au prochain système qui le comprend sur le chemin. Comme noté ci-dessus, cependant, il est difficile de savoir quel est le prochain système qui met en œuvre le protocole. Le cas simple qui en découle est de supposer que chaque système le long du chemin met en œuvre le protocole. C'est néanmoins une barrière à un développement harmonieux du nouveau protocole.

RSVP [1] affine le problème en mettant plutôt l'adresse de la destination ultime dans le champ Adresse de destination IP, puis en demandant que chaque routeur RSVP fasse un "petit changement dans son ... chemin de transmission" pour chercher le type spécifique de paquet RSVP, sortir de tels paquets du chemin de transmission principal, et effectuer un traitement local sur les paquets avant de les transmettre. Ceci a l'avantage décisif de permettre le tunnelage automatique à travers les routeurs qui ne comprennent pas RSVP, car les paquets vont naturellement s'écouler vers la destination ultime. Cependant, le coût en performance de ce Petit Changement peut être inacceptable, dans la mesure où le chemin de transmission principal des routeurs a tendance à être réglé avec précision – même l'ajout d'une seule instruction peut pénaliser des centaines de paquets par seconde dans leurs performances.

2.   Option d'alerte de routeur

Le but est alors de fournir un mécanisme par lequel les routeurs puissent intercepter les paquets qui ne leur sont pas directement adressés, sans subir de pénalisation significative des performances. Le présent document définit un nouveau type d'option IP, Alerte de routeur, à cette fin.

L'option Alerte de routeur a comme sémantique "les routeurs devraient examiner ce paquet de plus près". En incluant l'option Alerte de routeur dans l'en-tête IP de son message de protocole, RSVP peut causer l'interception du message tout en ne causant que peu de pénalité de performance sur la transmission des paquets de données normaux.

Les routeurs qui prennent en charge le traitement de l'option dans le chemin rapide démultiplexent déjà le traitement sur la base du champ de type d'option. Si tous les types d'option sont pris en charge dans le chemin rapide, l'ajout d'un autre type d'option à traiter a alors peu de chances d'avoir un impact sur les performances. Si certains types d'option ne sont pas pris en charge dans le chemin rapide, ce nouveau type d'option ne sera pas reconnu et fera que les paquets qui le portent seront éjectés sur le chemin lent, et donc aucun changement n'est nécessaire pour le chemin rapide, et aucune pénalité de performance ne sera subie par les paquets de données réguliers.

Les routeurs qui ne prennent pas en charge le traitement d'option dans le chemin rapide seront cause que les paquets qui portent cette nouvelle option seront transmis par le chemin lent, de sorte qu'aucun changement au chemin rapide n'est nécessaire et qu'aucune pénalité de performance ne sera subie par les paquets de données réguliers.

2.1   Syntaxe

L'option Alerte de routeur a le format suivant :

+--------+--------+--------+--------+

|10010100|00000100| valeur 2 octets |

+--------+--------+--------+--------+

Type :

Fanion copié : 1 (tous les fragments doivent porter l'option)

Classe d'option : 0 (contrôle)

Numéro d'option : 20 (décimal)

Longueur : 4

Valeur : Un code de deux octets avec les valeurs suivantes :

0 – Le routeur devra examiner le paquet

1 à 65535 - réservé

2.2   Sémantique

Les hôtes doivent ignorer cette option. Les routeurs qui ne reconnaissent pas cette option devront l'ignorer. Les routeurs qui reconnaissent cette option devront examiner avec plus d'attention les paquets qui la portent (vérifier le champ Protocole IP, par exemple) pour déterminer si un traitement ultérieur est ou non nécessaire. Les champs de valeurs non reconnus devront être ignorés en silence. La sémantique des autres valeurs dans le champ Value fera l'objet d'études ultérieures.

3.   Impact sur les autres protocoles

Pour que cette option soit efficace, son utilisation doit être obligatoire dans les protocoles qui attendent des routeurs qu'ils effectuent un traitement significatif sur les paquets qui ne leurs sont pas directement adressés. Ces protocoles sont actuellement RSVP [1] et IGMP [2].

4.   Considérations pour la sécurité

Si l'option Alerte de routeur n'est pas mise alors qu'elle devrait être mise, le comportement du protocole utilisant l'alerte de routeur, par exemple, RSVP ou IGMPv2, sera affecté dans la mesure où le protocole s'appuie sur l'utilisation de l'option Alerte de routeur.

Si l'option Alerte de routeur est mise alors qu'elle ne devrait pas être mise, il est vraisemblable que le flux va subir une pénalité de performance, car un paquet dont l'option Alerte de routeur est mise ne passera pas par le chemin rapide du routeur et sera traité plus lentement dans le routeur que si l'option n'avait pas été mise.

5.   Références

[1]   R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle" RFC2205, septembre 1997. (MàJ parRFC2750, RFC3936, RFC4495) (P.S.)

[2]   W. Fenner, "Protocole de gestion de groupe Internet, version 2" RFC2236, novembre 1997.

Adresse de l'auteur

Dave Katz

cisco Systems

170 W. Tasman Dr.

San Jose, CA 95134-1706 USA

téléphone : +1 408 526 8284

mél : dkatz@cisco.com