A Two-Way Active Measurement Protocol (TWAMP)
RFC 5357
| Document | Type |
RFC - Proposed Standard
(October 2008; Errata)
Was draft-ietf-ippm-twamp (ippm WG)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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)
Show full document text