Кратко
- RFC 9801 предписывает заменять полезную нагрузку каждого потерянного или отброшенного PLE-пакета таким же объёмом данных. Все реализации обязаны поддерживать шаблон
0xAA. - Чередующиеся нули и единицы сохраняют синхронизацию и не создают недопустимых заголовков 64B/66B; holdover удерживает такт. Исходная информация при этом не восстанавливается.
- Надёжная запись разделяет принятый пакет, разрыв последовательности, перестановку, синтетический интервал, состояние часов, L/R, PLOS/DEG, счётчики PLE и наблюдаемый результат клиента.
На выходе может идти ровный сигнал, хотя внутри сети только что потеряна полезная нагрузка. Осциллограф покажет частоту. Декодер увидит допустимую структуру. Но байты на этом участке могли не пересечь сеть вовсе: их сформировал приёмный IWF.
Так устроена защита в RFC 9801, стандарте Private Line Emulation для переноса TDM, Ethernet PHY, Fibre Channel и OTN через пакетную сеть. Передающая сторона режет непрерывный поток на пакеты фиксированного размера. Приёмная должна снова выдать непрерывный поток. Если пакет исчез, физическое время не ждёт.
Стандарт требует заменить отсутствующую нагрузку равным объёмом данных. Содержимое настраивается, но 0xAA поддерживается обязательно. Чередование битов сохраняет синхронизацию и предотвращает недопустимые sync headers в 64B/66B. Это технически корректная заглушка, а не восстановление прошлого.
Шов между пакетной и синхронной реальностью
Архитектура опирается на pseudowire из RFC 3985. Входной IWF добавляет control word, RTP-время, идентификатор VPWS и заголовки PSN. Выходной снимает их и передаёт битовый поток локальному CE.
Тип сервиса, тип и размер payload должны совпадать на обеих сторонах. Размер фиксирован на весь срок VPWS; поддержка 1 024 байт обязательна. Control word следует RFC 4385, а sequence number растёт с каждым пакетом. Разрыв доказывает отсутствие ожидаемой позиции к моменту решения, но не называет причину.
RTP-заголовок использует временные правила RFC 3550, не предоставляя RTCP, SRTP и всю мультимедийную архитектуру. До 200 Гбит/с timestamp работает на 125 МГц, выше — на 250 МГц. Относительная модель RFC 4197 передаёт разницу между входными часами и общей опорой.
Timestamp помогает определить момент выдачи. Он не содержит потерянные данные.
Размер буфера — это решение о сроке ожидания
Приёмник обязан иметь de-jitter buffer. Опоздавший пакет можно вернуть на место, если поддерживается reordering; иначе его надо отбросить. Корректная нагрузка, пришедшая после срока, для синхронного выхода становится такой же недоступной, как не пришедшая.
Типичная начальная отметка — половина буфера. Она оставляет место для увеличения и уменьшения задержки. Большой буфер терпит больше PDV, но добавляет latency. Малый ускоряет выдачу, но чаще превращает опоздание в потерю и синтетическое заполнение.
Нужно сохранять несколько самостоятельных свидетельств:
| Запись | Узкое утверждение |
|---|---|
| пакет и sequence number | эта нагрузка дошла до IWF |
| разрыв | ожидаемая позиция не была доступна вовремя |
| перестановка или отбрасывание | локальная политика обработала опоздание |
| интервал заполнения | на выход пошли локально созданные байты |
| holdover и recovered clock | ритм удерживался в заданном измерении |
| maintenance signal | нативному сервису показано ограниченное состояние |
| клиентское измерение | конкретное приложение увидело результат |
Пакетная трасса с потерей и непрерывный физический сигнал совместимы. IWF и существует для соединения этих картин. Недостоверным становится лишь вывод, что ровный выход подтверждает исходные данные.
Биты L и R говорят от разных сторон
L устанавливает передающий PE, когда payload недействителен из-за неисправности локальной attachment circuit. Дальний край обязан подставить подходящие данные и может ввести нативный downstream fault signal. R сообщает обратно, что принимающий IWF видит потери в PSN или обратную неисправность серверного слоя.
Флаги сохраняют направление и источник наблюдения. Они не возвращают payload, не доказывают реакцию CE и не устанавливают корень события.
Последовательные потери в течение настраиваемого времени приводят к PLOS; значение по умолчанию — одна миллисекунда. Превышение порога в последовательных секундных окнах приводит к DEG; описаны 15% в семи интервалах. Первый пропуск, порог, объявление состояния и нативная сигнализация имеют разные времена.
ES-PLE считает секунду с хотя бы одной потерей, PLOS или DEG. SES-PLE считает более 15% потерь, PLOS или DEG. UAS-PLE начинается и заканчивается после серий, по умолчанию десять секунд. Это измерения слоя PLE. Контроль attachment circuit зависит от технологии и остаётся вне RFC. Один SES-PLE не сообщает число потерянных Ethernet-кадров, Fibre Channel операций или OTN-блоков.
Гладкий выход не создаёт пропускную способность
RFC 4553, RFC 5086 и RFC 4842 показывают происхождение схем с sequence, timing и replacement data. RFC 9801 расширяет их на большее число сигналов и скоростей.
PLE — неэластичный поток постоянной скорости. Он не может TCP-дружественно отступить при перегрузке, как обсуждает RFC 2914. PSN должен обеспечивать низкие jitter и loss через QoS, traffic engineering, admission control или запас ёмкости. Конкретный способ не задан. Непрерывный выход не доказывает резервирование; возможно, край лишь кратко скрыл нехватку.
PLE также не добавляет шифрование, целостность или аутентификацию. Предполагается доверенный изолированный MPLS/SRv6-домен с мерами RFC 5920. Инъекция, задержка, перестановка и потеря могут превысить буфер, что укладывается в угрозы RFC 9055. Для PTP остаются атаки на задержку и время из RFC 7384. Стабильные часы не аутентифицируют данные.
Карточка RFC Editor, errata и история IETF подтверждают статус текста. Реестр IANA PWE3 подтверждает назначения. RFC 8214 описывает EVPN-VPWS, а расширения сигнализации PLE в RFC 9801 вынесены за границы. Это не свидетельства работы конкретной линии.
Текстовая и XML формы позволяют проверить норму. Только эксплуатационная запись показывает, когда устройство действительно создавало заполнение.
Непрерывность — действие защиты. Точность — доказуемое свойство. Если защита делает потерю незаметной на выходе, происхождение интервала надо отмечать ещё точнее.
Источники
- https://www.rfc-editor.org/rfc/rfc9801.html
- https://www.rfc-editor.org/rfc/rfc9801.txt
- https://www.rfc-editor.org/rfc/rfc9801.xml
- https://www.rfc-editor.org/info/rfc9801/
- https://www.rfc-editor.org/errata/rfc9801
- https://datatracker.ietf.org/doc/rfc9801/history/
- https://www.rfc-editor.org/rfc/rfc3985.html
- https://www.rfc-editor.org/rfc/rfc4385.html
- https://www.rfc-editor.org/rfc/rfc3550.html
- https://www.rfc-editor.org/rfc/rfc4197.html
- https://www.rfc-editor.org/rfc/rfc4553.html
- https://www.rfc-editor.org/rfc/rfc5086.html
- https://www.rfc-editor.org/rfc/rfc4842.html
- https://www.rfc-editor.org/rfc/rfc2914.html
- https://www.rfc-editor.org/rfc/rfc9055.html
- https://www.rfc-editor.org/rfc/rfc5920.html
- https://www.rfc-editor.org/rfc/rfc7384.html
- https://www.rfc-editor.org/rfc/rfc8214.html
- https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
