Кратко

  • Формат Header-Last позволял отправителю увидеть размер после сжатия и лишь затем отметить, начинает, продолжает или завершает пакет SDTP исходный последовательный кадр.
  • В RFC 1963 за сегментацию отвечали B и F. Бит E обозначал расширение заголовка CS, а поля последовательности в SDTP не было. B/E и номер последовательности относились к PPP Multilink из RFC 1990.
  • Length разделял пакеты SDTP внутри составного кадра PPP, Port выбирал согласованный канал. Ни одно поле не доказывало отсутствие потерь, физическую идентичность порта или восстановление услуги.

Обычно заголовок стоит перед данными и объясняет, как читать следующие байты. Информационный RFC 1963, опубликованный в августе 1996 года, намеренно изменил этот порядок. В стандартном формате Serial Data Transport Protocol сначала шли переносимые данные, затем Terminal Adaptation Header, причём октеты самого заголовка располагались в обратном порядке. Получателю приходилось разбирать пакет с двух концов.

Такое устройство следовало из времени появления информации. Протокол вырос из работ по сжатию синхронных данных в DSU/CSU. Если сжатый последовательный кадр требовалось распределить по нескольким пакетам SDTP, передатчик мог не знать полезную границу до появления достаточного объёма вывода компрессора. Заголовок в начале заставлял бы объявить тип фрагмента слишком рано. Заголовок в конце позволял увидеть размер, решить, является ли часть начальной, средней или конечной, и затем пропустить описание через компрессор.

Поэтому Header-Last был форматом по умолчанию. Header-First можно было согласовать, если кадры не делились, сжатие не было связано с SDTP или аппаратный тракт предпочитал обычный порядок. Переговоры устанавливали общий способ чтения байтов. Они не сообщали коэффициент сжатия, состояние компрессора или успех сборки.

Перед отправкой данных PPP должен был перейти в фазу Network-Layer Protocol, а SDCP — в состояние Opened. Реестр IANA закрепляет 0x0049 за PPP-SDTP и 0x8049 за PPP-SDCP. Эти значения и состояние подтверждали согласие о грамматике. Они не удостоверяли полноту или пригодность последующего пакета.

По умолчанию одно поле Information PPP содержало ровно один пакет SDTP. Length появлялся только при совместном согласовании Length-Field-Present и LCP Compound-Frames из RFC 1570. Тогда в одном контейнере PPP могли находиться несколько пакетов. Каждая длина включала собственное поле, необязательный Port, адаптационный заголовок, данные и возможный Odd-Pad. Один октет описывал итог от 2 до 255, два — до 65535, а ноль означал весь остаток поля Information.

Length давал парсеру границу единицы. Он не говорил, собран ли исходный последовательный кадр целиком. Соседние единицы составного кадра могли принадлежать разным частям, кадрам или портам. Правильно найденный конец контейнера не заменял сообщения о пропущенном фрагменте.

Multi-Port добавлял согласованное пространство имён. Без него весь трафик относился к неявному Port 0 и октет Port отсутствовал. После переговоров каждый пакет нёс номер: 0–254 для данных и 255 для управления. Часть параметров действовала для отдельного порта, а управление потоком на 255 могло затронуть все порты.

Номер помогал демультиплексировать поток, но не был удостоверением личности. RFC 1963 не связывал Port 7 криптографически с кабелем, устройством, клиентом или услугой. Смысл задавался локальной таблицей соответствий. Совпадает ли она с текущей физической схемой, требовалось подтверждать отдельно.

Границы последовательного кадра обозначали B и F. В синхронном HDLC-подобном режиме B отмечал начало, F — последнюю часть. Оба нуля означали середину, обе единицы — целый кадр в одном пакете. В асинхронном режиме оба бита должны были быть установлены. E выполнял иную функцию: сообщал о наличии расширения CS. Он не был битом окончания.

Это различие устраняет распространённое смешение. В RFC 1990 PPP Multilink действительно использовались B/E и 12- или 24-битный номер последовательности в группе линий. В RFC 1963 такого поля не было. SDTP не мог выявлять пропуск по движению счётчика Multilink, поскольку счётчика в его формате нет.

Сам документ требует сопоставлять таблицу с текстом. В таблице B/F значение 1,0 напечатано и для Begin Frame, и для Final Frame, хотя непосредственно перед ней F однозначно определён как признак последней части. Окружающие определения подтверждают смысл B/F. Но по ним нельзя заявлять, как поступала конкретная реализация. Для этого нужны её код, тесты или трассы, которых среди источников нет.

Особенно ясная граница появляется при обработке внутреннего FCS. Для HDLC-подобного кадра SDTP переносил байты между флагами, но не сами флаги. По умолчанию внутренний FCS передавался. Опция FCS-Type могла удалить его у отправителя и заново создать у получателя. RFC 1963 предупреждал: так делать нельзя без PPP Reliable Transmission или другого уровня, надёжно сообщающего о потерянном пакете. Запрещалось также отдавать пользователю неполный или повреждённый кадр с новым правильным FCS.

Предупреждение показывает, чего не знали B/F, Length и Port. Они описывали форму, протяжённость и согласованное назначение, но не потерю. Если средний пакет исчезал без уведомления снизу, получатель всё равно мог увидеть правдоподобные границы. Новый checksum превратил бы отсутствие материала в ложный признак целостности.

RFC 1663 решал отдельную задачу через согласованные Numbered-Mode, окна, подтверждения и повторную передачу. RFC 1962 согласовывал алгоритмы сжатия и обмен Reset. Нельзя незаметно приписывать их свойства полям SDTP. Header-Last согласовывал время разбиения с работой компрессора; он не был ни компрессором, ни механизмом надёжности.

Различие Лу Хэна между объявленной структурой и исполняемым доказательством хорошо раскрывает этот проект. RFC 1963 задавал небольшой общий язык: расположение, расширение, границу, длину и метку порта. Работающая система всё ещё должна была показать порядок прихода, обработку потерь, правила буфера, локальное соответствие портов, обращение с FCS и передачу приложению. Спецификация делала эти вопросы точными, но не отвечала за исполнение.

Источники