AM5748: Question to the PRP implementation and usage of NodesTtable

Hi Stephan,

I will talk with the team and get back with you early next week.

Regards,
Mike

Hi Stephan,

Thank you for your patience - I have a partial answer on the Linux driver side, and have a meeting with the firmware team to discuss further.

Regards,
Mike

Any updates on this topic in the meantime?

Thanks

Stephan

Hi Stephan,

Thank you for your patience.

I copied your original questions below to with each answer in bold for you to find easlier:

Is my assumption correct that:

1. the key attribute of the NodesTable is the MacAddress as received in the PRP_Supervision frame sent by a DANP or in any frame received from a SAN.
   Reception of a well-formed RCT is not a sufficient criterion to declare its source as DANP, since some protocols reply with the same frame as received.

   Correct

2. If destination node is not registered as a SAN in the NodesTable the frame will be appended by an RCT and send to LAN A and LAN B

   Correct

3. If the destination node is registered as a SAN frame to the port(s) where the SAN is registered

A SAN register at only one LAN or port, not both ports as defined in NOTE 1 of standard reproduced below:

NOTE 1 The NodesTable is populated by the received frames and distinguishes SANs from DANPs. The NodesTable allows a node to identify another node as SAN on one LAN only and in this case the node could send frames without an RCT over the port of that LAN only. A node without a NodesTable always sends all frames with an RCT over both ports, also when the destination is a SAN. In applications where broadcast traffic is the bulk, the impact on network load is small.

Sending information to network:

In case for any reason the DANP source node is not receiving any supervision frames from the DANP destination node, but other Frames on LAN A and LAN B including the proper RCT, the DANP destination node will send the frame to the DANP destination node on both ports without RCT, because it is registered as a single attached node causes by the missing supervision frames?

It will be registered as SAN AB node, frame will be sent to both the port and RCT will be removed for both.

Or is the behaviour of a DANP in sending direction different (like send always to LAN A and LAN B with RCT)?

RCT is removed in firmware (Linux always stick RCT for both copies send to port A and B) based on node table state of the destination node. If destination is DAN, RCT is retained in the outgoing frame or stripped if SAN.

Receiving information from the network:

For the receiving I assume the NodesTable entries are not relevant and the duplicate discard algorithm does not depend on the information if the source node is registered as DAN or not?

As per standard, node table is updated as well on received frame at port A and B. If SV frames are received, node is marked DAN or SAN-A or SAN-B.  Discard happens if RCT is present and frame received on both ports within the discard timer.