Телекоммуникационные технологии. Том 1
       

C UDP-инкапсуляция


Реализации RSVP обычно требуют возможности выполнять любые сетевые операции ввода/вывода, т.е., посылать и получать IP-дейтограммы, используя код протокола 46. Однако, некоторые важные классы вычислительных систем могут не поддерживать такого рода операции. Для использования RSVP, такие ЭВМ должны инкапсулировать сообщения RSVP в UDP-дейтограммы.

Базовая схема UDP-инкапсуляции использует два предположения:

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

  2. Маршрутизаторы первого/последнего узлов должны поддерживать RSVP.

Пусть Hu является ЭВМ, которая нуждается в UDP-инкапсуляции, а Hr ЭВМ, способная выполнять любые сетевые операции ввода/вывода. Схема UDP-инкапсуляции должна допускать RSVP взаимодействие ЭВМ типа Hr, Hu и маршрутизаторов.

Сообщения Resv, ResvErr, ResvTear и PathErr посылаются по уникастным адресам, полученным из состояний прохода или резервирования узла. Если узел отслеживает, в каком из предыдущих узлов и в каком интерфейсе нужна UDP-инкапсуляция, эти сообщения при необходимости могут быть посланы с применением UDP инкапсуляции. С другой стороны, сообщения Path и PathTear могут посылаться адресату с применением как мультикастных, так и уникастных адресов.

В таблицах 4.4.9.6.1 и 4.4.9.6.2 приведены базовые правила UDP-инкапсуляции сообщений Path и PathTear, для уникастных и мультикастных DestAddress. Другие типы сообщений, которые работают с уникастными адресами, должны следовать правилам из табл. 4.4.9.6.1. Записи в колонке `RSVP посылает' имеют формат `mode(destaddr, destport)'.

Полезно определить две разновидности UDP-инкапсуляций, одна используется для посылки сообщений от Hu, другая от Hr и R. Это делается, для того чтобы избежать двойной обработки сообщения получателем. На практике эти два вида инкапсуляций разделяются по номерам UDP портов Pu и Pu'.

В таблицах используются следующие символы.

  • D является портом назначения (DestAddress) конкретной сессии.

  • G* является стандартным групповым адресом формата 224.0.0.14, т.е., группа ограничена пределами локальной сети.


  • Pu и Pu' являются стандартными UDP-портами для UDP-инкапсуляции RSVP, с номерами 1698 и 1699.


  • Ra равен IP-адресу интерфейса маршрутизатора `a'.


  • Интерфейс маршрутизатора `a' локально доступен для Hu и Hr.




Таблица 4.4.9.6.1. Правила UDP- инкапсуляции для уникастных сообщений Path и Resv

(D - уникастный адрес места назначения; R - маршрутизатор; Raw - режим произвольных операций сетевого ввода/вывода.)

Узел RSVP посылает RSVP получает
Hu UDP(D/Ra,Pu) [1] UDP(D,Pu) и UDP(D,Pu’) [2]
Hr Raw(D)

и, если (UDP),

тогда UDP(D, Pu’)		 RAW()

и UDP(D, Pu) [2]

(игнорировать Pu’)
R (интерфейс а) Raw(D)

и, если (UDP),

тогда UDP(D, Pu’)		 RAW()

и UDP(Ra, Pu)

(игнорировать Pu’)
[1] Hu посылает уникастные сообщения Path либо по адресу D, если D является локальным, либо по адресу Ra маршрутизатора первого узла. Ra предполагается известным.
[2] Здесь D является адресом локального интерфейса, через который приходит сообщение.
[3] Это предполагает, что приложение присоединилось к группе D.
Таблица 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),

тогда 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, подключен непосредственно к локальной сети. Существует несколько подходов в случае, когда это не так.

  1. Hu может запускать как уникастные, так и мультикастные сессии в UDP(Ra,Pu) с TTL=Ta. Здесь Ta должно быть достаточным, чтобы достичь R. Если Ta слишком мало, сообщение Path не дойдет до R. Если Ta слишком велико, R и последующие маршрутизаторы могут переправлять UDP-пакет до тех пор, пока не иссякнет запас по TTL. Это включит UDP-инкапсуляцию между маршрутизаторами в Интернет, возможно вызвав паразитный UDP трафик. ЭВМ Hu должна быть непосредственно сконфигурирована с использованием Ra и Ta.


  2. Конкретная ЭВМ локальной сети, соединенная с Hu может считаться “транспортной ЭВМ RSVP". Транспортная ЭВМ будет прослушивать (G*,Pu) и переправлять любое сообщение Path непосредственно R, хотя это и не будет маршрутом передачи данных. Транспортная ЭВМ должна быть сконфигурирована с использованием Ra и Ta.



Содержание раздела