Кратко

  • RFC 1613 требовал отдельное TCP-соединение для каждого виртуального канала X.25. Logical Channel Number внутри XOT был произвольным и не различал одинаково пронумерованные вызовы в разных потоках.
  • XOT передавал X.25-механизму идентификатор потока; выходной локальный интерфейс устанавливал собственный LCN. Операционная идентичность находилась в отображении, а не в переносимом поле.
  • Явные параметры управления потоком, локальные управляющие пакеты и отдельная настройка PVC проводили ту же границу между общей совместимостью и локальным решением.

Коллизия возникала не в пакете, а в области имён

Устройства A и B открывают XOT-сеансы к C с одинаковым LCN. Если C индексирует состояние только числом, два допустимых локальных значения попадают в одну ложную глобальную таблицу.

RFC 1613, cisco Systems X.25 over TCP (XOT), приводит этот пример. Карточка RFC Editor датирует документ маем 1994 года и относит к Informational, а не Internet Standard. Это свидетельство опубликованного метода, но не всеобщего внедрения.

На каждый Virtual Circuit полагалось отдельное TCP-соединение. В XOT сам LCN не имел решающего значения. X.25-механизм C должен был знать, что пакеты пришли с разных логических интерфейсов; XOT передавал ему идентификатор потока.

Поток добавлял недостающий контекст

TCP создавался раньше канала X.25; использовался TCP-порт 1998, а данные XOT в SYN запрещались. Нынешний реестр IANA показывает x25-svc-port на 1998 для TCP и UDP. Запись координирует число, но не доказывает активную службу, владельца или соответствие. RFC 1613 определяет TCP.

Соединение разделяло одинаковые LCN, но не аутентифицировало человека, не давало полномочий и не подтверждало прикладной результат.

Исторический TCP в RFC 793 передавал упорядоченный поток октетов без границ пакетов X.25. XOT добавлял четыре байта: 16-битные Version и Length. Ненулевой Version или незаконная длина требовали закрыть TCP.

Это обрамление — только предпосылка. RFC 1006 уже восстанавливал границы TPDU другим четырёхоктетным заголовком, и BTW посвятил этому отдельный материал. В XOT даже целый пакет можно связать не с тем каналом, если потерять поток и интерфейс.

На выходе номер менялся

Перед отправкой через локальный X.25-интерфейс реализация устанавливала LCN этого интерфейса. Число менялось, а предполагаемый circuit продолжался.

Надёжная квитанция связывает TCP connection, логический XOT interface, входной LCN, выходной интерфейс и его LCN. Одно число двусмысленно; одни TCP endpoints скрывают локальное назначение. Running-Code Primacy сужает утверждение: RFC задаёт минимум, а конфигурация, переходы и пакеты доказывают конкретное отображение.

Общего default не существовало

В Call следовало явно указывать Packet Size и Window Size: разнородные площадки через TCP/IP не могли полагаться на единый сетевой default. Решение принять неполный Call оставалось локальным, но Call Confirm должен был вернуть фактические значения.

Flow control мог быть end-to-end или локальным. Локальный вариант мог дробить и объединять DATA и вести разные последовательности. Связка modulo 128/8 требовала перевода и уменьшения слишком большого окна либо отказа. RNR в одном направлении не означал остановку DATA в другом. Надёжность TCP не доказывала совместимость окна, готовность получателя или завершение операции.

Interrupt и Reset сохраняли сквозной смысл. Restart, DTE Reject, Diagnostic и Registration были локальными и не пересекали XOT.

PVC, обычно подготовленный без Call/Clear, требовал нестандартного setup после TCP. Сверялись имена интерфейсов, локальные LCN и параметры потока. Статусы различали отсутствующий/down интерфейс, неизвестный PVC, несовместимую конфигурацию или flow control. Нулевой успех вёл к локальным Reset; закрытие TCP разрывало PVC. Две связи после коллизии setup не могли одновременно нести данные.

Граница доказанного

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

Мы не тестировали реализацию, выпуск Cisco, оператора или capture. IANA не подтверждает работающую службу. Текущее распространение, инциденты, прикладной успех и прямое происхождение современных overlay не установлены.

Надёжный вывод уже: корректному полю может не хватать области действия для идентификации операционного объекта. RFC 1613 сохранил в потоке и интерфейсе границу, которая не помещалась в числе.

Источники