RFC: 3775
Оригинал: Mobility Support in IPv6
Другие версии: RFC 6275
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Шнитман Виктор Зиновьевич

11.5. Перемещение

11.5.1. Определение перемещения

Основной задачей определения перемещения является определение передач обслуживания на уровне L3. Этот раздел не пытается специфицировать алгоритм определения быстрого перемещения, который будет функционировать оптимально для всех типов приложений, канальных уровней и сценариев развертывания; вместо этого, в нем описан общий метод, который использует средства протокола IPv6 Neighbor Discovery, включая определение маршрутизаторов (Router Discovery) и определение недостижимости соседей (Neighbor Unreachability Detection). На момент написания данного документа этот метод считается достаточно хорошо понятым для того, чтобы его рекомендовать для стандартизации, однако ожидается, что будущие версии данной спецификации или другие спецификации могут содержать обновленные версии алгоритма определения перемещения, который имеет лучшую производительность.

Общий метод определения перемещения использует механизм определения недостижимости соседей для определения того, когда подразумеваемый маршрутизатор (маршрутизатор, используемый по умолчанию) больше не является двунаправленно достижимым, в этом случае мобильный узел должен определить новый подразумеваемый маршрутизатор (обычно на новом линке). Однако такое определение происходит только тогда, когда мобильный узел имеет пакеты для отсылки, и при отсутствии частых сообщений Router Advertisement или указаний от канального уровня мобильный узел может оказаться не осведомленным относительно передачи обслуживания L3, которая произошла. Поэтому, мобильный узел должен дополнять этот метод другой информацией всякий раз, когда она становится доступной мобильному узлу (например, от более низких протокольных уровней).

Когда мобильный узел обнаруживает передачу обслуживания L3, он выполняет процедуру определения дублирования адреса (Duplicate Address Detection [13]) со своим «локальным для линка» адресом, выбирает новый подразумеваемый маршрутизатор, как следствие процедуры Router Discovery, и затем выполняет процедуру Prefix Discovery с этим новым маршрутизатором для формирования нового временного адреса (адресов), как описано в разд. 11.5.2. Затем он регистрирует свой новый основной временный адрес в своем домашнем агенте, как описано в разд. 11.7.1. После обновления своей регистрации в домашнем агенте, мобильный узел обновляет связанные с ней привязки мобильности в узлах-корреспондентах, которые вместе с ним выполняют оптимизацию маршрутов, как описано в разд. 11.7.2.

Из-за временного нарушения потока пакетов и накладных расходов сигнализации, возникающих в результате обновления привязок мобильности, мобильный узел должен избегать выполнения передачи обслуживания L3 до тех пор, пока это не станет абсолютно необходимо. А именно, когда мобильный узел получает сообщение Router Advertisement от нового маршрутизатора, которое содержит другой набор префиксов «на линке», если мобильный узел определяет, что выбранный в настоящее время подразумеваемый маршрутизатор на старом линке все еще остается двунаправленно достижимым, он должен, как правило, продолжить использование старого маршрутизатора на старом линке, а не переключаться с него для использования нового подразумеваемого маршрутизатора.

Для определения передач обслуживания L3 мобильные узлы могут использовать информацию из принятых сообщений Router Advertisement. Выполняя это, мобильный узел должен рассматривать следующие проблемы:

  • На том же самом линке может быть несколько маршрутизаторов, поэтому прослушивание нового маршрутизатора не обязательно создает передачу обслуживания L3.
  • Когда на одном и том же линке имеется несколько маршрутизаторов, они могут объявлять различные префиксы. Таким образом, даже прослушивание нового маршрутизатора с новым префиксом не является надежной индикацией передачи обслуживания L3.
  • «Локальные для линка» адреса маршрутизаторов не являются глобально уникальными, поэтому после завершения передачи обслуживания L3 мобильный узел может продолжать получать сообщения Router Advertisement с тем же самым «локальным для линка» адресом источника. Это может оказаться обычным случаем, если маршрутизаторы используют один и тот же «локальный для линка» адрес на нескольких интерфейсах. Эту проблему можно избежать, если маршрутизаторы используют бит Router Address (R), поскольку он предоставляет глобальный адрес маршрутизатора.

Кроме того, мобильный узел должен рассматривать следующие события в качестве индикации того, что могла произойти передача обслуживания L3. После приема таких указаний мобильный узел должен выполнить процедуру Router Discovery для определения маршрутизаторов и префиксов на новом линке, как описано в разд. 6.3.7 RFC 2461 [12].

  • Если сообщения Router Advertisement, которые принимает мобильный узел, включают опцию Advertisement Interval, то мобильный узел может использовать ее поле Advertisement Interval, как индикацию частоты, с которой он должен продолжать получение будущих объявлений от этого маршрутизатора. Это поле указывает минимальную скорость (максимальное время между последовательными объявлениями), которую должен ожидать мобильный узел. Если это время проходит, а мобильный узел не получил ни одного объявления от этого маршрутизатора, он может быть уверенным в том, что по крайней мере одно объявление, посланное маршрутизатором, потеряно. Тогда мобильный узел может реализовать свою собственную политику для определения того, сколько потерянных объявлений от этого текущего подразумеваемого маршрутизатора являются индикацией состоявшейся передачи обслуживания L3.

  • Процедура Neighbor Unreachability Detection определяет, что подразумеваемый маршрутизатор больше не доступен.

  • В некоторых типах сетей предупреждение о том, что произошла передача обслуживания L2, может быть получено от протоколов более низких уровней или от программного обеспечения драйвера устройства в мобильном узле. Хотя дальнейшие подробности относительно обработки указаний L2, как намеков на перемещения, являются пунктом для дальнейшего исследования, во время написания данной спецификации разумным считается следующее:

    Индикация передачи обслуживания L2 может подразумевать, а может и не подразумевать перемещение L2, а перемещение L2 может подразумевать, а может и не подразумевать перемещение L3; эти взаимоотношения могут быть функцией типа L2, но могут быть также функцией реального развертывания беспроводной топологии.

    Если только не известно наверняка, что индикация передачи обслуживания L2 вероятно подразумевает перемещение L3, то вместо немедленной групповой рассылки сообщений запроса маршрутизаторов возможно окажется лучше попытаться проверить, является ли подразумеваемый маршрутизатор все еще двунаправленно достижимым. Это может быть выполнено путем посылки индивидуального сообщения Neighbor Solicitation и ожидания ответного сообщения Neighbor Advertisement с установленным флагом solicited (запрошенное). Заметим, что это подобно определению недостижимости соседей, но не имеет того же самого конечного автомата, например, состояния STALE.

    Если подразумеваемый маршрутизатор не отвечает на это сообщение Neighbor Solicitation, имеет смысл продолжить групповую рассылку сообщений Router Solicitation.

Страница 92 из 120

2007 - 2022 © Русские переводы RFC, IETF, ISOC.