Раздел: Документация
0 ... 33 34 35 36 37 38 39 ... 55 Агент маршрутизаци Агент резервирования ресурсов База данных маршрутизаци Агент управления Блок контроля доступа протокола соответствующего потока и т.п. Проект нового стандарта сетевого протокола IPv6 предусматривает существенное упрощение процедуры идентификации потока введением в заголовке пакета специального поля Flowjd - классификационной метки потока. Таким образом, выбор класса обслуживания может базироваться на содержании заголовка IP-пакета и (или) на значении классификационной метки, добавляемой к каждому пакету. Состав класса варьируется в довольно широких пределах и может содержать как целую категорию потоков (например, все видеопотоки), так и один единственный поток. При этом состав класса определяется локально для конкретного маршрутизатора и, следовательно, один и тот же пакет может быть классифицирован различным образом на разных маршрутизаторах. Например, на маршрутизаторах опорной сети каждый класс будет объединять довольно широкую группу потоков, в то время как на периферийных маршрутизаторах каждому типу потока может соответствовать отдельный класс. Блок контроля доступа. Процедуры контроля доступа реализуют алгоритм, который хост-компютер или маршрутизатор используют для определения возможности предоставления требуемого уровня обслуживания потокам приложения, запросившего соединения. Положительное решение принимается при условии, что для уже обрабатываемых потоков уровень качества обслуживания не понизится. Эти процедуры контроля доступа выполняются на каждом сетевом узле в ходе реализации запроса на соединение, инициированного приложением реального времени. Если найдется хотя бы один узел, который не в состоянии поддерживать запрашиваемые услуги, то соединение не устанавливается. В дополнение к гарантиям предоставления требуемого уровня обслуживания контроль доступа объединяется с политикой администрирования узла, которая может предусматривать определенные правила аутентификации пользователей, допущенным к процедуре резервирование ресурсов. Наконец, важнейшим элементом схемы реализации интегрированного сервиса является протокол резервирования ресурсов. Его основная задача - это идентификация и поддержание режима обслуживания потоков на конечных хостах и всех маршрутизаторах, участвующих в соединении. Примерами таких протоколов являются RSVP и ST-2 [76]. Первый из них будет более подробно рассмотрен ниже. Иллюстрацией взаимодействия рассмотренных выше элементов модели интегрального обслуживания на маршрутизаторе может служить рис. 5.4. В маршрутизаторе условно можно выделить две составляющие: тракт передачи пакетов и фоновую программу (на рис. 5.4 ниже и выше пунктирной линии соответственно). Программное и аппаратное обеспечение тракта передачи участвует в обработке каждого пакета и должно быть тщательно оптимизировано. Тракт передачи разделяется на три секции: входной драйвер, межсетевой ретранслятор и выходной драйвер. Межсетевой ретранслятор обрабатывает заголовки пакета сетевого уровня (IP-пакета в случае TCP/IP-стека) и, выполнив операции классификации пакета, передает его соответствующему выходному драйверу. Последний решает задачи диспетчеризации пакетов потока. С позиций уровневой модели стека протоколов выходной драйвер имеет две составляющие - диспетчер пакетов, который максимально независим от особенностей физического интерфейса, и собственно 1/О-драйвер, учитывающий особенности аппаратной реализации соответствующего интерфейса. Фоновые процессы, выполняемые процессором общего назначения, формируют структуры данных, которые контролируют тракт передачи пакетов. Так, агент маршрутизации выполняет процедуры, соответствующие протоколу маршрутизации (RIP, OSPF) и формирует маршрутные таблицы. Агент резервирования ресурсов реализует протокол RSVP и если блок контроля доступа дает «добро» новому запросу, то этот агент вносит соответствующие изменения в базу данных контроля трафика (информация из последней используется классификатором и диспетчером пакетов). Агент сетевого управления является обязательным элементом каждого маршрутизатора, но в контексте модели интегрального сервиса он должен располагать возможностью модификации базы данных контроля трафика в соответствии с административной политикой контроля доступа к ресурсам сети. Схема реализации модели интегрального обслуживания на хост-компьютере в основных своих чер-iox аналогична рассмотренной. Очевидно, что вместо маршрутизации данные на хосте генерируются или принимаются приложением реального времени, которое и активизирует локальный агент резервирования ресурсов. Агент маршрутизации Входной драйвер
Диспетчер Выходной драйвер Рис. 5.4. Взаимодействие элементов модели ISPN на маршрутизаторе 5.3. РЕЗЕРВИРОВАНИЕ РЕСУРСОВ. ПРОТОКОЛ RSVP Обобщенная схема модели ISPN предполагает возможность выбора приложением необходимого ему класса сервиса (гарантируемого, контролируемой загрузки или традиционного «как удастся»). Кроме этого, для реализации сервиса реального времени необходимо, чтобы все сетевые элементы, участвующие в соединении: -располагали механизмами контроля качества обслуживания потока данных конкретного приложения -могли обмениваться между собой и приложением информацией, необходимой для согласования их возможностей удовлетворения запроса приложения к определенным ресурсам. Как показано выше, решение задач первой группы обеспечивается механизмами контроля трафика. Вторая задача решается протоколом резервирования ресурсов. Всякий такой протокол должен: -поддерживать все виды сервиса -работать с групповыми адресами -позволять динамически изменять состав взаимодействующих хостов -иметь возможности изучения требований к ресурсам разных приложений с целью оптимизации и использования общих сетевых ресурсов -контролировать протокольные «накладные расходы» так, чтобы снизить скорость их роста с увеличением состава группы. Существуют несколько протоколов, решающих перечисленные задачи. Идеологии Интернет более соответствует протокол RSVP, предложенный инженерной группой Интернет. Документ RFC 2205 [77] определяет, что протокол RSVP используется хостом для запроса от сети необходимого уровня обслуживания потоков данных определенного приложения. RSVP используется также маршрутизаторами для генерации запросов на обслуживание ко всем узлам, участвующим в соединении, установления и поддержания их режимов, обеспечивающих запрошенный сервис. В целом, результатом RSVP-запроса является резервирование ресурсов на всех сетевых узлах маршрута от источника до получателя. RSVP резервирует ресурсы для однонаправленного потока, т.е. он логически отделяет источник от получателя. Этот протокол работает поверх IP, занимая место транспортного протокола в стеке. Однако он не является транспортным протоколом для данных приложения и играет роль контрольного и, отчасти, маршрутизирующего протокола. Вместе с тем RSVP не решает задачи выбора маршрута для пакетов приложения, но обеспечивает необходимый уровень качества обслуживания пакетов на всех этапах их маршрута. RSVP должен иметь механизм взаимодействия с протоколом маршрутизации для решения проблемы резервирования ресурсов при изменениях маршрута доставки пакетов. Рис. 5.5 иллюстрирует схему взаимодействия RSVP с основными сетевыми элементами программного обеспечения на хосте и маршрутизаторе. В общем случае задачей протокола RSVP является обеспечение должного уровня функционирования распределенного сетевого приложения, содержащего I источников и J получателей потоков данных реального времени. Принципиальным и очень важным в модели резервирования ресурсов является вопрос о том, какое из устройств - получатель или источник должно быть инициатором запроса на резервирование ресурсов. В концепциях ATM и frame relay необходимые ресурсы запрашивает источник потока данных. На первый взгляд это решение является вполне естественным, ибо источник знает характеристики своего трафика и может сформировать запрос к ресурсам сети для обслуживания своих потоков. Однако этот подход, будучи приемлемым с определенными оговорками для одноадресной передачи, является совершенно неудовлетворительным для многоадресной рассылки и учета гетерогенности характеристик получателей. Действительно, у разных членов группы могут быть различные требования к ресурсам сети, что определяется их предпочтениями в части типа принимаемых потоков (каждый может принимать различные подмножества существующих потоков данных), различной вычислительной мощностью их хост-компьютеров, разной пропускной способностью каналов связи и т.п. Все эти проблемы масштабирования решаются, если возложить ответственность за формирование запроса на обслуживание на приемную часть приложения. Так же легко решается в этом случае и проблема динамического изменения состава групп - присоединившийся получатель просто генерирует свой запрос к ресурсам. Маршрутизаторы сводят воедино запросы на ресурсы и резервируют их на общих участках пути от получателя до отправителей. Маршрутизатор Приложение RSVP Агент Данные Контроль доступа Контроль доступа к ресурсам
RSVP Агент маршрутизации RSVP Агент Контроль доступа Контроль доступа к ресурсам
Данные Рис. 5.5. Схема функционирования RSVP на маршрутизаторе и хост-компьютере Проблема инициализации запроса на ресурсы от приемника решается посредством механизмов высокоуровневых протоколов контроля и сигнализации. Посредством этого же протокола приемник может получать общее описание трафика источника и с его учетом сформировать свой запрос к ресурсам, который и направляется по маршруту, определенному для пересылки данных, назад к источнику. По мере прохождения этого запроса по сети на всех ее узлах (маршрутизаторах) будут резервироваться необходимые ресурсы или будет принято решение о невозможности их выделения. В этом случае формируется другой маршрут для доставки данных к этому получателю. RSVP-запрос от конечной системы-получателя определяет объем ресурсов, которые необходимо зарезервировать на сетевом узле для всех или определенной части потоков данных. Эти требования к ресурсам содержатся в переменной Flow Spec, а признаки пакетов, использующих эти ресурсы, задаются переменной Filter Spec. Если проверка прав доступа к ресурсам (Admission Control) проходит успешно, то данные из структуры Flow Spec используются для инициализации диспетчера пакетов, а из переменной Filter Spec - для классификатора. Очевидно, что значения полей этих структуированных переменных зависят от выбора типа сервиса. Для повышения эффективности группового использования ресурсов маршрутизатора протокол RSVP предусматривает три режима резервирования: «примитивная» фильтрация (wildcard filter style - WF), «фиксированная» фильтрация (fixed-filter style- FF) и «динамическая» фильтрация (dynamic-filter style - DF). Первый из них создает на каждом интерфейсе общий ресурс для потоков всех источников. Такое резервирование можно сравнить с созданием общей «трубы», пропускная способность которой определяется наибольшим из частичных запросов к этому ресурсу. Пропускная способность такой «трубы» автоматически увеличивается при появлении источника с большими требования (конечно, если только это увеличение принципиально возможно). Такой режим резервирования полезен для поддержания аудиопотоков в групповых конференциях, где число одновременно говорящих участников и, соответственно, одновременно существующих аудиопотоков обычно невелико, и их потребности в канале могут быть удовлетворены при рассматриваемом алгоритме резервирования. Режим «фиксированной» фильтрации (FF) реализует принцип «точно определенный ресурс - строго определенному источнику». Этот режим наилучшим образом соответствует передаче видеопотоков в конференции с фиксированным составом группы. Режим «динамической» фильтрации обеспечивает возможность резервирования ресурса, совместно используемого некоторой группой источников. Такое резервирование позволяет приемнику изменять состав принимаемых потоков (в пределах заданной группы) без обращения к процедурам контроля доступа. Следует иметь в виду, что резервирование ресурса в этом случае производится по принципу «наихудшего случая», т.е. из расчета, что все приемники, использующие ресурс данного маршрутизатора, получают потоки от разных источников. Проиллюстрируем описанные режимы резервирования на примере простого распре-Si деленного приложения, схема которого представлена на рис. 5.6. Маршрутизатор своими входными интерфейсами а и Ь связан с источниками S] и <s2 . s3 ) ($2/ з)/ соответственно. Его выходные интерфейсы end поддерживают приемники R], R2 и R3. При этом интерфейс d работает в режимеРис* 5-6- Схема потоков распределенного многоадресной передачи. Все пакеты от S] S2приложения и S3 маршрутизируются на оба выходных интерфейса. Для простоты будем считать, что резервируется один ресурс, и единицей его измерения является В. В этих предположенияхsi режим резервирования на основе шаблонной фильтрации иллюстрируется рис. 5.7. Приемники R], R2 и R3, обладая разными (S2, s3) возможностями обработки потоков источников,D а 1— r3 требуют резервирования ресурсов в объеме 4В, ЗВ и 2В. Поскольку интерфейс d обеспечи-рис 57 Резервирование ресурсов на основе вает приемники R2 и R3, то объем резервиро-«примитивной» фильтрации вания на нем устанавливается равным ЗВ. Так как данные на выходные интерфейсы поступают с двух входных, то источникам Si, S2 и S3, будет направлено сообщение о резервировании ресурсов на данном узле в объеме 4В. Ситуация, возникающая при резервировании ресурсов на основе «фиксированной» фильтрации, показана на рис. 5.8. Здесь приемник на выходном интерфейсе с требует для обработки потока от S] четыре единицы ресурса и от S2 - пять единиц, в то время как на интерфейсе d приемник R2 намерен получать потоки от S2 и S3, требуя для этого три и одну единицы ресурса, а приемник R3 для обработки потока от Si нуждается в одной единице ресурса.
-R2
0 ... 33 34 35 36 37 38 39 ... 55
|
||||||||||||||||||||||||||||||||||||||||||||||
