TSG-N.

20021209-03

3GPP2 TSG-N
TITLE:

MMS: DNS-ENUM Recipient MDN Address Resolution, NAPTR RRs at Individual

MDN Level

SOURCE:

James Yu Tel: +1-571-434-5572

Fax: +1-571-434-5401
email: james.yu@neustar.biz

ABSTRACT:

This contribution discusses a scheme where MNP is incorporated into the ENUM
provisioning process to resolve the MMSC address that is associated with the recipient
MDN. The carriers are able to assign the NAPTR RRs for individual MDN.

RECOMMENDATION:

Review the scheme. If accepted in concept, the proposed revision to Annex G of

N.P0042/PN-xxxx v0.07 will be submitted later.

NeuStar, Inc. grants a free, irrevocable license to 3GPP2 and its Organizational Partners to
incorporate text or other copyrightable material contained in the contribution and any
modifications thereof in the creation of 3GPP2 publications; to copyright and sell in
Organizational Partner's name any Organizational Partner's standards publication even though it
may include all or portions of this contribution; and at the Organizational Partner's sole discretion
to permit others to reproduce in whole or in part such contribution or the resulting Organizational
Partner's standards publication. NeuStar, Inc. is also willing to grant licenses under such
contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for
purpose of practicing an Organizational Partners standard which incorporates this contribution.

This document has been prepared by NeuStar, Inc. to assist the development of specifications by
3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a
binding proposal on NeuStar, Inc. NeuStar, Inc. specifically reserves the right to amend or
modify the material contained herein and to any intellectual property of NeuStar, Inc. other than
provided in the copyright statement above.
1. Introduction

ENUM (telephone number mapping) has been considered as one of the solutions that
can resolve the MMSC address associated with the recipient Mobile Directory
Number (MDN). Annex G of N.P0042/PN-xxxx v0.07 describes how an ENUM
domain name can be formulated based on the MDN to retrieve the Naming Authority
Pointer (NAPTR) Resource Records (RRs); but it does not address how and where the
NPATR RRs can be retrieved, especially when number portability (NP) or mobile
number portability (MNP) is involved. This contribution intends to describe in more
details on how and where to provision the information at different levels of the
nameservers and to retrieve the NAPTR RRs.

Although this contribution focuses on the MNP with the DNS-ENUM, the proposed
scheme can incorporate non-mobile carriers such as wireline carriers and paging
carriers.

2. ENUM

It has been recognized in the industry that end user ENUM and private ENUM
should use different domain trees to avoid problems such as
- Mingling an end user NAPTR RRs with those of the end users serving carrier
- Swapping the NAPTR RRs from the end users old serving carrier to those from the
new serving carrier when number porting happens
- Who, the end user or the end users serving carrier, decides the nameservers to use to
host the NAPTR RRs? If the end user decides, what if the end user chooses low
capacity and unreliable equipment to run as the nameservers?
This contribution proposes that the carriers use the private ENUM approach to
address the need of the carriers. End user opt-in will not be an issue when private
ENUM is used. Private ENUM implies that a domain tree (e.g., foo.foo) instead of
e164.arpa is used. Normally, ENUM refers to the end user ENUM that uses
e164.arpa. But this contribution treats ENUM as a specific Domain Name System
(DNS) technology because a domain tree other than e164.arpa would be used.
It is assumed that foo.foo is the domain tree that is used by the carriers. A few
ENUM-related entities are defined below.
- Tier 0 Registry: This is the entity that has the delegated authority to the foo.foo
zone. It has the nameserver (NS) RRs of the Tier 1 Registry for each country code
in the foo.foo zone.
- Tier 1 Registry: This is the entity that has the delegated authority to the MDNs
(i.e., ENUM domain names) in a specific country code under the foo.foo zone. It
has the NS RRs of the Tier 2 Registry for each country code in the foo.foo zone.
- Tier 2 Registry: This entity has the following two types:
 * Tier 2 Registry (Carrier): This is the entity that hosts the NAPTR RRs for a
MDN this particular carrier currently serves.
* Tier 2 Registry (CRH): This is the entity run by a carrier that is the code range
holder (CRH) of a MDN that has ported out of that carrier. A carrier is the CRH of
a code range if it was initially assigned that code range before MNP was ever
implemented or was designated as the holder or owner of that code range.
Figure 1a shows the hierarchy of the nameservers used in handling the DNS-ENUM
queries when the Tier 1 Registry has all the MNP information so that Tier 2 Registry
(CRH) is not involved. Figure 1b shows the hierarchy of the nameservers used in
handling the DNS-ENUM queries when the Tier 1 Registry has no MNP information
and the Tier 2 Registry (CRH) is involved.
Each country code is served by a Tier 1 Registry. The Tier 1 Registry provisions the
NS RRs associated with the ENUM domain name for that country code (e.g.,
1.foo.foo) at the Tier 0 Registry. In the following sections, this contribution will not
address the root and the Tier 0 Registry specifically even if their nameservers may be
involved in handling the DNS-ENUM queries.
During the typically domain name registration, an entity named Registrar interfaces
with a Registry (e.g., .biz) to provision the required information at that Registry. In
this contribution, it is assumed that the carriers will play the registrars role or
outsource the role to an authorized entity in the provisioning process.

3. MNP
Some countries have supported MNP and others have not. For those countries that
support MNP, some use the centralized Number Portability Administration Center
(NPAC) to manage the porting events among the carriers or have a way for the
interested parties to get all the porting information in the whole country, while others
dont. In the latter case, the new carrier that is to serve a ported-out MDN from a code
range of the CRH normally informs the CRH about the routing information. In that
case, the CRH is typically involved in routing the call or signaling message. In terms
of the routing information, some countries use routing numbers (RNs) and others use
routing prefixes (RPs). A RN is a different number from the MDN and is used by the
network to route the call or message. A RP is usually placed before the MDN to make
a new MDN for routing.
For easier discussions, the following three scenarios will be used to discuss the
proposed DNS-ENUM/MNP implementations:

A. Tier 1 Registry knows all the MNP information (e.g., from the NPAC or the CRHs
who provide the information about their ported out numbers).
B. Only Tier 2 Registry (CRH) knows the MNP information for THE MDNs ported
out of its code range.
C. The country does not support MNP.
 Root
.

Tier 0
foo.foo Registry

Tier 1
x.x.foo.foo 1.foo.foo x.x.x.foo.foo Registry

Tier 2
4.3.2.1.3.3.5.2.0.2.1.foo.foo 5.4.3.2.3.3.5.2.0.2.1.foo.foo
Registry
[Carrier]

Figure 1a. DNS-ENUM hierarchy when Tier 1 Registry has all the MNP information.
 Root
.

Tier 0
foo.foo Registry

Tier 1
x.foo.foo x.x.foo.foo x.x.x.foo.foo Registry

Tier 2
z.z.z.z.x.x.foo.foo y.y.y.y.x.x.foo.foo Registry
[CRH]

Tier 2
x.x.x.x.x.y.y.y.y.x.x.foo.foo Registry
[Carrier]

Figure 1b. DNS-ENUM hierarchy when Tier 1 Registry has no MNP information.
4. Proposed DNS-ENUM/MNP Scheme

This section discusses the proposed scheme based on the three DNS-ENUM/MNP
implementation scenarios discussed in Section 3.

4.1 Tier 1 Registry knows all the MNP information

This section describes the proposed scheme for country codes such as 1 where Tier
1 Registry can get all the NP information. To better explain this scenario, 1.foo.foo
is used in the examples.

4.1.1 Key Information Provisioned at Tier 1 Registry and Tier 2 Registry (Carrier)

Every CRH of a code range such as +1-202-533 provides the NS RRs associated with
that code range to the Tier 1 Registry. The first 7 digits including the country code 1
of a RN is also a code range. If that code range is only used for RN (e.g., no MDN is
assigned out of that code range), then the carrier also needs to provide the NS RRs for
that code range. If RP instead of RN is used for routing, the NS RRs associated with
each RP that is assigned to a carrier is also provided to the Tier 1 Registry.
There are many ways a Tier 1 Registry can support the DNS-ENUM queries. One
implementation by the Tier 1 Registry is to create the same NS RRs for all the MDNs
in the same code range. It then uses the RN or RP from the MNP information and the
RN/RP-to-NS RRs mapping information to replace the set of NS RRs for a ported out
number from that code range. So if +1-202-533-1234 is ported to a carrier where the
RN is +1-202-544-0000, the set of NS RRs associated with +1-202-544 rather than
that associated with +1-202-533 would be used for 4.3.2.1.3.3.5.2.0.2.1.foo.foo. All
non-ported MDNs in +1-202-533 will have the same set of NS RRs that is associated
with +1-202-533 code range (i.e., the default set of NS RRs).
When +1-202-533-1234 is ported again to another carrier other than the CRH and the
Tier 1 Registry receives the new RN or RP information for the ported MDN, it
identifies the NS RRs associated with the new RN or RP and then updates the zone file
with the new set of NS RRs for 4.3.2.1.3.3.5.2.0.2.1.foo.foo.
If a MDN, +1-202-533-4567, is ported out of the CRH to another carrier, again, Tier 1
Registry will update the zone file by replacing the NS RRs with those associated with
RN or RP of the new carrier for 7.6.5.4.3.3.5.2.0.2.1.foo.foo.
If +1-202-533-1234 is ported back to the CRH, Tier 1 Registry will update the zone
file by using the default set of NS RRs associated with +1-202-533 code range for
4.3.2.1.3.3.5.2.0.2.1.foo.foo.
The Tier 2 Registry (Carrier) provisions the NAPTR RRs in the nameservers identified
by the NS RRs in the Tier 1 Registry for each served MDN. One of the NAPTR RRs
would be for the MMS. Other types of NAPTR RRs can be defined for other
services/applications/uses when needed. This is outside the scope of this contribution.
 The Tier 2 Registry (Carrier) can delete, add or update the NS RRs at the Tier 1
Registry when required.
It is recommended that the Time to Live (TTL) value of the NS and NAPTR RRs be
set to zero when the porting events can happen at any time.
Tier 1 Registry and each Tier 2 Registry (Carrier) also may provision other
information so that they can communicate over non-secure or secure links. That
aspect is not discussed.

4.1.2 DNS-ENUM query handling

The steps in handling a DNS-ENUM query shown in Figure 2 are described below.
1. The originating MMSC generates a DNS-ENUM query requesting for the NAPTR
RR for 4.3.2.1.3.3.5.2.0.2.1.foo.foo.
2. The query may go through a root nameserver and/or a Tier 0 Registrys nameserver
to reach a Tier 1 Registrys nameserver.
3. The Tier 1 Registrys nameserver returns the NS RRs associated with
4.3.2.1.3.3.5.2.0.2.1.foo.foo.
4. The originating MMSC sends the query to one of the nameservers in the NS RRs.
5. A nameserver of the Tier 2 Registry (Carrier) receives the query and responds with
the NAPTR RRs associated with 4.3.2.1.3.3.5.2.0.2.1.foo.foo.
6. The originating MMSC retrieves the NAPTR RR associated with mms, finds out
the IP address corresponding to the domain name and sends the MMS message to
that IP address.

Root

Tier 0
Registry

4.3.2.1.3.3.5.2.0.2.1.foo.foo
Orig.
MMSC Tier 1
NS RRs
Registry
4.3.2
.1
.3.3.5
.2.0.2
.1.fo
o.foo
NAP
TR R
Rs
Tier 2 Registry
(Carrier)

Figure 2. DNS-ENUM query handling when Tier 1 Registry has all the MNP information.
4.2 Tier 2 Registry (CRH) involved in DNS-ENUM process

This section describes the proposed scheme for country codes where Tier 1 Registry
does not have the MNP information. All DNS-ENUM queries must go through the
Tier 2 Registry (CRH) before reaching the Tier 2 Registry (Carrier).

4.2.1 Key Information Provisioned at Tier 1 Registry, Tier 2 Registry (CRH) and Tier
2 Registry (Carrier)

Every CRH of a code range such as +CC-xxx-yyy that has THE MDNs out of that
code range assigned to the subscribers provides the NS RRs associated with that code
range to the Tier 1 Registry. Since the Tier 1 Registry does not know any RN or RP
information, there is no need to provide the NS RRs associated with the RN or RP.
The Tier 1 Registry creates a set of the NS RRs for a code range pointing to the
nameservers of the Tier 2 Registry (CRH) of that code range. This information is
static so the TTL for those NS RRs can have a typical TTL value (e.g., days or weeks).
Every carrier provides the NS RRs associated with each of its code ranges, RNs and/or
RPs to other carriers. When a carrier receives a ported-in MDN, it informs the Tier 2
Registry (CRH) about the RN or RP for that MDN. The Tier 2 Registry (CRH) then
updates the zone file by using the NS RRs associated with the RN or RP of the Tier 2
(Carrier) for that ported-out MDN. The Tier 2 Registry (Carrier) can also provide the
RN or RP and the associated NS RRs to the Tier 2 Registry (CRH) when it informs the
Tier 2 Registry (CRH) about a newly ported-in MDN if it does not provide the NS
RRs for all its RNs and/or RPs.
The Tier 2 Registry (CRH) is the one responsible for updating the NS RRs associated
with each of its ported-out MDNs including the occasion when a ported-out MDN is
ported back.
The Tier 2 Registry (Carrier) provisions the NAPTR RRs in the nameservers identified
by the NS RRs in the Tier 2 Registry (CRH) for each served MDN including the
ported-in MDN. One of the NAPTR RRs would be for the MMS.
It is recommended that the Time to Live (TTL) value of the NS RRs at the Tier 2
Registry (CRH) and the NAPTR RRs at the Tier 2 Registry (Carrier) be set to zero
when the porting events can happen at any time.
The Tier 2 Registry (Carrier) can delete, add or update the NS RRs at the Tier 2
Registry (CRH), and the Tier 2 Registry (CRH) can delete, add or update the NS RRs
at the Tier 1 Registry when required.
A Tier 1 Registry and each Tier 2 Registry (CRH) or a Tier 2 Registry (CRH) and each
Tier 2 Registry (Carrier) also may provision other information so that they can
communicate over non-secure or secure links.

4.2.2 DNS-ENUM query handling

The steps in handling a DNS-ENUM query shown in Figure 3 are described below.
 1. The originating MMSC generates a DNS-ENUM query requesting for the NAPTR
RR for 9.8.7.3.3.3.1.1.1.c.c.foo.foo.
2. The query may go through a root nameserver and/or a Tier 0 Registrys nameserver
to reach a Tier 1 Registrys nameserver.
3. The Tier 1 Registrys nameserver returns the NS RRs associated with
3.3.3.1.1.1.c.c.foo.foo.
4. The originating MMSC sends the query to one of the nameservers in the NS RRs.
5. A nameserver of the Tier 2 Registry (CRH) receives the query and responds with
the NS RRs associated with 9.8.7.3.3.3.1.1.1.c.c.foo.foo.
6. The originating MMSC sends the query to one of the nameservers in the NS RRs.
7. A nameserver of the Tier 2 Registry (Carrier) returns the NAPTR RRs associated
with 9.8.7.3.3.3.1.1.1.c.c.foo.foo.
8. The originating MMSC retrieves the NAPTR RR associated with mms, finds out
the IP address corresponding to the domain name and sends the MMS message to
that IP address.

Root

Tier 0
Registry

9.8.7.3.3.3.1.1.1.c.c.foo.foo
Tier 1
Orig.
NS RRs Registry
MMSC
9.8.7.3.3
.3.1.1.1
.c.c.foo
.foo
NS RR
s
9.8.
7.3. Tier 2 Registry
3.3.
1.1. (CRH)
1.c.
NAP c.fo
TR o.fo
RRs o

Tier 2 Registry
(Carrier)

Figure 3. DNS-ENUM query handling when Tier 1 Registry has no MNP information.

4.3 No MNP

This section describes the proposed scheme for country codes where MNP is not
supported. In this case, the Tier 2 Registry (CRH) is the same as the Tier 2 Registry
(Carrier). The Tier 2 Registry (Carrier) is used in the description.
4.3.1 Key Information Provisioned at Tier 1 Registry and Tier 2 Registry (Carrier)

Again, every CRH of a code range such as +CC-xxx-yyy that has THE MDNs out of
that code range assigned to the subscribers provides the NS RRs associated with that
code range to the Tier 1 Registry. Since this country does not support MNP, no RN or
RP and no NS RRs associated with the RN or RP are involved.

The Tier 1 Registry creates a set of the NS RRs for a code range pointing to the
nameservers of the Tier 2 Registry (Carrier) of that code range. This information is
static so the TTL for those NS RRs can have a typical TTL value.

The Tier 2 Registry (Carrier) provisions the NAPTR RRs in the nameservers identified
by the NS RRs in the Tier 1 Registry for each served MDN. One of the NAPTR RRs
would be for the MMS. The NAPTR RRs can have typical TTL values if the
information does not change frequently.

The Tier 2 Registry (Carrier) can delete, add or update the NS RRs at the Tier 1
Registry when required.

A Tier 1 Registry and each Tier 2 Registry (Carrier) also may provision other
information so that they can communicate over non-secure or secure links.

4.3.2 DNS-ENUM query handling

The steps in handling a DNS-ENUM query are the same as those described in Section
4.1.2 except that the ENUM domain name is different (e.g., not country code 1).

5. Conclusion

This contribution proposes to use private ENUM to resolve the MMSC domain
name for a MDN whether it is portable or not. MNP is addressed by incorporating the
MNP information into the ENUM provisioning process.

The DNS technology is well known and the infrastructure is out there. Once a Tier 1
Registry for a country is chosen, the NS RRs and the MNP information, if applicable,
are incorporated into the nameservers of the Tier 1 Registry, the NS RRs are in the
nameservers of the Tier 2 Registry (CRH) when applicable, and the NAPTR RRs are
in the nameservers of the Tier 2 Registry (Carrier), the MMSC resolution based on the
recipient MDN in that country can be done.

Additional NAPTR RRs can be defined using the same domain tree for other
services/applications/uses such as:

- The domain name of the Short Message Service Center or Message Center for a
MDN.
- The domain name of the Home Location Register (HLR) for a MDN.
- The domain name of the location server for a MDN.
- The RN or RP for a MDN (equivalent to a dip to the NP database)

This infrastructure also can be used to retrieve Signaling System Number 7 (SS7)
point code and/or subsystem number (PC/SSN) information associated with various
services or network elements to reduce the traffic over SS7 network and/or the cost of
SS7 message transport.

The proposed scheme will meet the wireless carriers need if they allow the NAPTR
RRs at the individual MDN level. As discussed in an accompanying contribution,
TSG-N.20021209-04, the carriers can use a simpler approach by using the same set of
NAPTR RRs for the MDNs in the same code range or RP. It is recommended that
3GPP2 evaluate the two approaches and determine which one, the NAPTR RRs at
individual MDN level or the NATPR RRs at the code range or RP level, should be
adopted.