Pourquoi la taille de la MTU pour les trames Ethernet a-t-elle été calculée comme étant de 1 500 octets?

38

Existe-t-il un calcul spécifique qui a été fait pour arriver à ce nombre et quels facteurs ont été pris en compte pour ce calcul.

ethernet mtu protocol-theory

— Padmaraj
source

2

Les gens de l'IEEE s'opposent à l'ajout de 9k à la norme car les garanties mathématiques que FCS apporte aujourd'hui à 1,5k ne seraient plus toutes vraies à 9k.

— Ytti

5

@ytti, ce n'est qu'un des arguments contre l'approbation de> 1500 cadres. Le texte intégral de la lettre de Geoff Thomson (contenant les objections de l'IEEE à la normalisation des trames jumbo) figure dans draft-ietf-isis-ext-eth-01, Annexe 1 . Les objections commencent par le mot "Consideration"

— Mike Pennington

Est-ce qu'une réponse vous a aidé? Si tel est le cas, vous devez accepter la réponse afin que la question ne se répète pas pour toujours, à la recherche d'une réponse. Vous pouvez également fournir et accepter votre propre réponse.

— Ron Maupin

27

La réponse est dans draft-ietf-isis-ext-eth-01 , Sections 3-5. Ethernet utilise les mêmes deux octets de manière différente dans les encapsulations Ethernet II (DIX) et 802.3:

Ethernet II utilise les deux premiers octets après l'adresse MAC source Ethernet pour un type
802.3 utilise ces deux mêmes octets pour un champ Longueur .

J'inclus ci-dessous un diagramme annoté de chaque type de trame, qui montre exactement où se trouvent les octets en conflit dans l'en-tête Ethernet:

La RFC 894 (communément appelée trames Ethernet II) utilise ces octets pour le type

   +----+----+------+------+-----+
   | DA | SA | Type | Data | FCS |
   +----+----+------+------+-----+
             ^^^^^^^^

   DA      Destination MAC Address (6 bytes)
   SA      Source MAC Address      (6 bytes)
   Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
   Data    Protocol Data           (46 - 1500 bytes)
   FCS     Frame Checksum          (4 bytes)

IEEE 802.3 avec 802.2 LLC / SNAP (utilisé par Spanning Tree, ISIS) utilise ces octets pour Longueur.

   +----+----+------+------+-----+
   | DA | SA | Len  | Data | FCS |
   +----+----+------+------+-----+
             ^^^^^^^^

   DA      Destination MAC Address (6 bytes)
   SA      Source MAC Address      (6 bytes)
   Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
   Data    Protocol Data           (46 - 1500 bytes)
   FCS     Frame Checksum          (4 bytes)

Les encapsulations Ethernet II et 802.3 doivent pouvoir exister sur le même lien. Si IEEE autorisait les charges utiles Ethernet à dépasser 1 536 octets (0x600 hex), il serait alors impossible de distinguer les grandes trames 802.3 LLC ou SNAP des trames Ethernet II; Les valeurs de type d'Ethernet commencent à 0x600 hex.

MODIFIER:

J'inclus un lien vers des copies pdf des spécifications Ethernet Version 1 et Ethernet Version 2 , au cas où quelqu'un serait intéressé ...

— Mike Pennington
source

2

En passant, les valeurs comprises entre maxValidFrame (1500) et "1536 décimales" ne sont pas définies dans la norme Ethernet. Le comportement de l'équipement à ces valeurs n'est pas spécifié et ne peut être compté

— Mike Pennington

2

Eh bien, les trames Ethernet II ont leur champ type qui commence par 0x0600 (d'après la spécification IEEE 802.3x-1997) car la longueur maximale maximale de 802.3 était juste inférieure à celle. Donc, ce n'est qu'un effet, pas une cause.

— nos

1

@nos, prétendre que c'est un effet plutôt qu'une cause suppose que vous puissiez en prouver la cause ... pouvez-vous fournir des preuves faisant autorité pour la cause que vous proposez? La spécification Ethernet Version 1 d'origine publiée en 1980 utilisait déjà le champ Type et, en 1984, le protocole IP était spécifié avec Ethertype 0x0800

— Mike Pennington.

2

En effet, les spécifications ethernet I et II avaient déjà un champ de type (qui à ce moment-là n'était soumis à aucune restriction) et spécifiaient déjà une longueur maximale de données de 1 500 - à cette époque, il n'y avait pas de trames 802.3. On ne peut donc pas en conclure que la limite de 1500 a été ajoutée dans une spécification ultérieure en raison du champ de type.

— nos

2

@nos Je ne suis pas d'accord, Ethernet II devait coexister avec le standard préexistant. Et il a également défini l'utilisation du même champ pour agir à la fois comme champ de type dans la norme précédente et comme champ de longueur dans la nouvelle norme. Étant donné qu’il ne doit y avoir AUCUNE possibilité de confusion entre les deux normes, qui doivent coexister dans le même réseau, toute longueur qui pourrait ressembler à un type existant ne serait pas autorisée. Comme la liste de types existante commençait à 0x600un nombre inférieur à celui qui devait être choisi. Pour ne permettre aucune extension supplémentaire de la norme, il devait rester une bande si nécessaire.

14

À l'autre extrémité de la plage - 1500 octets, deux facteurs ont conduit à l'introduction de cette limite. Premièrement, si les paquets sont trop longs, ils introduisent des retards supplémentaires dans le trafic via le câble Ethernet. L'autre facteur était un dispositif de sécurité intégré aux premiers émetteurs-récepteurs à câble partagé. Ce dispositif de sécurité était un système anti-babillage.Si le périphérique connecté à un émetteur-récepteur présentait une défaillance et commençait à émettre en continu, il empêcherait tout autre trafic d'utiliser ce segment de câble Ethernet. Afin d'éviter ce problème, les premiers émetteurs-récepteurs ont été conçus pour s'éteindre automatiquement si la transmission dépassait environ 1,25 milliseconde. Cela équivaut à un contenu de données d'un peu plus de 1500 octets. Toutefois, comme l'émetteur-récepteur utilisait un simple temporisateur analogique pour arrêter la transmission si un babillage était détecté, la limite de 1 500 a été sélectionnée comme approximation de sécurité de la taille maximale des données qui ne déclencherait pas le dispositif de sécurité.

Source: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

— utilisateur1171
source

5

Bonjour @ utilisateur1171: Le style préféré de StackExchange consiste à inclure le matériel de réponse ici et à créer un lien en tant que référence. Ainsi, lorsque le lien finit par pourrir, la réponse est toujours utile.

— Craig Constantine

La fonction jabber a nécessité l’arrêt de la MAU au bout de 20 à 150 ms pour 10 Mbit / s (Clause IEEE 802.3 8.2.1.5), de 40 à 75 kbit pour Fast Ethernet (Clause 27.3.2.1.4) et deux fois plus élevée que pour Gigabit Ethernet. dépassant de loin la longueur du cadre. Le post de Yahoo est faux.

— Zac67

10

Lorsque Ethernet a été initialement développé en tant que support ou bus partagé avec 10Base5 et 10Base2, les collisions de trames étaient fréquentes et attendues dans le cadre de la conception. Comparez cela à aujourd'hui, où presque tout est commuté avec des domaines de collision distincts et en duplex intégral où personne ne s'attend à voir des collisions.

Le mécanisme de partage de "l'éther" utilisé CMSA / CD (Détection de collision et d'accès multiple avec détection de porteuse)

Carrier Sense signifiait qu'une station souhaitant émettre devait écouter le fil - capter le signal de la porteuse - pour s'assurer que personne d'autre ne parlait puisqu'il s'agissait d'un accès multiple sur ce support. Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time. Plus le nombre d'octets transmis dans une trame est long, plus toutes les autres stations doivent attendre longtemps avant la fin de la transmission. En d'autres termes, des rafales plus courtes ou des MTU plus petites signifient que les autres stations ont plus d'opportunités de transmission et une part plus équitable. Plus la vitesse du support de transmission (10 Mbits / s) est lente, plus le délai de transmission des stations sera long à mesure que le MTU augmentera (s'il est autorisé à dépasser 1 500).

Une question corollaire intéressante serait pourquoi la taille de trame minimale de 64 octets? Les trames étaient transmises dans des "slots" de 512 bits et prenaient 51,2us pour la propagation du signal aller-retour dans le support. Une station doit non seulement savoir quand commencer à parler en détectant l'IFG (intervalle entre trames de 96 bits), mais également écouter les collisions avec d'autres trames. La détection de collision suppose un délai de propagation maximal et le double (sécurité) pour ne pas manquer une transmission démarrant à peu près au même moment à partir de l'autre extrémité du fil ou une réflexion du signal de sa propre transmission lorsque quelqu'un oublie la résistance de terminaison au niveau du câble. extrémités du câble. La station ne doit pas terminer l'envoi de ses données avant de détecter une collision. L'attente de 512 bits ou de 64 octets le garantit.

— generalnetworkerror
source

2

À l'origine, max. la charge utile a été définie à 1 500 octets dans 802.3. Ethernet v2 prend en charge une longueur de trame> = 1536 et c’est ce que les implémentations IP utilisent. La plupart des fournisseurs de classe opérateur supportent actuellement environ 9 000 octets ("trames jumbo"). 1500 octets étant la norme que toutes les implémentations Ethernet doivent prendre en charge, il s’agit de ce qui est normalement défini par défaut sur toutes les interfaces.

Vous devriez google maxValidFrame, il a été défini par IEEE; Par conséquent, les implémentations de cadre jumbo 9KB qui sont communes aujourd'hui ne sont pas officiellement compatibles avec Ethernet, mais ils fonctionnent très bien pour Ethernet II charges utiles

— Mike Pennington

Strictement parlant, pas conforme à la norme 802.3. IP utilise Ethernet v2 cependant, donc j'ai tendance à ne même pas penser à 802.3 ...

5

Les jumbos ne sont pas compatibles avec Ethernet II ou 802.3 après la ratification de 802.3x. La clause 4.2.7.1 de 802.3x définit maxValidFrame à 1500B de charge utile. Ainsi, après 1997, toute charge utile supérieure à 1500 octets n’est pas conforme. Voir la lettre que le président de l'IEEE 802.3 a envoyée à l'IETF à ce sujet . En bref, 802.3 est bien plus qu’un standard de trame… il définit à la fois la configuration requise et la configuration matérielle. Cela signifie que les implémentations matérielles dépendent de la conformité avec le format de trame. Half Duplex avec CSMA-CD nécessite <= 1 500 Go de charge utile.

— Mike Pennington

-1

La trame Ethernet minimale est basée sur la durée de l'emplacement Ethernet, qui est de 512 bits (64 octets) pour 10M Ethernet. Après avoir soustrait 18 octets pour l'en-tête Ethernet et le CRC, vous obtenez 46 octets de charge utile.

Ethernet Slot Time a été spécifié pour que CSMA / CD fonctionne correctement. Assurez-vous que la taille minimale du cadre ne dépasse pas la longueur de câble la plus longue possible; si c'était le cas, la détection de collision déterministe serait impossible. Après la détection de collision à la longueur maximale du câble, vous avez besoin du signal de détection de collision pour être renvoyé à l'expéditeur.

— Pooja Khatri
source

3

J'ai du mal à comprendre en quoi le mécanisme de détermination de la taille minimale de la trame Ethernet est en rapport avec l'actuel standard maximum de 1500 octets maximum. S'il vous plaît élaborer!

— Stuggi

2

@Stuggi Ce n'est pas le cas.

— Ken Sharp