Шаблон технологии Ethernet, написан в доке IEEE 802,3. Это единственное описание кадра формата уровня MAC. В сети Ethernet реализован только один тип кадра канального уровня, заголовок которого есть множество заголовков подуровней MAC и LLC что есть некой .

• Ethernet DIX/Ethernet II , появился в 1980 году в результате совместной роботы трех фирм Xerox, Intel и Digital которые представил версию 802,3в качестве международного стандарта;
• Комитет принял 802,3 и немного переделал его. Так появились 802,3/LLC, 802,3/802,2 или Novell 802,2 ;
• Raw 802,3 или Novell 802,3 — созданы для ускорения работы своего стека протоколов в сетях Ethernet;
• Ethernet SNAP является итогом комитета 802,2 которые приведен к общему стандарту и стал гибок к будущим возможным добавлением полей;

Сегодня сетевое аппаратное и программное обеспечение умеют работать со всеми форматами кадров, и распознавание кадров работает автоматически что уменьшает и одним из . Форматы кадров показано на рис.1.

Рисунок 1

Кадр 802.3/LLC

Заголовок этого кадра объединяет поля заголовком кадров IEEE 802,3 и 802,2. Стандарт 802,3 состоит из:

• Поле преамбулы — называется полем синхронизирующих байтов — 10101010. В манчестерском кодировании этот код модифицируется в физической среде в сигнал с частотой 5 МГц.
• Начальный ограничитель кадра — является одним байтом 10101011. Это поле указывает на то, что следующий байт — это первый байт заголовка кадра.
• Адрес назначения — это поле может быть длиной 6 или 2 байта. Обычно это поле используют для MAC-адреса в 6 байт.
• Адрес источника — это поле которое содержит 6 или 2 байта MAC-адреса узла отправителя. Первый бит всегда является — 0.
• Длина — поле которое имеет размер 2 байта, и содержит длину поля данных в кадре.
• Поле данных — поле может иметь от 0 до 1500 байт. Но если вдруг данные занимают меньше 46 байт, то используется поле заполнителя , который дополняет поле до 46 байт.
• Поле заполнителя — Обеспечивает заполнение поля данных, если там вес меньший 46 байт. Нужен для корректной работы механизму обнаружений коллизий.
• Поле контрольной последовательности кадра — в этом поле записывается контрольная сума размером в 4 байта. Используется алгоритм CRC-32/

Этот кадр есть кадр подуровня MAC, в его поле данных влажуется кадр подуровня LLC с удаленными флагами в конце и начала кадра который передается через .

Кадр Raw 802.3/Novell 802,3

Раньше этот кадр был протоколом сетевого уровня в ОС MetWare. Но теперь, когда нужда в идентификации протокола верхнего уровня отпала, то кадр был инкапсулирован в кадр MAC кадра LLC.

Кадр Ethernet DIX/Ethernet II

Этот кадр имеет структуру, которая похожа на структуру Ras 802,3. Но 2-байтовое поле длины здесь имеет назначения поля типа протокола. Указывает тип протокола верхнего уровня, вложившей свой пакет в поле данных этого кадра. Различают эти кадры по длине поля, если значении меньше 1500 то это поле длины, если больше — то типа.

Кадр Ethernet SNAP

Кадр появился в результате устранения разнобоя в кодировках типов протоколов. Протокол используется также в протоколе IP при инкапсуляции следующих сетей: Token Ring, FDDI, 100VC-AnyLan. Но при передаче IP пакетов через Ethernet протокол использует кадры Ethernet DIX.

Протокол IPX

Этот протокол может использовать все четыре типа кадра Ethernet. Он определяет тип по проверки отсутствия или наличия поля LLC. Также за полями DSAP/SSAP. Если значение полей равны 0хАА, то это кадр SNAP иначе это 802,3/LLC.

Аппаратный

Аппаратн

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

получателя

назначения

источника

отправителя

отправителя

получате

(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-адреса, маску подсети и основной шлюз для каждого адаптера.

Detection - CSMA/CD ). Все компьютеры сети имеют доступ к общей шине через встроенный в каждый компьютер сетевой адаптер , используя полудуплексный режим передачи. Схема подключения компьютеров по коаксиальному кабелю приведена на рис.6.1 .

Рис. 6.1.

Станции на традиционной локальной сети Ethernet могут быть соединены вместе, используя физическую шину или звездную топологию, но логическая топология - всегда шинная. Под этим мы подразумеваем, что среда (канал) разделена между станциями и только одна станция одновременно может использовать ее. Также подразумевается, что все станции получают кадр , посланный станцией (широковещательная передача). Адресованный пункт назначения сохраняет кадр , в то время как остальные отбрасывают ее. Каким образом в этой ситуации мы можем убедиться, что две станции не используют среду в одно и то же время? Ответ: если их кадры столкнутся друг с другом. CSMA/CD разработан, чтобы решить эту проблему согласно следующим принципам:

1. Каждая станция имеет равное право на среду (коллективный доступ).
2. Каждая станция, имеющая кадр для того, чтобы послать его, сначала "слушает" (отслеживает) среду. Если в среде нет данных, станция может начать передачу (слежение за несущей частотой).
3. Может случиться, что две станции, следящие за средой, находят, что она не занята, и начинают посылать данные. В этом случае возникает конфликт, называемый коллизией.

Протокол заставляет станцию продолжать следить за линией после того, как передача началась. Если есть конфликт , то все станции его обнаруживают, каждая передающая станция передает сигнал сбоя в работе, чтобы уничтожить данные линии, и после этого каждый раз ждет различное случайное время для новой попытки. Случайные времена предотвращают одновременную повторную посылку данных. Перед началом передачи узел должен убедиться, что несущая среда не занята, признаком чего является отсутствие на ней несущей частоты. Если среда свободна, то узел имеет право начать передачу кадра определенного формата. Предположим, что узлу 2 требуется передать кадр узлу N. Обнаружив, что среда свободна, узел 2 начинает передачу кадра ( рис. 6.2), которая предваряется преамбулой (preamble) , состоящей из 7 байт вида 10101010, и байта начала кадра (Start of Frame Delimiter - SFD) вида 10101011. Эти комбинации нужны приемнику для вхождения в побитовый и кадровый синхронизм с передатчиком. Кадр заканчивается полем последовательности контроля кадра ( FCS - Frame Check Sequence ) длиной 4 байта (на рис. 6.2 не показано). Сигналы передатчика распространяются по кабелю в обе стороны, и все узлы распознают начало передачи кадра. Только узел N опознает свой собственный адрес (МАС- адрес назначения) в начале кадра и записывает его содержимое в свой буфер для обработки. Из принятого кадра определяется адрес источника (МАС- адрес источника), которому следует выслать кадр -ответ. Получатель пакета на 3-м уровне определяется в соответствии с полем Тип протокола (Protocol Type) : значение 0х0800 - адрес модуля IP , 0806 - адрес модуля ARP . Минимальное и максимальное значения длины поля для протоколов верхних уровней - 46 и 1500 байт соответственно. Порядок передачи бит кадра: слева направо / снизу вверх ( рис. 6.2), цифрами обозначены длины полей кадра в байтах.

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

Рис. 6.2.

Иногда возникают ситуации, когда один узел уже начал передачу, но другой узел еще не успел это обнаружить и также начинает передачу своего кадра. Такая ситуация захвата свободной среды более чем одним узлом называется коллизией . Механизм разрешения коллизии состоит в следующем ( рис. 6.3):

Рис. 6.3.

Если уровень принимаемого сигнала не превышает порогового значения, то узел продолжает передачу, если же превышает, то узел прекращает передачу кадра и посылает в сеть специальную 32-битную jam -комбинацию (сигнал коллизии) с нерегламентированной последовательностью, просто приводящей к повышению уровня сигнала в локальной сети из-за увеличения амплитуды импульсов манчестерского кода суммарного сигнала. После этого узел, обнаруживший коллизию, делает случайную паузу и затем снова может повторить попытку передачи кадра. Число повторных попыток не может превысить 16. Если же и после 16-й попытки кадр вызвал коллизию, то он отбрасывается. При большом количестве узлов вероятность коллизии возрастает, и пропускная способность сети Ethernet падает, т.к. сеть все большее время занята обработками коллизий и отбрасыванием кадров. Три фактора определяют работу CSMA/CD : минимальная длина кадра, скорость передачи данных и домен конфликта.

Станции нужно ждать определенное время, чтобы убедиться, что на линии нет никаких данных, - это время равно минимальной длине кадра, разделенной на скорость передачи (время, которое требуется, чтобы передать кадр минимальной длины), и пропорционально времени, необходимому для первого бита, чтобы пройти максимальное сетевое расстояние ( домен конфликта). Другими словами, мы имеем:

Минимальная длина кадра/Скорости передачи пропорциональна Домен конфликта/Скорость Распространения

В традиционной Локальной сети Ethernet , минимальная длина кадра - 520 битов, скорость передачи - 10 Mбит/с, скорость распространения - почти равна скорости света, и домен конфликта - около 2500 метров.

Рис. 6.5.

• Преамбула . Преамбула кадров содержит 7 байтов (56 битов) чередующихся нулей и единиц, которые приводят в готовность систему для приема прибывающего кадра и подготавливают ее для синхронизации с помощью тактовых импульсов. Преамбула фактически добавляется на физическом уровне и не является (формально) частью кадра.
• Ограничитель начала кадра (SFD - Start Frame Delimiter). Поле SFD (1 байт: 10101011) отмечает начало кадра и указывает станции на окончание синхронизации. Последние два бита - 11 (две единцы) - сигнал, что следующее поле - адрес получателя.
• Адрес получателя (DA - Destination Address) . Поле DA насчитывает 6 байтов и содержит физический адрес станции пункта назначения или промежуточного звена.
• Исходный адрес (SA -

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

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

Сеть 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 м. По мере приближения к гигабитным скоростям подобные ограничения становятся все более суровыми.

Рис. 1. Формат кадра Ethernet DIX (II)

Первые два поля заголовка отведены под адреса:

DA (Destination Address) - МАС-адрес узла назначения;

SA (Source Address) - МАС-адрес узла отправителя. Для доставки кадра достаточно одного адреса - адреса назначения; адрес источника помещается в кадр для того, чтобы узел, получивший кадр, знал, от кого пришел кадр и кому нужно на него ответить. Принятие решения об ответе не входит в компетенцию протокола Ethernet, это дело протоколов верхних уровней. Ethernet же только выполнит такое действие, если с сетевого уровня поступит соответствующее указание.

Поле Т (Туре, или EtherType) содержит условный код протокола верхнего уровня, данные которого находятся в поле данных кадра, например шестнадцатеричное значение 08-00 соответствует протоколу IP. Это поле требуется для поддержки интерфейсных функций мультиплексирования и демультиплексирования кадров при взаимодействии с протоколами верхних уровней.

Поле данных может содержать от 46 до 1500 байт. Если длина пользовательских данных меньше 46 байт, то это поле дополняется до минимального размера байтами заполнения. Эта операция требуется для корректной работы метода доступа Ethernet (он рассматривается в следующем разделе).

Поле контрольной последовательности кадра (Frame Check Sequence, FCS) состоит из 4 байт контрольной суммы. Это значение вычисляется по алгоритму CRC-32.

Кад р Ethernet DIX (II) не отражает разделения канального уровня Ethernet на уровень MAC и уровень LLC: его поля поддерживают функции обоих уровней, например интерфейсные функции поля Г относятся к функциям уровня LLC, в то время как все остальные поля поддерживают функции уровня MAC.

Существуют еще три стандартных формата кадра 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 по приведениюпредыдущих форматов кадров к некоторому общему стандарту и приданию кадру необходимой гибкости для учета в будущем возможностей добавления полей или изменения их назначения.

Как уже было сказано, в настоящее время оборудованием Ethernet используются только кадры Ethernet DIX (II). Остальные форматы кадров, в том числе кадр 802.3/LLC, попрежнему формально являющийся стандартным, вышли из употребления из-за более сложного формата, который оказался не нужен в условиях существования единой технологии канального уровня.