ETSI TS 129 303 V8.0.0 (2009-01) Technical Specification Universal Mobile Telecommunications System (UMTS); LTE; Domain Name System Procedures (3GPP TS 29.303 version 8.0.0 Release 8) 3GPP TS 29.303 version 8.0.0 Release 8 1 ETSI TS 129 303 V8.0.0 (2009-01) Reference DTS/TSGC-0429303v800 Keywords LTE, UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 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 Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. 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 http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 2009. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI 3GPP TS 29.303 version 8.0.0 Release 8 2 ETSI TS 129 303 V8.0.0 (2009-01) Intellectual Property Rights IPRs essential or potentially essential to the present document 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 (http://webapp.etsi.org/IPR/home.asp). 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. Foreword 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, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp. ETSI 3GPP TS 29.303 version 8.0.0 Release 8 3 ETSI TS 129 303 V8.0.0 (2009-01) Contents Intellectual Property Rights................................................................................................................................2 Foreword.............................................................................................................................................................2 Foreword.............................................................................................................................................................5 1 Scope........................................................................................................................................................6 2 References................................................................................................................................................6 3 Definitions, symbols and abbreviations...................................................................................................6 3.1 Definitions..........................................................................................................................................................6 3.2 Abbreviations.....................................................................................................................................................7 4 General DNS Based Node Selection Description....................................................................................7 4.1 Resource Records...............................................................................................................................................7 4.1.1 A and AAAA................................................................................................................................................7 4.1.2 NAPTR.........................................................................................................................................................7 4.1.3 SRV..............................................................................................................................................................7 4.2 Selecting Domain Names...................................................................................................................................8 4.3 Identifying Nodes, Services and Protocols.........................................................................................................8 4.3.1 IETF RFC 3958 Service and Protocol service names for 3GPP...................................................................8 4.3.2 Identification of node names.........................................................................................................................8 4.3.3 Services from node names............................................................................................................................9 4.3.3.1 General....................................................................................................................................................9 4.3.3.2 Procedure................................................................................................................................................9 4.3.3.3 Services of a PGW from PGW node name...........................................................................................10 4.3.3.4 Services of a MME from MME node name (or GUTI).........................................................................10 4.3.3.5 Services of an SGSN from a P-TMSI...................................................................................................10 5 Procedures for EPC Node Discovery and Selection...............................................................................11 5.1 Procedures for Discovering and Selecting a PGW...........................................................................................11 5.1.1 Discovering a PGW for a 3GPP Access.....................................................................................................11 5.1.1.1 General..................................................................................................................................................11 5.1.1.2 Discovering a PGW for a 3GPP Access - S8/Gp roaming case............................................................11 5.1.1.3 Discovering a PGW for a 3GPP Access - S5/Gn intra-operator existing PDN.....................................12 5.1.1.4 Discovering a PGW for a 3GPP Access - S5/Gn intra-operator initial attach.......................................12 5.1.2 Discovering a PGW for a non-3GPP Access with Network Based Mobility Management........................13 5.1.2.1 Discovering a PGW for a non-3GPP Access – S2a/S2b initial attach for roaming and non- roaming.................................................................................................................................................13 5.1.2.2 Discovering a PGW for a non-3GPP Access – S2a/S2b initial attach and chained S2a/S2b with GTP or PMIPv6 based S8.....................................................................................................................13 5.2 Procedures for Discovering and Selecting a SGW...........................................................................................13 5.2.1 General........................................................................................................................................................13 5.2.2 SGW Selection during TAU with SGW change - 3GPP roaming case......................................................14 5.2.3 SGW Selection during TAU with SGW change - non-roaming case.........................................................14 5.3 Procedures for Discovering and Selecting a PGW and SGW..........................................................................15 5.4 Procedures for Discovering and Selecting an MME........................................................................................15 5.5 Procedures for Discovering and Selecting an SGSN........................................................................................16 5.5.1 General........................................................................................................................................................16 5.5.2 SGSN initial target selection based on RAI................................................................................................16 5.5.3 SGSN initial target selection based on RNC-ID (UTRAN target)..............................................................17 Annex A (Informative): Examples.........................................................................................................18 Annex B (Normative): DNS procedures clarifications......................................................................19 B.1 DNS RFC procedures general clarifications..........................................................................................19 B.2 DNS procedures 3GPP clarifications on S-NAPTR...............................................................................19 ETSI 3GPP TS 29.303 version 8.0.0 Release 8 4 ETSI TS 129 303 V8.0.0 (2009-01) Annex C (Informative): DNS Pseudo-Code..........................................................................................20 C.1 S-NAPTR procedure base pseudo-code.................................................................................................20 C.2 S-NAPTR procedure - no topon.............................................................................................................21 C.3 S-NAPTR procedure candidate list........................................................................................................22 C.4 S-NAPTR procedure pseudo-code with topon.......................................................................................23 Annex D (Informative): Change history...............................................................................................25 History..............................................................................................................................................................26 ETSI 3GPP TS 29.303 version 8.0.0 Release 8 5 ETSI TS 129 303 V8.0.0 (2009-01) Foreword This Technical Specification has been produced by the 3rd 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 8.0.0 Release 8 6 ETSI TS 129 303 V8.0.0 (2009-01) 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. 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". 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]. ETSI 3GPP TS 29.303 version 8.0.0 Release 8 7 ETSI TS 129 303 V8.0.0 (2009-01) 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] 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]. DNS Domain Name System DDDS Dynamic Delegation Discovery Service FQDN Fully Qualified Domain Name GUTI Globally Unique Temporary Identity PGW PDN Gateway SGW Serving Gateway TAI Tracking Area Identity TAU Tracking Area Update 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. 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, to move services from host to host, and to designate some hosts as primary servers for a service from a ETSI 3GPP TS 29.303 version 8.0.0 Release 8 8 ETSI TS 129 303 V8.0.0 (2009-01) 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 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 some other identifier (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 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 record names, in general, represent a host 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 name of a specific node. When comparing 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. The canonical 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 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 names. The following list contains examples of domain names where canonical node names are in bold: topon.Eth-0.gw32.california.west.company.com topon.S8.gw32.california.west.company.com ETSI 3GPP TS 29.303 version 8.0.0 Release 8 9 ETSI TS 129 303 V8.0.0 (2009-01) topon.vip.sgw3.oregon.west.company.com topon.board3.pgw1.cluster1.net27.operator.com topon.S5.gw4.cluster1.net27.operator.com topon.board3.pgw1.cluster2.net27.operator.com In the examples above, "Eth-0.gw32.california.west.company.com" and "S8.gw32.california.west.company.com" are two different interfaces on the same node, "gw32.california.west.company.com". On the other hand, "gw4.cluster1.net27.operator.com" is topologically closer to "pgw1.cluster1.net27.operator.com" (they are both connected to the "cluster1.net27.operator.com" subnetwork) than to "pgw1.cluster2.net27.operator.com" (only connected to the wider "net.27.operator.com" 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 here is believed to be simpler and more logical to maintain than additional DNS records. The topologically aware naming restriction shall be placed only on all targets pointing to A/AAAA record sets from the S-NAPTR procedure. This restriction shall NOT apply to any other records the operator may be using. A NAPTR with flag "a" will have a replacement target pointing to the A/AAAA record directly, thus the topologically aware naming restriction applies to the NAPTR record with a flag "a". For the flag "s" case the topologically aware naming restriction applies to the targets in the SRV record, and not the NAPTR record replacement target. For the empty flag "" case the topologically aware naming does not apply restriction. After successfully completing the S- NAPTR procedure the operator is free to add another layer of indirection using a CNAME record. Topological matching with "topon" shall have higher importance in ordering which DNS records are used than the S- NAPTR ordering. Approximately, collocated sets of nodes have highest importance, then sets of nodes with the most labels in their common suffix, then second most number of labels and so on. Additional 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 4.3.3.1 General There are potential use cases where a node has a logical name of a peer or other identifier but does not have the protocols it supports. The NAPTR record for any of the services can be provisioned at the nodes logical name. The node logical name here equals to the domain name under which NAPTR records are provisioned. This allows any peer to discover the available services of any other peer based on node"s logical name. 4.3.3.2 Procedure 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 (such as GUTI, TAC, IMSI, MISDN etc.), or the canonical node name obtained from the S-NAPTR. Note that a node can have more than one name but there should be only one canonical name. (CNAME records can be used to create aliases for the canonical name) 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 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 ETSI