One document matched: draft-mule-peppermint-espp-requirements-00.txt
Network Working Group T. Creighton
Internet-Draft Comcast Cable Communications
Intended status: Informational J-F. Mule
Expires: August 21, 2008 CableLabs
February 18, 2008
Provisioning Protocol Requirements for ENUM-SIP Addressing Servers
draft-mule-peppermint-espp-requirements-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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Creighton & Mule Expires August 21, 2008 [Page 1]
Internet-Draft espp-requirements February 2008
Abstract
This document presents use cases and protocol requirements for
provisioning ENUM-SIP addressing servers. The provisioned data is
used by an addressing server to return part of the session
establishment data to SIP entities so that they can route SIP
sessions to the target destinations.
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 . . . 7
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 8
4.1. Connection-Oriented Operation . . . . . . . . . . . . . . 8
4.2. File Oriented Operation . . . . . . . . . . . . . . . . . 8
4.3. Security Requirements: Authentication, Integrity and
Confidentiality . . . . . . . . . . . . . . . . . . . . . 9
4.4. Data Model Requirements . . . . . . . . . . . . . . . . . 9
4.5. Data Presentation Requirements . . . . . . . . . . . . . . 9
4.6. Protocol Operations . . . . . . . . . . . . . . . . . . . 9
4.7. Versioning, Capability Exchange, and Extensibility
Requirements . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Creighton & Mule Expires August 21, 2008 [Page 2]
Internet-Draft espp-requirements February 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 routable
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 call
to the target destination.
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 (SBE) to use to reach those user
identities.
A provisioning protocol has been defined based on the requirements
summarized in this document ([CableLabs-ESPP]) and it is presented in
[I-D.espp-protocol]. A number of vendors have client and server
implementations of this protocol and two interoperability testing
events have been conducted to date.
This document is organized as follows: Section 3 presents some
motivations and use cases, and Section 4 defines protocol
requirements for ESPP.
The intent of the authors and participants in the CableLabs focus
team is to provide this document as input for discussion in the IETF.
Creighton & Mule Expires August 21, 2008 [Page 3]
Internet-Draft espp-requirements February 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]
and [I-D.ietf-speermint-terminology].
Creighton & Mule Expires August 21, 2008 [Page 4]
Internet-Draft espp-requirements February 2008
3. Motivations and Use Cases Examples
The main motivations for defining an open provisioning protocol for
ENUM-SIP addressing servers are 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), and to define 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) telephony personnel are responsible for provisioning telephone
numbers, location routing numbers (LRNs),
(c) other personnel or back-office systems are responsible for
provisioning other forms of resolvable addresses (email, instant
messaging, etc.).
For example, two SIP service providers that respectively service the
New York-Manhattan and New-York Queens metropolitan areas agree to
peer.
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
addressing information to each other's ENUM-SIP addressing servers -
provisioning NAPTRs for each Ingress SBE and through Route objects
associating them with the telephony address space (Service Area) of
each metropolitan area.
Once the Service Areas and Routes are established, the telephony
personnel manage the telephony addressing by adding telephone numbers
or LRNs to the respective Services Areas.
Some of the session establishment data (SBEs, Service Areas, Routes)
is usually provisioned once for each cable operator with occasional
subsequent updates as interconnect points are added or changed. It
is provisioned independently from the provisioning of the elements
contained in Service Areas (TNs, TN Ranges, LRNs, or public
Creighton & Mule Expires August 21, 2008 [Page 5]
Internet-Draft espp-requirements February 2008
identities such as IM identifiers). This allows the rare process of
provisioning SBEs, service areas, etc. to be distinctly separate from
the continuous process of adding subscribers.
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 service areas (which may not necessarily be based on
geographical boundaries). It also shows how each service area may be
reachable via signaling path border elements.
Service Areas:
+------------------------------------+
|Service Area Name| 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 |Service Areas | ( 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
Creighton & Mule Expires August 21, 2008 [Page 6]
Internet-Draft espp-requirements February 2008
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
interconnections with every member of the federation. Once
commissioned the operator's ENUM-SIP addressing server needs to
immediately receive with all 100M registered telephone numbers (TNs).
Rather than stream the 100M TNs over a network connection in real-
time, the administrator of the federation registry and operator
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 VoIP server
translations and legacy 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 or Call Management
Servers (CMS).
For example, a SIP service provider's switch translation personnel,
who are responsible for managing CMS translations, are given
responsibility for managing the operator's ENUM data. Rather than
provisioning complete 10-digit numbers to a peer's ENUM server some
may choose to provision Location Routing Numbers (LRNs). This
decision is, in large part, due to the fact that, in some networks,
the trunk selection algorithm of the operator's CMS are based on LRNs
(NPA-NXX). The switch translation personnel choose to reuse LRNs
rather than taking responsibility for keeping a complete set of the
operator's numbers up to date.
Creighton & Mule Expires August 21, 2008 [Page 7]
Internet-Draft espp-requirements February 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 ESPP Client writes one or more update requests to one
or more files and the file(s) are delivered to and consumed by
the ESPP Server.
o All ESPP Clients and Servers MUST use HTTP 1.1 as defined in
[RFC2616] for the transport mechanism.
o All ESPP 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 ESPP Client writes one or more requests to a file and
the file is delivered to and consumed by the ESPP 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 ESPP Server SHOULD NOT accept new
records through the real-time, connection-oriented interface.
o The maximum size of a bulk load file MUST NOT exceed 500 MB.
o The name of a bulk file SHOULD identify the ESPP Client, ESPP
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.
o The ESPP Server MUST maintain an error log that identifies
transactions that resulted in an error when being applied to the
database of the ESPP Server. The errors codes of the bulk load
interface SHOULD comply with the error codes of the real-time
interface.
Creighton & Mule Expires August 21, 2008 [Page 8]
Internet-Draft espp-requirements February 2008
4.3. Security Requirements: Authentication, Integrity and
Confidentiality
o All ESPP Clients and Servers MUST support Transport Layer
Security (TLS) as defined in [RFC4346] as the secure transport
mechanism.
o All ESPP 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 protocol MUST be capable of supporting a large addressing
space. For example, if the provisioned data involves telephone
numbers, the protocol must be capable of supporting an
addressing space of the same magnitude as the PSTN.
o The protocol's data model SHOULD provide means to logically
group public identities into Service Areas and associate Routes
to Service Areas.
4.5. Data Presentation Requirements
o The protocol MUST utilize SOAP 1.1 [SOAP], WSDL1.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 ESPP Clients
to provision objects into the same ESPP Server.
o The protocol MUST support the ability for ESPP objects created
by one ESPP Client to refer to ESPP objects created by another
ESPP Client.
Creighton & Mule Expires August 21, 2008 [Page 9]
Internet-Draft espp-requirements February 2008
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 August 21, 2008 [Page 10]
Internet-Draft espp-requirements February 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 Service Areas 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 August 21, 2008 [Page 11]
Internet-Draft espp-requirements February 2008
6. Acknowledgments
This document is based on the work of participants in the CableLabs
PacketCable ENUM Server vendor focus team.
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 and Sumanth Channabasappa.
Creighton & Mule Expires August 21, 2008 [Page 12]
Internet-Draft espp-requirements February 2008
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[CableLabs-ESPP]
CableLabs, "PacketCable ENUM Server Provisioning
Specification, PKT-SP-ENUM-PROV-I01-080215",
February 2008.
[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-00.txt (work in
progress), February 2008.
[I-D.ietf-speermint-terminology]
Meyer, R. and D. Malas, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16.txt (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.
[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.
Creighton & Mule Expires August 21, 2008 [Page 13]
Internet-Draft espp-requirements February 2008
[WSDL] W3C, "W3C Recommendation, Web Services Description
Language (WSDL) Version 1.1", March 2001.
[XML] W3C, "W3C Recommendation, Extensible Markup Language (XML)
1.0", August 2006.
Creighton & Mule Expires August 21, 2008 [Page 14]
Internet-Draft espp-requirements February 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 August 21, 2008 [Page 15]
Internet-Draft espp-requirements February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Creighton & Mule Expires August 21, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 08:56:07 |