draft-morton-ippm-twamp-rate-02.txt   draft-morton-ippm-twamp-rate-03.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 September 3, 2012 Intended status: Standards Track February 21, 2013
Expires: March 7, 2013 Expires: August 25, 2013
TWAMP Burst Rate Measurement Features TWAMP Burst Rate Measurement Features
draft-morton-ippm-twamp-rate-02 draft-morton-ippm-twamp-rate-03
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. There is an open question on using TCP transport instead of testing. This draft defines the modes in terms of traditional UDP
UDP. test packets. Use TCP transport instead of UDP may be desirable, but
is deferred for future 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
skipping to change at page 1, line 46 skipping to change at page 1, line 47
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 7, 2013. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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. Question on Transport Protocol Selection . . . . . . . . . 4 1.1. Alternate Transport Protocol Selection . . . . . . . . . . 4
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5
3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 6 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 6
3.1. Connection Setup with New Features . . . . . . . . . . . . 6 3.1. Connection Setup with New Features . . . . . . . . . . . . 6
3.2. Burst Generation: Request-TW-Session Packet Format . . . . 6 3.2. Burst Generation: Request-TW-Session Packet Format . . . . 6
3.3. Burst Measurement: Request-TW-Session Packet Format . . . 8 3.3. Burst Measurement: Request-TW-Session Packet Format . . . 8
3.4. Burst Gen and Meas: Accept Session Packet Format . . . . . 9 3.4. Burst Gen and Meas: Accept Session Packet Format . . . . . 9
3.5. Burst Gen and Meas: Stopping Test Sessions . . . . . . . . 9 3.5. Burst Gen and Meas: Stopping Test Sessions . . . . . . . . 9
3.6. Additional considerations . . . . . . . . . . . . . . . . 9 3.6. Additional considerations . . . . . . . . . . . . . . . . 9
4. Burst Generation in TWAMP Test . . . . . . . . . . . . . . . . 10 4. Burst Generation in TWAMP Test . . . . . . . . . . . . . . . . 10
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 4, line 33 skipping to change at page 4, line 33
responder to measure a burst of test packets and communicate the responder to measure a burst of test packets and communicate the
results in a single packet. results in a single packet.
Both features add the ability to control packet size in each Both features add the ability to control packet size in each
direction, enabling asymmetrical packet size testing. Although TWAMP direction, enabling asymmetrical packet size testing. Although TWAMP
[RFC5357] recommends padding truncation to achieve symmetrical sizes [RFC5357] recommends padding truncation to achieve symmetrical sizes
(to compensate for the Session-Reflector's larger test packet (to compensate for the Session-Reflector's larger test packet
header), these features configure test packet sizes when the test header), these features configure test packet sizes when the test
session is requested using the TWAMP-Control protocol. session is requested using the TWAMP-Control protocol.
We note that [draft-baillargeon-ippm-twamp-value-added-octets-01.txt]
addresses a similar measurement problem, but places different
requirements on the reflector host and does not include the
asymmetrical size aspect.
This memo is an update to the TWAMP core protocol specified in This memo is an update to the TWAMP core protocol specified in
[RFC5357]. Measurement systems are not required to implement the [RFC5357]. Measurement systems are not required to implement the
features described in this memo to claim compliance with [RFC5357]. features described in this memo to claim compliance with [RFC5357].
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set
to zero by senders and MUST be ignored by receivers. Also, the HMAC to zero by senders and MUST be ignored by receivers. Also, the HMAC
(Hashed Message Authentication Code) MUST be calculated as defined in (Hashed Message Authentication Code) MUST be calculated as defined in
Section 3.2 of [RFC4656]. Section 3.2 of [RFC4656].
1.1. Question on Transport Protocol Selection 1.1. Alternate Transport Protocol Selection
An open question in the IPPM problem statement draft is whether
testing with TCP transport protocol is a needed capability. The
current TWAMP test protocol capability is limited to UDP transport.
What are the implications of specifying a TWAMP-Test capability with An open question in the IPPM problem statement draft
TCP transport headers, with or without TCP flow control? [I-D.ietf-ippm-rate-problem] is whether testing with TCP transport
protocol is a needed capability. The current TWAMP test protocol
capability is limited to UDP transport.
This is clearly a topic where coordination is required between the This is clearly a topic where coordination is required between the
testing sender and receiver devices. It could be specified as an testing sender and receiver devices. It could be specified as an
independent TWAMP feature, although it is clearly related to the independent TWAMP feature, and although it is clearly related to the
features described here. features described here, the work is deferred to a future memo.
2. Purpose and Scope 2. Purpose and Scope
The purpose of this memo is to define two OPTIONAL closely-related The purpose of this memo is to define two OPTIONAL closely-related
features for TWAMP [RFC5357]. The features enhance the TWAMP features for TWAMP [RFC5357]. The features enhance the TWAMP
responder's capabilities to perform a simple operations on test responder's capabilities to perform a simple operations on test
packets, and the capability to demand asymmetrical size TWAMP-Test packets, and the capability to demand asymmetrical size TWAMP-Test
packets. packets.
This memo is intended to satisfy key requirements contianed in the
IPPM problem statement [I-D.ietf-ippm-rate-problem]. Referring to
the reference path defined in [I-D.morton-ippm-lmap-path], possible
measurement points include a Subscriber's host (mp000), the access
service demarcation point (mp100), Intra IP access where a globally
routable address is present (mp150), or the gateway between the
measured access network and other networks (mp190). The requirements
of this testing environment make it difficult to "correctly" generate
fixed rate packet ensembles. Some of the devices doing the
generation and/or measurement were designed for low-cost-large-scale
deployment and primarily for a purpose other than measurement.
The scope of the memo is limited to specifications of the following The scope of the memo is limited to specifications of the following
features: features:
o Burst Generation: the capability of the Session-Reflector to o Burst Generation: the capability of the Session-Reflector to
generate a burst of packets for return to the Session-Sender, and generate a burst of packets for return to the Session-Sender, and
the corresponding TWAMP-Control messages to activate the the corresponding TWAMP-Control messages to activate the
capability between compliant hosts. capability between compliant hosts.
o Burst Measurement: the capability of the Session-Reflector to o Burst Measurement: the capability of the Session-Reflector to
measure a burst of packets from the Session-Sender, report the key measure a burst of packets from the Session-Sender, report the key
skipping to change at page 16, line 21 skipping to change at page 16, line 21
unless the Reflect Octets feature is also active in which case the unless the Reflect Octets feature is also active in which case the
Session_Reflector MAY re-use the Sender's Packet Padding (since the Session_Reflector MAY re-use the Sender's Packet Padding (since the
requirements for padding generation are the same for each) to reach a requirements for padding generation are the same for each) to reach a
word boundary. word boundary.
The Sender Timestamp field SHALL have the sender's timestamp from The Sender Timestamp field SHALL have the sender's timestamp from
each packet received in the burst. each packet received in the burst.
In 1-to-1 response mode, the Session-Reflector SHALL send a Session- In 1-to-1 response mode, the Session-Reflector SHALL send a Session-
Reflector Measurement Packet in response to every Session-Sender Reflector Measurement Packet in response to every Session-Sender
packet received, and as immediately as possible. packet received, and as quickly as possible.
======================================================== ========================================================
In the accumulated response alternative, the Session-Reflector In the accumulated response alternative, the Session-Reflector
creates and holds all packet headers described above in a buffer, and creates and holds all packet headers described above in a buffer, and
sends them all at once in a single Session-Reflector test packet. sends them all at once in a single Session-Reflector test packet.
The length of the burst and the path MTU MUST be coordinated to avoid The length of the burst and the path MTU MUST be coordinated to avoid
fragmentation. fragmentation.
The first Session-Sender packet to arrive with a previously unseen The first Session-Sender packet to arrive with a previously unseen
skipping to change at page 18, line 32 skipping to change at page 18, line 32
>>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values
The suggested values are The suggested values are
X=7, xxx=128 X=7, xxx=128
Y=8, yyy=256 <<<< Y=8, yyy=256 <<<<
9. Acknowledgements 9. Acknowledgements
The authors thank folks for review and comment. The authors thank Chistofer Flinta for review and comment.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[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.
skipping to change at page 19, line 22 skipping to change at page 19, line 22
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control [RFC5938] Morton, A. and M. Chiba, "Individual Session Control
Feature for the Two-Way Active Measurement Protocol Feature for the Two-Way Active Measurement Protocol
(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]
Morton, A., "Rate Measurement Test Protocol Problem
Statement", draft-ietf-ippm-rate-problem-02 (work in
progress), February 2013.
[I-D.morton-ippm-lmap-path]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for
LMAP", draft-morton-ippm-lmap-path-00 (work in progress),
January 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
 End of changes. 14 change blocks. 
24 lines changed or deleted 41 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/