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

МЕТОДЫ РАСПРЕДЕЛЕНИЯ ЕМКОСТИ ТЕЛЕКОММУНИКАЦИОННЫХ КАНАЛОВ И ОБЕСПЕЧЕНИЯ КАЧЕСТВА СЕТЕВОГО ОБСЛУЖИВАНИЯ А.А. Букатов, О.В. Шаройко Южно-Российский региональный центр информатизации (ЮГИНФО) Южного федерального университета 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

paper

considers

for

also traffic

Besides

well

Engineering which

aim

individual methods

micro-flows known paper to

and

customers

and

aimed

provide

macro-flows

TrafficShaper,

also

presents

provide

to

large

adaptive

DiffServ methods

dynamic

reservation in boundary channels.

1

desired

applicable

IntServ, custom

customers

groups.

Quality

in

of

TCP/IP and

developed

bandwidth

The

Service networks.

MPLS

Traffic

by

authors

distribution

and

Введение Одной

из

важнейших

задач,

которые

должны

решаться

операторами

современных мультисервисных телекоммуникационных сетей, в число которых входят развитые научно-образовательные сети, является задача обеспечения определенного уровня качества сетевого обслуживания (QoS – Quality of Service) [1] как для агрегированной

совокупности

некоторых

сетевых

соединений,

так

и

для

индивидуальных сетевых соединений. Агрегирование соединений может выполняться на базе различных принципов, например, по принципу принадлежности абонента к определенной подсети, либо по принципу доступа к определенной службе (например, к службе IP-телефонии). Индивидуальным соединением мы называем двухточечное (unicast) или групповое (multicast) соединение, используемое при доступе абонента или группы абонентов к определенной услуге сети, например, к услуге проведения конкретной многоточечной видеоконференции. Требования к QoS для макропотоков (потоков информации, пересылаемых в рамках агрегированных сетевых соединений) подсетей, обычно выражаются в терминах

гарантированно

доступной

полосы

пропускания

сетевого

канала,

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

быть

выполнено,

например

средствами

рассматриваемого в гл. 1 настоящего обзора.

2

механизма

Traffic

shaper,

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

необходимо

в

момент

установления

соединения

выполнить

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

соединений

может

обеспечиваться

и

(распределения)

трафика

различных

агрегированных

соединений

3

путем

направления по

разным

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

распределения

и

резервирования

емкости

внешнего

канала

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

4

1. Механизм формирования заданной формы трафика Traffic Shaper Механизм Traffic Shaper [5], является одним из базовых программных механизмов маршрутизаторов, позволяющим ограничивать емкость в канале передачи данных,

доступную

тому

или

агрегированному

или

индивидуальному

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

может

быть

сконфигурирован

на

выходном

интерфейсе

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

5

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

6

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

7

реализуется с помощью трех компонент: планировщика пакетов, классификатора и обработчика запросов на резервирование. Планировщик пакетов отвечает за отправку пакетов в соответствии с их приоритетами. Для этого он может, например, использовать набор очередей, а также какие-либо другие механизмы. Задача классификатора – определить, какой уровень обслуживания требуется каждому пакету, поступающему в маршрутизатор. Обработчик запросов на резервирование принимает решение о возможности или не возможности удовлетворения того или иного запроса на резервирование и, в случае, если резервирование возможно, выполняет необходимые действия. Для передачи запросов на резервирование в 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, поддерживающей работу с информационными потоками с точностью до микропотоков.

8

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

существующих

сетевых

приложений

необходимость

таких

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

9

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

10

3. Архитектура Differentiated Services (DiffServ) Differentiated Services (DiffServ) [15-16] – это масштабируемая архитектура, предназначенная для организации дифференцированного обслуживания нескольких агрегированных информационных потоков (макропотоков). Дифференцированный уровень обслуживания может задаваться как в терминах некоторых количественных параметров (пропускная способность, допустимые величины задержек и потерь пакетов), так и в терминах относительных приоритетов одних служб по отношению к другим. При разработке архитектуры DiffServ учитывались и были удовлетворены следующие требования: 

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



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



архитектура должна обеспечивать работу существующих приложений без необходимости

изменения

программных

интерфейсов

или

программного

обеспечения конечных узлов; 

функции пересылки пакетов должны быть отделены от функций классификации сетевого трафика;



архитектура

должна

работать

без

какого-либо

специального

сигнального

протокола между промежуточными узлами; 

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

11



архитектура не должна требовать ведения на промежуточных устройствах сети какой либо информации о состояниях потоков или клиентов;



на магистрали сети должны применяться агрегированные классификаторы пакетов;



определение класса пакета на магистральных участках сети должно быть простой и «недорогой» операцией;



архитектура должна поддерживать «разумную» совместную работу с не DiffServсовместимыми узлами;



должна поддерживаться возможность постепенного внедрения архитектуры в существующих сетях. Архитектура DiffServ предполагает существование соседствующих DiffServ-

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

ставится

в

соответствие

номер

некоторого

класса

обслуживания,

реализованного в данном DiffServ-домене. Такой номер класса обслуживания называется DiffServ CodePoint (DSCP). Выбранное значение DSCP записывается в заголовок пакета, для чего используются 6 бит поля DS, которое входит в поле TOS пакетов IPv4 или в поле TrafficClass для IPv6. Это позволяет иметь в DiffServ-домене до 64-х различных классов обслуживания (для IPv4), хотя следует отметить, что в настоящее время стандартизировано лишь несколько значений DSCP. Для каждого класса обслуживания администратор DiffServ-домена может установить набор требований к параметрам, которым должен соответствовать процесс поступления извне в DiffServ-домен потока информации, обрабатываемой доменом с данным классом обслуживания. После того, как информация классифицирована и для

12

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

потоков

поступающих

в

DiffServ-домен

в

соответствие

с

требованиями, устанавливаемыми для выбранных классов обслуживания. При этом, например, часть пакетов может быть помещена в очередь или даже отброшена, если информация поступает быстрее, чем это разрешено для данного класса обслуживания. Такая процедура необходима, так как почти всегда, DiffServ-домен может обеспечить передачу потока информации в соответствии с некоторым классом обслуживания, только если при поступлении этот поток также соответствует некоторому набору параметров. Например, DiffServ-домен может гарантировать передачу информации с заданной задержкой только при условии, что интенсивность поступления информации не будет превышать некоторое пороговое значение, так как, в противном случае ухудшатся параметры пересылки пакетов всех информационных потоков, а не только того, интенсивность которого превысила пороговое значение. Внутренние маршрутизаторы DiffServ-домена обрабатывают значение DSCP, записанное в поле DS заголовка пакета, и, в соответствии с его конкретным значением, пересылают пакет следующему маршрутизатору, обеспечивая при этом соблюдение того или иного набора характеристик. Набор таких характеристик, обеспечиваемых на участке передачи между двумя соседними маршрутизаторами, называется Per-Hop Behavior (PHB). В архитектуре DiffServ PHB являются минимальными строительными блоками, из которых строятся различные классы обслуживания, реализуемые в DiffServ-домене. Конкретные механизмы, которые могут быть использованы для создания различных PHB, могут отличаться в маршрутизаторах разных моделей или производителей. Как правило, PHB настраиваются на основе таких низкоуровневых механизмов, как, например, очереди с приоритетами или очереди с весами. Архитектура DiffServ, как можно видеть, действительно позволяет организовать внутри DiffServ-домена как бы несколько виртуальных служб передачи информации, которые будут выполнять пересылку потоков данных, обеспечивая при этом максимально возможное соответствие параметров передачи соответствующим классам обслуживания (но не гарантируя полного соответствия). Надо отметить, что в DiffServ не предусматриваются каких-либо механизмов уведомления сетевых устройств со стороны приложений о том, сколько ресурсов им требуется или какое количество

13

потоков они планируют пересылать. В этом плане архитектура DiffServ соответствует традиционной архитектуре сети Интернет, когда на сетевых устройствах не запоминается информация об активных потоках, а сеть в целом является сетью без состояния. При этом в сетевых устройствах хранятся только правила обработки пакетов, а в каждом пакете содержится вся информация, необходимая для его доставки получателю. Корректная передача пакетов обеспечивается за счет того, что все промежуточные устройства выполняют идентичный алгоритм обработки пакетов. Следует особо отметить хорошую масштабируемость архитектуры DiffServ. Действительно, относительно «дорогие» операции по классификации

трафика

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

практически

может

быть

использована

лишь

для

агрегированных

макропотоков, препятствием применения ее для обслуживания микропотоков является относительно

небольшое

число

классов

обслуживания,

которые

могут

быть

реализованы в DiffServ-домене. Во-вторых, эта служба не гарантирует для обслуживаемых точного выполнения установленных для этих потоков требований к параметрам QoS. Фактически вместо резервирования сетевых ресурсов для каждого агрегированного

потока

выполняется

попытка

обеспечить

относительное

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

14

4.

Механизмы

управления

распределением

телекоммуникационных

ресурсов в технологии MPLS Идеология, положенная в основу технологии многопротокольной коммутации меток – MultiProtocol Label Switching (MPLS) [17], отчасти напоминает механизмы, применяемые в службе DiffServ. Пограничные маршрутизаторы MPLS сети разбивают все множество поступающих в сеть пакетов на классы эквивалентной обработки – Forwarding Equivalence Class (FEC). После этого, к каждому пакету приписывается внешняя, не входящая в состав заголовка IP-пакета, а предшествующая ему, метка, обозначающая выбранный для пакета FEC и пакет пересылается далее. Все внутренние маршрутизаторы, выполняя обработку пакета, принимают решения исключительно на основе анализа данной метки, а интерпретация заголовков пакетов не выполняется. При выходе пакета из MPLS сети метка снимается и пакет в том же виде, в котором он поступил в сеть, передается далее. Легко видеть, что имеются некоторые общие черты в принципах, используемых в MPLS и в DiffServ. Однако, если в DiffServ значение DSCP, определяемое на границе сети, используется только для выбора того или иного класса обслуживания, а для выбора маршрута передачи пакетов применяется стандартная процедура маршрутизации, то в технологии MPLS метка целиком и полностью определяет то, как будет пересылаться пакет через сеть. Из этого, очевидно, следует,

что

возможности

MPLS

по

управлению

распределением

телекоммуникационных ресурсов не уже, чем возможности DiffServ. Более того, в MPLS можно направлять различные типы информационных потоков по различным путям

так,

чтобы

характеристики

используемых

каналов

наиболее

точно

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

15

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

дает

новые

возможности

по

организации

и

использованию

альтернативных маршрутов для передачи информации через сеть. Для этого применяется технология, называемая Traffic Engineering (TE) [18-20]. Задача TE состоит в определении маршрутов потоков трафика через сеть, т.е. для каждого потока требуется указать точную последовательность промежуточных маршрутизаторов и их интерфейсов на пути между входной и выходной точками потока. При этом все ресурсы сети должны быть загружены, по возможности, наиболее сбалансировано. Последнее условие может быть формализовано разными способами. Например, максимальный коэффициент использования ресурса по всем ресурсам сети должен быть минимален, чтобы трафику был нанесен как можно меньший ущерб. Именно так формулируется задача TE в RFC 2702 [19]. Другим способом постановки задачи TE стал поиск такого набора путей, при которых все значения коэффициентов использования ресурсов не будут превышать некоторый заданный порог. Подобный подход более прост в реализации, так как связан с перебором меньшего количества вариантов, поэтому он чаще применяется на практике. Возможен также и способ нахождения оптимального решения для набора потоков с использованием внешней, по отношению к сети, системы в автономном режиме. Это может быть достаточно сложная система, которая включает подсистему имитационного моделирования, способную учесть не только средние интенсивности потоков, но и их пульсации, и оценить не только загрузку ресурсов, но и

16

результирующие параметры, с которыми будет передаваться информация – задержки, потери и т.п. Для решения задачи TE технология MPLS использует расширения протоколов маршрутизации, работающих на основе алгоритма состояния связей. В настоящее время такие расширения стандартизованы для протоколов OSPF и IS IS. В отличие от традиционной IP маршрутизации в технологии MPLS TE информация о найденном рациональном пути используется полностью – запоминается не только первый транзитный узел, но и все остальные промежуточные узлы пути вместе с начальным и конечным, т.е. фактически выполняется маршрутизация от источника. Поэтому достаточно, чтобы поиском путей занимались только пограничные маршрутизаторы сети, а внутренние – лишь поставляли им информацию о текущем состоянии сети, которая необходима для принятия решений. Такой подход, применяемый не только в MPLS, но и в других технологиях (например, в протоколе PNNI ATM), обладает несколькими преимуществами по сравнению с распределенной моделью поиска пути, лежащей в основе стандартных протоколов маршрутизации IP. Во-первых, он позволяет использовать «внешние» решения, когда пути находятся какой-либо

системой

оптимизации

сети

в

автономном

режиме,

а

потом

прокладываются в сети. Во-вторых, каждый из пограничных маршрутизаторов может работать по собственной версии алгоритма, в то время как при распределенном поиске на всех маршрутизаторов необходим идентичный алгоритм, что усложняет построение сети с оборудованием разных производителей. А, в-третьих, такой подход разгружает внутренние маршрутизаторы от работы по поиску путей. После нахождения пути, независимо от того, найден он был пограничным маршрутизатором или внешней системой, его необходимо установить. Для этого в MPLS TE используется специальный протокол сигнализации, который умеет распространять по сети информацию о явном (explicit) маршруте. Сегодня в MPLS TE определено два таких протокола: RSVP с расширениями и CR-LDP . Сообщения этих протоколов передаются от одного узла сети к другому в соответствии с данными об IPадресах маршрута. MPLS поддерживает два типа явных путей: строгий (strict), который определяет все промежуточные узлы, и свободный (loose), когда в сообщении протокола сигнализации задается только часть промежуточных узлов, а остальные

17

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

Каждый

маршрутизатор,

получив

такое

сообщение,

вычитает

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

можно

видеть,

MPLS

предоставляет

достаточно

богатый

набор

возможностей для управления распределением телекоммуникационных ресурсов. Однако, в то же время, MPLS, как таковая, не является технологией, предназначенной для решения именно данной задачи. MPLS – это, прежде всего, транспортная технология, которая, тем не менее, наделена хорошими средствами управления распределением

телекоммуникационных

ресурсов.

Поэтому,

для

управления

распределением ресурсов MPLS должна применяться совместно с уже описанными выше технологиями IntServ и DiffServ. В этом случае IntServ и DiffServ будут выступать

в

роли

интерфейсов,

с

помощью

которых

будут

определяться

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

18

5. Метод адаптивного динамического распределения и резервирования емкости пограничных каналов сети Рассмотренные

выше

методы

обеспечения

предоставляют

QoS

либо

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

сети

[22].

Указанный

метод

обеспечивает

резервирование

емкости

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

контролем

использования

этой

емкости

и

выполнением

динамического распределения свободной емкости канала между агрегированными потоками трафика сетей подразделений ЮФУ в соответствии с некоторой политикой распределения и текущим уровнем активности агрегированных потоков. Метод основан

на

предположении,

что

пограничный

канал

региональной

научно-

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

обслуживания

высокоприоритетных

микро

и

макропотоков,

так

и

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

19

Метод основан на использовании специальной системы учета интенсивности информационных потоков, проходящих через пограничные каналы [22], специальных демонов учета активных сетевых соединений приоритетных служб, и динамическом перераспределении емкости внешнего канала между микропотоками доступа к приоритетным службам и макропотоками трафика подсетей. Отметим, что изначально рассматриваемые средства предназначались для резервирования канала для служб доступа к центру высокопроизводительных вычислений (ЦВВ). В число этих служб входит служба интерактивного терминального доступа. Трафик микропотоков этой службы имеет ярко выраженный пульсирующий характер. Поэтому было принято решение о целесообразности резервирования емкости канала

не

для

однонаправленных

каждого

микропотока

микропотоков.

этой

Требуемая

службы, полоса

а

для

совокупности

пропускания

для

такого

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

динамической

установки

соответствующих ограничений на пограничном маршрутизаторе сети. К настоящему времени выполнена экспериментальная реализация рассмотренных средств [23] и проводится их опытная эксплуатация в телекоммуникационной сети ЮФУ.

20

Заключение В

настоящем

обеспечивающих

обзоре

рассмотрен

распределение

емкости

представительный

ряд

телекоммуникационных

методов,

каналов

и

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

динамического

занимающимися

созданием

резервирования

будут

и

корпоративных

развитием

телекоммуникационных сетей.

21

полезными и

специалистам, региональных

Литература

1. Shenker S., Partridge C., Guerin R., Specification of Guaranteed Quality of Service // RFC2212, September 1997, http://tools.ietf.org/html/rfc2212 2. Олифер В.Г., Олифер Н.А., Компьютерные сети. Принципы, технологии, протоколы, СПб: Питер, 2001. 3. McDysan, D., Sphon, D. ATM – Theory and Application, McGraw Hill, 1995. 4. Minoli, D., Vitella, D. ATM & Cell Relay Service for Corporate Environments, McGrawHill, 1994. 5. Traffic shaping // http://en.wikipedia.org/wiki/Traffic_shaping. 6. Braden R., Clark D., Shenker S. Integrated Services in the Internet Architecture: an Overview, RFC1633, June 1994, http://tools.ietf.org/html/rfc1633. 7. Clark D., Shenker S., Zhang L.Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms // Proc. SIGCOMM '92, Baltimore, MD, 1992. 8. Floyd S. Issues in Flexible Resource Management for Datagram Networks // Proceedings of the 3rd Workshop on Very High Speed Networks, Maryland, 1992. 9. Jamin S., Shenker S., Zhang L., Clark D. An Admission Control Algorithm for Predictive Real-Time Service // Proc. Third International Workshop on Network and Operating System Support for Digital Audio and Video, San Diego, CA, 1992. 10. Shenker S., Clark D., Zhang L. A Scheduling Service Model and a Scheduling Architecture for an Integrated Services Packet Network // ACM/IEEE Trans. on Networking, 1993. 11. Shenker S., Clark D., L. Zhang L. A Service Model for the Integrated Services Internet, 1993. 12. Partridge C. A Proposed Flow Specification, RFC1363, July 1992, http://tools.ietf.org/html/rfc1363 13. Zhang L., Deering S., Estrin D., Shenker S., Zappala D. RSVP: A New Resource ReSerVation Protocol // IEEE Network, 1993. 14. Wroclawski J. Specification of the Controlled-Load Network Element Service, RFC2211, September 1997, http://tools.ietf.org/html/rfc2211

22

15. Nichols K., Blake S., Baker F., Black D. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC2474, December 1998, http://tools.ietf.org/html/rfc2474 16. Blake S., Black D., Carlson M., Davies E., Wang Z., Weiss W. An Architecture for Differentiated Services, RFC2475, December 1998, http://tools.ietf.org/html/rfc2475 17. Rosen E., Viswanathan A., Callon R. Multiprotocol Label Switching Architecture, RFC3031, January 2001, http://tools.ietf.org/html/rfc3031 18. Олифер В., Олифер Н., Искусство оптимизации трафика // LAN, №12, 2001 19. Awduche D., Malcolm J., Agogbua J., O'Dell M., McManus J. Requirements for Traffic Engineering Over MPLS, RFC2702, September 1999, http://tools.ietf.org/html/rfc2702 20. Lakshman U., Lobo L. MPLS Configuration on Cisco IOS Software, Cisco Press, 2005. 21. Букатов А.А., Шаройко О.В. Методы и средства резервирования емкости каналов для служб удаленного доступа к вычислительным ресурсам регионального центра высокопроизводительных вычислений // Известия вузов. Северокавказский регион. Технические науки, 2004, № 2, с. 3-6. 22. Березовский А.Н., Букатов А.А.,. Шаройко О.В. Разработка модульной системы сбора статистической информации о работе телекоммуникационной сети // Материалы Международной научно-технической конференции «Искусственный интеллект. Интеллектуальные и многопроцессорные системы», Украина, Крым: изд. ТРТУ, 2004, с. 311-313. 23. Шаройко О.В., Березовский А.Н., Букатов А.А. Комплекс программных средств TrafficPolicier

для

управления

распределением

пропускной

способности

телекоммуникационных сетей между потребителями (Версия 2.0) // Свидетельство об официальной регистрации программы для ЭВМ № 2007615025 от 4.12.2007 г., Роспатент, 2007.

23