Кратко
- RFC 2103 разделил два независимых последствия мобильности: мог измениться локатор конечной точки, а могла измениться топология сети. Одно не обязательно сопровождалось другим.
- Dynamic Association Module мог обновить связь конечной точки с локатором при стабильной топологии. При перемещении целой сети требовалось участие карт и маршрутизаторов.
Самая важная ячейка матрицы RFC 2103 поначалу кажется парадоксальной: локатор не меняется, но топология меняется.
Сетевой узел может получить новых соседей, оставаясь внутри того же объемлющего узла Nimrod. Его конечные точки сохраняют локаторы. Запрос возвращает актуальную и правильную ассоциацию, однако входящим пакетам уже требуется новое описание связности. Ассоциация истинна; маршрут, вычисленный по старой карте, может быть ложным.
Точная граница полезной абстракции
RFC 1992 отделял идентификаторы конечных точек без топологического смысла от локаторов, размещавших узлы на иерархической карте. Смена провайдера требовала новых локаторов: перенос старого префикса в другую часть карты разрушал бы иерархию.
RFC 2103 превратил это разделение в модель мобильности. Dynamic Association Module, или DAM, поддерживал меняющееся соответствие конечной точки и локатора. Это не обязательный сервер и не переименованный DNS, а абстракция для сравнения подходов. Функция могла находиться в базе данных, домашнем представителе или распределённом состоянии маршрутизаторов.
Документ выделил четыре случая: не меняется ничего; меняется только локатор; меняется только топология; меняется и то и другое. Удобная история о перепривязке полностью описывает лишь второй. В третьем DAM нечего обновлять, хотя карту Nimrod надо менять. В четвёртом работают обе стороны.
Мобильность сети обнаружила утечку абстракции
В числе примеров были переезд организации и беспроводные сети в поездах, самолётах, автомобилях и судах. Когда узел меняет соседей, меняется граф. Если он выходит из объемлющего узла, могут измениться и локаторы его устройств.
RFC 2103 предупреждал, что обычные обновления топологии Nimrod, вероятно, оптимизированы для сравнительно медленных изменений. Быстро движущимся сетям могли понадобиться специальные сообщения представителям узлов, чтобы входящие пакеты шли по новой топологии. Документ не определил такое взаимодействие. Он зафиксировал следствие: мобильность сети способна теснее связать DAM с маршрутизацией и маршрутизаторами, чем мобильность одной конечной точки.
Поэтому свежая ассоциация отвечает лишь на вопрос, какой локатор сейчас связан с конечной точкой. Она не доказывает текущих соседей, распространения карты, перерасчёта маршрута или пригодности состояния пересылки.
Три места для хранения состояния
Центральная база, которую опрашивает источник, была проста и давала прямой путь. Но она создавала единую точку отказа и не считалась долгосрочно масштабируемой.
Распределённое ведение ассоциаций с переназначением у дома повторяло форму Mobile IP. Источник посылал к домашнему адресу, а представитель перенаправлял в текущее место. Это не требовало менять источники и обычные маршрутизаторы, ограничивало управляющий обмен и могло скрыть местоположение. Цена — треугольная маршрутизация, зависимость от домашнего представителя и неясная масштабируемость. RFC 2103 называл подход жизнеспособным первым приближением, а не окончательным решением.
Третий класс хранил состояние в маршрутизаторах. Он был сложнее, зато лучше подходил для меняющейся топологии. Реакция происходила ближе к движению ценой участия именно тех компонентов, которые чистая граница DAM пыталась отделить.
Mobile IP был механизмом, а не итогом
Адаптация RFC 2002 состояла из обнаружения, регистрации и пересылки. Мобильный хост регистрировал foreign agent или временный локатор у home agent. Тот сохранял привязку, перехватывал пакет, инкапсулировал и отправлял foreign agent, которому ещё требовалось декапсулировать, свериться со списком посетителей и доставить.
Регистрацию могли принять, а последующая пересылка могла не состояться. Кэшированный локатор мог устареть. Если конечной точки не было в visitor list, пакет следовало отбросить и вернуть ошибку. Непрямой путь мог работать, не будучи оптимальным. Аутентификация запроса также не решала, разрешено ли пользователю присоединиться к посещаемой сети.
Работа различала offline mobility с разрывом сеанса и online mobility с его сохранением. Второй вариант считался желательным, но непрерывность конкретного транспортного сеанса не была показана. Масштабируемость тоже не измерялась: система со временем реакции o не успевает за сменой подключения чаще 1/o, но практического значения o документ не приводил.
Документальная граница
Запись RFC Editor и IETF Datatracker сохраняют Informational-документ февраля 1997 года. RFC 2103 прямо говорит, что это не спецификация протокола, и оставляет открытыми отмену регистрации, детали аутентификации, быстрые обновления, предиктивную маршрутизацию и взаимодействие DAM с маршрутизаторами.
В этой незавершённости и состоит исторический смысл. Nimrod разделял идентичность, местоположение и маршрутизацию; RFC 2103 показал точку, где слои переставали совпадать. Перемещение конечной точки описывалось новой ассоциацией. Перемещение сети меняло граф, который делал ассоциацию полезной.
Приоритет работающего кода, минимальная начальная спецификация и слои реальности Lu Heng используются здесь как явно раскрытая современная рамка, а не историческое доказательство. Публикация описывает интерфейс; эксплуатационная реальность появляется после реализации обновления, принятия его маршрутизаторами и наблюдения пути.
Защищаемый вывод узок: текущая привязка доказывает текущую привязку. Для утверждения об успешной мобильности отдельно нужны версия топологии, распространение обновления, решение маршрута, пересылка, авторизация, сеанс и доставка.
Источники
- RFC Editor — запись RFC 2103
- RFC 2103 — Mobility Support for Nimrod
- IETF Datatracker — RFC 2103
- RFC 1992 — The Nimrod Routing Architecture
- RFC 2102 — Multicast Support for Nimrod
- RFC 2002 — IP Mobility Support
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng — On Reality Layers
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
