ENUM Working Group R. Shockey
Internet-Draft NeuStar
Intended status: Standards Track T. Creighton
Expires: January 8, 2009 Comcast Cable Communications
July 7, 2008
IANA Registration for an Enumservice Trunkgroup
draft-ietf-enum-trunkgroup-00
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 January 8, 2009.
Abstract
This document registers the Enumservice 'trunk' and subtypes 'sip'
and 'tel' using the URI schemes 'sip:' and 'tel:' as per the IANA
registration process defined in the ENUM specification RFC 3761
[RFC7761].
RFC 4904 [RFC4904] defines a technique for the conveyance of carrying
trunking information in SIP [RFC3261] and or TEL [RFC3966] URI's.
This Enumservice provides a mechanism for ENUM databases residing in
service provider networks a mechanism to query for that data.
Shockey & Creighton Expires January 8, 2009 [Page 1]
Internet-Draft Abbreviated Title July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Trunking Data . . . . . . . . . . . . . . . . . 4
4. Distribution of Trunkgroup Data . . . . . . . . . . . . . . . 4
5. Enumservice 'trunk' Response Examples . . . . . . . . . . . . 4
5.1. Trunk group in a global number, with a number prefix
trunk-context: . . . . . . . . . . . . . . . . . . . . . . 4
6. Implementation Considerations . . . . . . . . . . . . . . . . 5
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9.1. IANA Enumservice Registration for "trunk" . . . . . . . . 6
9.2. ENUM Service Registration for PSTN with Subtype "sip" . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Shockey & Creighton Expires January 8, 2009 [Page 2]
Internet-Draft Abbreviated Title July 2008
1. Introduction
ENUM (E.164 Number Mapping), RFC 3761 is a system that transforms
E.164 numbers (The International Public Telecommunication Number
Plan, ITU-T Recommendation E.164) [Recommendation E.164] into domain
names and then uses the Domain Name System (DNS), RFC 1034 [RFC1034]
and Naming Authority Pointer Records (NAPTR) records in the Dynamic
Delegation Discovery System (DDDS) RFC 3403 [RFC3403] to query the
services that are available for a specific domain name.
This document registers an Enumservice 'trunk' according to the
guidelines given in RFC 3761, to be used for provisioning a NAPTR
[RFC3403] resource record to indicate a type of connection associated
with an end point and/or telephone number. The registration is
defined within the DDDS (Dynamic Delegation Discovery System
[RFC3401][RFC3402][RFC3403][RFC3404][RFC3405]) hierarchy, for use
with the "E2U" DDDS Application defined in RFC 3761.
The service parameters defined in RFC 3761 dictate that a 'type' and
one or more 'subtype' should be specified. Within this set of
specifications the convention is assumed that the 'type' (being the
more generic term) defines the service and at least one of the
'subtype' may indicate the URI scheme.
In this document, one type is specified, 'trunk' and two subtypes
'sip' and 'tel' corresponding to the URI scheme specified.
RFC 4904 defines the general problem statement as to why sip/tel
URI's need to covey trunkgroup parameters.
This Enumservice solves the problem of how SIP proxies or other
intermediate session routing elements can query for and utilize
trunkgroup data.
The design of this Enumservice was influenced by several factors:
RFC 3761 has become the de facto query-response protocol of for a
variety of data types associated with E.164 numbering, addressing and
routing. RFC 3761 is already being used by service providers to
query for data that has significant privacy or security issues
associated with it. RFC 4769 [RFC4769], for instance, describes an
Enumservice that associates an E.164 number with a PSTN Local Routing
Number. This Enumservice extends that functionality to another form
of PSTN routing data.
Communications service providers are concerned with the impact of
call setup up times on the overall user experience. There is a
strong desire to maintain a single query-response mechanism for data
Shockey & Creighton Expires January 8, 2009 [Page 3]
Internet-Draft Abbreviated Title July 2008
involving E.164 phone numbers and not complicate call processing
applications with multiple protocol mechanisms. Were the query for
trunkgroup data to require a secondary protocol mechanism such as
LDAP or IRIS to retrieve the data, it could significantly impact call
setup times.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Definition of Trunking Data
Trunking data is defined in RFC 4904 as specific circuits in the PSTN
that represent a communications paths connecting two switching
systems that are used in the establishment of a end to end
connection.
4. Distribution of Trunkgroup Data
The distribution of trunkgroup data is generally restricted to
internal network operations. The NAPTR records described herein
SHOULD not be part of the e164.arpa DNS tree. Distribution of this
NAPTR data would be either within a service provider's internal
network, or on a private basis between one or more parties using a
variety of security mechanisms to prohibit general public access.
5. Enumservice 'trunk' Response Examples
This section documents several examples of how this protocol is used
for illustrative purposes only.
From examples given in RFC 4904:
5.1. Trunk group in a global number, with a number prefix trunk-
context:
tel:+16305550100;tgrp=TG-1;trunk-context=+1-630
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;trunk-context=+1-630@
isp.example.net;user=phone
Shockey & Creighton Expires January 8, 2009 [Page 4]
Internet-Draft Abbreviated Title July 2008
In an ENUM query-response mechanism this data would be presented as
follows.
$ORIGIN 0.0.1.0.5.5.5.0.3.6.1.enum4.network.net
NAPTR 10 100 "u" "E2U+trunk:tel"
"!^.*$!tel:+16305550100;tgrp=TG-1;trunk-context=+1-630!".
NAPTR 10 50 "u" "E2U+trunk:sip" "!^.*$!sip:+16305550100;tgrp=TG-
1;trunk-context=+1-630@isp.example.net;user=phone!".
6. Implementation Considerations
There may be one or more trunkgroups associated with a particular
E.164 number since there may be multiple terminations strategies
associated with an end-to-end connection. Since an ENUM query for
trunkgroup data may return multiple responses, it is important that
there be unambiguous information on which group to use or the order
to which sessions should be attempted.
Implementations of this Enumservice MUST be able to distinguish
between the order and preference fields in the NAPTR records. It is
recommended that implementers should fix the Order field to a single
value (such as 100) and use the preference field to rank order the
selections.
7. Privacy Considerations
It is assumed that carriers, service providers, or other
organizations that originate trunkgroup data will not publish such
information in a globally visible DNS tree, such as e164.arpa.
This data is strictly for internal service provider use only in
highly internally cached ENUM databases, which is only able to be
queried by trusted elements of their network, such as soft switches
and SIP proxy servers.
8. Security Considerations
The trunkgroup Enumservice defined in this document is assumed to be
used in an environment where elements are trusted and where attackers
are not supposed to have access to the protocol messages between
those elements. Traffic protection between network elements is
sometimes achieved by using IPSec and sometimes by physically
protecting the underlying network. In any case, it is presumed the
Shockey & Creighton Expires January 8, 2009 [Page 5]
Internet-Draft Abbreviated Title July 2008
environment where the enum trunkgroup request-response mechanism will
be used can ensure the integrity and accuracy of the data.
9. IANA Considerations
This document registers the 'trunk' Enumservice using the type
'trunk' and the subtypes 'sip' and 'tel' in the Enumservice registry
described in the IANA considerations in RFC 3761.
9.1. IANA Enumservice Registration for "trunk"
Enumservice Name: "trunk"
Enumservice Type: "trunk"
Enumservice Subtype: "tel"
URI Scheme: 'tel:'
Functional Specification:
This Enumservices indicate trunkgroup data, as defined in RFC 4904
necessary for a SIP proxy to make routing decisions.
Security Considerations: See Section 8.
Intended Usage: COMMON
Authors:
Richard Shockey (richard.shockey@neustar.biz)
Tom Creighton (tom_creighton@cable.comcast.com)
9.2. ENUM Service Registration for PSTN with Subtype "sip"
Enumservice Name: "pstn"
Enumservice Type: "pstn"
Enumservice Subtype: "sip"
URI Scheme: 'sip:'
Functional Specification:
These Enumservices indicate that the remote resource identified can
be addressed by the associated URI scheme in order to initiate a
Shockey & Creighton Expires January 8, 2009 [Page 6]
Internet-Draft Abbreviated Title July 2008
telecommunication session, which may include two-way voice or other
communications, to the PSTN.
Security Considerations: See Section 7.
Intended Usage: COMMON
Authors:
Richard Shockey (richard.shockey@neustar.biz)
Tom Creighton (tom_creighton@cable.comcast.com)
Interoperability considerations.
The URI is designed to be used specifically in conjunction with
systems that utilize private the RFC 3761 [ENUM] databases.
10. Acknowledgements
11. References
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC3261] 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.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
Shockey & Creighton Expires January 8, 2009 [Page 7]
Internet-Draft Abbreviated Title July 2008
RFC 3403, October 2002.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)",
RFC 3404, October 2002.
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Five: URI.ARPA Assignment Procedures", BCP 65,
RFC 3405, October 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network
(PSTN) Signaling Information", RFC 4769, November 2006.
[RFC4904] Gurbani, V. and C. Jennings, "Representing Trunk Groups in
tel/sip Uniform Resource Identifiers (URIs)", RFC 4904,
June 2007.
[Recommendation E.164]
ITU-T, "The International Public Telecommunication Number
Plan", May 1997.
11.2. Informative References
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Shockey & Creighton Expires January 8, 2009 [Page 8]
Internet-Draft Abbreviated Title July 2008
Authors' Addresses
Richard Shockey
NeuStar
46000 Center Oak Plaza
Sterling, VA 20166
USA
Phone: +1-571-434-5651
Email: richard.shockey@neustar.biz
Tom Creighton
Comcast Cable Communications
One Comcast Center
Philadelphia, PA 19103
USA
Phone: +1-215-286-8617
Email: tom_creighton@cable.comcast.com
Shockey & Creighton Expires January 8, 2009 [Page 9]
Internet-Draft Abbreviated Title July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Shockey & Creighton Expires January 8, 2009 [Page 10]