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