IETF RFC 8913 PDF

Scope, Model, and Applicability

The purpose of this document is the specification of a vendor-independent data model for TWAMP implementations.  

Figure 1 illustrates a redrawn version of the TWAMP logical model found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated with pointers to the UML diagrams [UML] provided in this document and associated with the data model of the four logical entities in a TWAMP deployment, namely the TWAMP Control-Client, Server, Session-Sender, and Session-Reflector. A UML Notation Guide is available in Section 5 of UML [UML].

As per TWAMP [RFC5357], unlabeled links in Figure 1 are left unspecified and may be proprietary protocols.

As per TWAMP [RFC5357], a TWAMP implementation may follow a simplified logical model, in which the same node acts as both Control-Client and Session-Sender, while another node acts at the same time as both TWAMP Server and Session-Reflector. Figure 2 illustrates this simplified logical model and indicates the interaction between the TWAMP configuration client and server using, for instance, NETCONF [RFC6241] or RESTCONF [RFC8040].

The data model defined in this document is orthogonal to the specific protocol used between the Config client and Config server to communicate the TWAMP configuration parameters.

Operational actions such as how TWAMP-Test sessions are started and stopped, how performance measurement results are retrieved, or how stored results are cleared, and so on, are not addressed by the configuration model defined in this document. As noted above, such operational actions are not part of the TWAMP specification [RFC5357] and hence are out of scope for this document. See also Appendix B. In addition, for operational state, the information provided in the Performance Metrics Registry [RFC8911] and [PERF-METRICS] can be used to develop an independent model for the Performance Metrics that need to be captured and retrieved.