Кратко

  • Внешняя FAS могла разрешить, отклонить, перенаправить поток или назначить ему правила, но соединение по-прежнему возникало на коммутаторе.
  • Сообщения LFAP подтверждали отдельные передачи ответственности, а не полный итог услуги.
  • AMBIGUOUS, NO_SUCH_FLOW и отсутствие анализа безопасности показывают, почему решение, действие устройства и экономическую запись нельзя смешивать.

В марте 1997 года RFC 2124 описал практический ответ на отсутствие стандартизованного представления политики соединений. Организации требовалось управлять допуском на нескольких ATM-коммутаторах, не заставляя каждого поставщика понимать её собственный язык правил. LFAP связал Connection Control Entity (CCE) внутри коммутатора с внешней Flow Admission Service (FAS).

Карточка RFC Editor и IETF Datatracker фиксируют статус: Informational, не Internet Standard. Документ подтверждает интерфейс и замысел, а не масштаб внедрения.

Коммутатор спрашивал до установления потока

Начальный обмен всегда исходил от коммутатора. CCE передавала Flow Admission Request (FAR) с идентификатором потока, адресами, видом сервиса, временем и необязательными данными клиента. FAS отвечала Flow Admission Acknowledge (FAA).

FAA могла разрешить или отклонить поток, добавить необязательную или обязательную политику и указать адрес перенаправления. Это было решение FAS по полученному описанию, не доказательство построенной цепи или доставки данных.

Непонятную необязательную политику CCE могла проигнорировать. Непонятная обязательная политика требовала прервать поток и сообщить об ошибке через Flow Admission Update. Центр задавал требование; локальная реализация определяла, станет ли оно состоянием.

Работающий поток создавал отдельные свидетельства

После установления CCE отправляла Flow Update Notification (FUN) по расписанию или при изменении. Сообщение могло содержать время, ACTIVE/INACTIVE, число байтов и пакетов, ячеек или кадров.

Накопительный счётчик шёл от начала потока, дельта — от предыдущего FUN. Потеря типа превращала корректные числа в ложный итог. Даже точный итог не доказывал право использования, доставку приложению или законность счёта.

SUCCESS в Flow Update Acknowledge (FUA) означал, что FAS приняла информацию FUN и теперь отвечала за неё. Это переход ответственности за сведения, но не гарантия долговременного хранения, полноты, согласия резервных экземпляров или результата для клиента.

Позже FAS могла послать Flow Change Request (FCR), изменить политику или остановить поток. Коммутатор отвечал Flow Change Acknowledge (FCA). POLICY_REJECT сообщал о неподдерживаемом изменении, NO_SUCH_FLOW — об отсутствующем состоянии. Первоначальный допуск не делал последующее управление автоматически исполненным.

Повтор был безопасен только при совпадении запроса

Если прежний Flow ID появлялся в FAR, полностью совпадающем с первым, кроме возможного Message ID, FAS повторяла прежний ответ. При ином содержимом она возвращала AMBIGUOUS и требовала новый идентификатор. Идемпотентность принадлежала всему запросу.

NO_SUCH_FLOW прямо показывал рассогласование. FAS могла получить FUN для соединения, которого не допускала или больше не помнила; коммутатор — FCR для уже неизвестного потока. Протокол требовал повторного допуска, отчёта или остановки, а не веры в одну базу данных.

Для переключения FAS выдавала префикс, а CCE добавляла локальный идентификатор. Без префикса один вызов после failover мог выглядеть как два в точке накопления. Пространство имён уменьшало коллизии, но не доказывало одинаковое состояние альтернативных FAS.

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

FAS могла отклонить, перенаправить или остановить соединение. Однако раздел Security Considerations лишь говорит, что вопросы безопасности в документе не обсуждаются. TCP-сессия была транспортом, но не доказательством полномочий источника политики. Сегодня реестр IANA указывает csi-lfap на порту 3145 и отдельно отмечает известное несанкционированное использование порта.

Граница с опубликованными материалами точна. RFC 2063 задаёт архитектуру измерения, а существующая статья BTW исследует временной пробел асинхронного чтения. RFC 2123 описывает NeTraMet, а его статья исследует проекцию трафика набором правил. RFC 2124 исследует переход от центрального решения к исполненному состоянию и согласованной записи.

Running-Code Primacy, Minimum Initial Specification, Localized Future Decision и On Reality Layers Heng Lu дают современный язык той же дисциплине: административное представление не заменяет исполнимую реальность.

LFAP предвосхитил программируемое управление. Его полезнейшее наследие — отдельные квитанции решения, исполнения, состояния и учёта.

Источники