Раздел: Документация
0 ... 34 35 36 37 38 39 40 ... 55  S3(B) Ri{S1(4B), S2(5B)} R2{S2 (3B),S3(B)} * R3{S1(B)} Рис, 5.8. Резервирование ресурсов на основе «фиксированной» фильтрации Соответственно этим запросам на выходном интерфейсе с ресурсы резервируются отдельно для потоков от S] и S2, а на интерфейсе d ресурс для Si резервируется по максимальной заявке. Информация, направляемая источникам о размере зарезервированных ресурсов, приведена на рисунке. Схема выделения ресурсов в режиме «динамической» фильтрации приведена на рис. 5.9. Приемник Ri для получения потоков от Si и S2 требует одну единицу ресурса, R2 для обработки потоков от Si и S3 запрашивает 3 единицы и R3 намерен обрабатывать поток только от S2, требуя для этого 2В. В соответствии с принципом «динамической» фильтрации на интерфейсе d резервируются три единицы ресурса, и его могут использовать потоки от всех трех источников. На интерфейсе с выделяется одна единица ресурса, который будет использоваться совместно для обработки потоков от Si и S2- Таким образом, источник Si информируется о наличии трех единиц ресурса, а источники S2 и S3 получают сообщение о выделении ресурса в объеме ЗВ и о том, что он будет использоваться ими совместно. S1 (ЗВ ) a  S2 , S3 (ЗВ ) Ri( S1f S2(B» R2{ S! ,S3 (3B)} R3{ S2(2B)} Рис. 5.9. Резервирование ресурсов на основе «динамической» фильтрации Resv Хост 1 Данные ...Path.. Хост 4 Протокол RSVP генерирует два сообщения - Resv и Path, на базе которых узлы сети, участвующие в соединении, могут обмениваться информацией, необходимой для резервирования ресурсов. Первое из них генерируется приемником потока и распространяется в направлении к источнику по пути маршрутизации потоков данных, сформированному протоколом одноадресной или многоадресной маршрутизации. Современные протоколы маршрутизации поддерживают только прямые маршруты, т.е. они знают только путь от источника до получателя, но не обратный. Поэтому для передачи сообщения Resv необходимо снабдить каждый сетевой узел информацией об адресе предшествующего ему узла. Эта информация передается протоколом RSVP в сообщении Path, которое генерируется узлом-отправителем и модифицируется каждым транзитным узлом маршрута. Любой узел, желающий стать отправителем информации, посылает сообщение Path всем участникам группы. По пути каждый маршрутизатор и каждый хост-адресат получают из этого сообщения информацию о сетевом адресе предшествующего транзитного узла, на который и следует пересылать сообщение Resv для данного отправителя информации. Этот адрес сохраняется в переменной Path State, а соответствующее поле сообщения Path модифицируется записью в него сетевого адреса текущего узла. Рисунок 5.10 иллюстрирует распространение сообщений протокола RSVP в простой сетевой среде. Рассмотрим несколько подробнее структуру этих сообщений. Сообщение Path. В дополнение к адресу предыдущего транзитного узла это сообщение включает следующие переменные: Хост 2 Хост 3 МАРШРУТИЗАТОР Хост 5 Хост 6 Рис. 5.10. Сообщения RSVP -структурированная переменная Sender Template, определяющая отправителя и описывающая формат данных потоков, принадлежащих определенной сессии (сессия - это множество пакетов, имеющих один IP-адрес назначения и общий TCP/UDP-порт). Каждая сессия может содержать несколько потоков данных, каждый из которых идентифицируется переменной Filter Spec -структурированная переменная Sender Tspec, которая описывает характеристики трафика источника; информация, содержащаяся в этой переменной, может использоваться приемником при определении его запроса к ресурсам, а также процедурами контроля трафика для предотвращения избыточного резервирования ресурсов - переменная Ad Spec является опциональным элементом сообщения Path. Она содержит информацию о характеристиках тракта передачи данных, например таких, как доступный сервис, оценка величины времени передачи и доступной пропускной способности канала и ряд других. Значения полей этой переменной могут быть модифицированы маршрутизаторами, которые поддерживают протокол RSVP. Сообщение Path пересылается строго по тому же маршруту, что и данные. Следовательно, оно будет корректно передано и маршрутизаторами, не поддерживающими протокол резервирования ресурсов. Такими маршрутизаторами эти сообщения передаются как обычные данные. Сообщение Resv. Это сообщение передается от узла к узлу в направлении от приемника к источнику на основании адресной информации, обеспеченной сообщением Path. При этом в групповой конференции сообщения Resv, генерируемые различными приемниками, объединяются на каждом узле маршрутизации, что предотвращает избыточный рост трафика протокола RSVP. Основными объектами сообщения Resv являются структуры Flow Spec, Filter Spec и Style. Переменная Flow Spec содержит поля Tspec и Rspec, определяющие требования к ресурсам, которые необходимо зарезервировать. Приемник, желающий провести резервирование ресурсов, может использовать информацию, содержащуюся в ранее полученном им сообщении Path (переменные Ad Spec и Sender Tspec), для формирования значений переменных Tspec и Rspec. Аналогично, при определении значений полей переменной Filter Spec может использоваться информация из структуры Sender Template. Сообщение Resv, прийдя на хост-огправитель, задает параметры механизма управления его трафиком. Суммируя рассмотрение механизмов протокола RSVP, дадим схематическое описание его работы на одном из хостов. 1.Получатель информации вступает в группу многоадресной рассылки, отправив сообщение по протоколу IGMP ближайшему маршрутизатору. 2.Потенциальный источник информации отправляет сообщение Path по адресу группы (или конкретного хоста). 3.Приемник информации получает сообщение Path, идентифицирующее отправителя. 4.Получатель отправляет сообщение Resv с описанием потоков, которые он намерен принимать, и со своими требованиями к ресурсам. 5.Сообщение Resv передается через все сетевые узлы к отправителю и обеспечивает резервирование необходимых ресурсов. 6.Если резервирование прошло успешно, то отправитель начинает передачу данных. 5.4. ДОСТАВКА ДАННЫХ ПРИЛОЖЕНИЙ РЕАЛЬНОГО ВРЕМЕНИ. ТРАНСПОРТНЫЙ ПРОТОКОЛ RTP Концепция ISPN для обеспечения обмена данными между приложениями реального времени требует определенной модификации транспортных механизмов IP-сетей. Использование TCP в качестве транспортного протокола для таких приложений невозможно по нескольким причинам. Так, этот протокол позволяет устанавливать соединения только между двумя конечными хостами и, следовательно, он не подходит для групповых конференций. Механизмы обеспечения надежности передачи этого протокола предполагают повторную передачу испорченных и потерянных пакетов, и последние могут приходить, когда приложение их уже не ждет. Кроме этого, протокол TCP не имеет удобного механизма привязки информации о синхронизации к сегментам данных. Другой широко используемый протокол транспортного уровня UDP лишен первых двух из отмеченных выше недостатков. Однако проблема привязки критически важной информации о синхронизации в нем не решается и, кроме этого, он требует передачи части функций контроля и обеспечения надежности передачи на уровень приложения. Предложенная в 1990 году [80] технология формирования кадров на уровне приложений (Application Level Framing - ALF) была нацелена на решение этих задач и составила основу целого ряда современных протоколов реального времени, включая RTP (Real Time Transport Protocol - транспортный протокол реального времени), SRM (Scaleable Reliable Multicast - масштабируемый надежный протокол многоадресной передачи), LSW (Lightweight Session - упрощенный сессионный протокол). Транспортный протокол реального времени (RTP) был предложен специальной рабочей группой по проблемам передачи аудио и видео информации инженерного комитета Интернет (IETF) и описан в документе RFC 1889 [78]. Чаще всего он реализуется как составная часть приложения, а не как отдельный уровень потокольного стека. Протокол RTP определяет формат заголовка пакета, формируемого приложением. Этот заголовок включает в себя данные, необходимые для поддержки коммуникаций реального времени в IP-сети. Пакет данных с RTP-заголовком поступает на транспортный уровень стеко протоколов и, чаще всего, посредством UDP передается приложению-получателю. Структура заголовка RTP-пакета приведена на рис. 5.11. oi зо з"Т~ У=2 Р X СС М I Payload Type Sequence Number Time Stamp Synchronization Source Identifier (SSRI) (First) Contributing Source Identifier (CSRC) (Last) Contributing Source Identifier (CSRC) V - версияP - заполнительX - расширение СС - вспомогательный счетчик М - маркер Рис. 5.11. Заголовок RTP-пакета Рассмотрим содержание полей заголовка, которые имеют важное значение для передачи трафика приложений реального времени. -Поле Sequence Number (порядковый номер) - обеспечивает информацию для оценки уровня потерь пакетов в сети и определяет позицию пакета в передаваемом сообщении; размер поля 16 бит. -Поле Time Stomp (временная метка) - содержит информацию о временной привязке первого байта в RTP-пакете данных. Временная метка считывается с обеспечивающих работу данного приложения внутренних, а не системных, часов. Частота генератора временных меток зависит от типа и формата передаваемых данных и должна быть достаточно высокой для обеспечения желаемой точности синхронизации работы распределенного приложения и вычисления джиттера. Ясно, например, что один такт этих синхронизующих часов на видео-кадр является недостаточным. Начальные значения поля Time Stamp задаются случайным образом и далее возрастают линейно. Так, если при передаче аудио-трафика постоянной интенсивности приложение читает с входного устройства каждый блок аудиоданных за 160 периодов генератора временных меток, то значения поля TS двух соседних пакетов будут отличаться на 160 вне зависимости от того передан этот пакет, или он был отброшен как соответствующий периоду молчания. Вообще говоря, последовательно передаваемые пакеты могут содержать значения полей Time Stamp, изменяющиеся немонотонно. Это характерно для видеоприложений, работающих с MPEG-кодерами, в которых используются методы интерполяционного кодирования (В-кадры). При этом нумерация пакетов (Sequence Number) будет изменяться монотонно. Отсюда очевидна недостаточность только нумерации кадров и важность поля lime Stamp для восстановления исходной последовательности кадров сообщения. Раздлер поля - 32 бита. -Поле Payload Туре - (тип передаваемых данных) - содержит информацию о методе кодирования передаваемых данных и, тем самым, определяет интерпретацию их приложением; длина поля - 7бит. -Поле Synchronization Source Identifier (SSRI - идентификаторы синхронизированных источников). Реализация мультимедийных коммуникационных приложений часто требует преобразования потоков данных, порождаедлых разными источниками. Это важно для обеспечения взаимодействия разных мультимедиа продуктов, для организации многоточечных конференций, в ряде других ситуаций. Во всех этих случаях используются программные шлюзы, выполняющие функции трансляторов и смесителей. Трансляторы обрабатывают поступающие от разных источников потоки независимо и генерируют независимые же выходные потоки с какой-то другой кодировкой. Они включают в себя аудио/видеоконверторы, защитные экраны, шлюзы, обеспечивающие взаимодействие станций с возможностями многоадресной передачи данных со станциями, функционирующими только в режиме одноадресной передачи. Смесители преобразуют входные потоки в единый новый выходной поток. Например, смеситель может объединять аудиопотоки от нескольких участников конференции в единый поток, передаваемый на все терминалы группы. Он может объединять также разные составляющие иерархически кодированного видеоисточника, поступающие от уровневых кодеров как независимые потоки. При этом смеситель на основе информации о возможностях принимающего терминала выберет необходимую подсистему этих потоков и объединит их в единый выходной поток. Шлюзы обоих типов используют протокол RTP и должны определенным образом модифицировать заголовок его пакетов. Так, источник каждого потока данных отмечается в поле SSRC. Смеситель, создавая новый поток данных, формирует и новое значение этого поля, помещая значения SSRC всех частичных потоков в специальный список идентификаторов потоков. Последний записывается в полях Contributing Source Identifiers (CSRC) заголовка RTP-пакета. Трансляторы не изменяют значений поля SSRC, но производя перекодировку входных потоков, модифицируют значения поля Payload Туре. Важной компонентой семейства протоколов реального времени является управляющий протокол RTCP (Real-Time Transport Control Protocol). Он обеспечивает передачу только контрольной информации и сигнализации, связанных с RTP-потоками. 0 ... 34 35 36 37 38 39 40 ... 55
|
