------------------------------------------------------------------
МИНИСТЕРСТВО ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И СВЯЗИ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРИКАЗ
от 6 декабря 2007 г. N 144
ОБ УТВЕРЖДЕНИИ ПРАВИЛ
ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ И МАРШРУТИЗАЦИИ
ПАКЕТОВ ИНФОРМАЦИИ
В соответствии со статьей 41 Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст. 2895; N 52 (часть I), ст. 5038; 2004, N 35, ст. 3607; N 45, ст. 4377; 2005, N 19, ст. 1752; 2006, N 6, ст. 636; N 10, ст. 1069; N 31 (часть I), ст. 3431, ст. 3452; 2007, N 1, ст. 8; N 7, ст. 835) и пунктом 4 Правил организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденных Постановлением Правительства Российской Федерации от 13 апреля 2005 г. N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст. 1463), приказываю:
1. Утвердить прилагаемые Правила применения оборудования коммутации и маршрутизации пакетов информации.
2. Направить настоящий Приказ на государственную регистрацию в Министерство юстиции Российской Федерации.
3. Контроль за исполнением настоящего Приказа возложить на заместителя Министра информационных технологий и связи Российской Федерации Б.Д. Антонюка.
Министр
Л.Д.РЕЙМАН
Утверждены
Приказом Министерства
информационных технологий
и связи Российской Федерации
от 6 декабря 2007 г. N 144
ПРАВИЛА
ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ И МАРШРУТИЗАЦИИ
ПАКЕТОВ ИНФОРМАЦИИ
I. Общие положения
1. Правила применения оборудования коммутации и маршрутизации пакетов информации (далее - Правила) разработаны в соответствии со статьей 41 Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст. 2895; N 52 (часть I), ст. 5038; 2004, N 35, ст. 3607; N 45, ст. 4377; 2005, N 19, ст. 1752; 2006, N 6, ст. 636; N 10, ст. 1069; N 31 (часть I), ст. 3431, ст. 3452; 2007, N 1, ст. 8; N 7, ст. 835) в целях обеспечения целостности, устойчивости функционирования и безопасности единой сети связи Российской Федерации.
2. Правила устанавливают обязательные требования к параметрам оборудования коммутации и маршрутизации пакетов информации (далее - оборудование), предназначенного для использования в сети связи общего пользования и технологических сетях связи в случае их присоединения к сети связи общего пользования.
3. Правила распространяются на оборудование коммутации и маршрутизации пакетов информации, эксплуатируемое на объектах связи.
4. Оборудование идентифицируется как оборудование коммутации и маршрутизации пакетов информации и в соответствии с пунктом 6 Перечня средств связи, подлежащих обязательной сертификации, утвержденного Постановлением Правительства Российской Федерации от 31 декабря 2004 г. N 896 (Собрание законодательства Российской Федерации, 2005, N 2, ст. 155), должно пройти процедуру обязательной сертификации в порядке, установленном Правилами организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденными Постановлением Правительства Российской Федерации от 13 апреля 2005 г. N 214 (Собрание законодательства Российской Федерации, 2005, N 28, ст. 1463).
II. Требования к оборудованию коммутации и маршрутизации
пакетов информации
5. Для оборудования коммутации и маршрутизации пакетов информации устанавливаются следующие обязательные требования при реализации:
1) протоколов передачи пакетов IP (приложение N 1 к настоящим Правилам);
2) протокола ICMP (приложение N 2 к настоящим Правилам);
3) протокола разрешения адресов (приложение N 3 к настоящим Правилам);
4) протокола соединения "точка - точка" (приложение N 9 к настоящим Правилам);
5) протокола высокоуровневого управления каналом передачи данных HDLC (приложение N 10 к настоящим Правилам);
6) функций протоколов передачи пакетов мультимедийной информации (приложение 10 к Правилам применения оконечного оборудования, выполняющего функции систем коммутации (далее - Правила применения оконечного оборудования коммутации), утвержденным Приказом Министерства информационных технологий и связи Российской Федерации от 24.08.2006 N 113 (зарегистрирован в Министерстве юстиции Российской Федерации 4 сентября 2006 г., регистрационный N 8196));
7) протокола инициирования сеанса связи (приложение 11 к Правилам применения оконечного оборудования коммутации).
6. Для оборудования коммутации и маршрутизации пакетов информации устанавливаются обязательные требования к процедурам инкапсуляции пакетов протокола IP (приложение N 4 к настоящим Правилам).
7. Для оборудования коммутации и маршрутизации пакетов информации устанавливаются следующие обязательные требования к параметрам:
1) интерфейсов к оборудованию, использующему режим ретрансляции кадров (Frame Relay) (приложение 27 к Правилам применения оборудования проводных и оптических систем передачи абонентского доступа (далее - Правила применения оборудования абонентского доступа), утвержденным Приказом Министерства информационных технологий и связи Российской Федерации от 24.08.2006 N 112 (зарегистрирован в Министерстве юстиции Российской Федерации 4 сентября 2006 г., регистрационный N 8194));
2) интерфейсов доступа к сети передачи данных с использованием контроля несущей и обнаружением коллизий (Ethernet) (приложение N 5 к настоящим Правилам);
3) интерфейсов к оборудованию, реализующему технологию маркерного доступа Token Ring (приложение N 6 к настоящим Правилам);
4) интерфейсов для распределенной передачи данных по волоконно-оптическим линиям FDDI и распределенной передачи данных по витой паре CDDI (приложение N 7 к настоящим Правилам);
5) интерфейсов передачи данных (приложение 7 к Правилам применения оборудования абонентского доступа);
6) интерфейсов к сети передачи данных, поддерживающих многопротокольную коммутацию по меткам (приложение N 8 к настоящим Правилам);
7) интерфейсов к оборудованию, работающему в пакетном режиме с подключением к сети передачи по протоколу X.25 (приложение N 13 к настоящим Правилам);
8) двухпроводного аналогового стыка (пункты 6.1, 6.2, 6.3, 10.1, 11, 12.2, 12.3, 13.2, 16, 17, 19, 21.1 - 21.4, 24.1 - 24.3, 68.1, 68.2, 68.3, 69.1, 69.2, 70.1, 70.2, 71, 72, 73 Правил применения оконечного оборудования, подключаемого к двухпроводному аналоговому стыку телефонной сети связи общего пользования (далее - Правила применения оконечного оборудования), утвержденных Приказом Министерства информационных технологий и связи Российской Федерации от 29.08.2005 N 102 (зарегистрирован в Министерстве юстиции Российской Федерации 2 сентября 2005 г., регистрационный N 6982);
9) станционного и абонентского окончания двухпроводного телефонного канала (приложение 1 к Правилам применения оборудования абонентского доступа);
10) интерфейсов цифровых абонентских линий (приложения 11 - 16 к Правилам применения оборудования абонентского доступа);
11) электрических интерфейсов оборудования плезиохронной (PDH) и синхронной (SDH) цифровых иерархий (приложение 20 к Правилам применения оборудования абонентского доступа);
12) интерфейса 64 кбит/с (приложение 19 к Правилам применения оборудования абонентского доступа);
13) оптического линейного интерфейса плезиохронной цифровой иерархии (приложение 22 к Правилам применения оборудования абонентского доступа);
14) оптических интерфейсов к оборудованию синхронной цифровой иерархии (приложение 2 к Правилам применения цифровых систем передачи синхронной цифровой иерархии, утвержденным Приказом Министерства информационных технологий и связи Российской Федерации от 23.11.2006 N 151 (зарегистрирован в Министерстве юстиции Российской Федерации 6 декабря 2006 г., регистрационный N 8569));
15) интерфейсов к оборудованию оптических систем со спектральным разделением (приложение 24 к Правилам применения оборудования абонентского доступа);
16) интерфейсов к оборудованию, использующему режим асинхронного переноса (приложение 26 к Правилам применения оборудования абонентского доступа);
17) интерфейса V5 к цифровым телефонным станциям (приложение 6 к Правилам применения оборудования абонентского доступа);
18) интерфейсов базового и первичного доступа (приложения 1 - 5 к Правилам применения оконечного оборудования коммутации);
19) интерфейса сигнализации E&M (приложение N 18 к Правилам применения оборудования цифровых систем передачи плезиохронной цифровой иерархии. Часть III. Правила применения каналообразующего оборудования плезиохронной цифровой иерархии (далее - Правила применения каналообразующего оборудования плезиохронной цифровой иерархии), утвержденным Приказом Министерства информационных технологий и связи Российской Федерации от 06.06.2007 N 60 (зарегистрирован в Министерстве юстиции Российской Федерации 22 июня 2007 г., регистрационный N 9676));
20) последовательных интерфейсов (приложение 9 к Правилам применения оборудования, реализующего технологии коммутации кадров, утвержденным Приказом Министерства информационных технологий и связи Российской Федерации от 07.12.2006 N 158 (зарегистрирован в Министерстве юстиции Российской Федерации 21 декабря 2006 г., регистрационный N 8655));
21) интерфейса IF (приложение N 12 к настоящим Правилам);
22) электропитания (приложение 33 к Правилам применения оборудования абонентского доступа);
23) электромагнитной совместимости оборудования (приложение 35 к Правилам применения оборудования абонентского доступа).
8. Оборудование выполняет функции маршрутизации, обеспечивающие формирование и обновление таблицы маршрутизации. Таблица маршрутизации формируется и обновляется в ручном или автоматическом режимах. В случае формирования и обновления таблицы маршрутизации в автоматическом режиме оборудование поддерживает протоколы маршрутизации IP, обеспечивающие формирование и обновление таблицы маршрутизации.
9. Коммутация пакетов информации осуществляется на основе пакетов информации типа: пакет протокола передачи данных, кадр, ячейка, цикл.
10. В оборудовании используется один или несколько из приведенных протоколов или интерфейсов.
11. Список используемых сокращений приведен в приложении N 13 к настоящим Правилам (справочно).
Приложение N 1
к Правилам применения
оборудования коммутации
и маршрутизации
пакетов информации
ТРЕБОВАНИЯ
К РЕАЛИЗАЦИИ ПРОТОКОЛОВ ПЕРЕДАЧИ ПАКЕТОВ IP
1. Обмен данными осуществляется пакетами, имеющими структуру и формат согласно таблице N 1 для протокола IPv4 или таблице N 7 для протокола IPv6.
Таблица N 1
----------------------------------------T--------------------------------------¬
¦ Наименование поля ¦ Длина поля, бит ¦
+---------------------------------------+--------------------------------------+
¦Версия ¦ 4 ¦
+---------------------------------------+--------------------------------------+
¦Длина заголовка ¦ 4 ¦
+---------------------------------------+--------------------------------------+
¦Тип сервиса ¦ 8 ¦
+---------------------------------------+--------------------------------------+
¦Полная длина ¦ 16 ¦
+---------------------------------------+--------------------------------------+
¦Идентификатор ¦ 16 ¦
+---------------------------------------+--------------------------------------+
¦Флаги ¦ 3 ¦
+---------------------------------------+--------------------------------------+
¦Смещение фрагмента ¦ 13 ¦
+---------------------------------------+--------------------------------------+
¦Время жизни ¦ 8 ¦
+---------------------------------------+--------------------------------------+
¦Тип протокола следующего уровня ¦ 8 ¦
+---------------------------------------+--------------------------------------+
¦Контрольная сумма заголовка ¦ 16 ¦
+---------------------------------------+--------------------------------------+
¦IP-адрес источника ¦ 32 ¦
+---------------------------------------+--------------------------------------+
¦IP-адрес назначения ¦ 32 ¦
+---------------------------------------+--------------------------------------+
¦IP-опции ¦ переменная длина ¦
¦(режим обработки пакета) ¦ ¦
+---------------------------------------+--------------------------------------+
¦Заполнение ¦ переменная длина ¦
+---------------------------------------+--------------------------------------+
¦Данные ¦ Полная длина пакета с данными не ¦
¦ ¦ превышает 65535 октетов ¦
+---------------------------------------+--------------------------------------+
¦ Примечание: Минимальная длина заголовка пакета 20 байт, максимальная длина¦
¦заголовка пакета 60 байт. ¦
L-------------------------------------------------------------------------------
1.1. Поле "Версия" содержит номер версии протокола IP.
1.2. Поле "Длина заголовка" содержит значение длины заголовка пакета в словах (одно слово - 32 бита).
1.3. Поле "Тип сервиса" содержит подполя, указанные в таблице N 2.
Таблица N 2
----------------------------------------T--------------------------------------¬
¦ Наименование подполя ¦ Длина, бит ¦
+---------------------------------------+--------------------------------------+
¦Приоритетность (Precedence) ¦ 3 ¦
+---------------------------------------+--------------------------------------+
¦Задержка (Delay) ¦ 1 ¦
+---------------------------------------+--------------------------------------+
¦Пропускная способность (Throughput) ¦ 1 ¦
+---------------------------------------+--------------------------------------+
¦Достоверность (Relibility) ¦ 1 ¦
+---------------------------------------+--------------------------------------+
¦Резервные биты (Reserved) ¦ 2 ¦
L---------------------------------------+---------------------------------------
Кодирование поля "Тип сервиса" выполняется в соответствии с правилами, приведенными в таблице N 3.
Таблица N 3
------------T------------------------------------------------------------------¬
¦ Разряд ¦ Параметр ¦
+-----------+------------------------------------------------------------------+
¦ 0 ¦Зарезервировано ¦
+-----------+------------------------------------------------------------------+
¦ 1 ¦Значение "0" - пакет можно фрагментировать, значение "1" - пакет ¦
¦ ¦нельзя фрагментировать ¦
+-----------+------------------------------------------------------------------+
¦ 2 ¦Значение "0" - последний фрагмент, значение "1" - еще фрагменты ¦
L-----------+-------------------------------------------------------------------
Значение разрядов 0 - 2 игнорируется, если не поддерживается управление приоритетом передачи пакетов.
1.4. Поле "Длина пакета IP" содержит значение длины пакета в байтах, включая заголовок и данные.
1.5. Поле "Идентификатора пакета" используется процедурой фрагментации при сборке (разборке) пакета для определения последовательности передаваемых фрагментов.
1.6. Поле "Флаги" используется процедурой фрагментации для управления последовательностью сборки фрагментов пакета. Поле "Флаги" содержит подполя, указанные в таблице N 2.
Кодирование поля "Флаги" выполняется в соответствии со следующими правилами, приведенными в таблице N 4.
Таблица N 4
----------------------------------------------T--------------------------------¬
¦ Наименование подполя ¦ Длина, бит ¦
+---------------------------------------------+--------------------------------+
¦Резервный бит (Reserved) ¦ 1 ¦
+---------------------------------------------+--------------------------------+
¦Возможность фрагментирования (DF) ¦ 1 ¦
+---------------------------------------------+--------------------------------+
¦Указатель последнего фрагмента (MF) ¦ 1 ¦
L---------------------------------------------+---------------------------------
1.7. Поле "Смещение фрагмента" используется для указания смещения данного фрагмента относительно первого фрагмента в блоках фрагментации (8 байт). Для первого фрагмента смещение устанавливается в "0".
1.8. Поле "Время жизни" содержит текущее значение счетчика максимально допустимого времени пребывания пакета в сети в секундах. При значении поля, равном "0", пакет удаляется.
1.9. Поле "Протокол" содержит стандартизированный код протокола следующего уровня.
1.10. Поле "Контрольная сумма заголовка" (далее - КСЗ) содержит контрольную сумму заголовка. При любом изменении содержания КСЗ пересчитывается.
1.11. В поле "Адрес источника пакета" указывается IP-адрес источника пакета.
1.12. В поле "Адрес получателя пакета" указывается IP-адрес получателя пакета.
1.13. При наличии поля "Режим обработки пакета" поддерживается два способа кодирования:
1) поле длиной 1 байт;
2) комбинация трех подполей: тип режима (1 байт), счетчик длины поля режима (1 байт), данные режима (переменная длина).
Подполе типа режима включает в себя:
1) флаг (1 бит);
2) класс режима (2 бита);
3) номер режима (5 бит).
При установке бита флага в значение "1" копируется данное поле при фрагментации во все фрагменты, в значение "0" - не копируется.
Установка битов класса режима соответствует следующим значениям:
1) "0" - управление;
2) "1" - зарезервировано;
3) "2" - отладка и измерение;
4) "3" - зарезервировано.
В "Режиме обработки пакета" предусмотрена поддержка классов режимов, приведенных в таблице N 5.
Таблица N 5
----------------T--------------------------------------------------------------¬
¦Класс/N режима ¦ Описание класса ¦
+---------------+--------------------------------------------------------------+
¦ 0/0 ¦Конец списка режимов. Длина поля режима 1 байт, поле счетчика ¦
¦ ¦длины поля режима отсутствует ¦
+---------------+--------------------------------------------------------------+
¦ 0/1 ¦Нет действий. Длина поля режима 1 байт, поле счетчика длины ¦
¦ ¦поля режима отсутствует ¦
+---------------+--------------------------------------------------------------+
¦ 0/2 ¦Безопасность. Длина поля режима 11 байт ¦
+---------------+--------------------------------------------------------------+
¦ 0/3 ¦Свободная маршрутизация от источника. Длина поля режима ¦
¦ ¦переменная ¦
+---------------+--------------------------------------------------------------+
¦ 0/9 ¦Строгая маршрутизация от источника. Длина поля режима ¦
¦ ¦переменная ¦
+---------------+--------------------------------------------------------------+
¦ 0/7 ¦Записанный маршрут. Длина поля режима переменная ¦
+---------------+--------------------------------------------------------------+
¦ 0/8 ¦Идентификатор потока. Длина поля режима 4 байта ¦
+---------------+--------------------------------------------------------------+
¦ 2/4 ¦Отметка времени Internet. Длина поля режима переменная ¦
L---------------+---------------------------------------------------------------
1.14. При наличии поля "Дополнения до границы заголовка" для выравнивания границы заголовка по длине, кратной 32 бит, свободные позиции заполнены нулевыми битами.
2. В протоколе IP реализованы две обязательные основные процедуры - адресация и фрагментация. Данные для этих процедур содержатся в заголовке пакета.
2.1. Процедура IP-адресации поддерживается для сетей трех классов с форматами, приведенными в таблице N 6.
Таблица N 6
--------------------T---------------------------------------T------------------¬
¦ Старшие разряды ¦ Формат ¦ Класс сети ¦
¦ +-------------------T-------------------+ ¦
¦ ¦ адрес сети ¦ адрес узла ¦ ¦
+-------------------+-------------------+-------------------+------------------+
¦ 0 ¦ 7 бит ¦ 24 бита ¦ A ¦
+-------------------+-------------------+-------------------+------------------+
¦ 10 ¦ 14 бит ¦ 16 бит ¦ B ¦
+-------------------+-------------------+-------------------+------------------+
¦ 110 ¦ 21 бит ¦ 8 бит ¦ C ¦
+-------------------+-------------------+-------------------+------------------+
¦ 111 ¦ Для режима расширенной адресации ¦
L-------------------+-----------------------------------------------------------
Не допускается нулевое значение в поле адреса сети для межсетевой маршрутизации.
2.2. Процедура фрагментации:
1) в случае если пакет IP подлежит передаче без фрагментации, поле данных пакета разделяется на фрагменты с выравниванием по длине блоков фрагментации (8 байт). Заголовок пакета процедуре фрагментации не подвергается;
2) фрагментация пакетов длиной 68 байт и менее не допускается;
3) следующие поля заголовка пакета могут подвергаться обработке при фрагментации:
а) поле режимов;
б) поле флагов;
в) смещение фрагмента;
г) длина заголовка;
д) длина пакета;
е) контрольная последовательность заголовка;
4) в случае, когда в заголовке пакета выставлен флаг, запрещающий его фрагментацию, пакет исключается из процесса передачи. Установка данного флага предусматривается, когда ресурсы на приеме не позволяют поддерживать процедуру обратной сборки пакета;
5) контрольная последовательность предусматривается только для поля заголовка пакета.
3. Структура и формат пакета для протокола IPv6 приведены в таблице N 7.
Таблица N 7
----------------------------------------T--------------------------------------¬
¦ Поле ¦ Длина (бит) ¦
+---------------------------------------+--------------------------------------+
¦Версия ¦ 4 ¦
+---------------------------------------+--------------------------------------+
¦Приоритет ¦ 4 ¦
+---------------------------------------+--------------------------------------+
¦Метка потока ¦ 24 ¦
+---------------------------------------+--------------------------------------+
¦Размер поля данных ¦ 16 ¦
+---------------------------------------+--------------------------------------+
¦Следующий заголовок ¦ 8 ¦
+---------------------------------------+--------------------------------------+
¦Предельное число шагов ¦ 8 ¦
+---------------------------------------+--------------------------------------+
¦Адрес отправителя ¦ 128 ¦
+---------------------------------------+--------------------------------------+
¦Адрес получателя ¦ 128 ¦
L---------------------------------------+---------------------------------------
3.1. Типы адресов:
Используются три типа адресов:
1) unicast - адрес одиночного получателя (пакет доставляется только по указанному адресу);
2) anycast - адрес набора получателей (пакет доставляется одному из интерфейсов с указанным адресом);
3) multicast - адрес группы получателей (пакет доставляется всем интерфейсам с указанным адресом).
Отличительной особенностью адреса последнего типа является значение "FF" первого байта адреса.
3.2. Все пакеты, принадлежащие одному потоку, посылаются одним отправителем, имеют один и тот же адрес места назначения, приоритет и метку потока.
3.3. Коды от "0" до "7" используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки.
3.4. Значения с "8" до "15" обозначают трафик, для которого не производится снижение потока в ответ на сигнал перегрузки.
3.5. Заголовки расширения размещаются между заголовком IP и заголовком верхнего уровня пакета.
Приложение N 2
к Правилам применения
оборудования коммутации
и маршрутизации
пакетов информации
ТРЕБОВАНИЯ
К РЕАЛИЗАЦИИ ПРОТОКОЛА ICMP
1. Назначением протокола ICMP является формирование и управление передачей сообщений:
а) об ошибках при обработке пакетов IP;
б) о состоянии узлов сети передачи данных.
2. Сообщения ICMP передаются в поле данных пакета IP. При этом значение первого байта поля данных пакета IP указывает на тип сообщения ICMP.
3. Любое неиспользованное поле сообщения ICMP устанавливается в "0".
4. Формат сообщений об ошибках при обработке пакетов IP соответствует структуре, приведенной в таблице N 1.
Таблица N 1
----------------------------------------T--------------------------------------¬
¦ Заголовок IP ¦ Переменная длина (байт) ¦
+---------------------------------------+--------------------------------------+
¦Тип сообщения ¦ 1 ¦
+---------------------------------------+--------------------------------------+
¦Код сообщения ¦ 1 ¦
+---------------------------------------+--------------------------------------+
¦Контрольная последовательность ¦ 2 ¦
¦сообщения ICMP ¦ ¦
+---------------------------------------+--------------------------------------+
¦Не используется ¦ 4 ¦
+---------------------------------------+--------------------------------------+
¦Заголовок пакета IP и первые 64 бита ¦ Переменная длина ¦
¦пакета IP, в котором обнаружена ошибка ¦ ¦
L---------------------------------------+---------------------------------------
5. Сообщения протокола ICMP об ошибках в пакетах IP:
1) Сообщение "Получатель недоступен" (Destination Unreachable Message) формируется и отправляется по адресу отправителя в случае, если:
а) недоступен адрес получателя;
б) недоступен порт в требуемом направлении передачи;
в) не поддерживается требуемый стек протоколов;
г) невозможна передача пакета без фрагментации при установленном флаге запрета фрагментации.
Кодирование поля сообщения "Получатель недоступен" осуществляется в соответствии с таблицей N 2.
Таблица N 2
-----------------------------------------------------------T-------------------¬
¦ Название поля ¦ Значение ¦
+----------------------------------------------------------+-------------------+
¦ Тип сообщения ¦ 3 ¦
+-------------T--------------------------------------------+-------------------+
¦ ¦сеть недоступна ¦ 0 ¦
¦ +--------------------------------------------+-------------------+
¦ ¦узел недоступен ¦ 1 ¦
¦ +--------------------------------------------+-------------------+
¦ ¦протокол недоступен ¦ 2 ¦
¦ +--------------------------------------------+-------------------+
¦ ¦порт недоступен ¦ 3 ¦
¦ +--------------------------------------------+-------------------+
¦ ¦фрагментация необходима, но запрещена ¦ 4 ¦
¦ +--------------------------------------------+-------------------+
¦ ¦исходный маршрут недействителен ¦ 5 ¦
L-------------+--------------------------------------------+--------------------
2) Сообщение "Время пребывания пакета IP в сети истекло" (Time Exceeded Message - TEM) передается по адресу источника данного пакета в следующих случаях:
а) при обнаружении, что поле "Время прерывания пакета" в данном пакете содержит нулевое значение;
б) при обнаружении, что заданное время пребывания данного пакета в сети истекает прежде окончания сборки его фрагментов.
Кодирование полей сообщения осуществляется в соответствии с таблицей N 3.
Таблица N 3
------------------------------------------------------------------T------------¬
¦ Название поля ¦ Значение ¦
+-----------------------------------------------------------------+------------+
¦ Тип сообщения ¦ 11 ¦
+----------------T------------------------------------------------+------------+
¦ Код сообщения: ¦Время пребывания пакета IP в сети истекло на ¦ 0 ¦
¦ ¦транспортном участке ¦ ¦
¦ +------------------------------------------------+------------+
¦ ¦Время сборки фрагментированного пакета IP ¦ 1 ¦
¦ ¦превышает время пребывания пакета IP в сети ¦ ¦
L----------------+------------------------------------------------+-------------
3) Сообщение "Проблемы в параметрах" (Parameter Problem Message - PPM) формируется, если значения параметров заголовка пакета IP не позволяют завершить его корректную обработку.
Сообщение передается по адресу источника данного пакета, при этом первый байт поля "Не используется" в заголовке сообщения ICMP содержит указатель, идентифицирующий байт заголовка пакета IP (порядковый номер байта), содержание которого привело к возникновению проблем.
Кодирование полей сообщения осуществляется в соответствии с таблицей N 4.
Таблица N 4
------------------------------------------------------------T------------------¬
¦ Название поля ¦ Значение ¦
+-----------------------------------------------------------+------------------+
¦Тип сообщения ¦ 12 ¦
+-----------------------------------------------------------+------------------+
¦Код-индикатор наличия проблем в параметрах заголовка ¦ 0 ¦
¦пакета IP (принимается как от шлюза, так и от узла) ¦ ¦
L-----------------------------------------------------------+-------------------
4) Сообщение "Подавление источника" (Source Quench Message - SQM) формируется в случае невозможности обработки принимаемых пакетов по причинам:
а) переполнения буферной памяти;
б) высокой интенсивности поступления пакетов.
Сообщение передается по адресу источника удаляемого из обработки пакета.
Формируется сообщение "Подавление источника" для каждого удаленного из обработки пакета.
В случае приема сообщения "Подавление источника" уменьшается интенсивность передачи пакетов.
Кодирование полей сообщения осуществляется в соответствии с таблицей N 5.
Таблица N 5
---------------------------------------------------T---------------------------¬
¦ Название поля ¦ Значение ¦
+--------------------------------------------------+---------------------------+
¦Тип сообщения ¦ 4 ¦
+--------------------------------------------------+---------------------------+
¦Код ¦ 0 ¦
L--------------------------------------------------+----------------------------
5) Сообщение "Перенаправление" (Redirect Message - RM) формируется в случае, если шлюз, через который надлежит продолжить передачу, принадлежит той же сети, что и узел-отправитель.
Сообщение передается по адресу источника пакета.
Поле "Не используется" в данном сообщении содержит адрес шлюза, к которому источник направляет свои пакеты.
Кодирование полей сообщения осуществляется в соответствии с таблицей N 6.
Таблица N 6
------------------------------------------------------------------T------------¬
¦ Название поля ¦ Значение ¦
+-----------------------------------------------------------------+------------+
¦ 1 ¦ 2 ¦
+-----------------------------------------------------------------+------------+
¦Тип сообщения ¦ 5 ¦
+--------------T--------------------------------------------------+------------+
¦Код сообщения ¦Перенаправление пакетов по критерию подполя "Адрес¦ 0 ¦
¦ ¦сети" ¦ ¦
¦ +--------------------------------------------------+------------+
¦ ¦Перенаправление пакетов по критерию подполя "Адрес¦ 1 ¦
¦ ¦узла" ¦ ¦
¦ +--------------------------------------------------+------------+
¦ ¦Перенаправление пакетов по критерию подполя "Тип ¦ 2 ¦
¦ ¦обслуживания" и подполя "Адрес сети" ¦ ¦
¦ +--------------------------------------------------+------------+
¦ ¦Перенаправление пакетов по критерию подполя "Тип ¦ 3 ¦
¦ ¦обслуживания" и подполя "Адрес узла" ¦ ¦
L--------------+--------------------------------------------------+-------------
Сообщение "Перенаправление" не формируется для пакетов, в заголовке которых указаны функции маршрутизации от узла-отправителя и адрес шлюза в поле адреса получателя, даже если этот маршрут не оптимален.
6. Сообщения ICMP о состоянии узлов сети:
Сообщения "Запрос эхо/Отклик эхо" формирует сообщение "Запрос эхо" (Echo) по инициативе системы административного управления.
При получении сообщения "Запрос эхо" сформировывается сообщение "Отклик эхо" (Echo Reply Message - EoERM).
Сообщение имеет формат, приведенный в таблице N 7.
Таблица N 7
----------------------------------------T--------------------------------------¬
¦ Заголовок IP ¦ Переменная длина ¦
+---------------------------------------+--------------------------------------+
¦Тип сообщения ¦ 1 байт ¦
+---------------------------------------+--------------------------------------+
¦Код сообщения ¦ 1 байт ¦
+---------------------------------------+--------------------------------------+
¦Контрольная последовательность ¦ 2 байта ¦
¦сообщения ICMP ¦ ¦
+---------------------------------------+--------------------------------------+
¦Идентификатор ¦ 2 байта ¦
+---------------------------------------+--------------------------------------+
¦Порядковый номер ¦ 2 байта ¦
+---------------------------------------+--------------------------------------+
¦Данные ¦ Переменная длина ¦
L---------------------------------------+---------------------------------------
Значение поля "Тип сообщения" устанавливается в "8" для "Запроса эхо" и в "0" для "Отклика эхо".
Поле данных, принятое в сообщении "Запрос эхо", посылается обратно в сообщении "Отклик эхо" без изменений.
Поля "Идентификатор" и "Порядковый номер" являются параметрами для отслеживания соответствия многократной посылки сообщений и получения откликов.
Поле "Код сообщения" устанавливается в значение "0".
7. Сообщения "Отметка времени/Отклик на отметку времени" (Timestamp/Timestamp Reply Message - ToTRM) формируется по инициативе системы административного управления.
Сообщение имеет формат, приведенный в таблице N 8.
Таблица N 8
-------------------------------------------------------------------------------¬
¦ Заголовок пакета IP ¦
+-----------------T------------------T-----------------------------------------+
¦ Тип сообщения ¦ Код (1 байт) ¦ Контрольная последовательность сообщения¦
¦ (1 байт) ¦ ¦ ICMP (2 байта) ¦
+-----------------+------------------+-----------------------------------------+
¦ Идентификатор ¦ Порядковый номер ¦
+------------------------------------+-----------------------------------------+
¦ Отметка исходного времени (4 байта) ¦
+------------------------------------------------------------------------------+
¦ Отметка времени приема (4 байта) ¦
+------------------------------------------------------------------------------+
¦ Отметка времени передачи (4 байта) ¦
L-------------------------------------------------------------------------------
Кодирование сообщений осуществляется по следующим правилам:
а) поля "Идентификатор" и "Порядковый номер" используются параметрами для отслеживания соответствия многократной посылки сообщения и получения откликов;
б) значение поля "Тип сообщения" устанавливается в "13" для сообщения "Отметка времени" и в "14" для сообщения "Отклик на отметку времени";
в) поле "Код сообщения" устанавливается в "0";
г) в поле "Отметка исходного времени" фиксируется момент времени, когда отправитель завершил формирование данного сообщения для его отправки;
д) в поле "Отметка времени приема" фиксируется момент времени, когда получатель принял сообщение, но еще не приступил к его обработке;
е) в поле "Отметка времени передачи" фиксируется момент времени, когда получатель завершил обработку сообщения для его возврата.
8. Сообщение "Информационный запрос/Ответ на информационный запрос" (Information Request/Information Reply Message - IRoIRM) формируется по инициативе системы административного управления.
Сообщение имеет формат, приведенный в таблице N 9.
Таблица N 9
------------------------------------------------T------------------------------¬
¦ Заголовок IP ¦ Переменная длина (байт) ¦
+-----------------------------------------------+------------------------------+
¦Тип сообщения ¦ 1 ¦
+-----------------------------------------------+------------------------------+
¦Код сообщения ¦ 1 ¦
+-----------------------------------------------+------------------------------+
¦Контрольная последовательность сообщения ICMP ¦ 2 ¦
+-----------------------------------------------+------------------------------+
¦Идентификатор ¦ 2 ¦
+-----------------------------------------------+------------------------------+
¦Порядковый номер ¦ 2 ¦
L-----------------------------------------------+-------------------------------
Кодирование полей сообщений "Информационный запрос/Ответ на информационный запрос" осуществляется по следующим правилам:
а) поля "Идентификатор" и "Порядковый номер" используются для отслеживания соответствия многократной посылки информационных запросов и получения откликов;
б) значение поля "Тип сообщения" устанавливается в "15" для информационного запроса (Information Request Message) и в "16" для отклика на информационный запрос (Information Reply Message);
в) поле "Код сообщения" устанавливается в "0";
г) сообщение "Information Request" отправляется с установкой адреса отправителя в заголовке пакета IP, но с нулевым значением адреса получателя. В ответном сообщении "Information Reply Message" поля адресов полностью определяются.
9. Сообщение "Объявление маршрутизатора" (Router Advertisement Message) формируется по инициативе системы административного управления.
Кодирование полей сообщений "Router Advertisement Message" осуществляется по следующим правилам:
а) в поле "Адрес отправителя пакета" заголовка IP, в котором передается сообщение "Router Advertisement Message", содержится адрес IP, принадлежащий интерфейсу, от которого отправлено сообщение;
б) в поле "Адрес пакета получателя" заголовка IP, в котором передается сообщение "Router Advertisement Message", содержится адрес IP смежного узла или специально задаваемый адрес "Advertisement Address".
Сообщение имеет формат, приведенный в таблице N 10.
Таблица N 10
-------------------------------------------------------------------------------¬
¦ Заголовок IP - переменная длина ¦
+------------------------T------------------------T----------------------------+
¦ Тип сообщения (1 байт) ¦ Код (1 байт) ¦ Контрольная ¦
¦ ¦ ¦последовательность (2 байта)¦
+------------------------+------------------------+----------------------------+
¦ Число адресов ¦ Размер входа адреса (1 ¦ Срок действия адресов (2 ¦
¦маршрутизатора (1 байт) ¦ байт) ¦ байта) ¦
+------------------------+------------------------+----------------------------+
¦ Адрес 1 маршрутизатора - 4 байта ¦
+------------------------------------------------------------------------------+
¦ Уровень предпочтения 1 - 4 байта ¦
+------------------------------------------------------------------------------+
¦ Адрес 2 маршрутизатора - 4 байта ¦
+------------------------------------------------------------------------------+
¦ Уровень предпочтения 2 - 4 байта ¦
+------------------------------------------------------------------------------+
¦ Адрес n маршрутизатора - 4 байта ¦
+------------------------------------------------------------------------------+
¦ Уровень предпочтения n - 4 байта ¦
+------------------------------------------------------------------------------+
¦ Примечание: n = 1, 2, 3..., бесконечность ¦
L-------------------------------------------------------------------------------
В поле "Счетчик допустимого времени пребывания пакета IP в сети" устанавливается значение 1 с, если в поле "Адрес получателя" задан групповой адрес вещания IP (IP multicast) или не менее 1 с в остальных случаях.
Значение поля "Тип сообщения" в заголовке пакета ICMP устанавливается в "9", поле "Код" устанавливается в значение "0".
Поле "Число адресов" маршрутизатора соответствует числу адресов, объявляемых в данном сообщении.
Поле "Размер входа адреса" содержит число 32-битовых слов информации для каждого адреса маршрутизатора (данный параметр зависит от версии протокола ICMP).
Поле "Срок действия адресов" содержит максимальное время в секундах, в течение которого адреса маршрутизатора могут считаться действительными.
Поле "Адрес маршрутизатора" содержит адрес IP отправляющего маршрутизатора на i-м интерфейсе, от которого отправляется данное сообщение (i = 1, 2,..., n, где n - число адресов).
Поле "Уровень предпочтения" содержит адрес маршрутизатора, который используется по умолчанию и является предпочтительным по отношению к другим адресам маршрутизатора в одной и той же подсети.
10. Сообщение "Запрос маршрутизатора" (Router Solicitation Message) формируется по инициативе системы административного управления.
Сообщение имеет формат, приведенный в таблице N 11.
Таблица N 11
----------------------------------------T--------------------------------------¬
¦ Заголовок IP ¦ Переменная длина ¦
+---------------------------------------+--------------------------------------+
¦Тип сообщения ¦ 1 байт ¦
+---------------------------------------+--------------------------------------+
¦Код сообщения ¦ 1 байт ¦
+---------------------------------------+--------------------------------------+
¦Контрольная последовательность ¦ 2 байта ¦
¦сообщения ICMP ¦ ¦
+---------------------------------------+--------------------------------------+
¦Зарезервировано ¦ 4 байта ¦
L---------------------------------------+---------------------------------------
Поля сообщения "Запрос маршрутизатора" (Router Solicitation Message) кодируются по следующим правилам:
а) в поле "Адрес отправителя пакета" заголовка пакета IP, в котором передается сообщение "Router Solicitation Message", содержится адрес IP, принадлежащий интерфейсу, от которого отправлено сообщение, или нулевое значение;
б) в поле "Адрес получателя пакета" заголовка пакета IP, в котором передается сообщение "Router Solicitation Message", содержится специально задаваемый адрес "Solicitation Address";
в) в поле "Счетчик допустимого времени пребывания пакета IP в сети" устанавливается значение 1 с, если в поле "Адрес получателя" задан групповой адрес вещания IP (IP multicast), или не менее 1 с в остальных случаях;
г) значение поля "Тип сообщения" в заголовке пакета ICMP устанавливается в "10", поле "Код" устанавливается в значение "0";
д) поле "Зарезервировано" устанавливается в "0" и игнорируется при приеме сообщения.
Приложение N 3
к Правилам применения
оборудования коммутации
и маршрутизации
пакетов информации
ТРЕБОВАНИЯ
К РЕАЛИЗАЦИИ ПРОТОКОЛА РАЗРЕШЕНИЯ АДРЕСОВ
1. Оборудование обеспечивает обработку пакетов сообщений ARP:
1) запрос;
2) ответ на запрос.
2. Форматы сообщений одинаковы, значение поля "Код операции" определяет тип сообщения. Поле "Код операции" устанавливается в значение "1" для пакета запроса ARP и в значение "0" для пакета ответа на запрос.
3. Генерация пакета запроса ARP инициируется оборудованием в случае, когда в таблице соответствия аппаратных адресов и IP-адресов отсутствует адрес получателя пакета IP, принятого оборудованием и подлежащего дальнейшей передаче.
4. Оборудование обеспечивает установку группового широковещательного адреса подсети, к которой оно принадлежит, в поле "Адрес получателя пакета запроса ARP". Поле "Адрес отправителя пакета" устанавливается в значение, соответствующее собственному IP-адресу. Поле "Аппаратный адрес получателя пакета" устанавливается в нулевое значение. Оборудование обеспечивает групповую передачу пакета запроса ARP ко всем подсоединенным узлам.
5. Если оборудование принимает пакет запроса ARP, содержащий собственный IP-адрес в поле "Протокольный адрес получателя пакета", обеспечивается генерация и посылка пакета в ответ на запрос ARP по адресу отправителя запроса. В этом пакете выполняется установка собственного аппаратного адреса в поле "Аппаратный адрес получателя пакета", до этого установленного в нулевое значение. При приеме пакета ответа на запрос ARP оборудование сформировывает связанную пару адресов, состоящую из адреса Internet и аппаратного адреса, полученного в пакете ответа, и выполняет внесение этой пары в таблицу соответствия адресов.
6. Формат пакета протокола разрешения адресов ARP при передаче пакетов протокола IP по сети передачи данных Ethernet приведен в таблице.
Таблица
-----------------------------------------------------------T-------------------¬
¦ Наименование поля ¦ Размер поля (бит) ¦
+----------------------------------------------------------+-------------------+
¦ 1 ¦ 2 ¦
+----------------------------------------------------------+-------------------+
¦Адрес получателя пакета в сети стандарта IEEE 802 ¦ 48 ¦
+----------------------------------------------------------+-------------------+
¦Адрес отправителя пакета в сети стандарта IEEE 802.2 ¦ 48 ¦
+----------------------------------------------------------+-------------------+
¦Тип протокола ¦ 16 ¦
+----------------------------------------------------------+-------------------+
¦Адресное пространство физической сети ¦ 16 ¦
+----------------------------------------------------------+-------------------+
¦Адресное пространство протокола ¦ 16 ¦
+----------------------------------------------------------+-------------------+
¦Длина адреса физической сети в байтах ¦ 8 ¦
+----------------------------------------------------------+-------------------+
¦Длина адреса протокола в байтах ¦ 8 ¦
+----------------------------------------------------------+-------------------+
¦Код операции ¦ 16 ¦
+----------------------------------------------------------+-------------------+
¦Физический адрес отправителя пакета ¦ переменная ¦
+----------------------------------------------------------+-------------------+
¦Адрес IP отправителя пакета ¦ переменная ¦
+----------------------------------------------------------+-------------------+
¦Физический адрес получателя пакета ¦ переменная ¦
+----------------------------------------------------------+-------------------+
¦Адрес IP получателя пакета ¦ переменная ¦
L----------------------------------------------------------+--------------------
7. Формат пакета протокола разрешения адресов ARP при передаче пакетов протокола IP в сети передачи данных Token Ring соответствует следующим требованиям:
а) минимальный размер пакета UI (ненумерованная информация), переносящего пакет ARP, не ограничен;
б) максимальный размер пакета UI, переносящего пакет ARP, определяется в соответствии со временем удержания маркера на узле.
Для поддержки передачи пакета запроса ARP по физической сети в оборудовании реализуется процедура обнаружения динамических адресов.
В оборудовании реализованы функция распознавания копий запросов ARP, поступающих от разных источников, и алгоритм исключения запроса копий.
Не допускается использование групповых и функциональных адресов в пакетах ARP.
Для пакетов UI, содержащих пакеты ARP, приоритет устанавливается по умолчанию.
8. Формат пакета протокола разрешения адресов ARP при передаче пакетов протокола IP в сети передачи данных FDDI соответствует следующим требованиям:
1) суммарная длина заголовка пакета уровня логического управления звеном (LLC) и заголовка протокола SNAP составляет 8 байт;
2) для передачи пакетов IP и ARP обеспечивается использование адресов FDDI только с длиной 6 байт;
3) поразрядная интерпретация адресов в пакете ARP осуществляется в обратном порядке в границах каждого байта;
4) групповой широковещательный IP-адрес отображается в групповой широковещательный адрес FDDI;
5) групповой многоточечный адрес IP отображается в групповой многоточечный адрес FDDI путем размещения 23-х младших битов адреса IP в младшие 23 бита адреса FDDI;
6) передача пакетов протокола IP осуществляется в режиме побайтовой поточной передачи;
7) отображение IP-адресов (4 байта) в адрес сети передачи данных FDDI (6 байт) осуществляется посредством процедуры обнаружения динамических адресов ARP.
Приложение N 4
к Правилам применения
оборудования коммутации
и маршрутизации
пакетов информации
ТРЕБОВАНИЯ
К ПРОЦЕДУРАМ ИНКАПСУЛЯЦИИ ПАКЕТОВ ПРОТОКОЛА IP
1. Требования к инкапсуляции пакетов протокола IP в пакеты протокола X.25:
1.1. Формат пакетов инкапсуляции.
Пакет "Запрос вызова" X.25 в поле "Данные вызова пользователя" содержит идентификатор протокола сетевого уровня NLPID (длиной 1 байт), инкапсулированного по виртуальному каналу X.25.
Для IP данный идентификатор NLPID имеет значение "СС" шестнадцатеричное.
Пакет IP переносится в поле блока данных пакета данных X.25. Пакеты посылаются как завершенные последовательности пакетов X.25 (пакет IP выровнен по границам пакета X.25. В случае, когда длина пакета IP превышает размер пакета данных X.25, пакет IP фрагментируется с использованием бита "еще данные").
1.2. Требования к процедурам инкапсуляции.
Инкапсуляция пакетов IP выполняется при помощи одного из трех способов:
1) пакеты IP, содержащиеся в мультиплексированных пакетах данных, передаваемых по каналу с "нулевой" (мультиплексированной) инкапсуляцией, инкапсулируются по идентификатору NLPID;
2) пакеты IP могут инкапсулироваться при помощи протокола SNAP (пакеты данных идентифицируются по "Уникальному административно назначаемому идентификатору" (OUI), содержащемуся в заголовке протокола SNAP (длиной 5 байт) и имеющему значение "000000" шестнадцатеричное, а также "Идентификатору протокола" (PID), имеющему значение "0800" шестнадцатеричное);
3) пакеты IP инкапсулируются по каналу, использующему "нулевую" инкапсуляцию, в мультиплексируемые пакеты данных внутри протокола SNAP.
В оборудовании поддерживается возможность согласования параметров для X.25 (размер пакета, размер окна).
В оборудовании обеспечивается возможность передачи (приема) блоков данных протокола длиной не менее 1600 байт.
По умолчанию максимальный размер передаваемых данных (MTU) X.25 для пакетов IP составляет до 1500 байт, при этом поддерживается возможность конфигурирования данного MTU (как минимум на уровне интерфейса) в диапазоне от 576 до 1600 байт.
В оборудовании поддерживается возможность конфигурирования максимальной длины блока данных (PDU) для протокола IP.
Для инкапсуляции пакетов IP между сетями передачи данных поддерживается отдельный виртуальный канал.
Обеспечивается поддержка нескольких виртуальных каналов для единственной инкапсуляции.
Обеспечивается прием нескольких входящих вызовов при одной и той же инкапсуляции от одного узла. При этом обеспечивается прием и последующая передача входящих PDU по дополнительному каналу.
Обеспечивается подтверждение вызовов одной и той же инкапсуляции с целью закрыть канал или игнорировать PDU от канала.
Не разрешается применение алгоритмов предотвращения конфликтов между вызовами виртуальных каналов.
Обеспечивается выбор (посредством конфигурации) режима, при котором для одного протокола назначается несколько виртуальных каналов.
В оборудовании поддерживается возможность конфигурации значения минимального "тайм-аута" для каналов, в течение которого каналы остаются открытыми, пока оконечные узлы находятся в активном состоянии.
Если виртуальный канал в момент приема пакета IP закрывается или сбрасывается, пакет IP пропадает.
В оборудовании обеспечивается использование "тайм-аута" простоя виртуальных каналов для сброса их активного состояния по истечении "тайм-аута". Длительность "тайм-аута" конфигурируема.
В оборудовании обеспечивается реализация конфигурируемой возможности приема вызовов от несконфигурированных адресов.
В оборудовании используется таймер закрытия канала с переменным значением для предотвращения повторных вызовов к аварийным узлам-получателям.
2. Требования к инкапсуляции пакетов протокола IP в кадры протокола Frame Relay.
2.1. Формат кадра.
Для пакетов IP, передаваемых по сети передачи данных Frame Relay, предусматриваются два способа инкапсуляции:
1) с использованием идентификатора протокола сетевого уровня NLPID, содержащего код протокола IP;
2) с использованием идентификатора протокола сетевого уровня NLPID, содержащего код протокола доступа подсети SNAP.
2.2. Согласование параметров уровня звена данных.
Параметры уровня звена данных назначаются по умолчанию, устанавливаются путем конфигурирования или в результате процедуры согласования посредством обмена кадрами "Идентификация параметров обмена" (XID). На этапе инициирования канала согласованию подлежат следующие параметры:
1) максимальный размер кадра;
2) таймер повторной передачи;
3) максимальное число неповрежденных информационных кадров (I-кадров).
2.3. Требования к процедуре фрагментации.
Максимальный размер передаваемого кадра составляет 262 байта. Для передачи пакетов IP, длина которых не позволяет инкапсулировать их в один кадр Frame Relay, применяется процедура фрагментации. Область действия фрагментации определяется границами сети Frame Relay.
Фрагменты передаются в порядке, определяемом значением поля сдвига от начала фрагментированного пакета (первый фрагмент имеет сдвиг, равный "0"). При передаче не допускается вставка в последовательность фрагментов, принадлежащих одному пакету, других пакетов или информации, относящихся к тому же соединению звена данных (DLC).
Если при процедуре обратной сборки обнаруживается пропадание или искажение фрагмента, сообщение исключается из обработки и передачи (считается утраченным).
2.4. Требования к процедуре инкапсуляции пакетов разрешения адресов.
Пакеты протокола разрешения адресов (ARP) инкапсулируются в пакеты Frame Relay с использованием способа инкапсуляции с заголовком протокола SNAP.
В процессе прохождения сети Frame Relay идентификатор соединения звена данных DLCI в заголовке инкапсулированного пакета ARP модифицируется.
Непосредственное использование групповых адресов IP в среде Frame Relay не регламентируется. Пакет с запросом протокола ARP копируется получателем пакета и рассылается по каждому соответствующему соединению DLC (эмуляция режима широковещательных адресов).
Групповая адресация в среде Frame Relay реализуется также посредством протокола обратного разрешения адресов (Inverse ARP).
3. Требования к инкапсуляции пакетов протокола IP при передаче по сети передачи данных ATM.
3.1. Мультиплексирование и форматы инкапсуляции.
Пакет IP передается в поле PDU протокола AAL5.
Для пакетов IP, передаваемых по сети передачи данных ATM, предусматриваются два способа инкапсуляции:
1) при использовании одного виртуального соединения несколькими протоколами - инкапсуляция с использованием заголовка уровня управления звеном данных LLC и заголовка протокола доступа подсети SNAP для идентификации протокола IP;
2) при выделении отдельного соединения виртуального канала каждому протоколу - инкапсуляция без использования заголовков уровня LLC и SNAP (для коммутируемых соединений ATM).
Выбор способа инкапсуляции обуславливается способом мультиплексирования и реализуется при конфигурации (для постоянных соединений) или посредством процедур сигнализации B-ISDN (для коммутируемых соединений). Если оборудование поддерживает работу только по постоянным соединениям, требование к возможности задания способа инкапсуляции при конфигурации является обязательным.
В зависимости от способа мультиплексирования многопротокольной передачи предусматриваются разные формы инкапсуляции.
Для инкапсуляции пакета IP заголовок LLC содержит значение "AAAA03" шестнадцатеричное, что соответствует случаю, когда за заголовком LLC следует заголовок SNAP, который идентифицирует протокол.
Заголовок SNAP состоит из поля OUI (длина 2 байта), значение которого устанавливается в "0", и поля EtherType (длина 2 байта), значение которого соответствует протоколу, которому принадлежит пакет.
Для протокола IP предусматривается установка поля EtherType в значение "0800" шестнадцатеричное, протоколу ARP соответствует "0806" шестнадцатеричное.
Для коммутируемых сетей передачи данных ATM блок PDU AAL5 не содержит заголовков LLC и SNAP и состоит только из данных пользователя и концевика.
Максимальная длина пакетов IP (MTU) по умолчанию составляет 9180 байт.
Структура блока данных протокола AAL5 с инкапсуляцией приведена на рисунке.
----T---T--T---T---T--T-----------T----------------T----T----T----T------T-----¬
¦АА ¦АА ¦03¦00 ¦00 ¦00¦ETHERTYPYP ¦Пакет IP или ARP¦PAD ¦ UU ¦CPI ¦Length¦ CRC ¦
+---+---+--+---+---+--+-----------+----------------+----+----+----+------+-----+
¦<-------->¦<-------------------->¦<-------------->¦<------------------------->¦
+----------+----------------------+----------------+---------------------------+
¦Заголовок ¦ Заголовок SNAP ¦ Данные ¦ Концевик AAL5 ¦
¦ LLC ¦ ¦ пользователя ¦ ¦
PAD - поле дополнения
UU - поле для передачи информации
CPI - индикатор общей части
Length - длина данных пользователя
CRC - контрольная последовательность
Рисунок.
Разрешение адресов.
В оборудовании реализуется поддержка параметров, специфичных для работы в сети передачи данных ATM.
Приложение N 5
к Правилам применения
оборудования коммутации
и маршрутизации
пакетов информации
ТРЕБОВАНИЯ
К ПАРАМЕТРАМ ИНТЕРФЕЙСОВ ДОСТУПА К СЕТИ С ИСПОЛЬЗОВАНИЕМ
КОНТРОЛЯ НЕСУЩЕЙ И ОБНАРУЖЕНИЕМ КОЛЛИЗИЙ (ETHERNET)
1. Требования к параметрам интерфейсов доступа к сети с использованием контроля несущей и обнаружением коллизий приведены в таблицах N N 1 - 9.
Таблица N 1. Параметры оптических интерфейсов 10 000 Мбит/с (10 Gigabit Ethernet)
------------------------------T------------------------------------------------¬
¦ Параметр ¦ Значение ¦
+-----------------------------+---------------T---------------T----------------+
¦Номинальная длина волны ¦ 850 нм ¦ 1310 нм ¦ 1550 нм ¦
+-----------------------------+---------------+---------------+----------------+
¦Тип оптического кабеля ¦ 62,5 мкм MMF, ¦ SMF ¦ SMF ¦
¦ ¦ 50 мкм MMF ¦ ¦ ¦
+-----------------------------+---------------+---------------+----------------+