One document matched: draft-petithuguenin-dispatch-unique-overlay-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-petithuguenin-dispatch-unique-overlay-02" ipr="noModificationTrust200902">
<front>
<title abbrev="Infrastructure Overlay">Infrastructure Overlay</title>
<author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
<organization>Unaffiliated</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="12" month="March" year="2012"/>
<area>RAI</area>
<workgroup>DISPATCH</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="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 <xref target="RFC2782"/> (SRV RR) to find the IP address of the HTTPS server that serves the configuration document for this overlay.
</t>
<t>
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".
</t>
<section title="VIPR Infrastructure Overlay">
<t>
<xref target="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.
</t>
</section>
<section title="Bitcoin-like Infrastructure Overlay">
<t>
The existing <eref target="http://bitcoin.org/">Bitcoin</eref> 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.
</t>
</section>
<section title="BOINC-like Infrastructure Overlay">
<t>
<eref target="http://boinc.berkeley.edu/">BOINC</eref> 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.
</t>
</section>
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Requirements">
<t>
The following requirements can be identified as a starting point for the discussion about infrastructure overlays:
</t>
<t>
<list style="hanging">
<t hangText="REQ-1:">The mechanism used to find the configuration servers of the infrastructure overlay MUST require as little administrative overhead as possible.</t>
<t hangText="REQ-2:">The mechanism MUST NOT require that one entity must shoulder the burden for administratively supporting the overlay.</t>
<t hangText="REQ-3:">The mechanism MUST ensure that no one can capture the overlay for its own gain.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>This document requires no IANA actions.</t>
</section>
<section title="Acknowledgements">
<t>Jon Peterson and Gonzalo Camarillo suggested to write this document, with Jon Peterson providing some of the ideas.</t>
<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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
RFC 2119.
</t>
</list>
</t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="RELOAD">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization/>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization/>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization/>
</author>
<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
<organization/>
</author>
<date day="17" month="January" year="2012"/>
<abstract>
<t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-20"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-20.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
<reference anchor="RFC2782">
<front>
<title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS SRV)</title>
<author fullname="Arnt Gulbrandsen" initials="A." surname="Gulbrandsen">
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region/>
<code>N-0175</code>
<country>NO</country>
</postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email>
</address>
</author>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>
<phone>+1 650 779 7001</phone>
</address>
</author>
<author fullname="Levon Esibov" initials="L." surname="Esibov">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>levone@microsoft.com</email>
</address>
</author>
<date month="February" year="2000"/>
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2782"/>
<format octets="24013" target="http://www.rfc-editor.org/rfc/rfc2782.txt" type="TXT"/>
</reference>
<reference anchor="RFC3404">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization/>
</author>
<date month="October" year="2002"/>
<abstract>
<t>This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3404"/>
<format octets="40124" target="http://www.rfc-editor.org/rfc/rfc3404.txt" type="TXT"/>
</reference>
<reference anchor="RFC3405">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization/>
</author>
<date month="October" year="2002"/>
<abstract>
<t>This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="65"/>
<seriesInfo name="RFC" value="3405"/>
<format octets="19469" target="http://www.rfc-editor.org/rfc/rfc3405.txt" type="TXT"/>
</reference>
<reference anchor="VIPR">
<front>
<title>Verification Involving PSTN Reachability: Requirements and Architecture Overview</title>
<author fullname="Mary Barnes" initials="M" surname="Barnes">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M" surname="Petit-Huguenin">
<organization/>
</author>
<date day="28" month="September" year="2011"/>
<abstract>
<t>The Session Initiation Protocol (SIP) has seen widespread deployment within individual domains, typically supporting voice and video communications. Though it was designed from the outset to support inter-domain federation over the public Internet, such federation has not materialized. The primary reasons for this are the complexities of inter-domain phone number routing and concerns over security. This document reviews this problem space, outlines requirements, and then describes a new model and technique for inter-domain federation with SIP involving the Public Switched Telephone Network (PSTN), called Verification Involving PSTN Reachability (VIPR). VIPR addresses the problems that have prevented inter-domain federation over the Internet. It provides fully distributed inter-domain routing for phone numbers, authorized mappings from phone numbers to domains, a new technique for automated SIP anti-spam, and privacy of number ownership, all while preserving the trapezoidal model of SIP.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-jennings-vipr-overview-02"/>
<format target="http://www.ietf.org/internet-drafts/draft-jennings-vipr-overview-02.txt" type="TXT"/>
</reference>
</references>
<section title="Proposal">
<t>
One possible way to implement infrastructure overlay is to do something similar to <xref target="RFC3404"/> and <xref target="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.
</t>
<t>
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 in section 13.15 of <xref target="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 <xref target="RELOAD"/> section 10.2 by using the "reload.arpa." subdomain instead of the instance name directly.
</t>
</section>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between -02 and -01">
<t>
<list style="symbols">
<t>The proposal cares about the RELOAD URI, not the instance-name in the configuration file.</t>
</list>
</t>
</section>
<section title="Modifications between -01 and -00">
<t>
<list style="symbols">
<t>Added a proposal.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:44:27 |