Кратко

  • Результат «ноль или один потерянный ICMP-ответ» в RFC 5184 относится к описанной реализации и режиму проб; он не покрывает все радиоканалы, драйверы, аутентификацию, IP-конфигурации и прикладные нагрузки.
  • L2-LinkConnect.confirm(Ack) лишь разрешает канальной операции начаться. Для заявления об успешном handover нужны последующие и отдельно измеренные свидетельства LinkUp, состояния IP и двустороннего сервиса.

В презентации осталась одна цифра: максимум один потерянный пакет. Исчезли частота проб, реализация, топология, тип аутентификации и границы эксперимента. Через квартал цифра стала обязательством для парка устройств, которых авторы опыта никогда не тестировали.

Так лабораторное наблюдение превращается в символическую власть. RFC 5184 позволяет избежать этой ошибки, потому что определяет не один «момент handover», а последовательность сообщений с разными значениями. Надёжный SLA должен следовать этой последовательности, а не наследовать самый привлекательный результат из приложения к экспериментальному RFC.

Сначала нужно знать, что именно измерялось

RFC 5184 имеет статус Experimental, отражает консенсус исследовательской группы MobOpts и не является Internet Standard IETF. Она описывает девять абстрактных примитивов, через которые уровень 3 получает данные уровня 2, подписывается на события и запрашивает канальные действия.

Request просит информацию или услугу. Confirm отвечает на Request. Indication асинхронно сообщает событие. Response может подтвердить Indication. Тип 1 запрашивает текущее состояние через L2-LinkStatus или список кандидатов L2-PoAList. Тип 2 регистрирует интерес к PoAFound, PoALost, LinkUp, LinkDown и LinkStatusChanged. Тип 3 управляет LinkConnect и LinkDisconnect.

Для Типа 3 Ack или Nack возвращается немедленно. После L2-LinkConnect.confirm(Ack) операция соединения начинается; после аналогичного Ack операция разъединения только начинает выполняться. Поэтому таймер до Ack измеряет приём команды, но не завершение радиооперации, не IP-сходимость и не потерю пользовательского трафика.

Одного времени handover не существует

В примере RFC уровень 3 отправляет LinkConnect Request. После Confirm уровень 2 начинает переход. Когда канальная часть закончена, он выдаёт L2-LinkUp.indication. Лишь затем уровень 3 выполняет свой шаг handover.

Даже LinkUp имеет технологически локальный смысл. Для инфраструктурного IEEE 802.11 в примере это установление ассоциации с точкой доступа. RFC 4907 предупреждает, что LinkUp не обязательно означает новую IP-конфигурацию, симметричный путь, низкие потери или своевременное уведомление. Приложению нужен собственный признак готовности Internet layer.

RFC 4957 показывает Ethernet-вариант: наличие физического carrier не гарантирует приём пакетов через bridge domain, поскольку spanning tree может ещё не перейти в forwarding. RFC 5568 отдельно подчёркивает, что ускорение IP-части Mobile IPv6 не сокращает latency переключения самого канала. Подготовленный туннель тоже не гарантирует немедленную доставку: новый access router должен обнаружить мобильный узел.

Значит, отчёт должен различать как минимум observation→decision, decision→Ack, Ack→LinkUp, LinkUp→IP-ready и IP-ready→first successful service. Каждая величина имеет собственное распределение, хвост и причину отказа.

Ноль или один ответ — точное, но узкое свидетельство

Экспериментальная часть RFC описывает реализацию, где канальный handover занимал около миллисекунды, а при ICMP echo-пробах каждые 10 мс терялось ноль или одно эхо-сообщение. Это полезный результат конкретной установки.

Интервал проб задаёт разрешение наблюдения. ICMP не воспроизводит очередь, retransmission, состояние и таймауты каждого приложения. Результат не охватывает все драйверы, прошивки, схемы аутентификации, загруженность эфира, мосты, движения, Mobile IPv6-реализации или направления потока. Он также не доказывает, что потеря симметрична.

Честное использование эксперимента требует сохранить его контекст рядом с числом: оборудование и build, версии протоколов, топологию, нагрузку, частоту и направление проб, объём выборки, распределение, определение начала и конца, а также условия, исключённые из опыта. Без этих полей точность «один пакет» лишь маскирует неопределённость.

Абстрактное качество нельзя сравнивать как физическую единицу

Condition сводит доступную полосу и качество канала к EXCELLENT, GOOD, FAIR, BAD или NONE. Алгоритм зависит от аппаратуры и программной реализации. RFC прямо говорит, что уровни одного устройства независимы от уровней другого, а решения на их основе могут ошибаться и не гарантируют оптимальный link.

Время Indication тоже вне области спецификации и зависит от сканирования. Пороговые настройки различаются. Эксперименты наблюдали ping-pong handover, а L2-LinkStatusChanged может оказаться ненадёжным из-за сложности абстракции качества. Неверное указание способно инициировать лишний переход.

Поэтому текущую оценку следует перепроверять перед необратимым действием. RFC допускает, что IP снова запросит LinkStatus и отменит handover, если прежняя точка остаётся предпочтительной. RFC 4907 рекомендует относиться к link indication как к подсказке, а не как к триггеру, который сам диктует действие.

Точная грамматика не аутентифицирует наблюдение

В разделе безопасности приведён иной источник ошибки. Поддельные beacon или управляющие кадры могут породить корректный L2-PoAFound.indication, после чего узел запросит соединение со злонамеренной точкой. Чередование ложного сильного и слабого RSSI может вызывать PoAFound и PoALost снова и снова, создавая denial of service.

Примитив правдиво передаёт то, что увидела локальная реализация; это не доказывает происхождение наблюдаемого сигнала. Кандидат должен быть связан с доказательством discovery, аутентификацией, локальной политикой и более поздней проверкой пути. В противном случае идеально соответствующий RFC журнал может описывать успешно исполненную атаку.

SLA должен обещать результат, который способен проверить

Для существенного handover нужен неизменяемый operation ID; интерфейс и технология; версия драйвера и реализации; кандидат и происхождение discovery; сырые измерения, окно и пороги; событие с монотонным временем; решение и причина; точный Request; Confirm и узкое значение Ack; начало и окончание link-операции; LinkUp и его технологическое определение; аутентификация; адрес, router, route и binding; потери, latency и прикладной результат; отмена и rollback.

Затем SLA может выбрать проверяемую границу: например, долю операций, где первый двусторонний обмен прошёл за заданное время при явных условиях. Отдельно следует публиковать failure modes и цензурированные данные — операции, где следующая стадия так и не наступила. Иначе среднее по успехам скрывает именно зависшие переходы.

Это соответствует слоям реальности Heng Lu. Метка интерфейса, состояние выполняющегося кода и результат для пользователя находятся на разных слоях. Минимальная спецификация координирует их имена, но не должна отнимать у локальной системы право на дополнительную проверку и отмену.

Быстрый handover и строгая доказательность не противоречат друг другу. Подготовку можно вести параллельно; необратимую власть нужно продвигать по мере появления свидетельств. RFC 5184 ценна не обещанием одного потерянного пакета, а возможностью точно сказать, какой шаг действительно завершён и какой результат ещё предстоит измерить.

Источники

  1. RFC 5184 — HTML
  2. RFC 5184 — текст
  3. Информационная страница RFC Editor
  4. Страница документа в IETF Datatracker
  5. История документа в IETF Datatracker
  6. Ссылки документа в IETF Datatracker
  7. Errata RFC 5184
  8. RFC 4907 — архитектурные последствия link indications
  9. Информационная страница RFC 4907
  10. RFC 4957 — уведомления канального уровня
  11. RFC 5568 — быстрые handover для Mobile IPv6
  12. Информационная страница RFC 5568
  13. RFC 5944 — поддержка IP-мобильности в IPv4
  14. RFC 6275 — поддержка мобильности в IPv6
  15. RFC 4140 — иерархический Mobile IPv6
  16. RFC 3819 — рекомендации проектировщикам подсетей
  17. RFC 4968 — анализ моделей IPv6-канала
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная спецификация и добровольное принятие
  20. Heng Lu — приоритет работающего кода