bmwg L. Contreras Internet-Draft Telefonica Intended status: Informational 3 March 2025 Expires: 4 September 2025 Calibration of Measured Time Values between Network Elements draft-contreras-bmwg-calibration-01 Abstract Network devices are incorporating capabilities for time stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. This draft proposes a methodology for Calibrating the measurements from different network element implementations in a common measurement scenario. Status of This Memo 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 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Contreras Expires 4 September 2025 [Page 1] Internet-Draft Time measurement calibration March 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Baseline measurement scenario . . . . . . . . . . . . . . . . 4 3. Network element calibration tests . . . . . . . . . . . . . . 4 3.1. Single network element test . . . . . . . . . . . . . . . 5 3.2. Paired network elements test . . . . . . . . . . . . . . 5 3.3. Measurement conditions . . . . . . . . . . . . . . . . . 6 3.4. Resolution of the calibration process . . . . . . . . . . 7 4. Further discussions . . . . . . . . . . . . . . . . . . . . . 7 4.1. Consideration of hybrid methods (e.g., IOAM) as measurement mechanisms for calibration assessment . . . . . . . . . . 7 4.2. Usage of instrumentation instead of physical fiber spools for determining the baseline value . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Latency is becoming one of the major drivers for network traffic engineering and planning due to the introduction of novel services sensitive to both latency and its variability. Network devices incorporate capabilities for time-stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. That is the case of the Flex Algo algorithms [RFC9502] [RFC9351] aiming to represent low latency topologies being based on the time reference measured among devices. Furthermore, services sensitive to latency, such as the deterministic ones [RFC8557], require from accurate information in order to place flows in the network. Contreras Expires 4 September 2025 [Page 2] Internet-Draft Time measurement calibration March 2025 The measurements here considered are those performed between neighbor nodes in a network, so that an end-to-end delay metric can be composed by aggregating partial measurements. (Note: in some scenarios, network elements, e.g. node A and B, can connect passing through another network element, e.g., node C, transparently, for instance, by means of a layer-2 connection. To be discussed if for such kind of scenarios the network elements A and B can be considered as neighbors in the context of this document). Different protocols are implemented nowadays on network devices to perform such measurements, such as TWAMP-light [RFC5357] [RFC8545] or STAMP [RFC8972]. It is then important to ensure that the time stamp produced by the network device is accurate so that the traffic engineering decisions based on such measurements are correct. Differences on accuracy of the measurements among devices can be due to different causes, such as different solutions for time stamping (e.g., hardware-based vs software-based), different module involved in the time stamping process (e.g., central processor vs line card), different type of component taking care of the timestamping (e.g., Network Processor, ASIC, hardware accelerator, etc), etc. The traffic engineering decisions will be typically implemented by centralized controllers, which can process the measurements and decide on the specific traffic engineering path. This can be the case of the Path Computing Element (PCE) [RFC5440]. It is important to note that any deviations or bias on the time stamps of the packets can lead to inaccurate calculations or decisions. An example is the following: Network Device A can introduce some delay (e.g., due to less powerful processing capabilities) in the timestamp versus Network Device B. In a dual-plane backbone, with similar characteristics in terms of physical path length, where one of the planes is built with network devices of type A while the other one is built with network devices of type B, the difference between the time stamps in A and B can lead to all the traffic being delivered by one of the planes if low latency flex algo topology is used. The purpose of this document is to present a benchmarking procedure to calibrate the time stamps of different network device implementations so that the observed measured can be corrected if needed during the processing of the measured time-stamped data. Contreras Expires 4 September 2025 [Page 3] Internet-Draft Time measurement calibration March 2025 2. Baseline measurement scenario In order to create a reference or baseline to later on compare the measurements obtained from distinct network elements, a reference scenario is defined. This reference scenario will serve to calibrate the time stamps of the different network devices. The reference scenario assume an instrumentation device generating and receiving TWAMP-light or STAMP packets. Those packets are delivered on a fiber spool of a given known length, L. Typical lengths for testing purposes are in the order of 20 - 100 kms. It can be assumed a delay of 5 us/km on that fiber spool [ITU-T-G.114]. The measurement setup is as follows: +------------+ | | +------------| tester |<-------------+ | | | | | +------------+ | | | | | | Fiber spool of length L | +----------------------------------------+ Figure 1: Baseline measurement scenario The tester will generate the baseline measurement for the time spent on delivering packets through the link represented by the fiber spool. Such a reference value can be defined as T_baseline and will serve for comparison of the measurements performed by the distinct implementations of network elements for calibration purposes. 3. Network element calibration tests Similar to the case before, it is possible to perform the same kind of test with actual network elements. Two scenarios are possible. * Performing the test with just one single network element, similar to the baseline scenario. This can be useful for characterizing the behavior of one specific network device implementation, for both hardware and software. * Performing the test between to network elements. This can be useful for determining interworking scenarios, considering either network elements from the same vendor but with different characteristics (e.g., network device model, hardware or software characteristics, etc), or network elements from different vendors. Contreras Expires 4 September 2025 [Page 4] Internet-Draft Time measurement calibration March 2025 3.1. Single network element test The scenario is similar to the baseline scenario, as follows. +------------+ | network | +------------| element |<-------------+ | | A | | | +------------+ | | | | | | Fiber spool of length L | +----------------------------------------+ Figure 2: Single network element test As before, the network element generates measurement packets through the link represented by the fiber spool. The obtained value can be referred as T_ne. The calibration exercise results from the comparison between T_baseline and T_ne. Note for discussion: consider the implications of connecting the fiber spool to ports / line cards of different characteristics in terms of hardware implementation. Maybe a restriction should be imposed in this kind of test to be performed considering the same kind of termination for the fiber spool. 3.2. Paired network elements test This scenario considers the measurement to be performed between a couple of network elements, as follows. +------------+ +------------+ | network | Fiber spool of length L | network | | element |<----------------------->| element | | A | | B | +------------+ +------------+ Figure 3: Paired network elements test The network elements can be from the same or different vendor. The purpose of this test is to calibrate measurements when the devices involved represent different implementations of the same network device functionality, including the protocol used for time stamping. Contreras Expires 4 September 2025 [Page 5] Internet-Draft Time measurement calibration March 2025 In this case, one of the network elements generates measurement packets through the link represented by the fiber spool of known length (and previously measured in the reference scenario). The obtained value can be referred as T_ne_ab, when the measurement is triggered from A to B. Similarly, it is possible to obtain T_ne_ba on the other direction. Assuming that both T_ne_ab and T_ne_ba produce the same result, the calibration exercise results from the comparison between T_baseline and T_ne_ab (or T_ne_ba). 3.3. Measurement conditions The measurements proposed should specify: * Network device model, hardware and software description. * Length of the fiber spool used as reference for the measurement. * Description of the ports / line card where the fiber spool is connected, since different line cards could produce measurements with different accuracy levels. * Protocol used in the measurement (e.g., TWAMP-light, STAMP, ...). * Duration of the test for statistical consistency (e.g., period for average, min, max calculations) * Network tester used for generating the baseline values. (Note: to consider scalability aspects on the collected measurements that could impact the calibration exercise. For instance, if multiple sessions are running in parallel from one node to several neighbor nodes, with one session per neighbor). (Note: to be discussed the possibility of considering asymmetric scenarios in the connection of network elements). (Note: to assess the extendibility of this approach to any network element, e.g. switches). Contreras Expires 4 September 2025 [Page 6] Internet-Draft Time measurement calibration March 2025 3.4. Resolution of the calibration process The calibration process of the time-stamps observed during the benchmarking methodology needs to take into account the time units of relevance for the purpose of the usage of such measurements. For instance, if the purpose is the generation of flex algo topologies based on delay, it should be taken into account that the delay field advertised when using IS-IS [RFC8570] or OSPF [RFC7471] is expressed in microseconds. Thus, differences below a microsecond are not relevant. (Note: a criteria should be discussed for rounding the values of the obtained measurements from both the tester and the different network elements). 4. Further discussions This is a placeholder for capturing topics that will be considered for next versions of the document. 4.1. Consideration of hybrid methods (e.g., IOAM) as measurement mechanisms for calibration assessment On-path hybrid methods, such as In situ Operations, Administration, and Maintenance (IOAM) [RFC9197] [RFC9326] allow the obtention of telemetry information that can be used for measuring delays in network links. The IOAM data can be embedded in different encapsulations. While these methods coud be used for collecting the metric of interest, in the context of calibrating hop-by-hop measurements, it would impose practical limitations. For instance, the need of generating individual flows per hop for the solely purpose of measuring the link delay. Furthermore, it would require the specification of the measurement conditions in terms of the flows used for embedding the telemetry data. 4.2. Usage of instrumentation instead of physical fiber spools for determining the baseline value Instrumentation equipment can introduce impairments in a link in a controlled manner, either as a deterministic or statistical manner. For the purpose of the calibration pursued in this document, the usage of instrumentation equipment can be considered instead of physical fiber spools by configuring deterministic delay values. Contreras Expires 4 September 2025 [Page 7] Internet-Draft Time measurement calibration March 2025 While this can be a proper approach, it presents some practical shortcomings. For instance, the need of supporting all the variety of interface bit rates of interest in the platforms to be calibrated. 5. Acknowledgements The author would like to thank Miguel Cros (Telefonica) for the valuable comments received. This work has been partially funded by the European Commission through the Horizon Europe SNS JU PREDICT-6G project (GA 101095890). 6. References 6.1. Normative References [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, . Contreras Expires 4 September 2025 [Page 8] Internet-Draft Time measurement calibration March 2025 [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, . [RFC9351] Talaulikar, K., Ed., Psenak, P., Zandi, S., and G. Dawra, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement", RFC 9351, DOI 10.17487/RFC9351, February 2023, . [RFC9502] Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica, R., and P. Psenak, "IGP Flexible Algorithm in IP Networks", RFC 9502, DOI 10.17487/RFC9502, November 2023, . 6.2. Informative References [ITU-T-G.114] "One-way transmission time", May 2003. [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, . Author's Address Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n 28050 Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com Contreras Expires 4 September 2025 [Page 9]