Internet Engineering Task Force (IETF) A. Morton Request for Comments: 6038 L. Ciavattone Updates: 5357 AT&T Labs Category: Standards Track October 2010 ISSN: 2070-1721
Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features
Октеты отражения и симметричный размер в TWAMP
Аннотация
В этом документе описаны два тесно связанных свойства протокола двухсторонних активных измерений (Two-Way Active Measurement Protocol или TWAMP) – необязательная возможность возврата отвечающим хостом некоторых октетов команды или заполнения отправителю и необязательный формат пакетов отправителя, обеспечивающий одинаковый размер пакетов в обоих направлениях.
Статус документа
Этот документ содержит проект стандарта Internet (Internet Standards Track).
Документ является результатом работы IETF и выражает согласованное мнение сообщества IETF. Документ был представлен на публичное рассмотрение и обобрен для публикации IESG. Дополнительная информация о стандартах Internet доступна в разделе 2 RFC 5741.
Информацию о текущем статусе документа, обнаруженных ошибках и способах обратной связи можно получить, воспользовавшись ссылкой http://www.rfc-editor.org/info/rfc6038.
Авторские права
Авторские права ((c) 2010) принадлежат IETF Trust и лицам, указанным в числе авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.
1. Введение
Протокол двухсторонних активных измерений TWAMP [RFC5357] является расширением протокола односторонних измерений OWAMP [RFC4656]. По мере разработки спецификация TWAMP была подвергнута широкому обсуждению, в результате чего было предложено несколько новых свойств TWAMP. Этот документ описывает два тесно связанных свойства TWAMP.
Одним из необязательных свойств отвечающего хоста является возврат ограниченного числа не назначенных (заполнение) октетов элементу Control-Client или Session-Sender в протоколах TWAMP-Control и TWAMP-Test. Благодаря этому, Control-Client или Session-Sender может встраивать октеты информации, которую он считает полезной, и быть уверенным в том что соответствующий тестовый пакет или отклик будет включать эту информации после отражения и возврата (сервером или рефлектором).
Документ также добавляет необязательную возможность гарантировать, что отраженные тестовые пакеты имеют одинаковый размер в обоих направлениях. Это обеспечивается путем задания нового формата пакетов TWAMP-Test Session-Sender. Хотя TWAMP [RFC5357] рекомендует отсекать заполнение для обеспечения симметрии размеров (компенсация увеличения заголовков в пакетах Session-Reflector), отсечка заполнения рефлектором не гарантируется, а при малом объеме заполнения такое выравнивание размера становится невозможным.
Этот документ обновляет базовый протокол TWAMP [RFC5357]. От системы измерения не требуется реализация описанных здесь функций для соответствия [RFC5357].
В документе для битов, помеченных MBZ (Must Be Zero), должно устанавливаться значение 0 при передаче, а получатель должен игнорировать их. Значение HMAC (Hashed Message Authentication Code) должно рассчитываться в соответствии с параграфом 3.2 в [RFC4656].
2. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119].
3. Назначение и область действия
Цель этого документа состоит в определении двух необязательных тесно связанных свойств TWAMP [RFC5357]. Эти свойства расширяют возможности хостов TWAMP для выполнения простых операций с пакетами управления и тестов – отражение октетов или заполнения, а также поддержка симметрии размера пакетов TWAMP-Test. Мотивами изменений послужило обеспечение хосту контроллера возможности помечать пакеты индексом для упрощения их идентификации и/или обеспечения одинакового размера пакетов, передаваемых в обоих направлениях.
Область действия документа ограничивается спецификацией двух свойств, указанных ниже.
Reflect Octets – отражение октетов
Способность сервера и рефлектора (Server/Session-Reflector) отражать заданные октеты клиенту или отправителю (Client/Session-Sender), а также аналогичное поведение клиента и отправителя.
Symmetrical Size – симметрия размера
Возможность обеспечить протоколу TWAMP-Test одинаковый размер пакетов для обоих направления за счет поддержки нового формата пакетов TWAMP-Test Session-Sender в Session-Sender и Session-Reflector. Меняется только формат тестовых пакетов Session-Sender.
Документ расширяет режимы работы за счет добавления двух значений поля Modes (параграф 3.1 в [RFC4656] для формата сообщения Server Greeting) при сохранении совместимости с реализациями базовой спецификации TWAMP [RFC5357]. Значения, соответствующие новым режимам, заданы в этом документе.
Когда Server и Control-Client согласовали использование режима Reflect Octets при организации управляющего соединения, Control-Client, Server, Session-Sender и Session-Reflector должны соответствовать приведенным ниже требованиям к этому режиму.
Когда Server и Control-Client согласовали использование режима Symmetrical Size при организации управляющего соединения, Control-Client, Server, Session-Sender и Session-Reflector должны соответствовать приведенным ниже требованиям к этому режиму.
4. Расширения TWAMP-Control
Протокол TWAMP-Control [RFC5357] использует поле Modes для идентификации и выбора коммуникационных возможностей и это поле является признанным механизмом расширения. Оба варианта расширения описаны ниже.
4.1. Организация соединения с новыми функциями
Соединения TWAMP организуются по процедуре, определенной в параграфе 3.1 [RFC4656] и параграфе 3.1 [RFC5357]. Новым свойствам нужны две новых битовых позиции (значения) для идентификации способности Server/Session-Reflector отражать конкретные октеты обратно Control-Client/Session-Sender и поддержки нового формата пакетов Session-Sender протокола TWAMP-Test. Выделенные значения и позиции указаны в разделе 7. Взаимодействие с IANA.
Server устанавливает один или оба бита новых режимов в поле Modes сообщения Server Greeting для индикации своих возможностей и желания работать в любом из этих режимов (или в обоих).
Если Control-Client предназначен для работы во всех тестовых сессиях, созданных этим управляющим соединением, с использованием одного или обоих новых режимов, он должен установить соответствующий каждой функции бит в поле Mode сообщения Setup Response. Для этих или иных расширений Control-Client может устанавливать несколько битов поля Mode в сообщении Setup Response.
4.2. Отражение октетов – формат пакета Request-TW-Session
Биты, предназначенные для свойства Reflect Octets в команде Request-TW-Session показаны на рисунке.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Schedule Slots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . ... множество полей (66 октетов) не показано ... . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding Length (4 октета) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time (8 октетов) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timeout (8 октетов) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type-P Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octets to be reflected | Length of padding to reflect | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (4 октетов) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 октетов) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Важно отметить, что поле Padding Length по-прежнему задает число октетов заполнения, которые Session-Sender будет добавлять во все пакеты TWAMP-Test, связанные с этим сеансом тестирования. Ниже обсуждается минимальный размер заполнения после определения двух новых полей вслед за полем Type-P Descriptor.
Отметим, что число октетов заполнения, добавляемых в конце тестового пакета Session-Reflector зависит от поддержки процесса отсечки, рекомендованного спецификацией TWAMP (параграф 4.2.1 в [RFC5357]).
Значение Octets to be reflected нужно указывать в 2-октетном поле, как показано на рисунке, и оно задает число октетов, которые Server должен отразить в сообщении Accept Session в соответствии с приведенным ниже описанием.
Значение Length of padding to reflect нужно указывать в 2-октетном поле, включая в него целое число без знака, указывающее количество октетов. Это поле указывает размер заполнения в пакете TWAMP-Test, которое Session-Sender ожидает в отраженном пакете, и число октетов, которые рефлектору нужно вернуть в своем пакете TWAMP-Test (параграф 5.2). Включение этого размера в сообщение Request-TW-Session позволяет серверу определить возможность выполнения конкретного запроса на отражение заполнения в пакетах TWAMP-Test и заранее организовать обработку для Session-Reflector.
Полю Padding Length следует иметь значение не меньше 27 для сессии TWAMP-Test без аутентификации, чтобы можно было выполнить процесс отсечки, рекомендуемый в спецификации TWAMP (параграф 4.2.1 в [RFC5357]). В сессиях с аутентификацией и шифрованием полю Padding Length следует иметь значение не меньше 641 для возможности отсечки в соответствии со спецификацией TWAMP (параграф 4.2.1 в [RFC5357]). Нужно задавать в поле Padding Length значение больше Length of padding to reflect при организации сеанса тестирования с использованием необязательного режима Reflect Octets.
В режиме TWAMP-Test без аутентификации нужно задавать Padding Length не меньше 27 + Length of padding to reflect при организации тестовой сессии с использованием необязательного режима Reflect Octets и процесса отсечки, рекомендуемого спецификацией TWAMP (параграф 4.2.1 в [RFC5357]). В режимах TWAMP-Test с аутентификацией и шифрованием нужно задавать Padding Length не меньше 64 + Length of padding to reflect при организации тестовой сессии с использованием необязательного режима Reflect Octets и процесса отсечки, рекомендуемого спецификацией TWAMP (параграф 4.2.1 в [RFC5357]).
4.3. Отражение октетов – формат пакета Accept Session
Биты, предназначенные для свойства Reflect Octets в команде Accept Session показаны на рисунке.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept | MBZ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | SID (16 октетов) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reflected octets | Server octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (8 октетов) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 октетов) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В поле Reflected octets нужно указывать число октетов Request-TW-Session для отражения и размер поля составляет 2 октета, как показано на рисунке.
В поле Server octets нужно указывать размер информации, которую сервер ожидает получить в заполнении отраженного пакета TWAMP-Test Packet Padding или 0, а размер поля составляет 2 октета, как показано на рисунке. Хотя Server определяет SID, это поле слишком велико (16 октетов) и обычно не появляется в пакетах TWAMP-Test. Перечисленные ниже элементы должны присутствовать в реализации, использующей свойство Reflect Octets.
-
Когда сервер не требует возврата октетов в пакетах TWAMP-Test, он должен указать 0 в поле Server octets.
-
Когда Server задает число октетов, возвращаемых в пакетах TWAMP-Test, он должен передать отличное от 0 значение в поле Server octets, а TWAMP-Test Sender должен включить эти октеты в поле Packet Padding (отраженного пакета).
-
В параграфе 5.1.22 указано, как Server octets должны включаться в заполнение пакета TWAMP-Test, когда это нужно серверу (указано на втором рисунке в этом параграфе).
При выполнении процесса отсечки, рекомендуемого TWAMP в параграфе 4.2.1 [RFC5357], в поле Accept должно быть указано значение 3 (некоторые аспекты запроса не поддерживаются), если расчет размера заполнения показывает, недостаточное число октетов для выравнивания размера тестовых пакетов Session-Sender и Session-Reflector.
4.4. Дополнительные соображения
Значение поля Modes, передаваемое сервером в сообщении Server Greeting, является объединением (OR) режимов, которые сервер готов поддерживать в этой сессии.
На момент публикации этого RFC использовались последние (младшие) 7 битов 32-битового поля Modes. Control-Client, соответствующий этому расширению [RFC5357], может игнорировать старшие биты поля Modes или может поддерживать другие свойства, передаваемые в этих битах. Оставшиеся биты предназначены для будущих расширений протокола.
5. Расширения TWAMP-Test
Протокол TWAMP-Test похож на тестовый протокол OWAMP [RFC4656] за исключением того, что Session-Reflector передает пакеты отправителю (Session-Sender) в ответ на каждый полученный пакет. TWAMP (см. раздел 4 в [RFC5357] определяет два дополнительных формата тестовых пакетов, пережаваемых рефлектором. Выбор подходящего формата зависит от режима защиты. Заданные здесь новые режимы используют октеты заполнения в каждом пакете или требуют отсечки таких октетов в зависимости от выбранного режима защиты.
5.1. Поведение отправителя
В этом параграфе описаны расширения для поведения TWAMP Session-Sender.
5.1.1. Тактирование пакетов
Send Schedule не применяется в TWAMP и не меняется этим документом.
5.1.2. Отражение октетов – формат и содержимое пакета
Формат и содержимое пакета Session-Sender соответствуют процедуре и рекомендациям параграфа 4.1.2 в [RFC4656] (как указано в параграфе 4.1.2 [RFC5357]).
Режим Reflect Octets переназначает исходное поле TWAMP-Test Packet Padding (параграф 4.1.2 в [RFC4656]) для режима без аутентификации, как показано на рисунке ниже.
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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | Packet Padding (to be reflected) | . (число октетов задается командой) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Additional Packet Padding . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Занчению поля Packet Padding (to be reflected) нужно соответствовать числу октетов, заданному в поле Request-TW-Session Length of padding to reflect для этой тестовой сессии. Эти октеты Session-Sender ожидает получить от Session-Reflector.
Размер поля Additional Packet Padding определяется разностью двух полей команды Request-TW-Session
Additional Packet Padding = Padding Length - Length of padding to reflect
Когда Server назначает октеты для возврата в пакетах TWAMP-Test, он должен передать отличное от 0 значение в поле Server octets, а TWAMP-Test Session-Sender должен включить это значение в первые два октета (Server octets) поля Packet Padding (to be reflected) как показано ниже.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Оставшиеся октеты Packet Padding (to be reflected) |
. (число октетов задается командой) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Поле Server octets содержит те же сведения, которые сервер возвратил клиенту (Control-Client) в сообщении Accept-Session, соответствующем сеансу тестирования (параграф 4.3). В Session-Reflector эти октеты должны быть отражены, как оставшаяся часть поля Packet Padding (to be reflected) field.
Отметим, что Session-Sender может вставлять октеты, используемые в поле Octets to be reflected команды Request-TW-Session, в любое место поля Packet Padding (to be reflected).
5.1.3. Отражение октетов – взаимодействие с отсечкой заполнения
При выборе режима Reflect Octets и выполнении процесса отсечки, рекомедуемого TWAMP (параграф 4.2.1 в [RFC5357]), Session-Sender должен определить минимальное заполнение, требуемое для сохранения одинакового размера тестовых пакетов в обоих направлениях. Объем такого заполнения зависит от режима защиты (без аутентификации, с аутентификацией, с шифрованием) и включения режима Reflect Octets.
При использовании лишь процедуры отсечки TWAMP (параграф 4.2.1 в [RFC5357]) Session-Sender должен добавить в конец пакета достаточное число октетов Packet Padding, чтобы пакеты IP имели одинаковый объем данных (payload) в обоих направлениях (обычно это желательно). Для компенсации большего размера пакетов Session-Reflector отправитель (Session-Sender) должен добавить не менее 27 октетов заполнения в режиме без аутентификации и не менее 643 в режимах с аутентификацией и шифрованием. Размеры пакетов протокола TWAMP-Test и величины отсечки заполнения для получения одного размера пакетов в обоих направлениях показаны в таблице ниже.
Отсечка заполнения TWAMP-Test.
|
Расположение октетов |
Без аутентификации |
С аутентификацией и шифрованием |
|---|---|---|
|
Заголовок рефлектора |
41 |
1121 |
|
Заголовок отправителя |
14 |
48 |
|
Отсекаемое заполнение |
27 |
641 |
При использовании режима Reflect Octets вместе с отсечкой, рекомендуемой TWAMP в параграфе 4.2.1 [RFC5357], Session-Sender должен добавить не менее (27 + Length of the padding to reflect) октетов в режиме без аутентификации. В режимах с аутентификацией и шифрованием Session-Sender должен добавить не менее (641 + Length of the padding to reflect) октетов.
5.1.4. Симметрия размера – формат пакетов Session-Sender
При выборе режима Symmetrical Size отправителю (Session-Sender) в режиме без аутентификации нужно использовать показанный ниже формат пакетов TWAMP-Test.
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 (27 октетов) |
| |
| |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
. .
. Packet Padding .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Это свойство требует изменить лишь формат пакетов Session-Sender, а формат пакетов Session-Reflector сохраняется.
5.1.5. Симметрия размера и отражение октетов – формат пакета Session-Sender
При выборе обоих режимов Symmetrical Size и Reflect Octets отправителю (Session-Sender) нужно применять в режиме без аутентификации показанный ниже формат пакетов TWAMP-Test.
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 (27 октетов) | | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + | Packet Padding (to be reflected) | . (число октетов задается командой) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Additional Packet Padding . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В этом комбинированном режиме после октетов Packet Padding to be reflected следует 27 октетов MBZ в случае работы без аутентификации и 644 октета MBZ при использовании аутентификации и шифрования.
5.2. Поведение рефлектора
Рефлектор TWAMP следует процедуре и рекомендациям параграфа 4.2 в [RFC5357] с 2 дополнительными функциями.
Reflect Octets
Указанные в поле Packet Padding (to be reflected) октеты тестового пакета Session-Sender должны включаться в тестовый пакет Session-Reflector.
Symmetrical Size
Session-Reflector должен работать, используя формат пакетов Session_Sender5, определенный в параграфе 5.1.4, где Padding Octets отделены от информационных полей.
5.2.1. Отражение октетов – формат и содержимое пакета Session-Reflector
Свойство Reflect Padding переопределяет поле Packet Padding, как показано ниже. При выборе режима Reflect Octets отправителю (Session-Sender6) нужно использовать в случае работы без аутентификации показанный ниже формат пакетов TWAMP-Test.
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 | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | Packet Padding (from Session-Sender) | +-+-+-+-+-+-+-+-+ + . . + +-+-+-+-+-+-+-+-+ | Packet Padding (from Session-Sender) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | | . Additional Packet Padding . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Поле Packet Padding (from Session-Sender) должно указывать столько же октетов как поле Packet Padding (to be reflected) в тестовом пакете Session-Sender, поэтому должно соответствовать размеру, заданному в сообщении Request-TW-Session.
Когда сервер возвращает отличное от 0 значение в поле Server octets сообщения Accept Session (параграф 4.3), рефлектору нужно отразить эти октеты в оставшейся части поля Packet Padding (to be reflected).
Параграф 4.2.1 в [RFC5357] рекомендует использовать в TWAMP процесс отсечки заполнения. При использовании этого процесса с режимом Reflect Octets рефлектор должен отражать указанные октеты из тестового пакета Session-Sender в поле Packet Padding (from Session-Sender) и может повторно использовать дополнительные октеты Packet Padding от Session-Sender. Session-Reflector должен отсекать заполнение так, чтобы отбросить макимальное число октетов для совпадения размера пакета с размером пакета от Session-Sender. При использовании рекомендуемого процесса отсечки Session-Reflector должен оставить 27 октетов заполнения в режиме без аутентификации и 647 в режимах с аутентификацией и шифрованием.
В любом случае Session-Reflector может повторно использовать Packet Padding отправителя, поскольку требования к заполнению совпадают.
5.2.2. Симметрия размера – формат пакета Session-Reflector
При выборе режима Symmetrical Size формат пакетов для режима без аутентификации и режимов с аутентификацией и шифрованием идентичен формату базовой спецификации TWAMP (параграф 4.2.1 в [RFC5357]. Поэтому формат тестовых пакетов Session-Reflector не меняется.
Session-Reflector должен создавать свои тестовые пакеты, используя информацию из пакетов от Session-Sender. Размер пакетов Session-Reflector нужно делать равным размеру пакетов Session-Sender.
5.2.3. Симметрия размера и отражение октетов – формат пакета Session-Sender
При выборе обоих режимов Symmetrical Size и Reflect Octets рефлектор должен работать с пакетами формата Session-Sender, определенного в параграфе 5.1.5, где Padding Octets отделены от информационных полей, а поле Packet Padding (to be reflected) предшествует Additional Padding.
Рефлектору нужно использовать тот же формат пакетов TWAMP-Test, который задан в параграфе 5.2.1.
6. Вопросы безопасности
Расширенные режимы работы не открывают возможности новых атак на хосты, взаиможействующие по протоколу TWAMP [RFC5357].
Применимы все соображения безопасности, относящиеся к двухсторонним измерениям в работающих сетях (см.[RFC4656] и [RFC5357]).
7. Взаимодействие с IANA
Этот документ добавляет два режима работы в реестр IANA для поля TWAMP Modes и описывает поведение при использовании этих режимов. Это поле признано механизмом расширения для TWAMP.
7.1. Спецификация реестра
Агентство IANA создало реестр TWAMP-Modes (по запросу [RFC5618]). Режимы TWAMP указываются в сообщениях TWAMP Server Greeting и Setup Response, как указано в параграфе 3.1 [RFC5357], в соответствии с параграфом 3.1 of [RFC4656] и расширены этим документом. Режимы указываются установкой битов 32-битового поля Modes, которые включены в реестр Modes. Для реестра TWAMP-Modes выделение новых значений (битов) предполагается для новых функций, если нет явных причин поступать иначе (например, использовать комплексное кодирование для расширения в будущем).
7.2. Содержимое реестра
Реестр TWAMP-Modes дополнен приведенными ниже значениями.
|
Значение |
Описание |
Определение семантики |
|---|---|---|
|
32 |
Reflect Octets |
Данный документ, параграф 3.1 (бит 5) |
|
64 |
Symmetrical Size |
Данный документ, параграф 3.1 (бит 6) |
8. Благодарности
Авторы благодарят Steve Baillargeon, Walt Steverson и Stina Ross за полезные комментарии и рецензии.
9. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP)”, RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, October 2008.
[RFC5618] Morton, A. and K. Hedayat, “Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)”, RFC 5618, August 2009.
Адреса авторов
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Len Ciavattone
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
Phone: +1 732 420 1239
EMail: lencia@att.com
Перевод на русский язык
Николай Малых
1В оригинале указано некорректное значение. См. https://www.rfc-editor.org/errata/eid6409. Прим.перев.
2В оригинале ошибочно указан параграф 4.1.2. См. https://www.rfc-editor.org/rfc/rfc6038.txt. Прим. перев.
3В оригинале указано некорректное значение. См. https://www.rfc-editor.org/errata/eid6408. Прим.перев.
4В оригинале ошибочно указано 56. См. https://www.rfc-editor.org/errata/eid5549. Прим. перев.
5В оригинале ошибочно указано Session_Reflector. См. https://www.rfc-editor.org/errata/eid4259. Прим. перев.
6В оригинале ошибочно указано Session-Sender. См. https://www.rfc-editor.org/errata/eid4260. Прим. перев.
7В оригинале ошибочно указано 56. См. https://www.rfc-editor.org/errata/eid6410. Прим. перев.