Two-Way Active Measurement Protocol (TWAMP) YANG Data Model
Extracted elements (30)
Named identifiers for control connections and test sessions are required because at the time of creation the full IP/port 4-tuple is not yet known. A string name provides a programmable handle before all network parameters are negotiated.
Operational actions — starting/stopping TWAMP-Test sessions, retrieving measurement results, clearing stored results — are explicitly out of scope. The document provides only a configuration model; operational state for performance metrics should follow an independent model based on RFC 8911.
The server-tcp-port and reflector-udp-port parameters are configurable (not hard-coded to 862) for backward compatibility with TWAMP deployments predating the well-known port allocation in RFC 8545.
The Session-Reflector and Server cannot configure attributes on a per-session or per-connection basis because they have no foreknowledge of incoming sessions. All configurable parameters must be set at the device level and apply uniformly to all incoming connections or sessions.
The TWAMP data model is orthogonal to the management protocol used between the configuration client and server; both NETCONF (RFC 6241) and RESTCONF (RFC 8040) are valid transports. The model is compliant with the Network Management Datastore Architecture (NMDA, RFC 8342).
All members of pm-reg-list MUST have the same stream characteristics so that they combine to specify all metrics measured on a single stream, as required by the Registry for Performance Metrics (RFC 8911).
Each Session-Reflector test-session contains a 4-tuple {parent-connection-client-ip, parent-connection-client-tcp-port, parent-connection-server-ip, parent-connection-server-tcp-port} that MUST correspond to the equivalent 4-tuple in server/ctrl-connection, allowing the test session to be traced back to its parent TWAMP-Control connection.
If the Control-Client cannot determine an acceptable mode — or when bit combinations do not make sense (e.g., authenticated and unauthenticated bits both set) — it MUST respond with zero Mode bits in the Set-Up-Response message, indicating it will not continue the control connection.
The Client-IV (16-octet binary) MUST never be repeated for different sessions using the same secret key. RFC 4656 recommends using a cryptographically secure pseudo-random number source to generate it without cumbersome state.
The Control-Client MUST choose the highest-priority mode from the configured mode-preference-chain list, based on what is available in the Server Greeting message.
The max-count-exponent parameter limits the maximum Count value a Control-Client will accept. A Control-Client MUST close the control connection if the Server Greeting contains a Count exceeding this maximum, defending against DoS attacks that stall key generation. The default max-count-exponent SHOULD be 15 (= 32768).
The secret-key SHOULD contain at least 128 bits of entropy. The derived key length (dkLen) MUST be 16 octets for the AES Session-key used for encryption and 32 octets for the HMAC-SHA1 Session-key used for authentication, per Section 6.10 of RFC 4656.
The Session-Sender test session name MUST be identical to the corresponding test session name on the Control-Client, as the same name is used across both logical entities to identify the session.
The count grouping specifies an iteration count for key derivation, configured as a power-of-2 exponent (range 10..31, default 15, meaning 2^15 = 32768). The Server communicates the resulting count to the Control-Client in the Server Greeting message.
The ctrl-connection list on the Server is read-only and keyed by the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port}. Each active incoming TWAMP-Control TCP connection is represented by one entry.
The key-chain grouping maps a UTF-8 key-id (1..80 octets) to a binary secret-key for TWAMP-Control authentication/encryption. Both the Server and Control-Client use the same key-id-to-secret-key mapping; key-id must be unique across all systems in the administrative domain.
The mode-preference-chain list on the Control-Client specifies preferred TWAMP modes ordered by a uint16 priority value, where 0 is highest priority and each increment decreases priority by one. Each mode entry must be unique within the list.
The packet-distribution choice node in the Session-Sender test-session allows either 'periodic' (fixed periodic-interval in seconds, decimal64 with 5 fraction digits) or 'poisson' (mean interval lambda plus optional max-interval) packet transmission distributions.
The padding-fill-mode typedef controls TWAMP-Test packet padding: 'zero' fills with all zeros and 'random' fills with pseudorandom numbers, as per Section 4.2.1 of RFC 5357. The default is 'zero'.
The pm-reg-list in a test-session-request holds one or more uint16 Performance Metrics Registry index values (per RFC 8911) that specify the metrics to be measured. All entries in the list MUST have the same packet stream characteristics so they measure a single stream.
The refwait leaf on the Session-Reflector (uint32, range 1..604800 seconds, default 900) defines the inactivity timeout after which the Session-Reflector MAY discontinue a test session that has received no packets, freeing resources on failure.
The repeat leaf (uint32, default 0) controls test session repetition: 0 means no repeat; 1..4,294,967,294 repeats that many times with the repeat-interval delay between iterations; 4,294,967,295 means repeat forever without decrementing.
The SERVWAIT leaf on the Server (uint32, range 1..604800 seconds, default 900) defines the TWAMP-Control TCP session timeout; the Server MAY discontinue a control connection if no packet has been received within this period, per Section 3.1 of RFC 5357.
The token leaf on the Control-Client ctrl-connection holds 64 octets: a 16-octet Challenge concatenated with a 16-octet AES Session-key (encryption) and a 32-octet HMAC-SHA1 Session-key (authentication). When IKEv2-derived mode is selected, token is limited to 16 octets.
The TWAMP data model defines four logical entities: Control-Client, Server, Session-Sender, and Session-Reflector. These map to the TWAMP logical model in RFC 5357, with TWAMP-Control between Control-Client and Server and TWAMP-Test between Session-Sender and Session-Reflector.
The 'twamp-modes' typedef encodes TWAMP-Control modes as a bitmask with eight named bit positions: unauthenticated (0), authenticated (1), encrypted (2), unauth-test-encrypt-control (3), individual-session-control (4), reflect-octets (5), symmetrical-size (6), and IKEv2Derived (7).
The YANG module 'ietf-twamp' uses YANG features (control-client, server, session-sender, session-reflector) to indicate which logical entities a device supports. Each logical entity is modeled in its own container under the top-level 'twamp' container.
RFC 8913 registers the YANG module 'ietf-twamp' with the IANA 'YANG Module Names' registry. The module namespace is 'urn:ietf:params:xml:ns:yang:ietf-twamp' and the prefix is 'ietf-twamp'.
An attacker can set the Count field to its maximum (2^32) in a Server Greeting to cause the targeted system to stall for a significant period generating keys (DoS). Implementations SHOULD limit Count via max-count-exponent with a default of 15 (32768), and operators must size this parameter against their processing capacity.
In authenticated mode, timestamps are transmitted in the clear and are not cryptographically protected; only the rest of the TWAMP-Control message has encryption-level protection. Operators must weigh the trade-off between cryptographic protection and timestamp accuracy when selecting a mode.