Кратко

  • В SDP RFC 3108 направлением forward считалось движение от описываемого ATM-узла. В bearer signaling forward начинался на стороне, пославшей setup. При обратном создании SVC один параметр получал противоположные названия на двух уровнях.
  • Четырёхбайтовый eecid один к одному связывал сервисный вызов с поздней заявкой bearer. Это был локальный ключ корреляции, а не личность, аутентификация, глобальный номер или доказательство передачи медиа.

Правильное число оказалось в другой системе координат

Шлюз называет исходящий от него трафик forward. Протокол установления соединения называет forward путь от отправителя setup к получателю. Если bearer начинает удалённая сторона, один и тот же PCR, выходящий из первого шлюза, будет forward в SDP и backward в ATM-сигнализации. Оба определения корректны внутри своих систем.

RFC 3108 вышел в мае 2001 года на Standards Track. Он применил синтаксис SDP из RFC 2327 к ATM/AAL2 bearer connections и ввёл атрибуты для адресов, адаптационных уровней, traffic descriptors, QoS, типов bearer, каналов и сервисов. Описания могли передаваться с SIP, MGCP или Megaco/H.248.

Главной была независимость service-level call control и bearer setup. Шлюз, начинавший вызов, не обязан был начинать SVC. RFC 3108 определял направление SDP относительно рассматриваемого ATM-узла: от него — forward, к нему — backward независимо от инициаторов.

ATM/AAL2 signaling выбирал другой ноль: от инициатора setup к получателю. В backward setup сервисный инициатор принимал запрос bearer. Его исходящий параметр оставался forward в SDP, но становился backward в ATM. Шлюз должен был поменять направления при переводе.

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

Направление было частью состояния

Атрибуты atmQOSparms и atmTrfcDesc содержали обязательный directionFlag: f, b или fb. Прочие поля могли быть , если параметр не задан, неприменим, подразумевается или известен иным путём.

Поля описывали пиковую и устойчивую скорость ячеек, burst, вариацию и величину задержки, допустимые потери. Для чтения требовались reference node, инициатор вызова, инициатор bearer и протокол. Слово forward без этих координат не было завершённым фактом.

Символ $ в некоторых местах отдавал выбор получателю. Он не показывал, что именно выбрано и установлено. Дефис тоже имел контекстные значения. Синтаксис доказывал допустимость описания, но не решение policy или running state.

Ключ выбирал будущий получатель setup

Сервисный контекст мог сначала прийти через controllers, а ATM setup — позже напрямую из сети. Для соединения записей RFC 3108 применил eecid, end-to-end connection identifier, синоним четырёхбайтового bnc-id в указанных контекстах.

При forward establishment завершающий вызов шлюз выбирал значение, передавал его по SDP исходящей стороне и получал обратно в инициированном ею setup. При backward establishment значение выбирал исходящий шлюз, передавал завершающему и получал в setup, начатом оттуда.

То есть узел, которому предстояло принять setup, заранее выпускал собственный поисковый ключ. Уникальность требовалась только внутри этого узла. Назначившая сторона управляла освобождением и reuse; RFC рекомендовал хранить значение до завершения соединения.

Совпадение означало корреляцию, не больше. eecid не называл человека, не аутентифицировал peer, не создавал circuit и не измерял media. Setup/connect подтверждал bearer state; двусторонние пакеты и приложение подтверждали результат.

Кодирование ключа в bearer signaling оставалось компетенцией соответствующих протоколов. RFC приводил возможные information elements, но не объединял две записи в один источник истины.

Описание, установка и трафик были разными событиями

В примерах controllers обменивались сервисной информацией и давали команды шлюзам. Затем один шлюз посылал ATM setup с eecid, другой находил контекст и отвечал connect. Лишь после этого bearer мог нести media.

SDP подтверждал описание. Control acknowledgement подтверждал принятие команды. Setup показывал попытку, connect — логическое состояние. Ни один сам по себе не доказывал трафик в обе стороны, реальную задержку, потери или качество приложения.

Атрибут chain связывал отдельные SDP descriptions разных уровней одной связи, например IP и ATM, отличая их от альтернатив. Он объявлял отношение документов, но не создание и не работу уровней.

Поздние нормы нельзя переносить назад. RFC 3264 формализовал offer/answer в 2002 году; RFC 4566 и RFC 8866 позже пересмотрели SDP. Они показывают lineage, но не распространённость RFC 3108 и не единственный реальный обмен 2001 года.

Безопасность находилась в оболочке

RFC 3108 отмечал, что шифрование ATM/AAL2 bearer и аутентификация их сигнализации ещё не были стандартизированы подобно RTP payload. Строка SDP k= могла описать ключ или способ его получения, но не доказывала включённую защиту.

Описание могло прийти от недоверенного subscriber equipment. Защита возлагалась на encapsulating protocol или нижние уровни. SIP, MGCP и Megaco могли использовать IPsec authentication и опциональное шифрование. Возможность не равнялась факту конкретной сессии.

Полная цепочка сохраняет отдельно исходный SDP, sender и reference node; роли call и bearer; значение до и после перевода; allocator, scope и lifetime eecid; setup/connect/release; security association; установленную QoS; counters; пакеты обоих направлений и результат приложения.

У слов тоже должна быть provenance

ATM стал историей, но дефект остался. Распределённые системы повторяют слова local, active, primary, owner и forward на разных уровнях. Строка сохраняется, система координат меняется. Подпись может гарантировать неизменность сообщения и при этом сохранить ошибочное значение.

Шлюз RFC 3108 не мог выбрать один документ главным: каждый был авторитетен в своей области. Нужно было переводить, сохранять происхождение и связывать записи, не сливая их. Running state и наблюдаемый трафик оставались отдельной реальностью.

Оба уровня говорили forward. Они не спорили о линии, а начинали стрелку с разных мест. Сохранить это начало — значит отличить правильное описание от созданного bearer и от действительно работающего сервиса.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3108.html
  2. https://www.rfc-editor.org/info/rfc3108
  3. https://datatracker.ietf.org/doc/rfc3108/
  4. https://www.rfc-editor.org/rfc/rfc2327.html
  5. https://www.rfc-editor.org/info/rfc2327
  6. https://datatracker.ietf.org/doc/rfc2327/
  7. https://www.rfc-editor.org/rfc/rfc2543.html
  8. https://www.rfc-editor.org/info/rfc2543
  9. https://www.rfc-editor.org/rfc/rfc2705.html
  10. https://www.rfc-editor.org/rfc/rfc2805.html
  11. https://www.rfc-editor.org/rfc/rfc3015.html
  12. https://www.rfc-editor.org/rfc/rfc3264.html
  13. https://www.rfc-editor.org/rfc/rfc4566.html
  14. https://www.rfc-editor.org/rfc/rfc8866.html