6.1 Routing Mechanisms

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

6.1.1 General

This clause specifies the generic routing mechanisms in the 5GC. Specific requirements to support Indirect Communication are further defined in clause 6.10.

For HTTP message routing between Network Functions, the message routing mechanism as specified in clause 5 of IETF RFC 7230 [12] is almost followed with some differences due to the adoption of HTTP/2 and to some 5G system specificities.

NOTE: The term "inbound" are defined in clause 2.3 of IETF RFC 7230 [12]. It describes a directional requirement in relation to the request route: "inbound" means toward the origin server.

6.1.2 Identifying a target resource

The target resource is identified by a target URI (e.g. a Resource URI, a Custom operation URI or a Callback URI as defined in clause 4.4 of 3GPP TS 29.501 [5]).

6.1.3 Connecting inbound

If the request is not satisfied by a local cache, then the client shall connect to an authority server for the target resource or to a proxy.

If a proxy is applicable for the target URI, the client connects inbound by establishing (or reusing) a connection to that proxy as defined in clause 5.2 of IETF RFC 7230 [12]. For connecting inbound to an authority not in the same PLMN, the client connects to the Security Edge Protection Proxy.

If no proxy is applicable, then the client connects directly to an authority server for the target resource as defined in IETF RFC 7230 [12].

6.1.4 Pseudo-header setting

6.1.4.1 General

Once an inbound connection is obtained, the client sends a request message over the wire. The message starts with a HEADERS frame containing the Pseudo-Header Fields identifying the request target. The ":method" pseudo-header is always present.

When sending a request directly to an origin server or to a proxy, other than a CONNECT or server-wide OPTIONS request, a client shall include the below pseudo-headers:

– ":scheme".

– ":authority".

– ":path" includes the path and query components of the target URI. The path includes the optional deployment-specific string of the Resource URI or Custom operation URI "apiRoot" part.

When sending a CONNECT request to a proxy, a client shall include the ":authority" pseudo-header. The ":scheme" and ":path" ones shall be absent.

When sending a server-wide OPTIONS request to an origin server or to a proxy, a client shall include the below pseudo-headers:

– ":scheme".

– ":authority".

– ":path" set with the value "*".

6.1.4.2 Routing within a PLMN

For HTTP/2 request messages where the target URI authority component designates an origin server in the same PLMN as the client, the ":authority" HTTP/2 pseudo-header field shall be set to:

":authority" = uri-host [":" port] as specified in clause 8.1.2.3 of IETF RFC 7540 [7], excluding the [userinfo "@"] information as specified in clause 3.2 of IETF RFC 3986 [14].

Where the uri-host shall be:

– FQDN of the target NF service; or

– IP address of the target NF service

The FQDN of the target NF service need not contain the PLMN identifier.

6.1.4.3 Routing across PLMN

6.1.4.3.1 General

In order to reach the correct target NF service in the right PLMN and for HTTP/2 request messages where the target URI authority component designates an origin server not in the same PLMN as the client, the ":authority" HTTP/2 pseudo-header shall contain the FQDN including the PLMN ID.

The ":authority" pseudo-header field in the HTTP/2 request message shall be set to:

":authority" = uri-host [":" port] as specified in clause 8.1.2.3 of IETF RFC 7540 [7], excluding the [userinfo "@"] information as specified in clause 3.2 of IETF RFC 3986 [14].

Where the uri-host shall be:

– FQDN of the target NF service or the FQDN (authority) part of a callback URI or a specified link relation

The FQDN of the target NF service or the FQDN (authority) part of a callback URI or a specified link relation shall contain the PLMN identifier.

The format of the FQDN of target NF service is specified in clause 28.5 of 3GPP TS 23.003 [15].

To allow for TLS protection between the SEPP and Network Functions within a PLMN, the SEPP shall support:

– TLS wildcard certificate for its domain name and generation of telescopic FQDN, as specified in clause 13.1 of 3GPP TS 33.501 [17] and in clause 6.1.4.3.2; and

– forwarding HTTP requests originated by NFs within the SEPP’s PLMN towards the remote PLMN using the 3gpp-Sbi-Target-apiRoot header as specified in clause 6.1.4.3.3.

NOTE: Whether the SEPP and NFs within the SEPP’s PLMN use telescopic FQDN or the 3gpp-Sbi-Target-apiRoot header is based on PLMN operator’s policy and is independent from the method supported and used in the remote PLMN.

Both solutions for TLS protection between the SEPP and Network Functions within a PLMN may be used concurrently in a PLMN, e.g. in the transient phase where not all NFs of the PLMN have been upgraded to support the 3gpp-Sbi-Target-apiRoot header but when the PLMN operator would like to use the solution based on the 3gpp-Sbi-Target-apiRoot header with upgraded NFs. In this case, the SEPP should skip converting URIs into telescopic FQDNs (and use the solution based on 3gpp-Sbi-Target-apiRoot header) in:

– HTTP responses received from the remote PLMN (e.g. including the FQDN of the target NF service) when the corresponding HTTP request contains a 3gpp-Sbi-Target-apiRoot header;

– HTTP requests received from the remote PLMN (e.g. including callback URIs) using SEPP policies based on the target URI (i.e. target FQDN).

6.1.4.3.2 Use of telescopic FQDN between NFs and SEPP within a PLMN

When using TLS wildcard certificate and telescopic FQDN between the SEPP and NFs within the SEPP’s PLMN, the SEPP on the HTTP/2 client side shall form the telescopic FQDN, as specified in 3GPP TS 23.003 [15], for the following cases:

– FQDN of the target NF service in HPLMN is modified into a telescopic FQDN by the SEPP in the VPLMN;

– FQDN of the target NF service in VPLMN is modified into a telescopic FQDN by the SEPP in the HPLMN;

– FQDN (authority) part of callback URI of NF service resources in VPLMN is modified into a telescopic FQDN by the SEPP in the HPLMN;

– FQDN (authority) part of callback URI of NF service resources in HPLMN is modified into a telescopic FQDN by the SEPP in the VPLMN;

– FQDN (authority) part of link relation URI of NF service resources in VPLMN is modified into a telescopic FQDN by the SEPP in the HPLMN;

– FQDN (authority) part of link relation URI of NF service resources in HPLMN is modified into a telescopic FQDN by the SEPP in the VPLMN.

6.1.4.3.3 Use of 3gpp-Sbi-Target-apiRoot between NFs and SEPP within a PLMN

When using the 3gpp-Sbi-Target-apiRoot header between the SEPP and NFs within the SEPP’s PLMN, HTTP requests between the NFs and the SEPP shall be routed as specified in clause 6.10.2 for indirect communications, with the SEPP taking the role of the SCP.

When sending an HTTP request targeting a URI with an authority of a remote PLMN, NFs shall include the 3gpp-Sbi-Target-apiRoot header in the HTTP request, containing the apiRoot of the target URI in the remote PLMN, and shall set the apiRoot in the request URI to the apiRoot of the SEPP (or to the apiRoot of the SCP if the communication between the NF and SEPP goes through an SCP). The apiRoot of the SEPP (or SCP) may include an optional deployment-specific string of the SEPP (or SCP).

An SCP that receives an HTTP request targeting a URI with an authority of a remote PLMN shall route the HTTP request towards the SEPP as specified in clause 6.10.2 for indirect communications, i.e. the SCP shall forward the 3gpp-Sbi-Target-apiRoot header in the HTTP request it forwards to the SEPP, containing the apiRoot of the target URI in the remote PLMN, and it shall set the apiRoot in the request URI to the apiRoot of the SEPP.

If the SEPP receives an HTTP request from a NF with a request URI containing a telescopic FQDN and with a 3gpp-Sbi-Target-apiRoot header, the SEPP shall ignore the 3gpp-Sbi-Target-apiRoot header and route the request using the telescopic FQDN.

NOTE 1: This is to address the case of a potentially malicious or misbehaving NF that would include the 3gpp-Sbi-Target-apiRoot header and a request URI containing a telescopic FQDN when communicating with the SEPP.

NOTE 2: This solution does not require the SEPP to support TLS wildcard certificate for its domain name, nor the SEPP to modify URI attributes in HTTP request and response payloads with telescopic FQDNs.

NOTE 3: The communication between the NF and SEPP can be direct or go through an SCP.

6.1.4.3.4 Routing between SEPPs

The 3gpp-Sbi-Target-apiRoot header shall not be used between SEPPs if PRINS security is negotiated between the SEPPs. The apiRoot of the Request URI of the HTTP request encapsulating the protected message shall be set to the apiRoot of the remote SEPP. See clause 5.3.2.4 of 3GPP TS 29.573 [27].

If TLS security is negotiated between the SEPPs and at least one SEPP does not indicate support of the 3gpp-Sbi-Target-apiRoot header when negotiating the security policy, the SEPP shall use a pre-established TLS connection towards the other SEPP to forward the HTTP/2 messages sent by the NF service producers and NF service consumers, as is without reformatting. Additionally,

– if the NF uses the 3gpp-Sbi-Target-apiRoot HTTP header in the HTTP Request to convey the target apiRoot to the sending SEPP, the sending SEPP shall remove the 3gpp-Sbi-Target-apiRoot header and set the apiRoot of the request URI it forwards on the N32-f interface to the apiRoot received in the 3gpp-Sbi-Target-apiRoot header from the HTTP client;

– if the NF uses a telescopic FQDN in the HTTP Request to convey the target apiRoot to the sending SEPP, or if TLS is not used between the NF and the sending SEPP, the sending SEPP shall set the apiRoot of the Request URI in the HTTP Request towards the remote SEPP to the apiRoot of the target NF derived from the telescopic FQDN or from the request URI respectively.

If TLS security is negotiated between the SEPPs and both SEPPs indicate support of the 3gpp-Sbi-Target-apiRoot header when negotiating the security policy, HTTPS shall be used to forward messages between SEPPs. The sending SEPP shall replace the apiRoot of the Request URI in the HTTP Request with the apiRoot of the receiving SEPP before forwarding the HTTP Request on the N32 interface. Additionally,

– if the NF uses the 3gpp-Sbi-Target-apiRoot HTTP header in the HTTP Request to convey the target apiRoot to the sending SEPP, the sending SEPP shall forward the 3gpp-Sbi-Target-apiRoot header unmodified in the HTTP request towards the remote SEPP;

– if the NF uses a telescopic FQDN in the HTTP Request to convey the target apiRoot to the sending SEPP, or if TLS is not used between the NF and the sending SEPP, the sending SEPP shall insert the 3gpp-Sbi-Target-apiRoot header in the HTTP request towards the remote SEPP and set it to the apiRoot of the target NF derived from the telescopic FQDN or from the request URI respectively.

NOTE: Rel-15 compliant NFs and SEPP do not support the 3gpp-Sbi-Target-apiRoot header.

6.1.5 Host header

Clients that generate HTTP/2 requests shall use the ":authority" pseudo-header field instead of the Host header field.

6.1.6 Message forwarding

An HTTP/2 proxy shall use the ":authority" pseudo-header field to connect inbound to the origin server or another proxy if the request cannot be satisfied by the proxy cache.

An HTTP/2 proxy may also use other headers and/or payload content to connect inbound to the origin server or another proxy if the request cannot be satisfied by the proxy cache.