Monitoring Service KPIs using TWAMP

The TWAMP-Test runs between a Session-Sender and a Session-Reflector RFC 5357. The existing TWAMP-Test packet format has existing padding octets that are currently not used (either set to zero or pseudo-random values). These octets can be used to carry additional information between the Session-Sender and the Session-Reflector. The proposed extension uses these padding octets and provide a method to monitor services KPIs in the network. This feature is termed as Services KPI Monitoring using TWAMP. TWAMP server is used to inject the packet in the service plane for calculating the latency and liveliness. This is done as part of TWAMP data connection. The packets being sent out of TWAMP server is a UDP packet carrying the payload for the service for which we are interested in calculating the KPIs. The timestamping is done at the TWAMP server. Based on the service model, TWAMP server may be runnig on the same box where the service is hosted or in a remote server. The Interface between the TWAMP server and the service plane is implementation specific. the underlying transport is UDP since this is in data path. In this draft, the use cases presented are service latency and keep alive monitoring. Service latency for services like DPI, TDF, Video Caching is calculated. Similarly liveliness for http server, dns application is calculated in the implementation part. As per the proposed extension, both the TWAMP-Control and the TWAMP-Test packet formats are modified. One TWAMP-Test session SHALL be used to monitor KPIs for a specific service. But there can be multiple KPIs monitored using a single test session for a specific service. A single TWAMP-Control connection MAY establish multiple TWAMP-Test sessions that measure KPIs for multiple services in the network. This extension can be used to monitor KPIs for standalone service or a set of services.

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.

TWAMP: Two-Way Active Measurement Protocol KPI: Key Performance Indicator DPI: Deep Packet Inspection CGNAT: Carrier Grade Network Address Translation SFW: Stateful Firewall TDF: Traffic Detection Function DNS: Domain Name Server HTTP: Hyper Text Transfer Protocol FTP: File Transfer Protocol SKMC: Services KPI Monitoring Command PDU: Protocol Data Unit

Metric Name: Services Keepalive Monitoring Metric Description: This indicates whether the service is running or not at any point of time. Method of Measurement or Calculation: The Session-Reflector SHALL inject the Service PDU to the Service Block for service processing. Based on whether the Session-Reflector received the response, the Session-Reflector SHALL decide whether the Service is alive or not. Units of Measurement: This metric is expressed as a single bit boolean value. If this bit is set then it indicates that the Service Block is functional. If this bit is NOT set then it indicates that the Service Block is not functional. Measurement Point(s) with Potential Measurement Domain: This metric is calculated at the Session-Reflector. Measurement Timing: This metric is an instantaneous value. Based on the kind of service it MAY be a good idea to store the history of this value. It can be stored as an average of last one hour for 24 hours, then average of all values over previous day, week, month, year etc. These data MAY be used for some analytics. Implementation: The Session-Sender SHALL send the Service PDU as part of the TWAMP-Test Packet Padding. When Session-Reflector receives the TWAMP-Test packet, it SHALL extract the Service PDU. The Session-Reflector SHALL extract the service PDU from the TWAMP Payload and inject it to the service module. For ex, incase of http server, the service PDU can just be a http req. The service module will apply services on this PDU and once service processing is done, it would send the response(http resp) back to Session Reflector. The Session Reflector SHALL now reply back to the TWAMP client/session sender with the actual TWAMP data packet with payload being the boolean flag and response service PDU(http resp). Verification: The metric value is a boolean which SHOULD be either 0(Service NOT Alive) or 1(Service is Alive). The Session-Reflector MUST start the Packet Padding with the below 4 octets as indicated below. This is followed by the Service PDU (which MAY be same as whatever was sent by Session-Sender or can be the reply/response packet of the Service Block). Setting Bit 0(X) indicates that the Session-Reflector successfully sent the Service Request to the Service Block and received the response from the Service Block. If this bit is NOT set then it indicates that the Service Block is not functional.

Use and Applications: This metric is useful for monitoring the liveliness of a service. Normally the liveliness of the Server or a Network Element is not enough to know whether the Service is really Alive or NOT. Say for example if there is a Web Server Application, then just monitoring whether the Server(where the web server) is alive or not by using ping is just not enough to say whether the application is really Alive or not. There could be instances where in the Server is up and running, while the Web Server Application is not running because of some software bug. These kinds of scenarios can be caught only by probing the application and not just the Server where Applicaton is running. Reporting Model: This metric needs to be associated with a defined time interval, which could be defined by fixed intervals. Based on need, the TWAMP client can negotiate to check the liveliness of a service during connection establishment. If so, then for each of the data packet, the liveliness of the service is measured and reported back to session-sender/client for the entire session.

Metric Name: Service Latency Metric Description: This indicates the total latency introduced by the service for a data packet which is undergoing that service. Please note that the latency calculation in service agnostic. Method of Measurement or Calculation: The Session-Reflector SHALL notedown the time: Service latency measurement Sender Timestamp and inject the Service PDU to the Service Block for service processing. When the Session-Reflector receives the response, the Session-Reflector SHALL notedown the time: Service latency measurement Receiver Timestamp. Units of Measurement: This metric is expressed as a timestamp which is 64 bit value. The format of the timestamp is the same as in [RFC1305] and is as follows: the first 32 bits represent the unsigned integer number of seconds elapsed since 0h on 1 January 1900; the next 32 bits represent the fractional part of a second that has elapsed since then. So, Timestamp is represented as follows:

Measurement Point(s) with Potential Measurement Domain: This metric is calculated at the Session-Reflector. Measurement Timing: This metric is an instantaneous value. Based on the kind of service it MAY be a good idea to store the history of this value. It can be stored as an average of last one hour for 24 hours, then average of all values over previous day, week, month, year etc. These data MAY be used for some analytics. Implementation: The Session-Reflector SHALL extract the service PDU from the TWAMP Payload and inject it to the service module. For ex, incase of http server, the service PDU can just be a http req. The injecting of service module can be broken into below steps: - Session Reflector should note down the time(say T5) at which this service PDU(http req) is injected to service module. - The service module will apply services on this PDU and once service processing is done, it would send the response(http resp) back to Session Reflector. - Once this response serviced PDU is received at Session Reflector, the time(say T6) SHOULD be noted. - The Session Reflector SHALL now reply back to the TWAMP client/session sender with the actual TWAMP data packet with payload being the 2 timestamps and the response service PDU(http resp). - Now the TWAMP client/session sender after receiving the packet back can calculate the service latency, which would be T6-T5. Verification: This metric value is a pair of timestamps. Service Latency will be calculated by subtracting the "Service latency measurement Sender Timestamp" from the "Service latency measurement Receiver Timestamp" The Session-Reflector MUST start the Packet Padding with the 16 octets indicated below. This SHALL be followed by the Service PDU(which MAY be same as whatever was sent by Session-Sender or can be the reply/response packet of the Service Block).

We would like to thank Perceival A Monteiro for their comments, suggestions, reviews, helpful discussion, and proof-reading

TWAMP Services KPIs Registry IANA is requested to reserve and maintain the below Services KPIs: Value Description Explanation 0 None 1 Keepalive Whether the respective service is running or not 2 Service Latency Service Latency which SHALL include the transit time and actual service time Request-TW-Session message defined in .IANA is requested to reserve 2 octets for Service ID as follows: Value Description Semantics Reference X Service ID 2 Octets starting from offset 92th Octet This document

The TWAMP protocol (RFC 5357) supports anthenticated and encrypted mode for TWAMP session and data. The implementation discussed in the proposed extension supports the authenticated and encrypted mode and is therefore provides a secure mechanism to monitor services KPIs in the network.