QoS, RAN, TN — еще не все сказано

И снова здравствуйте, господа и дамы!

Сегодня я расскажу об очень ресурсоемкой теме. Тема с названием — внедрение QoS и политики приоритезации трафика в сетях Telco.

С чего все началось? Дело в том, что примерно до 2010 года все телеком операторы жили припеваючи, не зная проблем с технологией Ethernet, и строили свои сети по технологии SDH/Sonet. Суть этой технологии проста как две копейки — с помощью мультиплексирования потоков E1, которые в свою очередь, состоят из 32 таймслотов, создается канал связи с временным разделением фрэймов. Т.е. есть стандартная величина потока Е1 — 2.048 мб/с, который содержит 32 таймслота по 64 кб/с. Далее некоторое количество потоков Е1 мультиплексируется в базовые уровни информационных структур STM-1, STM-16, STM-64 STM-256, что соответствует скоростям 155 мб/с, 2.5 Гб/с, 10 Гб/с, 40 Гб/с. Это значит, что на клиентском интерфейсе мультиплексора под одно клиентское включение выделили 3 таймслота (192 кб/с), и этот клиент не сможет отобрать емкость в основном канале свыше, чем 192 кб/с. Но в этой технологии есть ряд проблем, которые не дали ей развиться после 2010 года — дороговизна оборудования, худшая масштабируемость по сравнению с Ethernet сетями, невозможность развить свыше 40G в выделенном канале (Ethernet за 100G перешагнули в 2015 году в коммерческом использовании). Относительно текущей статьи, я выделю основной плюс сетей SDH — прописал для клиента конкретное количество ресурса, и клиент не сможет забрать из магистрального потока бОльшее количество ресурса, сервис клиента с точки зрения качества будет ровно таким, какой прописали в SLA контракта, исходя из параметров технологии, посредством чего этот канал и был предоставлен. То же самое касается и базовых станций — прописали 8 Е1 на базовую станцию, БС ограничена во всех ее трех (реже 4, 5, 6) секторах 16-ю мб/с. Подключили две БС каскадом на тех же 8 Е1, значит две БС будут делить между собой все те же 16 мб/с — все просто.

Все началось из Москвы. Как мне рассказывали старожилы, примерно в 2007 году, все крупные телеком операторы задумались о том — как включать базовые станции нового поколения — на тот момент 3G — все также через из SDH? Посчитав затраты на развертывание сетей 3G, стало ясно, что сеть SDH станет дороже, нежели чем RAN 3G. И на выручку пришла технология Ethernet, которую в то время боялись как огня — TCP/IP, пакетная передача данных, коммутаторы, маршрутизаторы, модель OSI — какие-то незнакомые слова и аббревиатуры. Опустим тендерные перипетии, но основными поставщиками Ethernet оборудования для телеком операторов РФ стали Huawei и Nokia — причем Huawei архитектурно предлагали L2, а Nokia с самого начала были Full MPLS оборудованием. Есть вкрапления Cisco, Juniper — но чаще это магистрали и мелкие филиалы.

С внедрением сетей с технологией Ethernet, практически сразу стал вопрос о емкости и распределении трафика между клиентскими включениями — если в SDH все понятно (сколько прописал, столько и заняли полосы), то с Ethernet ничего не понятно — порты 100/1000 мб/с, да есть шейперы, но а как их ставить, если через один Ethertnet порт работают несколько базовых станций с сервисами разных приоритетов — есть реал тайм трафик критичный к потерям (голос и сигнализация), есть дата трафик, который не столь критичен к потерям. В тоже время деление трафика на голос и дату происходит на уровне контроллера (RNC), а не на уровне ТС. И тут на авансцену выходит QoS — Quality of Service с политиками приоритезации трафика.

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

Приведу пример распределения типов сервисов для 3G с их метками DSCP/P-bit.

Эта табличка означает, что на контроллере (RNC) необходимо для исходящего трафика для голосовых и не голосовых типов сервисов указать определенную метку (dscp или p-bit или и то и другое одновременно), для того, чтобы транспортная сеть MBH обработала тот или иной тип сервиса согласно своим политикам приоритезации трафика. Если это высокий приоритет, то ТС пропускает пакет без буферизации в режиме обработки tail drop, если это не высокий приоритет, то пакеты буферизируется, создаются очереди, и если памяти порта устройства достаточно, то пакет не отбрасывается. Если памяти не достаточно или есть перегрузка на интерфейсе, то пакет отбросится (это явление называется QoS Drop), и все это регулируется механизмами WRR. Это отдельная и очень большая тема, расскажу в другой раз. Сейчас наглядно покажу как это выглядит в реальности.

На графиках видно, как распределяется трафик по очередям на одном интерфейсе (клиентском в сторону базовой станции) и в каких очередях есть потери. Согласно приведенной табличке выше, можно понять, какой тип сервиса дропится в той или иной очереди. Главное, что нет дропа в EF (очередь, которая обслуживает голосовой сервис и сигнализацию). Для не приоритетных очередей, которые обслуживают дата-трафик (AF1-4), дроп позволителен в определенной доле десятых процентов. Эти потери пакетов вызывают ретрансмиты, которые в свою очередь провоцируют сужение TCP окна, которое напрямую влияет на скорость скачивания данных. В данном конкретном случае QoS drop вызван небольшим буфером для очередей на устройстве (маршрутизаторе), который не может сгладить микроберсты трафика LTE — решается заменой оборудования. В более современных версиях данного оборудования возможно программное перераспределение памяти на порты, обслуживающие высоконагруженных клиентов, но в этом, к сожалению, только замена.

После принятия решения о внедрении политики приоритезации трафика, в дело вступают инженеры, которые занимаются конфигурацией оборудования. Пример буду приводить на оборудовании МЕН и РРЛ Huawei. Стоит упомянуть, что на оборудовании MEN Huawei есть несколько типов интерфейсов — NNI и UNI — сетевые и клиентские соответственно.

Как видно из настроек, на сетевые и клиентские интерфейсы применены политики QoS с некоторой обработкой и доверием полю DSCP. Приведу пример настройки оборудования РРЛ Huawei

Как видно из настройки, указан тип доверия входящей маркировке — ip-dscp. Это означает, что РРЛ, подключенная к оборудованию МЕН будет доверять (не ремапить) входящему трафику со стороны оборудования МЕН и смотреть в поле DSCP для того, чтобы классифицировать трафик для дальнейшей обработки. На основании классификации и установленных политик внутри РРЛ, РРЛ примет решение, какой трафик она отбросит, в случае перегрузки в радио стволе. Т.е. на стыке двух разных типов оборудования — МЕН и РРЛ, должны быть одинаковые настройки с точки зрения маппинга и с точки зрения доверия — с двух сторон DSCP. Тогда в этом случае РРЛ корректно распознает трафик и корректно его обработает в случае перегрузок или иных ограничений.

Теперь рассмотрим ситуацию, когда инженер ошибся, и установил на стороне РРЛ доверие маркировке не DSCP, а P-Bit. РРЛ станет смотреть только в P-Bit, а оборудование МЕН не устанавливает в это поле никаких значений, т.к. нет соответствующей команды. По дефолту в этом поле нули, поэтому РРЛ весь трафик классифицирует как BE и обработает его с наименьшим приоритетом. В случае перегрузки пакеты будут дропиться в рандомном порядке и абсолютно все, не зависимо от того, голос это или дата трафик. Это приведет к потере голосовых фреймов и значительному искажению при разговоре, в худшем случае потере слов, колл-дропу (когда дропнется сигналка), не дозвонам и прочим «прелестям». Т.к. перегрузок на сети у всех операторов достаточно много, то соответствие сетей политикам приоритезации трафика — must have!!! Но, к сожалению, ни у одного оператора в РФ нет единой системы контроля за настройками на сети. Если худо бедно сверка параметров настройки QoS реализована и как-то выявляет проблемы с помощью комплексов, подобных Max Patrol, то на РРЛ эта проблема не решена никак. Дело в том, что каждый производитель РРЛ не предусмотрел единого механизма выгрузок конфиг файлов, унификации настройки параметров, что выливается в невозможность корректной проверки настроек. Чаще исправление конфигураций выполняется при решении конкретной задачи у конкретного абонента — есть проблемы с голосом, пошли проверять QoS по всему пути прохождения трафика, который прежде нужно выявить.

На этом все, пишите вопросы, отвечу на них с удовольствием.