Кратко

  • В контексте NSF RFC 1009 требовала от шлюзов разных поставщиков поддержки Ethernet и последовательных линий как минимальной основы соединения.
  • Приложение отделяло подключение от маршрутизации: открытого IGP, который позволил бы шлюзам разных компаний работать в одной автономной системе, тогда не было.
  • Документ фиксирует требование программы NSF и описанные тогда варианты; он не доказывает всеобщего соблюдения, успешного выбора маршрута или доставки пакета.

Общий разъём не означал общий маршрут

Два шлюза могли соединяться по Ethernet, но по-разному выбирать следующий узел. RFC 1009 сохранила эту границу. Приложение B задало общую технологию подключения шлюзов NSF и тут же признало, что для объединения оборудования разных поставщиков в одной автономной системе открытого IGP не существовало. Рабочая линия сама по себе ещё не доказывала наличие пригодного пути.

Выпущенная в июне 1987 года RFC 1009 формально перечисляла требования к интернет-шлюзам и давала ориентиры производителям. Шлюз описан как IP-маршрутизатор, подключённый к двум или более пакетным сетям. Для каждой сети требовалось учитывать собственное кадрирование, MTU, преобразование адресов и механизмы управления потоком или ошибками, а затем пересылать IP-дейтаграмму и выбирать следующий переход по базе маршрутов.

Во введении говорится, что документ готовился специально для научно-исследовательских программ NSF, хотя сами требования изложены в общем контексте Интернета. Приложение B с названием «NSFNET Specific Requirements» задаёт более узкие рамки. В разделе B.2 ради сетевой совместимости шлюзов разных поставщиков в этом контексте требовалась как минимум поддержка Ethernet и протоколов последовательных линий.

Ethernet подходил для такой роли по практическим причинам: спецификации считались зрелыми, технология была распространена и почти не зависела от поставщика. Документ называл её общей точкой разграничения между сетевыми системами NSF, поставленными разными компаниями. Внутри своей сети поставщик мог оставить собственную технологию коммутации. Но его шлюз должен был иметь Ethernet-подключение к шлюзу другой компании. Общим становился стык, а не вся внутренняя архитектура.

Совместимость маршрутов решалась отдельно

Ethernet переносит дейтаграммы по совместимому каналу, но не подсказывает маршрутизатору, какой сосед знает путь к цели. Раздел B.3 утверждает, что открытого IGP для совместной работы шлюзов разных производителей в одной автономной системе тогда не было. Вместо единого решения RFC описывает несколько реально используемых подходов.

Как минимум один поставщик применял собственный IGP и EGP для связи с остальным Интернетом. RIP успешно связывал устройства разных производителей, хотя протокол не был документирован, а реализации различались в деталях. Сетевое сообщество NSF создало и программу-шлюз для посредничества между протоколами. Её прототип работал на 4.3BSD, обменивался маршрутами внутри системы через RIP и Hello и использовал EGP для связи с другими автономными системами.

Роли этих компонентов различались: Ethernet обеспечивал общий канал, RIP или программа-посредник обменивали и переводили сведения о маршрутах, а EGP работал на границе автономных систем. Упоминание любого из них не доказывает, что устройства вычислили одинаковый маршрут, внесли его в таблицу пересылки или доставили пакет.

RFC 1009 показывает промежуточный этап: NSF могла задать предсказуемую точку подключения поставщиков раньше, чем появился общий способ вычислять маршруты. В 1995 году её сменила RFC 1812. Эта последовательность документов не говорит о том, как конкретная компания реализовала требование или как именно переключилась отдельная сеть.

Более поздний принцип проектирования

В позднейшей Note 64 автора Lu Heng предложил ограничивать общую спецификацию правилами, необходимыми для совместной работы, а остальные решения оставлять тем, кто запускает системы. Этот взгляд помогает отделить интерфейс Ethernet от внутренних решений производителей. Но NSF установила условие в рамках своей программы закупок. Это не было добровольным изменением для всего Интернета и не формулировалось авторами RFC 1009 в терминах Note 64.

Источники и границы выводов

Основной источник — RFC 1009, разделы B.2–B.3 приложения. Предшествующий проект — RFC 985; последующий документ — RFC 1812. Они подтверждают записанные требования и описанные способы маршрутизации, но не внедрение у конкретного поставщика, работу конкретной сети, сходимость маршрута или доставку трафика.