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,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[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,
<https://www.rfc-editor.org/info/rfc7471>.
[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,
<https://www.rfc-editor.org/info/rfc8545>.
[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, <https://www.rfc-editor.org/info/rfc8570>.
[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,
<https://www.rfc-editor.org/info/rfc8972>.
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, <https://www.rfc-editor.org/info/rfc9197>.
[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,
<https://www.rfc-editor.org/info/rfc9326>.
[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,
<https://www.rfc-editor.org/info/rfc9351>.
[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,
<https://www.rfc-editor.org/info/rfc9502>.
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,
<https://www.rfc-editor.org/info/rfc8557>.
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]