Протоколы Internet


Протокол резервирования ресурсов RSVP - часть 32


  • Одиночное RSVP-сообщение не должно превосходить максимального размера IP-дейтограммы, примерно 64K байт (на практике значительно меньше!).
  • Перегруженные сетевые области, которые не поддерживают RSVP, могут потерять отдельные фрагменты, а это приведет к потере всего сообщения.
  • RSVP использует свой механизм периодического обновления для предотвращения влияния случайной потери отдельных пакетов. При перегрузке сети, однако, существенные потери RSVP-сообщений могут вызвать серьезные нарушения при резервировании сетевых ресурсов. Для контроля задержек, связанных с обслуживанием очереди, и влияния потерь RSVP пакетов, маршрутизаторы должны быть сконфигурированы так, чтобы обеспечивать для данных целей приоритетное обслуживание. Если RSVP-пакеты идут через область сети, где вероятность потери значительна, следует увеличить значение таймаутов.

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

    1. Когда узел N направляет сообщение Path выходному логическому интерфейсу L, он включает в сообщение дескриптор логического интерфейса LIH (logical interface handle). Значение LIH содержится в объекте RSVP_HOP.
    2. Следующий узел N' запоминает значение LIH в своем состоянии прохода.
    3. Когда N' посылает сообщение Resv узлу N, он включает в него значение LIH из состояния прохода (содержится в объекте RSVP_HOP).
    4. Когда сообщение Resv прибывает в N, его значение LIH выдает информацию, необходимую для осуществления резервирования в определенном логическом интерфейсе. Заметим, что узел N создает и интерпретирует LIH, которое совершенно не доступно для узла N'.

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

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




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