RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)
In plain English — editorial summary, not part of the RFC
The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]
Document record
- Document ID
- RFC5357
- Published
- October 2008
- Authors
- K. Hedayat; R. Krzanowski; A. Morton; K. Yum; J. Babiarz
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- ops
- Pages
- 26
- Also known as
- —
Topics
Referenced by
6 later RFCs formally update or obsolete part of this document.
- RFC 5618Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)Current
August 2009
- RFC 5938Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)Current
August 2010
- RFC 6038Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size FeaturesCurrent
October 2010
- RFC 7717IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)Current
December 2015
- RFC 7750Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)Current
February 2016
- RFC 8545Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)Current
March 2019
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 5358Preventing Use of Recursive Nameservers in Reflector AttacksCurrent
October 2008
- RFC 5343Simple Network Management Protocol (SNMP) Context EngineID DiscoveryCurrent
September 2008
- RFC 5375IPv6 Unicast Address Assignment ConsiderationsCurrent
December 2008
- RFC 5388Information Model and XML Data Model for Traceroute MeasurementsCurrent
December 2008
- RFC 5324MIB for Fibre-Channel Security Protocols (FC-SP)Current
September 2008
- RFC 5415Control And Provisioning of Wireless Access Points (CAPWAP) Protocol SpecificationUpdated
March 2009
- RFC 5416Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11Current
March 2009
- RFC 5417Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP OptionCurrent
March 2009
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?