Типы фреймов
Основным и использующимся форматом является Ethernet II или Ethernet DIX (По первой букве названий компаний учавствующих в разработке – DEC, Intel и Xerox)
…в настоящее время оборудованием Ethernet используются только кадры Ethernet DIX (II). Остальные форматы кадров, в том числе кадр 802.3/LLC, попрежнему формально являющийся стандартным, вышли из употребления из-за более сложного формата, который оказался не нужен в условиях существования единой технологии канального уровня.
iptcp.net
| Preamble (8 bytes) | DA (6 bytes) | SA (6 bytes) | E-Type (2 bytes) | PAYLOAD | FCS (4 bytes) |
Преамбула (8 bytes) – последовательность бит, которая как говорят, не является частью ETH загаловка, используется для синхронизации. Как бы говорит ресиверу, что сейчас он будет принимать ethernet фрейм. Выглядит он так, первые 7 байт – 10101010 (и так 7 раз) и последний 8-ой 10101011.
В 802.3 преамбула стала 7 байт, которые так содержало последовательность 10101010 (7 раз, 7 байт) и было добавлено еще одно поле, которое назвали SD (Start of Frame Delimiter ), что означает : начало ethernet кадра.
Собственно тоже самое что и в DIX реализации, только выделено дополнительное поле. Вместо одного как в DIX’е.
admindoc.ru
- DA (6 bytes) – Destination address – MAC (media access control) адрес назначения. Может быть как юникаст, мультикаст так и бродкаст (unicast, multicast или broadcast).
- SA (6 bytes) – Source address – MAC адрес источника – всегда юникаст.
- E-Type (2 bytes) – EtherType – Идентификатор L3 протокола. Содержит условный код протокола верхнего уровня. Например, 0x0800 это – IPv4, а 0x8100 – это тегированый заголовок 802.1q. Список всех EtherType Касательно поля: “Требуется для поддержки интерфейсных функций мультиплексирования и демультиплексирования кадров при взаимодействии с протоколами верхних уровней” (с)
- PayLoad – L3 пакет размером от 46 до 1500 байт. Если длина пользовательских данных меньше 46 байт, то это поле дополняется до минимального размера байтами заполнения. Эта операция требуется для корректной работы метода доступа Ethernet
- FCS (4 bytes) – Frame Check Sequence – Поле контрольной последовательности кадра – 4 байтовое значение CRC (Cyclic Redundancy Check) используемое для выявления ошибок передачи. Вычисляется, с попощью алгоритма CRC – циклический избыточный код(?), отправляющей стороной и помещается в поле FCS. Принимающая сторора вычисляет данное значение самостоятельно и сравнивает с полученным.
Существуют еще три стандартных формата Ethernet фрейма:
- Кадр 802.3/LLC является стандартом комитета IEEE 802 и построен в соответствии с принятым разбиением функций канального уровня на уровень MAC и уровень LLC. Поэтому результирующий кадр является вложением кадра LLC, определяемого стандартом 802.2, в кадр MAC, определяемого стандартом 802.3.
- Кадр Raw 802.3, или Novell 802.3, появился в результате усилий компании Novell по ускорению разработки своего стека протоколов в сетях Ethernet.
- Кадр Ethernet SNAP стал результатом деятельности комитета 802.2 по приведениюпредыдущих форматов кадров к некоторому общему стандарту и приданию кадру необходимой гибкости для учета в будущем возможностей добавления полей или изменения их назначения.
Размер Payload
Стоит поговорить касательно нижнего порога payload – 46 байтов.
В совокупе с заголовком фрейма это будет 64 байта (два раза по 6 байт – это мак адреса; 2 байта это тип EtherType; 4 байта FCS) 6+6+2+4=18 18+46=64 байта.
Это связано с работой CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Такой размер считается достаточно длинным, чтобы можно было определить коллизию и оповестить передающую станцию и остальных “участников” в общй шине о коллизии. В нынешних сетях нет общей шины и узлы практически всегда работаю в полномдуплексе поэтому коллизии исключены.
По поводу верхнего порога, предпосылок на введение такого значения, в 1500 байт, было несколько:
1) Задержка при передаче – чем больше фрейм, тем дольше длится передача. Для ранних сетей, где домен коллизии не ограничивался портом, и всем станциям приходилось ждать завершения передачи – это было серьезной проблемой.
2) Чем больше фрейм, тем больше вероятность того что фрейм при передаче будет поврежден, что приведет к необходимости повторной передачи, и все устройства в домене коллизии будут вынуждены опять ждать.
3) Ограничение накладываемые памятью используемой под буфер интерфейса – на тот момент (1979г) увеличение буферов значительно удорожало стоимость иннтерфейса.
4) Ограничение, вносимое полем Lenght/Type – в стандарте закрпелено, что все значение выше 1536 (от 05-DD до 05-FF) указывают на EtherType, соответственно длина должна быть меньше 05-DC.
Косательно последнего пункта, про поля, в интернете наткнулся на другое его описание в котором говорили, что ответ кроется в draft-ietf-isis-ext-eth-01
Так как оба формата Ethernet фрейма используют два байта после поля Source MAC, принято было следующее: если значение поля больше или равно 0x0600 или 0x05ff (?) (1536 в decimal) то это Ethernet II
RFC 894 (commonly known as Ethernet II frames) use these bytes for Type:
+----+----+------+------+-----+
| DA | SA | Type | Data | FCS |
+----+----+------+------+-----+
^^^^^^^^
DA Destination MAC (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 with 802.2 LLC / SNAP (used by Spanning-Tree, ISIS) use these bytes for Length:
+----+----+------+------+-----+
| DA | SA | Len | Data | FCS |
+----+----+------+------+-----+
^^^^^^^^
DA Destination MAC (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)
В итоге получаем, что в стандарте 802.3 размер фрейма ограничивался 1518 байтами сверху, a payload 1500 байтами (отсюда и дефолтный размер MTU для Ethernet интерфейса) и 64 байтами снизу, а payload 46 байт.
Фреймы меньше 64 байт называются Runts, больше 1518 байт – Giants
Runts: Any frame which is received and which is less than 64 bytes is illegal, and is called a "runt". In most cases, such frames arise from a collision, and while they indicate an illegal reception, they may be observed on correctly functioning networks. A receiver must discard all runt frames. Giants: The Giant (Jumbo) Frame Any frame which is received and which is greater than the maximum frame size, is called a "giant". In theory, the jabber control circuit in the transceiver should prevent any node from generating such a frame, but certain failures in the physical layer may also give rise to over-sized Ethernet frames. Like runts, giants are discarded by an Ethernet receiver. Jumbo Frame Some modern Gigabit Ethernet NICs support frames that are larger than the traditional 1500 bytes specified by the IEEE. This new mode requires support by both ends of the link to support Jumbo Frames. Path MTU Discovery or PLPMTUD is required to utilise this feature, since there is no other way for a router to determine that all systems on the end-to-end path will support these larger sized frames.
Эволюция размеров Ethernet заголовков
С развитием технологий и спецификаций линейки IEEE 802 претерпевал изменения и размер фрейма. Основные дальнейшее изменения размера фрейма (не MTU!):
- 802.3AC — увеличивает максимальный размер фрейма до 1522 – добавляется Q-tag – несущий информацию о 802.1Q (VLAN tag) и 802.1p (биты под COS)
- 802.1AD — увеличивает максимальный размер фрейма до 1526, поддержка QinQ
- 802.1AH (MIM) – Provider Bridge Backbone Mac in Mac + 30 байт к размеру фрейма
- MPLS – увеличиваем размер фрейма на стек меток 1518 + n*4, где n – количество меток в стеке.
- 802.1AE – Mac Security, к стандартным полям добавляются поля Security Tag и Message Authentication Code + 68 байт к размеру фрейма.
Теперь интересное, все эти фреймы увеличенного размера группируются под одним именем – Baby-Giant frames. “Негласное” верхнее ограничение по размерам для Baby-Giant – это 1600 байт.
Зачастую, современные сетевые интерфейсы форвардят эти фреймы даже без имзенения значения HW MTU
Ссылки:
http://admindoc.ru/763/ethernet-2/
Список EtherType
Статья на хабре
Скан документа “The Ethernet” v2