Учебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы
 Скачать 22.28 Mb.
|
|
спецификацию фильтра, которая опреде ляет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта). Вместе спецификации запроса и фильтра представляют собой дескриптор потока, для которого выполняется резервирование. Запрашиваемые параметры QoS в спецификации запроса могут отличаться от ука занных в спецификации трафика. Например, если приемник решает принимать не все посылаемые источником пакеты, а только их часть (что указывается в спецификации фильтра), то ему нужна, соответственно, меньшая пропускная способность. 4. Каждый маршрутизатор, лоддерживающий протокол RSVP вдоль восходящего пути, получив RESV-сообщение, проверяет, во-первых, имеются ли у маршрутизатора ре сурсы, необходимые для поддержания запрашиваемого уровня QoS, а во-вторых, имеет ли пользователь право на резервирование ресурсов. Если запрос не может быть удовлетворен (из-за недостатка ресурсов или ошибки авторизации), маршрутизатор возвращает сообщение об ошибке отправителю. Если запрос принимается, то маршру тизатор посылает RESV-сообщение далее вдоль маршрута следующему маршрутизатору, 610 Глава 18. Дополнительные функции маршрутизаторов ІР-сетей а данные о требуемом уровне QoS передаются тем механизмам маршрутизатора, которые ответственны за управление трафиком. 5. Прием маршрутизатором запроса на резервирование ресурсов означает также передачу параметров QoS на обработку в соответствующие блоки маршрутизатора. Конкретный способ обработки параметров QoS маршрутизатором в протоколе RSVP не описывается, но обычно она заключается в том, что маршрутизатор проверяет наличие свободной про пускной способности и емкости памяти для нового резервирования. При положительном результате проверки маршрутизатор запоминает новые параметры резервирования и вычитает их из счетчиков соответствующих свободных ресурсов. 6. Когда последний в обратном направлении маршрутизатор получает RESV-сообщение и принимает запрос, то он посылает подтверждающее сообщение узлу-источнику. При групповом резервировании учитывается тот факт, что в точках разветвления дерева до ставки несколько резервируемых потоков сливаются в один. Так, в маршрутизаторе R1 в рассматриваемом примере сливаются RESV-сообщения от приемников С2 и СЗ. Если для всех резервируемых потоков запрашивается одинаковая пропускная способность, то она требуется и для общего потока, а если запрашиваются различные величины про пускной способности, то для общего потока выбирается максимальная. 7. После установления состояния резервирования в сети источник начинает отправлять данные, которые обслуживаются на всем пути к приемнику (приемникам) с заданным качеством обслуживания. Таблица 18.1. Таблица сообщений протокола резервирования ресурсов (RSVP) Типы сообщений Содержание сообщений РАТН-сообщение от ис точника к приемнику Спецификация трафика источника Спецификация трафика источника Рекомендуемые параметры для качественного приема своего трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки, параметры алгоритма ведра маркеров, то есть среднюю скорость и глубину ведра, дополнительно могут быть заданы максимально допусти мая скорость и предельные размеры пакетов потока Спецификация фильтра Определяет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта) Спецификация запроса приемника Требуемые приемнику параметры качества обслуживания Дескриптор потока Спецификация фильтра плюс спецификация запроса приемника RESV-сообщение — за прос на резервирование ресурсов Спецификация трафика источника плюс дескриптор потока Нужно подчеркнуть, что описанная схема обеспечивает резервирование только в одном направлении. Для того чтобы в рамках пользовательского сеанса данные передавались с за данным качеством обслуживания также и в обратном направлении, нужно, чтобы приемнйк и источник поменялись местами и выполнили RSVP-резервирование еще раз. Для того чтобы параметры резервирования можно было применить затем к трафику дан ных, необходимо, чтобы RSVP-сообщения и пакеты данных следовали через сеть одним и тем же маршрутом. Это можно обеспечить, если передавать RSVP-сообщения на основе Стандарты QoS в IP-сетях 611 тех же записей таблиц маршрутизации, которые применяются для пользовательского трафика. ВНИМАНИЕ------------------------------------------------------------------------------------------------------------------- Если для передачи RSVP-сообщений будет использоваться традиционная схема выбора маршрута в таблицах маршрутизации, то окажется упущенной возможность полноценного решения задач инжиниринга трафика, так как не все возможные маршруты будут задействованы для резервиро вания, а только кратчайший маршрут, выбранный в соответствии с некоторой метрикой протокола маршрутизации. - Резервирование можно отменить прямо или косвенно. Прямая отмена выполняется по инициативе источника или приемника с помощью соответствующих сообщений протокола RSVP. Неявная отмена происходит по тайм-ауту: состояние резервирования имеет срок жизни, как, например, и динамические записи в таблицах маршрутизации, и приемник по протоколу RSVP должен периодически подтверждать резервирование. Если же подтверж дающие сообщения перестают поступать, то резервирование отменяется по истечении его срока жизни. Такое резервирование называется мягким. Для протокола RSVP в настоящее время разработано большое количество расширений, которые делают его пригодным не только для работы в рамках архитектуры RSVP. Одними из наиболее важных являются расширения, относящиеся к инжинирингу трафика. Эти расширения применяются в технологии MPLS, рассматриваемой в главе 20. Дифференцированное обслуживание Дифференцированное обслуживание (DiffServ) опирается на ту же обобщенную модель QoS, что и интегрированное обслуживание, однако в качестве объектов обслуживания рассматриваются не отдельные потоки, а классы трафика. рішДОр,- j В отличие от потока в классах трафика пакеты не различаются в зависимости от их марш рутов; это отличие иллюстрирует рис. 18.4. Так, маршрутизатор R1 относит все потоки, требующие приоритетного обслуживания и втекающие в его интерфейс il, к одному классу, независимо от их дальнейшего маршрута. Маршрутизатор R2 оперирует уже другим составом приоритетного класса, так как в него вошли не все потоки интерфейса il маршрутизатора R1. Обычно в сети DiffServ поддерживается дифференцированное обслуживание небольшого количество классов трафика,, например двух (чувствительного к задержкам и эластично го) или трех (к первым двум прибавляется класс, требующий гарантированной доставки пактов с определенным минимумом скорости трафика). Небольшое количество классов определяет масштабируемость этой модели, так как маршрутизаторы не должны запоми нать состояния каждого пользовательского потока. Высокая степень масштабирумости Diffserv обеспечивается также тем, что каждый маршрутизатор самостоятельно принимает решение о том, как он должен обслуживать тот или иной класс трафика, не согласуя свои 612 Глава 18. Дополнительные функции маршрутизаторов ІР-сетей действия с другими маршрутизаторами. Такой подход назван независимым поведением маршрутизаторов (Per Hop Behavior, РНВ). Так как в модели DiffServ маршруты паке тов не отслеживаются, то здесь не используется сигнальный протокол резервирования ресурсов, подобный протоколу RSVP в модели IntServ. Вместо этого маршрутизаторы сети выполняют статическое резервирование ресурсов для каждого из поддерживаемых сетью классов. Рис. 18.4. В модели DiffServ объектами обслуживания являются классы трафика, а не потоки В качестве признака принадлежности IP-пакета к определенному классу в DiffServ исполь зуется метка, переносимая в поле приоритета 1Р-пакета (ToS-байт), которое с появлением стандартов DiffServ было переопределено и названо DS-байтом. Как показано на рис. 18.5, DS-байт переопределяет значения битов ToS-байта, определенных ранее в соответствую щих спецификациях (RFC 791, RFC 1122, RFC 1349). Биты: 0 1 2 3 4 5 6 7 Биты: 0 1 2 3 4 5 6 7 і і Байт типа DS-байт DSlCP ' І сервиса 1 1 протокола N IPv4 Код класса трафика —г Пока не испопьзуется Приоритет Тип сервиса к С------------------ N Т Т RFC 1122 RFC 1349 Этот бит должен быть нулевым Код класса дифференцированного обслуживания RFC 2474 Поле типа сервиса (TOS) RFC 791 Рис. 18.5. Соответствие битов DS-байта битам поля типа сервиса В настоящее время используются только старшие 6 битов DS-байта, причем только стар шие три из них требуются для определения класса трафика (что дает не более 8-ми различ- Стандарты QoS в IP-сетях 613 ных классов). Младший бит (из используемых шести) 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-сервиса — обеспечение качества обслуживания, сопоставимого с качеством обслуживания выделенных каналов, поэтому этот сервис называется также сервисом виртуальных выделенных каналов. 614 Глава 18. Дополнительные функции маршрутизаторов ІР-сетей Поскольку EF-сервис допускает полное вытеснение другого трафика (например, при его реализации с помощью приоритетной очереди), то его реализация должна включать не которые средства ограничения влияния EF-трафика на другие классы трафика, например, путем ограничения скорости EF-трафика на входе маршрутизатора по алгоритму ведра маркеров. Максимальная скорость EF-трафика и, возможно, величина пульсаций должны устанавливаться сетевым администратором. Четыре класса AF-сервиса ориентированы на гарантированную доставку, но без минимиза ции уровня задержек пакетов, как это оговорено для EF-сервиса. Гарантированная доставка выполняется в том случае, когда входная скорость трафика не превышает отведенной данному классу минимальной пропускной способности. Реализация классов AF-трафика хорошо сочетается с EF-сервисом — EF-трафик может обслуживаться по приоритетной схеме, но с ограничением интенсивности входного потока. Оставшаяся пропускная способ ность распределяется между классами AF-трафика в соответствии с алгоритмом взвешен ного обслуживания, который обеспечивает необходимую пропускную способность, но не минимизацию задержек. Реализация AF-сервиса предполагает (но не требует) взвешенного обслуживания для каждого класса с резервированной полосой пропускания, а также при менения обратной связи (в форме RED). Относительная простота определяет недостатки дифференцированного обслуживания. Главным недостатком является сложность предоставления количественных гарантий пользователям. Поясним это на примере сети, изображенной на рис. 18.6. Рис. 18.6. Неопределенность уровня обслуживания в мрдели DiffServ Обслуживание классов трафика подразумевает, что пограничные маршрутизаторы выпол няют профилирование трафика без учета адреса назначения пакетов. Обычно для вход ных интерфейсов пограничных маршрутизаторов задается некоторый порог допустимой нагрузки для трафика каждого класса. Например, пусть наша сеть поддерживает трафик двух классов, реализуя особое обслуживание и обслуживание с максимальными усилиями, Стандарты QoS в IP-сетях 615 причем порог для трафика с особым обслуживанием установлен в 20 % пропускной способ ности для каждого входного интерфейса каждого пограничного маршрутизатора. Кроме того, предположим для упрощения рассуждений, что все интерфейсы маршрутизаторов сети имеют одинаковую пропускную способность. Несмотря на такое достаточно жесткое ограничение, интерфейсы маршрутизаторов сети оказываются под воздействием разной нагрузки. На рис. 18.6 для упрощения ситуации показаны только потоки, требующие особого обслуживания. Так, выходной интерфейс ill маршрутизатора R1 обслуживает два таких потока и нагружен на 40 %, в то время как выходной интерфейс І21 маршрутизатора R2 — только один из них, так как второй поток уходит через другой выходной интерфейс. Выходной же интерфейс І31 маршрутизатора $3 перегружен, обслуживая три таких потока, так что его коэффициент использования равен 60 %. Учитывая факторы, влияющие на образование очередей (см. главу 7), мы знаем, что коэффициент использования является наиболее существенным фактором и значения в районе 50 % являются критическими. Поэтому в интерфейсе І31 возникают длинные очереди пакетов класса особого обслуживания, которые снижают качество такого обслу живания, так как приводят к длительным задержкам и их вариациям, а также потерям пакетов. Кроме того, страдает трафик класса обслуживания с максимальными усилиями, проходящий через этот интерфейс, так как ему достается только 40 % пропускной способ ности интерфейса. Мы несколько утрировали картину, так как обычно интерфейсы магистральных марш рутизаторов являются более скоростными, чем пограничных, так что их коэффициент использования оказывается ниже, чем сумма коэффициентов использования входных интерфейсов, как в нашем примере. Для того чтобы снизить вероятность перегрузки вну тренних интерфейсов магистральных маршрутизаторов и выходных интерфейсов погра ничных маршрутизаторов, можно также уменьшить допустимый порог нагрузки входных интерфейсов трафиком особого обслуживания, например, до 5 %. Однако все эти меры не дают гарантии, что все интерфейсы всех маршрутизаторов сети будут работать в нужном диапазоне значений коэффициента использования, а следователь но, обеспечивать заданное качество обслуживания. Для того чтобы дать такие гарантии, необходимо «улучшить» модель DiffServ и применять методы инжиниринга трафика, то есть контролировать не классы, а потоки трафика, в данном случае агрегированные. Под агрегированным понимается поток, состоящий из пакетов одного класса, имеющих общую часть пути через сеть. Эта общая часть не обязательно включает полный путь от входного интерфейса одного из пограничных маршрутизаторов до выходного интерфейса другого пограничного маршрутизатора. Достаточно, чтобы пакеты проходили хотя бы два общих интерфейса, чтобы считать их агрегированным потоком, как, например, в случае потока, проходящего через интерфейсы i l l и І22 (см. рис. 18.6). Затем, зная путь прохождения каждого агрегированного потока через сеть, можно прове рить, имеются ли достаточные ресурсы вдоль пути следования каждого потока, например, не превышают ли коэффициенты использования интерфейсов заданного порога. Для этого нужно провести профилирование с учетом адресов назначения пакетов. Однако реали зация такого подхода в IP-сетях сталкивается с несколькими трудностями. Во-первых, в технологии Diffserv не предусмотрен сигнальный протокол, такой как, например, RSVP в технологии IntServ. Это означает, что все проверки наличия ресурсов у маршрутизаторов для каждого агрегированного потока нужно выполнять в автономном режиме, вручную или с помощью какого-то специального программного обеспечения. Во-вторых, для проведения |