Форматы кадров Ethernet. Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря

Аппаратный

Аппаратн

Сетевой адрес

получателя

назначения

источника

отправителя

получате

(Target Internet

Заголовок кадра Ethernet

Поле данных кадра Ethernet (ARP-запрос)

Рисунок 6 - Широковещательная передача ARP-запроса компьютером A

Аппаратный

Аппаратн

Сетевой адрес

получателя

назначения

источника

отправителя

получате

(Target Internet

Заголовок кадра Ethernet

Поле данных кадра Ethernet (ARP-ответ)

Рисунок 7 - ARP-ответа компьютера B

2.2.2 Работа ARP протокола в случае, когда отправитель и получатель расположены в разных сетях

Пусть компьютер A с именем Vito и компьютер B с именем Maxx так же, как и в первом случае, находятся в одной сети класса C 192.168.0.0, не разделенной на подсети, но компьютер B подключен и к внешней сети и помимо своих обычных функций выполняет функции шлюза (маршрутизатора). Компьютер A хочет обратиться через внешнюю сеть к некоторому компьютеру C с IP-адресом 195.5.27.10, т.е. получатель находится в другой сети. На рисунке 8 приведена соответствующая иллюстрация.

Компьютер C (получатель)

IP-адрес: 195.5.27.10

Компьютер

Vito(отправи

MAC-адрес:00-02-44-63-D3-87 MAC-адрес: 00-80-48-B7-BD-

IP-адрес: 192.168.0.147
	IP-адрес: 192.168.0.145

Компь ютер B

ARP-запрос

Рисунок 8 - Расположение отправителя и получателя в разных сетях

При обращении компьютера A к компьютеру C, например, при вводе на компьютере A команды ping –n 1 195.5.27.10 , компьютер A действует следующим образом.

Сначала компьютер A определяет, в какой сети – локальной или удаленной – находится компьютер C. Для этого он “накладывает” стандартную маску подсети класса C 255.255.255.0 на свой IP-адрес 192.168.0.147 и получает результат 192.168.0.0.

Затем он “накладывает” ту же маску на IP-адрес компьютера-получателя 195.5.27.10 и получает результат 195.5.27.0. Т.к. результаты этих двух операций различны, компьютер A делает вывод о том, что компьютер C находится в другой сети и передачу данных нужно выполнить через шлюз (компьютер B).

Затем компьютер A должен послать кадр Ethernet с эхо-запросом, указав в заголовке вложенного в этот кадр пакета ICMP IP-адрес компьютера-получателя 195.5.27.10, а в заголовке кадра Ethernet – MAC-адрес шлюза, т.е. компьютера B (а не

MAC-адрес компьютера-получателя ), т.к. сначала кадр по сети Ethernet должен достигнуть шлюза. Следовательно, компьютер A должен знать MAC-адрес шлюза, но в настройках TCP/IP компьютера указывается не MAC-адрес, а IP-адрес шлюза. Если компьютер A недавно обращался к шлюзу, то MAC-адрес шлюза может находиться в таблице ARP компьютера A. Если же компьютер A после начальной загрузки еще не обращался к шлюзу или обращался к нему давно и соответствующая динамическая запись соответствия “IP-адрес – MAC-адрес” уже удалена, то таблица ARP компьютера A не будет содержать MAC-адреса шлюза (если только он не введен туда администратором вручную). В этом случае компьютер A должен выяснить MAC-адрес шлюза с помощью протокола ARP.

Процесс выяснения компьютером A MAC-адреса шлюза (компьютера B) описан выше. После определения MAC-адреса шлюза компьютер A посылает эхо-запрос компьютеру C. Этот эхо-запрос поступает на компьютер B, который, выполняя функцию маршрутизатора, направляет эхо-запрос компьютеру C через внешнюю сеть.

При передаче данных от отправителя получателю, находящемуся в удаленной сети, в заголовке IP-пакета указывается IP-адрес получателя, а в заголовке кадра Ethernet указывается MAC-адрес не получателя, а MAC-адрес шлюза, через который

должны быть переданы данные. Аналогично, при поступлении на отправитель (компьютер А) ответных данных от получателя (компьютера C) через шлюз (компьютер В) в поле MAC-адреса источника заголовка кадра Ethernet указывается MAC-адрес не компьютера C, а MAC-адрес шлюза (компьютера В), а в поле IP-адреса источника заголовка IP-пакета указывается IP-адрес не шлюза В, а IP-адрес компьютера C.

2.2.3 Использование протокола ARP для проверки наличия в сети дублированного IP-адреса

Кроме установления соответствия между MAC-адресам и IP-адресом, протокол ARP выполняет еще одну важную функцию. При включении (загрузке) компьютера и при изменении его IP-адреса протокол ARP позволяет определить, имеются ли в локальной сети компьютеры с одинаковыми IP-адресами. Для этого при загрузке компьютера и после изменения его IP-адреса компьютер посылает ARP-запрос, в котором в качестве получателя пакета (полесетевой адрес получателя ) указывает свой собственный IP-адрес.

Такой ARP-запрос называется самообращенным (от слова gratuitous – “беспричинным”, т.е. не вызванным необходимостью последующей передачи данных, или “безвозмездным”, т.е. не требующим ответа). Компьютер, пославший самообращенный ARP-запрос, не ждет на него ответа. Если ответа на самообращенный ARP-запрос не поступает, значит, такого же IP-адреса, как у данного компьютера, в локальной сети больше нет. Если же какой-либо компьютер локальной сети отвечает на самообращенный ARP-запрос своим MAC-адресом, значит, в локальной сети уже есть компьютер с таким IP-адресом. В этом случае на экране компьютера, пославшего самообращенный ARP-запрос, и на экране компьютера, ответившего на этот запрос, выводятся сообщения об ошибке - “Конфликт IP-адреса с другой системой в сети”.

2.3 Протокол ICMP

Протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol) входит с состав стека TCP/IP. Протокол ICMP используется для тестирования доступности узлов сети и представляет собой эхо-протокол (на посланный запрос должен быть получен ответ). ICMP протокол работает с двумя типами сообщений: эхо-запрос и эхо-ответ . Компьютер или маршрутизатор посылают по сети эхо-запрос, в котором указывают IP-адрес узла, доступность которого нужно проверить. Компьютер (маршрутизатор), который получает эхо-запрос, формирует и отправляет эхо-ответ и возвращает сообщение узлу - отправителю запроса. В запросе могут содержаться некоторые данные (контрольная сумма), которые должны быть возвращены в ответе. Так как эхо-запрос и эхо-ответ передаются по сети внутри IPпакетов (см. рис. 9), то их успешная доставка означает нормальное функционирование всей транспортной системы интерсети.

Рисунок 9 - Инкапсуляция (вложение) ICMP-сообщения в IP-датаграмму

Для отправки эхо-запросов и приема эхо-ответов используется утилита (программа)ping .

2.4 Протокол DHCP

Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов.

При автоматическом статическом способе DHCP-сервер присваивает IP-адрес клиенту из пула (массива) наличных IP-адресов без вмешательства администратора. Границы пула (массива) назначаемых адресов задает администратор при конфигурировании DHCP-сервера. Между идентификатором клиента и присвоенным ему IP-адресом, как и при ручном назначении, существует соответствие. Оно устанавливается в момент первичного назначения сервером DHCP IP-адреса клиенту. При всех последующих запросах (на получение IP-адреса) сервер возвращает клиенту тот же самый IP-адрес.

При динамическом распределении адресов DHCP-сервер выдает адрес клиенту на ограниченное время, что дает возможность впоследствии повторно использовать этот IP-адреса другим компьютерами. Динамическое назначение адресов позволяет строить IP-сеть, количество узлов в которой, намного превышает количество имеющихся в распоряжении администратора IP-адресов.

DHCP обеспечивает надежный и простой способ конфигурации сети TCP/IP, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра "продолжительности аренды" (lease duration), которая определяет, как долго компьютер может использовать назначенный IP-адрес, перед тем как снова запросить его от сервера DHCP в аренду.

Протокол DHCP использует модель клиент-сервер. Во время старта системы DHCP - клиент, находится в состоянии "инициализации" и посылает широковещательное сообщение discover (обнаружить) для поиска в сети DHCPсервера. DHCP-сервер, получив это сообщение, отвечает на него сообщением offer (предложение), которое содержит IP-адрес и конфигурационную информацию. DHCP - клиент, получив предложение от DHCP-сервера, переходит в состояние "запрос" и отправляет сообщение request (запрос) DHCP-серверу. DHCP-сервер посылает сообщение DHCP-acknowledgment (подтверждение), содержащее тот же IP-адрес, который уже был послан ранее на стадии исследования, а также параметр аренды для

этого адреса. Кроме того, DHCP-сервер посылает параметры сетевой конфигурации. После того, как клиент получит это подтверждение, он переходит в состояние "связь", находясь в котором он может принимать участие в работе сети TCP/IP. По истечения срока аренды IP-адреса компьютер пытается обновить параметры аренды у DHCPсервера, а если этот IP-адрес не может быть выделен снова, то компьютеру выделяется другой IP-адрес. На рисунке 10 приведен формат DHCP пакета.

Рисунок 10 - Формат DHCP пакета

Использование протокола DHCP кроме своих достоинств имеет ряд недостатков. Во-первых, это проблема согласования информационной адресной базы в службах DHCP и DNS (система доменных имен). DNS служит для преобразования символьных имен в IP-адреса, если IP-адреса, будут, динамически изменятся сервером DHCP, то эти изменения необходимо также динамически вносить в базу данных сервера DNS. Хотя протокол динамического взаимодействия между службами DNS и DHCP уже реализован некоторыми фирмами (так называемая служба Dynamic DNS), стандарт на него пока не принят.

Во-вторых, нестабильность IP-адресов усложняет процесс управления сетью. Системы управления, основанные на протоколе SNMP, разработаны с расчетом на статичность IP-адресов.

В-третьих, централизация процедуры назначения адресов снижает надежность системы: при отказе DHCP-сервера все его клиенты оказываются не в состоянии получить IP-адрес и другую информацию о конфигурации. Последствия такого отказа могут быть уменьшены за счет использования в сети нескольких серверов DHCP, каждый из которых имеет свой пул IP-адресов.

Для работы с протоколом DHCP в ОС “Windows” используется команда ipconfig , которая служит для отображения всех текущих параметров сети TCP/IP и обновления параметров DHCP и DNS. При вызове командыipconfig можно использовать ряд параметров, например:

/all - вывод полной конфигурации TCP/IP для всех адаптеров. Без этого параметра командаipconfig выводит только IP-адреса, маску подсети и основной шлюз для каждого адаптера.

Выделим три главных элемента стандарта: формат кадра, систему сигнализации между рабочими станциями при осуществлении передачи данных по протоколу CSMA/CD и набор физических сред: коаксиальный кабель, витая пара, волоконно-оптический кабель.

Формат кадра Ethernet

На рис. 7-2 показан формат кадра Ethernet. Поля имеют следующие назначения:
— Преамбула: 7 байт, каждый из которых представляет чередование единиц и нулей 10101010. Преамбула позволяет установить битовую синхронизацию на приемной стороне.
— Ограничитель начала кадра (SFD, start frame delimiter): 1 байт, последовательность 10101011. указывает, что далее последуют, информационные поля кадра. Этот байт можно относить к преамбуле.
— Адрес назначения (DA, destination address): 6 байт, указывает МАС-адрес станции (МАС-адреса станций), для которой (которых) предназначен этот кадр. Это может быть единственный физический адрес (unicast), групповой адрес (multicast) или широковещательный адрес (broadcast).
— Адрес отправителя (SA, source address): б байт, указывает МАС-адрес станции, которая посылает кадр.
— Поле типа или длины кадра (Т or L, type or length): 2 байта. Существуют два базовых формата кадра Ethernet (в английской терминологии raw formats -сырые форматы) -EthernetII и IEEE 802.3 (рис. 7.2), причем различное назначение у них имеет именно рассматриваемое поле. Для кадра EthernetII в этом поле содержится информация о типе кадра. Ниже приведены значения в шестнадцатеричной системе этого поля для некоторых распространенных сетевых протоколов: 0х0800 для IP, 0х0806 для ARP, 0х809В для AppleTalk, 0х0600 для XNS, и 0х8137 для IPX/SPX. С указанием в этом поле конкретного значения (одного из перечисленных) кадр приобретает реальный формат, и в таком формате кадр уже может распространяться по сети.
— Для кадра IEEE 802,3 в этом поле содержится выраженный в байтах размер следующего поля — поля данных (LLC Data). Если эта цифра приводит к общей длине кадра меньше 64 байт, то за полем LLC Data добавляется поле Pad. Для протокола более высокого уровня не возникает путаницы с определением типа кадра, так как для кадра IEEE 802.3 значение этого поля не может быть больше 1500 (0x05DC). Поэтому, в одной сети могут свободно сосуществовать оба формата кадров, более того, один сетевой адаптер может взаимодействовать с обоими типами посредством стека протоколов.
— Данные (LLC Data): поле данных, которое обрабатывается подуровнем LLC. Сам по себе кадр IEEE 802.3 еще не окончательный. В зависимости от значений первых нескольких байт этого поля, могут быть три окончательных формата этого кадра IEEE 802.3:
— Ethernet_802.3 (не стандартный, в настоящее время устаревающий формат, используемый Novell) — первые два байта LLC Data равны 0xFFFF;
— EthernetSNAP (стандартный IEEE 802.2 SNAP формат, которому отдается наибольшее предпочтение в современных сетях, особенно для протокола TCP/IP) — первый байт LLC Data равен 0хАА;
— Ethernet_802.2 (стандартный IEEE 802.2 формат, используется фирмой Novell в NetWare 4.0) — первый байт LLC Data не равен ни 0xFF (11111111), ни 0хАА (10101010).

Дополнительное поле (pad — наполнитель) — заполняется только в том случае, когда поле данных невелико, с целью удлинения длины кадра до минимального размера 64 байта — преамбула не учитывается. Ограничение снизу на минимальную длину кадра необходимо для правильного разрешения коллизий.

Контрольная последовательность кадра (FCS, frame check sequence): 4-байтовое поле, в котором указывается контрольная сумма, вычисленная с использованием циклического избыточного кода по полям кадра, за исключением преамбул SDF и FCS.

Рис. 7.2. Два базовых MAC формата кадра Ethernet

Основные варианты алгоритмов случайного доступа к среде

Протокол CSMA/CD определяет характер взаимодействия рабочих станций в сети с единой общей для всех устройств средой передачи данных. Все станции имеют равноправные условия по передаче данных. Нет определенной последовательности, в соответствии с которой станции могут получать доступ к среде для осуществления передачи. Именно в этом смысле доступ к среде осуществляется случайным образом. Реализация алгоритмов случайного доступа представляется значительно более простой задачей, чем реализация алгоритмов детерминированного доступа. Поскольку в последнем случае требуется или специальный протокол, контролирующий работу всех устройств сети (например, протокол обращения маркера, свойственный сетям Token Ring и FDDI), или специальное выделенное устройство-мастер концентратор, который в определенной последовательности предоставлял бы всем остальным станциям возможность передавать (сети Arcnet, 100VG AnyLAN).

Однако сеть со случайным доступом имеет один, пожалуй главный, недостаток — это не совсем устойчивая работа сети при большой загруженности, когда может проходить достаточно большое время, прежде чем данной станции удается передать данные. Виной тому-коллизии, которые возникают между станциями, начавшими передачу одновременно или почти одновременно. При возникновении коллизии передаваемые данные не доходят до получателей, а передающим станциям приходится повторно возобновлять передачу.

Дадим определение: множество всех станций сети, одновременная передача любой пары из которых приводит к коллизии, называется коллизионным доменом (collision domain). Из-за коллизии (конфликта) могут возникать непредсказуемые задержки при распространении кадров по сети, особенно при большой загруженности сети (много станций пытаются одновременно передавать внутри коллизионного домена, > 20-25), и при большом диаметре коллизионного домена (> 2 км). Поэтому при построении сетей желательно избегать таких экстремальных режимов работы.

Проблема построения протокола, способного наиболее рационально разрешать коллизии, и оптимизирующего работу сети при больших загрузках, была одной из ключевых на этапе формирования стандарта Ethernet IEEE 802.3. Первоначально рассматривались три основных подхода в качестве кандидатов для реализации стандарта случайного доступа к среде (рис. 7.3): непостоянный, 1-постоянный и р-постоянный.

Рис. 7.3. Алгоритмы множественного случайного доступа (CSMA) и выдержка времени в конфликтной ситуации (collision backoff)

Непостоянный (nonpersistent) алгоритм. При этом алгоритме станция, желающая передавать, руководствуется следующими правилами.

1. Прослушивает среду, и, если среда свободна (т.е. если нет другой передачи или нет сигнала коллизии), передает, в противном случае — среда занята -переходит к шагу 2.
2. Если среда занята, ждет случайное (в соответствии с определенной кривой распределения вероятностей) время и возвращается к шагу 1.

Использование случайного значения ожидания при занятой среде уменьшает вероятность образования коллизий. Действительно, предположим в противном случае, что две станции практически одновременно собрались передавать, в то время, как третья уже осуществляет передачу. Если первые две не имели бы случайного времени ожидания перед началом передачи (в случае, если среда оказалась занятой), а только прослушивали среду и ждали, когда она освободится, то после прекращения передачи третьей станцией первые две начали бы передавать одновременно, что неизбежно приводило бы к коллизиям. Таким образом, случайное ожидание устраняет возможность образования таких коллизий. Однако неудобство этого метода проявляется в неэффективном использовании полосы пропускания канала. Поскольку может случиться, что к тому моменту, когда среда освободится, станция, желающая передавать, еще будет продолжать ожидать некоторое случайное время, прежде чем решится прослушивать среду, поскольку перед этим уже прослушивала среду, которая оказалась занятой. В итоге канал будет простаивать какое-то время, даже если только одна станция ожидает передачи.

1-постоянный (1-persistent) алгоритм. Для сокращения времени, когда среда не занята, мог бы использоваться 1-постоянный алгоритм. При этом алгоритме станция, желающая передавать, руководствуется следующими правилами.

1. Прослушивает среду, и, если среда не занята, передает, в противном случае переходит к шагу 2;
2. Если среда занята, продолжает прослушивать среду до тех пор, пока среда не освободится, и, как только среда освобождается, сразу же начинает передавать.

Сравнивая непостоянный и 1-постоянный алгоритмы, можно сказать, что в 1-постоянном алгоритме станция, желающая передавать, ведет себя более «эгоистично». Поэтому, если две или более станций ожидают передачи (ждут, пока не освободится среда), коллизия, можно сказать, будет гарантирована. После коллизии станции начинают решать, что им делать дальше.

Р-постоянный (p-persistent) алгоритм. Правила этого алгоритма следующие:
1. Если среда свободна, станция с вероятностью р сразу же начинает передачу или с вероятностью (1-р) ожидает в течение интервала времени Т. Интервал Т обычно берется равным максимальному времени распространения сигнала из конца в конец сети;
2. Если среда занята, станция продолжает прослушивание до тех пор, пока среда не освободится, затем переходит к шагу 1;
3. Если передача задержана на один интервал Т, станция возвращается к шагу 1.

И здесь возникает вопрос выбора наиболее эффективного значения параметра р. Главная проблема, как избежать нестабильности при высоких загрузках. Рассмотрим ситуацию, при которой n станций намерены передать кадры, в то время, как уже идет передача. По окончанию передачи ожидаемое количество станций, которые попытаются передавать, будет равно произведению количества желающих передавать станций на вероятность передачи, то есть пр. Если np > 1, то в среднем несколько станций будут пытаться передать сразу, что вызовет коллизию. Более того, как только коллизия будет обнаружена, все станции вновь перейдут к шагу 1, что вызовет повторную коллизию. В худшем случае, новые станции, желающие передавать, могут добавиться к n, что еще больше усугубит ситуацию, приведя, в конечном итоге, к непрерывной коллизии и нулевой пропускной способности. Во избежании такой катастрофы пр должно быть меньше единицы. Если же сеть подвержена возникновению состояний, когда много станций одновременно желают передавать, то необходимо уменьшать р. С другой стороны, когда р становиться слишком малым, даже отдельная станция может прождать в среднем (1 — р)/р интервалов Т, прежде чем осуществит передачу. Так если р=0,1, то средний простой, предшествующий передаче, составит 9Т.

Сетевые технологии

Статья получилась довольно объёмная, рассмотренные темы - форматы Ethenet фреймов, границы размеров L3 Payload, эволюция размеров Ethernet заголовков, Jumbo Frame, Baby-Giant, и много чего задето вскользь. Что-то вы уже встречали в обзорной литературе по сетям передачи данных, но со многим, однозначно, не сталкивались, если глубоко не занимались изысканиями.

Начнём с рассмотрения форматов заголовков Ethernet фреймов в очереди их появления на свет.

Форматы Ehternet фреймов.

1) Ethernet II

Рис. 1

Preamble – последовательность бит, по сути, не являющаяся частью ETH заголовка определяющая начало Ethernet фрейма.

DA (Destination Address) – MAC адрес назначения, может быть юникастом, мультикастом, бродкастом.

SA (Source Address) – MAC адрес отправителя. Всегда юникаст.

E-TYPE (EtherType) – Идентифицирует L3 протокол (к примеру 0x0800 – Ipv4, 0x86DD – IPv6, 0x8100- указывает что фрейм тегирован заголовком 802.1q, и т.д. Список всех EtherType - standards.ieee.org/develop/regauth/ethertype/eth.txt)

Payload – L3 пакет размером от 46 до 1500 байт

FCS (Frame Check Sequences) – 4 байтное значение CRC используемое для выявления ошибок передачи. Вычисляется отправляющей стороной, и помещается в поле FCS. Принимающая сторона вычисляет данное значение самостоятельно и сравнивает с полученным.

Данный формат был создан в сотрудничестве 3-х компаний – DEC, Intel и Xerox. В связи с этим, стандарт также носит название DIX Ethernet standard . Данная версия стандарта была опубликована в 1982г (первая версия, Ehernet I – в 1980г. Различия в версиях небольшие, формат в целом остался неизменным). В 1997г. году данный стандарт был добавлен IEEE к стандарту 802.3, и на данный момент, подавляющее большинство пакетов в Ethernet сетях инкапсулированы согласно этого стандарта.

2) Ethernet_802.3/802.2 (802.3 with LLC header)

Рис. 2

Как вы понимаете, комитет IEEE не мог смотреть спокойно, как власть, деньги и женщины буквально ускользают из рук. Поэтому, занятый более насущными проблемами, за стандартизацию технологии Ethernet взялся с некоторым опозданием (в 1980 взялись за дело, в 1983 дали миру драфт, а в 1985 сам стандарт), но большим воодушевлением. Провозгласив инновации и оптимизацию своими главными принципами, комитет выдал следующий формат фрейма, который вы можете наблюдать на Рисунке 2.

Первым делом обращаем внимание на то, что “ненужное” поле E-TYPE преобразовано в поле Length, которое указывало на количество байт следующее за этим полем и до поля FCS. Теперь, понять у кого длинее можно было уже на втором уровне системы OSI. Жить стало лучше. Жить стало веселее.

Но, указатель на тип протокола 3его уровня был нужен, и IEEE дало миру следующую инновацию - два поля по 1 байту - Source Service Access Point(SSAP ) и Destination Service Access Point (DSAP ). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?

Замечание: В жизни же это мало пригодилось и SSAP/DSAP значения обычно совпадают. К примеру SAP для IP – 6, для STP - 42 (полный список значений - standards.ieee.org/develop/regauth/llc/public.html)

Не давая себе передышки, в IEEE зарезервировали по 1 биту в SSAP и DSAP. В SSAP под указание command или response пакета, в DSAP под указание группового или индивидуального адреса (см. Рис. 6). В Ethernet сетях эти вещи распространения не получили, но количество бит в полях SAP сократилось до 7, что оставило лишь 128 возможных номера под указание вышестоящего протокола. Запоминаем этот факт, к нему мы ещё вернёмся.

Было уже сложно остановиться в своём стремлении сделать лучший формат фрейма на земле, и в IEEE фрейм формате появляется 1 байтное поле Control . Отвечающее, не много, не мало, за Connection-less или же Connection-oriented соединение!

Выдохнув и осмотрев своё детище, в IEEE решили взять паузу.

Замечание : Рассматриваемые 3 поля - DSAP, SNAP и Control и являются LLC заголовком.

3) «Raw» 802.3

Рис. 3

Данный «недостандарт» явил в мир Novell. Это были лихие 80-ые, все выживали, как могли, и Novell не был исключением. Заполучив ещё в процессе разработки спецификации стандарта 802.3/802.2, и лёгким движением руки выкинув LLC заголовок, в Novell получили вполне себе неплохой фрейм формат (с возможность измерения длины на втором уровне!), но одним существенным недостатком – отсутствием возможности указания вышестоящего протокола. Но, как вы уже могли догадаться, работали там ребята не глупые, и по здравому размышлению выработали решение – «а обратим ка мы свои недостатки в свои же достоинства», и ограничили этот фрейм-формат исключительно IPX протоколом, который сами же и поддерживали. И задумка хорошая, и план был стратегически верный, но, как показала история, не фортануло.

4) 802.3 with SNAP Header.

Время шло. В комитет IEEE приходило осознание того, что номера протоколов и деньги кончаются. Благодарные пользователи засыпали редакцию письмами, где 3-х байтный LLC заголовок ставился в один ряд с такими великими инновациями человечества, как оборудование собаки 5ой ногой, или же с рукавом, который можно использовать для оптимизации женской анатомии. Выжидать дальше было нельзя, настало время заявить о себе миру повторно.

Рис. 4

И в помощь страждущим от нехватки номеров протоколов (их всего могло быть 128 – мы упоминали), IEEE вводит новый стандарт фрейма Ethernet SNAP (Рис. 4). Основное нововведение - добавление 5-ти байтного поля Subnetwork Access Protocol (SNAP), которое в свою очередь состоит из двух частей – 3х байтного поля Organizationally Unique Identifier (OUI) и 2х байтного Protocol ID (PID) - Рис. 5.

Рис. 5

OUI или же vendor code – позволяет идентифицировать пропиетарные протоколы указанием вендора. К примеру, если вы отловите WireShark`ом пакет PVST+, то в поле OUI увидите код 0x00000c, который является идентификатором Cisco Systems (Рис. 6).

Рис. 6

Замечание: Встретить пакет с инкапсуляцией в формат фрейма 802.3 SNAP довольно легко и сейчас – это все протоколы семейства STP, протоколы CDP, VTP, DTP.

Поле PID это, по сути, то же поле EtherType из DIX Ethernet II - 2 байта под указание протокола вышестоящего уровня. Так как ранее, для этого использовались DSAP и SSAP поля LLC заголовка, то для указания того, что тип вышестоящего протокола нужно смотреть в поле SNAP, поля DSAP и SSAP принимают фиксированное значение 0xAA (также видно на Рис. 6)

Замечание: При использовании для переноса IP пакетов формата фрейма LLC/SNAP, IP MTU снижается с 1500 до 1497 и 1492 байт соответственно.

По заголовкам в формате фрейма в принципе всё. Хотел бы обратить внимание на ещё один момент в формате фрейма – размер payload. Откуда взялся этот диапазон - от 46 до 1500 байт?

Размер L3 Payload.

Откуда взялось нижнее ограничение, знает, пожалуй, каждый, кто хотя бы читал первый курикулум CCNA. Данное ограничение является следствием ограничения в размер фрейма в 64 байта (64 байта – 14 байт L2 заголовок - 4 байта FCS = 46 байт) накладываемого методом CSMA/CD – время требуемое на передачу 64 байт сетевым интерфейсом является необходимым и достаточным для определения коллизии в среде Ethernet.
Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.

А вот откуда взялись эти пресловутые 1500 байт, вопрос сложнее. Я нашел следующее объяснение - предпосылок на введение верхнего ограничения размера фрейма было несколько:

Задержка при передаче – чем больше фрейм, тем дольше длится передача. Для ранних сетей, где Collision домен не ограничивался портом, и все станции должны были ждать завершения передачи, это было серьёзной проблемой.
Чем больше фрейм, тем больше вероятность того что фрейм при передаче будет поврежден, что приведет к необходимости повторной передачи, и все устройства в collision домене будут вынуждены опять ожидать.
Ограничения, накладываемые памятью используемой под интерфейс буферы – на тот момент (1979г) увеличение буферов значительно удорожало стоимость интерфейса.
Ограничение, вносимое полем Length/Type – в стандарте закреплено, что все значения выше 1536 (от 05-DD до 05-FF.) указывают на EtherType, соответственно длина должна быть меньше 05-DC. (У меня правда есть подозрение, что это скорее следствие, чем предпосылка, но вроде инфа от разработчиков стандарта 802.3)

Итого, в стандарте 802.3 размер фрейма ограничивался 1518 байтами сверху, а payload 1500 байтами (отсюда и дефолтный размер MTU для Ethernet интерфейса).

Замечание: Фреймы меньше 64 байт называются Runts, фреймы больше 1518 байт называются Giants. Просмотреть кол-во таких фреймов полученных на интерфейсе можно командой show interface gigabitEthernet module/number и show interface gigabitEthernet module/number counters errors. Причём до IOS 12.1(19) в счётчики шли как фреймы с неверным, так и верным CRS (хотя вторые не всегда дропались – зависит от платформы и условий). А вот начиная с 12.1.(19) отображаются в этих счётчиках только те runt и giant фреймы, которые имеют неверный CRS, фреймы меньше 64 байт, но с верным CRS (причина возникновения обычно связана с детегированием 802.1Q или источником фреймов, а не проблемами физического уровня) с этой версии попадают в счётчик Undersize, дропаются они, или же форвардятся дальше, зависит от платформы.

Эволюция размеров 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.

Отдельно обратим внимание на спецификации 802.3AS - увеличивает максимальный размер фрейма до 2000 (но сохраняет размер MTU в 1500 байт!). Увеличение приходится на заголовок и трейлер. Изначально увеличение планировалось на 128 байт – для нативной поддержки стандартом 802.3 вышеперечисленных расширений, но в итоге сошлись на 2х тысячах, видимо, чтобы два раза не собираться (или как говорят в IEEE – this frame size will support encapsulation requirements of the foreseeable future). Стандарт утвержден в 2006 году, но кроме как на презентациях IEEE, я его не встречал. Если у кого есть что добавить здесь (и не только здесь) – добро пожаловать в комменты. В целом тенденция увеличения размера фрейма при сохранении размера PAYLOAD, порождает у меня в голове смутные сомнения в правильности выбранного направления движения.

Замечание: Немного в стороне от перечисленного обосновался FCoE фрейм – размер фрейма до 2500 байт, зачастую, эти фреймы называются mini-jumbo. Для их саппорта необходимо включать поддержку jumbo-frame.

И последний «бастард» Ethernet это Jumbo Frame (хотя если перевести Jumbo, то вырисовывается скорее Ходор – отсылка к Game of Thrones). Под это описание попадают все фреймы превосходящие размером стандарт в 1518 байт, за исключением рассмотренных выше. Jumbo пакеты никак не отражены в спецификациях 802.3 и поэтому реализация остаётся на совести каждого конкретного вендора. Тем не менее, Jumbo фреймы существуют столько же, сколько существует Ethernet. Определено это следующим:

Выгода соотношения Payload к заголовкам. Чем больше это соотношение, тем эффективней мы можем использовать линии связи. Конечно здесь разрыв будет не такой как в сравнении с использованием пакетов в 64 байт и 1518 байт для TCP сессий. Но свои 3-8 процентов, в зависимости от типа трафика выиграть можно.
Значительно меньшее количество заголовков генерирует меньшую нагрузку на Forwading Engine, также и на сервисные Engine. К примеру, frame rate для 10G линка загруженного фреймами по 1500 байт равен 812 744 фреймов в секунду, а тот же линк загруженный Jumbo фреймами в 9000 байт генерирует фрейм рейт всего лишь в 138 587 фрейм в секунду. На рисунке 7 приведены график из отчёта Alteon Networks (ссылка будет внизу статьи) утилизации CPU и гигабитного линка, в зависимости от типа используемого размера фрейма.
Увеличение TCP Throughput при изменении размера MTU -

Подуровень управления доступом к среде

В зависимости от скорости передачи данных и передающей среды существует несколько вариантов технологий локальных сетей. Независимо от способа передачи стек сетевого протокола и программы работают одинаково практически во всех нижеперечисленных вариантах.

Сеть Ethernet

Историческая справка. Зарождение Ethernet

Манчестерский код

Ни в одной из версий Ethernet не применяется прямое двоичное кодирование бита 0 напряжением 0 В и бита 1 - напряжением 5В, так как такой способ приводит к неоднозначности. Если одна станция посылает битовую строку 00010000, то другая может интерпретировать ее как 10000000 или 01000000, так как они не смогут отличить отсутствие сигнала (0 В) от бита 0 (0 В). Можно, конечно, кодировать единицу положительным напряжением +1 В, а ноль - отрицательным напряжением -1 В. Но при этом все равно возникает проблема, связанная с синхронизацией передатчика и приемника. Разные частоты работы их системных часов могу привести к рассинхронизации и неверной интерпретации данных. В результате приемник может потерять границу битового интервала. Особенно велика вероятность этого в случае длинной последовательности нулей или единиц. Таким образом, принимающей машине нужен способ однозначного определения начала, конца и середины каждого бита без помощи внешнего таймера. Это реализуется с помощью манчестерского кодирования. В манчестерском коде каждый временной интервал передачи одного бита делится на два равных периода. Бит со значением 1 кодируется высоким уровнем напряжения в первой половине интервала и низким - во второй половине, а нулевой бит кодируется обратной последовательностью - сначала низкое напряжение, затем высокое. Такая схема гарантирует смену напряжения в середине периода битов, что позволяет приемнику синхронизироваться с передатчиком. Недостатком манчестерского кодирования является то, что оно требует двойной пропускной способности линии по отношению к прямому двоичному кодированию, так как импульсы имеют половинную ширину. Например, для того чтобы отправлять данные со скоростью 10 Мбит/с, необходимо изменять сигнал 20 миллионов раз в секунду.

Формат кадра Ethernet

Преамбула (8 байт). Ethernet-кадр начинается с 8-байтового поля преамбулы. В каждый из первых 7 байт преамбулы записывается значение 10101010, а в последний байт - значение 10101011. Первые 7 байт должны «разбудить» принимающие адаптеры и помочь им синхронизировать свои таймеры с часами отправителя. Как уже отмечалось, адаптер А должен передать кадр со скоростью 10 Мбит/с, 100 Мбит/с или 1 Гбит/с в зависимости от типа локальной Ethernet-сети. Однако поскольку ничего не бывает абсолютно точным в реальном мире, скорость передачи всегда будет несколько отличаться от номинала. Величина этого отклонения скорости другим адаптерам локальной сети заранее не известна. Таким образом, первые 62 бита преамбулы, представляющие собой чередующиеся нули и единицы, позволяют приемнику с достаточной точностью настроиться на скорость передатчика, а последние два разряда (две единицы подряд) сообщают адаптеру В, что преамбула закончилась и следом идет уже первый информационный байт поля кадра. Адаптер В понимает, что следующие 6 байт содержат адрес получателя.

Адрес получателя (6 байт). Это поле содержит LAN-адрес принимающего адаптера. Получив Ethernet-кадр с адресом получателя, отличным от собственного физического адреса или широковещательного адреса локальной сети, адаптер отбрасывает кадр. В противном случае он передает содержимое поля данных сетевому уровню.

Адрес отправителя (6 байт). Это поле содержит LAN-адрес адаптера, передающего кадр в локальную сеть. Поле типа (2 байта). Поле типа позволяет локальной Ethernet-сети «мультиплексировать» протоколы сетевого уровня. Чтобы понять, что это означает, вспомним, что хосты могут помимо протокола IP использовать и другие протоколы. В самом деле, любой хост может поддерживать несколько протоколов сетевого уровня - разные протоколы для разных приложений. По этой причине, получив Ethernet-кадр, адаптер В должен знать, какому протоколу сетевого уровня он должен передать (то есть демультиплексировать) содержимое поля данных. Каждому сетевому протоколу (например, IP, Novell IPX или AppleTalk) присвоен зафиксированный в стандарте номер. Обратите внимание, что поле типа аналогично полю протокола в дейтаграмме сетевого уровня и полю номера порта сегмента транспортного уровня. Все эти поля служат для связи протокола одного уровня с протоколом уровнем выше.

Поле данных (от 46 до 1500 байт). Это поле содержит IP-дейтаграмму. Максимальная единица передачи (Maximal Transfer Unit, MTU) в Ethernet-сети составляет 1500 байт. Это означает, что если размер IP-дейтаграммы превышает 1500 байт, тогда хост должен разбить ее на отдельные фрагменты (см. подраздел «Фрагментация IP-дейтаграмм» в разделе «Интернет-протокол» главы 4). Минимальный размер поля данных равен 46 байт. Это означает, что если размер IP-дейтаграммы меньше 46 байт, то данные, помещаемые в это поле, дополняются байтами-заполнителями. При этом сетевой уровень получает дейтаграмму от канального уровня с этими дополнительными байтами и отсекает все лишнее сам, ориентируясь на поле длины в заголовке IP-дейтаграммы. Вот почему на практике в WireShark мы иногда получали 6 нулевых байтов в приходящем пакете.

CRC (4 байта). Назначение поля CRC заключается в том, чтобы получающий адаптер мог определить, не исказился ли кадр при передаче, то есть обнаружить ошибки в кадре. Искажение битов в кадре может быть вызвано ослаблением сигнала в канале, скачками напряжения, наводками в кабелях и интерфейсных платах.

Минимальный размер кадра

Если кадр короткий, а расстояние между компьютерами большое, то отправитель может не обнаружить коллизии. Если отправитель закончит отсылать кадр до прихода сигнала о коллизии, то он подумает, что сигнал о коллизии относится не к нему.

Связь характеристик канала

Пусть M - минимальный размер кадра

P – пропускная способность канала

M/P – время записи кадра в канал

Связь между скоростью, длиной канала и минимальным размером кадра:

M/P > 2T, где T=L/c

P=10 Mb/s M=64 B тогда L<7680 м

P=10 Gb/s M=64 B тогда L<7,68 м

Между тем, кроме верхней границы размера поля данных очень важна и нижняя граница. Поле данных, содержащее 0 байт, вызывает определенные проблемы. Дело в том, что когда приемопередатчик обнаруживает столкновение, он обрезает текущий кадр, а это означает, что отдельные куски кадров постоянно блуждают по кабелю. Чтобы было легче отличить нормальные кадры от мусора, сети Ethernet требуется кадр размером не менее 64 байт (от поля адреса получателя до поля контрольной суммы включительно). Если в кадре содержится меньше 46 байт данных, в него вставляется специальное поле Pad, с помощью которого размер кадра доводится до необходимого минимума. Другой (и даже более важной) целью установки ограничения размера кадра снизу является предотвращение ситуации, когда станция успевает передать короткий кадр раньше, чем его первый бит дойдет до самого дальнего конца кабеля, где он может столкнуться с другим кадром. Эта ситуация показана на рис. 4.17. В момент времени 0 станция А на одном конце сети посылает кадр. Пусть время прохождения кадра по кабелю равно т. За мгновение до того, как кадр достигнет конца кабеля (то есть в момент времени т - е), самая дальняя станция В начинает передачу. Когда станция В замечает, что получает большую мощность, нежели передает сама, она понимает, что произошло столкновение. Тогда она прекращает передачу и выдает 48-битный шумовой сигнал, предупреждающий остальные станции. Примерно в момент времени 2т отправитель замечает шумовой сигнал и также прекращает передачу. Затем он выжидает случайное время и пытается возобновить передачу. Если размер кадра будет слишком маленьким, отправитель закончит передачу прежде, чем получит шумовой сигнал. В этом случае он не сможет понять, произошло это столкновение с его кадром или с каким-то другим, и, следовательно, может предположить, что его кадр был успешно принят. Для предотвращения такой ситуации все кадры должны иметь такую длину, чтобы время их передачи было больше 2т. Для локальной сети со скоростью передачи 10 Мбит/с при максимальной длине кабеля в 2500 м и наличии четырех повторителей (требование спецификации 802.3) (мое: вероятно L=2500*5, где 5 – максимальное количество участков кабеля между компьютерами) минимальное время передачи одного кадра должно составлять в худшем случае примерно 50 мкс, включая время на прохождение через повторитель, которое, разумеется, отлично от нуля. Следовательно, длина кадра должна быть такой, чтобы время передачи было по крайней мере не меньше этого минимума. При скорости 10 Мбит/с на передачу одного бита тратится 1000 не, значит, минимальный размер кадра должен быть равен 500 бит. При этом можно гарантировать, что система сможет обнаружить коллизии в любом месте кабеля. Из соображений большей надежности это число было увеличено до 512 бит или 64 байт. Кадры меньшего размера с помощью поля Pad искусственно дополняются до 64 байт. По мере роста скоростей передачи данных в сети минимальный размер кадра должен увеличиваться, или должна пропорционально уменьшаться максимальная длина кабеля. Для 2500-метровой локальной сети, работающей на скорости 1 Гбит/с, минимальный размер кадра должен составлять 6400 байт. Или же можно использовать кадр размером 640 байт, но тогда надо сократить максимальное расстояние между станциями сети до 250 м. По мере приближения к гигабитным скоростям подобные ограничения становятся все более суровыми.