Skip to main content

Data-plane probe for in-band telemetry collection

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Petr Lapukhov ,
Last updated 2016-12-12 (Latest revision 2016-06-10)
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


Detecting and isolating network faults in IP networks has traditionally been done using tools like ping and traceroute (see [RFC7276]) or more complex systems built on similar concepts of active probing and path tracing. While using active synthetic probes is proven to be helpful in detecting data-plane faults, isolating fault location is a much harder problem, especially in diverse networks with multiple active forwarding planes (e.g. IP and MPLS). Moreover, existing end-to-end tools do not generally support functionality beyond dealing with packet loss - for example, they are hardly useful for detecting and reporting transient (i.e. milli- or even micro-second) network congestion. Modern network forwarding hardware can allow for more sophisticated data-plane functionality that provides substantial improvement to the isolation and identification capabilities of network elements. For example, it has become possible to encode a snapshot of a network element's state within the packet payload as it transits the device. One example of such state would be queue depth on the egress port taken by that specific packet. When combined with a unique device identifier embedded in the same packet, this could allow for precise time and topological identification of the the congested location within the network. This document proposes a format for requesting and embedding telemetry information in active probes, i.e. packet designated for actively testing the network while not carrying application traffic. These active probes could be conveyed over multiple protocols (ICMP, UDP, TCP, etc.) and the document does not prescribe any particular transport. In addition, this document provides recommendations on handling the active probes by devices that do not support the required data-plane functionality.


Petr Lapukhov

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)