ETSI TS 129 303 V15.5.0 (2019-07)

Universal Mobile Telecommunications System (UMTS); LTE; Domain Name System Procedures; Stage 3 (3GPP TS 29.303 version 15.5.0 Release 15)

RTS/TSGC-0429303vf50

General Information

• Status: Published
• Publication Date: 30-Jun-2019
• Technical Committee: 3GPP CT 4 - MAP/CAMEL/GTP/BCH/SS/TrFO/IMS/GUP/WLAN (formely CN4)
• Current Stage: 12 - Completion
• Completion Date: 01-Jul-2019

Standards Content (Sample)

TECHNICAL SPECIFICATION
Universal Mobile Telecommunications System (UMTS);
LTE;
Domain Name System Procedures;
Stage 3
(3GPP TS 29.303 version 15.5.0 Release 15)

3GPP TS 29.303 version 15.5.0 Release 15 1 ETSI TS 129 303 V15.5.0 (2019-07)

Reference
RTS/TSGC-0429303vf50
Keywords
LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 2 ETSI TS 129 303 V15.5.0 (2019-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 3 ETSI TS 129 303 V15.5.0 (2019-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 6
1 Scope . 7
2 References . 7
3 Definitions, symbols and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 General DNS Based Node Selection Description . 9
4.1 Resource Records . 9
4.1.1 A and AAAA . 9
4.1.2 NAPTR . 9
4.1.3 SRV . 10
4.2 Selecting Domain Names . 10
4.3 Identifying Nodes, Services and Protocols . 10
4.3.1 IETF RFC 3958 Service and Protocol service names for 3GPP . 10
4.3.2 Identification of canonical node names . 10
4.3.3 Services from node names or other FQDN identifying a service. 12
4.3.3.1 General . 12
4.3.3.2 Procedure . 12
4.3.3.2.1 S-NAPTR Procedure - General . 12
4.3.3.2.2 S-NAPTR Procedure for a canonical node name . 12
4.3.3.3 Services of a PGW from PGW node name (or collocated PGW/GGSN) . 13
4.3.3.4 Services of a MME from MME node name (or GUTI or 5G-GUTI) . 14
4.3.3.5 Services of an SGSN from a P-TMSI . 15
4.3.3.6 Services of an SGW from SGW canonical node name . 16
4.3.3.7 Services of an MSC Server from MSC Server canonical node name . 17
4.3.3.8 Services of an AMF from AMF instance name (or 5G-GUTI) . 17
4A SGW/PGW selection using GTP-C load control . 18
4A.1 General . 18
4A.2 Node-level load control . 18
4A.3 APN-level load control . 19
5 Procedures for EPC Node Discovery and Selection . 20
5.1 Procedures for Discovering and Selecting a PGW . 20
5.1.1 Discovering a PGW for a 3GPP Access . 20
5.1.1.1 General . 20
5.1.1.2 Discovering a PGW or collocated PGW/GGSN for a 3GPP Access - S8/Gp roaming case
existing PDN . 21
5.1.1.3 Discovering a PGW or collocated PGW/GGSN for a 3GPP Access - S5/Gn intra-operator
existing PDN . 22
5.1.1.4 Discovering a PGW, collocated PGW/GGSN or GGSN for a 3GPP Access - S5/Gn intra-
operator initial attach. 24
5.1.2 Discovering a PGW for a non-3GPP Access with Network Based Mobility Management . 24
5.1.2.1 Discovering a PGW for a non-3GPP Access – S2a/S2b initial attach for roaming and non-
roaming . 24
5.1.2.2 Discovering a PGW for a non-3GPP Access – S2a/S2b initial attach and chained PMIP-based
S8-S2a/S2b . 24
5.1.3 Discovering a PGW for a non-3GPP Access with DSMIPv6 . 25
5.1.3.1 Discovering a PGW for a non-3GPP Access – S2c initial attach . 25
5.2 Procedures for Discovering and Selecting a SGW . 25
5.2.1 General . 25
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 4 ETSI TS 129 303 V15.5.0 (2019-07)
5.2.2 SGW Selection during TAU or RAU with SGW change - 3GPP roaming case . 26
5.2.3 SGW Selection during TAU or RAU with SGW change - non-roaming case . 27
5.2.4 SGW Selection during non-3GPP handover to 3GPP access . 28
5.3 Procedures for Discovering and Selecting a PGW and SGW . 28
5.4 Procedures for Discovering and Selecting an MME . 29
5.4A Procedures for Discovering and Selecting an AMF . 31
5.5 Procedures for Discovering and Selecting an SGSN . 31
5.5.1 General . 31
5.5.2 SGSN initial target selection based on RAI (UTRAN target/GERAN Iu mode target/GERAN Gb
mode target) . 32
5.5.3 SGSN initial target selection based on RNC-ID (UTRAN target/GERAN Iu mode target) . 33
5.5.4 Void . 34
5.6 GW Selection for SIPTO . 34
5.6.1 SIPTO above RAN . 34
5.6.2 SIPTO at the local network with LGW collocated with the (H)(e)NB . 35
5.6.3 SIPTO at the local network with stand-alone GW (LGW collocated with SGW) . 35
5.6.4 SIPTO for eHRPD . 35
5.7 Procedures for Discovering and Selecting an MSC Server . 35
5.7.1 General . 35
5.7.2 Selection of the MSC server enhanced for SRVCC based on target RAI (UTRAN / GERAN Iu &

A/Gb mode target) . 35
5.8 Procedures to support Dedicated Core Networks . 36
5.8.1 General . 36
5.8.2 SGW, PGW and GGSN Selection Procedure . 37
5.8.3 MMEGI and Null-NRI/SGSN Group ID Retrieval Procedure . 37
5.8.4 MME and SGSN Selection Procedure . 38
5.9 Procedures to support Cellular Internet of Things . 39
5.9.1 DCN based solution . 39
5.9.2 Alternative solution. 39
5.10 Procedures for Discovering and Selecting an SGW-U . 39
5.11 Procedures for Discovering and Selecting PGW-U . 40
5.12 Procedures to select a node supporting a particular network capability . 41
5.12.1 General principles . 41
5.12.1.1 General . 41
5.12.1.2 Selecting a node supporting a particular network capability within a Dedidated Core Network . 41
5.12.1.3 Selecting an SGW or PGW supporting a particular network capability . 42
5.12.2 Procedures to support Dual Connectivity with NR . 42
5.12.2.1 General . 42
5.12.3 Procedures to support interworking with 5GC. 43
5.12.3.1 General . 43
5.12.3.2 PGW-C/SMF selection. 43
5.12.3.3 PGW-U/UPF selection . 43
6 Procedures for OAM System Node Discovery . 44
6.1 Procedures for Relay Node OAM System Discovery . 44
6.1.1 General . 44
6.1.2 OAM System Selection based on Type Allocation Code . 44
7 Procedures for NF Discovery in 5G System . 44
7.1 General . 44
7.2 Procedure for AMF Discovery by 5G-AN . 44
Annex A (Informative): Examples . 46
A.1 Introduction . 46
A.2 Preconditions . 46
A.3 Collocated Simple LTE Example . 46
A.3.1 Network description . 46
A. 3.2 Master file for "Collocated Simple LTE Example" . 47
A. 3.3 SOA and NS records . 47
A. 3.4 MME file for "Collocated Simple LTE Example" . 48
A. 3.5 APN file for "Collocated Simple LTE Example" . 50
A. 3.6 PGW/SGW node file for "Collocated Simple LTE Example" . 50
A. 3.7 TAI/TAC file for "Collocated Simple LTE Example" . 52
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 5 ETSI TS 129 303 V15.5.0 (2019-07)
A. 3.8 MME lookup based on GUTI for "Simple LTE Example" . 54
A. 3.9 APN lookup for "Simple LTE Example" (i.e. PGW candidate list) . 55
A. 3.10 TAI lookup for "Simple LTE Example" (i.e. SGW candidate list) . 57
A. 3.11 Finding the collocated SGW and PGW together . 59
A. 3.12 S11 lookup by SGW canonical node name . 60
A. 3.13 TAI lookup for "Colocation Simple LTE Example" (i.e. MME candidate list) . 61
A.4 LTE Example with Dedicated Core Network . 62
A.4.1 General . 62
A.4.2 APN file for DCN . 62
A.4.3 PGW/SGW node file for "Collocated Simple LTE Example" . 63
A.4.4 TAI/TAC file for DCN . 64
Annex B (Normative): DNS procedures clarifications . 65
B.1 DNS RFC procedures general clarifications . 65
B.2 DNS procedures 3GPP clarifications on S-NAPTR . 65
B.3 DNS procedures 3GPP clarifications for Dedicated Core Networks . 66
B.4 DNS procedures 3GPP clarifications for Network Capability . 66
Annex C (Informative): DNS Pseudo-Code . 66
C.1 S-NAPTR procedure base pseudo-code . 66
C.2 S-NAPTR procedure - no topon . 68
C.3 S-NAPTR procedure candidate list . 69
C.4 S-NAPTR procedure pseudo-code with topon . 69
Annex D (Informative): SGSN examples . 72
D.1 Introduction . 72
D.2 Preconditions . 72
D.3 SGSN file . 72
D.4 Null-NRI/SGSN Group ID file for DCN . 73
Annex E (Informative): SGW/PGW selection examples using GTP-C load control . 74
E.1 PGW selection using GTP-C load control at node level . 74
E.2 PGW selection using GTP-C load control at APN level . 74
E. 2.1 PGW selection when APN load control information is available for each candidate PGW . 74
E.2.2 PGW selection when APN load control information is not available for each candidate PGW . 75
Annex F (Informative): Examples for AMF Discovery by 5G AN . 76
F.1 Introduction . 76
F.2 Preconditions . 76
F.3 Example of an AMF Region with 2 AMF Sets . 76
F.3.1 Master file . 76
F.3.2 SOA and NS records . 76
F.3.3 AMF Set file . 76
Annex G (Informative): Change history . 78
History . 81

ETSI
3GPP TS 29.303 version 15.5.0 Release 15 6 ETSI TS 129 303 V15.5.0 (2019-07)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 7 ETSI TS 129 303 V15.5.0 (2019-07)
1 Scope
The present document describes Domain Name System (DNS) Procedures for the Evolved Packet System. This
document covers the Evolved Packet Core gateway node selection using DNS (e.g. SGW and PGW nodes) excluding
all User Equipment (UE) initiated DNS-based discovery and selection procedures.
The present document specifies functions, procedures and information which apply to GERAN Iu mode. However,
functionality related to GERAN Iu mode is neither maintained nor enhanced.
The present document also describes the Domain Name System (DNS) Procedures for the Evolved Packet System
interworking with the 5G System, as specified in 3GPP TS 23.501 [28] and 3GPP TS 23.502 [29].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] IETF RFC 1034:"DOMAIN NAMES - CONCEPTS AND FACILITIES".
[3] IETF RFC 1035:"DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION".
[4] 3GPP TS 23.003: "Numbering, addressing and identification".
[5] GSMA PRD IR.67: "DNS Guidelines for Operators" Version 2.1.0.
[6] IETF RFC 3596: "DNS Extensions to Support IP Version 6".
[7] IETF RFC 3403: " Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
Name System (DNS) Database".
[8] IETF RFC 2782: "A DNS RR for specifying the location of services (DNS SRV)".
[9] IETF RFC 3958: "Domain-Based Application Service Location Using SRV RRs and the Dynamic
Delegation Discovery Service (DDDS)".
[10] IETF RFC 3401: "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive
DDDS".
[11] 3GPP TS 23.401: "GPRS enhancements for E-UTRAN access ".
[12] 3GPP TS 25.413: "UTRAN Iu interface RANAP signalling".
[13] IETF RFC 2671: "Extension Mechanisms for DNS (EDNS0)".
[14] IETF RFC 3402: "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm".
[15] IETF RFC 2308: "Negative Caching of DNS Queries (DNS NCACHE)".
[16] IETF RFC 3330: "Special Use IPv4 Addresses".
[17] IETF RFC 3849: "IPv6 Address Prefix Reserved for Documentation".
[18] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2".
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 8 ETSI TS 129 303 V15.5.0 (2019-07)
[19] 3GPP TS 36.413: "Evolved Universal Terrestrial Access Network (E-UTRAN); S1 Application
Protocol (S1AP)".
[20] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC)".
[21] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)".
[22] 3GPP TS 36.300: " Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[23] 3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service
(GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3".
[24] 3GPP2 X.S0057-B: "E-UTRAN - eHRPD Connectivity and Interworking: Core Network
Aspects".
[25] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".
[26] 3GPP TS 29.244: "Interface between the Control Plane and the User Plane of EPC Nodes;
stage 3".
[27] 3GPP TS 29.272: "Mobility Management Entity (MME) and Serving GPRS Support Node
(SGSN) related interfaces based on Diameter protocol".
[28] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[29] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".
[30] 3GPP TS 29.273: "Evolved Packet System (EPS); 3GPP EPS AAA interfaces".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP
TR 21.905 [1].
Domain Name System as defined in IETF RFC 1034 [2], IETF RFC 1035[3], and as used in 3GPP in 3GPP TS 23.003
[4] and GSMA PRD IR.67 [5]
The phrase "operators shall provision" in this document is intended to convey what is required to provision in DNS to
provide DNS based selection for the corresponding function documented here. If there is a non-DNS procedure in an
operator's network for that function then there is no functional requirement for the operator to provision such DNS
records.
The term "S4-SGSN" refers to a Release-8 SGSN that has at least one set of S4/S3/S16 interfaces enabled.
The term "Release 8 SGSN supporting only Gn/Gp" refers to a Release 8 or later SGSN that either explicitly does not
support S4 interfaces or all S4/S3/S16 interfaces are disabled due to operator policy. Such a node cannot use an SGW
but can use a collocated PGW/GGSN. See 3GPP TS 23.401 [11] Annex D for use cases.
The term "Release-8 SGSN" applies to either case.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905[1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
3GPP TR 21.905 [1].
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 9 ETSI TS 129 303 V15.5.0 (2019-07)
DCN Dedicated Core Network
DDDS Dynamic Delegation Discovery Service
DNS Domain Name System
ECGI E-UTRAN Cell Global Identification
eHRPD evolved High Rate Packet Data
FQDN Fully Qualified Domain Name
GUTI Globally Unique Temporary Identity
HSGW eHRPD Serving Gateway
LGW Local Gateway
LIPA Local IP Access
NR New Radio
PGW PDN Gateway
RAI Routing Area Identity
SGW Serving Gateway
SIPTO Selected IP Traffic Offload
TAI Tracking Area Identity
TAU Tracking Area Update
TWAN Trusted WLAN Access Network

4 General DNS Based Node Selection Description
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
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 10 ETSI TS 129 303 V15.5.0 (2019-07)
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],
subclause 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"> . .
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
ETSI
3GPP TS 29.303 version 15.5.0 Release 15 11 ETSI TS 129 303 V15.5.0 (2019-07)
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
...