Internet DRAFT - draft-hedayat-two-way-active-measurement-protocol

draft-hedayat-two-way-active-measurement-protocol





  
  
  
                                                             J. Babiarz 
  Internet Draft                                        Nortel Networks 
  Expires: November 2006                                     K. Hedayat 
                                                          Brix Networks 
                                                          R. Krzanowski 
                                                                Verizon 
                                                               Kiho Yum 
                                                       Juniper Networks 
                                                              July 2005 
  
                A Two-way Active Measurement Protocol (TWAMP) 
	    draft-hedayat-two-way-active-measurement-protocol-01.txt 
                                      
  
 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 (2005). 
     
     
 Abstract 
     
     
  
 Hedayat, et al.         Expires November 2006                [Page 1] 
  





  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
    The IPPM One-way Active Measurement Protocol [OWAMP] provides a 
    common protocol for measuring one-way metrics between network 
    devices.  OWAMP [OWAMP] can be used in both directions 
    independently 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 a Two-way Active 
    Measurement Protocol, based on the One-way Active Measurement 
    Protocol [OWAMP], that will accommodate two-way or round-trip 
    measurements.  
     
     
 Table of Contents 
     
     
    1. Introduction..................................................2 
    2. Terminology...................................................3 
    3. Protocol Overview.............................................3 
       3.1 Relationship of Test and Control Protocols................3 
       3.2 Logical Model.............................................3 
    4. TWAMP Control.................................................5 
       4.1 Connection Setup..........................................6 
       4.2 TWAMP Control Commands....................................6 
       4.3 Creating Test Sessions....................................6 
       4.4 Send Schedules............................................6 
       4.5 Starting Test Sessions....................................6 
       4.6 Stop-Sessions.............................................6 
       4.7 Fetch-Session.............................................7 
    5. TWAMP Test....................................................7 
       5.1 Sender Behavior...........................................7 
       5.2 Reflector Behavior........................................8 
    6. Implementers Guide...........................................12 
       6.1 Complete TWAMP...........................................12 
       6.2 TWAMP Light..............................................12 
    7. Security Considerations......................................13 
    8. IANA Considerations..........................................13 
    9. References...................................................14 
       9.1 Normative References.....................................14 
     
  
 1. Introduction 
  
  
    The IETF IP Performance Metrics (IPPM) working group has proposed 
    the draft standard for round-trip delay [RFC2681] metric.  IPPM has 
    also proposed a new protocol for establishment of sessions for 
    measurement of one-way metrics [OWAMP].  Two-way Active Measurement 
    Protocol uses the methodology and architecture of OWAMP [OWAMP] to 
    define an open protocol for measurement of two-way or round-trip 

  
 Hedayat, et al.   Expires November 2006December 2005          [Page 2] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
    metrics.  Henceforth in this document the term two-way also 
    signifies round-trip. 
     
     
 2. Terminology 
  
  
    In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
    and "OPTIONAL" 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 of two-way metrics.  It is based on OWAMP [OWAMP] and 
    adheres to its overall architecture and design.  The protocol 
    defined in this document defines extensions and changes to OWAMP 
    [OWAMP] 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 [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 of OWAMP [OWAMP] with the following exceptions: 
  
 Hedayat, et al.   Expires November 2006December 2005          [Page 3] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
     
    -  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 the 
        Session-Reflector.  Consequently the support for the Fetch 
        command is optional by the Server.  However, the Server may 
        choose to implement the Fetch-Client and support the 
        Fetch-Command to enable both one-way and two-way measurements 
        in the same session.  This is explained in more detail in 
        section 4.7. 
     
    Several examples of possible relationship scenarios between these 
    roles are presented below.  In the first example different logical 
    roles are played on different hosts. 
     
           +----------------+               +-------------------+ 
           | Session-Sender |<-TWAMP-Test-->| Session-Reflector | 
           +----------------+               +-------------------+ 
             ^                                     ^ 
             |                                     | 
             |                                     | 
             |                                     | 
             |  +----------------+<----------------+ 
             |  |     Server     |<-------+ 
             |  +----------------+        | 
             |    ^                       | 
             |    |                       | 
             | TWAMP-Control         TWAMP-Control 
             |    |                       | 
             v    v                       v 
           +----------------+     +-----------------+ 
           | Control-Client |     |   Fetch-Client  | 
           +----------------+     +-----------------+ 
     
     












  
 Hedayat, et al.   Expires November 2006December 2005          [Page 4] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
    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 OWAMP [OWAMP] 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 of Control-Client, 
    Fetch-Client, Session-Sender, and Server, and the other playing the 
    role of  Session-Reflector.  This is the third example shown below. 
     
            
           +-----------------+                   +-------------------+ 
           |     Server      |<------------------|                   | 
           | Control-Client  |                   | Session-Reflector | 
           | Session-Sender  |<--TWAMP-Test----->|                   | 
           +-----------------+                   +-------------------+ 
     
     
    Additionally, following the guidelines of OWAMP [OWAMP], TWAMP has 
    been defined to allow for small test packets that would fit inside 
    the payload of a single ATM cell (only in unauthenticated and 
    encrypted modes). 
     
     
 4. TWAMP Control 
     
     
    All TWAMP Control messages are similar in format to and follow the 
    same guidelines defined in section 3 of OWAMP [OWAMP]. 
     
  
 Hedayat, et al.   Expires November 2006December 2005          [Page 5] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
     
 4.1 Connection Setup 
     
     
    Connection establishment of TWAMP follows the same procedure 
    defined in section 3.1 of OWAMP [OWAMP]. 
     
     
 4.2 TWAMP Control Commands 
     
     
    TWAMP control commands are as defined in section 3.3 of OWAMP 
    [OWAMP] except for the optional requirement of the Fetch-Session 
    command. 
     
     
 4.3 Creating Test Sessions 
     
     
    Test sessions creation follows the same procedure as defined in 
    section 3.4 of OWAMP [OWAMP].  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. 
     
     
 4.4 Send Schedules 
     
     
    Send schedule of test packets follow the same procedure and 
    guidelines as defined in section 3.5 of OWAMP [OWAMP]. 
     
     
 4.5 Starting Test Sessions 
     
     
    Starting test sessions follow the same procedure and guidelines as 
    defined in section 3.6 of OWAMP [OWAMP]. 
     
     
 4.6 Stop-Sessions 
     
     
    Stopping test sessions follow the same procedure and guidelines as 
    defined in section 3.7 of OWAMP [OWAMP]. 
     
     

  
 Hedayat, et al.   Expires November 2006December 2005          [Page 6] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
 4.7 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 the Fetch-Session request if either 
    it does not support 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. TWAMP Test 
  
     
    The TWAMP test protocol is similar to the OWAMP [OWAMP] 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] test 
    protocol there are three modes: unauthenticated, authenticated, and 
    encrypted.  
     
  
 5.1 Sender Behavior 
  
  
    The sender behavior is as defined in section 4.1 of OWAMP [OWAMP] 
    for both packet timing and packet format.  Additionally the 
    Session-Sender records the necessary information provided by 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 Packet Timings 
     
     
    Packet timings follow the same procedure and guidelines as defined 
    in section 4.1.1 of OWAMP [OWAMP]. 
  
 Hedayat, et al.   Expires November 2006December 2005          [Page 7] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
     
     
 5.1.2 Packet Format and Content 
     
     
    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 the exception of optional packet information recording.  If 
    the Session-Reflector chooses not to collect packet information for 
    packets received from the Session-Sender, the Server will not 
    support the Fetch-Session command.  Additionally, 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. 
     
    -  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 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 Session-Reflector MUST determine the elapsed 
        time since the reception of the packet for incorporating the 
        value in the reflected test packet. 
  
 Hedayat, et al.   Expires November 2006December 2005          [Page 8] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
     
     
 5.2.1 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 of the packet is 
    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                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Sender Sequence Number                 | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                          Timestamp                            | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |         Error Estimate        |           MBZ                 | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Sender Timestamp                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |      Sender Error Estimate    |           MBZ                 | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                          Reflector Delay                      | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                                                               | 
    .                                                               . 
    .                         Packet Padding                        . 
    .                                                               . 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 






  
 Hedayat, et al.   Expires November 2006December 2005          [Page 9] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
     
    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)                        | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Sender Sequence Number                 | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        IZP (12 octets)                        | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                          Timestamp                            | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |         Error Estimate        |                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               | 
    |                        IZP (6 octets)                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Sender Timestamp                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |      Sender Error Estimate    |                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               | 
    |                        IZP (6 octets)                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Reflector Delay                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        IZP (12 octets)                        | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 
    |                                                               | 
    .                                                               . 
    .                         Packet Padding                        . 
    .                                                               . 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     
     
    Sequence Number is the sequence number of the test packet and 
    starts with zero and is incremented by one for each subsequent 
    packet.  Sender Sequence Number is the Sequence Number of the 
    packet transmitted by the Session-Sender that corresponds to this 
  
 Hedayat, et al.   Expires November 2006December 2005         [Page 10] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
    test packet.  The generated sequence number by the 
    Session-Reflector, Sequence Number, is independent from the 
    sequence number of the received packets. 
     
    Timestamp and Error Estimate are the transmit timestamp and error 
    estimate of the test packet respectively.  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].   
     
    Reflector Delay is the amount of time between the reception of a 
    test packet from the Session-Sender and transmission of the 
    corresponding test packet specified in microseconds.  The purpose 
    of Reflector Delay is removing the Session-Reflector transition 
    time from the round-trip delay calculations. 
     
    Similar to OWAMP [OWAMP] the TWAMP packet layout is the same in 
    authenticated and encrypted modes.  The encryption operation of 
    Session-Receiver packet follow the same rules of Session-Sender 
    packets as defined in OWAMP [OWAMP]. 
     
    The minimum data segment length is, therefore, 36 octets in 
    unauthenticated mode, and 80 octets in both authenticated mode and 
    encrypted modes. 
     
    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].  In unauthenticated 
    mode, no encryption is applied. 
     
     

  
 Hedayat, et al.   Expires November 2006December 2005         [Page 11] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
 6. 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] TWAMP is designed with 
    complete flexibility to allow different architectures that suite 
    multiple system requirements. 
     
     
 6.1 Complete TWAMP 
     
     
    In this example the roles of Control-Client, Fetch-Client, and 
    Session-Sender are implemented in one host referred to as the 
    controller and the roles of Server and Session-Receiver 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 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 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 is implemented in 
    another host referred to as the responder. 
  
 Hedayat, et al.   Expires November 2006December 2005         [Page 12] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
     
     
               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 behavior of TWAMP as 
    described in section 5.2.1.  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. Security Considerations 
     
     
    The security considerations of OWAMP [OWAMP] apply.  
     
     
 8. IANA Considerations 
     
     
    There are no IANA considerations associated with this 
    specification. 








  
 Hedayat, et al.   Expires November 2006December 2005         [Page 13] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
  
  
 9. References  
  
  
 9.1 Normative References 
  
  
       [OWAMP]   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. 
     
     
    Authors' Addresses 
     
     
       Kaynam Hedayat 
       Brix Networks 
       285 Mill Road 
       Chelmsford, MA  01824 
       US 
     
       Phone: +1 978 367 5611 
       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 
       EMail: roman.krzanowski@verizon.com 
       URI:   http://www.verizon.com/ 
     
     
       Kiho Yum 
       Juniper Networks 
       1194 Mathilda Ave. 
       Sunnyvale, CA 
       US 
     
  
 Hedayat, et al.   Expires November 2006December 2005         [Page 14] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
       Phone: +1 408 936 2272 
       EMail: kyum@juniper.net 
       URI:   http://www.juniper.com/ 
     
     
 IPR Disclosure Acknowledgement 
     
     
    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 (2005).   
  
 Hedayat, et al.   Expires November 2006December 2005         [Page 15] 
  




  
 Internet-Draft    Two-way Active Measurment Protocol         July 2005 
  
     
    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 
     
     
    Funding for the RFC Editor function is currently provided by the 
    Internet Society. 
     
     




































  
 Hedayat, et al.   Expires November 2006December 2005         [Page 16]