bmwg L. Contreras Internet-Draft Telefonica Intended status: Informational 21 October 2024 Expires: 24 April 2025 Calibration of Measured Time Values between Network Elements draft-contreras-bmwg-calibration-00 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 24 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Contreras Expires 24 April 2025 [Page 1] Internet-Draft Time measurement calibration October 2024 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 . . . . . . . . . . . . . . . . 3 3. Network element calibration tests . . . . . . . . . . . . . . 4 3.1. Single network element test . . . . . . . . . . . . . . . 4 3.2. Paired network elements test . . . . . . . . . . . . . . 5 3.3. Measurement conditions . . . . . . . . . . . . . . . . . 6 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 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. That is the case of the Flex Algo algorithms [RFC9502] [RFC9351] aiming to reflect low latency topologies which are based on the time reference measured among devices. Furthermore, services sensitive to latency, as the deterministic ones [RFC8557], require from accurate information in order to place flows in the network. The measurements here considered are those performed between neighbour network elements in a network, so that an end-to-end delay metric can be composed by aggregating partial measurements. Contreras Expires 24 April 2025 [Page 2] Internet-Draft Time measurement calibration October 2024 (Note: in some scenarios, netowrk elements, e.g. node A and B, can connect passing through another network element, e.g., node C, transparently, e.g., by means of a layer-2 connection. To be discussed if for such kind of scenarios the network elements A and B can be cosnidered as neighbours 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 are correct. Differences on the measurements among devices can be due to different causes, such as different solution 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. Those 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 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 and the other one 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 2. Baseline measurement scenario In order to create a reference or baseline to later on compare the measurements obtained from network elements, a reference scenario is defined. This reference scenario will serve to calibrate the time stamps of the different network devices. Contreras Expires 24 April 2025 [Page 3] Internet-Draft Time measurement calibration October 2024 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 lenght, 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 throuhg 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 characterizingthe 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. 3.1. Single network element test The scenario is similar to the baseline scenario, as follows. Contreras Expires 24 April 2025 [Page 4] Internet-Draft Time measurement calibration October 2024 +------------+ | network | +------------| element |<-------------+ | | A | | | +------------+ | | | | | | Fiber spool of length L | +----------------------------------------+ Figure 2: Single network element test As before, the network element generates measurement packets throuhg 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 measuremnet 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 callibrate measurements when the devices involved represent different implementations of the same network device functionality, including the protocol used for time stamping. Contreras Expires 24 April 2025 [Page 5] Internet-Draft Time measurement calibration October 2024 In this case, one of the network elements generates measurement packets throuhg 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 trigerred 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. (Note: to assess the differences of distinct line card / port behavior on the same network element; check if this can be a meaningful difference). * 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 neighbour nodes, with one session per neighbour). (Note: to discuss about the resolution of the measurement got from both the tester and the different network element implementations). (Note: to be discussed the possibility of considering assymetric scenarios in the connection of network elements). (Note: to assess the extendibility of this approach to any network element, e.g. switches). Contreras Expires 24 April 2025 [Page 6] Internet-Draft Time measurement calibration October 2024 4. 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). 5. References 5.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, . [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, . [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, . [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, . 5.2. Informative References Contreras Expires 24 April 2025 [Page 7] Internet-Draft Time measurement calibration October 2024 [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 24 April 2025 [Page 8]