QoD API specification version 0.8.0

[akoshunyadi]

QoD API specification version 0.8.0

[SyeddR]

The new spec looks good to me. Couple of ques

1. Are we expecting both ipv4 and ipv6 information to be provided in API? If only one type is required shall we use "anyof" in the spec? If both IPs are provided, is the expectation to create QoS for both ipv4 and ipv6 session?
2. There is a TFT limit device (UE) can support number of flows. If we are allowing port ranges and ports that would easily reach TFT limit. Are we going to enforce restriction in the API or is it left to operator's implementation

[eric-murray]

Hi @SyeddR

The idea is that the API consumer provides what information they know about the UE and AS sufficient to set-up the required session. If they wanted the enhanced QoS to apply to both IPv4 and IPv6 connectivity, then they would need to provide both addresses, at least for the AS. For the UE, any one of the 4 specified identifiers can identify the UE itself, though I agree this may lead to ambiguity as to intentions.

For example, if the API consumer provides both IPv4 and IPv6 addresses for the AS, but only an IPv6 address for the UE, does that mean they want enhanced QoS for both IPv4 and IPv6 flows, and only provided the UE IPv6 address to allow the UE to be identified, or do they only want the enhanced QoS for the IPv6 flow (in which case, why provide the AS Ipv4 address)? I think a lot of details about behaviour will come down to individual operator implementations of the API, and we cannot expect consistent behaviour across different implementations for all possible parameter values.

This also applies to your second point about port ranges and, indeed, IP subnets. Some subnets allowed by the specification (setting 0.0.0.0/0 for both UE and AS for example) are clearly ridiculous and would always be rejected. But there will be a "grey area" where some operators will accept a configuration request and others will not. It will be hard to avoid such discrepancies given that operator networks are not homogeneous and each has its own limitations. This also make it hard to tie down the interface specification to only allow parameter values and ranges to be specified that can be accepted by all API implementations.