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

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

РЕДАКЦИЯ 1-1998

    
    
    СОГЛАСОВАНЫ Начальником УЭС Госкомсвязи России А.Ю.Рокотяном 06.08.1998 г.
    
    УТВЕРЖДЕНЫ Первым заместителем Председателя Госкомсвязи России Н.С.Мардер 06.08.1998 г.
    
    Заместителем генерального директора ЦНИИС Ю.И.Филюшиным     
    
    ВНЕСЕНО Изменение N 1 (РД 45.038-99), утвержденное Министерством Российской Федерации по связи и информатизации, введенное в действие с 15.04.2002
    

    Изменение N 1 внесено юридическим бюро

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

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

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

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

    
    2.1. Аппаратура передачи пакетов IP должна быть реализована в соответствии с функциональными требованиями к межсетевой передаче пакетов в сетях IP, определенными в стандарте Internet RFC 1126 и стеком протоколов IP, определенным в стандартах Internet RFC 1122 и RFC 1123.
    
    2.2. Аппаратура маршрутизации пакетов IP классифицируется в зависимости от области применения (назначения) и набора поддерживаемых функций.
    
    2.3. В зависимости от области применения различают аппаратуру внутрисетевой маршрутизации и аппаратуру межсетевой маршрутизации.
    
    2.4. Аппаратура внутрисетевой маршрутизации подразделяется на:
    
     маршрутизаторы локальных сетей
    
     узловые маршрутизаторы
    
     маршрутизаторы доступа
    
    Аппаратура межсетевой маршрутизации подразделяется на:
    
     магистральные маршрутизаторы
    
     шлюзы.
    
    2.5. Маршрутизаторы локальных сетей предназначены для маршрутизации нагрузки внутри локальных сетей и для обеспечения взаимодействия с удаленными локальными сетями.
    
    Узловые маршрутизаторы предназначены для использования в корпоративных сетях, а также на местных сетях передачи данных.
    
    Маршрутизаторы доступа предназначены для использования в корпоративных сетях и сетях передачи данных для организации доступа абонентов через телефонную сеть общего пользования или ISDN.
    
    Магистральные маршрутизаторы используются при построении транспортных сетей для передачи информации IP.
    
    Шлюзы используются для организации межсетевого взаимодействия, включая взаимодействие сетей различного типа (IP, X.25 и т.д.).
    
    Маршрутизаторы указанных типов различаются производительностью, числом портов и набором поддерживаемых протоколов.
    
    2.6. В зависимости от набора поддерживаемых функций различают:
    
     маршрутизаторы;
    
     комбинированные маршрутизаторы.
    
    В первом случае аппаратура выполняет только функции маршрутизации сообщений/пакетов для неориентированных на соединение протоколов передачи.
    
    Аппаратура может иметь последовательный или параллельный интерфейс ООД/АКД или интерфейсы локальных сетей (Ethernet, Token Ring и т.д.).
    
    В сетях передачи данных и транспортных сетях такая аппаратура может использоваться только совместно с оборудованием передачи данных других типов, например, с коммутаторами пакетов/кадров X.25/Frame Relay или виртуальных соединений ATM.
    
    2.8. Комбинированный маршрутизатор совмещает в себе функции маршрутизации пакетов IP и других не ориентированных на соединение протоколов с функциями коммутации или мультиплексирования пакетов/кадров X.25/Frame Relay или виртуальных соединений ATM.
    
    В качестве физических интерфейсов аппаратура может иметь
    
     последовательный/параллельный интерфейс ООД/АКД
    
     интерфейс локальной сети
    
     интерфейс ПЦИ (Е1, Е3)
    
     интерфейс BRI/PRI ISDN
    
     интерфейс СЦИ (STM1, STM4)
    
    В ряде случаев комбинированный маршрутизатор может включать групповые и одиночные модемы для работы по аналоговым линиям связи.
    
    2.9. Аппаратура маршрутизации пакетов IP может устанавливаться как на объектах связи ВСС РФ, так и в помещениях пользователей.
    
    

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

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

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

    Требования к реализации протокола IP регламентируются стандартом Internet RFC 791, где определяются правила кодирования, форматы и функции управления передачей пакетов.
    
    Реализация функций данного протокола является обязательной для аппаратуры маршрутизации пакетов IP.
    
    3.1.1.1 Форматы пакетов протокола IP
    
    Формат пакета протокола IP и кодирование его полей должны соответствовать RFC 791 п.3.1. При этом должна поддерживаться минимальная длина заголовка пакета 20 байт и максимальная длина пакета 65535 байт.
    
    Формат заголовка пакета IP и перечень поддерживаемых полей должен соответствовать следующей таблице:
    
    

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

    
    
    3.1.1.2 Требования к функциям кодирования/декодирования полей заголовка пакета IP
    
    3.1.1.2.1 Поле "Версия"
    
    Поле "Версия" должно содержать номер версии формата заголовка пакета IP. Аппаратура должна поддерживать все версии по 4 включительно.
    
    3.1.1.2.2 Поле "Длина заголовка "
    
    Поле Длина заголовка должно содержать значение длины заголовка пакета в словах (1 слово - 32 бита).
    
    3.1.1.2.3 Поле "Тип обслуживания"
    
    Поле должно содержать код набора параметров качества обслуживания:
    
     приоритетность;
    
     задержка;
    
     пропускная способность;
    
     надежность.
    
    Кодирование поля "Тип обслуживания" должно выполняться в соответствии со следующими правилами:
    
    

    
    
    Кодирование разрядов приоритетности должно осуществляться в соответствии с RFC 791 п.3.1.
    
    В случае, если аппаратура не поддерживает управление приоритетом передачи пакетов, значения разрядов 0-2 должно игнорироваться.
    
    3.1.1.2.4 Поле "Длина пакета IP"
    
    Поле должно содержать значение длины пакета IP в байтах, включая заголовок и данные. Возможность обрабатывать пакеты длиной менее 576 байт является обязательным требованием к маршрутизаторам пакетов IP; в отдельных случаях допускается длина пакета до 65535 байт.
    
    3.1.1.2.5 Поле "Идентификатор пакета"
    
    Поле "идентификатора пакета" должно использоваться процедурой фрагментации при сборке/разборке пакета для определения последовательности передаваемых фрагментов.
    
    3.1.1.2.6 Поле "Флаги"
    
    Поле должно использоваться процедурой фрагментации для управления последовательностью сборки фрагментов пакета. Кодирование разрядов поля должно осуществляться в соответствии со следующими правилами:
    
    

    
    
    3.1.1.2.7 Поле "Смещение фрагмента"
    
    Поле должно использоваться для указания смещения данного фрагмента относительно первого фрагмента в блоках фрагментации (8 байт). Для первого фрагмента смещение устанавливается в "0".
    
    3.1.1.2.8 Поле "Счетчик допустимого времени пребывания пакета в сети"
    
    Поле должно содержать текущее значение счетчика максимально допустимого времени пребывания пакета в сети в секундах. Если в поле находится значение "0", пакет должен быть удален.
    
    3.1.1.2.9 Поле "Тип протокола следующего уровня"
    
    Поле должно содержать стандартизированный код протокола следующего уровня в соответствии с RFC 1340.
    
    3.1.1.2.10 Поле "Контрольная последовательность заголовка" (КПЗ)
    
    Поле должно содержать контрольную последовательность заголовка. При любом изменении содержания заголовка КПЗ должно пересчитываться. Формирование КПЗ должно осуществляться в соответствии с RFC 791 п.3.1.
    
    3.1.1.2.11 Поле "Адрес источника пакета"
    
    Кодирование поля "Адрес источника пакета" должно соответствовать требованиям RFC 791 п.3.2.
    
    3.1.1.2.12 Поле "Адрес получателя пакета"
    
    Кодирование поля "Адрес получателя пакета" должно соответствовать требованиям RFC 791 п.3.2.
    
    3.1.1.2.13 Поле "Режим обработки пакета"
    
    Кодирование и форматы данного поля должны соответствовать RFC 791 п.3.1.
    
    Число режимов в каждом пакете не ограничивается.
    
    Должны поддерживаться два способа кодирования поля режимов:
    
    1) поле длиной 1 байт,
    
    2) комбинация трех подполей:
    
     тип режима (1 байт);
    
     счетчик длины поля режима (1 байт);
    
     данные режима (переменная длина).
    
    Подполе типа режима должно включать:
    
     флаг (1 бит);
    
     класс режима (2 бита);
    
     номер режима (5 бит).
    
    При установке бита флага в значение "1" аппаратура должна копировать данное поле при фрагментации что данная функция при фрагментации копируется во все фрагменты, в значение "0" - не копируется.
    
    Установка битов класса режима должно соответствовать следующим значениям:
    
     "0" - управление;
    
     "1" - зарезервировано;
    
     "2" - отладка и измерение;
    
     "3" - зарезервировано.
    
    3.1.1.2.14 Поле дополнения до границы заголовка
    
    Для выравнивания границы заголовка по длине, кратной 32 бит, свободные позиции должны быть заполнены нулевыми битами.
    
    3.1.1.3 Режимы обработки пакета IP
    
    Состав режимов должен соответствовать RFC 791 п.3.1.
    
    В аппаратуре должна быть предусмотрена поддержка следующих классов режимов:     
    

    
    
    3.1.1.3.1 Режим "Конец списка режимов"
    
    Тип режима: 0.
    
    Предназначен для использования указателем конца списка режимов, может совпадать с концом заголовка пакета IР. Допускается копирование, внесение и удаление данного режима при фрагментации.
    
    3.1.1.3.2 Режим "Нет действий"
    
    Тип режима: 1.
    
    Предназначен для выравнивания смежных полей режимов по границе слова (32 бит), может находиться в любом месте списка режимов. Допускается копирование, внесение и удаление данного режима при фрагментации.
    
    3.1.1.3.3 Режим "Свободная маршрутизация от источника и записанный маршрут"
    
    Тип режима: 131.
    
    Предназначен для передачи данных источника пакета IР о маршруте, которые должны быть использованы аппаратурой транзитного узла для направления пакета к получателю и записи данных о маршруте.
    
    

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

    
    
    Кодирование полей: Тип режима должен быть установлен в двоичное значение "10000011".
    
    Поле счетчика длины поля режима должно содержать значение переменной длины данного поля в байт.
    
    Поле Указатель должно содержать порядковый номер байта, начиная с которого в поле данных о маршруте находится адрес источника пакета. Наименьшее допустимое значение поля указателя "4".
    
    Данные о маршруте должны состоять из последовательности адресов, каждый длиной 4 байта.
    
    Если значение указателя превышает значение длины поля режима, данные о маршруте от источника должны считаться отсутствующими (записанный маршрут исчерпан) и маршрутизация должна осуществляться по значению поля адреса получателя пакета.
    
    Если адрес в поле получателя пакета достигнут, и поле указателя содержит значение, не превышающее длину поля режима, следующий адрес в маршруте от источника должен заменить адрес в поле адреса получателя, и адрес записанного маршрута должен заменить последний использованный адрес источника; значение поля указателя должно увеличиваться на 4.
    
    Аппаратура должна обеспечивать неизменность длины пакета IP в процессе замены адресов маршрута.
    
    Копирование данного режима при фрагментации обязательно; не допускается наличие более одного поля данного режима в пакете.
    
    3.1.1.3.4 Режим "Строгая маршрутизация от источника и записанный маршрут"
    
    Тип режима: 137.
    
    Предназначен для передачи данных источника пакета IP о маршруте, которые должны быть использованы аппаратурой транзитного узла для направления пакета к получателю и записи данных о маршруте.
    

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

    
    
    Кодирование полей: Тип режима должен быть установлен в двоичное значение "10001001".
    
    Поле счетчика длины поля режима должно содержать значение переменной длины данного поля в байт.
    
    Поле Указатель должно содержать порядковый номер байта, начиная с которого в поле данных о маршруте находится адрес источника пакета, который подлежит обработке. Наименьшее допустимое значение поля указателя "4".
    
    Данные о маршруте должны состоять из последовательности адресов, каждый длиной 4 байта.
    
    Если значение указателя превышает значение длины поля режима, данные о маршруте от источника должны считаться отсутствующими (записанный маршрут исчерпан) и маршрутизация должна осуществляться по значению поля адреса получателя пакета.
    
    Если адрес в поле получателя пакета достигнут, и поле указателя содержит значение, не превышающее длину поля режима, следующий адрес в маршруте от источника должен заменить адрес в поле адреса получателя, и адрес из записанного маршрута должен заменить адрес источника, использованный последним; значение поля указателя должно увеличиваться на 4.
    
    Аппаратура должна обеспечивать неизменность длины пакета IP в процессе замены адресов маршрута.
    
    Аппаратура должна обеспечивать посылку пакета строго по следующему адресу маршрута от источника.
    
    Копирование данного режима при фрагментации обязательно; не допускается наличие более одного поля данного режима в пакете.
    
    3.1.1.3.5 Режим "Записанный маршрут"
    
    Тип режима: 7.
    
    Предназначен для записи маршрута пакета.
    
    Формат поля режима "Записанный маршрут" аналогичен форматам полей функций "Свободная маршрутизация от источника и записанный маршрут" и "Строгая маршрутизация от источника и записанный маршрут".
    
    Кодирование полей: поле Тип режима должно быть установлено в двоичное значение "00000111". Указатель должен содержать номер байта, начиная с которого должен записываться очередной адрес.
    
    Кодирование остальных полей должно выполняться аналогично кодированию данных полей для режимов "Свободная маршрутизация от источника и записанный маршрут" и "Строгая маршрутизация от источника и записанный маршрут".
    
    Поле данных о маршруте предназначено для записи последовательности адресов узлов, проходимых пакетом. Длина поля данных о маршруте должна быть достаточной для регистрации всех адресов маршрута.
    

    Аппаратура должна обеспечивать неизменность длины пакета IP в процессе замены адресов маршрута.
    
    Начальное значение поля данных должно быть нулевым.
    
    Аппаратура должна обеспечивать запись адреса узла, начиная с байта, указанного в поле указателя при наличии поля данного режима в пакете. Значение указателя должно увеличиваться на 4.
    
    Если аппаратура получает пакет с заполненным полем данных о маршруте, дальнейшая запись не производится. Если свободного поля недостаточно для записи полного адреса, пакет должен считаться пораженным ошибкой и исключаться аппаратурой из обработки и передачи; по адресу источника пакета должна обеспечиваться посылка сообщения протокола ICMP "Некорректные параметры обмена".
    
    При фрагментации поле данного режима копированию не подлежит; не допускается наличие более одного поля данного режима в пакете.
    
    3.1.1.3.6 Режим "Идентификатор потока"
    
    Тип режима: 136.
    
    Предназначен для идентификации принадлежности пакета к потоку в сетях, поддерживающих способы передачи потоков.
    
    Поле режима "Идентификатор потока" состоит из двух подполей каждое длиной 2 байта.
    
    Кодирование полей: первые два байта должны быть установлены в двоичное значение"1000100000000010".
    
    Вторые два байта должны содержать идентификатор потока.
    
    При фрагментации подлежит обязательному копированию; не допускается наличие более одного поля данного режима в пакете.
    
    3.1.1.3.7 Режим "Отметка времени"
    
    Тип режима: 68.
    
    Предназначен для контроля времени прохождения пакетом узлов сети.
    

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

    
    
    Кодирование полей: Тип режима должен быть установлен в двоичное значение "01000100".
    
    Максимальное значение счетчика длины поля режима - 40 байт.
    
    Поле Указатель должно содержать число байт от начала поля режима до конца последней отметки времени плюс 1. Наименьшее допустимое значение указателя "5".
    
    Поле отметок времени должно считаться заполненным, когда значение указателя превышает значение счетчика длины поля режима.
    
    Поле Переполнение должно содержать число узлов, пройденных пакетом до приема аппаратурой, на которых отметка времени не была выполнена из-за отсутствия свободного места в поле отметок.
    
    Для поля флага, в соответствии с режимом заполнения поля отметок, должны поддерживаться следующие значения:
    
    "0" - только отметки времени, записываемые в последовательных 4-х-байтовых словах,
    
    "1" - каждая отметка времени записывается вместе с адресом узла, на котором она выполнена,
    
    "3" - поля адресов заполняются заранее на предшествующих узлах. При прохождении соответствующего узла на нем выполняется только заполнение поля отметки времени по собственному адресу, и проставляется адрес следующего узла.
    
    Отметка времени должна формироваться аппаратурой в миллисекундах и записываться в 4-х-байтовых словах. Отсчет времени должен выполняться от полуночи по универсальному скоординированному времени.
    
    Для аппаратуры допускается отсчет времени в нестандартных единицах и от нестандартного источника. Для индикации такого отсчета старший бит поля отметки времени должен быть установлен в значение "1".
    
    Аппаратура должна обеспечивать неизменность длины пакета IP в процессе внесения отметок времени в поле пакета.
    
    Начальное значение поля отметок времени должны составлять нули или пары полей, состоящие из адреса узла маршрута и нулевого поля отметки времени.
    
    При заполнении поля отметок времени, если значение указателя превышает длину поля режима, пакет должен обрабатываться аппаратурой без внесения отметок времени, с увеличением значения поля Переполнение на 1.
    
    Если свободного поля недостаточно для записи отметки времени полностью, или превышена разрядность поля Переполнение, аппаратура должна считать пакет пораженным ошибкой и исключать его из обработки и передачи; в аппаратуре должна обеспечиваться посылка сообщения протокола ICMP "Некорректные параметры обмена" по адресу источника пакета.
    
    При фрагментации поле данного режима копированию не подлежит; не допускается наличие более одного поля данного режима в пакете.
    
    3.1.1.4 Процедуры протокола IP
    
    В протоколе IР должны быть реализованы две обязательные основные процедуры - адресация и фрагментация. Данные для этих процедур содержатся в заголовке пакета.
    
    3.1.1.4.1 Процедура адресации
    
    Аппаратура должна поддерживать предусмотренную в протоколе IР адресацию для сетей трех классов в соответствии со следующими форматами:     
    

    
    
    Не допускается нулевое значение в поле адреса сети для межсетевой маршрутизации (RFC 791 п.3.2.).
    
    3.1.1.4.2 Процедура фрагментации
    
    В случае, если пакет IP подлежит передаче без фрагментации, аппаратура должна установить поля Флаги и Смещение фрагментации в его заголовке в значение "0".
    
    Если пакет IP подлежит фрагментации, аппаратура должна разделять поле данных пакета на фрагменты с выравниванием по длине блока фрагментации (8 байт). Заголовок пакета процедуре фрагментации не подвергается.
    
    Фрагментация пакетов длиной 68 байт и менее не допускается.
    
    При фрагментации копирование полей режимов из заголовка пакета выполняется только для полей, для которых это предусмотрено в RFC 791, в противном случае поле режима сохраняется только в первом фрагменте пакета.
    
    Следующие поля заголовка пакета могут подвергаться обработке при фрагментации:
    
     поле режимов;
    
     поле флагов;
    
     смещение фрагмента;
    
     длина заголовка;
    
     длина пакета;
    
     контрольная последовательность заголовка.
    
    В случае, когда в заголовке пакета выставлен флаг, запрещающий его фрагментацию, пакет может быть исключен из процесса передачи. Установка данного флага предусматривается, когда ресурсы на приеме не позволяют поддерживать процедуру обратной сборки пакета (RFC 791 п.3.2.).
    
    3.1.1.4.3 Обработка ошибок
    
    В протоколе IP не реализованы поддержка защиты от ошибок при передаче пакета, квитирование передачи, как сквозное, так и транзитное, управление потоком, а также повторная передача пакетов. Контрольная последовательность предусматривается только для поля заголовка пакета.
    
    Обнаружение ошибок должно быть реализовано средствами протокола управления (ICMP).
         
    

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

    
    Назначением протокола ICMP является формирование и управление передачей сообщений об ошибках при обработке пакетов IP, а также сообщений о состоянии узлов сети.
    
    Протокол управления сообщениями ICMP является неотъемлемой частью протокола IP (RFC 792) и реализация его функций является обязательной для аппаратуры маршрутизации пакетов IP.
    
    Требования к протоколу ICMP регламентируются стандартами Internet RFC 792 и RFC 1256.
    
    3.1.2.1 Форматы сообщений ICMP
    
    Аппаратура должна передавать сообщения ICMP в поле данных пакета IP. При этом значение первого байта поля данных пакета IР должно указывать на тип сообщения ICMP.
    
    Кодирование полей заголовка пакета IP для сообщения ICMP должно осуществляться в соответствии со следующей таблицей:  
       
    

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

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

    
    
    3.1.2.2 Сообщения протокола ICMP об ошибках в пакетах IP
    
    3.1.2.2.1 Сообщение "получатель недоступен"
    
    Аппаратура должна формировать сообщение "Получатель недоступен" (Destination Unreachable Message) и отправлять его по адресу отправителя в случае, если:
    
     недоступен адрес получателя;
    
     недоступен порт в требуемом направлении передачи;
    
     не поддерживается требуемый стек протоколов;
    
     невозможна передача пакета без фрагментации при установленном флаге запрета фрагментации.
    
    Кодирование поля сообщения Destination Unreachable Message должно осуществляться в соответствии со следующей таблицей
    
    

    
    
    3.1.2.2.2 Сообщение "время пребывания пакета IP в сети истекло"
    
    Аппаратура должна формировать сообщение "время пребывания пакета IP в сети истекло" (Time Exceeded Message - ТЕМ) в следующих случаях:
    
     При обнаружении, что поле "время пребывания пакета в сети" в данном пакете содержит нулевое значение;
    
     При обнаружении, что заданное время пребывания данного пакета в сети истекает прежде окончания сборки его фрагментов.
    
    Сообщение должно передаваться по адресу источника данного пакета.
    
    Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:
    
    

    
    
    3.1.2.2.3 Сообщение "Проблемы в параметрах"
    
    Аппаратура должна формировать сообщение "Проблемы в параметрах" (Parameter Problem Message - РРМ), если значения параметров заголовка пакета IP не позволяют завершить его корректную обработку.
    
    Сообщение должно передаваться по адресу источника данного пакета, при этом первый байт поля "не используется" в заголовке сообщения ICMP должен содержать указатель, идентифицирующий байт заголовка пакета IP (порядковый номер байта), содержание которого привело к возникновению проблем.
    
    Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:
    
    

    
    
    3.1.2.2.4 Сообщение "Подавление источника"
    
    Аппаратура должна формировать сообщение "Подавление источника" (Source Quench Message - SQM) в случае невозможности обработки принимаемых пакетов по причинам:
    
     переполнения буферной памяти;
    
     высокой интенсивности поступления пакетов.
    
    Сообщение должно передаваться по адресу источника удаляемого из обработки пакета.
    
    Допускается формирование сообщения "подавление источника" для каждого удаленного из обработки пакета.
    
    В случае приема сообщения "подавление источника" аппаратура должна уменьшить интенсивность передачи пакетов.
    
    Кодирование полей сообщения должно осуществляться в соответствии со следующей таблицей:
    
    

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

    
    
    Аппаратура не должна формировать сообщение "перенаправление" для пакетов, в заголовке которых указаны функции маршрутизации от узла-отправителя и адрес шлюза в поле адреса получателя, даже если этот маршрут неоптимален (RFC 792).
    
    3.1.2.3 Сообщения ICMP о состоянии узлов сети
    
    3.1.2.3.1 Сообщения "запрос эхо/отклик эхо"
    
    Аппаратура должна формировать сообщение "запрос эхо" (Echo) по инициативе системы административного управления.
    
    При получении сообщения "запрос эхо" аппаратура должна сформировать ответное сообщение "отклик эхо" (Echo Reply Message - EoERM).
    
    

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

    
    Значение поля Тип сообщения должно быть установлено в "8" для "запроса эхо" и в "0" для "отклика эхо".
    
    Поле данных, принятое в сообщении "запрос эхо" должно быть послано обратно в сообщении "отклик эхо" без изменений.
    
    Поля Идентификатор и Порядковый номер являются параметрами для отслеживания соответствия многократной посылки сообщений и получения откликов.
    
    Поле кода сообщения должно быть установлено в значение "0".
    
    3.1.2.3.2 Сообщения "Отметка времени/Отклик на отметку времени"
    
    Аппаратура должна формировать сообщения "Отметка времени/Отклик на отметку времени" (Timestamp/Timestamp Reply Message ToTRM) по инициативе системы административного управления.
    

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

    
    
    Кодирование сообщений должно осуществляться в соответствии с форматом, приведенном на рисунке и следующими правилами:
    
    Поля Идентификатор и Порядковый номер должны использоваться параметрами для отслеживания соответствия многократной посылки сообщения и получения откликов.
    
    Значение поля Тип сообщения устанавливается в "13" для сообщения "отметка времени" и в "14" для сообщения "отклик на отметку времени".
    
    Поле кода сообщения должно устанавливаться в "0".
    
    В поле "Отметка исходного времени" должен фиксироваться момент времени, когда отправитель завершил формирование данного сообщения для его отправки.
    
    В поле "Отметка времени приема" должен фиксироваться момент времени, когда получатель принял сообщение, но еще не приступил к его обработке.
    
    В поле "Отметка времени передачи" должен фиксироваться момент времени, когда получатель завершил обработку сообщения для его возврата.
    
    3.1.2.3.3 Сообщения "Информационный запрос/Ответ на информационный запрос"
    
    Аппаратура должна формировать сообщения "Информационный запрос/Ответ на информационный запрос" (Information Request or Information Reply Message - IRoIRM) пo инициативе системы административного управления для определения номера сети.
    

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

    
    Кодирование полей сообщений Information Request и Information Reply Message должно осуществляться в соответствии с форматом, приведенным на рисунке, и следующим правилам:
    
    Поля Идентификатор и Порядковый номер должны использоваться для отслеживания соответствия многократной посылки информационных запросов и получения откликов.
    
    Значение поля Тип сообщения должно устанавливаться в "15" для информационного запроса Information Request Message и в "16" для отклика на информационный запрос Information Reply Message.
    
    Поле кода сообщения должно устанавливаться в значение "0".
    
    Сообщение Information Request Message может быть отправлено с установкой адреса отправителя в заголовке пакета IP, но с нулевым значением адреса получателя. В ответном сообщении Information Reply Message поля адресов должны быть полностью определены.
    
    3.1.2.3.4 Сообщение "Объявление маршрутизатора"
    
    Аппаратура должна формировать сообщение "Объявление маршрутизатора" (Router Advertisement Message) по инициативе системы административного управления.
    
    Кодирование полей сообщения Router Advertisement Message должно осуществляться в соответствии с форматом, представленном на рисунке, и следующими правилами:
    
    В поле "адрес отправителя пакета" заголовка пакета IP, в котором передается сообщение Router Advertisement Message, должен содержаться адрес IP, принадлежащий интерфейсу, от которого отправлено сообщение.
    
    В поле "адрес получателя пакета" заголовка пакета IP, в котором передается сообщение Router Advertisement Message, содержится адрес IP смежного узла или специально задаваемый адрес AdvertisementAddress.
    

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

    
    
    В поле "Счетчик допустимого времени пребывания пакета IP в сети" устанавливается значение 1 с, если в поле "Адрес получателя" задан групповой адрес вещания IР (IР multicast) или не менее 1 с в остальных случаях.
    
    Значение поля "Тип сообщения" в заголовке пакета ICMP устанавливается в "9", поле "Код" устанавливается в значение "0".
    
    Правило подсчета контрольной последовательности должно соответствовать RFC 1256.
    
    Поле "Число адресов" маршрутизатора должно соответствовать числу адресов, объявляемых в данном сообщении.
    
    Поле "Размер входа адреса" содержит число 32-х-битовых слов информации для каждого адреса маршрутизатора (данный параметр зависит от версии протокола ICMP).
    
    Поле "Срок действия адресов" содержит максимальное время в секундах, в течение которого адреса маршрутизатора могут считаться действительными.
    
    Поле "Адрес маршрутизатора" содержит адрес IP отправляющего маршрутизатора на -м интерфейсе, от которого отправляется данное сообщение (Число адресов).
    
    Поле "Уровень предпочтения" содержит адрес маршрутизатора, который должен использоваться по умолчанию и является предпочтительным по отношению к другим адресам маршрутизатора в одной и той же подсети.
    
    3.1.2.3.5 Сообщение "Запрос маршрутизатора"
    
    Аппаратура должна формировать сообщение "Запрос маршрутизатора" (Router Solicitation Message) по инициации системы административного управления
         

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

    
    Поля сообщения Router Solicitation Message:
    
    В поле "адрес отправителя пакета" заголовка пакета IP, в котором передается сообщение Router Solicitation Message, содержится адрес IP, принадлежащий интерфейсу, от которого отправлено сообщение, или нулевое значение.
    
    В поле "адрес получателя пакета" заголовка пакета IP, в котором передается сообщение Router Solicitation Message, содержится специально задаваемый адрес SoIicitationAddress.
    
    В поле "Счетчик допустимого времени пребывания пакета IP в сети" устанавливается значение 1 с, если в поле "Адрес получателя" задан групповой адрес вещания IP (IP multicast) или не менее 1 с в остальных случаях.
    
    Значение поля "Тип сообщения" в заголовке пакета ICMP устанавливается в "10", поле "Код" устанавливается в значение "0".
    
    Правило подсчета контрольной последовательности должно соответствовать RFC 1256.
    
    Поле "Зарезервировано" устанавливается "0" и игнорируется при приеме сообщения.
    
    

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

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

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

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

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

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

    
    
    3.2.1.2 Процедура инициирования сеанса со смежным узлом
    
    3.2.1.2.1 Формат сообщения процедуры Neighbor Acquisition (тип сообщения 3)
    
    Формат сообщения процедуры Neighbor Acquisition и коды состояния должны соответствовать RFC 904 Приложение A.1:
    

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

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

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

    
    
    3.2.1.3 Процедура взаимодействия со смежным узлом
    
    3.2.1.3.1 Формат сообщения процедуры Neighbor Reachability (тип сообщения 5)
    
    Формат сообщения процедуры Neighbor Reachability должен соответствовать RFC 904, Приложение А.2:
    
    

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

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

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

    
    
    Сообщения приветствия Hello должны посылаться регулярно через интервал, определенный в сообщении процедуры инициирования сеанса Neighbor Acquisition (RFC 904, п.2).
    
    Сообщение поддержки сеанса I-H-Y должны посылаться в ответ на сообщение приветствия Hello (RFC 904 п.2).
    
    3.2.1.4 Процедура взаимодействия с сетью Network Reachability
    
    3.2.1.4.1 Сообщение опроса "Poll" (тип сообщения 2)
    
    Формат сообщения опроса Poll процедуры Network Reachability должен соответствовать RFC 904, Приложение А.3:
    
    

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

    
    
    Префикс (номер) сети-источника сообщения может состоять из 1 (для сети типа А), 2 (для сети типа В) или 3 (для сети типа С) байт. Незначащие разряды слева должны дополняться нулями.
    
    Сообщение опроса Poll посылается регулярно через интервал, определенный в сообщении процедуры инициирования сеанса Neighbor Acquisition (RFC 904, п.4).
    
    Опрос узла с интервалом менее 2 мин не допускается (RFC 904, п.3.2).
    
    В случае неприема ответного сообщения обновления информации маршрутизации Update на сообщение опроса Poll посылается повторное сообщение опроса с тем же порядковым номером (RFC 904, п.4.4.).
    
    Допускается посылка только одного незапрошенного сообщения обновления данных маршрутизации Update между последующими командами опроса Poll, принимаемыми от смежного узла (RFC 904, п.4.4.).
    
    При приеме сообщения Poll маршрутизатор должен выполнять одно из следующих действий:
    
     посылка сообщения Update, если в течение интервала опроса это первое сообщение опроса,
    
     повторная посылка сообщения Update (незапрошенное сообщение Update),
    
     посылка сообщения об ошибке,
    
     игнорирование сообщения Poll (RFC 904, п.4.4.).
    
    3.2.1.4.2 Сообщение обновления информации маршрутизации "Update" (тип сообщения 1)
    

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

    
    
    Информация о доступности сетей должна кодироваться в сообщениях обновления информации маршрутизации Update в форме списка сетей и шлюзов.
    
    Формат сообщения обновления информации маршрутизации UPDATE должен соответствовать RFC 904, Приложение А.4.
    
    Сообщение Update может содержать два списка шлюзов. Оба списка включают в себя только шлюзы, напрямую соединяющиеся с сетью, адрес IP которой указан в последнем принятом сообщении опроса.
    
    Внутренний список содержит некоторые или все адреса шлюзов в одной и той же сети (автономной системе) в качестве посылающих информацию о доступности, вместе с номерами сетей, доступными через эти шлюзы; первым в списке должен стоять адрес шлюза, который посылает сообщение.
    
    Внешний список содержит адреса шлюзов в другой сети (автономной системе), известных посылающему шлюзу.
    
    Только шлюзы, принадлежащие сети-получателю, могут содержать внешний список в сообщениях Update (RFC 904, п.4.4.).
    
    При кодировании сообщения Update могут указываться следующие типы состояний (RFC 904, Приложение А.4):
    
    

    
    
    3.2.1.5 Сообщение об ошибке "Error" (тип сообщения 8)
    
    3.2.1.5.1 Формат сообщения Error
    
    Формат сообщения Error протокола EGP должен соответствовать RFC 904, Приложение А.5:
    

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

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

    
    
    Сообщение Error посылается после приема другого сообщения (команды или ответа) с неверным форматом, содержимым или порядком следования. Сообщение Error не посылается в ответ на другое сообщение Error. Получение сообщения Error само по себе не должно приводить к изменению состояния (RFC 904, п.4.5).
    
    Условия определения ошибочной ситуации приведены в RFC 904, Приложение.А.5.
    
    3.2.1.6 Процедуры и функции EGP
    
    Аппаратура должна поддерживать следующие функции протокола EGP:
    
     функции управления переменными состояния (RFC 904, п.4.1),
    
     инициации и завершения процедур протокола (RFC 904, п.4.2),
    
     алгоритма определения доступности смежного узла (RFC 904, п.4.3),
    
     алгоритма определения доступности сетей (RFC 904, п.4.4),
    
     процедур обработки сообщений об ошибке (RFC 904, п.4.5).
         
    

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

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

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

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

    
    
    3.2.2.2 Сообщения BGP-1
    
    Минимальная длина сообщения BGP-1 составляет 8 байт (сообщение состоит из заголовка), максимальная длина - 1024 байт (RFC 1105, п.3).
    
    3.2.2.2.1 Формат сообщения инициирования сеанса "OPEN"
    
    Формат сообщения OPEN должен соответствовать RFC 1105, п.3.2.:
    

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

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

    
    
    3.2.2.2.2 Формат сообщения подтверждения установления сеанса "OPEN CONFIRM"
    
    Сообщение OPEN CONFIRM состоит только из заголовка (код типа сообщения 5) без поля данных (RFC 1105, п.3.3.).
    
    Сообщение OPEN CONFIRM посылается в ответ на посланное сообщение инициирования сеанса OPEN (RFC 1105, п.3.3).
    
    3.2.2.2.3 Формат сообщения обновления данных маршрутизации "UPDATE"
    
    Формат сообщения UPDATE должен соответствовать RFC 1105, п.3.4.
    

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

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

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

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

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

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

    
    
    3.2.2.2.5 Формат сообщения поддержки сеанса "KEEPALIVE"
    
    Сообщение KEEPALIVE должно состоять только из заголовка (код типа сообщения 4) без поля данных (RFC 1105, п.3.5.).
    
    Обмен сообщениями KEEPALIVE между взаимодействующими узлами должен осуществляться до истечения тайм-аута, задаваемого в заголовке сообщений. Минимальный интервал обмена сообщениями KEEPALIVE должен быть не менее 1/3 тайм-аута.
    
    По истечении тайм-аута сеанс BGP-1 завершается (RFC 1105, п.3.5.).
    
    3.2.2.3 Процедуры и функции BGP-1
    
    Для аппаратуры, поддерживающей BGP-1, должны быть реализованы следующие процедуры:
    
     установка кода аутентификации (RFC 1105, п.3.1.);
    
     идентификация, обработка и формирование списка кодов ошибок для сообщения NOTIFICATION (RFC 1105, п.3.5);
    
     процедура обработки ошибок заголовка сообщений (RFC 1105, п.3.1);
    
     процедура обработки ошибок сообщений OPEN и OPEN CONFIRM (RFC 1105, п.3.2);
    
     процедура обработки ошибок сообщения UPDATE (RFC 1105, п.3.4, 5);
    
     поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1105, п.4);
    
     процедура обработки завершения сеанса (RFC 1105, п.4).
         
    

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

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

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

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

    
    
    3.2.3.2 Сообщения BGP-2
    
    Минимальная длина сообщения BGP-2 составляет 19 байт (сообщение состоит из заголовка), максимальная длина - 4096 байт (RFC 1163, п.4).
    
    3.2.3.2.1 Формат сообщения инициирования сеанса "OPEN"
    
    Формат сообщения OPEN должен соответствовать RFC 1163, п.4.2:
    
    

_______________
    * Брак оригинала. - Примечание .     

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

    
    
    Структура и значения полей сообщения OPEN должны соответствовать RFC 1163, п.4.2.
    
    Поля кода аутентификации и данных аутентификации должны быть установлены в нулевое значение. Допускается использование ненулевого значения полей кода и данных аутентификации при использовании механизма аутентификации (RFC 1105, п.4.2).
    
    3.2.3.2.2 Формат сообщения обновления данных маршрутизации "UPDATE"
    
    Формат сообщения UPDATE должен соответствовать RFC 1163, п.4.3:
    
    Значение поля Длина поля Атрибуты пути соответствует суммарной длине данного поля переменной длины в байт. Данное значение должно составлять целое неотрицательное число полей Номер сети IP.
    
    Каждое поле Атрибут пути имеет переменную длину и состоит из трех частей (подполей):
    
     тип атрибута,
    
     длина атрибута,
    
     значение атрибута.
    

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

    
    
    Не допускается использование атрибута в одном и том же сообщении UPDATE больше одного раза (RFC 1163, п.5).
    
    Тип атрибута (длина подполя 2 байта), в свою очередь, состоит из:
    
     поля флагов атрибута (старший байт),
    
     поля кода типа атрибута (младший байт).
    
    Кодирование поля флагов атрибута должно осуществляться в соответствии со следующими правилами (RFC 1163, п.4.3):
    
     бит 0 (старший) в поле флагов атрибута предназначен для индикации, является ли атрибут обязательным (значение "1" - обязательный, значение "0" - необязательный);
    
     бит 1 в поле флагов атрибута определяет, является ли необязательный атрибут транзитивным (значение "1" - является, значение "0" - не является). Для обязательного атрибута данный бит всегда установлен в значение "1" (транзитивные атрибуты должны пропускаться через узел без обработки);
    
     бит 2 в поле флагов атрибута определяет, может ли информация, содержащаяся в необязательном транзитивном атрибуте, быть разделена на части (значение "1" - разбиение допускается, значение "0" - не допускается), для обязательных атрибутов и необязательных нетранзитивных атрибутов данный бит всегда должен устанавливаться в значение "0";
    
     бит 3 в поле флагов атрибута определяет длину атрибута в байт (значение "1" - 2 байта, значение "0" - 1 байт), длина атрибута в 2 байта допускается только в случае, когда длина значения атрибута превышает 255 байт;
    
     биты 4-7 в поле флагов атрибута не используются и устанавливаются в нулевое значение.
    
    Соответствие поля кода типа атрибута, длины атрибута и значения (категории) атрибута приведено в следующей таблице:
    
    

    
    
    ORIGIN - определяет источник информации о пути. В поле данных могут находиться следующие значения:
    
    0 - сеть (сети) является внутренней по отношению к источнику (сети) (передача по протоколу IGP),
    
    1 - сеть (сети) является внешней по отношению к источнику (сети) (передача по протоколу EGP),
    
    2 - не регламентируется.
    
    AS_PATH - (автономные системы), через которые необходимо пройти до сетей, перечисляемых в сообщении UPDATE.
    
    NEXT_HOP - адрес IP пограничного узла маршрутизации, который должен быть задействован в качестве транзитного к сетям, перечисляемым в сообщении UPDATE. Пограничный узел маршрутизации должен принадлежать той же сети, что и узел, обменивающийся по протоколу BGP-2 и посылающий данные о ее доступности.
    
    INREACHABLE - используется для уведомления узла маршрутизации BGP-2 о том, что сведения о ранее заявленных маршрутах устарели.
    
    INTER-AS METRIC - может быть использован на внешних звеньях для различия между несколькими точками входа/выхода в одну и ту же смежную сеть. Значением атрибута является целое двухбайтовое число, называемое метрикой. При приеме по внешнему звену данный атрибут может быть распространен по внутренним звеньям сети к другим узлам маршрутизации BGP-2 в рамках сети. Данный атрибут не должен pacпространяться к другим узлам маршрутизации BGP-2 в смежной сети.
    
    Если бит 3 в поле флагов атрибута установлен в 0, третий байт атрибута пути содержит длину данных атрибута в байт, если в 1 - длину данных атрибута в байт содержат третий и четвертый байты.
    
    Остальные байты атрибута пути содержат значение атрибута и интерпретируются в соответствии с флагами атрибута и кодом типа атрибута.
    
    Значения атрибута должны соответствовать RFC 1163, п.5.
    
    Номер сети IP, состоящий из четырех байт, идентифицирует сеть, описываемую с помощью атрибутов пути и участвующую в межсетевой маршрутизации. Не допускается использовать номера подсетей и базовых узлов. Общее число полей Номер сети IР в сообщении UPDATE определяется по формуле:
    

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

    
    Результат расчета по данной формуле должен приводить к целому неотрицательному числу полей Номер сети IP.
    
    Минимальная длина сообщения UPDATE, включая заголовок, составляет 37 байт (RFC1163, п.4.3.).
    
    3.2.3.2.3 Формат сообщения уведомления "NOTIFICATION"
    
    Сообщение уведомления посылается при обнаружении ошибки. Сразу же после посылки данного сообщения сеанс межсетевого обмена протокола завершается.
    
    Формат сообщения NOTIFICATION должен соответствовать RFC 1163, п.4.5.:
    

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

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

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

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

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

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

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

    
    Минимальная длина сообщения уведомления составляет 21 байт, включая заголовок (RFC 1163, п.4.3.).
    
    3.2.3.2.4 Формат сообщения поддержки сеанса "KEEPALIVE"
    
    Сообщение KEEPALIVE состоит только из заголовка длиной 19 байт (код типа сообщения 4) без поля данных (RFC 1163, п.4.4.).
    
    Обмен сообщениями KEEPALIVE между взаимодействующими узлами должен осуществляться до истечении тайм-аута, задаваемого в сообщении инициирования сеанса OPEN. Максимальный интервал обмена сообщениями KEEPALIVE должен быть не менее 1/3 тайм-аута.
    
    По истечении тайм-аута сеанс BGP-2 завершается (RFC 1163, п.4.4.).
    
    3.2.3.3 Процедуры и обработка ошибок BGP-2
    
    В соответствии с RFC 1163, для аппаратуры, поддерживающей протокол BGP-2, должны быть реализованы следующие процедуры:
    
     установка кода аутентификации (RFC 1163, п.4.2);
    
     процедура согласования версии протокола (RFC 1163, п.7);
    
     идентификация, обработка и формирование списка кодов ошибок для сообщения NOTIFICATION (RFC 1163, п.4.5, 6.4);
    
     обработки ошибок заголовка сообщений протокола BGP-2 (RFC 1163, п.6.1);
    
     процедура формирования списка атрибутов пути (RFC 1163, п.5);
    
     процедура обработки сообщений обновления данных маршрутизации (RFC 1163, п.6.3);
    
     поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1163, п.6.5, 6.6);
    
     процедура обработки завершения сеанса (RFC 1163, п.6.7).
         
    

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

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

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

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

    
    
    3.2.4.2 Сообщения BGP-3
    
    Аппаратура должна поддерживать требования к длине сообщения протокола (минимальная длина - 19 байт (сообщение состоит только из заголовка), максимальная длина - 4096 байт), и требования к форматам сообщений (RFC 1267, п.4).
    
    3.2.4.2.1 Сообщение инициирования сеанса "OPEN"
    
    Формат сообщения OPEN должен соответствовать RFC 1267, п.4.2.
    

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

    
    
    Структура и значения полей сообщения OPEN должны соответствовать RFC 1267 п.4.2.
    
    Поля кода аутентификации и данных аутентификации должны быть установлены в нулевое значение. Допускается использование ненулевого значения полей кода и данных аутентификации при использовании механизма аутентификации (RFC 1267 п.4.2).
    
    Аппаратура должна осуществлять посылку сообщения OPEN для инициирования сеанса протокола BGP-3.
    
    При приеме сообщения OPEN аппаратурой должен инициироваться счетчик тайм-аута и начать выполняться генерация и посылка сообщений KEEPALIVE.
    
    3.2.4.2.2 Сообщение обновления данных маршрутизации "UPDAТЕ "
    
    Формат сообщения UPDATE должен соответствовать RFC 1267, п.4.3.
    
    

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

    
    
    Поле Атрибуты пути является обязательным для сообщения UPDATE. Последовательность атрибутов пути должна состоять из трех подполей:
    
     тип атрибута,
    
     длина атрибута,
    
     значение атрибута.
    
    Тип атрибута (длина подполя 2 байта), в свою очередь ….. состоять из:
    
     поля флагов атрибута (старший байт),
    
     поля кода типа атрибута (младший байт).
    
    Кодирование поля флагов атрибута должно осуществляться в соответствии со следующими правилами (RFC 1267, п.4.3):
    
     бит 0 (старший) в поле флагов атрибута предназначен для индикации обязательности атрибута: (значение "1" - обязательный, значение "0" - необязательный);
    
     бит 1 в поле флагов атрибута предназначен для индикации транзитивности необязательного атрибута (значение "1" - является транзитивным, значение "0" - не является транзитивным). Для обязательного атрибута данный бит должен быть всегда установлен в значение "1" (транзитивные атрибуты должны пропускаться аппаратурой без обработки);
    
     значение бита 2 в поле флагов атрибута должно соответствовать возможности разбиения информации, содержащейся в необязательном транзитивном атрибуте (значение "1" - разбиение допускается, значение "0" - не допускается), для обязательных атрибутов и необязательных нетранзитивных атрибутов данный бит всегда должен устанавливаться в значение "0";
    
     значение бита 3 в поле флагов атрибута должно соответствовать длине атрибута в байт (значение "1" - 2 байта, значение "0" - 1 байт); длина атрибута в 2 байта допускается только в случае, когда длина значения атрибута превышает 255 байт;
    
     биты 4-7 в поле флагов атрибута не используются и должны устанавливаться в нулевое значение.
    
    Если бит 3 в поле флагов атрибута установлен в значение "0", длину данных атрибута в байт должен содержать третий байт Атрибута пути, если в "1" - третий и четвертый байты.
    
    Третье подполе поля Атрибута пути должно содержать значение атрибута и интерпретироваться в соответствии с Флагами атрибута и Кодом типа атрибута.
    
    Значения (категория) атрибута должны соответствовать RFC 1267, п.5.
    
    

    
    
    Атрибут ORIGIN должен использоваться для определения источника информации о пути. В поле данных атрибута могут находиться следующие значения:
    
    0 - сеть является внутренней по отношению к источнику пакета,
    
    1 - сеть является внешней по отношению к источнику пакета,
    
    2 - не регламентируется.
    
    Атрибут AS_PATH должен использоваться для хранения перечня путей, проходимых пакетом, до сетей, перечисляемых в сообщении UPDATE.
    
    Атрибут NEXT_HOP должен использоваться для определения адреса пограничного узла маршрутизации, который должен быть задействован в качестве транзитного к сетям, перечисляемым в сообщении UPDATE.
    
    Атрибут INREACHABLE должен использоваться для уведомления узла маршрутизации протокола BGP-3 о том, что сведения о ранее заявленных маршрутах устарели.
    
    Значение атрибута INTER-AS METRIC должно быть целым двухбайтовым числом.
    
    Каждое поле Сеть в сообщении UPDATE должно идентифицировать сеть, описываемую с помощью атрибутов пути и участвующую в межсетевой маршрутизации: поле должно содержать номер сети, состоящий из четырех байт. Не допускается использовать номера подсетей и базовых узлов. Общее число полей Сеть в сообщении UPDATE должно соответствовать формуле:
    
    Длина сообщения = 19 + суммарная длина атрибутов пути + 4 х номер сети.
    
    Результат расчета по данной формуле должен приводить к целому неотрицательному числу полей Сеть.
    
    Минимальная длина сообщения UPDATE, включая заголовок, должна составлять 37 байт (RFC 1267, п.4.3.).
    
    Генерация и посылка сообщения UPDATE должна осуществляться аппаратурой при обновлении данных маршрутизации.
    
    При приеме сообщения UPDATE счетчик тайм-аута в аппаратуре должен быть обнулен.
    
    3.2.4.2.3 Сообщение поддержки сеанса "KEEPALIVE"
    
    Сообщение KEEPALIVE должно состоять из заголовка длиной 19 байт (код типа сообщения 4) без поля данных (RFC 1267, п.4.4.).
    
    В целях поддержки сеанса BGP-3 при отсутствии обмена другими сообщениями аппаратурой должна осуществляться периодическая генерация и передача сообщения KEEPALIVE до истечения тайм-аута, задаваемого в сообщении инициирования сеанса OPEN. В аппаратуре должен поддерживаться максимальный интервал посылки сообщений KEEPALIVE длительностью не менее 1/3 тайм-аута.
    
    При приеме сообщения KEEPALIVE счетчик тайм-аута в аппаратуре должен быть обнулен.
    

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

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

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

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

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

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

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

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

    
    Минимальная длина сообщения уведомления должна составлять 21 байт, включая заголовок (RFC 1267, п.4.3.).
    
    Генерация и посылка сообщения уведомления с кодом и субкодом, соответствующими данному типу ошибок, должна обеспечиваться в аппаратуре при обнаружении ошибки. Сразу же после посылки данного сообщения аппаратура должна обеспечивать завершение сеанса BGP-3.
    
    3.2.4.3 Процедуры и обработка ошибок BGP-3
    
    В соответствии с RFC 1267, в аппаратуре должны быть реализованы следующие процедуры:
    
     процедуры обработки ошибок (RFC 1267, п.6);
    
     установка кода аутентификации (RFC 1267, п.4.2);
    
     процедура согласования версии протокола (RFC 1267, п.7);
    
     идентификация, обработка и формирование списка кодов ошибок для сообщения NOTIFICATION (RFC 1267, п.6.4);
    
     процедура формирования списка атрибутов пути (RFC 1267, п.5);
    
     процедура обработки сообщений обновления данных маршрутизации (RFC 1267, п.6.3);
    
     поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1267, п.6.5);
    
     процедура обработки завершения сеанса (RFC 1267, п.6.7);
    
     процедура обнаружения конфликта сеансов (RFC 1267, п.6.8);
    
     процедура обнаружения противоречий между стратегиями маршрутизации автономных систем (RFC 1267, п.10);
    
     процедура настройки периодичности выбора маршрута (RFC 1267, п.А.5.5).
    
    Все таймеры, реализованные в аппаратуре для поддержки BGP-3, должны быть конфигурируемы (RFC 1267 п.А.5.4).
         
    

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

    
    Для BGP-4 допускается использование равнозначного названия Протокол бесклассовой межрегиональной маршрутизации CIDR.
    
    Инициирование сеанса BGP-4 аппаратурой допускается при условиях, предусмотренных в RFC 1771, п.2.
    
    3.2.5.1 Формат заголовка и типы сообщений BGP-4
    
    Для всех типов сообщений BGP-4 формат заголовка должен соответствовать RFC 1771, п.4.1.:
    

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

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

    
    
    3.2.5.2 Сообщения BGP-4
    
    Аппаратура должна поддерживать требования к длине сообщения протокола (минимальная длина - 19 байт (сообщение состоит только из заголовка), максимальная длина - 4096 байт), и требования к форматам сообщений (RFC 1771, п.4).
    
    3.2.5.2.1 Сообщение инициирования сеанса "OPEN"
    
    Формат сообщения OPEN должен соответствовать RFC 1771, п.4.2.
    

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

    
    
    Структура и значения полей сообщения OPEN должны соответствовать RFC 1771, п.4.2.
    
    3.2.5.2.2 Сообщение обновления данных маршрутизации "UPDATE"
    
    Формат сообщения UPDATE должен соответствовать RFC 1771, п.4.3:
    

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

    
    
    Структура и значения полей сообщения UPDATE должны соответствовать RFC 1771, п.4.3.
    
    3.2.5.2.3 Сообщение поддержки сеанса " KEEPALIVE"
    
    Сообщение KEEPALIVE должно состоять из заголовка длиной 19 байт (код типа сообщения 4) без поля данных (RFC 1771, п.4.4.).
    
    В целях поддержки сеанса BGP-4 при отсутствии обмена другими сообщениями аппаратурой должна осуществляться периодическая генерация и передача сообщения KEEPALIVE до истечения тайм-аута, задаваемого в сообщении инициирования сеанса OPEN. В аппаратуре должен поддерживаться максимальный интервал посылки сообщений KEEPALIVE длительностью не менее 1/3 тайм-аута.
    
    При приеме сообщения KEEPALIVE счетчик тайм-аута в аппаратуре должен быть обнулен.
    
    При неприеме каких-либо сообщений по истечении заданного тайм-аута аппаратура должна обеспечивать завершение сеанса BGP-4 (RFC 1771, п.4.4.).
    
    3.2.5.2.4 Сообщение уведомления "NOTIFICATION"
    
    Формат сообщения NOTIFICATION должен соответствовать RFC 1771, п.4.5.
    
    

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

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

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

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

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

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

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

    
    Минимальная длина сообщения уведомления должна составлять 21 байт, включая заголовок (RFC 1771, п.4.5.).
    
    Генерация и посылка сообщения уведомления с кодом и субкодом, соответствующими данному типу ошибок, должна обеспечиваться в аппаратуре при обнаружении ошибки. Сразу же после посылки данного сообщения аппаратура должна обеспечивать завершение сеанса ВGР-4.
    
    3.2.5.3 Процедуры и функции BGP-4
    
    В соответствии с RFC 1771, в аппаратуре должны быть реализованы следующие процедуры:
    
     поддержка информационных баз BGP-4 (RFC 1771, п.3.2);
    
     процедуры обработки ошибок BGP-4 (RFC 1771, п.п.6.1-6.4);
    
     установка кода аутентификации (RFC 1771, п.4.2);
    
     процедура согласования версии протокола (RFC 1771, п.7);
    
     процедура формирования списка атрибутов пути (RFC 1771, п.5);
    
     поддержка режима синхронизации обмена сообщениями и обработка ошибок тайм-аута (RFC 1771, п.6.5);
    
     процедура обработки завершения сеанса (RFC 1771, п.6.7);
    
     процедура обработки сообщений обновления данных маршрутизации (RFC 1771, п.7);
    
     процедура обнаружения и разрешения конфликта сеансов (RFC 1771, п.6.8);
    
     процедура обработки критериев выбора маршрута (RFC 1771, п.9.3).
    
    Все таймеры, реализованные в аппаратуре для поддержки BGP-4, должны быть конфигурируемы (RFC 1771, п.А.6.4).
    
    

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

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

    3.3.1 Сообщения ARP

    Аппаратура должна обеспечивать обработку пакетов сообщений ARP. Должны поддерживаться два типа сообщений ARP.
    
     Запрос
    
     Ответ на запрос.
    
    Формат сообщений одинаковый, значение поля Код операции должно определять тип сообщения. Поле Код операции должно устанавливаться в значение "1" для пакета запроса ARP и в значение "0" для пакета ответа на запрос (RFC 826).
    
    Генерация пакета запроса ARP должна инициироваться аппаратурой в случае, когда в таблице соответствия физических (сетевых) адресов и адресов Internet отсутствует адрес получателя пакета IP, принятого аппаратурой и подлежащего дальнейшей передаче.
    
    Аппаратура должна обеспечивать установку группового широковещательного адреса подсети, к которой она принадлежит, в поле Адрес получателя пакета в сети стандарта IEEE 802 пакета запроса ARP. Поле Адрес отправителя пакета в сети стандарта IEEE 802 должно устанавливаться в значение, соответствующее собственному адресу Internet аппаратуры. Поле Физический адрес получателя пакета должно устанавливаться в нулевое значение. Аппаратура должна обеспечить групповую передачу пакета запроса ARP ко всем подсоединенным узлам.
    
    Если аппаратура принимает пакет запроса ARP, содержащий ее собственный адрес Internet в поле Протокольный адрес получателя пакета, она должна обеспечить генерацию и посылку пакета ответа на запрос ARP по адресу отправителя запроса. В этом пакете она должна выполнить установку собственного физического (сетевого) адреса в поле Физический адрес получателя пакета, до этого установленного в нулевое значение.
    
    При приеме пакета ответа на запрос ARP аппаратура должна сформировать связанную пару адресов, состоящую из адреса Internet и физического (сетевого) адреса, полученного в пакете ответа, и выполнить внесение этой пары в таблицу соответствия адресов.
         

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

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

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

    
    
    Для всех типов сетей стандарта IEEE 802 поле Адресное пространство физической сети должно устанавливаться в значение "6".
    
    Поле Тип протокола для передачи пакетов IP должно устанавливаться в значение "2048".
    
    Поле Длина адреса физической сети должно устанавливаться в значение "2" для 16-битовых и "6" для 48-битовых адресов сетей стандарта IEEE 802.
    
    Поле Длина адреса протокола должно устанавливаться в значение "4" для IP (RFC 1042).
    
    3.3.2.2 Передача/прием пакетов ARP в локальной сети стандарта IEEE 802
    
    Пакеты ARP должны передаваться в формате пакета Ненумерованная информация (UI) Уровня логического управления звеном (LLC) типа 1 стандарта IEEE 802.2 с кодом управления 3. Поля заголовка пакета UI в этом случае должны устанавливаться в следующие значения: поля DSAP и SSAP устанавливаются в "170", глобальное значение SAP должно соответствовать SNAP. Установка значений полей пакета для SNAP должна соответствовать RFC 1042.
    
    Минимальный размер пакета UI, переносящего пакет ARP, должен составлять 24 байта.
    
    Максимальный размер пакета UI, переносящего пакет ARP, ограничивается максимальным размером пакета в каждой конкретной сети стандарта IEEE 802.
    
    Возможность принимать пакеты UI, переносящие пакеты ARP и при необходимости фрагментировать их является обязательным требованием к аппаратуре.
    
    3.3.2.3 Передача/прием пакетов ARP в локальной сети стандарта IEEE 802.5 (Token Ring)
    
    Минимальный размер пакета UI, переносящего пакет ARP, для сети стандарта IEEE 802.5 не ограничен.
    
    Максимальный размер пакета UI, переносящего пакет ARP, должен определяться в соответствии со временем удержания маркера на узле.
    
    Для поддержки передачи пакета запроса ARP по физической сети в аппаратуре должна быть реализована процедура обнаружения динамических адресов.
    
    В аппаратуре должны быть реализованы: функция распознавания копий запросов ARP, поступивших от разных источников, и алгоритм исключения запроса из копий.
    
    Не допускается использование групповых и функциональных адресов в пакетах ARP.
    

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

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

    Обработка пакетов протокола ARP по сети в стандарте ISO 9314 регламентируется RFC 1390.
    
    3.3.3.1 Формат пакета протокола ARP
    
    При передаче по локальной сети FDDI формат пакета протокола ARP должен соответствовать формату, предусмотренному для сетей стандарта IEEE 802.
    
    Установка значений полей пакета должна соответствовать предусмотренному для сетей стандарта IEEE 802 за исключением поля Адресное пространство физической сети (для сети FDDI данное поле должно устанавливаться в значение "1").
    
    Порядок инкапсуляции пакетов протокола ARP должен соответствовать RFC 1390.
    
    Суммарная длина заголовка пакета уровня логического управления звеном (LLC) и заголовка протокола SNAP должна составлять 8 байт.
    
    Для передачи пакетов протоколов IР и 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 должны игнорироваться.
    
    Порядок обработки команд уровня Логического yправления звеном данных (LLC) должен соответствовать RFC 1390.
    
    

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

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

    
    Требования к процедурам инкапсуляции пакетов IP в пакеты Х.25 регламентируются стандартом Internet RFC 1356.
    
    3.4.1.1 Формат пакетов инкапсуляции
    
    Пакет Запрос вызова Х.25 (Рис.5-3, Рекомендация МСЭ-Т Х.25, 03/93) в поле Данные вызова пользователя должен содержать идентификатор протокола сетевого уровня NLPID (длиной 1 байт), инкапсулируемого по виртуальному каналу Х.25.
    
    Для IP данный идентификатор NLPID должен иметь значение "СС" 16-тиричное (RFC 1356, пп.3.2, 5.1).
    
    Пакет IP переносится в поле блока данных пакета данных Х.25. Пакеты посылаются как завершенные последовательности пакетов Х.25 (пакет IP выровнен по границам пакета Х.25. В случае, когда длина пакета IP превышает размер пакета данных Х.25, пакет IP фрагментируется с использованием бита "еще данные" (RFC 1356, пп.3.1, 5.1).
    
    3.4.1.2 Требования к процедурам инкапсуляции
    
    Инкапсуляция пакетов IP должна выполняться при помощи одного из трех способов:
    
     пакеты IP могут содержаться в мультиплексированных пакетах данных, передаваемых по каналу с нулевой (мультиплексированной) инкапсуляцией (такие пакеты данных идентифицируются по идентификатору NLPID);
    
     пакеты IР могут инкапсулироваться при помощи протокола SNAP (пакеты данных идентифицируются по Уникальному административно назначаемому Идентификатору (OUI), содержащемуся в заголовке протокола SNAP (длиной 5 байт) и имеющему значение "000000" 16-тиричное, а также Идентификатору Протокола (PID), имеющему значение "0800" 16-тиричное). Такой способ инкапсуляции также называется "нулевой" инкапсуляцией;
    
     пакеты IP могут инкапсулироваться по каналу, использующему "нулевую" инкапсуляцию, в мультиплексированные пакеты данных внутри протокола SNAP (RFC 1356, п.3.4).
    
    В аппаратуре допускается поддержка возможности согласования параметров для Х.25 (размер пакета, размер окна).
    
    Взаимосвязь между размером блока данных протокола и размером пакета Х.25 исключается (RFC 1356, п.3.5).
    
    В аппаратуре должна обеспечиваться возможность передачи/приема блоков данных протокола длиной не менее 1600 байт (RFC 1356, п.3.6).
    
    По умолчанию размер максимального блока передачи (MTU) X.25 для пакетов IP должен составлять до 1500 байт, при этом в аппаратуре должна поддерживаться возможность конфигурирования данного MTU (как минимум на уровне интерфейса) в диапазоне от 576 до 1600 байт.
    
    В аппаратуре должна поддерживаться возможность конфигурирования максимальной длины блока данных протокола (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).
    
    В аппаратуре должен обязательно поддерживаться следующий минимальный перечень процедур Х.25:
    
     установление вызова,
    
     освобождение вызова,
    
     передача полных последовательностей пакетов.
    
    Для аппаратуры рекомендуется поддержка следующего перечня процедур протокола Х.25:
    
     расширенная нумерация для последовательностей кадров и/или пакетов,
    
     управление потоком,
    
     процедура согласования параметров,
    
     обратное начисление платы (RFC 1356, п.3.12).
    
    Не допускается использование следующих процедур Х.25:
    
     прерывание пакетов
    
     использование бита Q (индикация ограниченных данных),
    
     быстрый выбор,
    
     использование бита D (индикация сквозной значимости) (RFC 1356, п.3.13).
    
    Для кода диагностики сброса, означающего, что запрошенный протокол не поддерживается, в аппаратуре должно использоваться значение "249" или "0" (RFC 1356 п.3.14).
    
    В аппаратуре допускается использование способов улучшения функциональных характеристик СДОП, работающих по Х.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 регламентируется RFC1483.
    
    Разрешение адресов при прохождении пакетов IP по сети ATM регламентируется RFC1577.
    
    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 содержит значение "АААА03" 16-тиричное, что соответствует случаю, когда за заголовком LLC следует заголовок SNAP, который идентифицирует протокол.
    
    Заголовок SNAP состоит из поля OUI (длина 2 байта), значение которого устанавливается в "0", и поля EtherType (длина 2 байта), значение которого должно соответствовать протоколу, которому принадлежит пакет.
    
    Для протокола IP предусматривается установка поля EtherType в значение "0800" 16-тиричное, протоколу ARP соответствует "0806" 16-тиричное.
    
    Для коммутируемых сетей ATM блок PDU AAL5 не содержит заголовков LLC и SNAP и состоит только из данных пользователя и концевика.
    
    Максимальная длина пакетов IP (MTU) по умолчанию составляет 9180 байт.
    

         
    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 кГц). При работе от собственного генератора относительная нестабильность тактовой частоты должна быть не хуже ±20.10Fт.
    
    Как оптические, так и электрические интерфейсы должны выполнять требования по фазовым дрожаниям выходных сигналов, установленные в Рек.МСЭ-Т 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 Тактовая синхронизация
    
    В нормальном режиме передатчик должен синхронизироваться от сетевого эталона, частота которого определяет такт принимаемых сигналов на физическом уровне. В аварийных условиях (при работе от собственного генератора) относительное отклонение тактовой частоты от номинала 155520 кбит/с не должно быть более ±20.10Fт.
    
    3.5.1.2.1.1.4.3 Способ передачи ячеек
    
    Ячейки ATM, структура которых должна соответствовать Рек.МСЭ-Т I.361, должны размещаться в цикле, предусмотренном Рек.МСЭ-Т G.707 с применением стандартного скремблера СЦИ.
    
    При этом, вначале поток ячеек размещается в контейнере С-4, а затем (совместно с байтами заголовка) - в VC-4, причем ячейки согласуются с байтами STM-1. Поскольку емкость С-4 (2340 октетов) не кратна длине ячеек (53 октета), ячейки могут пересекать границу С-4.
    
    Для отыскания первого байта VC-4 используется указатель AU-4 (байты H1 и Н2 SOH). Используются байты J1, В3, С2 и G1 трактового заголовка РОН.
    
    3.5.1.2.1.1.4.4 Контроль ошибок заголовка
    
    Процедура контроля (НЕС) должна охватывать весь заголовок ячейки. Используемый для контроля код должен позволять либо исправлять одиночные ошибки, либо обнаруживать множественные.
    
    Алгоритм контроля рассчитан на характеристики волоконно-оптических линий, в которых, как считается, преобладают одиночные ошибки и сравнительно большие пакеты ошибок. На передаче вычисляется значение поля НЕС. Приемник имеет два указанных выше режима работы. По умолчанию должен использоваться режим коррекции одиночных ошибок. При обнаружении ошибки в заголовке ячейки возможны два действия в зависимости от состояния приемника. В режиме коррекции корректируются одиночные ошибки и приемник переключается в режим обнаружения. В режиме обнаружения все ячейки с ошибочными заголовками отбрасываются. При обнаружении безошибочного заголовка ячейка сохраняется и приемник переключается в режим коррекции.
    
    Процедуры вычисления значения поля НЕС и контроля должны соответствовать стандарту 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) должен выполняться с помощью поля НЕС. При этом, для повышения помехозащищенности и надежности механизма определения границ ячеек производится скремблирование их информационных полей, что, кроме того, способствует повышению качества передачи ячеек. Эти операции должны выполняться в соответствии с стандартом ETS 300 300 п.10.5.
    
    3.5.1.2.1.1.5 Функции ОАМ
    
    Функции ОАМ - передача и прием сигналов обслуживания (AIS и RDI), контроль качественных показателей должны соответствовать Рек.МСЭ-Т I.610.
    
    3.5.1.2.1.1.5.1 Назначение байтов заголовков СЦИ
    
    В секционном заголовке SOH используются байты A1, A2, J0, B1 (при наличии регенераторов), В2, H1, Н2, Н3, К2 (биты 6-8) и M1 (биты 2-8). В заголовке РОН тракта используются байты J1, В3, С2, 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 соответственно. На уровне секций используется байт В2, результат вычисления на дальнем конце вводится в байт Z2 и в качестве сигнала REI (индикация ошибок на дальнем конце) посылается обратно на передающий конец.
    
    Аналогично на уровне трактов используется байт В3, результат вычисления ошибок вводится в байт G1 (биты 1-4) и передается как REI на ближний конец.
    
    Для контроля секции регенерации (поток F1) используется байт В1. Этот контроль не обязателен и вводится только при наличии регенераторов.
    
    Процедуры контроля качества должны соответствовать положениям СЦИ, определенным в Рек. МСЭ-Т 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 - CИAC мультиплексной секции 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 кбит/с рекомендуются только оптические интерфейсы. При этом:
    
    При работе от собственного генератора нестабильность тактовой частоты должна быть не хуже ±20.10Fт.
    
    Интерфейсы должны выполнять требования по фазовым дрожаниям выходных сигналов, установленные в Рек.МСЭ-Т 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 Требования безопасности
    
    В любых (даже аварийных) условиях не должны превышаться значения параметров, установленные в стандарте IEC 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 Тактовая синхронизация
    
    В нормальном режиме передатчик должен синхронизироваться от сетевого эталона, частота которого определяет такт принимаемых сигналов на физическом уровне. В аварийных условиях (при работе от собственного генератора) относительное отклонение тактовой частоты от номинала 622080 кбит/с не должно быть более ±20.10Fт.
    
    3.5.1.2.1.2.2.3 Способ передачи ячеек
    
    Ячейки ATM, структура которых должна соответствовать Рек.МСЭ-Т I.361, должны размещаться в предусмотренной Рек.МСЭ-Т G.707 структуре AU-4-4c с применением стандартного скремблера СЦИ.
    
    При этом, вначале поток ячеек размещается в С-4-4с, а затем (совместно с байтами заголовка) - в сцепке виртуальных контейнеров VC-4-4c, причем ячейки согласуются с байтами сцепки. Поскольку емкость С-4-4с (9360 октетов) не кратна длине ячеек (53 октета), ячейки могут пересекать границу С-4-4с.
    
    Для отыскания первого байта VC-4-4c используются указатели AU. Используются байты J1, В3, С2 и G1 трактового заголовка РОН.
    
    Нижеследующие функции интерфейса 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.3.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 Сигналы, определенные в Рек.I.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.10Fт.
    
    При этом возможно использование как оптических, так и электрических интерфейсов - в зависимости от требуемой дальности связи и местных условий.
    
    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 дБ.
    
    Частотная характеристика затухания - приблизительно .
    
    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 Тактовая синхронизация
    
    На пользовательской стороне интерфейса оборудование физического уровня может получать тактовую частоту от принимаемых на физическом уровне сигналов, или от местного генератора оборудования пользователя.
    
    3.5.1.2.2.1.2.3 Способ передачи ячеек
    
    Интерфейсный сигнал должен состоять из непрерывного потока ячеек, образованного ячейками ATM, структура которых должна соответствовать Рек.МСЭ-Т I.361, и ячейками физического уровня, которые вставляются для согласования транспортной возможности интерфейса со скоростью передачи, а также в моменты недоступности ячеек ATM. Минимальное расстояние между ячейками физического уровня должно составлять 26 ячеек уровня ATM.
    
    Вставляемые ячейки физического уровня могут быть либо пустыми, либо ячейками ОАМ физического уровня.
    
    3.5.1.2.2.1.2.4 Контроль ошибок заголовка
    
    Процедура контроля (НЕС) должна охватывать весь заголовок ячейки. Используемый для контроля код должен позволять либо исправлять одиночные ошибки, либо обнаруживать множественные.
    
    Алгоритм контроля рассчитан на характеристики волоконно-оптических линий, в которых, как считается, преобладают одиночные ошибки и сравнительно большие пакеты ошибок. На передаче вычисляется значение поля НЕС. Приемник имеет два указанных выше режима работы; по умолчанию должен использоваться режим коррекции одиночных ошибок. При обнаружении ошибки в заголовке ячейки возможны два действия в зависимости от состояния приемника. В режиме коррекции корректируются одиночные ошибки и приемник переключается в режим обнаружения. В режиме обнаружения все ячейки с ошибочными заголовками отбраковываются. При обнаружении безошибочного заголовка ячейка сохраняется и приемник переключается в режим коррекции.
    
    Процедура вычисления значения поля НЕС и контроля должна отвечать требованиям стандарта ETS 300 299 п.10.3.
    
    3.5.1.2.2.1.2.5 Пустые ячейки
    
    Пустые ячейки должны вставляться на передающем конце для подгонки скорости передачи и отбрасываться на приеме. Эти ячейки должны иметь стандартные заголовки, указанные в стандарте ETS 300 299 п.10.4.
    
    3.5.1.2.2.1.2.6 Определение границ и скремблирование информационных полей ячеек.
    
    Определение границ ATM ячеек (аналог цикловой синхронизации систем с STM) должно выполняться с помощью поля НЕС. Для повышения помехозащищенности и надежности механизма определения границ ячеек производится скремблирование их информационных полей, что, кроме того, способствует повышению качества передачи ячеек. Эти операции должны выполняться в соответствии с требованиями стандарта ETS 300 299 п.10.5.
    
    3.5.1.2.2.1.3 Функции ОАМ
    
    Функция ОАМ: передача и прием сигналов обслуживания (AIS и FERF) и контроль качественных показателей должны соответствовать Рек.МСЭ-Т I.610.
    
    3.5.1.2.2.1.3.1 Ресурсы для передачи ячеек ОАМ физического уровня
    
    Частость передачи ячеек ОАМ определяется потребностями ОАМ, однако она не может быть выше, чем одна ОАМ ячейка на каждые 27 ячеек и не может быть ниже, чем одна ОАМ ячейка на каждые 513 ячеек общего потока в рабочем состоянии.
    
    3.5.1.2.2.1.3.2 Типы ячеек ОАМ
    
    Согласно Рек.МСЭ-Т I.610 имеются три потока ОАМ физического уровня, реализуемых ячейками обслуживания со специальными заголовками:
    
    F1 - функции ОАМ на уровне секции регенерации
    
    F2 - функции ОАМ на уровне цифровой секции
    
    F3 - функции ОАМ на уровне тракта.
    
    Ячейки потока F1 (F3) должны вставляться в общий поток периодически, но без ограничения транспортных возможностей уровня ATM. Минимальная частость появления этих ячеек определяется требованиями к готовности секции (тракта) и не должна быть ниже одной ячейки F1 (F3) на 513 ячеек.
    
    Поток F2 в данном интерфейсе отсутствует, поскольку здесь не организуется специальный цикл передачи и достаточно двух потоков ОАМ. Нумерация потоков должна быть сдвинута для сохранения соответствия с интерфейсами, использующими цикл СЦИ.
    
    Заголовки ячеек потоков F1 и F3 должны соответствовать стандарту ETS 300 299 табл.3.
    
    3.5.1.2.2.1.3.3 ОАМ функции и информационные поля
    
    Распределение октетов информационных полей ячеек потоков F1 и F3 между функциями ОАМ физического уровня должно соответствовать стандарту ETS 300 299 п.11.3.
    
    3.5.1.2.2.1.3.4 Сигналы обслуживания
    
    Интерфейс должен поддерживать следующие сигналы обслуживания:
    
    P-AIS - СИАС тракта передачи (посылается в направлении передачи для оповещения оконечного пункта о том, что повреждение обнаружено и отмечено сигнализацией
    
    P-FERF - Сигнал о Повреждении, Принятый с Дальнего Конца Тракта (оповещение аппаратуры противоположного направления об обнаружении повреждения в тракте)
    
    S-AIS - СИАС секции - см. определение для тракта
    
    S-FERF - Сигнал о Повреждении, Принятый с Дальнего Конца Секции - см. определение для тракта.
    
    Контроль качественных показателей
    
    Назначение данного контроля - обнаружение и сообщение об ошибках в передаче. Эта функция должна реализоваться с помощью ячеек уровня ATM и пустых ячеек, но не ячеек ОАМ физического уровня. Вычисление производится для блока ячеек. Поток F3 ОАМ переносит результат. Функция FEBE (Показатель Ошибок на Дальнем Конце) передает результат контроля аппаратуре противоположного направления передачи.
    
    3.5.1.2.2.1.4 Оперативные функции
    
    3.5.1.2.2.1.4.1 Интерфейсные сигналы
    
    Интерфейс должен поддерживать указанные ниже сигналы обслуживания согласно процедурам, установленным в стандарте ETS 300 299 п.12.1.
    
    3.5.1.2.2.1.4.1.1 Сигналы, генерируемые в функциональном оборудовании
    
    LOS - потеря сигнала
    
    LOC - потеря границ ячеек
    
    LOM - потеря потока (F1 или F3) обслуживания
    
    3.5.1.2.2.1.4.1.2 Сигналы, передаваемые и принимаемые на интерфейсе Пользователь-Сеть
    
    S-AIS - СИАС Секции
    
    P-AIS - СИАС Тракта
    
    S-RDI - Сигнал о Повреждении, Принятый с Дальнего Конца Секции
    
    P-RDI - Сигнал о Повреждении, Принятый с Дальнего Конца Тракта
    
    3.5.1.2.2.1.4.2 Контроль состояний интерфейса
    
    Пользовательская и сетевая стороны интерфейса должны информировать друг друга о текущих состояниях физического уровня в связи с различными дефектами, которые могут быть обнаружены. Эти состояния должны соответствовать перечням, приведенным в п.12.2.1 (состояния F пользовательской стороны) и п.12.2.2 (состояния G сетевой стороны) стандарта ETS 300 299. Таблицы состояний определены в п.12.2.4 того же стандарта.
    
    Обе стороны интерфейса должны обмениваться информацией об аварийных состояниях (которые могут возникнуть на сетевой стороне или между сетевой и пользовательской стороной) в форме сигналов, указанных выше в п.3.4.1.3.1.4.1.
    
    3.5.1.2.2.1.4.2.1 Перечень примитивов
    
    Перечень примитивов, которыми обмениваются физический уровень и устройства обслуживания, должен соответствовать стандарту ETS 300 299 п.12.2.3.
    
    3.5.1.2.2.2 Интерфейсы UNI на скорости 622080 кбит/с
    
    3.5.1.2.2.2.1 Функции подуровня физической среды
    
    Возможны два варианта данного интерфейса:
    
    а) асимметричный - со скоростью передачи в одном направлении 622080 кбит/с и 155520 кбит/с в другом
    
    б) симметричный - со скоростью передачи 622080 кбит/с в обоих направлениях.
    
    Для варианта а) компоненты, относящиеся к скорости 155520 кбит/с, должны иметь характеристики, отвечающие п.3.4.1.3.1.
    
    На скорости 622080 кбит/с рекомендуются только оптические интерфейсы, к которым и относится дальнейшее изложение.
    
    При работе от собственного генератора нестабильность тактовой частоты должна быть не хуже ±20.10Fт.
    
    3.5.1.2.2.2.1.1 Затухание тракта
    
    Затухание оптического тракта должно быть в пределах 0-7 дБ.
    
    3.5.1.2.2.2.1.2 Среда передачи
    
    В качестве среды передачи должны использоваться два одномодовых волокна, характеристики которого соответствуют Рек.МСЭ-Т G.652, по одному - для каждого направления передачи.
    
    3.5.1.2.2.2.1.3 Линейный код
    
    В качестве линейного кода должен применяться двоичный код NRZ (без возврата к нулю). При этом, излучение света соответствует двоичной единице, отсутствие излучения - двоичному нулю. Коэффициент гашения должен соответствовать Рек.МСЭ-Т G.957, код применения I-4.
    
    3.5.1.2.2.2.1.4 Рабочая волна
    
    Рабочая волна должна быть около 1310 нм (второе окно прозрачности).
    
    3.5.1.2.2.2.1.5 Характеристики входного и выходного портов
    
    Оптические параметры должны соответствовать Рек.МСЭ-Т G.957, код применения I-4. При этом оптические соединители должны рассматриваться в качестве составной части аппаратуры (приемника или передатчика), но не оптической линии.
    
    3.5.1.2.2.2.1.6 Оптические соединители
    
    Соединитель интерфейса на стороне аппаратуры, обращенной к пользователю, должен быть типа "гнездо". На стороне, обращенной к сети, соединитель должен быть либо типа "гнездо" (при этом кабель в сторону сети должен оснащаться вилками на обоих концах), либо аппаратура на этой стороне должна иметь встроенный кабель с соединителем типа "вилка".
    
    3.5.1.2.2.2.1.7 Требования безопасности
    
    В любых (даже аварийных) условиях не должны превышаться значения параметров, установленные в стандарте IEC 825-1, класс 1.
    
    3.5.1.2.2.2.2 Функции подуровня конвергенции передачи
    
    3.5.1.2.2.2.2.1 Транспортные возможности
    
    При скорости передачи на физическом уровне 622080 кбит/с максимальная скорость, доступная для ячеек пользователя, сигнализации и ОАМ ячеек (исключая служебные ячейки физического уровня) должна составлять 599040 кбит/с.
    
    Нижеследующие функции интерфейса 622080 кбит/с аналогичны функциям интерфейса 155520 кбит/с:
    
    3.5.1.2.2.2.2.2 Тактовая синхронизация - см. п.3.5.1.2.2.1.2.2
    
    3.5.1.2.2.2.2.3 ОАМ функции и информационные поля - см. п.3.5.1.2.2.1.3
    
    3.5.1.2.2.2.2.4 Сигналы обслуживания - см. п.3.5.1.2.2.1.3.4
    
    3.5.1.2.2.2.2.5 Контроль качественных показателей - см. п.3.5.1.2.2.1.3.5
    
    3.5.1.2.2.2.3 Оперативные функции - см. п.3.5.1.2.2.1.4
    
    3.5.1.2.2.2.3.1 Интерфейсные сигналы - см. п.3.5.1.2.2.1.4.1
    
    3.5.1.2.2.2.3.2 Сигналы, генерируемые в функциональном оборудовании - см. п.3.5.1.2.2.1.4.1.1
    
    3.5.1.2.2.2.3.3 Сигналы, передаваемые и принимаемые на интерфейсе Пользователь-Сеть - см. п.3.5.1.2.2.1.4.1.2
    
    3.5.1.2.2.2.3.4 Контроль состояний интерфейса - см. п.3.5.1.2.2.1.4.2
    
    3.5.1.2.2.2.3.5 Перечень примитивов - см. п.3.5.1.2.2.1.4.3
    
    3.5.1.2.3 Интерфейсы в формате ПЦИ
    
    Данные интерфейсы позволяют использовать для передачи ячеек ATM существующие системы передачи ПЦИ и линии связи. Они могут использоваться в сетевых конфигурациях, определенных в Рек.МСЭ-Т I.412. Общие для всех UNI характеристики установлены в Рек.МСЭ-Т I.432.1, а характеристики подуровня физической среды - в Рек.МСЭ-Т I.431.
    
    3.5.1.2.3.1 Интерфейсы UNI на скорости 2048 кбит/с
    
    Параметры, специфичные для скорости передачи 2048 кбит/с, определены в Рек.МСЭ-Т I.432.3.
    
    3.5.1.2.3.1.1 Перечень функций интерфейса
    
    Тактовая синхронизация. Данная функция обеспечивает тактовую синхронизацию, необходимую аппаратуре пользователя для приема информации из агрегатного потока.
    
    Октетная синхронизация. Эта функция обеспечивает синхронизацию по 8 кГц, необходимую для аппаратуры пользователя с целью поддержки октетной структуры речевых кодеров и других необходимых целей синхронизации.
    
    Цикловая синхронизация. Функция обеспечивает аппаратуру пользователя информацией, необходимой для приема каналов, разделенных по времени.
    
    Питание. Функция обеспечивает возможность подачи через интерфейс питания для аппаратуры пользователя.
    
    Обслуживание. Функция обеспечивает информацию об оперативных или аварийных ситуациях на интерфейсе.
    
    Процедура CRC (контроль избыточным кодом). Функция обеспечивает защиту от ложной цикловой синхронизации и может контролировать верность передачи.
    
    3.5.1.2.3.1.2 Интерфейсные цепи для обмена информацией
    
    Для интерфейсных цепей для обмена информацией должны использоваться две симметричные цепи, каждая для одного направления передачи цифровых сигналов. Все указанные выше функции (кроме питания и, возможно, обслуживания) комбинируются в двух агрегатных цифровых сигналах, по одному в каждом направлении передачи. Два провода каждой цепи, несущей цифровой сигнал, могут взаимно меняться.
    
    Если через интерфейс подается питание, для него должна использоваться добавочная цепь.
    
    3.5.1.2.3.1.3 Активизация/деактивизация
    
    Интерфейсы должны быть всегда активны. Никаких процедур для активизации или деактивизации не используется. Для указания уровню 2 о транспортных возможностях уровня 1 используется тот же набор примитивов, который указан в Рек.МСЭ-Т I.430. Он применяется только на стыке уровней 1 и 2.
    
    3.5.1.2.3.1.4 Оперативные функции
    
    Перечень и определения видов сигналов нa интерфейсе, алгоритмы определения сигналов, таблицы состояний на сетевой и пользовательской сторонах интерфейса и определения примитивов должны соответствовать Рек.МСЭ-Т I.431 п.3.4.
    
    3.5.1.2.3.1.5 Характеристики подуровня физической среды
    
    3.5.1.2.3.1.5.1 Электрические характеристики
    
    Электрические характеристики интерфейсов должны соответствовать ГОСТ 26886-86 раздел 4 и Рек.МСЭ-Т G.703 п.6 (для симметричных линий 120 Ом).
    
    Симметричная линия, подключаемая к интерфейсу, должна иметь импеданс 120±24 Ом в полосе 0,2-1 МГц и 120±12 Ом на частоте 1 МГц.
    
    3.5.1.2.3.1.5.2 Структура цикла
    
    Количество бит в канальном интервале - 8 (с 1 по 8)
    
    Количество канальных интервалов в цикле - 32 (с 0 по 31).
    
    Цикл содержит 256 бит, частота повторения циклов - 8000 в секунду.
    
    Назначение бит в КИ 0
    
    Назначение бит в КИ 0 должно отвечать требованиям Рек.МСЭ-Т G.704 п.2.3.2. При этом:
    
    Бит Е отводится для информации об ошибках (процедура CRC).
    
    Биты Sa с позициями 4 и 8 резервированы для международной стандартизации и в настоящее время должны игнорироваться оконечным оборудованием пользователя.
    
    Биты Sa с позициями 5-7 резервированы для национального использования. Оконечное оборудование пользователя, не использующее эти биты, должно игнорировать любые их комбинации.
    
    3.5.1.2.3.1.5.3 Распределение канальных интервалов
    
    КИ 0 должен использоваться для цикловой синхронизации согласно Рек.МСЭ-Т G.704.
    
    КИ 16 должен использоваться для сигнализации.
    
    В КИ 1-31 возможна передача любых последовательностей бит.
    
    3.5.1.2.3.1.5.4 Тактовая синхронизация
    
    Сетевое окончание должно получать такт от сетевого источника. Аппаратура пользователя синхронизируется по принимаемому от сетевого окончания сигналу и использует этот такт при передаче. В отсутствие синхронизма (например, когда поврежден доступ, по которому в нормальном режиме поступает тактовый сигнал), относительные отклонения тактовой частоты не должны превышать ±50.10Fт. Аппаратура пользователя должна нормально принимать и распознавать сигнал с такими отклонениями. Если аппаратура пользователя имеет более одного интерфейса, она называется аппаратурой пользователя с несколькими доступами и должна быть способна использовать синхросигнал с любого доступа (или со всех) и соответственно синхронизировать передачу на каждом интерфейсе.
    
    3.5.1.2.3.1.5.5 Фазовые дрожания
    
    3.5.1.2.3.1.5.5.1 Общие соображения
    
    Требования к фазовым дрожаниям должны учитывать абонентские конфигурации с одним и несколькими доступами. Система передачи, используемая в любой линии доступа, может быть оснащена схемой восстановления тактовой частоты с высокой или низкой добротностью. Опорный сигнал для измерений фазовых дрожаний следует получать от сетевого источника. Номинальная величина единичного интервала составляет 488 нс.
    
    3.5.1.2.3.1.5.5.2 Допустимые фазовые дрожания на входе аппаратуры пользователя
    
    Аппаратура пользователя должна работать нормально, без ошибок и потери цикловой синхронизации в случае приема сигнала 2048 кбит/с с синусоидальными дрожаниями, указанными в Рек.МСЭ-Т I.431 п.5.4.2. Аппаратура пользователя с несколькими доступами должна выдерживать максимальную разность фаз между входами в 41 единичный интервал.
    
    

Рис.3.34. Фазовые дрожания на входе аппаратуры

    
    3.5.1.2.3.1.5.5.3 Выходные фазовые дрожания аппаратуры пользователя и сетевого окончания с одним интерфейсом UNI
    
    Выходные фазовые дрожания (от пика до пика) должны удовлетворять требованиям Рек.МСЭ-Т I.431 п.5.4.3.1. Входной сигнал должен иметь допустимый джиттер и отклонение частоты.
    
    

    
    
    Характеристика передачи фазовых дрожаний приведена ниже.
    

Рис.3.35. Характеристика передачи фазовых дрожаний

    
    
    Выходные фазовые дрожания аппаратуры пользователя с несколькими интерфейсами UNI к одной сети.
    
    Выходные фазовые дрожания (от пика до пика) должны удовлетворять требованиям Рек.МСЭ-Т 1.431 п.5.4.3.2. Входной сигнал должен иметь допустимый джиттер и отклонение частоты.
    
    Аппаратура с несколькими интерфейсами, в которой применяется метод выбора синхронизации (в данный момент для синхронизации используется только один вход) может рассматриваться как аппаратура с одним интерфейсом, если она отвечает требованиям Рек.МСЭ-Т I.431 п.5.4.3.1 в момент переключения на другой интерфейс (входной сигнал, используемый для синхронизации, меняется от нормального рабочего цикла с номинальной частотой к циклу СИАС с отклонением тактовой частоты ±50.10Fт, в то время как на всех других входах принимаются сигналы с нормальным рабочим циклом с номинальной частотой). Входные сигналы должны иметь допустимые фазовые дрожания и отклонения фазы бит не более 0,5 единичного интервала.
    

    
    
    3.5.1.2.3.1.5.6 Защищенность от продольных помех на входе
    
    Как минимум, приемник должен безошибочно воспринимать нормальный сигнал в присутствии напряжения продольной помехи в диапазоне частот от 10 Гц до 30 МГц в соответствии с Рек.МСЭ-Т I.431.
    
    3.5.1.2.3.1.5.7 Затухания асимметрии на выходе
    
    Затухания асимметрии на выходе должна отвечать следующим требованиям:
    

    3.5.1.2.3.1.5.8 Полное сопротивление
    
    Полное сопротивление по отношению к земле входа приемника или выхода передатчика должно быть более 1000 Ом в диапазоне от 10 Гц до 1 МГц в соответствии с Рек.МСЭ-Т I.431.
    
    3.5.1.2.3.1.5.9 Интерфейсные процедуры
    
    3.5.1.2.3.1.5.10 Коды свободных каналов и свободных канальных интервалов
    
    В любом канальном интервале, не присвоенном какому-либо каналу (например, в КИ, ожидающих присвоения при каждом соединении, свободных КИ не полностью используемого интерфейса и др.), а также в каждом КИ канала, не отданного для соединения в обоих направлениях, должна передаваться комбинация из не менее, чем трех двоичных единиц в октете.
    
    3.5.1.2.3.1.5.11 Заполнение промежутков между блоками данных (frames) уровня 2
    
    В моменты отсутствия предназначенных для передачи блоков данных (frames) уровня 2 должны передаваться смежные флаги HDLC.
    
    3.5.1.2.3.1.5.12 Процедуры цикловой синхронизации и CRC-4
    
    Процедуры цикловой синхронизации и CRC-4 должны соответствовать Рек.МСЭ-Т G.704 п.4.
    
    3.5.1.2.3.1.5.13 Обслуживание интерфейса
    
    Эталонные сетевые конфигурации для обслуживания данного интерфейса должны соответствовать Рек.МСЭ-Т I.604. Перечень и содержание процедур обслуживания должны соответствовать Рек.МСЭ-Т I.431 п.5.9.
    
    3.5.1.2.3.1.6 Функции подуровня конвергенции передачи
    
    3.5.1.2.3.1.6.1 Скорость передачи
    
    Скорость передачи должна быть равна 2048 кбит/с.
    
    3.5.1.2.3.1.6.2 Транспортные возможности
    
    Скорость передачи, доступная для ячеек ATM (пользовательская информация, сигнализация, ОАМ и ячейки, используемые для подгонки скорости передачи), исключая ячейки заголовка физического уровня, должна составлять 1920 кбит/с.
    
    3.5.1.2.3.1.6.3 Функции, специфичные для транспорта
    
    Структура цикла должна соответствовать Рек.МСЭ-Т I.431 (см. п.3.1.2.3.1.2.2).
    
    3.5.1.2.3.1.6.4 Функции, специфичные для ATM
    
    3.5.1.2.3.1.6.5 Формат ячеек ATM
    
    Формат ячеек должен соответствовать Рек. МСЭ-Т I.361.
    

    3.5.1.2.3.1.6.6 Размещение ячеек ATM
    
    Ячейки ATM прямо размещаются в цикле согласно Рек.МСЭ-Т G.804. Ячейки согласуются с байтами цикла. КИ 0 используется для ОАМ функций, КИ 16 не используется на данном интерфейсе. КИ 1-КИ 15 и КИ 17-КИ 31 используются для транспорта ячеек ATM.
    
    3.5.1.2.3.1.6.7 Контроль заголовков ячеек
    
    Контроль заголовков ячеек должен выполняться согласно Рек.МСЭ-Т I.432.1 п.4.3.2.
    
    3.5.1.2.3.1.6.8 Определение границ ячеек
    
    Определение границ ячеек должно выполняться согласно Рек.МСЭ-Т I.432.1 п.4.3.3.
    
    3.5.1.2.3.1.6.9 Скремблирование
    
    Для скремблирования ячеек ATM должна использоваться функция , как указано в Рек.МСЭ-Т I.432.1 п.4.3.4.
    
    3.5.1.2.3.1.6.10 Пустые ячейки
    
    Использование пустых ячеек для подгонки скорости передачи должно отвечать требованиям Рек.МСЭ-Т I.432.1 п.4.3.5.
    
    3.5.1.2.3.1.6.11 Функции, специфичные для ОАМ
    
    3.5.1.2.3.1.6.12 Операции ОАМ
    
    Операции ОАМ, описанные в Рек.МСЭ-Т I.432.2 п.6.1, должны выполняться с использованием сигналов, указанных в Рек.МСЭ-Т I.431 п.4.7.3, со следующими отличиями:
    
     не различаются Секции и Тракты;
    
     функция RDI реализуется с использованием сигнала RAI согласно Рек.МСЭ-Т G.704;
    
     контроль качественных показателей реализуется с использованием процедуры CRC4, как это определено в Рек.МСЭ-Т G.706.
    
    Перечень и определения состояний интерфейса на стороне пользователя и сети должны соответствовать Рек.МСЭ-Т I.432.3 п.п.4.2.5.2 и 4.2.5.3.
    
    3.5.1.2.3.2 Интерфейсы UNI на скорости 34368 кбит/с
    
    Данные интерфейсы стандартизованы Форумом ATM (стандарт af-phy.0034.000) на основе рекомендаций МСЭ-Т и стандартов ETSI. Требования этого раздела соответствуют стандарту Форума ATM af-phy.0034.000.
    
    3.5.1.2.3.2.1 Общие положения
    
    Функции и примитивы физического уровня должны соответствовать Рек.МСЭ-Т I.321 п.4. Информационные потоки и функции физического уровня интерфейса должны соответствовать Рек.МСЭ-Т I.413. п.3.
    
    3.5.1.2.3.2.2 Характеристики подуровня физической среды
    
    Характеристики, зависящие от физической среды, должны соответствовать разделу 6 ГОСТ 26886-86 и Рек.МСЭ-Т G.703 п.8.
    
    3.5.1.2.3.2.3 Физические/электрические характеристики
    
    Импульсные характеристики выходных сигналов, сопротивление измерительной нагрузки и требования к фазовым дрожаниям должны соответствовать требованиям Рек. МСЭ-Т G.703 п.8.2.
    
    Входной сигнал должен соответствовать указанному выше, допустимые фазовые дрожания и коэффициент отражения - требованиям Рек.МСЭ-Т G.703. п.8.3
    
    3.5.1.2.3.2.4 Скорость передачи
    
    Номинальная скорость передачи должна составлять 34368 кбит/с, как указано в Рек.МСЭ-Т G.703 п.8.1.
    
    В отсутствие синхронизации от сетевого эталона относительное отклонение тактовой частоты от номинального значения не должно быть более ±20х10.
    
    3.5.1.2.3.2.5 Линейный код
    
    Код в линии должен быть HDB3, согласно Рек.МСЭ-Т G.703 п.8.1.
    
    3.5.1.2.3.2.6 Характеристики подуровня Конвергенции Передачи
    
    3.5.1.2.3.2.6.1 Функции, специфичные для транспорта
    
    Структура цикла должна соответствовать Рек.МСЭ-Т G.832, п.2.1., стандартам ETS 300 337 п.5.1 и ETS 300 417-5 п.8. Данный цикл длиной 125 мкс содержит 7 байт заголовка и 530 байт нагрузки.
    
    При использовании данного цикла должны быть приняты меры, исключающие симуляцию комбинаций цикловой синхронизации содержанием поля нагрузки (заголовками ячеек).
    
    3.5.1.2.3.2.6.2 Функции, специфичные для АТМ
    
    Специфичные для ATM функции подуровня Конвергенции Передачи должны быть основаны на Рек.МСЭ-Т G.804 п.6 и Рек.МСЭ-Т I.432 п.4.
    
    3.5.1.2.3.2.6.2.1 Размещение ячеек ATM
    
    Ячейки ATM должны размещаться непосредственно в 530 байтах поля нагрузки цикла согласно Рек.МСЭ-Т G.804 п.6.1. Байты ячеек должны быть согласованы с байтами цикла.
    
    3.5.1.2.3.2.6.2.2 Подгонка скорости передачи ячеек
    
    Подгонка скорости передачи ячеек должна выполняться добавлением или удалением пустых ячеек, как это указано в Рек.МСЭ-Т G.804 п.6.2 и Рек.МСЭ-Т I.432 п.4.4.
    
    3.5.1.2.3.2.6.2.3 Определение границ ячеек
    
    Определение границ ячеек должно выполняться с использованием механизма НЕС, определенного в Рек.МСЭ-Т G.804 п.6.5 и Рек.МСЭ-Т I.432 п.4.5.
    
    3.5.1.2.3.2.6.2.4 Скремблирование ячеек
    
    Поля нагрузки ячеек должны скремблироваться с использованием самосинхронизирующегося скремблера, определенного в Рек.МСЭ-Т G 804 п.6.4 и Рек.МСЭ-Т I.432 п.4.5.
    
    3.5.1.2.3.2.6.2.5 Генерирование и контроль комбинаций НЕС
    
    Передатчик должен вычислять значение НЕС для первых четырех байтов заголовка ячеек ATM и вписывать этот результат в байт НЕС, как это указано в Рек.МСЭ-Т G.804 п.6.6 и Рек.МСЭ-Т I.432 п.4.3.
    
    Приемник должен поддерживать режимы коррекции единичных и обнаружения множественных ошибок в заголовках при использовании процедур, указанных в Рек.МСЭ-Т I.432 п.4.3. По умолчанию используется режим коррекции единичных ошибок.
    
    3.5.1.2.3.2.7 Функции ОАМ (оперативные и обслуживания) физического уровня
    
    3.5.1.2.3.2.7.1 Дефекты и отказы
    
    Обнаружение наступления и прекращения состояния потери цикловой синхронизации (OOF) должно выполняться согласно Рек.МСЭ-Т G.783 п.2.2.2 и стандарту ETS 300 417-2 п.4.3.
    
    В состоянии синхронизма максимальное время обнаружения OOF для случайного сигнала без цикла равно 625 мкс. Алгоритм, используемый для проверки синхронизма таков, что в нормальном режиме (Пуассоновского типа) не вызывает ложного сигнала OOF более, чем один раз за 6 мин.
    
    В состоянии потери синхронизма максимальное время вхождения в синхронизм должно быть 250 мкс для ошибочного сигнала, не эмулирующего синхрокомбинации. Алгоритм восстановления синхронизма должен быть таким, чтобы вероятность ложного восстановления для случайного сигнала без цикла была не более за время 250 мкс.
    
    Обнаружение наступления и прекращения состояния потери сигнала (LOS) должно выполняться согласно Рек.МСЭ-Т G.775 п.4.2 и стандарту ETS 300 417-1 п.8.2.
    
    Состояние LOS наступает, когда входной сигнал имеет уровень на 35 дБ ниже номинального (или еще ниже) для N последовательных импульсных интервалов, где N равно от 10 до 255 включительно. Состояние LOS снимается, когда входной сигнал имеет уровень на 15 дБ ниже номинального (или еще выше) для N последовательных импульсных интервалов, где N равно от 10 до 255 включительно.
    
    СИАС должен обрабатываться согласно Рек.МСЭ-Т G.751 п.п.2.5.2 (примечания 1 и 2 только) и п.2.5.3. СИАС на физическом уровне состоит только из единиц, без цикла. Этот сигнал должен обнаруживаться при . Время обнаружения и исполнения последующих действий должно быть не более 1 мс.
    
    Входной сигнал должен проверяться, согласно стандарту ETS 300 337 п.8.2 и стандарту ETS 300 417-1 п.8.2.1, по признакам:
    
    несоответствие трассы (Trail Trace mismatch, TR);
    
    отсутствие оборудования (Unequipped);
    
    искаженный сигнал (Degraded);
    
    индикация о повреждении с дальнего конца (RDI);
    
    Байт TR входит в состав заголовка цикла сигнала, его использование должно соответствовать Рек.МСЭ-Т G.832 п.2.1.2 и стандарту ETS 300 337 п.5.1.2.
    
    Входной сигнал должен проверяться по признаку несоответствие метки сигнала (Signal Label mismatch) согласно стандарту ETS 300 417-1 п.8.2.1.
    
    Отказы должны опознаваться на основе их постоянства - согласно стандарту ETS 300 417-1 п.8.3.
    
    3.5.1.2.3.2.7.2 Сигналы обслуживания
    
    Сигналы обслуживания, определенные в Рек.МСЭ-Т G.832 п.2.1.2 и стандарте ETS 300 337 п.5.1, должны обрабатываться согласно Рек.МСЭ-Т I.432 п.6.1 и стандарту ETS 300 417-5 п.8.2.
    
    Сигнал RDI (FERF) должен посылаться во встречном направлении, если на приеме обнаружены сигналы LOS, LOF, TR, СИАС, Unequipped или Signal Label mismatch, как определено в Рек.МСЭ-Т I.432 п.6.1 и стандарте ETS 300 417-5 п.8.2.
    
    Сигнал FEBE должен посылаться во встречном направлении, если на приеме процедура BIP-8 обнаружила одну или более ошибок, в соответствии с 2.1.2 Рек.МСЭ-Т G.832 п.2.1.2, стандартом ETS 300 337 п.5.1.2 и стандартом ETS 300 417-5 п.8.2.
    
    Генерирование сигналов RDI (FERF) и FEBE выполняется с использованием байта МА заголовка цикла. Структура этого байта показана ниже.
    
    

    
    
    3.5.1.2.3.2.7.3 Контроль качественных показателей
    
    Контролируемые показатели ошибок должны соответствовать Рек.МСЭ-Т G.826 и стандарту ETS 300 417-1. Это Блоки с ошибками (ЕВ), Секунды с ошибками (ES). Пораженные секунды (SES) и Фоновые блоковые ошибки (ВВЕ). Контроль входного (на ближнем конце) сигнала основывается на процедуре BIP-8 контроля байта ЕМ заголовка и принимаемых сигналах дефектов (LOS и др). Контроль выходного (на дальнем конце) сигнала основывается на приеме сигналов FEBE и дефектов RDI (FERF).
    
    Определения событий даны в Рек.МСЭ-Т G.826 п.5 и стандарте ETS 300 417-1 п.8.4.
    
    Для данного интерфейса размер блока соответствует размеру цикла, т.е. 4296 байт.
    
    3.5.1.2.3.3 Интерфейсы UNI для медных линий на скорости 25600 кбит/с
    
    Данные интерфейсы предназначены для передачи ячеек ATM по существующим внутриобъектовым кабельным линиям длиной порядка 100 м с неэкранированными парами с импедансом 100 и 120 Ом или экранированными с импедансом 150 Ом.
    
    Интерфейсы определены в Рек.МСЭ-Т I.432.5 (подуровень физической среды). Общие параметры описаны в Рек.МСЭ-Т I.432.1, а подуровень Конвергенции Передачи - в Рек МСЭ-T I.432.2.
    
    В данном разделе излагаются требования к интерфейсам, рассчитанным на работу по неэкранированным парам 120 Ом. Требования к интерфейсам для других пар см. в Рек.МСЭ-Т I.432.5.
    
    3.5.1.2.3.3.1 Подуровень физической среды
    
    3.5.1.2.3.3.1.1 Требования к звену передачи
    
    3.5.1.2.3.3.1.1.1 Скорость передачи
    
    Информационная (до линейного кодирования) скорость передачи равна 25600 кбит/с. Линейная (символьная) скорость после кодирования 4В5В равна 32 МБод. Задающий генератор передатчика на стороне пользователя должен иметь погрешность частоты не более ±100х10Fт.
    
    3.5.1.2.3.3.1.1.2 Симметрия скоростей передачи
    
    Интерфейсы симметричны, т.е. скорости передачи в обоих направлениях равны.
    
    3.5.1.2.3.3.1.1.3 Коэффициент ошибок
    
    Активный входной интерфейс должен обеспечивать , когда передатчик, соответствующий разделу 3.4.1.5.1.2, работает с эталонной моделью канала, описанного в разделе 3.4.1.5.1.4 в присутствии наиболее тяжелой переходной помехи, указанной в разделе 3.4.1.5.1.4.
    
    3.5.1.2.3.3.1.1.4 Тактовая синхронизация звена передачи
    
    На передаче в подуровнях физической среды и конвергенции передачи используется кварцевый генератор или распределяемый по объекту эталонный источник с малыми фазовыми дрожаниями, который обеспечивает передачу с номинальной частотой 25600 кбит/с.
    
    Приемник извлекает такт из принимаемого с линии сигнала.
    
    3.5.1.2.3.3.1.1.5 Независимая синхронизация направлений передачи
    
    Рекомендуется использовать схему синхронизации точка-точка, когда генератор на передаче каждого звена (направления передачи) независим. В этих условиях необходимая для работы форма импульсов описывается шаблонами раздела 3.4.1.5.1.2.2.
    
    3.5.1.2.3.3.1.2 Требования к передатчику
    
    Излагаемые здесь требования описывают передаваемый сигнал. Для измерения этих параметров должна быть обеспечена возможность посылки по схемам передатчика нескремблированных некодированых сигналов на линейной символьной скорости.
    
    При всех измерениях нагрузка передатчика должна быть активной и равной 120 Ом.
    
    3.5.1.2.3.3.1.2.1 Искажения времени пересечения нулевого значения импульса
    
    Искажения рабочего цикла
    
    Данный параметр определяет статические, не зависящие от передаваемых данных, искажения времени пересечения нулевого значения, обычно вызываемые асимметрией времени нарастания и спада в логических схемах передатчика и др.
    
    Измерения проводятся на указанных ниже сигналах, которые используются только при испытаниях и не существуют в нормальных рабочих условиях.
    
    Искажения определяются, как половина разности ширины положительных и отрицательных импульсов в схемах передатчика, связанных по переменному току.
    
    Искажения рабочего цикла передатчика (TDCD) должны быть менее 1,5 нс (в пике) при синхронизации выходного сигнала от местного генератора.
    
    Определены два следующих измерительных сигнала (символы на линейной скорости): 00110011... и 01010101... . Эти измерительные последовательности не должны скремблироваться или кодироваться.
    
    Краевые фазовые дрожания
    
    Краевые фазовые дрожания относятся к любым формам сигналов, совместимым с рекомендациями по скремблированию и кодированию раздела 3.4.1.5.2. Они определяются как максимум пиковой вариации передних и задних фронтов данных (относительно тактового сигнала передатчика). Краевые фазовые дрожания передатчика должны быть менее 4 нс от пика до пика при синхронизации выходного сигнала от местного источника.
    
    Формы сигналов передатчика
    
    Форма сигналов передатчика должна соответствовать шаблонам, определенным в таблицах 2-6 и рисунках 3-7 Рек.МСЭ-Т I.432.5. Кроме того, частота среза по уровню 3 дБ на выходе передатчика в наихудшем случае должна быть равна или менее 12 кГц.
    
    В следующих таблицах и рисунках приводится измеряемая амплитуда импульса, нормализованная так, что значение 1 для каждого графика представляет амплитуду основной частоты для односимвольного элемента. Время выражается в процентах от измеряемой ширины импульса. Для линейной символьной скорости передачи 32 Мбода номинальная ширина импульса в линии равна 32,25 нс. Поэтому, например, номинальная длительность 5-символьного элемента, соответствующая 100%, составляет 156,25 нс.
    
         
    Шаблоны для 5-символьных элементов
         

Рис.3.36. Форма сигнала передатчика для 5-символьмого элемента

    
    
    Шаблоны для 4-символьных элементов
    
    

Рис.3.37. Форма сигнала передатчика для 4-х-символьного элемента

    
    Шаблоны для 3-символьных элементов