- Законы
- Кодексы
- Форум
Технические требования к аппаратуре связи, реализующей функции маршрутизации пакетов протокола межсетевого обмена (аппаратура маршрутизации пакетов IP). РД 45.038-99
Утверждаю
Первый заместитель
Председателя
Госкомсвязи России
Н.С.МАРДЕР
6 августа 1998 года
Согласовано
Начальник УЭС
Госкомсвязи России
А.Ю.РОКОТЯН
6 августа 1998 года
Внесено Изменение N 1, утвержденное Министерством Российской Федерации по связи и информатизации и введенное в действие с 15.04.2002.
СПИСОК СОКРАЩЕНИЙ И ОБОЗНАЧЕНИЙ
AAL - ATM Adaptation Layer, Уровень адаптации ATM
ARP - Address Resolution Protocol, протокол разрешения адресов
ATM - Asynchronous Transfer Mode, Асинхронный Режим Переноса
BGP - Border Gateway Protocol, протокол пограничной маршрутизации
B-ISDN - Broadband Integrated Services Digital Network, Широкополосная
цифровая сеть с интегрированными службами
CIDR - Class-Independent Domain Routing Protocol, протокол бесклассовой
межрегиональной маршрутизации
DSAP - Destination Service Access Point, точка доступа к службе
получателя
EGP - Exterior Gateway Protocol, протокол внешней маршрутизации
FDDI - Fiber Distributed Data Interface, распределенный
волоконно-оптический интерфейс данных
ICMP - Internet Control Message Protocol, протокол сообщений управления
Internet
IEEE - Institute of Electrical and Electronics Engineers
IP - Internet Protocol, протокол межсетевого обмена Internet
LLC - Logical Link Control, управление логическим звеном данных
MAC - Media Access Control, управление доступом к среде передачи
MTU - Maximum Transmission Unit, максимальный блок передачи
NLPID - Network Layer Protocol Identifier, идентификатор протокола
сетевого уровня
OUI - Organizationally Unique Identifier, уникальный административно
назначаемый идентификатор
PDU - Protocol Data Unit, блок данных протокола (данных пользователя)
PID - Protocol Identifier, идентификатор протокола
RFC - Reference For Comments, форма нормативного документа Internet
SNAP - SubNetwork Access Protocol, протокол подсети доступа
SSAP - Source Service Access Point, точка доступа к службе источника
UI - Unnumbered information, сообщение Ненумерованная Информация
UNI - User-Network interface, интерфейс "пользователь-сеть"
XID - Exchange Identification, сообщение Идентификация параметров
обмена протокола Frame Relay
DLC - Data Link Connection, соединение звена данных Frame Relay
АКД - Аппаратура окончания канала данных
ООД - Оконечное оборудование данных
ПЦИ - Плезиохронная цифровая иерархия
СЦИ - Синхронная цифровая иерархия
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.
В качестве физических интерфейсов аппаратура может иметь:
- последовательный/параллельный интерфейс ООД/АКД;
- интерфейс локальной сети;
- интерфейс ПЦИ (E1, E3);
- интерфейс 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 и перечень поддерживаемых полей должен соответствовать следующей таблице:
-----+----T----+----T----+----T----+----T----+----T-----+-----T-----+------
¦ 1 ¦ 2 ¦ 3 ¦ 4 ¦ 5 ¦ 6 ¦ 7 ¦ 8 ¦ 9 ¦ 10 ¦ 11 ¦ 12 ¦ 13 ¦ 14 ¦
-----+----+----+----+----+----+----+----+----+----+-----+-----+-----+------
<------------------------------------------------------------------------>
максимально 60 байт
Поля заголовка:
--------+------------------------------------------------+----------------- ¦N поля ¦ Название ¦Длина поля (бит)¦
+-------+------------------------------------------------+----------------+ ¦1. ¦Версия ¦4 ¦ ¦2. ¦Длина заголовка ¦4 ¦ ¦3. ¦Тип обслуживания ¦8 ¦ ¦4. ¦Длина пакета IP ¦16 ¦ ¦5. ¦Идентификатор пакета IP ¦16 ¦ ¦6. ¦Флаги ¦3 ¦ ¦7. ¦Смещение фрагмента ¦13 ¦ ¦8. ¦Счетчик допустимого времени пребывания пакета ¦8 ¦ ¦ ¦в сети ¦ ¦ ¦9. ¦Тип протокола следующего уровня ¦8 ¦ ¦10. ¦Контрольная последовательность заголовка ¦16 ¦ ¦11. ¦Адрес источника пакета ¦32 ¦ ¦12. ¦Адрес получателя пакета ¦32 ¦ ¦13. ¦Режим обработки пакета ¦переменная длина¦ ¦14. ¦Поле дополнения до границы заголовка ¦переменная длина¦ --------+------------------------------------------------+-----------------
3.1.1.2. Требования к функциям кодирования/декодирования полей заголовка пакета IP
3.1.1.2.1. Поле "Версия"
Поле "Версия" должно содержать номер версии формата заголовка пакета IP. Аппаратура должна поддерживать все версии по 4 включительно.
3.1.1.2.2. Поле "Длина заголовка"
Поле "Длина заголовка" должно содержать значение длины заголовка пакета в словах (1 слово - 32 бита).
3.1.1.2.3. Поле "Тип обслуживания"
Поле должно содержать код набора параметров качества обслуживания:
- приоритетность;
- задержка;
- пропускная способность;
- надежность.
Кодирование поля "Тип обслуживания" должно выполняться в соответствии со следующими правилами:
-------+------------------------------------------------------------------- ¦Разряд¦ Параметр ¦ +------+------------------------------------------------------------------+ ¦0 - 2 ¦Приоритетность ¦ +------+------------------------------------------------------------------+ ¦3 ¦Значение "0" - нормальная задержка, значение "1" - малая задержка ¦ +------+------------------------------------------------------------------+ ¦4 ¦Значение "0" - нормальная пропускная способность, значение "1" - ¦ ¦ ¦низкая пропускная способность ¦ +------+------------------------------------------------------------------+ ¦5 ¦Значение "0" - нормальная надежность, значение "1" - высокая ¦ ¦ ¦надежность ¦ +------+------------------------------------------------------------------+ ¦6 - 7 ¦Зарезервировано ¦ -------+-------------------------------------------------------------------
Кодирование разрядов приоритетности должно осуществляться в соответствии с 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. Поле "Флаги"
Поле должно использоваться процедурой фрагментации для управления последовательностью сборки фрагментов пакета. Кодирование разрядов поля должно осуществляться в соответствии со следующими правилами:
-----------------+-------------------------------+------------------------- ¦ Разряд 0 ¦ Разряд 1 ¦ Разряд 2 ¦ +----------------+---------------+---------------+------------+-----------+ ¦Зарезервировано,¦ "0" ¦ "1" ¦ "0" ¦ "1" ¦ ¦устанавливается +---------------+---------------+------------+-----------+ ¦в "0" ¦Пакет можно ¦Пакет нельзя ¦Последний ¦Еще ¦ ¦ ¦фрагментировать¦фрагментировать¦фрагмент ¦фрагменты ¦ -----------------+---------------+---------------+------------+------------
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.
В аппаратуре должна быть предусмотрена поддержка следующих классов режимов:
------+-------------------------------------------------------------------- ¦Класс¦ Описание класса ¦ +-----+-------------------------------------------------------------------+ ¦00 ¦Конец списка режимов. Длина поля режима 1 байт, поле счетчика длины¦ ¦ ¦поля режима отсутствует ¦ +-----+-------------------------------------------------------------------+ ¦01 ¦Нет действий. Длина поля режима 1 байт, поле счетчика длины поля ¦ ¦ ¦режима отсутствует ¦ +-----+-------------------------------------------------------------------+ ¦02 ¦Безопасность. Длина поля режима 11 байт ¦ +-----+-------------------------------------------------------------------+ ¦03 ¦Свободная маршрутизация от источника. Длина поля режима переменная ¦ +-----+-------------------------------------------------------------------+ ¦09 ¦Строгая маршрутизация от источника. Длина поля режима переменная ¦ +-----+-------------------------------------------------------------------+ ¦07 ¦Записанный маршрут. Длина поля режима переменная ¦ +-----+-------------------------------------------------------------------+ ¦08 ¦Идентификатор потока. Длина поля режима 4 байта ¦ +-----+-------------------------------------------------------------------+ ¦24 ¦Отметка времени Internet. Длина поля режима переменная ¦ ------+--------------------------------------------------------------------
3.1.1.3.1. Режим "Конец списка режимов"
Тип режима: 0.
Предназначен для использования указателем конца списка режимов, может совпадать с концом заголовка пакета IP. Допускается копирование, внесение и удаление данного режима при фрагментации.
3.1.1.3.2. Режим "Нет действий"
Тип режима: 1.
Предназначен для выравнивания смежных полей режимов по границе слова (32 бита), может находиться в любом месте списка режимов. Допускается копирование, внесение и удаление данного режима при фрагментации.
3.1.1.3.3. Режим "Свободная маршрутизация от источника и записанный маршрут"
Тип режима: 131.
Предназначен для передачи данных источника пакета IP о маршруте, которые должны быть использованы аппаратурой транзитного узла для направления пакета к получателю и записи данных о маршруте.
-------------+----------------------------+-------------+------------------
¦ Тип режима ¦ Счетчик длины поля режима ¦ Указатель ¦Данные о маршруте¦
-------------+----------------------------+-------------+------------------
<-----------> <--------------------------> <-----------> <--------------->
1 байт 1 байт 1 байт переменная длина
Рис. 3.1. Формат поля режима Свободная маршрутизация от источника и записанный маршрут
Кодирование полей: Тип режима должен быть установлен в двоичное значение "10000011".
Поле счетчика длины поля режима должно содержать значение переменной длины данного поля в байт.
Поле Указатель должно содержать порядковый номер байта, начиная с которого в поле данных о маршруте находится адрес источника пакета. Наименьшее допустимое значение поля указателя "4".
Данные о маршруте должны состоять из последовательности адресов, каждый длиной 4 байта.
Если значение указателя превышает значение длины поля режима, данные о маршруте от источника должны считаться отсутствующими (записанный маршрут исчерпан) и маршрутизация должна осуществляться по значению поля адреса получателя пакета.
Если адрес в поле получателя пакета достигнут и поле указателя содержит значение, не превышающее длину поля режима, следующий адрес в маршруте от источника должен заменить адрес в поле адреса получателя и адрес записанного маршрута должен заменить последний использованный адрес источника; значение поля указателя должно увеличиваться на 4.
Аппаратура должна обеспечивать неизменность длины пакета IP в процессе замены адресов маршрута.
Копирование данного режима при фрагментации обязательно; не допускается наличие более одного поля данного режима в пакете.
3.1.1.3.4. Режим "Строгая маршрутизация от источника и записанный маршрут"
Тип режима: 137.
Предназначен для передачи данных источника пакета IP о маршруте, которые должны быть использованы аппаратурой транзитного узла для направления пакета к получателю и записи данных о маршруте.
-------------+----------------------------+-------------+------------------
¦ Тип режима ¦ Счетчик длины поля режима ¦ Указатель ¦Данные о маршруте¦
-------------+----------------------------+-------------+------------------
<-----------> <--------------------------> <-----------> <--------------->
1 байт 1 байт 1 байт переменная длина
Рис. 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.
Предназначен для контроля времени прохождения пакетом узлов сети.
-------+----------+---------+--------+----T-----+-------+-----T-------+---¬
¦ Тип ¦ Счетчик ¦Указатель¦Перепол-¦Флаг¦Адрес¦Отметка¦Адрес¦Отметка¦...¦
¦режима¦длины поля¦ ¦нение ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ режима ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
-------+----------+---------+--------+----+-----+-------+-----+-------+----
<-----> <--------> <-------> <------> <--> <----------------------------->
1 байт 1 байт 1 байт 4 бита 4 переменная длина
бита
Рис. 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 адресацию для сетей трех классов в соответствии со следующими форматами:
-------------------+-----------------------------------+------------------- ¦ Старшие ¦ Формат ¦ Класс сети ¦ ¦ разряды +-----------------+-----------------+ ¦ ¦ ¦ адрес сети ¦ адрес узла ¦ ¦ +------------------+-----------------+-----------------+------------------+ ¦0 ¦7 бит ¦24 бита ¦A ¦ +------------------+-----------------+-----------------+------------------+ ¦10 ¦14 бит ¦16 бит ¦B ¦ +------------------+-----------------+-----------------+------------------+ ¦110 ¦21 бит ¦8 бит ¦C ¦ +------------------+-----------------+-----------------+------------------+ ¦111 ¦Для режима расширенной адресации ¦ -------------------+-------------------------------------------------------
Не допускается нулевое значение в поле адреса сети для межсетевой маршрутизации (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 должно осуществляться в соответствии со следующей таблицей:
-----------------------------------------------+--------------------------- ¦ Поле заголовка пакета IP ¦ Значение ¦ +----------------------------------------------+--------------------------+ ¦Версия (Version) ¦4 ¦ +----------------------------------------------+--------------------------+ ¦Тип обслуживания ¦0 ¦ +----------------------------------------------+--------------------------+ ¦Протокол ¦1 ¦ -----------------------------------------------+---------------------------
Аппаратура должна устанавливать в "0" любое неиспользованное поле сообщения ICMP.
Правило подсчета контрольной последовательности в сообщениях протокола ICMP должно соответствовать RFC 792.
----------+-------+-------+------------------+-------+--------------------- ¦Заголовок¦Тип ¦Код ¦ Контрольная ¦Не ¦ Заголовок пакета ¦ ¦ IP ¦сообще-¦сооб- ¦последовательность¦исполь-¦IP + первые 64 бита ¦ ¦ ¦ния ¦щения ¦ сообщения ICMP ¦зуется ¦пакета IP, в котором¦ ¦ ¦ ¦ ¦ ¦ ¦ обнаружена ошибка ¦ ----------+-------+-------+------------------+-------+--------------------- <--------> <-----> <-----> <----------------> <-----> <------------------> переменная 1 байт 1 байт 2 байта 4 байта переменная длина длина
Рис. 3.4. Формат сообщений об ошибках протокола ICMP
3.1.2.2. Сообщения протокола ICMP об ошибках в пакетах IP
3.1.2.2.1. Сообщение "Получатель недоступен"
Аппаратура должна формировать сообщение "Получатель недоступен" (Destination Unreachable Message) и отправлять его по адресу отправителя в случае, если:
- недоступен адрес получателя;
- недоступен порт в требуемом направлении передачи;
- не поддерживается требуемый стек протоколов;
- невозможна передача пакета без фрагментации при установленном флаге запрета фрагментации.
Кодирование поля сообщения Destination Unreachable Message должно осуществляться в соответствии со следующей таблицей:
-----------------------------------------------------------------+--------- ¦ Название поля ¦Значение¦ +----------------------------------------------------------------+--------+ ¦Тип сообщения ¦3 ¦
+--------------+-------------------------------------------------+--------+ ¦Код сообщения:¦сеть недоступна ¦0 ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦узел недоступен ¦1 ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦протокол недоступен ¦2 ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦порт недоступен ¦3 ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦фрагментация необходима, но запрещена ¦4 ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦исходный маршрут недействителен ¦5 ¦ ---------------+-------------------------------------------------+---------
3.1.2.2.2. Сообщение "Время пребывания пакета IP в сети истекло"
Аппаратура должна формировать сообщение "Время пребывания пакета IP в сети истекло" (Time Exceeded Message - TEM) в следующих случаях:
- при обнаружении, что поле "время пребывания пакета в сети" в данном пакете содержит нулевое значение;
- при обнаружении, что заданное время пребывания данного пакета в сети истекает прежде окончания сборки его фрагментов.
Сообщение должно передаваться по адресу источника данного пакета.
Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:
---------------+-------------------------------------------------+--------- ¦ ¦ Название поля ¦Значение¦ +--------------+-------------------------------------------------+--------+ ¦Тип сообщения ¦11 ¦ +--------------+-------------------------------------------------+--------+ ¦Код сообщения:¦Время пребывания пакета IP в сети истекло на ¦0 ¦ ¦ ¦транзитном участке ¦ ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦Время сборки фрагментированного пакета IP ¦1 ¦ ¦ ¦превышает время пребывания пакета IP в сети ¦ ¦ ---------------+-------------------------------------------------+---------
3.1.2.2.3. Сообщение "Проблемы в параметрах"
Аппаратура должна формировать сообщение "Проблемы в параметрах" (Parameter Problem Message - PPM), если значения параметров заголовка пакета IP не позволяют завершить его корректную обработку.
Сообщение должно передаваться по адресу источника данного пакета, при этом первый байт поля "не используется" в заголовке сообщения ICMP должен содержать указатель, идентифицирующий байт заголовка пакета IP (порядковый номер байта), содержание которого привело к возникновению проблем.
Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:
---------------------------------------------------------------+----------- ¦ Название поля ¦ Значение ¦ +--------------------------------------------------------------+----------+ ¦Тип сообщения ¦12 ¦ +--------------------------------------------------------------+----------+ ¦Код - индикатор наличия проблем в параметрах заголовка пакета ¦0 ¦ ¦IP (принимается как от шлюза, так и от узла) ¦ ¦ ---------------------------------------------------------------+-----------
3.1.2.2.4. Сообщение "Подавление источника"
Аппаратура должна формировать сообщение "Подавление источника" (Source Quench Message - SQM) в случае невозможности обработки принимаемых пакетов по причинам:
- переполнения буферной памяти;
- высокой интенсивности поступления пакетов.
Сообщение должно передаваться по адресу источника удаляемого из обработки пакета.
Допускается формирование сообщения "Подавление источника" для каждого удаленного из обработки пакета.
В случае приема сообщения "Подавление источника" аппаратура должна уменьшить интенсивность передачи пакетов.
Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:
---------------------------------------------------------------+----------- ¦ Название поля ¦ Значение ¦ +--------------------------------------------------------------+----------+ ¦Тип сообщения ¦4 ¦ +--------------------------------------------------------------+----------+ ¦Код ¦0 ¦ ---------------------------------------------------------------+-----------
3.1.2.2.5. Сообщение "Перенаправление"
Аппаратура должна формировать сообщение "Перенаправление" (Redirect Message - RM) в случае, если шлюз, через который надлежит продолжить передачу, принадлежит той же сети, что и узел-отправитель.
Сообщение должно передаваться по адресу источника пакета.
Поле "Не используется" в данном сообщении должно содержать адрес шлюза, к которому источник должен направлять свои пакеты.
Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:
-----------------------------------------------------------------+--------- ¦ Название поля ¦Значение¦ +----------------------------------------------------------------+--------+ ¦Тип сообщения ¦5 ¦ +--------------+-------------------------------------------------+--------+ ¦Код сообщения:¦Перенаправление пакетов по критерию подполя ¦0 ¦ ¦ ¦"адрес сети" ¦ ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦Перенаправление пакетов по критерию подполя ¦1 ¦ ¦ ¦"адрес узла" ¦ ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦Перенаправление пакетов по критерию поля ¦2 ¦ ¦ ¦"Тип обслуживания" и подполя "адрес сети" ¦ ¦ ¦ +-------------------------------------------------+--------+ ¦ ¦Перенаправление пакетов по критерию поля ¦3 ¦ ¦ ¦"Тип обслуживания" и подполя "адрес узла" ¦ ¦ ---------------+-------------------------------------------------+---------
Аппаратура не должна формировать сообщение "Перенаправление" для пакетов, в заголовке которых указаны функции маршрутизации от узла-отправителя и адрес шлюза в поле адреса получателя, даже если этот маршрут неоптимален (RFC 792).
3.1.2.3. Сообщения ICMP о состоянии узлов сети
3.1.2.3.1. Сообщения "запрос эхо/отклик эхо"
Аппаратура должна формировать сообщение "запрос эхо" (Echo) по инициативе системы административного управления.
При получении сообщения "запрос эхо" аппаратура должна сформировать ответное сообщение "отклик эхо" (Echo Reply Message - EoERM).
------------+-------+-------+------------------+-------+--------+---------- ¦ Заголовок ¦Тип со-¦Код со-¦ Контрольная ¦Иденти-¦Поряд- ¦ Данные ¦ ¦ IP ¦общения¦общения¦последовательность¦фикатор¦ковый ¦ ¦ ¦ ¦ ¦ ¦ сообщения ICMP ¦ ¦номер ¦ ¦ ------------+-------+-------+------------------+-------+--------+---------- <----------> <-----> <-----> <----------------> <-----> <------> <-------->
переменная 1 байт 1 байт 2 байта 2 байта 2 байта переменная длина длина
Рис. 3.5. Формат сообщений Echo or Echo Reply Message
Значение поля Тип сообщения должно быть установлено в "8" для "запроса эхо" и в "0" для "отклика эхо".
Поле данных, принятое в сообщении "запрос эхо", должно быть послано обратно в сообщении "отклик эхо" без изменений.
Поля Идентификатор и Порядковый номер являются параметрами для отслеживания соответствия многократной посылки сообщений и получения откликов.
Поле кода сообщения должно быть установлено в значение "0".
3.1.2.3.2. Сообщения "Отметка времени/Отклик на отметку времени"
Аппаратура должна формировать сообщения "Отметка времени/Отклик на отметку времени" (Timestamp/Timestamp Reply Message ToTRM) по инициативе системы административного управления.
--------------------------------------------------------------------------- ¦ Заголовок пакета IP (переменная длина) ¦ +------------------+------------------+-----------------------------------+ ¦ Тип сообщения ¦ Код ¦ Контрольная последовательность ¦ ¦ (1 байт) ¦ (1 байт) ¦ сообщения ICMP (2 байта) ¦ +------------------+------------------+-----------------------------------+ ¦ Идентификатор ¦ Порядковый номер ¦ +-------------------------------------+-----------------------------------+ ¦ Отметка исходного времени (4 байта) ¦ +-------------------------------------------------------------------------+ ¦ Отметка времени приема (4 байта) ¦ +-------------------------------------------------------------------------+ ¦ Отметка времени передачи (4 байта) ¦ ---------------------------------------------------------------------------
Рис. 3.6. Формат сообщения Timestamp or Timestamp Reply Message
Кодирование сообщений должно осуществляться в соответствии с форматом, приведенным на рисунке и следующими правилами:
Поля Идентификатор и Порядковый номер должны использоваться параметрами для отслеживания соответствия многократной посылки сообщения и получения откликов.
Значение поля Тип сообщения устанавливается в "13" для сообщения "отметка времени" и в "14" для сообщения "отклик на отметку времени".
Поле кода сообщения должно устанавливаться в "0".
В поле "Отметка исходного времени" должен фиксироваться момент времени, когда отправитель завершил формирование данного сообщения для его отправки.
В поле "Отметка времени приема" должен фиксироваться момент времени, когда получатель принял сообщение, но еще не приступил к его обработке.
В поле "Отметка времени передачи" должен фиксироваться момент времени, когда получатель завершил обработку сообщения для его возврата.
3.1.2.3.3. Сообщения "Информационный запрос/Ответ на информационный запрос"
Аппаратура должна формировать сообщения "Информационный запрос/Ответ на информационный запрос" (Information Request or Information Reply Message - IRoIRM) по инициативе системы административного управления для определения номера сети.
----------+---------+---------+------------------+-------------+----------- ¦Заголовок¦ Тип ¦ Код ¦ Контрольная ¦Идентификатор¦Порядковый¦ ¦ IP ¦сообщения¦сообщения¦последовательность¦ ¦ номер ¦ ¦ ¦ ¦ ¦ сообщения ICMP ¦ ¦ ¦ ----------+---------+---------+------------------+-------------+----------- <--------> <-------> <-------> <----------------> <-----------> <--------> переменная 1 байт 1 байт 2 байта 2 байта 2 байта длина
Рис. 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 смежного узла или специально задаваемый адрес Advertisement Address.
--------------------------------------------------------------------------- ¦ Заголовок IP - переменная длина ¦ +-----------------------+---------------------+---------------------------+ ¦Тип сообщения - 1 байт ¦ Код сообщения - ¦ Контрольная ¦ ¦ ¦ 1 байт ¦ последовательность - ¦ ¦ ¦ ¦ 2 байта ¦ +-----------------------+---------------------+---------------------------+ ¦ Число адресов ¦Размер входа адреса -¦ Срок действия адресов - ¦ ¦маршрутизатора - 1 байт¦ 1 байт ¦ 2 байта ¦ +-----------------------+---------------------+---------------------------+ ¦Адрес 1 маршрутизатора - 4 байта ¦ +-------------------------------------------------------------------------+ ¦Уровень предпочтения 1 - 4 байта ¦ +-------------------------------------------------------------------------+ ¦Адрес 2 маршрутизатора - 4 байта ¦ +-------------------------------------------------------------------------+ ¦Уровень предпочтения 2 - 4 байта ¦ +-------------------------------------------------------------------------+ ---------------------------------------------------------------------------
Рис. 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) по инициации системы административного управления.
------------+---------+---------+-------------------------+---------------- ¦ Заголовок ¦ Тип ¦ Код ¦ Контрольная ¦Зарезервировано¦ ¦ IP ¦сообщения¦сообщения¦ последовательность ¦ ¦ ¦ ¦ ¦ ¦ сообщения ICMP ¦ ¦ ------------+---------+---------+-------------------------+---------------- <----------> <-------> <-------> <-----------------------> <-------------> переменная 1 байт 1 байт 2 байта 4 байта длина
Рис. 3.9. Формат сообщения Router Solicitation Message
Поля сообщения Router Solicitation Message:
В поле "адрес отправителя пакета" заголовка пакета IP, в котором передается сообщение Router Solicitation Message, содержится адрес IP, принадлежащий интерфейсу, от которого отправлено сообщение, или нулевое значение.
В поле "адрес получателя пакета" заголовка пакета IP, в котором передается сообщение Router Solicitation Message, содержится специально задаваемый адрес Solicitation Address.
В поле "Счетчик допустимого времени пребывания пакета 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, приложение А:
-------+------+---------+---------+------------------+-----------+--------- ¦Версия¦Тип ¦ Код ¦Информа- ¦ Контрольная ¦Номер узла ¦Перемен-¦ ¦ EGP ¦сооб- ¦ подтипа ¦ция о ¦последовательность¦(автономной¦ная со- ¦ ¦ ¦щения ¦сообщения¦состоянии¦ пакета сообщения ¦ системы) ¦стояния ¦ -------+------+---------+---------+------------------+-----------+--------- <-----> <----> <-------> <-------> <----------------> <---------> <------> 1 байт 1 байт 1 байт 1 байт 2 байта 2 байта 2 байта
Рис. 3.10. Формат заголовка пакета сообщения протокола EGP
Аппаратура должна поддерживать следующие типы команд и сообщений (в соответствии RFC с 904, п. 2):
---------------------+----------------------------------------------------- ¦Команда (сообщение) ¦ Ответная команда (сообщение) ¦ +--------------------+----------------------------------------------------+ ¦Запрос (Request) ¦Подтверждение (Confirm), Отказ (Refuse), Ошибка ¦ ¦ ¦(Error) ¦ +--------------------+----------------------------------------------------+ ¦Прерывание (Cease) ¦Подтверждение прерывания (Cease-ack), Ошибка (Error)¦ +--------------------+----------------------------------------------------+ ¦Приветствие (Hello) ¦Поддержка сеанса (I-H-U), Ошибка (Error) ¦ +--------------------+----------------------------------------------------+ ¦Опрос (Poll) ¦Обновление информации маршрутизации (Update), Ошибка¦ ¦ ¦(Error) ¦ ---------------------+-----------------------------------------------------
3.2.1.2. Процедура инициирования сеанса со смежным узлом
3.2.1.2.1. Формат сообщения процедуры Neighbor Acquisition (тип сообщения 3)
Формат сообщения процедуры Neighbor Acquisition и коды состояния должны соответствовать RFC 904, приложение А.1:
----------+---------------------------------+------------------------------ ¦Заголовок¦ Интервал сообщения приветствия ¦ Интервал сообщения опроса ¦ ¦ ¦ Hello (с) ¦ Poll (с) ¦ ----------+---------------------------------+------------------------------ <--------> <-------------------------------> <---------------------------> 10 байт 2 байта 2 байта
Рис. 3.11. Формат сообщения процедуры Neighbor Acquisition
3.2.1.2.2. Подтипы сообщений процедуры Neighbor Acquisition
Для процедуры Neighbor Acquisition, в соответствии с RFC 904, приложение А.1, должна выполняться генерация и обработка следующих подтипов сообщений:
-------------------------------------------------------------+------------- ¦ Подтип сообщения ¦Код подтипа ¦ ¦ ¦в заголовке ¦ ¦ ¦ сообщения ¦ +--T---------------------------------------------------------+------------+ ¦ ¦Запрос инициирования сеанса со смежным узлом Neighbor ¦0 ¦ ¦ ¦Acquisition Request ¦ ¦ +--+---------------------------------------------------------+------------+ ¦ ¦Подтверждение инициирования сеанса со смежным узлом ¦1 ¦ ¦ ¦Neighbor Acquisition Confirm response ¦ ¦ +--+---------------------------------------------------------+------------+ ¦ ¦Отказ в инициировании сеанса со смежным узлом Neighbor ¦2 ¦ ¦ ¦Acquisition Refuse response ¦ ¦ +--+---------------------------------------------------------+------------+ ¦ ¦Прерывание процедуры инициирования сеанса со смежным ¦3 ¦ ¦ ¦узлом Neighbor Acquisition Cease ¦ ¦ +--+---------------------------------------------------------+------------+ ¦ ¦Подтверждение прерывания процедуры инициирования сеанса ¦4 ¦ ¦ ¦со смежным узлом Neighbor Cease Acknowledgment ¦ ¦ L--+---------------------------------------------------------+-------------
3.2.1.2.3. Поле информации о состоянии
Установка значения поля информации о состоянии должна выполняться в соответствии с RFC 904, приложение А.1:
----------+-----------------------+---------------------------------------- ¦ Код ¦ Состояние ¦ Описание ¦ ¦состояния¦ ¦ ¦ +---------+-----------------------+---------------------------------------+ ¦0 ¦Не определено ¦ ¦ +---------+-----------------------+---------------------------------------+ ¦1 ¦Активное состояние ¦Только для команд запроса/подтверждения¦ ¦ ¦ ¦инициирования ¦ +---------+-----------------------+---------------------------------------+ ¦2 ¦Пассивное состояние ¦Только для команд запроса/подтверждения¦ ¦ ¦ ¦инициирования ¦ +---------+-----------------------+---------------------------------------+ ¦3 ¦Нет требуемого ресурса ¦Вне доступного пространства или ¦ ¦ ¦ ¦системных ресурсов ¦ +---------+-----------------------+---------------------------------------+ ¦4 ¦Административный запрет¦Неизвестный узел (автономная система) ¦ ¦ ¦ ¦или следует использовать другой ¦ ¦ ¦ ¦узел-шлюз ¦ +---------+-----------------------+---------------------------------------+ ¦5 ¦Неработоспособность ¦Останов по команде оператора или ¦ ¦ ¦ ¦прекращение по истечении тайм-аута ¦ +---------+-----------------------+---------------------------------------+ ¦6 ¦Некорректные параметры ¦Неверные параметры опроса или ¦ ¦ ¦ ¦невозможность определения режима ¦ +---------+-----------------------+---------------------------------------+ ¦7 ¦Нарушения в протоколе ¦Принята неверная команда или ответ ¦ ----------+-----------------------+----------------------------------------
3.2.1.3. Процедура взаимодействия со смежным узлом
3.2.1.3.1. Формат сообщения процедуры Neighbor Reachability (тип сообщения 5)
Формат сообщения процедуры Neighbor Reachability должен соответствовать RFC 904, приложение А.2:
---------------------------------------------------------------------------
¦ Заголовок ¦
---------------------------------------------------------------------------
<------------------------------------------------------------------------>
10 байт
Рис. 3.12. Формат сообщения процедуры Neighbor Reachability
3.2.1.3.2. Подтипы сообщений процедуры Neighbor Reachability
Для процедуры Neighbor Reachability, в соответствии с RFC 904, приложение А.2, должна выполняться генерация и обработка следующих подтипов сообщений:
--------------------------------------+------------------------------------ ¦ Подтип сообщения ¦ Код подтипа в заголовке сообщения ¦
Комментарии
Комментирование через социальные сервисы Facebook и Вконтакте:
Федеральное