Re: [Ntp] NTP over PTP

Miroslav Lichvar <> Tue, 29 June 2021 06:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E2AA3A283F for <>; Mon, 28 Jun 2021 23:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.296
X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Js07nlinWsPs for <>; Mon, 28 Jun 2021 23:52:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C8A23A283D for <>; Mon, 28 Jun 2021 23:52:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1624949538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yCX+dhzNNijexaXPxL1eiK3elW3c/SbJAbyEecf7T0Q=; b=atCzWhMGrCMugxVdAKWo9mER+4jq2K7V6HwdSgV7jsgIynnhyuS1leSRhSlATN3ZfD7Flf MexP/5MsfsMoBC3FEjGkWIWns2ztRX/CMSAy9h5XZLO7z+FhK1nBm59DtqZjr7S4e7fYCq mYdazpvsbKdLpoIatfEJxTrGx990k1o=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-482-YtZyXrR0OYy8nWDs4KRloA-1; Tue, 29 Jun 2021 02:52:16 -0400
X-MC-Unique: YtZyXrR0OYy8nWDs4KRloA-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8ACE2100CCC7; Tue, 29 Jun 2021 06:52:14 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 1D16A60C5F; Tue, 29 Jun 2021 06:52:12 +0000 (UTC)
Date: Tue, 29 Jun 2021 08:52:11 +0200
From: Miroslav Lichvar <>
To: Heiko Gerstung <>
Cc: "" <>
Message-ID: <YNrDGy2M2hpLz9zc@localhost>
References: <YNRtXhduDjU4/0T9@localhost> <> <YNnSj8eXSyJ89Hwv@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.79 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] NTP over PTP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jun 2021 06:52:23 -0000

On Mon, Jun 28, 2021 at 05:02:43PM +0200, Heiko Gerstung wrote:
> > The unicast mode seems to be intended for networks with partial
> > on-path hardware support, where requirements on accuracy are less
> > strict, and I think this might already be better supported by NTP.
> They might be less strict but that does not mean they are worse/equal compared to NTP.

How so?

You said unicast transparent clocks don't really exist. That would be
the only advantage of unicast PTP. Boundary clocks could fully support
hardware-timestamped NTP if someone was actually interested in
implementing that.

Without full on-path support NTP should generally perform better than
PTP as it doesn't assume network has a constant delay.

In the context of the drafts we are discussing here, I think it might
be easier for an existing PTP implementation to add support for
NTP+NTS than add NTS4UPTP.

> > If there is some hardware that can timestamp only fixed-length PTP
> > messages with no TLVs, then that will not work with any form of
> > NTS4UPTP either, right? There has to be some TLV to authenticate the
> > message and the hardware needs to accept that.
> No, that's not correct. The hardware timestamping is only required during phase 3 (packet transmission), which does not require an NTS TLV as it relies completely on the AUTHENTICATION_TLV and the integrated PTP security. See 3.3 of my draft. The NTS TLV is required in phase 2 where client and server only exchange messages to negotiate the transmission, and those are not hw timestamped. 

I don't see how that is relevant to hardware not timestamping PTP
messages with TLVs. If a TLV present in an event message breaks the
timestamping, the hardware is unusable for any security mechanism
discussed here, except the Daniel's idea to protect unauthenticated
PTP by authenticated NTP.

Miroslav Lichvar