Кратко

  • RFC 3033 назначил интернет-значения для Q.2941 Generic Identifier и Q.2957 User-to-user Signaling, разделив идентификаторы сеанса, ресурса и переносимые данные протокола установки.
  • Корректное значение было входом координации, а не квитанцией исполнения: новый VC, распознавание на вызываемой стороне, уведомление IP-уровня и реальный перенос требовали отдельных подтверждений.

Самый обманчивый кадр процедуры выглядит почти завершённым. SETUP несёт полную пятёрку параметров IPv4-сеанса. Принимающая сторона понимает, о каком потоке идёт речь. Но сеанс может оставаться на общем VC по умолчанию: новый канал ещё не подтверждён, а IP-уровень ничего не переключил.

RFC 3033 был опубликован в январе 2001 года как Proposed Standard. Он распределял значения в двух необязательных информационных элементах B-ISDN. Документ называл их необходимой основой для долговременных и чувствительных к QoS сеансов поверх ATM, но тут же предупреждал: это может быть не полный протокол, обеспечивающий совместимую реализацию. Назначение поля было полезной частью процедуры, а не заявлением о её завершении.

Между именем и трафиком стояла последовательность

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

На вызываемой стороне объект сигнализации B-ISDN должен определить, что входящий вызов относится к интернет-сеансу, и сообщить об этом объекту IP. Перемещает сеанс именно IP-уровень. Идентификатор даёт обоим уровням общего адресата разговора; он не обнаруживает поток, не строит канал, не гарантирует внутреннее уведомление и не меняет пересылку.

Получение идентификатора, установление VC, перенос сеанса и появление пакетов на новом пути — четыре разных события. Если первое автоматически закрывает остальные, символу приписывают исполнительную власть.

Два контейнера решали разные задачи

Generic Identifier по Q.2941 переносил идентификаторы между плоскостями управления. Сеть ATM могла проверять его содержимое, а элемент мог включать несколько типизированных значений. UUS по Q.2957 переносил пользовательские данные через плоскости управления, и сеть не проверяла их содержание. Правила исключений и взаимодействия тоже различались. Максимальные размеры составляли 63 и 133 октета.

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

Тип ограничивал утверждение

Значения приложений 0x03, 0x04, 0x05 и 0x06 обозначали IPv4, ST2+, IPv6 и MPLS. Тип 0x01 означал Session, 0x02 — Resource; отдельные диапазоны сохранялись для IANA и экспериментов.

IPv4-сеанс кодировался 13 октетами: два адреса, протокол и два порта. IPv6-вариант занимал 37. Обе формы предназначались для явных резервирований; шаблонные соответствия потребовали бы другого типа. MPLS VCID был четырёхоктетным ресурсом. Тип сообщал, как прочитать байты, но не говорил, что ресурс действительно предоставлен.

RFC сохранил и неопределённость. Он не задал порядок нескольких идентификаторов, смысл повторов одного типа или пустого элемента. Если SETUP либо ADD PARTY содержал Generic Identifier, ответ CONNECT либо ADD PARTY ACK должен был вернуть хотя бы один, но не обязательно тот же. Это позволяло вести согласование, не описывая его подробный протокол.

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

Перенос RSVP не был решением о резервировании

В UUS дискриминатор 0x06 обозначал интернет-протокол или приложение, а 0x02 — сообщение RSVP. Resv мог идти с SETUP, ResvConf с CONNECT, ResvErr или ResvTear с RELEASE.

RFC сравнивал последовательный вариант, когда установочный протокол передавался по существующему VC и состояния создавались одно за другим, и одновременный вариант внутри сигнализации B-ISDN. Одновременность упрощала допуск и таймеры, но не поддерживала по меньшей мере PVC. Поэтому обе процедуры сохраняли значение.

Наличие Resv не доказывает допуск. CONNECT не подтверждает установку требуемого QoS на всех уровнях. Существующий VC не подтверждает, что сеанс им пользуется. Решение RSVP, состояние канала, состояние IP, наблюдаемые пакеты и результат приложения должны храниться отдельно.

Узкая спецификация не спрятала пробелы

Агрегация сеансов, шаблонные идентификаторы, IPv6 flow label и классы трафика остались открытыми вопросами. Диапазоны IANA давали пространство будущего управления, а не свидетельство последующих назначений или внедрения. Раздел безопасности упоминал проверенный сетью номер вызывающего абонента как возможную часть аутентификации, но не превращал идентификатор сеанса в полномочие.

Исторический вывод не требует утверждений о распространённости ATM. Общий идентификатор помогает разным системам говорить об одном объекте, но не делает общими их машины состояний, права и результаты. RFC 3033 точно назвал предмет координации и оставил видимой работу, которая должна изменить реальность после этого.

Источники

Lu Heng не писал и не одобрял RFC 3033, рекомендации ITU-T или контекстные RFC. Его эссе используются как явно обозначенные аналитические рамки.