4.2. Протокол RSVP (Resource Reservation Protocol)
Протокол резервирования ресурса (RSVP-протокол) является технологическим Internet-протоколом, расположенным на транспортном уровне Internet-архитектуры (над протоколом IPv4 или IPv6). Поэтому, в отличии от других протоколов транспортного уровня, RSVP-протокол не транспортирует данные прикладной службы (процесса), а функционирует как другие протоколы управления (например, ICMP, IGMP и протоколы маршрутизации), обеспечивая тем самым нормальное функционирование всей Internet-сети. RSVP-сообщения передаются в форме не обрабатываемых IP-пакетов (используя номер протокола «46») через ретрансляционные участки, которые обслуживаются маршрутизаторами, имеющими в своем составе программные RSVP-модули. Это означает, что не обрабатываемые IP-пакеты должны использоваться между оконечными системами и маршрутизатором, находящимся на первом (или последнем) ретрансляционном участке. Однако, это не всегда возможно, так как не все системы могут формировать не обрабатываемые двунаправленные сетевые потоки данных (Raw Network I/O — InputStream/OutputStream). В таком случае, существует возможность применения оконечными системами процедуры повторного обрамления RSVP-сообщении с помощью UDP-блоков, из которых формируются пакеты. Такие RSVP/UDP/IP-пакеты передаются, либо оконечными IP-узлми на UDP-порт 1698, либо маршрутизаторами с программными RSVP-модулями на UDP-порт 1699.
RSVP-сеанс связи представляет собой поток данных (сообщений), в которых указаны:
IP-адрес назначения (во всех информационных IP-пакетах). Это могут быть одно- и много адресные сообщения.
Идентификатор протокола транспортного уровня (например, UDP- или TCP-протокол).
Номер транспортного порта-назначения, который используется демультиплексирования сообщений, содержащихся в IP-пакетах.
При совместном использовании RSVP-протокола и NAT-модулей возможны две следующие проблемы:
RSVP-сообщения могут содержать IP-адреса. В таком случае необходим RSVP-ALG-субмодуль, который должен изменять IP-адреса в зависимости от направления маршрута доставки и типа сообщения. Например, если бы внешний субъект передал RSVP-сообщение о маршруте субъекту корпоративной сети, то тогда бы RSVP-сообщение (в период RSVP-сеанса связи) содержало IP-адрес, который по предположению внешнего субъекта является IP-адресом субъекта корпоративной сети. Однако, когда RSVP-сообщение о маршруте будет принято NAT-модулем, последний должен изменить парамеры RSVP-сеанса связи, то есть модифицировать IP-адрес, чтобы RSVP-сообщение было принято субъектом корпоративной сети. Подобная процедура должна осуществлять со всеми, без исключения, сообщениями субъектов, содержащими IP-адреса.
RSVP-протокол имеет собственные средства, которые обеспечивают целостность RSVP-сообщений. Но это является источником еще одной проблемы. С одной стороны, NAT-модуль должен иметь возможность модифицировать IP-адреса внутри RSVP-сообщений. Однако, с другой стороны, когда выполнение такой функции обеспечено, то тогда не возможно реализовать функцию защиты целостности RSVP-сообщений, так как RSVP-сообщение уже было изменено. Более того, при реализации функции защиты целостности RSVP-сообщений RSVP-ALG-субмодуль не работает.