Кратко
- BACP разрешал гонку одновременных запросов; BAP требовал ответа до действия; Call-Status затем фиксировал исход звонка и решение о повторе.
- Request-Ack подтверждал допустимую принятую команду, но не линию и не трафик. Полная BAP-дейтаграмма должна была оставаться несжатой и незашифрованной для перехвата ISDN-адаптером.
RFC 2125 интересен не обещанием автоматической полосы, а дисциплиной отказа от преждевременного слова «успех».
RFC 1990 уже определил сборку PPP Multilink bundle. RFC 2125 добавил BACP и BAP для изменения числа линий. Карточка RFC Editor фиксирует статус документа, а реестр IANA — значения протоколов.
Favored-Peer определял очередь, а не личность
Каждая сторона согласовывала ненулевой четырёхоктетный Magic-Number. При одновременных однотипных запросах предпочтение получало меньшее значение; совпадение требовало нового числа.
Это было детерминированное разрешение гонки. Оно не удостоверяло оператора, не проверяло измерение загрузки и не давало общей власти над bundle.
После Ack предстоял сам звонок
Перед самостоятельным звонком отправлялся Call-Request; просьба позвонить в обратную сторону использовала Callback-Request. Каждому Request и Indication требовался Response до действия. Request-Ack означал допустимость и приём, Request-Nak — отказ сейчас, Request-Rej — отсутствие реализации, Request-Full-Nak — достижение предела.
Каждая попытка создавала Call-Status-Indication. При неудаче сообщалось, будет ли повтор; повтор требовал нового результата. Identifier исходного запроса связывал разрешение и исполнение, не смешивая их.
Лестница доказательств выглядела так: BACP открыт; гонка Favored-Peer решена; запрос принят; звонок завершён; член добавлен или удалён через LCP; на нём видны Multilink-фрагменты; приложение получило результат. Ранняя ступень не доказывала поздние.
Наблюдаемая нагрузка требовала согласия
Единого алгоритма загрузки не было. Для снятия линии по данным мониторинга отправлялся Link-Drop-Query; второй узел отвечал по своим наблюдениям и не мог опираться только на входящий трафик. Линия сохранялась, пока хотя бы одна наблюдающая сторона считала её нужной.
Локальная нехватка ресурса действовала иначе. Если порт или B-канал требовался для другой задачи, узел сразу посылал LCP Terminate-Request. Принудительное снятие допускалось и после исчерпания повторов без ответа. Совместная оптимизация не отменяла локальное распоряжение физическим ресурсом.
Повтор сохранял Identifier, чтобы потерянный ответ не превращал дубликат в новую операцию. BAP-пакетам рекомендовался приоритет над данными: сигнал добавления полосы не должен был застрять за самой перегрузкой.
Цена совместимости — открытый управляющий пакет
Некоторые ISDN terminal adapter управляли Multilink перед клиентом, который его не понимал. Поэтому целую BAP-дейтаграмму запрещалось сжимать или шифровать. Согласованное сжатие отдельных PPP-полей оставалось допустимым. Раздел Security Considerations лишь говорил, что вопросы безопасности не обсуждаются.
Открытый BACP, Ack или успешный Call-Status не доказывают конфиденциальность, личность, согласие пользователя, устойчивую полосу или доставку приложения.
Тексты Lu Heng о Running-Code Primacy, Minimum Initial Specification и Reality Layers здесь служат явно указанной современной линзой: общий контракт минимален, эвристика остаётся локальной, а символическое разрешение не заменяет исполненный результат.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
