Would there be any
interest in defining a way for a remote client to request that a
Session-Sender initiate a test session to a Session-Reflector and then gather
the results of that test? Right now a Control-Client can
effectively negotiate the configuration and starting of a
Session-Reflector. Why not allow a Control-Client to also negotiate
the configuration and starting of a Session-Sender? Two (or more)
test endpoints could be placed in a network and a central agent could open
TWAMP-Control connections to both endpoints, configure one as the
Session-Sender, and the other as the Session-Reflector. This might
involve modification to the TWAMP Request-TW-Session message behavior (keying
off the Conf-Sender/Conf-Receiver fields?) or maybe a completely new message
type. When a test completes the central agent would probably
want to gather the results. This might mean reinstating the
Fetch-Session and Fetch-Ack messages in the TWAMP-Control protocol so
that all the results that are collected by the Session-Sender could be sent
back to the central agent for further processing. Of course that
would require the OWAMP Fetch-Ack message format to be extended to include
Sender Timestamp, Sender Error Estimate, and Sender Sequence Number
information in each packet record.
Expanded Role
Diagram:
+----------------+ +-------------------+
| Session-Sender |<--TWAMP-Test-->| Session-Reflector |
+----------------+ +-------------------+
^ ^
| |
| |
v v
+----------------+
+----------------+
| Control-Server
|
| Control-Server |
+----------------+
+----------------+
^ ^ ^
| | |
| | |
| +--TWAMP-Control--+ +-TWAMP-Control-+
| | |
| | |
TWAMP-Control
| |
| | |
| | |
v v v
+--------------+ +----------------+
|
Fetch-Client | | Control-Client |
+--------------+
+----------------+
Collapsed Role
Diagram:
+----------------+ +-------------------+
| Session-Sender |<--TWAMP-Test-->| Session-Reflector |
|
Control-Server
|
| Control-Server |
+----------------+ +-------------------+
^ ^
| |
| |
TWAMP-Control
|
|
|
|
|
|
+------ TWAMP-Control
-------+
|
|
v
v
+----------------+
| Control-Client
|
| Fetch-Client |
+----------------+
This behavior could be
made purely optional if it used the existing TWAMP Request-TW-Session message
and any Control-Server that did not support this functionality could just
refuse the session in its Accept-Session message (accept field == 3,
“Some aspect of request is not supported”).
The argument could be made
that it is possible to setup an equivalent remote bidirectional test with
OWAMP using simultaneous one-way test tests so why should TWAMP be expanded to
do it too? In the abstract section of the TWAMP draft it says that OWAMP
does not accommodate round-trip or two-way measurements. Also, the
Reflector could still be a TWAMP Light reflector and then the burden of
implementing TWAMP-Control protocol resides in the endpoint that serves as the
Session-Sender (see diagram below).
TWAMP Light
Diagram:
+----------------+ +-------------------+
| Session-Sender |<--TWAMP-Test-->| Session-Reflector |
|
Control-Server
|
|
|
+----------------+ +-------------------+
^
^
|
|
TWAMP-Control
|
|
|
|
|
|
+-----------------------------+
|
|
v
v
+----------------+
| Control-Client
|
| Fetch-Client |
+----------------+
Something similar could
also be accomplished with SNMP MIBs for configuring TWAMP Session-Senders and
for gathering the resulting test measurements. However, this is so
similar to the existing OWAMP-Control behavior (ie. Fetch-Session, Fetch-Ack,
Request-Session) that, in my opinion, it seems more natural to extend the
TWAMP-Control protocol to support this
functionality.
Regards,
Walt
Steverson