One document matched: draft-ietf-enum-softswitch-req-01.txt
Differences from draft-ietf-enum-softswitch-req-00.txt
ENUM J. Lim
Internet-Draft W. Kim
Intended status: Informational C. Park
Expires: April 27, 2008 NIDA
L. Conroy
RMRL
October 25, 2007
ENUM-based Softswitch Requirement
<draft-ietf-enum-softswitch-req-01.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Lim, et al. Expires April 27, 2008 [Page 1]
Internet-Draft Softswitch ENUM Use April 2007
Abstract
This document describes experiences of operational requirements and
several considerations for ENUM-based softswitches concerning call
routing between two Korean VoIP carriers, gained during the ENUM pre-
commercial trial hosted by National Internet Development Agency of
Korea (NIDA) in 2006.
These experiences show that an interim solution can maintain the
stability of on-going commercial softswitch system operations during
the initial stage of ENUM service, where the DNS does not have
sufficient data for the majority of calls.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Call Routing on Softswitch . . . . . . . . . . . . . . . . . . 4
3. Infrastructure ENUM trial in Korea . . . . . . . . . . . . . . 5
4. Requirement for ENUM-based Softswitch . . . . . . . . . . . . 6
4.1. call routing cases for DNS response code . . . . . . . . . 6
4.2. type of domain routing . . . . . . . . . . . . . . . . . . 7
5. Trial Results . . . . . . . . . . . . . . . . . . . . . . . . 9
6. 'e164.arpa' considerations . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Lim, et al. Expires April 27, 2008 [Page 2]
Internet-Draft Softswitch ENUM Use April 2007
1. Introduction
ENUM[1] is a mapping system based on DNS[2][3] that converts from an
E.164[4] number to a domain name using 'Naming Authority
Pointer(NAPTR)' resource record[5]. ENUM is able to store different
service types (such as fax, email, homepage, SIP, H.323 and so on),
for every E.164 number. It originally focused on how end-users could
gain access to other end-user's communications contact information
through the Internet.
Recently, discussion on the need to update RFC 3761 has begun, to
ensure that the standard also works in the "Infrastructure ENUM"
scenario, where ENUM provides routing information between carriers.
When providing VoIP service, a VoIP carrier that wants to integrate
various protocols typically uses a softswitch. However, such a
system is still inefficient for interconnection, number portability,
and protocol information among carriers, because each softswitch does
not have end-to-end routing information for all carriers. This
information can be stored in DNS, using ENUM. Therefore, carriers
can expect many benefits if they use ENUM within the call routing
functions of their softswitches.
To confirm these benefits and to verify the performance of ENUM-
enabled softswitches, NIDA cooperated with two Korean VoIP service
providers for an Infrastructure ENUM trial in 2006. NIDA is a non-
profit organization with a mandate to manage 2.8.e164.arpa.
(representing the +82 country code of Korea). NIDA promotes and
facilitates technical cooperation on a national scale between
partners, and this includes ENUM. During the trial, NIDA provided a
centralized ENUM DNS to each VoIP service provider for call routing.
The data used in this Infrastructure trial was also accessible to the
public (i.e. it was an Internet-based system, rather than a closed
scheme).
Lim, et al. Expires April 27, 2008 [Page 3]
Internet-Draft Softswitch ENUM Use April 2007
2. Call Routing on Softswitch
In the PSTN (Public Switched Telephone Network), hardware-based
switches predominate in the network. A softswitch provides similar
functionality, but is implemented on a computer system by software.
It typically have to support various signalling protocols (such as
SIP[7], H.323[8], MGCP[9], and others), to make call connections for
VoIP service, often on the boundary point between the circuit and
packet network.
To make a call, first of all a softswitch must discover routing
information. It has to process the E.164 number that comes from
caller through its own routing table. The goal is to determine how
the call can be routed towards the callee, so that either the call
can be processed through the softwitch or the caller can connect to
the callee directly.
Today, call routing is often based on a prefix of the dialled number.
This is used very widely not only for legacy PSTN switch, but also
for softswitches. So, if a softswitch uses ENUM DNS for call
routing, in the beginning, most of calls queried to ENUM DNS would
fail if there are only a small group of carriers provisioning data
into ENUM. However a softswitch will have a higher success rate with
ENUM DNS as the number of carriers grows, as the overall percentage
of numbers provisioned in ENUM increases. In short, ENUM as a long
term solution has obvious benefits, but the problem lies in migrating
from today's prefix based routing towards that long term ENUM-based
solution.
Lim, et al. Expires April 27, 2008 [Page 4]
Internet-Draft Softswitch ENUM Use April 2007
3. Infrastructure ENUM trial in Korea
As described in Section 1, NIDA and two VoIP Service Providers built
ENUM-processing modules into their softswitches, interconnected these
via the IP network, and provisioned their customer numbers into a
centralized ENUM DNS system operated by NIDA. The carriers
provisioned their E.164 numbers using EPP [10] to a centralized
Registration Server (also operated by NIDA). Changes to the ENUM
data were implemented and updated to the ENUM DNS instantly, using
DNS Dynamic Update [11].
In the trial, the EPP-based provisioning sub-system was not
integrated with the carrier's main customer provisioning systems or
protocols, and as there were only two carriers a centralized ENUM
system using EPP was a perfectly reasonable choice.
Call routing
+---------------------------------------------+
| |
| |
+-----+------+ +-----------------+ +------+-----+
|Softswitch A|------| ENUM DNS(+82) |------|Softswitch B|
+-----+------+ | (Tier1,2) | +------+-----+
| +--------+--------+ |
+-----+------+ | +------+-----+
| IP Phone A | |Dynamic update | IP Phone B |
+------------+ |(RFC 2136) +------------+
|
+------------+ +--------+--------+ +------------+
| EPP Client | | Registration | | EPP Client |
| |------| server |------| |
+------------+ +-----------------+ +------------+
Provisioning E.164 Numbers(RFC 4114)
Carrier A NIDA Carrier B
Figure 1: Infrastructure ENUM Trial System Topology
Lim, et al. Expires April 27, 2008 [Page 5]
Internet-Draft Softswitch ENUM Use April 2007
4. Requirement for ENUM-based Softswitch
4.1. call routing cases for DNS response code
To use ENUM DNS, each softswitch needs to have an ENUM module that
converts from E.164 number to the ENUM domain name (as defined in RFC
3761) and processes a query to ENUM DNS. This ENUM module uses the
algorithm specified in RFC 3761.
However, in the initial stage of ENUM DNS roll-out, ENUM shares call
routing information from a limited number carriers. There is the
problem that a softswitch can't find all of the call routing
information it needs only in ENUM. To solve this problem, ENUM-based
softswitches have to follow a consistent set of rules. In the Korean
trial, the rules were:
1. The ENUM module of the softswitch converts E.164 number coming
from the VoIP subscriber to an ENUM domain name (as defined in
RFC 3761).
2. The ENUM module, acting as a DNS stub resolver, sends a query to
a recursive name server.
3. if the ENUM module receives a DNS answer, the call routing
process may branch off in several ways, depending on the Rcode
value in the DNS response message, as shown below.
A. Rcode=0 (No error condition)
There is, potentially, an answer to the corresponding query.
The normal call routing process needs to differentiate
between the following conditions:
+ If the response includes no URI that can be used to
initiate a call (such as SIP or H.323).
The call fails immediately.
+ If there is more than one usable URI (such as a SIP and a
H.323 URI, a pair of SIP URIs, or a pair of H.323 URIs),
the softswitch picks one based on the preference and order
values in the NAPTR RRSet.
B. Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4
(Not Implemented) or 5 (Refused)
There is no valid answer for the query.
The softswitch has no choice but to convert the E.164 number
with its vendor-specific method (such as a prefix-based
method). In this case, it means that the call has to be
delivered through PSTN for onward call routing.
Lim, et al. Expires April 27, 2008 [Page 6]
Internet-Draft Softswitch ENUM Use April 2007
It is also important to stress that the ENUM DNS servers MUST
respond to all queries they receive from the softswitches.
If the ENUM module in a softswitch does not receive a
response, it will eventually time out, and the ENUM module
will treat this as a DNS error. However, the delay involved
is long in terms of the normal call setup time, and should be
avoided.
4.2. type of domain routing
If the DNS response has a valid URI such as SIP or H.323, the
softswitch can resolve a domain name of that URI to route a call by
searching two different sources. One is a recursive nameserver, and
the other is fixed routing table in softswitch, mapping from the
domain name to the corresponding gateway's host name and IP address.
If there are many points of interconnection, using a recursive
nameserver is useful for resolving a domain name, but if there are
just a few known carriers and they do not change the interconnection
information frequently, a fixed routing table mapping domain name to
corresponding gateway hostname and IP address is more efficient
(rather than querying the recursive nameserver every time). In
addition, carriers would like to charge a interconnection fee for all
received calls, so they tend to make interconnection only with
trusted carriers based on some sort of agreement between these
carriers. They may agree on a specific gateway for this purpose.
These two types of domain routing are also affected by the Rcode=0
case described in Section 4.1.
There are two choices for routing. These are described and compared
here:
1. Case for using fixed routing table
A. If domain name part of URI is found in the internal fixed
routing table, the softswitch can use it.
B. If the domain name part of URI does not exist in the fixed
routing table, the call is forwarded to the PSTN.
2. Case for using recursive nameserver
A. If domain name part of URI can be resolved via the recursive
nameserver, softswitch can use it.
B. If domain name part of URI cannot be resolved on recursive
nameserver for any reason (such as a response with no usable
Lim, et al. Expires April 27, 2008 [Page 7]
Internet-Draft Softswitch ENUM Use April 2007
NAPTRs, or with Rcode=1, 2, 3, 4, or 5), call must be
forwarded to PSTN.
Case (1) seems inefficient because the administrator maintains two
management points for numbers; the ENUM DNS and the softswitch
itself. However this configuration can minimize the call routing
failure ratio during the transition period of ENUM (when there are
relatively few provisioned ENUM entries). Thus case (1) could
reasonably be implemented on the softswitches during the trial phase,
and hereafter as ENUM entries are populated, case (2) would be
reasonable choice.
With these requirements, the two carriers could use ENUM DNS for call
routing without any impact on their on-going commercial VoIP service.
Lim, et al. Expires April 27, 2008 [Page 8]
Internet-Draft Softswitch ENUM Use April 2007
5. Trial Results
To provide a stable commercial service, an ENUM-based Softswitch must
have a defined performance, in the same way as must a Non-ENUM
Softswitch. The only difference between these two types of
softswitch is the searching mechanism for call routing information,
which can be stored in softswitch itself or in the DNS. Therefore a
similar delay time for call routing is important to guarantee quality
of Service. During the trial, each carrier measured this delay time
based on SIP protocol (the so called "Answer Delay time"), defined as
elapsed time between requesting a call ('INVITE' message) and
receiving a response ('200OK'message) [7].
+------------------------+------+----------+
| Call Type | ENUM | Non-ENUM |
+------------------------+------+----------+
| Carrier A->A | 2.33 | 2.28 |
| | | |
| Carrier A->B | 2.23 | 2.25 |
| | | |
| Carrier A->other(PSTN) | 4.11 | 3.79 |
| | | |
| Carrier B->B | 2.18 | 2.05 |
| | | |
| Carrier B->A | 2.19 | 2.19 |
| | | |
| Carrier A->other(PSTN) | 3.95 | 3.41 |
+------------------------+------+----------+
Table 1: Average Answer Delay time (sec)
As shown in Table 1, there is little difference in time (under a
second) between the ENUM and Non-ENUM cases. Therefore it is
difficult for a caller with either carrier to notice the choice (ENUM
or non-ENUM) as an aspect of quality when a call initiates. This
means that ENUM definitely works well with softswitches on a
commercial basis.
To make the trial more realistic, the resolver that was used by ENUM-
based softswitch was a recursive nameserver that could be accessed
publicly. This was done as it was felt that a tough condition would
be better to verify the fact that an ENUM-based softswitch works as
well as Non-ENUM softswitch in providing a commercial VoIP service.
Lim, et al. Expires April 27, 2008 [Page 9]
Internet-Draft Softswitch ENUM Use April 2007
6. 'e164.arpa' considerations
During the trial, the Infrastructure ENUM deployed in the
2.8.e164.arpa zone could be accessed via the (public) Internet. In
this situation, each carrier questioned whether the centralized
number management under the ENUM DNS was realistic or not.
Another issue concerned responsibility for routing errors. All
carriers can use the shared ENUM data to route their calls. However,
if there are routing errors (due to the data being provisioned
incorrectly), it is not always clear who has responsibility for these
errors and who can correct the data. The errors occur in the
networks of the carriers placing the calls. Unless the identity of
the carrier responsible for delivering service to this telephone
number is known, it is not obvious (to the carrier handling the
error) who should be informed of these problems.
In addition, the carriers also question why Infrastructure ENUM needs
to be accessible publicly. To prevent disclosure of telephone
numbers, they prefer to access the ENUM DNS privately. Therefore any
ENUM module embedded in a softswitch needs to be flexible, to adopt
these considerations during the interim period of ENUM.
Lim, et al. Expires April 27, 2008 [Page 10]
Internet-Draft Softswitch ENUM Use April 2007
7. Security Considerations
This document basically follows the same security consideration of
RFC 3761 and 'draft-ietf-enum-infrastructure-05.txt'[6] because the
ENUM DNS could be accessed publicly.
In addition, If the recursive DNS handling ENUM queries coming from a
softswitch is compromised by an attacker, it will be able to fail a
call or cause delay to a call. Therefore, the recursive DNS used
should allow access from the local network to which the softswitch is
connected, whilst restricting access from outside, using a proper
access-list policy.
Lim, et al. Expires April 27, 2008 [Page 11]
Internet-Draft Softswitch ENUM Use April 2007
8. IANA Considerations
This document is only advisory, and does not have any IANA
considerations.
Lim, et al. Expires April 27, 2008 [Page 12]
Internet-Draft Softswitch ENUM Use April 2007
9. Acknowledgements
Thanks to Richard Shockey, Jason Livingood, Karsten Fleischhauer, Jim
Reid and Otmar Lendl who helped guide the direction of this document.
Lim, et al. Expires April 27, 2008 [Page 13]
Internet-Draft Softswitch ENUM Use April 2007
10. References
10.1. Normative References
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[2] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[3] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[4] ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164, February 2005.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[6] Livingood, J., Pfautz, P., and R. Stastny, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application for Infrastructure ENUM",
draft ietf-enum-infrastructure-05.txt (work in progress),
January 2007.
10.2. Informative References
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[8] ITU-T, "Packet-based multimedia communications systems",
Recommendation H.323, 2003.
[9] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[10] Hollenbeck, S., "E.164 Number Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 4114, June 2005.
[11] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
Lim, et al. Expires April 27, 2008 [Page 14]
Internet-Draft Softswitch ENUM Use April 2007
Authors' Addresses
JoonHyung Lim
National Internet Development Agency of Korea(NIDA)
3F. KTF B/D 1321-11
Seocho-dong
Seocho-gu
Seoul
Korea
Phone: +82-2-2186-4548
Email: jhlim@nida.or.kr
URI: http://www.nida.or.kr
Weon Kim
National Internet Development Agency of Korea(NIDA)
3F. KTF B/D 1321-11
Seocho-dong
Seocho-gu
Seoul
Korea
Phone: +82-2-2186-4502
Email: wkim@nida.or.kr
URI: http://www.nida.or.kr
ChanKi Park
National Internet Development Agency of Korea(NIDA)
3F. KTF B/D 1321-11
Seocho-dong
Seocho-gu
Seoul
Korea
Phone: +82-2-2186-4504
Email: ckp@nida.or.kr
URI: http://www.nida.or.kr
Lim, et al. Expires April 27, 2008 [Page 15]
Internet-Draft Softswitch ENUM Use April 2007
Lawrence Conroy
Roke Manor Research
Roke Manor
Old Salisbury Lane
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lconroy@insensate.co.uk
URI: http://www.sienum.co.uk
Lim, et al. Expires April 27, 2008 [Page 16]
Internet-Draft Softswitch ENUM Use April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lim, et al. Expires April 27, 2008 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:01 |