Описание услуги «Аудиоконференцсвязь»¢Т CR draft 2014_02_19.… · Web viewТехнические требования к оборудованию

Технические требования к оборудованию маршрутизатора ядра магистральной

сети IP/MPLS ОАО «Ростелеком» (Редакция 1)

Москва2014 г.

Технические требования к оборудованию маршрутизатора ядра магистральной сети IP/MPLS ОАО «Ростелеком»

Редакция: 2/2014 № Бизнес-процесса: БП.ПР.05 Стр.2 из 84

СОДЕРЖАНИЕ

1 НАЗНАЧЕНИЕ.........................................................................................................................3

2 ОБЩИЕ ПОЛОЖЕНИЯ........................................................................................................3

3 ОБЩАЯ ИНФОРМАЦИЯ.....................................................................................................4

4 ТРЕБОВАНИЯ К АРХИТЕКТУРЕ ОБОРУДОВАНИЯ..................................................4

5 ТРЕБОВАНИЯ К ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ И ИНТЕРФЕЙСАМ....5

6 ТРЕБОВАНИЯ К ФУНКЦИОНАЛЬНОСТИ ОБОРУДОВАНИЯ................................5

7 ТРЕБОВАНИЯ К СИСТЕМАМ УПРАВЛЕНИЯ, ПЛАНИРОВАНИЯ И АНАЛИЗА ТРАФИКА..........................................................................................................................................6

8 ТРЕБОВАНИЕ ПО ВЗАИМОДЕЙСТВИЮ С СУЩЕСТВУЮЩЕЙ СЕТЬЮ...........7

9 ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ОБОРУДОВАНИЕМ..............................................7

10 ТРЕБОВАНИЯ К ПРОИЗВОДИТЕЛЮ ОБОРУДОВАНИЯ..........................................7

11 ТРЕБОВАНИЯ ПО СЕРТИФИКАЦИИ ОБОРУДОВАНИЯ.........................................7

12 ТРЕБОВАНИЯ К УРОВНЮ ЗВУКА, СОЗДАВАЕМОМУ ОБОРУДОВАНИЕМ......7

13 ТРЕБОВАНИЯ К ЭЛЕКТРОПИТАНИЮ И ЗАЗЕМЛЕНИЮ.......................................8

14 ТРЕБОВАНИЯ К СОСТАВУ ПОСТАВЛЯЕМОЙ ДОКУМЕНТАЦИИ......................8

15 ТРЕБОВАНИЯ К ГАРАНТИЙНЫМ ОБЯЗАТЕЛЬСТВАМ..........................................9

16 ТРЕБОВАНИЯ К ЗИП............................................................................................................9

17 ТРЕБОВАНИЯ К РЕМОНТУ.............................................................................................10

18 ТРЕБОВАНИЯ К КОНТРОЛЬНО-ИЗМЕРИТЕЛЬНОЙ АППАРАТУРЕ.................10

19 ТРЕБОВАНИЯ К УЧЕБНО-ТРЕНИРОВОЧНЫМ СРЕДСТВАМ..............................11

20 ТРЕБОВАНИЯ К МОНТАЖУ............................................................................................11

21 ТРЕБОВАНИЯ К ИСПЫТАНИЯМ...................................................................................12

22 ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ И ОХРАНЕ ТРУДА...........................................12

23 ТРЕБОВАНИЯ К УСЛОВИЯМ ТРАНСПОРТИРОВКИ И ХРАНЕНИЯ..................13

24 ХРАНЕНИЕ И АРХИВИРОВАНИЕ..................................................................................14

25 РАССЫЛКА И АКТУАЛИЗАЦИЯ....................................................................................14

26 ПРИЛОЖЕНИЕ 1. ТРЕБОВАНИЯ К СОСТАВУ УСЛУГ ГАРАНТИЙНОЙ И ПОСЛЕГАРАНТИЙНОЙ ПОДДЕРЖКИ.................................................................................16

27 Приложение 2. Требования к поддержке функционала оборудования......................19



1 НазначениеНастоящий документ содержит информацию о технических требованиях к

оборудованию магистральной сети IP/MPLS ОАО «Ростелеком».

2 Общие положения2.1 Область применения

Требования данных «Технических требований к оборудованию магистральной сети IP/MPLS ОАО «Ростелеком» распространяются на работу лиц, ответственных за исполнение следующих бизнес-процессов, образующих технологический цикл взаимодействия подразделений в ОАО «Ростелеком»:

БП.ПР.05 Планирование и развитие сети связи; БП.ОП.01 Эксплуатация и оперативно-техническое управление сетями связи.Применение данного документа в макрорегиональных/ региональных филиалах

Общества - «Для руководства».Данный документ содержит технические требования к оборудованию

магистральной сети передачи данных IP/MPLS ОАО «Ростелеком».Основные типы используемого оборудования:

Маршрутизаторы; Коммутаторы; Системы управления.

Требования к СУ не конкретизируются в данном документе, так как зависят от назначения, функциональности, производительности системы и предъявляемых требований к резервированию.2.2 Нормативные ссылки

В данных «Технических требованиях к оборудованию магистральной сети IP/MPLS ОАО «Ростелеком» использованы ссылки на следующие нормативные документы:

• Процедура управления внутренней нормативной документацией ОАО «Ростелеком»;

• Инструкция по делопроизводству в ОАО «Ростелеком»;• Процедура управления записями в ОАО «Ростелеком»;•Регламент бизнес-процесса ПР5 Планирование и развитие сети связи.

2.3 Термины, определения и сокращенияВ настоящем документе используются следующие определения и сокращения:

Заказчик - филиал или макрорегиональный филиал ОАО «Ростелеком»;Общество - ОАО «Ростелеком»;Поставщик - поставщик оборудования;Производитель - производитель оборудования.

МРФ - макрорегиональный филиал ОАО «Ростелеком»;МТУ - Магистральный транзитный узел;

http://rtc.rt.ru/GD/DBP/DocLib/Forms/DispForm.aspx?ID=2202&Source=http%3A%2F%2Frtc.rt.ru%2FGD%2FDBP%2FPages%2Fpobp.aspx%3FGroupString%3D%253B%2523%25D0%2591%25D0%259F%252E%25D0%259F%25D0%25A0%252E05%2520%252D%2520%25D0%259F%25D0%25BB%25D0%25B0%25D0%252

http://rtc.rt.ru/GD/DBP/DocLib/Forms/DispForm.aspx?ID=2939&Source=http%3A%2F%2Frtc.rt.ru%2FGD%2FDBP%2FPages%2Fdbp.aspx&RootFolder=%2FGD%2FDBP%2FDocLib&ContentTypeId=0x0101000BC85B1AA3B21D4EAD739C7D20709ED0



МРУ - Магистрально-региональный узел;РУ - Региональный узел;СПД РТК - Сеть передачи данных IP/MPLS ОАО «Ростелеком»;СУ EoLBFD

Graceful restart

Flow export

---

-

-

Система управления; End Of Life, фаза прекращения жизненного цикла продукта;Bidirectional Forwarding Detection – Сетевой протокол, используется для обнаружения неисправностей между двумя пересылающими устройствами соединенных каналом;Функциональность оборудования, обеспечивающая при перезагрузке RE способность пересылать сигнальные пакеты протоколов маршрутизации и пакеты с данными;Функциональность оборудования, обеспечивающая передачу данных о потоках сетевого трафика;

MPLS

P

PE

Routing engine

SNMP

-

-

-

-

-

Multi Protocol Label Switching - Технология коммутации данных на основе меток.Provider-маршрутизатор в иерархии MPLS, занимающий первый уровень ядра сети;Provider Edge – пограничный маршрутизатор, в иерархии MPLS, занимающий второй уровень;Модуль системы маршрутизации, обеспечивающий поддержку таблицы маршрутизации, управление протоколами маршрутизации, контроль интерфейсов маршрутизатора и некоторыми компонентами шасси и обеспечивает интерфейс для управления системой;Simple Network Management Protocol – протокол управления сетевыми устройствами в IP сетях.

3 Общая информацияНа магистральной сети IP/MPLS используются маршрутизаторы ядра сети (core

router, CR), предназначеннные для передачи всех типов трафика магистральной сети IP/MPLS. Также CR обеспечивают выполнение функционала ASBR для сопряжения с присоединенными операторами и пиринг-партнерами.

4 Требования к архитектуре оборудования4.1 Маршрутизатор должен иметь неблокируемую архитектуру с неблокируемой

коммутационной матрицей. Производителем/поставщиком должна быть предоставлена информация обо всех ограничениях, связанных с пропускной способности суб-блоков и микросхем;

4.2 Должны быть зарезервированы модули управления, матрицы коммутации, блоки питания, система вентиляции:



Система электропитания 1:N, N≥1 Система охлаждения 1:N, N≥1 Плата route-processor 1:N, N≥1 Плата fabric-card 1:N, N≥1

4.3 Должна быть возможность «горячей» замены всех резервируемых модулей и линейных карт;

4.4 Система вентиляции должна быть с вертикальным проходом воздуха снизу вверх;

4.5 Температура окружающей среды от +2 С до +40 С. Относительная влажность 45-80% при температуре +25С. Работоспособность оборудования должна сохраняться при колебании температуры от 0С до +50С и относительной влажности 95% при температуре +25С;

4.6 Защита от оптического излучения должна быть согласно рекомендациям ITU-T G.664;

4.7 Аппаратура должна соответствовать требованиям EMC/ESD (Electric Membership Corporation/ Electrostatic Discharge) согласно стандарту IEC 1000 (Electromagnetic compatibility - электромагнитная совместимость);

4.8 Оборудование должно быть выполнено в стандартном 19RU форм-факторе или в собственном стоечном конструктиве.

5 Требования к производительности системы и интерфейсам 5.1 Коммутационная емкость (simplex) системы должна быть не менее 6,4Tbps с

возможностью увеличения до 12,8Tbps без замены компонентов оборудования.5.2 Неблокируемая коммутационная емкость на слот: 200 Gbps (full duplex) на

момент инсталляции системы с возможностью увеличения до 400 Gbps full duplex без замены компонентов оборудования.

5.3 Не менее 16 слотов на шасси для линейных модулей. 5.4 Поддержка линейных модулей с 10GE интерфейсами.5.5 Поддержка линейных модулей с 100GE интерфейсами.5.6 Форм-факторы трансиверов 10GigabitEthernet должны быть XFP или SFP+ или

другое при появлении более новых типов.5.7 Форм-фактор трансиверов 100GigabitEthernet должен быть CFP или другое при

появлении более новых типов.

6 Требования к функциональности оборудования6.1 Модульная архитектура ПО. Сбой отдельных программных модулей не должен

приводить к отказу всей системы. Система должан поддерживать перезапуск отдельных процессов.



6.2 При установке новой версии ПО всей системы пересылка пакетов не должна прерываться более чем на 60 секунд (при успешном обновлении).

6.3 Маршрутизатор ядра сети IP/MPLS должен обеспечивать:6.3.1 Быстрое (менее 1 секунды, желательно менее 300ms) детектирование

соседними P-узлами выхода из строя физического соединения между двумя узлами с помощью механизма BFD;

6.3.2 Быстрое (до 300ms) детектирование аппаратных и программных сбоев: Линейных плат (микрокода, ASIC-ов, etc); Системной шины (system bus); Supervisor engine/route processor/network processor/internet processor; Систем коммутации пакетов (forwarding engine, switchfabric); Роутинговых и MPLS процессов (LDP/RSVP/OSPF/BGP/IS-IS).

6.4 В случае реализации решения на базе одного резервированного маршрутизатора при аварии супервизора, либо какого-то из служебных процессов (LDP, RSVP, OSPF, IS-IS, BGP), должен обеспечиваться «non-stop routing» для протоколов LDP, OSPF, IS-IS, BGP, PIM. Служебные FIB/LFIB/ARP таблицы должны автоматически синхронизироваться между обоими супервизорами.

6.5 В каждой магистральной плоскости должны использоваться механизмы CSPF динамической прокладки LSP, MPLS Path Protection, MPLS Fast Reroute Link Protection и Node Protection.

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

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

6.8 Маршрутизаторы должны поддерживать минимально SNMP и flow export для экспорта статистических данных на внешние системы.

6.9 Должно обеспечиваться корректное дублирование snmp-счетчиков на PE маршрутизаторах в целях корректной тарификации абонентского трафика с основного RE на резервный.

6.10 Маршрутизатор должен соответствовать набору функций, приведенный в приложении 2.

7 Требования к системам управления, планирования и анализа трафика

7.1 СУ должны интегрироваться с оборудованием сети IP/MPLS.7.2 СУ должны иметь полную совместимость с протоколами IPv4 и IPv6.



7.3 Система сбора и обработки аварийных сообщений должна (минимально) обрабатывать данные со всего оборудования магистральной сети IP/MPLS.

7.4 Система мониторинга должна обрабатывать данные от всего оборудования магистральной сети IP/MPLS, клиентские подключения в объемах необходимых для обеспечения потребностей коммерческого блока.

7.5 Система анализа трафика должна обеспечивать возможность сбора данных со всех маршрутизаторов магистральной сети.

7.6 Система планирования сети должна в минимально необходимых для планирования объемах обеспечивать возможность проектирования сетевой модели.

7.7 Система визуализации сети должна обеспечивать отображение всего магистрального оборудования, а так же магистральных каналов.

7.8 Каждая система должна иметь техническую возможность для подключения АРМ в количестве необходимом для удовлетворения потребностей Технического и Коммерческого блоков.

8 Требование по взаимодействию с существующей сетью8.1 Должно быть обеспечено неконфликтное взаимодействие и полная интеграция

с уже установленным на сети оборудованием для всех функций и услуг, реализуемых на сети IP/MPLS ОАО «Ростелеком».

8.2 При вводе в эксплуатацию оборудования должен быть предусмотрен план миграции и переключения существующих объектов сети IP/MPLS.

9 Требования к управлению оборудованием9.1 Поддержка управления оборудованием с использованием командной строки по

протоколам telnet, SSH и авторизацией по RADIUS и TACACS.9.2 Поддержка возможности удалённого обновления ПО.

10 Требования к производителю оборудования10.1 Производители должны входить в ТОП-5 производителей оборудования

данного класса, которые уже эксплуатируются на сетях ведущих операторов связи.

10.2 Необходимо наличие офиса (представительства) продаж и/или сервисно-технической поддержки в РФ с целью качественного и оперативного взаимодействия с Поставщиком/Производителем оборудования.

10.3 Необходимо наличие русскоязычной технической поддержки по схеме 24х7.

11 Требования по сертификации оборудования11.1 Вся продукция должна иметь действующий сертификат «Россвязь» и иную

разрешительную документацию в соответствии с действующим законодательством РФ для применения на сети связи ОАО «Ростелеком».



12 Требования к уровню звука, создаваемому оборудованием12.1 Уровень любого акустического шума, излучаемого аппаратурой, не должен

превышать 30 дБ при контроле на расстоянии 1 м от аппаратуры (согласно публикаций МЕК 651).

13 Требования к электропитанию и заземлению13.1 Комплект аппаратуры питается по двум вводам от установки постоянного тока

с заземленным положительным плюсом и номинальным напряжением Uном = минус 48 В при изменениях напряжения на вводах питания в пределах от 40,5 до 57,0 В или номинальным напряжением Uном = минус 60 В при изменениях напряжения на вводах питания в пределах от 48,0 до 72,0 В. Переключение аппаратуры в процессе эксплуатации с одного номинала напряжения на другой не должно приводить к необходимости замены каких-либо блоков в аппаратуре.

13.2 Источник постоянного тока и распределительный щит с устройствами защиты предоставляются Заказчиком.

13.3 Поставщиком должны быть предоставлены данные о мощности электропотребления по каждому типу оборудования, включая оборудование системы управления для каждой обслуживаемой станции, в том числе пусковой ток включения по каждому вводу, как для конкретной конфигурации оборудования, так и при полном его заполнении. Если электропитание комплектов аппаратуры осуществляется от общего ввода через индивидуальные распределительные устройства стойки, то должны быть сообщены данные по индивидуальным для каждого комплекта и обще стоечным устройствам защиты и мощность, потребляемая стойкой при полном ее заполнении комплектами.

13.4 Каждый статив оборудования снабжен индивидуальными устройствами защиты для каждого комплекта аппаратуры, устанавливаемой на стативе, а также общестоечными клеммами, изолированными от корпуса, рабочего, а также защитного заземления. Необходимые для работы аппаратуры кабели питания от распределительного щита до статива поставляются Заказчиком.

13.5 Для аппаратуры, требующей бесперебойного питания переменным током с номинальным напряжением 380/220В, Заказчик поставляет устройства бесперебойного питания переменного тока соответствующей мощности.

14 Требования к составу поставляемой документации14.1 Поставщиком должны быть представлены данные о предлагаемой к поставке

эксплуатационно-технической документации в составе и объеме достаточном для осуществления монтажа, ввода в эксплуатацию и технического обслуживания (включая технические описания, инструкции по эксплуатации, руководства по монтажу и вводу в эксплуатацию, руководства оператора и администратора всех подсистем, типовые настройки оборудования для



организации предоставления услуг клиентам ОАО «Ростелеком», руководства по инсталляции ПО, полное описание всех реализованных протокольных стеков интерфейсов, описание программ и методик испытаний) оборудования, включая входящие в состав покупные (у третьих сторон) аппаратно-программные средства.

14.2 Вся документация должна соответствовать принятым стандартам. По возможности должны быть использованы стандартизированные символы и термины, рекомендованные МСЭ и МЭК.

14.3 Допускается поставка схем и спецификаций на английском языке.14.4 Документация на русском языке должна поставляться как в отпечатанном виде,

так и в электронном виде (на CD-ROM в формате Adobe Acrobat или MS OFFICE 97/2000). Использование другого программного обеспечения должно быть согласовано с Заказчиком дополнительно.

15 Требования к гарантийным обязательствам 15.1 Поставщик должен гарантировать соответствие качества оборудования

требованиям настоящих технических требований и Приложения 1.15.2 Гарантийный срок должен быть не менее 36 месяцев с момента ввода в

эксплуатацию оборудования со стороны Общества.15.3 В течение гарантийного срока Поставщик должен производить безвозмездную

замену или ремонт оборудования. Гарантии не распространяются на дефекты, возникающие вследствие некомпетентного обращения, обслуживания, хранения и транспортирования.

15.4 После истечения гарантийного срока Поставщик должен обеспечить по дополнительному договору послегарантийное обслуживание. Поставщик услуги послегарантийного обслуживания должен обеспечить состав услуг послегарантийной технической поддержки в объеме не менее, чем состав услуг гарантийной поддержки и может быть расширен по согласованию Сторон.

15.5 оборудование, включая все приобретаемые модули, на момент поставки не должно быть объявлено в статусе EoL

15.6 после объявления EoL вендор обязуется в течении пяти лет поставлять ЗИП и обеспечивать техническую поддержку по данной модели оборудования, включая все приобретаемые модули

16 Требования к ЗИП16.1 Поставщик должен представить данные о необходимом комплекте ЗИП для

обеспечения эксплуатации оборудования в течение гарантийного срока, с учетом географического разнесения предполагаемой конфигурации.

16.2 Состав ЗИП должен оговариваться в контракте на поставку оборудования.



16.3 Поставщик должен представить данные о необходимом комплекте ЗИП для обеспечения эксплуатации оборудования, исходя из требований надежности и с учетом топологии сети Заказчика.

16.4 В технико-коммерческом предложении Поставщика должен быть предложен комплект ЗИП, обязательно включающий модули, как влияющие, так и не влияющие на трафик.

16.5 Состав ЗИП должен оговариваться в контракте.16.6 Поставщик должен гарантировать продажу запчастей по всей номенклатуре

поставляемого оборудования в течение всего срока службы аппаратуры (20 лет).

17 Требования к ремонту17.1 Должна обеспечиваться возможность быстрой замены поврежденного

оборудования резервным с помощью ЗИП и исправления несъемного оборудования.

17.2 Замена съемных элементов и однотипных блоков, не содержащих элементов эксплуатационной регулировки, должна выполняться без подстройки оборудования.

17.3 Замена съемных элементов должна обеспечиваться без выключения электропитания.

17.4 Поставщик в течение срока службы оборудования обеспечивает его ремонт. После истечения гарантийного периода по требованию Заказчика Поставщик выполняет необходимый ремонт (предпочтительно в России в сервисном центре фирмы за дополнительную плату или в организованном Заказчиком при содействии Поставщика).

17.5 Время ремонта, с момента подтверждения факта приемки оборудования в ремонт до момента его возврата Заказчику, должно составлять не более 90 календарных дней.

17.6 Поставщик представляет Заказчику отчет о каждом проведенном ремонте, указывает причину повреждения и описание выполненной работы, а также ежегодно общую сводную статистическую информацию о проведенных ремонтах.

17.7 Перед передачей оборудования Заказчику, оборудование должно быть проверено в лаборатории Сервисной Службы Поставщика/Производителя с подтверждением устранения повреждения. Это необходимо в целях предупреждения ситуации повторной отправки в ремонт и угрозы не предоставления сервиса клиентам Заказчика.

17.8 Если в результате проверки в лабораториях Сервисной Службы Поставщика/Производителя оборудования, возвращенное из ремонта, диагностировано, как аварийное, Поставщик/Производитель за свой счет отправит оборудование в повторный ремонт и предоставит Заказчику эквивалентную замену в пределах установленных сроков ремонта.



18 Требования к контрольно-измерительной аппаратуре18.1 Поставщик должен предоставить рекомендованный список приборов,

необходимых для проведения эксплуатации оборудования (локализации неисправностей и их устранения, а также проверки соответствия параметров установленным нормам).

18.2 Заказчик решает вопрос о целесообразности приобретения средств измерения для эксплуатационных целей у Поставщика оборудования, либо непосредственно у фирм-поставщиков измерительного оборудования на основании анализа технических и стоимостных данных. Заказчик производит закупку измерительных приборов для технической эксплуатации по отдельным контрактам.

18.3 Контрольно- измерительное оборудование, используемое при пуско-наладочных работах, должно поставляться Поставщиком. Контрольно-измерительное оборудование должно быть укомплектовано шнурами, переходниками и приспособлениями для подключения к испытуемому оборудованию.

18.4 Приемо-сдаточные испытания должны производиться с использованием средств измерения, имеющих сертификат об утверждении типа Росстандарта РФ, свидетельства о поверке либо калибровочные сертификаты, выданные аккредитованными метрологическими лабораториями.

19 Требования к учебно-тренировочным средствам19.1 Базовый курс подготовки специалистов Заказчика проводится специалистами

Поставщика в учебных центрах Поставщика и/или Производителя. Базовый курс подготовки должен охватывать обучение по монтажу и пуско-наладке оборудования, по эксплуатации оборудования, по инсталляция ПО, обслуживанию и эксплуатации системы управления

19.2 В технико-коммерческом предложении Поставщик должен представить подробные программы курсов обучения специалистов, включая обучение работе с аппаратурой, а также те аспекты, которые связаны с обслуживанием аппаратуры, согласовать их с Заказчиком до подписания контракта.

19.3 Контрольный комплект учебных материалов должен быть передан не позднее двух месяцев до начала учебы.

19.4 Поставщик вначале обучения должен обеспечить каждого слушателя личным комплектом учебной документации на бумаге и магнитных (или оптических) носителях на русском языке.

19.5 Курс подготовки специалистов Заказчика проводится Поставщиком в учебном центре Поставщика/Производителя, не позднее, чем за месяц до начала работ по монтажу оборудования.

19.6 Поставщик должен предоставить Заказчику копию учебного программного обеспечения и право (лицензию) на его использование в учебном центре Заказчика для повышения квалификации своих специалистов.



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

19.8 По окончании проведения обучения должны слушателям быть выданы сертификаты.

20 Требования к монтажу20.1 Поставщик должен указать все мероприятия по подготовке места для монтажа,

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

20.2 Поставщик должен подготовить фактические чертежи, по которым будут выполняться монтажные работы. В комплект чертежей должны входить, как минимум (уточненные требования будут представлены в Техническом задании на планирования):

план размещения оборудования; ёмкость кроссов по сопряжению с сетью; подробные планы кабельных проводок; схемы установок оборудования электропитания; схемы аварийной сигнализации.

20.3 Поставщику разрешается вести работы на месте выполнения работ непрерывно в течение обычного рабочего дня Заказчика. Выполнение работ не должно мешать эксплуатации и обслуживанию действующей сети. Выполнение работ не должно отрицательно влиять на существующие средства связи.

20.4 Проверка смонтированного оборудования проводится совместно Поставщиком и Заказчиком. Результаты должны быть зарегистрированы и заверены.

21 Требования к испытаниям21.1 Поставщик должен пройти опытную зону по тестированию оборудования в

соответствии с утвержденной программой и методикой испытания (ПМИ) с целью демонстрации Заказчику того, что поставленное оборудование установлено и функционирует в соответствии с Техническими требованиями.

21.2 Обеспечение поставки дополнительного оборудования, необходимого для проведения испытаний и не входящего в список поставляемого оборудования Заказчику для функционирования/обслуживания Систем, является обязательством Поставщика.

21.3 Опытная зона должна проводиться представителем Заказчика с участием представителей Поставщика. Результаты должны быть зарегистрированы протоколом и заверены подписями ответственных лиц, как со стороны Заказчика, так и со стороны Поставщика.



22 Требования к безопасности и охране труда

22.1 Конструкция аппаратуры должна быть выполнена таким образом, чтобы обслуживающий персонал не подвергался опасным и вредным воздействиям электрического тока, электромагнитных полей и токсичных, химических веществ. Конструкция аппаратуры должна удовлетворять международным стандартам в области охраны труда и техники безопасности и особым требованиям Конечного Пользователя.

22.2 Конструкция аппаратуры должна исключать возможность попадания электрического напряжения на металлические детали корпусов, ручек управления. Стойки должны быть заземлены.

22.3 Все токоведущие элементы, находящиеся под напряжением, должны быть недоступны случайному прикосновению.

22.4 Клемма для заземления должна быть размещена на стойке в безопасном и удобном для подключения заземляющего проводника месте. Возле клеммы должен быть размещается знак заземления.

22.5 Величина сопротивления между клеммой защитного заземления и любой доступной прикосновению нетоковедущей металлической частью аппаратуры не должна превышать 0,1 Ом.

22.6 Сопротивление электрической изоляции токоведущих цепей, гальванически не связанных с землей, по отношению к корпусу аппаратуры должно быть не менее:

20 МОм в нормальных климатических условиях; 5 МОм при повышенной температуре; 1 МОм при повышенной влажности.

22.7 Изоляция цепей питания внутри стоек, при испытании относительно земли, в течение 1 мин должна выдерживать испытательное напряжение переменного тока частотой 50 Гц и амплитудой:

500 В - в нормальных климатических условиях; 300 В - при повышенной влажности (при снятых энергопотребляющих

деталях).22.8 На лицевой стороне блоков, соединенных с высоким напряжением, должна

быть предостерегающая надпись на видном месте.

22.9 Конструкция ручек, кнопок и других внешних деталей должна исключать какую-либо опасность для персонала.



23 Требования к условиям транспортировки и хранения

23.1 Оборудование в упакованном виде должно выдерживать транспортирование наземным, водным и воздушным транспортом (в герметизированных отсеках) при температуре от минус 50°С до плюс 50°С и относительной влажности до 95% при плюс 25°С, а также в негерметизированных отсеках самолетов при пониженном атмосферном давлении 1,2х104 Па (90мм рт.ст). Производитель должен предоставить максимальные транспортные габариты оборудования.

23.2 Аппаратура в упакованном виде должна выдерживать хранение в течение года в складских неотапливаемых помещениях при температуре от минус 40°С до плюс 40°С, среднемесячном значении относительной влажности 80% при температуре +20°С; допускается кратковременное повышение влажности до 100% при температуре не более +25°С без конденсации влаги, но суммарно не более 1 месяца в год.

23.3 Требования к условиям транспортировки и хранения не предъявляются, если ответственность за доставку и последующий монтаж возлагается на Поставщика.

24 Хранение и архивирование24.1 Подлинник данных «Технических требований к оборудованию магистральной

сети IP/MPLS ОАО «Ростелеком» во время срока действия хранится в Отделе документационного обеспечения Департамента управления делами в соответствии с требованиями Инструкции по делопроизводству в ОАО «Ростелеком».

25 Рассылка и актуализация25.1 Периодическая проверка данных «Технических требований к оборудованию

магистральной сети IP/MPLS ОАО «Ростелеком» проводится Департаментом операционной эффективности по мере необходимости, но не реже 1 раза в 12 месяцев.

25.2 Решение об инициации процесса внесения изменений в данные «Технические требования к оборудованию магистральной сети IP/MPLS ОАО «Ростелеком» принимает Технический директор на основании предложений других подразделений, анализа зарегистрированных и устраненных несоответствий, а также рекомендаций внутренних или внешних аудитов.

25.3 Порядок периодической проверки и внесения изменений в данные «Технические требования к оборудованию магистральной сети IP/MPLS ОАО «Ростелеком» определен в Процедуре управления внутренней нормативной документацией ОАО «Ростелеком».

https://my.rt.ru/companydirectory/_layouts/SVIP.CompanyDirectory/OrgUnit.aspx?id=RT_38052




25.4 Актуальная версия утвержденных «Технических требований к оборудованию магистральной сети IP/MPLS ОАО «Ростелеком» размещена на Интранет-портале в Реестре ВНД на странице Департамента планирования и развития сетей связи с указанием принадлежности к бизнес-процессу БП.ПР.05 «Планирование и развитие сети связи». Ответственность за размещение и поддержание в актуальном состоянии размещенной на Интранет-портале «Технических требований к оборудованию магистральной сети IP/MPLS ОАО «Ростелеком», а также доведение информации о месте размещения актуальных версий до всех заинтересованных подразделений несет Департамент операционной эффективности.




26 Приложение 1. Требования к составу услуг гарантийной и послегарантийной поддержки.

1. В состав услуг по гарантийной технической поддержке поставляемого оборудования и программного обеспечения (ПО) должны входить:

1.1 Услуга круглосуточной аварийной поддержки 7 дней в неделю 365 дней в году (проблемы Приоритета 1), включая работы на объекте при необходимости по согласованию сторон.

1.2 Услуга удаленной технической поддержки (Help Desk) в рабочие дни с 09:00 до 18:00 (время московское) для решения проблем Приоритета 2-4 (проблемы, не связанные с прерыванием сервиса клиентам Заказчика, угрозой жизни или здоровью людей) и консультирования уполномоченного персонала Заказчика по функциональным возможностям оборудования и ПО.

1.3 Услуга, поддержания текущей версии ПО в работоспособном состоянии путем предоставления модификаций ПО для исправления выявленных Производителем проблем (patch, maintenance release, correction release и т.п.).

1.4 Услуга по предоставлению уполномоченного сервисного менеджера (координатора) Сервисной службы Производителя по координации взаимодействия между Производителем и Заказчиком по вопросам:

1.4.1 технической поддержки,1.4.2 ремонта оборудования,1.4.3 отчетности на регулярной основе (2 раза в месяц) по:

статусу обработки заявленных Заказчиком проблем в пределах требуемых контрольных сроков (SLA – Service Level Agreement - п.5) по фактическому времени реагирования на запрос, времени восстановления аварии, времени решения;

прохождению оборудования, отправленного в ремонт – дата поступления в уполномоченные службы Производителем, дата возврата отремонтированного оборудования Заказчику, причина выхода из строя оборудования по заключению Сервисного Центра Производителя.

2. Услуги технической поддержки должны оказываться на русском языке сертифицированным персоналом Сервисной службы Производителя.

3. Производитель обязан иметь в РФ лабораторию, в которой представлены образцы оборудования и ПО для целей эффективного оказания услуг, в том числе демонстрации уполномоченному персоналу Заказчика и отработки процедур, связанных с работой на оборудовании (процедуры установки модификаций ПО и т.п.), до их исполнения на сети Заказчика, а также в целях проверки оборудования, возвращаемого из ремонта до передачи его Заказчику.

Классификация Приоритетов

Приоритет 1



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

Оборудование Заказчика, на которое распространяется действие Договора, полностью не работоспособно, что оказывает критическое воздействие на бизнес Заказчика. Работоспособность не может быть восстановлена силами Заказчика даже в ограниченных размерах. Исполнитель и Заказчик готовы использовать значительные ресурсы круглосуточно для того, чтобы ликвидировать проблему.

Некоторые примеры неисправностей Приоритета 1 (Аварийная ситуация):• Отказы сетевых элементов, их блоков (модулей), влияющие на предоставление

сервиса конечным пользователям, в случае, если уровень сервиса конечных пользователей нельзя восстановить стандартными процедурами техобслуживания, предусмотренными для данного оборудования;

• Отказы системы, ведущие к существенной потере способности системы работать с трафиком;

• Потеря функций системы, влияющих на предоставление сервиса конечным пользователям, в случае, если функции нельзя восстановить заменой запасных частей;

• Полная потеря функции вывода аварийных сообщений Системы;• Отказ системы управления или полная потеря управления сетью, притом, что

обслуживание сети становиться полностью невозможным;• Проблемы, связанные с безопасностью людей, обслуживающих Систему;• Многочисленный не одновременный выход из строя однотипных плат на

оборудовании или нарушение их основных функций.


Оборудование Заказчика, на которое распространяется действие Договора, в значительной степени не работоспособно, что оказывает серьёзное воздействие на бизнес Заказчика. Нормальная работоспособность не может быть восстановлена силами Заказчика. Исполнитель и Заказчик готовы использовать значительные ресурсы в течение полного рабочего дня.

Некоторые примеры неисправностей Приоритета 2: • Потеря некоторых функций, например:- невозможность активировать новый сервис для конечных пользователей,- невозможность произвести восстановление с системных баз данных,- потеря управления сетью и/или контроля функционирования системы

управления по отношению к сетевым элементам (без потери трафика),- выход из строя схем защиты трафика (без потери трафика).• Потеря возможности проведения диагностики.• Отказ основной или резервной рабочей станции системы управления.



• Потери трафика возникающие во время реконфигурации сервиса на сети заказчиком.

• Эпизодически возникающие проблемы с базами данных не позволяющие предоставлять сервис конечным потребителям, при отсутствии каких-либо обходных путей или временных решений.


Работоспособность Оборудования Заказчика, на которое распространяется действие Договора, значительно уменьшилась, но большинство функций сохранено.

Некоторые примеры неисправностей Приоритета 3:• Потеря возможности генерирования системных рапортов,• Проблемы, влияющие на администрирование Системы, стандартное

обслуживание и диагностику, но не влияющие существенно на предоставление сервиса конечным потребителям.

• Проблемы при выполнении документированных процедур • Ошибки в документации, приводящие к проблемам в эксплуатации.• Невозможность производить некоторые операции по эксплуатации Системы

Управления при отсутствии обходных или временных путей решения проблемы.• Отказ платы, блока питания, предохранителей, который не может быть

устранен простой заменой данного элемента.• Потеря способности Системы выводить аварийное сообщение, заданное

пользователем.• Эпизодические нерегулярные сбои в Системе, не приводящие к прерыванию

трафика.• Вопросы, связанные с неправильными измерительными данными,

полученными с использованием внутренних функций оборудования диагностики.• Проблемы управления для отдельных плат узла (без прерывания трафика).• Незначительные неудобства в работе с системой управления, или

невозможность выполнить некоторые операции без внедрения обходного решения.• Информационные запросы.

Требуемые контрольные сроки обработки проблем, заявленных Заказчиком (SLA):

Приоритет Срок реагирования

Срок восстановления

Срок решения

1 15 минут 4 часа х

2 25 минут 1 день ≤ 30 дней

3 2 часа 2 дня ≤ 60 дней



27 Приложение 2. Требования к поддержке функционала оборудования

Clause ComplianceComply

(Comply/Partial Comply)

1,1 GENERAL SYSTEMS CHARACTERISTICS AND ARCHITECTURE 1.1.1 Vendor shall furnish with functional block diagrams describing the high

level system architecture of the device. Comply1.1.12 Vendor shall list international standards, and interoperability agreements

to which the device conforms. Comply1.1.13 The hardware systems architecture shall be modular. Comply1.1.14 The control and forwarding planes shall be redundant, failover protected,

and hot swappable. Comply1.1.16 The device hardware modules shall be hot swappable, including all field

replaceable units (FRU) such as interface cards, device fabrics, packet processing modules, and controller cards. Hot swappable means the hardware modules or subsystems can be inserted or removed while the device is operational and carrying user traffic without negatively impacting the functionality and performance of other subsystems, and without affecting existing traffic that do not directly utilize the swapped subsystems. Comply

1.1.17 Vendor shall list all hardware modules that are hot swappable and those that are not. Comply

1.1.18 The device shall support redundant control-plane modules and other common critical cards. Comply

1.1.19 The system must support redundant fans and/or fan modules so that the failure of a single fan and/or fan module will not impact the operation of the system, if the system has fans. Comply

1.1.21 All device hardware components shall have part numbers and serial numbers. The serial and part numbers shall be clearly labeled on each hardware component and accessible via remote access. Comply

1.1.23 The system should allow interface modules access to full bandwidth available in the slot. Port density per slot must make maximum utilization of the slot capacity. Vendor must specify any such restrictions. Comply

1.1.24 The device chassis management system shall be capable of reporting the part numbers and serial numbers for all installed FRUs via CLI & EMS. Labels on components must match, precisely, the information provided by the chassis management system. The device shall continue to maintain the serial and part numbers for components that have failed and remain in the chassis until the components are removed from the system. Comply

1.1.25 The device shall have rack mount kit that can be adapted for 23" and 19" and ETSI compliant rack and cabinet mounting. Partially Comply

1.1.26 The system should support card-level and port-level diagnostics without requiring a reboot of the system. Comply

1.1.27 The system should support port-level diagnostics without impacting operation of other ports on the same line card. Comply

1,2 PERFROMANCE Y1.2.5 The device shall support Jumbo frames Y1.2.7 The system must have a roadmap to support higher speed interfaces (400

Gig) without any form of fork-lift upgrade Y1.3 PHYSICAL

1.3.4 Is it possible to stack equipment? If so please indicate the number of Comply



equipment per stack and provide a description1.4 RELIABILITY (MTBF)

1.4.1 Please provide in a reliability document a detailed description of the equipment (as set of boards/Field Replaceable Units (FRU)) and indicate for each FRU the predicted failure rate (MTBF) and the corresponding code (part number). Please give the name (complete, with the extension) of the reliability document in the "Information Item" column. Comply

1.4.2 Please give the standard used for reliability as well as the particular conditions (average temperature in the component vicinity and environmental factors. Comply

1.5 POWER 1.5.2 If System is -48..72 volt dc powered, the product is designed to terminate

multiple input sources (A and B feeds). Loss of a single input feed must not affect the operation of the device. Comply

1.5.3 System must provide fully redundant load-sharing power supplies (“A” and/or “B”) with independent visual alarm indicators. Comply

1.5.4 System must include a fail-safe power design. No single point of electrical, electronic, or mechanical failure in the power processing or distribution within any device should impede or disable the function of the device. Comply

1.5.5 The system must support a ‘hot-swap’ capability for power supplies without disconnecting power leads. Comply

1.5.7 Vendor must provide maximum power usage rating. Comply1.5.8 Vendor must provide typical power usage rating. Comply

1.5.26 Can you provide a power computation tool to estimate the required power according to different parameters (hardware configuration, bit rate, line attenuation, operating mode…) ?Please provide a full description Comply

1.5.27 Do the users able to get relevant traps for Power alarms? Comply1.6 ENVIRONMENT COMPLIANCE Comply

1.6.2 Certification (in Russian Federation) Comply1.6.3 The device shall be "hardened" or have a version of the device that is

hardened, compliant with IEC 61850-3 and IEEE 1613 Comply1.6.8 The device shall be NEBS level 3 compliant. Comply1.6.9 GR-63 – CORE: Network Equipment-Building System (NEBS)

Requirements: Physical Protection - Issue 3, March 2006. Comply1.6.10 GR-1089 – CORE: Electromagnetic Compatibility and Electrical Safety -

Generic Criteria for Network Telecommunications Equipment - Issue 4, June 2006. Comply

1.6.11 GR-78 – CORE: Generic Physical Design Requirements for Telecommunications Products and Equipment - Issue 1, September 1997. Comply

1.6.12 Electrical and electro magnetically security and EMC of the chassis. Does the equipment comply with following standards (EN 60950-1, (89/336/CEE) EMC, CE compliant, ETSI ES 201 468, …)Please describe if needed Comply

1.6.13 Is the Environmental Description of the product provided ?The used method and referent data needed to establish the Life Cycle Assessment have to be explained in-depth.Indicate in particular the weight of each used material. Comply

1.6.21 Do mechanics and climatic conditions of the chassis comply with ETSI ETS 300 119-2 and ETSI ETS 300 119-4?Please indicate - Sub rack depth and height (mm)- Operating range of temperature (centigrade degree)- Storage temperature: Relative humidity, operating- Relative humidity,

Comply



- storage conditions- Heat dissipation- Operating altitude- Maximum acoustic noise (dB)- Vibration- Weight (kg)

1.7 INTERFACE TYPE Y1.7.1 The device(s) shall support the following interfaces, specify the connector

type for all following interfaces in the comments column: Comply1.7.18 Ethernet interfaces shall interoperate with auto-negotiation enabled

equipment and be software programmable with respect to speed and duplex function . The default mode for auto-negotiation should be “disabled” for 10/100Mps and “enabled” for Gbps or higher interfaces. Comply

1.7.19 Autonegotiation shall be able to be enabled or disabled for all Ethernet interface types. Comply

1.7.20 The device shall support using 802.3x for flow control on the subscriber interfaces with ability to disable. Comply

1.7.21 The vendor shall identify any interfaces, protocols, encapsulation techniques, or signaling that is proprietary, non-compliant to any industry standard, or a unique extension to an industry standard. Provide plans and dates for submission and/or acceptance of these technologies to the appropriate standards body. Comply

1.7.30 The system must support Digital Diagnostic Monitoring for all optical interfaces whereby an optical power reading can be taken at a port and reported via the CLI and EMS. Comply

1.7.31 The system must support Digital Diagnostic Monitoring whereby the system monitors the optical power levels over a user-defined period and reports any crossings of user-defined thresholds via the CLI and the EMS. Comply

1.7.32 Support pluggable optics (SFP/SFP+/XFP/CFP) , especially for colored optics and passive optical systems Comply

1.7.35 The device shall support the use of third-party SFPs, XFPs, CFPs. Comply1.7.36 The device shall not use a software key to restrict the use of pluggable

optics. Comply1.7.37 The device shall provide the same functionality when using third-party

pluggable modules as is supported for supplier sourced modules. Comply1.7.40 Can the device support the capability to actively detect an external soft or

hard loopback toward any LAN or WAN port. Soft loop is defined to support MAC swapping for Ethernet frames. Hard loop is defined to be anything equivalent to connecting the transmit to the receive. Comply

1.7.59 Does the different interface provide some Telco-like features, like for instance facility-loopback capabilities, embedded test pattern generation/detection capabilities? Comply

1.7.61 Is Flow control, as specified in IEEE 802.3 Annex 31B supported and configurable? Comply

1.7.62 Do you support other manual configurations (i.e. speed, etc)? Please elaborate. Comply

1.7.63 Does the solution support the Link Aggregation functionality as specified in the IEEE 802.3? Please detail on what interfaces the LAG is supported. Comply

1.7.64 Can aggregated links be distributed on different boards? Give the maximum number of ports per LAG (possibly according the different types of interfaces) and the associated bandwidth. Comply

1.7.65 Is it possible to have a LAG with any number of ports between 1 and the maximum specified above? Comply

1.7.66 Is Load balancing of traffic over the LAG supported and programmable? Please describe the algorithm implemented and its parameters (based on

Comply



MAC@, VLAN, IP@, etc).1.7.97 For information : Is the equipment capable to transfer time/phase

synchronization via IEEE 1588 (2008) protocol through its traffic interfaces? Comply

1.7.111 The interface must support 'Jumbo' Ethernet frames up to a size of at least 9000 Bytes. Comply

1.7.112 The vendor must state the maximum frame size that the interface can support. Comply

1.7.113 The maximum frame size for the interface must be software configurable through the command line interface or other management interfaces. Comply

1.7.115 The vendor must state any features (or combinations of features) or other conditions that will result in the interface not supporting the full line rate. Comply

1.7.116 The vendor must state the maximum number of frames per-second that the interface can support. Comply

1.7.117 The vendor must state the amount of local buffer memory that is available for the interface for the purpose of buffering traffic in a congestion situation. Comply

1.7.118 In the event that buffer memory is a shared resource between multiple physical interfaces, the vendor must state the model for sharing memory between the interfaces with supporting information where relevant. Comply

1.7.119 The vendor must state the number of ingress and egress hardware queues for the proposed interface. Comply

1.7.123 The interface must provide statistical information about (at least):- Number of received frames- Number of dropped frames- Number of frames with errors- Packet and Byte count- Queue size- In case of optical interface, optical statistics (TX,RX power)This information must be accessible from the device's CLI and / or other management interface. Comply

1.7.124 The interface must support "The Interfaces Group MIB" according to RfC 2863. Comply

1.7.126 The vendor must state which specific (possibly proprietary) MIBs are supported in addition to the aforementioned standardised MIBs. Comply

1.7.127 The interface should have visual status indicators to show the status of each port. Comply

1.7.129 The vendor must state the maximum number of packets (IPv4, IPv6) per-second that the interface can support. Comply

1.7.131 The device must support 10 Gb Ethernet as defined in the IEEE standard 802.3-2008. Comply

1.7.133 The interface must support the WAN Interface Sublayer (WIS) for connection to STM-64 SDH equipment. Comply

1.7.134 The vendor must state which SONET/SDH features are supported by the interface. Comply

1.7.135 The interface must offer a modular physical interface design. This means that the optical or electrical physical interface is based on a pluggable module that is interchangeable between the different supported physical media types. Comply

1.7.136 Vendor must state which pluggable modules type should be used (XFP, SFP+). Comply

1.7.138 The vendor MUST state which transceiver modules can be installed, e.g.10GBASE-SR (Multi Mode, 850 nm)10GBASE-LR (Single Mode, 1310 nm, 10 km)10GBASE-ER (Single Mode, 1550 nm, 40 km)

Comply



10GBASE-ZR (Single Mode, 1550 nm, 80 km)10GBASE-SW (Multi Mode, 850 nm)10GBASE-LW (Single Mode, 1310 nm, 10 km)10GBASE-EW (Single Mode, 1550 nm, 40 km)10GBASE-ZW (Single Mode, 1550 nm, 80 km)CWDMDWDM

1.7.139 The interface should allow for the following physical optical interfaces to be installed:Modules with diversity of wavelengths and power budgets.Modules with tunable wavelength. Comply

1.7.146 The maximum frame size for the interface must be software configurable through the command line interface or other management interface. Comply

1.7.150 The vendor must state the amount of local buffer memory that is available for the interface for the purpose of buffering traffic in a congestion situation. Comply

1.7.151 In the event that buffer memory is a shared resource between multiple physical interfaces, the vendor must state the model for sharing memory between the interfaces with supporting information where relevant. Comply

1.7.163 The device must support 100 Gb Ethernet according to IEEE standard 802.3ba. Comply

1.7.166 The pluggable module should be of the CFP type, as specified by the Multi Source Agreement (MSA) Group. Comply

1.7.201 When Link Aggregation is enabled, the resulting logical interface must support at least a Maximum Transfer Unit of 9000 octets. Comply

1.7.203 The interface must provide statistical information about Layer 2 and Layer 3 performance and utilisation.This must include but is not limited to:- Packet and Byte count- Queue sizeThis information must be accessible from the device's CLI and / or other management interface. Comply

1.7.219 The interface must support the full line rate in both directions simultaneously. Should mention RFC2544 report for various packet size. Comply

1.7.222 In the event that the interface is oversubscribed in any way, then the vendor must provide a full description of the oversubscription model including the limitations and maximum performance that the interface (and other interfaces using the same resources) can support. This includes (but is not limited to) the amount of processing speed that the interface processor has, the connectivity to the backplane of the device (for chassis based architectures) Comply

1.7.231 The vendor must describe administrative controls for the interface's functionality. Comply

1.7.315 The interface must support Ethernet Link aggregation according to IEEE 802.1ax-2008. Comply

1.7.316 The interface must support the Link Aggregation Control Protocol (LACP) according to IEEE 802.1ax-2008. Comply

1.8 ALARMS 1.8.1 The device shall have full fault detection and isolation architecture. Comply1.8.2 The fault detection shall include hardware and software error

malfunctions. Comply1.8.3 Each fault detected shall generate an Alarm/event. Comply1.8.4 The device will support selection of traps to generate. Comply1.8.5 Alarm severity shall have a default and will be user configurable. Comply1.8.6 Alarms will indicate: alarm severity and alarm type, date and time, Comply



probable cause, device.1.8.7 Alarms will detail problems down to the device, hardware unit, card, port,

physical and logical connection. Comply1.8.8 The operator shall have the options to overwrite stored alarm data or

setup an automatic alarm file transfer function to a predetermined depository before alarm date is overwritten once the alarm storage period has been exceeded. Comply

1.8.11 The fault management function shall identify the fault as hardware or software specific. Comply

1.8.12 Alarms and Problem Reports shall be sent to the following systems: Comply1.8.12.1 · Local Craft Interface Comply1.8.12.2 · Problem Log Comply1.8.12.3 · Alarm Log (disk) Comply1.8.12.4 · Shelf Alarm Panel (visual and audible) Comply1.8.12.5 · Up to 8 destination remote peripheral device, such as a device OSS or

Network Management System Comply1.8.14 The device will support 8 destination IP address for reporting to remote

Management platforms. Destination addresses can be set via the craft, telnet and Management system. Comply

1.8.16 The information should be attainable from the Ethernet MIB/RMON MIB. If a standard is developed in the future to deal with these issues, it should be followed. Comply

Software



2,1 Describe your operating system (OS) name and the release frequency of new version Comply

2,2 Is your OS common to multiple platforms? Please elaborate. Comply2,3 Does you operating system supports batch/cron jobs and/or scripts

running in background ? Comply2,4 Does your operating system offer a shell mode (to access

Unix/Linux like commands, process management, directory arborescence browsing, etc.) ? Comply

2,5 Is your operating system based on a linux/Unix kernel ? Which one ? Comply

2,6 Does the software design include a sufficient process modularity to provide fault isolation for all software components (through protected memory space for example) ?If so, please elaborate on this modularity and its impact on the globalavailability. Comply

2,7 Do you implement process placement and/or process split into different cards or routing engine? Please elaborate in details, especially for a multi-shelf configuration. Comply

2,8 Is it possible to restart only a process without impacting others? If so, please elaborate. Comply

2,1 Is it possible to safety power down by CLI any hardware part (linecard, Routing processor, Fantray...) into a chassis ? Comply

2,11 Do you support ISSU between two minor releases in the same major release? Please elaborate on any restrictions about minimum release number, card restart or enabled services. Please give the

Comply



average service impact in duration.2,12 Do you support ISSU between two major releases? Please elaborate

on any restrictions about minimum release number, maximum major release gap, card restart or enabled services. Please give the average service impact in duration. Comply

2,13 Is your ISSU capability based on non stop routing feature (when no routing session or FIB information or layer 2 adjacency status is lost)? Comply

2,14 Vendor should list all protocol and hardware capabilty for ISSU support? Comply

2,16 What are the update modes for ISSU? Please elaborate on file transfer method Comply

2,17 Are any check regarding fimware integrity and/or confidentiality implemented? Describe the method used Comply

2,18 Does your implementation of ISSU requires some restart of Linecards or forwarding engine ? Elaborate on how long traffic is disrupted when forwarding plane is upgraded. Comply

2,2 Does the equipment support a multiple stage configuration mechanism? If so, what are the commands available for each stage? Comply

2,21 Does the equipment provide a configuration commit capability? Please elaborate. Comply

2,22 Does the equipment provide a configuration rollback capability? Please elaborate. Comply

2,23 Does the equipment provide a configuration semantic check? Please elaborate. Comply

2,24 Does the equipment provide a command completion inline? Please elaborate. Comply

2,26 Does the equipement provide an automatic configuration archival function locally (each time configuration is changed, old one is stored) ? How many configurations could be stored? Comply

2,27 Does the equipment provide a configuration comparison function ? (comparing between current and old one, and between two olds). Comply

2,28 Does the equipment support configuration templates (specifically MTU interface configuration)? Comply

2,29 Does the equipement support multi administrators configuration at the same time and a way to commit only one's changes ? Comply

2,3 Does the equipement support a way to prevent multi edition of the configuration by two administrators at the same time ? Comply

2,31 Does the equipment support a "replace pattern" configuration feature ? Comply

2,32 Does the equipement provide a way to apply a configuration change at a specified time (i.e. not right after the commit) ? Comply

2,33 Does the equipment provide a way to save a configuration without applying it right away (to edit the configuration change afterwards) ? Comply

2,34 Is there any mechanism to backup restore a configuration? Indicate how it is protected and which underlying protocols can be used. Comply

2,35 Is it possible to run CLI commands into edition mode ? Comply2,36 Does the CLI have options filter outputs (match, begin, find, count...) Comply



?If so, list the outputs

2,37 Is it possible to push a configuration file in edit mode? Comply2,4 Ability to back out of a software installation for the network

element: The platform shall have the ability to back out of an installation of a new software version and resume operation under the previous software version that has been reset to the previous operational configuration. This ability shall be provided prior to full operation under the new version and shall reset the new software to the previous operational configuration. Comply

2,41 Status Messages: The platform software shall provide incremental status messages to the user as stages of the upgrade are completed. Comply

2,42 Backward compatibility of software releases for the network element: All network element software releases shall be backward compatible to ALL previous release. Comply

2,43 Ability to detect software version number for the network element: The software version number of the platform shall be retrievable from all user interfaces. This requirement includes the ability to distinguish between different software “point” releases delivered during testing. Comply

2,44 Warning of improperly configured software for the network element: The software update procedure shall verify that the network element is in the proper configuration to apply the update. The software shall provide the user with ample warnings for an improperly configured system, and the user must be required to override the warnings manually. Comply

2,45 Network element software reset: The network element shall have the capability to have its system level and shelf level control software individually reset through a software-reset command available at the craft interface terminal command line interface and at the EMS. Comply

2,46 Duration of network element software reset: All network element software resets of system level and shelf level control software shall be completed within five (5) minutes, regardless of whether the command was issued at the craft interface terminal command line interface or at the EMS. Network element software reset shall be considered completed when the network element is completely visible again to the OSS. Comply

2,47 Remote network element software reset: The network element shall have the capability to have its system level and shelf level control software individually reset remotely (such as through remote access to a contact closure) in the event that the software becomes unresponsive to command requests. A software-reset command available from the EMS is not sufficient to satisfy compliance with this requirement. Comply

2,48 Local network element software reset: The network element shall have the capability to have its system level and shelf level control software individually reset locally in the event that the software becomes unresponsive to command requests. This capability shall not require the extraction and reinsertion of Line Cards. This capability shall require at least two steps (such as reset enable followed by a reset initiation). A software-reset command from the

Comply



craft interface terminal command line interface is not sufficient to satisfy compliance with this requirement.

2,5 No service-affecting network element software resets: All network element software resets shall have no affect on service traffic or network element management and control functions. All customer service and configuration data shall not be affected by software resets. Comply

2,51 Modular software: The software shall be modular in design to the extent that any module/component of the running software image can be installed, upgraded, troubleshoot without affecting other modules/components of the running software image.

NOTE: this requirement applies to the implementation of Bug fixes and patch release upgrades that can be implemented without impacting the entire code. Comply

2,53 Modular Software restart: Restarting of a software module shall not affect other modules Comply

2,56 Support timed load: The core router/switch shall have the capability to be programmed to reload/restart itself at a set future time and date. Comply

2,61 Quality: What quality techniques were used in development of the software? For example were fault trees or walkthroughs used? Please supply documentation of techniques used. Comply

2,64 Installed Base: Is this software currently in use? Where and how long? Provide contact names. Comply

2,65 How many installations are still in service? Comply2,66 Other Software: Has the vendor previously produced similar

software? Where and when was it installed? What are the similarities and differences? Comply

2,68 Release Testing: Can new releases, patches and upgrades be installed without affecting service? Has this been tested? Describe the testing procedure. Comply

2,72 Documentation: The vendor must supply software documentation. How is complete documentation ensured? Comply

2,73 Software Patches: How many patches have been made to each previous release and over what time period? Comply

2,74 Release Cycle: What is the major release cycle – how often is there a new release? Comply

2,91 How do the software subsystems communicate with each other? Please provide a detailed description of inter-process communications architecture. Comply

2,92 Please describe how contention for shared resources is arbitrated between different software subsystems and between different instances of the same software system. Comply

2,93 Please describe how the consistency of replicated information is maintained within the device. Comply

2,94 Does the software provide an open API to allow third party development of value added applications? If so, please explain. Comply

2,96 How frequently are minor software releases scheduled? Comply2,98 Does the platform support a SDK (Software Development Kit) to

develop "integrated" applications that leverage the Comply



control/forwarding plane of the device?

Protocols & Services



3,00 Protocols

3,01 The device must implement the Internet Protocol Version 4 according to RfC 791. Comply

3,02 The device must implement Internet Control Message Protocol according to RfC 792. Comply

3,03 The device must implement Transmission Control Protocol (TCP) according to RfC 793 / RfC 1323. Comply

3,04 The device must implement User Datagram Protocol (UDP) according to RfC 768. Comply

3,05 The device must implement Domain Name Service (DNS) client functionality for resolving hostnames. Comply

3,06 The device must implement Address Resolution Protocol (ARP) according to RfC 826. Comply

Staic Routing 3,07 support IPv4 static routes Comply3,08 support IPv6 static routes Comply3,09 support multicast IPv4 static routes Comply3,10 support multicast IPv6 static routes Comply3,11 Is it possible to associate a description to static route Comply3,12 Do you support Tag or BGP community setting on static routes? Comply3,13 Do you support static route pointing to recursive nexthop (BGP route for

example) ? Comply3,14 possible to change the static route's distance administrative value Comply3,15 Do you support static route with any type of interface as Next Hop

(Physical, Loopback, Lag, Tunnel)? Comply3,16 Do you support static route with multiple next-hops for the same prefix? If

so, please tell the maximum number of next-hops assignment for a prefix. Comply3,17 Is it possible to keep a static route up when the related outgoing interface

is down ? Comply3,18 Do you support static route with a next-hop which is not in a directly

connected subnet ? Comply3,19 Does your implementation offer a mechanism to allow a fast next-hop

failure detection which will enhance the convergence? Comply ISIS

3,56 Is the IS-IS routing protocol implemented according to RFC1142 and RFC1195? Comply

3,57 Is your IS-IS implementation event-driven? Comply3,58 Is it possible to change the IS-IS routing distance administrative value? Comply3,59 Do you implement the traffic-engineering router ID (TLV 135) as defined in

RFC 5305? Comply3,60 Does your implementation offer to tune LSP-generation timer and transit

LSP pacing ? Comply3,61 Is ISIS process/task an high priority task compared to BGP, management,

CLI ... Please elaborate on how ISIS could be impacted by other processes. Comply3,62 Do you support IPv6 TLVs in compliance with RFC5308? Comply3,63 Do you implement inter-level prefix redistribution in IS-IS as defined in Comply



RFC5302?3,64 Do you support prefixes leaking from level-1 to level-2? Please elaborate on

the possibility to control such redistribution (access-list based, etc). Comply3,65 Can your implementation provide a maximum limit of redistributed

prefixes in IS-IS per IS-IS database? Comply3,66 For passive interface, are your routes injected into IS-IS with metric 0? Comply3,67 Do you implement IS-IS administrative tags as defined in RFC5130? Comply3,68 Can your implementation make use of partial SPF calculations? Please

elaborate on your SPF calculations implementation (i.e. when partial runs or full runs occur, is it timer-driven or event-driven, etc) Comply

3,69 Is it possible to tune the SPF timers? Please elaborate on your algorithm implementation and the relation between the timers. Comply

3,70 Do you implement IS-IS fast flooding (i.e. ensuring that LSP that triggers a SPF calculation is flooded before the SPF computation is run)? Comply

3,71 Do you support AFI 49 in the ISO address? Comply3,72 Is it possible to configure the system NET address? Comply3,73 Is it possible to set up the overload-bit, per IS-IS database, permanently or

for a configured period of time? Please elaborate, especially for the behaviour when the router is (re)started. Comply

3,74 Is it possible to use high metrics in the same fashion as the overload-bit (for restarting or "waiting for BGP" cases")? Please elaborate. Comply

3,75 Is LSP Authentication type 1 (clear text password) in IS-IS implemented (per domain and per area)? Comply

3,76 Is LSP MD5 authentication in IS-IS implemented (per domain and per area)? Comply

3,77 Do you support point-to-point configuration for Ethernet-family interfaces (i.e. disabling pseudo-node election) as defined in RFC5309? Comply

3,78 Do you provide a feature to clear pseudo-nodes responsibility hosted by the router? Please provide the maximum number of pseudo-nodes the system can bear. Comply

3,79 Is it possible to set priority for DIS election mecanism ? Is it possible to set it per isis level ? Comply

3,80 Is your implementation able to use the padding TLV in IIH messages as an option? Please elaborate on the possible configurations of this padding feature. Comply

3,81 Does your implementation offer to tune the LSP lifetime and the LSP refresh timers? Comply

3,82 Do you support LSP fragmentation in at least in 10 parts? Please give the maximum number of fragments supported. Comply

3,83 Do you support IS-IS mesh-groups in compliance with RFC2973? Comply3,84 Do you support multi-topology and/or multi-instance IS-IS as defined

respectively in RFC5120 and in draft-ietf-isis-mi-06? Please elaborate on your implementation behavior in case of MT and MI? Please explicit if there are features not supported or features need to be configured to active. Comply

3,85 Do you implement MIB for IS-IS as defined in RFC4444? Comply3,86 What is the number (max) of isis equal cost path can be used. Is it

configurable? Comply3,87 Is it possible to configure the isis synchronisation with ldp ? Comply3,88 Do you support LFA SPF computation for IS-IS in compliance to RFC5286? Comply3,89 Do you support SRLG extention for IS-IS? Comply

BGP 3,90 Is your BGP-4 implementation compliant to RFC4271? Please describe your

BGP best-path selection algorithm. Are MED always compared on BGP best-path selection? If interoperabilty testing have been done successfully, please detail. Comply



3,91 Do you support AFI/SAFI 1/4 and 2/4 ? and cross-connecting BGP LSPs with LDP LSPs (LSP stitching) ? Comply

3,92 Is it possible to change the BGP administrative distance for extrernals/internals/locals routes ? Comply

3,93 Do you implement a "BGP peer-group"-like feature that allows for instance to apply a routing policy to a group of BGP-4 sessions? If so, please elaborate on the possibility, name, maximum numbers and potential impact on CPU and convergence times of the feature. Comply

3,94 Are BGP-4 communities implemented according to RFC1997? Please elaborate if your implementation supports communities which may impact the BGP best-path selection process. Comply

3,95 Is route reflection mechanism implemented according to RFC4456 (including the cluster-id capability)? Please detail how your BGP best path algorithm is modified to adapt to BGP route reflection. Comply

3,96 Is your route reflector implementation able to modify attribute capabilities such as next-hop and community values? If so, please elaborate on the possible modification and the feature name. Comply

3,97 Is BGP-4 route refresh implemented according to RFC2918? Comply3,98 Is route flap dampening implemented according to RFC 2439? If so, please

tell if per-session configuration is supported. Comply3,99 Are Multi-Protocol extensions to BGP-4 implemented according to

RFC4760? Please elaborate on the impact of manipulating different AFI/SAFI types on the number of entries that can be stored and maintained in the Adj-RIB-In, loc-RIB and Adj-RIB-Out tables of the implementation. Comply

3,100 Do you support AFI/SAFI tuple value (2,1), i.e. unicast IPv6 extensions for MP-BGP according to RFC 2545? Comply

3,101 Is BGP cease code implemented according to RFC 4486? Comply3,102 Do you support BGP-4 capabilities announcements as defined in RFC5492? Comply3,103 Can one session between two BGP-4 peers be established between any

kinds of interfaces, and especially between Loopback interfaces? Comply3,104 Is TCP MD5 signature for BGP-4 sessions implemented according to

RFC2385? Comply3,105 Is TCP Authentication Option for BGP-4 sessions implemented according to

RFC5925? Partial Comply3,106 Does your implementation offer BGP private AS numbers removal before

an advertisement to a different AS? Comply3,107 Is BGP TTL security Mecanism implemented as defined in RFC3682? Partial Comply3,108 Is your BGP-4 implementation event-driven? In any case, please elaborate

on any solution to enhance this mechanism in order to improve the BGP convergence. Comply

3,109 Does your implementation offer a mechanism to allow a fast next-hop failure detection which will enhance the BGP convergence? Please elaborate on the name and the mechanism detail. Comply

3,110 Does your implementation react in an event-driven mode to IGP topology changes in order to trigger best-path recalculation? Comply

3,111 Does your implementation support static routes redistribution into BGP-4 with filtering? Please explain criteria for redistribution (base on tag, ACL or Prefix List). Comply

3,112 Does your implementation support IPv4 routes redistribution from IS-IS into BGP-4? Comply

3,113 Does your implementation support IPv6 routes redistribution from IS-IS into BGP-4? Comply

3,114 Does your implementation support DDoS dynamic prevention as defined in RFC 5575? Comply

3,115 Is your implementation able to automatically restrict incoming TCP Comply



connections towards TCP port 179 (TCP port for BGP) to the IPv4 address of the configured BGP peers?

3,116 Is your implementation able to automatically restrict incoming TCP connections towards TCP port 179 (TCP port for BGP) to the IPv6 address of the configured BGP peers? Comply

3,117 Is your implementation able to limit the number of advertised and received BGP prefixes? If so, is it also able to send SNMP traps and/or warning to syslog and/or tear down the session? Comply

3,118 Do you support outbound route filtering as defined in RFC5292? Comply3,119 Is it possible to create ACLs (whitelist/blacklist) on BGP peers? Comply3,120 Is the BGP TCP MSS (maximum segment size) configurable? Comply3,121 Do you support path-MTU discovery on TCP sessions for BGP-4? Comply3,122 Is it possible to tune the DSCP value for BGP packets? Please elaborate on

the BGP-4 packets (keepalive and update) handling in the equipment and DSCP default values. Comply

3,123 Do you support BGP-4 MRAI (MinRouteAdvertisementIntervalTimer as defined in RFC4271)? If so, please elaborate on the configuration options with min-max values. Comply

3,124 Do you support AS_path attribute for 4 byte ASes in compliance with RFC4893? Comply

3,125 Do you implement the advertisement for multiple paths in BGP-4 as defined in draft-ietf-idr-add-paths-06.txt" Especially n paths and all paths. Elaborate on supported models and restrictions Comply

3,126 If ADD-PATH supported, please elaborate on which address families are supported Comply

3,127 Regarding Route-Refresh, when a BGP speaker is currently serving a route-refresh request (RIB-out advertisement) to a peer, does your implementation permit to send transient updates to the peer while the RIB-OUT (for route-refresh) is sent or are the transient updates queued (peer stuck) until RIB-OUT advertisement is finished ? Comply

3,128 Does your implementation support "local-as" feature, we mean peering by using an AS which is different from the one configured globally on the node. Comply

3,129 The device must support the BGP Conditional Route Injection feature. It allows to inject more specific prefixes into a BGP routing table over less specific prefixes that were selected through normal route aggregation. These more specific prefixes can be used to provide a finer granularity of traffic engineering or administrative control than is possible with aggregated routes. Partial Comply

3,130 The device must support BGP Policy Accounting that provides a means of charging customers according to the route that their traffic travels. Comply

3,131 The device should provide BGP Support for Dual AS Configuration for Network AS Migrations. Comply

3,132 The device must support BGP Multiple Topology Tables (MTR). Comply3,133 The device must support BGP address tracking to trigger path re-

calculation upon changes of the BGP next-hop internal routes. Comply3,134 The device must provide a mechanism that allows the network

administrator to limit the maximum number of Autonomous Systems in AS-PATH, which will be included in the BGP routing table. Comply

3,135 The device must support eBGP Multihop for peering between eBGP neighbours which are located in different IP subnets. Comply

3,136 The maximum number of hops that are allowed to establish an eBGP Multihop session, must be configurable based on RFC 3682. Comply

3,137 The device must support eBGP Multipath for peering between eBGP neighbours to load balance traffic through two or more lines (routes). Comply

3,138 Multipath routing must not be implemented in a round-robin (per packet) Comply



fashion. Flow-based Multipath routing must be supported.3,139 The device must support AS path prepending. Comply3,140 BGP - Support for disable-connected-check for eBGP Neighbours Partial Comply3,141 The device must support Route Distribution between routers with support

of iBGP Router Next-Hop self. Comply3,142 The device should implement recursive lookups within the iBGP Routing

domain. Comply3,143 The device must implement a Route Reflector client for iBGP according to

RfC 4456. Comply3,144 If the device implements "Route Reflector client for iBGP" according to RfC

4456, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,145 The route reflector client should be dynamically configurable to use the preconfigured list of Route Targets to construct its inbound route filtering, and install this on each of its BGP peers via the Outbound Route Filters feature described in RfC 5291. Partial Comply

3,146 If the device implements "Outbound Route Filtering" according to RfC 5291, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Partial Comply

3,147 The device must support the Link Bandwidth Community for unequal iBGP load balancing. Comply

3,148 The device must implement a BGP Route Reflector according to RfC 4456 "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)" Comply

3,149 If the device implements "BGP Route Reflector" according to RfC 4456, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,150 The device must implement Path MTU Discovery for the BGP session. Comply3,151 The device must implement "Route Refresh Capability for BGP-4"

according to RfC 2918. Comply3,152 If the device implements "Route Refresh Capability for BGP-4" according to

RfC 2918, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,153 The device must allow the configuration of the interval used by the BGP Process to scan the BGP Table to improve BGP convergence times. Comply

3,154 The device must allow the configuration of the advertisement interval between BGP Peers to improve BGP convergence times. Comply

3,155 The device must implement "BGP Route Flap Damping" according to RfC 2439.BGP Route flap configuration - although the RfC defines various parameters and sub parameters the below are expected as minimum requirements for configurable values:- Decay time- Dampening threshold value- Reuse threshold value- Maximum suppression time Comply

3,156 The vendor must support configurable grouping of similar peer policy enforcement, i.e. creation of a group of peers with a common function such as iBGP Route Reflectors, this ensures that only a single BGP update is created for all members reducing CPU utilisation (any vendor configuration limitations need to be advised if the function is supported). Comply

3,157 The device must implement "BGP Communities Attribute" according to RfC 1997. Comply

3,158 If the device implements "BGP Communities Attribute" according to RfC 1997, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,159 The device must support "An Application of the BGP Community Attribute Comply



in Multi-home Routing" according to RfC 1998.3,160 If the device implements "An Application of the BGP Community Attribute

in Multi-home Routing" according to RfC 1998, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,161 The device must implement the Site of Origin (SoO) attribute used as a Route Origin Extended Community [BGP-EXTCOMM]. The Site of Origin attribute identifies a particular site. A route must never be redistributed to any other BGP speaker at that site if the SoO match . Comply

3,162 The proposed device must support syslog logging connected to BGP events (e.g. support of neighbour change logging). Comply

3,163 The vendor must provide a mechanism that allows the network administrator to limit the maximum prefixes learned per peer. Comply

3,164 The vendor must describe the reaction (per peer) that the router will take if the maximum number of prefixes is reached (per peer). This may include:-Shutdown of the BGP session (restart session in defined time)-Alarm to syslog or generation of SNMP traps.In addition the device must be able to generate warning messages (e.g. syslog, SNMP trap) when the configurable limit of prefixes is learned (per peer). Comply

3,165 The device must implement BGP outbound route filtering. Comply3,166 The device must implement BGP inbound route filtering. Comply3,167 The device should implement BGP Prefix-Independent Convergence. Comply3,168 The device must implement "Definitions of Managed Objects for BGP-4"

according to RfC 4273. Partial Comply3,169 If the device implements "Definitions of Managed Objects for BGP-4"

according to RfC 4273, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Partial Comply

3,170 The vendor must describe administrative controls for BGP. Comply3,171 The vendor proposed device must support default route distribution

through BGP. Comply3,172 The device must support application of new route policies without clearing

whole BGP session. Comply3,173 The device must implement route policies (prefix propagation e.g. to

neighbors, routing table) based at least on AS-path, attribute. Comply3,174 The device must implement BGP authentication support for HMAC-SHA1-

96. Comply3,175 The device must implement BGP authentication support for SHA1. Comply3,176 The device must support the configuration for hiding the local ASN in order

to not prepend the local AS to updates from eBGP peers to ease AS migration. Comply

3,177 The vendor must support the MIB (Management Information Base) for the Border Gateway Protocol Version 4. Specifically it must support the network management protocol SMIv2 to handle the BGP-4 managed objects. Comply

3,178 Does your implementation support a dampening mechanism for BGP session flap ? We mean to slowdown establishment of BGP session when it is flapping too fast. Please elaborate on what are the configurable parameters or what are the default timers. Comply

3,179 Do you implement the MIB for BGP-4 as defined in RFC4273? Comply3,180 Do you implement support "best external route" as define in draft-ietf-idr-

best-external-02.txt? Comply3,181 Do you support RPKI? Please describe the implemented features.

(RPKI refers to RFCs between 6480 and 6492) Comply3,182 Can route policies be configured recursively? Please detail the maximum

number of policies in that case. Comply



3,183 The Route Reflector should support Outbound Route Filters according to RfC 5291. Comply

3,184 If the device implements "Outbound Route Filtering" according to RfC 5291, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,185 The device should implement BGP path diversity. Comply3,186 Does your implementation offer a way to check a policy attach point in the

configuration? Comply3,187 Does your implementation offer a way to test a policy on a prefix before its

application in live? Comply3,188 The device must implement the Border Gateway Protocol 4 (BGP4)

according to RfC 4271. Comply3,189 The device must implement "Multiprotocol Extensions for BGP-4"

according to RfC 4760. Comply3,190 The device must implement "Capabilities Advertisement with BGP-4"

according to RfC 5492. Comply3,191 The device must implement IPv6 routing on BGP4 according to RfC 2545

"Use of BGP-4 Multi-protocol Extensions for IPv6 Inter-Domain Routing". Comply3,192 The device should implement the Autonomous-System-Wide Unique BGP

Identifier for BGP-4 according to RfC 4271. Comply3,193 The device should implement BGPv4 MIB according to the IETF draft 'draft-

ietf-idr-bgp4-mibv2-12'. Partial Comply3,194 The device must implement "BGP-MPLS IP Virtual Private Network (VPN)

Extension for IPv6 VPN" according to RfC 4659. Comply IPv6

3,196 Do you support neighbour discovery for IPv6 in compliance with RFC 4861 and updated RFC 5942? Comply

3,197 Do you support path MTU discovery in compliance with RFC 1981? Comply3,198 Do you support ICMPv6 in compliance with RFC 4443? Comply3,200 Do you support IPv6 Stateless Address Auto-configuration in compliance

with RFC 4862? Comply3,201 Do you support IPv6 Global Unicast Address Format in compliance with

RFC 3587? Comply3,202 Do you support Unique Local IPv6 Unicast Addresses in compliance with

RFC 4193? Partial Comply3,203 Does the implementation restrict the use of subnet anycast IPv6 addresses

as per RFC 2526? If so, please elaborate. Comply3,205 The device must implement the IPv6 specification according to RfC 2460. Comply3,206 The device must be able to send and receive IPv6 datagrams according to

section 2 of RfC 2460. Comply3,207 The device must implement the forwarding of IPv6 datagrams according to

section 2 of RfC 2460. Comply3,208 The device must process extension headers according to section 4 of RfC

2460. Comply3,209 The device must implement the correct extension header order according

to section 4.1 of RfC 2460. Comply3,210 The device must respond to unrecognized option headers as described in

section 4.2 of RfC 2460. Comply3,211 The device must process Hop-by-Hop headers according to section 4.3 of

RfC 2460. Comply3,212 The device must process routing headers according to section 4.3 of RfC

2460. Comply3,213 The device must send, receive and process fragment headers according to

Section 4.5 of RfC 2460. Comply



3,214 The device must implement the Destination Options Header according to section 4.6 of RfC 2460. Comply

3,215 The device must not forward datagrams with Type 0 Routing Headers according to RfC 5095. Comply

3,216 The device must implement the IPv6 Router Alert Option according to RfC 2711. Comply

3,217 The device must implement ICMPv6 according to RfC 4443. Comply3,218 The device must implement Path MTU Discovery for IPv6 according to RfC

1981. Comply3,219 The device should implement Packetization Layer Path MTU Discovery

according to RfC 4821. Comply3,220 The vendor must state whether the device implements IPv6 Jumbograms

according to RfC 2675. Comply3,221 The device must perform the forwarding of IPv6 packets at roughly the

same rate as the forwarding of IPv4 packets. Comply3,222 The device must implement configuration of IPv6 static routes. Comply3,223 The vendor must provide information about any limitations on configuring

IPv6 on the proposed device. Comply3,224 The vendor must state any performance impact that configuring IPv6 has

upon their proposed device at both the interface and chassis level. Comply3,225 The device must implement Neighbor Discovery for IPv6 according to RfC

4861. Comply3,226 The device must implement Router Discovery according to section 6 of RfC

4861. Comply3,227 The device must implement Prefix Discovery according to section 6 of RfC

4861. Comply3,228 The device must implement Message Validation according to section 7.1 of

RfC 4861. Comply3,229 The device must implement Address Resolution according to section 7.2 of

RfC 4861. Comply3,230 The device must implement Neighbor Advertisement and Neighbor

Solicitation processing according to RfC 4861. Comply3,231 The device must implement Duplicate Address Detection according to

section 5.4 of RfC 4862. Comply3,232 The device must implement Neighbor Unreachability Detection according

to section 7.3 of RfC 4861 Comply3,233 The device must implement Redirect functionality according to section 8 of

RfC 4861. Comply3,234 The device must implement IPv6 Stateless Address Autoconfiguration

according to RfC 4862. Comply3,235 The device must implement Creation of Link Local Addresses according to

section 5.3 of RfC 4862. Comply3,236 The device must implement Duplicate Address Detection according to

section 5.4 of RfC 4862. Comply3,237 The device must implement Creation of Global Addresses according to

section 5.5 of RfC 4862. Comply3,238 The device should implement the ability do disable creation of Global

Unicast Address Comply3,239 The device must implement the IPv6 Addressing Architecture according to

RfC 4291. Comply3,240 The device must allow the operator to manually configure IPv6 addresses

through the Command Line Interface or other remote management facility. Comply3,241 The device must implement Default Address Selection for IPv6 according to

RfC 3484. Comply3,242 The device should implement Configurable Selection Policies according to Comply



section 2.1 of RfC 3484.3,243 The device must implement Reserved IPv6 Subnet Anycast Addresses

according to RfC 2526. Comply3,244 The device must support Dual-Stack (both IPv4 and IPv6 protocol stack)

according to RfC 4213. Partial Comply3,245 The device must implement MLD Version 2 for IPv6 according to RfC 3810. Comply3,246 The device must support any Redundancy Default Gateway Proprietary

Protocol over an IPv6 protocol. Comply3,250 The device must implement IPv6 over Ethernet according to RfC 2464. Comply3,251 The device must implement Address Mapping of IPv6 Multicast Packets on

Ethernet according to RfC 6085. Partial Comply3,252 The device must implement Secure Neighbor Discovery according to RfC

3971. Partial Comply3,253 The device must implement Cryptographically Generated Addresses

according to RfC 3972. Comply3,254 The device must implement the Extension Field Format according to RfC

4581. Comply3,255 The Supplier shall state all features that are not supported in IPv6 or

supported in a limited fashion. Compliant3,258 Support Destination Based Logging (DBL) Compliant3,259 The device MUST implement the IPv6 specification according to RFC 2460. Compliant3,260 The device MUST implement ICMPv6. Compliant3,261 The device MUST implement Path MTU Discovery for IPv6 according to

RFC 1981. Compliant3,262 The device SHOULD perform the forwarding of IPv6 packets at roughly the

same rate as the forwarding of IPv4 packets. Compliant3,263 The device MUST implement configuration of IPv6 static routes. Compliant3,265 The vendor MUST provide information about any limitations on

configuring IPv6 on the proposed device. Compliant3,266 The vendor MUST state any limitations to the number of routes in the

routing table. Compliant3,267 The device MUST implement IPv6 aware anti-spoofing feature such as

Reverse Path Forwading according to RFC 3704 that can be applied to any interface. Compliant

3,268 The device MUST implement Neighbor Discovery for IPv6 according to RFC 4861. Compliant

3,269 The device MUST implement Router Discovery according to section 6 of RFC 4861. Compliant

3,270 The device MUST implement Prefix Discovery according to section 6 of RFC 4861. Compliant

3,271 The device MUST implement Message Validation according to section 7.1 of RFC 4861. Compliant

3,272 The device MUST implement Address Resolution according to section 7.2 of RFC 4861. Compliant

3,273 The device MUST implement Neighbor Advertisement and Neighbor Solicitation processing according to RFC 4861. Compliant

3,274 The device MUST implement Duplicate Address Detection according to section 5.4 of RFC 4862. Compliant

3,275 The device MUST implement Neighbor Unreachability Detection according to section 7.3 of RFC 4861 Compliant

3,276 The device MUST implement Redirect functionality according to section 8 of RFC 4861. Compliant

3,277 The device MUST implement IPv6 Stateless Address Autoconfiguration according to RFC 4862. Compliant



3,278 The device MUST implement Creation of Link Local Addresses according to section 5.3 of RFC 4862. Compliant

3,279 The device MUST implement Duplicate Address Detection according to section 5.4 of RFC 4862. Compliant

3,281 The device SHOULD implement MLD Version 2 for IPv6 according to RFC 3810. Compliant

3,284 The device SHOULD implement IPv6 routing with the IS-IS protocol according to RFC 5308. Compliant

3,285 The device MUST implement IPv6 routing on BGP4 according to RFC 2545 "Use of BGP-4 Multi-protocol Extensions for IPv6 Inter-Domain Routing". Compliant

3,294 The vendor MUST provide additional capacity constraints regarding features that can be activated per dual stack Subscriber session Compliant

3,295 max number of Policies (in/out) Compliant3,296 max number of ACLs (in/out) Compliant3,297 max number of QoS Profiles Compliant3,298 other resources that are affected by Dual Stack activation Compliant3,336 The vendor SHOULD provide information about extra hardware

requirements for supporting IPv4 migration mechanisms. The vendor MUST provide information about capacity limitations in regards to these mechanisms Compliant

Virtual Router 3,340 Do you support the “Virtual Router” (VR) function (i.e. the ability to

configure several logical routers within the physical equipment)? Please elaborate on your implementation (mainly the process and table isolation) and the maximum number of VR supported. Compliant

3,341 Can your virtual router (VR) use only some interface or sub-interface? Please elaborate on your granularity and if you can create virtual interface (specify if a dedicated hardware is then needed). Compliant

3,342 Is your VR process hosted in the main routing engine card? If not please elaborate. Compliant

3,343 Is packet forwarding between two VRs using physical interface effectively passes through the physical interfaces? Compliant

3,344 If applicable, is it possible to perform packet forwarding between two VRs using virtual interfaces? Compliant

3,345 Is it possible to bind multiple physical interfaces to a given Virtual Router? Compliant3,346 Is it possible to bind multiple logical interfaces (i.e. VC, VLAN, VLAN-on-VC)

to a given Virtual Router? Compliant3,347 Is it possible to assign IP addresses to a logical interface (a loopback

interface for example) on a per virtual router basis? Compliant3,348 Do you support -ietf-dhc-dhcpv6-16.txt Compliant3,349 Do you support -ietf-idr-flow-spec-00.txt Compliant3,350 Do you support -ietf-isis-ipv6-06.txt Compliant3,351 Do you support -ietf-l3vpn-bgp-ipv6-07.txt Compliant3,352 Do you support -ietf-ngtrans-bgp-tunnel-04.txt Compliant3,353 Do you support -kato-bgp-ipv6-link-local-00.txt Compliant3,354 Do you support -ooms-v6ops-bgp-tunnel-06.txt Compliant

Load Balancing 3,262 Can load balancing (ECMP and/or LAG according to IEEE 802.3ad) be

based on MAC addresses (source and/or destination)? Comply3,264 Can load balancing (ECMP and/or LAG according to IEEE 802.3ad) be

based on IP addresses (source and/or destination)? Comply3,266 Can load balancing (ECMP and/or LAG according to IEEE 802.3ad) be

based on TCP/UDP destination port? Comply3,268 how was fragmented packet load-balancing hash done ? Comply



Can you configure so fragmented packet are NOT load balanced to avoid outof sequence packets?

3,270 Can load balancing (ECMP and/or LAG according to IEEE 802.3ad) be based on other criteria ?If so, can you precise the criteria Comply

3,272 Can load balancing (ECMP and/or LAG according to IEEE 802.3ad) be based on Round Robin? Comply

3,274 Do you support load-balancing for IPv4 traffic? Comply3,276 Do you support load-balancing for IPv6 traffic? Comply3,278 Do you support load-balancing with unequal bandwidth link? Comply3,280 Can ECMP be activated with BGP? Please elaborate on the number of paths,

the hashing algorithm and the list of parameters that can be set and their maximum values (e.g. maximum number of equal-cost flows). Comply

3,282 Can ECMP be activated with IS-IS? Please elaborate on the number of paths, the hashing algorithm and the list of parameters that can be set and their maximum values (e.g. maximum number of equal-cost flows). Comply

3,284 Can load balancing (ECMP) be per packet or per flow?Describe the default behavior per type of traffic Comply

3,286 Is load-balancing of MPLS traffic supported over layer-2 links bundle? Comply3,288 Can load balancing (ECMP and/or LAG according to IEEE 802.3ad) be

based on MPLS label ? How many ? Comply3,290 Can load balancing (ECMP and/or LAG according to IEEE 802.3ad) be

based on other criteria ?If so, can you precise the criteria Comply

3,292 Do you support load-balancing for multicast LDP, done by the downstream router at the control plane level? If so, please elaborate on your hashing algorithm. Comply

3,294 Do you support load-balancing for multicast LDP, done by the upstream router at the data-plane level? If so, please elaborate on your hashing algorithm. Comply

3,296 Do you support load-balancing for L3VPN traffic ?If so, can you precise the criteria Comply

3,298 Do you support load-balancing for L2VPN traffic ?If so, can you precise the criteria Comply

3,300 FRR/LFA 3,302 Do you support a Loop Free Alternate (LFA) calculation and redirection

mechanism as defined in RFC 5714? Please elaborate on your implementation. Comply

3,304 Do you support local SRLG ? Comply3,306 Do you support disabling/enabling protection per interface ? Comply3,308 Do you support disabling/enabling candidate per interface (interface that

cannot be used as LFA candidate) ? Comply3,310 Do you support RSVP-TE tunnel to be used as LFA candidate while not used

for nominal forwarding (LFA candidate only) ? Comply3,312 Can BFD trigger IPFRR ? Comply3,314 Can your implementation announce its best external routes as defined in

draft-ietf-idr-best-external-05? Comply3,316 Does your implementation offer any mechanism to send multiple paths

over a single BGP session (by making use of the BGP add-paths capability introduced in draft-ietf-idr-add-paths-06)? Please elaborate on your decision process and your best path selection. Comply

PIM 3,317 Does implementation support the PIM-SM protocol and conforms to

RFC4601 for IPv4? Comply



3,318 Does implementation support the PIM-SM protocol and conforms to RFC4601 for IPv6? Comply

3,319 Does implementation support "PIM-SSM", i.e. the use of the PIM-SM protocol in SSM mode and conforms to RFC4607 and section 4.8 of RFC4601 for IPv4? Comply

3,320 Does implementation support "PIM-SSM", i.e. the use of the PIM-SM protocol in SSM mode and conforms to RFC4607 and section 4.8 of RFC4601 for IPv6? Comply

3,321 Does the implementation support the PIM-bidir protocol and conforms to RFC 5015 for IPv4? Comply

3,322 Does the implementation support the PIM-bidir protocol and conforms to RFC 5015 for IPv6? Comply

3,323 Does implementation support the BSR mechanism and conforms to RFC 5059 for IPv4? Partial Comply

3,324 Does implementation support the BSR mechanism and conforms to RFC 5059 for IPv6? Partial Comply

3,325 Does the implementation support the anycast RP mechanism using PIM (RFC3446)? Comply

3,326 Does the implementation support the anycast RP mechanism using PIM (RFC4610)? Comply

3,327 Is PIM implemented in a per-state event-driven mode for IPv4? Comply3,328 Is PIM implemented in a per-state event-driven mode for IPv6? Comply3,329 Does implementation support source filtering mechanisms in the PIM-SM

RP function for IPv4? Comply3,330 Does implementation support source filtering mechanisms in the PIM-SM

RP function for IPv6? Comply3,331 Does implementation support the possibility to restrict the (*,G) and/or

(S,G) to which a receiver is willing to subscribe for IPv4? Comply3,332 Does implementation support the possibility to restrict the (*,G) and/or

(S,G) to which a receiver is willing to subscribe for IPv6? Comply3,333 Are there any troubleshooting tools such as counters (throughput per

multicast group, packet-drops per multicast group, active multicast routes in real-time…) for IPv4? Comply

3,334 Are there any troubleshooting tools such as counters (throughput per multicast group, packet-drops per multicast group, active multicast routes in real-time…) for IPv6? Comply

3,335 Does your implementation provide means to police the amount of PIM messages that are passed to the routing engine for IPv4? Comply

3,336 Does your implementation provide means to police the amount of PIM messages that are passed to the routing engine for IPv6? Comply

3,337 Can the PIM implementation perform RPF lookups on a routing table distinct from the one used for unicast? Can the shortest path computations for this alternative topology be done on a multicast-specific topology (like MT-ISIS in RFC5120 or MT-OSPFv2 in RFC4915) for IPv4? Comply

3,338 Can the PIM implementation perform RPF lookups on a routing table distinct from the one used for unicast? Can the shortest path computations for this alternative topology be done on a multicast-specific topology (like MT-ISIS in RFC5120 or MT-OSPFv2 in RFC4915) for IPv6? Comply

3,339 Is it possible to enable traffic accounting per (S,G) entry? Partial Comply3,340 Is your implementation compliant with RFC 3618 (MSDP)? Comply3,341 Does your implementation support SA filtering mechanisms that are

available at the RP? Comply3,342 What is the maximum number of SA messages that can be processed by the

implementation per unit of time without any performance degradation? Comply3,343 Does your implementation support PIM ECMP load-splitting for IPv4? Comply



If so, please describe on which basis ( (S,G) hash, round-robin,…) ?In case of (S,G) hash, are packets with same source address, and different group address balanced on different link ?In case of (S,G) hash, are packets with same group address, and different source address balanced on different link ?

3,344 Does your implementation support PIM ECMP load-splitting for IPv6?If so, please describe on which basis ( (S,G) hash, round-robin,…) ?In case of (S,G) hash, are packets with same source address, and different group address balanced on different link ?In case of (S,G) hash, are packets with same group address, and different source address balanced on different link ? Comply

3,345 Is there any load-balancing mechanism for IP multicast traffic over 802.3ad aggregated links for IPv4? Please specify if applicable on (*,G) criteria, (S,G) criteria or both.Are packets with same source address, and different group address balanced on different link ?Are packets with same group address, and different source address balanced on different link ? Comply

3,346 Is there any load-balancing mechanism for IP multicast traffic over 802.3ad aggregated links for IPv6? Please specify if applicable on (*,G) criteria, (S,G) criteria or both.Are packets with same source address, and different group address balanced on different link ?Are packets with same group address, and different source address balanced on different link ? Comply

MPLS 3,347 Is MPLS forwarding supported according to RFC 3031? Comply3,348 Is explicit null label and implicit null label supported?

What the default behaviour ?Is it configurable ? Comply

3,349 Is MPLS frame format compliant to RFCs 3032 & 4182? Comply3,350 Is the equipment able to push, swap and pop MPLS labels? Comply3,351 Is it possible to change the interface MTU for MPLS packets? Comply3,352 Is it possible to modify TTL processing (change between one mode to

another) ? Comply3,353 Is it possible to have a different TTL processing for transit packets & local

packets Comply3,354 If pipe/shortpipe supported, is it possible to fix manually the TTL value

imposed ? Comply3,355 Is TTL Processing consistent with RFC3443? Please indicate the supported

modes in comments (Uniform, short pipe, pipe). Comply3,356 Do you support IPFRR (LFA / remote LFA) in combination with LDP to

protect LDP LSPs? Comply3,357 Does your implementation provide some CLI "show" commands to check

FIB and LFIB at RP level and Linecard level ? Comply3,358 Is it possible to enable ECMP for MPLS flows? Please detail the hashing

algorithm and if the hashing can be tuned. Comply3,359 Do you support the LSR MIB in compliance with RFC 3813? If no is there a

proprietary MIB? Comply3,360 Do you support the FTN MIB in compliance with RFC 3814? If no is there a

proprietary MIB? Partial Comply3,361 Is P2MP MPLS forwarding (MPLS traffic replication = Branch LSR function)

supported in compliance with RFC 4461? Comply3,362 Do you support at least 8 replications per P2MP LSP (=fan-out)? Please give

the maximum number of P2MP LSP replication supported. Comply3,363 Can your implementation act as both Transit and Leaf LSR for a given LSP Comply



(= Bud LSR function) in compliance with RFC 4461? Please indicate if there is a hardware requirement for this specific feature

3,364 Is Label Distribution Protocol implementation compliant with RFC5036? Comply3,365 Are extended discovery and targeted sessions implemented according to

RFC5036 specification? Comply3,366 "Per Interface" & "Per platform" label space supported according to

RFC5036 specification? Partiallly Comply3,367 Are both "liberal" and "conservation" label retention modes supported

according to RFC5036 specification? Comply3,368 Can any loopback interface be used as a LDP session identifier? Comply3,369 Is LDP-IGP synchronization supported according to RFC5443 and RFC6138

for ISIS protocol" ? Comply3,370 Can BGP use LDP LSP to resolve nexthop ? Comply3,371 Does a targeted session only carry label mapping information regarding the

FEC128 and the FEC129? Comply3,372 Does your implementation allow applying a label distribution access list to

one LDP session? Please elaborate on the possible terms of this access list. Comply3,373 Is it possible to disable penultimate hop popping (i.e. deactivate the

advertisement of the implicit null label on the egress-LER)? Comply3,374 Do you support static label allocation? Comply3,375 Is LDP MD5 signature supported? Comply3,376 Is it possible to restrict the set of LDP neighbours using an access list? Comply3,377 Is it possible to set up LDP sessions over TE-LSPs (LSPs established by

RSVP-TE)? Comply3,378 Is LDP graceful restart supported in compliance with RFC3478? If so,

please give the default timer values and the range values for each parameter. Comply

3,379 Are LDP Capabilities supported in compliance with RFC5561? Partial Comply3,380 The device must implement "Multi-Protocol Label Switching (MPLS)

Support of Differentiated Services" according to RfC 3270. Comply3,381 The device should implement the MPLS Generic Associated Channel

according to RfC 5586. Partial Comply3,382 If the device implements "MPLS Generic Associated Channel" according to

RfC 5586, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Partial Comply

3,383 If the device implements "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)" according to RfC 4023, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,384 The vendor must state whether the device implements "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)" according to RfC 4576. Comply

3,385 If the device implements "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)" according to RfC 4576, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,386 The vendor must state whether the device implements "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)" according to RfC 4577. Comply

3,387 If the device implements "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)" according to RfC 4577, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,388 The vendor must describe administrative controls for BGP/MPLS Layer 3 IPv4 VPNs. Comply



3,389 The vendor must speciffy if there are limitations (equipment and management system) in using some Route Targets values/ranges Comply

3,390 The device must support the ability to create an OAM Service VPN, that allows for management of all external interfaces and for import of the selected Route Targets (hub and spoke) for Management and VPN Topology generation purposes. Comply

3,391 The device must support by default the segregation of Traffic including routing protocol traffic between VPNs. Comply

3,392 The device must support configuration of MPLS IPv4 VPNs with the same or overlapping IP address spaces. Comply

3,393 The device must support functionality that prevents visibility of the internal address and network structure of the core network (MPLS PE and P elements). Comply

3,394 The device must prohibit traffic flowing from customer VPNs to management VPN ports. Comply

3,395 The device must support that Any VPN can use the same address space as the underlying infrastructure. Comply

3,396 The device must never accept a packet with a label received from a CE router. Packets containing a label that arrive on a CE interface must be dropped. Thus it is not possible to insert fake labels, because no labels at all are accepted. It must be impossible to send packets with wrong labels from a CE router (the “outside”) through a PE into the MPLS cloud. Comply

3,397 The Vendor must support the ability to enable import and export routes (prefixes) and packets from one VPN to another (or extranet) Comply

3,398 The device must provide a mechanism that allows the network administrator to set a policy on a particular prefix learnt via a specific AS path. This policy will ensure that a particular prefix wins the local best path calculation without either advertising this policy outside of the local router or impacting the best path calculations used in the remainder of the network. This approach to policy enforcement must be compatible with RFC2547 – BGP / VPN’s. Comply

3,399 The device must ensure that a VPN does not abuse the MPLS label mechanisms or protocols to gain unauthorised access to other VPNs or the core. Comply

3,400 The vendor must state whether the device implements "ICMP Extensions for Multiprotocol Label Switching" according to RfC 4950. Comply

3,401 The vendor must describe which features consumes lables and how (VPN, etc.) Comply

3,402 The device must implement Label Distribution Protocol (LDP) according to RfC 5036 "LDP Specification". Comply

3,403 If the device implements "Label Distribution Protocol (LDP) according to RfC 5036 "LDP Specification", then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,404 The vendor must state whether support for cryptographic authentication of LDP Hellos is planned or implemented. Comply

3,405 The vendor must state label ranges that can be used for various MPLS services and functionalities. Comply

3,406 The vendor must state how many labels can be used simultaneously on device and state any limitations regarding label pool. Comply

3,407 Do you support the LDP MIB in compliance with RFC 3815? If no is there a proprietary MIB? Partial Comply

3,408 mLDP: Are P2MP LSP establishment supported in compliance with RFC6388 ? Comply

3,409 Are mLDP make-before-break procedures supported in compliance with RFC6388 section 9? Please elaborate. Comply

3,410 Do you support a make-before-break approach relying on building the new Comply



path in the control plane without breaking the old path, and after a configurable timer, updating the dataplane to receive traffic on the new path ? Please elaborate.

3,411 Do you support LDP Upstream Label Assignment as defined in RFC6389 and in section 7 of RFC6388 ? Comply

3,412 For P2MP LSPs established with mLDP , do you support MPLS FRR Link protection with RSVP-TE P2P Bypass tunnel ? Comply

3,413 Do you support OAM for mLDP-based P2MP LSPs (RFC6425, draft-ietf-bfd-multipoint) ? Please elaborate. Partial Comply

3,414 Does your implementation support for RPF check deactivation (to allow for distinct RPF and P2MP tunnel interfaces)? Comply

3,415 Does your implementation support static routing of multicast prefixes (configuration of an outgoing interface for a given multicast prefix, i.e. @Group-> if1)? Comply

3,416 Does your implementation support static forwarding of multicast flows into P2MP tunnels (i.e. @Group => P2MP LSP, or (S,G) => P2MP LSP)? Provide separate answers for IPv4 and IPv6 if appropriate. Comply

3,417 Is FEC IPv4-LDP LSP ping supported according to RFC 4379? Comply3,418 Is LSP Ping able to exercise all possible paths (Multi-path exercise option

for ECMP cases)? Comply3,419 Is FEC IPv4-LDP LSP traceroute supported according to RFC 4379? Comply3,420 Is LSP traceroute able to exercise all possible ECMP paths? Comply3,421 Is BFD for MPLS LSP supported according to RFC5884? Comply3,422 Is VPWS supported? Comply3,423 Is VPLS supported? Comply3,424 Is T-LDP for signalling protocol with FEC 128 element (pseudowire ID)

implemented? Could it be activating with IS-IS? Comply3,425 Is MP-iBGP for signalling protocol (auto-discovery and VPWS labels

distribution) implemented? Could it be activating with IS-IS? Comply3,426 Is BGP Auto-discovery with Route reflector function implemented? Comply3,427 Are PW types for Frame Relay DLCI and Frame-Relay Port mode (0x0001,

0x0019 and/or 0x00FF) implemented? Comply3,428 Are PW types for ATM AAL5 SDU VCC transport, ATM transparent cell

transport, ATM n-to-one VCC cell transport, ATM n-to-one VPC cell transport, ATM one-to-one VCC Cell Mode, ATM one-to-one VPC Cell Mode, ATM AAL5 PDU VCC transport (PW-id: 0x0002, 0x0003, 0x0009, 0x000A, 0x000C, 0x000D, 0x000E) implemented? Partial Comply

3,429 Are PW types for Ethernet Tagged Mode and Ethernet (0x0004 and 0x0005) implemented? Comply

3,430 Is PW type for HDLC (0x0006) implemented? Comply3,431 Is PW type for PPP (0x0007) implemented? Comply3,432 Is PW type for IP Layer2 Transport (0x000B) implemented? Comply3,433 Are PW types for Structure-agnostic (E1 over Packet, T1, E3, T3)

implemented? So following PW-id: 0x0011, 0x0012, 0x0013 and 0x0014. Partial Comply3,434 Is PW type for CESoPSN basic mode (0x0015) implemented? Comply3,435 The bidder shall support Ethernet VPWS (raw and tagged mode):

attachment of a single client port to a PW, without performing any MAC learning. Comply

3,436 The bidder shall support the pseudowire control word and pseudowire sequence numbers per PWE3 specifications. Please precise for each type of PW if your implementation is compliant with the draft-ietf-pwe3-ethernet-encap (which version). Comply

3,437 Is AC could cohabited with other services which are not L2VPN (e.g. MPLS, IP, multicast) on the same physical port (through configuration of virtual port)? Comply



3,438 Can one AC be linked to a set of Ethertype values? Please elaborate on the means and possibilities. Comply

3,439 Do you support the configuration of VPWS service MTU? Give details on which type of MTU is configurable (IP MTU, Ethernet MTU, MPLS MTU) without FCS, and give minimum and maximum value that could be configuring. Comply

3,440 Do you support ECMP performed from PE VPWS to P router? Give details on which criteria are based the hashing (MPLS labels, addresses MAC…). Give details if criteria depend of the type of traffic from AC (unicast, broadcast, multicast, MPLS). Comply

3,441 Do you support LAG according to IEEE 802.3ad performed from PE VPWS to P router? Give details on which criteria are based the hashing (MPLS labels, addresses MAC…). Give details if criteria depend of the type of traffic from AC (unicast, broadcast, multicast, MPLS). Comply

3,442 Do you support LAG according to IEEE 802.3ad performed from PE VPWS to AC? Give details on which criteria are based the hashing (MPLS labels, addresses MAC…). Give details if criteria depend of the type of traffic from AC (unicast, broadcast, multicast, MPLS). Comply

3,443 The bidder shall provide the flexibility that the PSN tunnel (tunnel LSP for transporting the pseudowire) be created using LDP or RSVP-TE signalling. Comply

3,444 Do you support the dynamic/static mapping of a pseudowire to an MPLS traffic engineered tunnel, where the pseudowire will be declared down immediately if the TE tunnel(s) goes down i.e. pseudowire does not fallback on IGP/LDP path if the (/all possible) TE Tunnel(s) fails? Give details of static mapping of VPWS to TE tunnel(s), and of dynamic TE tunnel selection for VPWS. Can TE tunnel selection can take into account VPN traffic CoS, while TE tunnels are associated to CoS values? Comply

3,445 Do you support the dynamic/static mapping of a pseudowire to MPLS traffic engineered tunnels, where this pseudowire will fallback on IGP/LDP path if the (/all possible) TE Tunnel(s) goes down? Give details of static mapping of TE tunnel to VPWS, and of dynamic TE tunnel selection for VPWS. Can TE tunnel selection can take into account VPN traffic CoS, while TE tunnels are associated to CoS values? Comply

3,446 Is VPWS to L3VPN interworking (PW termination in a L3VPN VRF) implemented? Comply

3,447 Is Ethernet VPWS with "PW mutualisation" implemented? Please precise in comment field if 1:1 mode (VPWS + cross-connect which appends C-VLANs without performing MAC address learning) and/or N:1 mode (associating an Ethernet bridge instance to a PW with performing MAC address learning). Partial Comply

3,448 Is VPWS local switching (VPWS from and to the same PE) between untagged/raw interfaces implemented? Please elaborate on the applicability (two ports on the same node, two ports on the same card, same port, etc). Comply

3,449 Is VPWS local switching (VPWS from and to the same PE) from 802.1Q to 802.1Q implemented? Please elaborate on the applicability (two ports on the same node, two ports on the same card, same port, etc). Comply

3,450 Is VPWS local switching (VPWS from and to the same PE) 802.1ad to 802.1ad implemented? Give details in the comment field (on the same equipment card and on two cards of the same equipment). Comply

3,451 The bidder shall support the LSP ping and traceroute capabilities for tunnel LSP (PSN tunnel). Comply

3,452 The bidder shall support VCCV “Virtual Circuit Connectivity Verification” capability for diagnostics and trouble-shooting of pseudowire according to RFC5586. The bidder shall specify which connection verification mechanisms are available for each type of pseudowire. Comply

3,453 The bidder shall support the Pseudowire failure detection and propagation Comply



using “BFD over pseudowire” mechanism.3,454 The bidder shall support the pseudowire failure detection and propagation

using targeted LDP “label withdraw” mechanism. (Ref: RFC 4447 – PW setup & maintenance using LDP). Comply

3,455 The bidder shall support the pseudowire failure detection and propagation using “Pseudowire Status TLV” mechanism. (Ref: RFC 4447 – PW Setup & Maintenance using LDP). Comply

3,456 Is PW redundancy implemented (pseudowire backup) as defined in draft-muley-pwe3-redundancy? Give details in the comment field. Comply

3,457 The bidder shall support high availability for PWs by protecting the targeted LDP (or MP-BGP) session(s) via non-stop routing (stateful implementation) during planned and unplanned failure situations e.g. route processor failover/switchover. Comply

3,458 The bidder shall support high availability for PWs by protecting the targeted LDP (or MP-BGP) session(s) via graceful restart (per IETF specs) during planned and unplanned failure situations e.g. route processor failover/switchover. Comply

3,459 Comply3,460 Is T-LDP for signalling protocol with FEC 128 element (pseudowire ID)

implemented? Could it be activating with IS-S? Comply3,461 Is T-LDP for signalling protocol with FEC 129 element (generalized

pseudowire ID) implemented? Could it be activating with IS-IS? Comply3,462 Is MP-iBGP for signalling protocol (auto-discovery and VPLS labels

distribution) implemented? Could it be activating with IS-IS? Comply3,463 Is BGP auto-discovery (BGP-AD) mechanism (with T-LDP signalled VPLS

implemented? Could it be activating with IS-IS? Comply3,464 In 802.1ad based L2VPN (VPWS and VPLS), is double VLAN translation

implemented (shall be able to translate both inner and outer VLAN of 802.1ad frames)? Comply

3,465 In 802.1ad based L2VPN (VPWS and VPLS), is mapping of 802.1ad (Q-in-Q) frames into PW (pseudowire) based on outer VLAN-id implemented? Comply

3,466 In 802.1ad based L2VPN (VPWS and VPLS), is mapping of 802.1ad (Q-in-Q) frames into PW (pseudowire) based on both inner and outer VLAN-id implemented? Partial Comply

3,467 In 802.1ad based L2VPN (VPWS and VPLS), is 802.1ad bundling (mapping of a range of inner and outer VLAN-id into a PW) implemented? Comply

3,468 In 802.1Q based L2VPN (VPWS and VPLS), is 802.1Q bundling (mapping of a range of VLAN-id into a PW) implemented? Comply

3,469 In IP based L2VPN (VPWS and VPLS), is DSCP to TC (formerly EXP) mapping implemented? Comply

3,470 In 802.1Q based L2VPN (VPWS and VPLS), is VLAN 802.1p to TC (formerly EXP) mapping implemented? Comply

3,471 In 802.1ad based L2VPN (VPWS and VPLS), is inner VLAN 802.1p to TC (formerly EXP) mapping implemented? Comply

3,472 In 802.1ad based L2VPN (VPWS and VPLS), is outer VLAN 802.1p to TC (formerly EXP) mapping implemented? Comply

3,473 Can Ethernet with different 802.1Q VLAN-id be set to attachment circuit on each pseudowire side? Comply

3,474 The router shall be capable of marking the TC (formerly EXP) field of PW label. Please precise how it can be done: manually configured or mapping between native protocol QoS level (e.g. ATM) and the PW layer. Comply

3,475 Are all sub-TLVs defined in RFC5305 (IS-IS-TE) supported? Comply3,476 Is traffic-engineering information stored in a separate database? If so,

please detail the update procedure of this TED in comparison to the legacy IGP routing database. Comply



3,477 Is advertisement of TE mesh group membership in IS-IS supported in compliance with RFC4972? Comply

3,478 Are configuration and advertisement of SRLG information in IS-IS supported in compliance with RFC 5307? Comply

3,479 Is RSVP-TE supported in compliance with RFC3209? Please indicate if interoperability tests with other vendors have been performed with success. Comply

3,480 Can the device act as an MPLS-TE head-end LER? Comply3,481 Can the device act as an MPLS-TE intermediate LSR? Comply3,482 Can the device act as a tail-end LER? Comply3,483 The device must be able to implement the Multi-AS Backbones options

defined in RFC 4364, along with option AB Comply3,484 The device must implement at least two methodes of label allcation (per

prefix and/or per VRF) Partial Comply3,485 The device must implement "Capabilities Advertisement with BGP-4"

according to RfC 5492. Comply3,486 The device should implement "Constrained Route Distribution for Border

Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)" according to RfC 4684. Comply

3,487 The device must support inside VPN routing interaction operation according to RfC 4364, section 7. Comply

3,488 The device shall implement event based BGP VPN import. Comply3,489 The device should implement "Node Behavior upon Originating and

Receiving Resource Reservation Protocol (RSVP) Path Error Messages" according to RfC 5711. Partial Comply

3,490 The device should implement "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)" according to RfC 3477. Comply

3,491 The device must implement "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)" according to RfC 3812. Comply

3,492 The device must implement the Carriers' Carrier feature according to section 9 of RfC 4364. Comply

3,493 Is Implicit Null label advertisement supported in RSVP-TE? Comply3,494 Is Explicit Null label advertisement supported in RSVP-TE? Comply3,495 Can penultimate hop popping be disabled in RSVP-TE (i.e. deactivate the

advertisement of the implicit null label on the egress-LER)? Comply3,496 Does your implementation support at least on of the two formats for

session attribute object (without resource affinities and with resource affinities) as defined in RFC 3209? Please indicate if you support both. Comply

3,497 Is Graceful Restart procedure for RSVP-TE defined in RFC 3473 supported? Comply3,498 Is RSVP Refresh reduction supported in compliance with RFC2961? Comply3,499 Are link bundling RSVP Procedures supported as defined in RFC 4201? Comply3,500 Are LSP Hierarchy procedures defined in RFC 4206 supported? Comply3,501 Is Signalling of unnumbered links in RSVP-TE supported in compliance

with RFC 3477? Comply3,502 Is MD5 authentication supported for RSVP-TE sessions as defined in RFC

2209? Comply3,503 Do you support soft preemption mechanism, as defined in RFC 5712? Comply3,504 Do you support the TE MIB in compliance with RFC 3812? If no is there a

proprietary MIB? Comply3,505 Is dynamic constrained path computation (CSPF) supported? Comply3,506 Does your implementation support different constraints that can be

configured for dynamic path computation such as bandwidth, setup/hold Comply



priorities, links/nodes to include/exclude, SRLG to exclude and Affinities to include/exclude?

3,507 Is it possible to specify the metric to be used for path optimization (TE metric or IGP metric) as defined in RFC 3785? Comply

3,508 Can CSPF be deactivated, and the ERO be explicitly configured with strict and loose hops? Comply

3,509 Is it possible to configure multiple path options, so that if a given option does not work another option is selected? Comply

3,510 Is make-before-break tunnel re-optimization supported? If yes indicate the triggers (timer driven, event driven, manual) Comply

3,511 Is dynamic tunnel resizing based on average measured bandwidth (aka auto bandwidth) supported? Comply

3,512 Is it possible to automatically setup a mesh of TE-LSPs between a group of LSRs (mesh group) (aka auto-mesh). If yes indicate how the mesh group can be determined (statically via access-list and/or dynamically via IGP extensions)? Comply

3,513 Is it possible to configure TE-LSPs as next-hop for either or both unicast and multicast prefixes? Comply

3,514 Is it possible to take TE LSPs into account in the SPF selection procedure (aka IGP shortcut or auto bandwidth) on the head end LSR? Comply

3,515 Is it possible to advertise a TE LSP as a link within the IGP? Comply3,516 Can BGP select a TE-LSP if the BGP next hop is reachable through the TE-

LSP? Comply3,517 Does the MPLS-TE implementation allow dynamic tunnel selection on the

head-end based on extended rules such as on one or more source address ranges, destination address ranges, source port ranges, destination port ranges, IPv4 protocol field or IPv6 next-header field and the DiffServ Code Point or Precedence field? Please specify on which criteria dynamic tunnel selection is done, examples would be appreciated. Comply

3,518 Is TE LSP global protection supported (with standby LSP)? Please give in the comment column an order of magnitude of the recovery delay per LSP. Comply

3,519 Is TE LSP full restoration (backup path computed and signalled after the failure) supported? Please give an order of magnitude of the recovery delay per LSP. Comply

3,520 Is TE LSP planned restoration (pre-computed backup path signalled after the failure) supported? Please gives an order of magnitude of the recovery delay per LSP. Comply

3,521 Is MPLS Fast Reroute Link Protection with NHOP Bypass LSPs (facility backup mode) supported in compliance with RFC 4090? Comply

3,522 Is MPLS Fast Reroute Node Protection with NNHOP Bypass LSPs (facility backup mode) supported in compliance with RFC 4090? Comply

3,523 Is MPLS Fast Reroute Node Protection with NNHOP detour (one to one) supported in compliance with RFC 4090? Comply

3,524 Can link and/or node protection be configured on a primary TE-LSP? Comply3,525 Can one link/node be protected by several Bypass LSPs (backup load

balancing)? Comply3,526 Can a bypass LSP path be explicitly configured? Comply3,527 Can a bypass LSP path be dynamically configured, taking into account the

link/node/SRLG to exclude? Comply3,528 Can NHOP and NNHOP bypass LSPs be automatically configured (no need

to configure each NHOP and NNHOP bypass)? Comply3,529 Is FRR Link Protection with one-hop primary TE-LSPs supported, and can it

protect IGP and LDP routes? Comply3,530 Can one hop primary TE-LSPs for link protection be automatically

configured? Comply



3,531 Regarding detour protection, does your implementation support non disruptive resignaling of detour path to optimize merging? Comply

3,532 Does your implementation of detour FRR provides deterministic FRR path, i.e. independantly of the order of the signalling happens, FRR will always have the same final path and same level of protection? Comply

3,533 Can failure detection rely on Ethernet alarms? Please list the set of alarms that trigger FRR. Comply

3,534 Can BFD trigger FRR? Give the detection delay. Comply3,535 Is it possible to tune the FRR triggering process? Comply3,536 PLR at Transit :

Is the recovery delay independent of the number of protected TE-LSPs ? If not, please give the reroute time for a hundred TE-LSP Comply

3,537 Can a primary LSP be automatically reverted on the nominal path when the failure is repaired (re-optimization) Comply

3,538 Is a primary LSP in dynamic mode rerouted in a make before break manner on an alternate path after the failure recovery (re-optimization)? Comply

3,539 Do you support for P2MP MPLS-TE? Comply3,540 Does your implementation support standard P2MP RSVP-TE signalling in

compliance with RFC4875? Comply3,541 Does your implementation P2MP support standard SRLG based on the RFC

4203 et 5307 ? Comply3,542 Does your implementation support explicit tree configuration on the Root

LSR? Comply3,543 Does your implementation support dynamic tree computation on the Root

LSR? Comply3,544 In the case some leaves cannot be reached, is your implementation able to

still establish a P2MP tunnel for the reachable leaves? Comply3,545 Does your implementation support make-before-break P2MP tunnel re-

optimization, with neither data loss nor data replication? Please list the supported re-optimization triggers (manual, event-driven and timer-driven). Comply

3,546 Does your implementation support bandwidth monitoring on the Root LSR and periodic P2MP Tunnel resizing decision (and potential rerouting) based on bandwidth thresholds (a.k.a. Autobandwidth)? Comply

3,547 Does your implementation support Leaf LSR addition/removal (Grafting/Pruning) without impact (packet loss) on other Leaves? Comply

3,548 Does your implementation support end-to-end P2MP Tunnel restoration on the Root LSR upon link or node failure? Comply

3,549 Does your implementation support P2MP Fast Reroute Link protection (Bypass mode)? Comply

3,550 Does your implementation support the setting of a P2MP Tunnel as a static next-hop for IP multicast routes on a Root LSR? Comply

3,551 Does your implementation support VLAN to P2MP Tunnel cross connection on a Root LSR? Comply

3,552 Does your implementation support P2MP_Tunnel to VLAN cross connection on a Leaf LSR? Comply

3,553 Does your implementation support P2MP MPLS-TE MIB as defined in draft-ietf-mpls-p2mp-te-mib-09? If no is there proprietary MIB ? Comply

3,554 Is it possible to setup inter-area TE-LSPs? Comply3,555 Is it possible to setup inter-AS TE-LSPs? Comply3,556 Is PCEP supported in compliance with RFC 5440? Partial Comply3,557 Do you provide an MPLS-TE management tool? If yes precise the supported

functions:Offline path computation for primary and backup tunnels (indicate the supported objective functions) ; TE Tunnel provisioning on Head-End

Comply



LSRs ; TE Tunnel Monitoring3,558 If yes to the previous question, can this tool interoperate with other vendor

equipments (if so indicate theses equipments)? Otherwise, indicate a set of MPLS-TE management tools that can manage this router. Comply

3,559 Does the router provide a management interface with a TE management tool? If yes indicate the type of interface (telnet, CORBA, XML…) Comply

3,560 Does your implementation support the FEC for RSVP Tunnel IPv4 LSP ping according to RFC 4379? Comply

3,561 Does your implementation support the FEC for RSVP tunnel IPv4 LSP traceroute according to RFC 4379? Comply

3,562 Does your implementation support the FEC for P2MP RSVP tunnel LSP ping according to RFC 6425? Comply

3,563 Does your implementation support the FEC for P2MP RSVP tunnel LSP traceroute according to RFC 6425? Comply

3,564 Does your implementation support P2MP MPLS-TE Ping and Traceroute according to RFC 6424? Comply

3,565 Does your implementation support Packet Loss and Delay measurement according to 6374? Partial Comply

3,566 Do you implement VRRP version 2 according to RFC 3768? Please detail if you have made successful interoperability test. Comply

3,567 Do you implement some enhancement to VRRPv2 such as more aggressive timers? Please elaborate. Comply

3,568 Do you support VRRP version 3 as defined in draft-ietf-vrrp-unified-spec-05? Comply

3,569 Does your implementation support the prioritization of prefixes to be installed in FIB in order to tune the convergence speed? If so, please elaborate on the convergence gain Comply

3,570 Do you support prefixe prioritization for /32 prefixes? Comply3,571 Do you support prefixe prioritization for others or a configuratble prefixes

size? Please elaborate Comply3,572 How is managed the default route ? Comply3,573 Do you support prefixe prioritization for prefixes specified by a prefix list? Comply3,574 Is policy based based prefix prioritization supported ? Comply3,575 The device must implement Virtual Router Redundancy Protocol version 3

(VRRP) according to RfC 5798. Comply3,576 If the device implements "Virtual Router Redundancy Protocol version 3

(VRRP)" according to RFC 5798, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,577 The vendor must state the failure detection and recovery times that their implementation of VRRP can guarantee. Comply

3,578 The vendor must state default parameters for VRRP. Comply3,579 The vendor must state the number of Virtual Router IDs that can be

configured simultaneously on a single interface. Comply3,580 The vendor must state any limitations on the total number of VRIDs that

can be configured on the device as a whole. Comply3,581 The device should implement "Definitions of Managed Objects for the

Virtual Router Redundancy Protocol" according to RfC 2787. Partial Comply3,582 If the device implements "Definitions of Managed Objects" according to

RFC 2787, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,583 The VRRP protocol must be implemented in a way that allows for the authentication of keep alive (and other) messages. Partial Comply

BFD 3,584 The device must implement Bi-Directional Forwarding Detection (BFD)

according to RfC 5880. Partial Comply



3,585 If the device implements "Bi-Directional Forwarding Detection (BFD)" according to RfC 5880, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Partial Comply

3,586 The vendor must state any limitations on the total number of BFD sessions that can be configured on the device (per card, device, min. timers, mutual trade-off, etc. ). Comply

3,587 The vendor must state if their BFD implementation supports Simple Password Authentication according to section 4.2 of RfC 5880. Comply

3,588 The vendor must state if their BFD implementation supports SHA-1 based authentication. Comply

3,589 The device must have eBGP support for Bidirectional Forwarding Detection (BFD) according to Section 10.2 of RfC 5882. Comply

3,590 If the device implements "eBGP support for Bidirectional Forwarding Detection (BFD)" according to Section 10.2 of RfC 5882, then the vendor must state any 'optional' or 'should' requirements that their implementation does not support. Comply

3,591 The vendor must state any limitations connected to the use of eBGP with BFD. Comply

3,592 The vendor must state the failure detection times that their implementation of BFD with BGP can guarantee and support. Information on any default parameters must be provided. Comply

3,593 The device must have OSPF support for Bidirectional Forwarding Detection (BFD). Comply

3,594 The vendor must state any limitations connected to the use of OSPF with BFD. Comply

3,595 The vendor must state any limitations connected to the use of Link Local with BFD. Comply

3,596 The vendor must state whether the implementation of Multihop BFD supports cryptographic authentication of BFD control packets according to section 6 of RfC 5883. Comply

3,597 Do you support BFD in asynchronous mode in compliance with RFC5880? Comply3,598 Do you support "BFD Admin Down" setting on per session and per platform

basis? Comply3,599 Do you support BFD Control Plane Independence by implementing BFD in

the Forwarding Plane and supporting C-bit in the BFD Control Packets? Comply3,600 Do you support BFD for connected interface? Comply3,601 Do you support BFD for static routes? Comply3,602 Do you support BFD for IS-IS routing protocol? Comply3,603 Do you support BFD for iBGP and eBGP routing protocol (single and multi-

hop)? Comply3,604 Do you support BFD for MP-iBGP and MP-eBGP routing protocol (single

and multi-hop)? Comply3,605 Do you support BFD for LDP (including targeted LDP)? Comply3,606 Do you support BFD for PIM? Comply3,607 Do you support BFD for RSVP-TE? Comply3,608 Do you support BFD for MPLS in compliance with RFC5884? Comply3,609 Is BFD implemented in the line-card hardware (as opposed to the routing

processor software)? If so, is it available for all type of interface proposed? Comply Misc

3,610 The device must support policy based routing which allows for routing decisions to be based on policies set by the administrator which take precedence over the device's normal routing behaviour. Comply

3,611 The device must support policy based routing decisions where the source IPv6 address of the packet is used as the basis for the routing decision. Comply



3,612 The device must support policy based routing decisions where the physical or logical ingress interface of the packet is used as the basis for the routing decision. Comply

3,613 The device must support policy based routing decisions where the IPv6 DSCP / TOS field of the packet is used as the basis for the routing decision. Comply

3,614 The device must support policy based routing decisions where the IP protocol number of the packet is used as the basis for the routing decision. Comply

3,615 The device must support policy based routing decisions where the TCP / UDP destination / source port number of the packet is used as the basis for the routing decision. Comply

3,616 The vendor's must provide information about any additional criteria which their proposed device can use for policy routing. Comply

3,617 The vendor must provide information about any limitations on configuring multiple simultaneous policy routing criteria. Comply

3,618 The device must allow the administrator to configure the action which will be taken when a policy match rule is matched which must be (at least): configurable next-hop address, force egress interface Comply

3,619 The vendor must state any performance impact that configuring policy based routing has upon their proposed device at both the interface and chassis level. This must contain information about the number of policy route entries that can be configured and have been tested. Comply

3,620 The device must implement VRRP Version 3 for IPv6 according to RfC 5798. Comply

3,622 Vendor proposed device must implement traffic classification based on IEEE 802.1p (CoS). Partial Comply

3,623 Vendor proposed device must implement traffic classification based on input interface. Comply

3,624 Vendor proposed device must implement traffic classification based on VLAN. Comply

3,625 Vendor proposed device must implement traffic classification based on source or/and destination IPv6 address / prefix. Comply

3,626 Vendor proposed device must implement traffic classification based on source or/and destination IP port. Comply

3,627 Vendor proposed device must implement traffic classification based on IP protocol (e.g. UDP, TCP,…) Comply

3,628 Vendor proposed device should implement traffic classification based on the application (e.g. ftp, http, etc.) Comply

3,629 Vendor proposed device must implement traffic classification based on DSCP. Comply

3,630 The vendor must state performance limitations for QoS classification. Comply3,631 The device must implement VRRP Version 3 for IPv6 according to RfC 5798

that supports multiple VRFs (Virtual Routing Instances). Comply3,632 The device must implement IPv6 packet filter lists that can filter IPv6

traffic based on the source and destination IPv6 address or a prefix that can be applied to any interface. Comply

3,633 The device must implement IPv6 packet filter lists that can filter IPv6 traffic based on the source and destination port that can be applied to any interface. Comply

3,634 The device must implement IPv6 packet filter lists that can filter IPv6 traffic based on the source and destination IPv6 protocol that can be applied to any interface. Comply

3,635 The device must implement IPv6 aware anti-spoofing feature such as Reverse Path Forwading according to RfC 3704 that can be applied to any interface. Comply



3,636 The vendor must state the performance impact of input and output packet filter lists. Comply

3,637 The device must support route (prefix) redistribution between IPv6 routing protocols. Comply

3,638 The device must allow for configurable route filter lists (IPv6 aware) for both the advertisement and acceptance of routing information between different routing protocols. Comply

3,639 The device must allow for the modification of routing information parameters when redistributing routing information (e.g. metric, attributes) based on the originating routing protocol, source and other routing protocol parameters. The device must allow the administrator to configure the modification behaviour and values. Comply

3,640 Does the equipment provide a “destination classes”-based accounting mechanism? (Accounting for packets headed for some given routes.). If so, please elaborate and detail what are the (logical) interface types that support such mechanism. Comply

3,641 Does your implementation support multiple criteria to set up a destination class? Please elaborate and list the available criteria and the number of configurable classes. Comply

3,642 Specifically, can one set up a destination class for routes that have some given BGP community tags? A combination of? Comply

3,643 Does your implementation allow retrieving the counters by and SNMP? Please detail if it is also possible through APIs, via files or other means. Comply

3,644 Can your implementation provide some kind of "in-depth" information about counted IPv4, IPv6 and MPLS traffic? Please elaborate. Comply

3,645 Does your implementation have any compatibility issues between a “destination classes”-based accounting mechanism and other accounting or non-accounting features? If so, please elaborate. Answer "compliant" only if there is no compatibility issue. Comply

3,646 Does the equipment provide a “source classes”-based accounting mechanism? (Accounting for packets from some given routes.) If so, please elaborate and detail what are the (logical) interface types that support such mechanism. Comply

3,647 Can this mechanism be activated on an output interface basis? (Accounting for packets that leave the router via a given interface.) If so, please elaborate on the configuration procedure. Comply

3,648 Does your implementation support multiple criteria to set up a source class? Please elaborate and list the available criteria and the number of configurable classes. Comply

3,649 Specifically, can one set up a source class for routes that have some given BGP community tags? A combination of? Comply

3,650 Does your implementation support class configuration by CLI? Please detail if other ways to configure classes are available (API, SNMP, …) and if the number of classes is then limited. Comply

3,651 Does your implementation allow retrieving the counters by and SNMP? Please detail if it is also possible through APIs, via files or other means. Comply

3,652 Can your implementation provide some kind of "in-depth" information about counted IPv4, IPv6 and MPLS traffic? Please elaborate. Comply

3,653 Does your implementation have any compatibility issues between a “source classes”-based accounting mechanism and other accounting or non-accounting features? If so, please elaborate. Answer "compliant" only if there is no compatibility issue. Comply

3,654 Can a packet be countered for both a destination and a source classes? Comply3,655 Does the equipment provide an IPFIX-like implementation (that is to say

some sort of flow-based accounting mechanism)? If so, please elaborate. Comply



3,656 Does your implementation have at least one collector (software running on an external server) compatible with your implementation? If so please list all of them. Comply

3,657 Does your implementation support multiple criteria to define a flow and to configure the corresponding metering capabilities? If so, please detail all of them, the kinds of traffic supported (IPv4 unicast/multicast, IPv6, MPLS, …) and your caching mechanism. Comply

3,658 Regarding the flows in the cache, do network events (update of a route) trigger their expiration?If, as part of the previous question, the output ifIndex or the IP next-hop could not be part of the key, what do you propose to detect such cases? Partial Comply

3,659 List all the fields that could be reported in the packets. What is the default list of fields (and their types)? Special attention will be given to reliability of IP destination address and mask, in/out ifIndex, byte and packet counters, IP Next-Hop, BGP Next-Hop, L4 ports, protocols and first n-bytes of the payload. Comply

3,660 Is packet sampling performed centrally on the RE in software ?Specify the netflow versions that are processed this way Comply

3,661 Is packet sampling performed centrally in hardware with an additionnal service card ?Specify the netflow versions that are processed this way Comply

3,662 Is packet sampling performed in a hardware manner by the line card/interface card ?Specify the netflow versions that are processed this way Comply

3,663 Is packet sampling (software or hardware) available with a specific lincence ? Per interface, per line card, per chassis, per network ? Comply

3,664 What is the range of sampling rate values that are configurable? What is the minimum sampling rate to use on a fully loaded (with 64 bytes packets)- interface or linecard? - NPU/CPU/PFE ? - chassis ?Give the figures for software and hardware implementations if it differs and if it exists Comply

3,665 Is this packet sampling configurable per interface? Per class of service? Please elaborate. Partial Comply

3,666 Can packet sampling be Count-based systematic (1 packet every n packets)? Partial Comply

3,667 Can packet sampling be Count-based random (1 random packet per n packets seen)? Comply

3,668 Can packet sampling be done only for packets that match a term of an IP filter configured on an interface? Comply

3,669 Are multiple destinations (exports) available : - for a single netflow version running (v5, v9, IPfix) ? - for different netflow versions running ? - into local files ?If so , please say how many? Comply

3,670 What happens if the packets that pass through the interfaces cannot be sampled (i.e. do not match the sampling capabilities or filters) ? For instance if half of the packets passing through an interface are 6PE packets the sampling process cannot cope with that kind of traffic but only with IPv4 packets. Does it have an influence on the sampling performances ? Please elaborate Comply

3,671 Is is possible to export sampling records toward different collectors, depending on the interface? Comply

3,672 Are the Netflow v5 and/or v9 formats supported, as an alternative to IPFIX, for the export of traffic records? Comply



3,673 Do you support Graceful Restart for RSVP-TE in compliance with RFC5063? If not, do you at least support the "downstream neighbour" mode? Please give the names used in your documentation to refer to "restarting node" and "downstream neighbour". Comply

3,674 Do you support the generation-id procedures defined for PIM in RFC 4601 to act as a "graceful restart" mechanism? Please elaborate on your way to maintain the multicast FIB during a restart event. Comply

3,675 Do you support Non stop routing (NSR) capability using Stateful Protocol Protection with no dependency on neighbours? Please elaborate on the synchronisation mechanisms (data mirroring/replication, data corruption/DoS attacks prevention) and the types of failures covered by this NSR capability (e.g. SW crashes, HW crashes, Planned Maintenance...). Comply

3,676 Do you support Non stop routing (NSR) capability for BGP? Comply3,677 Do you support Non stop routing (NSR) capability for MP-BGP? elaborate

which AFI/SAFI are supported with NSR Comply3,678 Do you support Non stop routing (NSR) capability for IS-IS? Comply3,679 Do you support Non stop routing (NSR) capability for LDP (including

Targeted LDP)? Comply3,680 For LDP and T-LDP, do you support all FECs for NSR ? If not, elaborate

which are supported Comply3,681 Do you support Non stop routing (NSR) capability for RSVP-TE? Comply3,682 Do you support Non stop routing (NSR) capability for PIM? Comply3,683 Do you support NSR capability for BFD ? Comply

High Availability

Clause Compliance

Comply (Comply/Partial

Comply)4,00 High availability "CHASSIS": The Router/Switch chassis must achieve at

least 99.999% availability when configured with redundant common hardware (Chassis, back plane, fans, power supplies, Commons, etc…). Comply

4,01 No common hardware faults for the network element: No single hardware fault shall result in a loss or degradation of service traffic or a loss of network element management and control functions. This requirement applies to traffic added, dropped or connected through the network element. Comply

4,02 No common software faults for the network element: No single software fault in the network element, or command, or sequence of commands to the network element shall result in a loss or degradation of service traffic or a loss of network element management and control functions. Nor shall any single software fault in the network element, or command, or sequence of commands to the network element cause it to enter a state recovery from which could result in a loss or degradation of service traffic or a loss of network element management and control functions. This requirement applies to traffic added, dropped, or connected through the network element. Comply

4,03 Reliability Modeling per Unit/chassis (FIT Rate/MTBF) Comply4,04 Line Card return rates: The return rate for each type of Line Card shall not

exceed 12 Line Cards per 1000 per year and, as an objective, should not exceed 1 Line Card per 1000 per month. This includes all field-replaceable units. Compliance with this requirement shall be demonstrated based on actual field data or vendor-provided predictions, if field data are not available. Comply

4,05 Line Card failure effects: Failure of a Line Card shall cause no error on any signal except the signals that pass through the pack that failed. Comply

4,06 No silent failures: There shall be no silent failures, which according to Comply



Telcordia TR-NWT-000418 are any equipment or software failures that result in a loss of service, a loss of protection, or a loss of network element management and control functions without an audible alarm and/or remote signaling to initiate corrective action. Compliance with this requirement shall be demonstrated through a design review, a review of the reliability block diagram, and the analyses of expected failures for the network element.

4,07 Backplane redundancy: Backplane paths must be all redundant and non-blocking in failure mode. Comply

4,08 Multiple control plane coordination: Access to resources shared by multiple control planes (e.g., CPU cycles, bandwidth) shall ensure that each has sufficient resources for normal operation. Comply

4,09 Signal path redundancy: Any network element management and control signal paths must be fully redundant. Comply

4,10 Switch module redundancy: Any switch module must be fully redundant and non-blocking. Comply

4,11 One switch fabric must be able to carry full switch load non-blocked without performance degradation. Or if the switch fabric redundancy is n X then the system must maintain a non-blocked fabric during one failure. The system is not required to survive multiple switch fabric failure if the system has an n X scheme. Comply

4,12 A load-sharing scheme is preferred over primary vs. secondary scheme. Comply4,13 The fail-over arbitration logic must have a tiebreaker scheme. Comply4,14 The fail-over arbitration must not have a kill based on lack of system

communication. Comply4,15 Central control redundancy: Central control of the system must be fully

redundant. Comply4,16 The fail-over mode of redundant control systems must be fully redundant Comply4,17 The fail-over of system control must be totally hit free at the data bit level. Comply4,18 · The fail-over arbitration must have a tiebreaker mechanism. Comply4,19 · Three control systems are preferred for tiebreaker and to prevent

false fail-over. Comply4,20 System control software redundancy: At least two images of System

Control Software must be contained within the system. Checksum of the SCS on the control systems (processors) is a required background diagnostic that is part of the fail-over scheme. Comply

4,21 Power distribution path redundancy: Power distribution paths must be all redundant and independent. The secondary path must fully perform and supply a fully loaded system when the primary path has a complete open and/or the primary path has a 0 ohm short to power and return, power to sense, return to sense, power to chassis, return to chassis, sense to chassis, power to signal ground, return to signal ground, sense to signal ground. Comply

4,22 Failure recovery: Upon the rectification of the cause of service-affecting failures related to power (e.g., restoration of power feeds) the network element shall autonomously recover to a normal operating software state and all traffic shall be restored without the need for manual intervention within 5 minutes, regardless of the hardware and software configuration of the element as well as the amount and mixture of the traffic either transiting or terminating on the element. Comply

4,23 Recording and reporting of transient software failures for the network element: Either the network element or the EMS shall have the capability to record and report (via notification to the NMS, EMS GUI and craft interface terminal command line interface) both the number and type of transient software faults in the network element. Comply

4,24 Network element primary backup database: The network element shall provide for at least one (1) local, primary, nonvolatile memory backup as

Comply



specified in Telcordia GR-472-CORE. As part of this requirements, at least two system wide configuration files, including current routing table must be contained within the system. Checksum of the configuration files, including routing tables on the control systems (processors) is a required background diagnostic that is part of the fail-over scheme. Latent fault detections: Background diagnostic and fault detection mechanisms shall be implemented

4,25 Data restoration time: Restoration of data from the local backup memory, once initiated, shall be completed within five (5) minutes, as specified in Telcordia GR-472-CORE. Restoration time includes the time to recover all functions necessary to restore any traffic that was interrupted as a result of a database loss. Comply

4,26 Please detail for each cards (RP, LC, SC,…) if it is hot-swappable without impact on the data plane or not? Comply

4,27 The switch over, in failure cases, from a faulty unit to a standard redundancy must occur automatically, i.e. such a failure must be self discovered and self “healed” by the device. Comply

4,28 Device must have a configurable option to take up its service as soon as a link / multiple links, connected to a Network Element, is /are recovered after an outage Comply

4,29 Identified problems must be alarmed immediately to the network management system and if it is possible be self-healed. Comply

4,30 For maintenance purposes it must be possible to manually force a switch over to redundant units and switch back. Comply

4,35 If your equipment can have SONET/SDH interfaces, does it support APS feature (or MSP for SDH as well)? Please elaborate on the configuration options such as 1:1 architecture, bidirectional / unidirectional mode, revertive (or not) option Comply

4,36 Does your equipment support routing engine redundancy and hot swapping capabilities? If so, does it support Non Stop Forwarding (NSF) features allowing, when the master role passes to another routing engine, to maintain L2 adjacencies status and forwarding table information like unicast/multicast FIBs and ARP tables? Please elaborate on your feature name (if different, as defined in this case, from NSF) and all the information maintained. Comply

4,37 In multi-chassis configuration, can failure events on the matrix trigger control plane events such as overload-bit set in IS-IS, BGP notification, etc? Comply

4,38 Do you support Graceful Restart for BGP in compliance with RFC4724? If not, do you at least support the "receiving speaker" mode? Please give the names used in your documentation to refer to "restarting speaker" and "receiving speaker". Comply

4,39 Do you support Graceful Restart for BGP with MPLS in compliance with RFC4781? If not, do you at least support the "neighbour of a restarting LSR" mode? Please give the names used in your documentation to refer to "restarting LSR" and "neighbour of a restarting LSR". Comply

4,40 Do you support Graceful Restart for IS-IS in compliance with RFC5306? If not, do you at least support the "neighbour of a restarting router" mode? Please give the names used in your documentation to refer to "restarting router" and "neighbour of a restarting router". Please also elaborate on the use of the ISIS Overload Bit if different from the specification. Comply

4,41 Do you support Graceful Restart for LDP (including targeted LDP) in compliance with RFC3478? If not, do you at least support the "neighbour of a restarting LSR" mode? Please give the names used in your documentation to refer to "restarting LSR" and "neighbour of a restarting LSR". Comply

QoSClause Compliance Comply




5,00 Is it possible to have at least 8 separate classes of service (with one associated queue per class) per physical ingress interface?(4 classes for data and 1 class for control) Comply

5,01 Is it possible to have at least 8 separate classes of service (with one associated queue per class) per physical egress interface?(4 classes for data and 1 class for control) Comply

5,02 Is it possible to have at least 8 separate classes of service (with one associated queue per class) per physical egress interface? Please detail is they are common or not for unicast and multicast IPv4, IPv6 and MPLS traffic Comply

5,03 Is it possible to mix the various methods of marking (L2, L3, and MPLS) on a same physical port? Comply

5,04 Can marking action be performed in both ingress and egress of a physical port? Comply

5,05 Does the device support the DiffServ standard as defined in RFC 2474 and RFC 2475 for both IPv4 and IPv6 traffic? Comply

5,06 Is it possible to mark TOS/DS field on IP packets (IPv4 or IPv6) generated by the routing processor (for routing protocols and management)? Comply

5,07 Is policing of unicast frames supported? Comply5,08 Is policing of Broadcast/multicast frames supported on all interfaces? Comply5,09 Can policing be performed at both ingress and egress? Comply5,10 Can CIR, EIR/PIR , CBS and MBS parameters be enforced by the policer? Comply5,11 Are discarded frames counters (per port, per VLAN, per queue ...)

available ? Comply5,12 Can policing be disabled? Comply5,13 Is shaping capability available? Comply5,14 Is per port ingress/egress policing supported? Comply5,15 Is per lag ingress/egress policing supported? Comply5,16 Is per port ingress/egress shaping supported? Comply5,17 Is it possible to have at least 8 separate classes of service (with one

associated queue per class) per logical ingress interface? Indicate the maximum number of supported Class of Services per logical interface. Please detail if it is common or not to unicast and multicast IPv4, IPv6 and MPLS traffic Comply

5,18 Is it possible to have at least 8 separate classes of service (with one associated queue per class) per logical egress interface? Indicate the maximum number of supported Class of Services per logical interface. Please detail if it is common or not to unicast and multicast IPv4, IPv6 and MPLS traffi. Comply

5,19 Is it possible to classify an IP flow according to DS field? Comply5,20 Is it possible to classify an IP flow according to TOS field? Comply5,21 Is it possible to apply an ACL filter in order to classify an IP flow? Comply5,22 Is it possible to classify simultaneously IPv4 and IPv6 traffics? Comply5,23 Is it possible to classify simultaneously IPv4 and IPv6 traffics on

different criteria? Comply5,24 Can the classification function be activated on both ingress and egress

for each logical interface? Comply5,25 Is it possible to mix the various methods of marking (L2, L3, and MPLS)

on a same line-card? Comply5,26 Is it possible to mix the various methods of marking (L2, L3, and MPLS)

on a same logical interface? Comply5,27 Is it possible to perform L3 marking of local traffic (management flows, Comply



routing protocol sent by the router itself, self generated traffic) protocol per protocol?

5,28 Is it possible to configure a tuneable 802.1p to DSCP mapping table? Comply5,29 Is it possible to configure a tuneable MPLS TC (formerly EXP) field to

DSCP mapping table? Comply5,30 Is it possible to configure a tuneable DSCP to MPLS TC (formerly EXP)

field mapping table? Comply5,31 Is it possible to configure a tuneable MPLS TC (formerly EXP) field to

802.1p mapping table? Comply5,32 Is it possible to configure a tuneable 802.1p to MPLS TC (formerly EXP)

field mapping table? Comply5,33 Is ingress/egress shaping supported by logical interface? Comply5,34 Can shaping be performed simultaneously with policing? Comply5,35 Are congestion avoidance mechanisms (like RED, WRED, ...)

implemented? Indicate the maximum number of queues (per interface, per slot, …) Comply

5,36 Is strict priority scheduling algorithm available? Comply5,37 Is WRR (Weighted Round Robin) scheduling algorithm available?

Indicate the size of input and output buffer memories Comply5,38 Is WFQ (Weighted Fair Queuing) algorithm scheduling available? Comply5,40 Can the scheduling be performed at LAG interface level (n ports on a

same board or on different boards)? Comply5,41 In case of shared memory, is it possible to limit the size of the queues?

Please elaborate (what's the default queue size in byte and packets ? How does it related to interface line speed?...) Comply

5,42 Is mapping between Class of Services and queues configurable? Comply5,43 Does the implementation support specific counter to monitor QoS

(queues traffic; discarded traffic, etc) Comply5,44 Do these counters allow distinction between “classified/queued”,

“scheduled”, and/or “discarded” traffics? Comply5,45 Can other QoS information/parameters be retrieved by SNMP? Comply5,46 Are other QoS administration mechanism (apart from SNMP) provided? Comply5,47 Support a Preference/Precedence/COS indicator that is used internally

(e.g., across the switch fabric) that provides intelligent discard if congestion results between interface COS Application points. Comply

5,48 Support COS/QOS/Traffic Management capabilities applicable per Logical Interface. The logical interface may be associated with a single physical port, or distributed among several ports as in the case of an Aggregated Interface (e.g., LAG group). Discuss the mechanism that enables COS/QOS/Traffic Management capabilities to be supported over Aggregated Interfaces. Include descriptions when the Aggregated Interface is configured in a) Active Standby and B) Active/Active mode of operation. Comply

5,49 Support Hashing over Links in a LAG bundle based on: ,S/D IP address (if IP payload), S/D MAC Address (If non IP payload), Describe any additional capabilities to load balance traffic flows over links in a LAG bundle. Comply

5,50 Support traffic policing and filtering. Provide a detailed description of the traffic policing and filtering features of the device. Comply

5,51 Support the ability to transparently carry the 802.1p values across the service network. The mechanism used to achieve this must not be visible to the customer. Use of Double tagging is acceptable. Please describe the mechanism. Comply

5,52 The platform must be able to alter the 802.1p values in the inner & Comply



outer VLAN tags independently. Both on Ingress and Egress. Please describe the mechanism.

5,53 Support RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 headers. Comply

5,54 The device shall support the mapping of DSCP, IP Precedence Bits to MPLS LSP, VLAN, 802.1P or other traffic engineering capabilities. Comply

5,55 The device must support traffic conditioning at all interfaces at line rate. Comply

5,56 The device must support RFC 2475, An Architecture for Differentiated Services, including edge conditioning functions such as Packet Classification, Policing, Shaping, and Marking & Metering. Comply

5,57 The device must support an appropriate scheduling mechanism to effectively implement Diffserv queuing behaviors (e.g. strict priority, Weighted Fair Queuing). Comply

5,58 The device shall support Assured Forwarding per hop behavior per RFC 2597. Comply

5,59 The device shall support Expedited Forwarding per hop behavior per RFC 3246. Comply

5,60 The device must support the default PHB (RFC 2474) for "best effort" traffic. Comply

5,61 The device must be able to configure all traffic parameters for rate limiting and traffic shaping associated with the PHBs listed above. Comply

5,62 The device must implement rate shaping capability for each queue. Comply5,63 The device must support rate limiting, filtering, and traffic shaping

based on three-color drop precedence scheme with configurable thresholds. . Comply

5,64 The device must be able to enforce MTU size settings. Comply5,65 During normal operation the queuing and forwarding policies of the

device shall preserve the customer’s original packet order within the same QoS. Comply

5,66 Excessive traffic in low priority classes must not affect traffic in the higher classes. Comply

5,67 Platform must support input traffic classification based on Interface (physical port or logical interface). Comply

5,68 Platform must support traffic classification based on VLAN Tag 802.1P bits. Classification must be supported on ingress and egress. For double tagged traffic, classification must be user configurable on a per logical channel basis, to classify the frame based on the Outer Tag 802.1P bits or Inner Tag 802.1P bits. Comply

5,69 Platform must support ingress traffic classification based on Priority values (802.1D). Comply

5,70 Platform must support input traffic classification based on IP-TOS/DSCP field. Comply

5,71 The Platform must support per-flow queuing. Comply5,72 Platform must support packet policing to protect system resources or

excessive bandwidth use by a specific traffic type. Comply5,73 Platform must support packet prioritization or “marking” based on the

results of classification and policing. Packets which exceed the permitted bandwidth requirements (bits per second) can be conditionally dropped or reclassified. Capability must be independently supported for in both ingress and egress direction, on a per logical channel basis. Comply

5,74 Platform must support packet queuing and congestion avoidance: high priority or latency-sensitive traffic can be placed in higher priority or

Comply



lower latency queues. The assignment of the traffic to the queues can be based on logical channel identifier, or classification.

5,75 Platform must support transmit scheduling: High-priority traffic can be transmitted before lower-priority traffic. Comply

5,76 The platform must support hardware queuing in the format of 1p3q3t one priority queue three normal queues and eight Tail Drop/WRED; the queue architecture must have the ability to perform bandwidth allocation on a per queue basis. Comply

5,77 If the platform supports per flow queuing, state how many per-flow queues can be supported. Comply

5,78 Provide details of the queuing mechanism in your switch architecture. Differentiate between software and hardware queues. Comply

5,79 For each queuing algorithm that your equipment supports please describe its impact on latency, jitter and throughput. Comply

5,80 Platform must support per VLAN queuing. Comply5,81 The queue depths must be configurable. Comply5,82 Describe the buffer management scheme of your switch architecture. Comply5,83 Platform must support remapping of incoming traffic based on VLAN

tag IDs to predefined priority values. Comply5,84 Platform must support configurable RED/WRED active buffer

management. Comply5,85 Platform must support a mechanism for guaranteed bandwidth (CIR). Comply5,86 Platform must support a minimum bandwidth granularity increment of

128 Kbps. Comply5,87 Platform must support burst capability above CIR. Comply5,88 Provide implementation details of burst capability. Comply5,89 The platform shall support the capability to generate reports for

monitoring the overall QoS of the network Comply5,90 The platform must support IP Diffserv functionality. Explain how the

DiffServ marked packets are mapped into MPLS tunnels and discuss if there are any performance or throughput considerations. Comply

5,91 The platform shall support DiffServ PHB type ‘Assured Forwarding (AF). Comply

5,92 The platform shall support RFC2597 assured forwarding rate limiting parameters. Describe in detail all configurable RFC2597 assured forwarding rate limiting parameters, on the access and trunk sides. Comply

5,93 The platform shall support support DiffServ PHB type ‘Expedited Forwarding (EF). Comply

5,94 The platform shall support configurable RFC2598 expedited forwarding rate limiting parameters. Describe in detail all configurable RFC2598 expedited forwarding rate limiting parameters, on the access and trunk sides. Comply

5,95 The platform shall support DiffServ PHB type ‘Best-Effort (BE)? Comply5,96 Describe your rate limiting implementation. Discuss the provisioning

parameters and granularity of the burst bandwidth. Additionally please advise if your system has the capability of a Three Two Rate/Two Three Color Policer. Comply

5,97 Platform must support Port based Rate Limiting. Comply5,98 Platform must support VLAN ID based Rate Limiting. Either single

tagged or double tagged. Support rate limiting based on inner tag, outer tag or combination of both. Comply

5,99 Discuss how the rate limiting algorithm handle fixed size packets vs. random sized packets Comply

5,100 State the granularity of bandwidth provisioning in rate limiting Comply



5,101 If a circuit is not fully utilizing the CIR bandwidth, then the unused portion must be available as burst bandwidth to other circuits. Comply

5,102 System must be capable of wire speed Traffic Management implementation. Comply

5,103 System must be capable of providing COS treatment for up to 1,000 logical interfaces on 10 G ports. This includes Policers and Shapers. Comply

5,104 System must be capable of providing COS treatment for up to 2,000 logical interfaces on 40 G ports. This includes Policers and Shapers Comply

5,105 System must be capable of providing COS treatment for up to 4,000 logical interfaces on 100 G ports. This includes Policers and Shapers Comply

5,106 Please provide information on your available buffer size and buffer allocation to both physical and logical interfaces. Comply

5,107 Please indicate the number of policy maps on both ingress and egress supported should be provided Comply

5,108 Queues : Support the capability to assign traffic to any of the possible 8 queues per physical port. Explain the capability to assign traffic to any of the possible 8 queues per physical port. What criteria is the assignment based on? Is it user definable? What are the possible definitions? Comply

5,109 Support for WRED, Class-Based WFQ, and LLQ mechanisms. Comply5,110 User configurable to Support assignment of traffic of more than one

class per queue. Comply5,111 Support for One alternate priority based low delay/jitter queue. The

algorithm is intended to produce a structure by where the data held within the non priority queue is not completely starved for bandwidth, thus allowing the TCP based streams to survive during times of congestion while introducing as little delay variation upon the priority queue as possible also the ability to limit any and all transmission queues. Comply

5,112 Support to serve all classes without bandwidth reservations [or below EF classes] with WFQ. Comply

5,113 Support at least 1 EF and 7 AF classes. How many EF and AF classes are supported? Comply

5,114 Platform shall supported a class based drop mechanism that uses configurable relative class weights within each queue, number of queues ranging from one to eight when using EXP and PREC values. The drop mechanism must be based on average queue depth with the ability to tune that relative average in order to accommodate bursty customer traffic patterns. Comply

5,115 Support for the class-full shaping, policing, and queuing mechanism should not be an absolute value instead a function of the line capacity etc. Comply

5,116 Support QoS packet coloring: default 0, ToS bit setting on all packets, EXP setting on labels on both inbound and outbound interfaces Comply

5,117 Support Queuing per logical interface. 8 queues per Logical Interface. How many logical interfaces can be supported for each interface type? Comply

5,118 Support Queuing per Physical interface. 8 queues per Physical Interface. Comply

5,119 The platform shall support “Marking per logical interface”. Comply5,120 The platform shall support Full line rate forwarding at 64 byte packet

sizes with QoS mechanism enabled Comply5,121 The platform shall support RFC 2597 (AF PHB Group) and 3246 (An

Expedited PHB). In the case of partial support of the RFCs, please indicate what is supported and what is not supported. Comply

5,122 Support ability to Classify Frames by EXP and TOS QoS as well as DSCP Comply



per logical interface. [Ability to assign EXP, TOS and DSCP to any queue].

5,123 Describe support for multiple classes of traffic from separate physical and logical sources bound for the same logical/ and or physical interface that traverse the systems fabric as well as hair pinning on the same card. Describe the support for class-full scheduling across the fabric and the flexibility to fine tune available to the network designer. Comply

5,124 The platform must support the capability to support Hashing over Links in a LAG bundle based on: S/D IP address (if IP payload), S/D MAC Address (If non IP payload), MPLS Label- 5 lables labels deep. Describe any additional capabilities to load balance traffic flows over links in a LAG bundle. Comply

5,125 The platformm must support a Preference/Precedence/COS indicator that is used internally (e.g., across the switch fabric) that provides intelligent discard if congestion results between interface COS Application points. Comply

5,126 Describe the capability to assign frames to TE-Tunnels based on EXP bit settings. Comply

5,127 When your equipment performs a P-Router function it must be able to optionally support the use .1p bits of the Ethernet Frame, in addition to the MPLS EXP bits, for COS treatment. Comply

SecurityClause Compliance Comply


6,00 Security levels are synonymous with user groups and provide the ability to organize users into identifiable subsets to which common usage rights/privileges are assigned. Comply

6,01 The device SHALL provide access privileges with various settable security levels. Comply

6,02 The device SHALL provide, at a minimum, the following security levels: “Administration”. Comply

6,03 The device SHALL provide, at a minimum, the following security levels: “Security”. Comply

6,04 The device SHALL provide, at a minimum, the following security levels: “Backup”. Comply

6,05 Those individuals assigned the “Security” security level SHALL be the only entities allowed to effect changes that affect security functions. Comply

6,06 Multiple security levels SHALL be assignable to an individual with a minimum of one level. Comply

6,07 The device SHALL provide time of day access controls. Comply6,08 The device SHALL provide a mechanism for mapping members into

identifiable groups having common access privileges by virtue of membership in the group. Comply

6,09 Users who are authorized to assume specific predefined roles SHALL NOT have default authority to modify the definition of roles unless authorized to do so. Comply

6,10 Device Management Activity Timers Comply6,11 The device SHALL provide a user inactivity timer that will terminate a

login when exceeded. Comply6,12 Device user inactivity timers SHALL be settable for between 1 minute up

to 60 minutes. Comply6,13 Device user inactivity timers SHALL be provided with a 10-minute Comply



default value. 6,14 Device user inactivity timers SHALL be settable only by those individuals,

granted the access control level of “Root”, “Administrator” or “Security”. Comply6,15 The device SHALL support Access Control Lists (ACLs) that define

allowed access to element functions. Comply6,16 The device SHALL support Access Control Lists (ACLs) that define

allowed access to information (data) stored/maintained within an element. Comply

6,17 device ACLs SHALL support “Read”, “Write”, “Delete”, and “Execute” access rights associated with element functions. Comply

6,18 device ACLs SHALL support “Read”, “Write”, “Delete” and “Modify” access rights associated with information (data) stored/maintained within the element. Comply

6,19 device ACLs SHALL associate user identifiers and assigned security levels with allowed access to element functions and information. Comply

6,20 The device SHALL be able to control access on a per user basis. Comply6,21 The device SHALL be able to control access on a user group basis. Comply6,22 The device SHALL be able to control access based end user system

address. Comply6,23 The device SHALL provide controls to restrict access on directory, file,

and command levels. Comply6,24 The device SHALL provide controls to restrict “write” access to

authorized users and programs. Comply6,25 The device SHALL restrict the disclosure of users’ access privileges to

authorized users. Comply6,26 Device consoles and other means of management access to the Device

SHALL be protected by the access control mechanisms. Comply6,27 The device SHALL provide configurable default privileges to users for

directories and files. Comply6,28 Device system files SHALL only be accessible by administrator privileged

users. Comply6,29 The device SHALL protect authentication data from access and disclosure

in clear text to all users. Comply6,30 If file replication across multiple servers is supported, the device SHALL

protect the replicated data from unauthorized disclosure and modification during transmission. Comply

6,31 The device SHALL protect audit information from access by unauthorized users. Comply

6,32 The device SHALL protect audit information from modification by any user. Comply

6,33 The device SHALL protect the device’s time-stamping clock to support the integrity of various authentication schemes and the integrity of the audit mechanism. Comply

6,34 The device SHALL restrict users from using commands to bypass controls (e.g., disable audit mechanism). Comply

6,35 The device SHALL provide the capability to customize individual privileges for each user ID and user role (e.g., administrator, operator). Comply

6,36 The Device SHALL only allow authorized user programs to be executed and initiated by an authorized user. Comply

6,37 The device operating system SHALL NOT allow user-access to unauthorized information or processes. (After a successful login, an authorized user SHALL be bound directly to an allowed application, and not allowed direct access to operating system resources thereafter.). Comply

6,38 The device application SHALL NOT allow a user to exit the application and return to the operating system environment. Upon exit from a device

Comply



application, a user SHALL be logged out of the device automatically and will need to login again to gain access to the same or to another device application.

6,39 Non-privileged user-level action, either deliberate or accidental, SHALL NOT cause the device to be unavailable to other users. Comply

6,40 Mechanisms SHALL be provided to allow “secure recovery” after a failure or discontinuity (e.g., without making the device vulnerable to a security compromise). Comply

6,41 The device SHALL provide reporting and display capabilities on user profiles, access privileges, and audit information. Comply

6,42 The device SHALL provide the mechanisms (i.e., with authentication, integrity and access control mechanisms) to protect monitoring and trace software from unauthorized use. Comply

6,43 The device SHALL provide mechanisms to secure (e.g., cryptographic-based user credentials) the execution of remote diagnostics and tools that can connect and disconnect sessions, enable and disable ports, and monitor user access. Comply

6,44 The device SHALL process alarms and message traffic with appropriate priorities to ensure proper notification when service is disrupted by a security event. Comply

6,45 The device SHALL provide the capability to generate alarms for specifiable security relevant events including Operational violations - e.g., denial of service in terms of an out-of-band service access port. Comply

6,46 Device Login functions SHALL require a non-blank (i.e., not Null) user identifier to log into said Device. Comply

6,47 Any default identifiers SHALL be capable of being deleted. Comply6,48 Login identifiers SHALL require a minimum length of 6 characters (mixed

alphabetic and numeric). Comply6,49 Login identifiers SHALL be stored within an element in a non-volatile

manner. Comply6,50 Only those individuals granted the access control level of “Root”,

“Administrator” or “Security” SHALL have access to the device login function. Comply

6,51 Only those individuals granted the access control level of “Root”, “Administrator” or “Security” SHALL have access to the device management function. Comply

6,52 Login identifiers SHALL be required for access to the device login function. Comply

6,53 Login identifiers SHALL be required for access to the device management function. Comply

6,54 Assignment of login identifiers SHALL be only by those individuals, granted the access control level of “Security”. Comply

6,55 Deletion of login identifiers SHALL be only by those individuals, granted the access control level of “Security”. Comply

6,56 Login passwords SHALL NOT be disclosed/displayed on the screen when entered during login. Comply

6,57 Login password lengths SHALL NOT be disclosed/displayed on the screen when entered during login. Comply

6,58 Device Login functions SHALL require a non-blank (i.e., Null) user password to log into said Device. Comply

6,59 Any default passwords SHALL be capable of being deleted. Comply6,60 Login passwords SHALL require a minimum length of 8 characters

(mixed alphabetic and numeric with special characters allowed). Comply6,61 It is desirable that the device "enforce" complex password usage as

specified in the preceding requirement. Comply



6,62 Login passwords SHALL be stored within a device in a non-volatile manner. Comply

6,63 Login passwords SHALL be required for access to the device login function,. Comply

6,64 Login passwords SHALL be required for the device management function. Comply6,65 Login passwords SHALL be stored within a device in an encrypted form

only. Comply6,66 Login password encrypted storage SHALL use the MD-5 hash algorithm

at a minimum. Comply6,67 Only one password SHALL be assignable to each login-ID, (i.e., the

number of passwords is equal to the number of login-IDs in the system). Comply6,68 Login identifier verification SHALL use a token method, such as SecureID,

as an alternative to passwords. Comply6,69 Assignment/changing of login passwords SHALL be allowed by those

individuals, granted the access control level of “Root”, “Administrator” or “Security”. Comply

6,70 Device Login functions (processes) SHALL post an entry to the security log whenever a login attempt occurs where the entry includes a field that identifies the success or failure of said attempt. Comply

6,71 The maximum threshold of tries a user will be given to enter a valid login/password combination SHALL be 3-5 attempts. Comply

6,72 The threshold of tries a user will be given to enter a valid login/password combination SHALL be settable only by those individuals, granted the access control level of “Root”, “Administrator” or “Security”. Comply

6,73 The device SHALL generate a distinct alarm when the threshold for unauthorized/invalid login attempts is reached. Comply

6,74 Device Login functions SHALL lock out the keyboard or session, or equivalent action, when the threshold for unauthorized/invalid attempts is exceeded except for out-of-band management. Comply

6,75 Only an individual granted the access control level of “Root”, “Administrator” or “Security” SHALL be allowed to restore a locked out keyboard or session after the threshold for unauthorized/invalid attempts has been exceeded. Comply

6,76 Device Login functions SHALL support a settable time interval, between 1 minute and 60 minutes, that controls the period of keyboard or session lockout following the user failure to enter a correct login/password combination within the allocated number of attempts. Comply

6,77 Device Login function time interval that controls keyboard or session lockout SHALL be settable only by those individuals, granted the access control level of “Root”, “Administrator” or “Security”. Comply

6,78 Device unauthorized/invalid login attempt alarm messages SHALL be transmitted to an element manager function. Comply

6,79 Device unauthorized/invalid login attempt alarm message transmission destination SHALL be settable only by those individuals, granted the access control level of “Root”, “Administrator” or “Security”. Comply

6,80 The Device SHALL NOT support ways to bypass the authentication mechanism other than documented procedures documented by the vendor. Comply

6,81 The device SHALL appear to perform the entire user authentication procedure, even if the user ID that is entered is not valid. Comply

6,82 Error feedback generated by the device during the user authentication procedure SHALL provide no information to the user other than “invalid”, i.e., it SHALL NOT reveal which part of the authentication dialog is incorrect. Comply

6,83 When a logical connection is established and before access to services is granted, the device SHALL provide an advisory warning message

Comply



regarding unauthorized entry or use and its possible consequences. 6,84 Upon a human user’s successful login to a device, the following SHALL be

displayed: The date and time of the user’s last successful access to the device. Comply

6,85 Upon a human user’s successful login to a device, the following SHALL be displayed: The number of unsuccessful attempts by that user ID to access the device since the last successful access by that user ID. Comply

6,86 When an authentication server is deployed, the device SHALL provide the capability to control routing to the security server for mediation to avoid unauthorized bypass of the server. Comply

6,87 The device SHALL provide mechanisms to protect the loading of new software and/or data by supporting authentication, access control, and integrity verification mechanisms for software installation, update, patching or replacement. Comply

6,88 If cryptographic mechanisms are used, the device SHALL provide the capability to securely administer the key management service that supports the crypto-based mechanisms. Comply

6,89 The device SHALL NOT provide a mechanism for any user, including the administrator, to retrieve any authentication information in clear text. Comply

6,90 Vendor reference manuals SHALL document activation and administration procedures for defining and enabling the generation of security alarms when communications ports are enabled or used. Comply

6,91 Security reference and training manuals for administrators, that include details of operating system and application security functions and procedures, SHALL be provided via hardcopy and website. Comply

6,92 Security manuals that define user access procedures SHALL be provided. Comply6,93 Only patches from an original operating system vendor, or third-party

patches that have been approved by the original operating system vendor, SHALL be installed in an operational device. Comply

6,94 The device SHALL log unauthorized access attempts in a local security log file. Comply

6,95 Device system elements SHALL support use of alarm thresholds for counts of unauthorized access attempts. Comply

6,96 Device system elements alarm count thresholds of unauthorized access attempts SHALL be settable only by those individuals, granted the access control level of “Root”, “Administrator” or “Security”. Comply

6,97 Device unauthorized access attempt alarm messages SHALL be transmitted to an element manager function. Comply

6,98 Device unauthorized access attempt alarm message transmission destination SHALL be settable only by those individuals, granted the access control level of “Root”, “Administrator” or “Security”. Comply

6,99 The device SHALL provide a mechanism to end a session through a secure logoff procedure. Comply

6,100 If a session gets interrupted due to events such as time-out, power failure, or link disconnection, the device SHALL prevent someone else from continuing the session as an imposter. Comply

6,101 Devices that perform routing and bridging functions SHALL have the capability to control various types of network interfaces (e.g., Ethernet® connection) so that access control screening is not bypassed. Comply

6,102 The device SHALL have the ability to control access to commands that affect its configuration, routing, and flow control, and any other features that determine how it handles traffic. Comply

6,103 The device SHALL have the capability to control the number of concurrent user accesses permitted at various resource levels (e.g., file). Comply

6,104 Device system log file time & date stamps SHALL be based on Device system time & date information. Comply



6,105 Device system time & date information SHALL be synchronized with other Device and EML, NML, SML and BML systems by use of the Network Time Protocol version 3 including support for RY 1305 Appendix C message authentication. Comply

6,106 The device SHALL write entries to a security log. Comply6,107 Device security log entries SHALL include a description of the action that

is being logged. Comply6,108 Device security log entries SHALL include an action identifier. Comply6,109 Device security log entries SHALL include the identity of the user that

initiated the action, including associated terminal, port, network address, or communication Device. Comply

6,110 Device security log entries SHALL include the date and time the action occurred. Comply

6,111 The device SHALL write entries to a security log whenever a Login identifier is added, changed or deleted. Comply

6,112 The device SHALL write entries to a security log whenever a Login password is added, changed or deleted. Comply

6,113 The device SHALL write entries to a security log whenever an authorized login occurs. Comply

6,114 The device SHALL write entries to a security log whenever an authorized logout occurs. Comply

6,115 The device SHALL write entries to a security log whenever an unauthorized or invalid login occurs. Comply

6,116 The device SHALL write entries to a security log whenever a security lockout of a keyboard or session is removed. Comply

6,117 The device SHALL write entries to a security log whenever an unauthorized/invalid login threshold is changed. Comply

6,118 The device SHALL write entries to a security log whenever a time interval that controls keyboard or session lockout is changed. Comply

6,119 The device SHALL write entries to a security log whenever an ACL is created, modified or deleted. Comply

6,120 The device SHALL write entries to a security log whenever an authorized attempt to access resources (including data and transactions) occurs. Comply

6,121 The device SHALL write entries to a security log whenever an unauthorized attempt to access resources (including data and transactions) occurs. Comply

6,122 The device SHALL write entries to a security log whenever changes to security profiles and attributes occurs. Comply

6,123 The device SHALL write entries to a security log whenever changes to access rights of resources occurs. Comply

6,124 The device SHALL write entries to a security log whenever changes to the security configuration (e.g., routing to a security server)) occurs. Comply

6,125 The device SHALL write entries to a security log whenever modification of software occurs. Comply

6,126 The device SHALL write entries to a security log whenever an unauthorized access threshold is changed. Comply

6,127 “Modify” or ”Delete” access to device security logs SHALL be allowed only to element functions and individuals granted the access control level of “Root”, “Administrator” or “Security”. Comply

6,128 “Read” and “Write” access to device security logs SHALL be allowed only to element functions and individuals granted the access control level of “Root”, “Administrator” or “Security” or “Backup”. Comply

6,129 “Modify” or ”Delete” access to device administrative logs SHALL be allowed only to element functions and individuals granted the access control levels of “Administration” or “Security”. Comply



6,130 “Read” and “Write” access to device administrative logs SHALL be allowed only to element functions and individuals granted the access control levels of “Administration” or “Backup”. Comply

6,131 All device security related audit trails must be collected, stored, archived, and reported to the Management System in real-time. Comply

6,132 The device SHALL provide a mechanism for the administrator to optionally record and maintain the audit log in an encrypted encoding. Comply

6,133 The device SHALL provide a mechanism for the administrator to dynamically control the types of events recorded in the audit log. Comply

6,134 Dynamic control of the types of events recorded SHALL include selective disabling of the recording of default audit events and the inclusion of other events such as the following: Valid user authentication attempts. Comply

6,135 Dynamic control of the types of events recorded SHALL include selective disabling of the recording of default audit events and the inclusion of other events such as the following: Creation and deletion of network resources. Comply

6,136 Dynamic control of the types of events recorded SHALL include selective disabling of the recording of default audit events and the inclusion of other events such as the following: Changes in network configuration. Comply

6,137 Dynamic control of the types of events recorded SHALL include selective disabling of the recording of default audit events and the inclusion of other events such as the following: Changes in security states of users, services, and nodes. Comply

6,138 The device SHALL contain a real-time mechanism that is able to monitor the occurrence or accumulation of security auditable events that may indicate an imminent security violation. This mechanism SHALL be able to immediately notify the administrator when administrator-defined thresholds are exceeded, and, if the occurrence or accumulation of these security relevant events continues, the device SHALL provide the capability to take the least disruptive action to terminate the event. Comply

6,139 There SHALL be no mechanism to disable the auditing of administrative actions performed by privileged users. Comply

6,140 Actual or attempted authentication data (e.g., passwords) SHALL NOT be recorded in the security log. Comply

6,141 The device SHALL support the capability to securely off-load audit data to other media for analysis and storage. Comply

6,142 The device SHALL support the capability to specify the condition (e.g., time interval) that causes the security log to be uploaded to a designated storage facility to avoid the overwrite of any information. Comply

6,143 The device MUST support the capability to securely transmit (i.e., with authentication, integrity, and confidentiality mechanisms) audit data to a network designated audit data collection node to off-load the audit capability from other network nodes. (Optional) Comply

6,144 The device SHALL have the capability to monitor, in real time, the occurrence or accumulation of security auditable events that may indicate an immediate security violation. Comply

6,145 When thresholds are exceeded, the device SHALL immediately notify an appropriate administrator. Comply

6,146 The device SHALL have the ability to record remote administrative actions in an audit log. Comply

6,147 The device SHALL provide the capability to off-load stored audit information to another storage media for long-term retention. Comply

6,148 The audit mechanism SHALL notify the administration when audit log space is near capacity. Comply

6,149 An administrator SHALL be able to activate detailed auditing for a specific user ID and/or point of access (e.g., port). Comply



6,150 The device SHALL provide the capability to control priorities so that audit and alarm files can be consistently accessed and data is not lost. Comply

6,151 The device MUST provide mechanisms for recognizing potential DoS attacks and block the logical interface from which sourced. Comply

6,152 Packet Filtering SHALL support Layer 2 access control lists. Comply6,153 Packet Filtering SHALL support filtering rules for allowed packets by

source IP address. Comply6,154 Packet Filtering SHALL support filtering rules for allowed packets by

destination IP address. Comply6,155 Packet Filtering SHALL support filtering rules for allowed packets by

transport protocol. Comply6,156 Packet Filtering SHALL support filtering rules for allowed packets by

destination port numbers. Comply6,157 Regarding Management Interfaces, Packet Filtering SHALL have the

capability discard all packets not explicitly allowed. Comply6,158 Packet Filtering SHALL have settable “on/off” control of blocking all

packets of type ICMP echo request. Comply6,159 Packet Filtering SHALL block all packets associated with the finger, who,

rwho, talk and tftp network applications. Comply6,160 Packet Filtering SHALL support counts of allowed packets by source IP

address. Comply6,161 Packet Filtering SHALL support counts of allowed packets by destination

IP address. Comply6,162 Packet Filtering SHALL support counts of allowed packets by transport

protocol. Comply6,163 Packet Filtering SHALL support counts of allowed packets by destination

port numbers. Comply6,164 Packet Filtering SHALL support counts of blocked packets by source IP

address. Comply6,165 Packet Filtering SHALL support counts of blocked packets by destination

IP address. Comply6,166 Packet Filtering SHALL support counts of blocked packets by transport

protocol. Comply6,167 Packet Filtering SHALL support counts of blocked packets by destination

port numbers. Comply6,168 The requirements in this section apply to all the device which have a

“northbound” interface for surveillance, provisioning, remote administration and other management actions across the NEL-EML-NML-SML layers of the TMN Management Model. Examples of protocols typically used include: SNMPvX, Telnet, TL1, FTP, http, (Simple Object Access Protocol (SOAP)/XML, CORBA and other protocols. Comply

6,169 All authentication information that traverses a data communications network, regardless of being private or public, SHALL NOT travel in "clear" text or otherwise be able to be read by an eavesdropping third party. Authentication includes validation of systems or users, and permissions assigned to those systems/users. Comply

6,170 The device SHALL support per command authorization using Terminal Access Controller Access Control System “Plus” (TACACS+). Comply

6,171 The device SHALL support command privilege levels using TACACS+. Comply6,172 The device SHALL support command exec levels using TACACS+. Comply6,173 IPsec, TLS, and SSHv2SHALL be supported for all device – Management

Systems interaction. Comply6,174 The SNMP default (i.e., “private”, “public”) community name SHALL NOT

be specified or used. Comply6,175 The SNMP implementation SHALL have been tested as free of all Comply



vulnerabilities identified in CERT advisory CA-2002-03 and CERT Summary C2002-01, February 28, 2002, issued by the CERT Coordination Center, Software Engineering Institute, Carnegie Mellon University, Pittsburgh PA 15213-3890, U.S.A.

6,176 SNMP (all versions) SHALL not be used unless over IPsec or Read-Only in a management environment. Comply

6,177 Identification/Authentication, Confidentiality and Integrity SHALL be based on Transport Layer Security (TLSv1) or Secure Shell (SSH) protocols when Telnet, TL1, FTP, W-Terminal/X-Windows or http type protocols are used. Comply

6,178 TLS and SSHv2based identification and authentication SHALL be mutual, specifically bi-directional “two-way” between the device and the MS. Comply

6,179 TLS and SSHv2based identification and mutual authentication SHALL be either based on digital signature from server with TLS secured ID/password from client or based on digital signatures between server and client. Comply

6,180 When ID/password from client are used as part of TLS and SSHv2 based identification and mutual authentication, the TLS or SSHv2 server SHALL interface with a TACACS+ server for validation of client presented ID/password. Comply

6,181 Identification/Authentication, Confidentiality and Integrity SHALL be provided by IPsec if SNMPv3 is used and symmetric “shared secret” keys are NOT deployed. Comply

6,182 The following requirements apply to all system elements that use the Extensible Markup Language (XML) for the storage, transmission or exchange of information: Comply

6,183 When XML is used for information transfers, the XML implementation SHALL be fully compliant with the latest World Wide Web Consortium (W3C) recommendation for XML. Comply

6,184 When XML is used for formatting information transfers, the XML implementation SHALL be fully compliant with the proposed World Wide Web Consortium (W3C) XML signature recommendation. Comply

6,185 When XML is used for formatting information transfers, the XML implementation SHALL be fully compliant with the proposed World Wide Web Consortium (W3C) XML encryption recommendation. Comply

6,186 When XML is used for formatting information transfers, the XML implementation SHALL be fully compliant with the proposed World Wide Web Consortium (W3C) XML key management recommendation. Comply

6,187 XML security, when used over TLS/SSLv3 or IPsec, SHALL be considered equivalent to the use of W3C XML signatures, W3C XML encryption and W3C XML key management. Comply

6,188 The operating system SHALL be on a release currently supported by the manufacturer. Comply

6,189 The operating system in use SHALL be the most current release (Service Pack) or the next most current (older) release. Comply

6,190 Operating system releases more than one release removed from the current release (Service Pack) SHALL NOT be used. Comply

6,191 All systems SHALL display the appropriate proprietary message and warning upon login. Comply

6,192 The “Guest” account SHALL remain disabled (this is the default setting). Comply6,193 The Guest and Install Administrator accounts SHALL be disabled,

renamed and have a unique password defined. Comply6,194 Systems SHALL be set up with a 32 bit password protected screensaver

enabled by default. Comply6,195 Systems SHALL be set to “Prompt for password on resume from

hibernate/suspend”. Comply



6,196 The default “Administrator” account SHALL be renamed to something other "Administrator". Comply

6,197 A new dummy account called “Administrator” SHALL then be created, with a complex password and no rights and then be disabled. Comply

6,198 Authentication Using Passwords Comply6,199 The “Maximum Password Age” SHALL be settable to no more than 180

days or six (6) calendar months. Comply6,200 The “Minimum Password Age” SHALL be set to “Allow Changes

Immediately”. Comply6,201 In the “Minimum Password Length” box, “At Least x Characters” SHALL

be set to at least 8. Comply6,202 The “Password Uniqueness” SHALL be set to at least “remember 12

passwords”. Comply6,203 “Account lockout” SHALL be set after no more than 9 bad attempts, with a

reset after no less than 30 minutes. Comply6,204 “Lockout Duration” SHALL be configurable across the range 15 to 90

minutes. Comply6,205 “Lockout Duration” SHALL be configurable by authorized Administrative

personnel. Comply6,206 If the “Hours” option is used to limit the entity’s access, the “forcibly

disconnect remote entities from server when logon hours expire” option SHALL be selected. Comply

6,207 Passwords on new accounts, or following an entity password reset by an administrator, SHALL be set to expire immediately, requiring the entity to change the password at the first login. Comply

6,208 An account SHALL NOT be created where the password is the same as the account UserID. Comply

6,209 The system SHALL enforce at least the following password format structure: at least one numeric, at least one alpha character, and SHALL NOT contain the account UserID in the password. Comply

6,210 Audit logging MUST be enabled for at least the following events: Logon and logoff - success and failure. Comply

6,211 Audit logging MUST be enabled for at least the following events: File and object access – failure. Comply

6,212 Audit logging MUST be enabled for at least the following events: Use of user rights – failure. Comply

6,213 Audit logging MUST be enabled for at least the following events: User and Group Management - success and failure. Comply

6,214 Audit logging MUST be enabled for at least the following events: Security Policy Changes - success and failure. Comply

6,215 Audit logging MUST be enabled for at least the following events: System events - success and failure. Comply

6,216 Audit logging MUST be enabled for at least the following events: Process tracking – failure. Comply

6,217 Audit logging MUST be enabled for at least the following events: Additional events as needed . Comply

6,218 Services and Subsystem Security Comply6,219 Only those services and subsystems that are absolutely required are

allowed, all others SHALL be disabled. Comply6,220 Services or subsystems that SHALL be disabled are: Trivial File Transfer

(TFTP). Comply6,221 Services or subsystems that SHALL be disabled are: Finger. Comply6,222 The following services SHALL NOT be used: Anonymous File Transfer

Protocol (FTP), unless providing public information. Comply6,223 The following services SHALL NOT be used: Network Information System Comply



(NIS). However, NIS+ can be used. 6,224 The following services SHALL NOT be used: Network File System (NFS). Comply6,225 The following services SHALL NOT be used: Remote Access Service (RAS)

Server. Comply6,226 The following services SHALL NOT be used: Berkeley Software Design

(BSD™) r* commands. Comply6,227 The following services SHALL NOT be used: ECHO . Comply6,228 The following services SHALL NOT be used: Chargen. Comply6,229 FTP Comply6,230 If the FTP server service is needed, it SHALL be configured as follows:

The appropriate notice SHALL be displayed upon connection. Comply6,231 If the FTP service needs to run on a system, it is recommended that it be

assigned a complete disk partition as the FTP directory, rather than using a directory on a partition containing other information. Comply

6,232 To help prevent denial of service attacks the FTP server MUST be configured for only a limited number of connections. Comply

6,233 An FTP server SHALL display the appropriate proprietary banner and notice. Comply

6,234 Hyper Text Transfer Protocol (HTTP) Server Service Comply6,235 To help prevent denial of service attacks the HTTP server MUST be

configured for only a limited number of connections. Comply6,236 Redundancy and reliability have an impact on system availability and

thus affect the security of the system. The following requirements apply to all located devices. Comply

6,237 The device SHALL provide measures to combat common Denial of Service (DoS) attacks, notably TCP SYN flood and Smurf attacks. Comply

6,238 The device MUST provide measures to mitigate Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks associated with control plane traffic. Comply

6,239 The device SHALL support protection for control packets for each routing protocol against DDoS flood. Comply

6,240 The device SHALL use separate queues for control packets for every control and routing protocol and implementation MUST be such that attacks on a particular type of control/routing traffic should not impact other control and routing traffic. Comply

6,241 The device SHALL monitor unusual levels of control traffic and apply rate limits on per protocol basis. Comply

6,242 In case of high CPU utilization, system elements SHALL ensure that authorized SNMP surveillance traffic and any other real time platform management interface have priority over all other traffic. Comply

6,243 In the event of systems being under attack, resource management mechanisms SHALL ensure access for system administrator(s). Comply

6,244 Device Software Installation and Upgrades Comply6,245 TFTP SHALL NOT be used for downloads or uploads of any software or

configuration data. Comply6,246 The device SHALL be capable of being upgraded and maintained without

having to shutdown or reboot. Comply6,247 All device system and application software executing within each

element SHALL be verified as free of Buffer overflow software vulnerabilities. Comply

6,248 All device system and application software executing within each element SHALL be verified as free of Trojan horse software vulnerabilities. Comply

6,249 Complete directions on how to securely install and configure each device SHALL be provided at time of delivery. Comply



6,250 A description of the procedure(s) for acquiring and incorporating the latest security patches for the device system and application software executing within each element SHALL be provided at time of delivery. Comply

6,251 A description of the process for testing each security patch, before approving release SHALL be provided at time of delivery. Comply

6,252 The level of backward compatibility of the device system software releases and security maintenance patch releases SHALL be specified at time of delivery. Comply

6,253 Each device includes some form of operating system software. The following requirements apply to all devices: Comply

6,254 rlogin, rsh and all other common “r” command functionality SHALL NOT be enabled. Comply

6,255 Anonymous FTP functionality SHALL NOT be enabled or required for any functionality. Comply

6,256 Network File System (NFS) functionality SHALL NOT be enabled or required. Comply

6,257 The SNMP default (i.e., “private”, “public”) community name SHALL NOT be specified or used. Comply

6,258 Any Web Server functionality used to access or manage a system element SHALL be certified in writing by the supplier(s) as uncompromizable resulting from buffer overflows. Comply

6,259 HTTP trace functionality SHALL be disabled in any deployed web server. Comply6,260 ActiveX SHALL NOT be used within the system, either between system

elements or within a system element. Comply6,261 Login identifiers SHALL be required for system access. Comply6,262 Login functions SHALL require a non-blank (i.e., not Null) user identifier

for log-in. Comply6,263 Any default identifiers SHALL be capable of being deleted. Comply6,264 Login identifiers SHALL have a minimum length of 8 characters (mixed

alphabetic and numeric). Comply6,265 Login identifiers SHALL be stored in a non-volatile manner. Comply6,266 Login passwords SHALL be required for system access. Comply6,267 Login passwords SHALL NOT be disclosed/displayed on the screen when

entered during login. Comply6,268 Login password lengths SHALL NOT be disclosed/displayed on the

screen when entered during login. Comply6,269 Login functions SHALL require a non-blank (i.e., Null) user password for

log-in. Comply6,270 Any default passwords SHALL be capable of being deleted. Comply6,271 Login passwords SHALL have a minimum length of 8 characters (mixed

alphabetic and numeric with special characters allowed). Comply6,272 Login passwords SHALL be stored in a non-volatile manner. Comply6,273 Login passwords SHALL be stored in an encrypted form only. Comply6,274 Login password encrypted storage SHALL use the MD-5 hash algorithm

at a minimum. Comply6,275 Login password encrypted storage SHALL use the SHA-1 hash algorithm

as an alternative to the MD-5 hash algorithm. Comply6,276 An age threshold SHALL be definable for all login passwords. Comply6,277 Login passwords SHALL be voided when the password has exceeded the

password age threshold. Comply6,278 The age threshold for login passwords SHALL be disableable. Comply6,279 Selection of a new device OS password to replace an expired password,

due to exceeding the age threshold, MUST NOT be the same as at least the Comply



3 previous passwords. 6,280 The minimum age threshold for login passwords SHALL be 30 days. Comply6,281 The maximum age threshold for login passwords SHALL be 999 days. Comply6,282 Login identifier verification SHALL use a token method, such as SecureID,

as an alternative to passwords. Comply6,283 Login functions (processes) SHALL support password age checking. Comply6,284 Login functions SHALL support a settable threshold of tries a user will be

given to enter a valid login ID and password combination. Comply6,285 Login functions SHALL support disabling the threshold of tries a user will

be given to enter a valid login ID and password combination. Comply6,286 The minimum threshold of tries a user will be given to enter a valid

login/password combination SHALL be 1 attempt. Comply6,287 The maximum threshold of tries a user will be given to enter a valid

login/password combination SHALL be 5 attempts. Comply6,288 The threshold of tries a user will be given to enter a valid login/password

combination SHALL be settable only by those individuals, granted the access control level of “Administrator” or “Security Administrator”. Comply

6,289 Service function thresholds for unauthorized/invalid login attempts SHALL be settable only by those individuals, granted the access control level of “Administrator” or “Security Administrator”. Comply

6,290 Login functions SHALL lock out the keyboard or session when the threshold for unauthorized/invalid attempts is exceeded. Comply

6,291 Only an individual granted the access control level of “Administrator”,“ Security”, or System Administrator SHALL be allowed to restore a locked out keyboard or session after the threshold for unauthorized/invalid attempts has been exceeded. Comply

6,292 Login functions SHALL support a settable time interval between 1 minute and 360 minutes that controls the period of keyboard or session lockout following the user failure to enter a correct login/password combination within the allocated number of attempts. Comply

6,293 Login function time interval that controls keyboard or session lockout SHALL be settable only by those individuals, granted the access control level of “Administrator”, “Security”, or System Administrator. Comply

6,294 Only an individual granted the access control level of “Administrator” SHALL be allowed to restore a locked out keyboard or session after the threshold for unauthorized/invalid attempts has been exceeded. Comply

6,295 The device SHALL support Access Control Lists (ACLs) that define allowed access to administrator functions. Comply

6,296 Devices SHALL support Access Control Lists (ACLs) that define allowed access to information (data) stored/maintained within a service function. Comply

6,297 Device ACLs SHALL support “Read”, “Write”, “Delete”, and “Execute” access rights associated with information (data) stored/maintained within the function. Comply

6,298 Device ACLs SHALL associate user identifiers and assigned security levels with allowed access to Administrative functions and information. Comply

6,299 The device SHALL log unauthorized access attempts in a customer administrative log file. Comply

6,300 The device SHALL support use of alarm thresholds for counts of unauthorized access attempts. Comply

6,301 Device alarm count thresholds of unauthorized access attempts SHALL be settable only by those individuals, granted the access control level of “Administrator” or “Security”. . Comply

6,302 Device OS Security Audit Trail Log Comply6,303 Device OS log file time & date stamps SHALL be based on Device system Comply



time & date information.6,304 Device system time & date information SHALL be synchronized with

other the Device and EML (Element Management Layer), NML (Network Management Layer), SML (Service Management Layer) and BML (Business Management Layer) systems by use of the Network Time Protocol version 3 (NTPv3) including support for RY 1305 Appendix C message authentication. Comply

6,305 Device security log entries SHALL include the security level of the individual. Comply

6,306 The device SHALL support the capability to securely transmit (i.e., with authentication, integrity, and confidentiality mechanisms) audit data to a network designated audit data collection node to off-load the audit capability from other network nodes. Comply

6,307 The device RADIUS clients SHALL employ mechanisms to maximize entropy of the Request Authenticator. Comply

6,308 The Request Authenticator SHALL be temporarily and globally unique to the device. Comply

6,309 Different RADIUS server parameters (Server address, Secret, Timeouts) SHALL be configurable for each authentication method (e.g. EAP [Extensible Authentication Protocol], PAP). Comply

6,310 Device RADIUS clients SHALL include failover logic to new RADIUS servers if the current server stops responding. Comply

6,311 The device RADIUS client MUST support EAP-TLS as specified in RY 3748, RY 2716. Comply

6,312 The secret shared between the client and the RADIUS server SHALL be at least 16 octets in size. Comply

6,313 The device SHALL be able to forward RADIUS accounting traffic to accounting servers that are different than the RADIUS authentication servers. Comply

6,314 The device SHALL be configurable to attach to multiple RADIUS authentication servers. Comply

6,315 The device SHALL be configurable to attach to multiple RADIUS accounting servers. Comply

6,316 The device SHALL have the option to strip the domain name extension before forwarding the user name to a RADIUS server. Comply

6,317 The device SHALL support RADIUS accounting of DHCP IP address assignment. Comply

6,318 The protocols used to provide assurance of authenticity and confidentiality for signaling and routing SHALL be IPsec. Please specify if ANY routing and signaling protocols cannot be protected with IPsec in your device implementation. Comply

6,319 The protocols used to provide assurance of management protocols SHALL be: TLSv1, SSH, IPsec, and CORBA - XML Security mechanisms. Comply

6,320 Management Plane functions supported by the protocols, SNMP, HTTP, Telnet, TL1, FTP, CORBA and XML SHALL be secured by the use of TLS mechanisms (i.e. SSH/TLSv1 ) or by the use of network layer mechanisms (specifically IPsec over IP version 4 or the native IPsec capabilities of IP version 6). Comply

6,321 Regarding IEEE 802.1q, MAC addresses SHALL be specified for each port or some other mechanism is used to prevent malicious users from sending rootid bpdu. Comply

6,322 802.1q signaling SHALL be settable (on/off) on all ports. Comply6,323 802.1q auto trunking SHALL be settable (on/off) on all ports. Comply6,324 Regarding IEEE 802.1d (Spanning Tree Protocol), separate spanning tree

instances SHALL be supported for each VLAN. Comply



6,325 Method(s) to manage memory resources used in tracking MAC addresses and VLAN parameters SHALL be supported. Please explain how this is accomplished. Comply

6,326 Regarding Definition of the Differentiated Services (DS) Field as specified in RY 2474, the device SHALL provide mechanisms to validate that ingress traffic is marked with codepoint values appropriate for the traffic and the ingress port. Comply

6,327 The device use of IPsec in a DS environment SHALL NOT change the inner header's DS field by decapsulation processing to ensure that modifications to the DS field cannot be used to launch theft of service or DoS attacks across an IPsec tunnel endpoint. Comply

6,328 Does it implement an authentication mechanism for NTP? Please describe.What are the other security features available? Please describe.Ability to use filter list to define only IP server need? Comply

6,329 ftp protection Comply6,330 Does the router implement access control list on data plane?

If so please provide a list of available criteria that can be used in the matches Comply

6,331 Do these access control list support IPv6? If so is there any restriction or new criteria that can be used in the matches? Comply

6,332 Is it possible to name access lists? Comply6,333 Is it possible to use criteria referenced by a name (a group of network

prefixes or tag for instance) in an access list ? Comply6,334 Is it possible to log the hits (success and failure)?

Does the router implement a summarization mechanism? Do these logs could be exported via syslog?Can we configure a logging rate? Comply

6,335 Does the router implement dedicated security filters to protect the router processor?If so, please elaborate on the mechanism and give an exhausted list of available criteria for the matches. Comply

6,336 Do these security filters (above question) support IPv6 traffic? If so, is there any restriction or new criteria for the matches? Comply

6,337 Possibility to apply IP filter rules (input and output) per interface? If so, does this filtering have any impact on the forwarding performances? Comply

6,338 Can filters be applied to MPLS traffic without traffic needing to leave MPLS environment? Comply

6,339 Is it possible to associate an ACL rule to - a BGP tag like "filter all IP packet where destination @IP is known in the local routing table as belonging to 3215:200 community- ISIS learn @ (aka all address learn by ISIS must not be joignable from an external interface) Comply

6,340 Does log action of drop packets have an impact on CPU in case of massive drop (DoS) ? Comply

6,341 Do you provide some statistic view on drop packets like"In the last 24 hours, x packets were drop by entry 1 of ACL toto. " Comply

6,342 Do you provide some statistic view on drop packets like" In the last hour, x packets were drop by entry 1 of ACL toto with Source Ip 1, destination IP 2, source port 1, destination port 2" Comply

6,343 Does the equipment support Denial Of Service (DoS) tracking system? Please elaborate on the security events that can be logged? Comply

6,344 Can security events be reported (via Syslog, Secure Syslog, SNMP trap, others…)? Please elaborate. Comply

6,345 Can some management protocol be disabled? Is it global or per Comply



interface/virtual router?6,346 Is access to management defined by user name, incoming interface or

both? Comply6,347 Is managment plane on dedicated hardware ? Comply6,348 Are the log messages time-stamped? Is process/virtual-router/user ID

included? Comply6,349 Do you support an ingress filtering capability for IP unicast packets based

on Reverse Path Forwarding mechanism as introduced in RFC 3704?Please describe HW and possible limitation of the implemented mechanism (IPv4 and IPv6). Comply

6,350 Do you support Ingress Access Lists as described in RFC 3704? Comply6,351 Do you support Strict Reverse Path Forwarding as described in RFC

3704? Comply6,352 Do you support Loose Reverse Path Forwarding as described in RFC

3704? Comply6,353 Do you support Loose RPF mode ignoring default routes as described in

RFC 3704? Comply6,354 Do you support Strict and Loose RPF mode with discard/blackhole

(RTBH filtering) as described in RFC 5635? Comply6,355 Do you provide statistics on IP packets dropped due to ingress filtering

with RPF? Please detail if an alarm can be raised on threshold of packets dropped. Comply

6,356 Do you provide some sort of service (like ACL) to protect the control plane that can be enable on the router? For each of them, please:• Precise the default state (enable/disable) and the way the services accept new connection (dedicated socket, routing process super-daemon)• Precise the address families the service supports.Elaborate on the available protections to restrict the access that can be configured (dedicate ACL, dynamic ACL…)• Elaborate the available protections to control the different process (policing, prioritization…)• Is this mechanism implemented in software or hardware, is there any potential impact on the convergence time?• Does the implementation provide counter, log functions? Comply

ManagementClause Compliance

Comply (Comply/Partial Comply)

7,01 Does the equipment support community based SNMP v1? If so, please detail if one access-list can be attached to one community and if “views” supports inclusions and exclusions. Please give the maximum number of communities and hosts that can be supported. Comply

7,02 Does the equipment support community based SNMP v2c? If so, please detail if one access-list can be attached to one community and if “views” supports inclusions and exclusions. Please give the maximum number of communities and hosts that can be supported. Comply

7,03 Are the 64-bit traffic counters supported for all interfaces? Comply7,04 Is GET-BULK supported? Comply7,05 Does the equipment support USM-based SNMP v3? Please detail if

“views” supports inclusions and exclusions. Please give the maximum number of users/groups that can be supported and detail if one access list can be attached to one user. Comply

7,06 What are the supported combinations of Auth / Priv? Please describe Comply



the usable systems for key management.7,07 Is SNMP SET supported? Please elaborate on the possible restrictions to

some MIBs or OIDs. Comply7,08 Are the incoming SNMP packets serialized or parallelized? Please

describe your queuing mechanism. Comply7,09 For all versions of SNMP, how are defined the IP source address and the

UDP source port of the response packet? If it is not the direct mapping of the destination IP address and destination UDP port of the SNMP query packet, as it is expected to be, can it be configured? Please elaborate. Comply

7,10 Same question as above for a virtual router, respectively a logical router (if different and if applicable)? Please elaborate. Comply

7,11 Is the transport of SNMP packets over IPv6 supported? Comply7,12 If the equipment supports “null” interfaces (packet sinks), are those

interfaces present in IF-MIB or in a dedicated MIB? Please describe how many “null” interfaces could have counters attached. Comply

7,13 If supported, do logical routers, respectively virtual routers, have a distinct “view” showing their respective resources? Comply

7,14 Is indexes persistency supported? If so, please detail which indexes. Comply7,15 Does the equipment support an SNMP-based SLA probe? If so, please

elaborate on the supported probes (attention will be given to RTT and Jitters, with and without VRFs, and to IPv6). Comply

7,16 Regarding interface accounting and routing, does the equipment support dedicated IPv4 and IPv6 OIDs? If so, is it in through new generation IP-MIB/IP-FORWARD-MIB/BGPv2-MIB/etc or is IPv6 handled in dedicated MIBs? In any case, please elaborate. Comply

7,17 Does your equipment support the following IETF MIBs? ATM-MIB, BGP4-MIB, BGP4-V2-MIB, BRIDGE-MIB, DISMAN-PING-MIB, ENTITY-MIB, IF-MIB, IP-FORWARD-MIB, IGMP-MIB, IP-MIB, IPMROUTE-MIB, IPV6-MIB, MPLS-LSR-MIB, MPLS-VPN-MIB, MSDP-MIB, OSPF-MIB, OSPFV3-MIB, PIM-MIB, PWE3 MIBs, SNMPv2-MIB, SONET-MIB and VRRP-MIB.Please list all other IETF MIBs that your equipment supports, their version (which RFC or draft) and their level of implementation (complete or not, with details).You are encouraged to provide with your answers your MIB files (in a format that can be compiled) and a dump of a “walk” of the complete MIB tree (long routing tables could be shortened for practical reasons). Comply

7,18 Does your equipment support enterprise specific MIBs or non-IETF MIBs?Special attention will be given to MIBs related to configuration management, environmental monitoring, hardware (inventory from the rack down to the optics, fans, power modules, including CPUs, memory, disks and/or flashes), accounting and routing not covered by IETF MIBs, firewall/ACL and src/dst class accounting.You are encouraged to provide with your answers your MIB files (in a format that can be compiled) and a dump of a “walk” of the complete MIB tree (long routing tables could be shortened for practical reasons). Comply

7,19 Does the equipment support notification through SNMP traps? If so, please specify the version(s) supported (and the corresponding parameters), and the number of destinations configurable. Comply

7,20 Are the source IP address and source UDP port of the SNMP traps configurable? Please detail how they are configured and their default values. Partial Comply

7,21 Do you support the traps defined in IETF RFCs or drafts that are supported by the equipment. Please detail the ones supported.

Comply



Special attention will be given to routing protocols events, system events, interface events so please be exhaustive.

7,22 Does your equipment support notifications for both beginning and end of events? Comply

7,23 Does the equipment provide a XML programmable API? Please elaborate and please list the different XML schemas available. Comply

7,24 Is this API conformant with NETCONF? Please elaborate on the level of conformance and on the capabilities supported. Comply

7,25 Are configuration operations possible through this API? Please elaborate. Comply

7,26 Are operational information (interfaces and adjacencies states, counters, environmental data...) available through this API? Please elaborate. Comply

7,27 Are transport protocols available to use this API? Please list them and include the protection mechanisms (such as ACLs protecting the service, encryption of the sessions, etc). Comply

7,28 Do you provide a toolkit to use this API? If so, what are the supported languages? Comply

7,30 Does the equipment provide a way to run scripts within the box? Please elaborate. Comply

7,31 For each access mode (Telnet, SSH, HTTP / SHTTP, SSL, IPSec, Accounting), please describe the authentication and authorization procedures whenever granted access to the equipment is required. Comply

7,32 Is it possible to have different authentication and authorization processes for each different possible mode? If so, please elaborate.Is it limited to dedicate interface (Console, Aux, port). Comply

7,34 Is it possible to define an access password and limit the timeout of the idle sessions to the line access? Comply

7,35 What are the protocols that can be used for AAA purposes? For each of these options, please elaborate on the AAA procedure itself (in particular Radius and TACACS+). Comply

7,36 Is it possible to configure multiple AAA servers for each supported protocol? Please elaborate on the maximum number of servers and describe limitations such as maximum authentication key length and authentication algorithms implemented. In particular, does the authentication traffic transit in clear text or is it encrypted? Comply

7,37 Is the traffic between the equipment and the AAA servers encrypted? If yes, please describe algorithm. Comply

7,38 Do you implement a backup process in case of impossibility of joining AAA servers? Comply

7,39 Can administrative command be logged? If so, please describe the different possibility. Comply

7,40 Do you provide multiple authorization levels? Please, elaborate on the authorization management feature, in particular on the following points:- describe the different authorization levels- describe the different possibilities to define user groups- describe the way a user can be restrict to a subset of commands- Is it possible to log each configuration changes? Comply

7,41 Do you implement default accounts? Please elaborate on the following items:- How and where are the local passwords stored?- If passwords are encrypted, which encryption / hashing modes are available?- How can a local password be changed?- How many local accounts can be configured in the equipment? Comply

7,42 Is it possible to deny unwanted services like IP source-route, finger, Comply



etc?What are the other security features available? Please describe.

7,43 System must support standard SNMP traps for all faults in the system. Comply7,44 System must support a separate trap for every system affecting or

performance affecting event or error. Comply7,45 System must support the ability to enable/disable a trap for each fault

type. Comply7,46 System must support ability to configure thresholds for traps, where

applicable. Comply7,47 System must support ability to configure send traps to a minimum of 8

systems (IP addresses). Comply7,48 System should support ability to control/specify destination(s) of each

trap. Comply7,49 Vendor shall provide a comprehensive lists of all traps supported by

the system and recommendation on the alarm severity for each trap. Comply7,50 The device shall support SNMPv3 and RMON Ethernet PM on all

Ethernet interfaces. Comply7,51 System must support IETF RY 2863, The Interfaces Group MIB. Comply7,65 System must support IETF RY 3289, MIB for Differentiated Services

Architecture. Comply7,66 Provide the complete list of MIBs, both standard and enterprise,

supported by the platform. Comply7,67 System must support statistics for non-conforming (yellow) frames

dropped at each queuing point in the system on a per-port, per-queue} basis. Comply

7,68 System must support statistics for conforming (green) frames dropped at each queuing point in the system on a per-port, per-queue basis. Comply

7,69 System should support statistics for non-conforming (yellow) frames dropped at each queuing point in the system on a per-port, per-queue, per-VLAN basis. Comply

7,70 System should support statistics for conforming (green) frames dropped at each queuing point in the system on a per-port, per-queue, per-VLAN basis. Comply

7,71 System should support on-demand monitoring of queues on a per-port, per-queue, per-VLAN basis. Comply

7,72 System must support statistics for utilization at each queuing point in the system on a per-port, per-queue} basis. Comply

7,73 System must supports statistics for dropped (red) frames at the ingress policer on a per-port, per-queue, per-VLAN, per-class-of-service} basis. Comply

7,74 System must support a minimum of 64-bit counters for Ethernet statistics. Comply

7,75 Count of Originating/terminating LSP Comply7,76 Count of Transit LSP's Comply7,77 Bandwidth reservation (RSVP) per LSP Comply7,78 Bandwdith reservation per port Comply7,79 Bandwidth utilization per port Comply7,80 Utilization per port by CoS Comply7,81 Dropped packets per queue Comply7,82 Auto bandwidth changes as they happen Comply7,83 The device shall have full fault detection and isolation architecture. Comply7,84 The fault detection shall include hardware and software error

malfunctions. Comply7,85 Each fault detected shall generate an Alarm/event. Comply7,86 The device will support selection of traps to generate. Comply



7,87 Alarm severity shall have a default and will be user configurable. Comply7,88 Alarms will indicate: alarm severity and alarm type, date and time,

probable cause, device. Comply7,89 Alarms will detail problems down to the device, hardware unit, card,

port, physical and logical connection. Comply7,91 Alarms shall be categorized in 3 different levels: 7,92 Catastrophic/Critical: Priority 1. Comply7,93 Major: Priority 2 Comply7,94 Minor: Priority 3 Comply7,95 Information/Event: priority 3 Comply7,96 The fault management function shall identify the fault as hardware or

software specific. Comply7,97 Alarms and Problem Reports shall be sent to the following systems: 7,98 · Local Craft Interface Comply7,99 · Problem Log Comply

7,100 · Alarm Log (disk) Comply7,101 · Shelf Alarm Panel (visual and audible) 7,102 · Up to 8 destination remote peripheral device, such as a device OSS or

Network Management System Comply7,103 The device shall supply a Heartbeat to the Network Management

system. Provide details. Comply7,104 The device will support 8 destination IP address for reporting to

remote Management platforms. Destination addresses can be set via the craft, telnet and Management system. Comply

7,105 Ethernet (Loss of Signal, Loss of Link and CRC/Frame errors received at the Ethernet interfaces) – see below for more information Comply

7,106 Software failures Comply7,107 Security violations Comply7,108 Loss of Signal (LOS - on electrical interfaces-) Comply7,109 The information should be attainable from the Ethernet MIB/RMON

MIB. If a standard is developed in the future to deal with these issues, it should be followed. Comply

7,110 The device shall support collection of performance data, based on two methods: periodic snapshots and persistent memory. In each case, the vendor shall provide for accumulation of data in real time in files. Either OSS SFTP will be used for file transfer of stored data. Comply

7,111 System must support data collection interval for real-time performance management must be 5 minutes or less. Comply

7,112 System performance data must be collected via out-of-band interface and in-band management interface. Comply

7,113 System 5-minute performance data must be collected via SNMP GET to read the value of an SNMP object specified by the OID. Comply

7,114 System must support simultaneous polling by a minimum of four systems every five minutes. Comply

7,115 System must support Threshold Crossing Alerts (TCAs) with user provisionable thresholds for each PM parameter (with exception of status parameters). Comply

7,116 System must support the ability to enable/disable reporting of TCA on a per-parameter and per client port basis. Comply

7,117 System must support access of all performance monitoring data by the EMS, NMS and/or OSS. Comply

7,118 System must continue to collect statistics when counters are reset via the CLI or NMS. Comply



7,119 The device shall provide Performance Monitoring (PM) data collection at different hierarchical levels Comply

7,120 What size counters are supported for each interface type? Comply7,121 Can the counters be reset per port and/or EVC? Comply7,122 Performance monitoring data is used for troubleshooting and for

reporting performance statistics to customers. The data must be reported accurately and be stored in the device long enough to be collected. Comply

7,123 Octets Received Comply7,124 Octets Transmitted Comply7,125 Frames Received without Errors Comply7,126 Frames Transmitted without Errors Comply7,127 Jumbo Frames Received Comply7,128 Jumbo Frames Transmitted Comply7,129 Pause Frames Received Comply7,130 Pause Frames Transmitted Comply7,131 Time Valid Carrier Present on LAN Interface Comply7,132 Time Valid Carrier not Present on LAN Interface Comply7,133 The following cumulative Ethernet LAN (client interface) PM error

parameters shall be supported. 7,134 Frames Received with Errors (types of errors are broken out below) Comply7,135 Frames Received and Discarded with Errors Comply7,136 Frames not Transmitted due to Errors Comply7,137 Frames Transmitted with Errors Comply7,138 Frames Received and Discarded due to Congestion (buffer overflow) Comply7,139 Frames Received with YS Errors Comply7,140 Frames Received with Alignment Errors Comply7,141 Frames Received not Transmitted due to MAC Errors Comply7,142 Oversized Frames Received (over provisionable MTU) Comply7,143 Runts Received (< 64 bytes with CRC errors) Comply7,144 Jabbers Received (>1548 bytes with CRC errors) Comply7,145 Total Frames Comply7,146 Broadcast Frames Comply7,147 Multicast Frames Comply7,148 Undersize Frames Comply7,149 Oversize Frames Comply7,150 Fragmented Frames Comply7,151 Jabbers Comply7,152 Number of Frames less than 64 Octets Comply7,153 Number of frames 65-127 Octets Comply7,154 Number of frames 128-255 Octets Comply7,155 Number of frames 256-511 Octets Comply7,156 Number of frames 512-1023 Octets Comply7,157 Number of frames 1024-1518 Octets Comply7,158 Number of frames 1518-2048 Octets Comply7,159 Number of frames 2048-4096 Octets Comply7,160 Number of frames 4096-8000 Octets Comply7,161 Number of frames 8000-9600 Octets Comply7,162 The following alarm conditions shall be reported and be able to be

retrieved: Comply



7,163 Raising Alarm Comply7,164 Falling Alarm Comply7,165 Raising threshold Comply7,166 Falling threshold Comply7,167 When a request to retrieve alarms is received all current alarm and

threshold crossing events shall be reported. Comply7,168 Performance statistics shall be able to be cleared and reset on a per

port and/or EVC basis. Comply7,169 The device shall provide Threshold Crossing Alerts (TCAs) with user

provisionable thresholds for each PM parameter (for the error PM parameters only – not for the status parameters). Comply

7,170 All performance monitoring data shall be accessible by the EMS/NMS or OSS. Comply

7,171 The device must implement Simple Network Management Protocol version 1 as defined in RfC1157. Comply

7,172 The device must implement Simple Network Management Protocol version 2c as defined in RfC1901. Comply

7,173 The device must implement Simple Network Management Protocol version 3 as defined in RfC 3410 - 3418. Comply

7,174 The device must implement Simple Network Management Protocol version 1 trap generation to the trap receiver. Comply

7,175 The device must implement Simple Network Management Protocol version 2c trap generation to the trap receiver. Comply

7,176 The device must implement Simple Network Management Protocol version 3 trap generation to the trap receiver. Comply

7,177 The device provide a facility for limiting SNMP access to a list of hosts or source IP addresses. Comply

7,178 The vendor must state how servicing SNMP requests impacts the performance of the router's control plane or forwarding plane. Comply

7,179 The vendor must state the maximum rate at which SNMP requests can be handled. Comply

7,180 The device must implement SMI version 2 as defined in RfC2578. Comply7,181 The vendor must state all underlying SNMP transport protocols (L3)

implemented by the device. Comply7,182 The device must implement SNMP views to restrict SNMP access based

on the SNMP community values. Comply7,183 The device must implement Simple Network Management Protocol

(SNMP) MIB II according to RfC 1213. Comply7,184 The device must implement the Remote Monitoring (RMON) MIB

according to RfC 2819. Comply7,185 The device must implement "Management Information Base for the

Internet Protocol (IP)" according to RfC 4293 Comply7,186 The device must implement the TCP MIB according to RfC 4022. Comply7,187 The vendor must details any 'optional' or 'should' requirements defined

in RFC1157 (Simple Network Management Protocol version 1) that their proposed device does not implement Comply

7,188 The vendor must details any 'optional' or 'should' requirements defined in RFC1901 (Simple Network Management Protocol version 2c) that their proposed device does not implement Comply

7,189 The vendor must details any 'optional' or 'should' requirements defined in RFC 3410 (Simple Network Management Protocol version 3) that their proposed device does not implement Comply

7,190 The vendor must details any 'optional' or 'should' requirements defined in RFC 2578 (SMI version 2) that their proposed device does not

Comply



implement7,191 The vendor must details any 'optional' or 'should' requirements defined

in RFC1213 (Simple Network Management Protocol (SNMP) MIB II) that their proposed device does not implement Comply

7,192 The vendor must details any 'optional' or 'should' requirements defined in RFC 2819 (Remote Monitoring (RMON) MIB) that their proposed device does not implement Comply

7,193 The vendor must details any 'optional' or 'should' requirements defined in RFC 4293 (Management Information Base for the Internet Protocol (IP)) that their proposed device does not implement Comply

7,194 The vendor must details any 'optional' or 'should' requirements defined in RFC 4022 (TCP MIB) that their proposed device does not implement Comply

7,195 The device must implement configuration of source interface (IP address) for snmp protocols Comply

7,196 The device must implement time synchronization via Network Time Protocol version 3 according to RfC 1305 as an NTP server. Comply

7,197 The device must implement time synchronization via Network Time Protocol version 3 according to RfC 1305 as an NTP client. Comply

7,198 The device must implement the authentication of NTPv3 messages (e.g. with MD5 hashing). Comply

7,199 The vendor must details any optional requirements defined in RFC 1305 (Network Time Protocol version 3) that their proposed device does not implement Comply

7,200 The device must implement configuration of source interface (IP address) for NTP. Comply

Documents

Описание услуги «Аудиоконференцсвязь»¢Т CR draft 2014_02_19.… · Web viewТехнические требования к оборудованию