| Internet-Draft | LISP Data-Plane Telemetry | May 2022 |
| Farinacci, et al. | Expires 10 November 2022 | [Page] |
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 November 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.ietf-lisp-rfc6830bis]. 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 [I-D.ietf-lisp-rfc6833bis].¶
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.¶
The following list of telemetry data has been identified as being useful to obtain:¶
A Telemetry Record is an RLOC-record encoded in LCAF JSON Type format [RFC8060] 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:¶
{ "type" : "telemetry",
"packet-count" : "<pc>",
"packet-loss" : "<pl>",
"byte-count" : "<bc>",
"packet-rate" : "<pr>",
"bit-rate" : "<br>",
"bandwidth" : "<b>",
"packet-jitter" : "<pj>",
"forward-latency" : "<fl>",
"forward-hop-count" : "<hc>",
"reverse-ttl" : "<ttl>",
"reverse-timestamp" : "<ts>"
}
¶
JSON data values:¶
| JSON Value | Encoding 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 [I-D.ietf-lisp-sec]. Telemetry Records can be kept confidential by encrypting RLOC-probe Map-Reply message with the asymmetric keys described in [I-D.ietf-lisp-ecdsa-auth] or the symmetric keys computed by the key exchange detailed in [RFC8061].¶
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.]¶