J. Babiarz
  Internet Draft                                        Nortel Networks
  Expires: December 2006
                                                             K. Hedayat
  Internet Draft                                          Brix Networks
  Expires: April 2007                                     R. Krzanowski
                                                                Verizon
                                                               Kiho
                                                                 K. Yum
                                                       Juniper Networks
                                                              A. Morton
                                                              AT&T Labs
                                                             J. Babiarz
                                                        Nortel Networks
                                                          November 2006

                A Two-way Active Measurement Protocol (TWAMP)
                         draft-ietf-ippm-twamp-01
                        draft-ietf-ippm-twamp-02

 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
    other groups may also distribute working documents as
    Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than as "work in
    progress."

    The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt
    The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.

 Copyright Notice

    Copyright (C) The Internet Society (2006).

 Abstract

    The IPPM One-way Active Measurement Protocol [OWAMP] [RFC4656] (OWAMP)
    provides a common protocol for measuring one-way metrics between
    network devices.  OWAMP [OWAMP] can be used in both directions
    independently 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 draft proposes memo specifies a Two-way Active Measurement Protocol,
    Protocol (TWAMP), based on the One-way Active Measurement
    Protocol [OWAMP], OWAMP, that will accommodate adds two-way or
    round-trip
    measurements. 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.

 Table of Contents

    1. Introduction..................................................2
    2. Terminology...................................................3
    3. Protocol Overview.............................................3
       3.1 Introduction..................................................3
       1.1 Relationship of Test and Control Protocols................3
       3.2
       1.2 Logical Model.............................................3
    4.
    2. Protocol Overview.............................................5
    3. TWAMP Control.................................................5
       4.1
       3.1 Connection Setup..........................................6
       4.2 Setup..........................................5
       3.2 Integrity Protection......................................6
       3.3 Value of the Accept Fields................................6
       3.4 TWAMP Control Commands....................................6
       4.3
       3.5 Creating Test Sessions....................................6
       4.4
       3.6 Send Schedules............................................6
       4.5 Schedules............................................8
       3.7 Starting Test Sessions....................................6
       4.6 Stop-Sessions.............................................6
       4.7 Fetch-Session.............................................6
    5. Sessions....................................8
       3.8 Stop-Sessions.............................................8
       3.9 Fetch-Session.............................................8
    4. TWAMP Test....................................................7
       5.1 Test....................................................8
       4.1 Sender Behavior...........................................7
       5.2 Behavior...........................................9
       4.2 Reflector Behavior........................................8
    6. Behavior........................................9
    5. Implementers Guide...........................................12
       6.1 Guide...........................................14
       5.1 Complete TWAMP...........................................12
       6.2 TWAMP...........................................14
       5.2 TWAMP Light..............................................12
    7. Light..............................................14
    6. Security Considerations......................................13 Considerations......................................15
    7. Acknowledgements.............................................15
    8. IANA Considerations..........................................13 Considerations..........................................15
    9. References.................................................1413
       9.1 Internationalization Considerations..........................16
    10. References..................................................16
       10.1 Normative References.....................................14 References....................................16
 1. Introduction

    The IETF IP Performance Metrics (IPPM) working group has proposed
    the completed
    a draft standard for the round-trip delay [RFC2681] metric.  IPPM
    has also proposed completed a new protocol for establishment the control and collection of sessions
    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
    time accuracy is less demanding for round-trip delay, and
    measurement of one-way metrics [OWAMP]. support at the remote end may be limited to a simple
    echo function.  This memo specifies the Two-way Active Measurement
    Protocol
    Protocol, or TWAMP.  TWAMP uses the methodology and architecture of
    OWAMP [OWAMP] [RFC4656] to define an open protocol for measurement of
    two-way or round-trip
    metrics.  Henceforth metrics (henceforth in this document the term
    two-way also signifies round-trip.

 2. Terminology

    In round-trip).  The TWAMP measurement
    architecture is usually comprised of only two hosts with specific
    roles, and this document, the allows for some protocol simplifications, making it
    an attractive alternative 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
    [RFC2681] and indicate requirement levels for compliant
    implementations.

 3. Protocol Overview

    The Two-way Active Measurement Protocol is an open protocol for
    measurement [RFC2119].

 1.1 Relationship of two-way metrics.  It is based on OWAMP [OWAMP] Test and
    adheres Control Protocols

    Similar to its overall architecture OWAMP [RFC4656], TWAMP consists of two inter-related
    protocols: TWAMP-Control and design. TWAMP-Test.  The protocol relationship of these
    protocols is as defined in this document defines extensions and changes to section 1.1 of OWAMP
    [OWAMP] as follows:

    -  Define a new [RFC4656].

 1.2 Logical Model

    The role and definition of the logical entity, Session-Reflector, entities are as defined in place of the
        Session-Receiver.

    -  Define the Session-Reflector behavior in place of the
        Session-Receiver behavior of OWAMP [OWAMP].

    -  Define a new test packet format for packets transmitted from the
        Session-Reflector to Session-Sender.

    -  Presence of the Fetch client in the system and the support of
        the Fetch command by the Server are optional.

 3.1 Relationship of Test and Control Protocols

    Similar to OWAMP [OWAMP], 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 [OWAMP].

 3.2 Logical Model
    The role and definition of the logical entities are as defined in
    section 1.2
    section 1.2 of OWAMP [OWAMP] [RFC4656] with the following exceptions:

    -  The Session-Receiver is called the Session-Reflector in the
        TWAMP architecture.

    -  The presence of the Fetch-Client is optional since two-way
        measurements do not require data retrieval from Session-Reflector has the
        Session-Reflector.  Consequently capability
        to create and send a measurement packet when it receives a
        measurement packet.  Unlike the support for Session-Receiver, the Fetch
        command
        Session-Reflector does not collect any packet information.

    -  The Server is optional by an end system that manages one or more TWAMP
        sessions, and is capable of configuring per-session state in
        the Server. end-points.  However, the a Server may
        choose to implement the Fetch-Client and support associated with a
        Session-Reflector would not have the
        Fetch-Command capability to enable both one-way return the
        results of a test session, and two-way measurements this is a difference from OWAMP.

    -  The Fetch-Client entity does not exist in the same session.  This TWAMP
        architecture, as the Session-Reflector does not collect any
        packet information to be fetched.  Consequently there is explained in more detail in
        section 4.7.

    Several examples no
        need for the Fetch-Client.

    An example of possible relationship scenarios between these roles
    are presented below.  In the first 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         TWAMP-Control
             |
             |    |
             v    v                       v
           +----------------+     +-----------------+
           | Control-Client |     |   Fetch-Client  |
           +----------------+     +-----------------+
    Second example is similar to the first example without the
    Fetch-Client.  In this example only two-way metrics are collected.

           +----------------+                +-------------------+
           | Session-Sender |<--TWAMP-Test-->| Session-Reflector |
           +----------------+                +-------------------+
             ^                                      ^
             |                                      |
             |                                      |
             |                                      |
             |  +----------------+                  |
             |  |     Server     |<-----------------+
             |  +----------------+
             |       ^
             |       |
             |   TWAMP-Control
             |       |
             v       V
           +----------------+
           | Control-Client |
           +----------------+

    Similar to

    As in OWAMP [OWAMP] [RFC4656], different logical roles can be played by the
    same host.  For example, in the figure above, there could be
    actually two hosts: one playing the role roles of Control-Client,
    Fetch-Client, Session-Sender, Control-Client and Server,
    Session-Sender, and the other playing the
    role roles of  Server and
    Session-Reflector.  This is the third example is shown below.

           +-----------------+                   +-------------------+
           | Control-Client  |<--TWAMP Control-->|      Server      |<------------------|       |
           | Control-Client                 |                   | Session-Reflector                   |
           | Session-Sender  |<--TWAMP-Test----->| Session-Reflector |
           +-----------------+                   +-------------------+
    Additionally, following the guidelines of OWAMP [OWAMP], [RFC4656], TWAMP
    has been defined to allow for small test packets that would fit
    inside the payload of a single ATM cell (only in unauthenticated
    mode).

 4.

 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 its overall architecture and design.  The protocol
    defined in this document extends and changes OWAMP [RFC4656] as
    follows:

    -  Define a new logical entity, Session-Reflector, in place of the
        Session-Receiver.

    -  Define the Session-Reflector behavior in place of the
        Session-Receiver behavior of OWAMP [RFC4656].

    -  Define a new test packet format for packets transmitted from the
        Session-Reflector to Session-Sender.

    -  Fetch client does not exist in the TWAMP architecture.

 3. TWAMP Control

    All TWAMP Control messages are similar in format to and follow the
    same similar
    guidelines to those defined in section 3 of OWAMP [OWAMP].

 4.1 [RFC4656] with
    the exceptions outlined in the following sections.  All OWAMP
    [RFC4656] Control messages except for the Fetch-Session command
    apply to TWAMP.

 3.1 Connection Setup

    Connection establishment of TWAMP follows the same procedure
    defined in section 3.1 of OWAMP [OWAMP].

 4.2 [RFC4656].  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

    Integrity protection of TWAMP follows the same procedure defined in
    section 3.2 of OWAMP [RFC4656].

 3.3 Value of the Accept Fields

    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 are as defined in section 3.3 of section 3.4 of OWAMP
    [RFC4656] except that the Fetch-Session command does not apply to
    TWAMP.

 3.5 Creating Test Sessions

    Test sessions creation follows the same procedure as defined in
    section 3.5 of OWAMP [RFC4656].

    In order to distinguish the session as a two-way versus a one-way
    measurement session the first octet of the Request-Session command
    MUST be set to 5.  Value of 5 indicates that this is a
    Request-Session for a two-way metrics measurement session.

    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
    perform in these roles, with the Session-Sender first sending and
    then receiving test packets.  The Session-Reflector first receives
    the test packets, and returns each test packet to the
    Session-Sender as fast as possible.

    Both Conf-Sender and Conf-Receiver 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 zero.

    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.  Receiver Port is the UDP port to which TWAMP test packets
    are reflected by the Session-Reflector (the port where the
    Session-Sender wants to receive test 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
    Session-Sender to Session-Reflector Control Message exchange MUST
    be used in the test packets.

    The SID is as defined in OWAMP [RFC4656].  Since the SID is always
    generated by the receiving side, the Session-Reflector determines
    the SID, and the SID in the Request-Session message MUST be set to
    0.

    The Start Time is as 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 DCSP MUST
    be used in test packets reflected by the Session-Reflector.

    Since there are no Schedule Slot Descriptions, the Request-Session
    Message is followed by HMAC.  This completes one logical message,
    referred to as the Request-Session Command.

    The Session-Reflector MUST respond to each Request-Session Command
    with an Accept-Message as defined in OWAMP
    [OWAMP] except for [RFC4656].  The Port is
    the optional requirement of port to which TWAMP test packets are sent by the Fetch-Session
    command.

 4.3 Creating Test Sessions

    Test sessions creation follows Session-Sender
    toward the same procedure as defined in
    section 3.4 of OWAMP [OWAMP]. Session-Reflector.  In order to distinguish other words, the session
    as a two-way versus a one-way measurement session Port field
    indicates the first octet
    of port number where the Request-Session command MUST be set Session-Reflector expects to 5.  Value of 5
    indicates that this is a Request-Session for a two-way metrics
    measurement session.

 4.4
    receive packets from the Session-Sender.

 3.6 Send Schedules

    The Send schedule of Schedule for test packets follow the same procedure and
    guidelines as defined in section 3.5 3.6 of OWAMP [OWAMP].

 4.5
    [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 follow is the same procedure and guidelines
    as defined in section 3.6 3.7 of OWAMP [OWAMP].

 4.6 [RFC4656].

 3.8 Stop-Sessions

    The procedure and guidelines for Stopping test sessions follow is the same procedure and guidelines
    as defined in section 3.7 3.8 of OWAMP [OWAMP].

 4.7 [RFC4656].  The Stop-Session
    command can only be issued by the Session-Sender.  The Next SeqNo
    and Number of Skip Ranges MUST be set to 0 and 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.

 3.9 Fetch-Session

    The purpose of TWAMP is measurement of two-way metrics.  Two-way
    measurements do not rely on packet level data collected by the
    Session-Reflector such as sequence number, timestamp, and TTL.  As
    such the protocol does not require the retrieval of packet level
    data from the Server and the Fetch-Session command is optionally
    supported by the Server.

    However, TWAMP can be used as an extension to OWAMP [OWAMP] where
    both one-way and two-way measurements are measured in the same
    session.  In this case the Server MAY support the Fetch-Session
    command as defined in section 3.8 of OWAMP[OWAMP].  The
    Session-Reflector will reject level
    data from the Fetch-Session request if either
    it does not support Server and the Fetch-Session command or Session-Reflector
    cannot provide the required data.  In this case the server MUST
    respond with a Fetch-Ack message with Accept value of 3.

 5. is not defined
    in TWAMP.

 4. TWAMP Test

    The TWAMP test protocol is similar to the OWAMP [OWAMP] [RFC4656] test
    protocol 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 [OWAMP] [RFC4656] test
    protocol there are three modes: unauthenticated, authenticated, and
    encrypted.

 5.1

 4.1 Sender Behavior

    The sender behavior is as determined by the configuration of the
    Session-Sender and is not defined in section 4.1 this standard.  Further, the
    Session-Reflector does not need to know the Session-Sender
    behaviour to the degree of detail as needed in OWAMP [OWAMP]
    for both packet timing and packet format. [RFC4656].
    Additionally the Session-Sender collects and records the necessary
    information provided by 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.

 5.1.1

 4.1.1 Packet Timings

    Packet timings follow

    Since the same procedure and guidelines as defined
    in section 4.1.1 Send Schedule is not communicated to the
    Session-Reflector, there is no need for a standardized computation
    of OWAMP [OWAMP].

 5.1.2 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 [OWAMP].

 5.2 Reflector Behavior

    When receiving packets the reflector behavior is same as
    Session-Receiver behavior defined in section 4.2 of OWAMP [OWAMP]
    with
    [RFC4656] (with the exception of optional packet information recording.  If the Session-Reflector chooses not reference to collect packet information for
    packets received from the Session-Sender, the Server will not
    support the Fetch-Session command.  Additionally, Send
    Schedule).

 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,

    -  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 timestamp (in the packet).

    -  In authenticated or encrypted mode, decrypt the first block (16
        octets) of the packet body.

    -  Copy the packet sequence number into the corresponding reflected
        packet to the Session-Sender.

    -  Optionally store the packet sequence number, send time, receive
        time, and the TTL for IPv4 (or Hop Limit for IPv6) from the
        packet IP header for the results to be transferred.

    -  Packets not received within the Timeout are considered lost.
        They are optionally recorded with their true sequence number,
        presumed send time, receive time consisting of a string of zero
        bits, and TTL (or Hop Limit) of 255.  The Session-Reflector
        will not generate a test packet to the Session-Sender for
        packets that are considered lost.

    - Transmit a test packet to the Session-Sender in response to
       every received packet.  The response must MUST be generated as
       immediately as possible.  The format and content of the test
       packet is defined in section 5.2.1.  Prior to the transmission
       of the test packet packet, the Session-Reflector MUST determine enter the best
       possible approximation of its actual sending time of as its
       Timestamp (in the packet). This permits the determination of the
       elapsed time since between the reception of the packet for incorporating and its
       transmission.

    -  Packets not received within the
        value in Timeout are ignored by the reflected
       Reflector.  The Session-Reflector MUST NOT generate a test packet.

 5.2.1
       packet to the Session-Sender for packets that are ignored.

 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 format various formats of the
    packet is are presented below.

    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                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                         Packet Padding                        .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    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                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        IZP (12 octets)                        |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Timestamp                            |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Error Estimate        |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                        IZP (6 octets)                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Receive Timestamp                      |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        IZP (8 octets)                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    |                        Sender Sequence Number                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        IZP (12 octets)                        |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Sender Timestamp                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Sender Error Estimate    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                        IZP (6 octets)                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                         Packet Padding                        .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Sequence Number is the sequence number of the test packet and according
    to its arrival at the Session-Reflector.  It starts with zero and
    is incremented by one for each subsequent packet.  The Sequence
    Number generated sequence number by the Session-Reflector,
    Sequence Number, Session-Reflector is independent from the
    sequence number of the
    received arriving packets.

    Timestamp and Error Estimate are the Session-Reflector's transmit
    timestamp and error estimate of for the reflected test packet packet,
    respectively.  The format of all timestamp and error estimate
    fields follow the definition and formats defined by OWAMP[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.  The format of all timestamp and error estimate
    fields follow the definition and formats defined by OWAMP[OWAMP].

    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 of 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 corresponds caused the
    Session-Reflector to generate and send this test packet.

    Similar to OWAMP [OWAMP] [RFC4656] the TWAMP packet layout is the same in
    authenticated and encrypted modes.  The encryption operation of
    Session-Receiver
    Session-Sender packet follow the same rules of Session-Sender
    packets as defined in OWAMP [OWAMP]. [RFC4656].

    The minimum data segment length is, therefore, 40 octets in
    unauthenticated mode, and 80 octets in both authenticated mode and
    encrypted modes. modes (with the implication that the later two modes will
    not fit in a single ATM cell).

    The Session-Reflector TWAMP-Test packet layout is the same in
    authenticated and encrypted modes.  The encryption operations are,
    however, different.  The difference is that in encrypted mode both
    the sequence numbers and timestamps are encrypted to provide
    maximum data integrity protection while in authenticated mode the
    sequence numbers are encrypted and the timestamps are sent in clear
    text.  Sending the timestamp in clear text in authenticated mode
    allows one to reduce the time between when a timestamp is obtained
    by a reflector and when the packet is reflected out.  In encrypted
    mode, both the sender and reflector have to fetch the timestamp,
    encrypt it, and send it; in authenticated mode, the middle step is
    removed, potentially improving accuracy (the sequence number can be
    encrypted before the timestamp is fetched).

    In authenticated mode, the first block (32 octets) of each packet
    is encrypted using AES Electronic Cookbook (ECB) mode.

    Obtaining the key, encryption method, and packet padding is as
    defined in section 4.1.2 of OWAMP [OWAMP]. [RFC4656].  In unauthenticated
    mode, no encryption is applied.

 6.

 5. Implementers Guide

    This section serves as guidance to implementers of TWAMP.  Two
    architectures are presented in this section for implementations
    where two hosts play the subsystem roles of TWAMP.  Although only
    two architectures are presented here the protocol does not require
    their use.  Similar to OWAMP [OWAMP] [RFC4656] TWAMP is designed with
    complete flexibility to allow different architectures that suite
    multiple system requirements.

 6.1

 5.1 Complete TWAMP

    In this example the roles of Control-Client, Fetch-Client, Control-Client and Session-Sender are
    implemented in one host referred to as the controller and the roles
    of Server and Session-Receiver Session-Reflector are implemented in another host
    referred to as the responder.

               controller                              responder
           +-----------------+                   +-------------------+
           | Control-Client  |<--TWAMP-Control-->| Server            |
           | Fetch-Client                 |                   |                   |
           | 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-Receiver Session-Reflctor behavior of both OWAMP
    [OWAMP] and TWAMP as
    described in section 5.2.  In this
    architecture the responder supports the Fetch-Session command.
    After the transmission of test packets the controller fetches the
    responder's information through its Fetch-Client.  This
    architecture allows for collection of both one-way and two-way
    metrics.

 6.2 4.2.

 5.2 TWAMP Light

    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-Receiver 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-Receiver Session-Reflector behavior of TWAMP as
    described in section 5.2.1 4.2 with the following exceptions.  The
    Session-Reflector SHOULD copy the sequence number of the received
    packet to the Sequence Number field of the reflected packet.  This
    is necessary since in case of TWAMP Light the Session-Reflector
    does not have knowledge of the session state.  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.
    Furthermore, the Server does not support the Fetch-Session command
    and the responder does not collect the received packet information.  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 5.2.1.

 7.

 6. Security Considerations

    The security considerations of OWAMP [OWAMP] [RFC4656] apply.

 8. IANA Considerations

    There are no IANA considerations associated with this
    specification.

 9.

 7. Acknowledgements

    The authors wish

    We would like to thank Nagarjuna Venn, Sharee McNab and McNab, Nick Kinraid Kinraid,
    and Stanislav Shalunov for their
    comments comments, suggestions, reviews,
    helpful discussion and suggestions. proof-reading.

 8. IANA Considerations
    IANA has allocated a well-known TCP port number (861) for the
    OWAMP-Control part of the OWAMP [RFC4656] protocol which also
    applies to the TWAMP-Control part of the TWAMP protocol.

 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.

 10. References

 10.1 Normative References

       [OWAMP]

       [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
                  Zekauskas, M., "A One-way Active Measurement Protocol
                  (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004.

       [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A
                  Round-Trip Delay Metric for IPPM". RFC 2681, STD 1,
                  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.

    Authors' Addresses

       Kaynam Hedayat
       Brix Networks
       285 Mill Road
       Chelmsford, MA  01824
       US

       Phone: +1 978 367 5611
       USA

       EMail: khedayat@brixnet.com
       URI:   http://www.brixnet.com/

       Roman M. Krzanowski, Ph.D.
       Verizon
       500 Westchester Ave.
       White Plains, NY
       US

       Phone: +1 914 644 2395
       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
       US

       Phone: +1 408 936 2272
       USA

       EMail: kyum@juniper.net
       URI:   http://www.juniper.com/

 IPR Disclosure Acknowledgement

       Jozef Z. Babiarz
       Nortel Networks
       3500 Carling Avenue
       Ottawa, Ont  K2H 8E9
       Canada

       Email: babiarz@nortel.com
       URI:   http://www.nortel.com/

 Full Copyright Statement

    Copyright (C) The Internet Society (2006).

    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 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.

 Disclaimer of Validity

    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 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.

 Copyright Notice

    Copyright (C) The Internet Society (2006).

    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.

 Acknowledgment

    Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society. IETF
    Administrative Support Activity (IASA).