Аппаратно-диагностический комплекс для анализа видео-потоков и их интеграция в системы контроля

ОАО «Московская Городская Телефонная Сеть»
Аппаратно-диагностический комплекс для анализа
видео-потоков и их интеграция в системы контроля
качества передачи видеоизображений
по государственным контрактам с ДИТ г. Москвы.
Требования технические.
Версия 1.0
Москва
2014
1.
Общие требования к комплексу:
1.1 В рамках оказания услуг по государственным контрактам комплекс для анализа
видео-потоков должен обеспечивать постоянный сбор статистических данных на
уровне предоставляемых услуг (не ниже уровня приложений по модели OSI).
1.2 Комплекс для анализа видео-потоков должен обеспечивать:
- контроль параметров качества передачи видео-потока от камер
видеонаблюдения по сети Заказчика;
- оперативную регистрацию изменений (событий, инцидентов), происходящих на
сети и влияющих на качество передачи видеоизображения.
1.3 Программная архитектура комплекса должна обеспечивать
интеграцию в системы контроля качества видеоизображения ОАО МГТС.
2.
Требования к функциональности по сканированию и фильтрации сетевого
трафика:
2.1
Распознавание и анализ содержимого пакетов на уровнях сетевой модели OSI от
уровня 2 до уровня 7. Возможности по сканированию содержимого пакетов должны
включать:

сканирование, распознавание и фильтрацию протоколов на уровнях от 2 до 4
сетевой модели OSI и их содержимого включая:

сканирование, распознавание и фильтрацию сетевых потоков данных включая
реинкапсуляцию и фильтрацию типов пакетов – VLAN 802.1Q, VLAN 802.1Q-in-Q, MPLS,
PWE3, tcp, udp.

сканирование, распознавание, фильтрацию пакетов, передаваемых в jumbo-frame
до 64k байт;

Возможность сканирования не менее 8 интерфейсов (не менее 8x10Gb/s) съёма
трафика, работающих в любых режимах балансировки трафика, в том числе по
алгоритмам мас and mac, src ip – dst ip, src ip + порт – dst ip + port, но не ограничиваясь
ими.
2.2
Распознавание и анализ содержимого пакетов на сетевой модели OSI уровня 7
должны включать - классификацию и фильтрацию протоколов сеансового уровня RTSP,
RTCP;
Аккуратность распознавания - наличие нераспознанного трафика RTP должно составлять
0%.
2.3
Возможность просмотра и сохранения изображения для видео-потока с
произвольного IP-адреса из списка доступных источников.
3.
Требования к анализу протоколов RTCP и RTSP:
3.1 Автоматическое обнаружение потоков RTP, привязка данных потоков к IP
адресам;
3.2 Анализ и отслеживание поведения установленных сессий, наличие поведенческих
механизмов протоколов RTCP и RTSP при подключённом к системе мониторинга
обратном направлении передачи данных (опционально);
3.3 Анализ и контроль следующих характеристик передаваемых видеопотоков RTP (в
кодеке H.264):
- Потери пакетов;
- Количество пакетов;
- Неоднородность задержки (джиттер);
- Остановку видеопотока RTP (отсутствие пакетов в потоке в течение заданного
времени или отсутствие информативного изображения);
- Очерёдность прихода пакетов (packet reordering);
- Появление видео-потока;
- Исчезновение потока от ранее зафиксированного IP-адреса/камеры;
- Наличие RTCP-пакетов для видео-потока;
- Скорость передачи данных в каждом потоке;
- Блочное распределение потерь пакетов;
- Активные IP-адреса;
- Количество активных камер для каждого IP адреса.
Требования к фиксации событий:
Комплекс для анализа видео-потока должен позволять фиксировать следующие
события:
(с обязательной генерацией сообщений для внешних программных систем):
- Превышение заданного уровня потерь. Уровень порога является переменным и
задается в процентах.
- Превышение порогового значения неоднородности задержки (задается в
миллисекундах).
- Остановка потока в течение нескольких (задаётся пользователем) секунд.
- Определение источников с низкой скоростью трансляции пакетов
(потенциальный "синий экран"/"чёрный экран").
- Пороговые значения должны задаваться администратором системы и являться
едиными для всех потоков RTP.
4.
5.
Требования к подсистеме оперативной обработки данных:
5.1 Подсистема должна быть предназначена для обработки собираемой статистики
по анализируемым видеопотокам. Результаты обработки должны позволять без
применения каких-либо дополнительных средств проводить анализ текущей
ситуации по услугам.
5.2 Необходимые параметры от системы оперативной обработки данных:
- сводные данные по потерям единичных пакетов, предоставляемые в виде
таблицы, содержащей:
- IP-адрес источника видео-потоков;
- количество принятых пакетов за период;
- количество потерянных пакетов за период;
- процент к общему числу пакетов;
- количество камер для данного IP-адреса;
- суммарная длительность активности источника видео-потоков в течение
периода;
- длительность отсутствия активности источника видео-потоков;
- процент недоступности источника видео-потоков к длительности периода;
- количество пакетов с нарушенным порядком следования;
- пакетный джиттер (вариация задержки передачи пакетов);
- количество интервалов недоступности источника видео-потоков;
- счётчик серийных потерь в течение периода.
6.
Требования к функциональности по интеграции комплекса для анализа
видео-потока с внешними сетевыми элементами, внешними системами инвентори,
внешними системами мониторинга:
6.1
Возможность по интеграции с внешними системами инвентори (SQL,
HTTP/FTP/CSV/PLAIN TEXT).
6.2
Возможность интеграции с внешними системами мониторинга (SNMP, Zabbix).
6.3
Обеспечение стандартных методов (SNMP v2 Push) для интеграции с внешними
системами мониторинга состояния системы.
6.4
Наличие документированного открытого API для интеграции с внешними
системами.
6.5
Интеграция со всеми внешними системами должна обеспечиваться с помощью
открытых документированных по RFC протоколов – SNMPv2, SSH, FTP, http api, syslog.
6.6
Оперативная синхронизация данных по прошедшим событиям по всему пулу
видеопотоков должна осуществляться не реже 15 минут.
6.7
Возможность обратной синхронизации по добавлению новых пулов камер (IP
адресов) по протоколам SQL, http api, FTP (CSV).
7.
Требования по количественным и техническим характеристикам:
7.1
Минимальное количество анализируемых RTP потоков - не менее 70 000;
7.2
Минимальное количество подключаемых интерфейсов 10G - не менее 7
интерфейсов 10G;
7.3
Способ подключения интерфейсов с помощью пассивных разветвителей;
7.4
Аппаратная реализация съёмников трафика, возможность анализа трафика при
100% нагрузке всех 7 10G интерфейсов без потери данных;
7.5
Наличие неинтрузивного сбора данных из 10G интерфейсов обеспечивающих
объективную оценку качества RTP потока без создания нагрузки на активное
оборудование;
7.6
Реакция на изменение показателей качества источников видеоинформации:
доступность, потери пакетов, джиттер, скорость передачи, «синий экран» - не более 2
минут;
7.7
Журнал событий не менее чем за 1 год по 70000 камер не должен влиять на
производительность системы.
7.8
Глубина журналирования для потоков с 70000 камер должна составлять не менее
одного года.
Конфигурирование и администрирование
Комплекс для анализа видео-потока и подсистема оперативной обработки данных
должны настраиваться c помощью платформо независимого CLI-интерфейса (удалённый
доступ должен поддерживаться с помощью протокола шифрования SSHv2). Возможность
конфигурирования с помощью WEB интерфейса (опционально).
8.
9.
Требования к размещению и масштабированию съёмников RTP трафика
9.1
Измерительные модули, входящие в состав комплекса, должны обладать
автономностью, возможностью размещения на распределенных площадках,
объединённых в единую систему. Измерительные модули должны располагаться в
местах разграничения зон ответственности на стыках сетей ОАО МГТС и Заказчика и
сторонних операторов (опционально).
9.2
Время на развертывание и подключение измерительных модулей комплекса в
новой точке не должно превышать более 3 суток (при наличии доступа).Измерительные
модули должны быть платформо - независимыми от производителей
маршрутизирующего и коммутирующего оборудования.
9.3
Для измерительных модулей на 7x10G линков используемое стойко - место не
должно превышать 2U и 350Вт энергопотребления (при условии централизованного
размещения подсистемы оперативной разработки в ЦОД ОАО МГТС).
9.4
Подсистема оперативной обработки должна занимать не более 2U стойко места и
потреблять не более 400Вт Для обработки данных не менее чем с 70 000 потоков RTP.В
линейке оборудования Производителя должны присутствовать измерительные модули с
интерфейсами 100G c полностью идентичным функционалом предлагаемому решению.