Кратко

  • RFC 2333 определял NHRP как разрешение NBMA-адреса на основе уже принятого маршрутного решения, а не как протокол маршрутизации или сквозную проверку.
  • Целесообразность shortcut зависела от топологии, стоимости установки, потребностей приложения, охвата NHRP и условий предотвращения петель.
  • ACK регистрации, авторитетный Resolution Reply и запись кэша были разными свидетельствами управляющей плоскости со своим источником, политикой и Holding Time.
  • В ATM после разрешения адреса ещё требовалось создать виртуальное соединение; пересылка, обратный путь, удалённый сервис и результат приложения проверялись отдельно.
  • Надёжное решение должно накапливать доказательства по этапам: маршрут, применимость, отображение, соединение, пакеты, сервис, приложение.

Самая убедительная строка отвечала на узкий вопрос

Состояние NHRP выглядело точным.

Адрес назначения был связан с NBMA-адресом, ответ мог считаться авторитетным, таймер показывал остаток срока. Такая конкретность побуждала читать запись как готовую достижимость.

Но RFC 2333 был заявлением о применимости. Документ рассматривал, в каких средах NHRP подходит для IP поверх ATM, SMDS или X.25 и при каких ограничениях сокращённый путь остаётся оправданным.

Подходящая среда ещё не означала, что запрос отправлен. Правильный ответ не означал, что ATM принял SVC. Установленный SVC не гарантировал корректную IP-пересылку и обратный путь. Работающий IP не доказывал доступность процесса приложения.

Кэш давал вход следующему действию. Он не был отчётом обо всей цепочке.

Маршрутизация говорила первой

NHRP не заменял протоколы маршрутизации.

Источник обычным способом определял следующий переход. Если путь использовал интерфейс NBMA и нужного отображения не было, клиент мог отправить Resolution Request. Для цели внутри логической NBMA-сети ответ указывал её собственный адрес; для внешней цели — адрес текущего выходного маршрутизатора.

При динамической маршрутизации NHRP отражал выбор сетевого алгоритма.

Этот выбор не становился оптимальным по всем метрикам. Меньшее число первоначальных IP-переходов не гарантировало меньшую задержку, цену или перегрузку. Ответ NHRP также не удостоверял данные и политику, на которых основывался маршрут.

Отображение относилось к конкретной эпохе. При быстрых изменениях shortcut мог стать кратковременным. В некоторых сценариях между маршрутизаторами потеря сведений, нужных для подавления петель, позволяла устойчивую петлю пересылки.

NHRP использовал маршрутное решение, но не закреплял его навсегда.

Сокращённый путь должен был окупаться

В Classical IP over ATM область LIS определяла прямое взаимодействие. ATMARP разрешал адреса внутри LIS, а станции из разных LIS шли через IP-маршрутизатор, даже если общая ATM-среда технически позволяла прямое виртуальное соединение.

NHRP расширял разрешение между LIS одной логической NBMA-сети и мог убрать промежуточные IP-переходы. Это позволяло использовать особенности среды, включая параметры QoS.

RFC 2333 не требовал строить каждый возможный shortcut.

Соединение расходовало сигнализацию, память, состояние коммутаторов и ресурсы интерфейса. Короткий обмен без особых требований мог завершиться раньше, чем новый путь оправдает затраты. Решение зависело от приложения и политики оператора.

«NHRP уместен в этой архитектуре» и «этому потоку сейчас нужен shortcut» были разными выводами.

Право инициировать ограничивало рост состояния

До появления shortcut пакет мог пройти несколько маршрутизаторов. Если бы каждый NHRP-узел отреагировал, один поток получил бы несколько параллельных сокращений.

Документ предлагал разрешить инициативу исходному хосту, первому маршрутизатору, чей следующий переход достижим через NBMA-интерфейс, либо обязательному policy router.

Это было распределение полномочий, а не гарантия результата.

Ограничение определяло, кто вправе создавать отображения и нижележащее соединительное состояние. Без него оптимизация сама становилась источником лишних соединений.

Между маршрутизаторами требовалась остановка

Связи host-host, host-router и router-host входили в общий сценарий. Router-router предъявлял более жёсткие требования.

Базовый NHRP мог не сохранить маршрутную информацию, нужную для подавления петель, например при изменении метрик через границы автономных систем.

Безопаснее был частный случай: целевой хост стабильно и непосредственно соседствовал с не-NBMA-интерфейсом выходного маршрутизатора. Если запрос с Q bit приходил от маршрутизатора без такого условия, выход мог вернуть NAK и оставить трафик на обычном пути.

NAK здесь не означал потерю связности. Он отклонял оптимизацию, безопасность которой не была доказана.

Принятая регистрация не была проверкой жизни

RFC 2332 позволял NHC регистрировать соответствие протокольного и NBMA-адреса у обслуживающего NHS.

Сервер проверял ошибки и политику. Он мог не обслуживать адрес, испытывать нехватку ресурсов, запрещать запрос административно или обнаружить конфликт уникальности.

Успешный Registration Reply означал, что NHS принял информацию на тот момент.

Он не проверял удалённое приложение, не строил автоматически сквозное ATM-соединение, не подтверждал синхронизацию каждого сервера и не обещал неизменность маршрута.

Регистрация имела Holding Time и нуждалась в регулярном обновлении с запасом на потерю пакетов. Сам протокол делал возраст частью смысла состояния.

ACK был квитанцией принятия, а не бессрочным сигналом присутствия.

Авторитетность относилась к отображению

RFC 2332 различал авторитетную и неавторитетную информацию.

Клиент мог потребовать ответ NHS, обслуживающего цель. Транзитный сервер при разрешённых условиях мог ответить из собственного кэша. Различие показывало, кто сделал утверждение и на каком основании.

Даже авторитетный ответ оставался утверждением об адресном соответствии.

Он не резервировал ресурсы SVC, не обходил фильтры и закрытые группы, не проверял обратный путь и не знал состояния приложения.

«Авторитетный» означало компетентный ответчик для этого вопроса, а не свидетель всех последующих событий.

Один кэш хранил разные истории

NHS мог получить запись из регистрации, обмена Resolution, заранее настроенной таблицы, ARP или внешнего механизма. NHC тоже мог использовать ответ, ручную конфигурацию или иной источник.

RFC 2677 делал наблюдаемыми тип, происхождение, применение, действительность Holding Time, остаток и согласованный MTU. Выученная запись должна была исчезнуть при нулевом таймере. Административная запись могла иметь неопределённый срок благодаря постоянной конфигурации.

Одинаковая пара адресов поэтому поддерживала разные решения.

Свежий авторитетный ответ, синхронизированная копия, ручное значение и отрицательный кэш не имели одинаковой доказательной силы. Наличие записи без происхождения скрывало главное.

Кэш хранил утверждения, а не наблюдения за текущими пакетами.

Согласие серверов не измеряло внешний мир

SCSP и распределённая служба из RFC 2335 синхронизировали данные между NHS.

Это уменьшало внутренние расхождения и позволяло разным серверам давать согласованный сервис.

Репликация не опрашивала endpoint заново.

Если исходное отображение устарело, несколько серверов могли идеально разделять одну прошлую картину. Их согласие подтверждало работу синхронизации, не доставку пакетов.

RFC 2332 предусматривал Purge и ошибки для обнаруженной петли, недостижимого протокольного адреса, неправильного ответа, сбоя аутентификации и превышения числа переходов. Состояние изначально оставалось отзывным.

После разрешения ещё предстояло соединение

В ориентированной на соединения NBMA-среде, такой как ATM, источник после получения адреса мог ещё устанавливать соединение с нужной полосой.

Следовательно, resolved не означало connected.

Сигнализация могла отказать из-за ресурсов или политики. Соединение могло получить неподходящие параметры. Прямой поток мог работать без возврата. Хост мог отвечать на IP, а приложение — не пройти аутентификацию или транзакцию.

Каждое событие имело собственного наблюдателя и отдельный момент.

Обычный маршрут сохранял непрерывность

Когда пакет запускал разрешение, источник мог отбросить его, удержать или отправить по обычному маршруту. RFC 2332 рекомендовал третий вариант по умолчанию, чтобы данные могли идти во время поиска shortcut.

Маршрутизатор без NHRP мог молча отбросить запрос. Сокращение не появлялось, но hop-by-hop-связность могла сохраняться.

Архитектура отделяла оптимизацию от базового сервиса.

NHRP мог не сработать при исправном приложении. NHRP мог выглядеть исправным при отказавшем приложении. Наблюдаемость должна была показывать оба состояния.