Comment Ethernet sait-il la longueur d'une trame?


17

En regardant l' entrée Ethernet sur Wikipedia, je ne peux pas comprendre comment il est indiqué la longueur de la trame Ethernet. Le champ d'en-tête EtherType / Length peut apparemment indiquer soit un type de trame soit une longueur explicite, et je suppose que dans le cas d'un type de trame, il doit faire une autre logique pour déterminer la longueur du paquet. Par exemple, si le champ EtherType est 0x0800, cela indique une charge utile IPv4, et donc la carte réseau de réception devra examiner les 32 premiers bits de la charge utile pour trouver la longueur du paquet IP, et donc pour déterminer la longueur totale de la trame Ethernet, et savoir quand chercher la somme de contrôle de fin de trame et l'écart intertrame.

Est-ce que cela semble correct? J'ai également examiné la spécification IEEE 802.3 pour Ethernet (partie 1, de toute façon) qui semble corroborer cela, mais elle est assez opaque.


Réponses:


21

La sous-couche de codage physique est chargée de délimiter les trames et de les envoyer à la couche MAC.

En Gigabit Ethernet, par exemple, le schéma de codage 8B / 10B utilise un groupe de codes 10 bits pour coder un octet 8 bits. Les deux bits supplémentaires indiquent si un octet est une information de contrôle ou des données. Les informations de contrôle peuvent être Configuration, Start_of_packet, End_of_packet, IDLE, Carrier_extend, Error_propagation.

C'est ainsi qu'une carte réseau sait où commence et se termine une trame. Cela signifie également que la longueur de la trame n'est pas connue avant qu'elle ne soit entièrement décodée, comme une chaîne terminée par NULL en C.


1
Ceci est spécifié dans IEEE Std 802.3-2015 (Section Trois), 36.2.4.2 et 36.2.4.15 (entre autres dans cette chose illisible qu'ils appellent standard;).
stefanct

1

L'article auquel vous voulez vraiment répondre est http://en.wikipedia.org/wiki/Ethernet_II_framing ; qui dit:

Comme cette norme développée par l'industrie est passée par un processus de normalisation IEEE formel, le champ EtherType a été changé en un champ de longueur (de données) dans la nouvelle norme 802.3. (Les paquets Ethernet d'origine définissent leur longueur avec le cadre qui l'entoure, plutôt qu'avec un nombre de longueurs explicites.) Étant donné que le destinataire du paquet doit toujours savoir comment interpréter le paquet, la norme exigeait un en-tête IEEE 802.2 pour suivre la longueur et spécifier le type de paquet.


Je suppose que je ne suis pas clair sur ce que "les paquets Ethernet d'origine définissent leur longueur avec le cadrage qui l'entoure". Les bits de préambule / de début de trame sont assez clairs, mais comment le client sait-il que la fin de la trame a été atteinte? Comment fait-il la distinction entre le CRC et l'écart intertrame? Le bruit électrique aléatoire IFG est-il facile à distinguer du signal réel?
dirtside

La fin de trame dans "Ethernet classique" est signalée par un codage illégal.
Vatine du

@womble, L'article que vous avez lié est bon mais le morceau que vous avez cité est très trompeur hors de son contexte. Aujourd'hui, la plupart des trames sur un réseau Ethernet n'utilisent pas de champ de longueur explicite.
Peter Green

-3

Logiquement, il n'y a que trois options:

  1. Utilisation d'une taille d'image statique comme dans.
  2. Spécifier la taille du cadre dans son en-tête, ou ailleurs, ou même le délimiter avec quelques drapeaux.
  3. Pas d'envoi de trames du tout

L'un de ces travaux en Ethernet car il n'y a aucune autre option actuellement disponible pour la mise en réseau moderne;) 1er et 3e sont mauvais pour Ethernet, donc vous avez raison!


-3

Il a fallu un certain temps pour résoudre ce problème une fois auparavant et de nouveau maintenant. Pas beaucoup d'informations disponibles, ce qui est surprenant car c'est une question tellement évidente. J'ai finalement opté pour la solution qui utilise les champs de longueur dans les en-têtes de paquets. Voir le lien suivant

http://www3.rad.com/networks/infrastructure/lans/etherform.htm#_ieee

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.