РД 45.038-99 (с изм. 1 2002)

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

К АППАРАТУРЕ СВЯЗИ, РЕАЛИЗУЮЩЕЙ ФУНКЦИИ МАРШРУТИЗАЦИИ ПАКЕТОВ ПРОТОКОЛА МЕЖСЕТЕВОГО ОБМЕНА

(АППАРАТУРА МАРШРУТИЗАЦИИ ПАКЕТОВ IP)

РД 45.038-99

Внесено Изменение № 1, утвержденное Министерством Российской Федерации по связи и информатизации и введенное в действие с 15.04.2002 г.

СПИСОК СОКРАЩЕНИЙ И ОБОЗНАЧЕНИЙ

1 Назначение Технических требований

1.1 Настоящие Технические требования (ТТ) распространяются на аппаратуру связи, реализующую функции маршрутизации пакетов протокола межсетевого обмена (Internet Protocol - IP) на сетях передачи данных и транспортных сетях общего пользования ВСС РФ.

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

1.3. В ТТ приняты нормы и показатели, соответствующие государственным стандартам Российской Федерации (ГОСТ), Руководящему Техническому Материалу (РТМ) по применению систем и аппаратуры синхронной цифровой иерархии (СЦИ) на сети связи РФ, Рекомендациям МСЭ-Т, стандартам ETSI, стандартам Internet, спецификациям Форума ATM.

2 Классификация аппаратуры маршрутизации пакетов IP

2.1. Аппаратура передачи пакетов IP должна быть реализована в соответствии с функциональными требованиями к межсетевой передаче пакетов в сетях IP, определенными в стандарте Internet RFC 1126 и стеком протоколов IP, определенным в стандартах Internet RFC 1122 и RFC 1123.

2.2. Аппаратура маршрутизации пакетов IP классифицируется в зависимости от области применения (назначения) и набора поддерживаемых функций.

2.3. В зависимости от области применения различают аппаратуру внутрисетевой маршрутизации и аппаратуру межсетевой маршрутизации.

2.4. Аппаратура внутрисетевой маршрутизации подразделяется на:

маршрутизаторы локальных сетей

узловые маршрутизаторы

маршрутизаторы доступа

Аппаратура межсетевой маршрутизации подразделяется на:

магистральные маршрутизаторы

шлюзы.

2.5. Маршрутизаторы локальных сетей предназначены для маршрутизации нагрузки внутри локальных сетей и для обеспечения взаимодействия с удаленными локальными сетями.

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

Маршрутизаторы доступа предназначены для использования в корпоративных сетях и сетях передачи данных для организации доступа абонентов через телефонную сеть общего пользования или ISDN.

Магистральные маршрутизаторы используются при построении транспортных сетей для передачи информации ЕР.

Шлюзы используются для организации межсетевого взаимодействия, включая взаимодействие сетей различного типа (IP, X.25 и т.д.).

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

2.6. В зависимости от набора поддерживаемых функций различают:

- маршрутизаторы;

- комбинированные маршрутизаторы.

В первом случае аппаратура выполняет только функции маршрутизации сообщений/пакетов для неориентированных на соединение протоколов передачи.

Аппаратура может иметь последовательный или параллельный интерфейс ООД/АКД или интерфейсы локальных сетей (Ethernet, Token Ring и т.д.).

В сетях передачи данных и транспортных сетях такая аппаратура может использоваться только совместно с оборудованием передачи данных других типов, например, с коммутаторами пакетов/кадров X.25/Frame Relay или виртуальных соединений ATM.

2.8. Комбинированный маршрутизатор совмещает в себе функции маршрутизации пакетов IP и других не ориентированных на соединение протоколов с функциями коммутации или мультиплексирования пакетов/кадров X.25/Frame Relay или виртуальных соединений ATM.

В качестве физических интерфейсов аппаратура может иметь

- последовательный/параллельный интерфейс ООД/АКД

- интерфейс локальной сети

- интерфейс ПЦИ (Е1, Е3)

- интерфейс BRI/PRI ISDN

- интерфейс СЦИ (STM1, STM4)

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

2.9. Аппаратура маршрутизации пакетов IP может устанавливаться как на объектах связи ВСС РФ, так и в помещениях пользователей.

3 Технические требования к аппаратуре маршрутизации пакетов IP

3.1 ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ ФУНКЦИЙ ПРОТОКОЛОВ ПЕРЕДАЧИ ПАКЕТОВ IP

3.1.1 Требования к реализации функций протокола IP

Требования к реализации протокола IP регламентируются стандартом Internet RFC 791, где определяются правила кодирования, форматы и функции управления передачей пакетов.

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

3.1.1.1 Форматы пакетов протокола IP

Формат пакета протокола IP и кодирование его полей должны соответствовать RFC 791 п. 3.1. При этом должна поддерживаться минимальная длина заголовка пакета 20 байт и максимальная длина пакета 65535 байт.

Формат заголовка пакета IP и перечень поддерживаемых полей должен соответствовать следующей таблице:

Поля заголовка:

3.1.1.2 Требования к функциям кодирования/декодирования полей заголовка пакета IP

3.1.1.2.1 Поле "Версия"

Поле "Версия" должно содержать номер версии формата заголовка пакета IP. Аппаратура должна поддерживать все версии по 4 включительно.

3.1.1.2.2 Поле "Длина заголовка"

Поле Длина заголовка должно содержать значение длины заголовка пакета в словах (1 слово - 32 бита).

3.1.1.2.3 Поле "Тип обслуживания"

Поле должно содержать код набора параметров качества обслуживания:

- приоритетность;

- задержка;

- пропускная способность;

- надежность.

Кодирование поля "Тип обслуживания" должно выполняться в соответствии со следующими правилами:

Кодирование разрядов приоритетности должно осуществляться в соответствии с RFC 791 п. 3.1.

В случае, если аппаратура не поддерживает управление приоритетом передачи пакетов, значения разрядов 0-2 должно игнорироваться.

3.1.1.2.4 Поле "Длина пакета IP"

Поле должно содержать значение длины пакета IP в байтах, включая заголовок и данные. Возможность обрабатывать пакеты длиной менее 576 байт является обязательным требованием к маршрутизаторам пакетов IP; в отдельных случаях допускается длина пакета до 65535 байт.

3.1.1.2.5 Поле "Идентификатор пакета"

Поле "идентификатора пакета" должно использоваться процедурой фрагментации при сборке/разборке пакета для определения последовательности передаваемых фрагментов.

3.1.1.2.6 Поле "Флаги"

Поле должно использоваться процедурой фрагментации для управления последовательностью сборки фрагментов пакета. Кодирование разрядов поля должно осуществляться в соответствии со следующими правилами:

3.1.1.2.7 Поле "Смещение фрагмента"

Поле должно использоваться для указания смещения данного фрагмента относительно первого фрагмента в блоках фрагментации (8 байт). Для первого фрагмента смещение устанавливается в "0".

3.1.1.2.8 Поле "Счетчик допустимого времени пребывания пакета в сети"

Поле должно содержать текущее значение счетчика максимально допустимого времени пребывания пакета в сети в секундах. Если в поле находится значение "0", пакет должен быть удален.

3.1.1.2.9 Поле "Тип протокола следующего уровня"

Поле должно содержать стандартизированный код протокола следующего уровня в соответствии с RFC 1340.

3.1.1.2.10 Поле "Контрольная последовательность заголовка" (КПЗ)

Поле должно содержать контрольную последовательность заголовка. При любом изменении содержания заголовка КПЗ должно пересчитываться. Формирование КПЗ должно осуществляться в соответствии с RFC 791 п. 3.1.

3.1.1.2.11 Поле "Адрес источника пакета"

Кодирование поля "Адрес источника пакета" должно соответствовать требованиям RFC 791 п. 3.2.

3.1.1.2.12 Поле "Адрес получателя пакета"

Кодирование поля "Адрес получателя пакета" должно соответствовать требованиям RFC 791 п. 3.2.

3.1.1.2.13 Поле "Режим обработки пакета"

Кодирование и форматы данного поля должны соответствовать RFC 791 п. 3.1.

Число режимов в каждом пакете не ограничивается.

Должны поддерживаться два способа кодирования поля режимов:

1) поле длиной 1 байт,

2) комбинация трех подполей:

- тип режима (1 байт);

- счетчик длины поля режима (1 байт);

- данные режима (переменная длина).

Подполе типа режима должно включать:

- флаг (1 бит);

- класс режима (2 бита);

- номер режима (5 бит).

При установке бита флага в значение "1" аппаратура должна копировать данное поле при фрагментации что данная функция при фрагментации копируется во все фрагменты, в значение "0" - не копируется.

Установка битов класса режима должно соответствовать следующим значениям:

"0" - управление;

"1" - зарезервировано;

"2" - отладка и измерение;

"3" - зарезервировано.

3.1.1.2.14 Поле дополнения до границы заголовка

Для выравнивания границы заголовка по длине, кратной 32 бит, свободные позиции должны быть заполнены нулевыми битами.

3.1.1.3 Режимы обработки пакета IP

Состав режимов должен соответствовать RFC 791 п. 3.1.

В аппаратуре должна быть предусмотрена поддержка следующих классов режимов:

3.1.1.3.1 Режим "Конец списка режимов "

Тип режима: 0.

Предназначен для использования указателем конца списка режимов, может совпадать с концом заголовка пакета IP. Допускается копирование, внесение и удаление данного режима при фрагментации.

3.1.1.3.2 Режим "Нет действий "

Тип режима: 1.

Предназначен для выравнивания смежных полей режимов по границе слова (32 бит), может находиться в любом месте списка режимов. Допускается копирование, внесение и удаление данного режима при фрагментации.

3.1.1.3.3 Режим "Свободная маршрутизация от источника и записанный маршрут"

Тип режима: 131.

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

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

Кодирование полей: Тип режима должен быть установлен в двоичное значение "10000011".

Поле счетчика длины поля режима должно содержать значение переменной длины данного поля в байт.

Поле Указатель должно содержать порядковый номер байта, начиная с которого в поле данных о маршруте находится адрес источника пакета. Наименьшее допустимое значение поля указателя "4".

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

Если значение указателя превышает значение длины поля режима, данные о маршруте от источника должны считаться отсутствующими (записанный маршрут исчерпан) и маршрутизация должна осуществляться по значению поля адреса получателя пакета.

Если адрес в поле получателя пакета достигнут, и поле указателя содержит значение, не превышающее длину поля режима, следующий адрес в маршруте от источника должен заменить адрес в поле адреса получателя, и адрес записанного маршрута должен заменить последний использованный адрес источника; значение поля указателя должно увеличиваться на 4.

Аппаратура должна обеспечивать неизменность длины пакета IP в процессе замены адресов маршрута.

Копирование данного режима при фрагментации обязательно; не допускается наличие более одного поля данного режима в пакете.

3.1.1.3.4 Режим "Строгая маршрутизация от источника и записанный маршрут"

Тип режима: 137.

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

Рис. 3.2. Формат поля режима Строгая маршрутизация от источника и записанный маршрут

Кодирование полей: Тип режима должен быть установлен в двоичное значение "10001001".

Поле счетчика длины поля режима должно содержать значение переменной длины данного поля в байт.

Поле Указатель должно содержать порядковый номер байта, начиная с которого в поле данных о маршруте находится адрес источника пакета, который подлежит обработке. Наименьшее допустимое значение поля указателя "4".

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

Если значение указателя превышает значение длины поля режима, данные о маршруте от источника должны считаться отсутствующими (записанный маршрут исчерпан) и маршрутизация должна осуществляться по значению поля адреса получателя пакета.

Если адрес в поле получателя пакета достигнут, и поле указателя содержит значение, не превышающее длину поля режима, следующий адрес в маршруте от источника должен заменить адрес в поле адреса получателя, и адрес из записанного маршрута должен заменить адрес источника, использованный последним; значение поля указателя должно увеличиваться на 4.

Аппаратура должна обеспечивать неизменность длины пакета IP в процессе замены адресов маршрута.

Аппаратура должна обеспечивать посылку пакета строго по следующему адресу маршрута от источника.

Копирование данного режима при фрагментации обязательно; не допускается наличие более одного поля данного режима в пакете.

3.1.1.3.5 Режим "Записанный маршрут"

Тип режима: 7.

Предназначен для записи маршрута пакета.

Формат поля режима "Записанный маршрут" аналогичен форматам полей функций "Свободная маршрутизация от источника и записанный маршрут" и "Строгая маршрутизация от источника и записанный маршрут".

Кодирование полей: поле Тип режима должно быть установлено в двоичное значение "00000111". Указатель должен содержать номер байта, начиная с которого должен записываться очередной адрес.

Кодирование остальных полей должно выполняться аналогично кодированию данных полей для режимов "Свободная маршрутизация от источника и записанный маршрут" и "Строгая маршрутизация от источника и записанный маршрут".

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

Аппаратура должна обеспечивать неизменность длины пакета IP в процессе замены адресов маршрута.

Начальное значение поля данных должно быть нулевым.

Аппаратура должна обеспечивать запись адреса узла, начиная с байта, указанного в поле указателя при наличии поля данного режима в пакете. Значение указателя должно увеличиваться на 4.

Если аппаратура получает пакет с заполненным полем данных о маршруте, дальнейшая запись не производится. Если свободного поля недостаточно для записи полного адреса, пакет должен считаться пораженным ошибкой и исключаться аппаратурой из обработки и передачи; по адресу источника пакета должна обеспечиваться посылка сообщения протокола ICMP "Некорректные параметры обмена".

При фрагментации поле данного режима копированию не подлежит; не допускается наличие более одного поля данного режима в пакете.

3.1.1.3.6 Режим "Идентификатор потока"

Тип режима: 136.

Предназначен для идентификации принадлежности пакета к потоку в сетях, поддерживающих способы передачи потоков.

Поле режима "Идентификатор потока" состоит из двух подполей каждое длиной 2 байта.

Кодирование полей: первые два байта должны быть установлены в двоичное значение "1000100000000010".

Вторые два байта должны содержать идентификатор потока.

При фрагментации подлежит обязательному копированию; не допускается наличие более одного поля данного режима в пакете.

3.1.1.3.7 Режим "Отметка времени"

Тип режима: 68.

Предназначен для контроля времени прохождения пакетом узлов сети.

Рис. 3.3. Формат поля режима Отметка времени

Кодирование полей: Тип режима должен быть установлен в двоичное значение "01000100".

Максимальное значение счетчика длины поля режима - 40 байт.

Поле Указатель должно содержать число байт от начала поля режима до конца последней отметки времени плюс 1. Наименьшее допустимое значение указателя "5".

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

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

Для поля флага, в соответствии с режимом заполнения поля отметок, должны поддерживаться следующие значения:

"0" - только отметки времени, записываемые в последовательных 4-х-байтовых словах,

"1" - каждая отметка времени записывается вместе с адресом узла, на котором она выполнена,

"3" - поля адресов заполняются заранее на предшествующих узлах. При прохождении соответствующего узла на нем выполняется только заполнение поля отметки времени по собственному адресу, и проставляется адрес следующего узла.

Отметка времени должна формироваться аппаратурой в миллисекундах и записываться в 4-х-байтовых словах. Отсчет времени должен выполняться от полуночи по универсальному скоординированному времени.

Для аппаратуры допускается отсчет времени в нестандартных единицах и от нестандартного источника. Для индикации такого отсчета старший бит поля отметки времени должен быть установлен в значение "1".

Аппаратура должна обеспечивать неизменность длины пакета IP в процессе внесения отметок времени в поле пакета.

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

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

Если свободного поля недостаточно для записи отметки времени полностью, или превышена разрядность поля Переполнение, аппаратура должна считать пакет пораженным ошибкой и исключать его из обработки и передачи; в аппаратуре должна обеспечиваться посылка сообщения протокола ICMP "Некорректные параметры обмена" по адресу источника пакета.

При фрагментации поле данного режима копированию не подлежит; не допускается наличие более одного поля данного режима в пакете.

3.1.1.4 Процедуры протокола IP

В протоколе IP должны быть реализованы две обязательные основные процедуры - адресация и фрагментация. Данные для этих процедур содержатся в заголовке пакета.

3.1.1.4.1 Процедура адресации

Аппаратура должна поддерживать предусмотренную в протоколе IP адресацию для сетей трех классов в соответствии со следующими форматами:

Не допускается нулевое значение в поле адреса сети для межсетевой маршрутизации (RFC 791 п. 3.2).

3.1.1.4.2 Процедура фрагментации

В случае если пакет IP подлежит передаче без фрагментации, аппаратура должна установить поля Флаги и Смещение фрагментации в его заголовке в значение "0".

Если пакет IP подлежит фрагментации, аппаратура должна разделять поле данных пакета на фрагменты с выравниванием по длине блока фрагментации (8 байт). Заголовок пакета процедуре фрагментации не подвергается.

Фрагментация пакетов длиной 68 байт и менее не допускается.

При фрагментации копирование полей режимов из заголовка пакета выполняется только для полей, для которых это предусмотрено в RFC 791, в противном случае поле режима сохраняется только в первом фрагменте пакета.

Следующие поля заголовка пакета могут подвергаться обработке при фрагментации:

- поле режимов;

- поле флагов;

- смещение фрагмента;

- длина заголовка;

- длина пакета;

- контрольная последовательность заголовка.

В случае, когда в заголовке пакета выставлен флаг, запрещающий его фрагментацию, пакет может быть исключен из процесса передачи. Установка данного флага предусматривается, когда ресурсы на приеме не позволяют поддерживать процедуру обратной сборки пакета (RFC 791 п. 3.2).

3.1.1.4.3 Обработка ошибок

В протоколе IP не реализованы поддержка защиты от ошибок при передаче пакета, квитирование передачи, как сквозное, так и транзитное, управление потоком, а также повторная передача пакетов. Контрольная последовательность предусматривается только для поля заголовка пакета.

Обнаружение ошибок должно быть реализовано средствами протокола управления (ICMP).

3.1.2 Требования к реализации функций протокола ICMP

Назначением протокола ICMP является формирование и управление передачей сообщений об ошибках при обработке пакетов IP, а также сообщений о состоянии узлов сети.

Протокол управления сообщениями ICMP является неотъемлемой частью протокола IP (RFC 792) и реализация его функций является обязательной для аппаратуры маршрутизации пакетов IP.

Требования к протоколу ICMP регламентируются стандартами Internet RFC 792 и RFC 1256.

3.1.2.1 Форматы сообщений ICMP

Аппаратура должна передавать сообщения ICMP в поле данных пакета IP. При этом значение первого байта поля данных пакета IP должно указывать на тип сообщения ICMP.

Кодирование полей заголовка пакета IP для сообщения ICMP должно осуществляться в соответствии со следующей таблицей:

Аппаратура должна устанавливать в "0" любое неиспользованное поле сообщения ICMP.

Правило подсчета контрольной последовательности в сообщениях протокола ICMP должно соответствовать RFC 792.

Рис. 3.4. Формат сообщений об ошибках протокола ICMP

3.1.2.2 Сообщения протокола ICMP об ошибках в пакетах IP

3.1.2.2.1 Сообщение "получатель недоступен"

Аппаратура должна формировать сообщение "Получатель недоступен" (Destination Unreachable Message) и отправлять его по адресу отправителя в случае, если:

- недоступен адрес получателя;

- недоступен порт в требуемом направлении передачи;

- не поддерживается требуемый стек протоколов;

- невозможна передача пакета без фрагментации при установленном флаге запрета фрагментации.

Кодирование поля сообщения Destination Unreachable Message должно осуществляться в соответствии со следующей таблицей

3.1.2.2.2 Сообщение "время пребывания пакета IP в сети истекло"

Аппаратура должна формировать сообщение "время пребывания пакета ЕР в сети истекло" (Time Exceeded Message - ТЕМ) в следующих случаях:

- При обнаружении, что поле "время пребывания пакета в сети" в данном пакете содержит нулевое значение;

- При обнаружении, что заданное время пребывания данного пакета в сети истекает прежде окончания сборки его фрагментов.

Сообщение должно передаваться по адресу источника данного пакета.

Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:

3.1.2.2.3 Сообщение "Проблемы в параметрах"

Аппаратура должна формировать сообщение "Проблемы в параметрах" (Parameter Problem Message - PPM) если значения параметров заголовка пакета IP не позволяют завершить его корректную обработку.

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

Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:

3.1.2.2.4 Сообщение "Подавление источника"

Аппаратура должна формировать сообщение "Подавление источника" (Source Quench Message - SQM) в случае невозможности обработки принимаемых пакетов по причинам:

- переполнения буферной памяти;

- высокой интенсивности поступления пакетов.

Сообщение должно передаваться по адресу источника удаляемого из обработки пакета.

Допускается формирование сообщения "подавление источника" для каждого удаленного из обработки пакета.

В случае приема сообщения "подавление источника" аппаратура должна уменьшить интенсивность передачи пакетов.

Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:

3.1.2.2.5 Сообщение "Перенаправление"

Аппаратура должна формировать сообщение "Перенаправление" (Redirect Message - RM) в случае, если шлюз, через который надлежит продолжить передачу принадлежит той же сети, что и узел-отправитель.

Сообщение должно передаваться по адресу источника пакета.

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

Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:

Аппаратура не должна формировать сообщение "перенаправление" для пакетов, в заголовке которых указаны функции маршрутизации от узла-отправителя и адрес шлюза в поле адреса получателя, даже если этот маршрут неоптимален (RFC 792).

3.1.2.3 Сообщения ICMP о состоянии узлов сети

3.1.2.3.1 Сообщения "запрос эхо / отклик эхо"

Аппаратура должна формировать сообщение "запрос эхо" (Echo) по инициативе системы административного управления.

При получении сообщения "запрос эхо" аппаратура должна сформировать ответное сообщение "отклик эхо" (Echo Reply Message - EoERM).

Рис. 3.5. Формат сообщений Echo or Echo Reply Message

Значение поля Тип сообщения должно быть установлено в "8" для "запроса эхо" и в "0" для "отклика эхо".

Поле данных, принятое в сообщении "запрос эхо" должно быть послано обратно в сообщении "отклик эхо" без изменений.

Поля Идентификатор и Порядковый номер являются параметрами для отслеживания соответствия многократной посылки сообщений и получения откликов.

Поле кода сообщения должно быть установлено в значение "0".

3.1.2.3.2 Сообщения "Отметка времени/Отклик на отметку времени"

Аппаратура должна формировать сообщения "Отметка времени/Отклик на отметку времени" (Timestamp / Timestamp Reply Message ToTRM) по инициативе системы административного управления.

Рис. 3.6. Формат сообщения Timestamp or Timestamp Reply Message

Кодирование сообщений должно осуществляться в соответствии с форматом, приведенном на рисунке и следующими правилами:

Поля Идентификатор и Порядковый номер должны использоваться параметрами для отслеживания соответствия многократной посылки сообщения и получения откликов.

Значение поля Тип сообщения устанавливается в "13" для сообщения "отметка времени" и в "14" для сообщения "отклик на отметку времени".

Поле кода сообщения должно устанавливаться в "0".

В поле "Отметка исходного времени" должен фиксироваться момент времени, когда отправитель завершил формирование данного сообщению для его отправки.

В поле "Отметка времени приема" должен фиксироваться момент времени, когда получатель принял сообщение, но еще не приступил к его обработке.

В поле "Отметка времени передачи" должен фиксироваться момент времени, когда получатель завершил обработку сообщения для его возврата.

3.1.2.3.3 Сообщения "Информационный запрос/Ответ на информационный запрос"

Аппаратура должна формировать сообщения "Информационный запрос/Ответ на информационный запрос" (Information Request or Information Reply Message - IRoIRM) по инициативе системы административного управления для определения номера сети.

Рис. 3.7. Формат сообщения Information Request or Information Reply Message

Кодирование полей сообщений Information Request и Information Reply Message должно осуществляться в соответствии с форматом, приведенным на рисунке и следующим правилам:

Поля Идентификатор и Порядковый номер должны использоваться для отслеживания соответствия многократной посылки информационных запросов и получения откликов.

Значение поля Тип сообщения должно устанавливаться в "15" для информационного запроса Information Request Message и в "16" для отклика на информационный запрос Information Reply Message.

Поле кода сообщения должно устанавливаться в значение "0".

Сообщение Information Request Message может быть отправлено с установкой адреса отправителя в заголовке пакета IP, но с нулевым значением адреса получателя. В ответном сообщении Information Reply Message поля адресов должны быть полностью определены.

3.1.2.3.4 Сообщение "Объявление маршрутизатора"

Аппаратура должна формировать сообщение "Объявление маршрутизатора" (Router Advertisement Message) по инициативе системы административного управления.

Кодирование полей сообщения Router Advertisement Message должно осуществляться в соответствии с форматом, представленном на рисунке и следующими правилами:

В поле "адрес отправителя пакета" заголовка пакета IP, в котором передается сообщение Router Advertisement Message, должен содержаться адрес IP, принадлежащий интерфейсу, от которого отправлено сообщение.

В поле "адрес получателя пакета" заголовка пакета IP, в котором передается сообщение Router Advertisement Message, содержится адрес IP смежного узла или специально задаваемый адрес AdvertisementAddress.

Рис. 3.8. Формат сообщения Router Advertisement Message

В поле "Счетчик допустимого времени пребывания пакета IP в сети" устанавливается значение 1с, если в поле "Адрес получателя" задан групповой адрес вещания IP (IP multicast) или не менее 1с в остальных случаях.

Значение поля "Тип сообщения" в заголовке пакета ICMP устанавливается в "9", поле "Код" устанавливается в значение "0".

Правило подсчета контрольной последовательности должно соответствовать RFC 1256.

Поле "Число адресов" маршрутизатора должно соответствовать числу адресов, объявляемых в данном сообщении.

Поле "Размер входа адреса" содержит число 32-х-битовых слов информации для каждого адреса маршрутизатора (данный параметр зависит от версии протокола ICMP).

Поле "Срок действия адресов" содержит максимальное время в секундах, в течение которого адреса маршрутизатора могут считаться действительными.

Поле "Адрес маршрутизатора" содержит адрес IP отправляющего маршрутизатора на i-м интерфейсе, от которого отправляется данное сообщение (i = 1...Число адресов).

Поле "Уровень предпочтения" содержит адрес маршрутизатора, который должен использоваться по умолчанию и является предпочтительным по отношению к другим адресам маршрутизатора в одной и той же подсети.

3.1.2.3.5 Сообщение "Запрос маршрутизатора"

Аппаратура должна формировать сообщение "Запрос маршрутизатора" (Router Solicitation Message) по инициации системы административного управления

Рис. 3.9. Формат сообщения Router Solicitation Message

Поля сообщения Router Solicitation Message:

В поле "адрес отправителя пакета" заголовка пакета IP, в котором передается сообщение Router Solicitation Message, содержится адрес IP, принадлежащий интерфейсу, от которого отправлено сообщение, или нулевое значение.

В поле "адрес получателя пакета" заголовка пакета IP, в котором передается сообщение Router Solicitation Message, содержится специально задаваемый адрес SolicitationAddress.

В поле "Счетчик допустимого времени пребывания пакета IP в сети" устанавливается значение 1с, если в поле "Адрес получателя" задан групповой адрес вещания IP (IP multicast) или не менее 1с в остальных случаях.

Значение поля "Тип сообщения" в заголовке пакета ICMP устанавливается в "10", поле "Код" устанавливается в значение "0".

Правило подсчета контрольной последовательности должно соответствовать RFC 1256.

Поле "Зарезервировано" устанавливается в "0" и игнорируется при приеме сообщения.

3.2 ТРЕБОВАНИЯ К ФУНКЦИЯМ ПРОТОКОЛОВ ВНЕШНЕЙ МАРШРУТИЗАЦИИ ПАКЕТОВ IP

Аппаратура должна передавать информацию маршрутизации в поле данных пакетов протокола IP с указанием соответствующего значения протокола следующего уровня в заголовке пакета.

3.2.1 Протокол EGP (внешней маршрутизации)

3.2.1.1 Формат заголовка сообщения EGP

Для всех типов сообщений протокола EGP (Exterior Gateway Protocol) формат заголовка должен соответствовать RFC 904 Приложение А:

Рис. 3.10. Формат заголовка пакета сообщения протокола EGP

Аппаратура должна поддерживать следующие типы команд и сообщений (в соответствии RFC 904, п. 2):

3.2.1.2 Процедура инициирования сеанса со смежным узлом

3.2.1.2.1 Формат сообщения процедуры Neighbor Acquisition (тип сообщения 3)

Формат сообщения процедуры Neighbor Acquisition и коды состояния должны соответствовать RFC 904 Приложение А.1:

Рис. 3.11. Формат сообщения процедуры Neighbor Acquisition

3.2.1.2.2 Подтипы сообщений процедуры Neighbor Acquisition

Для процедуры Neighbor Acquisition, в соответствии с RFC 904, Приложение А.1., должна выполняться генерация и обработка следующих подтипов сообщений:

3.2.1.2.3 Поле информации о состоянии

Установка значения поля информации о состоянии должна выполняться в соответствии с RFC 904 Приложение А.1:

3.2.1.3 Процедура взаимодействия со смежным узлом

3.2.1.3.1 Формат сообщения процедуры Neighbor Reachability (тип сообщения 5)

Формат сообщения процедуры Neighbor Reachability должен соответствовать RFC 904 Приложение А.2:

Рис. 3.12. Формат сообщения процедуры Neighbor Reachability

3.2.1.3.2 Подтипы сообщений процедуры Neighbor Reachability

Для процедуры Neighbor Reachability, в соответствии с RFC 904 Приложение А.2, должна выполняться генерация и обработка следующих подтипов сообщений:

3.2.1.3.3 Поле информации о состоянии

Кодирование значения поля информации о состоянии должно выполняться в соответствии с RFC 904 Приложение А.2:

Сообщения приветствия Hello должны посылаться регулярно через интервал, определенный в сообщении процедуры инициирования сеанса Neighbor Acquisition (RFC 904, п. 2).

Сообщение поддержки сеанса I-H-Y должны посылаться в ответ на сообщение приветствия Hello (RFC 904 п. 2).

3.2.1.4 Процедура взаимодействия с сетью Network Reachability

3.2.1.4.1 Сообщение опроса "Poll" (тип сообщения 2)

Формат сообщения опроса Poll процедуры Network Reachability должен соответствовать RFC 904 Приложение А.3:

Рис. 3.13. Формат сообщения опроса Poll процедуры Network Reachability

Префикс (номер) сети-источника сообщения может состоять из 1 (для сети типа А), 2 (для сети типа В) или 3 (для сети типа С) байт. Незначащие разряды слева должны дополняться нулями.

Сообщение опроса Poll посылается регулярно через интервал, определенный в сообщении процедуры инициирования сеанса Neighbor Acquisition (RFC 904 п. 4)

Опрос узла с интервалом менее 2 мин. не допускается (RFC 904 п. 3.2).

В случае неприема ответного сообщения обновления информации маршрутизации Update на сообщение опроса Poll посылается повторное сообщение опроса с тем же порядковым номером (RFC 904 п. 4.4).

Допускается посылка только одного незапрошенного сообщения обновления данных маршрутизации Update между последующими командами опроса Poll, принимаемыми от смежного узла (RFC 904 п. 4.4).

При приеме сообщения Poll маршрутизатор должен выполнять одно из следующих действий:

- посылка сообщения Update, если в течение интервала опроса это первое сообщение опроса,

- повторная посылка сообщения Update (незапрошенное сообщение Update),

- посылка сообщения об ошибке,

- игнорирование сообщения Poll (RFC 904 п. 4.4).

3.2.1.4.2 Сообщение обновления информации маршрутизации "Update" (тип сообщения 1)

Рис. 3.14. Формат сообщения обновления информации маршрутизации UPDATE

Информация о доступности сетей должна кодироваться в сообщениях обновления информации маршрутизации Update в форме списка сетей и шлюзов.

Формат сообщения обновления информации маршрутизации UPDATE должен соответствовать RFC 904 Приложение А.4.

Сообщение Update может содержать два списка шлюзов. Оба списка включают в себя только шлюзы, напрямую соединяющиеся с сетью, адрес IP которой указан в последнем принятом сообщении опроса.

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

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

Только шлюзы, принадлежащие сети-получателю, могут содержать внешний список в сообщениях Update (RFC 904, п. 4.4).

При кодировании сообщения Update могут указываться следующие типы состояний (RFC 904, Приложение А.4):

3.2.1.5 Сообщение об ошибке "Error" (тип сообщения 8)

3.2.1.5.1 Формат сообщения Error

Формат сообщения Error протокола EGP должен соответствовать RFC 904 Приложение А.5:

Рис. 3.15. Формат сообщения об ошибке ERROR

Коды информации о состоянии в сообщении Error аналогичны кодам сообщения Update.

В сообщении об ошибке должна обеспечиваться индикация причины посылки данного сообщения (RFC 904, Приложение А.5):

Сообщение Error посылается после приема другого сообщения (команды или ответа) с неверным форматом, содержимым или порядком следования. Сообщение Error не посылается в ответ на другое сообщение Error. Получение сообщения Error само по себе не должно приводить к изменению состояния (RFC 904, п. 4.5).

Условия определения ошибочной ситуации приведены в RFC 904, Приложение А.5.

3.2.1.6 Процедуры и функции EGP

Аппаратура должна поддерживать следующие функции протокола EGP:

- функции управления переменными состояния (RFC 904, п. 4.1),

- инициации и завершения процедур протокола (RFC 904, п. 4.2),

- алгоритма определения доступности смежного узла (RFC 904, п. 4.3),

- алгоритма определения доступности сетей (RFC 904, п. 4.4),

- процедур обработки сообщений об ошибке (RFC 904, п. 4.5).

3.2.2 Протокол BGP-1 (пограничной маршрутизации)

3.2.2.1 Формат заголовка и типы сообщений BGP-1

Для всех типов сообщений BGP-1 (Border Gateway Protocol-1) формат заголовка должен соответствовать RFC 1105 п. 3.1:

Рис. 3.16. Формат заголовка сообщения протокола BGP-1

В BGP-1 предусматриваются следующие типы сообщений (RFC 1105 п. 3):

3.2.2.2 Сообщения BGP-1

Минимальная длина сообщения BGP-1 составляет 8 байт (сообщение состоит из заголовка), максимальная длина - 1024 байт (RFC 1105 п. 3).

3.2.2.2.1 Формат сообщения инициирования сеанса "OPEN"

Формат сообщения OPEN должен соответствовать RFC 1105 п. 3.2:

Рис. 3.17. Формат сообщения инициирования сеанса OPEN

Для данного сообщения предусматриваются следующие коды типа звена (RFC 1105 п. 3.2):

3.2.2.2.2 Формат сообщения подтверждения установления сеанса "OPEN CONFIRM"

Сообщение OPEN CONFIRM состоит только из заголовка (код типа сообщения 5) без поля данных (RFC 1105 п. 3.3).

Сообщение OPEN CONFIRM посылается в ответ на посланное сообщение инициирования сеанса OPEN (RFC 1105 п. 3.3).

3.2.2.2.3 Формат сообщения обновления данных маршрутизации "UPDATE"

Формат сообщения UPDATE должен соответствовать RFC 1105 п. 3.4.

Рис. 3.18. Формат сообщения UPDATE

Для данного сообщения предусматриваются следующие коды направления перехода по графу маршрутов:

3.2.2.2.4 Формат сообщения уведомления "NOTIFICATION"

Формат сообщения должен соответствовать RFC 1105 п. 3.5.

Сообщение NOTIFICATION посылается в случае обнаружения ошибки в любом из сообщений протокола BGP-1. Сразу же после этого сеанс BGP-1 считается завершенным (RFC 1105 п. 3.5).

Рис. 3.19. Формат сообщения NOTIFICATION

Для сообщения NOTIFICATION предусматриваются следующие типы уведомлений:

Все ошибки, кроме ошибки при обновлении данных маршрутизации должны рассматриваться как неисправимые и приводить к разрыву соединения транспортного протокола (RFC 1105 п. 3.5, 3.6).

Поле данных для диагностики может: не содержать ни одного байта (ошибки типа 2, 3, 5, 9, 10), содержать копию неверного значения поля сообщения (ошибки типа 6, 7, 8) или содержать коды ошибок (RFC 1105 п. 3.5):

3.2.2.2.5 Формат сообщения поддержки сеанса "KEEPALIVE"

Сообщение KEEPALIVE должно состоять только из заголовка (код типа сообщения 4) без поля данных (RFC 1105 п. 3.5).

Обмен сообщениями KEEPALIVE между взаимодействующими узлами должен осуществляться до истечения тайм-аута, задаваемого в заголовке сообщений. Минимальный интервал обмена сообщениями KEEPALIVE должен быть не менее 1/3 тайм-аута.

По истечении тайм-аута сеанс BGP-1 завершается (RFC 1105 п. 3.5).

3.2.2.3 Процедуры и функции BGP-1

Для аппаратуры, поддерживающей BGP-1, должны быть реализованы следующие процедуры:

- установка кода аутентификации (RFC 1105 п. 3.1);

- идентификация, обработка и формирование списка кодов ошибок для сообщения NOTIFICATION (RFC 1105 п. 3.5);

- процедура обработки ошибок заголовка сообщений (RFC 1105 п. 3.1);

- процедура обработки ошибок сообщений OPEN и OPEN CONFIRM (RFC 1105 п. 3.2);

- процедура обработки ошибок сообщения UPDATE (RFC 1105 п. 3.4.5);

- поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1105 п. 4);

- процедура обработки завершения сеанса (RFC 1105 п. 4).

3.2.3 Протокол BGP-2 (пограничной маршрутизации)

3.2.3.1 Формат заголовка и типы сообщений BGP-2

Для всех типов сообщений BGP-2 (Border Gateway Protocol-2) формат заголовка должен соответствовать RFC 1163 п. 4:

Рис. 3.20. Формат заголовка сообщения протокола BGP-2

В BGP-2 предусматриваются следующие типы сообщений (RFC 1163 п. 4.1):

3.2.3.2 Сообщения BGP-2

Минимальная длина сообщения BGP-2 составляет 19 байт (сообщение состоит из заголовка), максимальная длина - 4096 байт (RFC 1163 п. 4).

3.2.3.2.1 Формат сообщения инициирования сеанса "OPEN"

Формат сообщения OPEN должен соответствовать RFC 1163 п. 4.2:

Рис. 3.21. Формат сообщения инициирования сеанса OPEN

Структура и значения полей сообщения OPEN должны соответствовать RFC 1163 п. 4.2.

Поля кода аутентификации и данных аутентификации должны быть установлены в нулевое значение. Допускается использование ненулевого значения полей кода и данных аутентификации при использовании механизма аутентификации (RFC 1105 п. 4.2).

3.2.3.2.2 Формат сообщения обновления данных маршрутизации "UPDATE"

Формат сообщения UPDATE должен соответствовать RFC 1163 п. 4.3:

Значение поля Длина поля Атрибуты пути соответствует суммарной длине данного поля переменной длины в байт. Данное значение должно составлять целое неотрицательное число полей Номер сети IP.

Каждое поле Атрибут пути имеет переменную длину и состоит из трех частей (подполей):

- тип атрибута,

- длина атрибута,

- значение атрибута.

Рис. 3.22. Формат сообщения UPDATE протокола BGP-2

Не допускается использование атрибута в одном и том же сообщении UPDATE больше одного раза (RFC 1163 п. 5).

Тип атрибута (длина подполя 2 байта), в свою очередь, состоит из:

- поля флагов атрибута (старший байт),

- поля кода типа атрибута (младший байт).

Кодирование поля флагов атрибута должно осуществляться в соответствии со следующими правилами (RFC 1163 п. 4.3):

- бит 0 (старший) в поле флагов атрибута предназначен для индикации, является ли атрибут обязательным (значение "1" - обязательный, значение "0" - необязательный);

- бит 1 в поле флагов атрибута определяет, является ли необязательный атрибут транзитивным (значение "1" - является, значение "0" - не является). Для обязательного атрибута данный бит всегда установлен в значение "1" (транзитивные атрибуты должны пропускаться через узел без обработки);

- бит 2 в поле флагов атрибута определяет, может ли информация, содержащаяся в необязательном транзитивном атрибуте, быть разделена на части (значение "1" - разбиение допускается, значение "0" - не допускается), для обязательных атрибутов и необязательных нетранзитивных атрибутов данный бит всегда должен устанавливаться в значение "0";

- бит 3 в поле флагов атрибута определяет длину атрибута в байт (значение "1" -2 байта, значение "0" - 1 байт), длина атрибута в 2 байта допускается только в случае, когда длина значения атрибута превышает 255 байт;

- биты 4-7 в поле флагов атрибута не используются и устанавливаются в нулевое значение.

Соответствие поля кода типа атрибута, длины атрибута и значения (категории) атрибута приведено в следующей таблице:

ORIGIN - определяет источник информации о пути. В поле данных могут находиться следующие значения:

0 - сеть (сети) является внутренней по отношению к источнику (сети) (передача по протоколу IGP),

1 - сеть (сети) является внешней по отношению к источнику (сети) (передача по протоколу EGP),

2 - не регламентируется.

AS_PATH - (автономные системы), через которые необходимо пройти до сетей, перечисляемых в сообщении UPDATE.

NEXT_HOP - адрес IP пограничного узла маршрутизации, который должен быть задействован в качестве транзитного к сетям, перечисляемым в сообщении UPDATE. Пограничный узел маршрутизации должен принадлежать той же сети, что и узел, обменивающийся по протоколу BGP-2 и посылающий данные о ее доступности.

INREACHABLE - используется для уведомления узла маршрутизации BGP-2 о том, что сведения о ранее заявленных маршрутах устарели.

INTER-AS METRIC - может быть использован на внешних звеньях для различия между несколькими точками входа/выхода в одну и ту же смежную сеть. Значением атрибута является целое двухбайтовое число, называемое метрикой. При приеме по внешнему звену данный атрибут может быть распространен по внутренним звеньям сети к другим узлам маршрутизации BGP-2 в рамках сети. Данный атрибут не должен распространяться к другим узлам маршрутизации BGP-2 в смежной сети.

Если бит 3 в поле флагов атрибута установлен в 0, третий байт атрибута пути содержит длину данных атрибута в байт, если в 1 - длину данных атрибута в байт содержат третий и четвертый байты.

Остальные байты атрибута пути содержат значение атрибута и интерпретируются в соответствии с флагами атрибута и кодом типа атрибута.

Значения атрибута должны соответствовать RFC 1163 п. 5.

Номер сети IP, состоящий из четырех байт, идентифицирует сеть, описываемую с помощью атрибутов пути и участвующую в межсетевой маршрутизации. Не допускается использовать номера подсетей и базовых узлов. Общее число полей Номер сети IP в сообщении UPDATE определяется по формуле:

Длина сообщения = 19 + суммарная длина атрибутов пути + 4 х номер сети.

Результат расчета по данной формуле должен приводить к целому неотрицательному числу полей Номер сети IP.

Минимальная длина сообщения UPDATE, включая заголовок, составляет 37 байт (RFC 1163 п. 4.3).

3.2.3.2.3 Формат сообщения уведомления "NOTIFICATION"

Сообщение уведомления посылается при обнаружении ошибки. Сразу же после посылки данного сообщения сеанс межсетевого обмена протокола завершается.

Формат сообщения NOTIFICATION должен соответствовать RFC 1163 п. 4.5:

Рис. 3.23. Формат сообщения NOTIFICATION

Предусматриваются следующие коды ошибки:

Поле субкода ошибки заполняется значением целого числа. Значение "0" устанавливается в случае, если для данного типа ошибок субкода не предусмотрено.

Для ошибок в заголовке сообщения предусматриваются следующие субкоды:

Для ошибок в сообщении OPEN предусматриваются следующие субкоды:

Для ошибок в сообщении UPDATE предусматриваются следующие субкоды:

Поле данных сообщения уведомления используется для диагностики причины посылки данного сообщения. Правила заполнения поля данных информацией для диагностики должны соответствовать RFC 1163 п. 6.

Длина поля данных определяется исходя из следующей формулы:

Длина сообщения = 21+ длина поля данных

Минимальная длина сообщения уведомления составляет 21 байт, включая заголовок (RFC 1163 п. 4.3).

3.2.3.2.4 Формат сообщения поддержки сеанса "KEEPALIVE"

Сообщение KEEPALIVE состоит только из заголовка длиной 19 байт (код типа сообщения 4) без поля данных (RFC 1163 п. 4.4).

Обмен сообщениями KEEPALIVE между взаимодействующими узлами должен осуществляться до истечении тайм-аута, задаваемого в сообщении инициирования сеанса OPEN. Максимальный интервал обмена сообщениями KEEPALIVE должен быть не менее 1/3 тайм-аута.

По истечении тайм-аута сеанс BGP-2 завершается (RFC 1163 п. 4.4).

3.2.3.3 Процедуры и обработка ошибок BGP-2

В соответствии с RFC 1163, для аппаратуры, поддерживающей протокол BGP-2, должны быть реализованы следующие процедуры:

- установка кода аутентификации (RFC 1163, п. 4.2);

- процедура согласования версии протокола (RFC 1163, п. 7);

- идентификация, обработка и формирование списка кодов ошибок для сообщения NOTIFICATION (RFC 1163, п. 4.5, 6.4);

- обработки ошибок заголовка сообщений протокола BGP-2 (RFC 1163, п. 6.1);

- процедура формирования списка атрибутов пути (RFC 1163, п. 5);

- процедура обработки сообщений обновления данных маршрутизации (RFC 1163, п. 6.3);

- поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1163, п. 6.5, 6.6);

- процедура обработки завершения сеанса (RFC 1163, п. 6.7).

3.2.4 Протокол BGP-3 (пограничной маршрутизации)

Аппаратура должна инициировать сеанс протокола BGP-3 в соответствии с условиями, определенными в RFC 1267 п. 2.

3.2.4.1 Формат заголовка и типы сообщений BGP-3

Для всех типов сообщений протокола BGP-3 в аппаратуре должен поддерживаться формат заголовка, соответствующий RFC 1267 п. 4.1:

Рис. 3.24. Формат заголовка сообщения протокола BGP-3

Аппаратура должна обеспечивать обработку следующих типов сообщений BGP-3 (RFC 1267 п. 4.1):

3.2.4.2 Сообщения BGP-3

Аппаратура должна поддерживать требования к длине сообщения протокола (минимальная длина - 19 байт (сообщение состоит только из заголовка), максимальная длина - 4096 байт), и требования к форматам сообщений (RFC 1267, п. 4).

3.2.4.2.1 Сообщение инициирования сеанса "OPEN"

Формат сообщения OPEN должен соответствовать RFC 1267 п. 4.2.

Рис. 3.25. Формат сообщения инициирования сеанса OPEN

Структура и значения полей сообщения OPEN должны соответствовать RFC 1267 п. 4.2.

Поля кода аутентификации и данных аутентификации должны быть установлены в нулевое значение. Допускается использование ненулевого значения полей кода и данных аутентификации при использовании механизма аутентификации (RFC 1267 п. 4.2).

Аппаратура должна осуществлять посылку сообщения OPEN для инициирования сеанса протокола BGP-3.

При приеме сообщения OPEN аппаратурой должен инициироваться счетчик тайм-аута и начать выполняться генерация и посылка сообщений KEEPALIVE.

3.2.4.2.2 Сообщение обновления данных маршрутизации "UPDATE"

Формат сообщения UPDATE должен соответствовать RFC 1267 п. 4.3.

Рис. 3.26. Формат сообщения UPDATE

Поле Атрибуты пути является обязательным для сообщения UPDATE. Последовательность атрибутов пути должна состоять из трех подполей:

- тип атрибута,

- длина атрибута,

- значение атрибута.

Тип атрибута (длина подполя 2 байта) в свою очередь должен состоять из:

- поля флагов атрибута (старший байт),

- поля кода типа атрибута (младший байт).

Кодирование поля флагов атрибута должно осуществляться в соответствии со следующими правилами (RFC 1267 п. 4.3):

- бит 0 (старший) в поле флагов атрибута предназначен для индикации обязательности атрибута: (значение "1" - обязательный, значение "0" - необязательный);

- бит 1 в поле флагов атрибута предназначен для индикации транзитивности необязательного атрибута (значение "1" - является транзитивным, значение "0" - не является транзитивным). Для обязательного атрибута данный бит должен быть всегда установлен в значение "1" (транзитивные атрибуты должны пропускаться аппаратурой без обработки);

- значение бита 2 в поле флагов атрибута должно соответствовать возможности разбиения информации, содержащейся в необязательном транзитивном атрибуте (значение "1" - разбиение допускается, значение "0" - не допускается), для обязательных атрибутов и необязательных нетранзитивных атрибутов данный бит всегда должен устанавливаться в значение "0";

- значение бита 3 в поле флагов атрибута должно соответствовать длине атрибута в байт (значение "1" - 2 байта, значение "0" - 1 байт); длина атрибута в 2 байта допускается только в случае, когда длина значения атрибута превышает 255 байт;

- биты 4-7 в поле флагов атрибута не используются и должны устанавливаться в нулевое значение.

Если бит 3 в поле флагов атрибута установлен в значение "0", длину данных атрибута в байт должен содержать третий байт Атрибута пути, если в "1" - третий и четвертый байты.

Третье подполе поля Атрибута пути должно содержать значение атрибута и интерпретироваться в соответствии с Флагами атрибута и Кодом типа атрибута.

Значения (категория) атрибута должны соответствовать RFC 1267 п. 5.

Атрибут ORIGIN должен использоваться для определения источника информации о пути. В поле данных атрибута могут находиться следующие значения:

0 - сеть является внутренней по отношению к источнику пакета,

1 - есть является внешней по отношению к источнику пакета,

2 - регламентируется.

Атрибут AS_PATH должен использоваться для хранения перечня путей, проходимых пакетом, до сетей, перечисляемых в сообщении UPDATE.

Атрибут NEXT_HOP должен использоваться для определения адреса пограничного узла маршрутизации, который должен быть задействован в качестве транзитного к сетям, перечисляемым в сообщении UPDATE.

Атрибут INREACHABLE должен использоваться для уведомления узла маршрутизации протокола BGP-3 о том, что сведения о ранее заявленных маршрутах устарели.

Значение атрибута INTER-AS METRIC должно быть целым двухбайтовым числом.

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

Длина сообщения = 19 + суммарная длина атрибутов пути + 4 х номер сети.

Результат расчета по данной формуле должен приводить к целому неотрицательному числу полей Сеть.

Минимальная длина сообщения UPDATE, включая заголовок, должна составлять 37 байт (RFC 1267 п. 4.3).

Генерация и посылка сообщения UPDATE должна осуществляться аппаратурой при обновлении данных маршрутизации.

При приеме сообщения UPDATE счетчик тайм-аута в аппаратуре должен быть обнулен.

3.2.4.2.3 Сообщение поддержки сеанса "KEEPALIVE"

Сообщение KEEPALIVE должно состоять из заголовка длиной 19 байт (код типа сообщения 4) без поля данных (RFC 1267 п. 4.4).

В целях поддержки сеанса BGP-3 при отсутствии обмена другими сообщениями аппаратурой должна осуществляться периодическая генерация и передача сообщения KEEPALIVE до истечения тайм-аута, задаваемого в сообщении инициирования сеанса OPEN. В аппаратуре должен поддерживаться максимальный интервал посылки сообщений KEEPALIVE длительностью не менее 1/3 тайм-аута.

При приеме сообщения KEEPALIVE счетчик тайм-аута в аппаратуре должен быть обнулен.

При неприеме каких-либо сообщений по истечении заданного тайм-аута аппаратура должна обеспечивать завершение сеанса BGP-3 (RFC 1267 п. 4.4).

3.2.4.2.4 Сообщение уведомления "NOTIFICATION"

Формат сообщения NOTIFICATION должен соответствовать RFC 1267 п. 4.5.

Рис. 3.27. Формат сообщения NOTIFICATION

В сообщении NOTIFICATION должны поддерживаться следующие коды ошибки:

Поле субкода ошибки должно заполняться значением целого числа. Значение "0" должно устанавливаться в случае, если для данного типа ошибок субкода не предусмотрено.

Для ошибок в заголовке сообщения должны поддерживаться следующие субкоды:

Для ошибок в сообщении OPEN должны поддерживаться следующие субкоды:

Для ошибок в сообщении UPDATE должны поддерживаться следующие субкоды:

Поле данных сообщения уведомления должно использоваться для диагностики причины посылки данного сообщения. Правила заполнения поля данных информацией для диагностики должны соответствовать RFC 1267 п. 6.

Длина поля данных должна определяться исходя из следующей формулы:

Длина сообщения = 21 + длина поля данных

Минимальная длина сообщения уведомления должна составлять 21 байт, включая заголовок (RFC 1267 п. 4.3).

Генерация и посылка сообщения уведомления с кодом и субкодом, соответствующими данному типу ошибок, должна обеспечиваться в аппаратуре при обнаружении ошибки. Сразу же после посылки данного сообщения аппаратура должна обеспечивать завершение сеанса BGP-3.

3.2.4.3 Процедуры и обработка ошибок BGP-3

В соответствии с RFC 1267, в аппаратуре должны быть реализованы следующие процедуры:

процедуры обработки ошибок (RFC 1267 п. 6);

установка кода аутентификации (RFC 1267 п. 4.2);

процедура согласования версии протокола (RFC 1267 п. 7);

идентификация, обработка и формирование списка кодов ошибок для сообщения NOTIFICATION (RFC 1267 п. 6.4);

процедура формирования списка атрибутов пути (RFC 1267 п. 5);

процедура обработки сообщений обновления данных маршрутизации (RFC 1267 п. 6.3);

поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1267 п. 6.5);

процедура обработки завершения сеанса (RFC 1267 п. 6.7);

процедура обнаружения конфликта сеансов (RFC 1267 п. 6.8);

процедура обнаружения противоречий между стратегиями маршрутизации автономных систем (RFC 1267 п. 10);

процедура настройки периодичности выбора маршрута (RFC 1267 п. А.5.5).

Все таймеры, реализованные в аппаратуре для поддержки BGP-3, должны быть конфигурируемы (RFC 1267 п. А.5.4).

3.2.5 Протокол BGP4 (пограничной маршрутизации)

Для BGP-4 допускается использование равнозначного названия Протокол бесклассовой межрегиональной маршрутизации CIDR.

Инициирование сеанса BGP-4 аппаратурой допускается при условиях, предусмотренных в RFC 1771 п. 2.

3.2.5.1 Формат заголовка и типы сообщений BGP-4

Для всех типов сообщений BGP-4 формат заголовка должен соответствовать RFC 1771 п. 4.1:

Рис. 3.28. Формат заголовка сообщения BGP-4

В аппаратуре должны поддерживаться следующие типы сообщений BGP-4 (RFC 1771 п. 4.1):

3.2.5.2 Сообщения BGP-4

Аппаратура должна поддерживать требования к длине сообщения протокола (минимальная длина - 19 байт (сообщение состоит только из заголовка), максимальная длина - 4096 байт), и требования к форматам сообщений (RFC 1771, п. 4).

3.2.5.2.1 Сообщение инициирования сеанса "OPEN"

Формат сообщения OPEN должен соответствовать RFC 1771 п. 4.2.

Рис. 3.29. Формат сообщения OPEN

Структура и значения полей сообщения OPEN должны соответствовать RFC 1771 п. 4.2.

3.2.5.2.2 Сообщение обновления данных маршрутизации "UPDATE"

Формат сообщения UPDATE должен соответствовать RFC 1771 п. 4.3:

Рис. 3.30. Формат сообщения UPDATE

Структура и значения полей сообщения UPDATE должны соответствовать RFC 1771 п. 4.3.

3.2.5.2.3 Сообщение поддержки сеанса "KEEPALIVE"

Сообщение KEEPALIVE должно состоять из заголовка длиной 19 байт (код типа сообщения 4) без поля данных (RFC 1771 п. 4.4).

В целях поддержки сеанса BGP-4 при отсутствии обмена другими сообщениями аппаратурой должна осуществляться периодическая генерация и передача сообщения KEEPALIVE до истечения тайм-аута, задаваемого в сообщении инициирования сеанса OPEN. В аппаратуре должен поддерживаться максимальный интервал посылки сообщений KEEPALIVE длительностью не менее 1/3 тайм-аута.

При приеме сообщения KEEPALIVE счетчик тайм-аута в аппаратуре должен быть обнулен.

При неприеме каких-либо сообщений по истечении заданного тайм-аута аппаратура должна обеспечивать завершение сеанса BGP-4 (RFC 1771 п. 4.4).

3.2.5.2.4 Сообщение уведомления "NOTIFICATION"

Формат сообщения NOTIFICATION должен соответствовать RFC 1771 п. 4.5.

Рис. 3.31. Формат сообщения NOTIFICATION

В аппаратуре должны поддерживаться следующие коды ошибки:

Поле субкода ошибки должно заполняться значением целого числа. Значение "0" должно устанавливаться в случае, если для данного типа ошибок субкода не предусмотрено.

Для ошибок в заголовке сообщения должны поддерживаться следующие субкоды:

Для ошибок в сообщении OPEN должны поддерживаться следующие субкоды:

Для ошибок в сообщении UPDATE должны поддерживаться следующие субкоды:

Поле данных сообщения уведомления должно использоваться для диагностики причины посылки данного сообщения. Правила заполнения поля данных информацией для диагностики должны соответствовать RFC 1771 п. 6.

Длина поля данных должна определяться исходя из следующей формулы:

Длина сообщения = 21 + длина поля данных

Минимальная длина сообщения уведомления должна составлять 21 байт, включая заголовок (RFC 1771 п. 4.5).

Генерация и посылка сообщения уведомления с кодом и субкодом, соответствующими данному типу ошибок, должна обеспечиваться в аппаратуре при обнаружении ошибки. Сразу же после посылки данного сообщения аппаратура должна обеспечивать завершение сеанса BGP-4.

3.2.5.3 Процедуры и функции BGP-4

В соответствии с RFC 1771, в аппаратуре должны быть реализованы следующие процедуры:

- поддержка информационных баз BGP-4 (RFC 1771, п. 3.2);

- процедуры обработки ошибок BGP-4 (RFC 1771, п. п. 6.1-6.4);

- установка кода аутентификации (RFC 1771, п. 4.2);

- процедура согласования версии протокола (RFC 1771, п. 7);

- процедура формирования списка атрибутов пути (RFC 1771 п. 5);

- поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1771 п. 6.5);

- процедура обработки завершения сеанса (RFC 1771 п. 6.7);

- процедура обработки сообщений обновления данных маршрутизации (RFC 1771 п. 7);

- процедура обнаружения и разрешения конфликта сеансов (RFC 1771 п. 6.8);

- процедура обработки критериев выбора маршрута (RFC 1771 п. 9.3).

Все таймеры, реализованные в аппаратуре для поддержки BGP-4, должны быть конфигурируемы (RFC 1771 п. А.6.4).

3.3 ТРЕБОВАНИЯ К ФУНКЦИЯМ ПРОТОКОЛА РАЗРЕШЕНИЯ АДРЕСОВ

Реализация функций протокола разрешения адресов Address Resolution Protocol (ARP) является обязательной для аппаратуры. Требования к функциям и форматам сообщений ARP регламентируются стандартами Internet RFC 826, 1042, 1390

3.3.1 Сообщения ARP

Аппаратура должна обеспечивать обработку пакетов сообщений ARP. Должны поддерживаться два типа сообщения ARP:

- Запрос

- Ответ на запрос.

Формат сообщений одинаковый, значение поля Код операции должно определять тип сообщения. Поле Код операции должно устанавливаться в значение "1" для пакета запроса ARP и в значение "0" для пакета ответа на запрос (RFC 826).

Генерация пакета запроса ARP должна инициироваться аппаратурой в случае, когда в таблице соответствия физических (сетевых) адресов и адресов Internet отсутствует адрес получателя пакета IP, принятого аппаратурой и подлежащего дальнейшей передаче.

Аппаратура должна обеспечивать установку группового широковещательного адреса подсети, к которой она принадлежит, в поле Адрес получателя пакета в сети стандарта IEEE 802 пакета запроса ARP. Поле Адрес отправителя пакета в сети стандарта IEEE 802 должно устанавливаться в значение, соответствующее собственному адресу Internet аппаратуры. Поле Физический адрес получателя пакета должно устанавливаться в нулевое значение. Аппаратура должна обеспечить групповую передачу пакета запроса ARP ко всем подсоединенным узлам.

Если аппаратура принимает пакет запроса ARP, содержащий ее собственный адрес Internet в поле Протокольный адрес получателя пакета, она должна обеспечить генерацию и посылку пакета ответа на запрос ARP по адресу отправителя запроса. В этом пакете она должна выполнить установку собственного физического (сетевого) адреса в поле Физический адрес получателя пакета, до этого установленного в нулевое значение.

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

3.3.2 Протокол разрешения адресов ARP при передаче пакетов протокола IP по сети в стандарте IEEE 802

3.3.2.1 Формат пакета протокола ARP

Рис. 3.32. Формат пакета ARP (RFC 826)

Для всех типов сетей стандарта IEEE 802 поле Адресное пространство физической сети должно устанавливаться в значение "6".

Поле Тип протокола для передачи пакетов IP в должно устанавливаться значение "2048".

Поле Длина адреса физической сети должно устанавливаться в значение "2" для 16-битовых и "6" для 48-битовых адресов сетей стандарта IEEE 802.

Поле Длина адреса протокола должно устанавливаться в значение "4" для IP (RFC 1042).

3.3.2.2 Передача/прием пакетов ARP в локальной сети стандарта IEEE 802

Пакеты ARP должны передаваться в формате пакета Ненумерованная информация (UI) Уровня логического управления звеном (LLC) типа 1 стандарта IEEE 802.2 с кодом управления 3. Поля заголовка пакета UI в этом случае должны устанавливаться в следующие значения: поля DSAP и SSAP устанавливаются в "170", глобальное значение SAP должно соответствовать SNAP. Установка значений полей пакета для SNAP должна соответствовать RFC 1042.

Минимальный размер пакета UI, переносящего пакет ARP, должен составлять 24 байта.

Максимальный размер пакета UI, переносящего пакет ARP, ограничивается максимальным размером пакета в каждой конкретной сети стандарта IEEE 802.

Возможность принимать пакеты UI, переносящие пакеты ARP и при необходимости фрагментировать их является обязательным требованием к аппаратуре.

3.3.2.3 Передача/прием пакетов ARP в локальной сети стандарта IEEE 802.5 (Token Ring)

Минимальный размер пакета UI, переносящего пакет ARP, для сети стандарта IEEE 802.5 не ограничен.

Максимальный размер пакета UI, переносящего пакет ARP, должен определяться в соответствии со временем удержания маркера на узле.

Для поддержки передачи пакета запроса ARP по физической сети в аппаратуре должна быть реализована процедура обнаружения динамических адресов.

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

Не допускается использование групповых и функциональных адресов в пакетах ARP.

Для пакетов UI, содержащих пакеты ARP, приоритет должен устанавливаться по умолчанию (RFC 1042).

3.3.3 Протокол разрешения адресов ARP при передаче пакетов протокола IP по сети в стандарте ISO 9314 (FDDI)

Обработка пакетов протокола ARP по сети в стандарте ISO 9314 регламентируется RFC 1390.

3.3.3.1 Формат пакета протокола ARP

При передаче по локальной сети FDDI формат пакета протокола ARP должен соответствовать формату, предусмотренному для сетей стандарта IEEE 802.

Установка значений полей пакета должна соответствовать предусмотренному для сетей стандарта IEEE 802 за исключением поля Адресное пространство физической сети (для сети FDDI данное поле должно устанавливаться в значение "1").

Порядок инкапсуляции пакетов протокола ARP должен соответствовать RFC 1390.

Суммарная длина заголовка пакета уровня логического управления звеном (LLC) и заголовка протокола SNAP должна составлять 8 байт.

Для передачи пакетов протоколов IP и ARP аппаратура должна обеспечивать использование адресов FDDI только с длиной 6 байт.

Поразрядная интерпретация адресов в пакете ARP для сети FDDI должна осуществляться в обратном порядке в границах каждого байта.

Групповой широковещательный адрес Internet должен отображаться в групповой широковещательный адрес FDDI.

Групповой многоточечный адрес IP должен отображаться в групповой многоточечный адрес FDDI путем размещения 23-х младших битов адреса IP в младшие 23 бита адреса FDDI.

Передача пакетов протокола IP по сети FDDI должна осуществляться в режиме побайтовой поточной передачи.

Отображение адреса Internet (4 байта) в адрес сети FDDI (6 байт) должно осуществляться посредством процедуры обнаружения динамических адресов ARP.

3.3.3.2 Требования к ARP для Уровня управления доступом к среде передачи

Поддержка протоколов IP и ARP в аппаратуре предусматривается только для одиночных станций на уровне Управления доступом к среде передачи (MAC) (с подключением к одиночному или двойному кольцу).

Аппаратура должна поддерживать спецификации Уровня управления доступом к среде передачи сети FDDI (ISO 9314-2).

Аппаратура должна обеспечивать прием пакетов в пределах максимального блока передачи (MTU) сети FDDI и при необходимости их фрагментацию.

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

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

В аппаратуре должна обеспечиваться передача кадров с пакетами протоколов IP и ARP в виде Асинхронных кадров уровня Логического управления звеном данных (LLC) с использованием маркеров общего вида (Unrestricted tokens).

В аппаратуре должен обеспечиваться порядок кодирования полей кадров на уровне Управления доступом к среде передачи (MAC).

Пакеты Ненумерованная информация с установленным битом Poll должны игнорироваться.

Порядок обработки команд уровня Логического управления звеном данных (LLC) должен соответствовать RFC 1390.

3.4 ТРЕБОВАНИЯ К ПРОЦЕДУРАМ ИНКАПСУЛЯЦИИ ПАКЕТОВ ПРОТОКОЛА IP

3.4.1 Инкапсуляция пакетов протокола IP в пакеты протокола Х.25

Требования к процедурам инкапсуляции пакетов IP в пакеты Х.25 регламентируются стандартом Internet RFC 1356.

3.4.1.1 Формат пакетов инкапсуляции

Пакет Запрос вызова Х.25 (Рис. 5-3, Рекомендация МСЭ-Т Х.25, 03/93) в поле Данные вызова пользователя должен содержать идентификатор протокола сетевого уровня NLPID (длиной 1 байт), инкапсулируемого по виртуальному каналу Х.25.

Для IP данный идентификатор NLPID должен иметь значение "СС" 16-тиричное (RFC 1356 пп. 3.2, 5.1).

Пакет IP переносится в поле блока данных пакета данных Х.25. Пакеты посылаются как завершенные последовательности пакетов Х.25 (пакет IP выровнен по границам пакета Х.25. В случае, когда длина пакета IP превышает размер пакета данных Х.25, пакет IP фрагментируется с использованием бита "еще данные" (RFC 1356 пп. 3.1, 5.1).

3.4.1.2 Требования к процедурам инкапсуляции

Инкапсуляция пакетов IP должна выполняться при помощи одного из трех способов:

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

- пакеты IP могут инкапсулироваться при помощи протокола SNAP (пакеты данных идентифицируются по Уникальному административно назначаемому Идентификатору (OUI), содержащемуся в заголовке протокола SNAP (длиной 5 байт) и имеющему значение "000000" 16-тиричное, а также Идентификатору Протокола (PID), имеющему значение "0800" 16-тиричное). Такой способ инкапсуляции также называется "нулевой" инкапсуляцией;

- пакеты IP могут инкапсулироваться по каналу, использующему "нулевую" инкапсуляцию, в мультиплексированные пакеты данных внутри протокола SNAP (RFC 1356 п. 3.4).

В аппаратуре допускается поддержка возможности согласования параметров для Х.25 (размер пакета, размер окна).

Взаимосвязь между размером блока данных протокола и размером пакета Х.25 исключается (RFC 1356 п. 3.5).

В аппаратуре должна обеспечиваться возможность передачи/приема блоков данных протокола длиной не менее 1600 байт (RFC 1356 п. 3.6).

По умолчанию размер максимального блока передачи (MTU X.25 для пакетов IP должен составлять до 1500 байт, при этом в аппаратуре должна поддерживаться возможность конфигурирования данного MTU (как минимум на уровне интерфейса) в диапазоне от 576 до 1600 байт.

В аппаратуре должна поддерживать