- Законы
- Кодексы
- Форум
Технические требования к аппаратуре связи, реализующей функции маршрутизации пакетов протокола межсетевого обмена (аппаратура маршрутизации пакетов IP). РД 45.038-99
¦Ошибка во флагах атрибута ¦4 ¦ +-----------------------------------------------------------+-------------+ ¦Неверная длина атрибута ¦5 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительный атрибут типа ORIGIN ¦6 ¦ +-----------------------------------------------------------+-------------+ ¦Зацикливание маршрута ¦7 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительный атрибут типа NEXT_HOP ¦8 ¦ +-----------------------------------------------------------+-------------+ ¦Ошибка в необязательном атрибуте ¦9 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительное значение в поле Номер сети ¦10 ¦ ------------------------------------------------------------+--------------
Поле данных сообщения уведомления должно использоваться для диагностики причины посылки данного сообщения. Правила заполнения поля данных информацией для диагностики должны соответствовать RFC 1267, п. 6.
Длина поля данных должна определяться исходя из следующей формулы:
Длина сообщения = 21 + длина поля данных
Минимальная длина сообщения уведомления должна составлять 21 байт, включая заголовок (RFC 1267, п. 4.3).
Генерация и посылка сообщения уведомления с кодом и субкодом, соответствующими данному типу ошибок, должны обеспечиваться в аппаратуре при обнаружении ошибки. Сразу же после посылки данного сообщения аппаратура должна обеспечивать завершение сеанса BGP-3.
3.2.4.3. Процедуры и обработка ошибок BGP-3
В соответствии с RFC 1267 в аппаратуре должны быть реализованы следующие процедуры:
процедуры обработки ошибок (RFC 1267, п. 6);
установка кода аутентификации (RFC 1267, п. 4.2);
процедура согласования версии протокола (RFC 1267, п. 7);
идентификация, обработка и формирование списка кодов ошибок для сообщения NOTIFICATION (RFC 1267, п. 6.4);
процедура формирования списка атрибутов пути (RFC 1267, п. 5);
процедура обработки сообщений обновления данных маршрутизации (RFC 1267, п. 6.3);
поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1267, п. 6.5);
процедура обработки завершения сеанса (RFC 1267, п. 6.7);
процедура обнаружения конфликта сеансов (RFC 1267, п. 6.8);
процедура обнаружения противоречий между стратегиями маршрутизации автономных систем (RFC 1267, п. 10);
процедура настройки периодичности выбора маршрута (RFC 1267, п. А.5.5).
Все таймеры, реализованные в аппаратуре для поддержки BGP-3, должны быть конфигурируемы (RFC 1267, п. А.5.4).
3.2.5. Протокол BGP-4 (пограничной маршрутизации)
Для BGP-4 допускается использование равнозначного названия - Протокол бесклассовой межрегиональной маршрутизации CIDR.
Инициирование сеанса BGP-4 аппаратурой допускается при условиях, предусмотренных в RFC 1771, п. 2.
3.2.5.1. Формат заголовка и типы сообщений BGP-4
Для всех типов сообщений BGP-4 формат заголовка должен соответствовать RFC 1771, п. 4.1:
--------------+-----------------------------+------------------------------ ¦ Маркер ¦ Длина сообщения ¦ Тип сообщения ¦ --------------+-----------------------------+------------------------------ <------------> <---------------------------> <---------------------------> 16 байт 2 байта 1 байт
Рис. 3.28. Формат заголовка сообщения BGP-4
В аппаратуре должны поддерживаться следующие типы сообщений BGP-4 (RFC 1771, п. 4.1):
------------------------------------------+-------------------------------- ¦ Тип сообщения ¦Код типа сообщения в заголовке ¦ +-----------------------------------------+-------------------------------+ ¦Инициирование сеанса OPEN ¦1 ¦ +-----------------------------------------+-------------------------------+ ¦Обновление данных маршрутизации UPDATE ¦2 ¦ +-----------------------------------------+-------------------------------+ ¦Уведомление NOTIFICATION ¦3 ¦ +-----------------------------------------+-------------------------------+ ¦Поддержка сеанса KEEPALIVE ¦4 ¦ ------------------------------------------+--------------------------------
3.2.5.2. Сообщения BGP-4
Аппаратура должна поддерживать требования к длине сообщения протокола (минимальная длина - 19 байт (сообщение состоит только из заголовка), максимальная длина - 4096 байт) и требования к форматам сообщений (RFC 1771, п. 4).
3.2.5.2.1. Сообщение инициирования сеанса "OPEN"
Формат сообщения OPEN должен соответствовать RFC 1771, п. 4.2.
----------+------+-----------+---------+---------+--------------+----------
¦Заголовок¦Версия¦Номер сети ¦Тайм-аут ¦Идентифи-¦ Длина поля ¦Необяза- ¦
¦ ¦ ¦(автономной¦сообщений¦катор от-¦необязательных¦тельные ¦
¦ ¦ ¦ системы) ¦протокола¦правителя¦ параметров ¦параметры¦
----------+------+-----------+---------+---------+--------------+----------
<--------> <----> <---------> <-------> <-------> <------------> <-------->
19 байт 1 байт 2 байта 2 байта <...> 1 байт переменная
байта длина
Рис. 3.29. Формат сообщения OPEN
Структура и значения полей сообщения OPEN должны соответствовать RFC 1771, п. 4.2.
3.2.5.2.2. Сообщение обновления данных маршрутизации "UPDATE"
Формат сообщения UPDATE должен соответствовать RFC 1771, п. 4.3:
--------------------------------------------------------------------------- ¦ Заголовок ¦ +-------------------------------------------------------------------------+ ¦ Недопустимая длина маршрутов (2 байта) ¦ +-------------------------------------------------------------------------+ ¦ Отозванные маршруты (длина переменная) ¦ +-------------------------------------------------------------------------+ ¦ Суммарная длина атрибутов пути (2 байта) ¦ +-------------------------------------------------------------------------+ ¦ Атрибуты пути (длина переменная) ¦ +-------------------------------------------------------------------------+ ¦ Информация о доступности сетевого уровня (длина переменная) ¦ ---------------------------------------------------------------------------
Рис. 3.30. Формат сообщения UPDATE
Структура и значения полей сообщения UPDATE должны соответствовать RFC 1771, п. 4.3.
3.2.5.2.3. Сообщение поддержки сеанса "KEEPALIVE"
Сообщение KEEPALIVE должно состоять из заголовка длиной 19 байт (код типа сообщения 4) без поля данных (RFC 1771, п. 4.4).
В целях поддержки сеанса BGP-4 при отсутствии обмена другими сообщениями аппаратурой должна осуществляться периодическая генерация и передача сообщения KEEPALIVE до истечения тайм-аута, задаваемого в сообщении инициирования сеанса OPEN. В аппаратуре должен поддерживаться максимальный интервал посылки сообщений KEEPALIVE длительностью не менее 1/3 тайм-аута.
При приеме сообщения KEEPALIVE счетчик тайм-аута в аппаратуре должен быть обнулен.
При неприеме каких-либо сообщений по истечении заданного тайм-аута аппаратура должна обеспечивать завершение сеанса BGP-4 (RFC 1771, п. 4.4).
3.2.5.2.4. Сообщение уведомления "NOTIFICATION"
Формат сообщения NOTIFICATION должен соответствовать RFC 1771, п. 4.5.
-----------------+-------------+--------------+----------------------------
¦ Заголовок ¦ Код ошибки ¦Субкод ошибки ¦ Данные для диагностики ¦
-----------------+-------------+--------------+----------------------------
<---------------> <-----------> <------------> <-------------------------->
19 байт 1 байт 1 байт переменная длина
Рис. 3.31. Формат сообщения NOTIFICATION
В аппаратуре должны поддерживаться следующие коды ошибки:
---------------------------------------------------------------+----------- ¦ Тип уведомления ¦Код ошибки¦ +--------------------------------------------------------------+----------+ ¦Ошибка в заголовке сообщения ¦1 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка в сообщении OPEN ¦2 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка в сообщении UPDATE ¦3 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка по тайм-ауту ¦4 ¦ +--------------------------------------------------------------+----------+ ¦Ошибка порядка обмена сообщениями ¦5 ¦ +--------------------------------------------------------------+----------+ ¦Прерывание ¦6 ¦ ---------------------------------------------------------------+-----------
Поле субкода ошибки должно заполняться значением целого числа. Значение "0" должно устанавливаться в случае, если для данного типа ошибок субкода не предусмотрено.
Для ошибок в заголовке сообщения должны поддерживаться следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Нарушение синхронизации передачи сообщений в сеансе ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Некорректная длина сообщения ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Некорректный тип сообщения ¦3 ¦ ------------------------------------------------------------+--------------
Для ошибок в сообщении OPEN должны поддерживаться следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Данная версия протокола не поддерживается ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Неверный номер сети (автономной системы) ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Неверный идентификатор отправителя ¦3 ¦ +-----------------------------------------------------------+-------------+ ¦Данный необязательный параметр не поддерживается ¦4 ¦ +-----------------------------------------------------------+-------------+ ¦Процедура аутентификации завершилась с отрицательным ¦5 ¦ ¦результатом ¦ ¦ +-----------------------------------------------------------+-------------+ ¦Неприемлемое значение тайм-аута ¦6 ¦ ------------------------------------------------------------+--------------
Для ошибок в сообщении UPDATE должны поддерживаться следующие субкоды:
------------------------------------------------------------+-------------- ¦ Описание ¦Субкод ошибки¦ +-----------------------------------------------------------+-------------+ ¦Список атрибутов сформирован, неверно ¦1 ¦ +-----------------------------------------------------------+-------------+ ¦Неидентифицируемый обязательный атрибут ¦2 ¦ +-----------------------------------------------------------+-------------+ ¦Отсутствует обязательный атрибут ¦3 ¦ +-----------------------------------------------------------+-------------+ ¦Ошибка во флагах атрибута ¦4 ¦ +-----------------------------------------------------------+-------------+ ¦Неверная длина атрибута ¦5 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительный атрибут типа ORIGIN ¦6 ¦ +-----------------------------------------------------------+-------------+ ¦Зацикливание маршрута ¦7 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительный атрибут типа NEXT_HOP ¦8 ¦ +-----------------------------------------------------------+-------------+ ¦Ошибка в необязательном атрибуте ¦9 ¦ +-----------------------------------------------------------+-------------+ ¦Недействительное значение в поле Номер сети ¦10 ¦ +-----------------------------------------------------------+-------------+ ¦Неверно сформирован атрибут типа AS_PATH ¦11 ¦ ------------------------------------------------------------+--------------
Поле данных сообщения уведомления должно использоваться для диагностики причины посылки данного сообщения. Правила заполнения поля данных информацией для диагностики должны соответствовать RFC 1771, п. 6.
Длина поля данных должна определяться исходя из следующей формулы:
Длина сообщения = 21 + длина поля данных.
Минимальная длина сообщения уведомления должна составлять 21 байт, включая заголовок (RFC 1771, п. 4.5).
Генерация и посылка сообщения уведомления с кодом и субкодом, соответствующими данному типу ошибок, должны обеспечиваться в аппаратуре при обнаружении ошибки. Сразу же после посылки данного сообщения аппаратура должна обеспечивать завершение сеанса BGP-4.
3.2.5.3. Процедуры и функции BGP-4
В соответствии с RFC I771 в аппаратуре должны быть реализованы следующие процедуры:
- поддержка информационных баз BGP-4 (RFC 1771, п. 3.2);
- процедуры обработки ошибок BGP-4 (RFC 1771, п. п. 6.1 - 6.4);
- установка кода аутентификации (RFC 1771, п. 4.2);
- процедура согласования версии протокола (RFC 1771, п. 7);
- процедура формирования списка атрибутов пути (RFC 1771, п. 5);
- поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1771, п. 6.5);
- процедура обработки завершения сеанса (RFC 1771, п. 6.7);
- процедура обработки сообщений обновления данных маршрутизации (RFC 1771, п. 7);
- процедура обнаружения и разрешения конфликта сеансов (RFC 1771, п. 6.8);
- процедура обработки критериев выбора маршрута (RFC 1771, п. 9.3).
Все таймеры, реализованные в аппаратуре для поддержки BGP-4, должны быть конфигурируемы (RFC 1771, п. А.6.4).
3.3. ТРЕБОВАНИЯ К ФУНКЦИЯМ ПРОТОКОЛА РАЗРЕШЕНИЯ АДРЕСОВ
Реализация функций протокола разрешения адресов Address Resolution Protocol (ARP) является обязательной для аппаратуры. Требования к функциям и форматам сообщений ARP регламентируются стандартами Internet RFC 826, 1042, 1390.
3.3.1. Сообщения ARP
Аппаратура должна обеспечивать обработку пакетов сообщений ARP. Должны поддерживаться два типа сообщения ARP:
- Запрос;
- Ответ на запрос.
Формат сообщений одинаковый, значение поля Код операции должно определять тип сообщения. Поле Код операции должно устанавливаться в значение "1" для пакета запроса ARP и в значение "0" для пакета ответа на запрос (RFC 826).
Генерация пакета запроса ARP должна инициироваться аппаратурой в случае, когда в таблице соответствия физических (сетевых) адресов и адресов Internet отсутствует адрес получателя пакета IP, принятого аппаратурой и подлежащего дальнейшей передаче.
Аппаратура должна обеспечивать установку группового широковещательного адреса подсети, к которой она принадлежит, в поле Адрес получателя пакета в сети стандарта IEEE 802 пакета запроса ARP. Поле Адрес отправителя пакета в сети стандарта IEEE 802 должно устанавливаться в значение, соответствующее собственному адресу Internet аппаратуры. Поле Физический адрес получателя пакета должно устанавливаться в нулевое значение. Аппаратура должна обеспечить групповую передачу пакета запроса ARP ко всем подсоединенным узлам.
Если аппаратура принимает пакет запроса ARP, содержащий ее собственный адрес Internet в поле Протокольный адрес получателя пакета, она должна обеспечить генерацию и посылку пакета ответа на запрос ARP по адресу отправителя запроса. В этом пакете она должна выполнить установку собственного физического (сетевого) адреса в поле Физический адрес получателя пакета, до этого установленного в нулевое значение.
При приеме пакета ответа на запрос ARP аппаратура должна сформировать связанную пару адресов, состоящую из адреса Internet и физического (сетевого) адреса, полученного в пакете ответа, и выполнить внесение этой пары в таблицу соответствия адресов.
3.3.2. Протокол разрешения адресов ARP при передаче пакетов протокола IP по сети в стандарте IEEE 802
3.3.2.1. Формат пакета протокола ARP
--------------------------------------------------------------------------- ¦ Адрес получателя пакета в сети стандарта IEEE 802 (48 бит) ¦ +-------------------------------------------------------------------------+ ¦ Адрес отправителя пакета в сети стандарта IEEE 802 (48 бит) ¦ +----------------------------------------------------------+--------------- ¦ Тип протокола (16 бит) ¦ +----------------------------------------------------------+ ¦ Адресное пространство физической сети (16 бит) ¦ +----------------------------------------------------------+ ¦ Адресное пространство протокола (16 бит) ¦ +---------------------------------------------------+------- ¦ Длина адреса физической сети в байт (8 бит) ¦ +---------------------------------------------------+ ¦ Длина адреса протокола в байт (8 бит) ¦ +---------------------------------------------------+------- ¦ Код операции (16 бит) ¦ +----------------------------------------------------------+ ¦ Физический адрес отправителя пакета (длина переменная) ¦ +----------------------------------------------------------+ ¦ Адрес IP отправителя пакета (длина переменная) ¦ +----------------------------------------------------------+ ¦ Физический адрес получателя пакета (длина переменная) ¦ +----------------------------------------------------------+ ¦ Адрес IP получателя пакета (длина переменная) ¦ ------------------------------------------------------------
Рис. 3.32. Формат пакета ARP (RFC 826)
Для всех типов сетей стандарта IEEE 802 поле Адресное пространство физической сети должно устанавливаться в значение "6".
Поле Тип протокола для передачи пакетов IP должно устанавливаться в значение "2048".
Поле Длина адреса физической сети должно устанавливаться в значение "2" для 16-битовых и "6" для 48-битовых адресов сетей стандарта IEEE 802.
Поле Длина адреса протокола должно устанавливаться в значение "4" для IP (RFC 1042).
3.3.2.2. Передача/прием пакетов ARP в локальной сети стандарта IEEE 802
Пакеты ARP должны передаваться в формате пакета Ненумерованная информация (UI) Уровня логического управления звеном (LLC) типа 1 стандарта IEEE 802.2 с кодом управления 3. Поля заголовка пакета UI в этом случае должны устанавливаться в следующие значения: поля DSAP и SSAP устанавливаются в "170", глобальное значение SAP должно соответствовать SNAP. Установка значений полей пакета для SNAP должна соответствовать RFC 1042.
Минимальный размер пакета UI, переносящего пакет ARP, должен составлять 24 байта.
Максимальный размер пакета UI, переносящего пакет ARP, ограничивается максимальным размером пакета в каждой конкретной сети стандарта IEEE 802.
Возможность принимать пакеты UI, переносящие пакеты ARP, и, при необходимости, фрагментировать их является обязательным требованием к аппаратуре.
3.3.2.3. Передача/прием пакетов ARP в локальной сети стандарта IEEE 802.5 (Token Ring)
Минимальный размер пакета UI, переносящего пакет ARP, для сети стандарта IEEE 802.5 не ограничен.
Максимальный размер пакета UI, переносящего пакет ARP, должен определяться в соответствии со временем удержания маркера на узле.
Для поддержки передачи пакета запроса ARP по физической сети в аппаратуре должна быть реализована процедура обнаружения динамических адресов.
В аппаратуре должны быть реализованы: функция распознавания копий запросов ARP, поступивших от разных источников, и алгоритм исключения запроса из копий.
Не допускается использование групповых и функциональных адресов в пакетах ARP.
Для пакетов UI, содержащих пакеты ARP, приоритет должен устанавливаться по умолчанию (RFC 1042).
3.3.3. Протокол разрешения адресов ARP при передаче пакетов протокола IP по сети в стандарте ISO 9314 (FDDI)
Обработка пакетов протокола ARP по сети в стандарте ISO 9314 регламентируется RFC 1390.
3.3.3.1. Формат пакета протокола ARP
При передаче по локальной сети FDDI формат пакета протокола ARP должен соответствовать формату, предусмотренному для сетей стандарта IEEE 802.
Установка значений полей пакета должна соответствовать предусмотренному для сетей стандарта IEEE 802 за исключением поля Адресное пространство физической сети (для сети FDDI данное поле должно устанавливаться в значение "1").
Порядок инкапсуляции пакетов протокола ARP должен соответствовать RFC 1390.
Суммарная длина заголовка пакета уровня логического управления звеном (LLC) и заголовка протокола SNAP должна составлять 8 байт.
Для передачи пакетов протоколов IP и ARP аппаратура должна обеспечивать использование адресов FDDI только с длиной 6 байт.
Поразрядная интерпретация адресов в пакете ARP для сети FDDI должна осуществляться в обратном порядке в границах каждого байта.
Групповой широковещательный адрес Internet должен отображаться в групповой широковещательный адрес FDDI.
Групповой многоточечный адрес IP должен отображаться в групповой многоточечный адрес FDDI путем размещения 23-х младших битов адреса IP в младшие 23 бита адреса FDDI.
Передача пакетов протокола IP по сети FDDI должна осуществляться в режиме побайтовой поточной передачи.
Отображение адреса Internet (4 байта) в адрес сети FDDI (6 байт) должно осуществляться посредством процедуры обнаружения динамических адресов ARP.
3.3.3.2. Требования к ARP для Уровня управления доступом к среде передачи
Поддержка протоколов IP и ARP в аппаратуре предусматривается только для одиночных станций на уровне Управления доступом к среде передачи (MAC) (с подключением к одиночному или двойному кольцу).
Аппаратура должна поддерживать спецификации Уровня управления доступом к среде передачи сети FDDI (ISO 9314-2).
Аппаратура должна обеспечивать прием пакетов в пределах максимального блока передачи (MTU) сети FDDI и при необходимости их фрагментацию.
В аппаратуре должна обеспечиваться передача пакетов длиной больше 576 байт только в случае подтверждения возможности их приема от получателя.
Для снижения потребления ресурсов сети, затрачиваемых на фрагментацию пакетов на промежуточных узлах, аппаратура должна поддерживать возможность передачи пакетов IP уменьшенной длины.
В аппаратуре должна обеспечиваться передача кадров с пакетами протоколов IP и ARP в виде Асинхронных кадров уровня Логического управления звеном данных (LLC) с использованием маркеров общего вида (Unrestricted tokens).
В аппаратуре должен обеспечиваться порядок кодирования полей кадров на уровне Управления доступом к среде передачи (MAC).
Пакеты Ненумерованная информация с установленным битом Poll должны игнорироваться.
Порядок обработки команд уровня Логического управления звеном данных (LLC) должен соответствовать RFC 1390.
3.4. ТРЕБОВАНИЯ К ПРОЦЕДУРАМ ИНКАПСУЛЯЦИИ ПАКЕТОВ ПРОТОКОЛА IP
3.4.1. Инкапсуляция пакетов протокола IP в пакеты протокола X.25
Требования к процедурам инкапсуляции пакетов IP в пакеты X.25 регламентируются стандартом Internet RFC 1356.
3.4.1.1. Формат пакетов инкапсуляции
Пакет Запрос вызова X.25 (Рис. 5 - 3, Рекомендация МСЭ-Т X.25, 03/93) в поле Данные вызова пользователя должен содержать идентификатор протокола сетевого уровня NLPID (длиной 1 байт), инкапсулируемого по виртуальному каналу X.25.
Для IP данный идентификатор NLPID должен иметь значение "СС" 16-тиричное (RFC 1356, пп. 3.2, 5.1).
Пакет IP переносится в поле блока данных пакета данных X.25. Пакеты посылаются как завершенные последовательности пакетов X.25 (пакет IP выровнен по границам пакета X.25. В случае, когда длина пакета IP превышает размер пакета данных X.25, пакет IP фрагментируется с использованием бита "еще данные" (RFC 1356, пп. 3.1, 5.1).
3.4.1.2. Требования к процедурам инкапсуляции
Инкапсуляция пакетов IP должна выполняться при помощи одного из трех способов:
- пакеты IP могут содержаться в мультиплексированных пакетах данных, передаваемых по каналу с нулевой (мультиплексированной) инкапсуляцией (такие пакеты данных идентифицируются по идентификатору NLPID);
- пакеты IP могут инкапсулироваться при помощи протокола SNAP (пакеты данных идентифицируются по Уникальному административно назначаемому Идентификатору (OUI), содержащемуся в заголовке протокола SNAP (длиной 5 байт) и имеющему значение "000000" 16-тиричное, а также Идентификатору Протокола (PID), имеющему значение "0800" 16-тиричное). Такой способ инкапсуляции также называется "нулевой" инкапсуляцией;
- пакеты IP могут инкапсулироваться по каналу, использующему "нулевую" инкапсуляцию, в мультиплексированные пакеты данных внутри протокола SNAP (RFC 1356, п. 3.4).
В аппаратуре допускается поддержка возможности согласования параметров для X.25 (размер пакета, размер окна).
Взаимосвязь между размером блока данных протокола и размером пакета X.25 исключается (RFC 1356, п. 3.5).
В аппаратуре должна обеспечиваться возможность передачи/приема блоков данных протокола длиной не менее 1600 байт (RFC 1356, п. 3.6).
По умолчанию размер максимального блока передачи (MTU X.25 для пакетов IP должен составлять до 1500 байт, при этом в аппаратуре должна поддерживаться возможность конфигурирования данного MTU (как минимум на уровне интерфейса) в диапазоне от 576 до 1600 байт.
В аппаратуре должна поддерживаться возможность конфигурирования максимальной длины блока данных протокола (PDU) для IP.
Для инкапсуляции пакетов IP между сетями должен поддерживаться отдельный виртуальный канал. Допускается поддержка нескольких виртуальных каналов для единственной инкапсуляции.
Допускается прием нескольких входящих вызовов при одной и той же инкапсуляции от одного узла. При этом должен обеспечиваться прием и последующая передача входящих PDU по дополнительному каналу.
Допускается отвержение дополнительных вызовов одной и той же инкапсуляции с целью снижения нагрузки со сбросом ООД. Не допускается прием входящего вызова только с целью закрыть канал или игнорировать PDU от канала.
Не разрешается применение алгоритмов предотвращения конфликтов между вызовами виртуальных каналов.
Допускается выбор (посредством конфигурации) режима, при котором для одного протокола назначается несколько виртуальных каналов (RFC 1356, п. 3.7).
В аппаратуре должна поддерживаться возможность конфигурации значения минимального тайм-аута для каналов, в течение которого они остаются открытыми пока оконечные узлы находятся в активном состоянии.
Если виртуальный канал в момент приема пакета IP закрывается или сбрасывается, пакет IP пропадает (RFC 1356, п. 3.8).
В аппаратуре должно обеспечиваться использование тайм-аута простоя виртуальных каналов для сброса их активного состояния по истечении тайм-аута. Длительность тайм-аута должна быть конфигурируемой. Рекомендуемое значение тайм-аута для передачи пакетов IP составляет 90 сек.
В аппаратуре должна обеспечиваться реализация конфигурируемой возможности приема вызовов от несконфигурированных адресов вызова (RFC 1356, п. 3.10).
В аппаратуре должен использоваться таймер закрытия канала с переменным значением для предотвращения повторных вызовов к аварийным узлам-получателям (RFC 1356, п. 3.11).
В аппаратуре должен обязательно поддерживаться следующий минимальный перечень процедур X.25:
- установление вызова;
- освобождение вызова;
- передача полных последовательностей пакетов.
Для аппаратуры рекомендуется поддержка следующего перечня процедур протокола X.25:
- расширенная нумерация для последовательностей кадров и/или пакетов;
- управление потоком;
- процедура согласования параметров;
- обратное начисление платы (RFC 1356, п. 3.12).
Не допускается использование следующих процедур X.25:
- прерывание пакетов;
- использование бита Q (индикация ограниченных данных);
- быстрый выбор;
- использование бита D (индикация сквозной значимости) (RFC 1356, п. 3.13).
Для кода диагностики сброса, означающего, что запрошенный протокол не поддерживается, в аппаратуре должно использоваться значение "249" или "0" (RFC 1356, п. 3.14).
В аппаратуре допускается использование способов улучшения функциональных характеристик СДОП, работающих по X.25 (RFC 1356, пп. 4.4, 4.5).
3.4.2. Инкапсуляция пакетов протокола IP в кадры протокола Frame Relay)
Инкапсуляция пакетов протокола IP в кадры протокола Frame Relay регламентируется RFC 1490.
3.4.2.1. Формат кадра
Для пакетов IP, передаваемых по сети Frame Relay, предусматривается два способа инкапсуляции:
- с использованием идентификатора протокола сетевого уровня NLPID, содержащего код протокола IP (формат кадра должен соответствовать RFC 1490, пп. 4.1, 8);
- с использованием идентификатора протокола сетевого уровня NLPID, содержащего код протокола доступа подсети SNAP (формат кадра должен соответствовать RFC 1490, п. 8).
3.4.2.2. Согласование параметров уровня звена данных
Параметры уровня звена данных могут быть назначены по умолчанию, установлены путем конфигурирования или в результате процедуры согласования посредством обмена кадрами Идентификация параметров обмена (XID). На этапе инициирования канала согласованию подлежат следующие параметры:
- максимальный размер кадра,
- таймер повторной передачи,
- максимальное число неподтвержденных информационных кадров (I-кадров) (RFC 1490, п. 5).
Значения данных параметров, задаваемые по умолчанию, должны соответствовать п. 5.9 Рекомендации МСЭ-Т Q.922.
3.4.2.3. Фрагментация
Максимальный размер кадра, передаваемого по сети Frame Relay, составляет 262 байта. Для передачи пакетов IP, длина которых не позволяет инкапсулировать их в один кадр Frame Relay, может применяться процедура фрагментации. Область действия фрагментации определяется границами сети Frame Relay.
Формат и процедура фрагментации должны соответствовать RFC 1490, п. 6.
Фрагменты передаются в порядке, определяемом значением поля сдвига от начала фрагментированного пакета (первый фрагмент имеет сдвиг, равный "0"). При передаче не допускается вставка в последовательность фрагментов, принадлежащих одному пакету, других пакетов или информации, относящихся к тому же соединению звена данных (DLC).
Максимальная величина фрагмента составляет 2 К.
Если при процедуре обратной сборки обнаруживается пропадание или искажение фрагмента, сообщение исключается из обработки и передачи (считается утраченным) (RFC 1490, п. 6).
3.4.2.4. Разрешение адресов
Пакеты протокола разрешения адресов (ARP) инкапсулируются в пакеты Frame Relay с использованием способа инкапсуляции с заголовком протокола SNAP.
Формат пакета ARP при передаче по сети Frame Relay должен соответствовать RFC 1490, п. 7.
В процессе прохождения сети Frame Relay идентификатор соединения звена данных DLCI в заголовке инкапсулированного пакета ARP модифицируется.
Кодирование и обработка полей адреса пакета ARP должно соответствовать RFC 1490, п. 7.
Непосредственное использование групповых адресов IP в среде Frame Relay не регламентируется. Пакет с запросом протокола ARP может копироваться получателем пакета и рассылаться по каждому соответствующему соединению DLC (эмуляция режима широковещательных адресов).
Групповая адресация в среде Frame Relay может быть реализована также посредством протокола обратного разрешения адресов (Inverse ARP) RFC 1490, п. 7.
3.4.3. Инкапсуляция пакетов протокола IP при передаче по сети ATM
Инкапсуляция пакетов протокола IP для передачи по сети ATM регламентируется RFC 1483.
Разрешение адресов при прохождении пакетов IP по сети ATM регламентируется RFC 1577.
3.4.3.1. Мультиплексирование и форматы инкапсуляции
Пакет IP передается в поле блока данных протокола PDU AAL5.
Для пакетов IP, передаваемых по сети ATM, предусматривается два способа инкапсуляции:
- при использовании одного виртуального соединения несколькими протоколами: инкапсуляция с использованием заголовка уровня управления звеном данных LLC и заголовка протокола доступа подсети SNAP для идентификации протокола IP;
- при выделении отдельного соединения виртуального канала каждому протоколу: инкапсуляция без использования заголовков уровня LLC и SNAP (для коммутируемых соединений ATM).
Выбор способа инкапсуляции обуславливается способом мультиплексирования и может быть реализован при конфигурации (для постоянных соединений) или посредством процедур сигнализации B-ISDN (для коммутируемых соединений). Если аппаратура поддерживает работу только по постоянным соединениям, требование к возможности задания способа инкапсуляции при конфигурации является обязательным.
В зависимости от способа мультиплексирования многопротокольной передачи предусматриваются разные форматы инкапсуляции.
Формат блока PDU AAL5 для инкапсуляции с использованием заголовков LLC и SNAP должен соответствовать RFC 1483, п. 4.
Для инкапсуляции пакета IP заголовок LLC содержит значение "AAAA03" 16-тиричное, что соответствует случаю, когда за заголовком LLC следует заголовок SNAP, который идентифицирует протокол.
Заголовок SNAP состоит из поля OUI (длина 2 байта), значение которого устанавливается в "0", и поля EtherType (длина 2 байта), значение которого должно соответствовать протоколу, которому принадлежит пакет.
Для протокола IP предусматривается установка поля EtherType в значение "0800" 16-тиричное, протоколу ARP соответствует "0806" 16-тиричное.
Для коммутируемых сетей ATM блок PDU AAL5 не содержит заголовков LLC и SNAP и состоит только из данных пользователя и концевика.
Максимальная длина пакетов IP (MTU) по умолчанию составляет 9180 байт.
-----+----T--T--T--T--T----------+----------------+---T----+---T------+---¬
¦ AA ¦ AA ¦03¦00¦00¦00¦ETHERTYPYP¦Пакет IP или ARP¦PAD¦ UU ¦CPI¦Length¦CRC¦
+----+----+--+--+--+--+----------+----------------+---+----+---+------+---+
¦<---------->¦<----------------->¦<-------------->¦<--------------------->¦
Заголовок Заголовок SNAP Данные Концевик AAL5
LLC пользователя
PAD - поле дополнения
UU - поле для передачи информации от пользователя к пользователю
CPI - индикатор общей части
Length - длина данных пользователя
CRC - контрольная последовательность
Рис. 3.33. Структура блока данных протокола AAL5 с инкапсуляцией LLC/SNAP при многопротокольном мультиплексировании по одному виртуальному каналу
3.4.3.2. Разрешение адресов
В аппаратуре должна быть реализована поддержка параметров, специфичных для работы в сети ATM (RFC 1577, п. 3).
При работе по постоянным соединениям ATM в качестве протокола разрешения адресов предусматривается использование протокола обратного разрешения адресов InATMARP, регламентируемого RFC 1293.
При работе по коммутируемым соединениям ATM используется протокол ATMARP без поддержки групповых адресов. При работе по коммутируемым соединениям ATM аппаратура должна соответствовать требованиям, предусмотренным в RFC 1577, п. 6.2.
Процедура обмена пакетами протокола разрешения адресов и формирования адресов, реализованная в аппаратуре, должна соответствовать RFC 1577, п. 6.3.
Процедура формирования и обслуживания таблицы адресов, реализованная в аппаратуре, должна соответствовать RFC 1577, п. 6.4.
Формат пакетов ATMARP и InATMARP должен соответствовать RFC 1577, п. 6.6.
Формат инкапсуляции пакетов ATMARP и InATMARP в PDU AAL5 должен соответствовать RFC 1577, п. 6.7.
Организация соединений конфигурации "точка - несколько точек" через сеть ATM регламентируется RFC 2022.
Реализация возможности маршрутизации пакетов IP через несколько сетей ATM регламентируется RFC 2332.
3.5. ТРЕБОВАНИЯ К ИНТЕРФЕЙСАМ
3.5.1. Требования к интерфейсам ATM
3.5.1.1. Требования к функциям интерфейсов ATM
Функции интерфейсов ATM, реализованные в аппаратуре, должны соответствовать "Техническим требованиям на аппаратуру, реализующую Асинхронный режим переноса информации (Аппаратура ATM)", Ред. 1-1998, утвержденным Госкомсвязи Российской Федерации 21 мая 1998 г., п. 3.1.
3.5.1.2. Требования к физическим интерфейсам ATM
В зависимости от используемых средств передачи различают интерфейсы:
- в формате СЦИ, скорости передачи 155520 и 622080 кбит/с;
- с прямой передачей ячеек (cell based) на скоростях 155520 и 622080 кбит/с СЦИ, но без организации СЦИ-цикла;
- в формате ПЦИ, скорости передачи 2048 и 34368 кбит/с;
- для медных физических линий (скорость передачи 25600 кбит/с).
Функции физических интерфейсов разделены между двумя подуровнями:
- физической среды (функции, зависящие от среды передачи);
- конвергенции передачи (функции, определяющие процессы передачи ячеек).
3.5.1.2.1. Интерфейсы в формате СЦИ
Данный раздел определяет параметры физического уровня интерфейсов в формате СЦИ, которые должны соответствовать стандарту ETS 300 300.
Основной средой передачи для данных интерфейсов является оптическое волокно. Однако не исключается применение и существующих (коаксиальных) линий.
3.5.1.2.1.1. Интерфейсы UNI на скорости 155520 кбит/с
3.5.1.2.1.1.1. Функции подуровня физической среды
Интерфейсы должны быть симметричны, т.е. скорость передачи в обоих
направлениях должна быть одинакова и равна 155520 кбит/с (Fт = 155520 кГц).
При работе от собственного генератора относительная нестабильность тактовой
-6
частоты должна быть не хуже +/- 20 x 10 Fт.
Как оптические, так и электрические интерфейсы должны выполнять требования по фазовым дрожаниям выходных сигналов, установленные в Рек. МСЭ-Т G.825.
Фазовые дрожания выходных сигналов интерфейса аппаратуры, имеющей оптические или электрические интерфейсы, отвечающие требованиям Рек. МСЭ-Т G.825 по входным фазовым дрожаниям и G.958 по коэффициенту их передачи, должны соответствовать требованиям Рек. МСЭ-Т G.825.
3.5.1.2.1.1.2. Электрический СЦИ интерфейс 155520 кбит/с
3.5.1.2.1.1.2.1. Среда передачи
В качестве среды передачи используются два коаксиальных кабеля, один для каждого направления передачи. Конфигурация линии - точка-точка.
Импеданс кабеля - 75 Ом +/- 5% в полосе 50 - 200 МГц.
Вносимое затухание тракта передачи на частоте 155520 кГц - не более 20 дБ.
Частотная характеристика затухания - приблизительно.
3.5.1.2.1.1.2.2. Электрические параметры
Электрический сигнал на выходе должен соответствовать табл. 11 и рис. 24 и 25 Рек. G.703 для интерфейса со скоростью передачи 155520 кбит/с.
Электрический сигнал на входе должен соответствовать тем же требованиям с учетом изменений, вносимых коаксиальной линией передачи.
Электрический соединитель интерфейса на стороне аппаратуры, обращенной к пользователю, должен быть типа "гнездо". На стороне, обращенной к сети, соединитель должен быть либо типа "гнездо" (при этом кабель в сторону сети должен оснащаться вилками на обоих концах), либо аппаратура на этой стороне должна иметь встроенный кабель с соединителем типа "вилка".
3.5.1.2.1.1.2.3. Линейный код
В качестве линейного кода должен использоваться код CMI согласно Рек. МСЭ-Т G.703 п. 12.1.
3.5.1.2.1.1.2.4. Электромагнитная совместимость и защищенность от помех
Экранирующие свойства кабелей и соединителей, а также требования к помехозащищенности должны соответствовать стандарту ETS 300 300 п. 7.1.2.6.
3.5.1.2.1.1.3. Оптический СЦИ интерфейс 155520 кбит/с
3.5.1.2.1.1.3.1. Затухание тракта
Затухание оптического тракта должно быть в пределах от 0 до 7 дБ.
3.5.1.2.1.1.3.2. Среда передачи
В качестве среды передачи должны, в соответствии с Рек. МСЭ-Т G.652, использоваться два одномодовых волокна, по одному - для каждого направления передачи.
3.5.1.2.1.1.3.3. Линейный код
В качестве линейного кода должен применяться двоичный код NRZ (без возврата к нулю). При этом излучение света должно соответствовать двоичной единице, отсутствие излучения - двоичному нулю. Коэффициент гашения должен соответствовать Рек. МСЭ-Т G.957, код применения I-1.
3.5.1.2.1.1.3.4. Рабочая волна
Рабочая волна должна быть около 1310 нм (второе окно прозрачности).
3.5.1.2.1.1.3.5. Характеристики входного и выходного портов
Оптические параметры должны соответствовать стандарту ETS 300 232, код применения I-1. При этом оптические соединители должны рассматриваться в качестве составной части аппаратуры (приемника или передатчика), но не оптической линии.
3.5.1.2.1.1.3.6. Оптические соединители
Соединитель интерфейса на стороне аппаратуры, обращенной к пользователю, должен быть типа "гнездо". На стороне, обращенной к сети, соединитель должен быть либо типа "гнездо" (при этом кабель в сторону сети должен оснащаться вилками на обоих концах), либо аппаратура на этой стороне должна иметь встроенный кабель с соединителем типа "вилка".
3.5.1.2.1.1.3.7. Требования безопасности
В любых (даже аварийных) условиях не должны превышаться параметры, установленные в стандарте IEC 825-1, класс 1.
3.5.1.2.1.1.4. Функции подуровня конвергенции передачи
Данные функции должны быть одинаковы для электрического и оптического интерфейсов.
3.5.1.2.1.1.4.1. Транспортные возможности
При скорости передачи на физическом уровне 155520 кбит/с максимальная скорость, доступная для ячеек пользователя, сигнализации и ОАМ ячеек (исключая служебные ячейки физического уровня) составляет 149760 кбит/с.
3.5.1.2.1.1.4.2. Тактовая синхронизация
В нормальном режиме передатчик должен синхронизироваться от сетевого
эталона, частота которого определяет такт принимаемых сигналов на
физическом уровне. В аварийных условиях (при работе от собственного
генератора) относительное отклонение тактовой частоты от номинала
-6
155520 кбит/с не должно быть более +/- 20 - 10 Fт.
3.5.1.2.1.1.4.3. Способ передачи ячеек
Ячейки ATM, структура которых должна соответствовать Рек. МСЭ-Т I.361, должны размещаться в цикле, предусмотренном Рек. МСЭ-Т G.707, с применением стандартного скремблера СЦИ.
При этом, вначале поток ячеек размещается в контейнере C-4, а затем (совместно с байтами заголовка) - в VC-4, причем ячейки согласуются с байтами STM-1. Поскольку емкость C-4 (2340 октетов) не кратна длине ячеек (53 октета), ячейки могут пересекать границу C-4.
Для отыскания первого байта VC-4 используется указатель AU-4 (байты H1 и H2 SOH). Используются байты J1, B3, C2 и G1 трактового заголовка POH.
3.5.1.2.1.1.4.4. Контроль ошибок заголовка
Процедура контроля (HEC) должна охватывать весь заголовок ячейки. Используемый для контроля код должен позволять либо исправлять одиночные ошибки, либо обнаруживать множественные.
Алгоритм контроля рассчитан на характеристики волоконно-оптических линий, в которых, как считается, преобладают одиночные ошибки и сравнительно большие пакеты ошибок. На передаче вычисляется значение поля HEC. Приемник имеет два указанных выше режима работы. По умолчанию должен использоваться режим коррекции одиночных ошибок. При обнаружении ошибки в заголовке ячейки возможны два действия в зависимости от состояния приемника. В режиме коррекции корректируются одиночные ошибки и приемник переключается в режим обнаружения. В режиме обнаружения все ячейки с ошибочными заголовками отбрасываются. При обнаружении безошибочного заголовка ячейка сохраняется и приемник переключается в режим коррекции.
Процедуры вычисления значения поля HEC и контроля должны соответствовать стандарту ETS 300 300 п. 10.3.
3.5.1.2.1.1.4.5. Пустые ячейки
Пустые ячейки должны вставляться на передающем конце для подгонки скорости передачи и отбрасываться на приеме. Эти ячейки должны иметь стандартные заголовки, указанные в стандарте ETS 300 300 п. 10.4.
3.5.1.2.1.1.4.6. Определение границ и скремблирование информационных полей ячеек
Определение границ ATM ячеек (аналог цикловой синхронизации систем с STM) должно выполняться с помощью поля HEC. При этом, для повышения помехозащищенности и надежности механизма определения границ ячеек производится скремблирование их информационных полей, что, кроме того, способствует повышению качества передачи ячеек. Эти операции должны выполняться в соответствии с стандартом ETS 300 300 п. 10.5.
3.5.1.2.1.1.5. Функции ОАМ
Функции ОАМ - передача и прием сигналов обслуживания (AIS и RDI), контроль качественных показателей должны соответствовать Рек. МСЭ-Т 1.610.
3.5.1.2.1.1.5.1. Назначение байтов заголовков СЦИ
В секционном заголовке SOH используются байты A1, A2, J0, B1 (при наличии регенераторов), B2, H1, H2, H3, K2 (биты 6 - 8) и M1 (биты 2 - 8). В заголовке POH тракта используются байты J1, B3, C2, G1 (Биты 1 - 4 для REI-счета ошибок и бит 5 для сигнала RDI). Распределение байтов по функциям должно отвечать табл. 3 стандарта ETS 300 300. Процедуры использования этих байтов и порядок счета байтов и битов должны соответствовать положениям СЦИ в соответствии с Рек. МСЭ-Т G.709.
3.5.1.2.1.1.5.2. Сигналы обслуживания
Сигнал индикации аварийного состояния (СИАС - AIS) должен посылаться в направлении передачи для оповещения оконечного пункта о том, что повреждение обнаружено и отмечено сигнализацией.
Сигнал индикации о повреждении с дальнего конца (СИПДК - RDI) должен посылаться для оповещения оконечного пункта в противоположном передаче направлении о том, что в тракте обнаружено повреждение. Этот же сигнал должен использоваться и для индикации потери границ ячеек.
Процедуры генерирования и обнаружения сигналов AIS и RDI должны соответствовать положениям СЦИ, определенным в Рек. МСЭ-Т G.709.
3.5.1.2.1.1.5.3. Контроль качества передачи
Контроль качества передачи должен выполняться путем наблюдения за цифровыми ошибками в СЦИ секциях и трактах, что соответствует потокам обслуживания F2 и F3 соответственно. На уровне секций используется байт B2, результат вычисления на дальнем конце вводится в байт Z2 и в качестве сигнала REI (индикация ошибок на дальнем конце) посылается обратно на передающий конец.
Аналогично на уровне трактов используется байт B3, результат вычисления ошибок вводится в байт G1 (биты 1 - 4) и передается как REI на ближний конец.
Для контроля секции регенерации (поток F1) используется байт B1. Этот контроль не обязателен и вводится только при наличии регенераторов.
Процедуры контроля качества должны соответствовать положениям СЦИ, определенным в Рек. МСЭ-Т G.709.
3.5.1.2.1.1.6. Оперативные функции
3.5.1.2.1.1.6.1. Интерфейсные сигналы
Интерфейс должен поддерживать следующие сигналы, используемые для оперативных функций.
3.5.1.2.1.1.6.1.1. Сигналы, определенные в Рек. МСЭ-Т I.610
В функциональном оборудовании должны генерироваться сигналы:
- LOS - потеря сигнала;
- LOF - потеря цикловой синхронизации;
- LOP - потеря указателя;
- MS-AIS - СИАС мультиплексной секции STM-1;
- P-AIS - СИАС тракта VC-4;
- MS-RDI - Индикация о Повреждении с Дальнего конца мультиплексной секции;
- P-RDI - Индикация о Повреждении с Дальнего конца тракта.
3.5.1.2.1.1.6.1.2. Сигналы о состоянии определения границ ячеек:
OCD - сбой в определении границ ячеек;
LCD - потеря границ ячеек.
3.5.1.2.1.1.6.2. Контроль состояний интерфейса
Пользовательская и сетевая стороны интерфейса должны информировать друг друга о текущих состояниях физического уровня в связи с различными дефектами, которые могут быть обнаружены. Эти состояния должны соответствовать перечням, приведенным в п. 12.2.1 (состояния F пользовательской стороны) и п. 12.2.2 (состояния G сетевой стороны) стандарта ETS 300 300 и определениям таблиц состояний в п. 12.2.4 того же стандарта.
Обе стороны интерфейса должны обмениваться информацией об аварийных состояниях (которые могут возникнуть на сетевой стороне или между сетевой и пользовательской стороной) в форме сигналов, указанных выше в п. 3.4.1.2.1.4.1.
3.5.1.2.1.1.6.2.1. Перечень примитивов
Перечень примитивов, которыми обмениваются физический уровень и устройства обслуживания, должен соответствовать стандарту ETS 300 300 п. 12.2.3.
3.5.1.2.1.2. Интерфейсы UNI на скорости 622080 кбит/с
3.5.1.2.1.2.1. Функции подуровня физической среды
Возможны применения двух вариантов данного интерфейса:
а) асимметричный - со скоростью передачи в одном направлении 622080 кбит/с и 155520 кбит/с в другом;
б) симметричный - со скоростью передачи 622080 кбит/с в обоих направлениях.
Для варианта а) компоненты, относящиеся к скорости 155520 кбит/с, должны иметь характеристики, отвечающие п. 3.4.1.2.1.
На скорости 622080 кбит/с рекомендуются только оптические интерфейсы. При этом:
При работе от собственного генератора нестабильность тактовой частоты
-6
должна быть не хуже +/- 20 x 10 Fт.
Интерфейсы должны выполнять требования по фазовым дрожаниям выходных сигналов, установленные в Рек. МСЭ-Т G.825.
В этом случае принимается, что аппаратура, имеющая интерфейсы, отвечающие требованиям Рек. МСЭ-Т G.825 по входным фазовым дрожаниям и G.958 по коэффициенту их передачи, обеспечивает нормальную работу, если фазовые дрожания выходных сигналов интерфейса соответствуют требованиям Рек. МСЭ-Т G.825.
3.5.1.2.1.2.1.1. Затухание тракта
Затухание оптического тракта должно быть в пределах от 0 до 7 дБ.
3.5.1.2.1.2.1.2. Среда передачи
В качестве среды передачи должны использоваться два одномодовых волокна, соответствующие требованиям Рек. МСЭ-Т G.652, по одному волокну для каждого направления передачи.
3.5.1.2.1.2.1.3. Линейный код
В качестве линейного кода должен применяться двоичный код NRZ (без возврата к нулю). При этом, излучение света соответствует двоичной единице, отсутствие излучения - двоичному нулю. Коэффициент гашения должен соответствовать Рек. МСЭ-Т G.957, код применения I-4.
3.5.1.2.1.2.1.4. Рабочая волна
Рабочая волна должна быть около 1310 нм (второе окно прозрачности).
3.5.1.2.1.2.1.5. Характеристики входного и выходного портов
Оптические параметры должны соответствовать стандарту ETS 300 232, код применения I-4. При этом, оптические соединители должны рассматриваться в качестве составной части аппаратуры (приемника или передатчика), но не оптической линии.
3.5.1.2.1.2.1.6. Оптические соединители
Соединитель интерфейса на стороне аппаратуры, обращенной к пользователю, должен быть типа "гнездо". На стороне, обращенной к сети, соединитель должен быть либо типа "гнездо" (при этом кабель в сторону сети должен оснащаться вилками на обоих концах), либо аппаратура на этой стороне должна иметь встроенный кабель, с соединителем типа "вилка".
3.5.1.2.1.2.1.7. Требования безопасности
В любых (даже аварийных) условиях не должны превышаться значения параметров, установленные в стандарте EEC 825-1, класс 1.
3.5.1.2.1.2.2. Функции подуровня конвергенции передачи
3.5.1.2.1.2.2.1. Транспортные возможности
При скорости передачи на физическом уровне 622080 кбит/с максимальная скорость, доступная для ячеек пользователя, сигнализации и ОАМ ячеек (исключая служебные ячейки физического уровня) должна составлять 599040 кбит/с.
3.5.1.2.1.2.2.2. Тактовая синхронизация
В нормальном режиме передатчик должен синхронизироваться от сетевого
эталона, частота которого определяет такт принимаемых сигналов на
физическом уровне. В аварийных условиях (при работе от собственного
генератора) относительное отклонение тактовой частоты от номинала
-6
622080 кбит/с не должно быть более +/- 20 x 10 Fт.
3.5.1.2.1.2.2.3. Способ передачи ячеек
Ячейки ATM, структура которых должна соответствовать Рек. МСЭ-Т I.361, должны размещаться в предусмотренной Рек. МСЭ-Т G.707 структуре AU-4-4c с применением стандартного скремблера СЦИ.
При этом, вначале поток ячеек размещается в C-4-4c, а затем (совместно с байтами заголовка) - в сцепке виртуальных контейнеров VC-4-4c, причем ячейки согласуются с байтами сцепки. Поскольку емкость C-4-4c (9360 октетов) не кратна длине ячеек (53 октета), ячейки могут пересекать границу C-4-4c.
Для отыскания первого байта VC-4-4c используются указатели AU. Используются байты J1, B3, C2 и G1 трактового заголовка POH.
Нижеследующие функции интерфейса 622080 кбит/с аналогичны функциям интерфейса 155520 кбит/с.
3.5.1.2.1.2.2.4. Контроль ошибок заголовка - см. п. 3.5.1.2.1.1.4.4
3.5.1.2.1.2.2.5. Пустые ячейки - см. п. 3.5.1.2.1.1.4.5
3.5.1.2.1.2.2.6. Определение границ и скремблирование информационных полей ячеек - см. п. 3.5.1.2.1.1.4.6
3.5.1.2.1.2.3. Функции ОАМ - см. п. 3.5.1.2.1.1.5
3.5.1.2.1.2.3.1. Назначение байтов заголовков СЦИ - см. п. 3.5.1.2.1.1.5.1
3.5.1.2.1.2.3.2. Сигналы обслуживания - см. п. 3.5.1.2.1.1.5.2
3.5.1.2.1.2.3.3. Контроль качества передачи - см. п. 3.5.1.2.1.1.5.3
3.5.1.2.1.2.4. Оперативные функции - см. п. 3.5.1.2.1.1.6
3.5.1.2.1.2.4.1. Интерфейсные сигналы - см. п. 3.5.1.2.1.1.6.1
3.5.1.2.1.2.4.1.1. Сигналы, определенные в Рек. 1.610 - см. п. 3.5.1.2.1.1.6.1.1
3.5.1.2.1.2.4.1.2. Сигналы о состоянии определения границ ячеек - см. п. 3.5.1.2.1.1.6.1.2
3.5.1.2.1.2.4.2. Контроль состояний интерфейса - см. п. 3.5.1.2.1.1.6.2
3.5.1.2.1.2.4.2.1. Перечень примитивов - см. п. 3.5.1.2.1.1.6.2.1
3.5.1.2.2. Интерфейсы с прямой передачей ячеек на скоростях СЦИ
Данный раздел определяет параметры физического уровня интерфейсов с прямой передачей ячеек на скоростях СЦИ, но без организации СЦИ-циклов. Указанные параметры должны соответствовать стандарту ETS 300 299.
При этом предполагается, что основной средой передачи для данных интерфейсов является оптическое волокно. Однако не исключается применение и существующих (коаксиальных) линий.
3.5.1.2.2.1. Интерфейсы UNI на скорости 155520 кбит/с
3.5.1.2.2.1.1. Функции подуровня физической среды
Интерфейсы должны быть симметричны, т.е. скорости передачи в обоих направлениях одинаковы и равны 155520 кбит/с. При работе от собственного генератора стабильность тактовой частоты должна быть не хуже +/- 20 x -6 10 Fт.
При этом возможно использование как оптических, так и электрических интерфейсов - в зависимости от требуемой дальности связи и местных условий.
3.5.1.2.2.1.1.1. Электрический интерфейс 155520 кбит/с
3.5.1.2.2.1.1.1.1. Возможности использования
Дальность связи зависит от затухания используемой среды передачи. Например, для микрокоаксиального кабеля диаметром 4 мм она равна 100 м, для кабеля диаметром 7 мм - 200 м.
3.5.1.2.2.1.1.1.2. Среда передачи
В качестве среды передачи должны использоваться два коаксиальных кабеля, по одному для каждого направления передачи. Конфигурация линии - точка-точка.
Импеданс кабеля - 75 Ом +/- 5% в полосе 50 - 200 МГц.
Вносимое затухание тракта передачи на частоте 155520 кГц - не более 20 дБ.
_
Частотная характеристика затухания - приблизительно \/F.
3.5.1.2.2.1.1.1.3. Электрические параметры
Электрический сигнал на выходе должен соответствовать табл. 11 и рис. 24 и 25 Рек. МСЭ-Т G.703 для интерфейса со скоростью передачи 155520 кбит/с.
Электрический сигнал на входе должен соответствовать тем же требованиям с учетом изменений, вносимых коаксиальной линией передачи.
Электрический соединитель интерфейса на стороне аппаратуры, обращенной к пользователю, должен быть типа "гнездо". На стороне, обращенной к сети, соединитель должен быть либо типа "гнездо" (при этом кабель в сторону сети должен оснащаться вилками на обоих концах), либо аппаратура на этой стороне должна иметь встроенный кабель с соединителем типа "вилка".
3.5.1.2.2.1.1.1.4. Линейный код
В качестве линейного кода должен использоваться код CMI согласно Рек. МСЭ-Т G.703, п. 12.1.
3.5.1.2.2.1.1.1.5. Электромагнитная совместимость и защищенность от помех
Экранирующие свойства кабелей и соединителей, а также требования к помехозащищенности должны соответствовать стандарту ETS 300 299 п. 7.1.2.6.
3.5.1.2.2.1.1.2. Оптический интерфейс 155520 кбит/с
3.5.1.2.2.1.1.2.1. Затухание тракта
Затухание оптического тракта должно быть в пределах от 0 до 7 дБ.
3.5.1.2.2.1.1.2.2. Среда передачи
В качестве среды передачи должны использоваться два одномодовых волокна, характеристики которого соответствуют Рек. МСЭ-Т G.652, по одному - для каждого направления передачи.
3.5.1.2.2.1.1.2.3. Линейный код
В качестве линейного кода должен применяться двоичный код NRZ (без возврата к нулю). При этом, излучение света соответствует двоичной единице, отсутствие излучения - двоичному нулю. Коэффициент гашения должен соответствовать Рек. МСЭ-Т G.957, код применения I-1.
3.5.1.2.2.1.1.2.4. Рабочая волна
Рабочая волна должна быть около 1310 нм (второе окно прозрачности).
3.5.1.2.2.1.1.2.5. Характеристики входного и выходного портов
Оптические параметры должны соответствовать Рек. МСЭ-Т G.957, код применения I-1.
При этом оптические соединители должны рассматриваться в качестве составной части аппаратуры (приемника или передатчика), но не оптической линии.
3.5.1.2.2.1.1.2.6. Оптические соединители
Соединитель интерфейса на стороне аппаратуры, обращенной к пользователю, должен быть типа "гнездо". На стороне, обращенной к сети, соединитель должен быть либо типа "гнездо" (при этом кабель в сторону сети должен оснащаться вилками на обоих концах), либо аппаратура на этой стороне должна иметь встроенный кабель с соединителем типа "вилка".
3.5.1.2.2.1.1.2.7. Требования безопасности
В любых (даже аварийных) условиях не должны превышаться значения параметров, установленные в стандарте IEC 825-1, класс 1.
3.5.1.2.2.1.2. Функции подуровня конвергенции передачи
Данные функции должны быть одинаковы для электрического и оптического интерфейсов.
3.5.1.2.2.1.2.1. Транспортные возможности
При скорости передачи на физическом уровне 155520 кбит/с максимальная скорость, доступная для ячеек пользователя, сигнализации и ОАМ ячеек (исключая служебные ячейки физического уровня) должна составлять 149760 кбит/с.
3.5.1.2.2.1.2.2. Тактовая синхронизация
Комментарии
Комментирование через социальные сервисы Facebook и Вконтакте:
Федеральное