WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 |
МЕТОДЫ РАСПРЕДЕЛЕНИЯ ЕМКОСТИ ТЕЛЕКОММУНИКАЦИОННЫХ КАНАЛОВ И ОБЕСПЕЧЕНИЯ КАЧЕСТВА СЕТЕВОГО ОБСЛУЖИВАНИЯ А.А. Букатов, О.В. Шаройко Южно-Российский региональный центр информатизации (ЮГИНФО) Южного федерального университета 344090, г. Ростов-на-Дону, пр. Стачки, д. 200/1, корп. 2 Аннотация. Рассматриваются методы распределения емкости телекоммуникационных каналов между индивидуальными абонентами или абонентскими сетями, совместно использующими эти каналы для доступа к внешним сетям, а также методы обеспечения качества сетевого обслуживания (QoS) для микропотоков (индивидуальных сетевых соединений) и макропотоков (агрегированных сетевых соединений), применимые на уровне IP стека протоколов TCP/IP. Наряду с широко известными методами, технологиями и протоколами, такими как Traffic Shaper, служба IntServ (протокол RSVP), служба DiffServ, протокол MPLS, рассматриваются оригинальные методы обеспечения адаптивного динамического распределения емкости пограничных каналов и резервирования их емкости для служб доступа к определенным ресурсам сети.

Annotation. The paper presents an overview of various techniques for bandwidth distribution among individual customers and large customers groups. The paper also considers methods aimed to provide desired Quality of Service for traffic micro-flows and macro-flows applicable in TCP/IP networks.

Besides well known TrafficShaper, IntServ, DiffServ and MPLS Traffic Engineering paper also presents custom methods developed by authors which aim to provide adaptive dynamic bandwidth distribution and reservation in boundary channels.

1 Введение Одной из важнейших задач, которые должны решаться операторами современных мультисервисных телекоммуникационных сетей, в число которых входят развитые научно-образовательные сети, является задача обеспечения определенного уровня качества сетевого обслуживания (QoS – Quality of Service) [1] как для агрегированной совокупности некоторых сетевых соединений, так и для индивидуальных сетевых соединений. Агрегирование соединений может выполняться на базе различных принципов, например, по принципу принадлежности абонента к определенной подсети, либо по принципу доступа к определенной службе (например, к службе IP-телефонии). Индивидуальным соединением мы называем двухточечное (unicast) или групповое (multicast) соединение, используемое при доступе абонента или группы абонентов к определенной услуге сети, например, к услуге проведения конкретной многоточечной видеоконференции.

Требования к QoS для макропотоков (потоков информации, пересылаемых в рамках агрегированных сетевых соединений) подсетей, обычно выражаются в терминах гарантированно доступной полосы пропускания сетевого канала, используемого для обеспечения доступа «из конца в конец» абонентов подсети к интересующим их сетевым ресурсам. При этом на практике такое требование обычно вырождается в требование обеспечения соответствующей полосы пропускания канала лишь до определенной точки сети («последняя миля», «последняя миля» + внешний канал до некоторой точки обмена трафиком (IX – Internet eXcange) между сетями основных сетевых операторов, например до междугородней телефонной станции Москвы М9). Дополнительно следует отметить, что методом реализации такого требования зачастую является «жесткое» распределение емкости внешнего канала между абонентскими подсетями, при котором временно неиспользуемая емкость канала, выделенная некоторой подсети, не может быть предоставлена другой подсети, временно испытывающей дефицит емкости внешнего канала. Такое распределение может быть выполнено, например средствами механизма Traffic shaper, рассматриваемого в гл. 1 настоящего обзора.

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

Требования к QoS для макропотоков сетевых служб и для микропотоков (потоков информации, пересылаемых в рамках индивидуального сетевого соединения) обычно формулируются лишь для соединений сетевых служб, предполагающих обмен информацией в реальном масштабе времени. К такого рода сетевым службам относятся, например, служба IP-телефонии, служба проведения видеоконференций а также службы интерактивного удаленного доступа к уникальному оборудованию, такому как центры высокопроизводительных вычислений либо физические установки различного назначения (ускорители, астрофизические обсерватории и пр. Обычно такие требования формулируются в терминах максимально допустимых значений задержки пакетов, вариации задержек и пр., но могут формулироваться взаимной приоритетности сетевых служб. Для микропотоков индивидуальных соединений требования QoS могут также формулироваться в терминах гарантированно доступной полосы пропускания канала между конечными точками соединения. Поскольку индивидуальные соединения существуют лишь между моментами установления и разрыва соединений, для предоставления этому соединению гарантированной полосы пропускания необходимо в момент установления соединения выполнить резервирование требуемой полосы пропускания, а в момент разрыва соединения – отменить резервирование. Такие возможности предоставляют рассматриваемые в главе 2 служба IntServ и протокол RSVP. Хотя такое резервирование и выполняется динамически, на протяжении существования соединения это резервирование является «жестким», что не позволяет выделить временно неиспользуемую зарезервированную емкость другим соединениям, испытывающим временный дефицит емкости канала.



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

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

В заключительной части введения отметим, что в рамках настоящего обзора рассматриваются лишь в той или иной мере универсальные средства обеспечения QoS, реализованные на уровне IP стека протоколов TCP/IP. При этом нами не рассматривались как средства обеспечения QoS, предоставляемые различными технологиями физического уровня (от относительно простых средств технологии Frame Relay [2] до развитых средств технологии ATM [3-4]), так и, например, средства резервирования каналов IP-телефонии, реализованные в оборудовании конкретных производителей. Указанные рамки выбраны в связи с тем, что, во-первых, физический уровень сетей различных операторов связи может быть построен на основе различных технологий, и, во-вторых, рассмотрение средств, ориентированных на обеспечение QoS конкретных служб, повлекло бы превышение объема обзора.

1. Механизм формирования заданной формы трафика Traffic Shaper Механизм Traffic Shaper [5], является одним из базовых программных механизмов маршрутизаторов, позволяющим ограничивать емкость в канале передачи данных, доступную тому или агрегированному или индивидуальному информационному потоку, определяемому списком контроля доступа ACL (Access Control List). Это может быть использовано (и использовалось до появления более развитых средств) как для постоянного распределения, так и для «временного резервирования» (например, для проведения видеоконференции) емкости каналов путем ручной настройки маршрутизаторов на всем пути передачи информационного потока.

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

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

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

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

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

Еще один недостаток TrafficShaper'а связан с тем, что каждую очередь необходимо индивидуально настраивать на каждом маршрутизаторе. В большой распределенной сети это может создать существенные проблемы, особенно, при большом числе абонентов, для которых необходимо установить ограничения.

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

2. Архитектура Integrated Services (IntServ) и протокол RSVP Архитектура Integrated Services (IntServ) [6] и реализующая эту архитектуру интегрированная служба включает ряд механизмов, которые обеспечивают требуемый уровень QoS при передаче пакетов определенных двухточечных или групповых сетевых соединений (микропотоков) «из конца в конец», т.е. для всего пути, по которому передается информация. Архитектура IntServ была разработана в результате реализации предложений [7-12], разработанных на основе выводов из проведенных в начале 1990 годов экспериментов по многоадресной трансляции через Интернет заседаний комитетов Internet Engineering Task Force (IETF). Главный вывод состоял в том, что приложения реального времени зачастую не могут хорошо работать через Интернет из-за меняющихся задержек передачи пакетов данных при прохождении ими очередей на коммуникационных устройствах и потерь пакетов при перегрузках этих устройств. Был также сделан вывод о необходимости разработки механизмов, которые будут в реальном времени обеспечивать заданные уровни параметров передачи пакетов для всего маршрута, по которому передается информация, в том числе – путем резервирования требуемой для этого полосы пропускания каналов.





В разработанных предложениях под термином Integrated Services понимается модель работы сети Интернет, включающая традиционную, так называемую «besteffort», службу доставки информации, службу, обеспечивающую пересылку пакетов с гарантированным соблюдением определенных параметров передачи [1], и службу доставки в режиме управляемого распределения пропускной способности каналов [14].

Архитектура IntServ является надстройкой над стандартной моделью передачи данных в Интернет, расширяющей ее новой функциональностью. Она позволяет сочетать службы передачи трафика реального времени и службу управляемого распределения канальных ресурсов совместно с обычным способом передачи информации. Для обеспечения гарантированных параметров передачи пакетов в IntServ используется механизм предварительного резервирования ресурсов на маршрутизаторах. Такой подход требует хранения на маршрутизаторах некоторой информации об активных потоках, что существенно отличает модель IntServ от традиционной схемы работы сети Интернет. Управление трафиком в IntServ реализуется с помощью трех компонент: планировщика пакетов, классификатора и обработчика запросов на резервирование. Планировщик пакетов отвечает за отправку пакетов в соответствии с их приоритетами. Для этого он может, например, использовать набор очередей, а также какие-либо другие механизмы. Задача классификатора – определить, какой уровень обслуживания требуется каждому пакету, поступающему в маршрутизатор. Обработчик запросов на резервирование принимает решение о возможности или не возможности удовлетворения того или иного запроса на резервирование и, в случае, если резервирование возможно, выполняет необходимые действия.

Для передачи запросов на резервирование в IntServ применяется специальный протокол RSVP (ReSerVation Protocol) [13]. В соответствии с этим протоколом, отправители информации рассылают специальные сообщения RSVP Path по уникальному (unicast) или групповому (multicast) адресу. Маршрутизаторы, в которых реализована поддержка протокола RSVP, получая такие сообщения, запоминают информацию о пути прохождения RSVP трафика. Получатели информации, желающие принимать данные с теми или иными параметрами передачи, отправляют сообщение RSVP Resv. Это сообщение пересылается RSVP маршрутизаторами в обратном, по отношению к RSVP Path, направлении. Получив такое сообщение, каждый маршрутизатор, поддерживающий RSVP, пытается выполнить резервирование и пересылает пакет следующему RSVP маршрутизатору на пути к источнику информации. Резервирование считается успешным, если всем RSVP маршрутизаторам между отправителем и получателем информации удалось зарезервировать необходимые ресурсы.

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

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

Отметим также, что IntServ не предусматривает каких либо средств обеспечения QoS для макропотоков, что существенно ограничивает область применения IntServ.

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

Pages:     || 2 | 3 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.