По различным сетевым протоколам

Важным преимуществом использования FR-сети в качестве транспортной среды (применение FR-кадра в качестве базового информационного элемента, в который «вкладывается» пакет сетевого протокола) является то, что сетевые протоколы имеют возможность достаточно простого построения (конфигурации) распределенной СПД на основе «простых физических» FR-соединений. Для достижения этой простоты необходимо иметь некоторый уникальный механизм в рамках FR-протокола (дополнение к процедурной и логической характеристикам FR-протокола) для идентификации сетевого протокола при передаче пакета, «вкладываемого» в FR-кадр. Главной целью такого механизма является обеспечение корректной доставки сообщения пользователя адресату. Рассмотрим основные положения проекта международного стандарта, разработанного ANSI (Т1.617, Приложение F).

Сущность способа идентификации сетевого протокола при передаче пакета, «вкладываемого» в FR-кадр, заключается в использовании стандартного формата FR-кадра, в котором имеется специальное поле идентификатора протокола 3-го уровня в поле данных (рис. 31.2). В дальнейшем такой FR-кадр будем именовать многопротокольным кадром, включающим в себя следующие поля:

- адресное поле. Имеет стандартный размер — 2 октета, но может быть увеличено при необходимости до 3 или 4 октетов;

- идентификатор ненумерованного информационного кадра (ИНИК). Это поле кодируется в соответствии с Рекомендацией ITU-T Q.922 (используется так же, как и в кадре LMI);

- необязательное поле. Это поле может быть полезным для отправителя кадра в целях более четкого разграничения границы заголовка кадра, а также для «выравнивания», если это необходимо, размера кадра. Если это поле (либо несколько октетов) используется, то оно должно иметь только нулевое заполнение;

- идентификатор протокола сетевого уровня (ИПCУ). Это поле содержит код сетевого протокола, в соответствии с процедурной характеристикой которого осуществляется передача пакета. Кодирование этого поля осуществляется в соответствии со стандартами ANSI и ITU-T, при условии того, что все фирмы-производители примут единую систему идентификации.

Рис. 31.2. Формат многопротокольного кадра

Если некоторый сетевой протокол не имеет ИПСУ, определенного стандартами ANSI/ITU-T, в этом случае может быть использован специальный код (шестнадцатеричная «08»), который определен в Рекомендации ITU-T Q.933. Если для ИПСУ используется 4-октетное поле, то оно служит для идентификации протоколов канального и сетевого уровней (рис. 31.3). Кодирование этих полей определено стандартом ANSI Т1.617 и Рекомендацией ITU-T Q.933 и тем самым обеспечивает совместимость на нижних уровнях. Более того, возможность использования специального кода (идентификатора) в первом октете этих двух полей (7...10-й октеты, рис. 31.3) позволяет идентифицировать уникальные пользовательские протоколы.

Рис. 31.3. Формат многопротокольного кадра, использующего Рекомендацию ITU-T

для идентификации протокола сетевого уровня

Такой формат многопротокольного кадра (рис. 31.3) обеспечивает возможность идентифицировать протоколы взаимодействия объединенных локальных вычислительных сетей (ЛВС) и маршрутизации, определенные стандартами Американского института инженеров в области электротехники и электроники (IEEE — Institute of Electrical and Electronics Engineers, «Комитет 802 по стандартизации ЛВС») для протоколов доступа к ЛВС (ПДЛВС). В этом случае, для идентификации ПДЛВС IEEE (заголовок ПДЛВС) используются пять октетов, следующие после октета ИПСУ. Заголовок ПДЛВС имеет следующее кодирование:

- первые три октета (уникальный идентификатор организации) определяют организацию, которая устанавливает кодирование последних двух октетов;

- последние два октета — идентификатор протокола.

Все узлы связи и маршрутизаторы должны распознавать и соответствующим образом интерпретировать поле ИПСУ и заголовок ПДЛВС.

Заголовок ПДЛВС пригоден как для протоколов маршрутизации в ЛВС, так и для протоколов взаимодействия объединенных ЛВС. При использовании последних существует дополнительная необязательная функция поля FCS в FR-кадре, которая заключается в том, что в этом поле размещается циклическая проверка корректности пакета, сформированного протоколом управления ЛВС и «вложенного» в FR-кадр (т.е. имеет место двойное применение поля FCS). Кодирование идентификаторов протоколов взаимодействия объединенных ЛВС представлено в стандартах IEEE 802.3, 802.4, 802.5, 802.6 и на волоконно-оптическую ЛВС (FDDI).

Рис. 31.4. Процедура фрагментирования и формирования FR-кадра

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

На первом этапе устройство доступа «добавляет» к кадру ЛВС пятиоктетный заголовок (рис. 31.2). Это большое сообщение, с «добавленным» заголовком, затем разбивается на фрагменты меньшей длины, равной размеру информационного поля кадра FR-сети. Далее эти маленькие фрагменты рассматриваются как блоки «чистых» данных, к которым добавились (еще до поступления в сеть) так называемые заголовки фрагментирования. После чего каждый такой фрагмент «вкладывается» в многопротокольный FR кадр, представленный на рис. 31.5. «Внутреннее содержимое» информационного поля многопротокольного FR-кадра (включая заголовки фрагментирования) определяется исключительно протоколами верхних уровней (но не канального).

Рис. 31.5. Формат многопротокольного кадра, «переносящего» один из фрагментов

исходного сообщения, которое подверглось делению

Заголовок FR-кадра (при фрагментировании исходного сообщения) содержит следующие поля:

o адресное поле. Стандартный формат FR-кадра, имеющий 2-октетную или, если это необходимо, 3- и 4-октетную длину;

o идентификатор ненумерованного информационного кадра. Этот идентификатор определяется Рекомендацией ITU-T Q.922 (его значение аналогично значению кадра LMI);

o необязательное поле. Этот октет кодируется значением «00000000» и служит для «выравнивания», если это необходимо, размера кадра;

o ИПСУ. Кодирование представлено в Q.933 (ITU-T);

o уникальный идентификатор организации. Имеет постоянный код (шестнадцатеричный «00-80-С2»);

o идентификатор протокола. Имеет постоянный код (шестнадцатеричный «00-0D»);

o последовательный номер. Длина этого поля составляет два октета. Значение этого номера увеличивается каждый раз при поступлении нового целого сообщения, подлежащего фрагментированию. Таким образом, формируется уникальный идентификатор для каждого FR-кадра, «переносящего» один из фрагментов исходного сообщения, которое подверглось делению. Начальное значение этого номера, как правило, выбирается произвольным образом;

o бит «финал». Этот бит устанавливается в «1» в FR-кадре, содержащем последний фрагмент исходного сообщения, которое подверглось делению, а в других — в «0»;

o смещение. Длина этого поля составляет 11 октетов. Значение величины, содержащейся в этом поле, определяет логическое смещение передаваемого фрагмента относительно первого фрагмента исходного сообщения, которое подверглось делению. Эта величина равняется порядковому номеру байта, перед которым произошло деление исходного сообщения (байт, который стал первым в очередном блоке исходного сообщения), деленному на 32. Очевидно, что эта величина в FR-кадре, «переносящем» первый из фрагментов исходного сообщения, устанавливается в «0»;

o данные. Это поле содержит заголовок верхнего уровня и данные пользователя.

Рис. 31.6. Пример фрагментирования IP-пакета

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

Рис. 31.7. Диаграмма многоуровневого управления доставкой пакетов Х.25

на основе упрощенного метода формирования FR-кадра

На рис. 31.6 показана процедура фрагментирования и формирования первых двух FR-кадров из исходного «большого» IP-пакета.