Кратко

  • RFC 1490 рекомендовала, но не требовала, делить пакеты, превышающие максимальный размер кадра Frame Relay; сборка обратно выполнялась на оконечных DTE этой сети.
  • Фрагменты должны были идти в строгом порядке по одному виртуальному соединению. Потеря или повреждение части приводили к отбрасыванию всего сообщения, а повторную передачу поручали протоколу верхнего уровня.
  • В 1998 году RFC 2427 сообщила, что общая инкапсуляция широко внедрена, но алгоритм фрагментации не имел совместимых реализаций. Его удалили и указали на FRF.12.

RFC 2427 не выносит общий приговор всей RFC 1490. В документе 1998 года сказано, что инкапсуляция нескольких протоколов, описанная в RFC 1490, широко применялась и внедрялась. В том же приложении авторы пишут, что алгоритм фрагментации не имел совместимых реализаций. Преемник исключил его и заменил ссылкой на FRF.12. Это не означает, что никто никогда не писал такую реализацию. Это означает, что устройства с разными реализациями не могли работать друг с другом по этому алгоритму. Именно эта разница важна для истории протоколов.

В 1993 году проблема начиналась с размера. RFC 1490, опубликованная в июле, описывала передачу маршрутизируемого и мостового трафика по сети Frame Relay. В некоторых сетях максимальный кадр мог иметь размер всего 262 октета, тогда как инкапсулированный пакет мог быть больше. Фрагментация позволяла делить его на кадры подходящего размера и собирать на другом конце. Стандарт рекомендовал эту возможность, но не требовал её. Поэтому базовая инкапсуляция могла использоваться даже там, где оба устройства не поддерживали дополнительный алгоритм.

Граница обработки была существенной. RFC 1490 ограничивала фрагментацию краями сети Frame Relay — оконечными устройствами DTE. Сначала отправитель инкапсулировал пакет, затем делил его на кадры, которые сеть могла переносить. Получатель собирал пакет и передавал его в тот же путь обработки, что и пакет, пришедший целиком. IP не получал последовательность небольших IP-дейтаграмм. Это была локальная мера против ограничения размера кадра в конкретной сетевой услуге.

RFC 791 описывает другой механизм — фрагментацию на уровне IP. В самом IP-дейтаграмме находятся идентификатор, смещение и признаки фрагментации; исходный дейтаграмм собирает узел назначения IP. В RFC 1490 уже инкапсулированный пакет помещался в отдельную структуру фрагментации и восстанавливался на границе Frame Relay до обычной обработки переданного протокола. Похожие слова не означают одинаковую сетевую роль, получателя или ответственность.

Формат RFC 1490 требовал сохранять состояние незавершённого сообщения. Каждый фрагмент включал идентификатор инкапсуляции, двухоктетный номер последовательности, смещение и признак последнего фрагмента. Номер увеличивался с каждым новым фрагментируемым сообщением и при запуске выбирался случайно. Смещение задавалось шагом в 32 октета; первая часть начиналась со смещения ноль. Эти поля позволяли получателю определить принадлежность частей, поставить их в правильные места и понять, когда сообщение собрано.

Правила упорядочивания были строгими: фрагменты следовало посылать от нулевого смещения и не прерывать другой информацией для того же канала данных. Устройство должно было уметь собрать не менее 2 КиБ; рекомендовалось 8 КиБ. При потере или повреждении фрагмента вся передача отбрасывалась. Повторная отправка отдельной части не предусматривалась — ею должен был заниматься протокол верхнего уровня.

Таймера сборки тоже не было. RFC 1490 объясняла это требованием Frame Relay доставлять кадры по порядку: получателю не требовался собственный таймер, чтобы признать неполную последовательность устаревшей. Это предпосылка алгоритма, а не замер каждого оператора и не доказательство, что все устройства успешно ей пользовались. Незавершённое сообщение всё равно занимало память; потеря части означала отбрасывание целого, а восстановление оставалось за верхним уровнем.

Через пять лет RFC 2427 разделила судьбу разных механизмов. Она назвала инкапсуляцию RFC 1490 широко внедрённой и отметила её принятие отраслевыми и ITU-документами. Но для алгоритма фрагментации зафиксировала отсутствие совместимых реализаций и упомянула замечания о его недостаточности для некоторых применений Frame Relay. Алгоритм убрали в пользу FRF.12. Документ не называет производителя, конкретный сбой или причину несовместимости. Источники дают право зафиксировать исход, но не выдумывать детали его причин.

Поэтому неверны оба упрощения. Отсутствие совместимости фрагментации не означает, что RFC 1490 целиком не применялась: преемник утверждает обратное о базовой инкапсуляции. Но широкое применение инкапсуляции не доказывает, что каждая её необязательная функция заработала между устройствами. Один стандарт может содержать несколько механизмов с разными циклами внедрения и разными наборами совместимости.

Пометка «поддерживает RFC 1490» не отвечает на рабочие вопросы. Какую функцию поддерживает устройство? Какой размер кадра задан для виртуального соединения? Совпадают ли у двух DTE формат и порядок фрагментов? Кто повторяет передачу при потере части? RFC 2427 сохранила ответ на уровне механизма: базовая инкапсуляция имела широкую реализацию, а фрагментация — нет подтверждённой совместимости. Переход к FRF.12 показывает изменение стандарта, но не доказывает, что его приняла каждая последующая сеть.