According to 3GPP TS 29.244, the Node ID IE in a PFCP Session Establishment Response is mandatory.
When eUPF is reporting a failed session, the Node ID IE is missing.
This is giving us interop problems with a compliant decoder.
Since the Node ID is mandatory, there is no flag to indicate presence.
If we introduce a presence flag now to accomodate the non-compliant message, then all current users of the PFCP library will fail to set the presence to true on outgoing PFCP messages -- because so far the presence was implicit.
So it would be great if we could fix eUPF's compliance instead.
I expect no adverse effects from adding the missing Node ID.
To reproduce, for example, set a low pdr_map/far_map size and establish more sessions than that can support.
Observe PFCP response from eUPF.
The second such response in packet nr 8 reports a failure, wich lacks the Node ID.
Our CPF fails to validate the incoming message, and drops it.
Hence it re-sends the failed session establishment N times.
So a failure is aggregated by even more useless roundtrips and is hogging resources for a session at the CPF.
According to 3GPP TS 29.244, the Node ID IE in a PFCP Session Establishment Response is mandatory. When eUPF is reporting a failed session, the Node ID IE is missing.
This is giving us interop problems with a compliant decoder. Since the Node ID is mandatory, there is no flag to indicate presence. If we introduce a presence flag now to accomodate the non-compliant message, then all current users of the PFCP library will fail to set the presence to true on outgoing PFCP messages -- because so far the presence was implicit.
So it would be great if we could fix eUPF's compliance instead. I expect no adverse effects from adding the missing Node ID.
To reproduce, for example, set a low pdr_map/far_map size and establish more sessions than that can support. Observe PFCP response from eUPF.
An example is in this pcap: https://people.osmocom.org/neels/chuu0Che/eupf_lacks_node_id.pcapng (how brain damaged that I cannot attach a pcap here) The first PFCP Session Establishment Response contains the Node ID.
The second such response in packet nr 8 reports a failure, wich lacks the Node ID.
Our CPF fails to validate the incoming message, and drops it. Hence it re-sends the failed session establishment N times. So a failure is aggregated by even more useless roundtrips and is hogging resources for a session at the CPF.