Кратко

  • RFC 3475 требовал, чтобы получение и обработка Call Release запускали освобождение всех связанных Connections.
  • Каждая ветвь всё равно проходила Label Withdraw и Label Release, поэтому подтверждение Call не доказывало атомарное завершение, возврат физических ресурсов или закрытие услуги.

Команда закрытия способна открыть очередь работ. В марте 2003 года RFC 3475 показал это в управляющей плоскости ASON.

Документ имел статус Informational, а не Internet Standard. Он фиксировал коды IANA для расширений CR-LDP, выбранных в работе ITU-T ASON, и оставлял правила применения документам ITU-T. Это запись предложения, не доказательство массового внедрения.

ASON отделял Call как отношение от Connections, которые занимали ресурсы. У одной Call могло быть несколько Connections. Call Setup и Call Release действовали на верхний объект, а процедуры меток — на каждую реализацию.

Call Release содержал Source ID, Destination ID и CALL_ID. Любой сетевой субъект мог отправить его для завершения установленной Call. Notification с подходящим кодом состояния подтверждал освобождение инициатору, но этот чек оставался на уровне Call.

Обработка сообщения должна была запустить освобождение всех связанных Connections. Каждая следовала обычным процедурам CR-LDP Label Release и Label Withdraw. Одно решение становилось множеством переходов для разных соседей, FEC и меток.

RFC 3036 объясняет порядок. Нижестоящий LSR отзывал соответствие через Label Withdraw, а получатель отвечал Label Release. Вышестоящий LSR также посылал Release, когда соответствие больше не требовалось. Ни один такой чек не объявлял глобально, что исчезли все ветви.

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

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

CALL_ID связывал ветви, но не доказывал конец. Он не подтверждал обработку каждого Withdraw, удаление меток, возврат ёмкости кросс-коннекта, прекращение сигнала, трафика, услуги или расчётов.

Для soft permanent connections постоянно настроенные пользовательские сегменты могли сохраниться, пока управляемый сетевой сегмент снимался. Освобождение коммутируемой Connection не описывало всю инфраструктуру.

Crankback давал контраст: Notification с ER-HOP указывал место нехватки ресурсов для перерасчёта. Знание места блока не доказывало ресурсы на альтернативе или успех следующего запроса.

Позднейшие документы, включая RFC 4974, нельзя проецировать назад для изменения статуса или смысла RFC 3475. Они также не подтверждают конкретную эксплуатацию.

В слоях реальности Heng Lu Call Release — инструкция, обработка — решение, каждый обмен метками — ограниченный чек, а удаление состояния, оборудование, сигнал, трафик и услуга — отдельные наблюдения. Ответственная система сохраняет снимок Connections и закрывает каждую ветвь собственными доказательствами до закрытия всей Call.

Источники