4 General DNS Based Node Selection Description

29.3033GPPDomain Name System ProceduresRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Resource Records

4.1.1 A and AAAA

The A resource record is used to define IPv4 host address corresponding to fully qualified name of the host as defined in IETF RFC 1035 [3]. The AAAA resource record is used to define IPv6 host address corresponding to fully qualified name of the host as defined in IETF RFC 3596 [6].

It should be noted that in DNS A or AAAA record names, in general, represent a host and its "equivalent" interface. Host names, in general, cannot be used as node names. A node may need to have more than one host name for the simple reason that it can have multiple interfaces for different purposes.

4.1.2 NAPTR

The NAPTR resource record is defined in IETF RFC 3403 [7] and is a powerful tool that allows DNS to be used to lookup services for a wide variety of resource names, which are not in domain name syntax. NAPTR would be used by a client program to rewrite a string into a domain name. The rewrite process is controlled by flags that provide information on how to communicate with the host at the domain name that was the result of the rewrite. If DNS returns multiple NAPTR resource records those can be prioritized using embedded order and preference values defined by the DNS administrator.

The S-NAPTR procedure i.e., the "Straightforward-NAPTR" procedure, is defined in IETF RFC 3958 [9] and describes a Dynamic Delegation Discovery System (DDDS) [10] application procedures on how to resolve a domain name, application service name, and application protocol dynamically to target server and port by using both NAPTR and SRV (see IETF RFC 2782 [8]) resource records. The S-NAPTR also simplifies the use of NAPTR by limiting the NAPTR flags only to "a", "s" and "". Furthermore, only NAPTR "replacement" expressions are allowed, not "regular expressions", during the rewrite process. The changes compared to IETF RFC 3403 [7] NAPTR usage are procedural and are limited only to the resolver. The S-NAPTR use of the NAPTR resource record is exactly the same as defined in IETF RFC 3403 [7] from the DNS server and DNS infrastructure point of view. Additional information on S-NAPTR usage is provided in Annex B and Annex C.

The NAPTR resource record flags "s" and "" allow another layer of indirection in the DNS configuration. The "" flag causes the S-NAPTR procedure to query for new NAPTR resource records from the DNS infrastructure. The "s" flag causes the S-NAPTR procedure to query for an intermediary SRV resource record pointing to A/AAAA resource records. This additional query provides a selection mechanism by which the operator is able to assign different weights to different A/AAAA resource records while larger weights are given a proportionately higher probability of being selected. A DNS server might provide the A/AAAA records together with the SRV resource records as per IETF RFC 2782 [7]. The length of the NAPTR resource record indirection chain enabled using the "" flag is unbounded and may lead to a deep chaining of resource records over time in the DNS configuration. Additional layer of indirection and possible deep chaining both grows the DNS configuration significantly in size and complexity, and also makes the configuration prone to hard to trace errors. The use of NAPTR resource record "" flag pointing to other NAPTR resource records with flag "" is strongly discouraged. Specifically, NAPTR resource flag "" should only be provisioned to point to terminal NAPTR records (i.e., flag "a" or flag "s"). Generally, the use of flag "a" or of flag "s" is encouraged.

4.1.3 SRV

The SRV resource record is defined in IETF RFC 2782 [8] and allows DNS administrators to use pool of servers for a single domain with static load balancing to each server, to move services from host to host, and to designate some hosts as primary servers for a service from a pool of hosts. A resolver can ask for a specific service/protocol combination for a specific domain name and get back a Fully Qualified Domain Names (FQDN) of any available servers.

4.2 Selecting Domain Names

When using the S-NAPTR procedure under the DDDS framework, it becomes essential which domain name gets used for querying the actual NAPTR records. In the S-NAPTR procedure, the Application-Unique String used by the DDDS algorithm is the starting domain name for which the information of the services, protocols and actual canonical node names are sought. Related to the Application-Unique String, the First well-Known Rule of the DDDS algorithm in the S-NAPTR procedure outputs the same domain name that constitutes the Application-Unique String. For each node type in EPC that can be queried for information using the S-NAPTR procedure, the authoritative DNS server for the given domain should be provisioned with unique domain name for each EPC node or other identifier that is explicitly specified by a procedure in this specification (for example one based on APN, TAI,GUTI, etc) and corresponding NAPTR records. The authoritative DNS server for a given domain shall provision at least the EPC node names that may be exposed to the inter-operator roaming interfaces.

4.3 Identifying Nodes, Services and Protocols

4.3.1 IETF RFC 3958 Service and Protocol service names for 3GPP

Service and protocol service names for the S-NAPTR procedure shall be used in accordance with 3GPP TS 23.003 [4], clause 19.4.3.

4.3.2 Identification of canonical node names

There are many use cases where it is desirable to select a collocated node in preference to a non-collocated node, or a topologically closer (with respect to the network topology) node in preference to a less topologically closer node. To easily do this action a "canonical" node name shall be employed so that the "canonical" node names from two or more sets of records can be compared to see if nodes are actually the same nodes, or topologically closer nodes.

In DNS neither A or AAAA host names, in general, represent a node name, but rather a set of "equivalent" interfaces. A node may need to have more than one host name for the simple reason that it can have different interfaces for different purposes. For example, a node can have a set of roaming interfaces on a completely different network than the internal network due to security needs. Hence, there are always situations where multiple A/AAAA record sets must exist that implies multiple distinct host names. Therefore, host names, in general, cannot be used as node names.

Instead of creating new DNS records to map a host name to a node name this specification defines how host names shall be constructed and used in S-NAPTR procedure within 3GPP EPC.

The host names shall have form:

<"topon" | "topoff"> . <single-label-interface-name> . <canonical-node-name>

Where the first label is "topon" or "topoff" to indicate whether or not collocated and topologically close node selection shall be preferred, "single-label-interface-name" is a single label used to name a specific interface on a node (e.g. Eth-0, S8, vip, board3), "canonical-node-name" is a the canonical node name of a specific node. A node shall have exactly one canonical node name so a host name always includes the unique canonical node name of the node.Hence, when comparing the host name FQDNs to find out whether the nodes are actually the same, the first two labels of the host name FQDN shall be ignored.

NOTE 1: The canonical node name is not related to canonical name in the CNAME DNS record.

When using host names with "topon" as the first label the canonical node names of nodes shall be hierarchically structured to allow an operator to reflect the topological closeness of two nodes by naming the nodes with canonical node names sharing a common suffix domain name. The number of labels in the common suffix shall represent how close the operator considers them during node selection. The higher the number of labels in the common suffix is, the closer the nodes are. In other words, two topologically closest nodes are those with the longest matching suffix in their respective canonical node names.

The following list contains examples of domain names where canonical node names are in bold:

topon.Eth-0.gw32.california.west. example.com

topon.S8.gw32.california.west. example.com

topon.vip.sgw3.oregon.west. example.com m

topon.board3.pgw1.cluster1.net27. example.net

topon.S5.gw4.cluster1.net27. example.net

topon.board3.pgw1.cluster2.net27. example.net

In the examples above, "Eth-0.gw32.california.west.example.com " and "S8.gw32.california.west. example.com " are two different interfaces on the same node, "gw32.california.west. example.com ". On the other hand, "gw4.cluster1.net27.example.net" is topologically closer to "pgw1.cluster1.net27. example.net" (they are both connected to the "cluster1.net27. example.net" subnetwork) than to "pgw1.cluster2.net27. example.net" (only connected to the wider "net.27. example.net" subnetwork.)

Interface names and node names do NOT identify a function in the procedures here. The interface is part of the natural hierarchy within a node and the host name is already returned with the existing DNS records. The approach of identifying a canonical node name from a host name is believed to be simpler and more logical to maintain than creating additional DNS records simply to return a node name.

The topologically aware naming restriction (i.e. the format above using "topon" or "topoff") shall be placed only on all targets/replacements pointing logically to a A/AAAA record sets from the S-NAPTR procedure. These targets/replacements are denoted host names here (following the normal DNS terminology unless a CNAME is used to point to the actual A or AAAA record). This restriction shall NOT apply to any other DNS records the operator may be using.

Specifically, a NAPTR with flag "a" will have a replacement target pointing to the A/AAAA record directly, thus the topologically aware naming restriction on the host name applies to the replacement in the NAPTR record with a flag "a". For the NAPTR flag "s" case the topologically aware naming restriction on the host name applies to the target in the SRV record, and not the NAPTR record replacement. For the NAPTR empty flag "" case the topologically aware naming does not apply any restriction since this is not a host name. Other flags are not used in S-NAPTR.

During DNS provisioning for the S-NAPTR procedure the operator is free to add another layer of indirection using a CNAME record (see clause 6.6.2 of IETF RFC 1034 [2]).

While operators shall provision host names in DNS according to the above rules, it is still possible that the host name might be incorrectly configured (i.e. not conforming to the above format with first label of "topon" or "topoff"). For such misconfigured records implementations shall treat the misconfigured host name as valid within the S-NAPTR procedure where that host name was found, but may favor correctly configured records. Misconfigured host name for topological matching and colocation checks shall be treated as if the misconfigured host name had the label "topoff." prepended. Operators shall not depend on this behavior.

The order of using DNS records to contact a node is based on following ordering. When collocation of a pair of node types is explicitly stated as applicable in a procedure, collocation of the nodes shall have high est importance . When topological matching is explicitly stated as applicable in a procedure then topological matching with "topon", is of second highest importance. Then finally the ordering obtained by the S-NAPTR output . When collocation and topological ordering applies, collocated sets of nodes have highest importance, then sets of nodes with "topon" and the most labels in their common suffix, then sets of nodes with "topon" and second most number of labels and so on until we reach non-colocated nodes with "topoff" and within sets with same colocation or topological order then S-NAPTR order of one of the two nodes is used (specified in the specific procedure). Additional informative clarifications on how S-NAPTR is employed in the context of 3GPP EPC node usage and specifically how topological matching using the "topon" label interacts with S-NAPTR ordering is provided in Annex C.4.

4.3.3 Services from node names or other FQDN identifying a service

4.3.3.1 General

There are potential use cases where a node has a logical name of a peer or other FQDN identifier for a service but does not have the protocols it supports. The NAPTR record for any of the services can be provisioned at the nodes logical name or other FQDN identifier for a service. The node logical name or other FQDN identifier for a service is equal to the domain name under which NAPTR records are provisioned. This allows any core network node to discover the available services based on node’s logical name or other FQDN identifier for a service.

4.3.3.2 Procedure

4.3.3.2.1 S-NAPTR Procedure – General

These procedures are employed when any core network node has the FQDN of an entity and needs to find one or more services at that entity.

NOTE: There are three likely sources of the entity name. O&M provisioned, 3GPP specified based on some other identifier of a service (such as GUTI, TAC, IMSI, MISDN etc.), or the canonical node name obtained from a previous S‑NAPTR procedure. Note that a node can have more than one name, i.e. an alias, but there shall be only one canonical node name for a node. (CNAME records are a way to create aliases for the canonical node name or any other FQDN as per IETF RFC 1034 [2])

The S-NAPTR procedure requires that DNS NAPTR records shall be consistently provisioned as described in IETF RFC 3958 [9]. This means a NAPTR record for each protocol using "a" flag and the service field populated with the service and proto value may be provisioned. If a more sophisticated load balancing or non-standard ports are desired, NAPTR with "s" flag for each protocol and the corresponding SRV records with relative weighting for each interface need to be provisioned. NAPTR records with empty "" flag records may also be used.

A DNS resolver that intends to use the S-NAPTR procedure shall use the FQDN of the node or a specified FQDN identifier of a service as the Application-Unique String. If all protocols are desired, then the resolver simply runs the S-NAPTR procedure as if all protocols match.

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This list can be obtained one host name at a time, in a procedure similar to Annex C.2, or a complete ordered list of all nodes, in a procedure similar to Annex C.3. Such a complete list obtained from an S-NAPTR procedure is referred here as a candidate list.

NOTE: The candidate list is valid for at most for finite period of time due to DNS time to live and order of the records can change due to statistical selection. Operators should provision records with reasonable time to live values.

4.3.3.2.2 S-NAPTR Procedure for a canonical node name

One very important special case is S-NAPTR based on a node’s canonical node name.

Operators shall provision NAPTR records for all enabled interfaces of a node that are explicitly listed in clause 19.4.3 of 3GPP TS 23.003 [4] at the FQDN of the node’s unique canonical node name.

NOTE 1: Exception to this rule: The NAPTR records for x-3gpp-mme: x- s1-mme and x-3gpp-sgw:x-s1-u from clause 19.4.3 of 3GPP TS 23.003 [4] are to be considered entirely optional in this release of 3GPP.

With such provisioning by an operator a DNS resolver can at any time use the S-NAPTR procedure with a valid canonical node name to find all interfaces and protocols supported by that node that are listed in clause 19.4.3 of 3GPP TS 23.003 [4]. This includes interfaces of co-located functions that might not be easily discovered by other means.

NOTE 2: The remaining clauses within clause 4.3.3 cover cases where the FQDN used for the Application-Unique String is known to correspond to the resource of exactly one node and are relatively simple. These include the cases where an explicit identifier is defined by 3GPP for S-NAPTR lookup and examples of S-NAPTR based on canonical node names (the later is not intended to be an exhaustive list of examples). More complicated cases that cover identifiers for multiple nodes are covered in other clauses.

4.3.3.3 Services of a PGW from PGW node name (or collocated PGW/GGSN)

A UE with both a 3GPP access capability and non-3GPP access capability can roam in and out of the 3GPP network while maintaining the same PDN connection.

To support roaming to or from a non-3GPP network the HSS (or AAA) server can have an FQDN of a particular PGW or collocated PGW/GGSN node. One reason for using an FQDN instead of an IP address is that a PGW can be multihomed (i.e. more than one IP address). Another possible use case is when the PGW interface needs to be changed between PMIP and GTP. Even if each interface type only uses one IP address, the different interfaces can still use different IP addresses. For example, roaming and non-roaming interfaces are likely to be separated from each other using firewall or other mechanisms. Another possible use case is when the Home Agent (HA) functionality of a particular PGW needs to be discovered, e.g., during the HA reallocation procedure.

If the PGW node name employed by the operator is the PGW canonical node name then see clause 4.3.3.2 for provisioning.

If the PGW node name employed by the operator is not the PGW canonical node name then the operators shall provision at least the NAPTR records for S5 and S8 interfaces of a PGW node (see clause 19.4.3 of 3GPP TS 23.003 [4]) at that PGW node name. If the GGSN function is co-located then the NAPTR records for the Gn/Gp interfaces of the collocated PGW/GGSN shall be included as well. Only interfaces that exist and are allowed by the operator policy need be included.

NOTE 1: The PGW node name in HSS/AAA may or may not be the PGW’s canonical node name if the PGW’s FQDN was placed in the HSS/AAA from a non-3GPP source.

To resolve the allowed PMIPv6 interfaces the S-NAPTR procedure shall be used with the "Service Parameters" of

"x-3gpp-pgw:x-s5-pmip" , "x-3gpp-pgw:x-s8-pmip"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the PGW or collocated PGW/GGSN node.

For a more explicit example, an operator might provision a PGW name at:

gw1.pgw.node.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Similarly for the GTPv2 interfaces the S-NAPTR procedure shall use "Service Parameters" of

"x-3gpp-pgw:x-s5-gtp" , "x-3gpp-pgw:x-s8-gtp"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the specific PGW or collocated PGW/GGSN node.

Similarly for the GTPv1 Gn/Gp interfaces the S-NAPTR procedure shall use "Service Parameters" of

"x-3gpp-pgw:x-gn" , "x-3gpp-pgw:x-gp" "x-3gpp-ggsn:x-gn", "x-3gpp-ggsn:x-gp"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the specific PGW , collocated PGW/GGSN node. The "Service Parameters" of "x-3gpp-pgw:x-gn", "x-3gpp-pgw:x-gp" represent collocated PGW/GGSN nodes and "x-3gpp-ggsn:x-gn", "x-3gpp-ggsn:x-gp" represent a GGSN that does not have a PGW co-located.

Similarly for the Home Agent functionality of a PGW the S-NAPTR procedure shall use "Service Parameters" of

"x-3gpp-pgw:x-s2c-dsmip"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the specific PGW.

Similarly for the S2a interface the S-NAPTR procedure shall use "Service Parameters" of

"x-3gpp-pgw:x-s2a-pmip", "x-3gpp-pgw:x-s2a-gtp"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the specific PGW.

Similarly for the S2b interface the S-NAPTR procedure shall use "Service Parameters" of

"x-3gpp-pgw:x-s2b-pmip", "x-3gpp-pgw:x-s2b-gtp"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the specific PGW.

Additional requirements to support DCN are specified in clause 5.8.It is also possible for the DNS resolver to leave "Service Parameters" unspecified in the S-NAPTR procedure in order to identify all interfaces for all supported services and protocols.

NOTE 2: The services based on S-NAPTR at the canonical node name of the PGW might return services other than ones starting with x-3gpp-pgw or x-3gpp-ggsn since the PGW node can have a co-located SGW function or other functions.

4.3.3.4 Services of a MME from MME node name (or GUTI or 5G-GUTI)

There are procedures when:

– the old MME must be contacted by the new AMF, MME or S4 SGSN (a Release-8 SGSN supporting only Gn/Gp may also optionally use this procedure);

– the old AMF must be contacted by the new MME.

The primary use case is context transfer.

The 3GPP defined MME node FQDN shall be constructed as defined in clause 19.4.2.4 of 3GPP TS 23.003 [4] where the needed data can be obtained from the UE’s old GUTI (or mapped from old P-TMSI and old RAI see clause 4.3.3.5 for more details, or mapped from the 5G-GUTI). The 3GPP defined MME node FQDN is either the canonical node name itself or an alias of the MME’s canonical node name (the operator is free to choose the canonical node name).

If the MME node name employed by the operator is the 3GPP defined MME node FQDN then see clause 4.3.3.2 for provisioning.

If the MME node name employed by the operator is the 3GPP defined MME node FQDN, the operator shall provision NAPTR records under the 3GPP defined MME node FQDN for at least "x-3gpp-mme:x-s10", "x-3gpp-mme:x-s3" if S3/S4 GERAN/UTRAN is supported, and "x-3gpp-mme:x- gn " or "x-3gpp-mme:x-gp" if Gn/Gp is supported.

So, for example, for an MME or AMF to find all S10 interfaces of an MME based on the old GUTI or 5G-GUTI, the S-NAPTR procedure shall be prefixed with "Service Parameters" of

"x-3gpp-mme:x-s10"

and set the Application-Unique String to the FQDN as defined in clause 19.4.2.4 of 3GPP TS 23.003 [4], with the initial query targeted at 3GPP defined MME node FQDN.

Similarly, for example, for an MME to find all N26 interfaces of an AMF based on the old GUTI, the S-NAPTR procedure shall be prefixed with "Service Parameters" of

"x-3gpp-mme:x-s10"

and set the Application-Unique String to the FQDN as defined in clause 19.4.2.4 of 3GPP TS 23.003 [4], with the initial query targeted at 3GPP defined MME node FQDN.

Similarly, for an S4 -SGSN to find all S3 interfaces of an MME based on the old GUTI it would use a "Service Parameter" of "x-3gpp-mme:x-s3".

Similarly, for a Release 8 Gn/Gp-SGSN to find all Gn and Gp interfaces of an MME based on the old GUTI it would use a "Service Parameter" of " x-3gpp-mme:x-gn", " x-3gpp-mme:x-gp".

To find all MME related services of an MME based on the MME’s canonical node name, the S-NAPTR procedure shall be prefixed with "Service Parameters" of

"x-3gpp-mme:x-s10", "x-3gpp-mme:x-s3", "x-3gpp-mme:x-s11", "x-3gpp-mme:x-gn", "x-3gpp-mme:x-gp",

and set the Application-Unique String to the MME’s canonical node name.

It is also possible for the DNS resolver to use only the interfaces it is interested in or leave "Service Parameters" unspecified in the S-NAPTR procedure in order to identify all interfaces for all supported services and protocols.

NOTE 1: The services based on MME canonical node name can return services not starting with x-3gpp-mme since the MME node might, for example, have a co-located SGSN.

NOTE 2: The above procedures for discovering and selecting an AMF are identical to the procedures specified for discovering and selecting an MME; they can be used by MMEs not upgraded to support the procedure specified in clause 4.3.3.8. In this case, AMFs are provisioned in DNS as MMEs, following the mapping rules specified for EPS interworking with 5GS in clause 2.10.2 of 3GPP TS 23.003 [4], and the code space between AMF Region ID and MMEGI needs to be coordinated.

4.3.3.5 Services of an SGSN from a P-TMSI

There are procedures where the source SGSN must be contacted by the target MME or a target S4-SGSN. A Release 8 SGSN supporting only Gn/Gp may also optionally use this procedure.

During a mobility procedure towards a new core network node, a UE served by a SGSN has a previously assigned P‑TMSI by the source SGSN. A pre-Release-8 UE will provide the P‑TMSI. A Release-8 UE will map P‑TMSI to a derived GUTI using the procedure in 3GPP TS 23.003 [4] clause 2.8.2and referred to in Annex H of 3GPP TS 23.401 [11].

The targetMME or a target S4-SGSN extracts the source’s NRI, RAC, LAC, MNC and MCC from the P‑TMSI (or GUTI based on the procedure described in 3GPP TS 23.003 [4] clause 2.8.2).

The FQDN based on NRI, RAC, LAC, MNC and MCC as defined in 3GPP TS 23.003 [4] clause 19.4.2.6 is denoted in this specification as the NRI-RAI FQDN.

If the SGSN canonical node name employed by the operator is the NRI-RAI FQDN then see clause 4.3.3.2 for provisioning.

If the 3GPP defined NRI-RAI FQDN is not employed by an operator as the SGSN’s canonical node name then the operator shall provision NAPTR records under the NRI-RAI FQDN with at least "x-3gpp-sgsn:x-s3", "x-3gpp-sgsn:x-s4", "x-3gpp-sgsn:x-s16" (assuming the SGSN supports S3/S4/S16 GERAN/U-TRAN) and at least "x-3gpp-sgsn:x-gn", "x-3gpp-sgsn:x-gp" (assuming the SGSN supports legacy Gn/Gp).

The S-NAPTR procedure for finding the old SGSN services and interfaces from the P‑TMSI is started with "Service Parameters" of

"x-3gpp-sgsn:x-gn", "x-3gpp-sgsn:x-gp", "x-3gpp-sgsn:x-s3", "x-3gpp-sgsn:x- s16"

as defined in 3GPP TS 23.003 [4] and setting the Application-Unique String to the NRI-RAI FQDN based on NRI, RAC, LAC, MNC and MCC as defined in 3GPP TS 23.003 [4] clause 19.4.2.6:

NOTE 1: In the event a valid NRI is not available then the <NRI> value shall be excluded from the FQDN. The default SGSN in the SGSN pool shall be provisioned under that record (or the sole SGSN if there is no SGSN pool for that RAI).

NOTE 2: Service Parameters are logically limited to those supported by the target node that is performing the search for the source SGSN. So for example, a target Release-8 SGSN supporting only Gn/Gp would employ "x-3gpp-sgsn:x-gn" and "x-3gpp-sgsn:x-gp". An S4-SGSN only supporting S4/S3/S16 would employ "x-3gpp-sgsn:x-s3", "x-3gpp-sgsn:x-s16". A target MME would employ "x-3gpp-sgsn:x-s3" and may additionally include "x-3gpp-sgsn:x-gn" and "x-3gpp-sgsn:x-gp", to support the procedures in Annex D of 3GPP TS 23.401 [11].

NOTE 3: The services based on canonical node name can return services not starting with x-3gpp-sgsn since the SGSN node might, for example, have a co-located MME.

For a pre-Release-8 target node i.e. a UE moving from eUTRAN to pre-Release-8 UTRAN/GERAN the UE will provide a derived P-TMSI based on a GUTI (See Annex H of 3GPP TS 23.401 [11]). As a result the source MME or Release-8 SGSN looks like a pre-Release-8 SGSN to a pre-Release-8 target node. For pre-Release‑8 compatibility operators would continue to provision A/AAAA records as described in Annex C.1 of 3GPP TS 23.003 [4] for the corresponding Gn/Gp interfaces regardless of whether the source SGSN is pre-Release-8 or not.

NOTE 4: Gn/Gp interfaces are provisioned redundantly for both ".gprs" and ".3gppnetwork.org" top level domains during the transition to Release-8 to allow a gradual forward migration to 3ggpnetwork.org while still supporting existing pre-Release‑8 usage.

4.3.3.6 Services of an SGW from SGW canonical node name

An MME or S4-SGSN may need to find SGW interfaces on a SGW based solely on SGW’s canonical node name. The most common use cases are:

– An MME finding an S11 interface from an SGW node name where the SGW node name was determined from an S5/S8 interface selection based on TAI/eNodeB-ID (see clause 5.2).

– An S4-SGSN finding an S4 interface from an SGW node name where the SGW node name was determined from an S5/S8 interface selection based on RAI/RNC-ID (see clause 5.2).

– Finding if an SGW node has PGW interfaces from an SGW node name (both SGW and PGW functions would be listed under one canonical node name for co-located PGW/SGW).

See clause 4.3.3.2 for DNS provisioning of the canonical node name records.

For LTE initial attach cases, the S11 interface is initially unknown by an MME. The S5/S8 interface and the SGW hostname will be selected by procedures in clause 5. The MME will obtain SGW S11 interfaces from the SGW canonical node name. The S-NAPTR procedure shall use "Service Parameter" of

"x-3gpp-sgw:x-s11"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the canonical node name of the specific SGW node to find the available S11 interfaces

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of services and interfaces of that SGW (see Annex C.2 for a more detailed description of a candidate list).

For example, an operator might provision an SGW name at:

gw21.sgw.node.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Similarly, for GERAN/UTRAN initial attach cases the S4-SGSN will need to obtain the SGW S4 interface after procedures in clause 5 select the S5/S8 interface and SGW hostname. The only change from the MME case is the "Service Parameter" of

"x-3gpp-sgw:x-s4"

is employed.

In cases where a new PDN connection is added to an existing SGW the available SGW S5/S8 interfaces are commonly needed.

To resolve the allowed SGW PMIPv6 interfaces the S-NAPTR procedure shall be used with the "Service Parameters" of

"x-3gpp-sgw:x-s5-pmip", "x-3gpp-sgw:x-s8-pmip"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the canonical node name of the specific SGW node

Similarly for the S5/S8 GTP interfaces the S-NAPTR procedure shall use "Service Parameters" of

"x-3gpp-sgw:x-s5-gtp", "x-3gpp-pgw:x-s8-gtp"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the specific SGW node.

Additional requirements to support DCN are specified in clause 5.8.

It is also possible to combine the "Service Parameters" in the S-NAPTR or to leave "Service Parameters" as logically unspecified initially in the S-NAPTR procedure in order to identify all interfaces for all 3GPP TS 29.303 supported protocols of the node.

NOTE 1: The services based on canonical node name can return services not starting with x-3gpp-sgw since the SGW node might, for example, have a co-located PGW.

4.3.3.7 Services of an MSC Server from MSC Server canonical node name

During the SRVCC operations (see 3GPP TS 23.216 [20]), an MME or an SGSN may need to find the MSC Server Sv interface based on MSC Server canonical node name. The most common use cases are:

– An MME or an SGSN finding the Sv interface from an MSC Server node name, where the MSC server node name was determined from the Sv interface selection based on the Target RAI.

See clause 4.3.3.2 for DNS provisioning of the canonical node name records.

To find the MSC server services under the MSC server node name, the operator shall at least provision the "Service Parameter" of

"x-3gpp-msc:x-sv"

4.3.3.8 Services of an AMF from AMF instance name (or 5G-GUTI)

During a 5GS to EPS Idle mode mobility using N26 interface (see clause 4.11.1.3.2 of 3GPP TS 23.502 [29]), the MME needs to contact the old AMF for contexts transfer.

The 3GPP defined AMF instance FQDN shall be constructed as defined in clause 28.3.2.8 of 3GPP TS 23.003 [4] where the needed data can be obtained from the UE’s old GUTI (mapped from the 5G-GUTI). The 3GPP defined AMF instance FQDN is either the canonical node name itself or an alias of the AMF’s canonical node name (the operator is free to choose the canonical node name).

If the AMF node name employed by the operator is the 3GPP defined AMF instance FQDN then see clause 4.3.3.2 for provisioning.

If the AMF node name employed by the operator is the 3GPP defined AMF instance FQDN, the operator shall provision NAPTR records under the 3GPP defined AMF instance FQDN for "x-3gpp-amf:x-n26".

So, for example, for an MME to find all N26 interfaces of an AMF based on the old GUTI, the S-NAPTR procedure shall be prefixed with "Service Parameters" of

"x-3gpp-amf:x-n26"

and set the Application-Unique String to the FQDN as defined in clause 28.3.2.8 of 3GPP TS 23.003 [4], with the initial query targeted at 3GPP defined AMF instance FQDN.

NOTE: The above procedure avoids the need for code space coordination between AMF Region ID and MMEGI for EPS interworking with 5GS, i.e. the full address space of the AMF Region ID can be used for 5GS.