draft-morton-ippm-twamp-rate-03.txt   draft-morton-ippm-twamp-rate-04.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft L. Ciavattone Internet-Draft L. Ciavattone
Updates: 5357 (if approved) AT&T Labs Updates: 5357 (if approved) AT&T Labs
Intended status: Standards Track February 21, 2013 Intended status: Standards Track August 20, 2013
Expires: August 25, 2013 Expires: February 21, 2014
TWAMP Burst Rate Measurement Features TWAMP Burst Rate Measurement Features
draft-morton-ippm-twamp-rate-03 draft-morton-ippm-twamp-rate-04
Abstract Abstract
This memo describes two rate-measurement features for the core This memo describes two rate-measurement features for the core
specification of TWAMP - the Two-Way Active Measurement Protocol: an specification of TWAMP - the Two-Way Active Measurement Protocol: an
optional capability where the reflector host responds with a optional capability where the reflector host responds with a
controlled burst of test-session packets (instead of a single controlled burst of test-session packets (instead of a single
packet), and an optional test mode that requires the responder to packet), and an optional test mode that requires the responder to
measure a burst of test packets and communicate the results in measure a burst of test packets and communicate the results in
truncated packet(s). Both features add the ability to control packet truncated packet(s). Both features add the ability to control packet
size in the tested direction, enabling asymmetrical packet size size in the tested direction, enabling asymmetrical packet size
testing. This draft defines the modes in terms of traditional UDP testing. This draft defines the modes in terms of traditional UDP
test packets. Use TCP transport instead of UDP may be desirable, but test packets. Use of TCP transport instead of UDP may be desirable,
is deferred for future work. but is deferred to other work.
Requirements Language 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].
Status of this Memo Status of This Memo
This Internet-Draft is submitted 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). 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 August 25, 2013. This Internet-Draft will expire on February 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 19 skipping to change at page 2, line 22
(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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Alternate Transport Protocol Selection . . . . . . . . . . 4 1.1. Alternate Transport Protocol Selection . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4
3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 6 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . 5
3.1. Connection Setup with New Features . . . . . . . . . . . . 6 3.1. Connection Setup with New Features . . . . . . . . . . . 5
3.2. Burst Generation: Request-TW-Session Packet Format . . . . 6 3.2. Burst Generation: Request-TW-Session Packet Format . . . 5
3.3. Burst Measurement: Request-TW-Session Packet Format . . . 8 3.3. Burst Measurement: Request-TW-Session Packet Format . . . 7
3.4. Burst Gen and Meas: Accept Session Packet Format . . . . . 9 3.4. Burst Gen and Meas: Accept Session Packet Format . . . . 8
3.5. Burst Gen and Meas: Stopping Test Sessions . . . . . . . . 9 3.5. Burst Gen and Meas: Stopping Test Sessions . . . . . . . 8
3.6. Additional considerations . . . . . . . . . . . . . . . . 9 3.6. Additional considerations . . . . . . . . . . . . . . . . 9
4. Burst Generation in TWAMP Test . . . . . . . . . . . . . . . . 10 4. Burst Generation in TWAMP Test . . . . . . . . . . . . . . . 9
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . 9
4.1.2. Packet Formats and Contents . . . . . . . . . . . . . 10 4.1.2. Packet Formats and Contents . . . . . . . . . . . . . 9
4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 11 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . 10
4.2.1. Session-Reflector Burst Packet Format and Contents . . 11 4.2.1. Session-Reflector Burst Packet Format and Contents . 11
5. Burst Measurement in TWAMP Test . . . . . . . . . . . . . . . 13 5. Burst Measurement in TWAMP Test . . . . . . . . . . . . . . . 12
5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 13 5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . 12
5.1.2. Packet Formats and Contents . . . . . . . . . . . . . 13 5.1.2. Packet Formats and Contents . . . . . . . . . . . . . 12
5.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14 5.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . 13
5.2.1. Session-Reflector Burst Measurement Response 5.2.1. Session-Reflector Burst Measurement Response Packet
Packet Format and Contents . . . . . . . . . . . . . . 15 Format and Contents . . . . . . . . . . . . . . . . . 14
6. Special Case of One-packet Bursts . . . . . . . . . . . . . . 17 6. Special Case of One-packet Bursts . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Registry Specification . . . . . . . . . . . . . . . . . . 17 8.1. Registry Specification . . . . . . . . . . . . . . . . . 16
8.2. Registry Contents . . . . . . . . . . . . . . . . . . . . 18 8.2. Registry Contents . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an
extension of the One-way Active Measurement Protocol, OWAMP extension of the One-way Active Measurement Protocol, OWAMP
[RFC4656]. The TWAMP specification gathered wide review as it was [RFC4656]. The TWAMP specification gathered wide review as it was
deployed, resulting in recommendations for new features. deployed, resulting in recommendations for new features.
This memo describes two closely-related features for TWAMP. When This memo describes two closely-related features for TWAMP. When
measuring packet delivery rate to end-systems, unique control and measuring packet delivery rate to end-systems, unique control and
skipping to change at page 12, line 5 skipping to change at page 11, line 13
of each packet in the burst. of each packet in the burst.
4.2.1. Session-Reflector Burst Packet Format and Contents 4.2.1. Session-Reflector Burst Packet Format and Contents
The Burst Generation feature retains the usual Reflector packet The Burst Generation feature retains the usual Reflector packet
fields, as shown below. When the Burst Generation mode is selected, fields, as shown below. When the Burst Generation mode is selected,
the Session-Reflector SHALL use the following TWAMP-Test Packet the Session-Reflector SHALL use the following TWAMP-Test Packet
Format in Unauthenticated mode (shown with Reflect Octets feature Format in Unauthenticated mode (shown with Reflect Octets feature
activated): activated):
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ | | Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number | | Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ | | Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | Packet Padding (from Session-Sender) | | Sender TTL | Packet Padding (from Session-Sender) |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
. . . .
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| Packet Padding (from Session-Sender) | | | Packet Padding (from Session-Sender) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| | | |
. Additional Packet Padding . . Additional Packet Padding .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.2.1 of [RFC5357] describes the above fields as used in Section 4.2.1 of [RFC5357] describes the above fields as used in
TWAMP, with one exception. TWAMP, with one exception.
The Sequence Number field SHALL indicate the sequence number of each The Sequence Number field SHALL indicate the sequence number of each
packet sent throughout the test session. The Sequence Number SHALL packet sent throughout the test session. The Sequence Number SHALL
be increased by 1 for each packet. The initial Sequence Number SHALL be increased by 1 for each packet. The initial Sequence Number SHALL
be 0. be 0.
When one burst is complete, the Sequence Numbers SHALL continue to When one burst is complete, the Sequence Numbers SHALL continue to
skipping to change at page 14, line 5 skipping to change at page 13, line 9
5.1.2. Packet Formats and Contents 5.1.2. Packet Formats and Contents
The Session-Sender packet format and content SHALL comply with that The Session-Sender packet format and content SHALL comply with that
defined in section 4.1.2 of [RFC4656] (as indicated in section 4.1.2 defined in section 4.1.2 of [RFC4656] (as indicated in section 4.1.2
of TWAMP [RFC5357]). of TWAMP [RFC5357]).
This mode uses the original TWAMP-Test Packet Padding Field (see This mode uses the original TWAMP-Test Packet Padding Field (see
section 4.1.2 of [RFC4656]), or can be used with Reflect Octets section 4.1.2 of [RFC4656]), or can be used with Reflect Octets
feature as shown below for unauthenticated mode: feature as shown below for 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Sequence Number | | Burst Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| Packet Padding (to be reflected) | | Packet Padding (to be reflected) |
. (length in octets specified in command) . . (length in octets specified in command) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Additional Packet Padding . . Additional Packet Padding .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session-Sender Burst Test Packet Format Session-Sender Burst Test Packet Format
The Burst Sequence Number field SHALL indicate the number of each The Burst Sequence Number field SHALL indicate the number of each
burst. The Burst Sequence Number SHALL be increased by 1 for each burst. The Burst Sequence Number SHALL be increased by 1 for each
burst, and remain the same for each packet in a burst. The initial burst, and remain the same for each packet in a burst. The initial
number SHALL be 0. number SHALL be 0.
When one burst is complete, the Burst Sequence Number used in the all When one burst is complete, the Burst Sequence Number used in the all
packets of the next burst SHALL be increased by 1. packets of the next burst SHALL be increased by 1.
skipping to change at page 15, line 18 skipping to change at page 14, line 25
5.2.1. Session-Reflector Burst Measurement Response Packet Format and 5.2.1. Session-Reflector Burst Measurement Response Packet Format and
Contents Contents
The Burst Measurement feature specifies a standard Session-Reflector The Burst Measurement feature specifies a standard Session-Reflector
packet to communicate the results, as shown below. When the Burst packet to communicate the results, as shown below. When the Burst
measurement mode is selected, the Session-Sender SHALL use the measurement mode is selected, the Session-Sender SHALL use the
following Burst Measurement Response packet Format in Unauthenticated following Burst Measurement Response packet Format in Unauthenticated
mode (shown with Reflect Octets feature also in use): mode (shown with Reflect Octets feature also in use):
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ | | Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Burst Sequence Number | | Sender Burst Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp B | Sender Timestamp B
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ | | Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | Packet Padding (from Session-Sender) | | Sender TTL | Packet Padding (from Session-Sender) |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B
Session-Reflector Measurement Packet (1-to-1 response)
Session-Reflector Measurement Packet (1-to-1 response)
Section 4.2.1 of [RFC5357] describes the fields in the 1-to-1 Section 4.2.1 of [RFC5357] describes the fields in the 1-to-1
response packet above; they are the same as used in TWAMP. The main response packet above; they are the same as used in TWAMP. The main
difference is that Packet Padding SHALL be truncated on a 16 octet- difference is that Packet Padding SHALL be truncated on a 16 octet-
word boundary, returning the minimum information to the Session- word boundary, returning the minimum information to the Session-
Sender. Sender.
All Timestamps SHALL be formatted according to the precedent set in All Timestamps SHALL be formatted according to the precedent set in
section 4.1.2 of [RFC4656], which is to use [RFC1305] (and updated section 4.1.2 of [RFC4656], which is to use [RFC1305] (and updated
version), as follows: version), as follows:
skipping to change at page 17, line 44 skipping to change at page 17, line 4
live networks are relevant here as well. See [RFC4656] and live networks are relevant here as well. See [RFC4656] and
[RFC5357]. [RFC5357].
8. IANA Considerations 8. IANA Considerations
This memo adds two modes to the IANA registry for the TWAMP Modes This memo adds two modes to the IANA registry for the TWAMP Modes
Field, and describes behavior when the new modes are used. This Field, and describes behavior when the new modes are used. This
field is a recognized extension mechanism for TWAMP. field is a recognized extension mechanism for TWAMP.
8.1. Registry Specification 8.1. Registry Specification
IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). IANA has created a TWAMP-Modes registry (as requested in [RFC5618]).
TWAMP-Modes are specified in TWAMP Server Greeting messages and TWAMP-Modes are specified in TWAMP Server Greeting messages and Set-
Set-up Response messages, as described in section 3.1 of [RFC5357], up Response messages, as described in section 3.1 of [RFC5357],
consistent with section 3.1 of [RFC4656], and extended by this memo. consistent with section 3.1 of [RFC4656], and extended by this memo.
Modes are indicated by setting bits in the 32-bit Modes field that Modes are indicated by setting bits in the 32-bit Modes field that
correspond to values in the Modes registry. For the TWAMP-Modes correspond to values in the Modes registry. For the TWAMP-Modes
registry, we expect that new features will be assigned increasing registry, we expect that new features will be assigned increasing
registry values that correspond to single bit positions, unless there registry values that correspond to single bit positions, unless there
is a good reason to do otherwise (more complex encoding than single is a good reason to do otherwise (more complex encoding than single
bit positions may be used in the future, to access the 2^32 value bit positions may be used in the future, to access the 2^32 value
space). space).
8.2. Registry Contents 8.2. Registry Contents
skipping to change at page 19, line 24 skipping to change at page 18, line 29
(TWAMP)", RFC 5938, August 2010. (TWAMP)", RFC 5938, August 2010.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, October 2010. Features", RFC 6038, October 2010.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ippm-rate-problem] [I-D.ietf-ippm-rate-problem]
Morton, A., "Rate Measurement Test Protocol Problem Morton, A., "Rate Measurement Test Protocol Problem
Statement", draft-ietf-ippm-rate-problem-02 (work in Statement", draft-ietf-ippm-rate-problem-03 (work in
progress), February 2013. progress), April 2013.
[I-D.morton-ippm-lmap-path] [I-D.morton-ippm-lmap-path]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for A. Morton, "A Reference Path and Measurement Points for
LMAP", draft-morton-ippm-lmap-path-00 (work in progress), LMAP", draft-morton-ippm-lmap-path-01 (work in progress),
January 2013. February 2013.
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
Email: acmorton@att.com Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/ URI: http://home.comcast.net/~acmacm/
Len Ciavattone Len Ciavattone
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1239 Phone: +1 732 420 1239
Fax:
Email: lencia@att.com Email: lencia@att.com
URI:
 End of changes. 17 change blocks. 
122 lines changed or deleted 121 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/