HTPC.VRN.RU

Ubuntu 9.10, игры и 40"

2010-03-14T20:26:00.008+03:00

Сегодня решил попробовать сыграть в компьютерную игрушку на своем 40" ТВ. Он у меня подключен к компьютеру по HDMI и используется для просмотра фильмов. За полтора года - ни разу не пробовал играть. А зря!
Решил начать с Alien Arena. Так как у меня Ubuntu 9.10 - подключил game-репозиторий (http://www.playdeb.net/welcome/) и установил игру. Запускаться она сразу отказалась. Пришлось рыскать в интернете причину. На одном из форумов нашел решение (не помню на каком уже и надеюсь автор меня простит за отсутствие ссылки на него). Нужно было создать файлик в домашней папке с именем .alsoftrc и добавить следующее

[general]
drivers = oss

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

Этим повеселее оказалась игрушка Cube2: Sauerbraten. Просто потрясающая игра, а на 40" на расстоянии меньше метра - просто оказываешься эпицентре событий и несколько часов пролетают как 5 минут. Прежде всего хочется отметить то, что игроки - со всего мира. Уровень - в основном любительский, и даже мне, никогда особо не игравшем в игры, удавалось доползти до середины таблицы.

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

Так что - рекомендую Sauerbraten.

Многоклассовая модель обслуживания в гетерогенных Metro Ethernet сетях

2009-10-19T21:43:00.019+04:00

Текущая «best effort» инфраструктура в сетях масштаба города (далее - "сетях") обладает недостатками с точки зрения таких характеристик как задержка, джиттер, потери пакетов, значения которых должны быть минимальными для мультимедийных приложений (голос, видео, и данные) в моменты возникновении перегрузок в канале. Относительно недавно, получены результаты в разделении сервисов, для обеспечения поддержки не только мультимедийных приложений, но и важных данных. В этой статье мы определим основные типы трафика, обсудим их особенности и требования, а также постараемся получить соответствие типов трафика классам обслуживания.

Введение

В современных сетях происходит развертывание новых мультимедийных приложений: VoIP, видеоконференции, видео по запросу (Video on Demand), аудио по запросу (Music on Demand), телерадиовещание (ТРВ), появление множества интерактивных сетевых игр. Эти приложения производят трафик с характеристиками, сильно отличающимися от производимого обычными приложениями данных, а также предъявляют более строгие требования к задержке и потерям. Качество голоса, например, очень чувствительно к потере, задержке и колебанию задержки в очереди для буфера узла сети (свитча, маршрутизатора). Качество работы видеоприложений сильно ухудшается в моменты загрузки сети, и генерируемый этими приложениями трафик чувствителен к потерям. В дополнение к появляющимся приложениям, генерирующим потоковый трафик, сеть должна также поддерживать интерактивные приложения данных. Комфортная для пользователя работа этих приложений (telnet, веб-серфинг, интерактивные сетевые игры) требует небольших значений задержки. Однако, эти требования часто не выполняются из-за характера работы протокола TCP с потерянными пакетами

Типы трафика

Определим основные типы трафика, встречаемые в сетях масштаба города:

Интерактивное аудио и видео
Потоковое видео
Потоковое аудио
Интерактивный трафик данных
Игровой трафик
Административный
Остальной трафик

Рассмотрим по порядку каждый из выделенных типов трафика и определим характеристики каждого из них. Согласно Y.1540 [1] и Y.1541 [2] выбираем параметры производительности IP-сетей:

IPLR - количество потерянных IP-пакетов;
IPER - количество пакетов с ошибками;
IPTD — задержка (временной интервал между начальной передачей и окончательным приемом пакета);
IPDV — джиттер (изменение запаздывания, задержки).

Необходимо также, для каждого типа трафика поставить в соответствие класс обслуживания [1] (табл.1).

Табл. 1. ITU-T Y.1541 — соответствие классов обслуживания параметрам производительности IP-сетей.

Интерактивное аудио и видео

Данный тип сервиса в основном определяется телефонными звонками (VoIP), аудио- и видеоконференциями с низким разрешением. Согласно различным исследованиям [12], [13] и стандартам [11], [14] односторонняя задержка не должна превышать 150мс, джиттер 30-50мс, так как превышение этого порога сильно сказывается на качестве восприятия речи. При значениях задержки меньших 100мс пользователи услуги ее не замечают. Значения потерь пакетов не должны превышать порог 1 — 5% в зависимости от кодека. Класс обслуживания, наиболее оптимально соответствующий этим требованиям согласно [1] — 0.

Потоковое видео

Прежде всего это такие услуги как телевещание, видео по запросу (Video on Demand). Для них верны следующие общие требования [2]:

Хорошее качество видео
Высокая готовность
Средняя интерактивность - определяется для обратного потока (от пользователя).

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

В связи с большим размером единичного потока (от 3,5 Мбит для MPEG-2 и от 2 Мбит для H.264 ) и используемыми принципами кодирования предъявляются повышенные требования к потерям пакетов. Из рекомендации J.241 [2] для превосходного качества обслуживания (ESQ) значение IPLR должно быть минимальным. Также следует отметить , что параметр задержки может сильно отличаться в зависимости от сервиса потокового видео. В частности, для видео по запросу, «сетевого видеомагнитофона» и близких по архитектуре сервисов эти требования возрастают, так как требуется бОльшая интерактивность. Так как последние сервисы более требовательны к параметрам производительности IP-сетей, то пороговое значение имеет смысл определять и для этих сервисов. Согласно Дополнения 3 от 05.2008г. к рекомендации Y.1541 [3] значения IPTD, IPDV, IPLR, IPER соответствуют классам обслуживания 6 и 7 самой рекомендации. Исследования [15], [16] подтверждают значения, указанные в [7].

К классу 6 следует отнести услуги телевещания, а к классу 7 — услуги видео по запросу и аналогичных.

Потоковое аудио

Прежде всего, это такие услуги как радиовещание, аудио по запросу (Music on Demand). Для этого типа трафика значения параметров производительности IP-сети согласно [1], [17] вписываются в классы 0, 1. Для интерактивных сервисов (Music on Demand) класс обслуживания — 0, для услуг радиовещания класс обслуживания — 1.

Интерактивный трафик данных

К этому классу трафика следует отнести веб-серфинг, telnet, ssh, интерактивный обмен сообщениями (например, чат)[5]. Класс данного трафика — 3.

Игровой трафик

Значения параметров производительности IP-сети согласно исследованиям [6], [8], [9] соответствуют классу обслуживания 0, что противоречит рекомендации [7]. Значение задержки для хорошего и отличного качества сервиса не должны превышать 100 мс, значение джиттера должно быть меньше 50 мс, а уровень потерь пакетов должен оставаться ниже 1%.

Административный

Служит для обеспечения функционирования сети, мониторинга, управления сетевым оборудованием (OSPF, RIP, SNMP, telnet, http, ssh). Как правило, подобный трафик выделяется в отдельную виртуальную сеть (VLAN). Собственно, это самый важный трафик и посему класс обслуживания у него должен быть самый высокий. Согласно [1] самым строгим является класс 6.

Остальной трафик

Как правило, это трафик файлообмена, почтовых сервисов и прочих, менее важных служб. Класс обслуживания — 5.

Тип трафика - класс обслуживания

Получаем следующую таблицу (Табл. 2) соответствия классов обслуживания — типам трафика.

Табл. 2. Соответствие типов трафика классам обслуживания.

Как видно из таблицы - распределение типов трафика по классам обслуживания не равномерное. Важным вопросом для рассмотрения является возможность смешивания различных типов трафика. Выделение класса трафика, в большинстве используемом для построения сетей масштаба города, оборудовании — это отдельная очередь, так как используется таблица соответствия маркирования пакета и очереди. То бишь, каждый класс обслуживания [1] соответствует номеру очереди в сетевом узле.

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

В нашем случае происходит смешение (варианты):

игрового трафика, потокового аудио, интерактивного аудио и видео (классы 0)
административного трафика и потокового видео (класс 6).

Согласно исследованию «Service Differentiaition in the Internet to Support Multimedia Traffic » [11] рассмотрим вариант 1 — игровой трафик, потоковое аудио, интерактивное аудио и видео:

для каналов меньших, чем 1,5Мбит/c смешение этих типов трафика недопустимо;
для каналов 10Мбит возможно только при существенном сокращении общей пропускной способности и совсем низком потоке данных;
для каналов 100Мбит возможно при использовании не более чем 20% пропускной способности канала

Таким образом, необходимо определить игровой, потоковое аудио, интерактивное аудио и видео в различные классы. Классы для этих типов трафика следует выбрать исходя из важности каждого из трафиков и его востребованности в конкретной сети. Определим для игрового трафика класс 4, потоковое аудио определим в класс 1, а интерактивное аудио и видео в класс 0.

Теперь рассмотрим вариант 2. В конечном итоге, вывод, для ситуации смешивания административного и потокового видео повторяет вариант 1. А также, согласно безопасности и обеспечения стабильности функционирования сети, крайне непригодным является смешивание административного трафика с любым другим. Так как класс обслуживания 6 является самым строгим, то следует оставить за ним административный трафик, а для трафика потокового видео использовать только 7 класс.

Таким образом, получаем следующую таблицу (Табл. 3) соответствия типов трафика классам обслуживания.

Табл. 3. Соответствие типов трафика классам обслуживания после учета смешения.

Заключение

Из-за попадания разных типов трафика в один класс обслуживания и невозможности их смешения, классы обслуживания с указанными в стандарте Y.1541 параметрами производительности IP-сетей не соответствуют типам трафика. Однако, проведенная оптимизация и разделение типов трафика по классам (Табл. 3) позволяет повысить эффективность и производительность мультисервисной сети, а также повысить безопасность работы сети

Библиография
1.ITU-T Y.1540. Internet protocol data communication service – IP packet transfer and availability performance parameters, 2007.
2.ITU-T Y.1541. Network Performance objectives for IP-based services, Amendment 3, 2008.
3.ITU-T J.241. Quality of service ranking and measurement methods for digital video services delivered over broadband IP networks, 2005.
4.Focus Group On IPTV. Quality of Experience Requirements for IPTV, 5th FG IPTV meeting, 23-31 July 2007.
5.IPTV Focus Group Proceedings. Traffic management mechanisms for the support of IPTV services, 249с.
6.Grenville Armitage, Lawrence Stewart. Some Thoughts on Emulating Jitter for User Experience Trials, 2005.
7.IPTV Focus Group Meeting. Classification of IPTV services based on network QoS requirements, 2006.
8.Johannes Farber. Traffic Modelling for Fast Action Network Games, MTAP, 2004.
9.Sebastian Zander, Grenville Armitage. Empirically Measuring the QoS Sensitivity of Interactive Online Game Players, ATNAC, 2004.
10.Fouad Tobagi. Service Diffirentiation in the Internet to Support Multimedia Traffic, 2002.
11.ITU-T G.114. One-way transmission time, 2003.
12.Peter Caky, Martin Klimo, Onrey Skvarek. End to end voip quality measurement, Acta Electrotechnica et Informatika N1 Vol.6, 2006.
13.Tim Szigeti, Christina Hattingh. Quality of Service Design Overview, Cisco Press, 2004.
14.ETSI TS 101329. Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3, 2002.
15.Jason Greengrass, John Evans, Ali C. Begen. Streaming Video Coding and SLA Requerments, Cisco, 2009.
16.Marc Todd. Quality of Video over IP Measuring the Quality of Streaming MPEG-2 Transport Streams over IP, IneoQuest Technologies, 2001.
17.Rishikesh S. Gokhale. Packet Loss Concealment in Voice Over Internet, 2003.

NetUP IPTVProbe для мониторинга IPTV отметил новый релиз

2009-05-27T13:20:00.021+04:00

Вышел новый релиз свободно распространяемой (по лицензии GPLv2, GPLv3) NetUP IPTVProbe.
По сути - это система мониторинга и контроля качества оказываемых услуг интерактивного телевидения. Новое в версии:

Добавлена обработка IGMP-запросов и отображение временных параметров работы с IGMP
Очистка кода, исправление ошибок
Новая версия протокола обмена данными с зондами

Однако, вызывает недоумение вот такая цитата из описания:

В первом случае использовался коммутатор Cisco Catalyst 2950T с поддержкой IGMP Snooping, а во втором случае использовался обычный коммутатор без поддержки IGMP snooping. Как видно во втором случае присутствует существенное количество потерянных IP-пакетов.

Непонятно, причем тут IGMP Snooping и потери пакетов и как связано его присутствие или отсутствие с потерями пакетов? В общем - откровенная чепуха.

Новость на linux.org.ru , NetUP .

Мультисервисная сеть: качество обслуживания и мультикаст. Часть 1

2009-05-20T10:38:00.028+04:00

Часть 1, Часть 2, Часть 3

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

Введение

Современные мультисервисные сети операторов связи интенсивно охватывают все бOльшие территории, увеличивается база их абонентов, внедряются новые сервисы. Небезызвестная технология Triple Play одними провайдерами уже освоена, а другим предстоит еще познакомится с ней и с трудностями ее внедрения.

За внедрением Triple Play следует еще более возросшая нагрузка на пропускную способность каналов. Сами же каналы часто подвержены перегрузкам в часы пик, из-за чего в итоге страдает конечный пользователь.

Прежде всего, страдает трафик, чувствительный к задержкам, искажениям, времени передачи. К чувствительному трафику следует отнести трафик VoIP и IPTV. Не стоит забывать и о служебном (административном) трафике, без которого работа сети не представляется возможной. К нему следует отнести сервисы маршрутизации (RIP, OSPF), доменных имен (DNS), сервис DHCP, SNMP и прочие. Некоторые компании в ранг важного относят трафик приложений, от стабильной и быстрой работы которых, зависит вся деятельность и прибыль компании. Например, для провайдеров — это интернет трафик. Вследствие вызванных перегрузок естественно и уменьшается время доступа к сервисам.

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

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

Но не все так грустно, как может показаться на первый взгляд. Еще «основатели» Интернет предполагали о необходимости управления качеством обслуживания в сетях IP. Внедрение (Добавление) в заголовок IP-пакета байта типа обслуживания (ToS - Type of Service), положило начало созданию целого набора технологий качества обслуживания (QoS - Quality of Service).

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

QoS

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

Маркировка пакетов и их классификация

Маркировка пакетов служит для идентификации определенного типа трафика и может осуществляться следующим образом:

установкой в заголовке IP-пакета значения поля IP-приоритета (8 классов сервиса);
установкой в заголовке IP-пакета значения поля кода дифференцированной услуги (DSCP) (64 класса сервиса);
установкой значения в Ethernet фрейме с использованием 802.1p приоритета в заголовке 802.1Q (8 классов сервиса);
установкой значения MPLS EXP в MPLS метке.

Классификация служит для разделения IP-пакетов относящихся к различным типам трафика в зависимости от значений полей заголовка IP-пакета.

Обработка пакетов

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

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

Weighted Fair Queuing (WFQ) взвешенный алгоритм равномерного обслуживания.
Weighted Round Robin (WRR) взвешенный алгоритм кругового обслуживания. Используется механизм с учетом назначения каждому потоку трафика своего веса и обработка потока пропорционально этому весу.
Weighted Random Early Detection (WRED) взвешенный алгоритм произвольного раннего обнаружения. Используется для предотвращения перегрузки сети.

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

Возможности QoS

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

Постановка задачи

Перейдем собственно к описанию реальной задачи.

Необходимо подготовить существующую «домовую» сеть к внедрению сервиса теле- и радиовещания в сети.
Учесть влияние этого нового трафика на основные сетевые сервисы компании - предоставление выхода в сеть Интернет и услуги VoIP, учесть влияние быстро растущей базы абонентов и p2p трафика внутри локальной (пользовательской) сети.
Необходимо также решить как проводить модернизацию и масштабирование сети. Решение должно быть экономически оправданным.

Для начала, определим требования к сети.

Требования, предъявляемые для сервисов к сети

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

VoIP, видеоконференции

Для работы сервисов VoIP и видеоконференций требования к сети и качеству обслуживания сильно возрастают, так как необходимо обеспечить в сети для них:

низкие задержки для VoIP и интерактивного видео (видеоконференции) максимум 150 мс (милисекунд) в одну сторону (следуя International Telecommunication Union);
максимальное значение джиттера менее 10 мс для VoIP и 30 мс для интерактивного видео;
максимальные потери пакетов не более 0,25%;

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

VoD, AoD, ТРВ

Следует разделить эти сервисы на две категории:

предоставление услуги VoD (Video on Demand), AoD (Audio on Demand) - видео/аудио по заказу (запросу);
теле- и/или радиовещание - ТРВ (потоковое видео или аудио).

Для этих сервисов необходима различная пропускная способность. Для технологии VoD/AoD пропускная способность прямо пропорциональна количеству заказанных различных видеопотоков. Например, уже при заказе 100 пользователями различных фильмов при потоке 4-5 Мбит/с каждый, сформируется общий поток на магистрали 400-500 Мбит/с. Для снижения нагрузки на магистраль используется технология кеширующих серверов, располагающихся как можно ближе к абоненту.

Для сервиса ТРВ (потокового видео) используется технология multicast, которая существенно снижает нагрузку на магистраль. Однако, появляется требование поддержки оборудованием протокола групповой адресации IGMP и протоколов мультикаст маршрутизации (PIM, DVMRP).

Важные требования к сети для VoD/AoD и ТРВ:

задержка не более 4-5 секунд. Столь большая задержка возможна благодаря использованию буферизации в видеоприложениях;
по той же причине, не существует значительных требований к колебанию задержки;
потери должны составлять максимум 1-2%.

Решение задачи

Исходя из вышеназванных критериев перейдем к практике и решим поставленную задачу. Разобьем решение на несколько этапов:

Представление структуры и логической схемы сети;
Внедрение технологии мультикастинга;
Реализация технологии QoS;
Тестирования QoS;

Структура сети

Сеть на данный момент представляет собой многоуровневую иерархическую структуру.

На рисунке 1 представлена схема сети и используемое оборудование. В нашем случае, сеть построена на оборудовании компании D-Link.

Как видно из схемы, к роутеру west DGS-3612G подключен видеосервер. Роутеры techcenter, west, nord, nord-mk9 связаны оптическими линиями связи на скорости 1 Гбит/c. Свитчи nord-sw04 и nord-sw03 подключены на скорости 100 Мбит/c. Клиентское оборудование подключается на скорости 10 Мбит/c.

Физическая структура разбита на несколько уровней:

Ядро системы — techcenter
Район города — nord,west
Квартал — nord-mk9
Дом — nord-sw04
Подъезд — nord-sw03

Каждый дом подключен оптическим каналом связи. Внутри дома подъезды и клиенты подключены по технологии 100BASE-T Ethernet.

Достоинства сетевого оборудования этой компании применительно к нашим задачам:

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

Недостатки:

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

В таблице 1 приведена информация о некоторых возможностях используемого оборудования. Подробное описание оборудования можно найти на официальном сайте компании D-Link.

Имя	Модель	Интерфейсы	Мультикаст	QoS	Уровень	Производительность
main	DGS-3612G	8 портов SFP 4 комбо-порта SFP/1000BASE-T	IGMP v1,v2,v3 PIM	Class of Service на основе: - МАС-адреса; - TOS; - DSCP; - IP-адреса; - Номера порта TCP/UDP; - VLAN ID; - Содержимого пакетов, определяемых пользователем. WRED	3	24 Гбит/с
nord	DXS-3326GSR	20 SFP портов 4 комбо-порта SFP/10/100/1000BASE-T Gigabit	IGMP v1,v2,v3 PIM	Class of Service на основе: - МАС-адреса; - TOS; - DSCP; - IP-адреса; - Номера порта TCP/UDP; - VLAN ID; - Содержимого пакетов, определяемых пользователем. WRED	3	128 Гбит/с
nord-mk1	DES-3828	24 порта 10/100BASE-TX 2 комбо-порта 10/100/1000BASE-T/SFP	IGMP v1,v2,v3 PIM	Class of Service на основе: - МАС-адреса; - TOS; - DSCP; - IP-адреса; - Номера порта TCP/UDP; - VLAN ID; - Содержимого пакетов, определяемых пользователем. WRED;	3	12.8 Гбит/с
nord-mk-sw04,sw03	DES-2108	8 портов 10/100BASE-TX	IGMP Snooping v2	QoS на основе портов	2	1.6Гбит/с
-	DES-3526	24 порта 10/100BASE-TX 2 комбо-порта 1000BASE-T/MiniGBIC (SFP)	IGMP Snooping v3	Class of Service на основе: - МАС-адреса; - TOS; - DSCP; - IP-адреса; - Номера порта TCP/UDP; - Содержимого пакетов; определяемых пользователем - портов.	2	8.8 Гбит/с

Таблица 1. Используемое оборудование

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

Далее >>

Как организовать сервис телерадиовещания в интранет-сети

2009-05-26T08:00:00.001+04:00

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

В сетях Интранет уже давно внедрен и успешно применяется сервис VoIP, позволивший организовать голосовую связь без значительных материальных затрат. В свою очередь, увеличение пропускной способности канала влечет за собой появление новых сервисов, способных существенно изменить представление о современной IP-сети. Сейчас есть возможность получать сервисы файлообмена (подразумевается внутри сети), Интернет, телефонию и телевидение по одному кабелю. В итоге, подобные решения позволяют сэкономить на кабельной инфраструктуре и ее обслуживании, позволяют повысить качество предлагаемых услуг.
Что может уже сейчас предоставить современная IP-сеть?

доступ в сеть Интернет
обмен файлами (p2p)
услуга IP-телефонии
телеконференции
теле и радиовещание
видеонаблюдение

Сегодня рассмотрим сервис телерадиовещания (ТРВ) и затронем тему видеонаблюдения.

Эволюция традиционных сетей привела к появлению так называемых "мультисервисных сетей". В нынешних корпоративных сетях разного масшатаба присутствует трафик, который условно можно разделить на четыре категории:

потоковое видео, аудио;
видеоконференции и голосовая связь;
обычные данные;
служебные данные необходимых сервисов (DHCP, DNS и т.д.).

Каждая категория трафика весьма специфична, и имеет свою степень устойчивости относительно уровня потерь пакетов, задержки, джиттера. Значения этих характеристик необходимо нормировать с помощью технологии обеспечения качества обслуживания (Quality of Service, QoS), поэтому необходимо обеспечивать не только широкую полосу пропускания, но и приоритезацию трафика (для стабильной работы в моменты всплесков в сети).
Существует три способа доставки потокового видео:

Unicast (передача данных от одного источника к одному потребителю);
Broadcast (передача данных всей сети, пакеты будут передаваться каждому клиенту);
Multicast (передача данных от одного источника группе получателей, клиент может принять решение об участии в получении данных или об отказе);

Прежде чем внедрять новый сервис, тем более такой ресурсоемкий как ТРВ, необходимо:

Выявить и изолировать или ограничить уровень мультикаст трафика в сегменты с низкой пропускной способностью, если таковые имеются.
Постараться максимально оптимизировать маршруты движения мультикаст трафика.
Настроить оборудование с поддержкой IGMP, IGMP-snooping, PIM (для маршрутизации мультикаст трафика). Хорошо если все оборудование в сети поддерживает IGMP (IGMP-snooping). Для большой сети желательно иметь централизованную систему мониторинга сетевого оборудования, для быстрого обнаружения возникающих проблем.

Проектирование мультисервисной сети обычно начинается с задания сервисов, для которых она создается. В нашем же случае, мы имеем дело с «наследуемой системой», поэтому необходимо определить ограничения, связанные с уже имеющейся в наличии конфигурацией сети и установленным оборудованием. В нашей сети сервис видео не является приоритетным, а является дополнением к традиционным сервисам. На этапе настройки сервиса ТРВ необходимо контролировать параметры загрузки сети, чтобы в последствии не допустить заметного ухудшения работы традиционных сервисов. При уже работающем сервисе, необходимо измерить характеристики производительности. Методология измерений и сами характеристики производительности сетей и сетевых устройств довольно подробно описаны в документах IETF [1,2,3]. Для сетевого уровня, например, это серия документов группы IETF "IP-Performance Metrics Working Group" (IPPM). Определены методики измерений и для канального уровня (RFC2544), а также для более высоких уровней группы SG12 ITU-T, отвечающей за рекомендации в области субъективной и объективной оценки аудио и видео. Практика показывает, что результаты измерений второго и третьего уровня по методикам IETF часто не объясняют низкого качества конечного результата, а могут лишь использоваться для поиска неисправностей и проверки части гипотез о причинах низкого качества сервиса. Соответствующие действительности результаты, можно получить лишь экспериментально.

Схема сети

Сервис ТРВ создавался на базе сети, упрощенная схема которой представлена на рис. 1.

Как видно из рисунка, конечные узлы подключены к коммутаторам лабораторий по технологии 100Base-T, которые в свою очередь соединены с корневым коммутатором 100/1000Base-T. Серверы, в том числе и сервер вещания (Srv7), подключены к корневому коммутатору по технологии 1000Base-T. Таким образом, корневой коммутатор образует скоростную «сжатую» магистраль между лабораториями и серверами. Протокол IGMP поддерживается корневым коммутатором и одним из коммутаторов лабораторий. Используется три вида коммутаторов уровня доступа (лабораторий): управляемые 100Baset-T с поддержкой IGMP, неуправляемые 100Baset-T и неуправляемые 100Baset-T с uplink-портом 1000Baset-T. Эти три вида коммутаторов представлены, соответственно, коммутаторами L1, L2 и LN.

Серверная часть

Сервер вещания генерирует около 10 мультикаст потоков 3-4 Мбит/с каждый. Вещание происходит по протоколу UDP. Потоки представляют собой MPEG-2 телеканалы, принимаемые со спутника.
Оговорюсь сразу, что наш сервер видеовещания не был и не будет предназначен для промышленного (понимать коммерческого) использования, для которого существует множество аппаратных, масштабируемых и надежных решений. В таких решениях используются профессиональные аппаратные ресиверы, кодеры, декодеры, мультиплексоры, платформы для вещания. Наш же сервер реализован с использованием программного решения.
Мы остановились на небезызвестном Open Source продукте - Video Lan Client (VLC) [4]. В качестве операционной системы выбрана Debian/GNU Linux. VLC и Linux - это отличная платформа для тестирования и настройки всей сети перед внедрением коммерческого вещания. Данную платформу можно использовать как недорогое решение видеовещания для локальных сетей. Цена решения складывается из стоимости DVB-S тюнеров и сервера видеовещания, в который тюнеры будут установлены.
В качестве DVB-S тюнера было принято решение установить 3 карты SkyStar2 [5]. Причина, по которой была выбрана именно эта карта - большое количество различных программных решений под нее, как под Linux, так и под Windows. Так выглядит запуск VLC с необходимыми нам параметрами.

vlc --ts-es-id-pid --programs=16,17,18,65,75 dvb:
--dvb-adapter=0 --dvb-frequency=12207000 --dvb-s
rate=27500000 --dvb-voltage=18 –sout-standard-access=udp
--udp-caching=600 --sout-standard-mux=ts --sout '
#duplicate{dst=std{dst=230.1.1.1},select="program=8201",
dst=std{dst=230.1.1.2},select="program=8204",
dst=std{dst=230.1.1.3},select="program=8208",
dst=std{dst=230.1.1.4},select="program=8211",
dst=std{dst=230.1.1.6},select="program=8202",
dst=std{dst=230.1.1.7},select="program=8203",
scodes=dvbs}' -d;

В данной строке мы указываем номера каналов (programs), номер тюнера (dvb-adapter), параметры транспондера (dvb-frequency, dvb-srate) и указываем адрес назначения (dst). В качестве адреса назначения используются мультикаст адреса, выбираемые из диапазона 224.0.0.0 – 239.255.255.255. Исключение при выборе составляют следующие адреса:

224.0.0.1 – все узлы в данной сети; 224.0.0.2 – все маршрутизаторы в данной сети;
224.0.0.5 – все OSPF-маршрутизаторы; 224.0.0.6 – выделенные OSPF-маршрутизаторы;
224.0.0.9 – маршрутизаторы RIP-2; 224.0.0.10 – IGRP-маршрутизаторы;
224.0.1.1 – получатели информации по протоколу точного времени NTP.

Так выглядит скрипт в /etc/init.d/ для автоматической загрузки модулей карты с параметром dvb ядра dvb_shutdown_timeout=0, который не позволяет "уснуть" карте если она длительное время не задействована.

#! /bin/sh
set -e

case "$1" in
start)

/sbin/modprobe dvb-core dvb_shutdown_timeout=0
/sbin/modprobe skystar2
/sbin/modprobe stv0299

;;

stop)

/sbin/modprobe -r skystar2
/sbin/modprobe -r stv0299
/sbin/modprobe -r dvb-core

;;
*)
echo "Usage: /etc/init.d/dvb {start|stop}"
exit 1
esac
exit 0

В ходе эксплуатации выявилась аппаратная проблема у карты SkyStar2 (либо же "кривая" реализация драйверов). Проблема такова, что при пропадании сигнала, причиной чего могут быть различные атмосферные явления, уровень сигнала не всегда восстанавливается, и как следствие, поток с DVB-S карты SkyStar2 отсутствует. Дело в том, что данная карта не рассчитывалась для интенсивной бесперебойной работы, а является лишь бюджетным любительским вариантом спутникового тюнера.
Алгоритм решения проблемы следующий:

Завершение приложений использующих DVB-S карту SkyStar2.
Перезапуск драйвера DVB-S карты SkyStar2 (в этот момент карта инициализируется).
Повторный запуск приложений (конкретно VLC).

Был написан простой скрипт watchdog, который постоянно следит за потоком с сетевого интерфейса сервера и перезагружает сервис. Ниже представлена одна из первых версий скрипта, так как на данный момент, в связи с еще несколькими сервисами на основе VLC на этом сервере, скрипт существенно изменен.
Значение исходящего потока (переменная thread) получено экспериментально на основе мониторинга сетевого интерфейса. Как только значение потока становится ниже заданного порога, выполняются действия описанные выше.

#! /bin/sh

while [ 0 ] ; do

thread=$(tcpstat -o '%B' -F -s 7 | awk -F. '{print($1)}';

sig0=`dvbsnoop -n 1 -timeout 10 -s signal -adapter 0
| tail -n 1 | awk -F\ '{printf $7}'`;

sig1=`dvbsnoop -n 1 -timeout 10 -s signal -adapter 1
| tail -n 1 | awk -F\ '{printf $7}'`;

sig2=`dvbsnoop -n 1 -timeout 10 -s signal -adapter 2
| tail -n 1 | awk -F\ '{printf $7}'`;

echo $sig0 $sig1 $sig2 $thread >> /usr/dvb/log

if [ $thread -lt 3300000 ] ; then

echo $thread

echo "Завершаем все процессы VLC"

killall -9 vlc;

echo "Выгружаем DVB-S модули"

/etc/init.d/dvb stop

echo "Запускаем DVB-S модули"

/sbin/modprobe dvb-core dvb_shutdown_timeout=0

/sbin/modprobe skystar2

/sbin/modprobe stv0299

echo "Запускаем VLC с новыми DVB-S модулями"

vlc --ts-es-id-pid --programs=16,17,18,65,75 dvb:
--dvb-adapter=0 --dvb-frequency=12207000 –dvb-s
rate=27500000 --dvb-voltage=18 --sout-standard-access=udp
--udp-caching=600 --sout-standard-mux=ts
–sout '#duplicate{dst=std{dst=230.1.3.1},
select="program=16",dst=std{dst=230.1.3.2},
select="program=17",dst=std{dst=230.1.3.3},
select="program=18",dst=std{dst=230.1.3.4},
select="program=65",dst=std{dst=230.1.3.5},
select="program=75",sap,name="Radio_Music_Box",
scodec=dvbs}' -d

pidof vlc > vlcpid0

vlc --ts-es-id-pid –programs=8201,8204,8208,8211,8202,8203
dvb: --dvb-adapter=1 --dvb-frequency=12597000
--dvb-srate=27500000 --dvb-voltage=13
--sout-standard-access=udp --udp-caching=600
--sout-standard-mux=ts –sout '#duplicate{
dst=std{dst=230.1.1.1},select="program=8201",
dst=std{dst=230.1.1.2},select="program=8204",
dst=std{dst=230.1.1.3},select="program=8208",
dst=std{dst=230.1.1.4},select="program=8211",
dst=std{dst=230.1.1.6},select="program=8202",
dst=std{dst=230.1.1.7},select="program=8203",
scodes=dvbs}' -d;

pidof vlc > vlcpid1;

vlc --ts-es-id-pid --programs=525 dvb: --dvb-adapter=2
--dvb-frequency=12692000 –dvb-srate=27500000 –dvb-voltage=13
--sout-standard-access=udp --udp-caching=600
--sout-standard-mux=ts --sout '#duplicate{dst=std{
dst={230.1.2.1},select="program=525"}' -d;

pidof vlc > vlcpid2;

sleep 14

echo `date +%d.%m.%Y"-"%k:%M:%S`

SignalLevel[0,1,2,eth1]: $sig0 $sig1 $sig2 $thread >> /var/log/dvb/restartlog0

echo $thread – "Значение потока в норме"

fi

done

Как видно из кода скрипта информация о перезапусках сервиса пишется в файл /var/log/dvb/restartlog0, где можно точно посмотреть когда происходил перезапуск сервиса и составить диаграмму стабильности (нестабильности) работы сервиса. По данной диаграмме можно легко выяснить причину падения уровня сигнала. Причиной может послужить например загораживание вашей антенны каким-либо объектом или же неблагоприятные для приема атмосферные условия). Для повышения стабильности сервиса нужно повысить уровень принимаемого сигнала, чтобы даже при значительных изменениях в атмосфере уровень сигнала оставался в норме. Решение сводится к выбору большей по диаметру спутниковой антенны, качественного конвертера и кабеля от конвертера к картам SkyStar2. Другое решение - использовать другой, возможно, более дорогой, спутниковый тюнер. Характеристики самого сервера следующие: P-IV 1.6ГГц, RAM DDR 1Гб, HDD - 40Гб. Так как в нашем случае VLC не перекодирует принимаемый поток, то соответственно загрузка процессора не должна быть высокой. Значение не превышает 30%, а в среднем составляет 15 - 20 %. На этом реализация серверной части заканчивается.

Клиентская часть

Смотреть телеканалы можно как с помощью компьютера, так и на обычном телевизоре через STB (Set Top Box).
Рассмотрим первый вариант - просмотр видео на компьютере. Здесь можно выбрать один из трех способов.

1 способ. Для просмотра телеканалов можно воспользоваться все тем же самым VLС плеером (см. рис. 2).

Составляем плейлист из мультикаст адресов потоков с названиями каналов и выбирая элементы плейлиста смотрим. Тут никаких хитростей. Не забываем выбрать Deinterlace, чтобы убрать эффект гребенки.
Так выглядит плейлист VLC в текстовом виде.

#EXTINF:0,EuroNews
udp://@230.1.1.4
#EXTINF:0,BBC
udp://@230.1.1.2
#EXTINF:0,1Kanal
udp://@230.1.1.3
.........

2 способ. Также для просмотра можно использовать и Windows Media Player (WMP). Но как всегда с продуктами компании Microsoft возникают сложности. Для начала нужно установить Elecard [6] кодек, он коммерческий и в качестве триал версии его можно использовать 21 день. Далее установить программу UdpFilters [7], которая собственно и заставляет WMP смотреть наши каналы. Ссылка на канал по адресу udp://230.1.1.1:1234 выглядит в WMP таким образом "elecard://230.1.1.1:1234/udp". Составляем плейлист и смотрим (стрелки тегов изменены нарошно).

>?wpl version="1.0"?<
>smil<
>head<
>meta name="Generator" content=
"Microsoft Windows Media Player --10.0.0.4036"/<
>title<>/title<
>/head<
>body<
>seq<
>media src="elecard://230.1.1.1:1234/udp >>
Sport Planeta"/<
>media src="elecard://230.1.1.2:1234/udp >> BBC"/<
>media src="elecard://230.1.1.3:1234/udp >> 1 Kanal"/<
>media src="elecard://230.1.1.4:1234/udp >> EuroNews"/<
... ... ...
>/seq<
>/body<
>/smil<

3 способ. Можно смотреть и при помощи браузера. Для этого, устанавливая VLC, необходимо установить ActiveX и Mozilla плагин. Поднимаем веб-сервер, а если он имеется, то размещаем на нем php скрипт, находящийся по адресу [8]. Скрипт был немного изменен: добавлены ссылки на каналы (справа от видеоэкрана на рис. 3), установлен по-умолчанию режим деинтерлейсинга blend, удалена излишняя для просмотра вещаемых каналов функциональность. Скрипт автоматически определяет браузер и поэтому в Internet Explorer будет использоваться ActiveX, а в Mozilla Firefox - Mozilla плагин.
Оба плагина поддерживают регулировку громкости и полноэкранный режим (веб-интерфейс представлен ниже). Данное решение является не только межпрограммным, но и межплатформенным, так как установить Mozilla и VLC с плагином можно на большинстве современных операционных систем (см. рис. 3).

К сожалению, при просмотре через WMP + Elecard обнаружилось, что некоторые каналы начинают откровенно "тормозить" при частом переключении с канала на канал, по той же причине WMP часто зависает. Разницы в качестве картинки между использованием коммерческого кодека Elecard и кодека VLC не заметно, что весьма удивительно (возможно что-то не так в настройках). На некоторых каналах VLC выигрывает в качестве. По функциональности, если нет задачи записывать видео или «играться» с деинтерлейсингом (хотя никто не мешает добавить эту возможность в веб-интерфейс), то, без сомнений, веб-интерфейс гораздо удобнее. Подавляющее большинство пользователей в нашей сети использует именно веб-интерфейс.

А теперь можно перейти и ко второму варианту просмотра телеканалов.
Вариант второй заключается в просмотре телеканалов на телевизионном приемнике (телевизоре :-) ) с использованием STB-приставки. STB представляет собой небольшое устройство с сетевым интерфейсом и обычно с несколькими видеовыходами.
В качестве образца была взята STB-приставка AmiNet 110 (см. рис. 4) [9].

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

Развитие сервиса

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

каналы традиционного аналогового вещания;
веб-камеры;
создание своего видеоканала (например вещание видеозаписей или частной фильмотеки);
реализация сервиса VoD (Video on Demand).

В нашей сети к нескольким компьютерам подключены вебкамеры Logitech QuickCam. На данных компьютерах установлена программа VLC в качестве службы. Принятый с камер поток принимается, декодируется и раздается по мультикаст адресам в сеть. Таким образом, организован простой сервис видеонаблюдения. Организован свой канал — транслируются видеозаписи интересных и важных наших событий.

Заключение

Сервис ТРВ добавил функциональность в существующую инфраструктуру нашей сети, а также помог определить процент пользователей интересующихся данным видом сервиса, что может быть важно перед внедрением коммерческого вещания.
При всем при этом, на данный момент, он существенно не повлиял на ухудшение работы других сервисов сети.
Не стоит забывать о том, что требуется проводить контроль задержки, уровней ошибки и потери пакетов, джиттера, в условиях мультикаст трафика разной интенсивности и при выполнении на конечных узлах реально используемых сетевых приложений в рамках обычных (нескольких типовых) сценариев работы пользователей.
Отмечу, что за рамками данной статьи осталась информация о применении технологии имитационного моделирования для проектирования сетей и выявления потенциальных узких мест в них, настройке на оборудовании протоколов IGMP, PIM, реализации сервиса VoD. Внедрив сервис ТРВ, вы получите массу удовольствия!

Литература

IETF Network Working Group, IP-Performance Metrics (IPPM) for spatial and multicast - 2006. - (http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-02.txt). (на текущий момент доступна уже 11 версия)
IETF Network Working Group, Benchmarking Methodology for Network Interconnect Devices-1999.- (http://www.ietf.org/rfc/rfc2544.txt).
IETF Network Working Group, Framework for IP-Performance Metrics - 1998.- (http://www.ietf.org/rfc/rfc2330.txt).
http://www.videolan.org/vlc/
http://www.technisat.de
http://www.elecard.com/products/products-pc/consumer/mpeg2-decoder-plugin/
http://borpas.info/download/add/UdpFilters.exe
http://people.videolan.org/~dionoea/vlc-plugin-demo/plugin.php
http://www.aminocom.com/products/ipstb/aminet110.html

Опубликовано в журнале "Системный администратор", сентябрь 2007

Мультисервисная сеть: качество обслуживания и мультикаст. Часть 3

2009-05-25T17:26:00.009+04:00

Часть 1, Часть 2, Часть 3

Реализация QoS

Для обеспечения стабильного функционирования этого нового сервиса, необходимо назначить приоритеты для всех важных сервисов - VoIP, предоставление услуг Internet, административных сервисов, мультикаст трафика. Необходимо также, выбрать метод обработки классифицированных пакетов.

Приоритеты и механизм ACL

Маркировку пакетов необходимо производить максимально близко к абоненту, то есть на оборудовании, к которому он непосредственно подключен. Для маркировки пакетов используется механизм ACL (Access Control List).

Стандартом IEEE 802.1d определены 8 уровней приоритетов:

Level 7 - для трафика, связанного с управлением сетью, например, для сообщений с настройками маршрутизатора.
Level 6 - для голосового трафика, особенно чувствительного к неустойчивой синхронизации (т.е. к изменчивости задержек).
Level 5 - для видеоданных, требующих широкой полосы пропускания и чувствительных к неустойчивой синхронизации.
Level 4 - для трафика с контролируемой нагрузкой на сеть, но чувствительного к задержкам – например, для транзакций SNA (системной сетевой архитектуры IBM).
Level 3 - для трафика, требующего передачи при первой возможности или с преимуществом относительно других видов трафика – например, для важного рабочего трафика, допускающего некоторую задержку.
Level 2 - для выделения резерва полосы пропускания.
Level 1 - для некритичного “фонового” трафика, например, для неконтролируемой передачи данных, которая допускается, но не должна никоим образом сказываться на других задачах и пользователях. Level 0 - для трафика, передаваемого только при наличии возможностей.

В нашей конфигурации управление сетевым оборудованием вынесено в отдельный vlan (9-manage), поэтому необходимо определить для всего 9-manage vlan - 7 уровень приоритета (IEEE 802.1d).

В nord-mk1 строки конфигурации выглядят следующим образом:

create access_profile ip vlan profile_id 3 //Создаем правило

config access_profile profile_id 3 add access_id 1
ip vlan 9-manage port 1 permit priority 7 replace_priority
//для 9-manage vlan задаем 7 приоритет на 1 порту

...
config access_profile profile_id 3 add access_id 1
ip vlan 9-manage port 28 permit priority 7 replace_priority

Создаем для VoIP следующую конфигурацию:

create access_profile ip source_ip_mask 255.255.255.255
profile_id 4

config access_profile profile_id 4 add access_id 29
ip source_ip 192.168.0.4 port 1 permit priority 6
replace_priority

...

config access_profile profile_id 4 add access_id 29
ip source_ip 192.168.0.4 port 28 permit priority 6
replace_priority

Для всего мультикаст трафика задаем 6 приоритет:

create access_profile ip destination_ip_mask 240.0.0.0
profile_id 6

config access_profile profile_id 6 add access_id 1
ip destination_ip 224.0.0.0 port 1 permit priority 5
replace_priority

...

config access_profile profile_id 6 add access_id 1
ip destination_ip 224.0.0.0 port 28 permit priority 5
replace_priority

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

С остальными сервисами поступаем аналогично.

Для того, чтобы nord-mk1-sw04 (DES-2108) "понимал" заданные nord-mk1 приоритеты, необходимо, чтобы uplink его был тегированный.

Текущая конфигурация не обеспечивает полноценную реализацию QoS для каждого абонента, то есть исходящий трафик от абонента маркируется только после приема его nord-mk1. Вследствие этого, может возникнуть перегрузка на nord-mk1-sw04 (рисунок 1), когда абоненты создадут исходящий поток, превышающий пропускную способность uplink-канала (100 Мбит/c) на nord-mk1 (nord-mk1).

При использовании коммутаторов серии DES-3526 (26 портов) взамен DES-2108 (8 портов) этот недостаток полностью устраняется тем, что в DES-3526 существует механизм ACL, что позволяет перенести маркирование трафика максимально близко к абонентам. Конфигурация ACL DES-3828 полностью совместима с DES-3526. В итоге, получаем схему, в которой нужный исходящий и входящий трафик абонента промаркирован на всем пути следования пакетов. Таким образом, реализуется полноценное качество обслуживания для каждого абонента.

Использование DES-2108 обусловлено двумя причинами:

стоимость коммутатора DES-2108 в 3 раза ниже DES-3526;
невысокая плотность клиентов в подъездах;

По мере развития сети, увеличения плотности абонентов, повышения нагрузки на каналы в «узких» местах коммутаторы DES-2108 будут заменяться.

Методы обработки классифицированых пакетов.

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

Метод Strict.

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

Wighted Round Robin (Взвешенное круговое обслуживание).

Обработка приоритетов происходит в зависимости от их "веса", задаваемого в конфигурации коммутатора.

Пример:

config scheduling 0 max_packet 1
config scheduling 1 max_packet 2
config scheduling 2 max_packet 3
config scheduling 3 max_packet 4
config scheduling 4 max_packet 5
config scheduling 5 max_packet 6
config scheduling 6 max_packet 7
config scheduling 7 max_packet 8

В примере, для каждого уровня QoS задается количество пакетов, которые будут обработаны в первую очередь. То есть, при наличии в буфере устройства трафика с 8 приоритетами, сначала будут обработаны 8 пакетов 7 уровня QoS, затем 7 пакетов 6 уровня QoS, и так далее по убыванию.

Масштабируемость и модернизация сети

При увеличении количества абонентов плотность абонентов также будет расти. Масштабируемость и модернизация на уровне доступа абонента реализуется заменой свитчей DES-2108. В качестве замены выступает свитч DES-3526 (таблица 1), обладающий бОльшим количеством портов, наличием 2х комбо-портов 1000BASE-T/SFP Gigabit Ethernet, продвинутой функциональностью. Стоимость «на порт» DES 3526 равна стоимости «на порт» DES-2108.

Использование приоритетов для выбранного трафика позволит обеспечить стабильное функционирование важных сервисов без увеличения пропускной способности канала, что сэкономит и оттянет затраты на замену вышестоящего оборудования. При дальнейшем увеличении количества абонентов и загруженности каналов, управляемый коммутатор Fast Ethernet уровня 3 DES-3828 может быть заменен на аналогичный по функциональности DGS-3627G. Этот коммутатор обеспечивает высокую плотность гигабитных портов оснащенных слотами SPF для гибкого подключения по оптике, а также слотами для установки модулей расширения с портами 10 Gigabit Ethernet.

Так как все используемые коммутаторы стекируемые (за исключением DES-2108), то использование технологии виртуального стека, также позволяет масштабировать сеть, добавляя необходимое количество портов.

Итог

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

Надеюсь, данная статья поможет разобраться с практическими основами внедрения QoS, повысить эффективность работы сети, а также поможет обеспечить стабильную работу нужных именно Вам сервисов.

Литература

Шринивас Вегешна «Качество обслуживания в сетях IP», Cisco, издательство «Вильямс»,2003
http://www.dlink.ru/technical/
«Как организовать сервис телерадиовещания в сети», «Системный администратор», сентябрь 2007

Опубликовано в журнале "Системный администратор", апрель 2008

Мультисервисная сеть: качество обслуживания и мультикаст. Часть 2

2009-05-25T16:23:00.020+04:00

Часть 1, Часть 2, Часть 3

Внедрение мультикастинга

Технология мультикастинга предусматривает распространение данных от источника — группе получателей. Например - распространение телевизионных каналов ограниченной группе абонентов, при условии, что каждый абонент получает только тот канал, который он заказывал. Для достижения этой цели в IP сетях часто используется связка протоколов IGMP и PIM, хотя есть и другие, менее распространенные варианты.

IGMP + PIM

Для включения в мультикаст группу абонентов, находящихся в непосредственно присоединенных к маршрутизатору сетях, используется протокол IGMP. Для подключения к группе сначала посылается IGMP-сообщение "всем клиентам" о включении в группу, при этом локальный мультикаст-сервер подготавливает маршрут. Маршрутизатор регулярно отправляет запросы с требованием подтверждения участия в группе. Клиент посылает отклик - подтверждение для каждой из групп, если у него (клиента) есть хотя бы один процесс - член группы. Если при очередном запросе клиент не подтверждает членство в группе, то он покидает группу. На основе этих запросов-откликов мультикастинг-маршрутизатор составляет и поддерживает таблицу интерфейсов, которые имеют одного или более клиентов, входящих в мультикастинг-группы.

Для передачи групповых дейтаграмм в другие сети (через систему сетей), используются различные протоколы мультикаст маршрутизации.

Одними из наиболее используемыми современными протоколами мультикаст маршрутизации являются два протокола PIM (Protocol Independent Multicast) - PIM DM (Dense Mode) и PIM SM (Sparse Mode).

В нашем случае, по протоколу PIM передается информация о мультикаст группах всем роутерам вплоть до nord-mk1. Использование протокола PIM DM в нашем случае обусловлено большой плотностью получателей и архитектурой сети. Он не требует доступа к внутренним таблицам маршрутизации, поэтому достигается независимость от протоколов маршрутизации (OSPF, RIP, статическая маршрутизация). PIM DM реализует метод RPF (Reverse Path Forwarding) с усечением (Prune). То есть, при отсутствии получателей на очередном маршрутизаторе, отправляется сообщение Prune, и данный маршрутизатор отсекается от дерева рассылки. Каждые 3 минуты рассылаются пробные дейтаграммы, так как за это время истекает срок сообщения Prune. Время Prune можно задавать в конфигурации маршрутизатора.

Реализация

Итак, приступим к настройке мультикаста.

В нашем случае, для "обычной" маршрутизации используется протокол OSPF.

Настраиваем OSPF на обоих интерфейсах маршрутизаторов. Пример настройки на маршрутизаторе nord-mk1:

config ospf ipif System area 0.0.0.0 priority 1
hello_interval 10 dead_interval 40

config ospf ipif System authentication none
metric 1 state enable active

config ospf router_id 10.255.255.170

enable ospf

Проверить правильность настройки интерфейсов можно выполнив следующую команду

sh ospf neighbour

Результат вывода должен быть приблизительно таким.

IP Address of Router ID of Neighbor Neighbor

Neighbor Neighbor Priority State

--------------- --------------- -------- -------------

10.255.255.17 192.168.149.5 1 Full

Total Entries : 1

После тщетных попыток заставить работать мультикаст, пришлось обратиться в службу технической поддержки компании D-Link. На запрос были получены новые версии прошивок для nord и nord-mk1 и ситуация исправилась.

Следует также обратить внимание на следующую «особенность». В тексте конфигурационного файла nord-mk1 присутствуют вот такие записи:

disable gvrp
config gvrp 25-28 state disable ingress_checking
enable acceptable_frame admit_all pvid 1

Несмотря на казалось бы глобальное запрещение gvrp, вторая строка влияет на работу, причем именно мультикаста. Как оказалось, необходимо в качестве pvid выставить 1, несмотря на вот эти строки в нашей конфигурации:

config vlan default delete 1-28
config vlan default advertisement enable
create vlan 20-mik9jan-1 tag 20
config vlan 20-mik9jan-1 add tagged 26
config vlan 20-mik9jan-1 advertisement disable

Для каждого из маршрутизаторов DGS-3612G, DXS-3326GSR, nord-mk1 выполняем следующие команды:

enable igmp_snooping
config igmp_snooping all state enable
config igmp all state enable
enable pim
config pim all state enable
create pim crp group 224.0.0.0/4 rp System

Для свитча nord-mk1 обязательным является включение PIM DM совместно с IGMP на всех интерфейсах, где требуется получение мультикаст трафика. Эти и некоторые другие, менее значительные, особенности (ошибки) реализации удалось решить только при активном сотрудничестве со службой технической поддержки компании D-Link.

Проверяем фунционирование протоколов.

DES-3800:admin#show igmp

IGMP Interface Configurations

QI : Query Interval MRT : Maximum Response Time

RV : Robustness Value LMQI : Last Member Query Interval

Interface IP Address/Netmask Version QI MRT RV LMQI State

------------ ------------------ ------- ----- --- --- ---- --------

System 10.255.255.170/30 2 125 10 2 1 Enabled

101-port1 10.0.60.1/26 2 125 10 2 1 Enabled

102-port2 10.0.60.65/26 2 125 10 2 1 Enabled

...

116-port16 10.0.63.193/26 2 125 10 2 1 Enabled

Total Entries: 21

DES-3800:admin#show pim neighbor

PIM Neighbor Address Table

Interface Name Neighbor Address Expired Time

--------------- ---------------- ------------

System 10.255.255.169 96

Total Entries: 1

DES-3800:admin#sh igmp group

Interface Multicast Group Last Reporter IP Querier IP Expire

------------ --------------- --------------- --------- ---------

101-port1 230.1.1.1 10.0.60.4 SELF 145

101-port1 230.1.1.2 10.0.61.3 SELF 250

...

106-port6 239.255.255.250 10.0.61.77 SELF 216

DES-3800:admin#sh ipmc cache

IP Multicast Forwarding Table

Multicast Source Upstream Expire Routing

Group Address/Netmask Neighbor Time Protocol

--------------- ------------------ --------------- ------ ---------

230.1.1.1 10.0.6.144/32 10.255.255.169 163 PIM-DM

230.1.1.2 10.0.6.144/32 10.255.255.169 183 PIM-DM

...

230.1.1.1.6 10.0.6.144/32 10.255.255.169 209 PIM-DM

Total Entries: 21

Не углубляясь в тонкости подбора параметров протоколов PIM DM и IGMP, настройку мультикаста в данном сегменте сети можно считать завершенной. Таким образом, сеть подготовлена к внедрению сервиса теле- и радиовещания и решена первая часть задачи.

Далее >>