3. Fragmentation et découverte du MTU du chemin

3. Fragmentation et découverte du MTU du chemin

   Tout comme il est possible de recevoir un datagramme IP non étiqueté qui est trop grand pour être transmis sur sa liaison de sortie, il est possible de recevoir un paquet étiqueté qui est trop grand pour être transmis sur sa liaison de sortie.

   Il est également possible qu'un paquet reçu (étiqueté ou non étiqueté) qui était à l'origine assez petit pour être transmis sur cette liaison devienne trop grand en raison de l'ajout d'une ou plusieurs étiquettes supplémentaires sur sa pile d'étiquettes. Dans la commutation d'étiquettes, un paquet peut augmenter en taille si des étiquettes supplémentaires sont poussées. Ainsi, si l'on reçoit un paquet étiqueté avec une charge utile de trame de 1500 octets, et que l'on pousse une étiquette supplémentaire, on doit le transmettre comme une trame avec une charge utile de 1504 octets.

   Cette section spécifie les règles pour le traitement des paquets étiquetés qui sont "trop grands". En particulier, elle fournit des règles qui garantissent que les hôtes implémentant la découverte du MTU du chemin (Path MTU Discovery) [4], et les hôtes utilisant IPv6 [7,8], seront capables de générer des datagrammes IP qui n'ont pas besoin de fragmentation, même si ces datagrammes sont étiquetés lorsqu'ils traversent le réseau.

   En général, les hôtes IPv4 qui n'implémentent pas la découverte du MTU du chemin [4] envoient des datagrammes IP qui ne contiennent pas plus de 576 octets. Puisque les MTU utilisés sur la plupart des liaisons de données aujourd'hui sont de 1500 octets ou plus, la probabilité que de tels datagrammes aient besoin d'être fragmentés, même s'ils sont étiquetés, est très faible.

   Certains hôtes qui n'implémentent pas la découverte du MTU du chemin [4] généreront des datagrammes IP contenant 1500 octets, tant que les adresses IP source et de destination sont sur le même sous-réseau. Ces datagrammes ne passeront pas par des routeurs, et ne seront donc pas fragmentés.

   Malheureusement, certains hôtes généreront des datagrammes IP contenant 1500 octets, tant que les adresses IP source et de destination ont le même numéro de réseau par classe. C'est le seul cas où il y a un risque de fragmentation lorsque de tels datagrammes sont étiquetés. (Même ainsi, la fragmentation n'est pas probable à moins que le paquet ne doive traverser un Ethernet quelconque entre le moment où il est étiqueté pour la première fois et le moment où il est désétiqueté.)

   Ce document spécifie des procédures qui permettent de configurer le réseau de sorte que les grands datagrammes provenant d'hôtes qui n'implémentent pas la découverte du MTU du chemin soient fragmentés une seule fois, lorsqu'ils sont étiquetés pour la première fois. Ces procédures permettent (en supposant une configuration appropriée) d'éviter tout besoin de fragmenter des paquets qui ont déjà été étiquetés.

3.1. Terminologie

En ce qui concerne une liaison de données particulière, nous pouvons utiliser les termes suivants :

  -  Charge utile de trame (Frame Payload) :

     Le contenu d'une trame de liaison de données, excluant tout en-tête ou remorque de couche de liaison de données (par exemple, en-têtes MAC, en-têtes LLC, en-têtes 802.1Q, en-tête PPP, séquences de contrôle de trame, etc.).

     Lorsqu'une trame transporte un datagramme IP non étiqueté, la charge utile de trame est simplement le datagramme IP lui-même. Lorsqu'une trame transporte un datagramme IP étiqueté, la charge utile de trame se compose des entrées de la pile d'étiquettes et du datagramme IP.

  -  Taille maximale conventionnelle de la charge utile de trame (Conventional Maximum Frame Payload Size) :

     La taille maximale de la charge utile de trame autorisée par les normes de liaison de données. Par exemple, la taille maximale conventionnelle de la charge utile de trame pour Ethernet est de 1500 octets.

  -  Taille maximale réelle de la charge utile de trame (True Maximum Frame Payload Size) :

     La taille maximale de la charge utile de trame qui peut être envoyée et reçue correctement par le matériel d'interface attaché à la liaison de données.

     Sur les réseaux Ethernet et 802.3, on pense que la taille maximale réelle de la charge utile de trame est de 4 à 8 octets plus grande que la taille maximale conventionnelle de la charge utile de trame (tant qu'aucun en-tête 802.1Q ni aucun en-tête 802.1p n'est présent, et tant qu'aucun des deux ne peut être ajouté par un commutateur ou un pont pendant qu'un paquet est en transit vers son prochain saut). Par exemple, on pense que la plupart des équipements Ethernet pourraient envoyer et recevoir correctement des paquets transportant une charge utile de 1504 ou peut-être même 1508 octets, au moins, tant que l'en-tête Ethernet n'a pas de champ 802.1Q ou 802.1p.

     Sur les liaisons PPP, la taille maximale réelle de la charge utile de trame peut être pratiquement illimitée.

  -  Taille maximale effective de la charge utile de trame pour les paquets étiquetés (Effective Maximum Frame Payload Size for Labeled Packets) :

     C'est soit la taille maximale conventionnelle de la charge utile de trame, soit la taille maximale réelle de la charge utile de trame, selon les capacités de l'équipement sur la liaison de données et la taille de l'en-tête de liaison de données utilisé.

  -  Datagramme IP initialement étiqueté (Initially Labeled IP Datagram) :

     Supposons qu'un datagramme IP non étiqueté est reçu à un LSR particulier, et que le LSR pousse une étiquette avant de transmettre le datagramme. Un tel datagramme sera appelé un datagramme IP initialement étiqueté à ce LSR.

  -  Datagramme IP précédemment étiqueté (Previously Labeled IP Datagram) :

     Un datagramme IP qui avait déjà été étiqueté avant d'être reçu par un LSR particulier.

3.2. Taille maximale du datagramme IP initialement étiqueté

Chaque LSR qui est capable de

  a) recevoir un datagramme IP non étiqueté,
  b) ajouter une pile d'étiquettes au datagramme, et
  c) transmettre le paquet étiqueté résultant,

DEVRAIT prendre en charge un paramètre de configuration appelé "Taille maximale du datagramme IP initialement étiqueté", qui peut être défini sur une valeur non négative.

Si ce paramètre de configuration est défini sur zéro, il n'a aucun effet.

S'il est défini sur une valeur positive, il est utilisé de la manière suivante. Si :

  a) un datagramme IP non étiqueté est reçu, et
  b) ce datagramme n'a pas le bit DF défini dans son en-tête IP, et
  c) ce datagramme doit être étiqueté avant d'être transmis, et
  d) la taille du datagramme (avant l'étiquetage) dépasse la valeur du paramètre,

alors a) le datagramme doit être divisé en fragments, dont chacun a une taille ne dépassant pas la valeur du paramètre, et

  b) chaque fragment doit être étiqueté puis transmis.

Par exemple, si ce paramètre de configuration est défini sur une valeur de 1488, alors tout datagramme IP non étiqueté contenant plus de 1488 octets sera fragmenté avant d'être étiqueté. Chaque fragment sera capable d'être transporté sur une liaison de données de 1500 octets, sans autre fragmentation, même si jusqu'à trois étiquettes sont poussées sur sa pile d'étiquettes.

En d'autres termes, définir ce paramètre sur une valeur non nulle permet d'éliminer toute fragmentation des datagrammes IP précédemment étiquetés, mais cela peut causer une certaine fragmentation inutile des datagrammes IP initialement étiquetés.

Notez que le réglage de ce paramètre n'affecte pas le traitement des datagrammes IP qui ont le bit DF défini ; par conséquent, le résultat de la découverte du MTU du chemin n'est pas affecté par le réglage de ce paramètre.

3.3. Quand les datagrammes IP étiquetés sont-ils trop grands ?

Un datagramme IP étiqueté dont la taille dépasse la taille maximale conventionnelle de la charge utile de trame de la liaison de données sur laquelle il doit être transmis PEUT être considéré comme "trop grand".

Un datagramme IP étiqueté dont la taille dépasse la taille maximale réelle de la charge utile de trame de la liaison de données sur laquelle il doit être transmis DOIT être considéré comme "trop grand".

Un datagramme IP étiqueté qui n'est pas "trop grand" DOIT être transmis sans fragmentation.

3.4. Traitement des datagrammes IPv4 étiquetés qui sont trop grands

Si un datagramme IPv4 étiqueté est "trop grand", et que le bit DF n'est pas défini dans son en-tête IP, alors le LSR PEUT rejeter silencieusement le datagramme.

Notez que le rejet de tels datagrammes n'est une procédure sensée que si la "Taille maximale du datagramme IP initialement étiqueté" est définie sur une valeur non nulle dans chaque LSR du réseau qui est capable d'ajouter une pile d'étiquettes à un datagramme IP non étiqueté.

Si le LSR choisit de ne pas rejeter un datagramme IPv4 étiqueté qui est trop grand, ou si le bit DF est défini dans ce datagramme, alors il DOIT exécuter l'algorithme suivant :

  1. Retirer les entrées de la pile d'étiquettes pour obtenir le datagramme IP.

  2. Soit N le nombre d'octets dans la pile d'étiquettes (c'est-à-dire, 4 fois le nombre d'entrées de la pile d'étiquettes).

  3. Si le datagramme IP n'a PAS le bit "Don't Fragment" défini dans son en-tête IP :

     a. le convertir en fragments, dont chacun DOIT être au moins N octets inférieur à la taille maximale effective de la charge utile de trame.

     b. Préfixer chaque fragment avec le même en-tête d'étiquette qui aurait été sur le datagramme d'origine si la fragmentation n'avait pas été nécessaire.

     c. Transmettre les fragments

  4. Si le datagramme IP a le bit "Don't Fragment" défini dans son en-tête IP :

     a. le datagramme NE DOIT PAS être transmis

     b. Créer un message ICMP Destination Unreachable :

         i. définir son champ Code [3] sur "Fragmentation Required and DF Set",

        ii. définir son champ Next-Hop MTU [4] sur la différence entre la taille maximale effective de la charge utile de trame et la valeur de N

     c. Si possible, transmettre le message ICMP Destination Unreachable à la source du datagramme rejeté.

3.5. Traitement des datagrammes IPv6 étiquetés qui sont trop grands

Pour traiter un datagramme IPv6 étiqueté qui est trop grand, un LSR DOIT exécuter l'algorithme suivant :

  1. Retirer les entrées de la pile d'étiquettes pour obtenir le datagramme IP.

  2. Soit N le nombre d'octets dans la pile d'étiquettes (c'est-à-dire, 4 fois le nombre d'entrées de la pile d'étiquettes).

  3. Si le datagramme IP contient plus de 1280 octets (sans compter les entrées de la pile d'étiquettes), ou s'il ne contient pas d'en-tête de fragment, alors :

     a. Créer un message ICMP Packet Too Big, et définir son champ Next-Hop MTU sur la différence entre la taille maximale effective de la charge utile de trame et la valeur de N

     b. Si possible, transmettre le message ICMP Packet Too Big à la source du datagramme.

     c. rejeter le datagramme IPv6 étiqueté.

  4. Si le datagramme IP n'est pas plus grand que 1280 octets, et qu'il contient un en-tête de fragment, alors

     a. Le convertir en fragments, dont chacun DOIT être au moins N octets inférieur à la taille maximale effective de la charge utile de trame.

     b. Préfixer chaque fragment avec le même en-tête d'étiquette qui aurait été sur le datagramme d'origine si la fragmentation n'avait pas été nécessaire.

     c. Transmettre les fragments.

     Le réassemblage des fragments sera effectué à l'hôte de destination.

3.6. Implications concernant la découverte du MTU du chemin

Les procédures décrites ci-dessus pour le traitement des datagrammes qui ont le bit DF défini, mais qui sont "trop grands", ont un impact sur les procédures de découverte du MTU du chemin de la RFC 1191 [4]. Les hôtes qui implémentent ces procédures découvriront un MTU qui est assez petit pour permettre à n étiquettes d'être poussées sur les datagrammes, sans besoin de fragmentation, où n est le nombre d'étiquettes qui sont effectivement poussées le long du chemin actuellement utilisé.

En d'autres termes, les datagrammes provenant d'hôtes qui utilisent la découverte du MTU du chemin n'auront jamais besoin d'être fragmentés en raison de la nécessité de mettre un en-tête d'étiquette, ou d'ajouter de nouvelles étiquettes à un en-tête d'étiquette existant. (De plus, les datagrammes provenant d'hôtes qui utilisent la découverte du MTU du chemin ont généralement le bit DF défini, et ne seront donc jamais fragmentés de toute façon.)

Notez que la découverte du MTU du chemin ne fonctionnera correctement que si, au point où la fragmentation d'un datagramme IP étiqueté doit se produire, il est possible de faire router un message ICMP Destination Unreachable vers l'adresse source du paquet. Voir la section 2.3.

S'il n'est pas possible de transmettre un message ICMP depuis l'intérieur d'un "tunnel" MPLS vers l'adresse source d'un paquet, mais que la configuration du réseau permet au LSR à l'extrémité émettrice du tunnel de recevoir des paquets qui doivent passer par le tunnel, mais qui sont trop grands pour passer par le tunnel sans fragmentation, alors :

  -  Le LSR à l'extrémité émettrice du tunnel DOIT être capable de déterminer le MTU du tunnel dans son ensemble. Il PEUT le faire en envoyant des paquets à travers le tunnel vers le point de terminaison récepteur du tunnel, et en effectuant la découverte du MTU du chemin avec ces paquets.

  -  Chaque fois que le point de terminaison émetteur du tunnel a besoin d'envoyer un paquet dans le tunnel, et que ce paquet a le bit DF défini, et qu'il dépasse le MTU du tunnel, le point de terminaison émetteur du tunnel DOIT envoyer le message ICMP Destination Unreachable à la source, avec le code "Fragmentation Required and DF Set", et le champ Next-Hop MTU défini comme décrit ci-dessus.