Кратко

  • TREB версии 01 позволяет участвующим узлам BPv7 записывать выбранный следующий узел, локальное время и характеристики линии, а затем возвращать сведения в отчётах о состоянии Bundle.
  • Запись фиксирует постановку в очередь, а не доказанную передачу или приём; узел может отказаться, скрыть поля, заменить прежнюю запись или не сформировать отчёт.
  • Изменяемые копии TREB защищаются только на каждом отдельном хопе, поэтому проект считает hop-record диагностикой и прямо запрещает использовать его для маршрутизации или контроля доступа.

Маршрут, составленный из показаний

Обычный traceroute наблюдает ответы на последовательное истечение Hop Limit. В DTN логика иная: Bundle хранится до запланированного радио-, оптического или межспутникового контакта, а ответ может вернуться значительно позже.

Исходный узел создаёт traceroute-id. Каждый участник добавляет свой Node ID, выбранный следующий узел, локальное время постановки в очередь, планируемое начало передачи, тип линии, номинальную скорость, оценку расстояния, уровень конвергенции и отношение очереди к объёму следующего контакта. Доставка или удаление образует точку разворота; дальше отчёт может записывать собственный обратный маршрут.

Практическая ценность очевидна. Обычный Bundle Status Report называет отчитывающийся узел, но не несёт весь контекст линии. Одна копия TREB в отчёте о доставке способна вернуть накопленную прямую цепочку и отдельную обратную.

Однако версия 01 остаётся индивидуальным Internet-Draft от 28 сентября 2026 года, истекающим 1 апреля 2027 года и претендующим на Experimental. Запрос к IANA ещё не является назначением типа блока. В разделе реализации нет ни одного внедрения и ни одного измеренного результата.

Запись в очереди не подтверждает передачу

Узел создаёт запись пересылки, когда выбрал следующий хоп и поставил Bundle в очередь. Это не квитанция о работе передатчика, наступлении окна связи, приёме соседом или обработке приложением назначения.

После неудачной попытки или смены следующего узла прежняя запись заменяется. В переданной копии остаётся последнее локальное решение, а не неизменяемая история всех попыток. radiate-time тоже означает план, который не обновляется фактическим временем отправки.

event-time берётся из локальных часов. BPv7 не требует синхронизации узлов, поэтому разность времён разных авторов не становится автоматически задержкой. Интервал до следующей записи смешивает передачу и распространение; проект не разделяет их.

Ноль также не обязательно означает физический ноль. Для времени, скорости, расстояния, слоя конвергенции и перегрузки это может быть неизвестное, неприменимое или скрытое значение. Политика раскрытия оказывается частью набора данных.

У молчания нет единственного виновника

Промежуточный узел вправе не обрабатывать TREB из-за доверия, секретности топологии, ресурсов или локальной политики. Он пересылает блок без изменений. Если next-node-id одной записи не совпадает с self-node-id следующей, между ними есть как минимум один прозрачный узел, но полная последовательность не установлена.

Корректно обновляемый Hop Count помогает оценить число прозрачных хопов. record-limit, напротив, лишь ограничивает рост списка и не предотвращает петли. После заполнения Bundle продолжает путь, а поздние записи могут вернуться как переполнение.

Флаг запроса отчёта тоже не является приказом. BPv7 оставляет решение за Bundle Protocol Agent. Отсутствующий отчёт мог не создаваться, быть исключён политикой или потеряться на обратном пути. По локальному тайм-ауту источник завершает реконструкцию и игнорирует поздние материалы, хотя Bundles ещё могут двигаться.

Следовательно, молчание доказывает только отсутствие нового свидетельства до местного срока. Оно не указывает место потери на последнем видимом узле.

Обратный путь — другой эксперимент

В отчёте о доставке или удалении записи до точки разворота относятся к исследуемому Bundle, а после неё — к Bundle отчёта. Маршруты не обязаны быть симметричными. Прозрачные узлы и заполненный лимит могут скрыть часть обратного пути.

Отчёт о пересылке устроен иначе: он несёт одну запись автора и её позицию и не меняется при возвращении. Источник собирает картину по traceroute-id, идентичности исходного Bundle, позиции и связке Node ID. При репликации одна позиция может иметь несколько ветвей.

Упорядоченная таблица выглядит объективно. Но каждую строку написал описываемый ею узел по собственной политике, а окончательный порядок построил источник. Связный рассказ не становится нейтральным свидетельством.

Целостность заканчивается там, где меняются данные

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

Неизменяемый отчёт о пересылке может быть защищён автором. Это усиливает происхождение одного заявления, но не удостоверяет весь путь. Проект поэтому называет hop-records неаутентифицированными сквозным образом диагностическими данными и запрещает подавать их в маршрутизацию или контроль доступа.

Поле report-to также не служит достаточным удостоверением источника. Поддельный диагностический Bundle может направить увеличенные отчёты третьей стороне. Ограничения размера и частоты, авторизация источников и отказ от подозрительной копии уменьшают усиление, но не устраняют границу доверия.