Кратко

  • RFC 2127 представлял физический доступ ISDN, уровни D-канала, каждый B-канал и верхний интерфейс отдельными строками ifTable; связи ifStack задавали локальную топологию, а не подтверждённый сквозной канал.
  • Гиперканал мог занимать несколько B-каналов, но считаться одним вызовом в статистике сигнализации. Повтор одинаковых полей в нескольких строках не означал несколько вызовов или доказанную полезную ёмкость.
  • Для разъединения удалялась локальная связь ifStack. Такая операция сама по себе не удостоверяла освобождение на удалённой стороне, закрытие тарификации или результат приложения.

В телефонной сети метка может быть командой для обработки, а не описанием физики. В RFC 2127 категория передачи speech разрешала сети обращаться с соединением так, чтобы сохранить качество обычной речи. Из этого не следовала пригодность тракта для модема. Имя объекта было полезным, пока его смысл не расширяли.

Тот же принцип определял весь документ марта 1997 года. Физический Basic Rate или Primary Rate доступ, D-канал сигнализации, B-каналы передачи и верхняя инкапсуляция получали разные интерфейсные представления. Внутри D-канала отдельно существовали LAPD и сущность сетевого уровня. ifStack связывал эти слои.

Управляемая карта соединения

Одна строка isdnBearerTable соответствовала одному B-каналу. Состояние различало свободный порт, исходящую попытку, проверяемый входящий вызов и активное соединение. Это был точный ответ на вопрос о локальном носителе, но не на вопрос о доставке данных приложению.

Модель опиралась на RFC 1573: каждая подслойная сущность имела концептуальную строку ifTable, а ifStackTable показывал отношения «выше-ниже». Граф публиковал локальный агент. Он мог верно отражать представление реализации, не подтверждая независимо состояние удалённой АТС или полезную передачу.

Общий контроль коммутируемого доступа был вынесен в обязательный RFC 2128: конфигурация партнёров, активные вызовы и история. RFC 2127 оставлял у себя физические, сигнальные и относящиеся к B-каналам объекты ISDN. Разделение документов не позволяло истории вызова выдать себя за состояние канала.

Несколько носителей не стали несколькими вызовами

Гиперканал соединял один верхний интерфейс инкапсуляции с несколькими B-каналами. Реализация могла использовать DS0Bundle либо несколько строк ifStack с одинаковым HigherLayer и разными LowerLayer.

Во всех относящихся к вызову строках повторялись адрес и подадрес партнёра, происхождение, тип информации, признак multirate, время установления и соединения, тарификационные единицы. При этом таблица сигнализации учитывала один вызов вне зависимости от количества B-каналов.

Поэтому четыре строки B-каналов могли означать один вызов, а один вызов — четыре выделенных канала. Ни одно из этих чисел не доказывало полезную пропускную способность на удалённом конце. Распределение ресурса, сигнальный акт и доставка подтверждались разными данными.

В 1999 году RFC 2494 окончательно определил DS0 и DS0Bundle MIB. Это последующий контекст для варианта группировки, а не свидетельство того, что каждая реализация 1997 года уже так работала.

Разъединение меняло локальную связь

RFC 2127 предписывал удалить строку ifStack, связывавшую верхний интерфейс с B-каналом активного вызова. Управляющая станция могла инициировать чёткое изменение локальной модели.

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

Поля с памятью и неоднозначным нулём

Адрес партнёра относился к текущему или последнему вызову. Формат мог зависеть от коммутатора или PBX и быть специфичным для реализации; при отсутствии данных строка оставалась пустой. Значение не являлось автоматически свежим, нормализованным или аутентифицированным идентификатором.

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

Коммутируемый B-канал управлялся связанным каналом сигнализации. У выделенного B-канала такого управления не было; полностью выделенный PRI мог описываться DS1/E1 MIB без ISDN-специфических таблиц. Отсутствующая сигнализация могла быть свойством режима, а не аварией.

Категории передачи speech, аудио 3,1 кГц и прежнего аудио 7 кГц были сигнальными средствами. Сеть выбирала обработку в пределах обещанной услуги. Метка задавала ограниченное ожидание, но не полный маршрут и не каждое преобразование.

Незаполненная безопасность

Официальная карточка RFC и история IETF относят документ к Proposed Standard рабочей группы ISDN MIB. Реестр errata содержит одну подтверждённую техническую поправку к OID соответствия и одно отклонённое сообщение. Они не подтверждают распространённость или качество продуктов.

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

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

Источники и пределы

Официальные документы подтверждают устройство спецификации, но не конкретное внедрение или измеренный вызов. Более поздние тексты Lu Heng о приоритете работающего кода, минимальной исходной спецификации и слоях реальности используются только как дисциплина вывода: спецификация, локальное исполняемое состояние и эксплуатационный результат требуют разных доказательств. Они не доказывают намерения авторов RFC.