Internet Engineering Task Force (IETF) Z. Li
Request for Comments: 9533 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
One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group
Расширения протоколов OWAMP и TWAMP для измерения производительности LAG
Аннотация
Этот документ задаёт расширения протоколов односторонних One-Way Active Measurement Protocol или OWAMP) и двухсторонних (Two-Way Active Measurement Protocol или TWAMP) активных измерений для оценки производительности каждого члена группы агрегирования каналов (Link Aggregation Group или LAG). Знание показателей каждого канала в LAG позволяет операторам внедрять на каждом канале основанные на производительности правила распределения трафика.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9533.
Авторские права
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], OWAMP [RFC4656] и TWAMP [RFC5357] являются активными методами измерения и могут дополнять пассивные и гибридные методы. В любом из методов можно использовать одну тестовую сессию через LAG для измерения производительности конкретного канала группы с использованием специально созданного квинтета (5-tuple). Сессию можно организовать для измерения средних значения части или всех каналов LAG, меняя один или несколько элементов квинтета. Однако без знания каждого члена группы тестовая сессия не может применяться для измерения производительности каждого физического канала в группе.
Этот документ расширяет протоколы OWAMP и TWAMP для измерения производительности каждого канала группы LAG. Расширение может обеспечивать такие же показатели, как OWAMP и TWAMP (задержка и её вариации, потери пакетов.
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. Эти сессии далее в документе называются микросессиями. Хотя фактически микросессии являются сессиями OWAMP или TWAMP на каналах группы LAG, тестовые пакеты микросессий TWAMP должны содержать сведения о конкретном канале для проверки.
Для всех микросессий LAG используются общие значения Sender IP Address и Receiver IP Address. В качестве номера порта UDP все микросессии могут использовать общие значения Sender Port и Receiver Port или для каждой из микросессий может быть задана своя пара номеров Sender Port и Receiver Port. Первый вариант проще в использовании, поэтому рекомендуется применять его.
Тестовые пакеты в микросессиях должны содержать сведения о канале для проверки действительности. Например, при получении тестового пакета микросессии TWAMP Session-Sender проверяет, относится ли этот пакет к ожидаемому каналу группы.
3. Сессия OWAMP
3.1. Micro OWAMP-Control
Для поддержки микросессий OWAMP этот документ определяет новую команду – Request-OW-Micro-Sessions (5), основанную на команде OWAMP Request-Session и использующую формат сообщений, описанный в параграфе 3.5 [RFC4656]. Создание микросессии OWAMP выполняется по процедуре, описанной в параграфе 3.5 [RFC4656] с указанным ниже отличием.
Когда OWAMP Server получает команду Request-OW-Micro-Sessions и запрос воспринят, OWAMP Server должен организовать набор микросессии для всех членов группы LAG из которой было получено сообщение Request-OW-Micro-Sessions.
3.2. Micro OWAMP-Test
Пакеты Micro OWAMP-Test используют формат и процедуры, заданные для OWAMP-Test в разделе 4 [RFC4656] с указанным ниже дополнением.
OWAMP Session-Sender микросессии должен передавать пакеты Micro OWAMP-Test через канал, с которым связана микросессия. При получении тестового пакета OWAMP Session-Receiver микросессии должен сопоставлять канал, из которого принят пакет, с микросессией OWAMP. Если такой сессии нет, тестовый пакет должен отбрасываться.
4. Сессия Micro TWAMP
4.1. Micro TWAMP-Control
Для поддержки микросессий TWAMP этот документ определяет новую команду – Request-TW-Micro-Sessions (11), основанную на команде TWAMP Request-Session и использующую формат сообщений, описанный в параграфе 3.5 [RFC5357]. Для организации микросессии TWAMP используется процедура из параграфа 3.5 в [RFC5357] с указанным ниже дополнением.
При получении сервером TWAMP команды Request-TW-Micro-Sessions и восприятии запроса TWAMP Server должен организовать набор микросессий для всех членов группы каналов LAG, из которой получено сообщение Request-TW-Micro-Sessions.
4.2. Micro TWAMP-Test
Протокол Micro TWAMP-Test основан на протоколе TWAMP-Test [RFC5357] с расширениями, описанными в последующих параграфах.
4.2.1. Формат и содержимое пакетов отправителя
Формат пакета Micro TWAMP Session-Sender основан на формате TWAMP Session-Sender, заданном в параграфе 4.1.2 [RFC5357]. Добавлены два новых поля (Sender Micro-session ID и Reflector Micro-session ID) для передачи идентификаторов каналов группы LAG. Формат для режима без аутентификации приведён ниже.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Micro-session ID | Reflector Micro-session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Packet Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат пакета Micro Session-Sender в режиме без аутентификации.
Для режима с аутентификацией и шифрованием применяется показанный ниже формат.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MBZ (12 октетов) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Micro-session ID | Reflector Micro-session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 октетов) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Packet Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат пакета Micro Session-Sender в режиме с аутентификацией.
Все поля, за исключением Sender Micro-session ID и Reflector Micro-session ID, соответствуют определениям параграфа 4.1.2 в [RFC5357] с использованием указанных там процедур и рекомендаций.
Sender Micro-session ID (2 октета)
Содержит идентификатор канала в группе LAG на стороне Sender. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Sender.Reflector Micro-session ID (2 октета)
Содержит идентификатор канала в группе LAG на стороне Reflector. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Reflector.4.2.2. Поведение отправителя
TWAMP Session-Sender микросессии наследует поведение TWAMP Session-Sender, заданное в параграфе 4.1 [RFC5357]. Дополнительно TWAMP Session-Sender должен передавать тестовые пакеты Micro Session-Sender через каналы-члены, с которыми связана сессия. При передаче тестового пакета TWAMP Session-Sender микросессии должен включать идентификатор канала Sender, связанного с микросессией TWAMP, в поле Sender Micro-session ID. Если Session-Sender изнает идентификатор канала-члена группы у Reflector, он должен указываться в поле Reflector Micro-session ID (см. рисунки 2 и 3). В иных случаях поле Reflector Micro-session ID должно иметь значение 0.
Тестовый пакет с идентификатором канала у Sender передаётся рефлектору Session-Reflector, который «отражает» его с тем же идентификатором канала Sender. Таким образом, Session-Sender может использовать идентификатор канала Sender для проверки получения отражённого тестового пакета из канала-члена, связанного с корректной микросессией TWAMP.
Идентификатор канала у Reflector в поле Reflector Micro-session ID используется рефлектором Session-Reflector для проверки получения тестового пакета из канала, связанного с корректной микросессией TWAMP. Это означает, что Session-Sender нужно узнать идентификатор канала-члена группы у Reflector. Когда Session-Sender знает идентификатор канала у Reflector, он должен помещать его в поле Reflector Micro-session ID (см. рисунки 2 и 3) тестового пакета, передаваемого рефлектору Session-Reflector. Идентификатор канала у Reflector может быть определён из конфигурации или плоскости данных (например, из отражённого тестового пакета). Этот документ не задаёт способ получения идентификатора канала на стороне Reflector.
При получении отражённого тестового пакета TWAMP Session-Sender микросессии должен использовать полученный идентификатор канала для сопоставления тестового пакета с микросессией TWAMP. Если соответствующей сессии нет, отражённый тестовый пакет должен отбрасываться. Если имеется соответствующая сессия, Session-Sender микросессии должен использовать Sender Micro-session ID для проверки корректного получения тестового пакета из ожидаемого канала группы. Если пакет получен из другого канала, он должен отбрасываться. Session-Sender микросессии должен использовать поле Reflector Micro-session ID для проверки поведения Reflector. При несоответствии идентификатора тестовый пакет должен отбрасываться.
4.2.3. Формат и содержимое пакетов рефлектора
Формат пакета Micro TWAMP Session-Reflector основан на формате TWAMP Session-Reflector, заданном в параграфе 4.2.1 [RFC5357]. Добавлены два новых поля (Sender Micro-session ID и Reflector Micro-session ID) для передачи идентификаторов каналов группы LAG. Формат для режима без аутентификации приведён ниже.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | Sender Micro-session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | MBZ | Reflector Micro-session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Packet Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат пакета Micro Session- Reflector в режиме без аутентификации.
Для режима с аутентификацией и шифрованием применяется показанный ниже формат.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (12 октетов) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Micro-session ID | Reflector Micro-session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (8 октетов) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (12 октетов) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (6 октетов) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | | +-+-+-+-+-+-+-+-+ + | | | | | MBZ (15 октетов) | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | HMAC (16 октетов) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Packet Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок . Формат пакета Micro Session- Reflector в режиме с аутентификацией.
Все поля, за исключением Sender Micro-session ID и Reflector Micro-session ID, соответствуют определениям параграфа 4.1.2 в [RFC5357] с использованием указанных там процедур и рекомендаций.
Sender Micro-session ID (2 октета)
Содержит идентификатор канала в группе LAG на стороне Sender. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Sender.Reflector Micro-session ID (2 октета)
Содержит идентификатор канала в группе LAG на стороне Reflector. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Reflector.4.2.4. Поведение рефлектора
TWAMP Session-Reflector микросессии наследует поведение TWAMP Session-Reflector, описанное в параграфе 4.2 [RFC5357]. Дополнительно TWAMP Session-Reflector должен использовать идентификатор канала, откуда получен пакет, для сопоставления пакета с микросессией TWAMP. Если такой сессии нет, тестовый пакет должен отбрасываться. Если поле Reflector Micro-session ID отлично от 0, Reflector должен использовать значение Reflector Micro-session ID для проверки соответствия идентификатору канала, из которого получен пакет (при Reflector Micro-session ID = 0 проверка не выполняется), и должен отбрасывать тестовый пакет при несоответствии.
При отправке отклика на полученный тестовый пакет TWAMP Session-Reflector микросессии должен копировать идентификатор каналу Sender из принятого пакета в поле Sender Micro-session ID отражённого тестового пакета (см. рисунки 4 и 5). Кроме того, TWAMP Session-Reflector микросессии должен помещать в поле Reflector Micro-session ID (см. рисунки 4 и 5) отражённого пакета идентификатор канала, связанного с микросессией TWAMP.
5. Применимость
Для организации микросессий OWAMP клиент Control-Client передаёт команду Request-OW-Micro-Sessions серверу OWAMP. Сервер OWAMP воспринимает запрос и организует набор микросессий для всех каналов группы LAG.
Для микросессий TWAMP применяется похожая процедура, после чего TWAMP Session-Sender микросессии передаёт пакеты Micro Session-Sender с полями Sender Micro-session ID и Reflector Micro-session ID. Если поле Reflector Micro-session ID задано (не 0), Session-Reflector микросессии проверяет получение тестового пакета из канала, соответствующего корректной микросессии TWAMP. При отражении TWAMP Session-Reflector микросессии копирует Sender Micro-session ID из полученного от Session-Sender микросессии пакета в пакет Micro Session-Reflector, затем указывает в поле Reflector Micro-session ID идентификатор канала, связанного с микросессией TWAMP. При получении пакета Micro TWAMP Session-Reflector поле Sender Micro-session ID используется Session-Sender микросессии для проверки получения пакета из канала, соответствующего корректной сессии TWAMP. Session-Sender микросессии также использует поле Reflector Micro-session ID для проверки поведения Reflector.
6. Взаимодействие с IANA
6.1. Команда Micro OWAMP-Control
Агентство IANA включило указанную в таблице 1 команду в реестр OWAMP-Control Command Numbers.
Таблица . Номер команды Request-OW-Micro-Sessions.
|
Значение |
Описание |
Документ |
|---|---|---|
|
5 |
Request-OW-Micro-Sessions |
Этот документ |
6.2. Команда Micro TWAMP-Control
Агентство IANA включило указанную в таблице 2 команду в реестр TWAMP-Control Command Numbers.
Таблица . Номер команды Request-TW-Micro-Sessions.
|
Значение |
Описание |
Документ |
|---|---|---|
|
11 |
Request-TW-Micro-Sessions |
Этот документ |
7. Вопросы безопасности
Этот документ не задаёт дополнительных требований безопасности и механизмов защиты к описанным в [RFC4656] и [RFC5357].
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>.
[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>.
[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>.
[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>.
8.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>.
[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>.
Благодарности
Авторы благодарны Fang Xin, Henrik Nydell, Mach Chen, Min Xiao, Jeff Tantsura, 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.