Detectando diferentes tramas Ethernet

12

¿Cómo puede alguien distinguir entre diferentes paquetes en el protocolo Ethernet? No tiene campo / área de "longitud" como los protocolos de nivel superior utilizan para hacerlo.

Debido a que este protocolo tiene manejo tanto en el ámbito físico como en el lógico, supongo que la distinción también está separada.

¿La separación lógica se realiza utilizando el campo de protocolo "EtherType"? (es decir, obtener la longitud del paquete utilizando el tipo de protocolo de nivel superior, que tiene un campo de longitud en sus encabezados).

¿La distinción física es simplemente la no transmisión de señales eléctricas? (Que yo sepa, las señales eléctricas altas / bajas representan 0/1 bits).

Reflexión
fuente

Respuestas:

14

Aunque Ytti respondió, hay algunos detalles relevantes que pueden interesarle ...

¿Cómo puede alguien distinguir entre diferentes paquetes en el protocolo Ethernet? No tiene campo / área de "longitud" como los protocolos de nivel superior utilizan para hacerlo.

En realidad, Ethernet tiene múltiples encapsulaciones:

  • Ethernet II (normalmente utilizado para IP, como se especifica en [RFC 894], es la encapsulación más común): no tiene un campo de longitud , en su lugar se usa un campo de tipo ...
       +----+----+------+------+-----+
       | 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)
  • 802.2 LLC Ethernet: tiene un campo de longitud
       +----+----+------+------+------+------+-----+
       | DA | SA | Len  | LLC  | SNAP | 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)  <---
       LLC     802.2 LLC Header        (3 bytes)
       SNAP                            (5 bytes)
       Data    Protocol Data           (46 - 1492 bytes)
       FCS     Frame Checksum          (4 bytes)

Independientemente de la existencia del campo de longitud 802.2, siempre puede detectar el final de una trama de ethernet en el cable buscando la brecha entre tramas de 96 bits .

¿La separación lógica se realiza utilizando el campo de protocolo "EtherType"? (es decir, obtener la longitud del paquete utilizando el tipo de protocolo de nivel superior, que tiene un campo de longitud en sus encabezados).

Por separación lógica, supongo que se refiere a la separación entre diferentes protocolos llevados dentro de ethernet, tal es distinguir entre IPv4, IPv6 o quizás marcos de árbol de expansión.

  • Ethernet II normalmente usa el campo Tipo
  • 802.2 LLC Ethernet normalmente utiliza la extensión SNAP 802.2 Ethernet de cinco bytes . Los protocolos solo se decodifican con la extensión SNAP cuando los bytes 802.2 DSAP / SSAP son 0xAAAA.

¿La distinción física es simplemente la no transmisión de señales eléctricas? (Que yo sepa, las señales eléctricas altas / bajas representan 0/1 bits)

Simplísticamente, sí, hay una brecha de 96 bits entre las tramas de Ethernet; sin embargo, tenga en cuenta que ethernet utiliza una codificación 8b / 10b (FastEthernet) y una codificación 64b / 66b (GigabitEthernet), por lo que no es técnicamente correcto decir "no transmisión de señales eléctricas", ya que 8b / 10b no tiene un " "silencioso".


Para los curiosos, también estoy vinculando a la especificación original de Ethernet Versión 2 .

Mike Pennington
fuente
7

Ethernet tiene delimitador de trama de preámbulo e inicio al inicio y al final tiene 'IFG' o espacio entre cuadros. Estos se utilizan para determinar el inicio y el final del marco.

ytti
fuente
¿Es una separación en el ámbito físico o lógico? Sin embargo, ¿qué pasa si el campo de datos del protocolo incluirá información / caracteres / señales que son iguales a los delimitadores de inicio / fin?
Reflexión el
1
La brecha es, literalmente, solo eso, no hay riesgo de encontrarlo en la carga útil. Sin embargo, en otro contexto que no sea de Ethernet, esto es una preocupación y se puede solucionar asegurándose de que algunos símbolos nunca se usen para codificar datos, sino solo para señalizar, sin embargo, disminuiría la eficiencia al desperdiciar algunos símbolos por "no útiles" datos.
ytti