One document matched: draft-schwartz-peppermint-problem-statement-00.txt
Network Working Group D. Schwartz
Internet-Draft XConnect Global Networks
Intended status: Informational R. Mahy
Expires: August 15, 2008 Plantronics
A. Duric
Telio
E. Lewis
NeuStar
February 12, 2008
Consolidated Provisioning Problem Statement
draft-schwartz-peppermint-problem-statement-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 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes the type of data provisioned among Voice
Service Providers and underscores the need for clearly defined
structures and interfaces to facilitate this provisioning. This work
Schwartz, et al. Expires August 15, 2008 [Page 1]
Internet-Draft Consolidated-Prov-Prob February 2008
is in support of the service provider peering as defined by the
SPEERMINT WG.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Registry Data . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Index/Key Data . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Resolution Data . . . . . . . . . . . . . . . . . . . . . 5
4. Reachability vs. Routing . . . . . . . . . . . . . . . . . . . 6
5. Operations on the Registry Data . . . . . . . . . . . . . . . 6
6. Other Atrributes . . . . . . . . . . . . . . . . . . . . . . . 7
7. Data Encoding . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Data Management . . . . . . . . . . . . . . . . . . . . . . . 7
9. Data Propegation . . . . . . . . . . . . . . . . . . . . . . . 8
10. Querying The Registry . . . . . . . . . . . . . . . . . . . . 8
11. Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
12. Existing Technologies . . . . . . . . . . . . . . . . . . . . 8
13. Security Considerations . . . . . . . . . . . . . . . . . . . 9
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
16.1. Normative References . . . . . . . . . . . . . . . . . . . 10
16.2. Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Schwartz, et al. Expires August 15, 2008 [Page 2]
Internet-Draft Consolidated-Prov-Prob February 2008
1. Introduction
VoIP Service Providers (VSPs) engage in peering relationships with
other VSPs to create direct IP-to-IP interconnections. These
relationships provide network reach, greater technical capabilities
and enhanced economic benefit beyond that available with the Public
Switched Telephone Network (PSTN), while providing the security
benefit perceived to exist in the PSTN.
Because the business and operational management of hundreds or
thousands of direct peering relationships is difficult, VSPs often
enlist the help of peering exchanges to centralize (or assist
[I-D.ietf-speermint-terminology] with) the management of the
relationships. One of the central functions of these peering
exchanges is a registry of identifiers (often implemented as a
private ENUM tree) based on telephone numbers. This function is
called the peering or numbering registry. VSPs participating in the
peering exchange must provision their identifiers into the peering
registry to allow other VSPs with access to this registry to query
and obtain the correct resolution for a given number. Lack of clear
standards for this provisioning step has given rise to many
proprietary approaches that are rendering open provisioning
cumbersome and error prone.
VSP peering is not the only driver for this work, however. It is
quite common today for one VSP to receive number resolution data from
both authoritative or regulatory sources (e.g. a national telephone
number plan administrator) and commercial or private sources. Since
eventually all of the information resides locally, the VSP is
interested in merging resolution data across potentially different
local platforms so as to avoid multiple queries for each call. Today
this is virtually impossible to do in an efficient and standard
manner due to the proprietary nature of the individual registry
components.
In addition, many registry network architectures dictate sub
registries for overall resilience and performance. The transfer of
resolution data to the sub registries is not yet standardized and
results in unnecessary hardware/software component lock in.
This document attempts to describe the most common data that needs to
be exchanged in the cases highlighted above with the ultimate goal
being that of identifying the data structures and interfaces required
to support the data exchange scenarios specified above.
As a final note it is important to stress that while ENUM is not
mentioned explicitly in this document so as not to bias the outcome,
it is clear that in the minimum all the information present in a
Schwartz, et al. Expires August 15, 2008 [Page 3]
Internet-Draft Consolidated-Prov-Prob February 2008
NAPTR RR must be captured as the information therein has been well
thought out and deviating from this may curtail future growth.
Additionally, while E.164 numbering is not mentioned either for the
same reason, it is clear that in almost all cases the prefixes that
are being exchanged are in the e.164 format.
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].
Terms used or referred to elsewhere in the document (including in the
introduction):
DNS - Domain Name System [RFC1034]
RR - Resource Record [RFC1034]
TXT - DNS Text record [RFC1035]
NAPTR - Naming Authority Pointer record [RFC3403]
EPP - Extensible Provisioning Protocol [RFC3730]
ENUM - E.164 to URI DDDS [RFC3761]
URI - Uniform Resource Identifiers [RFC3986]
TLS - Transaction Layer Security [RFC4366]
3. Registry Data
Registry Data consists of both Index or Key data and Resolution data.
3.1. Index/Key Data
The organization of registry data is based on specific phone numbers
or phone number prefixes (which could represent blocks of phone
numbers, regions, or theoretically whole countries). For generality,
we will use the term prefix to include complete phone numbers as
well. Prefixes are the index or key used for all registry
manipulation and lookups. Even though some of the numbers
represented within these prefixes may not be globally reachable, the
prefix itself needs to be globally normalized before it can be
entered into a registry. These globally normalized prefixes always
Schwartz, et al. Expires August 15, 2008 [Page 4]
Internet-Draft Consolidated-Prov-Prob February 2008
begin with a plus (+) and a telephone country code. (Note that
prefixes in some countries can contain hexadecimal digits).
Since prefixes have variable lengths, a provisioning protocol must be
able to enter data for a sub-prefix or super-prefix of an existing
record. For example, it must be possible to enter records about
"+1202555" and "+12025551234" at the same time. For lookups
information about the most specific prefix will be returned. This
allows for some measure of aggregation. Also, in order to provide
maximal flexibility a provisioning protocol must provide a mechanism
for specifying both minimum and maximum number of digits in a prefix.
3.2. Resolution Data
For each prefix, there is a variety of data that can be exchanged.
The most important set of data identifies that a specific VSP is
responsible for the prefix and in most cases the VSP provides a SIP
URI through which this prefix can be reached.
In complex cases, several VSPs may claim some form of responsibility
for the same prefix. We can use the term "last hop" VSP to describe
the VSP closest to the end-user of a phone number. The provider who
was assigned a prefix by the national numbering authority is the
"first hop" VSP. The first hop VSP may have no way of knowing if the
last hop VSP will include itself in the registry. Therefore it is
important that the querier can obtain both records and use the most
specific one which contains reachability information.
In many cases, commercial registries also contain information used
for Local Number Portability. Even if a prefix is not reachable for
IP peering, it is useful to provide the "dipped" number and carrier
code. This information could be provided as a tel URI with the
number portability attributes defined in RFC 4769 [RFC4769].
Likewise it is very useful to know that a prefix is known not to
exist anywhere.
Like stated in the introduction it is imperative that the minimal set
of resolution data contain all the information required for a DNS
NAPTR RR.
Additionally, as a future proofing mechanism it is recommended that
resolution data include a catchall (similar to a DNS TXT RR) for data
that is not currently present in any ENUM service definitions.
One final note. One of the common "rewrite" rules for the URI in
NAPTR RRs for example is of the form "\1@somehost.company.example"
where the "\1" refers to the telephone number being processed. This
kind of shorthand should be available when processing prefixes in
Schwartz, et al. Expires August 15, 2008 [Page 5]
Internet-Draft Consolidated-Prov-Prob February 2008
bulk.
4. Reachability vs. Routing
The goal of the registry is to provide sufficient information to
identify a responsible VSP for a prefix. The responsible VSP can
provide a SIP URI that can be proxied or redirected as desired by the
VSP. It is important to note that the registry is expected to return
the same responsibility data for all parties that query it.
Routing information is also out of scope of the registry provisioning
problem. Once a responsible VSP is contacted, that VSP can use a
variety of techniques to route that request. For example, the VSP
could use TRIP [3], a private database, or a SIP location server.
Since this information is highly dynamic, it is inappropriate to
provision in a registry.
5. Operations on the Registry Data
WBelow is a list of logical operations on the registry data. Please
note that as stated above a provisioning protocol MUST apply these
operations equally to individual prefixes as well as prefix blocks.
Add: Add (responsible VSP) data about a new prefix to the registry.
Delete: Remove a prefix from the registry. Semantically it means
that the prefix no longer exists anywhere.
Port-out: A port-out is similar to a delete, but could be logged
differently. The semantics are that the prefix still exists, but
that the previous VSP is no longer responsible for it.
Port-In: A port-in is similar to an add, but the semantics are that
the prefix was previously assigned to a different provider.
Transfer: A transfer is a port-out and port-in operation performed
atomically. This operation insures that lookups do not fail for the
transferred prefix during the transfer.
Renumber: A renumber operation occurs when a specific prefix is
completely changed, but the data corresponding to the prefix has not
changed. This typically happens when a prefix is lengthened. For
example, when France moved from an 8-digit to a 10-digit dial plan,
the corresponding globally normalized prefix for a Parisian phone
number had a 1 inserted between the country code and the old prefix.
Renumbering could also accomplish prefix shortening (although this is
Schwartz, et al. Expires August 15, 2008 [Page 6]
Internet-Draft Consolidated-Prov-Prob February 2008
quite unlikely to occur) or prefix splitting (in the past United
States area codes where split when they were exhausted).
Modify: A modify operation occurs when some other attribute of a
prefix is modified (for example the target URI used for
reachability).
6. Other Atrributes
All the registry records will need to include some kind of validity
information. The provisioning protocol can indicate that a record is
not valid before one date and time and no longer valid after another
date and time.
In addition to responsibility data, we have identified the following
extra attributes as important or interesting:
Regardless of which protocol is used, issues that should be addressed
include:
Number type (unknown, IP, PSTN, both)
PSTN carrier code (for numbers with no IP reachability)
Fee category (free, landline, mobile, pay)
Media types supported (voice, video, message)
There MUST be a mechanism for an audit trail as issues of ownership
are bound to surface and a clearly defined mechanism for tracking
changes to registry data is essential.
7. Data Encoding
Since data may need to traverse administrative domain boundaries some
thought needs to be given to the rendering of the messages in
transmission. The encoding mechanism MUST be robust and easy to
design and troubleshoot with a strong bias towards an existing and
widely recognized standard.
8. Data Management
Due to the entrenchment of legacy software development processes
(e.g. SOAP/XML, WSDL, TLS) it is of utmost importance that whatever
emerges from this WG should be easy to implement with existing
Schwartz, et al. Expires August 15, 2008 [Page 7]
Internet-Draft Consolidated-Prov-Prob February 2008
methodologies.
9. Data Propegation
The transport layer is strictly point-to-point, with no caching or
forwarding.
10. Querying The Registry
The definition of the registry query mechanism is out of scope for
the PEPPERMINT activity. However, it is helpful to know what
mechanisms are in popular use to understand the necessary properties
for a provisioning interface. At present, there are two well-known
methods used by VSPs to query a peering registry. These are ENUM
[RFC3761] and SIP [RFC3261].
ENUM is simply a method of using DNS. It allows a VSP to query a
registry with a telephone number, an E.164 number in most cases, and
retrieve a list of URIs, each with a specific preference order.
When SIP is used for the query mechanism, the numbering registry
functions as a SIP redirect proxy [RFC3261] . The input to this
mechanism is a URI or more importantly the UserInfo part of the URI
containing the number to be queried. The response returned by the
proxy is either an error code indicating the absence of information
about the number queried or a redirect response (3XX) containing 1
(or more) Contact Headers representing available routing options.
11. Control
Since it may be possible to both push and pull data it is imperative
that a throttling mechanism exist to control the flow of data
exchange at all levels.
12. Existing Technologies
there has been some consideration to EPP extensions for ENUM
[RFC4114], and why it has not been adopted and why a requirements
document is now being produced to cover what would seemingly be
addressed by that solution.
There are two reasons for EPP not being adopted. One is that it
isn't compatible with legacy participants. The other reason is that
it requires more implementation work.
Schwartz, et al. Expires August 15, 2008 [Page 8]
Internet-Draft Consolidated-Prov-Prob February 2008
Legacy participants have an existing base of software development
built around SOAP/XML and WSDL, and are familiar with TLS.
Approaches to ENUM registry interfaces that use these tools will
blend more easily into the software products already in use to manage
telephone numbers.
The use of SOAP permits automatic generation of software to handle
the client side of the exchange. Domain name registries had to
provide software tool kits to give to registrars to match this
functionality. When a change is made to EPP, there will be a lot of
software exchanged.
From experience with both EPP and SOAP based approaches to registry
software, the SOAP based approach is much easier on the software
engineering process. The difference between the approaches is not
seen in a protocol analysis, but in an analysis of software
engineering.
13. Security Considerations
Security is to be implemented in the applications exchanging data,
the requirements here are meant to say that relevant security data
will be exchanged in the building of the transport. Specifically,
data integrity, authentication and secrecy. (Please note that all
three of these can be provided by using TLS, with the certificate
handshake being used by the application to complete the security
needs).
14. IANA Considerations
NA
15. Acknowledgements
Many of the points of information in this document are summarizations
of objectives and statements made by individuals on the PEPPERMINT
and SPEERMINT mailing lists. We would also like to acknowledge
Jeremy Barkan and Otmar Lendl for providing insightful inputs to the
original draft. Information on the PEPPERMINT mailing list can be
found at http://www.ietf.org/mailman/listinfo/peppermint.
16. References
Schwartz, et al. Expires August 15, 2008 [Page 9]
Internet-Draft Consolidated-Prov-Prob February 2008
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
16.2. Informational References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
RFC 3730, March 2004.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4114] Hollenbeck, S., "E.164 Number Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 4114, June 2005.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network
(PSTN) Signaling Information", RFC 4769, November 2006.
[I-D.ietf-speermint-terminology]
Malas, D. and D. Mayer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-15.txt, November 2007.
Schwartz, et al. Expires August 15, 2008 [Page 10]
Internet-Draft Consolidated-Prov-Prob February 2008
Authors' Addresses
David Schwartz
XConnect Global Networks
Malcha Technology Park
Building # 1
Jerusalem 90961
Israel
Phone: +972 52 347 4656
Email: dschwartz@xconnect.net
URI: www.kayote.com
Rohan Mahy
Plantronics
Email: rohan@ekabal.com
URI: www.plantronics.com
Alan Duric
Telio
Email: alan.duric@telio.no
URI: www.telio.no
Edward Lewis
NeuStar
46000 Center Oak Plaza
Building # 1
Sterling, VA 20166
USA
Phone: +1-571-434-5468
Email: ed.lewis@neustar.biz
URI: www.neustar.biz
Schwartz, et al. Expires August 15, 2008 [Page 11]
Internet-Draft Consolidated-Prov-Prob 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).
Schwartz, et al. Expires August 15, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 16:55:04 |