Приемник не готов (Receiver Not Ready, RNR);

ПРОТОКОЛ LLC

Стандарт 802.2 описывает работу подуровня LLC – логические процедуры передачи кадров и связь с сетевым уровнем. В основу протокола LLC положен протокол HDLC (High-level Data Link Control Procedure), широко использующийся в территориальных сетях.

Три типа процедур уровня LLC

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

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

Этот набор процедур является общим для всех методов доступа к среде, определенных стандартами 802.3-802.5.

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

Сервис с установлением соединений и с подтверждением LLC2 дает пользователю возможность установить логическое соединение перед началом передачи любого блока данных и, если это требуется, выполнить процедуры восстановления после ошибок и упорядочивание потока этих блоков в рамках установленного соединения. Протокол LLC2 во многом аналогичен протоколам семейства HDLC (LAP-B, LAP-D, LAP-M), которые применяются в глобальных сетях для обеспечения надежной передачи кадров на зашумленных линиях.

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

Когда какая процедура может использоваться? Все зависит от стратегии разработчиков конкретного стека протоколов. Например, в стеке TCP/IP уровень LLC всегда работает в режиме LLC1. Здесь от него требуется просто извлекать из кадра и де мультиплексировать пакеты различных протоколов. Аналогично используется уровень LLC стеком IPX/SPX.

А вот стек Microsoft/IBM, основанный на протоколе NetBIOS/NetBEUI, часто использует режим LLC2. Это происходит тогда, когда сам протокол NetBIOS/NetBEUI должен работать в режиме с восстановлением потерянных и искаженных данных. В этом случае эта работа перепоручается уровню LLC2. Если же протокол NetBIOS/NetBEUI работает в дейтаграммном режиме, то протокол LLC работает в режиме LLC1.

Как уже было замечено, чаще всего в локальных сетях используются протоколы LLC1. Это объясняется тем, что кабельные каналы локальных сетей обеспечивают низкую вероятность искажений бит и потери кадров. Поэтому, использование повышающего надежность обмена протокола LLC2 часто только замедляет общую пропускную способность стека коммуникационных протоколов. Тем не менее, иногда протокол LLC2 применяется и в локальных сетях. Так, этот протокол используется стеком SNA в том случае, когда мэйнфремы или миникомпьютеры IBM взаимодействуют через сети Token Ring. Протокол LLC2 используется также компанией Hewlett-Packard в том случае, когда принтеры подключается к сети Ethernet непосредственно, с помощью встроенных сетевых адаптеров.

Структура кадров LLC

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

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

Все типы кадров уровня LLC имеют единый формат (рис. 10.1). Они содержат четыре поля:

адрес точки входа сервиса назначения (Destination Service Access Point, DSAP),
адрес точки входа сервиса источника (Source Service Access Point, SSAP),
управляющее поле (Control)
поле данных (Data)

Рисунок 10.1. Структура LLC-кадра стандарта 802.2

Кадр LLC обрамляется двумя однобайтовыми полями "Флаг", имеющими значение 01111110. Флаги используются на MAC-уровне для определения границ блока.

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

Поле управления (один байт) используется для обозначения типа кадра данных - информационный, управляющий или ненумерованный. Кроме этого, в этом поле указываются порядковые номера отправленных и успешно принятых кадров, если подуровень LLC работает по процедуре LLC2 с установлением соединения. Формат поля управления полностью совпадает с форматом поля управления кадра LAP-B.

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

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

SSAP - это адрес верхнего уровня, который передает данные в протокол LLC.

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

Адреса DSAP и SSAP занимают по 1 байту.

Возможные варианты значений адресов SAP оговорены заранее в соответствии со стандартом 802.2. Например, для протокола IP значение SAP равно 0х6, для протокола NetBIOS -0*F0.

Если у службы определена только одна точка входа, тогда нужен только один SAP, но бывает, когда таких точек входа определяется несколько. Например, если в кадре LLC значения DSAP и SSAP содержат код протокола IPX, то обмен кадрами осуществляется между двумя IPX-модулями, но просто работающими в разных узлах. В этом случае адреса DSAP и SSAP будут иметь одинаковые значения, поскольку с кадром кадром LLC работает одинаковый тип службы.

Каждый кадр LLC относится к одному из трех типов (в зависимости от значения старших битов поля Control):

- ненумерованный (Unnumbered) – поле Control занимает 1 байт, два старших бита имеют значение 11,

- информационный (Information) – поле Control занимает 2 байта, старший бит установлен в 0,

- управляющий (Supervisory) – поле Control занимает 2 байта, два старших бита имеют значение 10.

Структура поля Control для разных типов кадров приведена на рис.10.2.

Рисунок 10.2. Структура поля Control кадра LLC

Процедура LLC1 использует только ненумерованные кадры с нулевым значением всех подполей (кроме двух первых бит). Поскольку протокол Ethernet использует обратный порядок бит в байте, то значение поля Control кадров LLC1, используемых в сетях Ethernet, имеет значение 0x03.

Процедура LLC2 использует кадры всех типов. Кадры делятся на команды и ответы. Разряд P/F в командах называется Poll (запрос) и требует, чтобы на команду был дан ответ, а в ответах называется F (Final) и указывает на последний кадр в ответе.

Ненумерованные кадры используются для установления соединения, их поле M несет код команды – запрос установки соединения, подтверждение соединения, разрыв соединения. После того, как соединение установлено, передача пользовательских данных и подтверждений осуществляется кадрами информационного типа. Поле N(S) несет номер отправленного кадра, поле N(R) несет номер кадра, который ожидает получить узел-источник. Поскольку поля N(S) и N(R) имеют длину в семь битов, для нумерации кадров циклически используются числа от 0 до 127. Если поступает кадр с номером, отличным от того, который ожидался приемником (например, после кадра 56 приходит кадр 58, а не ожидаемый кадр 57), такой кадр отбрасывается и передатчику отправляется кадр управляющего типа с кодом отказа в поле S и указанием ожидаемого номера кадра в поле N(R). Передатчик при этом должен возобновить передачу, начиная с запрошенного кадра.

Управляющие кадры, помимо передачи отказа (Reject, REJ), могут передавать еще две команды: приемник не готов(Receiver Not Ready, RNR) и приемник готов(Receiver Ready, RR), используемые для управления потоком. Если приемник не успевает обработать поток кадров, он отправляет управляющий кадр с командой RNR, по которой передатчик должен приостановить передачу до получения кадра с командой RR.

Кроме того, как было сказано, в режиме LLC1 можно использовать некоторые команды. Поэтому поле управления ненумерованного кадра в режиме LLC1 имеет еще несколько специальных бит.

Все кадры делятся на команды и ответы на эти команды. Поэтому для всех типов кадров используется специальный бит состояния команда/ответ - бит P/F (Poll/Final).

Бит P/F имеет следующее значение: в командах он называется битом Poll. Он говорит - это команда дайте ответ, а в ответах он называется битом Final, и он говорит - это ответ состоящий из одного кадра.

Бит P/F присутствует и в поле управления ненумерованного кадра в режиме LLC1.

Сами команды передаются в подполе М. Это поле управления ненумерованного кадра.

Теперь давайте рассмотрим второй режим - LLC2. Этот режим более сложный, и поэтому он использует все три типа кадров: информационный, управляющий (супервизорный), ненумерованный.

Ненумерованные кадры мы уже рассмотрели. Режим LLC2 использует их на начальной стадии взаимодействия двух узлов, а именно на стадии установления соединения по протоколу LLC2.

Поле М ненумерованных кадров LLC2 использует для определения несколько типов команд, которыми пользуются два узла на этапе установления соединения. Ниже приведены примеры некоторых команд:

Установить сбалансированный асинхронный расширенный режим (SABME). Эта команда является запросом на установление соединения. Она является одной из команд полного набора команд такого рода протокола HDLC.

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

Ненумерованное подтверждение (UA). Команда для подтверждения установления или разрыва соединения.

Сброс соединения (REST). Запрос на разрыв соединения.

Итак, соединение установлено, теперь необходимо передавать данные и положительные квитанции. Для этого использует LLC2 информационные кадры. Поле управления информационного кадра состоит из двух байт. Которые помещают первый значащий бит - 0 - признак передачи данных и положительных квитанций, бит состояния команд P/F.

В информационных кадрах имеется два подполя N(S) и N(R). Для чего они служат? Как мы уже говорили протокол LLC2 использует метод скользящего окна. Используется скользящее окно размером в 127 кадров. Кадры нумеруются от 0 до 127. Так вот, номер отправленного передатчиком кадра - это подполе N(S). Подполе N(R) - номер кадра, который приемник ожидает получить от передатчика следующим.

Таким образом, приемник всегда будет помнить номер последнего кадра, принятого от передатчика. Он всегда знает номер кадра, который он ожидает принять от передатчика следующим. Обозначим этот ожидаемый номер, через переменную V(R).

По сути, значение V(R) должно совпадать со значением подполя N(R) информационного кадра, который посылается передатчику.

Давайте рассмотрим, случай передачи информационного кадра передатчиком к приемнику. Передатчик помещает в подполе N(S) номер передаваемого кадра, скажем m, а в подполе N(R) будет занесено m+1.

Приемник, ожидает номер кадра V(R) равное m. Он принимает кадр от передатчика, и если в номер посланного кадра N(S)совпадает с номером ожидаемого кадра V(R), то такой кадр считается корректным (если, конечно, корректна его контрольная сумма), в этом случае так и будет.

Если приемник же приемник ожидал кадр m, а принял кадр с номером N(S) m+1, то есть неравным V(R), то этот кадр отбрасывается и посылается отрицательная квитанция - ошибка передачи кадра, нужно повторить кадр.

Для передачи отрицательных квитанций используются супервизорные кадры. Супервизорные кадры также имеют двухбайтовое поле управления с двумя значащими битами 10. Эти кадры состоят из команд:

Отказ (REJ) (с номером V(R)).

При приеме отрицательной квитанции передатчик обязан повторить передачу кадра с номером V(R), то есть повторить передачу ожидаемого кадра, а также всех кадров с большими номерами, которые он уже успел отослать, пользуясь механизмом окна в 127 кадров.

Приемник не готов (Receiver Not Ready, RNR);

Команда RNR используется для замедления потока кадров, поступающих на приемник. Это может быть необходимо, если приемник не успевает обработать поток кадров, присылаемых ему с большой скоростью за счет механизма окна. Получение кадра RNR требует от передатчика полной приостановки передачи, до получения кадра RR.