doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc5357.txt b/doc/rfc/rfc5357.txt
new file mode 100644
index 0000000..0bf8036
--- /dev/null
+++ b/doc/rfc/rfc5357.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                         K. Hedayat
+Request for Comments: 5357                                 Brix Networks
+Category: Standards Track                                  R. Krzanowski
+                                                                 Verizon
+                                                               A. Morton
+                                                               AT&T Labs
+                                                                  K. Yum
+                                                        Juniper Networks
+                                                              J. Babiarz
+                                                         Nortel Networks
+                                                            October 2008
+
+
+             A Two-Way Active Measurement Protocol (TWAMP)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The One-way Active Measurement Protocol (OWAMP), specified in RFC
+   4656, provides a common protocol for measuring one-way metrics
+   between network devices.  OWAMP can be used bi-directionally to
+   measure one-way metrics in both directions between two network
+   elements.  However, it does not accommodate round-trip or two-way
+   measurements.  This memo specifies a Two-Way Active Measurement
+   Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip
+   measurement capabilities.  The TWAMP measurement architecture is
+   usually comprised of two hosts with specific roles, and this allows
+   for some protocol simplifications, making it an attractive
+   alternative in some circumstances.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                     [Page 1]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Relationship of Test and Control Protocols .................3
+      1.2. Logical Model ..............................................3
+      1.3. Pronunciation Guide ........................................4
+   2. Protocol Overview ...............................................5
+   3. TWAMP-Control ...................................................6
+      3.1. Connection Setup ...........................................6
+      3.2. Integrity Protection .......................................7
+      3.3. Values of the Accept Field .................................7
+      3.4. TWAMP-Control Commands .....................................7
+      3.5. Creating Test Sessions .....................................8
+      3.6. Send Schedules ............................................10
+      3.7. Starting Test Sessions ....................................10
+      3.8. Stop-Sessions .............................................10
+      3.9. Fetch-Session .............................................12
+   4. TWAMP-Test .....................................................12
+      4.1. Sender Behavior ...........................................12
+           4.1.1. Packet Timings .....................................12
+           4.1.2. Packet Format and Content ..........................12
+      4.2. Reflector Behavior ........................................13
+           4.2.1. TWAMP-Test Packet Format and Content ...............14
+   5. Implementers' Guide ............................................20
+   6. Security Considerations ........................................20
+   7. Acknowledgements ...............................................21
+   8. IANA Considerations ............................................21
+      8.1. Registry Specification ....................................22
+      8.2. Registry Management .......................................22
+      8.3. Experimental Numbers ......................................22
+      8.4. Initial Registry Contents .................................22
+   9. Internationalization Considerations ............................22
+   Appendix I - TWAMP Light (Informative) ............................23
+   Normative References ..............................................24
+   Informative References ............................................24
+
+1.  Introduction
+
+   The Internet Engineering Task Force (IETF) has completed a Proposed
+   Standard for the round-trip delay [RFC2681] metric.  The IETF has
+   also completed a protocol for the control and collection of one-way
+   measurements, the One-way Active Measurement Protocol (OWAMP)
+   [RFC4656].  However, OWAMP does not accommodate round-trip or two-way
+   measurements.
+
+   Two-way measurements are common in IP networks, primarily because
+   synchronization between local and remote clocks is unnecessary for
+   round-trip delay, and measurement support at the remote end may be
+
+
+
+Hedayat, et al.             Standards Track                     [Page 2]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   limited to a simple echo function.  However, the most common facility
+   for round-trip measurements is the ICMP Echo Request/Reply (used by
+   the ping tool), and issues with this method are documented in Section
+   2.6 of [RFC2681].  This memo specifies the Two-Way Active Measurement
+   Protocol, or TWAMP.  TWAMP uses the methodology and architecture of
+   OWAMP [RFC4656] to define an open protocol for measurement of two-way
+   or round-trip metrics (henceforth in this document the term two-way
+   also signifies round-trip), in addition to the one-way metrics of
+   OWAMP.  TWAMP employs time stamps applied at the echo destination
+   (reflector) to enable greater accuracy (processing delays can be
+   accounted for).  The TWAMP measurement architecture is usually
+   comprised of only two hosts with specific roles, and this allows for
+   some protocol simplifications, making it an attractive alternative to
+   OWAMP in some circumstances.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.1.  Relationship of Test and Control Protocols
+
+   Similar to OWAMP [RFC4656], TWAMP consists of two inter-related
+   protocols: TWAMP-Control and TWAMP-Test.  The relationship of these
+   protocols is as defined in Section 1.1 of OWAMP [RFC4656].  TWAMP-
+   Control is used to initiate, start, and stop test sessions, whereas
+   TWAMP-Test is used to exchange test packets between two TWAMP
+   entities.
+
+1.2.  Logical Model
+
+   The role and definition of the logical entities are as defined in
+   Section 1.2 of OWAMP [RFC4656] with the following exceptions:
+
+   -  The Session-Receiver is called the Session-Reflector in the TWAMP
+      architecture.  The Session-Reflector has the capability to create
+      and send a measurement packet when it receives a measurement
+      packet.  Unlike the Session-Receiver, the Session-Reflector does
+      not collect any packet information.
+
+   -  The Server is an end system that manages one or more TWAMP
+      sessions, and is capable of configuring per-session state in the
+      endpoints.  However, a Server associated with a Session-Reflector
+      would not have the capability to return the results of a test
+      session, and this is a difference from OWAMP.
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                     [Page 3]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   -  The Fetch-Client entity does not exist in the TWAMP architecture,
+      as the Session-Reflector does not collect any packet information
+      to be fetched.  Consequently, there is no need for the Fetch-
+      Client.
+
+   An example of possible relationship scenarios between these roles is
+   presented below.  In this example, different logical roles are played
+   on different hosts.  Unlabeled links in the figure are unspecified by
+   this document and may be proprietary protocols.
+
+         +----------------+               +-------------------+
+         | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
+         +----------------+               +-------------------+
+           ^                                     ^
+           |                                     |
+           |                                     |
+           |                                     |
+           |  +----------------+<----------------+
+           |  |     Server     |
+           |  +----------------+
+           |    ^
+           |    |
+           | TWAMP-Control
+           |    |
+           v    v
+         +----------------+
+         | Control-Client |
+         +----------------+
+
+   As in OWAMP [RFC4656], different logical roles can be played by the
+   same host.  For example, in the figure above, there could actually be
+   two hosts: one playing the roles of Control-Client and Session-
+   Sender, and the other playing the roles of Server and Session-
+   Reflector.  This example is shown below.
+
+          +-----------------+                   +-------------------+
+          | Control-Client  |<--TWAMP-Control-->|      Server       |
+          |                 |                   |                   |
+          | Session-Sender  |<--TWAMP-Test----->| Session-Reflector |
+          +-----------------+                   +-------------------+
+
+1.3.  Pronunciation Guide
+
+   The acronym OWAMP is usually pronounced in two syllables, Oh-wamp.
+
+   The acronym TWAMP is also pronounced in two syllables, Tee-wamp.
+
+
+
+
+
+Hedayat, et al.             Standards Track                     [Page 4]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+2.  Protocol Overview
+
+   The Two-Way Active Measurement Protocol is an open protocol for
+   measurement of two-way metrics.  It is based on OWAMP [RFC4656] and
+   adheres to OWAMP's overall architecture and design.  The TWAMP-
+   Control and TWAMP-Test protocols accomplish their testing tasks as
+   outlined below:
+
+   -  The Control-Client initiates a TCP connection on TWAMP's well-
+      known port, and the Server (its role now established) responds
+      with its Greeting message, indicating the security/integrity
+      mode(s) it is willing to support.
+
+   -  The Control-Client responds with the chosen mode of communication
+      and information supporting integrity protection and encryption, if
+      the mode requires them.  The Server responds to accept the mode
+      and give its start time.  This completes the control-connection
+      setup.
+
+   -  The Control-Client requests (and describes) a test session with a
+      unique TWAMP-Control message.  The Server responds with its
+      acceptance and supporting information.  More than one test session
+      may be requested with additional messages.
+
+   -  The Control-Client initiates all requested testing with a Start-
+      Sessions message, and the Server acknowledges.
+
+   -  The Session-Sender and the Session-Reflector exchange test packets
+      according to the TWAMP-Test protocol for each active session.
+
+   -  When appropriate, the Control-Client sends a message to stop all
+      test sessions.
+
+   There are two recognized extension mechanisms in the TWAMP Protocol.
+
+   1) The Modes field is used to establish the communication options
+      during TWAMP-Control Connection Setup.
+
+   2) The TWAMP-Control Command Number is another intended extension
+      mechanism, allowing additional commands to be defined in the
+      future.
+
+   The TWAMP-Control protocol resolves different capability levels
+   between the Control-Client and Server.
+
+   All multi-octet quantities defined in this document are represented
+   as unsigned integers in network byte order, unless specified
+   otherwise.
+
+
+
+Hedayat, et al.             Standards Track                     [Page 5]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set
+   to zero by senders and MUST be ignored by receivers.
+
+3.  TWAMP-Control
+
+   TWAMP-Control is a derivative of the OWAMP-Control for two-way
+   measurements.  All TWAMP-Control messages are similar in format and
+   follow similar guidelines to those defined in Section 3 of OWAMP
+   [RFC4656] with the exceptions outlined in the following sections.
+   One such exception is the Fetch-Session command, which is not used in
+   TWAMP.
+
+3.1.  Connection Setup
+
+   Connection establishment of TWAMP follows the same procedure defined
+   in Section 3.1 of OWAMP [RFC4656].  The Modes field is a recognized
+   extension mechanism in TWAMP, and the current mode values are
+   identical to those used in OWAMP.  The only exception is the well-
+   known port number for TWAMP-Control.  A Client opens a TCP connection
+   to the Server on well-known port 862.  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.
+
+   The Control-Client MAY set a desired code point in the Diffserv Code
+   Point (DSCP) field in the IP header for ALL packets of a specific
+   control connection.  The Server SHOULD use the DSCP of the Control-
+   Client's TCP SYN in ALL subsequent packets on that connection
+   (avoiding any ambiguity in case of re-marking).
+
+   The possibility exists for Control-Client failure after TWAMP-
+   Control connection establishment, or the path between the Control-
+   Client and Server may fail while a connection is in progress.  The
+   Server MAY discontinue any established control connection when no
+   packet associated with that connection has been received within
+   SERVWAIT seconds.  The Server SHALL suspend monitoring control
+   connection activity after receiving a Start-Sessions command, and
+   SHALL resume after receiving a Stop-Sessions command (IF the SERVWAIT
+   option is supported).  Note that the REFWAIT timeout (described
+   below) covers failures during test sessions, and if REFWAIT expires
+   on ALL test sessions initiated by a TWAMP-Control connection, then
+   the SERVWAIT monitoring SHALL resume (as though a Stop-Sessions
+   command had been received).  An implementation that supports the
+   SERVWAIT timeout SHOULD also implement the REFWAIT timeout.  The
+   default value of SERVWAIT SHALL be 900 seconds, and this waiting time
+   MAY be configurable.  This timeout allows the Server to free up
+   resources in case of failure.
+
+
+
+Hedayat, et al.             Standards Track                     [Page 6]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   Both the Server and the Client use the same mappings from KeyIDs to
+   shared secrets.  The Server, being prepared to conduct sessions with
+   more than one Client, uses KeyIDs to choose the appropriate secret
+   key; a Client would typically have different secret keys for
+   different Servers.  The shared secret is a passphrase.  To maximize
+   passphrase interoperability, the passphrase character set MUST be
+   encoded using Appendix B of [RFC5198] (the ASCII Network Virtual
+   Terminal Definition).  It MUST not contain newlines (any combination
+   of Carriage-Return (CR) and/or Line-Feed (LF) characters), and
+   control characters SHOULD be avoided.
+
+3.2.  Integrity Protection
+
+   Integrity protection of TWAMP follows the same procedure defined in
+   Section 3.2 of OWAMP [RFC4656].  As in OWAMP, each HMAC (Hashed
+   Message Authentication Code) sent covers everything sent in a given
+   direction between the previous HMAC (but not including it) and the
+   start of the new HMAC.  This way, once encryption is set up, each bit
+   of the TWAMP-Control connection is authenticated by an HMAC exactly
+   once.
+
+   Note that the Server-Start message (sent by a Server during the
+   initial control-connection exchanges) does not terminate with an HMAC
+   field.  Therefore, the HMAC in the first Accept-Session message also
+   covers the Server-Start message and includes the Start-Time field in
+   the HMAC calculation.
+
+   Also, in authenticated and encrypted modes, the HMAC in TWAMP-Control
+   packets is encrypted.
+
+3.3.  Values of the Accept Field
+
+   Accept values used in TWAMP are the same as the values defined in
+   Section 3.3 of OWAMP [RFC4656].
+
+3.4.  TWAMP-Control Commands
+
+   TWAMP-Control commands conform to the rules defined in Section 3.4 of
+   OWAMP [RFC4656].
+
+   The following commands are available for the Control-Client:
+   Request-TW-Session, Start-Sessions, and Stop-Sessions.  The Server
+   can send specific messages in response to the commands it receives
+   (as described in the sections that follow).
+
+   Note that the OWAMP Request-Session command is replaced by the TWAMP
+   Request-TW-Session command, and the Fetch-Session command does not
+   appear in TWAMP.
+
+
+
+Hedayat, et al.             Standards Track                     [Page 7]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+3.5.  Creating Test Sessions
+
+   Test session creation follows the same procedure as defined in
+   Section 3.5 of OWAMP [RFC4656].  The Request-TW-Session command is
+   based on the OWAMP Request-Session command, and uses the message
+   format as described in Section 3.5 of OWAMP, but without the Schedule
+   Slot Descriptions field(s) and uses only one HMAC.  The description
+   of the Request-TW-Session format follows.
+
+   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-Control Command Number registry to
+   determine if there have been additional values assigned.
+
+   The Command Number value of 5 indicates a Request-TW-Session command,
+   and the Server MUST interpret this command as a request for a two-way
+   test session using the TWAMP-Test protocol.
+
+   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 Accept-Session message.  Command
+   Numbers that are Forbidden (and possibly numbers that are Reserved)
+   are unexpected.
+
+   In OWAMP, the Conf-Sender field is set to 1 when the Request-Session
+   message describes a task where the Server will configure a one-way
+   test packet sender.  Likewise, the Conf-Receiver field is set to 1
+   when the message describes the configuration for a Session-Receiver.
+   In TWAMP, both endpoints send and receive test packets, with the
+   Session-Sender first sending and then receiving test packets,
+   complimented by the Session-Reflector first receiving and then
+   sending.
+
+   Both the Conf-Sender field and Conf-Receiver field MUST be set to 0
+   since the Session-Reflector will both receive and send packets, and
+   the roles are established according to which host initiates the TCP
+   connection for control.  The Server MUST interpret any non-zero value
+   as an improperly formatted command, and MUST respond with the Accept
+   field set to 3 (meaning "Some aspect of request is not supported") in
+   the Accept-Session message.
+
+   The Session-Reflector in TWAMP does not process incoming test packets
+   for performance metrics and consequently does not need to know the
+   number of incoming packets and their timing schedule.  Consequently
+   the Number of Scheduled Slots and Number of Packets MUST be set to 0.
+
+   The Sender Port is the UDP port from which TWAMP-Test packets will be
+   sent and the port to which TWAMP-Test packets will be sent by the
+
+
+
+Hedayat, et al.             Standards Track                     [Page 8]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   Session-Reflector (the Session-Sender will use the same UDP port to
+   send and receive packets).  The Receiver Port is the desired UDP port
+   to which TWAMP-Test packets will be sent by the Session-Sender (the
+   port where the Session-Reflector is asked to receive test packets).
+   The Receiver Port is also the UDP port from which TWAMP-Test packets
+   will be sent by the Session-Reflector (the Session-Reflector will use
+   the same UDP port to send and receive packets).
+
+   The Sender Address and Receiver Address fields contain, respectively,
+   the sender and receiver addresses of the endpoints of the Internet
+   path over which a TWAMP-Test session is requested.  They MAY be set
+   to 0, in which case the IP addresses used for the Control-Client to
+   Server TWAMP-Control message exchange MUST be used in the test
+   packets.
+
+   The Session Identifier (SID) is as defined in OWAMP [RFC4656].  Since
+   the SID is always generated by the receiving side, the Server
+   determines the SID, and the SID in the Request-TW-Session message
+   MUST be set to 0.
+
+   The Start Time is as defined in OWAMP [RFC4656].
+
+   The Timeout is interpreted differently from the definition in OWAMP
+   [RFC4656].  In TWAMP, Timeout is the interval that the Session-
+   Reflector MUST wait after receiving a Stop-Sessions message.  In case
+   there are test packets still in transit, the Session-Reflector MUST
+   reflect them if they arrive within the Timeout interval following the
+   reception of the Stop-Sessions message.  The Session-Reflector MUST
+   NOT reflect packets that are received beyond the timeout.
+
+   Type-P descriptor is as defined in OWAMP [RFC4656].  The only
+   capability of this field is to set the Differentiated Services Code
+   Point (DSCP) as defined in [RFC2474].  The same value of DSCP MUST be
+   used in test packets reflected by the Session-Reflector.
+
+   Since there are no Schedule Slot Descriptions, the Request-TW-Session
+   message is completed by MBZ (Must Be Zero) and HMAC fields.  This
+   completes one logical message, referred to as the Request-TW-Session
+   command.
+
+   The Session-Reflector MUST respond to each Request-TW-Session command
+   with an Accept-Session message as defined in OWAMP [RFC4656].  When
+   the Accept field = 0, the Port field confirms (repeats) the port to
+   which TWAMP-Test packets are sent by the Session-Sender toward the
+   Session-Reflector.  In other words, the Port field indicates the port
+   number where the Session-Reflector expects to receive packets from
+   the Session-Sender.
+
+
+
+
+Hedayat, et al.             Standards Track                     [Page 9]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   When the requested Receiver Port is not available (e.g., port in
+   use), the Server at the Session-Reflector MAY suggest an alternate
+   and available port for this session in the Port field.  The Session-
+   Sender either accepts the alternate port, or composes a new Session-
+   Request message with suitable parameters.  Otherwise, the Server at
+   the Control-Client uses the Accept field to convey other forms of
+   session rejection or failure and MUST NOT suggest an alternate port;
+   in this case, the Port field MUST be set to zero.
+
+3.6.  Send Schedules
+
+   The send schedule for test packets defined in Section 3.6 of OWAMP
+   [RFC4656] is not used in TWAMP.  The Control-Client and Session-
+   Sender MAY autonomously decide the send schedule.  The Session-
+   Reflector SHOULD return each test packet to the Session-Sender as
+   quickly as possible.
+
+3.7.  Starting Test Sessions
+
+   The procedure and guidelines for starting test sessions is the same
+   as defined in Section 3.7 of OWAMP [RFC4656].
+
+3.8.  Stop-Sessions
+
+   The procedure and guidelines for stopping test sessions is similar to
+   that defined in Section 3.8 of OWAMP [RFC4656].  The Stop-Sessions
+   command can only be issued by the Control-Client.  The message MUST
+   NOT contain any session description records or skip ranges.  The
+   message is terminated with a single block HMAC to complete the Stop-
+   Sessions command.  Since the TWAMP Stop-Sessions command does not
+   convey SIDs, it applies to all sessions previously requested and
+   started with a Start-Sessions command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 10]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   Thus, the TWAMP Stop-Sessions command is constructed as follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      3        |    Accept     |              MBZ              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Number of Sessions                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        MBZ (8 octets)                         |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                       HMAC (16 octets)                        |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Above, the Command Number in the first octet (3) indicates that this
+   is the Stop-Sessions command.
+
+   Non-zero Accept values indicate a failure of some sort.  Zero values
+   indicate normal (but possibly premature) completion.  The full list
+   of available Accept values is described in Section 3.3 of [RFC4656],
+   "Values of the Accept Field".
+
+   If Accept has a non-zero value, results of all TWAMP-Test sessions
+   spawned by this TWAMP-Control session SHOULD be considered invalid.
+   If the Accept-Session message was not transmitted at all (for
+   whatever reason, including failure of the TCP connection used for
+   TWAMP-Control), the results of all TWAMP-Test sessions spawned by
+   this TWAMP-Control session MAY be considered invalid.
+
+   Number of Sessions indicates the number of sessions that the
+   Control-Client intends to stop.
+
+   Number of Sessions MUST contain the number of send sessions started
+   by the Control-Client that have not been previously terminated by a
+   Stop-Sessions command (i.e., the Control-Client MUST account for each
+   accepted Request-Session).  If the Stop-Sessions message does not
+   account for exactly the number of sessions in progress, then it is to
+   be considered invalid, the TWAMP-Control connection SHOULD be closed,
+   and any results obtained considered invalid.
+
+   Upon receipt of a TWAMP-Control Stop-Sessions command, the Session-
+   Reflector MUST discard any TWAMP-Test packets that arrive at the
+   current time plus the Timeout (in the Request-TW-Session command).
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 11]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+3.9.  Fetch-Session
+
+   One purpose of TWAMP is measurement of two-way metrics.  Two-way
+   measurement methods do not require packet-level data to be collected
+   by the Session-Reflector (such as sequence number, timestamp, and
+   Time to Live (TTL)) because this data is communicated in the
+   "reflected" test packets.  As such, the protocol does not require the
+   retrieval of packet-level data from the Server and the OWAMP Fetch-
+   Session command is not used in TWAMP.
+
+4.  TWAMP-Test
+
+   The TWAMP-Test protocol is similar to the OWAMP-test protocol
+   [RFC4656] with the exception that the Session-Reflector transmits
+   test packets to the Session-Sender in response to each test packet it
+   receives.  TWAMP defines two different test packet formats, one for
+   packets transmitted by the Session-Sender and one for packets
+   transmitted by the Session-Reflector.  As with OWAMP-test protocol
+   [RFC4656], there are three modes: unauthenticated, authenticated, and
+   encrypted.
+
+4.1.  Sender Behavior
+
+   The sender behavior is determined by the configuration of the
+   Session-Sender and is not defined in this standard.  Further, the
+   Session-Reflector does not need to know the Session-Sender behavior
+   to the degree of detail as needed in OWAMP [RFC4656].  Additionally,
+   the Session-Sender collects and records the necessary information
+   provided from the packets transmitted by the Session-Reflector for
+   measuring two-way metrics.  The information recording based on the
+   packet(s) received by the Session-Sender is implementation dependent.
+
+4.1.1.  Packet Timings
+
+   Since the send schedule is not communicated to the Session-Reflector,
+   there is no need for a standardized computation of packet timing.
+
+   Regardless of any scheduling delays, each packet that is actually
+   sent MUST have the best possible approximation of its real time of
+   departure as its timestamp (in the packet).
+
+4.1.2.  Packet Format and Content
+
+   The Session-Sender packet format and content follow the same
+   procedure and guidelines as defined in Section 4.1.2 of OWAMP
+   [RFC4656] (with the exception of the reference to the send schedule).
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 12]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   Note that the Reflector test packet formats are larger than the
+   Sender's formats.  The Session-Sender MAY append sufficient Packet
+   Padding to allow the same IP packet payload lengths to be used in
+   each direction of transmission (this is usually desirable).  To
+   compensate for the Reflector's larger test packet format, the Sender
+   appends at least 27 octets of padding in unauthenticated mode, and at
+   least 56 octets in authenticated and encrypted modes.
+
+4.2.  Reflector Behavior
+
+   TWAMP requires the Session-Reflector to transmit a packet to the
+   Session-Sender in response to each packet it receives.
+
+   As packets are received, the Session-Reflector will do the following:
+
+   -  Timestamp the received packet.  Each packet that is actually
+      received MUST have the best possible approximation of its real
+      time of arrival entered as its Received Timestamp (in the packet).
+
+   -  In authenticated or encrypted mode, decrypt the appropriate
+      sections of the packet body (first block (16 octets) for
+      authenticated, 96 octets for encrypted), and then check integrity
+      of sections covered by the HMAC.
+
+   -  Copy the packet sequence number into the corresponding reflected
+      packet to the Session-Sender.
+
+   -  Extract the Sender TTL value from the TTL/Hop Limit value of
+      received packets.  Session-Reflector implementations SHOULD fetch
+      the TTL/Hop Limit value from the IP header of the packet,
+      replacing the value of 255 set by the Session-Sender.  If an
+      implementation does not fetch the actual TTL value (the only good
+      reason not to do so is an inability to access the TTL field of
+      arriving packets), it MUST set the Sender TTL value as 255.
+
+   -  In authenticated and encrypted modes, the HMAC MUST be calculated
+      first, then the appropriate portion of the packet body is
+      encrypted.
+
+   -  Transmit a test packet to the Session-Sender in response to every
+      received packet.  The response MUST be generated as immediately as
+      possible.  The format and content of the test packet is defined in
+      Section 4.2.1.  Prior to the transmission of the test packet, the
+      Session-Reflector MUST enter the best possible approximation of
+      its actual sending time as its Timestamp (in the packet).  This
+      permits the determination of the elapsed time between the
+      reception of the packet and its transmission.
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 13]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   -  Packets not received within the Timeout (following the Stop-
+      Sessions command) MUST be ignored by the Reflector.  The Session-
+      Reflector MUST NOT generate a test packet to the Session-Sender
+      for packets that are ignored.
+
+   The possibility exists for Session-Sender failure during a session,
+   or the path between the Session-Sender and Session-Reflector may fail
+   while a test session is in progress.  The Session-Reflector MAY
+   discontinue any session that has been started when no packet
+   associated with that session has been received for REFWAIT seconds.
+   The default value of REFWAIT SHALL be 900 seconds, and this waiting
+   time MAY be configurable.  This timeout allows a Session-Reflector to
+   free up resources in case of failure.
+
+4.2.1.  TWAMP-Test Packet Format and Content
+
+   The Session-Reflector MUST transmit a packet to the Session-Sender in
+   response to each packet received.  The Session-Reflector SHOULD
+   transmit the packets as immediately as possible.  The Session-
+   Reflector SHOULD set the TTL in IPv4 (or Hop Limit in IPv6) in the
+   UDP packet to 255.
+
+   The test packet will have the necessary information for calculating
+   two-way metrics by the Session-Sender.  The format of the test packet
+   depends on the mode being used.  The two formats are presented below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 14]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   For unauthenticated mode:
+
+   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Timestamp                            |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Error Estimate        |           MBZ                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Receive Timestamp                    |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sender Sequence Number                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Sender Timestamp                         |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Sender Error Estimate    |           MBZ                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Sender TTL   |                                               |
+   +-+-+-+-+-+-+-+-+                                               +
+   |                                                               |
+   .                                                               .
+   .                         Packet Padding                        .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 15]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   For authenticated and encrypted modes:
+
+   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        MBZ (12 octets)                        |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Timestamp                            |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Error Estimate        |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+   |                        MBZ (6 octets)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Receive Timestamp                      |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        MBZ (8 octets)                         |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sender Sequence Number                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        MBZ (12 octets)                        |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Sender Timestamp                         |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Sender Error Estimate    |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+   |                        MBZ (6 octets)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Sender TTL   |                                               |
+   +-+-+-+-+-+-+-+-+                                               +
+   |                                                               |
+   |                                                               |
+   |                        MBZ (15 octets)                        |
+   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+   |                        HMAC (16 octets)                       |
+   |                                                               |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+
+
+Hedayat, et al.             Standards Track                    [Page 16]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   |                                                               |
+   .                                                               .
+   .                         Packet Padding                        .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Note that all timestamps have the same format as OWAMP [RFC4656] as
+   follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Integer part of seconds                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Fractional part of seconds                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Sequence Number is the sequence number of the test packet according
+   to its transmit order.  It starts with zero and is incremented by one
+   for each subsequent packet.  The Sequence Number generated by the
+   Session-Reflector is independent from the sequence number of the
+   arriving packets.
+
+   Timestamp and Error Estimate are the Session-Reflector's transmit
+   timestamp and error estimate for the reflected test packet,
+   respectively.  The format of all timestamp and error estimate fields
+   follow the definition and formats defined by OWAMP, Section 4.1.2 in
+   [RFC4656].
+
+   Sender Timestamp and Sender Error Estimate are exact copies of the
+   timestamp and error estimate from the Session-Sender test packet that
+   corresponds to this test packet.
+
+   Sender TTL is 255 when transmitted by the Session-Sender.  Sender TTL
+   is set to the Time To Live (or Hop Count) value of the received
+   packet from the IP packet header when transmitted by the Session-
+   Reflector.
+
+   Receive Timestamp is the time the test packet was received by the
+   reflector.  The difference between Timestamp and Receive Timestamp is
+   the amount of time the packet was in transition in the Session-
+   Reflector.  The Error Estimate associated with the Timestamp field
+   also applies to the Receive Timestamp.
+
+   Sender Sequence Number is a copy of the Sequence Number of the packet
+   transmitted by the Session-Sender that caused the Session-Reflector
+   to generate and send this test packet.
+
+
+
+Hedayat, et al.             Standards Track                    [Page 17]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   The HMAC field in TWAMP-Test packets covers the same fields as the
+   Advanced Encryption Standard (AES) encryption.  Thus, in
+   authenticated mode, HMAC covers the first block (16 octets); in
+   encrypted mode, HMAC covers the first six blocks (96 octets).  In
+   TWAMP-Test, the HMAC field MUST NOT be encrypted.
+
+   Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
+   generated independently of any other pseudo-random numbers mentioned
+   in this document).  However, implementations MUST provide a
+   configuration parameter, an option, or a different means of making
+   Packet Padding consist of all zeros.  Packet Padding MUST NOT be
+   covered by the HMAC and MUST NOT be encrypted.
+
+   The minimum data segment length of TWAMP-Test packets in
+   unauthenticated mode is 41 octets, and 104 octets in both
+   authenticated mode and encrypted modes.
+
+   Note that the Session-Reflector Test packet formats are larger than
+   the Sender's formats.  The Session-Reflector SHOULD reduce the length
+   of the Sender's Packet Padding to achieve equal IP packet payload
+   lengths in each direction of transmission, when sufficient padding is
+   present.  The Session-Reflector MAY re-use the Sender's Packet
+   Padding (since the requirements for padding generation are the same
+   for each), and in this case the Session-Reflector SHOULD truncate the
+   padding such that the highest-number octets are discarded.
+
+   In unauthenticated mode, encryption or authentication MUST NOT be
+   applied.
+
+   The TWAMP-Test packet layout is identical in authenticated and
+   encrypted modes.  The encryption operation for a Session-Sender
+   packet follows the same rules of Session-Sender packets as defined in
+   OWAMP section 4.1.2 of [RFC4656].
+
+   The main difference between authenticated mode and encrypted mode is
+   the portion of the test packets that are covered by HMAC and
+   encrypted.  Authenticated mode permits the timestamp to be fetched
+   after a portion of the packet is encrypted, but in encrypted mode all
+   the sequence numbers and timestamps are fetched before encryption to
+   provide maximum data-integrity protection.
+
+   In authenticated mode, only the sequence number in the first block is
+   encrypted, and the subsequent timestamps and sequence numbers are
+   sent in clear text.  Sending the timestamp in clear text allows one
+   to reduce the time between when a timestamp is obtained by a
+   Session-Reflector and when that packet is sent out.  This potentially
+   improves the timestamp accuracy, because the sequence number can be
+   encrypted before the timestamp is fetched.
+
+
+
+Hedayat, et al.             Standards Track                    [Page 18]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   In encrypted mode, the reflector MUST fetch the timestamps, generate
+   the HMAC, and encrypt the packet, then send it.
+
+   Obtaining the keys and encryption methods follows the same procedure
+   as OWAMP as described below.  Each TWAMP-Test session has two keys,
+   an AES Session-key and an HMAC Session-key, and the keys are derived
+   from the TWAMP-Control keys and the SID.
+
+   The TWAMP-Test AES Session-key is obtained as follows: the TWAMP-
+   Control AES Session-key (the same AES Session-key as used for the
+   corresponding TWAMP-Control session) is encrypted with the 16-octet
+   session identifier (SID) as the key, using a single-block AES-ECB
+   encryption.  The result is the TWAMP-Test AES Session-key to be used
+   in encrypting (and decrypting) the packets of the particular TWAMP-
+   Test session.  Note that the TWAMP-Test AES Session-key, TWAMP-
+   Control AES Session-key, and the SID are all comprised of 16 octets.
+
+   The TWAMP-Test HMAC Session-key is obtained as follows: the TWAMP-
+   Control HMAC Session-key (the same HMAC Session-key as used for the
+   corresponding TWAMP-Control session) is encrypted using AES-CBC
+   (Cipher Block Chaining) with the 16-octet session identifier (SID) as
+   the key.  This is a two-block CBC encryption that is always performed
+   with IV=0.  Note that the TWAMP-Test HMAC Session-key and TWAMP-
+   Control HMAC Session-key are comprised of 32 octets, while the SID is
+   16 octets.
+
+   In authenticated mode, the first block (16 octets) of each TWAMP-Test
+   packet is encrypted using the AES Electronic Codebook (ECB) mode.
+   This mode does not involve any chaining, and lost, duplicated, or
+   reordered packets do not cause problems with deciphering any packet
+   in a TWAMP-Test session.
+
+   In encrypted mode, the first six blocks (96 octets) are encrypted
+   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
+   is encrypted as a separate stream, with just one chaining operation;
+   chaining does not span multiple packets so that lost, duplicated, or
+   reordered packets do not cause problems.  The initialization vector
+   for the CBC encryption is a value with all bits equal to zero.
+
+   Implementation Note: Naturally, the key schedule for each TWAMP-Test
+   session MUST be set up at most once per session, not once per packet.
+
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 19]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+5.  Implementers' Guide
+
+   This section serves as guidance to implementers of TWAMP.  The
+   example architecture presented here is not a requirement.  Similar to
+   OWAMP [RFC4656], TWAMP is designed with enough flexibility to allow
+   different architectures that suit multiple system requirements.
+
+   In this example, the roles of Control-Client and Session-Sender are
+   implemented in one host referred to as the controller, and the roles
+   of Server and Session-Reflector are implemented in another host
+   referred to as the responder.
+
+              controller                              responder
+          +-----------------+                   +-------------------+
+          | Control-Client  |<--TWAMP-Control-->| Server            |
+          |                 |                   |                   |
+          | Session-Sender  |<--TWAMP-Test----->| Session-Reflector |
+          +-----------------+                   +-------------------+
+
+   This example provides an architecture that supports the full TWAMP
+   standard.  The controller establishes the test session with the
+   responder through the TWAMP-Control protocol.  After the session is
+   established, the controller transmits test packets to the responder.
+   The responder follows the Session-Reflector behavior of TWAMP as
+   described in Section 4.2.
+
+   Appendix I provides an example for purely informational purposes.  It
+   suggests an incremental path to adopting TWAMP, by implementing the
+   TWAMP-Test protocol first.
+
+6.  Security Considerations
+
+   Fundamentally, TWAMP and OWAMP use the same protocol for
+   establishment of Control and Test procedures.  The main difference
+   between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
+   vs. the Session-Receiver behavior in OWAMP.  This difference in
+   behavior does not introduce any known security vulnerabilities that
+   are not already addressed by the security features of OWAMP.  The
+   entire security considerations of OWAMP [RFC4656] applies to TWAMP.
+
+   The Server-Greeting message (defined in OWAMP, Section 3.1 of
+   [RFC4656]) includes a Count field to specify the iteration counter
+   used in PKCS #5 to generate keys from shared secrets.  OWAMP
+   recommends a lower limit of 1024 iterations, but no upper limit.  The
+   Count field provides an opportunity for a denial-of-service (DOS)
+   attack because it is 32 bits long.  If an attacking system set the
+   maximum value in Count (2**32), then the system under attack would
+   stall for a significant period of time while it attempts to generate
+
+
+
+Hedayat, et al.             Standards Track                    [Page 20]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   keys.  Therefore, TWAMP-compliant systems SHOULD have a configuration
+   control to limit the maximum Count value.  The default maximum Count
+   value SHOULD be 32768.  As suggested in OWAMP, this value MAY be
+   increased when greater computing power becomes common.  If a
+   Control-Client receives a Server-Greeting message with Count greater
+   that its maximum configured value, it SHOULD close the control
+   connection.
+
+7.  Acknowledgements
+
+   We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
+   Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote,
+   Murtaza Chiba, and Kevin Earnst for their comments, suggestions,
+   reviews, helpful discussion, and proof-reading.  Lars Eggert, Sam
+   Hartman, and Tim Polk contributed very useful AD-level reviews, and
+   the authors thank them for their contributions to the memo.
+
+8.  IANA Considerations
+
+   IANA has allocated a well-known TCP port number (861) for the OWAMP-
+   Control part of the OWAMP [RFC4656] protocol.
+
+   ...
+   owamp-control   861/tcp    OWAMP-Control
+   owamp-control   861/udp    OWAMP-Control
+   #                          [RFC4656]
+
+   IANA has also allocated a well-known TCP/UDP port number for the
+   TWAMP-Control protocol.
+
+   ...
+   twamp-control   862/tcp    Two-way Active Measurement Protocol
+                              (TWAMP) Control
+   twamp-control   862/udp    Two-way Active Measurement Protocol
+                              (TWAMP) Control
+   #                          [RFC5357]
+   #               863-872    Unassigned
+
+   Since TWAMP adds an additional Control command beyond the OWAMP-
+   Control specification and describes behavior when this control
+   command is used, IANA has created a 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.
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 21]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+8.1.  Registry Specification
+
+   IANA has created a TWAMP-Control Command Number registry.  TWAMP-
+   Control commands are specified by the first octet in OWAMP-Control
+   messages as shown in Section 3.5 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 [RFC5226] -- 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 numbers might be useful in this space, or 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 allocates one number
+   (6) as designated for experimentation and testing.
+
+8.4.  Initial Registry Contents
+
+   TWAMP-Control Command Number Registry
+
+   Value  Description             Semantics Definition
+   0      Reserved
+   1      Forbidden
+   2      Start-Sessions          RFC 4656, Section 3.7
+   3      Stop-Sessions           RFC 4656, Section 3.8
+   4      Reserved
+   5      Request-TW-Session      this document, Section 3.5
+   6      Experimentation         undefined, see Section 8.3.
+
+9.  Internationalization Considerations
+
+   The protocol does not carry any information in a natural language,
+   with the possible exception of the KeyID in TWAMP-Control, which is
+   encoded in UTF-8 [RFC3629, RFC5198].
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 22]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+Appendix I - TWAMP Light (Informative)
+
+   In this example, the roles of Control-Client, Server, and Session-
+   Sender are implemented in one host referred to as the controller, and
+   the role of Session-Reflector is implemented in another host referred
+   to as the responder.
+
+              controller                              responder
+          +-----------------+                   +-------------------+
+          |     Server      |<----------------->|                   |
+          | Control-Client  |                   | Session-Reflector |
+          | Session-Sender  |<--TWAMP-Test----->|                   |
+          +-----------------+                   +-------------------+
+
+   This example provides a simple architecture for responders where
+   their role will be to simply act as light test points in the network.
+   The controller establishes the test session with the Server through
+   non-standard means.  After the session is established, the controller
+   transmits test packets to the responder.  The responder follows the
+   Session-Reflector behavior of TWAMP as described in section 4.2 with
+   the following exceptions.
+
+   In the case of TWAMP Light, the Session-Reflector does not
+   necessarily have knowledge of the session state.  IF the Session-
+   Reflector does not have knowledge of the session state, THEN the
+   Session-Reflector MUST copy the Sequence Number of the received
+   packet to the Sequence Number field of the reflected 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
+   assumes that the Session-Reflector is configured and communicates its
+   configuration with the Server through non-standard means.  The
+   Session-Reflector simply reflects the incoming packets back to the
+   controller while copying the necessary information and generating
+   sequence number and timestamp values per Section 4.2.1. TWAMP Light
+   introduces some additional security considerations.  The non-standard
+   means to control the responder and establish test sessions SHOULD
+   offer the features listed below.
+
+   The non-standard responder control protocol SHOULD have an
+   authenticated mode of operation.  The responder SHOULD be
+   configurable to accept only authenticated control sessions.
+
+   The non-standard responder control protocol SHOULD have a means to
+   activate the authenticated and encrypted modes of the TWAMP-Test
+   protocol.
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 23]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+   When the TWAMP Light test sessions operate in authenticated or
+   encrypted mode, the Session-Reflector MUST have some mechanism for
+   generating keys (because the TWAMP-Control protocol normally plays a
+   role in this process, but is not present here).  The specification of
+   the key generation mechanism is beyond the scope of this memo.
+
+Normative References
+
+   [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
+             Zekauskas, "A One-way Active Measurement Protocol (OWAMP)",
+             RFC 4656, September 2006.
+
+   [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
+             Delay Metric for IPPM", RFC 2681, September 1999.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
+             "Definition of the Differentiated Services Field (DS Field)
+             in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
+
+   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
+             2008.
+
+   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+             STD 63, RFC 3629, November 2003.
+
+   [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
+             Interchange", RFC 5198, March 2008.
+
+Informative References
+
+   [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
+             Considered Useful", BCP 82, RFC 3692, January 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 24]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+Authors' Addresses
+
+   Kaynam Hedayat
+   Brix Networks
+   285 Mill Road
+   Chelmsford, MA  01824
+   USA
+   EMail: khedayat@brixnet.com
+   URI:   http://www.brixnet.com/
+
+   Roman M. Krzanowski, Ph.D.
+   Verizon
+   500 Westchester Ave.
+   White Plains, NY
+   USA
+   EMail: roman.krzanowski@verizon.com
+   URI:   http://www.verizon.com/
+
+   Al Morton
+   AT&T Labs
+   Room D3 - 3C06
+   200 Laurel Ave. South
+   Middletown, NJ 07748
+   USA
+   Phone  +1 732 420 1571
+   EMail: acmorton@att.com
+   URI:   http://home.comcast.net/~acmacm/
+
+   Kiho Yum
+   Juniper Networks
+   1194 Mathilda Ave.
+   Sunnyvale, CA
+   USA
+   EMail: kyum@juniper.net
+   URI:   http://www.juniper.com/
+
+   Jozef Z. Babiarz
+   Nortel Networks
+   3500 Carling Avenue
+   Ottawa, Ont  K2H 8E9
+   Canada
+   Email: babiarz@nortel.com
+   URI:   http://www.nortel.com/
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 25]
+
+RFC 5357          Two-Way Active Measurement Protocol       October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Hedayat, et al.             Standards Track                    [Page 26]
+