Алгоритмы мультимедиа

Определения

Поле данных RTP. Информация, пересылаемая в пакете RTP, например, фрагменты звука или сжатые видеоданные.

Пакет RTP. Информационный пакет, содержащий фиксированный заголовок. Один пакет транспортного нижнего уровня, например, UDP, обычно содержит один RTP-пакет, но это требование не является обязательным. Поле источников информации может быть пустым.

Пакет RTCP. Управляющий пакет, который содержит фиксированный заголовок, сходный с RTP, и за ним следуют структурные элементы, зависящие от типа RTCP-пакета. Обычно несколько RTCP-пакетов посылаются как составной RTCP-пакет, вложенный в дейтограмму нижележащего уровня.

Транспортный адрес. Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя.

Сессия RTP. Период с момента формирования группы участников RTP-обмена до ее исчезновения. Для каждого из участников сессия определяется конкретной парой транспортных адресов (сетевой адрес и номера портов для RTP и RTCP). Транспортный адрес места назначения может быть общим для всех участников сессии. Допускается реализация нескольких сессий для каждого из участников одновременно.

Источник синхронизации (SSRC). Источник потока RTP-пакетов, определяется 32-битным числовым SSRC-идентификатором, который записывается в заголовок RTP-пакета и не зависит от сетевого адреса. Все пакеты от источника синхронизации образуют часть с идентичной временной привязкой и нумерацией. Эти данные используются принимающей стороной при воспроизведении. Источниками синхронизации могут служить источники первичного сигнала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-идентификатор представляет собой случайное число, которое является уникальным для данной RTP-сессии. Участник сессии не должен применять один и тот же SSRC-идентификатор для всех RTP-сессий мультимедийного набора. Если участник формирует несколько потоков в рамках одной RTP-сессии (например, от нескольких видеокамер), каждый участник должен быть снабжен уникальным SSRC-идентификатором.

Информационный источник CSRC (contributing source). Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют парциальные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудиоконференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор.

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

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

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

Монитор. Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности, диагностические сообщения, производит оценку состояния связи, копит долгосрочную статистику обмена.

Все целочисленные поля передаются в соответствии c сетевым порядком, т.е. старший байт следует первым (big-endian). Порядок передачи описан подробно в работе [10.3]. Если не оговорено обратного, все цифровые константы являются десятичными. Все поля заголовка выравниваются по их естественным границам, т.е. 16-битовые поля имеют четное смещение, а 32-битные имеют адрес, кратный 4. Октеты-заполнители содержат нули.

Абсолютное время представляется с помощью временных меток в соответствии с форматом NTP (network time protocol), который характеризует время в секундах от начала суток (UTC) 1 января 1900 года [10.4]. Полное разрешение временной метки NTP определяется 64-битовым числом с фиксированной запятой без знака. Целочисленная часть задается первыми 32 битами, а дробная часть — последними. В некоторых полях, где допустимо более компактное представление, используются только средние 32 бита (16 бит — целочисленная часть и 16 бит — дробная). Заголовок RTP-пакета имеет следующий формат (см. рис. 10.4).

Первые 12 октетов присутствуют во всех RTP-пакетах, в то время как список CSRC-идентификаторов присутствует только, когда пакет формируется смесителем. Поля имеют следующие назначения:

V (Версия): 2 бита

Это поле идентифицирует версию протокола RTP. В настоящее время в это поле записывается код 2. Значение 1 использовалось в опытной версии RTP, а код 0 — в аудиоприложении vat.

p (Заполнитель): 1 бит

Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в одну UDP-дейтограмму.

x (Расширение): 1 бит

Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка.

CC (CSRC count — число CSRC): 4 бита

Число CSRC содержит код количества CSRC-идентификаторов, которые записаны в пакете.

M (маркер): 1 бит

Интерпретация маркера определяется профайлом. Предполагается разрешить выделять в потоке пакетов существенные события, такие, как границы кадра. Профайл может определить дополнительные маркерные биты или специфицировать отсутствие маркерных битов путем изменения числа битов в поле PT.

PT (Тип данных): 7 бит

Это поле идентифицирует формат поля данных RTP-пакета и определяет его интерпретацию приложением. Могут быть определены дополнительные коды типа данных. Исходный набор кодов по умолчанию для аудио и видео задан в профайле Internet-draft и может быть расширен в следующих редакциях стандарта (RFC-1700) [10.5].

Номер по порядку: 16 бит

Номер по порядку инкрементируется на 1 при посылке очередного RTP-пакета данных, этот код может использоваться получателем для регистрации потерь пакетов и для восстановления истинного порядка присланных фрагментов. Начальное значение кода является случайным. Алгоритм генерации таких кодов рассмотрен в [10.6].

Временная метка: 32 бита

Временная метка соответствует времени стробирования для первого октета в информационном RTP-пакете. Время стробирования должно быть получено от часов, показания которых увеличиваются монотонно и линейно, чтобы обеспечить синхронизацию и вычисление временного разброса. Разрешающая способность часов должна быть достаточной для обеспечения приемлемой точности синхронизации (одного тика на видеокадр обычно не достаточно). Частота часов зависит от формата данных и задается статически в профайле, в спецификации поля данных или динамически средствами, выходящими за пределы спецификации протокола RTP. Если RTP-пакеты генерируются периодически, используется временная привязка, определенная задающим генератором стробирования, а не показаниями системных часов.

Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к одному и тому же видео кадру).

SSRC: 32 бита

Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так, чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

CSRC-список: от 0 до 15 элементов, по 32 бита каждый

CSRC-список идентифицирует источники информации, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы.

Для эффективной реализации протокола число точек мультиплексирования должно быть минимизировано. В RTP мультиплексирование осуществляется по транспортным адресам мест назначения, которые определены RTP-сессией. Использование пакетов с различным типом поля данных, но с идентичным SSRC создает определенные проблемы:

Первые три из этих проблем вполне устранимы, если использовать различные SSRC для каждого вида среды при посылке их в пределах одной RTP-сессии.

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

В протоколе RTP предусмотрен механизм расширений заголовка, который позволяет модифицировать заголовок и экспериментировать с новыми форматами поля данных. Этот механизм устроен так, что расширения заголовка могут игнорироваться приложениями, которые не нуждаются в расширениях.

Расширения заголовка предназначены для ограниченного использования — и многие приложения лучше реализовать, используя профайл. Формат реализации расширений показан на рис. 10.5.

Если бит x в RTP-заголовке равен 1, то к заголовку добавлено расширение переменной длины, за которым может следовать список CSRC. Расширение заголовка содержит 16-битовое поле длины, определяющее число 32-битных слов в расширении, исключая 4-октета заголовка расширения (т.о. значения поля длина, равное нулю, вполне допустимо). Информационный заголовок RTP может иметь только одно расширение. Чтобы обеспечить работу различных приложений с различными расширениями заголовка или чтобы обеспечить работу с более чем одним типом расширений, первые 16 бит расширения заголовка остаются свободными для выбора идентификаторов или параметров. Формат этих 16 бит определяется спецификацией профайла, с которым работает приложение.

Кроме оконечных систем, RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP.

RTP транслятор/смеситель соединяет две или более области на транспортном уровне. Обычно каждая область определяется сетью и транспортным протоколом (например, IP/UDP), мультикаст-адресом или парой уникаст-адресов, а также портом назначения транспортного уровня. Одна система может служить транслятором или смесителем для нескольких RTP сессий.

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

Аналогично все оконечные системы RTP, которые взаимодействуют через один или более транслятор или смеситель, принадлежат одной и той же SSRC-области, т.е., SSRC-идентификаторы должны быть уникальными для задействованных оконечных систем. Существует большое разнообразие трансляторов и смесителей, спроектированных для решения различных задач и приложений. Некоторые служат для шифрования/дешифрования несущих дейтограмм.

Различие между смесителями и трансляторами заключается в том, что последние пропускают через себя потоки данных, при необходимости их преобразуя, а смесители просто объединяют несколько потоков в один.

Транслятор. Переадресует RTP-пакеты, не изменяя их SSRC-идентификаторы. Это позволяет получателям идентифицировать отдельные источники, даже если пакеты от всех источников проходят через один общий транслятор и имеют сетевой адрес транслятора. Некоторые типы трансляторов передают данные без изменений, другие кодируют данные и соответственно изменяют коды типа данных и временные метки. Приемник не может заметить присутствия транслятора.

Смеситель. Принимает потоки RTP-данных от одного или нескольких источников, может изменять формат данных, определенным образом объединяет потоки и затем формирует из них один общий поток. Так как объединяемые потоки не синхронизованы, смеситель производит синхронизацию потоков и формирует свою собственную временную шкалу для исходящего потока. Смеситель является источником синхронизации. Таким образом, все пакеты данных, переадресованные смесителем, будут помечены SSRC-идентификатором смесителя. Чтобы сохранить информацию об источниках исходных данных, смеситель должен внести свои SSRC-идентификаторы в список CSRC-идентификаторов, который следует за RTP-заголовком пакета. Смеситель, который, кроме того, вносит в общий поток свою составляющую, должен включить свой собственный SSRC-идентификатор в CSRC-список данного пакета.

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

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

Некоторый набор смесителей и трансляторов представлен на рис. 10.6. Здесь показано их влияние на SSRC и CSRC-идентификаторы. Оконечные системы обозначены символами ES и выделены цветом. Трансляторы обозначены буквами TRS (на рисунке — овалы), и смесители обозначены как MUX (прямоугольники). Запись M1:13(1,17 ) обозначает пакет, отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2.

Последовательное включение смесителей

В RTP-сессии могут быть задействовано несколько смесителей и трансляторов, как это показано на рис. 10.6. Если два смесителя включены последовательно, так, как MUX2 и MUX3, то пакеты, полученные смесителем, могут быть уже объединены и включать CSRC-список со многими идентификаторами. Смеситель (MUX3) должен формировать CSRC-список для исходящих пакетов, используя CSRC-идентификаторы уже смешанных входных пакетов (выход MUX2) и SSRC-идентификаторы несмешанных входных пакетов, поступивших от ES9 ( E:36 ). Это отмечено на рисунке для выходных пакетов смесителя MUX3 как M3:99(9,11,36). Если число идентификаторов в списке CSRC превышает 15, остальные не могут быть туда включены.

SSRC-идентификаторы в RTP-заголовках и в различных полях RTCP-пакетов являются случайными 32-битовыми числами, которые должны быть уникальными в рамках RTP-сессии. Очень важно, чтобы одни и те же числа не были использованы несколькими участниками сессии.

Недостаточно применять в качестве идентификатора локальный сетевой адрес (такой как IPv4), так как он может быть не уникальным. Так как RTP трансляторы и смесители разрешают работу с сетями, использующими различные адресные пространства, это допускает их случайное совпадение с большей вероятностью, чем в случае использования случайных чисел.

Неприемлемо также получать идентификаторы SSRC путем простого обращения к функции random() без тщательной инициализации.

Так как идентификаторы выбраны случайным образом, существует малая, но конечная вероятность того, что два или более источников выберут одно и то же число. Столкновение более вероятно, если все источники стартуют одновременно. Если N — число источников, а L — длина идентификатора (в нашем случае 32 бита), вероятность того, что два источника независимо выберут одно и то же значение (для больших N [10.8]), составляет 1-exp(-N2 /2(L+1)). Для N=1000 вероятность примерно равна 10-4.

Типовое значение вероятности столкновения много меньше худшего случая, рассмотренного выше. Возьмем случай, когда новый источник подключается к RTP-сессии, в которой все остальные источники уже имеют уникальные идентификаторы. Если N равно числу источников, а L — длина идентификатора, вероятность столкновения равна N/2L. Для N=1000 вероятность составит около 2*10-7.

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

Преодоление столкновений и детектирование петель

Хотя вероятность столкновения идентификаторов SSRC довольно мала, все RTP-реализации должны быть готовы обнаруживать столкновения и предпринимать адекватные меры для их преодоления. Если источник обнаруживает в какой-либо момент, что другой источник использует тот же идентификатор SSRC, он посылает пакет RTCP BYE для старого идентификатора и выбирает новый. Если получатель обнаруживает, что два других источника имеют равные идентификаторы (столкновение), он может воспринимать пакеты от одного и игнорировать от другого до тех пор, пока это не будет зарегистрировано отправителями.

Так как идентификаторы уникальны, они могут использоваться для детектирования петель, которые могут создаваться смесителем или транслятором. Петля приводит к дублированию данных и управляющей информации.

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

Оба вида петель и столкновения приводят к тому, что пакеты приходят с тем же самым SSRC-идентификатором, но с разными транспортными адресами, которые могут принадлежать оконечной или какой-то промежуточной системе. Следовательно, если источник меняет свой транспортный адрес, он должен также выбрать новый SSRC-идентификатор, чтобы ситуация не была интерпретирована как зацикливание. Петли или столкновения, происходящие на дальней стороне транслятора или смесителя, не могут быть детектированы с использованием транспортного адреса источника, если все копии пакетов идут через транслятор или смеситель. Однако столкновения могут быть детектированы, когда фрагменты двух RTCP SDES пакетов содержат равные SSRC-идентификаторы, но разные коды CNAME (см. описание протокола RTCP).

Чтобы детектировать и устранять конфликты, реализации RTP должны содержать алгоритм, аналогичный описанному ниже. Он игнорирует пакеты от нового источника, которые входят в противоречие с работающим источником. Алгоритм разрешает конфликты с SSRC-идентификаторами участников путем выбора нового идентификатора и посылки RTCP BYE для старого. Однако когда столкновение вызвано зацикливанием собственных пакетов участников сессии, алгоритм выбирает новый идентификатор только раз и после этого игнорирует пакеты от транспортного адреса, вызвавшего зацикливание. Это нужно, чтобы избежать потока пакетов BYE.

Этот алгоритм зависит от равенства транспортных адресов для RTP и RTCP пакетов источника. Алгоритм требует модификации приложений, которые не отвечают этому ограничению.

Данный алгоритм требует наличия таблицы транспортных адресов источников, упорядоченных по их идентификаторам. В таблицу заносятся адреса, откуда данный идентификатор был впервые получен. Каждый SSRC- или CSRC-идентификатор, полученный с информационным или управляющим пакетом, отыскивается в этой таблице, чтобы корректно обработать полученные данные. Для управляющих пакетов каждый элемент с его собственным SSRC, например, фрагмент SDES, требует отдельного просмотра. SSRC в сообщениях-отчетах составляют исключение. Если SSRC или CSRC не найдены, создается новая запись в таблице. Эти записи в таблице удаляются, когда приходит пакет RTCP BYE с соответствующим кодом SSRC или когда достаточно долго не приходит вообще никаких пакетов.

Чтобы отслеживать зацикливание собственных пакетов участников, необходимо также завести отдельный список транспортных адресов источников, которые считаются конфликтными. Заметим, что это должен быть короткий список, обычно пустой. Каждый элемент этого списка хранит адрес источника и время, когда был получен последний конфликтный пакет. Элемент может быть удален из списка, если за время 10 периодов посылки RTCP сообщений-отчетов не прибыло ни одного конфликтного пакета.

Предполагается, что собственные идентификаторы и состояния участников записаны в таблицу идентификаторов источников.

Алгоритм:

IF SSRC или CSRC-идентификатор не найден в таблице идентификаторов источников:
THEN создать новую запись и внести туда транспортный адрес источника и SSRC или
CSRC вместе с кодом состояния.
CONTINUE (продолжить) обычную процедуру обработки.
Идентификатор найден в таблице
IF транспортный адрес источника из пакета совпадает с одним из записанных в таблице:
THEN CONTINUE Продолжить обычную процедуру обработки.
Обнаружено столкновение идентификаторов или зацикливание
IF идентификатор источника не совпадает с собственным идентификатором участника:
THEN IF идентификатор источника совпадает с тем, что содержится в фрагменте RTCP SDES, содержащем элемент CNAME, который отличается от CNAME из рекорда таблицы:
THEN (опционно) Случилось столкновение посторонних идентификаторов.
ELSE (опционно) Случилось зацикливание.
ABORT Прервать обработку информационного или управляющего пакета.
Столкновение для идентификатора участника или зацикливание его пакетов
IF транспортный адрес найден в списке конфликтных адресов:
THEN IF идентификатор источника не найден во фрагменте RTCP SDES, содержащем CNAME, или если CNAME принадлежит участнику:
THEN (опционно) случилось зацикливание собственного трафика.
Записать текущее время в соответствующую запись таблицы конфликтных адресов.
ABORT (прервать) обработку информационного или управляющего пакета.
Зафиксировать факт столкновения.
Внести новую запись в таблицу конфликтных адресов и зафиксировать время записи.
Послать пакет RTCP BYE с идентификатором SSRC.
Выбрать новый идентификатор.
Внести новую запись в таблицу идентификаторов источников со старым SSRC, транспортным адресом источника обработанного пакета.
CONTINUE Продолжить обычную процедуру обработки.

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

Когда из-за столкновения выбран новый SSRC-идентификатор, кандидат-идентификатор должен быть сверен с содержимым таблицы идентификаторов. Если такой код там уже имеется, должен быть выбран другой кандидат и процедура сверки повторена.

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

Когда необходимо шифрование RTP или RTCP, все октеты будут инкапсулированы в одну дейтограмму нижележащего уровня и зашифрованы как единое целое. Для RTCP в начало последовательности перед шифрованием добавляется 32-битное случайное число, чтобы предотвратить возможные атаки. В случае RTP никаких префиксов не требуется, так как порядковый номер и временная метка и без того являются случайными числами.

Алгоритмом шифрования по умолчанию является DES (Data Encryption Standard), работающий в режиме CBC (Cipher Block Chaining), как это описано в RFC-1423 [10.9], за исключением того, что используется заполнение, кратное 8 октетам. Инициализационный вектор равен нулю, так как для RTP-заголовка используются случайные числа. Более подробно о векторах инициализации можно прочесть в [10.10]. Приложения, которые применяют шифрование, должны поддерживать алгоритм DES в режиме CBC. Этот метод выбран потому, что он показал на практике свою эффективность при работе с аудио- и видеоприложениями в Интернет. Возможно применение и других криптографических средств.

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

Для обеспечения демультиплексирования RTP полагается на нижележащий протокольный уровень. Для UDP и сходных с ним протоколов RTP использует четные номера портов, а соответствующие RTCP-потоки — нечетные номера. Если приложению предлагается использовать нечетный номер RTP-порта, этот номер должен быть заменен на ближайший четный меньше исходного.

Информационные RTP-пакеты не имеют поля длины или каких-либо других средств ограничения размеров пакета, по этой причине RTP полагается на нижележащий протокол при задании размера поля данных. Максимальная длина RTP-пакетов ограничена размером используемых транспортных пакетов (например, UDP).

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

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

Константы, определяющие тип данных (PT) RTP-пакета, задаются профайлом, а не самим протоколом. Однако значение октета RTP-заголовка, который содержит бит(ы) маркера, не должно ни при каких обстоятельствах равняться 200 и 201 (десятичные), чтобы отличить RTP-пакеты от RTCP-пакетов типа SR и RR.

Использование протокола RTP в различных приложениях может предъявлять различные требования. Адаптация протокола к этим требованиям осуществляется путем выбора определенных параметров, применения различных расширений (см. рис. 10.5) или путем вариации формата на основе профайлов. Типовое приложение использует только один профайл. Спецификация формата поля данных определяет то, например, как, закодированный видеосигнал (H.261) должен переноситься RTP-пакетами.

В рамках RTP-стандарта определены следующие элементы поля данных (этот список не следует рассматривать, как окончательный).

Заголовок поля данных RTP. Октет RTP заголовка, содержащий маркер типа поля данных, может быть переопределен с помощью профайла (например, можно изменить число маркерных битов).

Типы поля данных. Профайл обычно определяет набор форматов поля данных (например, типов кодирования исходных данных) и соответствие между этими форматами и кодами типа поля данных. Для каждого описанного типа поля данных должна быть определена частота временных меток.

Дополнения к заголовку RTP. К стандартному RTP-заголовку могут быть добавлены новые поля, расширяющие функциональность приложения.

Расширения заголовка RTP. Структура содержимого первых 16 бит расширения RTP-заголовка должна быть определена профайлом (см. рис. 10.5).

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

Установка соответствия между строкой и ключом. Профайл может специфицировать, какому ключу шифрования соответствует введенный пользователем пароль.

Нижележащий протокол. Определяется нижележащий транспортный протокол, который служит для пересылки RTP-пакетов.

Транспортное соответствие. Соответствие RTP и RTCP адресам транспортного уровня, например, UDP-портам.

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

Не предполагается, что для каждого приложения требуется свой профайл. В пределах одного класса приложений целесообразно использовать расширения одного и того же профайла. Простое расширение, такое, как введение дополнительного типа поля данных или нового типа RTCP-пакета, может быть выполнено путем регистрации их через комитет по стандартным числам Интернет и публикации их описаний в приложении к профайлу.

Алгоритмы работы отправителя и получателя RTP-пакетов определены в RFC-3550 на примере кодов, написанных на языке СИ.

Чтобы посчитать частоту потерь пакетов, нужно знать ожидаемое и реально полученное число пакетов для каждого из источников. Число полученных пакетов определяется простым их подсчетом с учетом возможного дублирования и запаздывания. Ожидаемое число пакетов может быть подсчитано получателем как разность между наибольшим порядковым номером пакета ( s->max_seq ) и номером первого пакета в последовательности ( S->base_seq ). При этом нужно учитывать, что номера имеют 16 бит и по этой причине могут переполниться (число переполнений хранится в переменной s->cycles ).

extended_max = s>cycles + s>max_seq;
expected = extended_max  s>base_seq + 1;

Число потерянных пакетов определяется как разность между ожидаемым и реально полученным числом пакетов:

lost = expected  s>received;

Доля потерянных пакетов за отчетный период (с момента посылки предыдущего SR или RR пакета) вычисляется из разности ожидаемого и реально полученного числа пакетов за отчетный период, где expected_prior и received_prior представляют собой значения, записанные в момент подготовки предыдущего отчета:

expected_interval = expected  s>expected_prior;
s>expected_prior = expected;
received_interval = s>received  s>received_prior;
s>received_prior = s>received;
lost_interval = expected_interval  received_interval;
if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
else fraction = (lost_interval << 8) / expected_interval;

Результирующее значение доли потерянных пакетов равно 8-битовому числу с фиксированной запятой, расположенной слева.

10.4. Протокол управления RTP (RTCP)

Управляющий протокол RTCP (RTP control protocol; см. RFC-3550, "RTP: A Transport Protocol for RealTime Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и применяется лишь совместно с RTP (смотри также http://book.itep.ru/4/44/rtc_4493.htm). Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. RTCP выполняет четыре функции.

Функции 1-3 являются обязательными, когда RTP работает в среде с IP мультикастингом, и рекомендательными для всех остальных сред. Разработчикам приложений RTP рекомендуется избегать механизмов, которые могут работать только в уникастном режиме.

Формат пакетов RTCP

Стандарт определяет несколько типов RTCP пакетов, которые предназначены для переноса управляющей информации.

SR: Отчет отправителя. Для статистики приема и передачи участников, которые являются активными отправителями

RR: Отчет получателя. Для получения статистики от участников, которые не являются активными отправителями

SDES: Элементы описания источника, включая CNAME

BYE: Отмечает прекращение участия в группе

APP: Специфические функции приложения

Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется RTP-пакетами; за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например, UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол низкого уровня задаст общую длину и определит конец составного пакета.

Каждый индивидуальный RTCP пакет в составном пакете может обрабатываться независимо, без каких-либо требований к порядку или комбинации пакетов. Однако для того, чтобы выполнить функции протокола, накладываются следующие ограничения.

Таким образом, все RTCP-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат.

Префикс шифрования. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета.

SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, — в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP-пакетом в составной дейтограмме является Bye.

Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах.

SDES. SDES-пакет, содержащий CNAME, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционно добавлены, если этого требует характер приложения и позволяет пропускная способность используемого канала.

Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться.

Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников. Пример составного RTCP-пакета, который может быть сформирован смесителем, представлен на рис. 10.7. Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.

Приложение может игнорировать RTCP-пакеты неизвестного ему типа. Дополнительные типы RTCP-пакетов могут быть зарегистрированы IANA (Internet assigned numbers authority).

Протокол RTP построен так, чтобы позволять приложению изменять число участников от единиц до тысяч. Например, при аудиоконференциях информационный поток всегда ограничен (сколько бы ни было участников, все они одновременно говорить не могут, так как не смогут ничего понять). Однако трафик управления таким свойством не обладает. Если доклады о приеме от каждого участника поступают с постоянной частотой, трафик управления будет расти пропорционально числу участников. Следовательно, нужно принимать меры по ограничению трафика.

Для каждой сессии предполагается, что предельно допустимый информационный трафик сессии делится между участниками. Эта полоса пропускания может быть зарезервирована. Полоса не зависит от метода кодирования, но на выбор этого метода может оказать влияние имеющаяся в распоряжении полоса пропускания используемого канала. Определенные ограничения на полосу сессии может накладывать конкретное приложение. Вычисление полосы пропускания, необходимой для управления, требует учета издержек транспортных протоколов (например, UDP и IP).

Трафик управления должен быть ограничен малой долей полной полосы пропускания сессии: настолько малой, чтобы не нанести ущерба основной функции транспортного протокола — переносу информации. Предлагается, чтобы доля трафика сессии, выделенная на RTCP, была фиксирована на уровне не более 5%. Параметры, определяющие трафик, должны быть идентичными для всех участников, чтобы они могли корректно вычислить период рассылки отчетов. Эти параметры фиксируются в соответствующем профайле.

Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты.

Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания RTCP должна быть равна 5% от этого значения.

Вычисление периода рассылки RTCP-пакетов зависит от оценки числа узлов, участвующих в сессии. Новые узлы добавляются к этому числу, когда они услышаны и соответствующие записи занесены в таблицы SSRC или CSRC-идентификаторов. Новые записи не рассматриваются как действующие до тех пор, пока не будет получено несколько пакетов с новым SSRC. Записи могут быть стерты из таблицы, когда приходит пакет RTCP Bye с соответствующим идентификатором SSRC.

Участник может пометить другой узел как пассивный или удалить его из списка, если от него не получено RTP или RTCP-пакетов в течение нескольких периодов RTCP-отчетов (пороговое число периодов предлагается сделать равным 5). Это обеспечивает определенную устойчивость против случайной потери пакетов. Все узлы должны вычислить период RTCP-отчетов, чтобы корректно оценить время тайм-аута.

Если зарегистрированный узел помечен как пассивный, он будет оставаться в списках достаточно долго и учитываться при вычислении распределения полосы пропускания для RTCP. Значение тайм-аута предлагается сделать равным 30 минутам. Заметим, что это значение почти в 5 раз больше, чем наибольшая величина периода рассылки RTCP-отчетов, который составляет 2-5 мин.

Данная спецификация определяет несколько элементов описания источника (SDES). Сюда входит CNAME (каноническое имя), Name (персональное имя) и Email (электронный адрес). Спецификация предлагает также средства для определения типа RTCP-пакетов, особого для каждого конкретного приложения. Приложения должно проявлять определенную осторожность при выделении полосы для любой дополнительной информации, так как это неизбежно вызовет замедление скорости предоставления отчетов и задержит присылку. Рекомендуется, чтобы дополнительная информация индивидуального участника не занимала более 20% полосы, выделенной для RTCP. Более того, даже не предполагается, что все элементы SDES будут включаться каждым приложением. Например, приложение может посылать только CNAME, name и email и не отправлять более никакой дополнительной информации. Name может быть присвоен более высокий приоритет, чем email, так как name будет отображаться пользовательским интерфейсом приложения постоянно, в то время как E-mail может отображаться тол ько при запросе. При каждой RTCP рассылке должны посылаться RR- и SDES-пакеты. Последний содержит элемент CNAME. Для небольших сессий, работающих с минимальными периодами рассылки, это будет происходить в среднем каждые 5 секунд. Каждая третья рассылка (15 секунд) может содержать один дополнительный элемент в пакете SDES. Семь из восьми раз это будет элемент Name и каждый восьмой раз (2 минуты) — элемент E-mail.

Когда несколько приложений работают одновременно, например, в случае мультимедиа-конференции, допускается, чтобы дополнительная информация пересылалась только в рамках одной RTP-сессии. Остальные сессии будут использовать только элемент CNAME.

RTP-получатели обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственное различие между формами отчета отправителя (SR) и получателя (RR), помимо кода типа пакета: отчет отправителя содержит 20-байтовую секцию информации об отправителе. SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отсылается пакет RR.

Как SR, так и RR-формы включают в себя нуль или более блоков отчетов о приеме, по одному для каждого источника синхронизации, от которого получатель принял информационные RTP-пакеты с момента последнего отчета. Отчеты не направляются для источников, перечисленных в списке CSRC. Каждый блок отчета о приеме содержит статистику данных, полученных от конкретного источника. Так как в SR или RR-пакет можно поместить максимум 31 блок отчетов, дополнительные RR-пакеты укладываются после исходного SR или RR-пакета.

Пакет отчета отправителя состоит из трех секций (см. рис. 10.8), за которыми может следовать четвертая, определяемая, если необходимо, профайлом. Первая секция — заголовок, имеет 8 октетов. Эта секция содержит следующие поля.

Версия (v): 2 бита

Идентифицирует версию протокола RTP, которая совпадает с версией RTCP-пакетов. Для данной спецификации v=2.

Заполнитель (P): 1 бит

Если бит заполнителя P=1, то этот пакет RTCP содержит некоторые октеты заполнителя после управляющей информации. Последний октет заполнителя содержит число октетов заполнителя. Заполнитель может быть нужен при некоторых алгоритмах шифрования, использующих фиксированные блоки. В составных RTCP-пакетах заполнитель может быть нужен только последнему пакету, так как составной пакет шифруется как целое.

Число отчетов о приеме (RC): 5 бит

Число блоков отчетов о приеме, содержащихся в этом пакете. Допустимо значение нуль.

Тип пакета(PT): 8 бит

Содержит константу 200 для пакетов RTCP SR.

Длина: 16 бит

Длина RTCP-пакета в 32-битных словах минус один, включая заголовок и заполнитель.

SSRC: 32 бит

Идентификатор источника синхронизации для отправителя SR-пакета.

Вторая секция информации из 20 октетов присутствует в каждом пакете отправителя. Поля этой секции имеют следующие значения.

Временная метка NTP: 64 бита

Указывает абсолютное время, когда данный доклад был послан; оно может быть использовано в комбинации с временными метками, присланными в докладах о приеме другими получателями, для измерения RTT до этих получателей.

Временная метка RTP: 32 бита

Соответствует тому же времени, что и временная метка NTP, но измеряется в тех же единицах и с тем же произвольным смещением, что и временные метки информационных пакетов RTP. Это соответствие может использоваться для внутри- и межсредовой синхронизации для источников, чьи временные метки NTP синхронизованы, и может применяться получателями, не зависящими от среды для оценки номинальной задающей частоты RTP. Заметьте, что в большинстве случаев эти временные метки не будут равны временным меткам RTP в любых последовательных информационных пакетах.

Число пакетов отправителя: 32 бита

Полное число информационных RTP-пакетов, переданных отправителем от начала передачи до момента генерации SR-пакета. Число сбрасывается в нуль, если отправитель изменяет свой SSRC-идентификатор.

Число октетов отправителя: 32 бита

Полное число октетов поля данных (исключая заголовки и заполнители), переданных в информационных RTP-пакетах отправителем, начиная с начала передачи до момента генерации SR-пакета. Это число сбрасывается в нуль, когда отправитель меняет свой SSRC-идентификатор. Оно может быть использовано для оценки среднего потока данных.

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

SSRC_n (идентификатор источника): 32 бита

SSRC -идентификатор источника, к которому относится информация, содержащаяся в блоке отчета о получении.

Доля потерянных (пакетов): 8 бит

Часть информационных RTP-пакетов от источника SSRC_n, потерянная с момента посылки предыдущего SR или RR-пакетов, представленная в виде числа с фиксированной запятой слева. Это эквивалентно целому, полученному после умножения данного числа на 256. Эта доля получается в результате деления числа потерянных пакетов на ожидаемое число пакетов. Если потери из-за дубликатов оказались отрицательными, доля потерянных пакетов объявляется равной нулю. Заметим, что от источника, все пакеты которого были потеряны при транспортировке, отчета о приеме послано не будет.

Суммарное число потерянных пакетов: 24 бита

Полное число информационных RTP-пакетов от источника SSRC_n, которые были потеряны с момента начала передачи. Это число определяется как разность между ожидаемым и полученным числами пакетов, где число полученных включает в себя и дубликаты. Таким образом, пакеты, пришедшие с опозданием, не считаются потерянными, а число потерянных пакетов может оказаться отрицательным, если получены дубликаты пакетов. Число ожидаемых пакетов определяется как разность между номером последнего полученного пакета и номером первого пакета.

Наибольший номер из числа полученных пакетов: 32 бита

Младшие 16 бит содержит наибольший порядковый номер полученного от источника SSRC_n информационного RTP-пакета. Старшие 16 бит несут в себе число циклов нумерации (переполнения счетчика номеров пакетов). Заметим, что различные получатели в рамках одной и той же сессии генерируют разные коды циклов нумерации (расширений), если они начали свою работу в разное время.

Разброс времени доставки: 32 бита

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

Если si равно временной метке i -го пакета RTP, а ri — время прибытия в единицах временной метки пакета i, тогда для двух пакетов i и j D может быть выражено как

Di,j =(rjri)(sjsi)=(rjsj)(risi)

Разброс времени доставки вычисляется непрерывно для каждого пребывающего от SSRC_n пакета i, используя разность D для данного пакета и предыдущего пакета i-1 согласно формуле

j=j+(|Di-1,i|j)/16

Вычисление разброса времени доставки позволяет мониторам, не зависимым от профайла, осуществлять интерпретацию докладов, приходящих от различных приложений. Этот алгоритм является оптимальным первым приближением, а масштабный параметр 1/16 обеспечивает приемлемое уменьшение влияние шума и разумную скорость сходимости [4].

Последняя временная метка (LSR = last SR): 32 бита

Средние 32 бита из 64 во временной метке NTP, полученной как часть последнего отчета RTCP-отправителя (SR) об источнике SSRC_n. Если SR пока не получено, в поле заносится нуль.

Задержка с момента последнего SR (DLSR = delay of last SR): 32 бита

Задержка, выраженная в единицах 1/65536 секунды, между моментом получения последнего SR-пакета от источника SSRC_n и временем посылки блока отчета о приеме. Если ни одного пакета SR от SSRC_n пока не получено, в поле DLSR заносится нуль.

Пусть SSRC_r обозначает получателя, отправляющего отчет о приеме. Источник SSRC_n может вычислить RTT для SSRC_r путем записи времени a, когда этот блок доклада о приеме был получен. Он вычисляет полное время RTT A-LSR, используя поле последней временной метки SR (LSR), и затем путем вычитания получает (A-LSR-DLSR). Это проиллюстрировано на рис. 10.9.

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

rr: RTCO-пакет отчета о приеме (RFC-1889)

Формат пакета отчета о приеме (RR) аналогичен формату SR пакета, за исключением того, что поле типа содержит код 201 и опущены первые пять слов информации об отправителе (это NTP/RTP временные метки, а также число пакетов и октетов отправителя). Остальные поля имеют то же самое значение, как и для пакета SR.

Когда нет информации об отправке или приеме, в начало составного RTCP-пакета вставляется пустой RR-пакет ( RC = 0 ).

Профайл должен определять специфические для приложения расширения в докладах получателей и отправителей, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно сообщаться. Этот метод предпочтительнее, чем описание нового типа RTCP-пакета, так как не требует дополнительных издержек:

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

Ожидается, что качество обратной связи важно не только для отправителя и получателей, но и для независимых мониторов. Отправитель может модифицировать свою передачу на основе обратной связи, получатели могут определить, являются ли проблемы локальными, региональными или глобальными. Менеджер сети может использовать независимые мониторы, которые получают только RTCP-пакеты, а не соответствующие информационные RTP-пакеты, для оценки эксплуатационных параметров своей сети для мультикастного обмена.

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

Для RTCP допустимо расщепление составных пакетов на пакеты нижележащего уровня: один зашифрованный и один открытый. Например, информация SDES может быть зашифрована, в то время как отчеты о приеме будут посылаться открыто для обеспечения мониторинга. В примере, представленном на рис. 10.11, информация SDES должна быть присоединена к RR-пакету, не содержащему отчета. Таким образом, соблюдается правило о том, что все составные пакеты начинаются с SR или RR пакетов.

SDES: RTCP-пакет описания источника

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

Поля версия (V), заполнитель (P) и длина имеют то же назначение, что и в случае SR-пакетов.

Тип пакета (PT): 8 бит

Содержит константу 202, которая идентифицирует данный пакет как RTCP SDES.

Число источников (SC): 5 бит

Число фрагментов SSRC/CSRC, содержащихся в данном SDES-пакете. Значение нуль допустимо, но бесполезно.

Каждый фрагмент состоит из идентификатора SSRC/CSRC, за которым следует список элементов описания источника SSRC/CSRC (число элементов может равняться нулю). Каждый фрагмент начинается на 32-битовой границе. Каждый элемент состоит из 8-битового поля типа, 8-битового поля числа октетов, характеризующего длину текста, исключая эти 2 октета заголовка, и собственно текста. Заметьте, что текст не может содержать более 255 октетов, но это вполне согласуется с требованиями ограничений на полосу, выделяемую для RTCP-пакетов.

Текст кодируется согласно требованиям UTF-2, определенным в стандарте 10646 [10.5],[10.6], annex F ISO. Эта кодировка известна также под названием UTF-8 или UTF-FSS. Она описана в документе "File System Safe UCS Transformation Format (FSS_UTF)", "X/open preliminary specification", документ номер P316 и "Unicode Technical Report #4". US-ASCII являются модификациями данного кодирования и требуют определенных доработок. Присутствие многооктетного кодирования задается путем установления старшего бита октета символа равным 1.

Описания элементов плотно прилегают друг к другу, т.е., их описания не выравниваются на 32-битовые границы путем индивидуального заполнения. Текст не завершается нулем, так как мультиоктетное кодирование может включать в себя нули. Список элементов в каждом фрагменте завершается одним или несколькими нулевыми октетами, первый из которых интерпретируется как тип элемента нуль, завершающий список, а последующие служат для заполнения до 32-битовой границы. Фрагменты, содержащие только нулевые элементы (4 нулевых октета), допускаются, но бесполезны.

Оконечные системы посылают один пакет SDES, содержащий их собственный идентификатор источника (то же, что и SSRC в фиксированных RTP-заголовках). Смеситель посылает один пакет SDES, содержащий фрагмент для каждого источника, от которого поступает SDES-информация, или несколько SDES-пакетов описанного выше формата в случае, когда число таких источников больше 31.

Из числа SDES-элементов только СNAME является обязательным. Некоторые элементы, описанные ниже, могут оказаться полезными только для определенных профайлов, но типы элементов выделяются из общего кодового пространства, чтобы обеспечить совместную работу различных приложений. Дополнительные элементы могут быть определены в профайле путем регистрации их кодов IANA.

CNAME: Канонический идентификатор конечной системы (рис. 10.13).

Идентификатор CNAME имеет следующие свойства.

Следовательно, CNAME должно по возможности получаться алгоритмически, а не вводиться вручную. Чтобы удовлетворить этому требованию, следует использовать описанный ниже формат, если другой синтаксис или семантика не заданы. Элемент CNAME должен иметь формат user@host, или host, если имя пользователя не доступно, как это бывает в однопользовательских системах. Для обоих форматов host является либо полным именем домена ЭВМ, откуда поступают данные в реальном масштабе времени, форматированные согласно требованиям документов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [10.9]; либо стандартным ASCII-представлением цифрового, сетевого адреса интерфейса ЭВМ, используемого для RTP-обмена: например, стандартное ASCII-представление IP-адреса (версия 4) в точечно-цифровом виде. Стандартное полное имя домена более удобно для человека и исключает необходимость посылать в дополнение элемент Name, но в некоторых обстоятельствах его может быть трудно или невозможно пол учить. Примерами могут служить dwarf@sleepy.beauty.com или dwarf@192.166.148.9 для мультипользовательских систем. В системах, где нельзя получить имя пользователя, можно применить sleepy.beauty.com или 192.166.148.9.

Имя пользователя должно иметь форму, которая может быть использована в запросах Finger или Talk, — т.е., это скорее имя, вводимое при аутентификации, чем истинное имя пользователя. Имя ЭВМ не обязательно идентично электронному почтовому адресу участника.

Этот синтаксис не обеспечит уникальности имени в тех случаях, когда приложение позволяет пользователю сформировать несколько источников на своей ЭВМ. Такое приложение должно полагаться на SSRC для дополнительной идентификации источника или на профайл, для которого приложение должно специфицировать синтаксис идентификаторов CNAME.

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

Разработчики приложений должны учитывать возможность того, что использование сетевого адреса, например, для Net-10 (описано в документе RFC-1597 [10.10]) может привести к появлению имен-дубликатов. Дубликаты имен могут возникать, когда ЭВМ с частными адресами, не имеющие выхода в Интернет, переадресуют свои RTP-пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-1627 [10.11].) Чтобы разрешать такие конфликты, приложение должно иметь средства для выработки и присвоения уникальных имен CNAME.

Name: Имя пользователя (рис. 10.14).

Это настоящее имя, используемое для описания источника, например, "Иван Дурак, russia.com". Оно может быть сформировано пользователем в произвольной форме. Для приложений типа конференций эта форма имени может быть наиболее желательной при отображении в списках участников и, следовательно, может посылаться более часто, чем любые другие элементы помимо CNAME. Такой приоритет может быть установлен профайлом. Значение NAME предполагается неизменным, по крайней мере, в пределах сессии. В то же время не требуется, чтобы оно было уникальным для группы участников сессии.

Email: Адрес электронной почты (рис. 10.15).

Адрес электронной почты должен иметь формат, согласующийся с требованиями документа RFC-822, например, ivan.durak@itep.ru. Значение элемента Email предполагается неизменным в пределах сессии.

phone: Телефонный номер

Телефонный номер должен иметь формат с символом плюс, замещающим международный код. Например, +7 095 129 9442 для номера в России.

LOC: Географический адрес пользователя

Различная детализация этого элемента сильно зависит от приложения. Для использования во время конференций строки типа "Zuzino, Moscow" может быть достаточно, в то время как для активной системы поиска сотрудников приемлемой может стать строка "room 205, itep bl 143". Значение LOC предполагается неизменным на время сессии. Исключение могут составлять мобильные ЭВМ.

TOOL: Имя приложения или программного средства

Строка, сообщающая имя и, возможно, версию приложения, формирующего поток, например, "VC 2.1". Эта информация может быть полезной для отладочных целей и сходна с SMTP-заголовками. Предполагается, что значение TOOL остается постоянным в течение сессии.

Note: Уведомление/статус

Для этого элемента предлагается следующая семантика (она может быть определена профайлом). Элемент NOTE предназначен для сообщений, характеризующих текущее состояние источника, например, "on the phone, can't talk". Или, во время семинара этот элемент может быть использован для передачи темы обсуждения. Он может служить только для передачи необычной информации и не должен включаться в систематическую рассылку, так как замедлит скорость передачи отчетов. В частности, он не должен включаться в конфигурационный файл пользователя.

Так как может быть важно отобразить элемент Note (в случае, когда он активен), скорость, с которой передаются другие элементы (кроме CNAME), может быть уменьшена ради того, чтобы передать элемент Note. Когда сообщение становится не актуальным, элемент NOTE передается еще несколько раз с той же частотой, но с длиной строки, равной нулю. Однако получатели должны рассматривать элемент Note как потерявший актуальность, если они не получают его, например, на протяжении 20-30 RTCP-интервалов.

PRIV: Элемент частного расширения SDES

Этот элемент используется, чтобы описать экспериментальные или специфические для приложения расширения SDES. Элемент содержит префикс, включающий в себя субполя длины и строки префикса, за которыми следует строка значения, занимающая остальное пространство элемента и несущая необходимую информацию. Поле длины префикса занимает 8 бит. Строка префикса представляет собой имя, определенное человеком, который сформировал элемент PRIV. Это имя должно быть уникальным, и никакой другой элемент PRIV не может иметь такое же. Разработчик приложения может выбрать имя приложения и, если необходимо, субтип дополнения.

Заметьте, что префикс занимает некоторое количество из 255 октетов элемента, поэтому желательно, чтобы он был короче.

Префиксы SDES PRIV не нужно регистрировать в IANA. Если некоторая форма элемента PRIV окажется достаточно универсальной, она должна быть приписана некоторому регулярному типу элемента SDES, зарегистрированному IANA, так что необходимость в префиксе отпадет. Это упростит использование и увеличит эффективность передачи.

Bye: Пакет завершения сессии RTCP

Пакет Bye указывает на то, что один или более источников покинули сессию.

Поля версия (V), заполнитель (P) и длина имеют те же назначения, что и в случае SR-пакетов

Тип пакета (PT): 8 бит

Содержит код 203, который указывает на то, что это RTCP пакет Bye.

Число источников (SC): 5 бит

Число фрагментов SSRC/CSRC, содержащихся в данном пакете. Значение нуль допустимо, но бесполезно.

Если пакет bye получен смесителем, он переадресует этот пакет с идентификаторами SSRC/CSRC без изменений. Если сам смеситель отключается, он должен послать пакет Bye, перечислив все источники, вносившие вклад в поток, с которым он работал, а также свой идентификатор SSRC. Опционно пакет Bye может содержать 8-битовое число октетов, за которым следует текст соответствующей длины, объясняющий причину отключения, например, "camera malfunction" или "RTP loop detected". Строка имеет то же кодирование, что описано для SDES. Если строка заполняет пакет до очередной 32-битовой границы, то в конце ее не будет нуля. В противном случае, пакет Bye дополняется нулевыми октетами.

APP: RTCPпакет, определенный приложением

Пакет APP предназначен для экспериментального использования при разработке новых приложений или новых функций. Здесь не требуется регистрации типа пакета. APP-пакеты с неузнанными именами должны игнорироваться. После тестирования, когда предполагается широкое использование, рекомендуется новый APP-пакет переопределить без субтипа и поля имени, затем его следует зарегистрировать в IANA (Internet Assigned Numbers Authority) как новый тип RTCP-пакета.

Поля версия (V), заполнитель (P) и длина имеют те же назначения, что и в случае SR-пакетов.

Субтип: 5 бит

Может использоваться в качестве субтипа, допуская описание набора APP-пакетов с уникальным именем, или для любых данных, специфических для конкретного приложения.

Тип пакета (PT): 8 бит

Содержит код 204, который указывает на то, что это RTCP пакет APP.

Имя: 4 октета

Имя, выбираемое разработчиком, который определил набор APP-пакетов. Это имя должно быть уникальным и не совпадать ни с одним другим именем другого APP-пакета данного приложения. Разработчик приложения может использовать для этой цели имя приложения, при этом новые типы пакетов приложения будут отличаться друг от друга кодом субтипа. Имя интерпретируется как последовательность четырех ASCII-символов, где строчные и прописные буквы не являются тождественными.

Поле информация, зависящая от приложения, имеет переменную длину.

Информация, зависящая от приложения, используется в APP-пакетах опционно. Она интерпретируется приложением, а не самим RTP. Размер поля должен быть кратным 32 бит.

Обработка RTCP в трансляторах

Кроме переадресации информационных пакетов (иногда с некоторой модификацией) трансляторы и мультиплексоры должны также обрабатывать RTCP-пакеты. Во многих случаях они разделяют на составные части комбинированные RTCP-пакеты, полученные от оконечных систем, собирают SDES-информацию и модифицируют SR или RR-пакеты. Пересылка этой информации может инициироваться приходом пакета или RTCP-таймером транслятора или смесителя.

Транслятор, который не модифицирует информационные пакеты, например, такой, который осуществляет связь между мультикастными и уникастными адресами, может просто переадресовывать RTCP-пакеты. Транслятор, который каким-то образом модифицирует поле данных, должен выполнить соответствующие преобразования в SR и RR-информации так, чтобы она отражала качество приема. Такие трансляторы не должны просто переадресовывать RTCP-пакеты. Вообще транслятор не должен объединять SR и RR-пакеты от различных источников, так как это ухудшит точность измерения задержки распространения, использующего поля LSR и DLSR.

Информация отправителя SR. Транслятор не генерирует своей собственной информации отправителя, а переадресует SR-пакеты, полученные из одной области и адресованные в другие области. SSRC остается неизменным, но, если необходима трансляция, информация отправителя должна быть модифицирована. Если транслятор изменяет кодировку данных, он должен изменить поле число октетов отправителя. Если он объединяет несколько информационных пакетов в один, то нужно изменить поле число пакетов отправителя. Если он изменяет частоту временных меток, нужно модифицировать поле временная метка RTP в SR-пакете.

Блоки отчетов о приеме SR/RR. Транслятор переадресует доклады о приеме, полученные из одной области сети, в другие. Заметим, что эти сообщения движутся в направлении, противоположном данным. SSRC при этом остается неизменным. Если транслятор объединяет несколько информационных пакетов в один выходной пакет и, следовательно, изменяет номер по порядку, он должен позаботиться о модификации полей потерянных пакетов и наибольший номер из числа полученных пакетов.

Транслятор не нуждается в своем собственном SSRC-идентификаторе, но может и завести такой идентификатор, чтобы посылать отчеты о том, что получено. Такие отчеты будут посылаться во все области сети, подключенные к транслятору.

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

BYE. Трансляторы переадресуют пакеты BYE без изменений. Трансляторы, имеющие свой собственный SSRC, должны генерировать пакеты BYE с этим SSRC-идентификатором, если они намереваются прекратить свою работу по переадресации.

APP. Трансляторы переадресовывают APP-пакеты без каких-либо изменений.

Обработка RTCP в смесителях

Так как смеситель генерирует свой собственный информационный поток, он не пропускает через себя SR или RR-пакеты и вынужден формировать новые пакеты для отправки в обоих направлениях.

Информация отправителя SR. Смеситель не пропускает через себя данные об отправителе от источников, которые он объединяет, так как характеристики потока при смешении кардинально меняются. Как источник синхронизации смеситель генерирует свои собственные SR-пакеты с информацией отправителя и посылает их в том же направлении, что и смешанный поток.

Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую.

SDES. Смесители обычно переадресуют без изменений SDES-информацию, которую они получают из сетевых областей зоны обслуживания, но могут в случае ограничения полосы пропускания отфильтровывать любую SDES-информацию помимо CNAME. CNAME должны доставляться, чтобы обеспечить работу по обслуживанию столкновений идентификаторов SSRC. Идентификатор в списке CSRC, сгенерированный смесителем, может вызвать столкновение с SSRC-идентификатором, сформированным оконечной системой. Смеситель должен послать SDES CNAME информацию о самом себе той сетевой области, куда он посылает SR или RR пакеты.

Так как смесители не переадресуют SR- или RR-пакеты, они обычно извлекают SDES-пакеты из составных RTCP-пакетов. Для того, чтобы минимизировать издержки, фрагменты из SDES-пакетов могут быть уложены в один SDES-пакет, который вкладывается в SR- или RR-пакет, посылаемый смесителем.

Смеситель, который не вводит идентификаторы CSRC, может также воздерживаться от пересылки SDES CNAME. В этом случае пространства идентификаторов SSRC для обеих сетевых областей оказываются независимыми.

BYE. Смесители должны переадресовывать пакеты BYE. Они должны генерировать пакеты BYE со своим собственным идентификатором SSRC, если они намериваются прервать пересылку пакетов.

APP. Обработка APP-пакетов смесителями зависит от вида приложения.

Эти значения типов были выбраны в диапазоне 200-204 для улучшенного контроля корректности заголовков RTCP пакетов. Когда поле типа пакета RTCP сравнивается с соответствующим октетом RTP-заголовка, этот диапазон соответствует маркерному биту 1 (который обычно отсутствует в информационных пакетах) и старшему биту стандартного поля типа данных, равному 1 (так как статические типы поля данных обычно лежат в младшей половине).

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

Типы пакетов RTCP. Могут быть определены и зарегистрированы в IANA новые, специфические для определенных классов приложений типы пакетов RTCP.

Период отчетов RTCP. Профайл должен специфицировать, какие значения констант будут использоваться для вычисления периода посылки RTCP докладов. Этот период определяет долю полосы пропускания выделенной для RTCP.

Расширения SR/RR. Секция расширения может быть определена для RTCP SR- и RR-пакетов, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно передаваться.

Проверка корректности заголовка RTCP

Пакеты RTCP подвергаются следующим проверкам.

10.5. Протокол резервирования ресурсов RSVP

Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205, 2210, 274547, 3182, смотри также http://book.itep.ru/ 4\44\rsv_4496.htm) используется ЭВМ для того, чтобы запросить для приложения определенный уровень качества сетевых услуг QoS (Quality of Service, например, определенный уровень полосы пропускания). RSVP применяется также маршрутизаторами для доставки QoS-запросов всем узлам вдоль пути информационного потока, а также для установки и поддержания необходимого уровня услуг (например, для приложений IP-телефонии). Функция этого протокола крайне важна и многообразна, и именно поэтому он — один из самых сложных протоколов.

Протокол RSVP обеспечивает интегрированный стиль резервирования сетевых ресурсов (IntServ).

В 1994 году группа IETF сформировала рабочую группу по интегрированным услугам (Intserv Working Group). Целью группы было расширение спектра услуг Интернет. Интегрированные услуги предполагают сигнальный механизм информирования вовлеченных сетевых устройств о необходимом качестве обслуживания. RSVP стал сигнальным протоколом для архитектуры IntServ. Хотя первоначально RSVP был предназначен для мультимедийных систем, этот протокол может успешно использоваться и для таких сетевых систем, как NFS или VPN.

RSVP запрашивает ресурсы только для одного из направлений трафика и только по указанию получателя. RSVP работает поверх IPv4 или IPv6. Протокол относится к числу управляющих, а не транспортных.

Протокол RSVP предназначен для работы с существующими и будущими маршрутными протоколами, управляющими как обычными, так и мультикастными потоками. В последнем случае ЭВМ сначала посылает IGMP-запрос, чтобы подключиться к мультикастинг-группе, а затем уже RSVP-сообщение для резервирования ресурсов по маршруту доставки.

Механизм обеспечения QoS включает в себя классификацию пакетов, административный контроль и диспетчеризацию. Классификатор пакетов определяет QoS класс (а иногда и маршрут движения) для каждого пакета. В процессе реализации резервирования RSVP-запрос проходит два местных управляющих модуля: контроль доступа и управление политикой. Контроль доступа определяет, имеет ли узел достаточно ресурсов для удовлетворения поступившей заявки. Управление политикой определяет, имеет ли пользователь административное разрешение сделать данное резервирование. Если обе проверки завершились успешно, параметры передаются классификатору пакетов и интерфейсу канального уровня (диспетчеру пакетов). Если же какой-либо из тестов не прошел, программа RSVP присылает прикладному процессу сообщение об ошибке.

Структура и содержимое параметров QoS документировано в спецификации RFC-2210. Так как число участников группы, а также топология связей меняется со временем, структура RSVP предполагает адаптацию ЭВМ и маршрутизаторов к этим изменениям. Для этой цели RSVP периодически посылает сообщения для поддержания необходимого состояния вдоль всего маршрута обмена. При отсутствии этих сообщений происходит тайм-аут, и резервирование аннулируется. Обобщая, можно сказать, что RSVP имеет следующие атрибуты:

Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме. Схема работы процесса RSVP показана на рис. 10.23.

Потоки данных

RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой.

Сессия RSVP описывается тремя параметрами: DestAddress, ProtocolId DstPort. DestAddress — IP-адрес места назначения информационных пакетов (уникаст или мультикаст). ProtocolId — идентификатор IP протокола. Опционный параметр DstPort — обобщенный порт места назначения, т.е. еще одна точка демультиплексирования на транспортном или прикладном уровне. DstPort может быть определено полем порта места назначения UDP/TCP.

Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут иметь различные мультикаст-адреса. Однако, DstPort необходим, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя.

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

Модель резервирования

Простой запрос резервирования RSVP состоит из flowspec (спецификация потока) и filter spec (спецификация фильтра); эта комбинация называется описателем потока. Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов.

Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра — для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра, обрабатываются без гарантий обеспечения оговоренного QoS.

Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:

В Tspec могут входить: IP-адрес отправителя, адрес получателя, номера портов получателя и отправителя, поле TOS и код транспортного протокола. Чем больше параметров входит в Tspec, тем сложнее задача транзитного маршрутизатора, тем больше и задержка. В случае IPv6 задача существенно упрощается (если ограничиться классификацией по меткам и не анализировать номера портов).

Форматы и содержимое Tspec и Rspec определяются общими моделями обслуживания [RFC-2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может применяться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

Так как номера портов UDP/TCP задействуются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Поэтому возможны три проблемы.

Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации. В каждом промежуточном узле запрос резервирования запускает две процедуры:

A. Резервирование канала

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

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

Б. Переадресация запроса назад

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

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

Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP посылаются вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

Стили резервирования

Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.

Другая опция резервирования контролирует выбор отправителей. В одних случаях каждому отправителю ставится в соответствие определенная спецификация фильтра, в других — таких спецификаций не требуется вовсе. В настоящее время определены следующие стили.

WF( * {Q}),

FF(S{Q}),

FF(S1{Q1}, S2{Q2}, ...)

SE((S1,S2,...){Q} )

Примеры стилей

На рис. 10.24. показан пример маршрутизатора с двумя входными интерфейсами IА и IБ, через которые проходят входные потоки, и двумя выходными интерфейсами IВ и IГ, через которые осуществляется переадресация входных потоков. Пусть существует три отправителя S1, S2 и S3, подключенные к интерфейсам IА и IБ, соответственно. Имеется три получателя R1, R2 и R3, которые маршрутизированы через выходные интерфейсы IВ и IГ, соответственно. Будем также предполагать, что интерфейс IГ подключен к широковещательной сети, а R2 и R3 достижимы через разные маршрутизаторы, не показанные на рисунке.

Здесь нужно специфицировать мультикастные маршруты в пределах узла, отображенного на рис. 10.24. Предположим сначала, что информационные пакеты от каждого из отправителей Si, показанных на рисунке, маршрутизованы на оба выходных интерфейса. При этих предположениях на рисунках 10.25, 10.26 и 10.27 проиллюстрированы стили резервирования WF, FF и SE соответственно.

Для простоты эти примеры показывают flowspec как одномерное кратное повторение некоторого базового качества ресурса B. Колонка "Резервирует" отображает запросы резервирования RSVP, полученные через выходные интерфейсы IВ и IГ, а колонка "Получает" — результирующее состояние резервирования для каждого интерфейса. Колонка "Посылает" показывает запросы резервирования, посланные предшествующим узлам (IА и IБ). В колонке "Резервирует" каждая рамка представляет один зарезервированный виртуальный канал с соответствующим дескриптором потока.

Рис. 10.25, демонстрируя стиль WF, приводит две ситуации, в которых требуется объединение.

На рис. 10.26 проиллюстрирован стиль резервирования FF (Fixed-Filter). У каждого выходного интерфейса имеется отдельное резервирование для каждого запрошенного источника, но это резервирование будет общим для всех получателей, которые послали запрос. Дескрипторы для получателей S2 и S3, полученные через выходные интерфейсы IВ и IГ, вкладываются в пакеты запросов, направляемых предыдущему узлу (IБ). С другой стороны, три различные дескриптора потоков, специфицирующих отправителя S1, объединяются в один запрос FF(S1{4B}), который посылается предыдущему узлу (IА).

На рис. 10.27 показан пример стиля резервирования SE. Когда резервирования стиля SE объединяются, результирующая спецификация фильтра является объединением исходных спецификаций, а результирующая спецификация flowspec равна наибольшей из flowspec.

Приведенные примеры предполагают, что информационные пакеты от S1, S2 и S3 маршрутизируются через оба выходных интерфейса. Нижняя часть рис. 10.24 показывает еще одно предположение о маршрутизации: информационные пакеты от S2 и S3 не переадресуются интерфейсу IВ, например, из-за того, что сеть обеспечивает более короткий путь для пакетов отправителя к R1. Рис. 10.25 показывает пример резервирования WF именно при этом предположении (стрелками отмечены допустимые маршруты). Так как нет пути от IБ к IВ, резервирование, переадресуемое интерфейсом IБ, рассматривает резервирование только для интерфейса IГ.

10.5.1. Механизмы протокола RSVP

Сообщения RSVP

На рис. 10.28 проиллюстрирована модель RSVP узла маршрутизатора. Каждый поток данных приходит со стороны предшествующего узла через соответствующий входной интерфейс и выходит из маршрутизатора через один или несколько выходных интерфейсов. Один и тот же интерфейс для разных потоков в пределах одной сессии может выполнять как входную, так и выходную роль. Несколько предшествующих узлов и/или последующих узлов могут для коммуникаций использовать один и тот же физический интерфейс; например, на рисунке два узла Г и Г' подключены к широковещательной сети через интерфейс IГ.

Существует два фундаментальных типа сообщений RSVP: Resv и Path. Каждый получатель посылает свой RSVP запрос резервирования в виде сообщений ( Resv ) отправителям данных. Эти сообщения должны двигаться в точности тем же маршрутом с учетом выбора отправителей, что и данные, только в противоположном направлении. Они создают и поддерживают состояние резервирования в каждом узле вдоль маршрута. Сообщения Resv должны быть в конце концов доставлены ЭВМ-отправителям, таким образом, ЭВМ устанавливают параметры управления трафиком.

Каждая ЭВМ-отправитель передает RSVP сообщения Path вдоль уникаст/мультикаст маршрутов, сформированных с помощью маршрутных протоколов. Эти сообщения Path запоминают состояние пути в каждом узле вдоль маршрута. Состояние пути включает в себя уникастный IP-адрес предыдущего узла, который используется для маршрутизации сообщений Resv от узла к узлу в противоположном направлении. Сообщение Path содержит также следующую информацию:

10.6. Объединение Flowspecs

Сообщение Resv, переадресованное предшествующему узлу, несет в себе спецификацию flowspec, которая является наибольшей из всех flowspec, запрошенных последующими узлами — получателями данных.

Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе, чтобы выполнить объединение спецификаций flowspec.

Заметим, что спецификации flowspecs представляют собой в общем случае многомерные векторы; они могут содержать как Tspec, так и Rspec компоненты, каждая из которых может сама быть многомерной.

Например, если один запрос требует высокой пропускной способности, а другой — жесткого ограничения задержек, то один не может быть "больше" другого. В таком случае, вместо взятия большего, прикладная программа объединения должна уметь сформировать такую спецификацию flowspec, которая по крайне мере столь же велика, как и каждая из составляющих; математически это наименьший верхний предел LUB (least upper bound). В некоторых случаях спецификация flowspec по крайне мере настолько мала, насколько нужно; тогда это наибольший нижний предел GLB (Greatest Lower Bound).

Для вычисления эффективного значения flowspec ( Re, Te ), инсталлируемого в интерфейс, используются следующие шаги [RFC-2210]. Здесь Te — эффективная спецификация Tspec, а Re — эффективная спецификация Rspec.

Гибкое состояние

RSVP использует подход soft state (гибкое состояние) для управления состоянием резервирования в маршрутизаторах и ЭВМ. Гибкое состояние RSVP создается и периодически обновляется посредством сообщений Path и Resv. Состояние уничтожается, если не приходит подтверждения в течение заданного времени таймаута очистки. Состояние может быть стерто также посредством сообщения teardown (уничтожение). По истечении каждого тайм-аута обновления и после любых изменений состояния RSVP осуществляет проверку, чтобы подготовить и отправить сообщения обновления Path и Resv последующим узлам.

Сообщения Path и Resv практически идемпотентны. Когда маршрут меняется, следующее сообщение Path инициализирует состояние прохода для нового маршрута, а последующие сообщения Resv установят для него резервирование. Состояние же на неиспользованном в данный момент сегменте маршрута будет аннулировано по тайм-ауту. Следовательно, определение того, является ли сообщение новым или обновляющим, принимается отдельно для каждого узла в зависимости от его текущего состояния.

Протокол RSVP посылает свои сообщения в виде IP-дейтограмм без какого-либо улучшения надежности. Периодическая передача сообщений обновления от ЭВМ и маршрутизаторов позволяет компенсировать случайные потери отдельных RSVP-сообщений. Если тайм-аут удаления установлен равным K периодам обновления, то RSVP может допускать потерю K-1 RSVP-пакетов подряд без аннулирования состояния. Механизм управления сетевым трафиком должен быть отконфигурирован так, чтобы предоставить минимальную полосу пропускания для сообщений RSVP и предотвратить их потерю из-за перегрузки канала.

Состояние, поддерживаемое RSVP, является динамическим. Для изменения набора отправителей Si или изменения любого запроса QoS, ЭВМ просто начинает посылать измененные сообщения Path и/или Resv. В результате будет осуществлено соответствующее изменение RSVP-состояния во всех узлах вдоль пути, а неиспользуемые состояния будут аннулированы по тайм-ауту, если не поступит прямых указаний по их ликвидации до этого.

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

Состояние, которое получено через конкретный интерфейс I*, никогда не должно переадресовываться этому интерфейсу. Состояние, которое направляется интерфейсу I*, должно вычисляться на основе состояний, полученных от других интерфейсов, исключая I*. Тривиальный пример, поясняющий это правило приведен на рис. 10.29, где показан маршрутизатор с одним отправителем и одним получателем на каждом интерфейсе (R1, S1 и R2, S2). Интерфейсы IA и IБ выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на рис. 10.29 "Получает" и "Отправляет" подразумевает внешнее направление по отношению к маршрутизатору).

Существует еще одно правило, которое управляет процессом переадресации сообщений Resv: состояние из сообщения Resv, полученное через выходной интерфейс Io, следует передавать входному интерфейсу Ii только в том случае, когда сообщение Path от Ii переадресовано к Io.

5.8. Аннулирование (Teardown)

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

Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.

Запрос аннулирование (teardown) может посылаться приложением оконечной системы (получатель или отправитель) или маршрутизатором в результате тайм-аута или при появлении привилегированной задачи. После инициализации запрос-аннулирование должен переадресовываться от узла к узлу без задержки. Сообщение аннулирования уничтожает специфицированное состояние в узле-получателе.

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

Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра. Например, в случае, показанном на рис. 10.29, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений.

Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы.

Ошибки

Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю — виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода.

Однако и для синтаксически верных запросов резервирования существует опасность быть отвергнутыми. Узел может решить аннулировать установленное резервирование из-за более приоритетных заданий. Так как неудовлетворение запроса может быть вызвано объединением нескольких запросов, ошибка резервирования должна быть ретранслирована всем получателям группы. Кроме того, объединение разнородных запросов создает потенциальную трудность, известную как проблема "резервирования килера", в которой один запрос может блокировать услуги другого. В действительности существует две такие проблемы.

Чтобы решить эту проблему, сообщения ResvErr устанавливают дополнительное состояние, называемое состоянием блокады, в каждом из узлов, через которые проходит это сообщение. Состояние блокады в узле модифицирует процедуру объединения так, чтобы игнорировать блокирующие спецификации flowspec (Q1 в вышеприведенном примере), позволяя скромным запросам проходить и осуществлять свое резервирование. Состояние резервирования Q1 считается в данном случае заблокированным.

Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены. Однако они были сохранены по следующим причинам:

Подтверждение

Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее. Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос. Этот механизм подтверждения имеет такую последовательность:

Управление политикой

Механизм управления политикой определяет, каким пользователям или приложениям позволено осуществлять резервирование и в каком объеме. RSVP-запросы QoS позволяют определенным пользователям получить предпочтительный доступ к сетевым ресурсам. Для предотвращения злоупотреблений необходима некоторая обратная связь. Такого рода связь может быть реализована с помощью административной политики обеспечения доступа или путем введения прямой или виртуальной оплаты резервирования. В любом случае требуется идентификация пользователя.

Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: "Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?" и "Позволено ли данному пользователю осуществлять резервирование?" Эти два решения называются "управлением доступа" и "управлением политикой", соответственно. Различные административные домены в Интернет могут иметь разные политики резервирования.

На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки могут включать в себя параметры доступа пользователя, его класс, номер акаунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов.

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

Безопасность

При использовании протокола RSVP возникают определенные проблемы безопасности.

Области, не поддерживающие RSVP

Невозможно развернуть протокол RSVP (или любой новый протокол) во всем Интернет одновременно. Более того, RSVP, вероятно, никогда не будет развернут повсеместно. RSVP должен гарантировать корректную работу, когда два RSVP-маршрутизатора объединены друг с другом через сетевую область, не поддерживающую этот протокол. Конечно, промежуточная сетевая область, лишенная поддержки RSVP, не способна осуществлять резервирование ресурсов. Однако если эта область обладает достаточной емкостью, она может обеспечить необходимый уровень услуг.

Протокол RSVP приспособлен для работы через такие, не поддерживающие его, сетевые области. Как поддерживающие, так и не поддерживающие RSVP маршрутизаторы переадресуют сообщения Path в соответствии с адресом места назначения, используя свои локальные таблицы маршрутизации. Следовательно, на маршрутизацию сообщений Path не оказывает влияние наличие промежуточных маршрутизаторов, лишенных RSVP-поддержки. Когда сообщение Path проходит через сетевую область, не поддерживающую RSVP, оно, направляясь к следующему узлу, поддерживающему RSVP, несет в себе IP-адрес последнего RSVP-маршрутизатора. Сообщение Resv тогда переадресуется непосредственно следующему RSVP-маршрутизатору на пути к отправителю.

Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг NonRSVP и передает его механизму управления трафиком. Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC-2210].

При некоторых топологиях маршрутизаторов с поддержкой RSVP и без нее возможна доставка сообщений Resv не в тот узел или не на тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, то оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е. интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно п опало.

Модель ЭВМ

Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор ( DestAddress, ProtocolId, DstPort ), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.

H1 Получатель посредством IGMP подключается к мультикаст-группе, заданной адресом DestAddress

H2 Потенциальный отправитель начинает посылать сообщения Path по адресу DestAddress

H3 Приложение получателя принимает сообщение Path

H4 Получатель начинает посылать соответствующие сообщения Resv, задавая дескрипторы нужных потоков

H5 Приложение отправителя получает сообщение Resv

H6 Отправитель начинает посылать информационные пакеты

Существует несколько соображений, касающихся синхронизации.

Получатель может просто игнорировать такие сообщения об ошибке или может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.

Функциональная спецификация RSVP. Формат сообщений RSVP

Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех) порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке.

Общий заголовок

В общем заголовке имеются следующие поля:

Vers. 4 бита — Номер версии протокола. В данном описании = 1.

Флаги: 4 бита — 0x01-0x08. Зарезервированы.

Флаги пока не определены.

Тип Msg. Тип сообщения (8 бит).

1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf

Контрольная сумма RSVP: 16 бит

Дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась.

Send_TTL: 8 бит

Значение TTL для протокола IP, с которым было послано сообщение.

Длина RSVP: 16 бит

Полная длина RSVP сообщения в байтах, включая общий заголовок и объекты переменной длины, которые за ним следуют.

Форматы объектов

Каждый объект состоит из одного или более 32-битных слов с 4-байтовым заголовком. Формат объекта показан на рис. 10.31:

Заголовок объекта имеет следующие поля.

Длина в байтах

16-битовое поле, содержащее полную длину объекта в байтах. Длина должна быть кратна 4 октетам, минимальное значение равно 4.

ClassNum

Идентифицирует класс объекта. Каждый класс объекта имеет свое имя, которое в данном документе записывается прописными буквами. Приложения RSVP должны распознавать следующие классы.

CType

Тип объекта, уникален в пределах класса Class-Num.

Максимальная длина объекта равна 65528 байт. Поля Class-Num и C-Тип могут использоваться совместно как 16-битовое число для определения уникального типа для каждого из объектов.

Старшие два бита Class-Num применяются для определения того, какие действия должен предпринять узел, если он не распознает Class-Num объекта.

Сообщения Path

Каждая ЭВМ-источник периодически отправляет сообщения Path для каждого из информационных потоков, берущих здесь свое начало. Это сообщение содержит объект SENDER_TEMPLATE, определяющий формат пакетов данных, и объект SENDER_TSPEC, специфицирующий характеристики трафика потока. Опционно сообщение может содержать объект ADSPEC, несущий в себе информацию о потоке (OPWA).

Сообщение Path направляется от отправителя к получателю по тому же маршруту, по которому движутся информационные пакеты. IP-адрес источника в сообщении Path должен характеризовать адрес отправителя, в то время как адрес места назначения должен быть равен DestAddress для текущей сессии. Эти адреса гарантируют, что сообщение будет корректно маршрутизовано даже через области сети, не поддерживающие RSVP. Формат сообщения Path имеет следующий вид:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]

Если присутствует объект INTEGRITY, он должен следовать непосредственно за стандартным общим заголовком. Не существует каких-либо иных ограничений порядка передачи, хотя упомянутое выше требование является рекомендательным. Число объектов POLICY_DATA может быть произвольным.

Объект PHOP (т.е., предыдущий RSVP_HOP ) каждого сообщения Path содержит адрес предшествующего узла, например, IP-адрес интерфейса, через который только что было послано сообщение Path. Он также содержит дескриптор логического интерфейса (LIH).

Каждый узел вдоль пути, поддерживающий RSVP, перехватывает сообщение Path и обрабатывает его с тем, чтобы сформировать состояние пути для отправителя, заданного объектами SENDER_TEMPLATE и SESSION. Любой из объектов POLICY_DATA, SENDER_TSPEC и ADSPEC также записываются в состояние пути. Если случилась ошибка при обработке сообщения Path, посылается сообщение PathErr первичному отправителю сообщения Path.

Периодически процесс RSVP в узле сканирует состояние прохода, чтобы сформировать новые сообщения Path для посылки их получателям. Каждое сообщение содержит дескриптор, характеризующий одного отправителя, и несет в себе IP-адреса отправителя.

Процесс RSVP переадресует и размножает (если требуется, — например, при мультикастинге) сообщения Path, используя маршрутную информацию, которую он получает от соответствующих процессов маршрутизации. Маршрут зависит от DestAddress сессии и для некоторых протоколов маршрутизации — от адреса источника. Маршрутная информация обычно включает в себя список выходных интерфейсов, куда должно направляться сообщение Path. Так как каждый выходной интерфейс имеет свой IP-адрес, сообщения Path, посланные разными интерфейсами, содержат отличные адреса PHOP. Кроме того, объекты ADSPEC, содержащие сообщения Path, будут отличаться для разных выходных интерфейсов.

Состояние пути для данной сессии и отправителя не обязательно должны иметь уникальные PHOP или уникальный входной интерфейс. Существует два случая, соответствующие мультикастной и уникастной сессиям.

Сообщения Resv

Сообщения Resv несут в себе запросы резервирования от узла к узлу, от получателей к отправителям в направлении, противоположном движению потока данных. IP-адрес места назначения сообщения Resv является уникастным адресом предшествующего узла, полученным из состояния прохода. IP-адрес источника является адресом узла, который посылает сообщение. Сообщение Resv имеет следующий формат:

<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>

Если присутствует объект INTEGRITY, он должен непосредственно следовать за общим заголовком. За объектом STYLE следует список дескрипторов потоков. Объекты в списке дескрипторов должны соответствовать требованиям, записанным в BNF.

Объект NHOP (напр., RSVP_HOP ) содержит IP-адрес интерфейса, через который посылаются сообщения Resv, и LIH для логического интерфейса, где требуется резервирование.

Появление объекта RESV_CONFIRM сигнализирует о запросе подтверждения резервирования и несет в себе IP-адрес получателя, которому должен быть послан ResvConf. Число объектов POLICY_DATA не лимитировано.

Ниже приведены правила, которые специфицируют структуру дескриптора потока для каждого из стилей резервирования.

<flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC>

<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ] <FILTER_SPEC>

<flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::=
<FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC>

Набор отправителей (reservation scope), которым направляется конкретный запрос резервирования, определяется следующим образом.

Когда сообщение Resv с произвольным выбором отправителя переадресуется более чем одному предыдущему узлу, в сообщение должен быть включен объект SCOPE. В этом случае список IP адресов для рассылки хранится именно в этом объекте.

Сообщение Resv, которое пересылается узлом, является в общем случае результатом объединения входящих сообщений Resv. Если одно из этих объединенных сообщений содержит объект RESV_CONFIRM и имеет число FLOWSPEC, большее, чем FLOWSPEC всех других объединенных запросов резервирования, тогда этот объект RESV_CONFIRM переадресуется в виде исходящего сообщения Resv. Объект RESV_CONFIRM из одного из объединенных запросов (чья спецификация flowspecs равна, меньше или сравнима с объединенной спецификацией flowspec и которая не подвергнута блокаде) запустит генерацию сообщения ResvConf, содержащего RESV_CONFIRM. Объект RESV_CONFIRM в запросе, который подвергнут блокаде, не будет переадресован или возвращен, он будет аннулирован в текущем узле.

Сообщения отмены прохода

Получение сообщения PathTear (path teardown) аннулирует состояния прохода. Соответствующее состояние должно согласовываться с объектами SESSION, SENDER_TEMPLATE и PHOP. Кроме того, сообщение PathTear для мультикастной сессии может соответствовать только состоянию прохода для входного интерфейса, через который получено сообщение PathTear. Если соответствия состоянию прохода нет, сообщение должно быть отброшено без дальнейшей рассылки.

Сообщения PathTear инициализируются непосредственно отправителем или в результате тайм-аута состояния прохода в каком-либо узле и направляются всем отправителям. Уникастное PathTear не должно переадресовываться, если состояние прохода соответствует той же сессии и отправителю, но имеет другой PHOP.

Сообщение PathTear должно маршрутизоваться в точности так же, как соответствующие сообщения Path. Следовательно, его IP-адрес места назначения должен совпадать с DestAddress, а его IP-адрес отправителя должен быть адресом, взятым из данных о состоянии прохода.

Сообщение PathTear может содержать в своем дескрипторе отправителя объект SENDER_TSPEC или ADSPEC, но они должны игнорироваться.

Удаление состояния прохода в результате получения сообщения PathTear или тайм-аута должно модифицировать состояние резервирования в данном узле. Эта модификация зависит от стиля резервирования. Например, предположим, что PathTear удаляет состояние прохода отправителя S. Когда стиль специфицирует явный выбор отправителя (FF или SE), всякое резервирование со спецификацией фильтрации, соответствующей отправителю S, должно быть удалено; когда стиль предусматривает произвольный выбор отправителя (WF), резервирование удаляется, если S является последним отправителем, участвующим в сессии. Эти изменения резервирования не должны вызвать немедленную посылку сообщения обновления Resv, так как сообщение PathTear уже вызвало необходимые изменения. Они не должны также вызвать отправку сообщения ResvErr, так как это может вызвать лавину таких сообщений.

Сообщения отмены Resv

Получение сообщения ResvTear (reservation teardown) вызывает удаление соответствующего состояния резервирования. При этом проверяется соответствие объектов SESSION, STYLE и FILTER_SPEC, а также LIH в объекте RSVP_HOP. Если соответствие не обнаружено, сообщение ResvTear игнорируется. Сообщение ResvTear может отменить любой субнабор спецификаций фильтрации в состояниях резервирования стилей FF или SE.

Сообщения ResvTear отправляются получателями или любым узлом, в котором состояние резервирование аннулируется в результате таймаута; далее они движутся в направлении получателей.

Сообщение ResvTear должно маршрутизироваться аналогично соответствующим сообщениям Resv, а его IP-адрес места назначения является уникастным адресом предыдущего узла.

Объекты FLOWSPEC в списке дескрипторов потоков сообщения ResvTear будут игнорироваться и могут быть опущены. Сообщение ResvTear может включать в себя объект SCOPE, но он должен игнорироваться.

В зависимости от изменения состояния узла получение сообщения ResvTear может вызвать переадресацию этого сообщения, посылку модифицированного сообщения Resv или не вызвать никакого сообщения. Эти три случая могут быть проиллюстрированы для стиля резервирования FF на рис. 10.26.

Сообщения об ошибке прохода

Сообщения PathErr (path error) несут в себе данные об ошибке в обрабатываемых сообщениях Path. Они направляются отправителям данных и маршрутизируются от узла к узлу, используя состояние прохода. При каждом шаге IP-адрес места назначения является уникастным адресом предыдущего узла. Сообщения PathErr не модифицируют состояния узлов, через которые проходят; они предназначаются только приложению отправителя.

Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил эту ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA.

Сообщения об ошибках Resv

Сообщения ResvErr (reservation error) сообщают об ошибках при обработке запросов Resv или о спонтанном нарушении резервирования, например, в результате административного вмешательства.

Сообщения ResvErr направляются соответствующим получателям, они маршрутизируются от узла к узлу с использованием состояния резервирования. В каждом из узлов в качестве IP-адреса места назначения используется уникастный адрес следующего узла.

Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA. Объект RSVP_HOP содержит адрес предыдущего узла, а объект STYLE копируется из сообщения Resv.

Следующие правила, зависящие от стиля резервирования, определяют структуру ошибки дескриптора потока.

<error flow descriptor> ::= <WF flow descriptor>

<error flow descriptor> ::= <FF flow descriptor>

<error flow descriptor> ::= <SE flow descriptor>

Заметим, что сообщение ResvErr содержит только один дескриптор потока. Следовательно, сообщение Resv, которое содержит N > 1 дескрипторов потока (стиль FF), может быть причиной N сообщений ResvErr.

Вообще говоря, сообщение ResvErr следует пересылать всем получателям, которые могут быть причиной данной ошибки. Конкретнее:

Сообщения подтверждения

Сообщения ResvConf посылаются в ответ на запрос подтверждения резервирования. Сообщение ResvConf посылается в результате появления объекта RESV_CONFIRM в сообщении Resv. Сообщение ResvConf посылается по уникастному адресу ЭВМ получателя, адрес берется из объекта RESV_CONFIRM.

Объект RESV_CONFIRM является копией объекта в сообщении Resv, который вызвал подтверждение. ERROR_SPEC используется только для переноса IP-адреса исходного узла в поле адрес узла с ошибкой (Error Node Address). Равенство кода ошибки и значения нулю свидетельствует о подтверждении. Список дескрипторов потоков специфицирует конкретное резервирование, которое подтверждается. Это может быть субнабор из списка дескрипторов потоков Resv, для которого запрошено подтверждение.

Использование портов

Сессия RSVP определяется в нормальной ситуации тремя параметрами: DestAddress, ProtocolId, DstPort. Здесь DstPort является полем порта назначения UDP/TCP. DstPort может быть опущен (сделан равным нулю), если ProtocolId специфицирует протокол, который не имеет поля порта места назначения.

RSVP допускает любое значение для ProtocolId. Однако реализации оконечных систем RSVP могут знать об определенных значениях для этого поля и, в частности, о значениях для UDP и TCP (17 и 6 соответственно). Оконечная система может выдать сигнал ошибки приложению, которая:

Спецификации фильтра и шаблоны отправителя определяют пару: SrcAddress, SrcPort, где SrcPort — поле UDP/TCP порта. В некоторых случаях SrcPort может быть опущен (установлен равным нулю). Существуют следующие правила использования нулевого значения полей DstPort и/или SrcPort в RSVP.

Посылка сообщений RSVP

Сообщения RSVP посылаются от узла к узлу между RSVP-маршрутизаторами, поддерживающими этот протокол, в виде IP-дейтограмм с кодом протокола 46. IP-дейтограммы предназначены также для использования между оконечными системами и первыми/последними маршрутизаторами.

Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках.

По прибытии RSVP-сообщения M, которое меняет статус, узел должен немедленно послать сообщение о модификации состояния. Однако это не должно привести к посылке сообщения через интерфейс, откуда пришло M (что может случиться, если приложение запустит процедуру обновления состояний для текущей сессии). Это правило предотвращает лавину пакетов в сетях с широковещательной рассылкой.

Каждое RSVP-сообщение должно пересылаться только в одной IP-дейтограмме. Если оно превосходит MTU, такая дейтограмма будет фрагментирована. Восстановление сообщения будет произведено узлом-получателем. Это имеет несколько следствий.

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

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

Исключение циклов сообщений RSVP

Переадресация сообщений RSVP должна исключать возможность образования петель. В спокойном состоянии сообщения Path и Resv направляются каждому узлу только раз за период обновления. Это исключает зацикливание пакетов, но имеется еще возможность петель автоматического обновления. Такие петли сохраняют состояние вечно, даже если оконечные узлы прекращают их обновление до тех пор, пока получатели не покинут мультикастинг-группу и/или отправители прекратят посылку сообщения Path. С другой стороны сообщения об ошибке и об аннулировании (teardown) посылаются немедленно и могут служить причиной возникновения циклов. Рассмотрим каждый тип сообщения.

Если топология не содержит петель, зацикливания сообщений Resv и ResvErr при произвольном выборе отправителя можно избежать, следуя приведенному выше правилу: состояние, которое получено через определенный интерфейс, никогда не должно переадресовываться через этот же интерфейс. Однако когда топология содержит петли, необходимы дополнительные усилия для предотвращения циклов автоматического обновления для сообщений Resv и ResvErr с произвольным выбором отправителя. Решением этой проблемы может быть включение списка адресов получателей в объект SCOPE.

Когда сообщение Resv со стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE для сообщения Resv приведены ниже.

На рис. 10.32 дан пример Resv -сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.

Объекты SCOPE не являются обязательными, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При работе с объектами SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил.

Состояние блокады

Основным правилом при формировании сообщения обновления Resv является объединение спецификаций flowspecs резервирования в узле посредством вычисления их LUB (наименьший верхний предел). Однако это правило модифицируется при наличии состояния блокады, возникшего из-за сообщений ResvErr при решении проблемы KR-II.

Когда получено сообщение ResvErr, его спецификация flowspec Qe используется для формирования или обновления элемента местного состояния блокады. Каждый элемент состояния блокады состоит из спецификации flowspec Qb, взятой из спецификации сообщения ResvErr, и соответствующего таймера блокады Tb. Когда время таймера блокады истекает, соответствующее состояние блокады аннулируется.

Гранулярность состояния блокады зависит от стиля сообщения ResvErr, которое явилось ее причиной. Каждому конкретному стилю может соответствовать свой элемент состояния блокады ( Qb(S),Tb(S) ), где S — отправитель. Для произвольного стиля выбора отправителя состояние блокады определяется предыдущим узлом P.

Элемент состояния блокады со спецификацией flowspec Qb называется блокадой резервирования со спецификацией flowspec Qi, если Qb не больше, чем Qi. Например, предположим, что LUB (least upper bound) двух спецификаций flowspecs было вычислено путем выбора максимума составляющих их компонент. Тогда Qb блокирует Qi, если для некоторой компоненты $$j Qb[j] \le Qi[j]$$.

Предположим, что узел получает сообщение ResvErr от предыдущего узла P или, если стиль выбора отправителя S является явным — в результате ошибки доступа. Тогда:

В результате предлагается модифицированное правило для объединения спецификаций flowspecs при формировании сообщения обновления резервирования.

Этот алгоритм объединения обновления применяется отдельно для каждого потока (каждого отправителя или PHOP), вносящего вклад в общее резервирование (стили WF или SE).

На рис. 10.33 приведен пример использования состояния блокады для совместного резервирования (стиль WF). Имеется два предшествующих узла, помеченных как (a) и (b), и два последующих узла, помеченных как (c) и (d). Большее резервирование 4B пришло сначала от (c), но "застряло" где-то до PHOP (a), а не по пути через PHOP (b). Рисунок показывает оконечное состояние после меньшего резервирования 2B, пришедшего позднее из (d). Это стабильное состояние нарушается каждые Kb*R секунд, когда состояние блокады удаляется по тайм-ауту. Следующее обновление (4B), посылаемое предыдущему узлу (a), предположительно будет отвергнуто путем посылки сообщения ResvErr, которое восстановит состояние блокады, возвращая ситуацию к тому, что изображено на рисунке. В то же самое время сообщение ResvErr будет направлено следующему узлу (c) и всем получателям, ответственным за резервирование 4B.

Локальное восстановление

Когда маршрут изменяется, следующее сообщение обновления Path или Resv установит проход или состояние резервирования (соответственно) вдоль нового маршрута. Чтобы обеспечить быструю адаптацию к изменениям маршрута, не вводя чрезмерно коротких периодов обновления, местный модуль протокола маршрутизации может сообщить процессу RSVP об изменении маршрута до определенных мест назначения. Процесс RSVP должен использовать эту информацию для запуска обновления в соответствующих областях с учетом изменения маршрута. При этом соблюдаются следующие правила спецификации.

Временные параметры

Существует два временных параметра, соответствующие каждому элементу прохода или состоянию резервирования RSVP в узле: период обновления R между последовательными коррекциями состояния соседнего узла и время жизни локального состояния L. Каждое сообщение RSVP Resv или Path может содержать объект TIME_VALUES, специфицирующий значение R, которое было использовано при генерации данного сообщения обновления. Эта величина R затем используется для определения значения L. Величины R и L могут варьироваться от узла к узлу. Ниже данные соображения излагаются более подробно.

Политика в области трафика и узлы с неинтегрированными услугами

Некоторые уровни QoS могут требовать определенной политики в управлении трафиком в некоторых или всех перечисленных ниже случаях.

RSVP знает, где такие точки находятся, и должен обеспечивать этими данными механизм управления трафиком. С другой стороны, RSVP не интерпретирует информацию в flowspec и, следовательно, не знает, использованы ли рекомендации управления в каждом конкретном случае.

Процесс RSVP передает управлению трафиком специальный флаг политики для каждой из трех указанных выше ситуаций.

RSVP должен также проверять наличие вдоль пути узлов, не поддерживающих RSVP, и переправлять эту информацию управлению трафиком. На основании этого флага и другой сопутствующей информации система контроля трафиком может обнаружить узлы, которые не способны обеспечить управление QoS. Эта информация передается получателям в спецификации Adspecs [RFC-2210].

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

ЭВМ с несколькими сетевыми интерфейсами

При работе с ЭВМ, имеющими несколько сетевых интерфейсов, требуется выполнение ряда специальных правил. К такого рода устройствам относятся и маршрутизаторы, которые поддерживают локальные прикладные программы.

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

Посылка данных

Приложение отправителя использует API-вызов для декларации характеристик его информационного потока для RSVP. Этот вызов может опционно включать локальный IP-адрес отправителя. Если он установлен приложением, этот параметр должен быть адресом интерфейса для отправки информационных пакетов, в противном случае используется системный интерфейс по умолчанию.

RSVP-процесс ЭВМ посылает затем приложению сообщения Path только через специфицированный интерфейс.

Выполнение резервирования

Приложение-получатель использует вызов API для запроса резервирования RSVP. Этот вызов может опционно включать локальный IP-адрес получателя, т.е., адрес интерфейса для получения информационных пакетов. В случае мультикаст-сессий — это интерфейс, к которому подключилась группа. Если этот параметр опущен, система использует значение по умолчанию.

Процесс RSVP должен посылать сообщения Resv приложению через специфицированный интерфейс. Однако когда приложение исполняется в маршрутизаторе, а сессия является мультикастной, возникает более сложная ситуация. Предположим, что в этом случае приложение получателя присоединяется к группе через интерфейс Iapp, который отличается от Isp — ближайшего интерфейса по пути к отправителю. Теперь имеется два возможных пути для мультикастной маршрутизации при доставке информационных пакетов приложению. Процесс RSVP должен определить, какой вариант выбрать, просмотрев состояние прохода и решив, какой из входных интерфейсов следует использовать для посылки сообщений.

Будущая совместимость

В будущем для существующих классов могут быть описаны новые объекты C-типа, а могут быть определены и новые классы объектов. Крайне желательно использовать такие объекты Интернет в рамках старых приложений, которые их не распознают. К сожалению, это возможно с заметными ограничениями. Здесь нужно придерживаться следующих правил (b в дальнейшем означает бит).

Ниже приведены более детализированные правила работы с нераспознанными классами объектов для Class-Num вида 11bbbbbb.

Хотя объекты с неизвестным классом не могут объединяться, эти правила позволяют передать их вплоть до узла, который сможет их распознать и объединить.

Интерфейсы RSVP

RSVP в маршрутизаторе имеет интерфейсы для управления трафиком, а в ЭВМ — интерфейсы для приложений (т.е., API), а также для управления трафиком (если такой контроль предусмотрен).

Интерфейс приложения RSVP

Структура реального интерфейса может зависеть от операционной системы. Некоторые из вызовов предполагают асинхронную присылку информации.

Опционный параметр receiver_address может использоваться получателем в маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами; это IP-адрес одного из интерфейсов узла. Флаг CONF_flag должен быть установлен, если желательно подтверждение резервирования. Параметр Policy_data специфицирует управляющие данные получателя, в то время как параметр style указывает на стиль резервирования. Остальные параметры зависят от стиля; обычно они соответствуют спецификациям фильтра и flowspecs.

Обращение: <Upcall_Proc>( ) > sessionid, Info_type, information_parameters

В настоящее время имеется пять типов обращений, отличающихся параметром Info_type. Выбор информационных параметров зависит от типа.

Обращение (отклик): <Upcall_Proc>( ) > sessionid,
Info_type = RESV_EVENT,
Style, Flowspec, Filter_Spec_list
[ , Policy_data ]

Хотя сообщения RSVP, указывающие на события path или resv, могут приходить периодически, API должно послать соответствующие асинхронные отклики приложению только на первое из них или при изменении полученной информации. Все события, сопряженные с ошибками или подтверждениями, должны доводиться до сведения приложения.

Интерфейс управления трафиком RSVP

Трудно представить общий интерфейс для управления трафиком, так как детали установления резервирования сильно зависят от технологии реализации канального уровня в интерфейсе.

Объединение RSVP-резервирований необходимо из-за мультикастной доставки данных, при которой информационные пакеты размножаются для отправки последующим узлам. В каждой такой точке размножения RSVP должен объединять запросы резервирования от последующих узлов путем выбора максимума их спецификаций flowspecs. В данном маршрутизаторе или ЭВМ может присутствовать несколько таких точек объединения/размножения.

В общем, эти сложности не влияют на реализацию протокола RSVP, нужно только четко определить, какие запросы резервирования следует объединить. Может оказаться желательным организовать реализацию RSVP из двух блоков: ядро, которое выполняет канально-независимую обработку, и адаптационный уровень, учитывающий канальную специфику.

Вызов: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_flags ) [ > Fwd_Flowspec ]

Интерфейс маршрутизации RSVP

Реализация RSVP нуждается в следующей поддержке со стороны механизма маршрутизации узла.

Ucast_Route_Query( [ SrcAddress, ] 
    DestAddress, Notify_flag ) > OutInterface
Mcast_Route_Query( [ SrcAddress, ] 
   DestAddress, Notify_flag ) > [ IncInterface, ] OutInterface_list

Ucast_Route_Change( ) > [ SrcAddress, ] 
   DestAddress, OutInterface Mcast_Route_Change( ) > [ SrcAddress, ] 
      DestAddress, [ IncInterface, ] OutInterface_list

Пакетные I/O интерфейсы RSVP

Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла.

Манипуляции, зависящие от вида услуг

Flowspecs, Tspecs и Adspecs являются объектами, совершенно недоступными для RSVP; их содержимое определено в документах спецификации услуг. Чтобы манипулировать этими объектами, процесс RSVP должен иметь в своем распоряжении следующие программы, зависящие от типа услуг.

10.6. Протокол запуска сессий SIP

Протокол SIP (Session Initiation Protocol) описан в документе RFC-3261, (смотри также [10.6] и The Internet Protocol Journal V6, N1, March 2003, William Stallings, "The Session Initiation Protocol") и служит для запуска, модификации и завершения сессий реального времени между партнерами IP-сети. SIP может поддерживать как моно-, так и мультимедийные приложения, включая видеоконференции.

Протокол SIP является лишь одним из протоколов, которые обеспечивают мультимедийный обмен через Интернет. SIP представляет собой сигнальный протокол, который позволяет одному партнеру послать запрос другому и согласовать параметры мультимедиа-сессии.

Собственно транспортировка мультимедиа-данных обычно осуществляется с помощью протокола RTP (RealTime Transport Protocol).

Базовым стимулом создания протокола SIP являлась необходимость реализации работы с VoIP (Voice over IP). Протокол поддерживает пять аспектов, сопряженных с установлением и завершением мультимедийных коммуникаций.

Положение пользователя. Пользователи могут менять свое положение и сохранять доступ к телефонии и другим приложениям дистанционно.

Доступность пользователя. Предполагается проверка готовности парнера-адресата участвовать в коммуникациях.

Возможности пользователя. Определяются параметры среды, которые должны быть использованы.

Формирование сессии. Создается соединение точка-точка или сессия с несколькими партнерами при заданных коммуникационных параметрах.

Управление сессией. Предполагается создание и завершение сессий, модификация параметров сессии и сервисов.

SIP базируется на модели транзакций, сходных с запросами/откликами в протоколе HTTP. Каждая транзакция состоит из запроса клиента, который включает в себя определенный метод, или функцию, для сервера и, по крайней мере, один отклик. SIP использует большинство полей заголовков, правил кодирования и кодов статуса протокола HTTP. Это позволяет работать с данными легко читаемого и отображаемого формата. SIP применяет протокол SDP (Session Description Protocol), который с помощью набора типов данных, специфизированных в MIME (Multipurpose Internet Mail Extensions), определяет содержимое сессии.

Компоненты и протоколы SIP

Система, использующая SIP, может рассматриваться как состоящая из клиентов, серверов и индивидуальных сетевых элементов. RFC-3261 определяет клиента и сервер следующим образом.

Клиент. Клиент является субъектом сети, который посылает SIP-запросы и получает SIP-отклики. Клиенты, если это требуется, могут непосредственно взаимодействовать с человеком. Агент пользователя клиента и прокси являются клиентами.

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

Индивидуальные элементы стандартной конфигурации включают в себя:

Агент пользователя. Резидентно присутствует в каждой конечной станции SIP. Он выполняет две роли:

Агент пользователя клиента UAC (User Agent Client): посылает запросы SIP. Агент пользователя сервера UAS (User Agent Server): получает SIP-запросы, генерирует отклики, принимает, отклоняет или перенаправляет запросы.

Сервер переадресации. Используется во время инициализации сессии, чтобы определить адрес запрашиваемого устройства. Сервер переадресации отсылает полученную информацию устройству, инициировавшему запрос, направляя UAC, который может применяться для контакта с альтернативным URI (Universal Resource Identifier). URI является универсальным идентификатором, используемым для именования любого ресурса в Интернет. URL, предназначенное для Web-адресов, имеет тип URI. Подробнее это рассмотрено в RFC-2396[1].

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

Регистратор. Является сервером, который принимает запросы REGISTER и помещает информацию, которую он получает (SIP-адрес и ассоциированный IP-адрес регистрирующего устройства) из этих запросов, в службу локализации для домена, который обслуживает.

Служба локализации. Используется серверами переадресации SIP или прокси, чтобы получить информацию о возможном положении источника запроса. Для этой цели служба локализации поддерживает базу данных SIP-адресов/ IP-адресов.

В RFC-3261 в качестве логических устройств определены различные серверы. Они могут быть использованы в качестве отдельных серверов в Интернет или могут объединяться в рамках одного приложения, которое работает резидентно на определенном физическом сервере.

На рис. 10.34 показано, как некоторые SIP компоненты связаны друг с другом и с протоколами, которые они применяют. Агент пользователя А использует SIP для установления сессии с другим агентом пользователя B, который выступает в роли сервера. Диалог запуска сессии пользуется SIP и включает один или более прокси серверов, чтобы переадресовать запросы и отклики между двумя агентами пользователя. Агенты пользователя работают также с протоколом SDP (Session Description Protocol), который служит для описания медийной сессии.

Прокси серверы могут, если это требуется, работать в качестве серверов переадресации. Система DNS (Domain Name System) является важной частью, реализующей протокол SIP. Обычно, UAC осуществляет запрос, используя доменное имя UAS, а не IP-адрес. Прокси сервер вынужден консультироваться у DNS-сервера, чтобы найти прокси сервер для зоны места назначения.

Из эксплуатационных соображений SIP часто работает поверх UDP (User Datagram Protocol), и обеспечивает свои собственные механизмы обеспечения надежности доставки, но может использовать и TCP. Если необходим безопасный или криптографический транспортный механизм, сообщения SIP могут передаваться посредством протокола TLS (Transport Layer Security).

С протоколом SIP ассоциирован SDP, описанный в RFC-2327 [10.4]. SIP применяется для приглашения одного или более партнеров для участия в сессии, в то время как кодированные SDP тела сообщений содержат информацию о типе медиа-данных (например, голос, видео). После того как эта информация отправлена и подтверждена, все участники знают IP-адреса, доступную полосу и тип данных. Затем начинается передача информации, с применением соответствующего транспортного протокола. Обычно используется RTP. Во время сессии участники, с помощью сообщений SIP, могут изменить параметры сессии, такие, как новые медиа-типы или новые участники сессии.

Универсальные локаторы ресурсов SIP

Ресурсы в конфигурации SIP идентифицируются URI. Примерами ресурсов могут служить:

URI SIP имеют формат, базирующийся на формате адресов email, в частности user@domain. Существует две общие схемы. Обычные URI имеют форму:

sip:ааа@itep.com

URI могут также включать пароль, номер порта и сопряженные параметры. Если требуется безопасная передача, sip: заменяется на sips:. В последнем случае сообщения SIP передаются с привлечением протокола TLS.

Примеры работы

Спецификация SIP достаточно сложна; главный документ, RFC-3261, содержит 269 страниц. Для пояснения работы протокола рассмотрим несколько примеров.

На рис. 10.35 показана успешная попытка пользователя А установить сессию с пользователем B, чье URI bbb@itep.com. [10.9] UAC А сконфигурирован для работы с прокси сервером (выходной сервер) в своем домене и начинает работу с посылки сообщения INVITE прокси серверу, которое указывает на намерение подключить к сессии UAS (1); сервер подтверждает получение запроса (2). Хотя UAS B определяется его URI, выходной прокси сервер должен учесть возможность того, что B в данный момент недоступен или что B поменял адрес. Соответственно, выходной прокси сервер должен переадресовать запрос INVITE прокси серверу, который ответственен за домен itep.com. Выходной прокси сервер, таким образом, консультируется с локальным серером DNS, чтобы получить IP-адрес прокси сервера itep.com (3), путем запроса ресурсной записи DNS SRV, которая содержит информацию о прокси для домена itep.com.

DNS-сервер откликается (4) отправкой IP-адреса прокси сервера itep.com. Прокси сервер А может теперь переадресовать сообщение INVITE выходному прокси серверу (5), который посылает подтверждение сообщения (6). Входной прокси сервер теперь консультируется с сервером локализации для определения адреса B (7), а сервер локализации откликается посылкой адреса B, что позволяет послать ему сообщение SIP (8).

Прокси сервер может теперь отослать сообщение INVITE B (9). Посылается отклик от B к А (10, 11, 12), в то время как UAS B обращается к локальному медийному приложению (например, телефонии). Когда медиа-приложение воспринимает вызов, UAS B посылает отклик OK А (13, 14, 15).

Наконец, UAC А посылает сообщение подтверждения UAS B, чтобы подтвердить получения окончательного отклика (16). В этом примере, ACK посылается непосредственно от А к B, обходя два прокси. Это происходит потому, что конечные точки уже знают адрес своего партнера из обмена INVITE/200 (OK). Медиа-сессия началась, А и B могут обмениваться данными через одно или более RTP-соединения.

В следующем примере (рис. 10.36) используется два типа сообщений, которые пока еще не входят в стандарт SIP, но описаны в документе RFC-2848 [5] и вероятно будут включены в последующие версии SIP. Эти типы сообщений поддерживают телефонные приложения. Предположим, что в предыдущем примере А была проинформирована о том, что B недоступен. UAC А может выдать сообщение SUBSCRIBE (1), указывающее, что он хочет быть проинформирован, когда B будет доступен.

Этот запрос будет переадресован в нашем случае через два прокси к серверу PINT (Public Switched Telephone Network [PSTN]Internet Networking – общедоступную коммутируемую телефонную сеть) (2, 3). Сервер PINT работает как шлюз между IP-сетью, из которой пришел запрос установить телефонное соединение, и телефонной сетью, которая осуществляет соединение с адресатом. В этом примере мы предполагаем, что логика сервера PINT совмещена со службой локализации. Может также случиться, что B подключен к Интернет, а не к PSTN, — в этом варианте нужна система, эквивалентная логике PINT, чтобы обрабатывать запросы SUBSCRIBE. Мы здесь предполагаем также, что функциональность PINT встроена в службу локализации. Служба локализации авторизует подписку, прислав сообщение OK (4), которое передается А (5, 6). Служба локализации затем немедленно посылает сообщение NOTIFY с текущим статусом B (7, 8, 9), которое подтверждается UAC А (10, 11, 12).

На рис. 10.37 показано продолжение обмена. B подключается к системе локализации, послав сообщение REGISTER прокси серверу своего домена (1). Прокси обновляет базу данных службы локализации, отражая факт регистрации (2). Обновление подтверждается прокси (3), что подтверждает регистрацию B (4). PINT воспринимает новый статус B от сервера локализации и посылает сообщение NOTIFY, содержащее новый статус B (5). Это сообщение переадресуется А (6, 7). UAC А подтверждает получение уведомления (8, 9, 10).

Сообщения SIP

Как было замечено, SIP является протоколом, базирующемся на текстах, с синтаксисом, сходным с HTTP. Существует два разных типа SIP сообщений: запросы и отклики. Различие форматов этих сообщений проявляется в первой строке. Первая строка запроса содержит метод, определяющий природу запроса, и URI запроса, указывающий, куда следует послать запрос. Первая строка отклика содержит код отклика. Все сообщения имеют заголовок, состоящий из нескольких строк, каждая строка начинается с метки заголовка. Сообщение может содержать в себе описание транспортируемых данных SDP. Для запросов SIP RFC-3261 определяет следующие методы.

Например, заголовок сообщения (1) на рис. 10.35 может выглядеть следующим образом:

INVITE sip:bbb@ itep.com SIP/2.0
Via: SIP/2.0/UDP 12.26.17.91:5060
MaxForwards: 70
To: B <sip:bbb@ itep.com
From: A <sip:aaa@iae.com;tag=1928301774
CallID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:aaa@iae.com>
ContentType: application/sdp
ContentLength: 142

Первая строка содержит название метода ( INVITE ), SIP URI, номер используемой версии протокола SIP. Последующие строки представляют собой список полей заголовка. В данном примере представлен минимально необходимый набор.

Заголовки Via показывают путь запроса через конфигурацию SIP (отправитель и промежуточные прокси), и используются при передаче по тому же маршруту откликов. Когда посылается сообщение INVITE, оно имеет только заголовок, вставленный А. Строка содержит IP адрес (12.26.17.91), номер порта (5060), и транспортный протокол (UDP), которые B должен применить в отклике.

Заголовок MaxForwards ограничивает число шагов, которые запрос может сделать до точки назначения. Содержимое этого поля является целым числом, которое декрементируется на 1 каждым прокси, переадресующим запрос. Если значение MaxForwards станет равным 0, прежде чем запрос достигнет места назначения, он отвергается с кодом ошибки в отклике, равным 483 (Too Many Hops – слишком много шагов).

Поле заголовка To содержит имя (B) и URI SIP или SIPS (sip:bbb@ itep.com), которому первоначально предназначался запрос. Поле заголовка From также содержит имя (A) и URI SIP или SIPS (sip:aaa@iae.com), которое указывает на отправителя запроса. Это поле заголовка имеет также свободный параметр, который содержит произвольную строку (1928301774), добавляемую к URI UAC. Она используется для идентификации сессии.

Поле заголовка Call-ID содержит глобально уникальный идентификатор данного вызова, генерируемый из комбинации псевдослучайной строки и имени ЭВМ или IP-адреса. Комбинация тэгов To, From и Call-ID полностью определяет отношение SIP партнеров А и B.

CSeq или поле заголовка Command Sequence содержит целое число и имя метода. Число CSeq инициализируется в начале вызова (в данном примере 314159), инкрементируется для каждого нового запроса в рамках диалога и является традиционным порядковым номером. CSeq используется, чтобы отличить повторную передачу от нового запроса.

Поле заголовка Contact содержит SIP URI для непосредственной коммуникации между агентами пользователя. Несмотря на то, что поле заголовка Via говорит другим элементам, куда следует посылать отклик, поле заголовка Contact сообщает другим элементам, куда посылать будущие запросы для заданного диалога.

Поле заголовка ContentType указывает на тип тела сообщения. Поле заголовка ContentLength содержит длину тела сообщения в октетах.

Типы откликов SIP, определенных в RFC-3261, имеют следующие категории.

Например, заголовок сообщения (13) на рис. 10.35 может выглядеть следующим образом:

SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.itep.com
Via: SIP/2.0/UDP bgb3.site3.iae.com
Via: SIP/2.0/UDP 12.26.17.91:5060
To: B <sip:bbb@itep.com;tag=a6c85cf
From: A <sip:aaa@iae.com;tag=1928301774
CallID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:bbb@itep.com>
ContentType: application/sdp
ContentLength: 131

Первая строка содержит номер версии SIP, которая используется, код отклика и имя. Последующие строки представляют собой список полей заголовка. Поля заголовка Via, To, From, Call-ID и CSeq копируются из запроса INVITE. (Существует три значения поля заголовка Via — одно связано с UAC А, другое введено прокси iae.com proxy и еще одно добавлено прокси itep.com). Телефонный номер B записан в тэг параметра поля заголовка To. Этот тэг вводится обеими сторонами диалога и включается во все будущие запросы в рамках заданного вызова.

Протокол описания сессии

Протокол SDP (Session Description Protocol), определенный в RFC-2327, описывает содержимое сессий, включая телефонию, Интернет-радио, приложения мультимедиа. SDP содержит информацию о [10.8]:

медиа-потоках. Сессия может реализовывать несколько потоков данных. В протоколе SDP в настоящее время определены аудио, видео, данные, управление и приложения (поточные), сходные с MIME типами электронной почты в Интернет;

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

портах. Для каждого потока специфицируются номера UDP портов для отправителя и получателя;

типах данных. Для каждого используемого типа потока (например, телефония) тип поля данных указывает на медиа-форматы, которые могут применяться во время сессии;

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

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

Несмотря на то, что SDP предоставляет возможность описания мультимедиа-данных, здесь не хватает механизмов согласования параметров сессии, которые намерены использовать партнеры. Документ RFC-3264 [10.7] предоставляет модель согласования на основе механизма предложения/отклика, в которой партнеры обмениваются SDP сообщениями с целью достичь согласия относительно природы данных, подлежащих пересылке.