Internet Engineering Task Force (IETF) Z. Li
Request for Comments: 9534 China Mobile
Category: Standards Track T. Zhou
ISSN: 2070-1721 Huawei
J. Guo
ZTE Corp.
G. Mirsky
Ericsson
R. Gandhi
Cisco Systems, Inc.
January 2024
Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group
Расширение протокола STAMP для измерения производительности LAG
Аннотация
Этот документ расширяет простой протокол двухсторонних активных измерений (Simple Two-way Active Measurement Protocol или STAMP) измерений для оценки производительности каждого члена группы агрегирования каналов (Link Aggregation Group или LAG). Знание показателей каждого канала в LAG позволяет операторам внедрять на каждом канале основанные на производительности правила распределения трафика.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9534.
Авторские права
Copyright (c) 2024. Авторские права принадлежат 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. Введение
Группы агрегирования каналов (LAG), как указано в [IEEE802.1AX], обеспечивают механизмы объединения нескольких физических каналов в один логический. Этот логический канал обеспечивает большую пропускную способность и повышает отказоустойчивость, поскольку при отказе одного из физических каналов агрегированный логический канал может продолжать пересылку трафика через оставшиеся в группе физические каналы.
Обычно при пересылке трафика через LAG применяется основанный на хэшировании механизм распределения трафика между членами LAG. Задержка в в разных каналах группы может различаться из-за разных транспортных путей, особенно при использовании LAG в распределенной сети. Для обеспечения малой задержки чувствительного ко времени трафика требуется явно распределять трафик по каналам LAG с учётом задержки, потерь и т. п. Для этого требуется решение, позволяющее измерить показатели производительности на каждом канале LAG. Измеренные значения показателей могут применяться вместе с анонсами атрибутов L2 членов группы [RFC8668] для распределения трафика.
В соответствии с классификацией [RFC7799], (STAMP) [RFC8762] является активным методом измерения и может дополнять пассивные и гибридные методы. Протокол обеспечивает механизм измерения в одном направлении или по кругу (round-trip) таких показателей как задержка и её вариации, потеря пакетов. Тестовую сессию STAMP через LAG для измерения производительности конкретного канала группы с использованием специально созданного квинтета (5-tuple). Сессию можно организовать для измерения средних значения части или всех каналов LAG, меняя один или несколько элементов квинтета. Однако без знания каждого члена группы тестовая сессия STAMP не может применяться для измерения производительности каждого физического канала в группе.
Этот документ расширяет протокол STAMP для измерения производительности каждого канала группы LAG. Расширение может обеспечивать такие же показатели, как OWAMP [RFC4656] и TWAMP [RFC5357] (задержка и её вариации, потери пакетов.
1.1. Уровни требований
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2. Микросессии в LAG
В этом документе рассматривается вариант, где LAG напрямую соединяет два узла. Пример на рисунке 1 показывает LAG из 4 каналов, соединяющих узлы A и B. Задача состоит в измерении производительности каждого канала в LAG.
+---+ +---+ | |-----------------------| | | A |-----------------------| B | | |-----------------------| | | |-----------------------| | +---+ +---+
Рисунок . Измерение производительности в LAG.
Для измерения показателей производительности каждого канала в LAG требуется организовать несколько сессий (по одной для каждого канала) между парой конечных точек, соединённых через LAG. Эти сессии далее в документе называются микросессиями. Хотя фактически микросессии являются сессиями STAMP на каналах группы LAG, тестовые пакеты микросессий должны содержать сведения о конкретном канале для проверки.
Для всех микросессий LAG используются общие значения Sender IP Address и Receiver IP Address. В качестве номера порта UDP все микросессии могут использовать общие значения Sender Port и Receiver Port или для каждой из микросессий может быть задана своя пара номеров Sender Port и Receiver Port. Первый вариант проще в использовании, поэтому рекомендуется применять его.
Тестовые пакеты в микросессиях должны содержать сведения о канале для проверки действительности. Например, при получении тестового пакета микросессии STAMP Session-Sender проверяет, относится ли этот пакет к ожидаемому каналу группы. Сведения о канале группы кодируются в Micro-session ID TLV (см. раздел 3, где представлено также подробное описание проверки канала.
STAMP Session-Sender в микросессии может включать Follow-Up Telemetry TLV [RFC8972] для запроса сведений у Session-Reflector микросессии. Эта временная метка может быть важна для Session-Sender в микросессии, поскольку она повышает точность сетевых измерений за счёт минимизации влияния задержки на измерения.
3. Проверка каналов группы
Тестовые пакеты должны передавать сведения о члене группы в Micro-session ID TLV, заданном в этом параграфе, для проверки канала. Session-Sender микросессии проверяет, получен ли тестовый пакет из ожидаемого канала группы, а также проверяет, отправлен ли пакет ожидаемым каналом-членом на стороне Reflector. Session-Reflector микросессии проверяет, был ли пакет передан ожидаемым членом группы.
3.1. Micro-session ID TLV
Механизм STAMP TLV [RFC8972] расширяет тестовые пакеты STAMP добавлением одного или нескольких необязательных TLV. Этот документ задаёт TLV Type (11) для Micro-session ID TLV, передающих идентификатор канала-члена для STAMP Session-Sender в поле Sender Micro-session ID и для Session-Reflector – в поле Reflector Micro-session ID. Формат Micro-session ID 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 = 11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Micro-session ID | Reflector Micro-session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Micro-session ID TLV.
Type (1 октет)
Length (2 октета)
Размер поля Value в октетах. Поле должно иметь значение 4.Sender Micro-session ID (2 октета)
Указывает идентификатор канала группы LAG на стороне отправителя (Sender). В будущем поле может использоваться не только с LAG. Значение поля должно быть уникальным в сессии STAMP у Session-Sender.Reflector Micro-session ID (2 октета)
Указывает идентификатор канала группы LAG на стороне рефлектора (Reflector). В будущем поле может использоваться не только с LAG. Значение поля должно быть уникальным в сессии STAMP у Session-Reflector.3.2. Процедуры Micro STAMP-Test
Для Micro STAMP-Test используются процедуры из раздела 4 STAMP [RFC8762] с указанными ниже дополнениями.
STAMP Session-Sender микросессии должен передавать пакеты Micro STAMP-Test через канал группы, с которым связана сессия. Сопоставление микросессий STAMP м идентификаторами каналов Sender/Reflector может быть задано путём добавления STAMP YANG [STAMP-YANG], детали добавления выходят за рамки этого документа.
При передаче тестовых пакетов STAMP Session-Sender микросессии должен указывать в поле Sender Micro-session ID идентификатор канала, связанного с микросессией STAMP. Если Session-Sender знает идентификатор канала для рефлектора, должно устанавливаться поле Reflector Micro-session ID. В иных случаях должно указываться Reflector Micro-session ID = 0. Идентификатор канала для рефлектора можно узнать из конфигурации или определить из плоскости данных (например, из отражённого тестового пакета). Этот документ не задаёт способ получения идентификатора канала для Reflector.
При получении STAMP Session-Reflector тестового пакета с отличным от 0 полем Reflector Micro-session ID, рефлектор микросессии должен использовать идентификатор канала Reflector для проверки принадлежности к микросессии STAMP. При несовпадении идентификаторов тестовый пакет должен отбрасываться. Если Reflector Micro-session ID = 0, проверка не выполняется. Если все проверки успешны, Session-Reflector передаёт отражённый тестовый пакет для Session-Sender. STAMP Session-Reflector микросессии должен указывать идентификаторы канала для Sender и Reflector, связанные с микросессией STAMP, в поля Sender Micro-session ID и Reflector Micro-session ID, соответственно. Идентификатор канала для Sender копируется из полученного тестового пакета.
При получении отражённого тестового пакета Session-Sender микросессии должен использовать Sender Micro-session ID для проверки получения тестового пакета из ожидаемого канала. При несовпадении идентификаторов тестовый пакет должен отбрасываться. Session-Sender микросессии должен использовать значение Reflector Micro-session ID для проверки корректности поведения рефлектора и при несовпадении значений тестовый пакет должен отбрасываться.
Два режима работы STAMP Session-Reflector (stateless и stateful) характеризуют ожидаемое поведение, как описано в разделе 4 STAMP [RFC8762]. Для STAMP-Test в микросессиях также поддерживаются режимы с учётом и без учёта состояния, однако Micro STAMP-Test не создаёт дополнительного состояния STAMP, т. е. все процедуры, относящиеся к Micro-session ID не учитывают состояния.
4. Применимость
STAMP Session-Sender микросессии передаёт пакеты Micro Session-Sender с Micro-session ID TLV. Session-Reflector микросессии проверяет, получен ли тестовый пакет из канала, связанного с микросессией STAMP, если поле Reflector Micro-session ID установлено. При отражении тестового пакета STAMP Session-Reflector микросессии копирует Sender Micro-session ID из полученного пакета от Session-Sender микросессии в свой пакет Session-Reflector и устанавливает в поле Reflector Micro-session ID идентификатор канала, связанного с микросессией STAMP. Session-Sender микросессии при получении пакета Micro Session-Reflector проверяет, принят ли он из канала, связанного с микросессией STAMP, по значению поля Sender Micro-session ID. Session-Sender микросессии использует также Reflector Micro-session ID для проверки корректности поведения Reflector.
5. Взаимодействие с IANA
Агентство IANA выделило значение STAMP TLV Type лоя Micro-session ID TLV в реестре STAMP TLV Types [RFC8972].
Таблица . Новое значение STAMP TLV Type.
|
Значение |
Описание |
Документ |
|---|---|---|
|
11 |
Micro-session ID |
Этот документ |
6. Вопросы безопасности
Заданное в этом документе расширение STAMP предназначено для применения в системах с LAG, где Session-Sender и Session-Reflector соединены напрямую групповым каналом. Предполагается, что узел, вовлечённый в работу STAMP был проверен на предмет целостности соединения LAG и нахождения узла-партнера на другом конце этого соединения (one-hop-away).
Документ не добавляет соображений безопасности, а механизмы защиты, указанные в [RFC8762] и [RFC8972], применимы и к этому документу.
7. Литература
7.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>.
7.2. Дополнительная литература
[IEEE802.1AX] IEEE, “IEEE Standard for Local and Metropolitan Area Networks — Link Aggregation”, IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, May 2020, <https://ieeexplore.ieee.org/document/9105034>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP)”, RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC7799] Morton, A., “Active and Passive Metrics and Methods (with Hybrid Types In-Between)”, RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, “Advertising Layer 2 Bundle Member Link Attributes in IS-IS”, RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>.
[STAMP-YANG] Mirsky, G., Min, X., Luo, W. S., and R. Gandhi, “Simple Two-way Active Measurement Protocol (STAMP) Data Model”, Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-12, 5 November 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-12>.
Благодарности
Авторы благодарят Mach Chen, Min Xiao, Fang Xin, Marcus Ihlar, Richard Foote за ценные комментарии к работе.
Адреса авторов
Zhenqiang Li China Mobile No. 29 Finance Avenue Xicheng District Beijing China Email: li_zhenqiang@hotmail.com Tianran Zhou Huawei China Email: zhoutianran@huawei.com Jun Guo ZTE Corp. China Email: guo.jun2@zte.com.cn Greg Mirsky Ericsson United States of America Email: gregimirsky@gmail.com Rakesh Gandhi Cisco Systems, Inc. Canada Email: rgandhi@cisco.comПеревод на русский язык
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.