Protocole d'acheminement en diffusion groupée par vecteur de distance

1.   Statut de ce mémoire

La présente RFC décrit un protocole d'acheminement par vecteur de distance pour l'acheminement des datagrammes de diffusion groupée à travers un internet. Il est dérivé du protocole d'informations d'acheminement (RIP, Routing Information Protocol) [1], et met en œuvre la diffusion groupée telle que décrite dans la RFC-1054. C'est un protocole expérimental, et sa mise en œuvre n'est pas recommandée pour l'instant. La distribution du présent mémoire n'est soumise à aucune restriction.

2.   Introduction

Il existe maintenant un projet de norme pour la diffusion groupée sur les réseaux IP [2], mais aucun protocole d'acheminement pour la prise en charge de la diffusion groupée inter réseau n'est disponible. Le présent mémoire décrit un protocole d'acheminement expérimental, appelé DVMRP, qui met en œuvre la diffusion groupée inter réseaux. DVMRP combine plusieurs des caractéristiques de RIP [1] avec l'algorithme de diffusion sur le chemin inverse tronqué (TRPB, Truncated Reverse Path Broadcasting) décrit par Deering [3].

DVMRP est un "protocole de passerelle intérieure" ; convenable pour être utilisé au sein d'un système autonome, mais pas entre différents systèmes autonomes. DVMRP n'est actuellement pas développé pour une utilisation dans l'acheminement de datagrammes qui ne seraient pas en diffusion groupée, de sorte que un routeur qui achemine à la fois des datagrammes en diffusion groupée et en envoi individuel doit faire fonctionner deux processus d'acheminement séparés. DVMRP est conçu pour être facilement extensible et pourrait être étendu pour acheminer des datagrammes en envoi individuel.

DVMRP a été développé pour être expérimenté avec les algorithmes de [3]. RIP était utilisé comme point de départ du développement parce qu'une mise en œuvre était disponible et que les algorithmes de vecteur de distance sont simples, comparés aux algorithmes d'état de liaison [4]. De plus, pour permettre aux expériences de traverser les réseaux qui ne prennent pas en charge la diffusion groupée, un mécanisme appelé "tunnelage" a été développé.

L'algorithme de transmission en diffusion groupée exige la construction d'arbres fondés sur les informations d'acheminement. Cette construction d'arbres exige plus d'informations d'état que RIP n'est conçu pour fournir, de sorte que DVMRP est plus compliqué que RIP à certains endroits. Un algorithme d'état de liaison, qui gère la plupart des états nécessaires peut être une meilleure base pour l'acheminement et la transmission de la diffusion groupée sur Internet.

DVMRP diffère de RIP d'une façon très importante. RIP pense en termes d'acheminement et transmission de datagrammes à une destination particulière. L'objet de DVMRP est de garder trace des chemins de retour à la source des datagrammes de diffusion groupée. Pour rendre l'explication de DVMRP plus cohérente avec RIP, le mot "destination" est utilisé à la place de "source" plus approprié, mais le lecteur doit se souvenir que les datagrammes ne sont pas transmis à ces destinations, mais générés à partir d'elles.

Le présent mémoire est organisé selon les sections suivantes :

- Présentation de la description de DVMRP.

- Explication des tunnels.

- Exposé de l'algorithme d'acheminement.

- Exposé de l'algorithme de transmission.

- Liste des diverses valeurs temporelles.

- Spécification des informations de configuration.

Le présent mémoire n'analyse pas l'acheminement par vecteur de distance, ni n'explique en détail l'algorithme de vecteur de distance ; voir en [1] des informations complémentaires sur ces sujets. Le ou les processus qui effectuent les fonctions d'acheminement et de transmissions sont appelés "routeurs" dans le présent mémoire.

3.   Description du protocole

DVMRP utilise le protocole de gestion de groupe Internet (IGMP, Internet Group Management Protocol) pour échanger les datagrammes d'acheminement [2].

Les datagrammes DVMRP sont composés de deux portions : un petit en-tête IGMP de longueur fixe, et un flux de données étiquetées.

L'en-tête IGMP de longueur fixe des messages DVMRP est :

 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

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

|Version|  Type |   Sous-type   |      Somme de contrôle        |

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

La version est 1.

Le type pour DVMRP est 3.

Le sous-type est un des suivants :

1 = Réponse ; le message fournit des chemins pour certaines destinations.

2 = Demande ; le message demande des chemins pour certaines destinations.

3 = Rapport de non-adhésion ; le message fournit un ou des rapports de non-adhésion.

4 = Annulation de non-adhésion ; le message annule un ou des rapports de non-adhésion précédents.

La somme de contrôle est le complément à un sur 16 bits de la somme des compléments à un du message entier, à l'exclusion de l'en-tête IP. Pour calculer la somme de contrôle, le champ Somme de contrôle est mis à zéro.

Le reste du message DVMRP est un flux de données étiquetées. La raison de l'utilisation d'un flux de données étiquetées est de fournir un moyen d'extension facile (de nouvelles commandes peuvent être développées en ajoutant de nouvelles étiquettes) et de réduire la quantité de données redondantes dans un message. Les éléments du flux, appelés commandes, sont des multiples de 16 bits, pour un verrouillage commode. Les commandes sont organisées selon un code numérique de commandes de huit bits, avec au moins une portion de données de huit bits. L'alignement de toutes les commandes sur seize bits est exigé.

Un message qui a une erreur sera éliminé au point de traitement où l'erreur est détectée. Aucun changement d'état dû au contenu du message avant l'erreur ne sera restauré à sa valeur précédente.

Certaines commandes ont des valeurs par défaut définies dans leur spécification. Comme les valeurs par défaut peuvent être changées lors de développements ultérieurs du protocole, une mise en œuvre prudente n'enverra pas de messages qui dépendent des valeurs par défaut.

La longueur des messages DVMRP est limitée à 512 octets, à l'exclusion de l'en-tête IP.

3.1   Commande NUL

Format :   0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

          |       0       |   |     Ignoré    |

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

Description : La commande NUL peut être utilisée pour fournir un alignement supplémentaire ou un bourrage à 32 bits.

3.2   Commande Indicateur de famille d'adresse (AFI)

Format :   0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

          |      2        |   |    famille    |

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

Valeurs pour famille :

2 = famille d'adresse IP, dans laquelle les adresses ont 32 bits.

Par défaut : famille = 2.

Description : La commande AFI fournit la famille d'adresse pour les adresses suivantes dans le flux (jusqu'à ce qu'une commande AFI différente soit donnée).

C'est une erreur si le receveur ne prend pas en charge la famille d'adresse.

3.3   Commande Gabarit-sous-réseau

Format :   0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

          |       3       |   |      compte   |

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

Argument supplémentaire, avec AFI = IP:

 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

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

|                Gabarit de sous-réseau                         |

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

Le compte est 0 ou 1.

Par défaut : On suppose que les chemins suivants sont pour des réseaux, et on utilise comme gabarit le gabarit de réseau pour chaque destination de chemin.

Description : La commande Gabarit de sous-réseau donne le gabarit du sous-réseau à utiliser pour les chemins suivants. Il y a des exigences sur les bits du gabarit de sous-réseau : les bits 0 à 7 doivent être 1, et tous les autres bits doivent être 0.

Si le compte est 0, aucun gabarit de sous-réseau ne s'applique, on suppose que les chemins suivants sont pour des réseaux, et on utilise le gabarit du réseau pour chacune des destination du chemin. Si le compte est 1, un gabarit de sous-réseau devrait être dans le flux des données, d'une taille appropriée données par la famille d'adresse.

C'est une erreur si le compte n'est pas égal à 0 ou 1.

Les gabarits de sous-réseau ne devraient pas être envoyés en dehors du réseau approprié.

Voir en [6] des informations complémentaires sur les sous-réseaux IP.

3.4   Commande Métrique

Format :   0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

          |      4        |   |     valeur    |

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

Valeur est la métrique, sous forme d'un entier non signé de 1 à 255.

Par défaut : aucune

Description : La commande métrique fournit la métrique de la destinations suivante. La métrique se rapporte au routeur qui envoie cette mise à jour d'acheminement DVMRP.

C'est une erreur que métrique soit égale à 0.

3.5   Commande Flags0

Format :  0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

         |      5        |   |     valeur    |

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

Signification des bits dans valeur :

Bit 7 : La destination est injoignable.

Bit 6 : L'horizon partagé dissimule le chemin.

Par défaut : Tous les bits à zéro.

Description : La commande flags0 fournit un moyen d'établir un certain nombre de fanions. Les seuls fanions définis, les bits 6 et 7, peuvent être utilisés pour fournir plus d'informations sur un chemin avec une métrique de infini. Un routeur qui reçoit un fanion qu'il ne prend pas en charge devrait l'ignorer. La commande est appelée flags0 pour permettre la définition de commandes de fanion supplémentaires à l'avenir (flags1, etc.).

C'est une commande expérimentale, et elle pourrait être changée à l'avenir.

3.6   Commande Infini

Format :  0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

         |       6       |   |    valeur     |

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

La valeur est l'infini, sous forme d'un entier non signé de 1 à 255.

Par défaut : valeur = 16.

Description : La commande infini définit l'infini pour les métriques suivantes du flux.

C'est une erreur que infini soit zéro, ou moins que la métrique actuelle.

3.7   Commande Adresse de destination (DA)

Format :  0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

         |        7      |   |    compte     |

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

Matrice d'argument supplémentaires de "compte", avec AFI = IP:

 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

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

|              Adresse de destination 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

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

|               Adresse de destination 2                        |

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

Compte est le nombre d'adresses fournies, de 1 à 255. La longueur des adresses dépend de la famille d'adresse en cours. Le nombre d'adresses fournies est soumis à la limitation à 512 octets de la longueur du message.

Par défaut : aucune.

Description : La commande DA donne une liste de destinations. Bien que ce format puisse exprimer des chemins vers des hôtes, l'algorithme d'acheminement ne prend en charge que des acheminements de réseau et de sous-réseaux. La métrique courante, infini, flags0 et gabarit de sous-réseau, lorsque elle est combinée avec une seule adresse de destination, définit un chemin. La métrique courante doit être inférieure ou égale à l'infini en cours.

C'est une erreur que compte soit égal à 0.

3.8   Commande Adresse de destination demandée (RDA)

Format :  0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

         |        8      |   |    compte     |

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

Dispositif d'arguments supplémentaires "compte" avec AFI = IP :

 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

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

|             Adresse de destination demandée 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

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

|            Adresse de destination demandée 2                  |

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

Compte est le nombre d'adresses fournies, de 0 à 255. La longueur des adresses dépend de la famille d'adresse actuelle. Le nombre d'adresses fournies dépend de la limitation de longueur de message de 512 octets.

Par défaut : Aucune.

Description : La commande RDA donne une liste de destinations pour lesquelles des chemins sont demandés. Une demande d'acheminement pour toutes les routes est codée en utilisant un compte = 0.

3.9   Commande Rapport de non adhésion (NMR)

Format :  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7

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

         |      9        |  |    compte     |

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

Dispositif d'arguments supplémentaires de "compte", avec AFI = IP :

 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

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

|          Adresse de diffusion groupée 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

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

|       Temps de garde 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

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

|               Adresse de diffusion groupée 2                  |

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

 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

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

|        Temps de garde 2                                       |

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

Compte est le nombre de paires Adresse de diffusion groupée et Temps de garde fournies, de 1 à 255. La longueur des adresses dépend de la famille d'adresse en cours. Le nombre DVMRP de paires fournies dépend de la limitation de longueur de message de 512 octets.

Par défaut : Aucune.

Description : La commande NMR est expérimentale, et n'a encore été essayée dans aucune mise en œuvre. Chaque paire Adresse de diffusion groupée et Temps de garde est appelée un rapport de non adhésion. Le rapport de non adhésion dit au routeur qui reçoit que le routeur d'envoi n'a pas de descendant membre du groupe dans le groupe donné. Sur la base de ces informations, le routeur qui reçoit peut arrêter de transmettre des datagrammes au routeur d'envoi pour la ou les adresses de diffusion groupée particulières de la liste. Le temps de garde indique, en secondes, pendant combien de temps le NMR est valide.

C'est une erreur que compte soit égal à 0.

Les seules autres commandes dans un message qui a la commande NMR peuvent être AFI, flags0, et NUL. Aucun fanion pertinent pour la commande flags0 n'est actuellement défini, mais cela pourra changer à l'avenir.

3.10   Commande Annuler le rapport de non adhésion (Annuler-NMR)

Format : 0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7

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

        |      10       |   |     compte    |

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

Dispositif d'arguments supplémentaires de "compte", avec AFI = IP :

 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

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

|           Adresse de diffusion groupée 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

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

|        Adresse de diffusion groupée 2                         |

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

Compte est le nombre d'adresses de diffusion groupées fournies, de 1 à 255. La longueur des adresses dépend de la famille d'adresse actuelle. Le nombre des adresses fournies dépend de la limitation de longueur de message de 512 octets.

Par défaut : Aucune.

Description : La commande Annuler NMR est expérimentale, et n'a pas été essayée par une mise en œuvre. Pour chaque adresse de diffusion groupée de la liste, tout rapport antérieur correspondant de non adhésion est annulé. Lorsque il n'y a pas de rapport de non adhésion correspondant pour une adresse de diffusion groupée données, la commande Annuler devrait être ignorée pour cette adresse de diffusion groupée.

C'est une erreur qu compte soit égal à 0.

Les seules autres commandes d'un message qui a la commande Annuler NMR peuvent être AFI, flags0, et NULL. Aucun fanion pertinent pour la commande flags0 n'est actuellement défini, mais cela pourra changer à l'avenir.

(Ne cherchez pas le 3.11, il n'existe pas non plus dans la version anglaise)

3.12   Exemples (avec les octets entre '{}'), n'incluant pas l'en-tête de message :

3.12.1  

Fourniture d'une seule route pour l'adresse IP 128.2.251.231 avec une métrique de 2, un infini de 16, un gabarit de sous-réseau de 255.255.255.0 :

Sous-type 1, AFI 2, métrique 2, infini 16, gabarit de sous-réseau 255.255.255.0

{2} {2} {4} {2} {6} {16} {3} {1} {255} {255} {255} {0}

Compte DA = 1 [128.2.251.231] {7} {1} {128} {2} {251} {231}

3.12.2  

Fourniture d'un chemin pour les adresses IP 128.2.251.231 et 128.2.236.2 avec une métrique de 2, un infini de 16, un sous-réseau de 255.255.255.0 :

Sous-type 1, AFI 2, métrique 2, infini 16, gabarit de sous-réseau 255.255.255.0

{2} {2} {4} {2} {6} {16} {3} {1} 255} {255} {255} {0}

Compte DA = 2 [128.2.251.231] [128.2.236.2]

{7} {1} {128} {2} {251} {231} {128} {2} {236} {2}

3.12.3   Demande de tous les chemins pour les destinations IP

Sous-type 2, AFI 2, Compte RDA = 0

{2} {2} {8} {0}

3.12.4  

Rapport de non adhésion pour les groupes 224.2.3.1 et 224.5.4.6 avec un temps de garde de 20 secondes, et le groupe 224.7.8.5 avec un temps de garde de 40 secondes.

Sous-type 3,

AFI 2, compte NMR = 3 [224.2.3.1, 20]

{2} {2} {10} {3} {224} {2} {3} {1} {0} {0} {0} {20}

[224.5.4.6, 20] [224.7.8.5, 40]

{224} {5} {4} {6} {0} {0} {0} {20} {224} {7} {8} {5} {0} {0} {0} {40}

3.13   Résumé des commandes

4.   Tunnels

Un tunnel est une méthode d'envoi des datagrammes entre les routeurs séparés par des passerelles qui ne prennent pas en charge d'acheminement de diffusion groupée. Il agit comme un réseau virtuel entre deux routeurs. Par exemple, un routeur fonctionnant à Stanford, et un routeur fonctionnant à BBN pourraient être connectés avec un tunnel pour permettre à des datagrammes en diffusion groupée de traverser l'Internet. On considère les tunnels comme étant un taxi transitoire.

Le tunnelage est effectué avec un datagramme envoyé en diffusion groupée normale faiblement encapsulé. L'encapsulation faible utilise une route de source IP lâche particulière à deux éléments [5]. (Cette forme d'encapsulation est préférable à l'encapsulation "forte", c'est-à-dire, en ajoutant un en-tête IP complet, parce qu'elle n'exige pas que les points d'extrémité du tunnel connaissent la taille maximum de mémoire tampon de réassemblage l'un de l'autre. Elle a aussi l'avantage du comportement correct de la valeur de la durée de vie du générateur et de toute autre option IP présente.)

Un tunnel a un point d'extrémité local, un point d'extrémité distant, et un seuil associé. Les routeurs de chaque côté du tunnel ont seulement besoin de se mettre d'accord sur les points d'extrémité local et distant. Voir à la section 8 des informations sur la façon de configurer les tunnels. Comme le nombre de passerelles intermédiaires entre les points d'extrémité d'un tunnel n'est pas connu, des recherches complémentaires seront nécessaires pour déterminer la métrique et les seuils appropriés.

Pour envoyer un datagramme sur un tunnel, il se passe ce qui suit :

-   Une option IP Nul est insérée dans le datagramme. Cela donne l'alignement préféré pour l'option Route de source IP lâche.

-   Une option Route de source IP lâche à deux éléments est insérée dans le datagramme.

-   Le pointeur route de source est réglé pour pointer sur le second élément dans la route de source.

-   Le premier élément dans la route de source est remplacé par l'adresse de l'hôte générateur (l'adresse IP originale de source).

-   Le second élément de la route de source est remplacé par l'adresse de diffusion groupée de destination fournie par l'hôte générateur (l'adresse IP originale de destination).

-   L'adresse IP de source est remplacée par l'adresse de l'interface de sortie appropriée du routeur (le point d'extrémité local du tunnel).

-   L'adresse IP de destination est remplacée par une adresse du routeur distant (le point d'extrémité distant du tunnel).

-   Le datagramme est transmis au routeur distant en utilisant des algorithmes d'acheminement en non diffusion groupée.

Les passerelles intermédiaires, non en diffusion groupée vont acheminer le datagramme tunnelé au point d'extrémité distant du tunnel. Comme l'adresse IP de source du datagramme a été remplacée par l'adresse du point d'extrémité local du tunnel, les messages d'erreur ICMP vont aller au routeur de diffusion groupée de l'origine. Ce comportement est désiré, parce qu'un hôte qui envoie un datagramme en diffusion groupée, qu'un routeur de diffusion groupée décide de tunneler, ne devrait pas être au courant de l'utilisation du tunnel. Si l'adresse IP de source du datagramme n'était pas changée lors de l'encapsulation du datagramme, toutes les erreurs ICMP seraient envoyées à l'hôte d'origine.

Lorsque le point d'extrémité distant du tunnel reçoit le datagramme tunnelé, il se produit ce qui suit :

-   L'adresse IP de source est remplacée par le premier élément dans la route de source lâche.

-   L'adresse IP de destination est remplacée par le second élément dans la route de source lâche.

-   L'option Nul et l'option Route de source lâche sont retirées du datagramme. Ceci est nécessaire parce qu'un hôte ne devrait pas être capable de dire qu'il a reçu un datagramme envoyé à travers un tunnel.

Comme aucun réseau spécifique n'est associé à un tunnel, il n'y a pas d'adhésion à un groupe local à retracer pour un tunnel. Le seul voisin sur un tunnel peut être le point d'extrémité distant. Les messages d'acheminement devraient être échangés à travers les tunnels, mais un chemin n'est pas créé pour un tunnel. Les messages d'acheminement devraient être envoyés comme datagrammes en envoi individuel directement au point d'extrémité distant du tunnel ; il ne devraient pas utiliser une route de source IP lâche.

Justification pour l'utilisation de la route de source lâche et de l'option d'enregistrement pour le tunnelage :

Nous avons envisagé de définir nos propres options IP pour traiter le tunnelage, mais nous étions préoccupés par le fait que les passerelles intermédiaires ne passent pas de façon transparente les options IP qu'elles ne connaissent pas. Les datagrammes qui utilisent une nouvelle option ne traverseraient pas l'Internet. Il serait meilleur de pouvoir créer une nouvelle option IP, mais cela ne fonctionne pas actuellement. Il faut se souvenir que ceci est un concept transitoire pour nous permettre de faire des expériences dans l'environnement actuel.

Le paquet tunnelé contenant l'option LSRR a les caractéristiques suivantes :

Deux questions se posent à propos de l'utilisation de l'option LSRR pour les tunnels qui sont "les passerelles intermédiaires peuvent elles ignorer l'option ?" et "la passerelle de destination peut-elle détecter correctement que LSRR est utilisé pour un tunnel ?"

Lorsque une passerelle intermédiaire reçoit un datagramme, elle examine l'adresse de destination. Pour un datagramme tunnelé, l'adresse de destination ne va pas correspondre à une adresse de la passerelle receveuse. Donc, l'option LSRR ne sera pas examinée, et la passerelle intermédiaire va transmettre le datagramme à son prochain bond vers l'adresse de destination.

Lorsque la passerelle de destination reçoit un datagramme, elle note que l'adresse de destination du datagramme correspond à une de ses propres adresses. Elle va ensuite chercher l'adresse de la prochaine option LSRR, car la route de source n'est pas épuisée. Cette adresse est une adresse de diffusion groupée. Comme il est interdit aux hôtes de mettre les adresses de diffusion groupée dans les routes de source, la passerelle peut en déduire que le LSRR est pour un tunnelage. La faiblesse ici est que cela a peut-être une autre signification à l'adresse de diffusion groupée dans le LSRR. Aucune autre signification n'est actuellement définie.

Si un datagramme tunnelé est adressé par erreur à une passerelle de destination qui ne prend pas en charge la diffusion groupée, la passerelle de destination va essayer de trouver un chemin vers l'adresse de diffusion groupée. Cela va échouer, et un message d'erreur ICMP Destination injoignable sera envoyé à la source du datagramme tunnelé. Comme l'adresse de source dans le datagramme tunnelé a été ajustée à l'adresse de la passerelle de diffusion groupée de source, les erreurs ICMP n'iront pas à l'hôte d'origine qui n'a pas connaissance des tunnels.

5.   Algorithme d'acheminement

La présente section donne une brève description de l'algorithme d'acheminement par vecteur de distance. Voir en [1] des informations complémentaires.

Alors que DVMRP peut exprimer des chemins vers des hôtes individuels, les algorithmes de transmission et d'acheminement ne peuvent prendre en charge que des acheminements de réseau et de sous-réseau.

Dans l'exposé ci-dessous, le terme "interface virtuelle" est utilisé pour se référer à une interface physique ou à un point d'extrémité local de tunnel. Une interface physique est une interface réseau, par exemple, une carte Ethernet. Une route pour une destination sera à travers une interface virtuelle. Le terme "réseau virtuel" est utilisé pour se référer à un réseau physique ou à un tunnel, avec la qualification que les chemins ne se réfèrent qu'aux réseaux physiques.

L'algorithme TRPB transmet des datagrammes de diffusion groupée en calculant l'arbre de plus court chemin (inverse) du réseau source (physique) à tous les receveurs possibles du datagramme. Chaque routeur de diffusion groupée doit déterminer sa place dans l'arbre, par rapport à la source particulière, puis déterminer lesquelles de ces interfaces virtuelles sont sur l'arbre des plus courts chemins. Le datagramme est transmis sur ces interfaces virtuelles. Le processus d'exclusion des interfaces virtuelles qui ne sont pas sur l'arbre des plus courts chemins s'appelle "élagage" (pruning).

Considérons un réseau virtuel. En utilisant la terminologie de Deering [3], un routeur est appelé le "parent" du réseau virtuel si il est responsable de la transmission des datagrammes sur ce réseau virtuel à travers son interface virtuelle de connexion. Le réseau virtuel peut aussi être considéré comme un réseau virtuel "fils" du routeur. En utilisant les informations de fils, les routeurs peuvent faire de la diffusion sur chemin inverse (RPB, Reverse Path Broadcasting).

Des datagrammes inutiles peuvent encore être envoyés sur certains réseaux, parce qu'il peut n'y avoir aucun receveur pour ces datagrammes sur les réseaux. Il a y deux sortes de receveurs : des hôtes qui sont membres d'un groupe de diffusion groupée particulier, et des routeurs de diffusion groupée. Si aucun routeur de diffusion groupée sur un réseau virtuel ne considère qu'un réseau virtuel remonte vers une source donnée, ce réseau virtuel est un réseau "feuille". Si un réseau est une feuille pour une source donnée, et si il n'y a pas de membre d'un groupe particulier sur le réseau, il n'y a alors aucun receveur pour les datagrammes provenant de la source pour le groupe sur ce réseau. Ce routeur parent du réseau peut s'abstenir d'envoyer ces datagrammes sur ce réseau, ou "tronquer" l'arbre des plus courts chemins. L'algorithme qui traque et utilise ces informations est l'algorithme de diffusion de chemin inverse tronqué (TRPB, Truncated Reverse Path Broadcasting).

Déterminer quels réseaux virtuels sont des feuilles n'est pas simple. Si un routeur voisin considère un réseau virtuel donné sur le chemin vers une destination donnée, le réseau virtuel n'est alors pas une feuille. Autrement, c'est une feuille. C'est une fonction de choix. Si un chemin, avec une métrique empoisonnée par un processus d'horizon partagé, est envoyé par un routeur, ce routeur utilise alors ce réseau virtuel comme le chemin montant pour cette route (c'est-à-dire que ce routeur choisit de dire que ce réseau virtuel n'est pas une feuille par rapport à la destination du chemin). Comme le nombre de routeurs sur un réseau virtuel est dynamique, et comme toutes les mises à jour d'acheminement reçues ne sont pas conservées par les routeurs, une heuristique est nécessaire pour déterminer quand un réseau est une feuille. DVMRP échantillonne les mises à jour d'acheminement sur une interface virtuelle lorsque fonctionne un temporisateur de garde, qui dure pendant LEAF_TIMEOUT secondes. Il y a un temporisateur de garde par interface virtuelle. Si un chemin est reçu avec une métrique empoisonnée par un traitement d'horizon partagé alors que le temporisateur de garde fonctionne ou à tout autre moment, l'interface virtuelle appropriée pour ce chemin est "gâchée" – ce n'est pas une feuille. Pour chaque chemin, toute interface virtuelle qui n'est pas gâchée dans le délai d'expiration du temporisateur de garde est considérée comme feuille.

Pour une description d'un algorithme de transmission encore meilleur, l'algorithme de diffusion groupée sur chemin inverse (RPM, Reverse Path Multicasting) voir en [3].

Une entrée de chemin doit comporter ce qui suit :

- Adresse de destination (une source de datagrammes de diffusion groupée) *

- Un gabarit de sous-réseau de l'adresse de destination *

- Le routeur du prochain bond vers l'adresse de destination

- L'interface virtuelle vers le routeur du prochain bond *

- La liste des interfaces virtuelles filles *

- La liste des interfaces virtuelles feuilles *

- Une adresse de routeur dominant pour chaque interface virtuelle

- Une adresse de routeur subordonné pour chaque interface virtuelle

- Un temporisateur

- Un jeu de fanions qui indique l'état de l'entrée

- Une métrique

- L'infini

Les lignes qui sont marquées d'une '*' indiquent des champs qui sont directement utilisés par l'algorithme de transmission.

Les listes des interfaces filles et feuilles peuvent être mises en œuvre comme schémas binaires (bitmaps).

5.1   Envoi des messages d'acheminement

Les messages d'acheminement DVMRP peuvent être utilisés pour trois objets de base : pour fournir périodiquement toutes les informations d'acheminement, pour fournir gratuitement les informations d'acheminement sur les chemins récemment changés, ou pour fournir certains ou tous les chemins en réponse à une demande.

Les messages d'acheminement envoyés à des interfaces physiques devraient avoir un TTL IP de 1.

Un certain nombre de temporisations et de rapports sont utilisés par les algorithmes d'acheminement et de transmission. Voir leurs valeurs à la section 6.

Règles sur le moment d'envoi des messages d'acheminement :

-   Toutes les FULL_UPDATE_RATE secondes, un routeur devrait envoyer des messages DVMRP avec toutes ses informations d'acheminement vers toutes ses interfaces virtuelles. Pour empêcher les routeurs de se synchroniser lorsque ils envoient les mises à jour, on doit utiliser un temporisateur en temps réel.

-   Chaque fois qu'un chemin est changé, une mise à jour d'acheminement devrait être envoyé pour ce chemin. Un certain délai doit être respecté entre les déclanchements de mises à jour pour éviter d'inonder le réseau avec des mises à jour déclanchées ; un intervalle de TRIGGERED_UPDATE_RATE secondes est suggéré.

-   Une demande pour tous les chemins devrait être envoyée sur toutes les interfaces virtuelles lorsque un routeur DVMRP est redémarré.

-   Si possible, lorsque un routeur DVMRP est sur le point de terminer l'exécution, il devrait envoyer des messages DVMRP avec une métrique égale à l'infini pour tous ses chemins, sur toutes les interfaces virtuelles.

Lors d'un envoi à des routeurs connectés via des réseaux qui prennent en charge la diffusion groupée, les messages devraient être envoyés à l'adresse 224.0.0.4. Donc, les routeurs doivent écouter l'adresse de diffusion groupée 224.0.0.4 sur toutes interface physique qui accepte la diffusion groupée. Si la diffusion groupée n'est pas acceptée, la diffusion peut être utilisée. Comme déjà mentionné, les mises à jour d'acheminement pour les tunnels devraient être envoyées comme datagrammes d'envoi individuel au point d'extrémité distant du tunnel.

Lors de l'envoi de messages d'acheminement, excepté en réponse à une demande spécifique de chemin (via la commande RDA avec un compte différent de zéro), le traitement d'horizon partagé empoisonné doit être effectué. Cela signifie qu'étant donné un chemin qui utilise le réseau X, les mises à jour d'acheminement envoyées au réseau X doivent inclure ce chemin avec la métrique égale à l'infini et devraient inclure le fanion approprié établi dans la commande FLAGS0.

L'horizon partagé empoisonnée est un moyen de réduire la probabilité de boucles d'acheminement. Une autre méthode, non disponible dans RIP, est de choisir un meilleur infini dans un chemin. Pour les chemins qui se propagent dans un réseau petit, mais bien connecté, un infini plus petit que 16 peut être meilleur. Plus l'infini est petit, moins un événement comptant pour l'infini prendra de temps. En traversant un grand internet, un infini de 16 peut être trop petit. Au prix d'un plus long événement comptant pour l'infini, l'infini peut être augmenté.

Un concept de la diffusion groupée sur Internet est l'utilisation de "seuils" pour mettre des restrictions sur les datagrammes de diffusion groupée qui sortent du réseau. Les routeurs de diffusion groupée sur la bordure d'un réseau organisé en sous-réseaux ou en systèmes autonomes peuvent exiger d'un datagramme qu'il ait un grand TTL pour sortir d'un réseau. Ce mécanisme conserve la plupart des datagrammes de diffusion groupée à l'intérieur du réseau, ce qui réduit le trafic externe. Une application qui veut envoyer en diffusion groupée en dehors de son réseau aura besoin de donner aux datagrammes de diffusion groupée un TTL d'au moins la somme des seuils et de la distance à la bordure du réseau (en supposant que le TTL soit utilisé comme un compte de bonds au sein du réseau). Une option de configuration devrait permettre de spécifier le seuil pour les interfaces physiques et pour les tunnels.

Lorsque un routeur est démarré, il doit envoyer une demande de tous les chemins sur chacune des interfaces virtuelles. La demande est un message qui a une commande RDA avec un compte égal à 0.

5.2   Réception des messages d'acheminement

Un routeur doit savoir sur quelle interface virtuelle est arrivé un message d'acheminement. Comme le message d'acheminement peut être adressé à l'adresse IP "tous-les-routeurs-de-diffusion-groupée", et à cause des tunnels, l'interface entrante ne peut être identifiée simplement en examinant l'adresse de destination IP du message.

Pour chaque chemin exprimé dans un message d'acheminement, il doit survenir ce qui suit :

SI une métrique a été donnée pour le chemin :

ALORS   ajouter dans la métrique de l'interface virtuelle sur laquelle le message est arrivé.

Chercher l'adresse de destination du chemin dans les tableaux d'acheminement.

SI le chemin n'existe pas dans les tableaux :

ALORS   essayer de trouver un chemin pour le même réseau dans les tableaux d'acheminement.

SI ce chemin existe dans les tableaux :

ALORS   SI ce chemin provient du même routeur que le routeur dont le chemin trouvé provient :

ALORS   CONTINUER avec le chemin suivant.

SI le chemin n'a pas une métrique de infini :

ALORS   ajouter le chemin aux tableaux d'acheminement.

CONTINUER avec le chemin suivant.

Si ce chemin provient du même routeur que le routeur dont le chemin trouvé provient :

ALORS   mettre à zéro le temporisateur de chemin.

SI une métrique a été reçue, et si elle est différente de la métrique du chemin trouvé :

ALORS    changer le chemin trouvé pour utiliser la nouvelle métrique et le nouvel infini.

SI la métrique est égale à l'infini :

ALORS   régler le temporisateur de chemin à EXPIRATION_TIMEOUT.

CONTINUER avec le chemin suivant.

SI l'infini reçu n'est pas égal à l'infini du chemin trouvé :

ALORS   changer l'infini du chemin trouvé pour celui de l'infini reçu.

   changer la métrique du chemin trouvé pour le minimum de l'infini reçu et de la métrique du chemin trouvé.

AUTREMENT   SI une métrique a été reçue, et (si elle est inférieure à la métrique du chemin trouvé ou si (le temporisateur du chemin est au moins à moitié chemin de EXPIRATION_TIMEOUT et la métrique du chemin trouvé est égale à la métrique reçue, et la métrique est inférieure à l'infini reçu)) :

ALORS   changer les tableaux d'acheminement pour utiliser le chemin reçu.

   remettre le temporisateur d'acheminement à zéro.

CONTINUER avec le chemin suivant.

5.3   Voisins

On devrait tenir une liste des routeurs de diffusion groupée voisins sur chacun des réseaux rattachés. Les informations peuvent être déduites par les messages d'acheminement DVMRP qui sont reçus. Un voisin qui n'a pas été entendu pendant NEIGHBOR_TIMEOUT secondes devrait être considéré comme mort.

5.4   Adhésion à un groupe local

Comme exigé par [2], un routeur de diffusion groupée doit garder trace des adhésions au groupe sur les réseaux à capacité de diffusion groupée qui lui sont rattachés. Toutes les QUERY_RATE secondes, une demande IGMP d'état des adhésions devrait être envoyée à l'adresse Tous-hôtes-de-diffusion-groupée (224.0.0.1) sur chaque réseau par un routeur désigné sur ce réseau. La demande IGMP de l'état des adhésions va amener les hôtes à répondre par des rapports IGMP d'adhésion après un bref délai. Les hôtes vont envoyer le rapport pour un groupe à l'adresse de diffusion groupée du groupe.

Les demandes d'état d'adhésion devraient avoir un TTL IP de 1.

Les routeurs qui sont sur un réseau choisissent ou "désignent" un seul routeur pour faire les interrogations. Le routeur désigné est le routeur avec la plus petite adresse IP sur ce réseau. Au démarrage, un routeur se considère lui-même comme le routeur désigné jusqu'à ce qu'il apprenne (en principe à travers les messages d'acheminement) qu'un routeur a une plus petite adresse. Pour apprendre l'état de l'adhésion de groupe présente sur un réseau au démarrage, un routeur devrait envoyer en diffusion groupée un certain nombre de demandes d'état d'adhésion, séparés par un bref délai. On suggère l'envoi de trois demandes séparées de quatre secondes.

Le routeur de diffusion groupée doit recevoir tous les datagrammes envoyés à toutes les adresses de diffusion groupée. À réception d'un rapport IGMP d'état des adhésions pour un groupe depuis une interface, il doit soit enregistrer l'existence de ce groupe sur l'interface et enregistrer l'heure, soit mettre à jour l'heure si le groupe est déjà enregistré. Les états d'adhésion de groupe enregistrées doivent subir une temporisation. Si un rapport d'adhésion de groupe n'est pas reçu pour un groupe enregistré après MEMBERSHIP_TIMEOUT secondes, le groupe enregistré devrait être supprimé.

6.   Algorithme de transmission

La présente section décrit l'algorithme de transmission de diffusion groupée et l'état qui doit être conservé pour l'algorithme.

L'algorithme de transmission est appliqué pour déterminer comment les datagrammes de diffusion groupée qui arrivent sur une interface physique ou un tunnel devraient être traités. Si les datagrammes de diffusion groupée étaient en inondation, un datagramme reçu sur une interface virtuelle serait transmis sur chaque autre interface virtuelle. À cause de la redondance des chemins dans l'internet, les datagrammes seraient dupliqués. Les informations de fille et de feuille que fournit l'algorithme d'acheminement sont utilisées pour élaguer les branches de l'arborescence vers toutes destinations possibles.

Dans les entrées de chemins, il y a une adresse de routeur dominant pour chaque interface virtuelle. Cette adresse est celle de certains routeurs qui ont un chemin avec une métrique plus faible (et dont la métrique n'est pas égale à l'infini) vers la destination, sur cette interface virtuelle. L'adresse du routeur dominant n'est pas réglée sur l'interface virtuelle du prochain bond.

Il y a également dans les entrées de chemins une adresse de routeur subordonné pour chaque interface virtuelle. Cette adresse est celle d'un routeur qui considère ce routeur comme le parent du réseau virtuel. Donc, l'adresse du routeur subordonné n'est pas réglée sur une interface virtuelle vers un réseau feuille.

L'algorithme pour manipuler les listes d'entrées de filles et de feuilles est le suivant :

Au démarrage du routeur :

Créer une entrée de chemin pour chaque interface virtuelle, avec :

-   toutes les autres interfaces virtuelles dans sa liste de filles,

-   une liste vide des feuilles,

-   pas d'adresse de routeur dominant,

-   pas d'adresse de routeur subordonné.

Lancer un temporisateur de temps de garde pour chaque interface virtuelle, avec une valeur de LEAF_TIMEOUT.

À réception d'un nouveau chemin :

Créer l'entrée de chemin, avec :

-   toutes les interfaces virtuelles autres que celle sur laquelle le nouveau chemin a été reçu, dans la liste des filles,

-   une liste de feuilles vide,

-   pas d'adresse de routeur dominant,

-   pas d'adresse de routeur subordonné.

Lancer le temporisateur de temps de garde pour toutes les interfaces virtuelles autres que celle sur laquelle a été reçu le nouveau chemin, avec une valeur de LEAF_TIMEOUT.

À réception d'un chemin sur l'interface virtuelle V du voisin N avec une métrique inférieure à celle du tableau d'acheminement (ou la même métrique que celle du tableau d'acheminement si l'adresse de N est inférieure à mon adresse pour V) pour ce chemin :

   Si V est dans la liste des filles, supprimer V de la liste des filles,

   Si il n'y a pas de routeur dominant pour V et si V n'est pas (pour l'instant) l'interface virtuelle de prochain bond, enregistrer N comme routeur dominant.

À réception d'un chemin sur l'interface virtuelle V du voisin N avec une métrique supérieure à celle du tableau d'acheminement (ou la même métrique que celle du tableau d'acheminement si l'adresse de N est supérieure à mon adresse pour V) pour ce chemin :

   Si N est le routeur dominant pour V, supprimer N comme routeur dominant et ajouter V à la liste des filles.

À réception d'un chemin sur l'interface virtuelle V du voisin N avec une métrique égale à l'infini (le fanion d'horizon partagé devrait aussi être établi) pour ce chemin :

   Si V est dans la liste des feuilles, supprimer V de la liste des feuilles.

   Si il n'y a pas de routeur subordonné pour V, enregistrer N comme routeur subordonné.

À réception d'un chemin sur l'interface virtuelle V du voisin N avec une métrique autre que l'infini (et pas de fanion d'horizon partagé) pour ce chemin :

   Si N est le routeur subordonné pour V, supprimer N comme routeur subordonné et lancer le temporisateur de temps de garde pour V.

À expiration du temporisateur pour une interface virtuelle (V) pour chaque chemin :

   Si il n'y a pas de routeur subordonné pour V, ajouter V à la liste des feuilles.

En cas d'échec du voisin N sur l'interface virtuelle V, pour chaque chemin :

   Si N est le routeur dominant pour V, supprimer N comme routeur dominant et ajouter V à la liste des filles.

   Si N est le routeur subordonné pour V, supprimer N comme routeur subordonné et lancer le temporisateur de temps de garde pour V.

L'algorithme de transmission est :

SI le TTL IP est inférieur à 2 :

ALORS   CONTINUER avec le datagramme suivant.

trouver le chemin vers la source du datagramme IP.

Si aucun chemin n'existe :

ALORS   CONTINUER avec le datagramme suivant.

SI le datagramme n'a pas été reçu sur l'interface virtuelle de prochain bond pour le chemin e:

ALORS   CONTINUER avec le datagramme suivant.

SI le datagramme est tunnelé :

ALORS   remplacer l'adresse de source du datagramme par la première adresse dans la route de source IP lâche.

   remplacer l'adresse de destination du datagramme par la seconde adresse dans la route de source IP lâche.

   supprimer la route de source IP lâche et l'option Nul dans le datagramme et ajuster les champs de longueur d'en-tête IP pour refléter la suppression.

Si la destination du datagramme est le groupe 224.0.0.0 ou le groupe 224.0.0.1:

ALORS   CONTINUER avec le datagramme suivant.

POUR chaque interface virtuelle V

FAIRE   SI V est dans la liste des filles pour la source du datagramme :

   ALORS   SI V n'est pas dans la liste des feuilles pour la source

   OU si il y a des membres du groupe de destination sur V :

   ALORS   Si le TTL IP est supérieur au seuil de V :

   ALORS   soustraire 1 du TTL IP

   transmettre le datagramme à partir de V

7.   Valeurs temporelles

La présente section contient une liste des divers taux et temporisateurs, leur signification, et leurs valeurs. Toutes les valeurs sont en secondes.

Les taux suivants sont affectés par le caractère dynamique de l'environnement d'acheminement. Un taux plus faible va permettre une adaptation plus rapide à un changement de l'environnement, au prix d'une consommation accrue de la bande passante du réseau.

FULL_UPDATE_RATE = 60

-   C'est la fréquence à laquelle sont envoyés les messages d'acheminement qui contiennent les tableaux d'acheminement complets.

TRIGGERED_UPDATE_RATE = 5

-   C'est la fréquence d'envoi des messages d'acheminement déclenchés.

Augmenter les taux et temporisateurs suivants peut allonger le temps pendant lequel les paquets peuvent être transmis inutilement à une interface virtuelle.

QUERY_RATE = 120

-   Fréquence d'interrogation de l'adhésion à un groupe local.

MEMBERSHIP_TIMEOUT = 2 * QUERY_RATE + 20

-   Durée de validité sans confirmation de l'adhésion à un groupe local.

LEAF_TIMEOUT = 2 * FULL_UPDATE_RATE + 5

-   Durée du temporisateur de garde pour une interface virtuelle.

Augmenter les temporisations suivantes va augmenter la stabilité de l'algorithme d'acheminement, au prix de réactions plus lentes aux changements de l'environnement d'acheminement.

NEIGHBOR_TIMEOUT = 4 * FULL_UPDATE_RATE

-   Durée de la prise en compte d'un voisin sans confirmation. C'est important pour la durée de validité des chemins, et pour l'établissement des fanions de filles et de feuilles.

EXPIRATION_TIMEOUT = 2 * FULL_UPDATE_RATE

-   Durée de validité d'un chemin en l'absence de confirmation. Lorsque cette temporisation arrive à expiration, les paquets ne sont plus transmis sur ce chemin et les mises à jour d'acheminement vont considérer que ce chemin a une métrique d'infini.

GARBAGE_TIMEOUT = 4 * FULL_UPDATE_RATE

-   Durée d'existence d'un chemin en l'absence de confirmation. Lorsque cette temporisation arrive à expiration, les mises à jour d'acheminement ne vont plus contenir d'informations sur ce chemin, et il sera supprimé.

8.   Options de configuration

Un routeur devrai être configurable avec les informations suivantes :

-   Descriptions de tunnel : point d'extrémité local, point d'extrémité distant, métrique, et seuil. Si aucun seuil n'est fourni, la métrique devrait être utilisée comme seuil par défaut.

-   Pour une interface physique : métrique, infini, seuil et gabarit de sous-réseau. Si aucun seuil n'est fourni, la métrique devrait être utilisée comme seuil par défaut.

9.   Conclusion

Le présent mémoire a présenté DVMRP, un protocole extensible d'acheminement par vecteur de distance, et un algorithme d'acheminement TRPB . Une mise en œuvre des idées présentées dans ce document a été faite, et est en cours d'évaluation.

Les caractéristiques ajoutée à DVMRP par rapport à RIP lui donnent de la souplesse, au prix d'une plus grande complexité de traitement. DVMRP a encore l'inconvénient d'être un algorithme de vecteur de distance. Comme les algorithmes d'état de liaison entretiennent la plupart des informations d'état que DVMRP doit conserver en plus de ce dont a besoin RIP, un protocole d'acheminement de diffusion groupée par état de liaison devrait être développé.

L'algorithme TRPB peut causer l'envoi de datagrammes inutiles. L'algorithme de diffusion groupés sur le chemin inverse (RPM) [3] pourrait être un meilleur algorithme. Les messages DVMRP NMR et Annuler-NMR sont conçus pour prendre en charge RPM. Des recherches complémentaires sur ce sujet sont nécessaires.

10.   Remerciements

Nous tenons à remercier Robb Foster, Alan Dahlbom, Ross Callon, et le groupe de travail Hôte de l'IETF pour leurs idées.

11.   Bibliographie

[1]   C. Hedrick, "Protocole d'informations d'acheminement", RFC 1058, juin 1988. (Historique)

[2]   S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", RFC 1054, mai 1988. (Obsolète, voir RFC 1112, STD 5),

[3]   Deering, S., "Multicast Routing in Internetworks and ExtendedLANs", SIGCOMM été 1988 Proceedings, août 1988.

[4]   Callon, R., "A Comparison of 'Link State' and 'Distance Vector' Routing Algorithms", DEC, novembre 1987.

[5]   J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet DARPA", RFC0791, STD 5, septembre 1981.

[6]   Groupe de travail Algorithmes de passerelles et structures de données, "Vers un schéma Internet standard de sous-réseau", RFC0940, avril 1985.