Рис. 6.37. Формат кадра IEEE 802.3
Существенным различием между двумя форматами является то, что поле "тип пакета" (Ethertype
) кадра Ethernet используется для обозначения размера кадра в случае IEEE 802.3. В кадре Ethernet это поле идентифицирует сетевой протокол, использующий данный кадр. К счастью, значения идентификаторов протоколов превышают 1500 — максимальный размер данных кадра, поэтому драйвер может легко определить используемый формат.
Другой, также часто используемый метод доступа, используемый в кольцевых топологиях сетей, заключается в передаче между сетевыми устройствами, подключенными к кольцу, маркера — небольшого пакета, играющего роль эстафетной палочки (например, в сетях Token Ring). Пока ни одно из устройств не передает данные, маркер, циркулирующий в кольце, имеет флаг "свободный". При необходимости передачи устройство дожидается свободного маркера, изменяет его флаг на "занятый" и передает пакет данных сразу же за маркером. Поскольку теперь в сети отсутствует свободный маркер, все остальные устройства должны воздержаться от передачи. При этом устройство, которому адресованы данные, при получении скопирует их в свой буфер. Занятый маркер совершает круг и возвращается к передавшему пакет устройству. Последнее извлекает из сети маркер и пакет данных, изменяет флаг маркера на "свободный" и вновь передает его в кольцо. Таким образом, ситуация возвращается к исходной.
Технология FDDI, также использует метод передачи маркера, правда, несколько отличающийся от только что описанного. Основное отличие заключается в том, что устройство сразу же после передачи пакета помещает свободный маркер. Если какое-либо устройство желает передать данные, оно может воспользоваться этим маркером, также поместив новый свободный маркер вслед за переданным пакетом. Таким образом, в кольце может одновременно существовать несколько пакетов, что повышает эффективность использование пропускной способности сети.
Формат кадров в сетях Token Ring определяется двумя стандартами — IEEE 802.5 и FDDI. Однако за исключением октета контроля доступа эти форматы не отличаются друг от друга. Формат кадра IEEE 802.5 приведен на рис. 6.38.
Рис. 6.38. Формат кадра IEEE 802.5
Протокол LLC
Протокол LLC обеспечивает большую часть услуг уровня канала данных. Этот протокол был разработан на основе другого протокола уровня канала данных — HDLC, однако обладает меньшей функциональностью по сравнению со своим родителем.
Формат кадра LLC представлен на рис. 6.39. Основными полями заголовка кадра являются DSAP
и SSAP
, которые определяют адреса точек доступа (SAP) соответственно отправителя и получателя данных. Кадр LLC также может содержать дополнительный заголовок SNAP (Sub-Network Access Point), также называемый адресом логической точки доступа (Logical SAP, LSAP).
Рис. 6.39. Формат кадра LLC
Инкапсуляция IP
При работе в локальной сети на базе технологии CSMA/CD возможны два варианта инкапсуляции датаграмм IP в кадры уровней LLC и MAC.
Первый заключается в использовании кадров Ethernet 2.0. В этом случае поле данных (1500 октетов) полностью принадлежит IP-датаграмме, a SAP адресуется полем "тип пакета", которое содержит значение параметра Ethertype
— индекса протокола верхнего уровня. В случае IP это значение равно 0x0800. Значения Ethertype для других протоколов приведены в табл. 6.11.
Таблица 6.11. Значение Ethertype для некоторых протоколов
0x0000–0x05DC | Поле Length IEEE 802.3 |
0x0800 | Internet IP (IPv4) |
0x0806 | ARP |
0x6003 | DEC DECNET Phase IV Route |
0x8137 | Novell IPX |
Второй вариант предполагает использование формата IEEE 802.3. В этом случае IP-датаграмма инкапсулируется в кадр LLC, а адресация SAP осуществляется в заголовке SNAP с помощью идентификатора Ethertype. При этом поля DSAP
и SSAP
не используются, и их значения устанавливаются равными 0xAA. Заметим, что в этом случае максимальный размер IP-датаграммы составляет 1492 октета.
При передаче данных TCP/IP в сетях Token Ring используется формат кадра IEEE 802.5, инкапсулирующий кадр LLC с заголовком SNAP, как описано выше.
Внутренняя архитектура
Как уже говорилось, драйвер, реализующий поставщика услуг уровня канала данных, состоит из двух частей: аппаратно-зависимой и аппаратно-независимой. Соответственно драйвер хранит отдельные структуры данных, необходимые для работы этих частей. Архитектура драйвера приведена на рис. 6.40.
Рис. 6.40. Архитектура драйвера DLPI