Кратко

  • RFC 2043 определил два отдельно согласуемых SNA Network Control Protocol: 0x804B управлял SNA поверх LLC 802.2 в пакетах 0x004B, а 0x804D — HPR NLP в пакетах 0x004D.
  • Opened означало лишь разрешение PPP переносить соответствующую оболочку. У SNACP не было опций конфигурации, а безопасность не обсуждалась, поэтому состояние не доказывало другую оболочку, восстановление, личность, авторизацию, доставку, внедрение или успех сеанса.

Фраза «SNA открыт» стирает главный факт RFC 2043. Открытым мог быть один конкретный SNA NCP, разрешающий один конкретный формат пакета. Второй NCP имел собственное состояние, а приложение — собственный результат.

Документ, опубликованный в октябре 1996 года, не был общей историей PPP, SNA или корпоративных сетей IBM. Он решал узкую задачу: как на общем соединении сохранить различие между двумя способами переноса SNA.

Общий физический канал не создавал общего состояния

RFC 1661 описывает последовательность фаз PPP. LCP устанавливает, настраивает и проверяет канал данных. Необязательная аутентификация и оценка качества могут предшествовать фазе сетевых протоколов. Только затем каждый сетевой протокол настраивается собственным NCP.

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

RFC 2043 переносит это правило внутрь SNA. В нём прямо сказано, что фактически существуют два SNA NCP: для SNA поверх LLC 802.2 и для SNA без LLC 802.2. Они согласуются раздельно и независимо. Общая линия — необходимое условие, но не право смешивать их состояния.

Четыре значения образуют две пары

В поле Protocol PPP значения диапазона 0***–3*** называют сетевые пакеты, а 8***–b*** — связанные NCP. RFC 1700 уже содержал четыре назначения, и нынешний реестр IANA сохраняет их.

В первой паре 0x804B — управляющий протокол SNA поверх LLC 802.2. После его открытия 0x004B переносит ровно одну SNA XID или FID2 PIU, перед которой находятся поля LLC: DSAP, SSAP, Control и LLC Information.

Во второй паре 0x804D управляет SNA без LLC. Значение 0x004D переносит один HPR Network Layer Packet, состоящий из NHDR, THDR и данных.

Открытие 0x804B не открывает 0x804D. Наличие 0x004D не сообщает состояние 0x004B. Если мониторинг сохраняет только «SNACP открыт», он удаляет связь между управляющим и информационным пакетами.

Место восстановления ещё не доказывает его результат

В варианте 0x004B LLC(2) включён для восстановления ошибок канала. RFC 2043 возлагает восстановление на маршрутизаторы по концам PPP-соединения. Это точная граница ответственности.

Но она не является отчётом об успехе. Наблюдение 0x004B подтверждает форму оболочки в точке захвата. Оно не доказывает повторную передачу, приём удалённым маршрутизатором, принятие PIU, обработку BIU или продолжение SNA half-session. Для каждого из этих результатов нужны отдельные записи.

Вариант 0x004D несёт HPR NLP без LLC. RFC также отмечает архитектурную возможность передавать HPR NLP через LLC, если реализация включает необязательную башню восстановления HPR. Это проверяемый выбор реализации, а не объединение двух NCP.

Согласование без опций не обещает скрытых свойств

SNACP использует механизм обмена LCP и только коды 1–7, от Configure-Request до Code-Reject. Затем RFC 2043 устанавливает: для SNA и SNA поверх LLC 802.2 нет Configuration Options.

Именно это ограничивает смысл Configure-Ack. Узлы могут разрешить фиксированное семейство пакетов, но не согласуют личность SNA, профиль приложения, цель восстановления, маршрут, свойство безопасности, авторизацию или деловой результат. Подтверждение не может заверить то, чего не было в запросе.

Opened — название состояния узкого автомата, а не заключение о готовности сервиса.

Безопасность и личность остались за пределами документа

В Security Considerations сказано, что вопросы безопасности не обсуждаются. PPP мог аутентифицировать узел до сетевой фазы, но RFC 1661 по умолчанию не требовал аутентификацию. Даже при её наличии доказательство должно называть метод, peer и результат.

Открытый SNACP не доказывает личность, разрешения внутри SNA, конфиденциальность или сквозную целостность. Максимальный размер тоже не является гарантией. RFC 2043 связывает размер SNA-пакета с полем Information PPP; RFC 1661 называет предел MRU и задаёт 1500 октетов по умолчанию. Это вместимость оболочки, а не судьба содержимого.

Документальная сохранность не равна внедрению

RFC 2200 в 1997 году обозначил PPP-SNACP как Elective. RFC 3790 позднее отметил отсутствие зависимости от IPv4. IANA до сих пор показывает четыре назначения. Они подтверждают статус, архитектурное свойство и номерную идентичность, но не использование.

Из них нельзя вывести наличие конкретной реализации, тест совместимости, объём трафика или успешный бизнес-сеанс. Отсутствие зарегистрированных errata говорит только о состоянии реестра исправлений.

Подход Heng Lu помогает оставить вывод узким. Спецификация задала минимальное общее правило: различить оболочку, запустить нужный NCP и не допускать данные до Opened. Работающий код, восстановление, безопасность и реальное принятие требуют других свидетельств. Публикация описывает возможность совместимости, но не создаёт эксплуатацию.

Надёжная запись разделяет четыре факта: PPP достиг сетевой фазы; названный SNACP вошёл в Opened; прошёл пакет с соответствующим значением; независимое свидетельство показало дальнейший результат. Канал, разрешение, доставка и приложение — не одна зелёная лампа.

Источники