draft-ietf-ippm-twamp-07.txt   draft-ietf-ippm-twamp-08.txt 
Network Working Group K. Hedayat Network Working Group K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: Nov 2008 R. Krzanowski Expires: Dec 2008 R. Krzanowski
Intended Status:Standards Track Verizon Intended Status:Standards Track Verizon
A. Morton A. Morton
AT&T Labs AT&T Labs
K. Yum K. Yum
Juniper Networks Juniper Networks
J. Babiarz J. Babiarz
Nortel Networks Nortel Networks
May 13, 2008 June 6, 2008
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-07 draft-ietf-ippm-twamp-08
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 5, line 44 skipping to change at page 5, line 44
with its greeting message indicating the security/integrity with its greeting message indicating the security/integrity
mode(s) it is willing to support. mode(s) it is willing to support.
- The Control-Client responds with the chosen mode of - The Control-Client responds with the chosen mode of
communication and information supporting integrity protection communication and information supporting integrity protection
and encryption, if the mode requires them. The Server responds and encryption, if the mode requires them. The Server responds
to accept the mode and start time. This completes the control to accept the mode and start time. This completes the control
connection setup. connection setup.
- The Control-Client requests (and describes) a test session with - The Control-Client requests (and describes) a test session with
a unique TWAMP-Control message. The Server repsponds with its a unique TWAMP-Control message. The Server responds with its
acceptance and supporting information. More than one test acceptance and supporting information. More than one test
session may be requested with additional messages. session may be requested with additional messages.
- The Control-Client initiates all requested testing with a start - The Control-Client initiates all requested testing with a start
sessions message, and the Server acknowleges. sessions message, and the Server acknowledges.
- The Session-Sender and the Session-Reflector exchange test - The Session-Sender and the Session-Reflector exchange test
packets according to the TWAMP-Test protocol for each active packets according to the TWAMP-Test protocol for each active
session. session.
- When appropriate, the Control-Client sends a message to stop all - When appropriate, the Control-Client sends a message to stop all
test sessions. test sessions.
There are two recognized extension mechanisms in the TWAMP There are two recognized extension mechanisms in the TWAMP
Protocol. The Modes field is used to establish the communication Protocol. The Modes field is used to establish the communication
skipping to change at page 7, line 9 skipping to change at page 7, line 9
assignment). The host that initiates the TCP connection takes the assignment). The host that initiates the TCP connection takes the
roles of Control-Client and (in the two-host implementation) the roles of Control-Client and (in the two-host implementation) the
Session-Sender. The host that acknowledges the TCP connection Session-Sender. The host that acknowledges the TCP connection
accepts the roles of Server and (in the two-host implementation) accepts the roles of Server and (in the two-host implementation)
the Session Reflector. the Session Reflector.
The possibility exists for Control-Client failure after TWAMP- The possibility exists for Control-Client failure after TWAMP-
Control connection establishment, or the path between the Control- Control connection establishment, or the path between the Control-
Client and Server may fail while a connection is in-progress. The Client and Server may fail while a connection is in-progress. The
Server MAY discontinue any established control connection when no Server MAY discontinue any established control connection when no
packet associated with that connection, AND no packet associated packet associated with that connection has been received within
with any test sessions started by that control connection have been SERVWAIT seconds. The Server SHALL suspend monitoring control
received for SERVWAIT seconds. The default value of SERVWAIT SHALL connection activity after receiving a Start-Sessions command, and
be 900 seconds, and this waiting time MAY be configurable. This SHALL resume after receiving a Stop-Sessions command (IF the
time-out allows a Server to free-up resources in case of failure. SERVWAIT option is supported). Note that the REFWAIT time-out
(described below) covers failures during test sessions. The default
value of SERVWAIT SHALL be 900 seconds, and this waiting time MAY
be configurable. This time-out allows a Server to free-up resources
in case of failure.
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]. As in OWAMP, each HMAC sent covers section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers
everything sent in a given direction between the previous HMAC (but everything sent in a given direction between the previous HMAC (but
not including it) and up to the beginning of the new HMAC. This not including it) and up to the beginning of the new HMAC. This
way, once encryption is set up, each bit of the TWAMP-Control way, once encryption is set up, each bit of the TWAMP-Control
connection is authenticated by an HMAC exactly once. connection is authenticated by an HMAC exactly once.
skipping to change at page 8, line 11 skipping to change at page 8, line 13
Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server
can send specific messages in response to the commands it receives can send specific messages in response to the commands it receives
(as described in the sections that follow). (as described in the sections that follow).
Note that the OWAMP Request-Session command is replaced by the Note that the OWAMP Request-Session command is replaced by the
TWAMP Request-TW-Session command, and the Fetch-Session command TWAMP Request-TW-Session command, and the Fetch-Session command
does not appear in TWAMP. does not appear in TWAMP.
3.5 Creating Test Sessions 3.5 Creating Test Sessions
Test sessions creation follows the same procedure as defined in Test session creation follows the same procedure as defined in
section 3.5 of OWAMP [RFC4656]. section 3.5 of OWAMP [RFC4656].
In TWAMP, the first octet is referred to as the Command Number, and In TWAMP, the first octet is referred to as the Command Number, and
the Command Number is a recognized extension mechanism. Readers are the Command Number is a recognized extension mechanism. Readers are
encouraged to consult the TWAMP-Control Command Number Registry to encouraged to consult the TWAMP-Control Command Number Registry to
determine if there have been additional values assigned. determine if there have been additional values assigned.
The Command Number value of 5 indicates a Request-TW-Session The Command Number value of 5 indicates a Request-TW-Session
Command, and the Server MUST interpret this command as a request Command, and the Server MUST interpret this command as a request
for a two-way test session using the TWAMP-Test protocol. for a two-way test session using the TWAMP-Test protocol.
skipping to change at page 9, line 27 skipping to change at page 9, line 30
the Internet path over which a TWAMP test session is requested. 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 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 Control-Client to Server TWAMP-Control Message exchange MUST be
used in the test packets. used in the test packets.
The Session Identifier (SID) is as defined in OWAMP [RFC4656]. The Session Identifier (SID) is as defined in OWAMP [RFC4656].
Since the SID is always generated by the receiving side, the Server Since the SID is always generated by the receiving side, the Server
determines the SID, and the SID in the Request-TW-Session message determines the SID, and the SID in the Request-TW-Session message
MUST be set to 0. MUST be set to 0.
The Start Time is as as defined in OWAMP [RFC4656]. The Start Time is as defined in OWAMP [RFC4656].
The Timeout is interpreted differently from the definition in OWAMP The Timeout is interpreted differently from the definition in OWAMP
[RFC4656]. In TWAMP, Timeout is the interval that the [RFC4656]. In TWAMP, Timeout is the interval that the
Session-Reflector MUST wait after receiving a Stop-Sessions Session-Reflector MUST wait after receiving a Stop-Sessions
message. In case there are test packets still in transit, the message. In case there are test packets still in transit, the
Session Reflector MUST reflect them if they arrive within the Session Reflector MUST reflect them if they arrive within the
timeout interval following the reception of the Stop-Sessions timeout interval following the reception of the Stop-Sessions
message. The Session-Reflector MUST NOT reflect packets that are message. The Session-Reflector MUST NOT reflect packets that are
received beyond the timeout. received beyond the timeout.
skipping to change at page 12, line 9 skipping to change at page 12, line 9
it receives. TWAMP defines two different test packet formats, one it receives. TWAMP defines two different test packet formats, one
for packets transmitted by the Session-Sender and one for packets for packets transmitted by the Session-Sender and one for packets
transmitted by the Session-Reflector. As with OWAMP [RFC4656] test transmitted by the Session-Reflector. As with OWAMP [RFC4656] test
protocol there are three modes: unauthenticated, authenticated, and protocol there are three modes: unauthenticated, authenticated, and
encrypted. encrypted.
4.1 Sender Behavior 4.1 Sender Behavior
The sender behavior is determined by the configuration of the The sender behavior is determined by the configuration of the
Session-Sender and is not defined in this standard. Further, the Session-Sender and is not defined in this standard. Further, the
Session-Reflector does not need to know the Session-Sender Session-Reflector does not need to know the Session-Sender behavior
behaviour to the degree of detail as needed in OWAMP [RFC4656]. to the degree of detail as needed in OWAMP [RFC4656].
Additionally the Session-Sender collects and records the necessary Additionally the Session-Sender collects and records the necessary
information provided from the packets transmitted by the information provided from the packets transmitted by the
Session-Reflector for measuring two-way metrics. The information Session-Reflector for measuring two-way metrics. The information
recording based on the received packet by the Session-Sender is recording based on the received packet by the Session-Sender is
implementation dependent. implementation dependent.
4.1.1 Packet Timings 4.1.1 Packet Timings
Since the Send Schedule is not communicated to the Since the Send Schedule is not communicated to the
Session-Reflector, there is no need for a standardized computation Session-Reflector, there is no need for a standardized computation
skipping to change at page 18, line 20 skipping to change at page 18, line 20
using AES, with the 16-octet session identifier (SID) as the key; using AES, with the 16-octet session identifier (SID) as the key;
this is a two-block CBC encryption, always performed with IV=0; its this is a two-block CBC encryption, always performed with IV=0; its
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 a TWAMP-Test session.
In encrypted mode, the first six blocks (96octets) 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.
 End of changes. 10 change blocks. 
15 lines changed or deleted 19 lines changed or added

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