[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
PEPPERMINT                                                     A. Newton
Internet-Draft                                                 SunRocket
Intended status: Informational                          January 27, 2007
Expires: July 31, 2007


      Provisioning Extensions in Peering Registries for Multimedia
             Interconnection (PEPPERMINT) Problem Statement
            draft-newton-peppermint-problem-statement-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 July 31, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Newton                    Expires July 31, 2007                 [Page 1]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


Abstract

   This document contains descriptions of the problems faced by
   operators and participants of multimedia interconnection (i.e.  SIP)
   peering registries with respect to identity provisioning.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Querying the Registry  . . . . . . . . . . . . . . . . . . . .  4
   3.  Registry Provisioning  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Provisioning Data  . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Provisioning Protocols . . . . . . . . . . . . . . . . . .  5
   4.  Database Co-location . . . . . . . . . . . . . . . . . . . . .  6
   5.  Internationalization Considerations  . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13





























Newton                    Expires July 31, 2007                 [Page 2]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


1.  Introduction

   VoIP Service Providers (VSPs) engage in peering relationships with
   other VSPs to create direct IP-to-IP interconnections.  These
   relationships provide 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 operational management
   of hundreds and thousands of direct peering relationship is
   difficult, VSPs enlist the help of peering exchanges to centralize
   the management of the relationships (this is often known as indirect
   peering).

   One of the central functions of these peering exchanges is a registry
   of identifiers, usually telephone numbers.  This function is often
   called the peering registry.  VSPs participating in the peering
   exchange must provision their identifiers into the peering registry.
   Once identifiers are provisioned into the registry, other VSPs may
   query the registry against those identifiers to find the responsible
   VSP.

   To gain as much IP-to-IP coverage, many VSPs have relationships with
   several peering exchanges.  However, the management of just a few
   peering exchange relationships can be made difficult since there is
   no widely excepted standard for which to provision identifiers into a
   peering registry.

   Additionally, some peering registries allow the co-location of their
   database inside the network of a participating VSP.  This is done to
   lower the latency on the query of the peering registry.  Updates to
   the co-located database are done via another mechanism.  Managing
   multiple co-located registry databases can also be problematic since
   there is no standard protocol for the update mechanism.

   The intended scope of work for the Provisioning Extensions in Peering
   Registries for Multimedia Interconnections (PEPPERMINT) activity is
   the creation of standard protocols to solve these two problems.














Newton                    Expires July 31, 2007                 [Page 3]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


2.  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 [3] and SIP [2].

   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, it is often refered to as a
   SIP redirect proxy.  This mechanism is normally used by having the
   peering registry in the signaling path of the VSP.  However, it is
   possible to use SIP redirection outside of a signaling path as a
   separate query mechanism.  The input to this mechansim is a URI with
   the result being multiple URIs, each with an optional display name
   and other parameters (i.e. meta-data).






























Newton                    Expires July 31, 2007                 [Page 4]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


3.  Registry Provisioning

3.1.  Provisioning Data

   The information being provisioned into peering registries by VSPs is
   an identifier and data about the identifier.  This identifier is the
   key used by other VSPs to retrieve a SIP [2] Address of Record (AoR).

   In most cases the identifier is a telephone number or a list of URIs
   containing the same telephone number.  And in most cases where a
   telephone number is the root of an identifier, the telephone number
   is an E.164 number.

3.2.  Provisioning Protocols

   As stated in Section 1, there is no widely accepted standard for
   provisioning identifiers into a peering registry.

   However, the EPP/E.164 [4] standard is used by some, but not many,
   peering registries.  Since RFC 4114 is based upon domain name
   registry provisioning, it is not seen as appropriate for peering
   registry provisioning, especially when provisioning number prefixes
   or number blocks.  And though a domain name model works well for ENUM
   [3] based registries, it is unknown how well it would work for SIP
   [2] based registries.  Finally, RFC 4114 lacks adoption because there
   is little awareness of it in the VSP and peering exchange
   communities.

   Some VSPs and peering registries utilize popular XML based
   technologies such as SOAP.  Though RFC 4114 is also an XML based
   protocol, it is believed that SOAP eliminates the need for VSPs to
   write client code.

   Finally, some peering registries are provisioned using files
   transfered over FTP [1].  While this lacks meaningful transaction
   semantics, it is easily accomplished by nearly any VSP.















Newton                    Expires July 31, 2007                 [Page 5]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


4.  Database Co-location

   Some peering registries co-locate their database of identifiers at
   the premises of the VSPs.  The peering registries then provide
   updates periodically to the co-located database.

   With the exception of DNS AXFR and IXFR mechanisms, there are no
   standard protocols employed for this database synchronization.  And
   the use of DNS zone transfer techniques may be adequate for
   registries with ENUM [3] interfaces, but it is difficult to adapt for
   registries with SIP [2] redirect interfaces.

   Because proprietary protocols are often used, VSPs typically dedicate
   hardware specifically for the database co-location.  VSPs with
   multiple peering exchange relationships must then manage multiple co-
   located databases, each on separate hardware.

   VSPs engaged in routing traffic to the Public Switched Telephone
   Network (PSTN) typically have additional location and routing
   databases, widely known as Route Management Systems (RMS) or Least
   Cost Routing Systems (LCRS).  When coupled with one or more peering
   exchanges, VSPs often need to interject the data from a peering
   registry into these systems.  This is very difficult to do when
   peering registries use proprietary protocols.



























Newton                    Expires July 31, 2007                 [Page 6]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


5.  Internationalization Considerations

   None at present.
















































Newton                    Expires July 31, 2007                 [Page 7]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


6.  IANA Considerations

   Not applicable.
















































Newton                    Expires July 31, 2007                 [Page 8]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


7.  Security Considerations

   None at present.
















































Newton                    Expires July 31, 2007                 [Page 9]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


8.  Acknowledgments

   Many of the points of information in this document are summarizations
   of objectives and statements made by individuals on the PEPPERMINT
   mailing list.  Information on the PEPPERMINT mailing list can be
   found at http://www.ietf.org/mailman/listinfo/peppermint.













































Newton                    Expires July 31, 2007                [Page 10]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


9.  Informative References

   [1]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
        RFC 959, October 1985.

   [2]  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.

   [3]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
        Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
        Application (ENUM)", RFC 3761, April 2004.

   [4]  Hollenbeck, S., "E.164 Number Mapping for the Extensible
        Provisioning Protocol (EPP)", RFC 4114, June 2005.




































Newton                    Expires July 31, 2007                [Page 11]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


Author's Address

   Andrew Newton
   SunRocket
   8045 Leesburg Pike, Suite 300
   Vienna, VA  22182
   US

   Phone: +1 703 636 0852
   Email: andy@hxr.us









































Newton                    Expires July 31, 2007                [Page 12]


Internet-Draft        PEPPERMINT Problem Statement          January 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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





Newton                    Expires July 31, 2007                [Page 13]