Окончание начало см. Сети 1997 #10 c.14; 1998, #3 c.14
Важным преимуществом использования сети FR в качестве транспортной среды (применения кадра FR в качестве базового информационного элемента, в который "вкладывается" пакет сетевого протокола) является то, что сетевые протоколы позволяют достаточно просто строить (конфигурировать) распределенные сети передачи данных (СПД) на основе "физических" FR-соединений. Чтобы добиться этой простоты, необходимо иметь в рамках FR-протокола некоторый уникальный механизм (дополнение к процедурной и логической характеристикам FR-протокола) для идентификации сетевого протокола при передаче пакета, "вкладываемого" в FR-кадр. Главная цель такого механизма - обеспечение корректной доставки адресату сообщения отправителя. Рассмотрим основные положения проекта международного стандарта, разработанного ANSI (Т1.617, Приложение F).
Сущность метода идентификации сетевого протокола при передаче пакета, "вкладываемого" в FR-кадр, заключается в использовании стандартного формата FR-кадра; в поле данных этого кадра имеется специальное поле идентификатора протокола 3-го уровня (рис. 1)
| ОктетыБиты | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Назначение |
| 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
| 2 | Адресная часть заголовка | ||||||||
| 3 | стандартного FR-кадра | ||||||||
| 4 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | Идентификатор ненумерованного |
| информационного кадра | |||||||||
| 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Необязательное поле |
| 6 | Идентификатор протокола сетевого уровня | ||||||||
| 7... | ДАННЫЕ | ||||||||
| Проверочная последовательность | |||||||||
| 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
Формат многопротокольного кадра.
В дальнейшем такой FR-кадр будем именовать многопротокольным кадром, включающим в себя следующие поля:
- адресное поле. Имеет стандартный размер 2 октета, но при необходимости может быть увеличено до 3 или 4 октетов;
- идентификатор ненумерованного информационного кадра (ИНИК). Поле кодируется в соответствии с Рекомендацией ITU-T Q.922 (используется так же, как в кадре LMI);
- необязательное поле. Отправитель кадра может использовать его для более четкого определения границы заголовка кадра или "выравнивания" размера кадра. Если это поле задействуется (может состоять из нескольких октетов), оно должно иметь только нулевое заполнение;
- идентификатор протокола сетевого уровня (ИПCУ). Поле содержит код сетевого протокола, в соответствии с процедурной характеристикой которого осуществляется передача пакета. Кодирование данного поля соответствует стандартам ANSI и ITU-T - при условии, что все производители примут единую систему идентификации.
Если какой-либо сетевой протокол не имеет ИПСУ, определенного стандартами ANSI/ITU-T, то может быть использован специальный код (шестнадцатеричное "08"), который определен в Рекомендации ITU-T Q.933. Для кодирования ИПСУ могут применять 2 дополнительных двухоктетных поля, которые служат для идентификации протоколов канального и сетевого уровней (рис. 2). Кодирование этих полей определено стандартом ANSI Т1.617 и Рекомендацией Q.933, что обеспечивает совместимость на нижних уровнях. Более того, возможность использования специального кода (идентификатора) в первом октете указанных полей (октеты 7-10) позволяет идентифицировать уникальные пользовательские протоколы.
| ОктетыБиты | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Назначение |
| 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
| 2 | Адресная часть заголовка | ||||||||
| 3 | стандартного FR-кадра | ||||||||
| 4 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | ИНИК |
| 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Необязательное поле |
| 6 | Идентификатор протокола сетевого уровня | ||||||||
| 7 | Идентификатор протокола | ||||||||
| 8 | 2 уровня | ||||||||
| 9 | Идентификатор протокола | ||||||||
| 10 | 3 уровня | ||||||||
| 11... | ДАННЫЕ | ||||||||
| Проверочная последовательность | |||||||||
| 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
Формат многопротокольного кадра, использующего Рекомендацию ITU-T для идентификации протокола сетевого уровня
Такой формат многопротокольного кадра обеспечивает идентификацию протоколов взаимодействия объединенных локальных сетей (ЛС) и протоколов маршрутизации, определенных стандартами протоколов доступа к ЛС (ПДЛС) Института инженеров в области электротехники и электроники (IEEE). Для идентификации ПДЛС IEEE (заголовок ПДЛС) используются пять октетов, следующих после октета ИПСУ. Заголовок ПДЛС имеет следующее кодирование:
- первые три октета (уникальный идентификатор) определяют организацию, которая кодирует последние два октета;
- последние два октета - идентификатор протокола.
Все узлы связи и маршрутизаторы должны распознавать и соответствующим образом интерпретировать поле ИПСУ и заголовок ПДЛС.
Заголовок ПДЛС пригоден как для протоколов маршрутизации в ЛС, так и для протоколов взаимодействия объединенных ЛС. При использовании последних существует дополнительная необязательная функция поля FCS в FR-кадре: в этом поле размещается проверочная последовательность (FCS) корректности пакета, сформированного протоколом управления ЛС и "вложенного" в FR-кадр. Кодирование идентификаторов протоколов взаимодействия объединенных ЛС осуществляется в стандартах IEEE 802.3, 802.4, 802.5, 802.6.
Использование многопротокольного FR-кадра позволяет передавать через межсетевой интерфейс пакеты ЛС, размер которых превышает размер поля данных FR-кадра. В этом случае необходимо иметь устройство доступа, обеспечивающее "разбиение" (фрагментирование) пакетов ЛС на меньшие информационные блоки. Элементарные блоки пакета ЛС должны иметь индивидуальные номера, с помощью которых можно "собирать" (восстанавливать) исходный пакет.
Процедуры фрагментирования и формирования FR-кадра
Процедуры фрагментирования и формирования FR-кадра представлены на рис. 3. Происходит следующее. Сначала устройство доступа добавляет к пакету ЛС пятиоктетный заголовок. Сообщение с "добавленным" заголовком разбивается на блоки меньшей длины, соответствующие по размеру информационному полю кадра FR-сети. Далее маленькие блоки рассматриваются как блоки "чистых" данных, к которым добавились (еще до поступления в сеть) так называемые подзаголовки фрагментирования. Каждый такой блок "вкладывается" в многопротокольный FR-кадр, представленный на рис. 4. "Внутреннее содержимое" информационного поля многопротокольного FR-кадра (включая подзаголовки фрагментирования) определяется исключительно протоколами верхних уровней (но не канального).
| ОктетыБиты | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Назначение |
| 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
| 2 | Адресная часть заголовка | ||||||||
| 3 | стандартного FR-кадра | ||||||||
| 4 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | ИНИК |
| 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Необязательное поле |
| 6 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | ИПСУ |
| 7 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Уникальный |
| 8 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | идентификатор |
| 9 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | организации |
| 10 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Идентификатор |
| 11 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | протокола |
| 12 | Последовательный | ||||||||
| 13 | номер | ||||||||
| 14 | Смещение | Резерв | F | Подзаголовок фрагментирования | |||||
| 15 | Смещение (продолжение) | ||||||||
| 16... | БЛОК ДАННЫХ | ||||||||
| Проверочная последовательность | |||||||||
| 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг | |
Формат многопротокольного кадра, "переносящего" один из блоков исходного сообщения, которое подверглось делению
При фрагментировании исходного сообщения заголовок FR-кадра содержит следующие поля:
- адресное поле. Стандартный формат FR-кадра, размер которого составляет 2 либо (если необходимо) 3 или 4 октета;
- идентификатор ненумерованного информационного кадра. Определяется Рекомендацией ITU-T Q.922 (аналогичен по значению кадру LMI);
- необязательное поле. Этот октет кодируется значением "00000000" и служит для "выравнивания", при необходимости, размера кадра;
- ИПСУ. Кодирование представлено в Q.933 (ITU-T);
- уникальный идентификатор организации. Имеет постоянный код (шестнадцатеричный "00-80-С2"; старший разряд - восьмой);
- идентификатор протокола. Имеет постоянный код (шестнадцатеричный "00-0D"; старший разряд - восьмой);
- последовательный номер. Длина поля составляет два октета. Начальное значение этого номера, как правило, выбирается произвольным образом; оно увеличивается при поступлении любого нового целого сообщения, подлежащего фрагментированию. Таким образом, формируется уникальный идентификатор каждого FR-кадра, "переносящего" один из блоков исходного сообщения, которое подверглось делению;
- бит "финал" устанавливается в "1" в FR-кадре, содержащем последний блок исходного сообщения, которое подверглось делению, а в других кадрах - в "0";
- смещение. Длина поля составляет 11 бит. Значение этого поля определяет логическое смещение конкретного блока относительно первого блока исходного сообщения, подвергшегося делению. Данное значение равняется порядковому номеру байта, перед которым произошло деление исходного сообщения (т. е. байта, ставшего первым в очередном блоке), деленному на 32. Очевидно, что в FR-кадре, "переносящем" первый из блоков исходного сообщения, эта величина устанавливается в "0";
- данные. Поле содержит заголовок верхнего уровня и данные пользователя.
На приемной стороне блоки собираются в исходное сообщение, после чего выполняются процедуры протокола верхнего уровня. Сборка исходного сообщения осуществляется на основе анализа значений смещения, которые передаются в подзаголовке фрагментирования. Если какой-либо кадр теряется в сети, протокол верхнего уровня обнаруживает это по отсутствию одного (или нескольких) блоков исходного сообщения. Тогда ответственность за восстановление исходного сообщения (путем его перезапроса) полностью ложится на протокол более высокого уровня.
На рис. 5 показана процедура формирования первых двух FR-кадров из исходной "большой" IP-дейтаграммы.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Назначение | |
| 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
| 2 | Адресная часть заголовка FR-кадра | ||||||||
| 3 | |||||||||
| 4 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | ИНИК |
| 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Необязательное поле |
| 6 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | ИПСУ |
| 7 | Исходная | ||||||||
| ... | Данные | IP-дейтаграмма | |||||||
| Проверочная последовательность | |||||||||
| 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
| Назначение | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
| Флаг | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 |
| Адресная часть | 2 | ||||||||
| заголовка FR-кадра | 3 | ||||||||
| ИНИК | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 4 |
| Необязательное поле | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 5 |
| ИПСУ | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 6 |
| Уникальный идентификатор организации | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 7 |
| 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 8 | |
| 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 9 | |
| Идентификатор протокола | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 10 |
| 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 11 | |
| Последовательный номер | n | 12 | |||||||
| 13 | |||||||||
| Подзаголовок фрагментирования | Смещ. | Резерв | 0 | 14 | |||||
| Смещение ("0") | 15 | ||||||||
| Необязательное поле | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 16 |
| ИПСУ | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 17 |
| Первые m байт исходной IP-дейтаграммы | 18 | ||||||||
| Данные | ... | ||||||||
| Проверочная последовательность | |||||||||
| Флаг | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | |
| Назначение | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
| Флаг | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 |
| Адресная часть заголовка FR-кадра | 2 | ||||||||
| 3 | |||||||||
| ИНИК | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 4 |
| Необязательное поле | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 5 |
| ИПСУ | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 6 |
| Уникальный идентификатор организации | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 7 |
| 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 8 | |
| 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 9 | |
| Идентификатор протокола | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 10 |
| 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 11 | |
| Последовательный номер | n | 12 | |||||||
| 13 | |||||||||
| Подзаголовок фрагментирования | Смещ. | Резерв | 1 | 14 | |||||
| Смещение ("m/32") | 15 | ||||||||
| Остаток исходной IP-дейтаграммы | 16 | ||||||||
| Данные | ... | ||||||||
| Проверочная последовательность | |||||||||
| Флаг | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | |
Пример фрагментирования IP -дейтаграммы
Интеграция сетей FR и Х.25
Рекомендация ITU-T Х.25 определяет стандарты протоколов и интерфейсов канального и сетевого уровней. С точки зрения ретрансляции кадров, протоколы Х.25 являются высокоуровневыми "механизмами" управления информационным обменом. Поэтому некоторые специалисты утверждают, что кадры Х.25 достаточно корректно вписываются в формат многопротокольного FR-кадра. Однако многие фирмы, производящие аппаратно-программные средства для сетей Х.25, считают, что механизмы формирования многопротокольного FR-кадра чрезвычайно сложны и что существует более простая реализация протоколов доставки пакетов Х.25 через FR-сеть.
В связи с этим в стандарт ANSI T1.617 (Приложение G) были внесены поправки, которые определяют упрощенный метод "обрамления" пакета Х.25 и формирования FR-кадра. Этот метод может быть применен только с обоюдного согласия сторон, так как не предусмотрено каких-либо процедур (механизмов) сигнализации с целью оповещения ООД о применении данного метода. На рис. 6 показано, как осуществляется многоуровневое управление доставкой пакетов Х.25 на основе упрощенного метода формирования FR-кадра.
Многоуровневое управление доставкой пакетов Х.25 на основе упрощенного метода формирования FR-кадра
На сетевом уровне осуществляется взаимодействие между оконечным оборудованием данных (ООД), а на втором (канальном) уровне поддерживается процедура доступа к каналу Link Access Procedure Balanced (LAPB). После "обрамления" кадра канального уровня (кадра LAPB) и формирования FR-кадра последний пересылается к месту назначения через определенный DLCI (при этом используются согласованные параметры и условия доставки по FR-сети). На приемной стороне кадр канального уровня освобождается от "обрамления" и направляется для обработки на канальный уровень управления, а затем - на сетевой уровень. Это означает, что протокол канального уровня (LAPB) взаимодействует с FR-сетью так же, как и с физическим уровнем обычной сети Х.25, причем FR-сеть прозрачна для всех типов кадров - информационных и управляющих, таких как RR, RNR, REJ и др. (см. Приложение v2).
На рис. 7 представлен формат FR-кадра, "переносящего" кадр LAPB. Адресное поле, поле управления и информационное поле кадра канального уровня полностью и без изменений вставляются в информационное поле FR-кадра. Одним из условий формирования такого FR-кадра является то, что в его заголовке не используется идентификатор типа протокола. Еще одно требование - применение стандартного двухоктетного адресного поля заголовка. Наконец, последнее условие относится к полю проверочной последовательности (FCS): FCS кадра канального уровня заменяется FCS FR-кадра, которая определяется с учетом всех полей - двухоктетного адресного поля заголовка FR-кадра, адресного поля, поля управления и информационного поля кадра канального уровня. Соответственно, на приемной стороне осуществляются процедуры, обратные указанным.
| Назначение | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| Флаг | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 |
| Заголовок кадра LAPB | Адресное поле | |||||||
| Поле управления | ||||||||
| Данные | Информационное поле кадра LAPB | |||||||
| FCS кадра LAPB | ||||||||
| Флаг | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Назначение |
| 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | Флаг |
| 0 | 0 | DLCI | Адрес | |||||
| 1 | D | B | F | DLCI | кадра FR | |||
| Адресное поле Поле управления | Заголовок кадра LAPB | |||||||
| Информационное поле кадра LAPB | Данные | |||||||
| &nb
ИТ-календарь
| ||||||||