Автор работы: Пользователь скрыл имя, 08 Июня 2014 в 15:22, дипломная работа
Основной целью группового вещания является создание эффективного механизма передачи данных по схеме "один-ко-многим" и "многие-ко-многим". Традиционные механизмы стека TCP/IP доставки пакетов мало пригодны для поддержки группового вещания. Например, использование уникальных адресов (unicast) приводит к необходимости установления многочисленных двухточечных соединений между отправителем и каждым из получателей. Другим способом передачи данных является широковещательная передача, когда станция направляет пакеты, используя широковещательные адреса (broadcast). Пакеты с такими адресами передаются всем конечным узлам указанной сети независимо от того, нужны ли они каждому из них. Во многих ситуациях такой способ передачи также оказывается неэффективным вследствие своей избыточности, которая ведет к чрезмерному росту трафика, особенно в крупных сетях.
Областью преимущественного применения дифференцированных сервисов специалисты видят магистрали сетей. Это связано с тем, что через магистраль обычно проходит настолько большое количество микропотоков различных приложений, что гарантированная поддержка каждого из них в соответствии с принципами интегрированного обслуживания требует чрезмерно больших накладных расходов в маршрутизаторах магистрали. Применение здесь дифференцированных сервисов гораздо экономичней, так как они работают с агрегированными потоками, образованными из микропотоков со схожими требованиями к QoS.
Кроме протоколов категорий IntServ и DiffServ, в IP-сетях на сегодня существует еще несколько протоколов, связанных с поддержкой качества обслуживания. Прежде всего, это протокол MPLS, который позволяет направлять поток по маршруту, обеспечивающему необходимое качество обслуживания.
Имеется также протокол согласованной поддержки качества обслуживания в подсетях IP, называемый Subnet Bandwidth Management (SBN). Он осуществляет связь средств поддержки QoS на канальном уровне для разделяемых и коммутируемых сетей IEEE 802 (спецификаций 802.1Q/p) с параметрами качества обслуживания на уровне IP.
ReSerVation Protocol (RSVP) — это протокол сигнализации, который обеспечивает резервирование ресурсов и управление ими с целью предоставления интегрированных в IP-сетях. Протокол RSVP представляет собой наиболее сложную QoS-технологию, как для приложений (хостов), так и для сетевых элементов (маршрутизаторов и коммутаторов). Он в наибольшей степени отличается от IP-сервиса "с максимальными усилиями" и обеспечивает на сегодня наивысший уровень качества обслуживания в терминах гарантий сервиса, дифференцированного распределения ресурсов и уровня детализации обратной связи для QoS-приложений и пользователей.
Протокол RSVP не предназначен обеспечивать QoS для всей сети Internet, и больше подходит для небольших сетей в которых широко используется групповое вещание, при котором у одного источника существует несколько приемников информации. При этом приемники информации могут отличаться своими возможностями, так что и потребности в пропускной способности соединения с источником у них могут быть разные. Для учета разнородности нескольких приемников в протоколе RSVP параметры резервирования определяет не источник, а приемник информации. Инициатором работы протокола остается источник, но он только рассылает всем приемникам уведомление о том, что вскоре начнет передавать данные и приемникам необходимо зарезервировать ресурсы сети для качественного приема этих данных. В частном случае, когда приемник один, то есть когда в пакете указан не групповой, а уникальный адрес назначения, работа протокола RSVP не изменяется.
Процесс функционирования RSVP основан на двух концепциях: на потоках (flows) и на резервировании (reservation). RSVP резервирует ресурсы для конкретного потока. Речь идет о потоках информационного обмена (данных), идущих от отправителя к получателю или, возможно, к нескольким получателям. Поток определяется целевым IP-адресом и целевым портом (последнее не обязательно). Вместе с потоком RSVP задает требуемый для него уровень QoS. RSVP не работает с полем flowspec, но соответствующая информация передается узлам и маршрутизаторам, лежащим на пути потока. Эти системы могут посмотреть данное поле, чтобы проверить наличие ресурсов, необходимых для удовлетворения запроса на резервирование, и, если таковые имеются, они с помощью значения поля резервируют запрошенные ресурсы.
Как говорилось ранее, приемники, использующие RSVP, осуществляют непосредственное резервирование. Это делается для того, чтобы избавить сервер от необходимости исполнять функции общего администратора для всех возможных получателей
Процесс резервирования разбит на две части: первая выполняется отправителем, вторая - получателем. Если резервирование осуществляет получатель, то возникает вопрос: откуда получатель знает о маршруте, по которому будет направлен поток? Отправитель вышлет маршрутные сообщения, которые пройдут по маршруту отправителя и будут переданы маршрутизаторами.
Маршрутное сообщение описывает путь потока до любого потенциального получателя и позволяет маршрутизаторам подготовиться к возможной передаче потока данных. Оно определяет поток для маршрутизаторов и предупреждает их о возможности поступления входящих запросов на резервирование.
Источник данных посылает по уникальному или групповому адресам получателя специальное сообщение Path, в котором он указывает рекомендуемые параметры для качественного приема своего трафика: верхней и нижней границ пропускной способности, задержки и вариации задержки. Эти параметры трафика содержатся в так называемой спецификации трафика (TSpec). Сообщение Path передается маршрутизаторами сети в направлении к приемнику (или приемникам) с использованием таблиц маршрутизации, полученных с помощью любого протокола маршрутизации.
Маршрутное сообщение, посланное отправителем, принимается всеми маршрутизаторами, находящимися на данном маршруте. Маршрутизатор заносит свой IP-адрес в качестве адреса последнего перехода сообщения. По мере распространения сообщения по сети каждый следующий маршрутизатор запоминает адрес предыдущего, а перед дальнейшим перенаправлением маршрутного сообщения заносит свой собственный IP-адрес. Поскольку каждый маршрутизатор помнит IP-адрес последнего для данного потока маршрутизатора, маршрутизатору, получающему запрос на резервирование, известно, как перенаправить этот запрос обратно отправителю. Это гарантирует, что приемники получат правильный маршрут для конкретного потока. Так делается потому, что большинство сетевых решений реализует более одного маршрута, так что не исключено, что приемник зарезервирует маршрут, который не задавал отправитель.
Маршрутные сообщения могут быть отосланы в любой момент, и маршрутизаторы поддерживают информацию о состоянии маршрута в так называемой временной (soft) базе данных. Информация о состоянии сохраняется только в течение определенного периода времени, после чего маршрутизаторы удаляют ее. Это позволяет достичь динамической гибкости в реализации маршрутов. Допускается задать новый маршрут (вследствие изменения топологии), который переопределит старый маршрут.
Возможна ситуация, когда маршрутизатор потерпит неудачу на некотором маршруте, а альтернативных путей не окажется. Следовательно, информация о маршруте устарела и должна быть удалена.
RSVP работает на маршрутизаторах, отвечая на запросы, которые передают сетевые приложения. Он служит в маршрутизаторах для перенаправления запросов, относящихся к QoS, всем станциям, лежащим на маршруте или маршрутах данного определенного потока. В задачу маршрутизаторов входит также работа с состояниями RSVP и поддержание информации о них. Другими словами, если приложение делает запрос RSVP, то каждый маршрутизатор должен перенаправить его другому маршрутизатору, находящемуся на маршруте до отправителя, то есть на обратном пути от получателя к отправителю.
Процесс RSVP получает маршруты посредством локальной маршрутной таблицы, QoS реализуется при помощи ряда механизмов, известных как механизмы управления информационным обменом (traffic control). Сюда входит три механизма:
Два модуля внутри RSVP, известные как модуль управления доступом (admission control) и модуль управления правами (policy control), предназначены для получения запроса RSVP. Модуль управления доступом определяет, есть ли на узле свободные ресурсы для удовлетворения. Модуль управления правами проверяет предоставленные запрашивающему объекту права. Если какая-либо из этих проверок закончится неуспешно, запрос аннулируется и запрашивающему объекту (приложению, которое сделало запрос) отсылается сообщение, разъясняющее род проблемы. При успешном завершении обеих проверок в классификаторе пакетов и пакетном планировщике устанавливаются параметры с целыо получения необходимых запрашивающему объекту ресурсов.
В любом запросе RSVP имеется дескриптор потока, который содержит:
значения параметров в классификаторе пакетов.
RSVP основан на концепции сеансов и рассматривает сеанс как поток данных для конкретного целевого объекта, который применяет определенный протокол транспортного уровня. Каждый сеанс обслуживается независимо. Он идентифицируется следующей совокупностью параметров:
В целях резервирования ресурсов между отправителем и получателем передаются два типа сообщений (процесс доставки этих сообщений ненадежен, так как программа использует IP-адрес напрямую):
В этой точке резервирование уже имеет место, и информацию о нем не нужно передавать дальше.
В запросе на резервирование есть набор опций, в совокупности известных как опции способа резервирования (reservation style). Эти опции позволяют осуществлять индивидуальное (уникальное) или общее резервирование. Например, общее резервирование может применяться при групповой адресации. Приложения видео и аудио, которые используют групповую адресацию, - великолепный пример подобного подхода. Индивидуальное резервирование предназначено для приложений, таких как небольшая видеоконференция между двумя настольными рабочими станциями, то есть используется в случае, когда нужен особый высокоприоритетный поток данных с минимальными потерями.
Приемник может запросить подтверждение и укажет присутствие запроса в резервирующем сообщении вместе со своим IP-адресом. Сразу же после удовлетворения запроса на резервирование, будь то индивидуальное или общее резервирование, отсылается подтверждающее сообщение.
Базовый процесс резервирования завершается в один проход. Это означает, что резервирующее сообщение отправляется от одного маршрутизатора к другому по обратному пути до отправителя. Каждый маршрутизатор на этом пути имеет право отказать в запросе.
Резервирование отменяется при помощи отменяющих (TearDown) сообщений. Пользоваться ими рекомендуется, но это не обязательно. Резервирование, не отмененное приложением, в конце концов будет отменено маршрутизаторами - поскольку сообщение об обновлении (Refresh) не было получено, резервирование должно быть отменено в течение определенного периода времени. Имеется два типа отменяющих сообщений: