Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Request for Comments: 9503 C. Filsfils
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 M. Chen
Huawei
B. Janssens
Colt
R. Foote
Nokia
October 2023
Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks
Расширения протокола STAMP для сетей с маршрутизацией по сегментам
Аннотация
Маршрутизация по сегментам (Segment Routing или SR) использует парадигму маршрутизации от источника (source routing). SR подходит к плоскостям пересылки как с многопротокольной коммутацией по меткам (SR-MPLS) так и IPv6 (SRv6). Этот документ задаёт расширения простого протокола двухсторонних активных измерений (Simple Two-Way Active Measurement Protocol или STAMP), описанного в RFC 8762, в сетях SR с плоскостями пересылки SR-MPLS и SRv6, дополняя расширения, определённые в RFC 8972.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9503.
Авторские права
Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).
1. Введение
Маршрутизация по сегментам (SR) использует парадигму маршрутизации от источника для программно-определяемых сетей (Software-Defined Network или SDN). SR подходит для плоскостей пересылки MPLS (SR-MPLS) и IPv6 (SRv6) [RFC8402]. Правила SR Policy, как определено в [RFC9256], применяются для направления трафика по конкретным, заданным пользователем путям, с использованием стека сегментов. Наличие полнофункционального набора инструментов измерения производительности (Performance Measurement или PM) SR является одним важных требований для измерения производительности сети при заключении соглашений об уровне обслуживания (Service Level Agreement или SLA).
Простой протокол двухсторонних активных измерений (Simple Two-Way Active Measurement Protocol или STAMP) обеспечивает возможности измерения различных показателей производительности в сетях IP [RFC8762] без применения канала управления для предварительной передачи параметров сессии. В [RFC8972] для STAMP определены необязательные расширения в форме TLV. Можно использовать модель данных YANG из [IPPM-STAMP-YANG] для режимов STAMP Session-Sender и STAMP Session-Reflector.
Тестовые пакеты STAMP передаются по пути IP между Session-Sender и Session-Reflector для измерения задержки и потерь пакетов на пути. В сетях SR может быть желательно обеспечить один путь (набор каналов и узлов) между Session-Sender и Session-Reflector пакетов STAMP в обоих направлениях. Это достигается с помощью расширений STAMP [RFC8762] для сетей SR-MPLS и SRv6, как указано в этом документе, с добавлением расширений из [RFC8972].
2. Используемые соглашения
2.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2.2. Сокращения
MPLS
Multiprotocol Label Switching – многопротокольная коммутация по меткам.SID
Segment Identifier – идентификатор сегмента.SR
Segment Routing – маршрутизация по сегментам.SR-MPLS
Segment Routing over MPLS – SR через MPLS.SRv6
Segment Routing over IPv6 – SR через IPv6.SSID
STAMP Session Identifier – идентификатор сессии STAMP.STAMP
Simple Two-Way Active Measurement Protocol – простой протокол двухсторонних активных измерений.2.3. Эталонная топология
В показанной ниже эталонной топологии STAMP Session-Sender S1 передаёт тестовый пакет STAMP, а STAMP Session-Reflector R1 возвращает отклик на него. Пакет с откликом может передаваться Session-Sender S1 по тому же или иному пути (набору каналов и узлов), нежели для пакетов в направлении Session-Reflector R1.
S1 добавляет метку передачи T1 и метку приёма T4, R1 – метку приёма T2 и метку передачи T3. Узлы S1 и R1 могут соединены по каналу или пути SR [RFC8402]. Канал может быть физическим или виртуальным, а группой агрегирования каналов (Link Aggregation Group или LAG) [IEEE802.1AX] или членом такой группы. Путь SR может представлять собой SR Policy [RFC9256] на узле S1 (head-end) с узлом R1 (tail-end) в качестве адресата.
T1 T2
/ \
+-------+ Тестовый пакет +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| |<- - - - - - - - - - | |
+-------+ Тестовый отклик +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Рисунок . Эталонная топология.
3. Destination Node Address TLV
Узлу Session-Sender может потребоваться передача пакетов для Session-Reflector с немаршрутизируемым (т. е. не подходящим в качестве Source Address в пакетах отклика) адресом получателя (Destination Address). Это можно сделать, например, путём инкапсуляции пакетов STAMP в туннельный протокол, как описано в Приложении A.
В [RFC8972] определены тестовые пакеты STAMP Session-Sender и Session-Reflector, которые могут включать необязательные TLV. В этом документе определяется TLV Type (значение 9 для IPv4 и IPv6) для Destination Node Address TLV в пестовых пакетах STAMP [RFC8972]. Формат Destination Node Address TLV показан на рисунке 2.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=9 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=9 | Length=16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат Destination Node Address TLV.
STAMP TLV Flags
Type
Тип (9) для IPv4 Destination Node Address TLV или IPv6 Destination Node Address TLV.Length
2-октетное значение размера поля Address в октетах (4 для IPv4 и 16 для IPv6).Destination Node Address TLV указывает адрес Session-Reflector для тестового пакета. Если полученный Destination Node Address является одним из адресов Session-Reflector, его следует указывать как Source Address в заголовке IP тестового пакета-отклика. При передаче Destination Node Address TLV должно указываться значение SSID.
Узел Session-Reflector, распознавший этот TLV, должен установить для флага U [RFC8972] в отклике на тестовый пакет значение 1, если он определил, что не является получателем, указанным в Destination Node Address TLV. В этом случае Session-Reflector не использует полученный Destination Node Address в поле Source Address заголовка IP в пакета отклика. В иных случаях Session-Reflector должен установить для флага U в Destination Node Address TLV пакета-отклика значение 0.
4. Return Path TLV
Для сквозных путей SR узлу Session-Reflector может потребоваться передача откликов в конкретный путь (Return Path). Session-Sender может указать это в тестовых пакетах для Session-Reflector с помощью Return Path TLV. Этот TLV в тестовом пакете от Session-Sender, позволяя не указывать и не поддерживать динамическое состояние сети SR для сессий STAMP на Session-Reflector.
В разделе 4 [RFC8762] заданы два режима поведения Session-Reflector – Stateless (без состояния) и Stateful (с поддержкой состояния). Для режима Stateful на Session-Reflector требуется конфигурация, соответствующая параметрам Session-Sender, включая Source Address, Destination Address, Source UDP Port, Destination UDP Port и, возможно, SSID (если SSID настраивается, а не создаётся автоматически). В этом случае для направления тестовых пакетов можно использовать локальные правила, создающие дополнительные состояния для сессий STAMP на Session-Reflector. При работе в неразборчивом (promiscuous) режиме Stateless Session-Reflector потребуется указать, как возвратить тестовые отклики по конкретному пути, например, для измерений в среде ECMP.
Для каналов узлу Session-Reflector может потребоваться передавать тестовые отклики по тому же (входному) каналу в обратном направлении. Session-Sender может запросить это в тестовых пакетах для Session-Reflector с помощью Return Path TLV.
В [RFC8972] определены тестовые пакеты STAMP с необязательными TLV. Этот документ определяет TLV Type (10) для Return Path TLV, указывающем Return Path для тестового пакета от Session-Sender. Формат Return Path TLV показан на рисунке 3.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=10 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Path Sub-TLVs | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат Return Path TLV.
STAMP TLV Flags
Type
Тип (10) для Return Path TLV.Length
2-октетное значение размера поля Return Path Sub-TLVs в октетах.Return Path Sub-TLVs
В соответствии с параграфом 4.1.Узлу Session-Sender недопустимо помещать более одного Return Path TLV в тестовый пакет STAMP. Узел Session-Reflector, поддерживающий такие TLV, должен обрабатывать лишь первый Return Path TLV в тестовом пакете, игнорируя другие при их наличии. Поддерживающий такие TLV узел Session-Reflector должен отвечать с использованием Return Path из полученного от Session-Sender тестового пакета, если при обработке TLV не возникло ошибок.
Узел Session-Reflector, поддерживающий этот TLV, должен установить для флага U [RFC8972] в тестовом отклике значение 1, если он определил, что не может использовать Return Path в тестовом отклике. В иных случаях Session-Reflector должен устанавливать для флага U в отклике значение 0.
4.1. Return Path Sub-TLV
Return Path TLV содержит 1 или несколько Sub-TLV для передачи сведений о запрошенном пути возврата (Return Path). Return Path Sub-TLV может передавать Return Path Control Code, Return Path IP Address или Return Path Segment List.
Флаги STAMP Sub-TLV устанавливаются по процедурам, описанным в [RFC8972].
В Return Path TLV тестового пакета Session-Sender недопустимо включать более одного Control Code Sub-TLV, Return Address Sub-TLV или Return Path Segment List Sub-TLV. В Return Path TLV тестового пакета Session-Sender недопустимо включать сразу Control Code Sub-TLV и Return Address или Return Path Segment List Sub-TLV тестового пакета Session-Sender. В Return Path TLV тестового пакета Session-Sender можно включать сразу Return Address и Return Path Segment List Sub-TLV.
4.1.1. Return Path Control Code Sub-TLV
Формат Control Code Sub-TLV в Return Path TLV показан на рисунке 4.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=1 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Code Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат Control Code Sub-TLV в Return Path TLV.
Type
STAMP TLV Flags
Флаги в соответствии с процедурами [RFC8972] и этого документа.Length
2-октетное значение размера флагов Control Code в октетах (4).Control Code Flags (32 bits)
Бит 31 (младший) в Reply Request Flag: 0x0 – отклик не запрошен; 0x1 – запршен отклик по тому же каналу.Остальные биты являются резервными и должны сбрасываться (0) при передаче и игнорироваться при получении.
Если флаг Control Code для Reply Request в тестовом пакете от Session-Sender имеет значение 0x0, Session-Reflector не передаёт отклика на тестовый пакет узлу Session-Sender и завершает обработку тестового пакета STAMP. В этом случае провидится лишь одностороннее измерение. Session-Reflector может локально передавать показатели производительности через телеметрию, используя сведения из полученного тестового пакета. В этом случае все остальные Return Path Sub-TLV должны игнорироваться.
Если флаг Control Code для Reply Request в тестовом пакете от Session-Sender имеет значение 0x1, Session-Reflector передаёт отклик на тест в тот же канал, где был принят тестовый пакет, в обратном направлении для Session-Sender. Канал может быть физическим интерфейсом, виртуальным каналом, LAG [IEEE802.1AX] или членом LAG. Все прочие Return Path Sub-TLV в этом случае должны игнорироваться. При использовании членов LAG для указания канала можно применять расширение STAMP для Micro-Session ID TLV, заданное в [STAMP-ON-LAG].
4.1.2. Return Address Sub-TLV
Тестовые отклики STAMP могут передаваться узлу Session-Sender по адресу Return Address в Return Address Sub-TLV всесто Source Address в тестовом пакете от Session-Sender.
Формат Return Address Sub-TLV в Return Path TLV для IPv4 и IPv6 показан на рисунке 5.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=2 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=2 | Length=16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Return IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат Return Address Sub-TLV в Return Path TLV.
Type
STAMP TLV Flags
Флаги в соответствии с процедурами [RFC8972] и этого документа.Length
2-октетное значение размера поля Return Address в октетах (4 для IPv4, 16 для IPv6).4.1.3. Return Path Segment List Sub-TLV
Формат Segment List Sub-TLV в Return Path TLV показан на рисунках 6 и 7. Поля Segment из Segment List Sub-TLV описаны в [RFC8402]. Сегменты должны указываться с использованием сетевого порядка байтов.
Session-Sender должен включать в тестовый пакет лишь один Return Path Segment List Sub-TLV, а в Segment List должен указываться хотя бы один Segment. Session-Reflector должен обрабатывать лишь первый Return Path Segment List Sub-TLV в тестовом пакете, игнорируя прочие Return Path Segment List Sub-TLV, если они меются.
Return Path Segment List Sub-TLV может иметь один из двух типов:
Type (3)
SR-MPLS Label Stack из Return Path;Type (4)
SRv6 Segment List из Return Path.STAMP TLV Flags
Флаги в соответствии с процедурами [RFC8972] и этого документа.Length
2-октетное значение размера поля Segment List в октетах (значение 0 недопустимо).4.1.3.1. Return Path SR-MPLS Label Stack Sub-TLV
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(1) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(n) (дно стека) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат SR-MPLS Label Stack Sub-TLV в Return Path TLV.
SR-MPLS Label Stack содержит список 32-битовых элементов стека (Label Stack Entry или LSE) из 20-битового значения метки, 8-битового поля Time-To-Live (TTL), 3-битового класса трафика (Traffic Class или TC) и 1-битового поля завершения стека (End-of-Stack или S). Размер Sub-TLV должен быть кратным 4. Например, SR-MPLS Label Stack Sub-TLV может передавать лишь одну метку Binding SID Label [PCE-BINDING-LABEL-SID] из Return SR-MPLS Policy. Метка Binding SID Label в Return SR-MPLS Policy является локальной для Session-Reflector. Механизм сигнализации Binding SID Label узлу Session-Sender выходит за рамки этого документа. В качестве другого примера SR-MPLS Label Stack Sub-TLV может включать Path Segment Identifier Label из Return SR-MPLS Policy в Segment List из SR-MPLS Policy.
4.1.3.2. Return Path SRv6 Segment List Sub-TLV
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment(1) (128 битов IPv6 Address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment(n) (128 битов IPv6 Address) (дно стека) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат SRv6 Segment List Sub-TLV в Return Path TLV.
SRv6 Segment List содержит список 128-битовых адресов IPv6, представляющих SRv6 SID. Размер Sub-TLV должен быть кратным 16. Например, Return Path SRv6 Segment List Sub-TLV может содержать лишь один SRv6 Binding SID [PCE-BINDING-LABEL-SID] из Return SRv6 Policy. SRv6 Binding SID из Return SRv6 Policy является локальным для Session-Reflector. Механизм сигнализации SRv6 Binding SID узлу Session-Sender выходит за рамки этого документа. В качестве другого примера Return Path SRv6 Segment List Sub-TLV может включать SRv6 Path Segment Identifier из Return SRv6 Policy в Segment List из SRv6 Policy.
5. Совместимость с TWAMP Light
Этот документ не включает дополнительных соображений о функциональной совместимости с протоколом TWAMP Light в дополнение к описанным в параграфе 4.6 [RFC8762], где рассмотрены два варианта взаимодействия:
-
STAMP Session-Sender с TWAMP Light Session-Reflector;
-
TWAMP Light Session-Sender с STAMP Session-Reflector.
Если любое из заданных здесь расширений STAMP применяется узлом STAMP Session-Sender, TWAMP Light Session-Reflector будет видеть его как поле Packet Padding.
6. Вопросы безопасности
Вопросы безопасности, рассмотренные в [RFC8762] и [RFC8972], применимы и к заданным здесь расширениям. В частности, режим аутентификации и защита целостности с использованием хэшированного кода аутентификации сообщений (Hashed Message Authentication Code или HMAC), указанные в параграфе 4.4 [RFC8762], применимы и к описанным здесь процедурам.
STAMP использует общеизвестный номер порта UDP, который может стать целью атаки с отказом в обслуживании (denial of service или DoS) или атаки в пути. Таким образом, соображения безопасности и методы снижения риска, указанные в разделе 6 [RFC8545], применимы и к расширениям STAMP, описанным в этом документе.
При желании атаки можно смягчить с помощью базовых проверок корректности полей временных меток (T2 позднее T1 в эталонной топологии из параграфа 2.3) в принятом Session-Sender отклике на тестовый пакет. packets at the. The minimal state associated with these protocols also limit the extent of measurement disruption that can be caused by a corrupt or invalid test packet to a single test cycle.
Заданные здесь расширения STAMP предназначены для внедрения в средах с единым административным доменом. В этом случае оператор предоставляет адреса Session-Sender и Session-Reflector, а также Return Path для сессии STAMP. Предполагается, что оператор целостность Return Path и подлинность Session-Reflector на другой стороне.
Заданные здесь расширения STAMP могут использоваться для подмены адресов. Например, Session-Sender может указать IP-адрес Return Path, отличающийся от адреса Session-Sender. Session-Reflector может отбрасывать тестовые пакеты Session-Sender, когда он не может определить, является ли Return Path IP Address локальным для Session-Sender. Чтобы помочь Session-Reflector в этом определении оператор может указывать также Return Path IP Address, например в списке управления доступом.
7. Взаимодействие с IANA
Агентство IANA выделило значения для Destination Address TLV Type и Return Path TLV Type из диапазона IETF Review TLV в реестре STAMP TLV Types [RFC8972], как указано в таблице 1.
Таблица . Типы STAMP TLV.
|
Значение |
Описание |
Документ |
|---|---|---|
|
9 |
Destination Node Address (IPv4 или IPv6) |
RFC 9503 |
|
10 |
Return Path |
RFC 9503 |
Агентство IANA создало реестр Return Path Sub-TLV Types. Коды из диапазона 1 – 175 нужно выделять по процедуре IETF Review, описанной в [RFC8126]. Коды 176 – 239 выделяются по процедуре First Come First Served из [RFC8126]. Остальные значения распределены в соответствии с таблицей 2.
Таблица . Реестр типов Return Path Sub-TLV.
|
Диапазон |
Процедура регистрации |
|---|---|
|
1-175 |
IETF Review |
|
176-239 |
First Come First Served |
|
240-251 |
Experimental Use |
|
252-254 |
Private Use |
Агентство IANA выделило указанные ниже значения типов Sub-TLV в реестре Return Path Sub-TLV Types.
Таблица . Типы Return Path Sub-TLV.
|
Значение |
Описание |
Документ |
|---|---|---|
|
0 |
Резерв |
RFC 9503 |
|
1 |
Return Path Control Code |
RFC 9503 |
|
2 |
Return IPv4 or IPv6 Address |
RFC 9503 |
|
3 |
SR-MPLS Label Stack of the Return Path |
RFC 9503 |
|
4 |
SRv6 Segment List of the Return Path |
RFC 9503 |
|
255 |
Резерв |
RFC 9503 |
Агентство IANA создало реестр Return Path Control Code Flags для Return Path Control Code Sub-TLV. Все коды в позициях 31 (младший бит) – 12 этого реестра выделяются по процедуре IETF Review, как указано в [RFC8126]. Коды в позициях 11 – 8 нужно выделять по процедуре First Come First Served из [RFC8126]. Остальные коды распредеелны в соответствии с таблицей 4.
Таблица . Return Path Control Code.
|
Диапазон |
Процедура регистрации |
|---|---|
|
31-12 |
IETF Review |
|
11-8 |
First Come First Served |
|
7-4 |
Experimental Use |
|
3-0 |
Private Use |
Агентство IANA выделило указанное в таблице 5 значение в реестре Return Path Control Code Flags.
Таблица . флагReturn Path Control Code.
|
Значение |
Описание |
Документ |
|---|---|---|
|
31 |
Reply Request |
RFC 9503 |
8. Литература
8.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, “Simple Two-Way Active Measurement Protocol”, RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, “Simple Two-Way Active Measurement Protocol Optional Extensions”, RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.
8.2. Дополнительная литература
[IEEE802.1AX] IEEE, “IEEE Standard for Local and metropolitan area networks — Link Aggregation”, IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014, <https://doi.org/10.1109/IEEESTD.2014.7055197>.
[IPPM-STAMP-YANG] Mirsky, G., Min, X., and W. S. Luo, “Simple Two-way Active Measurement Protocol (STAMP) Data Model”, Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-11, 13 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-11>.
[PCE-BINDING-LABEL-SID] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. Li, Ed., “Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.”, Work in Progress, Internet-Draft, draft-ietf-pce-binding-label-sid-16, 27 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-16>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing Architecture”, RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., “Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)”, RFC 8545, DOI 10.17487/RFC8545, March 2019, <https://www.rfc-editor.org/info/rfc8545>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, “Segment Routing Policy Architecture”, RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.
[STAMP-ON-LAG] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi, “Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG”, Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-on-lag-05, 17 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-on-lag-05>.
Приложение A. Пример использования Destination Node Address TLV
Тестовые пакеты STAMP могут инкапсулироваться с 1) SR-MPLS Label Stack и заголовком IPv4, содержащий адрес IPv4 Destination Address из сети 127.0.0/8 или 2) внешним заголовком IPv6, заголовком маршрутизации по сегментам (Segment Routing Header или SRH) и внутренним заголовком IPv6 с IPv6 Destination Address из диапазона ::1/128.
В среде ECMP хэш-функция пересылки может определять путь пересылки с использованием Source Address, Destination Address, портов UDP, метки ротока IPv6 и других полей пакета. Поэтому в IPv4, например, могут применяться разные значения IPv4 Destination Address из сети 127.0.0.0/8 в заголовке IPv4 тестовых пакетов STAMP для оценки разных путей ECMP. В IPv6 для этого могут служить, например, разные значения метки потоков в заголовке IPv6 тестовых пакетов STAMP. В этих случаях тестовые пакеты STAMP могут прийти на узел, не являющийся Session-Reflector для этой сессии STAMP, в ошибочных условиях и такой непредусмотренный узел может передать тестовый отклик с недействительными результатми измерения. Для обнаружения таких ошибок предусмотренный адрес Session-Reflector может передаваться в Destination Node Address TLV.
Благодарности
Авторы благодарны Thierry Couture за обсуждение использования измерений производительности при маршрутизации по сегментам. Спасибо также Greg Mirsky, Mike Koldychev, Gyan Mishra, Tianran Zhou, Al Morton, Reshad Rahman, Zhenqiang Li, Frank Brockners, Henrik Nydell, Cheng Li за комментарии и предложения. Спасибо Joel Halpern за рецензию Gen-ART, Martin Duke за рецензию AD и Kathleen Moriarty за рецензию по безопасности. Авторы признательны Robert Wilton, Éric Vyncke, Paul Wouters, John Scudder, Roman Danyliw, Lars Eggert, Erik Kline, Warren Kumari и Jim Guichard за рецензию IESG.
Участник работы
Ниже указан человек, внёсший существенный вклад в этот документ.
Daniel Voyer Bell Canada Email: daniel.voyer@bell.caАдреса авторов
Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Bart Janssens Colt Email: Bart.Janssens@colt.net Richard Foote Nokia Email: footer.foote@nokia.comПеревод на русский язык
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.