Internet DRAFT - draft-petithuguenin-dispatch-unique-overlay
draft-petithuguenin-dispatch-unique-overlay
DISPATCH M. Petit-Huguenin
Internet-Draft Unaffiliated
Intended status: Standards Track March 12, 2012
Expires: September 13, 2012
Infrastructure Overlay
draft-petithuguenin-dispatch-unique-overlay-02
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 September 13, 2012.
Copyright Notice
Copyright (c) 2012 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 September 13, 2012 [Page 1]
Internet-Draft Infrastructure Overlay March 2012
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. Proposal . . . . . . . . . . . . . . . . . . . . . . . 5
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 6
B.1. Modifications between -02 and -01 . . . . . . . . . . . . . 6
B.2. Modifications between -01 and -00 . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Petit-Huguenin Expires September 13, 2012 [Page 2]
Internet-Draft Infrastructure Overlay March 2012
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 built on top of RELOAD. If such Internet currency is
ever implemented on top of RELOAD, it would also require a unique
RELOAD instance.
1.3. BOINC-like Infrastructure Overlay
BOINC [2] is a software for volunteer computing and grid computing,
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 September 13, 2012 [Page 3]
Internet-Draft Infrastructure Overlay March 2012
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 the overlay.
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 September 13, 2012 [Page 4]
Internet-Draft Infrastructure Overlay March 2012
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-20 (work in
progress), January 2012.
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.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)",
RFC 3404, October 2002.
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Five: URI.ARPA Assignment Procedures", BCP 65,
RFC 3405, October 2002.
[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. Proposal
One possible way to implement infrastructure overlay is to do
something similar to [RFC3404] and [RFC3405], by defining a .arpa
subdomain named "reload". The overlay name as defined in a standard
track document then becomes a subdomain of "reload.arpa.", so if for
instance the name of an infrastructure overlay is "Quetzalcoatl", the
standard track document defining this overlay is also a request to
create a "Quetzalcoatl.reload.arpa." domain.
Because there is no way to clearly differentiate between a standard
overlay and an infrastructure overlay simply by looking at the
instance-name, especially since ICANN accepts applications for new
top-level domains, this proposal would also redefine the reload URI
Petit-Huguenin Expires September 13, 2012 [Page 5]
Internet-Draft Infrastructure Overlay March 2012
in section 13.15 of [RELOAD], by prepending a '&' symbol to the name
of the overlay to signal that the name following the symbol is the
name of an infrastructure overlay. A RELOAD implementation
supporting infrastructure overlay can then use the procedure defined
in [RELOAD] section 10.2 by using the "reload.arpa." subdomain
instead of the instance name directly.
Appendix B. Release notes
This section must be removed before publication as an RFC.
B.1. Modifications between -02 and -01
o The proposal cares about the RELOAD URI, not the instance-name in
the configuration file.
B.2. Modifications between -01 and -00
o Added a proposal.
Author's Address
Marc Petit-Huguenin
Unaffiliated
Email: petithug@acm.org
Petit-Huguenin Expires September 13, 2012 [Page 6]
