Кратко

  • В 1991 году BARRNet учитывала 1 816 внешних маршрутов. Раннее внедрение OSPF выявило лишний переход для части трафика NSFNET и нехватку памяти у небольших маршрутизаторов.
  • Отчёт связывает эти ограничения с адресом пересылки и stub-областями в OSPFv2. Это конкретный эксплуатационный случай, а не единственная причина развития протокола.

В апреле 1990 года исследовательская сеть Северной Калифорнии BARRNet ввела в эксплуатацию OSPF версии 1. К ноябрю сеть уже работала с версией 2. Когда в июле следующего года John Moy описал её опыт, речь шла не просто о раннем внедрении. В отчёте показан маршрут с ненужным дополнительным переходом и маршрутизаторы, которым не хватало памяти для хранения всех внешних маршрутов. Эти два ограничения названы причинами двух функций, добавленных в OSPFv2. История ценна своей конкретностью: операторы могли показать реальный трафик и реальные устройства, на которых стало видно, чего протоколу недоставало. RFC 1246, §§6.0, 6.2.1–6.2.2

BARRNet связывала не один университетский кампус. Согласно отчёту 1991 года, сеть обслуживала около 80 площадок от Сакраменто до Монтерея; скорости соединений составляли от 9,6 кбит/с до полного канала T1. В число участников входили университеты, государственные учреждения и компании. В Стэнфорде региональная сеть соединялась с NSFNET каналами T1 и T3; также она была подключена к ESnet в Ливерморе, к DDN через Federal Internet Exchange в NASA Ames и к университетским сетям Калифорнии. BARRNet должна была передавать трафик между своими площадками и одновременно обмениваться маршрутами с несколькими более крупными сетями. RFC 1246, §6.2

Ядро состояло из 14 маршрутизаторов Proteon. Шесть из них образовывали резервированное кольцо, а основные площадки соединяли полные каналы T1. Участники подключались за ядром, преимущественно по звёздной схеме со Стэнфордом в центре. Это важно: внешние шлюзы и маршрутизаторы, обрабатывавшие трафик, находились в разных точках одной региональной сети. В RFC зафиксировано 1 816 внешних маршрутов в OSPF на тот момент. Большинство пришло из NSFNET; остальные — из NSN, от маршрутизаторов BARRNet, продолжавших использовать другие протоколы, и из ESnet. Сеть импортировала маршруты RIP и EGP в OSPF, применяла внешние метрики типа 1 и метки, помогавшие управлять повторной передачей маршрутов через EGP. OSPF не заменил прежние протоколы разом: ему пришлось сосуществовать с уже действовавшими обменами маршрутами. RFC 1246, §§6.2.1–6.2.2

Справочник сетей 1990 года также описывает BARRNet как региональную сеть из арендованных каналов, микроволновых линий и разных типов подключений площадок. В более позднем обзоре Internet2 говорится, что университеты-участники во многом самостоятельно владели маршрутизаторами и обслуживали их. Эти сведения помогают отделить общую систему маршрутизации от ответственности за конкретное оборудование, но не доказывают, что такая модель вызвала лишний переход или нехватку памяти. RFC 1245 описывает испытания совместимости OSPF, а RFC 1131 содержит первоначальную спецификацию версии 1: стандарты, реализации и полевой опыт развивались параллельно. The User’s Directory of Computer Networks (1990); обзор Internet2; RFC 1245; RFC 1131

Первая проблема возникла на границе сети. Только маршрутизаторы BR5 и BR6 обменивались сведениями EGP с системой, которую RFC называет NSS. Если во внешнем объявлении OSPF не было отдельного адреса пересылки, трафик NSFNET, обрабатываемый BR10, BR16 и BR28, сначала шёл к шлюзу, объявившему маршрут, даже когда внешний следующий переход можно было достичь напрямую. В путь добавлялся ещё один маршрутизатор. Поле адреса пересылки в OSPFv2 позволяло указать в объявлении маршрутизатор, к которому следует направлять пакеты для данного назначения, и внутренние маршрутизаторы могли выбирать прямой путь. Спецификация объясняет механизм на общем примере; отчёт Moy связывает такое поведение с конкретными маршрутизаторами BARRNet. Источник не расшифровывает «NSS», поэтому сокращение оставлено без расширения. RFC 1246, §6.2.2; RFC 1247, §§2.2, 12.4.4

Вторая проблема касалась памяти. Некоторым маршрутизаторам не хватало её для хранения всех внешних маршрутов. BARRNet использовала четыре stub-области, каждая представляла собой одну локальную сеть без внутренних маршрутизаторов OSPF. В такие области не передавались внешние объявления, поэтому объём данных, который надо было хранить, сокращался. Отчёт называет это попыткой запустить OSPF на устройствах с ограниченной памятью, а не гарантией совместимости с любым небольшим устройством. Объём памяти и измерения до и после не приводятся. Область получала менее полное представление о внешних маршрутах, зато несла меньшую нагрузку состояния маршрутизации. RFC 1246, §§6.2.1–6.2.2; RFC 1247, §3.6

Moy поставил BARRNet в один ряд с несколькими ранними внедрениями. В том же отчёте названы NASA Science Internet и OARnet; развёртывание OSPF в Интернете началось весной 1990 года. Первое внедрение не выявило ошибок протокола, но показало полезные направления развития. Значение BARRNet точнее любых заявлений о первенстве: отчёт называет маршрутный обход и нехватку памяти, с которыми связаны две функции версии 2. RFC 1247 также указывает, что версии 1 и 2 несовместимы, поэтому переход между ними был эксплуатационной границей. В отчёте указаны месяцы внедрения BARRNet, но нет журнала миграции по каждому маршрутизатору и доказательства одновременного перехода. RFC 1246, §§6.0, 6.2.2; RFC 1247, приложение F

Эти ограничения источников удерживают историю в верном масштабе. Спецификация задавала ожидаемое поведение маршрутизаторов; работающая сеть показала, где модель добавляла лишний переход или требовала больше состояния, чем могло хранить устройство. Источники не утверждают, что топология BARRNet или OSPF сами по себе решили проблемы Интернета. Они фиксируют два практических требования: объявлять фактический следующий переход и давать области с ограниченными ресурсами возможность хранить меньше внешних маршрутов.

Источники