"Flow Description" Mapping

[emil-cheung]

Current Camara QoD API does not have ”Flow Information” or “Flow Description” concepts that are in 3GPP NEF AsSessionWithQoS API. Instead, a parameterization approach is used, i.e., putting attributes such as “ueAddr”, “uePorts” etc. at the root level of the request data model, and expect the transformation layer to map them to “Flow Information”/”Flow Description”.

After evaluation, we see some limitations on this approach:

• This “flat” data model may be difficult to evolve to other features already supported by 3GPP NEF AsSessionWithQoS API, such as Ethernet flow and external app ID.
• Lose the flexibility to define multiple flows in an AS session.
• Confusing mapping of “protocolIn”/“protocolOut” to 3GPP Flow Description, since IP-based protocols are usually bi-directional.

[eric-murray]

I'm supportive of extending the API definition to allow the API consumer to request enhanced QoS levels for multiple flows. However, I would add the following comments:

• It should be possible to request different QoS levels for the different flows, as this may be a requirement for the service the developer is trying to create. If multiple calls are required to the NEF to action this, then so be it.
• To prevent the API consumer bundling unrelated flows into a single request, the API should either grant all or refuse all requests within a given API call. In the event that the request is refused, any undoing of intermediate configuration steps is up to the network operator.
• The proposed changes should not be incorporated into the API until the mechanism for identifying the target UE by GPSI is defined and also incorporated (camaraproject/WorkingGroups/issues/4).
• If the UE is identified by source IP address, no restriction should be placed within the API (e.g. in the documentation or any pattern/regex) on whether this is the public (NATed) or private address of the UE. It should be possible for the API consumer to specify either depending on their knowledge, though mobile operators may chose whether to support both or only one of these possibilities depending on their implementation.

[hdamker]

There are different points addressed in this issue and additional ones in Eric's comment. My proposal would be to split the points up into different issues which can be discussed and addressed independently. I see the following different issues in the discussion:

• Allow multiple flow descriptions: We deliberately have choosen the "flat" approach and to allow the request of one flow (description) per service request. Our target was to reduce the complexity of the 3GPP API definition and provide an easy-to-use API for the use cases we are aware of. We have not yet seen use cases were developers have the need to request multiple flows in one (transactional) service request. Therefore we don't recommend to start with the complexity of an array of flow descriptions. The proposal is to start with the simplified "flat" API and discuss on additional API for concurrent multiple flows separately later.

• Incorporating port options explicitly into the JSON schema: These parameter options are currently only mentioned in the API documentation (single port, range of ports, or even "*"). We would welcome a solution proposal. This could be addressed independent of the topic of single or multiple flows per service request. BTW: with these options the "flat" description of a single flow has already a lot of flexibility which covers a lot of use cases we are aware of with a single service request.

• Resolving the confusion of “protocolIn”/“protocolOut” with a better parameter design: I agree that the current parameters are confusing and that we need a better parameter design here, e.g. the bidirectional character of TCP in one parameter. Probably we need also to cover the case where UDP flows use different port combinations per direction. Open for proposals.

• Identifying the target device/UE by GPSI: As mentioned by Eric this is another issue which need to be addressed for the QoD API after the mechanism is agreed and it will be supported by the south-bound interfaces and/or there is a non-proprietary translation function available.

• Identifying a device (UE) via public and/or private IP address: That's as well an independent issue to discuss (unfortunatley a complex one). On the one side I tend to agree (as on the device the developer sees the private, on the backend the public IP address). But I'm concerned if this will lead to differences between operators, and developers would need to find out if an operator has implemented the one or the other option or both.

[SyeddR]

@shilpa-padgaonkar i dont see clarification of below two questions. Pasting the ques in this thread

1. Are ueAddr and asAddr subnet ranges and not individual IP addresses? What is the reason behind subnet range?
2. uePorts and asPorts are not singular. It will become complicated to create QoS flows for each of ueAddr/uePorts+asAddr/asPorts combination.How do we address that?

[eric-murray]

@hdamker The issue of identifying the UE by public and/or private IP address is indeed important. If identifying the UE by source IP address is to be retained as an option once identification by GPSI is supported, then the only use case that makes sense to me is when that is the public IP address, as any API consumer that knows the private IP address should also know the MSISDN. A public server, however, would be unlikely to know the MSISDN.

But if private IP addresses can still be specified, there is an additional issue not yet addressed which is that the private IP address may not be unique, and several UEs may have the same private address. How do you propose to resolve this ambiguity? The 3GPP solution is to specify an ipDomain parameter along with the private UE address, this parameter identifying which PGW allocated the UE private address. But the API consumer would not know this information, so that solution would not work here.

@SyeddR I agree that IP subnet ranges are unnecessary here, and Vodafone would not implement support for these (i.e. if the API consumer specified a subnet range other than /32, then we would return an error message). There is no obligation on MNOs to fully implement all capabilities that can be requested through a valid API call, but only to give sensible error messages for those capabilities that can be requested but have not been implemented. Other MNOs may choose to support subnet ranges if they see some commercial advantage in doing that.

Similar arguments apply to port ranges, but here I think that there are valid use cases where port ranges may be specified. For example, a UE may have multiple active TLS sessions with the target server, and each will have a separate source port. Indeed, specifying a port range is optional, and Vodafone would treat the absence of any specified port range to mean whatever ports were in use between the UE and the specified server, which could be multiple. Again, it is up to each MNO to decide what capabilities to implement, and which API calls to return an error for.

[hdamker]

@SyeddR @eric-murray Thanks for your questions and comments.

Regarding identifying UE: that is an common topic not only affecting QoD APIs, therefore the discussion in Commonatilies working group. I also see the ambiguity of IPv4 addresses in mobile networks, thanks for creating issue #34 for that. For all identifiers (including IPv6 private or public addresses, MSISDN of GPSI as proposed in Commonalities) the main question is how the API user will get this identifier. E.g. even for an application on the UE the dominating device operating systems aren't allowing to read the MSISDN.

Regarding IP subnet ranges: Fully agree that on UE side a range does not make sense and a sensible requirement is to have /32 here. On the application server side we got already requests from developers to allow broader ranges, e.g. to cover redundant backend servers. I suppose that the operator policy will here depend on the requested quality profile. For some profiles it might be ok to allow any application server in the internet (0.0.0.0/0), others might even need to be restricted to known edge servers. In short: I agree with operator policy and sensible error messages here.

Also agree with the proposal of @eric-murray regarding the handling of port ranges as optional and with "*" as default. Until now we have seen port ranges for UDP connections in use cases.

@SyeddR IP address and port ranges are supported by the flow description parameter we are handing over to the south-bound network API, so they are not adding complexity. Nevertheless the policy checks have to be done.

[shilpa-padgaonkar]

@emil-cheung : Could you kindly share the sample JSON you had shared during this topic presentation?

[shilpa-padgaonkar]

@emil-cheung : Thank you for sharing the material. It is uploaded here for future reference - QoD enhanced flow info

[lbertz02]

The IPv4Addr supports subnets and should be labelled as IPv4AddrMask or the mask should be dropped in order to not mislead the dev.

[hdamker]

@emil-cheung we have now new #51 which should superseding this one. Can we close here?