Форматы кадров подуровня LLC

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

Протокол LLC занимает место между сетевыми протоколами и протоколами подуровня MAC [2, 4, 12]. Протоколы сетевого уровня передают через межуровневый интерфейс данные для протокола LLC - свой пакет (например, пакет IP, IPX или NetBEUI), адресную информацию об узле назначения, а также требования к качеству транспортных услуг, которое протокол LLC должен обеспечить. Протокол LLC помещает пакет протокола верхнего уровня в свой кадр, который дополняется необходимыми служебными полями. Далее через межуровневый интерфейс протокол LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу подуровня MAC, который упаковывает кадр LLC в свой кадр (рис. 4.6).

Рисунок 4.6 - Расположение подуровней и форматы протоколов

В основу протокола LLC положен протокол HDLC (High-level Data Link Control Procedure), являющийся стандартом ISO.

В соответствии со стандартом 802.2 подуровень управления логическим каналом LLC предоставляет верхним уровням три типа процедур [2]:

- LLC1 — процедура без установления соединения и без подтверждения;

- LLC2 — процедура с установлением соединения и подтверждением;

- LLC3 — процедура без установления соединения, но с подтверждением.

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

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

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

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

Следует отметить, что предоставление подтверждений является, скорее, оптимизацией, чем требованием. Сетевой уровень всегда может послать пакет и ожидать подтверждения его доставки. Если за установленный период времени подтверждение не будет получено отправителем, сообщение может быть выслано еще раз. Проблема при использовании данной стратегии заключается в том, что кадры обычно имеют жесткое ограничение максимальной длины, связанное с аппаратными требованиями. Пакеты сетевого уровня таких ограничений не имеют. Таким образом, если среднее сообщение разбивается на 10 кадров и 20% из них теряется по дороге, то передача сообщения таким методом может занять очень много времени. Если подтверждать получение отдельных кадров и в случае ошибки посылать их повторно, передача всего сообщения займет гораздо меньше времени. В таких надежных каналах, как, например, оптоволоконный кабель, накладные расходы на подтверждения на канальном уровне только снизят пропускную способность канала, однако для беспроводной связи такие расходы окупятся и уменьшат время передачи длинных сообщений. Данный подход аналогичен организации векторного и адресного переспроса обнаруженных искаженных пакетов (кадров) в системах передачи данных [13, 14].

Использование одного из трех режимов работы подуровня LLC зависит от стратегии разработчиков конкретного стека протоколов [4]. Например, в стеке TCP/IP подуровень LLC всегда работает в режиме LLC1, выполняя простую работу извлечения из кадра и демультиплексирования пакетов различных протоколов — IP, ARP. Аналогично используется стеком IPX/SPX подуровень LLC.

По своему назначению все кадры подуровня LLC (называемые в стандарте 802.2 блоками данных - Protocol Data Unit, FUU) подразделяются на три типа - информационные, управляющие и ненумерованные.

Информационные кадры (Information) предназначены для передачи информации в процедурах с установлением логического соединения LLC2 и должны обязательно содержать поле информации.

Управляющие кадры (Supervisory) предназначены для передачи команд и ответов в процедурах с установлением логического соединения LLC2, в том числе запросов на повторную передачу искаженных информационных блоков.

Ненумерованные кадры (Unnumbered) предназначены для передачи ненумерованных команд и ответов, выполняющих в процедурах без установления логического соединения передачу информации, идентификацию и тестирование LLC-подуровня, а в процедурах с установлением логического соединения LLC2 — установление и разъединение логического соединения, а также информирование об ошибках.

Все типы кадров подуровня LLC имеют единый формат (рис. 4.7).

Рисунок 4.7 - Структура кадра подуровня LLC

Кадр LLC обрамляется двумя однобайтовыми полями «Флаг», имеющими значение 01111110. Флаги используются на подуровнях МАС для определения границ кадра LLC. Кадр LLC вкладывается в кадр подуровня МАС, при этом флаги кадра LLC отбрасываются.

Кадр LLC содержит поле данных и заголовок, который состоит из трех полей:

- адреса точки входа службы назначения (Destination Service Access Point, DSAP);

- адреса точки входа службы источника (Source Service Access Point, SSAP);

- управляющего поля (Control).

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

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

Поле управления (1 или 2 байта) имеет сложную структуру при работе в режиме LLC2 и достаточно простую структуру при работе в режиме LLC1 (рис. 4.8).

Рисунок 4.8 - Структура поля управления

В режиме LLC1 используется только один тип кадра — ненумерованный. У этого кадра поле управления имеет длину в один байт. Все подполя поля управления ненумерованных кадров принимают нулевые значения, так что значимыми остаются только первые два бита поля, используемые как признак типа кадра. Учитывая, что в протоколе Ethernet при записи реализован обратный порядок битов в байте, то запись поля управления кадра LLC1, вложенного в кадр протокола Ethernet, имеет значение не 0хС0 (1100 0000), а 0x03 (0000 0011) (здесь и далее префикс 0х обозначает шестнадцатеричное представление).

В режиме LLC2 используются все три типа кадров. В этом режиме кадры делятся на команды и ответы на эти команды [12].