draft-ietf-ippm-twamp-value-added-octets-00.txt   draft-ietf-ippm-twamp-value-added-octets-01.txt 
Network Working Group S. Baillargeon Network Working Group S. Baillargeon
INTERNET-DRAFT C. Flinta INTERNET-DRAFT C. Flinta
Intended Status: Informational A. Johnsson Intended Status: Informational A. Johnsson
Expires: August 8, 2012 S. Ekelin Expires: September 27, 2012 S. Ekelin
Ericsson Ericsson
February 8, 2012 March 26, 2012
TWAMP Value-Added Octets TWAMP Value-Added Octets
draft-ietf-ippm-twamp-value-added-octets-00.txt draft-ietf-ippm-twamp-value-added-octets-01.txt
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
This memo describes optional extensions to the TWAMP test protocol This memo describes an extension to the TWAMP test protocol for
for identifying and managing packet trains, which enables measuring identifying and managing packet trains, which enables measuring
capacity metrics like the available path capacity, tight section capacity metrics like the available path capacity, tight section
capacity and UDP delivery rate in the forward and reverse path capacity and UDP delivery rate in the forward and reverse path
directions. directions.
This memo is the product of a working prototype. It does not
represent a consensus of the IETF community. The IETF community is
currently working on the problem statement and has not reached
consensus on the preferred method for measuring capacity metrics.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 27, 2012.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . 4 2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . 4
3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 5 3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 5
4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 6 4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 6
5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 7 5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 7 5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 7 5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 7
5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 7 5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 7
5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 12 5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 12
5.2.1 Session-Reflector Packet Format . . . . . . . . . . 13 5.2.1 Session-Reflector Packet Format . . . . . . . . . . 13
5.3 Additional Considerations . . . . . . . . . . . . . . . . 14 5.3 Additional Considerations . . . . . . . . . . . . . . . . 14
6 Security Considerations . . . . . . . . . . . . . . . . . . . 14 6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 14
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7 Security Considerations . . . . . . . . . . . . . . . . . . . 14
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . 15 8.1 Normative References . . . . . . . . . . . . . . . . . . 15
8.2 Informative References . . . . . . . . . . . . . . . . . 15 8.2 Informative References . . . . . . . . . . . . . . . . . 15
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1 Introduction 1 Introduction
The notion of embedding a number of meaningful fields in the padding The notion of embedding a number of meaningful fields in the padding
octets has been established as a viable methodology for carrying octets has been established as a viable methodology for carrying
additional information within the TWAMP-Test protocol running between additional information within the TWAMP-Test protocol running between
a Session-Sender and a Session-Reflector [RFC5357] [RFC6038]. a Session-Sender and a Session-Reflector [RFC5357] [RFC6038].
This memo describes an extension to the Two-Way Active Measurement This memo describes an optional extension to the Two-Way Active
Protocol [RFC5357]. It is called the Value-Added Octets feature. Measurement Protocol [RFC5357]. It is called the Value-Added Octets
feature.
This feature enables the controller host to measure capacity metrics This feature enables the controller host to measure capacity metrics
like the IP-type-P available path capacity (APC) [RFC5136], IP-layer like the IP-type-P available path capacity (APC) [RFC5136], IP-layer
tight section capacity (TSC) [Y1540] and UDP delivery rate (e.g. as tight section capacity (TSC) [Y1540] and UDP delivery rate (e.g. as
defined in [RFC1242]) on both forward and reverse paths using a defined in [RFC1242]) on both forward and reverse paths using a
single TWAMP test session with symmetrical or asymmetrical test single TWAMP test session with symmetrical or asymmetrical test
packet sizes. The actual method to calculate the APC, TSC or the UDP packet sizes. The actual method to calculate the APC, TSC or the UDP
delivery rate from packet-level data performance data is not delivery rate from packet-level data performance data is not
discussed in this memo. discussed in this memo.
The Valued-Added Octets feature consists of new behaviors for the The Valued-Added Octets feature consists of new behaviors for the
Session-Sender and Session-Reflector, and a set of value-added octets Session-Sender and Session-Reflector, and a set of value-added octets
of information that are placed at the beginning of the Packet Padding of information that are placed at the beginning of the Packet Padding
field [RFC5357] or at the beginning of the Packet Padding (to be field [RFC5357] or at the beginning of the Packet Padding (to be
reflected) field [RFC6038] by the Session-Sender, and are reflected reflected) field [RFC6038] by the Session-Sender, and are reflected
or returned by the Session-Reflector. The length of the value-added or returned by the Session-Reflector. The length of the value-added
octets (version 1) is 14 octets. octets (version 1) is 14 octets.
This memo is the product of a working prototype. It does not
represent a consensus of the IETF community. The IETF community is
currently working on the problem statement and has not reached
consensus on the preferred method for measuring capacity metrics.
1.1 Requirements Language 1.1 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2 Purpose and scope 2 Purpose and scope
The purpose of this memo is to describe the Valued-Added Octets The purpose of this memo is to describe the Valued-Added Octets
feature for TWAMP [RFC5357]. feature for TWAMP [RFC5357].
skipping to change at page 14, line 33 skipping to change at page 14, line 21
test sessions operate in TWAMP Light. When the Session-Reflector does test sessions operate in TWAMP Light. When the Session-Reflector does
not have knowledge of the session state, the measurement system will not have knowledge of the session state, the measurement system will
only be capable to estimate or calculate the capacity metrics in the only be capable to estimate or calculate the capacity metrics in the
forward path direction of transmission. Capacity measurements in the forward path direction of transmission. Capacity measurements in the
reverse path direction requires the Session-Reflector to have reverse path direction requires the Session-Reflector to have
knowledge of the session state and be capable to identify the test knowledge of the session state and be capable to identify the test
packets belonging to a specific test session. The method for creating packets belonging to a specific test session. The method for creating
a session state from the initial test packets on the TWAMP Light a session state from the initial test packets on the TWAMP Light
Session-Reflector is outside the scope of this specification. Session-Reflector is outside the scope of this specification.
6 Security Considerations 6 Experiments
This memo describes the protocol used in the current working
prototype implementation of the Value-added octets feature in the
Ericsson lab. The prototype has been tested in real network
environments. The conclusion from these tests is that the Value-added
octets feature is able to enable estimation of metrics such as
available path capacity in both the forward and reverse direction of
the network path.
During the experiments with the protocol described in this memo we
have identified a need for the controller and responder to use the
same maximum train length. The reflector must be able to buffer the
whole trains received from the controller. In order to reduce the
risk for buffer overrun the maximum train length may be negotiated.
This can be resolved by a new field in the Value-added octets or with
a new Request-Session message with a maximum train length field.
7 Security Considerations
The value-added padding octets permit DoS attacks on the responder The value-added padding octets permit DoS attacks on the responder
host communicating with core TWAMP [RFC5357]. The responder host MUST host communicating with core TWAMP [RFC5357]. The responder host MUST
provide a mechanism to protect or limit the use of its local memory, provide a mechanism to protect or limit the use of its local memory,
buffer space or maximum transmission time for a train. buffer space or maximum transmission time for a train.
The security considerations that apply to any active measurement of The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656] and [RFC5357]. live networks are relevant here as well. See [RFC4656] and [RFC5357].
7 IANA Considerations
IANA has created a TWAMP-Modes registry (as requested in [RFC5618]).
TWAMP-Modes are specified in TWAMP Server Greeting messages and Setup
Response messages, as described in Section 3.1 of [RFC5357],
consistent with Section 3.1 of [RFC4656]. Modes are indicated by
setting bits in the 32-bit Modes field that correspond to values in
the Modes registry. For the TWAMP-Modes registry, new features are
usually assigned increasing registry values that correspond to single
bit positions.
This memo does not define a new TWAMP mode. Therefore it is not a
recognized extension mechanism for TWAMP. A new mode is required to
communicate feature capability and use in an interoperable manner.
This is outside the scope of this memo.
8 References 8 References
8.1 Normative References 8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Zekauskas, "A One-way Active Measurement
Protocol(OWAMP)", RFC 4656, September 2006. Protocol(OWAMP)", RFC 4656, September 2006.
 End of changes. 14 change blocks. 
41 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/