Кратко

  • RFC 877 задал узкий общий интерфейс IP и X.25: идентификатор протокола, полные последовательности пакетов для дейтаграмм и параметры, которые стороны могли согласовать.
  • Виртуальный канал открывался по требованию, а срок его закрытия после простоя зависел от местной стоимости. Отдельный канал для каждого TCP-соединения стандарт не предусматривал.

Анализ

У канала были свои экономические часы

В сентябре 1983 года Дж. Т. Корб описал в RFC 877 способ передавать IP-дейтаграммы через публичные сети передачи данных на базе X.25. В начале документа сказано, что стандарт приняли CSNET, VAN Gateway и другие организации. Это названные участники, но не перепись всех сетей.

Нужно было соединить две разные модели работы: IP передавал дейтаграммы, а X.25 предоставлял виртуальные каналы через публичную сеть. RFC 877 не пытался превратить сетевой канал в подобие прикладного сеанса. Вместо этого он определил небольшую общую точку стыка, оставив часть эксплуатационных решений подключённым площадкам.

Один байт распознавал протокол

Первый октет поля Call User Data в запросе вызова X.25 служил для определения сетевого протокола. Значение 0xCC обозначало IP. Каждая дейтаграмма передавалась как полная последовательность пакетов X.25: она начиналась на границе пакета, а бит More указывал на продолжение, если требовались дополнительные пакеты. Дополнительный заголовок к пакетам данных RFC не добавлял.

Ограничение размера было задано, но допускало переговоры. Если стороны не согласовали более крупные пакеты X.25, размер IP-дейтаграммы не должен был превышать 576 октетов. В качестве примера большего согласованного размера документ приводит 1024 октета. Размеры пакетов, окна и другие возможности могли согласовываться сторонами; единого глобального профиля не вводилось.

TCP-сеанс не определял срок канала

У виртуального канала был собственный график. По RFC 877 он открывался по требованию, когда интерфейс получал дейтаграмму для передачи. После периода бездействия его можно было закрыть; продолжительность простоя зависела от стоимости открытого канала. Интерфейс также мог закрывать канал при нехватке доступных каналов, и любая из сторон могла завершить соединение.

Граница с TCP обозначена прямо: протоколы выше IP не влияют на этот стандарт. Интерфейс не открывает соответствующий канал X.25 для каждого TCP-соединения. Поэтому долгий TCP-сеанс не обещал постоянный выделенный канал публичной сети. Адаптер управлял сетевым ресурсом, а состояние TCP-соединения находилось на другом уровне.

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

Рекомендация не доказывает повсеместное внедрение

В официальном отчёте о протоколах ARPA-Internet за 1984 год, RFC 924, «Internet Protocol on X.25 Networks» был обозначен как Recommended со ссылкой на RFC 877. В этом документе Recommended означало, что узлам рекомендовалось внедрять протокол; это не доказывало, что его уже использовали все. В 1992 году RFC 1356 назвал метод RFC 877 широко применявшимся и заменил прежнюю спецификацию, чтобы устранить неоднозначности и учесть новые требования к размерам дейтаграмм и пакетов, управлению каналами и многопротокольному соединению.

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

Note 64 как более поздняя оптика

В Note 64 Хэнг Лу предлагает проектный принцип: задавать общий минимум правил, необходимый для взаимодействия, а последующие решения оставлять участникам, которые эксплуатируют систему. Как редакционная оптика эта идея помогает прочитать устройство RFC 877: 0xCC и границы пакетов были общими правилами, но длительность простоя и согласуемые возможности не получили единого глобального значения.

Это ретроспективное сопоставление. RFC 877 не ссылается на Note 64, и записка не подтверждает намерения Корба. Сам RFC показывает более узкий вывод: IP можно было распознавать и передавать по публичной сети X.25, не унифицируя стоимость и срок жизни каждого канала.

Источники