Content Hosting Configuration handling uplift in 5GMSd AS

[rjb1000]

Context

The syntax of the Content Hosting Configuration has been modified to take into account implementation feedback from 5G-MAG:

• Cardinality of distributionConfigurations.domainNameAlias is ambiguous in Content Hosting Configuration Standards#16
• Cardinality of distributionConfigurations.canonicalDomainName does not match described usage in Create Content Hosting Configuration requests Standards#17
• Cardinality of ingestConfiguration.path is incorrect in Content Hosting Configuration Standards#18
• Use of path part of URL in IngestConfiguration.entryPoint for pull ingest Standards#19
• Inconsistency for parameter name requestPathPattern Standards#27
• ContentHostingConfiguration.distributionConfigurations.supplementaryDistributionNetworks inconsistencies. Standards#28
• DASH Media Player – APIs and Functions - M8 interface between application and provider Standards#29

The purpose of this issue is to modify the handling of the Content Hosting Configuration in the 5GMSd AF.

Specification

TS 26.512 V17.3.0 includes an updated TS26512_M1_ContentHostingProvisioning.yaml in annex C.3.5.
The internal data structures in the 5GMS AS need to be adjusted to take into account these changes, namely:

• IngestConfiguration.path and IngestConfiguration.entryPoint replaced by IngestConfiguration.baseURL. (Requests at M4d are mapped to this base URL at M4d for pull requests at M2d.)
• DistributionConfiguration.baseURL added. (M4d requests are made to this base URL assigned by the 5GMSd AF.)
• DistributionConfiguration.supplementaryDistributionNetworks redefined. (Rel-17 and later only. Only relevant to the 5GMSd AS when it is later integrated with MBMS, MBS, etc.)
• PathRewriteRule.requestPattern renamed to PathRewriteRules.requestPathPattern.
• ContentHostingConfiguration.entryPointPath added. (Not relevant to 5GMSd AS.)

[davidjwbbc]

A version of the current development AS with the v17.3.0 changes applied is available on the "feature/uplift-to-ts26-512-v17-3-0" branch in my forks of rt-common-shared and rt-5gms-application-server.

I'm currently working on a fix for the configuration of multiple provisioning sessions in NGINX and modifications to fix the uri vs uri-reference issue found in the specs.

[davidjwbbc]

Reworked the "feature/uplift-to-ts26-512-v17-3-0" branches in the forked repositories with the suggested "Draft v17.4.0" versions from 5G-MAG/Standards#36. Moved examples out of the rt-common-shared repository and split them between the Application Function and Application Server. The rt-5gms-application-server now contains a tests/examples directory containing suitable test files for the M3 test client. The rt-5gms-application-function will follow when I've pulled together the relevant updates from @devbbc to create a "feature/uplift-to-ts26-512-v17-3-0" there too.

[rjb1000]

The Change Requests for TS 26.512 were approved at SA#98-e last week. Publication of V17.3.0 will follow soon.

(Full details on the seven issues linked from the Context section in the main issue description above.)

[davidjwbbc]

I've now reworked the NGINX configuration writing to group distribution configurations appropriately. I've also tested this with two provisioning sessions at once. Each provisioning session had a Content Hosting Configuration which requested both HTTP and HTTPS distributions. The configuration written out groups the two HTTP distribution configurations under the same "server" configuration so that the port 80 server can serve all configured url prefixes (obtained from distributionConfigurations.baseURL). Because the SSL configurations have different certificates, they are written out as two separate "server" sections. This does present a problem if two provisioning sessions both only use the canonicalDomainName as the first one in the configuration will be picked to provide its certificate and URL path prefix. This situation is going to need some more thought as the current solution is not ideal. Using different canonicalDomainNames for each provisioning session, or insisting that AP's use domainNameAlias may be a solution here.

I'd like to do a little more testing before posting the PR as I've only done a few basic tests so far, but I think this is feature complete now.

[rjb1000]

To address the above problem, we could limit our reference implementation according to one of the following limitations:

1. The 5GMS AF rejects distribution configurations referencing a certificate without a domain name alias.
2. The 5GMS AF rejects a distribution configuration for a previously seen domain name (canonical or alias) but referencing a different server certificate.

A more elegant solution for distribution configurations not using a host name alias is for the 5GMS AF to allocate a unique canonical 5GMS AS domain name for each such distribution configuration. However, this requires either dynamic DNS updates by the 5GMS AF or else selection of canonical names from a pool of pre-registered DNS names.