Waarom is tijd op het internet belangrijk?

De juiste tijd is cruciaal voor een steeds breder scala aan internettoepassingen en -diensten. Zo kunnen internetbeveiligingsprotocollen als TLS (voor veilige end-to-endcommunicatie), DNSSEC (voor veilige vertaling van domeinnamen naar IP-adressen) en RPKI (voor veilige routes op het internet) niet functioneren zonder de juiste tijd en hetzelfde geldt voor een functie als domeinnaamregistratie. Tijd speelt ook een cruciale rol in kritieke infrastructuren, die voor hun communicatie in toenemende mate gebruikmaken van het internet en internetprotocollen. Voorbeelden hiervan zijn ultrasnelle beurssystemen, elektriciteitsnetten, laadstations, scheepsnavigatie op afstand en telecomnetwerken.

Onnauwkeurige timing kan ernstige operationele gevolgen hebben, zoals gegevensverlies omdat back-upprogramma's te laat worden gestart of het voortijdig wissen van de cache van een DNS-resolver, en resulteren in prestatie- of beschikbaarheidsproblemen. Het is daarom van het allergrootste belang om betrouwbare tijddiensten te creëren voor internettoepassingen met uiteenlopende nauwkeurigheidseisen en deze diensten te beschouwen als 'eersteklas burgers' van de internetinfrastructuur. Dit staats haaks op de huidige situatie, waarin tijddiensten op het internet vaak een ondergeschoven kindje zijn.

Tijddistributie: het netwerktijdprotocol

Internettijddiensten zoals de veelgebruikte NTP Pool zijn doorgaans gebaseerd op het Network Time Protocol (NTP). NTP-infrastructuren verspreiden de tijd via een hiërarchie van tijdservers (zie Figuur 1), zodat ze grote aantallen internetapparaten kunnen bedienen. Het hoogste niveau wordt 'stratum 0' genoemd en bestaat uit referentieklokken, die de autoritatieve tijdbronnen van een NTP-infrastructuur zijn. Voorbeelden hiervan zijn op radio gebaseerde klokken (die bijvoorbeeld werken met gps) en terrestrische klokken (zoals cesium- of strontium-atoomklokken, quantumklokken of optische klokken). Stratum 1-servers krijgen hun tijd van rechtstreeks verbonden referentieklokken of via een tijdgevoelig netwerk (bijvoorbeeld gebaseerd op het Precision Time Protocol, zie hieronder). Stratum 2-servers synchroniseren hun tijd aan stratum 1-servers, en zo verder. Tijdservers in hetzelfde stratum kunnen ook op een peer-to-peermanier overeenstemming bereiken over hun tijd, zoals aangegeven door de horizontale pijlen in Figuur 1.

Figuur 1: Organisatie van een NTP-infrastructuur (gebaseerd op Wikipedia).

De nauwkeurigheid van stratum 1-servers is afhankelijk van die van de referentieklokken en van de hardware van de server zelf. Zo kan een op gps gebaseerde referentieklok de tijd verstrekken met een precisie van 30 nanoseconden of minder (95% van de tijd), terwijl een cesium-atoomklok in 300 miljoen jaar zelfs nog geen seconde zal verliezen. De hardware en software van een stratum 1-server zorgen doorgaans voor wat onvolkomenheden, dus in de praktijk zal de nauwkeurigheid iets lager zijn.

De meeste tijdconsumenten gebruiken een stratum 2+-server, die gewoonlijk gebruikmaakt van het internet om de tijd op te halen bij servers in de strata erboven. Daardoor kunnen NTP-pakketten onderhevig zijn aan vertragingen en vertragingsvariaties (jitter). Het NTP-algoritme voor kloksynchronisatie kan hiervoor compenseren en een precisie van tientallen tot rond de 100 milliseconden realiseren.

Tijdsynchronisatie met een precisie van microseconden of nauwkeuriger via het precisietijdprotocol

Een populair alternatief voor NTP is het Precision Time Protocol (PTP, IEEE1588), met een precisie van minder dan een milliseconde (microseconden of nauwkeuriger). Een dergelijke nauwkeurigheid is onder meer vereist voor kritieke toepassingen, die om te communiceren in toenemende mate gebruikmaken van het internet en internetprotocollen. Zo moet de tijd voor slimme elektriciteitsnetten op zijn minst tot op de microseconde nauwkeurig zijn, vragen ultrasnelle beurssystemen om een tot op de microseconde of zelfs nanoseconde nauwkeurige tijd en vergen telecommunicatiesystemen zoals CDMA een nauwkeurigheid van enkele microseconden. Deze geavanceerde toepassingen vereisen meestal ook een hoge stabiliteit, bijvoorbeeld een stabiele afwijking van 1 nanoseconde om schepen een haven binnen te loodsen.

PTP wordt over het algemeen eerder in laag 2-netwerken gebruikt dan op het internet (laag 3), zowel binnen lokale netwerken als netwerken die grote geografische gebieden beslaan (wide-area). PTP ondersteunt een nauwkeurigheid van minder dan een milliseconde, omdat PTP-switches tijdbewust zijn. Dit betekent dat ze kunnen compenseren voor de vertraging die ontstaat als een protocolbericht een switch passeert. Figuur 2 laat een voorbeeld zien van een PTP-pakket waarin de switch de vertraging heeft toegevoegd die het pakket in de switch heeft opgelopen, namelijk 2974 nanoseconden (correctionField).

https://images.ctfassets.net/yj8364fopk6s/5oWOYZiutJzFqIQd3obu18/2afe2788373c460ddc9723ea2a682641/Part_of_a_PTP_packet.png

PTP-netwerken zijn meestal gesloten, wat het voordeel heeft dat er minder risico is op aanvallen (bijvoorbeeld net als bij NTP-aanvallen), maar het nadeel is dat ze doorgaans niet beschikbaar zijn voor derden. Een ander protocol dat een precisie van minder dan een milliseconde biedt, is White Rabbit.

In deze blog noemen we netwerken die tijdbewuste protocollen zoals PTP en White Rabbit gebruiken tijdnetwerken.

Internettijd van minder dan een milliseconde is gebaseerd op een infrastructuur in ontwikkeling

Hoewel PTP al sinds 2002 een standaard is, staat de infrastructuur voor internettijd die tot op minder dan een milliseconde nauwkeurig is nog in de kinderschoenen. Er is sprake van maar een beperkt aantal operators van referentieklokken en wide-area-tijdnetwerken, die elk een specifieke regio of doelgroep bedienen. Internet exchange Netnod beheert bijvoorbeeld een PTP-netwerk in Zweden dat in dat land tot op de microseconde nauwkeurige tijd verstrekt. Daarnaast worden er momenteel verschillende tijdnetwerken geïmplementeerd of gepland voor wetenschappelijk onderzoek, zoals het landelijke netwerk van NPL (National Physical Laboratory) in het VK, het pilotnetwerk van de beheerder van het Nederlandse onderzoeks- en onderwijsnetwerk SURF, en CLONETS-DS, een pan-Europees tijdnetwerk in opdracht van de Europese Commissie. Voorbeelden van lokale tijdnetwerken zijn het microsecondetijdnetwerk dat datacenteroperator Equinix zijn klanten aanbiedt en ons netwerk voor TimeNL. Dat laatste netwerk maakt gebruik van PTP om de atoomklok die het als back-up gebruikt te synchroniseren met op radio gebaseerde referentieklokken.

Om de kwaliteit van tijdsignalen te beheren, maken tijdnetwerken steeds vaker gebruik van terrestrische referentieklokken omdat referentieklokken die werken met gps en andere radiosignalen gevoelig zijn voor jammen, spoofen of andere verstoringen. Beveiligingsonderzoekers hebben bijvoorbeeld geschetst hoe gerichte gps-verstoring kan leiden tot onnauwkeurigheden in NTP-tijdstempels door manipulatie van de meerderheidsprocedure die NTP-clients hanteren om de tijd te berekenen op basis van de tijdstempels die ze krijgen van verschillende upstream NTP-servers. Ook is er anekdotisch bewijs dat NTP-servers kunnen crashen als een aanvaller het gps-signaal verstoort door dit te spoofen of jammen. Gps-storingen vormen een reëel gevaar omdat ze 'in het wild' voorkomen. Zo werd in januari 2022 het vliegverkeer rond Denver Airport 33 uur lang verstoord door een onbekende gps-radiobron.

Voorbeelden van tijdnetwerken die werken met terrestrische klokken zijn die van Netnod en NPL, die de tijd verstrekken via cesium-atoomklokken in plaats van gps-ontvangers. Andere initiatieven die gericht zijn op het verkleinen van de afhankelijkheid van gps zijn het Amerikaanse overheidsinitiatief Complementary Positioning, Navigation, and Timing (PNT) and GPS Backup, de PNT-referentiearchitectuur en een initiatief vanuit de industrie genaamd OpenPNT.

In Europa is het terugdringen van de afhankelijkheid van satellietsystemen van derdelanden ook belangrijk met het oog op de strategische digitale autonomie.

De noodzaak van een open infrastructuur voor internettijd van minder dan een milliseconde

Het beperkte aantal spelers in de huidige infrastructuur voor tijd die minder dan een milliseconde afwijkt, is een probleem omdat dit het lastig maakt om diensten met die mate van nauwkeurigheid op internetbrede schaal aan te bieden. Het is voor internetserviceproviders (ISP's) bijvoorbeeld niet mogelijk om gemakkelijk een tijdsignaal op te halen bij meerdere providers van tijdnetwerken. Daardoor bestaat de kans dat de door hen geleverde 'sub-millisecond'-tijddiensten minder robuust zijn dan die van een NTP-infrastructuur (zie Figuur 1) of dan hun IP-connectiviteitsdiensten, waarvoor ze doorgaans samenwerken met meerdere redundante upstream ISP's. Bovendien fungeren operators van tijdnetwerken vaak ook als providers van referentieklokken, wat de flexibiliteit van de infrastructuur beperkt omdat referentieklokken niet door meerdere tijdnetwerken kunnen worden gedeeld.

Een belangrijke vereiste om dit probleem op te lossen is volgens ons het opzetten van wat we een 'OSub'-tijdinfrastructuur noemen: een open tijdinfrastructuur die het voor nieuwe spelers gemakkelijk maakt om 'sub-millisecond'-tijd te verstrekken, verspreiden en gebruiken. Om dit te bewerkstelligen, stellen we voor om (1) een reeks operationele best practices en opensourcesoftwarecomponenten te ontwikkelen voor operators van tijdbronnen, netwerken voor tijddistributie en internetdiensten waarmee ze hun tijddiensten kunnen optuigen en toevoegen aan de OSub-tijdinfrastructuur en (2) een database met de naam 'OSubTime-DB' op te zetten die het internetoperators zoals ISP's gemakkelijk maakt om netwerken voor tijddistributie te vinden en er verbinding mee te maken, net zoals operators van IP-netwerken met behulp van de welbekende PeeringDB besluiten hoe ze verbinding met het internet maken.

Onze visie op een OSub-tijdinfrastructuur

Figuur 3 toont een voorbeeld van de OSub-tijdinfrastructuur die we voor ogen hebben. De infrastructuur bestaat uit 4 verschillende rollen: providers van referentieklokken (bijvoorbeeld RCP1 t/m RCP4), providers van tijdnetwerken (TNP1 en TNP2), PoP's (P1 t/m P10) en internetproviders (ISP1 en ISP2). Spelers binnen een OSub-tijdinfrastructuur kunnen meerdere rollen combineren, net zoals Netnod voor het PTP-netwerk in Zweden zowel de rol van operator van een tijdnetwerk vervult als die van referentieklokprovider. Hoewel we ons richten op een publieke OSub-tijdinfrastructuur, voorzien we ook infrastructuren op basis van het gebied dat ze bestrijken (zoals lokaal, nationaal, regionaal) of de doelgroep die ze bedienen (bijvoorbeeld specifieke sectoren als energie of financiën).

Figuur 3: Een voorbeeld van een open infrastructuur voor internettijd van minder dan een milliseconde.

Een referentieklokprovider produceert een tijdsignaal met een precisie van minder dan een milliseconde (bijvoorbeeld tot op micro- of nanoseconden nauwkeurig). Voorbeelden zijn NPL, Equinix, SIDN en VSL, de beheerder van de officiële Nederlandse tijd. Referentieklokproviders opereren op stratum 0 in het NTP-model.

Een tijdnetwerkprovider beheert 1 of meer tijdnetwerken. Zo exploiteert TNP1 in Figuur 3 tijdnetwerken TN1 en TN2. We maken onderscheid tussen 'tier 1'- en 'tier 2'-providers. Tier 1-tijdnetwerkproviders (bijvoorbeeld TNP1 en TNP2) krijgen hun tijdsignalen van referentieklokproviders en distribueren deze naar tier 2-tijdnetwerkproviders, die tijdconsumenten bedienen. Tier 1-providers beheren meestal wide-area-netwerken, terwijl tier 2-providers meestal lokale netwerken beheren, bijvoorbeeld als onderdeel van een ISP-infrastructuur.

Een Point of Presence (PoP) is een faciliteit zoals een datacenter of internet exchange point die providers van referentieklokken en ISP's in staat stelt om verbinding te maken met tijdnetwerken. Zo maakt referentieklokprovider RCP1 verbinding met tijdnetwerkprovider TNP1 via PoP P1, terwijl ISP1 verbinding maakt met TNP1 via P4.

Een internetserviceprovider (ISP) beheert IP-netwerken (zoals IP1 in Figuur 3) en maakt verbinding met het bredere internet. In het voorbeeld in Figuur 3 fungeren de 2 ISP's (ISP1 en ISP2) ook als tier 2-tijdnetwerkproviders en bedienen ze gedistribueerde toepassingen voor op afstand beheerde offshore windparken. De ISP's maken verbinding met de tier 1-tijdproviders via de demarcatiepunten D1 en D2, die tijdgevoelige switches zijn.

Een tijdconsument krijgt zijn tijd van het lokale tijdgevoelige netwerk van de ISP via een switch (zoals D1 in Figuur 3) of via stratum 1 NTP-tijdservers (zoals T1 in Figuur 3), afhankelijk van de tijdvereisten van de consument. Zo maakt in Figuur 3 de exploitant die zijn windpark op afstand bestuurt gebruik van het lokale tijdnetwerk van ISP1 (TN3) voor tijd van minder dan een milliseconde, terwijl de mobiele telefoon NTP-server T1 of servers op een hoger stratum gebruikt voor tot op de milliseconde nauwkeurige tijd.

Operationele best practices voor OSub

De best practices die we voor een OSub-tijdinfrastructuur voor ogen hebben, hebben betrekking op verschillende aspecten van het bouwen en beheren van een tijdnetwerk. Er moet anders te werk worden gegaan dan bij een doorsnee IP-netwerk, omdat tijdnetwerken om een veel strakkere controle over de vertraging en jitter van het netwerk vragen.

We zijn in ons werk aan TimeNL onder meer de volgende 3 voorbeelden van best practices tegengekomen:

Netwerkontwerp: het transporteren van zeer nauwkeurige tijdsignalen is complexer dan het op basis van 'best effort' transporteren van IP-pakketten en vraagt om speciale netwerkontwerpen. Om bijvoorbeeld tijd met een afwijking van minder dan een milliseconde te transporteren via PTP, moeten alle tussenliggende switches PTP-bewust zijn, wat betekent dat ze kunnen compenseren voor de vertraging die wordt veroorzaakt door het doorsturen van het PTP-pakket binnen de schakelstructuur van de afzonderlijke nodes (zie het correctionField van PTP in Figuur 2). Alle paden in het tijdnetwerk moeten vrij zijn van 'obstakels' die de nauwkeurigheid negatief kunnen beïnvloeden, zoals niet-PTP-bewuste switches of asymmetrische paden. Daarnaast wordt PTP meestal geïmplementeerd via verbindingen op laag 2 en niet zozeer via IP (laag 3).

Beveiligingsontwerp: PTP-netwerken vereisen extra beveiligingsmaatregelen omdat het protocol eigenlijk is ontworpen voor gebruik binnen vertrouwde omgevingen. Daardoor is de oorspronkelijke specificatie minder geschikt voor een omgeving met tijdconsumenten die niet per se te vertrouwen zijn. Als een tijdconsument bijvoorbeeld een operationele fout maakt, kan deze zichzelf per ongeluk aankondigen als de beste klok in het netwerk (de 'time transmitter'), via het PTP-algoritme voor het selecteren van de beste klok, en er zo voor zorgen dat alle andere klokken, met inbegrip van de ware primaire klok, ermee worden gesynchroniseerd. Bescherming tegen dit soort ongewenste scenario's is lastig en vraagt om speciale maatregelen (bijvoorbeeld een lichte mate van filtering voor bepaalde PTP-pakketten) of een upgrade van de PTP-standaard (waaraan wordt gewerkt).

Netwerkbewaking: tijdnetwerken vereisen strenge controle van de kwaliteit van de dienstverlening, wat betekent dat ze grondiger moeten worden gemonitord dan typische 'best effort' IP-netwerken. Zo moeten operators controleren op variaties in de nauwkeurigheid (bijvoorbeeld met behulp van het programma PTP Trackhound van Meinberg), op padwijzigingen en of de juiste klok als primaire klok wordt gebruikt. Idealiter zouden operators de nauwkeurigheid van de tijd die ze verstrekken ook moeten monitoren vanuit het oogpunt van de consument en de precisie van hun tijdsignaal regelmatig door een externe auditor moeten laten toetsen aan atoomklokken.

Qua open source bestaat onze bijdrage aan de best practices momenteel uit een beveiligde opensource-implementatie van een PTP Boundary-Clock in de memory-safe programmeertaal Rust, die momenteel met financiering van SIDN fonds wordt ontwikkeld door onze partner Tweede Golf. Het is onze bedoeling om de tekortkomingen van PTP wat betreft bruikbaarheid en veiligheid aan te pakken, zoals het gegeven dat het niet ontworpen is voor gebruik in onbetrouwbare omgevingen zoals het netwerk van een ISP.

OSubTime4NL: een eerste, kleinschalig testbed

Om ons eerste pakket operationele best practices te verbeteren, zijn we in samenwerking met de Nederlandse internet exchanges AMS-IX en NL-ix bezig om hier in Nederland een kleinschalig OSub-tijdtestbed ('OSubTime4NL') op te zetten. Ons gemeenschappelijke doel is om erachter te komen wat ervoor nodig is om de rollen van internetoperator, tijdnetwerk en referentieklokprovider te combineren. Hiertoe zullen AMS-IX en NL-ix fungeren als PoP's, neemt NL-ix de rol van wide-area-tijdnetwerkprovider op zich en functioneren wij hier bij SIDN met behulp van TimeNL als referentieklokprovider.

Voor het uitvoeren van de pilot hebben we onze TimeNL-apparatuur overgebracht naar een datacenter in Arnhem, waar we verbinding kunnen maken met het laag 2-netwerk van NL-ix. NL-ix heeft een deel van hun infrastructuur zodanig geconfigureerd dat het PTP-bewust is, waardoor ze hun klanten tijd van minder dan een milliseconde kunnen leveren.

AMS-IX en NL-ix werken mee aan de pilot omdat ze beter willen begrijpen hoe ze hun klanten (ISP's) tijd van minder dan een milliseconde kunnen bieden. Onze insteek bij SIDN Labs is dat we willen helpen met het ontwikkelen van het concept van een OSub-tijdinfrastructuur, om zo toekomstige internettoepassingen mogelijk te maken en de aandacht te vestigen op het toenemende belang van tijdinfrastructuren.

Spelers met elkaar in contact brengen via OSubTime-DB

Om een OSub-tijdinfrastructuur zoals die in Figuur 3 op te zetten en te laten groeien, moeten providers van referentieklokken en ISP's kunnen beslissen via welke PoP's ze verbinding willen maken met een tijdnetwerk, analoog aan hoe autonome systemen aan de hand van de welbekende PeeringDB beslissen waar ze verbinding maken met het internet. ISP1 in Figuur 3 moet bijvoorbeeld selecteren met welke tijdnetwerken (TN1 en TN2) en via welke PoP's (P1, P2 en P3) hij wil peeren en welke referentieklokproviders (bijvoorbeeld RCP3) hij voor die netwerken wil gebruiken en klanten wil aanbieden.

Om dit te bewerkstelligen, introduceren we de OSubTime-DB, een database die de eigenschappen van tijdnetwerken beschrijft, zoals hun PoP's en de tijdsignalen die ze leveren (bijvoorbeeld nauwkeurigheid en type referentieklok). Laten we er als voorbeeld van uitgaan dat RCP1 zijn referentieklokken (RC1 en RC2) in de tijdinfrastructuur van Figuur 3 beschikbaar wil stellen via TN1. Hiertoe klopt RCP1 eerst bij de OSubTime-DB aan voor beschikbare tijdnetwerken en hun PoP's en selecteert hij een subset daarvan, bijvoorbeeld PoP P1 van tijdnetwerk TN1. Vervolgens trekt RCP1 een kabel naar P1 en zet er apparatuur neer (bijvoorbeeld een PTP-switch als TN1 is gebaseerd op PTP). Dan werkt de provider van TN1 (TNP1) zijn informatie in OSubTime-DB bij om te laten zien dat RC1 beschikbaar is via TN1 en past de metadata op zijn andere PoP's aan om de beschikbaarheid van RCP1 kenbaar te maken. Deze metadata bevatten de referentieklokken die RCP1 gebruikt (RC1 en RC2), hun nauwkeurigheid en andere gegevens zoals beveiligingscertificaten, het rechtsgebied van RCP1 en de eigenaar.

Op vergelijkbare wijze gebruikt een ISP de OSubTime-DB om te ontdekken welke tijdnetwerken beschikbaar zijn op welke PoP's en welk type referentieklokproviders deze ondersteunen. Op basis van deze gegevens bepaalt de ISP welke netwerken (bijvoorbeeld TN1), PoP's (bijvoorbeeld P2) en referentieklokproviders (bijvoorbeeld RCP1) moeten worden gebruikt om verbinding mee te maken.

Het beheer van OSubTime-DB

OSubTime-DB moet onder beheer staan van een toezichtsorgaan, vergelijkbaar met de beheerstructuur van PeeringDB. We denken hierbij aan een bescheiden bestuursorgaan dat een beperkt aantal beleidsmaatregelen instelt, bijvoorbeeld gericht op de kwaliteit van de gegevens in OSubTime-DB en op aanvaardbaar gebruik van OSubTime-DB. Om de veerkracht van OSub-tijdinfrastructuren te maximaliseren, moet het toezichtsorgaan de autonomie van spelers stimuleren en niet te veel beleidsmaatregelen instellen die de diversiteit van software, hardware en operationele procedures afremmen. Dit is in lijn met een belangrijke eigenschap van het internet, te weten gedecentraliseerd en gespreid eigendom en beheer en draagt bij aan de veerkracht van de OSub-tijdinfrastructuur.

Een bestuursorgaan kan aanvullende regels opstellen, bijvoorbeeld voor OSub-tijdsinfrastructuren voor specifieke sectoren (zoals de gezondheidszorg of energienetwerken). Providers van referentieklokken en tijdnetwerken zouden bijvoorbeeld kunnen worden verplicht om regelmatig hun prestaties en beveiliging te toetsen of referentieklokproviders binnen de tijdinfrastructuur zou kunnen worden opgelegd dat ze alleen met terrestrische atoomklokken mogen werken. Deze eisen kunnen bijvoorbeeld worden opgenomen in modelcontracten.

Wat de organisatie betreft, stellen we ons voor dat het toezichtsorgaan de voornaamste stakeholders van een OSub-tijdinfrastructuur vertegenwoordigt: referentieklokproviders, tijdnetwerkproviders, ISP's, PoP's en gebruikersgroepen zoals beheerders van kritieke infrastructuren en overheden. Dit is vergelijkbaar met de stuurgroepen van andere gezamenlijke initiatieven zoals MANRS (voor veilige routering) en de Nationale Anti-DDoS-Coalitie (voor gezamenlijke verdediging tegen DDoS-aanvallen).

Hoe gaan we verder?

Als de pilot met AMS-IX en NL-ix is afgelopen, willen we de geleerde lessen vastleggen in een eerste iteratie van een rapport met best practices voor OSub-tijdinfrastructuren. Daarnaast zijn we van plan om ons testbed OSubTime4NL uit te breiden met meer referentieklokproviders, tijdnetwerkproviders, PoP's en ISP's. We verwachten dat dit een eerste stap zal zijn naar een publiek Europees OSub-tijdinfrastructuur ('OSubTime4EU'), met bijvoorbeeld onder meer het Zweedse tijdnetwerk van Netnod.

Wat onderzoek betreft, willen we OSubTime-DB ontwikkelen en evalueren en mogelijk integreren in PeeringDB. Verder zijn we geïnteresseerd in NTP-onderzoek, zoals het in kaart brengen van de verschillende soorten referentieklokken van stratum 1-servers in de NTP Pool en andere tijddiensten en hoe deze in de loop van de tijd evolueren, bijvoorbeeld op basis van hun (niet-gestandaardiseerde) RefID-veld.

Wil je je aansluiten bij ons initiatief of feedback geven? Laat het ons weten!

Als je je wilt aansluiten bij OSubTime4NL of je gedachten over ons werk wilt delen, mail ons dan op sidnlabs@sidn.nl. Ook horen we graag van studenten die geïnteresseerd zijn in tijdgerelateerd onderzoek en bij ons hun afstudeerproject zouden willen doen.

Met dank aan

We danken Jan van Boesschoten (AMS-IX) en Jan Paul Dekker (NL-ix) voor het doornemen van de conceptversie van deze blog.