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

Сегодня я расскажу об очень ресурсоемкой теме. Тема с названием - внедрение 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.

Пример соответствия типов сервиса с маркировкой для 3G
Пример соответствия типов сервиса с маркировкой для 3G

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

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

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

Настройка NNI интерфейса СХ600

interface GigabitEthernet1/0/1 

Настройка main интерфейса 

carrier up-hold-time 10000 

Задержка на перевод порта в активное состояние. Необходима для предотвращения дрожания интерфейса. Применяется в кольцевых топологиях. Не применяется при топологиях типа: цепь 

negotiation auto 

negotiation необходим для быстрого обнаружения отказа в случае выхода из строя одного из двух волокон 

description XXXXXXXX 

Описание порта (к какому соседнему устройства подключен) 

undo shutdown 

set flow-stat interval 10 

указание периода сбора статистики 

mtu 9600

Настройка MTU. Необходимо обратить особое внимание на значение MTU. Для NNI интерфейсов между СХ600 MTU=9600; для NNI интерфейсов к ATN MTU=9500. 

Настройка ip адреса из диапазона интерконнекта 

isis enable 100 

Назначение номера ISIS процесса. Для main интерфейсов номер = 100; для саб-интерфейсов номер = номеру домена доступа 

isis circuit-type p2p 

Указание типа ISIS интерфейса. Значение всегда p2p 

isis cost XXX 

Команда указывается только при использовании скорости канала ниже скорости физического интерфейса. Значение cost вычисляется по формуле: cost=1000000/ полоса пропускания(в Мбит/с) . 

Например, при аренде канала 400Мбит/с при подключении через гигабитный порт: cost=1000000/400=2500 

ospf network-type p2p 

Включение OSPF Area0 между агрегаторами (в случае использования RTN). network-type - значение всегда p2p 

 

Значение cost (1-65535) вычисляется по формуле: OSPF cost= Bandwidth reference value (в мегабитах)/Interface bandwidth (в мегабитах). 

 

Для типовых скоростей: 

 

100000/100000 = 1 (для 100G линка) 

 

100000/10000 = 10 (для 10G линка) 

 

100000/1000 = 100 (для 1G линка) 

 

100000/100 = 1000 (для 100М линка) 

 

100000/10 = 10000 (для 10М линка) 

 

100000/1 = 65535 (Максимальное значение OSPF cost) 

ospf enable 1 area 0.0.0.0 

 

ospf cost 100 

 

mpls

Включение MPLS 

mpls te

 

mpls rsvp-te

 

mpls rsvp-te hello 

 

mpls te link administrative group 111 

[Опционально]. Указание административной группы для интерфейса

undo dcn 

Отключение функции dcn. DCN может быть включена при проведении пусконаладочных работ 

trust upstream default 

Включение полного доверия маркировке(включая CS6,CS7) 

port-queue be wfq weight 4 port-wred wred_be outbound 

Настройка политики QoS порта. Значение шейпера EF может корректироваться в зависимости от профиля реального трафика. Базовое значение шейпера для EF трафика = 50% от полосы пропускания канала. 

port-queue af1 wfq weight 10 port-wred wred_af1 outbound 

 

port-queue af2 wfq weight 15 port-wred wred_af2 outbound 

 

port-queue af3 wfq weight 20 outbound 

 

port-queue af4 wfq weight 20 outbound 

 

port-queue ef pq shaping 5000 outbound 

 

clock priority 10

Разрешить прием синхронизации. Указание приритета синхронизации 

clock synchronization enable 

Включение протокола SyncE на интерфейсе 

Настройка UNI интерфейса СХ600

interface GigabitEthernet2/1/10.1001

Настройка саб-интерфейса для передачи данных NodeB/eNodeB 

description 

Описание саб-интерфейса (для чего используется) 

mtu 9600 

Настройка MTU 

vlan-type dot1q 1001

Указание c-vlan 

loop-detect enable 

Включение loop-detect 

loop-detect block 5 

loop-detect priority 1 

loop-detect trigger interface-down enable 

l2 binding vsi xxx

Указание VSI 

mac-limit maximum 100 rate 0 

Ограничение количества изучаемых MAC-адресов 

trust upstream default

Привязка diffserve домена. Доверие маркировке DSCP 

statistic enable 

Включение сбора статистики саб-интерфейса 

qos-profile mobile-in inbound 

Применение профиля QoS без ограничения полосы пропускания. Может применяться профиль с ограничением полосы пропускания (в зависимости от политики QoS сети) 

qos-profile mobile-out outbound

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

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

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

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

Комментарии (6)


  1. evr1ka
    30.12.2022 09:30

    В свете изменившейся парадигмы, за других производителей, типа H3C сказать что-то можете? Имели такой опыт работы? Чтобы рекомендовали для организации связанности сити в организациях?


    1. temabeloglinskiy Автор
      31.12.2022 00:05

      Добрый день. Нет, с этим производителем не работал, но по компоновке очень похоже на Huawei - роутеры похожи на CX600-X2, X3, X8. Даже, порывшись в user manual нашел одинаковые команды настройки и фирменный system-view от Huawei - эта команда аналог conf t в Cisco. С первого взгляда смущает цена - по моей оценке, она раза в три выше, нежели чем Huawei продавал оборудование в РФ еще в прошлом году.


      1. Gansterito
        31.12.2022 11:19

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


    1. temabeloglinskiy Автор
      31.12.2022 00:15

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


  1. alexey_ivanchenko
    30.12.2022 21:03

    Добрый день. Исходя из вашего опыта, что нехорошего и в каких случаях будет происходить, если не настроить DSCP для GSM? Например, развернуты сети LTE и GSM, транспортная сеть общая. Для LTE DSCP настроили, для GSM - нет. Чего ожидать?


    1. temabeloglinskiy Автор
      30.12.2022 23:40

      Добрый день. Давайте рассмотрим таблицу классификации трафика для 2G. Если сложится такая ситуация, что весь высокоприоритетный трафик (EF) окажется в нулевой очереди, и при этом на сети случаются конжешны по причине микроберстов LTE в направлении downlink либо высокой утилизацией линков, то с какой-то долей вероятности пострадает вся сигналка + синхронизация, что в GSM крайне критично + голосовой канал TCH (в таблице CS speech services). Чаще это проявляется как разваливающиеся кодеки (речь становится как у робота и искажается), колл-дропам. Ну нужно понимать, что чаще всего проблемы в направлении DL, а не в UL, т.к. трафика в разы больше именно в первом направлении. Поэтому маркировать нужно в первую очередь трафик со стороны BSC/RNC/IMS в сторону БС. Для VoLTE критичны оба направления, поэтому маппить трафик нужно и как в направлении DL, так и в направлении UL.