Drinks Working Group T. Creighton
Internet-Draft Comcast Cable Communications
Intended status: Informational J-F. Mule
Expires: January 15, 2009 CableLabs
July 14, 2008
Provisioning Protocol Requirements for ENUM-SIP Addressing Servers
draft-mule-peppermint-espp-requirements-01
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 15, 2009.
Creighton & Mule Expires January 15, 2009 [Page 1]
Internet-Draft espp-requirements July 2008
Abstract
This document presents use cases and protocol requirements for
provisioning ENUM-SIP addressing servers. The provisioned data is
used by the addressing server to return session establishment data
for SIP entities to route SIP requests to the target destinations.
An ENUM-SIP addressing server acts as a Lookup Function in session
peering to determine the target domain of a given SIP request. It
may also act as a Location Routing Function to develop the location
of the SIP signaling entity in the target domain.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations and Use Cases Examples . . . . . . . . . . . . . . 5
3.1. Separation of Responsibility . . . . . . . . . . . . . . . 5
3.2. File-based Distribution and Bootstrapping . . . . . . . . 7
3.3. Backward Compatibility to Legacy Switch Translations . . . 8
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 9
4.1. Connection-Oriented Operation . . . . . . . . . . . . . . 9
4.2. File Oriented Operation . . . . . . . . . . . . . . . . . 9
4.3. Security Requirements: Authentication, Integrity and
Confidentiality . . . . . . . . . . . . . . . . . . . . . 10
4.4. Data Model Requirements . . . . . . . . . . . . . . . . . 10
4.5. Data Presentation Requirements . . . . . . . . . . . . . . 11
4.6. Protocol Operations . . . . . . . . . . . . . . . . . . . 11
4.7. Versioning, Capability Exchange, and Extensibility
Requirements . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Creighton & Mule Expires January 15, 2009 [Page 2]
Internet-Draft espp-requirements July 2008
1. Introduction
This document presents a set of use cases and protocol requirements
for an ENUM-SIP addressing Server Provisioning Protocol (ESPP). An
ENUM-SIP addressing server is a session routing server which resolves
telephone numbers or any type of public user addresses into Uniform
Resource Identifiers (URIs) based on various rules and routing logic.
The data provisioned into an ENUM-SIP addressing server is queried by
SIP entities using ENUM [RFC3761] or Session Establishment Protocol
(SIP) [RFC3261]. It is intended to provide the necessary information
for a querying SIP entity to route a session request to the target
destination.
An ENUM-SIP addressing server is a host that acts as a Lookup
Function in session peering to determine the target domain of a given
SIP request. It may also act as a Location Routing Function to
develop the target domain into the location of the SIP signaling
entity servicing the target user.
In order to perform address resolution, the addressing server often
receives configuration data from various data sources. These data
sources may reside in a service provider or enterprise network
(intra-office or intra-company back-office systems), or in a peer's
network in the case of bilateral session peering agreements, or in a
session peering registry shared by a group of SIP Service Providers
(SSPs). These data sources advertise the public user identities they
serve (SIP user addresses, telephone numbers, and other types of
Uniform Resource Identifiers) along with other data elements like the
Signaling path Border Elements (SBEs) to use to reach those user
identities.
The ENUM-SIP addressing server Provisioning Protocol (ESPP) is an
example of provisioning protocol based on the requirements in this
document ([I-D.espp-protocol]). It can be viewed as a provisioning
protocol for the lookup and location routing functions defined in
session peering.
This document is organized as follows: Section 3 presents some
motivations and use cases, and Section 4 defines protocol
requirements for a provisioning protocol for the lookup and location
routing functions.
This document is provided as input for protocol requirement
discussion in the drinks working group.
Creighton & Mule Expires January 15, 2009 [Page 3]
Internet-Draft espp-requirements July 2008
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 [RFC2119].
This document also reuses the SIP terminology defined in [RFC3261].
The Lookup Function (LUF), Location Routing Functions (LRF) and other
session peering terms are defined [I-D.ietf-speermint-terminology].
Creighton & Mule Expires January 15, 2009 [Page 4]
Internet-Draft espp-requirements July 2008
3. Motivations and Use Cases Examples
The main motivation for defining an open provisioning protocol for
ENUM-SIP addressing servers is to allow multiple server vendors to
accept provisioning data from multiple data sources (some internal to
a SIP service provider, some controlled by one or more session peers)
using a common and flexible data model for the data elements that may
need to be provisioned.
The remaining of this section provides a couple of use cases.
3.1. Separation of Responsibility
A SIP Service Provider's business practices may impose a separation
of roles and responsibilities such that:
(a) network engineering and planning personnel are responsible for
establishing points-of-interconnect (at layer 3 for IP
internetworking and layer 5 for SBEs),
(b) for telephony services, telephony personnel are responsible for
provisioning telephone numbers, and telephone number prefixes,
(c) other personnel or back-office application systems are
responsible for provisioning other forms of resolvable user
addresses (e.g., email addresses, instant messaging addresses
via self-provisioned web applications, etc.).
The above separation of roles and responsibilities imply that
multiple data sources may concurrently add, modify or delete data
elements that often must be "combined" for an ENUM-SIP addressing
server to return session establishment data.
For example, two SIP service providers agree to exchange SIP traffic
by establishing a session peering relationship for voice services
first, and they decide to first exchange traffic for a sub-set of
their customer base; two destination groups, the New York-Manhattan
and New York-Queens groups are peered. Note that the destination
groups used in this example are geographical to facilitate the
understanding of destination groups but in many cases, peers will
establish peering relationships independent of any gepgraphical
considerations (user groups, im groups, etc.).
In unison, the network engineering personnel of each company
establish physical inter-connect in the New York City 60 Hudson
Street facility. Each SIP service provider commissions redundant
Signaling path Border Elements that are used to secure the
interconnect located at 60 Hudson Street. Then through the use of
the ESPP protocol, the network engineering departments publish IP and
Creighton & Mule Expires January 15, 2009 [Page 5]
Internet-Draft espp-requirements July 2008
SIP addressing information to each other's ENUM-SIP addressing
servers - provisioning NAPTRs for each Ingress SBE and through Route
objects associating them with the logical Destination Groups of each
metropolitan area.
Once the Destination Groups and Routes are established, the telephony
personnel manage the telephony addressing by adding telephone
numbers, routing numbers or prefixes to the respective Destination
Groups.
Some of the data (SBEs, Destination Groups, Routes and their
respective priorities) is usually provisioned once for each SIP
Service Provider with occasional subsequent updates as interconnect
points are added or changed. It is provisioned independently from
the provisioning of the elements contained in Destination Groups
(TNs, TN Ranges, LRNs, or public identities such as IM identifiers).
This allows the rare process of provisioning SBEs, destination
groups, etc. to be distinctly separate from the continuous process of
adding subscribers. This also applies to non-voice applications
where subscribers are added independently of the underlying Layer-5
entities that service those users.
Note that the exchange of this information may be done directly
between peers or via an entity representing a group of SIP service
providers. Today, in some VoIP networks, this information is often
exchanged in a static manner using email and spreadsheets.
Figure 1 illustrates how telephone numbers may be grouped logically
into destination groups (which may not necessarily be based on
geographical boundaries). It also shows how each destination group
may be reachable via a domain or a list of signaling path border
elements.
Creighton & Mule Expires January 15, 2009 [Page 6]
Internet-Draft espp-requirements July 2008
Destination Groups:
+------------------------------------+
|Destination Group| TN or TN Ranges |
+-----------------+------------------+
|Manhattan |212-203-0000 -> |
| |212-203-9999 | ,---.
|Bronx |347-876-1000 -> | / \
| |347-876-1999 | / \
|Queens |347-354-6000 -> | ( Bronx )
| |347-354-6999 | \ /
+------------------------------------+ ,-----. \ /
Routes: / \ `---'
+--------------------------------------+ / \
|Route Name|Nodes |Destination Group| ( Manhattan ) ,---.
+----------+---------+-----------------+ ,-. / / \
|118th Ave |NYC-SBE-1|Manhattan/Bronx |-->(SBE) / / \
|60 Hudson |NYC-SBE-2|Queens |-+ `-'-----' ( Queens )
+----------+--------++-----------------+ ,+. /
+------------>(SBE) /
Nodes: `-''---'
+-----------------------------------+
|Node Name| Host/Domain Name |
+---------+-------------------------+
|NYC-SBE-1|sbe-1.nyc-sp1.example.com|
|NYC-SBE-2|sbe-2.nyc-sp2.example.com|
+---------+-------------------------+
Figure 1: Protocol Data Elements
3.2. File-based Distribution and Bootstrapping
The process of downloading large quantities of data to an ENUM-SIP
addressing server should be carried out as quickly as possible with
minimum resources. It involves the generation and transfer of a bulk
file between the client and server. It may be used in cases where
the loading a newly commissioned ENUM-SIP addressing server or
reloading an existing server data due to a complete shutdown or loss
of memory has occurred.
For example, a SIP service provider has decided to opt into a
federation of service providers that collectively service over one
hundred million (100M) subscribers, choosing to establish session
peering with every member of the federation. Once commissioned, the
SIP service provider's addressing server needs to immediately receive
all 100M registered user addresses (SIP addresses, TNs, etc.).
Rather than stream the 100M TNs over a network connection in real-
time, the administrator of the federation registry and SIP service
Creighton & Mule Expires January 15, 2009 [Page 7]
Internet-Draft espp-requirements July 2008
provider choose to utilize the file-based distribution mechanism (as
described in [I-D.espp-protocol]).
3.3. Backward Compatibility to Legacy Switch Translations
The underlying data schema used to provision ENUM-SIP addressing
servers should be backward compatible with today's legacy VoIP server
translations and PSTN. This requirement arises from the fact that
some SIP service providers may wish to utilize the same number
translation data employed by their SIP servers handling subscribers.
For example, a SIP service provider's switch translation personnel,
who are responsible for managing SIP to telephone number address
translations, are given responsibility for managing the ENUM data.
Rather than provisioning complete numbers to a peer's addressing
server some may choose to provision telephone number prefixes or
routing numbers. For example, an enterprise's branch office may wish
to provision the first n number of digits it can serve. As another
example, in North America, some may not wish to provision the
complete 10-digit numbers but opt for the provisioning Routing
Numbers (RNs) as prefixes. This decision is, in large part, due to
the fact that, in some enterprise and SIP service provider networks
today, the trunk selection algorithm are based on prefix (e.g. NPA-
NXX in North America). The translation personnel choose to reuse
prefixes rather than taking responsibility for keeping a complete set
of the service provider's numbers up to date.
Creighton & Mule Expires January 15, 2009 [Page 8]
Internet-Draft espp-requirements July 2008
4. Protocol Requirements
This section describes the high-level requirements for the ENUM-SIP
server provisioning protocol.
4.1. Connection-Oriented Operation
o The protocol MUST support a file-based, bulk delivery mechanism
where the Client writes one or more update requests to one or
more files and the file(s) are delivered to and consumed by the
Server.
o The protocol MUST also support real-time, transaction-based
operations where the Client requests one operation over a
reliable transport and the ESPP server processes the request
upon receipt and then responds to the Client with an indication
of the transaction' status (success, warning or error).
o All Clients and Servers MUST use HTTP 1.1 as defined in
[RFC2616] for the transport mechanism of real-time operations.
o All Clients and Servers SHOULD support HTTP Keep-Alive to allow
long lived connections, where multiple request and response
pairs are exchanged across a single network connection.
4.2. File Oriented Operation
o The protocol MUST support a file-based mechanism (bulk load)
where the Client writes one or more requests to a file and the
file is delivered to and consumed by the Server.
o The delivery or transmission of bulk files MAY be triggered by a
manual process out-of-band of the protocol.
o During bulk loading the Server SHOULD NOT accept new records
through the real-time, connection-oriented interface.
o The maximum size of a bulk load file SHOULD NOT exceed 500 MB.
o The name of a bulk file SHOULD identify the Client, Server, file
sequence number, and transaction ID(s) for which the bulk file
was generated.
o The bulk load interface MUST be capable of supporting the
download of an entire address space of the order of the PSTN.
o The format of the bulk load file MUST be compatible with the XML
definitions of the real-time interface.
Creighton & Mule Expires January 15, 2009 [Page 9]
Internet-Draft espp-requirements July 2008
o The Server MUST maintain an error log that identifies
transactions that resulted in an error when being applied to the
database of the Server. The errors codes of the bulk load
interface SHOULD comply with the error codes of the real-time
interface.
4.3. Security Requirements: Authentication, Integrity and
Confidentiality
o All Clients and Servers MUST support Transport Layer Security
(TLS) as defined in [RFC4346] as the secure transport mechanism.
o All Clients and Servers MUST use HTTP Digest Authentication as
defined in [RFC2617] as the secure authentication mechanism.
o Transfer of bulk files MUST use Secure Copy (SCP), which relies
on Secure Shell (SSH) for security, as the secure file transport
mechanism.
4.4. Data Model Requirements
o The provisioning protocol MUST be capable of supporting the
following data elements as part of user addresses: any type of
user addresses or Uniform Resource Identifiers that can be used
to establish SIP sessions, and telephone number related elements
(TNs, TN prefixes, TN ranges, and Routing Numbers).
o The protocol data model MUST provide means to logically group
public user addresses into Destination Groups.
o The protocol data model MUST allow the data separation between
public user addresses (and their logical groupings) and the
domain or routes that can be used to reach those user addresses.
o The protocol data model MUST support the data elements required
for the SPEERMINT Lookup Function and allow the Location Routing
Function to dynamically determine the target's SIP server
outside the provisioning framework. This is the case of dynamic
SIP location determination based on a domain name of the SSP and
mechanisms like [RFC3263].
o The protocol data model MUST also allow the data elements
required for the Location Routing Function to be provisioned
within this provisioning framework.
o Because of the above requirement, the protocol MUST be capable
of supporting the following data elements as part of Routes
associated with Destination Groups: ingress and egress Signaling
Creighton & Mule Expires January 15, 2009 [Page 10]
Internet-Draft espp-requirements July 2008
path border elements (SBE FQDNs, SIP transport protocol and
ports), priority of routes, etc.
4.5. Data Presentation Requirements
o The protocol MUST utilize SOAP 1.1 [SOAP], WSDL 1.1 [WSDL], and
XML 1.0 [XML].
o The protocol MUST support efficient transportation of a large
number of data model objects from the client to the server.
4.6. Protocol Operations
o The protocol MUST support the ability to add, modify, and delete
the objects defined in the protocol data model.
o The protocol MUST support the ability to query for a specific
instance of each type of object defined in the data model by
using the object identifier.
o The protocol MUST support the ability for multiple Clients to
provision objects into the same Server.
o The protocol MUST support the ability for objects created by one
Client to refer to objects created by another Client.
4.7. Versioning, Capability Exchange, and Extensibility Requirements
o The protocol MUST support schema versioning such that major
version changes are defined as any change that breaks backward
compatibility and minor version changes are defined as any
change that does not break backward compatibility.
o The protocol MUST allow, but not require, a server to expose
multiple concurrent major versions and/or minor versions of the
protocol concurrently.
o The protocol MUST make the major version identification of a
request message detectable by schema validation and the minor
version identification of a request message detectable by the
application.
o The protocol MUST be extensible such that new operations and
objects can be added to the protocol in a systematic manner.
Creighton & Mule Expires January 15, 2009 [Page 11]
Internet-Draft espp-requirements July 2008
5. Security Considerations
Provisioning data and other configuration information in scope of
this ENUM-SIP Server Provisioning protocol include public identities,
telephone number ranges, signaling path border elements and NAPTRs.
This information is sensitive and its transmission in the clear and
without integrity checking leaves servers exposed to eavesdropping
attacks.
If the object values such as TNs, Routes, or Destination Groups are
set maliciously, it may result in sessions being misrouted or an
over-allocation of signaling resources in an attempt to create denial
of service attacks.
An initial set of security requirements for such a provisioning
protocol are defined in Section 4.3.
Creighton & Mule Expires January 15, 2009 [Page 12]
Internet-Draft espp-requirements July 2008
6. IANA Considerations
This document does not register any values in IANA registries.
Creighton & Mule Expires January 15, 2009 [Page 13]
Internet-Draft espp-requirements July 2008
7. Acknowledgments
This document is based on the work of participants in the CableLabs
PacketCable ENUM Server vendor focus team and initial feedback from
the Peppermint/Drinks working groups.
The authors wish to thank the following participants for their
contributions and efforts:
Jack Burton, Paul Natale, Costas Gavrilidis, Matt Cannon, Ken
Cartwright, Kevin Johns, James Brister, Ted Lemon, Vivian Neou, Mark
McBride, Tim Cody, Sean Leach, Gene Lew, Rich Shockey, Mark Teodoro,
Robby Benedyk, Steve Dimig, , Ajay Gupta, Sean Kent, Tom Kershaw,
Manjul Maharishi, Yasir Saleem, Sanjeev Chauhan, Gaurav Sharma, Vikas
Sarawat, Daryl Malas, Sumanth Channabasappa, Penn Pfautz, and Otmar
Lendl.
Creighton & Mule Expires January 15, 2009 [Page 14]
Internet-Draft espp-requirements July 2008
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.espp-protocol]
Cartwright, K., Dimig, S., Teodoro, M., and J-F. Mule,
"ENUM-SIP Server Provisioning Protocol (ESPP)",
draft-mule-peppermint-espp-protocol-02.txt (work in
progress), July 2008.
[I-D.ietf-speermint-terminology]
Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16 (work in progress),
February 2008.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 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.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[SOAP] W3C, "W3C Recommendation, SOAP Version 1.1", May 2000.
[WSDL] W3C, "W3C Recommendation, Web Services Description
Creighton & Mule Expires January 15, 2009 [Page 15]
Internet-Draft espp-requirements July 2008
Language (WSDL) Version 1.1", March 2001.
[XML] W3C, "W3C Recommendation, Extensible Markup Language (XML)
1.0", August 2006.
Creighton & Mule Expires January 15, 2009 [Page 16]
Internet-Draft espp-requirements July 2008
Authors' Addresses
Tom Creighton
Comcast Cable Communications
One Comcast Center
Philadelphia, PA 19103
USA
Email: tom_creighton@cable.comcast.com
Jean-Francois Mule
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: jfm@cablelabs.com
Creighton & Mule Expires January 15, 2009 [Page 17]
Internet-Draft espp-requirements 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.
Creighton & Mule Expires January 15, 2009 [Page 18]