Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets
RFC 6802
Internet Engineering Task Force (IETF) S. Baillargeon
Request for Comments: 6802 C. Flinta
Category: Informational A. Johnsson
ISSN: 2070-1721 Ericsson
November 2012
Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets
Abstract
This memo describes an extension to the Two-Way Active Measurement
Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol,
which identifies and manages packet trains, in order to measure
capacity metrics like the available path capacity, tight section
capacity, and UDP delivery rate in the forward and reverse path
directions.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It has been approved for publication by the Internet
Engineering Steering Group (IESG). Not all documents approved by the
IESG are a candidate for any level of Internet Standard; see Section
2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6802.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Baillargeon, et al. Informational [Page 1]
RFC 6802 Ericsson TWAMP Value-Added Octets November 2012
Table of Contents
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Purpose and Scope ...............................................3
3. Capacity Measurement Principles .................................4
4. TWAMP-Control Extensions ........................................5
4.1. Additional Considerations ..................................6
5. Extended TWAMP-Test .............................................6
5.1. Sender Behavior ............................................6
5.1.1. Packet Timings ......................................7
5.1.2. Session-Sender Packet Format ........................7
5.2. Reflector Behavior ........................................12
5.2.1. Session-Reflector Packet Format ....................13
5.3. Additional Considerations .................................13
6. Experiments ....................................................14
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
1. Introduction
The notion of embedding a number of meaningful fields in the padding
octets has been established as a viable methodology for carrying
additional information within the TWAMP-Test protocol running between
a Session-Sender and a Session-Reflector [RFC5357] [RFC6038].
This memo describes an optional extension to the Two-Way Active
Measurement Protocol (TWAMP) [RFC5357]. It is called the Ericsson
TWAMP Value-Added Octets feature. This memo defines version 1.
This feature enables the controller host to measure capacity metrics
like the IP-type-P available path capacity (APC) [RFC5136], IP-layer
tight section capacity (TSC) [Y1540], and UDP delivery rate on both
forward and reverse paths using a single TWAMP test session. The
actual method to calculate the APC, TSC, or the UDP delivery rate
from packet-level performance data is not discussed in this memo.
The Valued-Added Octets feature consists of new behaviors for the
Session-Sender and Session-Reflector and a set of value-added octets
of information that are placed at the beginning of the Packet Padding
[RFC5357] or immediately after the Server Octets in the Packet
Padding (to be reflected) [RFC6038] by the Session-Sender and are
reflected or returned by the Session-Reflector. The length of the
Show full document text