One document matched: draft-yu-enumservice-sms-smpp-01.txt
Differences from draft-yu-enumservice-sms-smpp-00.txt
ENUM Working Group J. Yu
Internet Draft NeuStar
Document: draft-yu-enumservice-sms-smpp-01.txt April 2008
Category: Standards Track
RFC 4355 Update for Enumservice "sms:smpp"
and IANA Registration for "smpp:" URI
draft-yu-enumservice-sms-smpp-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 October 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document updates RFC 4355 by registering a new enumservice
subtype "smpp" under the existing type "sms" using the URI scheme
"smpp" as per the IANA registration process defined in RFC 3761 and
draft-ietf-enum-enumservices-guide-07 and registers a new URI type
"smpp" according to the URI registration procedure in RFC 4395.
This enumservice subtype indicates that the remote resource
identified by the URI scheme can receive short messages using the
Short Message Peer-to-Peer Protocol (SMPP).
Yu Standards Track - Expires October 14, 2008 1
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 4
5. Use of "smpp:" URI . . . . . . . . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 6
8.1 IANA Enumservice Registration for "smpp" . . . . . . . . . 7
8.2 IANA Registration Information for "smpp:" URI . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1 Normative References . . . . . . . . . . . . . . . . . . . 9
9.2 Informative References . . . . . . . . . . . . . . . . . . 10
10. Change History . . . . . . . . . . . . . . . . . . . . . . 11
10.1 Changes from Version 00 . . . . . . . . . . . . . . . . . 11
1. Conventions Used in this Document
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 BCP 14, RFC 2119 [1].
2. Introduction
ENUM (E.164 Number Mapping) [2] is a system that transforms
E.164 [3] telephone numbers into domain names and then uses
the Domain Name System (DNS) [4] and Naming Authority Pointer
(NAPTR) [5] resource records to query for the services or
resources that are available for a specific domain name.
This document updates RFC 4355 [6] by registering a new enumservice
subtype "smpp" under the existing type "sms" using the URI scheme
"smpp" as per the IANA registration process defined in RFC 3761 [2]
and draft-ietf-enum-enumservices-guide-07 [7] and registers a new
URI type "smpp" according to the URI registration procedure in RFC
4395 [8].
This enumservice subtype indicates that the remote resource
identified by the URI scheme can receive short messages using the
Short Message Peer-to-Peer Protocol (SMPP) [9].
The purpose of the registered enumservice subtype and URI
scheme is to enable service providers to exchange the short
message traffic over IP using the widely supported SMPP.
SMPP sessions can be established over TCP/IP or X.25 connections.
This document discusses only the TCP/IP case. Several radio access
Yu Standards Track - Expires October 14, 2008 2
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
technologies are used by the mobile networks worldwide, the way the
Global system for Mobile Communications (GSM) systems handle the
short message delivery [10,11] is used in this document to simplify
the discussions.
For a mobile-originated short message, the Mobile-services
Switching Center (MSC) or Serving GPRS Support Node (SGSN) that
serves the sender submits the short message to the Service Center
(SC) in the sender's home network via the Interworking MSC for
Short Message Service (SMS-IWMSC). A successful short message
delivery to a mobile user involves the SC and Gateway MSC for Short
Message Service (SMS-GMSC) in the sender's home network that
queries the Home Location Register (HLR) in the receiver's home
network via Signaling System Number 7 (SS7) to retrieve information
about the MSC and/or SGSN that currently serve(s) the receiver
followed by the short message delivery to the MSC or SGSN via SS7.
This document uses the Short Message Service Center (SMSC) to avoid
mentioning the SMS-GMSC, SMS-IWMSC and SC to simplify the
discussions.
3. Abbreviations
3GPP 3rd Generation Partnership Project
BNF Backus-Naur Form
DNS Domain Name System
GPRS General Packet Radio Service
GSM Global System for Mobile communications
GW Gateway
HLR Home Location Register
ID Identifier; Identity
IM Immediate Messaging; Instant Messaging
ITU-T International Telecommunication Union-Telecommunication
MNP Mobile Number Portability
MSC Mobile-services Switching Center
NAPTR Naming Authority Pointer
SC Service Center
SGSN Serving GPRS Support Node
SMPP Short Message Peer-to-Peer Protocol
SMS Short Message Service
SMS-GMSC Gateway MSC for SMS
SMS-IWMSC Interworking MSC for SMS
SMSC Short Message Service Center
SS7 Signaling System Number 7
URI Uniform Resource Identifier
VPN Virtual Private Network
Yu Standards Track - Expires October 14, 2008 3
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
4. Formal Syntax
RFC 4355 [6] allows subtypes be defined under the type "sms". This
document proposes a new subtype "smpp" so the enumservice value is
"sms:smpp".
The syntax specification using the augmented Backus-Naur Form (BNF)
as described in RFC 2234 [12] for the "smpp:" URI can be found in
Section 8.2.
5. Use of "smpp:" URI
There are at least five cases where some network entities in the
mobile networks that deal with short message submission or delivery
may want to retrieve the "smpp:" URI via ENUM queries so as to
deliver the short messages via SMPP/IP instead of SS7.
a. An SMS hub provider that receives a short message from the
originating network can send an ENUM query to retrieve the
"smpp:" URI for the destination mobile telephone number. If
the destination mobile telephone number is served by a mobile
operator (identified by the information in the host part of the
URI) that uses this SMS hub provider's service, the SMS hub
provider can use the information in the "smpp:" URI to terminate
the short message via SMPP/IP. If the destination mobile
telephone number is served by a mobile operator that does not
use this SMS hub provider's service, the SMS hub provider simply
forwards the short message to the SMS hub provider that can
reach the destination mobile operator.
b. The SMSC in the sender's home network that receives a short
message from the sender can send an ENUM query to see if the
home operator that serves the destination mobile telephone
number has an SMS Gateway (GW) (e.g., SMS Router [13] or IP-SM-
GW in [14,15,16]) that can receive all the mobile-terminated
short messages via SMPP/IP. If the "smpp:" URI is found and
SMPP sessions with the remote resource are allowed, the short
message is delivered to the SMS Gateway via SMPP/IP. Otherwise,
the SMSC handles the short message as is done today except that
it may send the ENUM query as is described in case #c after it
receives the positive response from the HLR.
c. The SMSC in the sender's home network that has queried the HLR
associated with the destination mobile telephone number and
received the E.164 number associated with the MSC and/or SGSN
that currently serve(s) the destination mobile telephone number
can send an ENUM query to see if the MSC or SGSN can receive the
Yu Standards Track - Expires October 14, 2008 4
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
short messages via SMPP/IP. If the "smpp:" URI is found and
SMPP sessions with the remote resource are allowed, the short
message is delivered via SMPP/IP. Otherwise, the short message
is delivered via SS7.
d. The SMS GW mentioned in case #b above that receives an incoming
short message via SS7 or IP and wants to send the short message
to the MSC or SGSN that currently serves the destination mobile
telephone number can send an ENUM query to see if that MSC or
SGSN can receive the short messages via SMPP/IP. If the "smpp:"
URI is found and SMPP sessions with the remote resource are
allowed, the short message is delivered via SMPP/IP. Otherwise,
the short message is delivered via SS7. Certainly, the SMS GW
can deliver the message via IP if the destination device
supports the capabilities specified in [14,15,16].
e. The MSC or SGSN serving the sender can use the E.164 number
associated with the sender's home SMSC to send an ENUM query to
see if that SMSC can receive short messages via SMPP/IP. If the
"smpp:" URI is found and SMPP sessions with the remote resource
are allowed, the short message is delivered via SMPP/IP.
Otherwise, the short message is delivered via SS7.
ENUM queries may not be needed for countries that do not support
mobile number portability (MNP) because the prefix of the
destination mobile telephone number or the E.164 numbers associated
with the MSC, SGSN and SMSC and locally provisioned data may be
sufficient to identify the remote entity/resource and whether the
remote entity/resource supports SMPP/IP. When the destination
mobile telephone number is subject to MNP and ENUM provides MNP-
corrected responses, the querier can use ENUM query to see if the
response contains the "smpp:" URI.
For the five cases above, case #a is the most likely case to happen
because the SMS hub providers currently use SMPP to communicate
with the originating SMSC, with each other, and/or with the
destination SMS GW. But they currently use local or remote
databases and/or other operator-specific information to identify
the destination operator and the destination SMS GW.
More and more operators may deploy the SMS GWs to receive all
incoming mobile-terminated short messages for reasons stated in
[13] or for delivering the message over IP [14,15,16]. When that
happens, more SMSCs may send ENUM queries to see if they can
retrieve the "smpp:" URI in the ENUM responses so as to deliver the
short messages via SMPP/IP without querying the HLR and delivering
Yu Standards Track - Expires October 14, 2008 5
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
the short messages via SS7. [14,15,16] discuss and specify how
short messages can be delivered to the terminating device over IP
when the terminating devices support SMS over IP or Immediate
Messaging (IM) after the SMS GW (e.g., IP-SM-GW) receives the short
messages from the SMSCs over SS7. Since the SMSCs are more likely
to support SMPP rather than Session Initiation Protocol (SIP) [17],
the SMS GW can advertise its ability to receive short messages over
SMPP/IP via ENUM. Using SIP to receive the short messages from the
SMSCs at the SMS GW that can deliver the messages via SIP is
outside the scope of this document.
Cases #c, #d and #e may happen when many MSCs and SGSNs support
SMPP/IP.
An SMPP message is acknowledged immediately when received;
therefore, the SMPP mechanism that requests for notification on
actual message delivery should be used so as not to impact the
message delivery status reporting mechanism that is available when
the short message is delivered via SS7.
6. Example
$ORIGIN 4.3.2.1.4.3.4.1.7.5.1.e164enum.net.
NAPTR 10 100 "u" "E2U+sms:smpp"
"!^.*!smpp:smsgw1.mnoX.3gppnetwork.org!" .
In this example, a "smpp:" URI is returned in the ENUM response.
The querying node, if supporting SMPP and having established
business relationship and prior exchange of security information
(e.g., system ID and password for SMPP session setup) for sending
the short messages via SMPP with the remote domain, can retrieve the
IP address for "smsgw1.mnoX.3gppnetwork.org" via DNS, establish the
SMPP session over TCP/IP if not yet established, and send the short
message via SMPP to that IP address.
7. Security Considerations
Please see the discussions on security considerations for the
Enumservice "sms:smpp" and "smpp:" URI in Sections 8.1 and 8.2
respectively.
8. IANA Considerations
This document registers the "smpp" Enumservice using the subtype
"smpp" under the existing type "sms" in the Enumservice registry
described in the IANA considerations in RFC 3761 [2] and draft-ietf-
Yu Standards Track - Expires October 14, 2008 6
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
enum-enumservices-guide-07 [6]. This document also registers with
the IANA the "smpp:" URI per RFC 4395 [8]. Details of the two
registrations can be found in the Sections 8.1 and 8.2 below.
8.1. IANA Enumservice Registration for "smpp"
Enumservice Name: "smpp"
Enumservice Class: Application
Enumservice Type: "sms"
Enumservice subtype: "smpp"
URI scheme: "smpp:"
Functional Specification: This Enumservice indicates that the
resource identified by the associated URI scheme is capable of
receiving a short message using the SMPP protocol [9].
Security Considerations: Use of the "sms:smpp" Enumservice shall
either be within a service provider's internal network, or on a
private basis between one or more parties. It is assumed that
this Enumservice value defined in this document is used in an
environment where entities are trusted and general public or
attackers are not supposed to have access to the DNS resource
records containing the "smpp:" URI.
The initial purpose of this Enumservice value and the "smpp:" URI
is to indicate that the remote resource can receive short messages
using SMPP, it is recommended that only the "hostpart" appears in
the URI. If the "user" part is present, it is recommended that it
contains the international telephone number with the leading "+"
so as not to convey user-specific information in the "smpp:" URI.
The entity that has the authoritative answer to an ENUM query may
execute the access control based on the source IP address of the
ENUM query and return an appropriate error code (e.g., "refused")
if the querier is not authorized to establish an SMPP session with
the remote resource.
Intended Usage: COMMON
Registration Document: This document contains all the information
needed for the registration of this enumservice subtype value.
Author: James Yu (see Author's Address Section for author contact
detail)
Further Information: See Section 5 of this document.
Yu Standards Track - Expires October 14, 2008 7
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
8.2. IANA Registration Information for "smpp:" URI
URI scheme name: The name of the URI is "smpp:".
Status: The intended status is Permanent.
SMPP is used by network entities operated by the
carriers/operators, inter-carrier vendors and the service
providers. Use of this URI should be either be within a service
provider's or carrier's/operator's internal network, or on a
private basis between one or more parties using a variety of
security mechanisms to prevent the general public access. The
records described herein should not be part of the e164.arpa or
any other portion of the Internet DNS tree when returned in the
ENUM response.
URI scheme syntax:
smpp-uri = "smpp:" [user "@" ] hostpart *(";" parameter)
[headers]
user = userid / telephone-subscriber
userid = *urlchar
parameter = attribute ["=" value]
"hostpart" and "headers" are imported from RFC 3261 [17],
"telephone-subscriber" is imported from RFC 3966 [18], "urlchar"
is imported from RFC 3986 [19], and "attribute" and "value" are
imported from RFC 2045 [20].
URI scheme semantics: The initial purpose of defining the "smpp:"
URI is to return the host information in the "smpp:" URI of the
ENUM response to identify the remote resource that can receive
short messages via SMPP/IP. This URI is not intended to be used
in other protocols (e.g., SIP Request-URI) for addressing and
routing purposes, at least for the purpose of this document. The
URI scheme syntax provides the extension mechanism to add
parameters and headers in the future for other uses of this URI.
Encoding considerations: US-ASCII characters are included in the URI
without any conversion. Non-US-ASCII characters MUST be percent-
encoded as described in Section 2.1 of RFC 3986 [19].
Intended usage: The "smpp:" URI identifies an entity that can
receive short messages using the SMPP protocol. The "host" part
of the URI can be used to locate the IP address of that entity.
Applications and/or protocols which may use this URL scheme name:
The "smpp:" URI is intended to be used by entities that
communicate with each other using the SMPP protocol. An entity
that has a short message to deliver and wants to find out if the
remote entity that deals with the destination telephone number can
Yu Standards Track - Expires October 14, 2008 8
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
make an ENUM query to see if such a URI is returned in the ENUM
response.
Interoperability considerations: The URI is designed to be used
specifically for nodes in the trusted systems that query private
ENUM implementations (e.g., Carrier ENUM).
Security considerations: The initial use of the "smpp:" URI is for
Enumservice "sms:smpp" where the "hostpart" in the "smpp:" URI
identifies the remote resource that can receive short messages
over SMPP/IP. It is recommended that only the "hostpart" appears
in the URI. If the "user" part is present, it is recommended that
it contains the international telephone number with the leading
"+" so as not to convey user-specific information in the "smpp:"
URI.
Frame Relay and Virtual Private Network (VPN) connections are
usually used to establish the SMPP sessions and each SMPP session
is authorized by verifying the System ID and password at the
session setup time. Those security related measures should be
used.
Person and email address to contact for further information: See the
Author's Address Section of this document for author's contact
information.
Author/change controller: This scheme is registered under the IETF
tree. As such, the IETF maintains change control.
References: See Sections 5 and 8.1 of this document and [9] and [10]
in Section 9 of this document.
9. References
9.1. Normative References
[1] S. Bradner, "Key Words for Use in RFC's to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] P. Faltstrom and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[3] ITU-T, "The International Public Telecommunication Numbering
Plan", Recommendation E.164, May 1997.
[4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC
1034, November 1987.
Yu Standards Track - Expires October 14, 2008 9
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
[5] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002.
[6] R. Brandner, et al., "IANA Registration for Enumservices email,
fax, mms, ems, and sms", RFC 4355, January 2006.
[8] T. Hansen, et al., "Guidelines and Registration Procedures for
New URI Schemes", RFC 4395, February 2006.
[9] SMS Forum, "Short Message Peer-to-Peer Protocol (SMPP)
Specification Version 5.0 ", February 19, 2003.
[12] D. Crocker and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[17] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation
Protocol", June 2002.
[18] H. Schulzrinne, "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[19] T. Berners-Lee, et al., "Uniform Resource Identifiers (URI):
Generic Syntax", RFC 3986, January 2005.
[20] N. Freed and N.S. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
9.2. Informative References
[7] B. Hoeneisen, et al., "IANA Registration of Enumservices:
Guide, Template and IANA Considerations", draft-ietf-enum-
enumservices-guide-08, March 2008.
[10] 3GPP TS 23.040 v7.0.1, "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Technical realization of the Short Message Service (SMS)
(Release 7)", March 2007.
[11] 3GPP TS 29.002 v7.9.0, "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Mobile Application Part (MAP specification; (Release 7)",
September 2007.
[13] 3GPP TS 23.840 v7.1.0, "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals; Study
into routeing of MT-SMs via the HPLMN; (Release 7)", March
2007.
Yu Standards Track - Expires October 14, 2008 10
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
[14] 3GPP TS 24.341 v7.2.0, "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Support of SMS over IP networks; Stage 3 (Release 7)", December
2007.
[15] 3GPP TR 23.811 v8.0.0, "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Service Level Interworking for Messaging Services; Stage 2
(Release 8)", March 2008.
[16] 3GPP TS 23.204 v7.5.0, "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
Support of Short Message Service (SMS) over generic 3GPP
Internet Protocol (IP) access; Stage 2 (Release 7)", March
2008.
10. Change History (to be removed)
10.1 Changes from Version 00
- Change the title to reflect that this I-D updates RFC 4355.
- Make the title shorter.
- Add RFC 4355 in the Normative References section.
- Add "TS 23.204 v7.5.0" in the Informative References section.
- Change "TS 23.811 v1.2.1" to "TR 23.811 v8.0.0".
- Use "SMS Forum's SMPP v5.0" for referencing SMPP.
- Make a better separation between Enumservice registration and URI
registration.
- Clarify that the SMS GW (e.g., IP-SM-GW) that can deliver messages
to the terminating device via SIP/IP still receives the short
messages from the SMSCs via SS7 so an operator can make an
implementation decision to have the SMS GW receive incoming SMS
traffic from the SMSCs via SMPP/IP instead of SS7.
Author's Address
James Yu
NeuStar, Inc.
46000 Center Oak Plaza
Sterling, VA 20166
U.S.A.
Phone: +1-571-434-5572
Email: james.yu@neustar.biz
Yu Standards Track - Expires October 14, 2008 11
RFC 4355 Update for Enumservice "sms:smpp" April 2008
and IANA Registration for "smpp:" URI
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Yu Standards Track - Expires October 14, 2008 12 | PAFTECH AB 2003-2026 | 2026-04-23 08:39:26 |