6.2 Качество обслуживания

Тонкая и разнообразная поддержка дифференцированного обслуживания разных типов трафика всегда рассматривалась как наиболее сильная сторона ATM. Действительно, разработчики технологии всесторонне проанализировали все типы существующего трафика, разделили его на несколько категорий, для каждой создали отдельную службу (CBR, VBR-RT, VBR-nRT, ABR и UBR), призванную наилучшим образом поддерживать передачу соответствующего ей трафика. При этом сеть может контролировать параметры QoS «из конца в конец» для каждого отдельного виртуального соединения, обеспечивая высокую степень гранулированности соглашений SLA.

Неспособность MPLS поддерживать QoS подобным образом очень многие считают ее слабостью и главной причиной сохранения АТМ на магистрали. Безусловно, проблемы с поддержкой QoS у сетей IP/MPLS существуют, но дело не в том, что MPLS не может поддерживать QoS так же, как ATM. Сегодня отсутствует принятый IETF и другими органами стандарт, устанавливающий для MPLS способы поддержки QoS в соответствии с особой ролью технологии, предназначенной для ядра сети, а не для ее периферии.

Нужно отметить, что поддержка QoS вообще не встроена жестко в MPLS (если не считать зарезервированных 3 бит Exp в заголовке, которые ряд производителей сегодня использует для переноса признака приоритетности кадра). Подобное «упущение» сделано сознательно, чтобы предоставить производителям и сетевым интеграторам свободу действий и возможность применять те из имеющихся механизмов QoS, что наилучшим образом отвечают потребностям сети. Сегодня таким рекомендуемым механизмом является архитектура DiffServ, она разработана для сетей IP и ориентирована на работу с несколькими агрегированными классами трафика, а не с отдельными пользовательскими соединениями, как в ATM. Именно такая технология подходит для работы на магистрали сети.

Другим выбором сетевых интеграторов может оказаться объединение техники инжиниринга трафика MPLS с DiffServ, этот механизм получил название «DiffServ Aware Traffic Engineering». Он предусматривает прокладку в сети IP/MPLS агрегированных путей LSP двух типов — для чувствительного к задержкам трафика и для остального: в результате весь пользовательский трафик сводится всего к двум классам, так что, вместо информации о параметрах QoS тысяч виртуальных соединений (подход ATM), устройствам LSR достаточно запоминать параметры только двух LSP по каждому интерфейсу — такое существенное сокращение обеспечивает высокую масштабируемость решения и сохраняет поддержку QoS. Беда только в том, что DiffServ Aware Traffic Engineering всего лишь Internet Draft, и до сих пор неясно, когда и в каком окончательном виде данная техника станет стандартом. Это действительно слабое место MPLS создает проблемы с совместимостью решений производителей в отношении механизмов QoS; кроме того, пользователь оказывается в совершенно непредсказуемой ситуации при получении сервиса MPLS — неизвестно, как его реализовал оператор, каким образом он поддерживает соблюдение параметров QoS и обеспечивает ли вообще, поскольку стандарта не существует. С ATM таких проблем нет: QoS у всех производителей реализуется более-менее однотипно, в соответствии со стандартами. Более того, АТM дает пользователю возможность проконтролировать качество виртуального соединения, а для MPLS подобные стандартные средства отсутствуют.

Что же касается отсутствия в MPLS АТМ-подобных механизмов гранулированной поддержки QoS, то для работы на современной магистрали они и не нужны. Такой на первый взгляд неожиданный вывод достаточно просто обосновать теоретически и подтвердить практическими измерениями трафика Internet.

Так, если считать, что каждое пользовательское соединение создает поток данных со скоростью 100—200 Кбит/с, то полностью загруженный канал E1 (2 Мбит/с) переносит 10—20 таких соединений, канал STM-1 (155 Мбит/с) — 60—120, канал STM-16 (2,5 Гбит/c) — 1000—2000, а канал STM-64 (10 Гбит/с) — уже 4000—8000. Отдельный пользовательский поток обладает очень высокой степенью пульсаций — 50:1 или даже 100:1, что и создает эффект очередей, ведущий к неравномерным задержкам пакетов. Однако при объединении значительного количества пользовательских потоков вступает в действие закон больших чисел: пульсации одних потоков накладываются на периоды молчания других, так что суммарный поток становится гораздо более «гладким». А чем реже поток пульсирует, тем меньше проявляется эффект очередей.

Обычно, поясняя выбор максимально допустимой загрузки канала для чувствительного к задержкам трафика, используют кривую, показывающую, как изменяется среднее время ожидания пакетов в очередях W от коэффициента загрузки канала. Однако при этом нельзя забывать, что на ожидание в очередях влияет и другой фактор, а именно — коэффициент пульсации трафика. На Рисунке 6.2 показано влияние на задержки обоих коэффициентов. После увеличения коэффициента загрузки канала до 0,3-0,5 кривая, соответствующая значительным пульсациям Kmax, достаточно резко поднимается вверх, в результате загруженный таким образом канал не позволяет обслуживать чувствительный к задержкам трафик. При уменьшении пульсации трафика точка, при которой задержки начинают ощущаться, сдвигается вправо. Если трафик становится «идеально» синхронным, то задержки из-за пребывания в очередях исчезают вовсе — пакеты поступают с фиксированной задержкой на обработку коммуникационным устройством и распространение данных по каналам связи.

Рисунок 6.2 - Зависимость среднего времени ожидания

в очереди от пульсации трафика

В своем докладе на 22-й конференции североамериканских операторов связи (North American Network Operator Group, NANOG), состоявшейся в мае 2001 г., Питер Лутберг (компания Stupi LLC) привел аналогичные графики задержек в очередях для каналов T1, OC-3, OC-48 и OC-192. В соответствии с его данными, канал OC-192 на 10 Гбит/с в сети IP может быть загружен до 97% (!) от своей номинальной скорости, и только после этого порога начинают появляться ощутимые задержки вследствие ожидания в очередях. К сожалению, из опубликованных материалов доклада не ясно, при каких предположениях сделан этот вывод.

Более конкретные результаты, подтверждающие низкую степень пульсации трафика в толстых каналах Internet, приведены в презентации компании Packet Design, сделанной на той же конференции NANOG. Сотрудники компании проводили измерения вариации задержек тестового трафика в 1 Мбит/с, который они пропускали через работающий канал OC-48 одного из американских операторов связи, при этом трафик пересылался между точками присутствия оператора в Сан-Франциско и Вашингтоне, т. е. между двумя побережьями. Результаты измерений показали, что 99,99% посланных пакетов прибыли в точку назначения с вариацией задержки меньшей, чем 1 мс, и только 0,01% имели показанные на Рисунке 6.3 отклонения в 10—20 мс (обычно американские операторы дают гарантию того, что трафик между двумя побережьями будет передаваться с вариацией не более 30 мс).

Рисунок 6.3 - Вариация задержки при передаче пакетов

по каналу OC-48 на 2,5 Гбит/с

Подведем итоги. При передаче трафика через высокоскоростные каналы 2,5—10 Гбит/с пульсации большого количества (несколько тысяч) отдельных пользовательских потоков в суммарном потоке настолько сглаживаются, что для их обработки достаточно простых методов работы с очередями: например, тех, которые развиваются в рамках механизмов DiffServ, применяемых в устройствах IP/MPLS. И тонкие методы поддержки QoS, как у ATM, в таких условиях просто излишни, а их применение приведет только к удорожанию магистрали из-за необходимости запоминания каждым магистральным маршрутизатором тысяч параметров отдельных соединений, т. е. к явно не масштабируемому решению.

Нужно также отметить, что проблемы поддержки QoS на скоростных магистралях не очень интересуют многих операторов по другой причине — эти каналы недогружены, так что о 97% загрузки их владельцам остается только мечтать. Дело в том, что в период бума Internet в мире было проложено столько оптического волокна, что этих запасов хватит на много лет кризиса. Это привело, например, к тому, что стоимость аренды волокна от Нью-Йорка до Лондона снизилась с 2000 до 400 долларов в месяц. Так что до критических загрузок, когда собственно и нужны методы QoS, большое число западных операторов просто еще не доросло.

Но все это справедливо только для высокоскоростных каналов. Как только мы переходим к рассмотрению «магистралей» в 2 Мбит/c и даже 155 Мбит/с, ситуация изменяется, и АТМ в данном случае выглядит предпочтительнее.