Качество обслуживания в современных сетях. Часть 1
28.03.2005 | khomya

Часть 1 | Часть 2

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

Больше всего проблем возникает при попытке «собрать» множество однофункциональных сетей в одну гибкую многосервисную сеть. Еще трудней получить такую сеть, которая бы смогла разрешить абсолютно все проблемы. Функции сети могут изменяться, появляться новые. Меняются и приложения, ориентированные на работу в сети, с собой они приносят новые требования к сети. Пользовательские рабочие станции сейчас предоставляют услуги по обработке сообщений, видеоинформации, телефонии и т.д.

Поэтому возникла необходимость гарантировать время реакции, пропускную способность сети и другие параметры сети. Такая технология была разработана и получила название качество обслуживания (Quality of Service, QoS).

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

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

Сетевой трафик

Можно выделить четыре наиболее общие характеристики трафика:

  • «взрывообразность»
  • терпимость к задержкам
  • время ответа
  • емкость и пропускная способность

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

«Взрывообразность» характеризует частоту посылки трафика пользователем. Чем чаще пользователь посылает свои данные в сеть, тем она больше. Пользователь, который посылает данные регулярно, в одном темпе, сводит показатель «взрывообразности» практически к нулю. Этот показатель можно определить отношением максимального (пикового) значения трафика к среднему.

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

Емкость сети – это реальное количество ресурсов, доступных пользователю на определенном пути передачи данных.

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

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

  • Трафик реального времени включает в себя аудио- и видеоинформацию, критичную к задержкам при передаче. Допустимые значения задержек обычно не превышают 0,1 с (сюда входит время на обработку пакетов конечной станцией). Кроме того, задержка должна иметь малые флуктуации (с ними связан эффект «дрожания»). При сжатии информации трафик данной категории становится очень чувствительным к ошибкам при передаче, а из-за жестких требований к задержкам при передаче потоков в режиме реального времени возникающие ошибки не могут быть исправлены с помощью повторной посылки.
  • Трафик транзакций. При передаче этого вида трафика задержки не должны превышать 1 с. В противном случае пользователи будут вынуждены прерывать работу и ждать ответа на свои сообщения, потому что только после получения ответа они могут продолжить отправлять свои данные. Такая схема обмена информацией снижает производительность труда, а разброс в значениях задержек может привести к возникновению чувства дискомфорта у пользователей. В некоторых случаях превышение допустимого времени задержек приводит к сбою рабочей сессии.
  • Трафик данных. Задержки при передаче трафика этой категории могут иметь практически любые значения и достигать даже нескольких секунд. Для такого трафика полоса пропускания более важна, чем время задержек: увеличение пропускной способности сети влечет за собой уменьшение времени передачи. Приложения, передающие большие объемы данных, разработаны, в основном, так, что захватывают всю доступную полосу пропускания сети. Редкими исключениями являются приложения потокового видео. Для них важны и пропускная способность и минимизация времени задержки.

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

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

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

Обзор технологий качества обслуживания

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

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

Характеристики технологий качества обслуживания:

Технология Доступность Достоинства Ограничения
Обеспечение перекрывающей пропускной способности Полностью доступна Проста в реализации По масштабируемости
Организация приоритетных очередей в маршрутизаторах Полностью доступна Испытанная технология, удовлетворительно работающая с существующими сетевыми протоколами Неприемлема для передачи аудио- и видеоинформации в реальном времени. Требует дополнительных ресурсов маршрутизаторов.
Протокол RSVP Находится в стадии разработки Может работать в любых IP-сетях Не проверен в больших, распределенных сетях.
Установление приоритетов в виртуальных сетях Находится в стадии разработки Потенциально должна хорошо интегрироваться в сети с коммутаторами Поддерживается только в виртуальных сетях.
Сети Frame Relay с качеством обслуживания Доступна с ограничениями Полезна как приложение к другим технологиям. Может использоваться для передачи голоса в реальном времени Не гарантирует задержку. Не стандартизована.
Сети ATM с качеством обслуживания Полностью доступна Опробованная. стандартизированная технология Требуется магистраль ATM.

Обеспечение перекрывающей пропускной способности

Появившиеся в последнее время новые высокоскоростные технологии, такие как Gigabit Ethernet, приводят к мысли, что все проблемы связанные с качеством обслуживания, можно решить просто увеличением пропускной способности, которой у новых технологий казалось бы предостаточно. Это может быть решением в некоторых случаях, особенно, если локальной сетью пользуются небольшие рабочие группы.

Использование высокоскоростных каналов связи, предоставляемых, например, технологиями Fast/Gigabit Ethernet со скоростями 100/1000 Мбит, при достаточно низкой загрузке сети, позволяет избежать возникновения узких мест в сети. Достигается и низкая задержка и небольшая амплитуда дрожания, причем без использования технологии ATM. Главным здесь является стремление отказаться от маршрутизации и других методов, способных вызвать потерю пакетов и их повторную передачу. Однако в подавляющем большинстве случаев все же необходим жесткий контроль за распределением трафика.

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

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

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

Приоритетные очереди в маршрутизаторах

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

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

На данный метод не существует единого стандарта. Отдельные его части описаны в разных стандартах. Каждый производитель сетевого оборудования реализует в своих изделиях собственные алгоритмы обработки очередей. Например, Cisco Systems использует алгоритм взвешенной справедливой очереди, а Bay Networks – очередь, основанную на классах.

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

Случайное раннее обнаружение (Random Early Detection, RED) предоставляет собой альтернативу очередям FIFO. Этот метод позволяет смягчить эффект от потери пакетов даже при очень больших нагрузках. Такая очередь по-прежнему использует принцип FIFO, но пакеты отбрасываются случайным образом (вместо того, чтобы отбрасывать хвост очереди), когда средняя длина очереди за данный промежуток времени превосходит установленное значение. Этим достигается оптимизация заполнения очереди. Данный алгоритм был изначально придуман для протокола TCP, но он может быть применим к трафику любого протокола, когда сеть не гарантирует доставки.

Очередь с приоритетами – это алгоритм, при котором несколько очередей FIFO или RED образуют одну очередь. Трафик распределяется между этими очередями в соответствии с заданными критериями. При этом трафик отправляется в порядке строгой очередности: первым – трафик с высоким приоритетом, вторым – со средним и т.д.

Очереди на основе классов (Class Based Queuing, CBQ) – это алгоритм, при которм трафик делится на несколько классов. Каждый класс имеет собственную очередь и ему выделяется некоторая часть пропускной способности канала.

Взвешенная справедливая очередь (Weighted Fair Queuing, WFQ) – частный случай СBQ, когда классам соответствуют независимые потоки. Каждому классу соответствует одна очередь FIFO и ей отводится некоторая часть пропускной способности канала. При этом происходит перераспределение пропускной способности между потоками. Выделение дополнительной пропускной способности для больших потоков позволяет уменьшить задержку при их обработке.

Интерфейсом к очередям передачи пакетов служит протокол резервирования ресурсов (Resource Reservation Protocol, RSVP). Этот протокол позволяет системам запрашивать сервисы у сети, например, гарантированную пропускную способность, максимальный уровень потерь пакетов и предсказуемую задержку.

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

Протокол резервирования ресурсов

В основу протокола резервирования ресурсов RSVP заложены три понятия:

  • сеанс
  • спецификация потока
  • спецификация фильтра

Сеанс – это период обработки потока данных. Сеанс начинается с выделения ресурсов, необходимых для пропуска потока, и заканчивается после прохождения потока. Запрос на резервирование ресурсов от получателя состоит из спецификации потока и фильтра.
Спецификацию потока
определяют параметры услуг, которые необходимо зарезервировать, чтобы поток мог пройти через данный узел без потери качества.
Спецификация фильтра
определяет набор пакетов, под которые запрашиваются ресурсы. Любые другие пакеты обрабатываются по остаточному принципу с предоставлением минимальных услуг, которые сеть может обеспечить в это время. Спецификация фильтра описывает произвольное подмножество пакетов одного сеанса. Фильтр может быть настроен на различные параметры: конкретных отправителей, конкретные протоколы, поля заголовков и т.д.

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

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

Сообщение PATH используется для распространения информации об обратном маршруте. Используемый протоколом RSVP протокол маршрутизации не может определить обратный маршрут, а сообщение RESV должно передаваться именно по обратному маршруту. Информация об обратном маршруте получается следующим образом: любое устройство, желающее стать отправителем, посылает сообщение PATH членам своей группы. При получении этого сообщения маршрутизаторы и члены группы переходят в состояние PATH. В этом состоянии пакеты для данного отправителя должны пересылаться на маршрутизатор, от которого они были получены. Каждый маршрутизатор, получивший сообщение PATH, запоминает идентификатор потока и канал связи, по которому пришло это сообщение. Если потенциальный адресат, принявший команду PATH, хочет получить указанные данные, он посылает команду RESV. Эта команда следует по пути PATH, но в обратном направлении.

Можно упрощенно описать данный алгоритм на следующем примере. Предположим, что отправитель, зная всех получателей, хочет показать им видеоклип. Так как адреса известны, он посылает им сообщение PATH. Это сообщение несет информацию о том, что отправитель собирается показать видеоклип членам своей группы. По пути следования к адресатам, сообщение выставляет на маршрутизаторах необходимые для передачи потока параметры. Если какой-либо маршрутизатор не может обеспечить данные параметры, он отвергает сообщение. Это означает, что получатель на таком маршруте не сможет посмотреть видеоклип. После достижения сообщением PATH всех получателей, они анализируют полученую с этим сообщением информацию и отвечают сообщением RESV. Сообщение RESV проходит по маршруту сообщения PATH, но в обратном направлении. Получатели закладывают в сообщения RESV информацию о том, хотят ли они просмотреть клип. Они могут попросить показать другой клип. Некоторые попросят уменьшить качество видео, так как имеют плохие каналы связи и т.д. После того как отправитель получил все сообщения RESV, он начинает сеанс с учетом пожеланий каждого получателя.

Сообщения RESV/PATH могут использоваться для определения вышедшего из строя узла или канала связи. Обмен этими сообщениями подтверждает, что сеанс ещё не окончен, то есть выделенные ресурсы должны поддерживаться.

Можно привести другой пример работы протокола RSVP. Если рабочей станции необходимо зарезервировать полосу пропускания для какого-либо трафика, она посылает ближайшему маршрутизатору запрос протокола RSVP, который определяет, что необходим канал с пропускной способностью 1 Мбит/с до определенного получателя. Данный запрос просматривается всеми маршрутизаторами на пути. Если маршрутизатор может поддержать содержащиеся в запросе требования, он передает запрос следующему маршрутизатору и т.д. Запрос считается выполненным, если все маршрутизаторы ответили утвердительно. Если один из маршрутизаторов не поддерживает требований, он ответит конечной станции сообщением о том, что запрос отклонен.

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

Неспособность протоколов маршрутизации учитывать вопросы качества обслуживания при выборе маршрута приводит к другой проблеме, связанной с протоколом RSVP. Это – масштабируемость. Каждый маршрутизатор должен принимать и обрабатывать информацию о состоянии всех контролируемых протоколом RSVP потоков данных, проходящих через него, а это может привести к перегрузке маршрутизатора, обслуживающего множество потоков. Проблема только отчасти сглаживается умением RSVP объединять маршруты для групповой доставки данных. Сложности также возникают при обработке данных, которые перенаправляются по другим маршрутам, например, из-за возникновения перегрузок. Новые маршруты должны быть проложены в соответствии с требованиями RSVP с помощью специальных сообщений от других маршрутизаторов в потоке.

Несмотря на эти недостатки и тот факт, что протокол RSVP все ещё находится в стадии рассмотрения в группе IETF и не проверен в больших распределенных сетях, все ведущие производители сетевого оборудования (Cisco Systems, 3Com, Bay Networks и т.д.) вводят его поддержку в свои маршрутизаторы.

Часть 1 | Часть 2

Просмотров новости: 3 881  <, , , >


-->