Technical details about PTPv2 on OS2

Hardware
1

Hi,

We plan to use an OS2 device. We are currently designing a GrandMaster PTPv2 in an FPGA and have a few technical questions to help us correctly define the scope of the FPGA design.

Transport mapping

  1. Do you use/support Annex C (UDP/IPv4), Annex D (UDP/IPv6), or Annex E (Ethertype 0x88F7)? Is it selectable, and what’s the factory default?

Delay mechanism
2) Do you require End-to-End (Delay_Req/Delay_Resp) or Peer-to-Peer (Pdelay_*)?

Two-step acceptance
3) Will the device sync correctly to a two-step master (Sync + Follow_Up)?

PTP version & profile
4) Which IEEE 1588 version (2008 vs 2019/v2.1) and profile (Default vs 802.1AS/gPTP)? What domainNumber do you use by default?

Role/BMCA behavior
5) Can the device be forced to Slave (ignore BMCA) when our FPGA is grandmaster?

Multicast/unicast use
6) Do you expect multicast only, or do you require unicast negotiation (Signaling TLVs)?

Message rates
7) Supported/recommended ranges for logSyncInterval, logAnnounceInterval, logDelayReqInterval.

L2/L3 framing details
8) If Annex C/D: which multicast group(s) (e.g., 224.0.1.129), required TTL, and any IGMP expectations?
9) If Annex E: acceptable destination MAC(s) (All-PTP 01-1B-19-00-00-00; Pdelay 01-80-C2-00-00-0E; unicast allowed?).

Thanks

Pierre

2

Hi Pierre,

Thanks for reaching out to the Ouster Community.
Please see the answers to your questions below.
If you need more hands-on support feel free to reach out to ouster.com/tech-support.

  1. Annex E (Ethertype 0x88F7) is the factory default and is not selectable

  2. It depends on the profile (aka config) you have selected on the sensor. Ouster sensors have verbatim configs from LinuxPTP

    1. default: E2E
    2. gPTP: P2P
    3. automotive-slave: P2P

  3. Yes in all profiles it will correctly sync to a two-step master. However, each profile starts with a different assumption on two-step. Ref: LinuxPTP Configs

    1. default: assume_two_step 0 (two step not assumed, but will still sync if master it using two-step)
    2. gPTP: assume_two_step 1 (two step assumed)
    3. automotive-slave: assume_two_step 1 (two step assumed)

  4. Ouster sensors have the following profiles: PTP HTTP API and are on version IEEE 1588v2 2008

  5. Yes, the automotive-slave profile can be use to force Slave mode

  6. Ouster sensors expect multicast.

  7. Ouster sensors follow the LinuxPTP configs verbatim, please refer to them for logSyncInterval, logAnnounceInterval, logDelayReqInterval

  8. N/A

  9. Yes, the verbatim LinxPTP profiles accept the following MACs. Ouster sensors only have profiles where unicast is not allowed.

    ptp_dst_mac 01:1B:19:00:00:00

    p2p_dst_mac 01:80:C2:00:00:0E

2 Likes
3

Great!

Thank you very much for this valuable information. I really appreciate it!

Have a great day!

Pierre

1 Like