draft-ietf-ippm-twamp-value-added-octets-06.txt   draft-ietf-ippm-twamp-value-added-octets-07.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: March 9, 2013 S. Ekelin Expires: March 24, 2013 S. Ekelin
Ericsson Ericsson
September 5, 2012 September 20, 2012
Ericsson TWAMP Value-Added Octets Ericsson TWAMP Value-Added Octets
draft-ietf-ippm-twamp-value-added-octets-06.txt draft-ietf-ippm-twamp-value-added-octets-07.txt
Abstract Abstract
This memo describes an extension to the TWAMP test protocol for This memo describes an extension to the TWAMP test protocol 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 contains the description of a working prototype. It does This memo contains the description of a working prototype. It does
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on March 9, 2013. This Internet-Draft will expire on March 24, 2013.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2012 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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
This memo does not extend the standard modes of operation through This memo does not extend the standard modes of operation through
assignment of a new value in the Modes field (see Section 3.1 of assignment of a new value in the Modes field (see Section 3.1 of
[RFC4656] for the format of the Server Greeting message). This memo [RFC4656] for the format of the Server Greeting message). This memo
does not define a vendor specific or experimental mode since the does not define a vendor specific or experimental mode since the
Modes field as currently defined does not explicitly reserve a value Modes field as currently defined does not explicitly reserve a value
or range of values for this purpose. or range of values for this purpose.
This memo assumes the TWAMP controller is capable to send test This memo assumes the TWAMP controller is capable to send test
packets with value-added padding octets and the TWAMP responder is packets with value-added padding octets and the TWAMP responder is
configured to interpret the value-added padding octets embedded in configured to interpret the value-added padding octets embedded in
each TWAMP test packet. Bootstrapping such behavior at the TWAMP each TWAMP test packet. Bootstrapping such behavior at the TWAMP
responder is implementation-specific. In general, the Value-Added responder is implementation-specific. By default, the feature MUST be
Octets feature should be deployed in an environment where both disabled on the TWAMP host. In general, the Value-Added Octets
controller and responder are managed by the same administrative feature should be deployed in an environment where both controller
entity and such entity has established an agreement to operate the and responder are managed by the same administrative entity and such
Value-Added Octets feature between the pair of hosts or between entity has established an agreement to operate the Value-Added Octets
specific UDP endpoints between the pair of hosts. See section 4 and feature between the pair of hosts or between specific UDP endpoints
section 5.3 for additional considerations. between the pair of hosts. See section 4 and section 5.3 for
additional considerations.
The Value-Added Octets Version 1 feature is intended to work in The Value-Added Octets Version 1 feature is intended to work in
conjunction with any TWAMP modes. When the Server and Control-Client conjunction with any TWAMP modes. When the Server and Control-Client
are configured or have agreed to use the Value-Added Octets Version 1 are configured or have agreed to use the Value-Added Octets Version 1
feature, then the Control-Client, the Server, the Session-Sender, and feature, then the Control-Client, the Server, the Session-Sender, and
the Session-Reflector must all conform to the requirements of that the Session-Reflector must all conform to the requirements of that
feature, as identified below. feature, as identified below.
3 Capacity Measurement Principles 3 Capacity Measurement Principles
Most capacity estimation methods for APC [RRBNC][PDM][ENHJMMB][SBW] Most capacity estimation methods for APC [RRBNC][PDM][ENHJMMB][SBW]
and for UDP delivery rate need to send and receive packets in groups, and for UDP delivery rate need to send and receive packets in
called packet trains or simply trains. Each train is sent at a groups,called packet trains or simply trains. Each train is sent at a
specific transmission rate in a given direction. These trains must be specific transmission rate in a given direction. These trains must be
identified within each bi-directional test session stream. identified within each bi-directional test session stream.
The first measurement principle is to send multiple trains within a The first measurement principle is to send multiple trains within a
test session stream from one IP node to another IP node in order to test session stream from one IP node to another IP node in order to
estimate the APC, TSC or UDP delivery rate in the forward direction. estimate the APC, TSC or UDP delivery rate in the forward direction.
Each train consists of a group of test packets which are separated Each train consists of a group of test packets which are separated
from each other by a packet interval, as shown in the picture below. from each other by a packet interval, as shown in the picture below.
The packet interval is measured using either the first bit or the The packet interval is measured using either the first bit or the
last bit of two consecutive packets. last bit of two consecutive packets.
skipping to change at page 12, line 41 skipping to change at page 12, line 41
| Train | Desired Reverse Packet... | | Train | Desired Reverse Packet... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval | Additional Packet Padding | | Interval | Additional Packet Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the mode using Reflect Octets illustrated above, the value-added In the mode using Reflect Octets illustrated above, the value-added
padding octets are embedded in the Packet Padding (to be reflected) padding octets are embedded in the Packet Padding (to be
field. reflected)field.
The Version (Ver) field MUST be encoded in the first 4 bits. It The Version (Ver) field MUST be encoded in the first 4 bits. It
identifies the version number of the value-added padding octets and identifies the version number of the value-added padding octets and
meaning of the flag bits and the corresponding fields. This memo meaning of the flag bits and the corresponding fields. This memo
defines version 1 with two flag bits: L and I. When the Value-Added defines version 1 with two flag bits: L and I. When the Value-Added
Octets Version 1 feature is selected, the Session-Sender MUST set the Octets Version 1 feature is selected, the Session-Sender MUST set the
Ver field to 1. Ver field to 1.
The 2 bits after the Version field are used for flags: L and I. The 2 bits after the Version field are used for flags: L and I.
 End of changes. 7 change blocks. 
16 lines changed or deleted 17 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/