draft-ietf-ippm-twamp-value-added-octets-04.txt   draft-ietf-ippm-twamp-value-added-octets-05.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: December 31, 2012 S. Ekelin Expires: January 20, 2013 S. Ekelin
Ericsson Ericsson
June 29, 2012 July 19, 2012
Ericsson TWAMP Value-Added Octets Ericsson TWAMP Value-Added Octets
draft-ietf-ippm-twamp-value-added-octets-04.txt draft-ietf-ippm-twamp-value-added-octets-05.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 December 31, 2012. This Internet-Draft will expire on January 20, 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 10 skipping to change at page 3, line 10
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
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 . . . . . . . . . . . . . . . . 5 3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 6
4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 7 4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 7
5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Additional Considerations . . . . . . . . . . . . . . . . . 8
5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 8 5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 8 5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 9
5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 8 5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 9
5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 12 5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 9
5.2.1 Session-Reflector Packet Format . . . . . . . . . . 14 5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 13
5.3 Additional Considerations . . . . . . . . . . . . . . . . 14 5.2.1 Session-Reflector Packet Format . . . . . . . . . . 15
6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 Additional Considerations . . . . . . . . . . . . . . . . 15
7 Security Considerations . . . . . . . . . . . . . . . . . . . 15 6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 16
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7 Security Considerations . . . . . . . . . . . . . . . . . . . 16
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1 Normative References . . . . . . . . . . . . . . . . . . 15 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . 17
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . 17
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 optional extension to the Two-Way Active This memo describes an optional extension to the Two-Way Active
Measurement Protocol [RFC5357]. It is called the Ericsson TWAMP Measurement Protocol [RFC5357]. It is called the Ericsson TWAMP
skipping to change at page 4, line 26 skipping to change at page 4, line 26
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 on both tight section capacity (TSC) [Y1540] and UDP delivery rate on both
forward and reverse paths using a single TWAMP test session. The forward and reverse paths using a single TWAMP test session. The
actual method to calculate the APC, TSC or the UDP delivery rate from actual method to calculate the APC, TSC or the UDP delivery rate from
packet-level data performance data is not discussed in this memo. packet-level data performance data is not 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 immediately after the Server Octets in the Packet
reflected) field [RFC6038] by the Session-Sender, and are reflected Padding (to be reflected) field [RFC6038] by the Session-Sender, and
or returned by the Session-Reflector. The length of the value-added are reflected or returned by the Session-Reflector. The length of the
octets in version 1 is 10 octets. value-added octets in version 1 is 10 octets. The Valued-Added Octets
feature does not change the basic roles and functions of the TWAMP
hosts which are still responsible to include timestamp(s) and
sequence number(s) in the test packets.
This memo contains the description of a working prototype. It does This memo contains the description of a working prototype. It does
not represent a consensus of the IETF community. The IETF community not represent a consensus of the IETF community. The IETF community
is currently working on the problem statement and has not reached is currently working on the problem statement and has not reached
consensus on the preferred method for measuring capacity metrics. 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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
o The definition of new Session-Sender and Session-Reflector o The definition of new Session-Sender and Session-Reflector
behaviors behaviors
The motivation for this feature is to enable the measurement of The motivation for this feature is to enable the measurement of
capacity metrics on both the forward and reverse paths using a single capacity metrics on both the forward and reverse paths using a single
TWAMP test session. Multiple TWAMP test sessions between a controller TWAMP test session. Multiple TWAMP test sessions between a controller
and a responder with different DSCPs may also be used to evaluate the and a responder with different DSCPs may also be used to evaluate the
QoS impacts on the capacity metrics. QoS impacts on the capacity metrics.
The motivation for this document is to capture the prototype
presented and demonstrated at the IETF 80. It may be used as a
reference for future work or may be used during benchmark analysis to
compare the accuracy or performance of the available path capacity
estimates under various condition or use cases.
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). A new mode [RFC4656] for the format of the Server Greeting message). This memo
is recommended to communicate feature capability during control does not define a vendor specific or experimental mode since the
connection setup. Modes field as currently defined does not explicitly reserve a value
or range of values for this purpose.
This memo assumes the TWAMP responder is configured through non-
standard means to interpret the value-added padding octets embedded
in each TWAMP test packet. Bootstrapping such behavior MAY be
achieved using one of the following methods:
o Configuration provided through the management interface
o Assignment of a proprietary TWAMP mode communicated during
TWAMP control connection setup
The Value-Added Octets Version 1 mode is intended to work with any This memo assumes the TWAMP controller is capable to send test
TWAMP modes. When the Server and Control-Client are configured or packets with value-added padding octets and the TWAMP responder is
have agreed to use the Value-Added Octets Version 1 mode during configured to interpret the value-added padding octets embedded in
control connection setup, then the Control-Client, the Server, the each TWAMP test packet. Bootstrapping such behavior at the TWAMP
Session-Sender, and the Session-Reflector must all conform to the responder MAY be achieved with configuration provided through the
requirements of that mode, as identified below. host management interface. For instance, the user MAY turn on/off the
new behavior at the TWAMP responder with a command. When the host is
also running with the control protocol, the user MAY configure the
TWAMP responder to signal its willingness support a vendor specific
TWAMP mode that is not currently assigned to existing standard modes
but recognized as the Value-Added Octets Version 1 feature by the
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 packet padding octets are designed to retain backward The Value-Added Octets Version 1 feature is intended to work in
compatibility with the original TWAMP test protocol [RFC5357]. conjunction with any TWAMP modes including future TWAMP modes. When
the Server and Control-Client are configured or have agreed to use
the Value-Added Octets Version 1 feature, then the Control-Client,
the Server, the Session-Sender, and the Session-Reflector must all
conform to the requirements of that 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 17 skipping to change at page 7, line 30
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 TWAMP-Control protocol [RFC5357] uses the Modes field to identify and
select specific communication capabilities, and this field is a select specific communication capabilities, and this field is a
recognized extension mechanism. 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]. For Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. According to
interoperability, the Value-added octet feature requires one new bit the standard specifications, the Value-added octet feature requires
position (and value) to identify the ability of the Server/Session- one new bit position (and value) to identify the ability of the
Reflector to read and act upon the new fields in the value-added Server/Session-Reflector to read and act upon the new fields in the
octets. Such bit position (and value) is not defined in this memo. A value-added octets. Such bit position (and value) is not defined in
proprietary value MAY be used. this memo. Instead, a vendor specific value MAY be used at the
vendor's own risk. As of today, 7 out of the 32 possible TWAMP modes
are allocated as modes 1, 2, 4, 8, 16, 32 and 64. For instance, value
2147483648 could be used by a specific pair of hosts to signal the
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
In the TWAMP control architecture, the TWAMP reflector (server)
signals the modes it wishes to operate and the TWAMP controller
(control-cient) selects the mode or modes supported by the responder.
This feature is designed to retain backward compatibility with the
original TWAMP control and test protocols.
A TWAMP reflector that does not support the Value-Added Octets
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
feature but inadvertently signal a mode mapping to the Value-Octets
feature 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]. Both hypothetical scenarios do not
impact the operation of the TWAMP controller who is still responsible
to process and collect the performance data.
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
identical to TWAMP [RFC5357] except for the definition of the first identical to TWAMP [RFC5357] except for the definition of the first
skipping to change at page 8, line 27 skipping to change at page 9, line 27
The Session-Sender packet format follows the same procedure and The Session-Sender packet format follows the same procedure and
guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and
Symmetrical Size Features [RFC6038]. Symmetrical Size Features [RFC6038].
This feature allows the Session-Sender to set the first few octets in This feature allows the Session-Sender to set the first few octets in
the TWAMP-Test Packet Padding field with information to communicate the TWAMP-Test Packet Padding field with information to communicate
value-added padding version number, flag bits, sequence number of the value-added padding version number, flag bits, sequence number of the
last packet in a train and desired reverse packet interval (or per- last packet in a train and desired reverse packet interval (or per-
packet waiting time) for the reverse path direction of transmission. packet waiting time) for the reverse path direction of transmission.
The Valued-Added Octets feature must be immediately placed after the
TWAMP header or immediately after any new field that could be added
to the TWAMP header or added to the beginning of the padding octets
in the future. Therefore the placement of the first bit from the
valued-added octets depends on the mode(s) being selected.
A version number and a sequence of flag bits are defined at the very A version number and a sequence of flag bits are defined at the very
beginning of the value-added padding octets. The version number beginning of the value-added padding octets. The version number
identifies the version of the value-added padding octets and meaning identifies the version of the value-added padding octets and meaning
of the flag bits and corresponding fields. Each flag bit indicates if of the flag bits and corresponding fields. Each flag bit indicates if
a specific field is used in the valued-added padding octets. The a specific field is used in the valued-added padding octets. The
version number and flag bits provide an effective method for version number and flag bits provide an effective method for
extracting information at Session-Reflector and Session-Sender. This extracting information at Session-Reflector and Session-Sender. This
document defines version 1 with two flag bits: L and I. document defines version 1 with two flag bits: L and I.
The format of the test packet depends on the TWAMP modes. The Value- The format of the test packet depends on the TWAMP modes. The Value-
Added Octets Version 1 mode is intended to work with any TWAMP Added Octets Version 1 feature is intended to work with any TWAMP
modes. modes.
The Session-Sender SHALL use the following TWAMP test packet format The Session-Sender SHALL use the following TWAMP test packet format
when the Value-Added Octets version 1 is selected in conjunction with when the Value-Added Octets version 1 is selected in conjunction with
the Unauthenticated mode: the Unauthenticated mode:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
skipping to change at page 11, line 48 skipping to change at page 12, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 reflected)
field. 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 mode 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.
The Last Seqno in Train bit (L) is the first flag. When the Value- The Last Seqno in Train bit (L) is the first flag. When the Value-
Added Octets Version 1 mode is selected, the Session-Sender MAY set Added Octets Version 1 feature is selected, the Session-Sender MAY
the Last Seqno in Train bit L to 1. set the Last Seqno in Train bit L to 1.
The Desired Reverse Packet Interval bit (I) is the second flag. When The Desired Reverse Packet Interval bit (I) is the second flag. When
the Value-Added Octets Version 1 mode is selected, the Session-Sender the Value-Added Octets Version 1 feature is selected, the Session-
MAY set the Desired Reverse Packet Interval bit I to 1. Sender MAY set the Desired Reverse Packet Interval bit I to 1.
The Reserved field is reserved for future use. All 10 bits of the The Reserved field is reserved for future use. All 10 bits of the
Reserved field MUST be transmitted as zero by the Session-Sender. Reserved field MUST be transmitted as zero by the Session-Sender.
If the Last Seqno in Train bit is set to 1, then the Last Seqno in If the Last Seqno in Train bit is set to 1, then the Last Seqno in
Train field MUST contain an unsigned 32 bit integer generated by the Train field MUST contain an unsigned 32 bit integer generated by the
Session-Sender. It MUST indicate the expected sequence number of the Session-Sender. It MUST indicate the expected sequence number of the
last packet in the train. It SHOULD be used by the Session-Sender and last packet in the train. It SHOULD be used by the Session-Sender and
Session-reflector to identify the train a test packet belongs to. The Session-reflector to identify the train a test packet belongs to. The
packets belonging to a train are determined by observing the test packets belonging to a train are determined by observing the test
skipping to change at page 14, line 10 skipping to change at page 15, line 10
Session-Sender. If the train is already transmitted, the Session-Sender. If the train is already transmitted, the
duplicate test packet SHOULD be returned to the Session- duplicate test packet SHOULD be returned to the Session-
Sender as quickly as possible. The Session-Reflector MUST Sender as quickly as possible. The Session-Reflector MUST
NOT discard duplicate test packets. NOT discard duplicate test packets.
For any other combinations of the Version field and the L and I For any other combinations of the Version field and the L and I
flags, the Session-Reflector SHOULD return the test packet to the flags, the Session-Reflector SHOULD return the test packet to the
Session-Sender as quickly as possible. Session-Sender as quickly as possible.
The Session-Reflector MUST implement the changes described above when The Session-Reflector MUST implement the changes described above when
the Value-Added Octets Version 1 mode is selected. the Value-Added Octets Version 1 feature is selected.
5.2.1 Session-Reflector Packet Format 5.2.1 Session-Reflector Packet Format
The Session-Reflector packet format follows the same procedure and The Session-Reflector packet format follows the same procedure and
guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and
Symmetrical Size Features [RFC6038], with the following changes: Symmetrical Size Features [RFC6038], with the following changes:
o The Session-Reflector MUST re-use (reflect) the value-added o The Session-Reflector MUST re-use (reflect) the value-added
padding octets (10 octets) provided in the Sender's Packet padding octets (10 octets) provided in the Sender's Packet
Padding. Padding.
skipping to change at page 14, line 32 skipping to change at page 15, line 32
o The Session-Reflector MAY re-use the rest of the padding octets o The Session-Reflector MAY re-use the rest of the padding octets
in the Sender's Packet Padding. in the Sender's Packet Padding.
The truncation process [RFC5357] is recommended when the Symmetrical The truncation process [RFC5357] is recommended when the Symmetrical
mode is not used. The Session-Reflector MUST truncate exactly 27 mode is not used. The Session-Reflector MUST truncate exactly 27
octets of padding in Unauthenticated mode,and exactly 56 octets in octets of padding in Unauthenticated mode,and exactly 56 octets in
Authenticated and Encrypted modes. Authenticated and Encrypted modes.
5.3 Additional Considerations 5.3 Additional Considerations
The Session-Reflector supporting the Value-Added Octets feature
should revert back to the standard Session-Reflector behavior if it
cannot interpret the value-added padding octets in a given test
packet. Section 5.2 also describes such behavior. For instance, the
test packet is returned as quickly as possible to the Session-Sender
when the Last Seqno in the Train is not what is expected.
Capacity measurements introduce an additional consideration when the Capacity measurements introduce an additional consideration when the
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 may not have knowledge of the session state, the measurement system may
be restricted to estimating or calculating the capacity metrics in be restricted to estimating or calculating the capacity metrics in
the forward path direction of transmission only. Capacity the forward path direction of transmission only. Capacity
measurements in the reverse path direction is best handled with a measurements in the reverse path direction is best handled with a
Session-Reflector supporting knowledge of the session state and being Session-Reflector supporting knowledge of the session state and being
capable of identifying the test packets belonging to a specific test capable of identifying the test packets belonging to a specific test
session. A method for creating a session state from the initial test session. A method for creating a session state from the initial test
packet may be implemented on the TWAMP Light Session-Reflector. This packet may be implemented on the TWAMP Light Session-Reflector. This
 End of changes. 21 change blocks. 
58 lines changed or deleted 124 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/