LISP Data-Plane Telemetrylispers.netSan JoseCAUSAfarinacci@gmail.comZededaSanta ClaraCAUSAsaid@zededa.comZededaSanta ClaraCAUSAerik@zededa.comThis draft specs a JSON formatted RLOC-record for telemetry data
which decapsulating xTRs include in RLOC-probe Map Reply messages.This document describes how the Locator/Identifier Separation
Protocol (LISP) can obtain, measure, and distribute data-plane
telemetry information. LISP is an encapsulation protocol built
around the fundamental idea of separating the topological location
of a network attachment point from the node's identity . As a result LISP creates two
namespaces: Endpoint Identifiers (EIDs), that are used to identify
end-hosts and routable Routing Locators (RLOCs), used to identify
network attachment points. LISP then defines functions for
mapping between the two namespaces and for encapsulating traffic
originated by devices using non-routable EIDs for transport across
a network infrastructure that routes and forwards using
RLOCs.This document specifies how a decapsulating xTR returns telemetry data
to an encapsulating xTR using RLOC-probe messages defined in
.Early versions of this document will define the type and format of the
telemetry data and how it will be distributed. Later versions of this
document will describe how telemetry measurement will be performed.is a LISP ITR, RTR, or PITR
data-plane network element . An encapsulating xTR
typically sends RLOC-probe Map-Request messages to decapsulating
xTRs to test for reachability of RLOC addresses. For the design
scope of this specification, RLOC-probes are also sent to obtain
LISP telemetry data measured by a decapsulating xTR.is a LISP ETR, RTR, or PETR
data-plane network element . A decapsulating xTR
typically RLOC-probe replies with a Map-Reply message to an
RLOC-probe Map-Request sent by an encapsulating xTR. When a
decapsulating xTR does data-plane telemetry measurement, it
returns measurement data in RLOC-probe Map-Reply messages to an
encapsulating xTR.a telemetry record is an
RLOC-record that contains telemetry data specified in this
document. The telemetry data is encoded as an LCAF JSON Type
specified in .The following list of telemetry data has been identified as being
useful to obtain:Packet Count - the number of packets received within a given
time window between the encapsulating xTR and decapsulating
xTR.Byte Count - the number bytes summed from all packets
received within a given time window between the encapsulating
xTR and decapsulating xTR.Packet Rate - the rate in packets per second an encapsulating xTR
is sending encapsulated packets to a decapsulating xTR.Bit Rate - the bit rate per second an encapsulating xTR is
sending encapsulated packets to a decapsulating xTR.Bandwidth - the amount of bandwidth used between encapsulating xTR and
decapsulating xTR in bytes per second.Packet Loss - the number of packets lost within a given time window
between the encapsulating xTR and decapsulating xTR.Packet Jitter - the amount of inter-packet time for a train
of packets within a given time window between the encapsulating
xTR and decapsulating xTR.Forward Hop-Count - the number underlay router hops from the
encapsulating xTR to the decapsulating xTR.Forward One-Way Latency - the amount of time from the
encapsulating xTR to the decapsulating xTR. Available when a
universal clock and rough time synchronization is available.Reverse TTL - the TTL value a decapsulating xTR is using for the
RLOC-probe Map-Reply. This is used to compute the return or Reverse
Hop-Count or number of underlay router hops between the decapsulating
xTR and encapsulating xTR.Reverse Timestamp - the universal clock timestamp when the
decapsulating xTR sent the RLOC-probe Map-Reply message. This is
used to compute the return or Reverse One-Way Latency between the
decapsulating xTR to the encapsulating xTR.A Telemetry Record is an RLOC-record encoded in LCAF JSON Type format
within the EID-record inserted in a RLOC-probe
Map-Reply message. The RLOC-record is appended to the existing RLOC-records
for the EID being probed.An encapsulating xTR does not need to request telemetry data
so the decapsulating xTR can provide it unilaterally by default or
via configuration to enable the feature. When an encapsulating xTR
receives a Telemetry Record in a RLOC-probe Map-Reply, it SHOULD NOT
store it in the map-cache and not use the RLOC-record for forwarding (since
there are no RLOCs in this record). The priority for this RLOC-record MUST
be set to 255 and the weight MUST be set to 0.The JSON key values imply directionality. The directionality is
from encapsulating xTR to decapsulating xTR. That is, the same
direction of RLOC-probe Map-Requests and encapsulated packet
flow. The JSON string format is defined to be:",
"packet-loss" : "",
"byte-count" : "",
"packet-rate" : "",
"bit-rate" : " ",
"bandwidth" : "",
"packet-jitter" : "",
"forward-latency" : "",
"forward-hop-count" : "",
"reverse-ttl" : "",
"reverse-timestamp" : ""
}
]]>JSON data values:JSON ValueEncoding Description<pc>Number of packets encoded as an integer value within a string.<pl>Number of lost packets encoded as an integer value within a
string.<bc>Number of bytes encoded as an integer value within a
string.<pr>Packet rate in packets per second encoded as an integer
value within a string.<br>Bit rate in kilobits per second encoded as an integer value
within a string.<b>Bandwidth in kilobytes encoded as an integer value within a
string.<pj>Packet jitter in milliseconds encoded as an integer value
within a string.<fl>Latency in milliseconds encoded as an integer value within
a string.<hc>Hop count encoded as an integer value within a string.<ttl>Map-Reply IP header TTL encoded as an
integer value within a string.<ts>Timestamp encoded in Linux UTC format
as an within a string (i.e. Tue Jun 26 16:27:25 UTC 2018).RLOC-probe Map-Reply messages are signed to protect and
authenticate the Telemetry Record according to details in . Telemetry Records can be kept
confidential by encrypting RLOC-probe Map-Reply message with the
asymmetric keys described in or the symmetric keys
computed by the key exchange detailed in .At this time there are no specific requests for IANA.The authors would like to thank the LISP WG for their review
and acceptance of this draft. A special thanks to Colin Cantrell
for his review, commentary and guidance.[RFC Editor: Please delete this section on publication as RFC.]Posted April 2024.Document timer and reference update.Posted October 2023.Document timer and reference update.Posted May 2023.Document timer and reference update.Posted November 2022.Included new references to standards track RFCs.Document timer and reference update.Posted May 2022.Document timer and reference update.Posted November 2021.Document timer and reference update.Posted May 2021.Document timer and reference update.Posted November 2020.Document timer and reference update.Posted June 2020.Document timer and reference update.Posted December 2019.Document timer and reference update.Posted June 2019.Document timer and reference update.Posted December 2018.Document timer and reference update.Initial draft posted June 2018.