--- 1/draft-ietf-ippm-twamp-07.txt 2008-06-09 21:12:29.000000000 +0200 +++ 2/draft-ietf-ippm-twamp-08.txt 2008-06-09 21:12:29.000000000 +0200 @@ -1,24 +1,24 @@ Network Working Group K. Hedayat Internet Draft Brix Networks -Expires: Nov 2008 R. Krzanowski +Expires: Dec 2008 R. Krzanowski Intended Status:Standards Track Verizon A. Morton AT&T Labs K. Yum Juniper Networks J. Babiarz Nortel Networks - May 13, 2008 + June 6, 2008 A Two-way Active Measurement Protocol (TWAMP) - draft-ietf-ippm-twamp-07 + draft-ietf-ippm-twamp-08 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -205,26 +205,26 @@ 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 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 repsponds with its + 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 acknowleges. + 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. The Modes field is used to establish the communication @@ -259,25 +259,29 @@ 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. 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, AND no packet associated - with any test sessions started by that control connection have been - received for SERVWAIT seconds. 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. + 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 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 Integrity protection of TWAMP follows the same procedure defined in section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers everything sent in a given direction between the previous HMAC (but 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 connection is authenticated by an HMAC exactly once. @@ -301,21 +305,21 @@ 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. 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]. 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. @@ -365,21 +369,21 @@ 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 as defined in OWAMP [RFC4656]. + 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. @@ -470,22 +474,22 @@ 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 [RFC4656] test protocol 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 - behaviour to the degree of detail as needed in OWAMP [RFC4656]. + 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 received packet 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 @@ -755,21 +759,21 @@ 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 result is the TWAMP-Test HMAC Session-key to use in authenticating the packets of the particular TWAMP-Test session. Note that all of TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are comprised of 32 octets, while the SID is 16 octets. ECB mode used for encrypting the first block of TWAMP-Test packets in authenticated mode does not involve any actual chaining; this 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 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.