One document matched: draft-petithuguenin-dispatch-unique-overlay-00.txt

DISPATCH                                               M. Petit-Huguenin
Internet-Draft                                           Stonyfish, Inc.
Intended status: Standards Track                      September 28, 2011
Expires: March 31, 2012


                         Infrastructure Overlay
             draft-petithuguenin-dispatch-unique-overlay-00

Abstract

   This document provides requirements for infrastructure overlays, a
   special kind of peer-to-peer overlay whose main purpose would be
   defeated if more than one instance would exist on the Internet.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 31, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Petit-Huguenin           Expires March 31, 2012                 [Page 1]

Internet-Draft           Infrastructure Overlay           September 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  VIPR Infrastructure Overlay . . . . . . . . . . . . . . . . 3
     1.2.  Bitcoin-like Infrastructure Overlay . . . . . . . . . . . . 3
     1.3.  BOINC-like Infrastructure Overlay . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Release notes  . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
































Petit-Huguenin           Expires March 31, 2012                 [Page 2]

Internet-Draft           Infrastructure Overlay           September 2011


1.  Introduction

   [RELOAD] is a peer to peer protocol developed by the P2PSIP Working
   Group.  Each RELOAD instance has a unique name, which is used by the
   process in section 10.2 of this specification to find the
   configuration servers, enrollment servers and bootstrap servers
   needed to join the overlay.  The process assumes that the RELOAD
   instance name is a FQDN, and uses the process in [RFC2782] (SRV RR)
   to find the IP address of the HTTPS server that serves the
   configuration document for this overlay.

   This process is adequate when the management of the overlay does not
   need to be distinguished from the owner of the FQDN used as the
   instance name, which is the case most of the time.  But there is a
   special class of overlays that, by definition, requires to be unique
   on the Internet and for which having the possibility of create
   instances would defeat their very purpose.  This specification calls
   the kind of overlays that are not domain specific, but application
   specific "infrastructure overlays".

1.1.  VIPR Infrastructure Overlay

   [VIPR] is a technology that is being standardized in the VIPR Working
   Group and that aims to build bridges between SIP islands by
   automatically provision SIP routes after the "ownership" of a PSTN
   phone number has been verified by an actual PSTN phone call.  This
   technology uses an RELOAD overlay as a distributed database where
   mappings between phone numbers and servers responsible for the
   validation process are stored.  The promise of VIPR to bridge these
   SIP islands cannot be fulfilled if there is more than one distributed
   database storing these mappings.

1.2.  Bitcoin-like Infrastructure Overlay

   The existing Bitcoin [1] protocol is using an IRC channel to find the
   initial peer servers, but one can imagine a Bitcoin-like Internet
   currency that is built on top of RELOAD.  If such Internet currency
   is ever implemented, it would also require a unique RELOAD instance.

1.3.  BOINC-like Infrastructure Overlay

   BOINC [2] is a software which is used for donating computer resources
   for projects as diverse as SETI@Home, Malariacontrol.net and LHC@
   Home.  This kind of research benefiting humanity as a whole could
   probably be better served if implemented on a unique overlay.






Petit-Huguenin           Expires March 31, 2012                 [Page 3]

Internet-Draft           Infrastructure Overlay           September 2011


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


3.  Requirements

   The following requirements can be identified as a starting point for
   the discussion about infrastructure overlays:

   REQ-1:  The mechanism used to find the configuration servers of the
      infrastructure overlay MUST require as little administrative
      overhead as possible.
   REQ-2:  The mechanism MUST NOT require that one entity must shoulder
      the burden for administratively supporting th eoverlay.
   REQ-3:  The mechanism MUST ensure that no one can capture the overlay
      for its own gain.


4.  Security Considerations

   TBD


5.  IANA Considerations

   This document requires no IANA actions.


6.  Acknowledgements

   Jon Peterson and Gonzalo Camarillo suggested to write this document,
   with Jon Peterson providing some of the ideas.

   This document was written with the xml2rfc tool described in
   [RFC2629].


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.

   [RELOAD]   Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and



Petit-Huguenin           Expires March 31, 2012                 [Page 4]

Internet-Draft           Infrastructure Overlay           September 2011


              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-18 (work in
              progress), August 2011.

7.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [VIPR]     Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
              Huguenin, "Verification Involving PSTN Reachability:
              Requirements and Architecture Overview",
              draft-jennings-vipr-overview-02 (work in progress),
              September 2011.

URIs

   [1]  <http://bitcoin.org/>

   [2]  <http://boinc.berkeley.edu/>


Appendix A.  Release notes

   This section must be removed before publication as an RFC.


Author's Address

   Marc Petit-Huguenin
   Stonyfish, Inc.

   Email: petithug@acm.org














Petit-Huguenin           Expires March 31, 2012                 [Page 5]