- Законы
- Кодексы
- Форум
Технические требования к аппаратуре связи, реализующей функции маршрутизации пакетов протокола межсетевого обмена (аппаратура маршрутизации пакетов IP). РД 45.038-99
+-------------------------------------+-----------------------------------+ ¦Сообщение приветствия Hello ¦0 ¦ +-------------------------------------+-----------------------------------+ ¦Сообщение поддержки сеанса I-H-U ¦1 ¦ --------------------------------------+------------------------------------
3.2.1.3.3. Поле информации о состоянии
Кодирование значения поля информации о состоянии должно выполняться в соответствии с RFC 904, приложение А.2:
--------------------------------------------+------------------------------ ¦ Состояние ¦ Код состояния ¦ +-------------------------------------------+-----------------------------+ ¦Не определено ¦0 ¦ +-------------------------------------------+-----------------------------+ ¦Узел активен ¦1 ¦ +-------------------------------------------+-----------------------------+ ¦Узел неработоспособен ¦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:
----------------------+-------------------+--------------------------------
¦ Заголовок ¦ Не используется ¦Адрес IP (номер) сети-источника¦
----------------------+-------------------+--------------------------------
<--------------------> <-----------------> <----------------------------->
10 байт 2 байта 3 байта
Рис. 3.13. Формат сообщения опроса Poll процедуры Network Reachability
Префикс (номер) сети - источника сообщения может состоять из 1 (для сети типа A), 2 (для сети типа B) или 3 (для сети типа C) байт. Незначащие разряды слева должны дополняться нулями.
Сообщение опроса 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)
------------------------------+-----------------------+----------- ¦ Заголовок ¦Число внутренних узлов ¦ Число ¦ ¦ (10 байт) ¦ (шлюзов) (1 байт) ¦ внешних ¦ ¦ ¦ ¦ узлов ¦ ¦ ¦ ¦ (шлюзов) ¦ ¦ ¦ ¦ (1 байт) ¦ +-----------------------------+-----------------------+----------- ¦Префикс (номер) IP сети-источника (1, 2 или 3 байт) ¦ +-----------------------------------------------------+ ¦Адрес шлюза (узла) IP (без номера сети) (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------+------------------------ ¦Число n дистанций на шлюз ¦ ¦1 (1 байт) ¦ +-----------------------------+------------------------ ¦Номер дистанции 1 (1 байт) ¦Число сетей на ¦ ¦ ¦дистанции m (1 байт) ¦ +-----------------------------+-----------------------+ ¦Префикс (номер) IP сети 1 на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------------------------------+ ¦... ¦ +-----------------------------------------------------+ ¦Префикс (номер) IP сети m на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------+-----------------------+ ¦Номер дистанции 2 (1 байт) ¦Число сетей на ¦ ¦ ¦дистанции m (1 байт) ¦ +-----------------------------+-----------------------+ ¦Префикс (номер) IP сети 1 на дистанции (1, 2 или 3 ¦ ¦байт) ¦ +-----------------------------------------------------+ ¦... ¦ +-----------------------------------------------------+ ¦Префикс (номер) IP сети m на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------+------------------------ ¦Число n дистанций на шлюз ¦ ¦2 (1 байт) ¦ +-----------------------------+------------------------ ¦Номер дистанции 1 (1 байт) ¦Число сетей на ¦ ¦ ¦дистанции m (1 байт) ¦ +-----------------------------+-----------------------+ ¦Префикс (номер) IP сети 1 на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------------------------------+ ¦... ¦ +-----------------------------------------------------+ ¦Префикс (номер) IP сети m на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------+-----------------------+ ¦Номер дистанции 2 (1 байт) ¦Число сетей на ¦ ¦ ¦дистанции m (1 байт) ¦ +-----------------------------+-----------------------+ ¦Префикс (номер) IP сети 1 на дистанции (1, 2 или ¦
¦3 байт) ¦ +-----------------------------------------------------+ ¦... ¦ +-----------------------------------------------------+ ¦Префикс (номер) IP сети m на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------------------------------+ ¦... ¦ +-----------------------------+------------------------ ¦Число n дистанций на шлюз k ¦ ¦(1 байт) ¦ +-----------------------------+------------------------ ¦Номер дистанции 1 (1 байт) ¦Число сетей на ¦ ¦ ¦дистанции m (1 байт) ¦ +-----------------------------+-----------------------+ ¦Префикс (номер) IP сети 1 на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------------------------------+ ¦... ¦ +-----------------------------------------------------+ ¦Префикс (номер) IP сети m на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------+-----------------------+ ¦Номер дистанции 2 (1 байт) ¦Число сетей на ¦ ¦ ¦дистанции m (1 байт) ¦ +-----------------------------+-----------------------+ ¦Префикс (номер) IP сети 1 на дистанции (1, 2 или ¦ ¦3 байт) ¦ +-----------------------------------------------------+ ¦... ¦ +-----------------------------------------------------+ ¦Префикс (номер) IP сети m на дистанции (1, 2 или ¦ ¦3 байт) ¦ -------------------------------------------------------
Рис. 3.14. Формат сообщения обновления информации маршрутизации UPDATE
Информация о доступности сетей должна кодироваться в сообщениях обновления информации маршрутизации Update в форме списка сетей и шлюзов.
Формат сообщения обновления информации маршрутизации UPDATE должен соответствовать RFC 904, приложение А.4.
Сообщение Update может содержать два списка шлюзов. Оба списка включают в себя только шлюзы, напрямую соединяющиеся с сетью, адрес IP которой указан в последнем принятом сообщении опроса.
Внутренний список содержит некоторые или все адреса шлюзов в одной и той же сети (автономной системе), в качестве посылающих информацию о доступности, вместе с номерами сетей, доступными через эти шлюзы; первым в списке должен стоять адрес шлюза, который посылает сообщение.
Внешний список содержит адреса шлюзов в другой сети (автономной системе), известных посылающему шлюзу.
Только шлюзы, принадлежащие сети-получателю, могут содержать внешний список в сообщениях Update (RFC 904, п. 4.4).
При кодировании сообщения Update могут указываться следующие типы состояний (RFC 904, приложение А.4):
-----------------------------------+--------------------------------------- ¦ Состояние ¦ Код состояния в заголовке сообщения ¦ +----------------------------------+--------------------------------------+ ¦Не определено ¦0 ¦ +----------------------------------+--------------------------------------+ ¦Узел активен ¦1 ¦ +----------------------------------+--------------------------------------+ ¦Узел неработоспособен ¦2 ¦ +----------------------------------+--------------------------------------+ ¦Незатребованное сообщение ¦128 ¦ -----------------------------------+---------------------------------------
3.2.1.5. Сообщение об ошибке "Error" (тип сообщения 8)
3.2.1.5.1. Формат сообщения Error
Формат сообщения Error протокола EGP должен соответствовать RFC 904, приложение А.5:
----------------+----------------------+-----------------------------------
¦ Заголовок ¦ Код причины ошибки ¦ Заголовок ошибочного сообщения ¦
----------------+----------------------+-----------------------------------
<--------------> <--------------------> <-------------------------------->
10 байт 1 байт 3 байта
Рис. 3.15. Формат сообщения об ошибке ERROR
Коды информации о состоянии в сообщении Error аналогичны кодам сообщения Update.
В сообщении об ошибке должна обеспечиваться индикация причины посылки данного сообщения (RFC 904, приложение А.5):
-------------------------------------------------------+------------------- ¦ Причина ошибки ¦Код причины ошибки¦ +------------------------------------------------------+------------------+ ¦Не определена ¦0 ¦ +------------------------------------------------------+------------------+ ¦Неверный формат заголовка сообщения ¦1 ¦ +------------------------------------------------------+------------------+ ¦Неверный формат поля данных сообщения ¦2 ¦ +------------------------------------------------------+------------------+ ¦Информация о доступности сети/узла недействительна ¦3 ¦ +------------------------------------------------------+------------------+ ¦Превышение частоты опроса ¦4 ¦ +------------------------------------------------------+------------------+ ¦Нет ответного сообщения ¦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:
------------+-----------------+-----------+-----------+------------------ ¦ Маркер ¦ Длина сообщения ¦ Версия ¦ Тип ¦ Тайм-аут (сек.) ¦ ¦ ¦ (в байт) ¦ протокола ¦ сообщения ¦ ¦ ------------+-----------------+-----------+-----------+------------------ <----------> <---------------> <---------> <---------> <---------------> 2 байта 2 байта 1 байт 1 байт 2 байта
Рис. 3.16. Формат заголовка сообщения протокола BGP-1
В BGP-1 предусматриваются следующие типы сообщений (RFC 1105, п. 3):
------------------------------------------------------+-------------------- ¦ Тип сообщения ¦Код типа сообщения ¦ ¦ ¦ в заголовке ¦ +-----------------------------------------------------+-------------------+ ¦Инициирование сеанса OPEN ¦1 ¦ +-----------------------------------------------------+-------------------+ ¦Обновление данных маршрутизации UPDATE ¦2 ¦ +-----------------------------------------------------+-------------------+ ¦Уведомление NOTIFICATION ¦3 ¦ +-----------------------------------------------------+-------------------+ ¦Поддержка сеанса KEEPALIVE ¦4 ¦ +-----------------------------------------------------+-------------------+ ¦Подтверждение установления сеанса OPEN CONFIRM ¦5 ¦ ------------------------------------------------------+--------------------
3.2.2.2. Сообщения BGP-1
Минимальная длина сообщения BGP-1 составляет 8 байт (сообщение состоит из заголовка), максимальная длина - 1024 байт (RFC 1105, п. 3).
3.2.2.2.1. Формат сообщения инициирования сеанса "OPEN"
Формат сообщения OPEN должен соответствовать RFC 1105, п. 3.2:
-------------+---------------+--------------+--------------+---------------
¦ Заголовок ¦ Номер узла ¦Код типа звена¦ Код ¦ Данные ¦
¦ ¦ (шлюза) ¦ ¦аутентификации¦аутентификации¦
-------------+---------------+--------------+--------------+---------------
<-----------> <-------------> <------------> <------------> <------------>
8 байт 2 байта 1 байт 1 байт переменная
длина
Рис. 3.17. Формат сообщения инициирования сеанса OPEN
Для данного сообщения предусматриваются следующие коды (RFC 1105, п. 3.2).
-----------------------------------------------------------+--------------- ¦ Тип звена ¦Код типа звена¦ +----------------------------------------------------------+--------------+ ¦Взаимодействующие узлы находятся в пределах одной ¦0 ¦ ¦автономной системы - сети (INTERNAL) ¦ ¦ +----------------------------------------------------------+--------------+ ¦Взаимодействующий узел (шлюз) находится в автономной ¦1 ¦ ¦системе - сети более высокого уровня иерархии (UP) ¦ ¦ +----------------------------------------------------------+--------------+ ¦Взаимодействующий узел (шлюз) находится в автономной ¦2 ¦ ¦системе - сети более низкого уровня иерархии (DOWN) ¦ ¦ +----------------------------------------------------------+--------------+ ¦Взаимодействующие узлы принадлежат автономным системам - ¦3 ¦ ¦сетям одного уровня (H-LINK) ¦ ¦ -----------------------------------------------------------+---------------
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.
--------------------------------------------------------------------------- ¦ Заголовок - 8 байт ¦ +-------------------------------------------------------------------------+ ¦ Адрес шлюза (узла) - 4 байта ¦ +---------------------+-----------------------+---------------------------+ ¦ Число пар ¦ Код направления ¦ Номер сети (автономной ¦ ¦"Направление - номер ¦ перехода по графу ¦ системы), передававшей ¦ ¦ сети" n в данном ¦ маршрутов - 1 байт ¦информацию маршрутизации - ¦ ¦ сообщении - 2 байта ¦ ¦ 2 байта ¦ +---------------------+-----------------------+---------------------------+ ¦ 1 пара "Направление - номер сети" ¦ +-------------------------------------------------------------------------+ ¦ ... ¦ +-------------------------------------------------------------------------+ ¦ n пара "Направление - номер сети" ¦ +---------------------+---------------------------------------------------+ ¦ Число пар ¦ ¦ ¦ "Сеть-метрика" m ¦ ¦ ¦в данном сообщении - ¦ ¦ ¦ 2 байта ¦ ¦ +---------------------+---------------------------------------------------+ ¦ Номер сети IP - 4 байта ¦ +---------------------+---------------------------------------------------+ ¦ Метрика - 2 байта ¦ ¦ +---------------------+---------------------------------------------------+ ¦ 1 пара "Сеть-метрика" ¦ +-------------------------------------------------------------------------+ ¦ ... ¦ +-------------------------------------------------------------------------+ ¦ m пара "Сеть-метрика" ¦ ---------------------------------------------------------------------------
Рис. 3.18. Формат сообщения UPDATE
Для данного сообщения предусматриваются следующие коды направления перехода по графу маршрутов:
----------------------------------------------------------+---------------- ¦ Направление ¦Код направления¦
+---------------------------------------------------------+---------------+ ¦Переход вверх по звену в графе маршрутов (UP) ¦1 ¦ +---------------------------------------------------------+---------------+ ¦Переход вниз по звену в графе маршрутов (DOWN) ¦2 ¦ +---------------------------------------------------------+---------------+ ¦Переход по горизонтальному звену в графе маршрутов ¦3 ¦ ¦(H_LINK) ¦ ¦ +---------------------------------------------------------+---------------+ ¦Информация, полученная от протокола EGP (EGP_LINK) ¦4 ¦ +---------------------------------------------------------+---------------+ ¦Неполная информация (INCOMPLETE) ¦5 ¦ ----------------------------------------------------------+----------------
3.2.2.2.4. Формат сообщения уведомления "NOTIFICATION"
Формат сообщения должен соответствовать RFC 1105, п. 3.5.
Сообщение NOTIFICATION посылается в случае обнаружения ошибки в любом из сообщений протокола BGP-1. Сразу же после этого сеанс BGP-1 считается завершенным (RFC 1105, п. 3.5).
------------------+--------------------------+-----------------------------
¦ Заголовок ¦ Код типа уведомления ¦ Данные для диагностики ¦
------------------+--------------------------+-----------------------------
<----------------> <------------------------> <-------------------------->
8 байт 2 байта переменная длина
Рис. 3.19. Формат сообщения NOTIFICATION
Для сообщения NOTIFICATION предусматриваются следующие типы уведомлений:
---------------------------+----------------------------------+------------ ¦ Тип уведомления ¦ Данные для диагностики ¦ Код типа ¦ ¦ ¦ ¦уведомления¦ +--------------------------+----------------------------------+-----------+ ¦Ошибка при открытии звена ¦Тип звена (1 байт) ¦1 ¦ +--------------------------+----------------------------------+-----------+ ¦Неизвестный код ¦Нет ¦2 ¦ ¦аутентификации ¦ ¦ ¦ +--------------------------+----------------------------------+-----------+ ¦Отказ процедуры ¦Нет ¦3 ¦ ¦аутентификации ¦ ¦ ¦ +--------------------------+----------------------------------+-----------+ ¦Ошибка при обновлении ¦См. следующую табл. ¦4 ¦ ¦данных маршрутизации ¦ ¦ ¦ +--------------------------+----------------------------------+-----------+ ¦Ошибка при синхронизации ¦Нет ¦5 ¦ +--------------------------+----------------------------------+-----------+ ¦Неверная длина сообщения ¦Значение неверной длины (2 байта) ¦6 ¦ +--------------------------+----------------------------------+-----------+ ¦Неверный тип сообщения ¦Неверный тип (1 байт) ¦7 ¦ +--------------------------+----------------------------------+-----------+ ¦Недействительная версия ¦Недействительная версия (1 байт) ¦8 ¦ ¦протокола ¦ ¦ ¦ +--------------------------+----------------------------------+-----------+ ¦В сообщении OPEN указан ¦Нет ¦9 ¦ ¦недействительный номер ¦ ¦ ¦ ¦узла (шлюза) ¦ ¦ ¦ +--------------------------+----------------------------------+-----------+ ¦Прерывание протокола ¦Нет ¦10 ¦ ---------------------------+----------------------------------+------------
Все ошибки, кроме ошибки при обновлении данных маршрутизации, должны рассматриваться как неисправимые и приводить к разрыву соединения транспортного протокола (RFC 1105, п. п. 3.5, 3.6).
Поле данных для диагностики может: не содержать ни одного байта (ошибки типа 2, 3, 5, 9, 10), содержать копию неверного значения поля сообщения (ошибки типа 6, 7, 8) или содержать коды ошибок (RFC 1105, п. 3.5):
---------------------------------------------------------------+----------- ¦ Тип ошибки ¦Код ошибки¦ ¦ ¦(2 байта) ¦ +--------------------------------------------------------------+----------+ ¦Недействительное число пар "Направление - номер сети" в ¦1 ¦ ¦сообщении ¦ ¦ +--------------------------------------------------------------+----------+ ¦Недействительный код направления перехода по графу ¦2 ¦ +--------------------------------------------------------------+----------+ ¦Недействительный номер сети (автономной системы), передававшей¦3 ¦ ¦информацию маршрутизации ¦ ¦ +--------------------------------------------------------------+----------+ ¦Направления переходов EGP_LNK или INCOMPLETE_LINK находятся не¦4 ¦ ¦в конце списка ¦ ¦ +--------------------------------------------------------------+----------+ ¦Зацикленный маршрут ¦5 ¦ +--------------------------------------------------------------+----------+ ¦Недействительный номер узла (шлюза) ¦6 ¦ +--------------------------------------------------------------+----------+ ¦Недействительное число пар "Сеть-метрика" в сообщении ¦7 ¦ +--------------------------------------------------------------+----------+ ¦Недействительный номер сети IP ¦8 ¦ ---------------------------------------------------------------+-----------
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:
------------------------+------------------------+-------------------------
¦ Маркер ¦ Длина сообщения ¦ Тип сообщения ¦
------------------------+------------------------+-------------------------
<----------------------> <----------------------> <---------------------->
16 байт 2 байта 1 байт
Рис. 3.20. Формат заголовка сообщения протокола BGP-2
В BGP-2 предусматриваются следующие типы сообщений (RFC 1163, п. 4.1):
-------------------------------------------+------------------------------- ¦ Тип сообщения ¦Код типа сообщения в заголовке¦ +------------------------------------------+------------------------------+ ¦Инициирование сеанса OPEN ¦1 ¦ +------------------------------------------+------------------------------+ ¦Обновление данных маршрутизации UPDATE ¦2 ¦ +------------------------------------------+------------------------------+ ¦Уведомление NOTIFICATION ¦3 ¦ +------------------------------------------+------------------------------+ ¦Поддержка сеанса KEEPALIVE ¦4 ¦ -------------------------------------------+-------------------------------
3.2.3.2. Сообщения BGP-2
Минимальная длина сообщения BGP-2 составляет 19 байт (сообщение состоит из заголовка), максимальная длина - 4096 байт (RFC 1163, п. 4).
3.2.3.2.1. Формат сообщения инициирования сеанса "OPEN"
Формат сообщения OPEN должен соответствовать RFC 1163, п. 4.2:
----------+------+----------------+---------+--------------+---------------
¦Заголовок¦Версия¦ Номер сети ¦Тайм-аут ¦ Код ¦ Данные ¦
¦ ¦ ¦ (автономной ¦сообщения¦аутентификации¦аутентификации¦
¦ ¦ ¦ системы) ¦протокола¦ ¦ ¦
----------+------+----------------+---------+--------------+---------------
<--------> <----> <--------------> <-------> <------------> <------------>
19 байт 1 байт 2 байта 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.
Каждое поле Атрибут пути имеет переменную длину и состоит из трех частей (подполей).
- тип атрибута;
- длина атрибута;
- значение атрибута.
-----------------------------------------------------------+--------------- ¦ Заголовок (19 байт) ¦ ¦ +----------------------------------------------------------+--------------+ ¦ Длина поля Атрибуты пути (2 байта) ¦ ¦ +----------------------------------------------------------+--------------+ ¦ Атрибут пути 1 (переменная длина) ¦ ¦ +----------------------------------------------------------+--------------+ ¦ Атрибут пути 2 (переменная длина) ¦ ¦ +----------------------------------------------------------+--------------+ ¦ ... ¦ ¦ +----------------------------------------------------------+--------------+ ¦ Атрибут пути n (переменная длина) ¦ ¦ +----------------------------------------------------------+--------------+ ¦ Номер сети IP 1 ¦ ¦ +----------------------------------------------------------+--------------+ ¦ ... ¦ ¦ +----------------------------------------------------------+--------------+ ¦ Номер сети IP n ¦ ¦ -----------------------------------------------------------+---------------
Рис. 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 ¦11 ¦Обязательный ¦ +-----------------------+------------------+------------------------------+ ¦AS-PATH ¦2 ¦Обязательный ¦ +-----------------------+------------------+------------------------------+ ¦NEXT_HOP ¦34 ¦Обязательный ¦ +-----------------------+------------------+------------------------------+ ¦UNREACHABLE ¦40 ¦Обязательный условно ¦ +-----------------------+------------------+------------------------------+ ¦INTER-AS METRIC ¦52 ¦Необязательный ¦ ------------------------+------------------+-------------------------------
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:
--------------+--------------+-------------------+------------------------- ¦ Заголовок ¦ Код ошибки ¦ Субкод ошибки ¦ Данные для диагностики ¦ --------------+--------------+-------------------+------------------------- <------------> <------------> <-----------------> <----------------------> 19 байт 1 байт 1 байт переменная длина
Рис. 3.23. Формат сообщения NOTIFICATION
Предусматриваются следующие коды ошибки:
---------------------------------------------------------------+----------- ¦ Тип уведомления ¦Код ошибки¦ +--------------------------------------------------------------+----------+ ¦Ошибка в заголовке сообщения ¦1 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка в сообщении OPEN ¦2 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка в сообщении UPDATE ¦3 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка по тайм-ауту ¦4 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка порядка обмена сообщениями ¦5 ¦ +--------------------------------------------------------------+----------+ ¦Прерывание ¦6 ¦ ---------------------------------------------------------------+-----------
Поле субкода ошибки заполняется значением целого числа. Значение "0" устанавливается случае, если для данного типа ошибок субкода не предусмотрено.
Для ошибок в заголовке сообщения предусматриваются следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Нарушение синхронизации передачи сообщений в сеансе ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Некорректная длина сообщения ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Некорректный тип сообщения ¦3 ¦ ------------------------------------------------------------+--------------
Для ошибок в сообщении OPEN предусматриваются следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Данная версия протокола не поддерживается ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Неверный номер сети (автономной системы) ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Данный код аутентификации не поддерживается ¦3 ¦ +-----------------------------------------------------------+-------------+ ¦Процедура аутентификации завершилась с отрицательным ¦4 ¦ ¦результатом ¦ ¦ ------------------------------------------------------------+--------------
Для ошибок в сообщении UPDATE предусматриваются следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Список атрибутов сформирован неверно ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Неидентифицируемый обязательный атрибут ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Отсутствует обязательный атрибут ¦3 ¦ +-----------------------------------------------------------+-------------+ ¦Ошибка во флагах атрибута ¦4 ¦ +-----------------------------------------------------------+-------------+ ¦Неверная длина атрибута ¦5 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительный атрибут типа ORIGIN ¦6 ¦ +-----------------------------------------------------------+-------------+ ¦Зацикливание маршрута ¦7 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительный атрибут типа NEXT_HOP ¦8 ¦ +-----------------------------------------------------------+-------------+ ¦Ошибка в необязательном атрибуте ¦9 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительное значение в поле Номер сети ¦10 ¦ ------------------------------------------------------------+--------------
Поле данных сообщения уведомления используется для диагностики причины посылки данного сообщения. Правила заполнения поля данных информацией для диагностики должны соответствовать 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:
-------------------------+------------------------+------------------------
¦ Маркер ¦ Длина сообщения ¦ Тип сообщения ¦
-------------------------+------------------------+------------------------
<-----------------------> <----------------------> <--------------------->
16 байт 2 байта 1 байт
Рис. 3.24. Формат заголовка сообщения протокола BGP-3
Аппаратура должна обеспечивать обработку следующих типов сообщений BGP-3 (RFC 1267, п. 4.1):
-----------------------------------------+--------------------------------- ¦ Тип сообщения ¦ Код типа сообщения в заголовке ¦ +----------------------------------------+--------------------------------+ ¦Инициирование сеанса OPEN ¦1 ¦ +----------------------------------------+--------------------------------+ ¦Обновление данных маршрутизации UPDATE ¦2 ¦ +----------------------------------------+--------------------------------+ ¦Уведомление NOTIFICATION ¦3 ¦ +----------------------------------------+--------------------------------+ ¦Поддержка сеанса KEEPALIVE ¦4 ¦ -----------------------------------------+---------------------------------
3.2.4.2. Сообщения BGP-3
Аппаратура должна поддерживать требования к длине сообщения протокола (минимальная длина - 19 байт (сообщение состоит только из заголовка), максимальная длина - 4096 байт) и требования к форматам сообщений (RFC 1267, п. 4).
3.2.4.2.1. Сообщение инициирования сеанса "OPEN"
Формат сообщения OPEN должен соответствовать RFC 1267, п. 4.2.
----------+------+-----------+---------+-------------+--------+------------
¦Заголовок¦Версия¦Номер сети ¦Тайм-аут ¦Идентификатор¦Код ¦Данные ¦
¦ ¦ ¦(автономной¦сообщений¦ отправителя ¦аутенти-¦аутентифи- ¦
¦ ¦ ¦ системы) ¦протокола¦ ¦фикации ¦кации ¦
----------+------+-----------+---------+-------------+--------+------------
<--------> <----> <---------> <-------> <-----------> <------> <--------->
19 байт 1 байт 2 байта 2 байта 4 байта 1 байт переменная
длина
Рис. 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.
--------------------------------------------------------- ¦Заголовок (19 байт) ¦ +-------------------------------------------------+------ ¦Суммарная длина атрибутов пути в байт (2 байта) ¦ +-------------------------------------------------+------------------------ ¦Атрибуты пути (длина переменная) ¦ +-------------------------------------------------------------------------+ ¦Сеть 1 ¦ +-------------------------------------------------------------------------+ ¦... ¦ +-------------------------------------------------------------------------+ ¦Сеть n ¦ ---------------------------------------------------------------------------
Рис. 3.26. Формат сообщения UPDATE
Поле Атрибуты пути является обязательным для сообщения UPDATE. Последовательность атрибутов пути должна состоять из трех подполей:
- тип атрибута;
- длина атрибута;
- значение атрибута.
Тип атрибута (длина подполя 2 байта) в свою очередь должен состоять из:
- поля флагов атрибута (старший байт);
- поля кода типа атрибута (младший байт).
Кодирование поля флагов атрибута должно осуществляться в соответствии со следующими правилами (REC 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 ¦1 ¦1 ¦Обязательный ¦ +--------------------+----------+------------------+----------------------+ ¦AS_PATH ¦2 ¦Перемен. ¦Обязательный ¦ +--------------------+----------+------------------+----------------------+ ¦NEXT_HOP ¦3 ¦4 ¦Обязательный ¦ +--------------------+----------+------------------+----------------------+ ¦UNREACHABLE ¦4 ¦0 ¦Обязательный условно ¦ +--------------------+----------+------------------+----------------------+ ¦INTER-AS METRIC ¦5 ¦2 ¦Необязательный ¦ ---------------------+----------+------------------+-----------------------
Атрибут ORIGIN должен использоваться для определения источника информации о пути. В поле данных атрибута могут находиться следующие значения:
0 - сеть является внутренней по отношению к источнику пакета;
1 - сеть является внешней по отношению к источнику пакета;
2 - регламентируется.
Атрибут AS_PATH должен использоваться для хранения перечня путей, проходимых пакетом, до сетей, перечисляемых в сообщении UPDATE.
Атрибут NEXT_HOP должен использоваться для определения адреса пограничного узла маршрутизации, который должен быть задействован в качестве транзитного к сетям, перечисляемым в сообщении UPDATE.
Атрибут INREACHABLE должен использоваться для уведомления узла маршрутизации протокола BGP-3 о том, что сведения о ранее заявленных маршрутах устарели.
Значение атрибута INTER-AS METRIC должно быть целым двухбайтовым числом.
Каждое поле Сеть в сообщении UPDATE должно идентифицировать сеть, описываемую с помощью атрибутов пути и участвующую в межсетевой маршрутизации: поле должно содержать номер сети, состоящий из четырех байт. Не допускается использовать номера подсетей и базовых узлов. Общее число полей Сеть в сообщении UPDATE должно соответствовать формуле:
Длина сообщения = 19 + суммарная длина атрибутов пути + 4 x номер сети.
Результат расчета по данной формуле должен приводить к целому неотрицательному числу полей Сеть.
Минимальная длина сообщения 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.
-------------+--------------+---------------------+------------------------ ¦ Заголовок ¦ Код ошибки ¦ Субкод ошибки ¦Данные для диагностики ¦ -------------+--------------+---------------------+------------------------ <-----------> <------------> <-------------------> <---------------------> 19 байт 1 байт 1 байт переменная длина
Рис. 3.27. Формат сообщения NOTIFICATION
В сообщении NOTIFICATION должны поддерживаться следующие коды ошибки:
-------------------------------------------------------------+------------- ¦ Тип уведомления ¦ Код ошибки ¦ +------------------------------------------------------------+------------+ ¦Ошибка в заголовке сообщения ¦1 ¦ +------------------------------------------------------------+------------+ ¦Ошибка в сообщении OPEN ¦2 ¦ +------------------------------------------------------------+------------+ ¦Ошибка в сообщении UPDATE ¦3 ¦ +------------------------------------------------------------+------------+ ¦Ошибка по тайм-ауту ¦4 ¦ +------------------------------------------------------------+------------+ ¦Ошибка порядка обмена сообщениями ¦5 ¦ +------------------------------------------------------------+------------+ ¦Прерывание ¦6 ¦ -------------------------------------------------------------+-------------
Поле субкода ошибки должно заполняться значением целого числа. Значение должно "0" устанавливаться в случае, если для данного типа ошибок субкода не предусмотрено.
Для ошибок в заголовке сообщения должны поддерживаться следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Нарушение синхронизации передачи сообщений в сеансе ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Некорректная длина сообщения ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Некорректный тип сообщения ¦3 ¦ ------------------------------------------------------------+--------------
Для ошибок в сообщении OPEN должны поддерживаться следующие субкоды:
-----------------------------------------------------------+--------------- ¦ Описание ¦Субкод ошибки ¦ +----------------------------------------------------------+--------------+ ¦Данная версия протокола не поддерживается ¦1 ¦ +----------------------------------------------------------+--------------+ ¦Неверный номер сети (автономной системы) ¦2 ¦ +----------------------------------------------------------+--------------+ ¦Неверный идентификатор отправителя ¦3 ¦ +----------------------------------------------------------+--------------+ ¦Данный код аутентификации не поддерживается ¦4 ¦ +----------------------------------------------------------+--------------+ ¦Процедура аутентификации завершилась с отрицательным ¦5 ¦ ¦результатом ¦ ¦ -----------------------------------------------------------+---------------
Для ошибок в сообщении UPDATE должны поддерживаться следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Список атрибутов сформирован неверно ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Неидентифицируемый обязательный атрибут ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Отсутствует обязательный атрибут ¦3 ¦ +-----------------------------------------------------------+-------------+
Комментарии
Комментирование через социальные сервисы Facebook и Вконтакте:
Федеральное