Примеры сетевых топологий


Форматы объектов - часть 3


Эти адреса гарантируют, что сообщение будет корректно маршрутизовано даже через области сети, не поддерживающие 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.


Начало  Назад  Вперед