Кратко

  • RFC 1201 позволял передавать одну датаграмму в виде до 120 кадров ARCNET, каждый длинный кадр содержал не более 504 октетов клиентских данных.
  • Предел в 60 480 октетов описывал возможности формата, а не сетевой MTU: максимум требовалось настраивать и согласовывать между узлами.

Уровень определяет смысл подтверждения

Аппаратура ARCNET могла принять кадр, но не донести подтверждение приёма до отправителя. Тогда отправитель повторял передачу, и получатель видел тот же фрагмент снова. RFC 1201 предписывал игнорировать повторную часть при сборке пакета, чтобы дубликат не разрушал уже идущую реконструкцию. Подтверждение кадра, повторная передача и готовая IP-датаграмма здесь были разными событиями.

Эта граница важна для перехода между двумя схемами передачи. Опубликованная в 1988 году RFC 1051 описывала прежнее отображение IP и ARP на ARCNET, поощряла IP-фрагментацию и рекомендовала MTU 253 октета, если часть узлов не поддерживала расширенный кадр. В феврале 1991 года RFC 1201 заменила её и перенесла разбиение пакета на канальный уровень ARCNET.

Формат ограничивал, но не задавал MTU

Длинный кадр ARCNET имел фиксированную длину 512 октетов. Однако программному обеспечению было доступно не всё поле: часть занимали аппаратный и программный заголовки и заполнение. Клиентские данные занимали до 504 октетов. Короткий кадр был 256 октетов, а для длины данных 250, 251 или 252 октета существовал отдельный формат исключения.

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

До 120 частей по 504 октета давали 60 480 октетов. RFC 1201 называла такую длину непрактичной и требовала настраиваемого максимума, согласованного между узлами одной сети. Реализация должна была принимать датаграммы до 576 октетов и настоятельно рекомендовала поддержку 1 500. Эти нормативные значения не подтверждают фактическую настройку конкретной ARCNET или успешную передачу.

504 октета позволяли избежать канальной фрагментации, но увеличивали число IP-пакетов на каждом узле пути. RFC упоминала TCP MSS и обнаружение MTU, например RFC 1063, как способы сообщить меньший размер. Более поздняя RFC 1191 описывает обнаружение MTU пути IPv4, но не измеряет конкретный интерфейс ARCNET. RFC 791 задаёт контекст IP-датаграмм, а RFC 826 — ARP.

Один носитель — два несовместимых формата

RFC 1201 сообщает о соглашении пяти компаний от 1989 года применять новый формат канального уровня ARCNET. Он использовал номера протоколов 212 для IP, 213 для ARP и 214 для RARP; в RFC 1051 значения отличались. Две схемы могли находиться в одной физической ARCNET, но, как прямо говорится в RFC 1201, не могли общаться друг с другом. Совместная среда не гарантировала совместимую интерпретацию.

RFC Editor сейчас указывает для RFC 1201 статус STD 46 / Internet Standard. Это подтверждает каталогизацию стандарта, но не число установок и не долю совместимых устройств. Документ подтверждает более узкую историю: фиксированные кадры привели к фрагментации на канальном уровне; практический максимум остался настройкой сети; смена идентификаторов обозначила границу совместимости.

Источники