[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
DRINKS WG                                                 Debbie Guyton
Internet Draft                                                Telcordia
Intended Status: Proposed Standard                        July 07, 2008
Expires: January 07, 2009



Key Data for a Registry Provisioning Interface
draft-guyton-drinks-registry-data-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 January 07, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

This document defines data that should be included in a provisioning
interface for a Registry. The provisioning interface may be used in
(near) real time, or periodically, from a service provider's service
provisioning system to establish and administer telephone number (TN)
and associated routing information in the Registry after necessary
validations. Based on 1) effective date/time specified for the data
and 2) validation of the TN assignee, these data will be used to
define selective routing views for various recipient service providers
which would be reflected in ENUM-SIP address servers. In addition,
the concept of multiple TNs sharing a common routing pattern simplifies
the definition and administration of routing data.

D. Guyton            Expires 01/07/09                      [Page  1]

Registry Provisioning Interface                            July 2008


Table of Contents

      1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
      2. Key Provisioning Interface Data and Associated Benefits. . 3
      3. Concept of Validation to Control the Distribution of Data. 6
      4. Summary of Benefits. . . . . . . . . . . . . . . . . . . . 6
      5. Formal API Definition. . . . . . . . . . . . . . . . . . . 7
      6. Security Considerations. . . . . . . . . . . . . . . . . . 7
      7. IANA Considerations. . . . . . . . . . . . . . . . . . . . 7
      8. Informative References . . . . . . . . . . . . . . . . . . 7
      9. Author's Addresses . . . . . . . . . . . . .. . . . . . .  7
      Full Copyright Statement  . . . . . . . . . . . . . . . . . . 8
      Intellectual Property Statement . . . . . . . . . . . . . . . 8
      Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8


1. Introduction

The intent of this contribution is to describe key data elements that
should be present in a provisioning interface to a Registry, including
some concepts that lead to additional benefits above and beyond the
basic TN and associated route information. These include the concept
of an effective date/time, the concept of a recipient group of defined
service providers so that selective routing is possible, and the
concept of a destination tag, or common routing pattern, associated
with a logical grouping of TNs.

This contribution is being provided to get agreement that these
concepts are beneficial to the Industry and to identify other parties
interested in contributing to the development of a provisioning Web
Services Description Language [WSDL]  for a Registry database defined
using these concepts.

This document is organized as follows:

o Section 2 describes some recommended key data for a Registry
  provisioning interface and the associated benefits these data
  provide.


o Section 3 discusses the use of validation and how it is used to
  control the distribution of data from the Registry to the ENUM-SIP
  address servers.


o Section 4 summarizes the benefits realized by the concepts discussed
  in this contribution.






D. Guyton            Expires 01/07/09                      [Page  2]
Registry Provisioning Interface                            July 2008


2. Key Provisioning Interface Data and Associated Benefits

2.1 Dial Code to Destination (DCD) Association Data

DCD data associates dial codes (primarily TNs, but could also be
shorter codes for larger code blocks) with a Destination Tag for
logical groupings of dial codes that share a common routing pattern
to a Destination or Entry Point in a host network.

The following is a list of data and definitions and associated benefits
for DCD data:

1. Country Code (CC) - necessary for filtering and validation support

2. Dial Code (DC) - this may be the national component of an E.164
number (e.g., 10 digit number for NANP (CC=1), TN length varies by CC),
or it may be leading digits or a prefix of the national number (e.g.,
NPA-NXX for NANP (CC=1) or National Destination Code (NDC) globally).

3. Dial Code Type (DC Type) - allows for filtering and validation
support, e.g.,

o DC Type = E for global e.164 TNs
o DC Type = C for NDC

4. Destination Tag (DT) - is the name of a common routing pattern (a
combination of destination URIs and Resource Records for various
services) with which the Dial Code is being associated.

5. Effective Date/Time (expressed as UTC/GMT) - provides a means of
establishing the dial code to destination mapping in the Registry in
advance, prior to being effective. This allows more than one service
provider to provision data pertaining to the same dial code (i.e.,
prior to the completion of a porting process). However, the record
for the current assignee of the Dial Code is the only one that can
be valid. See Validation discussion in Section 3.

This approach also allows support for network planning and
re-arrangements by changing routing patterns for selected Dial Codes
at specified effective date/times. In general, this concept provides
the capability to establish the relationship, modify it with a
specified effective date/time, or discontinue the relationship.

(Note that translating to various time zones for ease of loading or
viewing data should be straightforward.)

6. VoIP Origination Point - for example, can assume values of "Yes",
"No", or "Unknown". While other DCD data applies to terminating calls,
it would be useful to specify this originating data if known.



D. Guyton            Expires 01/07/09                      [Page  3]

Registry Provisioning Interface                            July 2008


For example, in some regulatory environments, different rate
structures and interconnection rules apply to PSTN-originated vs.
VoIP/IMS-originated calls, so this distinction is potentially
critical.

7. Assignee/Owner Identity - a service provider identity, or
equivalent identification, of the assignee of the dial code.

8. Administrator Identity - a service provider identity, or
equivalent identification, of the administrator (company) that is
administering and managing the data through the provisioning interface.
This may be a contracted entity, and may not necessarily be the same
as the assignee.

9. Network Provider type - although, in general, it is expected that
the carrier who is the assignee of the dial code would define the
DCD (the DC to Destination Tag relationship), this would allow the
use of multiple carriers (e.g., transit carriers) each to provide
a routing pattern and thus allow choice.

2.2 Host Entry Point data

The Host Entry Point (HEP) data associates the Destination Tag (DT)
with a pattern of associated host or gateway routing information,
expressed as full resource records (e.g., NAPTR), or as component
elements of resource records (e.g., RegExp/URI).  The data elements
of this pattern of routing information may be made available to all
participating service providers or only to a specified Recipient
Group (a collection of service providers to be given a common route).
See Section 3.3 for definition of a Recipient Group. This allows for
selective routing to various groups of service providers if needed,
or, for completeness, perhaps a default of "All" where every service
provider gets the same route.

The following is a list of data and definitions and associated
benefits for HEP data.

1. Destination Tag (DT) that identifies the common routing pattern

2. Recipient Group (RG) associated with this DT

3. Host Address - may be expressed as a full Resource Record (e.g.,
NAPTR) or as only the RegExp/URI

Note that for filtering, manipulating and validation, it is more
useful to provide the data elements making up a NAPTR.

4. Resource Record Type - specifying the type of resource record,
e.g., NAPTR, NS, DNAME, CNAME




D. Guyton            Expires 01/07/09                      [Page  4]
Registry Provisioning Interface                            July 2008


5. Scheme - specifying the scheme of interest, e.g., SIP, MAILTO,
TEL (for NAPTRs only)

6. Service - specifying the type of service being routed, e.g.,
E2U+SIP, E2U+SMS, E2U+MMS, E2U+EMAIL, E2U+PSTN (for NAPTRs only)

7. Preference - could be provided or defaulted (for NAPTRs only)

8. Order - could be provided or defaulted (for NAPTRs only)

9. Effective Date/Time (UTC/GMT) - allowing (in a similar manner
as discussed for DCD above) for establishing a record, modifying
a record, or discontinuing a record.

This would be beneficial to support network planning and
re-arrangements where network entry gateways change or traffic
(based on routing patterns or recipient groups) are partitioned
and directed to several gateways based on an effective date/time.

10. Owner Identity - identifies the service provider that defines
or "owns" this relationship of DT, Host Address, and RG

11. Administrator Identity - identifies the administrator (company)
that is providing the data through the Registry provisioning
interface and may not necessarily be the same as the owner.

2.3 Recipient Group and Recipient Group Members

Recipient Group (RG) data associates a number of Recipient Group
Members into an identified group of service providers that receive
the same routing information. A default group of "All" can be defined
when no selective routing is desired.  The data elements would include:

1. RG Member (RGM) - a service provider identity, or corporate
identity, of a service provider to be included in the group

2. RG - a name for the Recipient Group

3. Effective Date/Time - in this case a member is either in the
group or not so they become effective or are discontinued at a given
date/time

4. Owner Identity - identifies the service provider that defines or
"owns" this relationship of RGM and RG

5. Administrator Identity - identifies the administrator (company)
that is providing the data through the Registry provisioning interface
and may not necessarily be the same as the owner.





D. Guyton            Expires 01/07/09                      [Page  5]
Registry Provisioning Interface                            July 2008

2.4 General Notes on the Provisioning Interface Data

Some general notes about provisioning the data include the following:

1. The assignee/owner for the DCD, HEP, and RG must be identified as
the same assignee/owner service provider.

2. Although all of these data are needed to support routing, a
Registry provisioning interface approach may need to consider the fact
that the data may come from different sources in the organization.
DCD data may be provisioned as the output of a service provider's
service provisioning process, whereas, the HEP data may be provisioned
as the output of a service provider's network planning and management
process as it focuses on the common routing patterns, or Destination
Tags, and the entry points or gateways in the network.


3. Concept of Validation to Control the Distribution of Data

With the above framework for the DCD in Section 2.1, TN-to-assignee
validation can be performed in near-real-time as an effective
date/time is reached, or as a TN port becomes effective, in order to
validate the assignee of the TN before allowing the information to be
distributed from a Registry to address servers. Only valid records are
distributed or provisioned in each address server.

For example, more than one service provider can have the same TN
registered in the Registry with overlapping effective date/times.
This is likely and necessary for most timely handling in a number
porting process.  Only the one record that is valid will be distributed
to the address servers. If a record already exists in an address
server from the previous assignee, it would be deleted and the new
assignee's record added as validation shows a change of assignee - one
becomes invalid, the other becomes valid.

Thus, the recommended approach is to allow the validation
to control the distribution of data to address servers triggered by
the change in TN assignee in the Registry or triggered by a change
in effective date/time.

Similarly for a HEP record in Section 2.2, the distribution or change
in routing information through the use of the DT, Host Address, and
RG can be managed by an effective date/time to support network growth
and re-arrangement.

4. Summary of Benefits
Using effective date/time and an associated validation mechanism allows
the entry of multiple TN and associated routing information during the
porting process in order to distribute the new routing information upon





D. Guyton            Expires 01/07/09                      [Page  6]
Registry Provisioning Interface                            July 2008

port completion and validation of the new TN-to-assignee relationship.
In addition, effective date/time provides flexibility in pre-defining
data for network planning and re-arrangements. The validation process
controls the distribution by only letting valid records be distributed
to address servers. As changes occur, the validation mechanism
initiates the deletion of no-longer-valid records and distributes the
new valid records.

Using the concept of a Recipient Group allows the capability of
selective routing by providing different entry points to different
groups of service providers based on say, level of trust and firewall
considerations, or perhaps based on geographic routing needs.

Using the concept of a Destination Tag allows multiple TNs to share
a routing pattern and routing information can be based on the
Destination Tag itself and not the individual TN, thus simplifying
the definition and administration of routing data.

5. Formal API Definition
TBD in subsequent contribution. The definition will follow the
terminology followed in SPEERMINT [I-D.ietf-speermint-terminology].

6. Security Considerations
These will be defined when the provisioning WSDL is defined.

7. IANA Considerations
Should there be interest in working on a protocol for the Registry
provisioning interface in IETF, a formal IANA consideration section
should be drafted with proper registrations for the protocol
namespace(s), versions, etc.


8. Informative References


[WSDL]     W3C, "W3C Recommendation, Web Services Description
              Language (WSDL) Version 1.1", March 2001.


[I-D.ietf-speermint-terminology] Meyer, R. and D. Malas,
    "SPEERMINT Terminology", draft-ietf-speermint-terminology-16.
     txt(work in progress), February 2008.


9. Authors' Addresses

    Debbie Guyton, Ph.D.
    Telcordia Technologies
    1 Telcordia Drive/RRC 1E222
    Piscataway, NJ 08854

Email: dguyton@telcordia.com


D. Guyton            Expires 01/07/09                      [Page  7]

Registry Provisioning Interface                            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 Statement

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).




D. Guyton            Expires 01/07/09                      [Page  8]