Кратко

  • Новый раздел 3.3 в draft-ietf-ippm-stamp-ext-hdr-14 требует, чтобы плоскость данных выходного узла предоставляла Session-Reflector полученные IP-заголовки и заголовки расширения IPv6. Для измерения в обоих направлениях плоскость данных входного узла также должна передать отправителю заголовки ответного пакета.
  • Документ остаётся Internet-Draft, а не RFC или отчётом о внедрении. Сопоставление по длине и начальным байтам, как и флаг C при невозможности использовать TLV, по существу присутствовали в версии 13. Новым стало явное требование к обмену данными между внутренними функциями узла.

График может показывать успешный приём зондов и одновременно не объяснять, почему отражатель не вернул нужный заголовок. Причина иногда находится после сетевого интерфейса: пересылающая часть устройства видела пакет, но не передала его заголовок процессу STAMP. Это не то же самое, что потеря в сети. Редакция от 18 сентября переносит внимание с самого факта прибытия пакета на доступность полученных полей для измерения.

Её новый раздел 3.3 предписывает плоскости данных выходного узла, обработавшей тестовый пакет Session-Sender, предоставить локальному Session-Reflector полученные IP-заголовки и заголовки расширения IPv6. При двусторонней проверке есть и вторая граница: плоскость данных входного узла должна предоставить Session-Sender заголовки ответного пакета отражателя. Ответ может прийти, но без этой передачи измеритель не получает полного материала для оценки обратного направления. Это требование проекта к реализации, а не свидетельство дефекта конкретной сети.

Для выбора заголовка используется запрос в TLV. Если поле запроса ненулевое, должны совпасть длина и первые восемь октетов заголовка расширения IPv6 либо первые четыре октета фиксированного IP-заголовка. Нулевой запрос выбирает первый заголовок подходящей длины. При отсутствии совпадения TLV возвращается с флагом соответствия C=1. В версии 14 алгоритм изложен непосредственно в процедурных разделах. Однако версия 13 уже описывала эти случаи в определениях полей и называла недоступность заголовков из плоскости данных возможным источником неудачи. Представлять флаг C или сопоставление как совершенно новую функцию было бы неверно.

Отражённый TLV свидетельствует о выборе конкретного заголовка из тех, которые действительно попали к измерительной функции. Он не удостоверяет полный состав заголовков на всём пути и не гарантирует сохранность всех данных IOAM на промежуточных узлах. Флаг C без местных журналов не укажет однозначно на ошибку выбора, неудавшуюся внутреннюю передачу или иное ограничение. Ранее BTW разбирала неоднозначность этого флага для пределов MTU, скорости и объёма; нынешняя тема — новая обязанность передачи заголовков между компонентами.

Проект уточняет и расчёт MTU пути: учитывать нужно весь получившийся пакет, включая IP, UDP, STAMP и TLV. Предыдущая редакция уже защищала от превышения размера; расширено объяснение того, что входит в расчёт. В Datatracker проект отмечен активным, находится на стадии AD Evaluation и передан IESG. Окончательное утверждение, совместимость реализаций и распространённость в эксплуатации не доказаны.

Источники