Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 29.500  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3.2…   5.2.3.3…   5.2.4…   6…   6.3…   6.4…   6.5…   6.6…   6.7…   6.10…   6.10.3…   6.10.6…   6.10.11…   6.10.12…   6.11…   A   B   C   D… 
6.10 Support of Indirect Communication  6.10.1 General  6.10.2 Routing Mechanisms with SCP Known to the NF  6.10.2.1 General  6.10.2.2 HTTP/2 connection management  6.10.2.3 Connecting inbound  6.10.2.4 Pseudo-header setting  6.10.2.5 3gpp-Sbi-Target-apiRoot header setting  6.10.2.6 Cache key (ck) query parameter  6.10.2A Routing Mechanism with SCP Unknown to the NF  6.10.2A.1 Connecting inbound  6.10.2A.2 HTTP/2 connection management  6.10.2A.3 Pseudo-header setting 
...

 

6.10  Support of Indirect Communication |R16|  p. 104

6.10.1  General  p. 104

NF Service Consumers and NF Service Producers may support or be configured to use Indirect Communication models via SCP as specified in clauses 6.3 and 7.1 of TS 23.501. This clause defines specific requirements to support Indirect Communication models. Specific requirements to support indirect communication between different PLMNs with or without delegated discovery with possible NF selection at target PLMN are defined in clause 6.10.12.
An SCP may be known to the NF (e.g. SCP based on independent deployment units) or not (e.g. SCP based on service mesh, with co-located NF and SCP within the same deployment unit). If the SCP is known to the NF, the NF shall be configured with a scheme, authority, and optionally a deployment-specific prefix of the SCP. The scheme may be "http" or "https". If the scheme is "https" then the authority shall contain an FQDN and not a literal IP address. If the scheme is "http" then the authority shall contain either an FQDN or a literal IP address. In either case, the authority may optionally contain a port number. If the SCP is known to the NF, but the NF is not configured with a deployment-specific prefix of the SCP, the NF shall consider the deployment-specific prefix of the SCP to be empty. If the SCP is unknown to the NF, the NF may still be configured to use delegated discovery through the unknown SCP as detailed in Clause 6.10.2A.
Indirect Communication models shall support the same level of security as Direct Communication ones. Security requirements for Indirect Communications are specified in clause 5.9.2.4 of TS 33.501 and clause 13.3 of TS 33.501. TLS shall be used between the SCP and NFs, if network security is not provided by other means. When co-located, the NF and associated SCP may interact using HTTP. Clause 6.7.5 specifies how to support the client credentials assertion and authentication procedure specified in clause 13.3.8 of TS 33.501.
More than one SCP may be present in the communication path between an NF Service Consumer and an NF Service Producer. Clause 6.2.19 of TS 23.501 and clause 6.3.16 of TS 23.501 describe how to route messages through SCPs.
Up

6.10.2  Routing Mechanisms with SCP Known to the NF  p. 105

6.10.2.1  General  p. 105

The routing mechanisms specified in clause 6.1 shall apply for Indirect Communication models with the additions or modifications specified in this clause. This routing mechanism shall be used when TLS is used between the NF and the SCP, or between two SCPs. This routing mechanism may also be used when TLS is not used, i.e. when network security is provided by other means.

6.10.2.2  HTTP/2 connection management  p. 105

Separate HTTP(S) connections shall be set up between the HTTP client and the SCP, between SCPs (if there is more than one SCP in the communication path between the HTTP client and the HTTP server), and between the SCP and the HTTP server. HTTP CONNECT requests shall not be used for Indirect Communication models.
The NFs and the SCP shall manage the HTTP/2 connections as defined in clause 5.2.6.

6.10.2.3  Connecting inbound  p. 105

If the request is not satisfied by a local cache, the NF (acting as an HTTP/2 client) shall connect inbound by establishing (or reusing) a connection to an available SCP as defined in Section 7.3.2 of RFC 9110 when sending HTTP/2 request.
When forwarding a request to another SCP, an SCP shall connect inbound by establishing (or reusing) a connection to the next hop SCP.
When the SCP forwards the request to the HTTP server, the SCP (acting as an HTTP/2 client) shall connect inbound to an authority server for the target resource. For connecting inbound to an authority not in the same PLMN, the SCP shall connect to the Security Edge Protection Proxy.
Up

6.10.2.4  Pseudo-header setting  p. 105

For Indirect Communications with or without delegated discovery, when sending a request to the SCP, the HTTP client shall set the pseudo-headers as follows:
  • ":scheme" set to "http" or "https";
  • ":authority" set to the FQDN or IP address of the SCP (if the scheme is "http"), or to the FQDN of the SCP (if the scheme is "https");
  • ":path" including the optional deployment-specific string of the SCP and the path and query components of the target URI excluding the optional deployment-specific string of the target URI.
An HTTP client which has not received information whether the callback URI contains any deployment specific string or not shall behave assuming that there is no deployment specific string in the callback (i.e. target) URI. If the HTTP client has previously received the prefix of the callback URI it shall include it, if available, in the 3gpp-Sbi-Target-apiRoot header (see clause 6.10.2.5).
When an HTTP client sending a notification request corresponding to default notification subscription where the target URI is unknown (e.g. for Indirect Communication with Delegated Discovery, as specified in clause 6.10.3.3), it shall include the optional deployment-specific string of the SCP and the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") in the ":path".
Additionally, for HTTP requests for which an HTTP client may cache responses (e.g. GET request), the HTTP client should include the cache key (ck) query parameter set to an implementation specific value that is bound to the target NF (see clause 6.10.2.6).
The HTTP client shall include the apiRoot of an authority server for the target resource (including the optional deployment-specific string of the target URI), if available, in the 3gpp-Sbi-Target-apiRoot header (see clause 6.10.2.5).
When forwarding a request to another SCP, an SCP shall replace the apiRoot of the SCP received in the request URI of the incoming request by the apiRoot of the next hop SCP. The SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource (including the optional deployment-specific string of the target URI), if available, e.g. if the 3gpp-Sbi-Target-apiRoot header was received in the request. The SCP shall set the pseudo-headers as specified in clause 6.1, with the following additions:
  • the SCP shall modify the ":authority" HTTP/2 pseudo-header field to the FQDN or IP address of the next hop SCP (if the scheme is "http"), or to the FQDN of the SCP (if the scheme is "https").
  • the SCP shall remove any optional deployment-specific string of the SCP in the ":path" HTTP/2 pseudo-header and add any optional deployment-specific string of the next hop SCP;
  • the SCP shall remove the cache key query parameter, if this parameter was received in the request;
  • if the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") is present in the ":path", the SCP shall replace it with the real path of the target URI registered in the selected default subscription.
When forwarding a request to the HTTP server, the SCP shall replace the apiRoot of the SCP received in the request URI of the incoming request by the apiRoot of the target NF service instance. If the 3gpp-Sbi-Target-apiRoot header was received in the request, the SCP shall use it as the apiRoot of the target NF service instance, if the SCP does not (re)select a different HTTP server, and regardless shall remove it from the forwarded request. The SCP shall set the pseudo-headers as specified in clause 6.1, with the following additions:
  • the SCP shall modify the ":authority" HTTP/2 pseudo-header field to the FQDN or IP address of the target NF service instance (if the scheme is "http"), or to the FQDN of the target NF service instance (if the scheme is "https").
  • the SCP shall remove any optional deployment-specific string of the SCP in the ":path" HTTP/2 pseudo-header and add any optional deployment-specific string of the target URI;
  • the SCP shall remove the cache key query parameter, if this parameter was received in the request;
  • if the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") is present in the ":path", the SCP shall replace it with the real path of the target URI registered in the selected default subscription.
EXAMPLE 1:
For indirect communication without delegated discovery, if the NF Service Consumer needs to send the request "GET https://example.com/a/b/c/nudm-sdm/v1/{supi}/nssai" to the NF Service Producer (represented by the FQDN "example.com" and where "/a/b/c" is the "apiPrefix" of the NF service producer figured out from NRF discovery):
EXAMPLE 2:
For indirect communication, if the NF Service Producer needs to send a notification request "POST https://example.com/a/b/c/notification" to the NF Service Consumer (represented by the FQDN "example.com", i.e. the host part of the callback URI):
EXAMPLE 3:
For indirect communication with Delegated Discovery, if the NF Service Producer needs to send a notification request to a default subscription and SCP selects a target default notification subscription (with callback URI "https://example.com/a/b/c/notification" registered):
EXAMPLE 4:
For indirect communication, if the NF Service Producer needs to send a notification request "POST https://example.com/prefix123/a/b/c/notification" to the NF Service Consumer with a callback URI Prefix "/prefix123":
Up

6.10.2.5  3gpp-Sbi-Target-apiRoot header setting  p. 107

For Indirect Communications with or without delegated discovery, the HTTP client shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the SCP. In particular:
  • for Indirect Communication without Delegated Discovery, a service request sent to the SCP to create a resource shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected NF service instance of the NF Service Producer, if the NF Service Consumer has indeed selected a specific NF service instance;
  • after a resource has been created, subsequent service requests sent to the SCP and targeting the resource shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot received earlier in Location header of service responses from the NF Service Producer;
  • notifications or callbacks sent via the SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the notification or callback URI (i.e. "http" or "https" scheme, the fixed string "://" and authority (host and optional port) as defined in RFC 3986 followed by the Callback URI prefix when available).
An SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the next hop SCP. In particular:
  • if the received request does not include a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, and NF service discovery is not delegated to a next hop SCP, then the SCP shall select a target NF service instance (performing an NF service discovery with the NRF or based on local configuration (i.e. without interacting with NRF) according to the received "3gpp-Sbi-Discovery-*" request header(s)) and insert a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected target NF service instance;
  • if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, but the SCP needs to reselect a different NF service instance, the SCP shall modify and set the 3gpp-Sbi-Target-apiRoot header to the apiRoot of the newly selected target NF service instance;
  • if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance and the SCP does not reselect a different NF service instance, the SCP shall forward the received 3gpp-Sbi-Target-apiRoot header to the next hop SCP.
When forwarding the request to the HTTP server, the SCP shall set the pseudo-headers as specified in clause 6.10.2.4.
Up

6.10.2.6  Cache key (ck) query parameter  p. 107

The cache key (ck) query parameter may be used by cache systems in the NF service consumer and/or in the SCP in order to distinguish cache objects.
It shall be set to a string value that is linked to the apiRoot of the target NF, i.e. the same apiRoot shall always produce the same value for the content of the ck parameter. The ck parameter may contain e.g. a short compact hash value of the whole apiRoot of the target NF.
The ck parameter shall only be used in HTTP requests between the NF service consumer and the SCP, it shall not be sent to the actual NF service producer.
The ck parameter is not part of the actual service definition and therefore it is not documented in OpenAPI specification files. It shall comply with the following OpenAPI definition:
paths: 
  /<resource>:
    <method>:
      parameters:
        - name: ck
          in: query
          description: cache key parameter
          schema:
            type: string
Up

6.10.2A  Routing Mechanism with SCP Unknown to the NF  p. 108

6.10.2A.1  Connecting inbound  p. 108

When indirect communication models are used and a NF sends an HTTP/2 request, this NF (acting as an HTTP/2 client) shall connect directly to an authority for the target resource via an available SCP, which then acts as an "interception proxy" as defined in Section 2.5 of RFC 3040 and also referred to in Section 3.7 of RFC 9110. This routing mechanism is incompatible with and shall not be used when TLS is used between the NF and the SCP.
Up

6.10.2A.2  HTTP/2 connection management  p. 108

The NF shall manage the HTTP/2 connections as defined in clause 5.2.6.

6.10.2A.3  Pseudo-header setting  p. 108

The NF service consumer shall set the following pseudo-headers:
  • ":scheme" pseudo-header shall be set to "http";
  • ":authority" pseudo-header shall be set as follows:
    • if delegated discovery is used and has not yet been performed by the SCP, or if the NF Service Consumer only selects a target NF (service) set when in Indirect Communication without delegated discovery: set based on local configuration.
    • if delegated discovery is not used or has already been performed by the SCP: set as specified in clause 6.1.4.
  • ":path" pseudo-header shall include the path and query components of the target URI as specified in clause 6.1.4.
Up

Up   Top   ToC