Twamp протокол что это
Протокол измерения производительности IP-сетей
Измерение производительности IP-сетей с помощью стандартных протоколов всегда было трудным делом. Изобретатели IP обеспечили некоторые инструментальные средства для поиска простых неисправностей (ICMP ping, traceroute, UDP Echo), как часть набора программ TCP/IP. Эти инструменты не были предназначены для проведения глубоких исследований производительности сети. В результате остается потребность в основанных на стандартах, эффективных инструментах мониторинга производительности сетей уровня предприятия, пишет Network World.
Организация IETF нацелена заполнить эту потребность новым черновым стандартом TWAMP (Two-Way Active Measurement Protocol), разработанным рабочей группой IP Performance Metrics. TWAMP – двухсторонний протокол активного измерения определяет гибкий метод измерения производительности IP между двумя любыми устройствами сети, которые поддерживают TWAMP.
В прошлом протоколы измерения производительности сети были частными, также не обеспечивалась способность к взаимодействию между сетевыми устройствами от разных поставщиков. TWAMP предлагает операторам больших корпоративных сетей гибкий набор решений и полную доступность информации о производительности с помощью способности к взаимодействию всех устройств, развернутых в сетях предприятия. Работа протокола основана на измерении производительности в центральной и пограничной областях IP-сети с использованием совместной работы маршрутизаторов и коммутаторов. Любые две оконечных точки сети могут взаимодействовать и поэтому устраняется необходимость в дополнительном управляющем программном обеспечении.
Архитектура TWAMP определяет два набора протоколов: один для того, чтобы устанавливать сеансы измерения производительности, названный протоколом управления, другой для передачи и приема измеряющих данных. Протокол управления дает возможность оконечным точкам сети договориться и запустить сеанс измерения производительности. Протокол передачи и приема измеряющих данных определяет формат пакета, который необходим для того, чтобы измерить производительность в обоих направлениях между устройствами сети.
Используя TWAMP, предприятия смогут избежать развертывания дорогостоящих систем управления сетью, в которых используются частные протоколы, и эффективно измерять производительность своей IP-сети во всех ее местоположениях.
Русские Блоги
Протокол TWAMP
Протокол TWAMP
Использование стандартных протоколов для измерения производительности IP-сети всегда является проблемой. Изобретатель IP однажды предоставил некоторые инструменты как часть набора протоколов TCP / IP, такие как Ping по протоколу управляющих сообщений Интернета (ICMP), Traceroute и Echo по протоколу дейтаграмм пользователя (UDP). Однако эти инструменты не готовы к общему тестированию производительности, а предназначены для простого устранения сбоев IP-сети. Следовательно, в корпоративных сетях необходимы стандартные и эффективные инструменты мониторинга производительности.
IETF намеревается использовать новый проект стандарта, разработанный рабочей группой по показателям эффективности интеллектуальной собственности, чтобы удовлетворить эту потребность. Протокол двустороннего активного измерения (TWAMP) определяет гибкий метод измерения производительности двустороннего IP-трафика между любыми двумя устройствами в сети, которые поддерживают этот стандарт. Используя TWAMP, ИТ-менеджеры предприятия могут эффективно измерять полную IP-производительность передачи посредством взаимодействия между развернутыми сетевыми устройствами.
В прошлом протокол был проприетарным, поэтому устройства от разных производителей не могли взаимодействовать. Использование проприетарных протоколов приносит пользу поставщикам оборудования, поскольку заставляет их ИТ-клиентов покупать и развертывать соответствующие продукты в сети.
TWAMP позволяет операторам крупных корпоративных сетей гибко выбирать решения, позволяя им полностью понимать производительность сети за счет возможности взаимодействия всех устройств, развернутых в сети. TWAMP измеряет производительность IP ядра и границы посредством взаимодействия между маршрутизаторами и коммутаторами в сети.
Любые два терминала могут взаимодействовать друг с другом, что снижает потребность менеджеров в развертывании систем, использующих закрытые проприетарные протоколы для измерения производительности.
TWAMP определяет два набора протоколов: один используется для установления сеансов измерения производительности, называемых протоколами управления; другой используется для передачи и приема пробников измерения производительности.
Протокол управления позволяет терминалу согласовывать и инициировать сеанс измерения производительности. Протокол передачи и приема пробника для измерения рабочих характеристик определяет формат пакета данных, необходимый для измерения рабочих характеристик в обоих направлениях. Эта часть протокола разработана с учетом аппаратных реализаций, чтобы снизить нагрузку на локальный ЦП во время сеансов измерения производительности.
Архитектура TWAMP состоит из нескольких объектов, которые отвечают за инициирование сеансов мониторинга и обмен пакетами данных. Для обеспечения гибкости TWAMP определяет разные сущности. Чтобы облегчить реализацию, некоторые из этих объектов могут располагаться рядом.
Протокол управления TWAMP обеспечивает гибкий способ установления сеанса мониторинга и обмена информацией между отправителем и получателем пакета данных мониторинга. В таких сценариях можно исключить необходимость в определенных объектах в TWAMP. В стандарте TWAMP эта упрощенная архитектура определяется как TWAMP Light.
TWAMP Light используется, чтобы помочь тем респондентам, которые активно отвечают контроллеру TWAMP в сети, реализовать этот стандарт для объекта, тем самым реализуя измерение производительности двунаправленного IP в любом месте сети.
Крупным предприятиям необходимо создать экосистему, основанную на протоколах измерения производительности, основанных на стандартах. В этой экосистеме показатели эффективности IP получаются посредством взаимодействия между сетевыми устройствами.
Благодаря использованию и развертыванию TWAMP предприятия могут эффективно измерять производительность IP-сети в различных местах, избегая при этом огромных денежных затрат на развертывание собственной системы управления производительностью протокола.
Понимание протокола двухавтомательных активных измерений
Протокол двухстороннего активного управления (TWAMP), описанный в RFC 5357, является расширением протокола одностороннего активного управления (OWAMP), который обеспечивает измерение в два или оба пути вместо однонаправленных возможностей. Двухсторонние измерения полезны, поскольку задержки в оба пути не требуют синхронизации часов хоста, а удаленная поддержка может явиться простой функцией эха. Однако протокол контроля интернет-сообщений (ICMP) Эхо-запрос/ответ (используется эхо-запросом) для этой цели имеет несколько недостатков. Протокол TWAMP определяет открытый протокол для измерения метрик двусторонности или обратного пути с большей точностью, чем другие методы, с помощью штампов времени (задержки обработки также можно учитывать).
Обычно TWAMP работает между интерфейсами на двух устройствах, которые играют определенную роль. TWAMP часто используется для проверки соответствия соглашению об уровне обслуживания (SLA), и функция TWAMP часто представлена в этом контексте. TWAMP использует два связанных протокола, работающих между несколькими определенными элементами:
TWAMP-управление — инициирует, запускает и завершает тестовые сеансы. Протокол TWAMP-управления запускается между элементом Control-Client и элементом сервера.
TWAMP-Test – обмен пакетами между двумя элементами TWAMP. Протокол TWAMP-test запускается между элементом-отправителем сеанса и отражателем сеанса.
Четыре элемента показаны на рис. 1:
Хотя четыре различных устройства TWAMP могут выполнять четыре логические роли TWAMP Control-Client, Server, Session-Sender и Session-Reflector, различные устройства могут выполнять различные роли. Общая реализация объединяет роли control-Client и Session-Sender в одном устройстве (известном как контроллер TWAMP или клиент TWAMP) и роли сервера и отражателя сеансов на другом устройстве (известном как ответчик TWAMP или TWAMP-сервер). В этом случае каждое устройство работает как по протоколам TWAMP-Control (между Control-Client и Server), так и с протоколами TWAMP-Test (между отправителем сеанса и отражателем сеансов).
Клиент-серверная архитектура TWAMP в ее реализации выглядит так:
Control-Client настраивает, запускает и останавливает тестовые сеансы TWAMP.
Отправитель сеанса создает тестовые пакеты TWAMP, которые отправляются на отражатель сеансов на сервере TWAMP.
Отражаитель сеанса возвращает измерительные пакеты при получении тестового пакета, но не сохраняет такую информацию.
Сервер управляет одним или более сеансами с TWAMP-клиентом и прослушивает контрольные сообщения на TCP-порте.
Упаковка этих элементов в процессы клиента TWAMP и сервера TWAMP показана на рис. 2.
В таблице 1 содержится информация о поддержке TWAMP и связанной с ним информации о времени на MPC, MS-MIC/MPC и других модуль маршрутизации:
Временная заземка на модуль маршрутизации
Временная точка на MPC (аппаратная временная точка)
Временная точка на MPC (si-interface)
Временная точка на MS-MIC/MPC (делегирование зондов)
Understand Two-Way Active Measurement Protocol
The Two-Way Active Management Protocol (TWAMP), described in RFC 5357, is an extension of the One-Way Active Management Protocol (OWAMP) that supplies two-way or round-trip measurements instead of unidirectional capabilities. Two-way measurements are helpful because round-trip delays do not require host clock synchronization and remote support might be a simple echo function. However, the Internet Control Message Protocol (ICMP) Echo Request/Reply (used by ping) for this purpose has several shortcomings. TWAMP defines an open protocol for measuring two-way or round-trip metrics with greater accuracy than other methods by using time-stamps (processing delays can be factored as well).
Usually, TWAMP operates between interfaces on two devices playing specific roles. TWAMP is often used to check Service Level Agreement (SLA) compliance, and the TWAMP feature is often presented in that context. TWAMP uses two related protocols, running between several defined elements:
TWAMP-Control—Initiates, starts, and ends test sessions. The TWAMP-Control protocol runs between a Control-Client element and a Server element.
TWAMP-Test—Exchanges test packets between two TWAMP elements. The TWAMP-Test protocol runs between a Session-Sender element and a Session-Reflector element.
The four elements are shown in Figure 1:
Although four different TWAMP devices can perform the four logical roles of TWAMP Control-Client, Server, Session-Sender, and Session-Reflector, different devices can play different roles. A common implementation combines the roles of Control-Client and Session-Sender in one device (known as the TWAMP controller or TWAMP client) and the roles of Server and Session-Reflector in the other device (known as the TWAMP responder or TWAMP server). In this case, each device runs both the TWAMP-Control (between Control-Client and Server) and TWAMP-Test (between Session-Sender and Session-Reflector) protocols.
The TWAMP client-server architecture as implemented looks like this:
Control-Client sets up, starts and stops the TWAMP test sessions.
Session-Sender creates TWAMP test packets that are sent to the Session-Reflector in the TWAMP server.
Session-Reflector sends back a measurement packet when a test packet is received, but does not maintain a record of such information.
Server manages one or more sessions with the TWAMP client and listens for control messages on a TCP port.
The packaging of these elements into TWAMP client and TWAMP server processes is shown in Figure 2.
Table 1 provides information about TWAMP and related timestamp support on MPC, MS-MIC/MPC, and Routing Engine:
RFC 5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)
Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)
Смешанный режим защиты для протокола TWAMP
Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.
Авторские права ((c) 2009) принадлежат IETF Trust и лицам, указанным в числе авторов документа. Все права защищены.
Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.
Исключено в варианте HTML.
1. Introduction
Протокол TWAMP [RFC5357] является расширением протокола односторонних активных измерений ( One-Way Active Measurement Protocol или OWAMP) [RFC4656]. Спецификация TWAMP прошла широкое обсуждение, в процессе которого были предложены несколько рекомендаций по новым функциям TWAMP. В настоящее время число реализаций TWAMP растет и ожидается их широкое использование. Разработаны даже устройства, предназначенные для проверки соответствия реализаций протоколу.
В этом документе описано простое расширение TWAMP – опция для использования разных режимов защиты в протоколах TWAMP-Control и TWAMP-Test (смешанная защита). Документ также описывает новый реестр IANA для дополнительных функций, названный TWAMP Modes.
Когда Server и Control-Client согласовали использование смешанного режима защиты в процессе организации соединения, Control-Client, Server, Session-Sender и Session-Reflector должны соответствовать требованиям к этому режиму, указанным в разделах 3 – 5.
Этот документ обновляет [RFC5357].
1.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].
2. Назначение и область действия
Назначение этого документа состоит в описании и спецификации расширения для протокола TWAMP [RFC5357] и запросе на создание реестра для будущих расширений TWAMP.
Область действия документа ограничена спецификацией указанного ниже расширения.
Расширение режимов работы путем выделения нового значения поля Modes (параграф 3.1 в [RFC4656]) при сохранении совместимости с имеющимися реализациями TWAMP [RFC5357]. Это значение добавляет необязательную возможность применять разные режимы защиты для протоколов TWAMP-Control и TWAMP-Test. Расширение предназначено для обеспечения протоколу TWAMP-Control, имеющему низкую скорость передачи пакетов, возможности применять более строгую защиту по сравнению с используе мой TWAMP-Test.
3. Расширения TWAMP-Control
Все сообщения OWAMP-Control, за исключением команды Fetch-Session, применимы к протоколу TWAMP-Control.