Кратко

  • RFC 948 сопоставил Ethernet-совместимый способ передачи IP с вариантом по правилам IEEE 802.2/802.3. Поле, которое Ethernet считал типом протокола, в 802.3 означало длину. Физически общая линия не обеспечивала взаимопонимания между узлами с разными способами обрамления.
  • Айра Уинстон предложил сначала дать каждому новому и старому узлу статический выбор формата, пока всем пользоваться Ethernet-совместимым режимом и лишь затем переключить сеть целиком. Двуязычный шлюз мог соединить преждевременно разделившиеся группы, но документ предупреждал о заметной потере производительности.

Поле выглядело одинаково, смысл был другим

RFC 948 отделял совместимость на проводе от совместимости программы. Физические уровни Ethernet Version 2.0 и IEEE 802.3 были практически совместимы. На канальном уровне одно место заголовка получило два назначения: тип вложенного протокола в Ethernet и длина кадра в 802.3. Получатель не мог передать данные IP, пока не решил, какой из двух смыслов применить. Индикатор исправной линии этого решения не принимал.

Первый маршрут Уинстона сохранял уже работающие Ethernet-установки. В рассмотренном 802.3 со скоростью 10 Мбит/с допустимая длина не превышала 1500. Значения выше этой границы разрешалось использовать по частному соглашению. Типы для IP, ARP и формата с хвостом находились выше 1500, поэтому поле можно было использовать как тип протокола на физическом соединении, совместимом с 802.3. Старая часть сети продолжала читать привычные Ethernet-кадры. Числовой зазор облегчал сосуществование; он не объединял два канальных языка.

Второй маршрут строился на LLC Type 1 Unnumbered Information в IEEE 802.2/802.3. Значения DSAP и SSAP равнялись 96 — указанному в RFC 948 глобальному SAP для IP. Если для минимального размера кадра требовались нулевые октеты, они оставались вне IP-дейтаграммы. Для сопоставления адресов документ допускал статические таблицы и настойчиво рекомендовал динамическое обнаружение по образцу ARP. У двух узлов с одинаковой оболочкой IP работал. Сосед на том же проводе, который оставался в Ethernet-режиме, не получал от этого способности разобрать другую оболочку.

Последний узел задавал срок

Уинстон прямо назвал результат смешивания: один физический LAN превращался в две несовместимые подсети. Узел, понимавший оба формата, мог стать шлюзом, но работа через него, по оценке RFC, значительно снижала производительность. Два близких компьютера начинали обмениваться через посредника только из-за несовпадения формы кадра. Схема кабелей уже переставала показывать фактическую сеть.

Автор предпочитал IEEE-совместимый способ. Стандарты IEEE были приняты на национальном и международном уровне, а обрамление могло применяться на других физических сетях семейства 802. Однако Ethernet уже был установлен. Поэтому порядок перехода был частью предложения: новые реализации должны иметь статический выбор; старые нужно обновить тем же выбором; пока идёт работа, все передают в Ethernet-совместимом режиме. После готовности каждого узла весь LAN переходит к IEEE-методу. Если один компьютер всё ещё не умеет выбирать, назначенная дата переключения станет датой разрыва сети.

В 1988 году RFC 1042 зафиксировал другой конкретный вариант для сетей IEEE 802: LLC/SNAP, DSAP и SSAP по 170, нулевой код организации и затем EtherType. Он также пояснил, что кадры широковещания на смешанной физической линии достигают лишь машин с тем же канальным форматом. Если смешение необходимо, документ рекомендовал IP-шлюз, будто это две отдельные сети. Последующая спецификация сохраняет проблему совместимости, хотя способ обрамления отличается от прямого SAP 96 в RFC 948. Данных о выполненной по плану Уинстона миграции эти документы не дают.

Исторический конфликт помещается в одном вопросе: кто вправе объявить сеть обновлённой? Провод и порт готовы раньше, чем все участники одинаково понимают рамку вокруг IP. RFC 948 передал ответ не кабелю, а согласованному выбору каждого узла.

Источники