8. Интеграция fr сетей

Обычно любой протокол управления высокого уровня (от сетевого уровня и выше) функционирует на основе базового протокола ретрансляции кадров. В настоящее время имеется несколько стандартов сетевых протоко­лов, то есть существует несколько типов ИВС. Следовательно, если даже FR сеть является интегрирующей транспортной основой высокоуровневой сети, построенной с использованием технических средств различных фирм-производителей, то возможна такая ситуация, при которой ООД абонентов будут взаимодействовать только с такими же (изготовленными той же фир­мой) ООД (рис. 8.1).

Такая ситуация для потребителей сетевых услуг крайне нежелательна. Понимая это, ANSI предложил пакет проектов стандартов протоколов и ин­терфейсов FR для утверждения их в качестве международных, позволяю­щих взаимодействовать с высокоуровневыми (сетевыми и выше) протоко­лами, включая ISO 8208, 8802.2 и IP. Тем не менее, являясь международ­ной организацией по стандартизации, ANSI не издает стандарты протоколов де-факто, а направляет последние на рассмотрение FRF, которая является международной организацией потребителей (то есть организацией фирм-производителей, реализующих стандарты протоколов в своих коммуникаци­онных аппаратно-программных комплексах).

8.1. Характеристика fr протокола для интеграции сетей, функционирующих по различным сетевым протоколам

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

Рис. 8.1 .Взаимодействие протоколов сетевого уровня

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

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

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

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

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

Таблица 8.1

Формат многопротокольного кадра

Октеты	Биты
	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									Идентификатор протокола сетевого уровня
7...									ДАННЫЕ
									Проверочная последовательность
	0	1	1	1	1	1	1	0	Флаг

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

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

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

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

Таблица 8.2

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

Октеты	Биты
	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									Идентификатор протокола сетевого уровня
7 8									Идентификатор протокола 2-го уровня
9 10									Идентификатор протокола 3-го уровня
11...									ДАННЫЕ
									Проверочная последовательность
	0	1	1	1	1	1	1	0	Флаг

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

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

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

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

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

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

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

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

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

Таблица 8.3

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

Октеты	Биты
	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	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	Смещение (продолжение)
6...									БЛОК ДАННЫХ
									Проверочная последовательность
	0	1	1	1	1	1	1	0	Флаг

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

Рис. 8.3. Пример фрагментирования IP дейтаграммы