A Two-Way Active Measurement Protocol (TWAMP)
RFC 5357
Document | Type |
RFC - Proposed Standard
(October 2008; Errata)
Was draft-ietf-ippm-twamp (ippm WG)
|
|
---|---|---|---|
Authors | Jozef Babiarz , Roman Krzanowski , Kaynam Hedayat , Kiho Yum , Al Morton | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5357 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lars Eggert | ||
Send notices to | (None) |
Network Working Group K. Hedayat Request for Comments: 5357 Brix Networks Category: Standards Track R. Krzanowski Verizon A. Morton AT&T Labs K. Yum Juniper Networks J. Babiarz Nortel Networks October 2008 A Two-Way Active Measurement Protocol (TWAMP) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract 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. Hedayat, et al. Standards Track [Page 1] RFC 5357 Two-Way Active Measurement Protocol October 2008 Table of Contents 1. Introduction ....................................................2 1.1. Relationship of Test and Control Protocols .................3 1.2. Logical Model ..............................................3 1.3. Pronunciation Guide ........................................4 2. Protocol Overview ...............................................5 3. TWAMP-Control ...................................................6 3.1. Connection Setup ...........................................6 3.2. Integrity Protection .......................................7 3.3. Values of the Accept Field .................................7 3.4. TWAMP-Control Commands .....................................7 3.5. Creating Test Sessions .....................................8 3.6. Send Schedules ............................................10 3.7. Starting Test Sessions ....................................10 3.8. Stop-Sessions .............................................10 3.9. Fetch-Session .............................................12 4. TWAMP-Test .....................................................12 4.1. Sender Behavior ...........................................12 4.1.1. Packet Timings .....................................12 4.1.2. Packet Format and Content ..........................12 4.2. Reflector Behavior ........................................13 4.2.1. TWAMP-Test Packet Format and Content ...............14 5. Implementers' Guide ............................................20 6. Security Considerations ........................................20 7. Acknowledgements ...............................................21 8. IANA Considerations ............................................21 8.1. Registry Specification ....................................22 8.2. Registry Management .......................................22 8.3. Experimental Numbers ......................................22 8.4. Initial Registry Contents .................................22 9. Internationalization Considerations ............................22 Appendix I - TWAMP Light (Informative) ............................23 Normative References ..............................................24 Informative References ............................................24 1. Introduction The Internet Engineering Task Force (IETF) has completed a Proposed Standard for the round-trip delay [RFC2681] metric. The IETF has also completed a protocol for the control and collection of one-way measurements, the One-way Active Measurement Protocol (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip or two-way measurements. Two-way measurements are common in IP networks, primarily becauseShow full document text