Content Hosting Configuration handling uplift in 5GMSd AS about rt-5gms-application-server

[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.