Таблица 4.4.9.6.2. Правила UDP-инкапсуляции для мультикастных сообщений Path
Узел |
RSVP посылает |
RSVP получает |
Hu |
UDP(G*,Pu) |
UDP(D,Pu’) [3] и UDP(G*,Pu) |
Hr |
Raw(D,Tr) и, тогда UDP(D, Pu’) |
RAW() и UDP(G*, Pu) (игнорировать Pu’) |
R (интерфейс а) |
Raw(D,Tr) и, если (UDP), тогда UDP(D, Pu’) |
RAW() и UDP(G*, Pu) (игнорировать Pu’) |
Маршрутизатор может определить, нуждается ли его интерфейс Х в UDP-инкапсуляции, контролируя поступление UDP-инкапсулированных сообщений Path, которые были посланы либо G* (мультикаст D) либо по адресу интерфейса X (уникаст D). Для данной схемы существует один неудачный режим: если нет ни одной ЭВМ в сети, которая бы выполняла функцию RSVP отправителя, тогда не будет сообщений прохода (Path), чтобы запустить UDP-инкапсуляцию. В этом случае будет необходимо сконфигурировать UDP-инкапсуляцию для интерфейса локального маршрутизатора.
Когда получен UDP-инкапсулированный пакет, в большинстве систем TTL не доступно для приложения. Процесс RSVP, который получает UDP-инкапсулированное сообщение Path или PathTear должен использовать поле Send_TTL общего RSVP-заголовка для извлечения значения TTL. В тех случаях, когда это по каким-либо причинам не приемлемо, значение TTL может быть задано вручную при конфигурации.
Мы предположили, что первый маршрутизатор, поддерживающий RSVP, подключен непосредственно к локальной сети. Существует несколько подходов в случае, когда это не так.