Кратко
draft-ietf-mpls-stamp-pw-21прямо говорит: ограничение скорости на punt path в плоскость управления для STAMP неотличимо от реальной потери в сети и может учитываться как потеря пакетов.- Прежде чем тревога станет обвинением или командой сменить путь, надо связать сессию, инкапсуляцию, ограничители обоих концов, оба направления, MTU, ECMP, обратный контекст и независимые данные о сервисном трафике.
Один пропавший ответ, две разные истории
Цифра на панели выглядит окончательной: пять процентов тестовых циклов не завершились. Но она не указывает место исчезновения пакета.
STAMP отправляет тест от Session-Sender к Session-Reflector. В MPLS пакет следует по label stack, а на Provider Edge исключается из обычной пересылки и поступает в плоскость управления. Обработка расходует CPU и память, поэтому оба конца применяют rate limiting против перегрузки и отказа в обслуживании.
Если пакет отбросил транзитный узел, ответа нет. Если пакет дошёл до конца и его отбросил защитный policer, ответа тоже нет. Для отправителя обе причинные цепочки заканчиваются тишиной.
Revision 21 фиксирует границу честно: policing на punt path неотличим от настоящей сетевой потери и может быть показан как packet loss. Метрика доказывает незавершённый цикл измерения. Она ещё не доказывает отказ клиентского пути.
Документ одобрен, но ещё не опубликован как RFC
Текущая редакция датирована 10 сентября 2026 года. IESG одобрила её 14 сентября, а на следующий день документ перешёл в очередь RFC Editor. Редакторская работа и действия IANA продолжаются. После публикации документ должен получить статус Proposed Standard и обновить RFC 8762 и RFC 8972. Сейчас это Internet-Draft.
Область применения ограничена point-to-point LSP и point-to-point single-segment pseudowire в одном административном домене. Multipoint и multi-segment случаи исключены. Документ не подтверждает внедрение, инцидент или отказ у названного оператора.
История разработки показывает, почему формулировка важна. Во время IESG review было отмечено, что некоторые методы направляют каждый тестовый пакет в плоскость управления на обоих концах. Рецензент потребовал ясно сказать, что policing там будет выглядеть для STAMP как сетевая потеря. Revision 21 учла замечание. Процесс стандартизации не создал неоднозначность, а сделал её видимой.
Два формата оставляют разные координаты
RFC 8762 задаёт базовый STAMP, RFC 8972 — SSID и расширения. Format 1 использует IP/UDP. Format 2 работает без них и вводит разные G-ACh channel types для пакетов Sender и Reflector. Ненулевой SSID передаётся в обе стороны.
В Format 1 сессию можно связать с адресами, портом назначения и SSID. В Format 2 нужны SSID, принятый LSP/PW-контекст и локальные параметры. TLV, читающие или задающие IP/UDP-поля, там неприменимы.
Эта разница влияет на соответствие маршрута. IP-адреса зонда могут отличаться от адресов реального потока, и IP-based ECMP выберет другой путь. На совместимом оборудовании GAL не должен участвовать в ECMP, но несовместимое оборудование может изменить выбор. Одинаковый label stack — важное условие, а не универсальное доказательство одинакового прохождения.
Обратное направление — отдельная зона отказа
Получив тест через G-ACh, Reflector должен отправить ответ в обратном направлении bidirectional LSP или PW. Для поиска контекста он использует полученный PW label или ultimate LSP label. Если обратный контекст не найден, пакет следует отбросить без ответа.
Sender снова видит тишину. Причина может находиться на прямом пути, при punt processing, в Reflector, в поиске обратного контекста, на обратном пути или в последнем ограничителе.
Ёмкость также считается по направлениям. Reflector отвечает на каждый принятый тест, поэтому обратный поток может быть сопоставим с прямым, даже когда обратная полоса меньше. Одна round-trip метрика объединяет два направления и два защищённых процессора. Без направленного журнала ответственность легко назначить не той команде.
MTU может сломать только измерение
G-ACh, GAL, IP/UDP и padding увеличивают пакет. Он должен помещаться в MTU каждого направления. Слишком большой G-ACh тест не фрагментируется, а отбрасывается и выглядит как потеря. Это реальная потеря зонда, но не автоматическое доказательство проблем у меньших пользовательских пакетов.
Есть и обратная ошибка. При сломанном LSP Format 1 с маршрутизируемым адресом может дойти до Reflector по другому MPLS- или IP-пути и дать недействительный успешный результат. Немаршрутизируемые адреса и edge filtering снижают риск, но не превращают ответ в сертификат пути.
HMAC защищает целостность сообщения, а не правильность его интерпретации. Он не доказывает одинаковый ECMP и не объясняет отсутствие. Инъекция может исказить delay/loss, а подавление тестов — представить здоровый путь отказавшим.
Защиту надо включить в доказательную цепочку
Отключать limiter нельзя: это откроет плоскость управления для перегрузки. Вместо этого проект рекомендует знать момент ограничения и коррелировать его с failure notification — через UDP-порты Format 1 или LSP/PW-контекст и channel type Format 2. Входной policing не должен быть строже полосы, выделенной тестам.
Рекомендация RFC 5085 держать некоторые control messages ниже пяти процентов PW bit rate применяется и к STAMP. Это защита ресурса, а не гарантия измерения. Несколько сессий могут делить aggregate policer.
К тревоге следует приложить:
- версию спецификации, SSID и роли;
- LSP/PW-контекст и направление;
- формат, порты, channel type, CW, GAL/TTL, labels и размер;
- тестовую скорость и полосу в обоих направлениях;
- настройки, счётчики и время обоих punt-path limiter;
- отправленные, отражённые и принятые пакеты и T1–T4;
- результат обратного context lookup;
- проверку MTU и overhead;
- предположения ECMP и entropy label;
- независимые данные плоскости пересылки;
- правило тревоги, уверенность и открытые причины; и
- решение, повторный тест и доказательство восстановления.
Так мониторинг может сделать раннее, но точное заявление: на пути зонда наблюдалась потеря. Отказ сервиса, влияние на клиента и ответственность устанавливаются следующими доказательствами.
Источники
- Текущий проект MPLS STAMP
- История проекта и review
- Текст revision 21
- RFC 8762 — STAMP
- RFC 8972 — Расширения STAMP
- RFC 5085 — Pseudowire VCCV
- RFC 7708 — GAL как VCCV channel
- RFC 7325 — Требования MPLS forwarding
- RFC 6790 — Entropy Labels
- RFC 8085 — Рекомендации UDP
- Running-Code Primacy
- The Stability Fallacy
- On Authority, Belief, and the Internet’s Addressing System
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
