ETSI TS 184 010 V3.1.1 (2011-08)

Telecommunications and Internet Converged Services and Protocols for Advanced Networks (TISPAN); ENUM & DNS Principles for an Interoperator IP backbone network

DTS/TISPAN-04015-NGN-R3

General Information

• Status: Published
• Publication Date: 10-Aug-2011
• Technical Committee: TISPAN 4 - TISPAN Numbering Addressing and routing
• Current Stage: 12 - Completion
• Due Date: 17-Aug-2011
• Completion Date: 11-Aug-2011

Standards Content (Sample)

Technical Specification
Telecommunications and Internet Converged Services and
Protocols for Advanced Networks (TISPAN);
ENUM & DNS Principles for an
Interoperator IP backbone network

2 ETSI TS 184 010 V3.1.1 (2011-08)

Reference
DTS/TISPAN-04015-NGN-R3
Keywords
DNS, ENUM
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
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 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI 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
3 ETSI TS 184 010 V3.1.1 (2011-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Description and Assumptions . 10
4.1 Introduction . 10
4.2 DNS as used on an Interoperator IP backbone network . 11
4.3 IP Connectivity and Service-oriented interconnection services . 12
4.4 Requirements for the Interoperator IP Backbone network . 13
4.4.1 General Issues . 13
4.4.2 Top level requirements . 13
4.4.3 IP Version Issues . 14
4.4.4 IP Addressing. 14
4.4.5 DNS data transport. 14
4.4.6 DNS/ENUM client . 14
4.4.7 Security Issues . 15
4.4.8 Quality of Service . 15
4.4.9 Service Related Issues . 15
5 DNS and ENUM for the Interoperator IP backbone network . 16
5.1 Naming and Addressing within IP Multi-media core network Sub-system (IMS) . 16
5.2 E.164 Number Translation (ENUM) . 16
5.3 Shared ENUM Infrastructure for Inter-operator IP backbone Networks . 16
5.4 Non-root DNS/ENUM architecture . 16
6 Addressing and Routeing . 17
6.1 User Addressing . 17
6.2 Naming of home network . 17
7 ENUM and DNS Structure and Delegation Model . 18
7.1 Introduction . 18
7.2 Model for the Interoperator IP backbone network . 18
7.2.1 Introduction. 18
7.2.2 ENUM & DNS Architecture . 18
7.2.3 Example resolution . 19
7.2.4 Access to ENUM servers . 20
8 Delegation and use of domains . 20
Annex A (informative): Configuration Information for Services that Utilise DNS . 22
A.1 Introduction . 22
A.2 ENUM FQDN Format . 22
A.3 ENUM Tiers . 22
A.4 Technical Requirements for Interconnexion . 23
A.4.1 NAPTR formats . 23
A.4.2 ENUMservice field. 23
A.4.3 URI Formats . 24
A.4.4 SIP server configuration . 24
ETSI
4 ETSI TS 184 010 V3.1.1 (2011-08)
Annex B (informative): General Configuration Information for Providers' DNS Servers . 27
B.1 Introduction . 27
B.2 Hardware . 27
B.3 Software . 27
B.4 Caching. 27
B.5 Reverse Mapping . 27
B.6 Use of DNS Interrogation Modes . 28
B.7 Use of the inter-operator IP backbone network Root DNS Server . 29
B.8 Provisioning of Communications Providers DNS servers . 29
Annex C (informative): Bibliography . 30
History . 31

ETSI
5 ETSI TS 184 010 V3.1.1 (2011-08)
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://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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI
6 ETSI TS 184 010 V3.1.1 (2011-08)
1 Scope
The present document captures a set of assumptions that would help to define a set of ETSI requirements and a possible
architecture for an IPX and in particular the ENUM & DNS aspects. It explains why an IPX may prove useful and
provides guidelines which would apply to its use as a private, inter-operator IP backbone for ETSI TISPAN compliant
networks. It is important that all potential Carriers' IPX implementations, ongoing in the market, should take account of
ETSI NGN standards and specifications in order to ensure different "NGN implementations" may interoperate together.
The present document analyses a particular case of numbering and naming resolution for use by NGN Communications
Providers when providing indirect interconnection as specified in ES 282 001 [18] and covers the need for a standard
solution to address numbering and naming resolution implemented through an ENUM/DNS solution for this particular
case.
A TISPAN IPX does not currently exist. It should not be assumed from the present document that ETSI would look to
set in place an ETSI specific IPX, but the detailed requirements and approach set out within this document will ensure
that ETSI is able to assess the options in moving forward. No decision on the way forward has yet been taken. However
within ETSI there is strong recognition of the benefits that can be gained from adopting a combined approach with other
parties providing the requirements specified by ETSI TISPAN can be accommodated.
The present document would also allow an assessment to be made against the approach that is currently planned to
introduce an IPX by the GSMA.
Whilst the document details possible sub-domains that an operator may use they should only be viewed as possible
examples.
The present document does not put constraints on commercial models.
The present document describes an Infrastructure ENUM that need not to be based on an Interoperator IP backbone, but
it is managed by a confederation of operators also on the basis of a distributed architecture. As a consequence the
applicability of the references to the Interoperator IP backbone network should be evaluated based on the operator's
ENUM implementation.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 1035: "Domain Names - Implementation and Specification".
[2] IETF RFC 6116: "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)".
[3] IETF RFC 3403: "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name
System (DNS) Database".
[4] IETF RFC 3404: "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
Resource Identifiers (URI)".
[5] IETF RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Servers".
ETSI
7 ETSI TS 184 010 V3.1.1 (2011-08)
[6] IETF RFC 2782: "A DNS RR for specifying the location of services (DNS SRV)".
[7] ETSI TS 129 421: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; TISPAN; NGN Release 1; Endorsement of
3GPP TS 29.162 Interworking between IM CN Sub-system and IP networks (3GPP TS 29.421)".
[8] ETSI TS 184 011: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Requirements and usage of E.164 numbers in NGN and
NGCN".
[9] IETF RFC 3261: "SIP: Session Initiation Protocol".
[10] IETF RFC 3966: "'The Tel URI for Telephone Numbers".
[11] IETF RFC 4355: "IANA Registration for Enumservices email, fax, mms, ems, and sms".
[12] IETF RFC 3764: "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-
Record".
[13] IETF RFC 4769: "IANA registration for an ENUM service containing Public Switched Telephone
Network (PSTN) Signalling Information".
[14] ETSI TS 187 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN SECurity (SEC); Requirements".
[15] IETF RFC 2671: "Extension Mechanisms for DNS (EDNS0)".
[16] IETF RFC 5358: "Preventing Use of Recursive Nameservers in Reflector Attacks".
[17] IETF RFC 5452: "Measures for Making DNS More Resilient against Forged Answers".
[18] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Functional Architecture".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IETF RFC 4282: "The Network Access Identifier".
[i.2] GSMA IR67 version 3.1 (Jan 2009).
[i.3] ETSI TR 184 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Portability of telephone numbers between operators for Next
Generation Networks (NGNs)".
[i.4] IETF RFC 3824: "Using E.164 numbers with the Session Initiation Protocol (SIP)".
[i.5] ETSI TR 184 005: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Types of numbers used in an NGN environment".
[i.6] ETSI TR 184 008: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Infrastructure ENUM Options for a TISPAN IPX".
[i.7] ETSI TR 187 002: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); TISPAN NGN Security (NGN-SEC); Threat, Vulnerability and
Risk Analysis".
[i.8] ETSI TR 187 010: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Security; Report on issues related to security in identity
imanagement and their resolution in the NGN".
ETSI
8 ETSI TS 184 010 V3.1.1 (2011-08)
[i.9] ETSI TS 184 006: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Interconnection and Routeing requirements related to
Numbering and Naming for NGNs; NAR Interconnect".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
carrier of record: Service Provider to which the E.164 number was allocated for end user assignment, by the National
Regulatory Authority (NRA) or the International Telecommunication Union (ITU), for instance, a code under
"International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878)
NOTE: In the case that the number is ported the carrier of record maybe changed due the national number
portability (NP) policies. It is understood that the definition of carrier-of-record within a given
jurisdiction is subject to modification by national authorities.
Communications Provider (CP): any entity providing communications services to 'End Users' and using a network to
provide routeing capabilities
delegation: when a part of a zone is maintained separately, it is delegated to a new nameserver that will have authority
of that part of the domain namespace
NOTE: The original zone will have the nameserver (NS) record for the delegated domain and the new sub-zone
will have a new Start Of Authority (SOA) record.
DNS Client: See "DNS Resolver".
DNS Resolver: also known as a "DNS Client", this is an entity that is attempting to resolve a given domain name to an
address or vice versa
NOTE: Usually the DNS Resolver is connected to a local DNS caching server that performs the DNS look-ups on
behalf of the DNS Resolver. Application programs use function calls, such as 'gethostbyname', to find the
IP address representing a domain name. The name may be specified either as a Fully Qualified Domain
Name (FQDN) or only partially. In the latter case, the DNS Resolver appends (a) configured local domain
name(s) at the end of the name.
DNS Server: can be a Nameserver, a Local Caching DNS Server or both
domain name: consists of two or more labels separated with a dot ('.') character
NOTE: It starts from the least significant domain on the left, and ends with the most significant domain (or top-
level domain) on the right. This naming convention naturally defines a hierarchy.
interoperator IP backbone provider: provider of a transit network or transit services that does not offer "services" to
end users, but offers pure IP connectivity or session-based service interconnection to Communications Providers
nameserver: takes care of DNS Queries sent by DNS Resolvers
NOTE: The query is answered by using locally stored information (either configured locally or cached from a
previous query result), by requesting the information from another DNS Server, or by providing the DNS
Resolver with the details of another DNS Server to query. One Nameserver can serve (i.e. be authoritative
for) several domains. There may also be several Nameservers serving one domain (Usually one
Nameserver is the Primary and the other/rest are Secondaries. The Seconedary Namersever request
authoritative DNS data from the Primary Nameserver due to a configured DNS data update process.).
ETSI
9 ETSI TS 184 010 V3.1.1 (2011-08)
Shared ENUM Infrastructure: Inter-operator infrastructure according to ENUM technology as defined in
RFC 6116 [2], used by the originating or an intermediate network to map a specific E.164 number into a URI that
identifies a specific entry point into the network actually serving that specific E.164 number
NOTE: Carrier ENUM infrastructure is different from user ENUM infrastructure where the end-user may register
his E.164 number to be associated with a URI of his desire.
zone: DNS is a distributed database that contains information of each domain name
NOTE: Each DNS server maintains a part of the database called a zone. Usually a zone contains information of
one domain. However, one zone may contain information about many (sub)domains. Each information
element is stored in a record that contains at least a domain name and type (which includes type specific
information).
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
ATM Asynchronous Transfer Mode
BGCF Border Gateway Control Function
BGF Border Gateway Function
BGP Border Gateway Protocol
CC Country Code
CP Communications Provider
CSCF Call Session Control Function
DNS Domain Name System
ENUM Telephone Number Mapping
FQDN Fully Qualified Domain Name
GSMA Global System for Mobile Communications (GSM) Association
GTP GPRS Tunnel Protocol
HTTP Hyper Text Transfer Protocol
IANA Internet Assigned Numbers Authority
I-CSCF Interrogating - Call Server Control Function
IDNA Internationalized Domain Names for Applications
IMS IP Multimedia sub-system
IP Internet Protocol
IPSec Internet Protocol Security
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
IPX IP Packet eXchange
MGCF Media Gateway Control Function
MMS Multimedia Messaging Service
NAI Network Access Identifiers
NAPTR Naming Authority PoinTeR
NGN Next Generation Network
NP Number Portability
NS Name Server
P-CSCF Proxy - Call Service Control Function
PLMN Public Land Mobile Network
QoS Quality of Service
RTP Real-Time Transport Protocol
S-CSCF Server - Call Session Control Function
SEG Security gateway
SIP Session Initiation Protocol
SIP(S) Session Initiation Protocol (Secure)
SLA Service Level Agreement
SMTP Simple Mail Transfer Protocol
SOA Start Of Authority
TCP Transport Control Protocol
UDP User Datagram Protocol
UPSF User Profile Server Function
ETSI
10 ETSI TS 184 010 V3.1.1 (2011-08)
URI Uniform Resource Identifier
VPN Virtual Private Network
4 Description and Assumptions
4.1 Introduction
DNS/ENUM can be used in an ETSI TISPAN compliant environment to support E.164 number resolution and number
portability.
Due to TR 184 003 [i.3] DNS/ENUM can be used to support number portability between operators of NGNs by using a
shared infrastructure or operator local infrastructure (non-root approach). The present document describes the usage of
DNS/ENUM in a shared infrastructure. Nevertheless some general DNS/ENUM protocol requirements are also
applicable in a provider local DNS/ENUM infrastructure.
An inter-operator IP backbone network provides a method of supporting interconnectivity of IP based services and
interconnection between different IMS based IP networks. Many, if not all, of these services rely upon DNS. Therefore,
it is of utmost importance for the interworking and stability of such services that operators have all the necessary
information to hand to ease configuration of their DNS servers that are connected to the Interoperator IP backbone
network for each IP based service provided.
The present document consists of an overview of DNS in relation to the successful interworking of fixed network
services, the configuration of DNS servers, and procedures that would assist in the configuration and usage of domain
names and DNS Servers within an inter-operator IP backbone network.
This network is viewed as a key enabler for the support of full interconnectivity between communications providers.
Whilst competing, Communications Providers deploying Next Generation Networks have the common objective of
delivering traffic to each other in a profitable and cost effective manner. This will enable their customers to realise the
full value of these services and comply with regulatory conditions that are applied to these services/networks. The
common protocol for these networks is IP.
Two basic possibilities exist for Interconnection between communication providers on the network layer as specified in
ES 282 001 [18]:
• Direct connection between two NGN Communication Providers on a bilateral basis (e.g. often using leased
lines and VPN connectivity).
• Indirect Connection via an Interoperator IP backbone network which facilitates interconnectivity for
Communication Provider networks. Such indirect interconnection is isolated from the Internet. Security rules
are defined to prevent unintended access to it.
These two options are not mutually exclusive and it is a commercial decision which method Communications Providers
use. The benefits of connectivity via an IPX include the ability to reach different interworking partners across the globe
via one connection.
These two options are not mutually exclusive and it is a commercial decision which method Communications Providers
use. The benefits of connectivity or "session-based" services via an Interoperator IP backbone provider include the
ability to reach different communication providers using a single network connectivity agreement.
To ensure interoperability of all Communications Providers connected to the Interoperator IP backbone network will
need to adhere to a set of common rules. These include rules regarding architecture functionalities, protocols,
numbering and IP addressing resolution mechanisms, routeing, security, QoS, etc.
The Interoperator IP backbone provider does not offer "services" to end users, but offers pure IP connectivity or
session-based service interconnection to Communications Providers, and may provide transport functions required to
enhance that interconnection, for example ENUM & DNS functionalities, numbering resolution mechanism, routeing
capabilities and, if required, Triggering functionalities (see TS 184 006 [i.9]).
Direct Connectivity between Communications Providers is a viable alternative defined in ETSI TISPAN NGN
standards and specifications, but it is outside of the scope of the present document.
ETSI
11 ETSI TS 184 010 V3.1.1 (2011-08)
The IPX is isolated from the Internet and security rules are defined to prevent unitended access from it.
An interoperator IP Backbone network could be operated by any qualified party. The IP backbone network is expected
to support Quality of Service features end to end, which requires parties involved in the transport of a service up to the
terminating user equipment, to be bound by service level agreements.
4.2 DNS as used on an Interoperator IP backbone network
The proposed approach requires a specific a DNS architecture.
The Master Root DNS node(s) that Interoperator IP backbone providers see are known as "Slave Roots". DNS Servers
and are commonly provisioned by Communication provider. However, these Slave Root DNS Servers can be
provisioned by operators themselves if they so wish. Each Slave Root DNS Server is synchronised with a "back-end"
Root DNS Server known as the "Master Root". This is known as a "Zone Transfer" and ensures that the data is the same
in all interconnected Communication Providers. Figure 1 depicts this.
Master
Zone File
Master/slave
Root
Master
Zone Transfers
Root
Slave
Root
Other shared ENUM
CShared ENUM
Infrastructure
Infrastructure
Queries/Responses
NNI
Other Intermediate
Network
NNI
Intermediate Network(s )
Slave
Root
Local
NNI
DNS
Communication
Provider 2
Communication
Provider 1
NNI
Figure 1: Backbone Architecture
The ENUM&DNS is completely separate and autonomous from the DNS infrastructure of public Internet to be
managed for QoS, availability, security, as required.
Communication Providers will define a bilateral agreement with the Interoperator IP backbone network provider to
manage access procedures to the ENUM&DNS servers for the numbering, naming and addressing resolution.
The access to the Inter-operator IP Backbone network infrastructure and functionalities (for instance to ENUM/DNS,
etc.) and related data population is limited to Communication Provider interconnected with specific Inter-operator IP
backbone network eventually also in charge for NAR resolution and routeing determination.
The data in the Master Root DNS Server is known as the Master Zone File. Access to the master Zone file will only be
available to parties authorised to perform that role by the Interoperator IP backbone providers/Communications
Providers. The population of the data that goes into the Master Zone File has a number of sources, mainly from
Communications Providers, and Interoperator IP backbone providers acting on their behalf. It also needs to be policed
and validated to ensure integrity of the sub-domain allocation and usage. Communications Providers can also query the
root directly.
Figure 2 showing the overall process architecture depicts the administration of the name server information that is
required to populate the master root and slave servers.
ETSI
12 ETSI TS 184 010 V3.1.1 (2011-08)
Interoperator
IPX
Providers
IP backbone
N S Info
DNS
N S Info
Operators
Policing
Problem
Queries
Master Root DNS Server
Operational
Problem
Queries
Support
Administration Interface s
Master
Zone
File
DNS Interface s
Slave
Zone Transfers
Root
DNS
Zone Transfers
Zone Transfers
Interoperator
DNS Queries /Responses Slave Root
IP backbone
Provider 1 DNS
Slave
Zone Transfers
Slave Root  &
Root
DNS Local DNS
DNS
Local
&
DNS
Interoperator
NO 3
Local DNS
IP backbone Provider 1
NO 2
NO 1
Figure 2: Overall Process Architecture
4.3 IP Connectivity and Service-oriented interconnection
services
The Interoperator IP backbone network may permit three connectivity options:
• Transport-Only Connectivity
• Bilateral Service Transit Connectivity
• Multilateral Service Transit for pure IP connectivity or "session-based" services
Transport only connectivity
Communication Providers interconnected indirectly using the Inter-operator IP backbone network with guaranteed QoS.
This model is not service aware and it can be used to transport general IP traffic between two Communications
Providers (provided compliance with security requirements is maintained).
Bilateral Service Transit connectivity for pure IP connectivity or "session-based" services
A bilateral agreement between Communications Providers interconnected indirectly for specific 'session based' services
using as a transit operator the Interoperator IP backbone provider with guaranteed QoS. This model provides the
opportunity to include service based interconnect charging in addition to the transport charging of the transport only
model.
Multilateral service transit for pure IP connectivity or "session-based" services
Communications Providers interconnected indirectly for specific "session-based" services using as a transit operator the
Inter-operator IP backbone network with guaranteed QoS. In this case the transit service is a multilateral one among
Communication Providers.
In order to support interworking of IP services, cascade interconnect billing and multilateral interconnect service hub
(e.g. IP service Proxy) working would be required.
ETSI
13 ETSI TS 184 010 V3.1.1 (2011-08)
Considered purely from a connectivity point of view the required IP network between different operators might take
different forms via the public Internet (with VPN) or direct leased line such as Frame relay or ATM. However
Inter-operator IP backbone network shall be compliant with ETSI TISPAN standards for NGN architectures, protocols,
interconnection, numbering, naming, addressing resolution and routing, etc., utilizing, to enable QoS, availability,
reliability, security, etc., a dedicated inter-operator NGN "IP-based" network, that is totally separate from the public
Internet.
Communication providers should evaluate the alternatives for direct interconnection or indirect interconnection and
choose the most appropriate. Issues such as QoS, security, control of interworking networks, overall reliability and
issuing of new network features such as support for ENUM/DNS are easier handled within direct or indirect
interconnections, being an operators' managed interconnection architecture. The benefits of this approach are more
clearly assessed in TR 184 008 [i.6].
4.4 Requirements for the Interoperator IP Backbone network
4.4.1 General Issues
Considered purely from a connectivity point of view the required IP network between different operators might take
different forms via the public Internet (with VPN) or direct leased line such as Frame relay or ATM. However the
preferred ETSI approach is similar to the model used by 3GPP networks, utilizing a dedicated inter-operator IP
network, that is totally separate from the public Internet.
Using an inter-operator IP backbone network to carry IMS traffic would be less onerous than building direct
connections between each and every IMS network in the world. As the number of operators increases, such an approach
clearly does not scale without the introduction of 'transit IPX carriers' that would result in some form of carrier based IP
backbone network.
Communications Providers should evaluate the alternatives for IMS interworking and choose the most appropriate. One
approach would be to use the inter-operator IP backbone network as the default routing choice but where traffic is high
(typically between national carriers) a leased line or IP-VPN may be more cost effective. As the IP routing is separate
from the physical topology, multiple physical connections may co-exist. In practice operators may have several physical
interconnection links: leased line for national traffic, IP-VPN for medium volume and an inter-operator IP backbone
network for all others. The DNS system will resolve the destination domain to an IP address that will be routed over the
appropriate link.
Issues such as QoS, security, control of interworking networks, overall reliability and issuing of new network features
such as support for ENUM are easier handled inside an inter-operator IP backbone network than when using public
internet to relay IMS traffic between operators. This is due to the fact that the inter-operator IP backbone network can
be considered to be a closed operator controlled network unlike public Internet, which is totally open for everyone. The
benefits of this approach are more clearly assessed in TR 184 008 [i.6].
4.4.2 Top level requirements
NGNs will not emerge at the same rate in all countries due to market differences, economic drivers and technological
differences. It's therefore essential that any proposal to establish an Interoperator IP backbone network takes full
account of the variable timeframe for evolution from country to country. Whilst connectivity at the IPX level can be
facilitated in a number of ways, different countries are likely to require different connectivity implementations within
their national environment, particularly as national databases will already be implemented or planned, closely coupled
with different national number portability implementations. The rapid introduction of NGNs must not be hampered by
the need to change such arrangements in order to facilitate connectivity at the Interoperator IP backbone level.
There will also be an overriding need to ensure compliance with applicable national regulatory requirements and agreed
processes, procedures and operating practices which are adopted at the national level in order to facilitate national
number portability.
Interoperator IP backbone network operators should:
• Comply with any IP addressing guidelines set within ETSI, comply with DNS guidelines as specified in the
present document
• Have IPv4/IPv6 routing capability
ETSI
14 ETSI TS 184 010 V3.1.1 (2011-08)
• Distribute all valid known routes to Communications Providers
• Control which routes a Communications Provider can advertise to the network
• Offer interconnectivity to other inter-operator IP backbone networks (IPX peering)
• Comply with agreed Service Level Agreements
• Conform with security requirements laid out in TS 187 001 [14], TR 187 002 [i.7] and TR 187 010 [i.8]
• Support end-to-end QoS requirements, described in any agreed SLA
• Create the agreements required with other IPX Providers to fulfil the end to end SLA
• Maintain required traffic separation e.g. invoke mechanisms to ensure the underlying IPX network is not
reachable by end users
4.4.3 IP Version Issues
IMS core systems & terminals can be either IPv6, IPv4 based or dual stack. General usage of IPv4 and IPv6 regarding
IMS detailed in TS 129 421 [7].
4.4.4 IP Addressing
Internet routers should not be able to route to the IP addresses advertised to the Inter-ServiceProvider IP Backbone. The
IP Backbone Providers and Service Provider networks shall be totally separated from public Internet, from an IP routing
and connectivity perspective.
Currently, Inter-Service Provider IP Backbone networks use IPv4 addressing but it is assumed that plans to introduce
native IPv6 addressing will emerge in the foreseeable future. Support of IPv6 by native transport or tunnelling the IPv6
traffic over IPv4 between Communications Providers where required are options that could be considered.
Both IP Backbone Providers and Service Providers who employ IPv6 in their network should assume full responsibility
for Communication Providers that deploy IPv4.
An IP Backbone Provider is responsible for the denial of IP spoofing attacks originated by its Service Provider
customers, i.e. only traffic from valid IP address ranges is allowed to flow to other customers or other IP Backbone
Providers.
4.4.5 DNS data transport
Providers shall:
• support the transport of DNS queries and responses require to facilitate routeing
• provide transport of ENUM queries and responses to support any identified services [2]
• support the transport of DNS and ENUM queries and responses via IPv4 and IPv6, UDP and TCP
• support the differentiation between different DNS domains and ENUM domains regarding the IPv4/IPv6
addresses of the DNS caching servers to provide advanced security as well as scalability measures
4.4.6 DNS/ENUM client
An DNS/ENUM client which sends DNS/ENUM queries and receives DNS/ENUM answers (e.g. S-CSCF, BGF, DNS)
resolver should be supported by the following requirements:
• must support the DNS/ENUM basic functional standards RFC 1035 [1], RFC 6116 [2], RFC 3403 [3],
RFC 2782 [6];
• in the case of using UDP as transport protocol the DNS/ENUM client must support RFC 2671 [15] to extend
DNS the limitation of 512 octets in size when DNS protocol messages are sent over UDP;
ETSI
15 ETSI TS 184 010 V3.1.1 (2011-08)
• to ensure a basic level of security the DNS/ENUM client must support RFC 5358 [16] and RFC 5452 [17].
4.4.7 Security Issues
In order to maintain proper level of security within the Interoperator IP backbone network certain requirements for
operators and backbone providers should be taken into account.
It is strongly recommended that operators should implement firewalls adjacent to Border Gateways. Generally operators
should allow only routing information (BGP), GTP traffic, signalling, DNS, SMTP and SIP(S) traffic. However, also
traffic related to IMS user plane (such as RTP and HTTP) should be allowed due to IMS interworking. Therefore, due
to potentially numerous new protocols introduced by IMS interworking, there should not be any kind of restrictions on
the used protocols or port numbers with in the inter-operator IP backbone network.
It is important to note that also firewalls must support IPv6 when IPv6 is used.
Security gateways (SEGs) should be used at the border of an operator network.
IPSec tunnels between CSCFs are not needed, if the Interoperator IP backbone network itself provides comparable level
of security such as IPSec tunnel.
SEG should be responsible for enforcing security policies for the inter-network traffic; all incoming & outgoing IP
traffic would then need to pass through it.
Usage of IPSec is mandatory if connectivity with the public Internet occurs, i.e. IMS connection must always be
secured at some level. If IPSec is used in inter-PLMN IMS connections, it is recommend using the common IPSec
parameter set in order to reduce the number of options.
Above all, operators should realize that the actual security level of the whole IMS system depends on much more than
just securing the transportation between CSCFs. This is done on an operational service level, where it is decided how
these services are deployed and used. ETSI TISPAN IPX itself is nothing else than just IP bearer network, which does
not provide any kind of actual security features besides the fact that no outsider should be able to access the a
Interoperator IP backbone network.
Consideration with TS 187 001 [14], TR 187 002 [i.7] and TR 187 010 [i.8].
Security issues related to IMS services, such as Peer-to-Peer traffic, are for further study.
4.4.8 Quality of Service
An SLA will define a service specification between a communications Provider and an IP backbone provider. The
involved parties may agree an IP QoS profile that should be supported over the connection and this extends to whole
Inter-Service Provider IP backbone network comprising IP backbone Providers maintained networks and routers.
Service guarantees should be defined and the backb
...