draft-ietf-ippm-twamp-04.txt   draft-ietf-ippm-twamp-05.txt 
K. Hedayat K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: November 2007 R. Krzanowski Expires: May 2008 R. Krzanowski
Verizon Verizon
K. Yum K. Yum
Juniper Networks Juniper Networks
A. Morton A. Morton
AT&T Labs AT&T Labs
J. Babiarz J. Babiarz
Nortel Networks Nortel Networks
November 2007
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-04 draft-ietf-ippm-twamp-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.2 Logical Model.............................................3 1.2 Logical Model.............................................3
2. Protocol Overview.............................................5 2. Protocol Overview.............................................5
3. TWAMP Control.................................................5 3. TWAMP Control.................................................5
3.1 Connection Setup..........................................5 3.1 Connection Setup..........................................5
3.2 Integrity Protection......................................6 3.2 Integrity Protection......................................6
3.3 Value of the Accept Fields................................6 3.3 Value of the Accept Fields................................6
3.4 TWAMP Control Commands....................................6 3.4 TWAMP Control Commands....................................6
3.5 Creating Test Sessions....................................6 3.5 Creating Test Sessions....................................6
3.6 Send Schedules............................................8 3.6 Send Schedules............................................8
3.7 Starting Test Sessions....................................8 3.7 Starting Test Sessions....................................8
3.8 Stop-Sessions.............................................8 3.8 Stop-Sessions.............................................9
3.9 Fetch-Session.............................................8 3.9 Fetch-Session.............................................9
4. TWAMP Test....................................................9 4. TWAMP Test....................................................9
4.1 Sender Behavior...........................................9 4.1 Sender Behavior...........................................9
4.2 Reflector Behavior.......................................10 4.2 Reflector Behavior.......................................10
5. Implementers Guide...........................................15 5. Implementers Guide...........................................16
5.1 Complete TWAMP...........................................15 5.1 Complete TWAMP...........................................17
5.2 TWAMP Light..............................................16 5.2 TWAMP Light..............................................17
6. Security Considerations......................................17 6. Security Considerations......................................18
7. Acknowledgements.............................................17 7. Acknowledgements.............................................18
8. IANA Considerations..........................................17 8. IANA Considerations..........................................19
9. Internationalization Considerations..........................18 9. Internationalization Considerations..........................20
10. References..................................................18 10. References..................................................21
10.1 Normative References....................................18 10.1 Normative References....................................21
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has completed The IETF IP Performance Metrics (IPPM) working group has completed
a draft standard for the round-trip delay [RFC2681] metric. IPPM a draft standard for the round-trip delay [RFC2681] metric. IPPM
has also completed a protocol for the control and collection of has also completed a protocol for the control and collection of
one-way measurements, the One-way Active Measurement Protocol one-way measurements, the One-way Active Measurement Protocol
(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip
or two-way measurements. or two-way measurements.
Two-way measurements are common in IP networks, primarily because Two-way measurements are common in IP networks, primarily because
skipping to change at page 5, line 28 skipping to change at page 5, line 28
Session-Receiver. Session-Receiver.
- Define the Session-Reflector behavior in place of the - Define the Session-Reflector behavior in place of the
Session-Receiver behavior of OWAMP [RFC4656]. Session-Receiver behavior of OWAMP [RFC4656].
- Define a new test packet format for packets transmitted from the - Define a new test packet format for packets transmitted from the
Session-Reflector to Session-Sender. Session-Reflector to Session-Sender.
- Fetch client does not exist in the TWAMP architecture. - Fetch client does not exist in the TWAMP architecture.
All multi-octet quantities defined in this document are represented
as unsigned integers in network byte order unless specified
otherwise.
3. TWAMP Control 3. TWAMP Control
All TWAMP Control messages are similar in format and follow similar TWAMP-Control is a derivative of the OWAMP-Control for two-way
guidelines to those defined in section 3 of OWAMP [RFC4656] with measurements. All TWAMP Control messages are similar in format and
the exceptions outlined in the following sections. All OWAMP follow similar guidelines to those defined in section 3 of OWAMP
[RFC4656] Control messages except for the Fetch-Session command [RFC4656] with the exceptions outlined in the following sections.
apply to TWAMP. All OWAMP [RFC4656] Control messages except for the Fetch-Session
command apply to TWAMP.
3.1 Connection Setup 3.1 Connection Setup
Connection establishment of TWAMP follows the same procedure Connection establishment of TWAMP follows the same procedure
defined in section 3.1 of OWAMP [RFC4656]. The host that initiates defined in section 3.1 of OWAMP [RFC4656]. The mode values are
the TCP connection takes the roles of Control-Client and (in the identical to OWAMP. The only exception is the well-known port
two-host implementation) the Session-Sender. The host that number for TWAMP-control. A client opens a TCP connection to the
acknowledges the TCP connection accepts the roles of Server and (in server on well-known port N (Refer to the IANA Considerations
the two-host implementation) the Session Reflector. section below for the TWAMP-control port number assignment). The
host that initiates the TCP connection takes the roles of Control-
Client and (in the two-host implementation) the Session-Sender.
The host that acknowledges the TCP connection accepts the roles of
Server and (in the two-host implementation) the Session Reflector.
3.2 Integrity Protection 3.2 Integrity Protection
Integrity protection of TWAMP follows the same procedure defined in Integrity protection of TWAMP follows the same procedure defined in
section 3.2 of OWAMP [RFC4656]. section 3.2 of OWAMP [RFC4656].
3.3 Value of the Accept Fields 3.3 Value of the Accept Fields
Accept values used in TWAMP are the same as the values defined in Accept values used in TWAMP are the same as the values defined in
section 3.3 of OWAMP [RFC4656]. section 3.3 of OWAMP [RFC4656].
skipping to change at page 6, line 31 skipping to change at page 6, line 39
3.5 Creating Test Sessions 3.5 Creating Test Sessions
Test sessions creation follows the same procedure as defined in Test sessions creation follows the same procedure as defined in
section 3.5 of OWAMP [RFC4656]. section 3.5 of OWAMP [RFC4656].
In order to distinguish the session as a two-way versus a one-way In order to distinguish the session as a two-way versus a one-way
measurement session the first octet of the Request-Session command measurement session the first octet of the Request-Session command
MUST be set to 5. Value of 5 indicates that this is a MUST be set to 5. Value of 5 indicates that this is a
Request-Session for a two-way metrics measurement session. Request-Session for a two-way metrics measurement session.
In TWAMP, the first octet is referred to as the Command Number, and
the Command Number is a recognized extension mechanism. Readers are
encouraged to consult the TWAMP Command Number Registry to
determine if there have been additional values assigned.
If a TWAMP server receives an unexpected command number, it MUST
respond with the Accept field set to 3 (meaning "Some aspect of
request is not supported") in the Server-Start message.
In OWAMP, the Conf-Sender field is set to 1 when the In OWAMP, the Conf-Sender field is set to 1 when the
Request-Session message describes a task where the Server will Request-Session message describes a task where the Server will
configure a one-way test packet sender. Likewise, the configure a one-way test packet sender. Likewise, the
Conf-Receiver field is set to 1 when the message describes the Conf-Receiver field is set to 1 when the message describes the
configuration for a Session-Receiver. In TWAMP, both endpoints configuration for a Session-Receiver. In TWAMP, both endpoints
perform in these roles, with the Session-Sender first sending and perform in these roles, with the Session-Sender first sending and
then receiving test packets. The Session-Reflector first receives then receiving test packets. The Session-Reflector first receives
the test packets, and returns each test packet to the the test packets, and returns each test packet to the
Session-Sender as fast as possible. Session-Sender as fast as possible.
skipping to change at page 12, line 13 skipping to change at page 13, line 13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated and encrypted modes: For authenticated and encrypted modes:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) | | MBZ (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Sender Sequence Number | | Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | | | Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) | | MBZ (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | | | Sender TTL | |
+++++++++++++++++ | +++++++++++++++++ |
| MBZ (7 octets) |
| | | |
| |
| MBZ (15 octets) |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number is the sequence number of the test packet according Sequence Number is the sequence number of the test packet according
to its arrival at the Session-Reflector. It starts with zero and to its transmit order.It starts with zero and is incremented by one
is incremented by one for each subsequent packet. The Sequence for each subsequent packet. The Sequence Number generated by the
Number generated by the Session-Reflector is independent from the Session-Reflector is independent from the sequence number of the
sequence number of the arriving packets. arriving packets.
Timestamp and Error Estimate are the Session-Reflector's transmit Timestamp and Error Estimate are the Session-Reflector's transmit
timestamp and error estimate for the reflected test packet, timestamp and error estimate for the reflected test packet,
respectively. The format of all timestamp and error estimate respectively. The format of all timestamp and error estimate
fields follow the definition and formats defined by OWAMP[RFC4656]. fields follow the definition and formats defined by OWAMP[RFC4656].
Sender Timestamp and Sender Error Estimate are exact copies of the Sender Timestamp and Sender Error Estimate are exact copies of the
timestamp and error estimate from the Session-Sender test packet timestamp and error estimate from the Session-Sender test packet
that corresponds to this test packet. that corresponds to this test packet.
skipping to change at page 13, line 45 skipping to change at page 14, line 46
Sender Sequence Number is a copy of the Sequence Number of the Sender Sequence Number is a copy of the Sequence Number of the
packet transmitted by the Session-Sender that caused the packet transmitted by the Session-Sender that caused the
Session-Reflector to generate and send this test packet. Session-Reflector to generate and send this test packet.
Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in
authenticated and encrypted modes. The encryption operation of authenticated and encrypted modes. The encryption operation of
Session-Sender packet follow the same rules of Session-Sender Session-Sender packet follow the same rules of Session-Sender
packets as defined in OWAMP [RFC4656]. packets as defined in OWAMP [RFC4656].
The minimum data segment length is, therefore, 40 octets in The minimum data segment length is, therefore, 41 octets in
unauthenticated mode, and 80 octets in both authenticated mode and unauthenticated mode, and 104 octets in both authenticated mode and
encrypted modes (with the implication that the later two modes will encrypted modes (with the implication that the later two modes will
not fit in a single ATM cell). not fit in a single ATM cell).
The Session-Reflector TWAMP-Test packet layout is the same in The Session-Reflector TWAMP-Test packet layout is the same in
authenticated and encrypted modes. The encryption operations are, authenticated and encrypted modes. The encryption operations are,
however, different. The difference is that in encrypted mode both however, different. The difference is that in encrypted mode both
the sequence numbers and timestamps are encrypted to provide the sequence numbers and timestamps are encrypted to provide
maximum data integrity protection while in authenticated mode the maximum data integrity protection while in authenticated mode the
sequence numbers are encrypted and the timestamps are sent in clear sequence numbers are encrypted and the timestamps are sent in clear
text. Sending the timestamp in clear text in authenticated mode text. Sending the timestamp in clear text in authenticated mode
skipping to change at page 15, line 7 skipping to change at page 16, line 10
result is the TWAMP-Test HMAC Session-key to use in authenticating result is the TWAMP-Test HMAC Session-key to use in authenticating
the packets of the particular TWAMP-Test session. Note that all of the packets of the particular TWAMP-Test session. Note that all of
TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are
comprised of 32 octets, while the SID is 16 octets. comprised of 32 octets, while the SID is 16 octets.
ECB mode used for encrypting the first block of TWAMP-Test packets ECB mode used for encrypting the first block of TWAMP-Test packets
in authenticated mode does not involve any actual chaining; this in authenticated mode does not involve any actual chaining; this
way, lost, duplicated, or reordered packets do not cause problems way, lost, duplicated, or reordered packets do not cause problems
with deciphering any packet in an TWAMP-Test session. with deciphering any packet in an TWAMP-Test session.
In encrypted mode, the first two blocks (32 octets) are encrypted In encrypted mode, the first six blocks (96octets) are encrypted
using AES CBC mode. The AES Session-key to use is obtained in the using AES CBC mode. The AES Session-key to use is obtained in the
same way as the key for authenticated mode. Each TWAMP-Test packet same way as the key for authenticated mode. Each TWAMP-Test packet
is encrypted as a separate stream, with just one chaining is encrypted as a separate stream, with just one chaining
operation; chaining does not span multiple packets so that lost, operation; chaining does not span multiple packets so that lost,
duplicated, or reordered packets do not cause problems. The duplicated, or reordered packets do not cause problems. The
initialization vector for the CBC encryption is a value with all initialization vector for the CBC encryption is a value with all
bits equal to zero. bits equal to zero.
Implementation note: Naturally, the key schedule for each Implementation note: Naturally, the key schedule for each
TWAMP-Test session MAY be set up only once per session, not once TWAMP-Test session MAY be set up only once per session, not once
skipping to change at page 16, line 43 skipping to change at page 17, line 46
| Control-Client | | Session-Reflector | | Control-Client | | Session-Reflector |
| Session-Sender |<--TWAMP-Test----->| | | Session-Sender |<--TWAMP-Test----->| |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
This example provides a simple architecture for responders where This example provides a simple architecture for responders where
their role will be to simply act as light test points in the their role will be to simply act as light test points in the
network. The controller establishes the test session with the network. The controller establishes the test session with the
Server through non-standard means. After the session is Server through non-standard means. After the session is
established the controller transmits test packets to the responder. established the controller transmits test packets to the responder.
The responder follows the Session-Reflector behavior of TWAMP as The responder follows the Session-Reflector behavior of TWAMP as
described in section 4.2 with the following exceptions. The described in section 4.2 with the following exceptions.
Session-Reflector SHOULD copy the sequence number of the received
packet to the Sequence Number field of the reflected packet. This In the case of TWAMP Light, the Session-Reflector does not
is necessary since in case of TWAMP Light the Session-Reflector necessarily have knowledge of the session state. IF the
does not necessarily have knowledge of the session state. The Session-Reflector does not have knowledge of the session state,
controller receives the reflected test packets and collects two-way THEN the Session-Reflector MUST copy the Sequence Number of the
metrics. This architecture allows for collection of two-way received packet to the Sequence Number field of the reflected
metrics. packet. The controller receives the reflected test packets and
collects two-way metrics. This architecture allows for collection
of two-way metrics.
This example eliminates the need for the TWAMP-Control protocol and This example eliminates the need for the TWAMP-Control protocol and
assumes that the Session-Reflector is configured and communicates assumes that the Session-Reflector is configured and communicates
its configuration with the Server through non-standard means. The its configuration with the Server through non-standard means. The
Session-Reflector simply reflects the incoming packets back to the Session-Reflector simply reflects the incoming packets back to the
controller while copying the necessary information and generating controller while copying the necessary information and generating
sequence number and timestamp values per section 5.2.1. sequence number and timestamp values per section 4.2.1.
6. Security Considerations 6. Security Considerations
Fundamentally TWAMP and OWAMP use the same protocol for Fundamentally TWAMP and OWAMP use the same protocol for
establishment of Control and Test procedures. The main difference establishment of Control and Test procedures. The main difference
between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
vs. the Session-Receiver behavior in OWAMP. This difference in vs. the Session-Receiver behavior in OWAMP. This difference in
behavior does not introduce any known security vulnerabilities that behavior does not introduce any known security vulnerabilities that
are not already addressed by the security features of OWAMP. The are not already addressed by the security features of OWAMP. The
entire security considerations of OWAMP [RFC4656] applies to TWAMP. entire security considerations of OWAMP [RFC4656] applies to TWAMP.
skipping to change at page 17, line 42 skipping to change at page 18, line 47
authenticated mode of operation. The responder SHOULD be authenticated mode of operation. The responder SHOULD be
configurable to accept only authenticated control sessions. configurable to accept only authenticated control sessions.
The non-standard responder control protocol SHOULD have a means to The non-standard responder control protocol SHOULD have a means to
activate the authenticated and encrypted modes of the TWAMP-Test activate the authenticated and encrypted modes of the TWAMP-Test
protocol. protocol.
7. Acknowledgements 7. Acknowledgements
We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
and Stanislav Shalunov for their comments, suggestions, reviews, Stanislav Shalunov, Matt Zekauskas, Walt Steverson and Jeff Boote
helpful discussion and proof-reading. for their comments, suggestions, reviews, helpful discussion and
proof-reading.
8. IANA Considerations 8. IANA Considerations
IANA has allocated a well-known TCP port number (861) for the IANA has allocated a well-known TCP port number (861) for the
OWAMP-Control part of the OWAMP [RFC4656] protocol which also OWAMP-Control part of the OWAMP [RFC4656] protocol.
applies to the TWAMP-Control part of the TWAMP protocol. ...
owamp-control 861/tcp OWAMP-Control
owamp-control 861/udp OWAMP-Control
# [RFC4656]
# 862-872 Unassigned
IANA is requested to allocate a well-known TCP/UDP port number for
the TWAMP-Control protocol. It would be ideal if the port number
assignment was adjacent to the OWAMP assignment. The recommended
Keyword for this entry is "twamp-control" and the Description is
"Two-way Active Measurement Protocol (TWAMP) Control".
During final editing, port N in section 3.1 should be replaced with
the assigned port number.
Since TWAMP adds an additional Control command to the OWAMP-Control
specification, and describes behavior when this control command is
used, this memo requests creation an IANA registry for the TWAMP
Command Number field. The field is not explicitly named in
[RFC4656] but is called out for each command. This field is a
recognized extension mechanism for TWAMP.
8.1 Registry Specification
IANA will create an TWAMP-Control Command registry. TWAMP-Control
commands are specified by the first octet in OWAMP-Control messages
as shown in section 3.4 of [RFC4656], and modified by this
document. Thus this registry may contain sixteen possible values.
8.2 Registry Management
Because the registry may only contain sixteen values, and because
OWAMP and TWAMP are IETF protocols, this registry must only be
updated by "IETF Consensus" as specified in [RFC2434] -- an RFC
documenting the use that is approved by the IESG. We expect that
new values will be assigned as monotonically increasing integers in
the range [0-15], unless there is a good reason to do otherwise.
8.3 Experimental Numbers
[RFC3692] recommends allocating an appropriate number of values for
experimentation and testing. It is not clear to the authors
exactly how many might be useful in this space, nor if it would be
useful that they were easily distinguishable or at the "high end"
of the number range. Two might be useful, say one for session
control, and one for session fetch. On the other hand, a single
number would allow for unlimited extension, because the format of
the rest of the message could be tailored, with allocation of other
numbers done once usefulness has been proven. Thus, this document
will allocate one number, the next sequential number 6, as
designated for experimentation and testing.
8.4 Initial Registry Contents
TWAMP-Control Command Registry
Value Description Semantics Definition
0 Reserved
1 Forbidden
2 Start-Sessions RFC4656, Section 3.7
3 Stop-Sessions RFC4656, Section 3.8
4 Fetch-Session RFC4656, Section 3.9
5 Request-TW-Session this document, Section 3.5
6 Experimentation undefined, see Section 8.3.
9. Internationalization Considerations 9. Internationalization Considerations
The protocol does not carry any information in a natural language, The protocol does not carry any information in a natural language,
with the possible exception of the KeyID in TWAMP-Control, which is with the possible exception of the KeyID in TWAMP-Control, which is
encoded in UTF-8. encoded in UTF-8.
10. References 10. References
10.1 Normative References 10.1 Normative References
skipping to change at page 18, line 34 skipping to change at page 21, line 25
September 1999. September 1999.
[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.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Definition of the Differentiated Services Field (DS Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
an IANA Considerations Section in RFCs, RFC 2474,
October 1998.
10.2 Informative References
[RFC3692] Narten, T., Assigning Experimental and Testing Numbers
Considered Useful, RFC 3692, January 2004.
Authors' Addresses Authors' Addresses
Kaynam Hedayat Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 Chelmsford, MA 01824
USA USA
EMail: khedayat@brixnet.com EMail: khedayat@brixnet.com
URI: http://www.brixnet.com/ URI: http://www.brixnet.com/
 End of changes. 24 change blocks. 
46 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/