Кратко

  • draft-ietf-nmop-simap-concept-13 задаёт путь от сервиса к поддерживающим логическим и физическим ресурсам и обратный путь от ресурса к зависимым сервисам.
  • Ответ показывает, что сервер представил клиенту при определённых правах, уровне абстракции, источниках и времени. Полнота, синхронизация, причина, полномочия, исполнение и итог требуют отдельных доказательств.

При аварии оператору нужен не перечень оборудования, а цепочка воздействия. От клиентского сервиса необходимо спуститься через его компоненты, логические узлы и каналы, уровни 3 и 2 к физическим устройствам. Начав с подозрительного ресурса, нужно пройти вверх и увидеть сервисы, которые на него опираются.

Service & Infrastructure Map превращает эту задачу в обход графа. Это сильнее набора разрозненных таблиц, но не тождественно наблюдению всей сети. Результат строит SIMAP-сервер; он выбирает экземпляр топологии, связывает внешние источники и применяет правила доступа. Корректный ответ может быть намеренно неполным.

Актуальный документ — draft-ietf-nmop-simap-concept-13 от 4 сентября 2026 года. IETF Datatracker называет его действующим Internet-Draft рабочей группы NMOP с предполагаемым статусом Informational. История фиксирует IETF Last Call до 26 сентября. Это ещё не RFC, и текст может измениться.

Два направления одного графа

Базовыми сущностями служат сети, узлы, каналы и точки терминации. Поддерживающие отношения соединяют элементы внутри уровня и между уровнями. При движении от сервиса клиент находит логические ресурсы и затем физическую основу. При движении от ресурса он начинает с физического объекта или элемента уровня 2 либо 3 и выходит к сервисам, узлам, каналам и точкам терминации, которые от него зависят.

RFC 8345 уже определяет в YANG поддерживающие сети, узлы, каналы и точки терминации. SIMAP расширяет операционный контекст, связывая топологию сервиса с инфраструктурой, инвентаризацией, assurance и наблюдаемостью.

Ссылка на внешнюю модель не переносит автоматически её доказательную силу. Инвентарная запись может иметь другой идентификатор. Симптом assurance мог быть зафиксирован позже топологического снимка. Метрика может описывать интервал, а отношение — проектное намерение. Технически соединённые записи не обязательно относятся к одному объекту в одно время.

Границу ответа задают права

Версия 13 подчёркивает: клиент получает только то, что ему разрешено видеть. Сервер может скрыть уровни или заменить нативную топологию абстрактным представлением из соображений безопасности, управления или коммерции. Такой ответ может полностью соответствовать политике и не быть полной картой инфраструктуры.

Поэтому отсутствие элемента в ответе не доказывает его отсутствие в сети. Один абстрактный узел может представлять несколько нативных устройств. Логический канал может скрывать физические маршруты с разной общей судьбой при отказе. Клиент сервиса может знать нужную зависимость и не видеть внутреннюю структуру провайдера.

Нужно различать и два вида навигации. Переход от канала уровня 3 к поддерживающему пути уровня 2 — движение между уровнями. Переход от агрегированного узла к его нативным компонентам — движение между уровнями абстракции. Запись «получен уровень 3» ничего не говорит о детализации и скрытой части представления.

Слову live нужна временная метка

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

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

До сравнения следует назвать экземпляр, тип представления, источник, время наблюдения и состояние синхронизации. Без этого live остаётся меткой класса, а не доказательством свежести.

Зависимость не устанавливает причину

Если запрос от ресурса возвращает пять сервисов, он подтверждает, что выбранное представление моделировало эти пять сервисов как зависимые. Он не доказывает, что ресурс вызвал пять сбоев. Ресурс мог быть резервным, участвовать в балансировке, находиться в устаревшей связи или изменить состояние после снимка. У сервиса могла быть другая причина отказа.

Причинный вывод требует хронологии: изменение состояния ресурса, совместимое изменение трафика или сервиса, рассмотрение альтернатив и наблюдение восстановления после вмешательства. SIMAP упорядочивает расследование, но не превращает соседство в графе в причинность.

Запись в карту не меняет рабочую сеть

Документ отделяет операции записи SIMAP от конфигурации live-сети. Запись предназначена для what-if анализа, предполагаемой и пассивной топологии. Реальные изменения выполняются обычными операциями контроллера.

Автоматизации нужны разные квитанции: карта или предложение, решение и полномочие, операция контроллера либо устройства, последующее наблюдение. Принятая запись модели не доказывает, что устройство получило команду. Принятая команда не доказывает, что сервис восстановился.

То же относится к closed loop. SIMAP может поддержать мониторинг и анализ, но цикл включает разрешённое действие и обратную связь. Без независимого измерения после действия система знает лишь о завершении этапа собственного процесса.

У представления должна быть квитанция

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

Эти ограничения делают SIMAP не слабее, а проверяемее. Надёжный вывод звучит не как «это сеть», а точнее: при таких источниках, правах и времени этот сервер представил такую зависимость.

Источники

Текст и состояние: SIMAP, версия 13 и история Datatracker. Связанные основы: RFC 8345, RFC 8341, RFC 8040, RFC 9417 и RFC 9408. Проект YANG для SIMAP является индивидуальным Internet-Draft без формального статуса в процессе IETF. Зафиксированный исходный текст: архив версии 13. Контекст транспортной инженерии: RFC 9522.