Optional IS-IS Fragment Timestamping

Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks and advanced telemetry solutions. If such information is delayed during flooding it can be difficult for those applications to adequately fulfill their intended purpose. This document describes extensions to ISIS allowing it to carry the origination time on each fragment. The origination time can be used to aid troubleshooting of large domains and/or by the applications themselves to improve their behavior. As an example, in case of Traffic Engineered Networks synchronization of the Traffic Engineering Database (TED) enables the compute nodes to adapt to changes in the network state and/or react to network events in a timely manner. Relying on a synchronized TED while the flooding information is delayed can easily lead to service degradation due to substandard re-optimization of network load. The origination time proposed in this document is meant to be used by the compute nodes or by an operator of Traffic Engineered Network to measure any delays incurred in TED synchronization. The awareness of delays in the distribution of information can be incorporated further into algorithms and network tooling to improve the responsiveness and quality of decisions taken. A requirement for the correct interpretation of the additions proposed in this document is an infrastructure capable of synchronizing time across devices involved so the timestamps at the various points of interest become comparable. This could be accomplished by utilizing Precision Time Protocol (PTP) IEEE Std. 1588 or 802.1AS designed for bridged LANs. The achieved precision is carried in the timestamp of the fragment.

This section defines a new, optional TLV that can be present in any fragment. In case of multiple instances of the TLV in a fragment only the first occurrence MUST be used. The semantics of the TLV is the point in time the fragment with the current sequence number has been generated. Its absence signifies that such information is not available. For practical purposes, although desirable, timestamping the moment a fragment is flooded would be preferable but beside practical implementation problems this could generate on different interfaces the same fragment with different content which breaks one of the fundamental tenants of link-state protocols. However, an implementation is free to choose to use, e.g. the moment the fragment is queued for flooding first time rather than the time the version is generated. To save space the timestamp is following semantically with the exception of shorter seconds field including a wrap-around for the epoch and carrying only 2^-4 of a second as maximum resolution of the timestamp since this is considered sufficient for link-state purposes. The specification follows further guidelines of .

Type: TBD1
Length: ...
Seconds: 4 bytes of number of seconds since the PTP epoch and following its semantics at shortened length. Any value smaller than 0x5000_0000 (roughly AD 2012) MUST be considered as 2^32 + field value (i.e. a number larger than 2^32). The resulting wraparound will occur in the year 2078.
Fraction: 4-bits of fraction of the second in units of 2^-4 which is equivalent to 1/16 of a second or roughly 60 msec.
Precision: 4 bits indicating the maximum possible slip (either in future or past) of the clock used to generate the timestamp (depending on the synchronization protocol) as 2^-Precision where at minimum of the range 0 signifies 1 second precision (minimum required) and at maximum of the range 16 indicates a precision of 60 msecs or better. For practical purposes this can be as well the minimum precision of the synchronization protocol, e.g. stratum deviation.