Кратко

  • RFC 1270 утверждал, что обычно SNMP следует передавать по UDP/IP, чтобы управление пересекало маршрутизаторы и не зависело от конкретной технологии канального уровня.
  • Маршрутизация, контрольная сумма, мультиплексирование и фрагментация относились к сетевому стеку; управление, привязанное к каналу, могло застрять в сегменте, который оно наблюдало.
  • Меморандум носил информационный характер и не создавал новый стандарт; он не утверждал, что UDP/IP доставит сообщения управления при полном отказе сети.

Путь управления должен был выйти за пределы канала

К 1991 году SNMP уже позволял станции управления наблюдать за сетевыми узлами и управлять ими. Но оставался практический вопрос: передавать сообщения SNMP непосредственно с помощью каждой локальной сетевой технологии или использовать уровень, соединяющий сети между собой?

Для обычной работы в Интернете RFC 1270 выбрал второй вариант. Аргумент начинался с факта, который легко теряется на схемах протоколов: станция управления и наблюдаемое устройство часто подключены не к одному физическому каналу. Обмен, ограниченный Ethernet, может достичь устройства в том же сегменте, но сам по себе не проходит через маршрутизатор к другому сегменту. Адрес и маршрут сетевого уровня это позволяют.

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

IP был не просто оболочкой

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

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

Это не означает, что IP сохраняет управление при любом сбое. Если одна область нарушена, но есть альтернативный маршрут, маршрутизация может сохранить доступ к устройству за этой областью. Если исчез единственный путь или сам адресат, UDP не создаст запасной маршрут и не гарантирует ответ. Даже наблюдение за сетью зависит от неё самой.

Граница стандартизации, а не универсальный закон

RFC 1270 прямо указывал свой статус: информационный меморандум, не задающий стандарт Интернета. Действовавшая тогда спецификация SNMP, RFC 1157, требовала UDP для обмена сообщениями; RFC 1270 отмечал, что в тот момент UDP был единственным стандартизованным транспортом для этой цели. Поэтому предпочтение UDP/IP опиралось и на существующий стандарт, и на довод об интероперабельности в Интернете.

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

Позднее RFC 1418 определил передачу SNMP поверх службы транспортировки без установления соединения OSI для сред, где UDP/IP недоступен, но по-прежнему считал UDP/IP предпочтительным для большинства интернет-сред. Выбор 1991 года был не абсолютным правилом о единственном допустимом транспорте, а практическим ответом на сеть, через которую предполагалось вести управление.

Чего не доказывал успешный запрос

Наличие маршрутизируемого пути управления не доказывает успешность операции. Отправленный по UDP запрос не является подтверждением доставки. Маршрутизируемый адрес не доказывает, что ответило именно ожидаемое устройство. Ответ не подтверждает исправность каждого промежуточного сегмента; отсутствие ответа не показывает, что причиной стали отказ узла, разделение сети, фильтр, перегрузка, потерянный фрагмент или отсутствующий маршрут.

В этом и заключается историческая ценность аргумента RFC 1270. Канал управления должен был пересекать структуру маршрутизации и не привязываться к изменениям канальной среды. Но свидетельства, возвращавшиеся по нему, оставались ограниченными. Доступность сети, состояние устройства, доставка запроса, получение ответа и последующее действие оператора — разные события. Архитектура расширила область действия управления, но не объединила эти события в одно доказательство.

Источники: RFC 1270, RFC 1157, RFC 1418.