ENUM Working Group J. Yu Internet Draft NeuStar Document: draft-ietf-enum-enumservice-sms-smpp-00.txt April 2008 Category: Standards Track IANA Registrations of Enumservice "sms:smpp" and "smpp" URI draft-ietf-enum-enumservice-sms-smpp-00.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 30, 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 scheme "smpp" according to the URI registration procedure in RFC 4395. This enumservice subtype indicates that the remote resource identified by the URI can receive short messages using the Short Message Peer-to-Peer Protocol (SMPP). Standards Track - Expires October 30, 2008 1 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" URI Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . 2 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 4 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 7 8.1 IANA Registration for Enumservice "sms:smpp" . . . . . . . 7 8.2 IANA Registration for "smpp" URI . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 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. 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 RR Resource Record 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 SRV Service SS7 Signaling System Number 7 URI Uniform Resource Identifier VPN Virtual Private Network Standards Track - Expires October 30, 2008 2 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" URI 3. 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 (RRs) 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 scheme "smpp" according to the URI registration procedure in RFC 4395 [8]. This enumservice subtype indicates that the remote resource identified by the URI 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 [10] connections. This document discusses only the TCP/IP case. Several radio access technologies are used by the mobile networks worldwide, the way the Global system for Mobile Communications (GSM) systems handle the short message delivery [11,12] 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. Standards Track - Expires October 30, 2008 3 IANA Registrations for Enumservice April 2008 "sms:smpp" and "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 5234 [13] for the "smpp" URI can be found in Section 8.2. 5. Use Cases There are at least five use 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 [14] or IP-SM- GW in [15,16,17]) 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 Standards Track - Expires October 30, 2008 4 IANA Registrations for Enumservice April 2008 "sms:smpp" and "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 terminating device supports the capabilities specified in [15,16,17]. 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 [14] or for delivering the messages over IP [15,16,17]. 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 Standards Track - Expires October 30, 2008 5 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" URI the short messages via SS7. [15,16,17] discuss and specify how short messages can be delivered to the terminating devices 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) [18], 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 to the terminating devices 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.example.net. NAPTR 10 100 "u" "E2U+sms:smpp" "!^.*!smpp:smsgw.mnoX.example.com!" . In this example, an "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 first query to see if any Service (SRV) RR [19] can be retrieved via DNS for _smpp._tcp.smsgw.mnoX.example.com. The querying node selects an SRV RR based on [19] if more than one SRV RRs are retrieved and uses the host name in the "Target" field of the SRV RR to retrieve the IP address via DNS. If no SRV RR can be found, it retrieves the IP address of "smsgw.mnoX.example.com" via DNS. It then establishes the SMPP session over TCP/IP, if not yet established, and sends the short message via SMPP to that IP address. If an SRV RR is retrieved and selected, the port number in the SRV RR is used for the TCP connection. Otherwise, the default port number of 2775 is used. Standards Track - Expires October 30, 2008 6 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" URI 7. Security Considerations Please see the discussions on security considerations for the registrations of 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- enum-enumservices-guide-07 [6]. This document also registers with the IANA the "smpp" URI scheme per RFC 4395 [8]. Details of the two registrations can be found in Sections 8.1 and 8.2 below. 8.1. IANA Registration for Enumservice "sms:smpp" Enumservice Name: "smpp" Enumservice Class: Common Application Enumservice Type: "sms" Enumservice subtype: "smpp" URI scheme: "smpp" Functional Specification: This Enumservice indicates that the resource identified by the associated URI 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 RRs 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 "hostport" appears in the URI. If the "userinfo" 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. Intended Usage: COMMON Standards Track - Expires October 30, 2008 7 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" URI 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. 8.2. IANA Registration 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:" [userinfo "@"] hostport *(";" uri-param) [headers] userinfo = user / telephone-subscriber uri-param = user-param / other-param user-param = "user=" ( "phone" / other-user ) "hostport", "headers", "user", "other-param" and "other-user" are imported from RFC 3261 [18]. "telephone-subscriber" is imported from RFC 3966 [20]. URI scheme semantics: "user=phone" must be present when "telephone- subscriber" appears in the "userinfo" part of the URI. The default TCP port number for SMPP is 2775. If a port number appears in the "hostport" part, that port number should be used. The initial purpose of defining the "smpp" URI scheme is to return the host information in the "smpp" URI in 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. Standards Track - Expires October 30, 2008 8 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" 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 [21]. Intended usage: The "smpp" URI identifies a remote resource that can receive short messages using the SMPP protocol. The "hostport" part of the URI can be used to locate the IP address of that remote resource. Please see Section 6 of this document for an example on how the host name in the "hostport" part of the URI is used to locate the IP address. 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 or associated with a telephone number can 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 "hostport" in the "smpp" URI identifies the remote resource that can receive short messages over SMPP/IP. It is recommended that only the "hostport" appears in the URI. If the "userinfo" 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. Standards Track - Expires October 30, 2008 9 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" URI 9. References 9.1. Normative References [1] S. Bradner, "Key Words for Use in RFCs 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. [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. [13] D. Crocker and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [18] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation Protocol", June 2002. [20] H. Schulzrinne, "The tel URI for Telephone Numbers", RFC 3966, December 2004. [21] T. Berners-Lee, et al., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005. 9.2. Informative References [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. [7] B. Hoeneisen, et al., "IANA Registration of Enumservices: Guide, Template and IANA Considerations", draft-ietf-enum- enumservices-guide-08, March 2008. [9] SMS Forum, "Short Message Peer-to-Peer Protocol (SMPP) Specification Version 5.0 ", February 19, 2003. [10] ITU-T Recommendation X.25, "Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) Standards Track - Expires October 30, 2008 10 IANA Registrations for Enumservice April 2008 "sms:smpp" and "smpp" URI for terminals operating in the packet mode and connected to public data networks by dedicated circuit", October 1996. [11] 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. [12] 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. [14] 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. [15] 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. [16] 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. [17] 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. [19] A. Gulbrandsen, et al., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 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 Standards Track - Expires October 30, 2008 11 IANA Registrations for Enumservice April 2008 "sms:smpp" and "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). Standards Track - Expires October 30, 2008 12
Datatracker
Report a datatracker bug
draft-ietf-enum-enumservice-sms-smpp-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| Replaces | draft-yu-enumservice-sms-smpp | ||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |