Стандарты QoS в IP-сетях

Фильтрация маршрутных объявлений

Дляконтроля достижимости узлов и сетей можно, наряду с фильтрацией пользовательско­ го трафика, ограничить распространение объявлений протоколов маршрутизации. Такая

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

Пусть, например, маршрутизаторы Cisco должны ограничить распространение маршрут­ ных объявлений о какой-нибудь сети. Для этого нужно включить описание данной сети в стандартный список доступа, а затем применить к интерфейсу специальную команду с ключевым словом d i s t r i b u t e - l i s t (вместо accessgroup, как в случае фильтрации пользовательского трафика).

Например, если администратор не хочет, чтобы информация о внутренних сетях - 194.12.34.0/24 и 132.7.0.0/16 предприятия распространялась по внешним сетям, ему до­ статочно написать следующий стандартный список доступа:

Послеэтого достаточно применить его к интерфейсу с помощью команды

Стандарты QoS в IP-сетях

Технологии стека TCP/IP были разработаны для эластичного трафика, который доста­ точно терпим к задержкам и вариациям задержек пакетов. Поэтому основное внимание разработчиков протоколов TCP/IP было сосредоточено на обеспечении надежной передачи трафика с помощью TCP Тем не менее для борьбы с перегрузками на медленных линиях доступав IP-маршрутизаторы со временем были встроены многие механизмы QoS, в том числемеханизмы приоритетных и взвешенных очередей, профилирования трафика и об­ ратной связи. Однако эти механизмы использовались каждым сетевым администратором по своему усмотрению, без какой-либо стройной системы. И только в середине 90-х годов начались работы по созданию стандартов QoS для IP-сетей, на основе которых можно было бы создать систему поддержки параметров QoS в масштабах составной сети и даже Интернета.

^результатебылиразработаныдве системы стандартов QoSдля 1Р~сетей:

2 система интегрированного обслуживания (Integrated Services, IntServ) ориентирована напредоставление гарантий QoS для потоков конечных пользователей (именно Поэтому

технологияintServ применяется восновном на периферии сети);

3 система дифференцированного обслуживания (Differentiated Services, DiffServ) делает то же самое для классов трафика, и следовательно, ее предпочтительнее использовать на

магистрали.

Под маркером в данном случае понимается некий абстрактный объект, носитель «порции» информации, используемый для построения эталонного потока. Генератор маркеров перио­ дически с постоянным интервалом w направляет очередной маркер в «ведро» с ограничен­ ным объемом Ъбайт. Все маркеры имеют одинаковый объем т байт, а генерация маркеров происходит так, что «ведро» заполняется со скоростью г бит/с. Нетрудно подсчитать, что

г= 8m/w. Эта скорость г и является максимальной средней скоростью для трафика пакетов,

аобъем ведра соответствует максимальному размеру пульсации потока пакетов. Если ведро заполняется маркерами «до краев» (то есть суммарный объем маркеров в ведре становится равным Ь)уто поступление маркеров временно прекращается. Фактически, ведро маркеров представляет собой счетчик, который наращивается на величину т каждые w секунд.

При применении алгоритма ведра маркеров профиль трафика определяется средней ско­ ростью г и объемом пульсации b.

Сравнение эталонного и реального потоков выполняет сервер —абстрактное устройство, которое имеет два входа. Вход 1 связан с очередью пакетов, а вход 2 - е ведром маркеров. Сервер также имеет выход, на который он передает пакеты из входной очереди пакетов. Вход 1 сервера моделирует входной интерфейс маршрутизатора, а выход —выходной интерфейс.

Пакет из входной очереди продвигается сервером на выхрдтолько втом случае, если кмоменту его поступления на сервер «ведро» заполнено маркерами до уровня не ниже М байт, где М —

объем пакета.

При продвижении пакета из ведра удаляются маркеры общим объемом в Мбайт (с точно­ стью до размера одного маркера, то есть до т байт).

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

□Если алгоритм ведра маркеров применяется для сглаживания трафика, то пакет просто задерживается в очереди на некоторое дополнительное время, ожидая поступления

введро нужного числа маркеров. Таким образом, даже если в результате пульсации

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

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

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

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

Алгоритм ведра маркеров допускает пульсацию трафика в определенных пределах. Пусть пропускная способность выходного интерфейса, который моделируется выходом сервера, равна R. Это значит, что сервер не может передавать данные на выход со скоростью, пре­ вышающей R бит/с. Можно показать, что на любом интервале времени t средняя скорость исходящего с сервера потока равна минимуму из двух величин: R и г + b/t. При больших значениях t скорость выходного потока стремится к г —это и говорит о том, что алгоритм обеспечивает желаемую среднюю скорость. В то же время в течение небольшого време­ ни t пакеты могут выходить из сервера со скоростью, большей г. Если г + b/t < Я, то они

Резервирование в модели IntServ выполняется с помощью уже упоминавшегося прото­ кола резервирования ресурсов (RSVP). Это сигнальный протокол, во многом подобный

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

Далее описана процедура резервирования необходимых ресурсов сети с помощью про­ токола RSVP, а в табл. 18.1 сведены воедино все упоминаемые в этом описании типы сообщений.

1.Источник данных (компьютер С1 на рис. 18.3) посылает получателям по уникальному или групповому (как на рисунке) адресу специальное РАТН-сообщение, в котором ука­ зывает рекомендуемые параметры для качественного приема своего трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки. Эти па­ раметры составляют спецификацию трафика источника. РАТН-сообщение передается маршрутизаторами сети в направлении ко всем указанным в групповом адресе получате­ лям. В качестве параметров трафика применяются параметры алгоритма ведра маркеров, то есть средняя скорость и глубина ведра. Кроме того, дополнительно могут быть заданы максимально допустимая скорость и предельные размеры пакетов потока.

2.Каждый маршрутизатор, поддерживающий протокол RSVP, получив РАТН-сообщение, фиксирует «состояние пути», которое включает предыдущий адрес источника РАТНсообщения, то есть последний по времени шаг в обратном направлении (ведущий к ис­ точнику). Это необходимо для того, чтобы ответ приемника прошел по тому же пути, что и РАТН-сообщение.

3.После получения PATH-сообщения приемник отправляет в обратном направлении маршрутизатору, от которого он получил это сообщение, запрос на резервирование ресурсов, то есть RESV-сообщение. На рис. 18.3 показано два приемника, компьютеры С2 и СЗ. В дополнение к спецификациям трафика источника С1 (которые содержат параметры для качественного приема его трафика: верхние и нижние границы про­ пускной способности, задержки и вариации задержки) RESV-сообщение дополнительно включает спецификацию запроса приемника, в которой указываются требуемые при­ емнику параметры качества обслуживания, и спецификацию фильтра, которая опреде­ ляет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта). Вместе спецификации запроса и фильтра представляют собой дескриптор потока, для которого выполняется резервирование. Запрашиваемые параметры QoS в спецификации запроса могут отличаться от ука­ занных в спецификации трафика. Например, если приемник решает принимать не все посылаемые источником пакеты, а только их часть (что указывается в спецификации фильтра), то ему нужна, соответственно, меньшая пропускная способность.

4.Каждый маршрутизатор, лоддерживающий протокол RSVP вдоль восходящего пути,

получив RESV-сообщение, проверяет, во-первых, имеются ли у маршрутизатора ре­ сурсы, необходимые для поддержания запрашиваемого уровня QoS, а во-вторых, имеет ли пользователь право на резервирование ресурсов. Если запрос не может быть удовлетворен (из-за недостатка ресурсов или ошибки авторизации), маршрутизатор возвращает сообщение об ошибке отправителю. Если запрос принимается, то маршру­ тизатор посылает RESV-сообщение далее вдоль маршрута следующему маршрутизатору,

а данные о требуемом уровне QoS передаются тем механизмам маршрутизатора, которые ответственны за управление трафиком.

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

ивычитает их из счетчиков соответствующих свободных ресурсов.

6.Когда последний в обратном направлении маршрутизатор получает RESV-сообщение

ипринимает запрос, то он посылает подтверждающее сообщение узлу-источнику. При групповом резервировании учитывается тот факт, что в точках разветвления дерева до­ ставки несколько резервируемых потоков сливаются в один. Так, в маршрутизаторе R1 в рассматриваемом примере сливаются RESV-сообщения от приемников С2 и СЗ. Если для всех резервируемых потоков запрашивается одинаковая пропускная способность, то она требуется и для общего потока, а если запрашиваются различные величины про­ пускной способности, то для общего потока выбирается максимальная.

7.После установления состояния резервирования в сети источник начинает отправлять данные, которые обслуживаются на всем пути к приемнику (приемникам) с заданным качеством обслуживания.

Таблица 18.1. Таблица сообщений протокола резервирования ресурсов (RSVP)

Нужно подчеркнуть, что описанная схема обеспечивает резервирование только в одном направлении. Для того чтобы в рамках пользовательского сеанса данные передавались сза­ данным качеством обслуживания также и в обратном направлении, нужно, чтобы приемнйк и источник поменялись местами и выполнили RSVP-резервирование еще раз.

Для того чтобы параметры резервирования можно было применить затем к трафику дан­ ных, необходимо, чтобы RSVP-сообщения и пакеты данных следовали через сеть одним и тем жемаршрутом. Это можно обеспечить, если передавать RSVP-сообщения на основе

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

маршрутизации.

-

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

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

Дифференцированное обслуживание

Дифференцированное обслуживание (DiffServ) опирается на ту же обобщенную модель QoS, что и интегрированное обслуживание, однако в качестве объектов обслуживания рассматриваются не отдельные потоки, а классы трафика.

рішДОр,- j

Вотличие от потока в классах трафика пакеты не различаются в зависимости от их марш­ рутов; это отличие иллюстрирует рис. 18.4. Так, маршрутизатор R1 относит все потоки, требующие приоритетного обслуживания и втекающие в его интерфейс il, к одному классу, независимо от их дальнейшего маршрута. Маршрутизатор R2 оперирует уже другим составом приоритетного класса, так как в него вошли не все потоки интерфейса il маршрутизатора R1.

Обычнов сети DiffServ поддерживается дифференцированное обслуживание небольшого количество классов трафика,,например двух (чувствительного к задержкам и эластично­ го)или трех (к первым двум прибавляется класс, требующий гарантированной доставки пактов с определенным минимумом скорости трафика). Небольшое количество классов определяет масштабируемость этой модели, так как маршрутизаторы не должны запоми­ нать состояния каждого пользовательского потока. Высокая степень масштабирумости Diffserv обеспечивается также тем, что каждый маршрутизатор самостоятельно принимает решениео том, как он должен обслуживать тот или иной класс трафика, не согласуя свои

ныхклассов). Младший бит (из используемых шести) DS-байта обычно переносит признак IN - индикатор того, что пакет «вышел» из профиля трафика (аналогично признакам DE втехнологии Frame Relay и CPL в технологии ATM). Промежуточные два бита обычно описывают различные варианты обслуживания пакетов внутри одного класса трафика.

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

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

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

в соответствии с SLA, а во входной точке домена будет кондиционироваться в соответствии

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

Насегодняшний день в IETF разработано два стандарта пошагового продвижения пакетов для схемы РНВ, которые представляют два разных варианта обслуживания.

□Быстрое продвижение (Expedited Forwarding, EF) характеризуется значением кода 10111 и представляет собой высший уровень качества обслуживания, обеспечивая минимум задержек и вариаций задержек. Любой трафик, интенсивность которого пре­ вышает указанную в профиле, отбрасывается.

□Гарантированная доставка (Assured Forwarding, AF) характеризуется четырьмя класса­ ми трафика и тремя уровнями отбрасывания пакетов в каждом классе —всего получа­ ется 12 различных типов трафика. Каждому классу трафика выделяются определенные минимум пропускной способности и размер буфера для хранения его очереди. Трафик, параметры которого превышают указанные в профиле, доставляется с меньшей степе­ нью вероятности, чем трафик, удовлетворяющий условиям профиля. Это означает, что качество его обслуживания может быть понижено, но он не обязательно будет отброшен.

Наоснове этих пошаговых спецификаций и соответствующих соглашений об уровне об­ служивания (SLA) могут быть построены сервисы для конечных пользователей «из конца вконец» —это EF-сервис и AF-сервис соответственно.

Основное назначение EF-сервиса —обеспечение качества обслуживания, сопоставимого с качеством обслуживания выделенных каналов, поэтому этот сервис называется также

сервисом виртуальных выделенных каналов.

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

Четыре класса AF-сервиса ориентированы на гарантированную доставку, но без минимиза­ ции уровня задержек пакетов, как это оговорено для EF-сервиса. Гарантированная доставка выполняется в том случае, когда входная скорость трафика не превышает отведенной данному классу минимальной пропускной способности. Реализация классов AF-трафика хорошо сочетается с EF-сервисом —EF-трафик может обслуживаться по приоритетной схеме, но с ограничением интенсивности входного потока. Оставшаяся пропускная способ­ ность распределяется между классами AF-трафика в соответствии с алгоритмом взвешен­ ного обслуживания, который обеспечивает необходимую пропускную способность, но не минимизацию задержек. Реализация AF-сервиса предполагает (но не требует) взвешенного обслуживания для каждого класса с резервированной полосой пропускания, а также при­ менения обратной связи (в форме RED).

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

Рис. 18.6. Неопределенность уровня обслуживания в мрдели DiffServ

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

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

Несмотря на такое достаточно жесткое ограничение, интерфейсы маршрутизаторов сети оказываются под воздействием разной нагрузки. На рис. 18.6 для упрощения ситуации показаны только потоки, требующие особого обслуживания. Так, выходной интерфейс ill маршрутизатора R1 обслуживает два таких потока и нагружен на 40 %, в то время как выходной интерфейс І21 маршрутизатора R2 —только один из них, так как второй поток уходит через другой выходной интерфейс. Выходной же интерфейс І31 маршрутизатора $3 перегружен, обслуживая три таких потока, так что его коэффициент использования равен60 %. Учитывая факторы, влияющие на образование очередей (см. главу 7), мы знаем, чтокоэффициент использования является наиболее существенным фактором и значения в районе 50 % являются критическими. Поэтому в интерфейсе І31 возникают длинные очереди пакетов класса особого обслуживания, которые снижают качество такого обслу­ живания, так как приводят к длительным задержкам и их вариациям, а также потерям пакетов. Кроме того, страдает трафик класса обслуживания с максимальными усилиями, проходящий через этот интерфейс, так как ему достается только 40 %пропускной способ­ ности интерфейса.

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

Однако все эти меры не дают гарантии, что все интерфейсы всех маршрутизаторов сети будутработать в нужном диапазоне значений коэффициента использования, а следователь­ но, обеспечивать заданное качество обслуживания. Для того чтобы дать такие гарантии, необходимо «улучшить» модель DiffServ и применять методы инжиниринга трафика, то есть контролировать не классы, а потоки трафика, в данном случае агрегированные. Под агрегированным понимается поток, состоящий из пакетов одного класса, имеющих общую частьпути через сеть. Эта общая часть не обязательно включает полный путь от входного интерфейса одного из пограничных маршрутизаторов до выходного интерфейса другого пограничного маршрутизатора. Достаточно, чтобы пакеты проходили хотя бы два общих интерфейса, чтобы считать их агрегированным потоком, как, например, в случае потока, проходящего через интерфейсы ill и І22 (см. рис. 18.6).

Затем, зная путь прохождения каждого агрегированного потока через сеть, можно прове­ рить, имеются ли достаточные ресурсы вдоль пути следования каждого потока, например, не превышают ли коэффициенты использования интерфейсов заданного порога. Для этого нужно провести профилирование с учетом адресов назначения пакетов. Однако реали­ зация такого подхода в IP-сетях сталкивается с несколькими трудностями. Во-первых, в технологии Diffserv не предусмотрен сигнальный протокол, такой как, например, RSVP втехнологии IntServ. Это означает, что все проверки наличия ресурсов у маршрутизаторов для каждого агрегированного потока нужно выполнять в автономном режиме, вручную или с помощью какого-то специального программного обеспечения. Во-вторых, для проведения