draft-ietf-ippm-twamp-value-added-octets-05.txt   draft-ietf-ippm-twamp-value-added-octets-06.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: January 20, 2013 S. Ekelin Expires: March 9, 2013 S. Ekelin
Ericsson Ericsson
July 19, 2012 September 5, 2012
Ericsson TWAMP Value-Added Octets Ericsson TWAMP Value-Added Octets
draft-ietf-ippm-twamp-value-added-octets-05.txt draft-ietf-ippm-twamp-value-added-octets-06.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 January 20, 2013. This Internet-Draft will expire on March 9, 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 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4
2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . 4 2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . 4
3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 6 3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 6
4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 7 4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 7
4.1 Additional Considerations . . . . . . . . . . . . . . . . . 8 4.1 Additional Considerations . . . . . . . . . . . . . . . . . 7
5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 8 5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 9 5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 8
5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 9 5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 8
5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 13 5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 13
5.2.1 Session-Reflector Packet Format . . . . . . . . . . 15 5.2.1 Session-Reflector Packet Format . . . . . . . . . . 15
5.3 Additional Considerations . . . . . . . . . . . . . . . . 15 5.3 Additional Considerations . . . . . . . . . . . . . . . . 15
6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 16 6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Security Considerations . . . . . . . . . . . . . . . . . . . 16 7 Security Considerations . . . . . . . . . . . . . . . . . . . 16
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . 17 9.1 Normative References . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . 17
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 5, line 39 skipping to change at page 5, line 39
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 MAY be achieved with configuration provided through the responder is implementation-specific. In general, the Value-Added
host management interface. For instance, the user MAY turn on/off the Octets feature should be deployed in an environment where both
new behavior at the TWAMP responder with a command. When the host is controller and responder are managed by the same administrative
also running with the control protocol, the user MAY configure the entity and such entity has established an agreement to operate the
TWAMP responder to signal its willingness support a vendor specific Value-Added Octets feature between the pair of hosts or between
TWAMP mode that is not currently assigned to existing standard modes specific UDP endpoints between the pair of hosts. See section 4 and
but recognized as the Value-Added Octets Version 1 feature by the section 5.3 for additional considerations.
TWAMP controller. In general, the Value-Added Octets feature should
be deployed in an environment where both controller and responder are
managed by the same administrative entity and such entity has
established an agreement to operate the Value-Added Octets feature
between the pair of hosts or between specific UDP endpoints 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 including future TWAMP modes. When conjunction with any TWAMP modes. When the Server and Control-Client
the Server and Control-Client are configured or have agreed to use are configured or have agreed to use the Value-Added Octets Version 1
the Value-Added Octets Version 1 feature, then the Control-Client, feature, then the Control-Client, the Server, the Session-Sender, and
the Server, the Session-Sender, and the Session-Reflector must all the Session-Reflector must all conform to the requirements of that
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 groups,
called packet trains or simply trains. Each train is sent at a 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
skipping to change at page 7, line 28 skipping to change at page 7, line 19
sent at a higher rate than what is available on the network path. sent at a higher rate than what is available on the network path.
In order to fulfill the above measurement principles and to measure In order to fulfill the above measurement principles and to measure
the APC, TSC and UDP delivery rates in the reverse direction, the the APC, TSC and UDP delivery rates in the reverse direction, the
test packets at the Session-Reflector MUST be re-grouped into trains test packets at the Session-Reflector MUST be re-grouped into trains
and then transmitted back to the Session-Sender with a provided and then transmitted back to the Session-Sender with a provided
packet interval. packet interval.
4 TWAMP Control Extensions 4 TWAMP Control Extensions
TWAMP-Control protocol [RFC5357] uses the Modes field to identify and
select specific communication capabilities, and this field is a
recognized mechanism.
TWAMP connection establishment follows the procedure defined in TWAMP connection establishment follows the procedure defined in
Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. According to Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. The TWAMP-
the standard specifications, the Value-added octet feature requires Control protocol [RFC5357] uses the Modes field to identify and
one new bit position (and value) to identify the ability of the select specific communication capabilities. According to the standard
Server/Session-Reflector to read and act upon the new fields in the specifications, the Value-Added Octets feature requires one new bit
value-added octets. Such bit position (and value) is not defined in position (and value) to identify the ability of the Server/Session-
this memo. Instead, a vendor specific value MAY be used at the Reflector to read and act upon the new fields in the value-added
vendor's own risk. As of today, 7 out of the 32 possible TWAMP modes octets. Such bit position (and value) is not defined in this memo.
are allocated as modes 1, 2, 4, 8, 16, 32 and 64. For instance, value Bootstrapping the TWAMP Value-Added Octets Version 1 feature is
2147483648 could be used by a specific pair of hosts to signal the implementation-specific.
willingness to use the Value-Added Octets feature. If the selected
vendor specific value conflicts with a standard TWAMP mode in the
future, the host MUST comply to the newly standard TWAMP mode and
automatically disable the Value-Added Octets feature. As an
alternative, the user may opt for TWAMP light which does not require
the control protocol. In such case, the configuration and signaling
of a vendor specific TWAMP mode is not necessary.
Both the Reflect Octets mode and Symmetrical Size mode MAY be Both the Reflect Octets mode and Symmetrical Size mode MAY be
selected to ensure the reflection of the value-added padding octets selected to ensure the reflection of the value-added padding octets
by the Session-Reflector and symmetrical size TWAMP-Test packets in by the Session-Reflector and symmetrical size TWAMP-Test packets in
the forward and reverse directions of transmission. the forward and reverse directions of transmission.
4.1 Additional Considerations 4.1 Additional Considerations
In the TWAMP control architecture, the TWAMP reflector (server) In the TWAMP control architecture, the TWAMP reflector (server)
signals the modes it wishes to operate and the TWAMP controller signals the modes it wishes to operate and the TWAMP controller
(control-cient) selects the mode or modes supported by the responder. (control-cient) selects the mode or modes supported by the responder.
This feature is designed to retain backward compatibility with the This feature is designed to retain backward compatibility with the
original TWAMP control and test protocols. original TWAMP control and test protocols. As an alternative, the
user may opt for TWAMP light architecture which does not require the
A TWAMP reflector that does not support the Value-Added Octets TWAMP control protocol.
feature must not signal the corresponding vendor specific mode. In
such case, the TWAMP controller must not select the Value-Added
Octets feature and must not include any value-added octets in the
test packets. If the TWAMP controller inadvertently sends value-added
octets in the test packets, the TWAMP responder shall treat the
value-added octets as regular padding octets and return the test
packets as quickly as possible to the Session-Sender as defined in
[RFC5357].
A TWAMP reflector that does not support the Value-Added Octets The methods to determine if the Value-Added Octets feature is
feature but inadvertently signal a mode mapping to the Value-Octets supported on a TWAMP reflector is implementation-specific. When the
feature shall treat the value-added octets as regular padding octets Value-Added Octets feature is not supported on a TWAMP reflector, the
and return the test packets as quickly as possible to the Session- TWAMP controller must not select the Value-Added Octets feature and
Sender as defined in [RFC5357]. Both hypothetical scenarios do not must not include any value-added octets in the test packets. If the
impact the operation of the TWAMP controller who is still responsible TWAMP controller inadvertently sends value-added octets in the test
to process and collect the performance data. packets to a TWAMP responder that does not support such feature, the
TWAMP responder shall treat the value-added octets as regular padding
octets and return the test packets as quickly as possible to the
Session-Sender as defined in [RFC5357].
5 Extended TWAMP Test 5 Extended TWAMP Test
The forward and reverse APC, TSC and UDP delivery rate measurement The forward and reverse APC, TSC and UDP delivery rate measurement
characteristics depend on the size and packet intervals of the test characteristics depend on the size and packet intervals of the test
packets. This memo allows variable packet sizes and packet intervals packets. This memo allows variable packet sizes and packet intervals
between trains and even between packets in the same train. The between trains and even between packets in the same train. The
functionality is described below. functionality is described below.
The TWAMP-test protocol carrying the value-added padding octets is The TWAMP-test protocol carrying the value-added padding octets is
 End of changes. 12 change blocks. 
65 lines changed or deleted 42 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/