One document matched: draft-ietf-p2psip-sip-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-ietf-p2psip-sip.xml 3234 2008-10-27 22:27:49Z lowekamp $ -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<!-- Don't change this. It breaks stuff -->
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-ietf-p2psip-sip-00" ipr="full3978">
<front>
<title abbrev="RELOAD SIP Usage">A SIP Usage for RELOAD</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>MS: SJC-21/2</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Bruce B. Lowekamp" initials="B. B." role="editor"
surname="Lowekamp">
<organization>SIPeerior Technologies</organization>
<address>
<postal>
<street>5251-18 John Tyler Highway #330</street>
<city>Williamsburg</city>
<region>VA</region>
<code>23185</code>
<country>USA</country>
</postal>
<email>bbl@lowekamp.net</email>
</address>
</author>
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
<organization>Network Resonance</organization>
<address>
<postal>
<street>2064 Edgewood Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>
<phone>+1 650 320-8549</phone>
<email>ekr@networkresonance.com</email>
</address>
</author>
<author fullname="Salman A. Baset" initials="S.A." surname="Baset">
<organization>Columbia University</organization>
<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<country>USA</country>
</postal>
<email>salman@cs.columbia.edu</email>
</address>
</author>
<author fullname="Henning Schulzrinne" initials="H.G."
surname="Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<country>USA</country>
</postal>
<email>hgs@cs.columbia.edu</email>
</address>
</author>
<date day="27" month="October" year="2008" />
<area>RAI</area>
<workgroup>P2PSIP</workgroup>
<abstract>
<t>
This document defines a SIP Usage for REsource LOcation And
Discovery (RELOAD), The SIP Usage provides the functionality
of a SIP proxy or registrar in a fully-distributed system.
The SIP Usage provides lookup service for AoRs stored in the
overlay. The SIP Usage also defines GRUUs that allow the
registrations to map an AoR to a specific node reachable
through the overlay. The Attach method is used to establish
a direct connection between nodes through which SIP messages
are exchanged.
</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>The SIP Usage of RELOAD allows SIP user agents to provide a
peer-to-peer telephony service without the requirement for permanent
proxy or registration servers. In such a network, the RELOAD overlay
itself performs the registration and rendezvous functions ordinarily
associated with such servers.</t>
<t>The SIP Usage involves two basic functions:
<list style="hanging">
<t hangText="Registration: ">SIP UAs can use the RELOAD data
storage functionality to store a mapping from their AOR to their
Node-ID in the overlay, and to retrieve the Node-ID of other
UAs.</t>
<t hangText="Rendezvous: ">Once a SIP UA has identified the
Node-ID for an AOR it wishes to call, it can use the RELOAD
message routing system to set up a direct connection which can be
used to exchange SIP messages.</t>
</list>
</t>
<t>For instance, Bob could register his Node-ID, "1234", under his
AOR, "sip:bob@dht.example.com". When Alice wants to call Bob, she
queries the overlay for "sip:bob@dht.example.com" and gets back
Node-ID 1234. She then uses the overlay to establish a direct
connection with Bob and can use that direct connection to perform a
standard SIP INVITE. The way this works is as follows:</t>
<t><list style="numbers">
<t>Bob, operating Node-ID 1234, stores a mapping from his URI to his
Node-ID in the overlay. I.e., "sip:bob@dht.example.com ->
1234".</t>
<t>Alice, operating Node-ID 5678, decides to call Bob. She looks up
"sip:bob@dht.example.com" in the overlay and retrieves "1234".</t>
<t>Alice uses the overlay to route an Attach message to Bob's peer.
Bob responds with his own Attach and they set up a direct
connection, as shown below.</t>
</list></t>
<figure>
<artwork><![CDATA[
Alice Peer1 Overlay PeerN Bob
(5678) (1234)
-------------------------------------------------
Attach ->
Attach ->
Attach ->
Attach ->
<- Attach
<- Attach
<- Attach
<- Attach
<------------------ ICE Checks ----------------->
INVITE ----------------------------------------->
<--------------------------------------------- OK
ACK -------------------------------------------->
<------------ ICE Checks for media ------------->
<-------------------- RTP ---------------------->
]]></artwork>
</figure>
<t>It is important to note that RELOAD's only role here is to set up the
direct connection between Alice and Bob. As soon as the ICE checks
complete and the connection is established, then ordinary SIP is used.
In particular, the establishment of the media channel for the phone call
happens via the usual SIP mechanisms, and RELOAD is not involved. Media
never goes over the overlay. After the successful exchange of SIP
messages, call peers run ICE connectivity checks for media.</t>
<t>As well as allowing mappings from AORs to Node-IDs, the SIP Usage
also allows mappings from AORs to other AORs. For instance, if Bob
wanted his phone calls temporarily forwarded to Charlie, he could store
the mapping "sip:bob@dht.example.com -> sip:charlie@dht.example.com".
When Alice wants to call Bob, she retrieves this mapping and can then
fetch Charlie's AOR to retrieve his Node-ID.</t>
<t>The SIP usage allows a RELOAD overlay to be used as a distributed SIP
registrar/proxy network augmenting the functionality of <xref
target="RFC3263"></xref>. This entails three primary operations:</t>
<t><list style="symbols">
<t>Registering one's own AOR with the overlay.</t>
<t>Looking up a given AOR in the overlay.</t>
<t>Forming a direct connection to a given peer.</t>
</list></t>
<!-- EKR RemoveD: Too much information here
<section title="SIP Connect">
<t>This usage allows two clients to form a new TLS or DTLS
connection between them and then use this connection for sending
SIP messages to one another. This does not store any information
in the overlay, but it allows the Attach request to be used to set up
a TLS or DTLS connection between two peers and then use that
connection to send SIP messages back and forth.</t>
<t>The Attach request will ensure that the connection is formed
to a peer that has a certificate which includes the user that the
connection is being formed to.</t>
</section>
<section title="SIP GRUUs">
<t>GRUUs that refer to peers in the P2P network are constructed by
simply forming a GRUU, where the value of gr URI parameter
contains a base64 encoded version of the destination list that
will reach the peer. Typically the destination list is just a
single entry with the Node-ID of peer.</t>
</section>
-->
<!-- EKR Removed
<section title="SIP Tunnel">
<t>This Tunnel request allows two peers to exchange SIP messages
across the overlay using the Tunnel method without first setting
up a direct connection using Attach. This allows a SIP message to
be sent immediately, without the delay associated with Attach and
for a simple SIP exchange, it may result in fewer messages being
sent.</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">RFC 2119</xref>.</t>
<t>We use the terminology and definitions from <xref
target="I-D.ietf-p2psip-concepts">Concepts and Terminology for Peer to
Peer SIP</xref> and the <xref target="I-D.ietf-p2psip-base">RELOAD Base
Protocol</xref> extensively in this document.</t>
</section>
<!-- EKR: Fodder from previous P2PSIP overview
<t>All SIP URIs for a given overlay MUST be constructed so that they
terminate in the domain name of the overlay. For instance, if the
overlay name is "example.com", then all AORs must be of the form
{sip,sips}:username@example.com. Accordingly, to dereference a URI,
a P2PSIP implementation MUST check to see if the domain matches an
overlay which it is a member of. If so, it uses the following
procedures. Otherwise, it MUST follow <xref target="RFC3263"></xref>
procedures. Note that unless the P2PSIP overlay provides some kind
of gateway to ordinary SIP (e.g., a publicly accessible SIP server)
this is likely to be only partially successful, since, for instance,
the callee may not be able to call back.</t>
<section title="SIP Location">
<t>A peer acting as a SIP UA stores their registration information
in the overlay by storing either another URI (for retargeting) or a
destination lists to reach them at a Resource-ID in the overlay formed
from the user's SIP AOR. When another peer wishes to find a peer
that is registered for a SIP URI, the lookup of the user's name is
done by taking the user's SIP Address of Record (AOR) and using it
as the Resource Name that is hashed to get a Resource-ID. When the
Resource Name is dereferenced, the result is a set of values. Each
value is either another SIP URI or a destination list. If the
value is a SIP URI, the calling peer looks up that URI and
continues the process until it gets a destination list.</t>
<t>If the value is a destination list, then it is used to reach a
peer that represents a SIP UA registered for that AOR. Typically
this destination list will have just one entry but in the case of
peers or clients that can not be directly reached (for instance
via a strict NAT or firewall), a destination list with more than
one entry may need to be used.</t>
<t>The Resource Name for this usage is a user's SIP AOR, such as
"sip:alice@example.com". This allows the set to store many values
in a dictionary structure. The authorization policy is that Store
requests are only allowed if the user name in the signing
certificate, when turned into a SIP URL and hashed, matches the
Resource-ID. This policy ensures that only a user with the
certificate with the user name "alice@example.com" can write to
the Resource-ID that will be used to look up calls to
"sip:alice@example.com".</t>
<t>[[Open Issue: Should the Resource Name be
"sip:alice@example.com", "alice@example.com", or a string that
includes the code point defined for the kind? The issue here is
determining whether different usages that store data at a
Resource Name that is primarily formed from "alice@example.com"
should hash to the same Resource-ID as the SIP Usage. For example,
if a buddy list had a Resource Name that was roughly the same, would
we want the buddy list information to end up on the same peers
that stored the SIP location data or on different peers?]]</t>
</section>
-->
<section title="Registering AORs">
<t>In ordinary SIP, a UA registers its AOR and location with a
registrar. In RELOAD, this registrar function is provided by the overlay
as a whole. To register its location, a RELOAD peer stores a
SipRegistration structure under its own AOR. This uses the
SIP-REGISTRATION Kind-ID, which is formally defined in <xref
target="sec.sip-reg-kind"></xref>. <list style="hanging">
<t hangText="Note:">GRUUs are handled via a separate mechanism, as
described in <xref target="sec-gruus"></xref>.</t>
</list></t>
<t>As a simple example, if Alice's AOR were "sip:alice@dht.example.com"
and her Node-ID were "1234", she might store the mapping
"sip:alice@example.org -> 1234". This would tell anyone who wanted to
call Alice to contact node "1234".</t>
<t>RELOAD peers MAY store two kinds of SIP mappings:</t>
<t><list style="symbols">
<t>From AORs to destination lists (a single Node-ID is just a
trivial destination list.)</t>
<t>From AORs to other AORs.</t>
</list></t>
<t>The meaning of the first kind of mapping is "in order to contact me,
form a connection with this peer." The meaning of the second kind of
mapping is "in order to contact me, dereference this AOR". This allows
for forwarding. For instance, if Alice wants calls to her to be
forwarded to her secretary, Sam, she might insert the following mapping
"sip:alice@dht.example.org -> sip:sam@dht.example.org".</t>
<t>The contents of a SipRegistration structure are as follows:</t>
<figure>
<!--begin-pdu-->
<artwork><![CDATA[
enum {sip_registration_uri (1), sip_registration_route (2),
(255)} SipRegistrationType;
select (SipRegistration.type) {
case sip_registration_uri:
opaque uri<0..2^16-1>;
case sip_registration_route:
opaque contact_prefs<0..2^16-1>;
Destination destination_list<0..2^16-1>;
/* This type can be extended */
} SipRegistrationData;
struct {
SipRegistrationType type;
uint16 length;
SipRegistrationData data;
} SipRegistration;
]]></artwork>
</figure>
<t>The contents of the SipRegistration PDU are:</t>
<t><list style="hanging">
<t></t>
<t hangText="type "></t>
<t>the type of the registration</t>
<t></t>
<t hangText="length "></t>
<t>the length of the rest of the PDU</t>
<t></t>
<t hangText="data "></t>
<t>the registration data</t>
</list></t>
<t><list style="symbols">
<t>If the registration is of type "sip_registration_uri", then the
contents are an opaque string containing the URI.</t>
<t>If the registration is of type "sip_registration_route", then the
contents are an opaque string containing the callee's contact
preferences and a destination list for the peer.</t>
</list></t>
<t>RELOAD explicitly supports multiple registrations for a single AOR.
The registrations are stored in a Dictionary with the dictionary keys
being Node-IDs. Consider, for instance, the case where Alice has two
peers:</t>
<t><list style="symbols">
<t>her desk phone (1234)</t>
<t>her cell phone (5678)</t>
</list></t>
<t>Alice might store the following in the overlay at resource
"sip:alice@dht.example.com".</t>
<t><list style="symbols">
<t>A SipRegistration of type "sip_registration_route" with
dictionary key "1234" and value "1234".</t>
<t>A SipRegistration of type "sip_registration_route" with
dictionary key "5678" and value "5678".</t>
</list></t>
<t>Note that this structure explicitly allows one Node-ID to forward to
another Node-ID. For instance, Alice could set calls to her desk phone
to ring at her cell phone. It's not clear that this is useful in this
case, but may be useful if Alice has two AORs.</t>
<t>In order to prevent hijacking, registrations are subject to access
control rules. Before a Store is permitted, the storing peer MUST check
that:</t>
<t><list style="symbols">
<t>The certificate contains a username that is a SIP AOR that hashes
to the Resource-ID being stored at.</t>
<t>The certificate contains a Node-ID that is the same as the
dictionary key being stored at.</t>
</list></t>
<t>Note that these rules permit Alice to forward calls to Bob without
his permission. However, they do not permit Alice to forward Bob's calls
to her. See <xref target="sec-security-malicious-retargeting"></xref>
for more on this point.</t>
</section>
<section title="Looking up an AOR">
<t>When a RELOAD user wishes to call another user, starting with a
non-GRUU AOR, he follows the following procedure. (GRUUs are discussed
in <xref target="sec-gruus"></xref>).</t>
<t><list style="numbers">
<t>Check to see if the domain part of the AOR matches the domain
name of an overlay of which he is a member. If not, then this is an
external AOR, and he MUST do one of the following: <list
style="symbols">
<t>Fail the call.</t>
<t>Use ordinary SIP procedures.</t>
<t>Attempt to become a member of the overlay indicated by the
domain part, if that overlay is a RELOAD overlay.)</t>
</list></t>
<t>Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID
corresponding to the AOR. This Fetch SHOULD NOT indicate any
dictionary keys, which will result in fetching all the stored
values.</t>
<t>If any of the results of the Fetch are non-GRUU AORs, then repeat
step 1 for that AOR.</t>
<t>Once only GRUUs and destination lists remain, the peer removes
duplicate destination lists and GRUUs from the list and forms a SIP
connection to the appropriate peers as described in the following
sections. If there are also external AORs, the peer follows the
appropriate procedure for contacting them as well.</t>
</list></t>
</section>
<section title="Forming a Direct Connection">
<t>Once the peer has translated the AOR into a set of destination lists,
it then uses the overlay to route Attach messages to each of those
peers. The "application" field MUST be 5060 to indicate SIP. If
certificate-based authentication is in use, the responding peer MUST
present a certificate with a Node-ID matching the terminal entry in the
route list. Note that it is possible that the peers already have a
RELOAD connection between them. This MUST NOT be used for SIP messages.
However, if a SIP connection already exists, that MAY be used. Once the
Attach succeeds, the peer sends SIP messages over the connection as in
normal SIP.</t>
</section>
<section anchor="sec-gruus" title="GRUUs">
<t>GRUUs do not require storing data in the Overlay Instance. Rather,
they are constructed by embedding a base64-encoded destination list in
the gr URI parameter of the GRUU. The base64 encoding is done with the
alphabet specified in table 1 of RFC 4648 with the exception that ~ is
used in place of =. An example GRUU is
"sip:alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer
needs to route a message to a GRUU in the same P2P network, it simply
uses the destination list and connects to that peer.</t>
<t>Because a GRUU contains a destination list, it MAY have the same
contents as a destination list stored elsewhere in the resource
dictionary.</t>
<t>Anonymous GRUUs are done in roughly the same way but require either
that the enrollment server issue a different Node-ID for each anonymous
GRUU required or that a destination list be used that includes a peer
that compresses the destination list to stop the Node-ID from being
revealed.</t>
</section>
<section anchor="sec.sip-reg-kind"
title="SIP-REGISTRATION Kind Definition">
<t>The first mapping is provided using the SIP-REGISTRATION Kind-ID:</t>
<t><list style="hanging">
<t></t>
<t hangText="Kind IDs">The Resource Name for the SIP-REGISTRATION
Kind-ID is the AOR of the user. The data stored is a
SipRegistrationData, which can contain either another URI or a
destination list to the peer which is acting for the user.</t>
<t></t>
<t hangText="Data Model">The data model for the SIP-REGISTRATION
Kind-ID is dictionary. The dictionary key is the Node-ID of the
storing peer. This allows each peer (presumably corresponding to a
single device) to store a single route mapping.</t>
<t></t>
<t hangText="Access Control">If certificate-based access control is
being used, stored data of Kind-ID SIP-REGISTRATION must be signed
by a certificate which (1) contains user name matching the storing
URI used as the Resource Name for the Resource-ID and (2) contains a
Node-ID matching the storing dictionary key.</t>
</list></t>
<t>Data stored under the SIP-REGISTRATION kind is of type
SipRegistration. This comes in two varieties: <list style="hanging">
<t></t>
<t hangText="sip_registration_uri "></t>
<t>a URI which the user can be reached at.</t>
<t></t>
<t hangText="sip_registration_route "></t>
<t>a destination list which can be used to reach the user's
peer.</t>
</list></t>
<!--
<section title="SIP Tunnel">
<t>Two peers can also exchange SIP messages across the
overlay using the Tunnel method. This allows a SIP message to be
sent immediately, without the delay associated with Attach. For a
simple SIP exchange, it may result in fewer messages being sent.</t>
<t>An implementation SHOULD use Attach for a dialog that is
expected to endure for sufficient time and exchange significant
numbers of messages. An implementation MAY establish an initial
dialog using Tunneling and then migrate it to a direct dialog opened
with Attach once that negotiation is complete.</t>
<t>As an application of Tunnel, this usage defines the following
items:</t>
<t><list style="symbols">
<t>For SIP, the application attribute is 5060.</t>
<t>The application MAY establish any dialog using Tunnel if it
expects to replace it once an Attach request completes. The
application SHOULD NOT exchange messages with another SIP UA
repeatedly using a Tunnel unless it is unable to complete a
Attach.</t>
<t>The Replaces header should be used to migrate dialogs
established via Tunnel to a direct connection.</t>
<t>The dialogid is the GRUU of the destination of the
request.</t>
<t>By using the GRUU of the destination as the dialogid, the
receiving peer is able to deliver the message to the appropriate
process without parsing the SIP message.</t>
</list></t>
[OPEN ISSUE: How is the Via List constructed for the SIP message?]
<t>In constructing the message, the SIP UA forms the message as if
it were being routed directly to the GRUU of the destination. The
SIP stack hands the message to RELOAD for delivery. Although the
message is passed through a sequence of untrusted peers, it is not
subject to modification by those peers because of the message's
signature.</t>
<t>OPEN ISSUE: should specify how to request encryption of the
message end-to-end.</t>
<t>OPEN ISSUE: If the tunneling vs direct decision can be made
equivalently to a link-layer decision, it may not be necessary to
modify the dialog or inform the SIP UA in any way that it has now
obtained a direct route.</t>
<t>OPEN ISSUE: what does the via list look like?</t>
</section>
-->
</section>
<section title="Security Considerations">
<section title="Overview">
<t>RELOAD provides a generic storage service, albeit one designed to
be useful for P2PSIP. In this section we discuss security issues that
are likely to be relevant to any usage of RELOAD. In <xref
target="section.sip-issues"></xref> we describe issues that are
specific to SIP.</t>
<t>In any Overlay Instance, any given user depends on a number of
peers with which they have no well-defined relationship except that
they are fellow members of the Overlay Instance. In practice, these
other nodes may be friendly, lazy, curious, or outright malicious. No
security system can provide complete protection in an environment
where most nodes are malicious. The goal of security in RELOAD is to
provide strong security guarantees of some properties even in the face
of a large number of malicious nodes and to allow the overlay to
function correctly in the face of a modest number of malicious
nodes.</t>
<t>P2PSIP deployments require the ability to authenticate both peers
and resources (users) without the active presence of a trusted entity
in the system. We describe two mechanisms. The first mechanism is
based on public key certificates and is suitable for general
deployments. The second is an admission control mechanism based on an
overlay-wide shared symmetric key.</t>
</section>
<section anchor="section.sip-issues" title="SIP-Specific Issues">
<section title="Fork Explosion">
<t>Because SIP includes a forking capability (the ability to
retarget to multiple recipients), fork bombs are a potential DoS
concern. However, in the SIP usage of RELOAD, fork bombs are a much
lower concern because the calling party is involved in each
retargeting event and can therefore directly measure the number of
forks and throttle at some reasonable number.</t>
</section>
<section anchor="sec-security-malicious-retargeting"
title="Malicious Retargeting">
<t>Another potential DoS attack is for the owner of an attractive
number to retarget all calls to some victim. This attack is
difficult to ameliorate without requiring the target of a SIP
registration to authorize all stores. The overhead of that
requirement would be excessive and in addition there are good use
cases for retargeting to a peer without there explicit
cooperation.</t>
</section>
<section title="Privacy Issues">
<t>All RELOAD SIP registration data is public. Methods of providing
location and identity privacy are still being studied.</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>This section contains the new code points registered by this
document.</t>
<t>TODO define SIP usage specific kinds, etc here.</t>
</section>
<section title="Acknowledgments">
<t>This draft is a merge of the "REsource LOcation And Discovery
(RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B.
Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen
Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security
Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick,
the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia
Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) draft
by Salman A. Baset, Henning Schulzrinne, and Marcin Matuszewski.</t>
<t>Thanks to the many people who contributed including: Michael Chen,
TODO - fill in.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3263"?>
<reference anchor="I-D.ietf-p2psip-base">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization></organization>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization></organization>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization></organization>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization></organization>
</author>
<author fullname="Henning Schulzrinne" initials="H"
surname="Schulzrinne">
<organization></organization>
</author>
<date day="27" month="October" year="2008" />
<abstract>
<t>This document 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 which do not need to route
traffic or store data for others.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-00" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-00.txt"
type="TXT" />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-p2psip-concepts"?>
</references>
<section anchor="sec-changes" title="Change Log">
<section title="Changes since draft-ietf-p2psip-reload-00">
<t><list style="symbols">
<t>Split SIP Usage from combined draft into new
draft.</t>
</list></t>
</section>
</section>
<!--
<t>The forwarding layer is responsible for looking at message and
doing one of three things:</t>
<t><list style="symbols">
<t>Deciding the message was destined for this peer and passing the
message up to the layer above this.</t>
<t>Looking at the Node-ID that represents the next peer to send
the message too and if there is an existing connection, sending
the message over the connection.</t>
<t>Requesting the overlay Routing logic to tell the forwarding layer
which peer the message needs to be forwarded to (based on the
target Node-ID or Resource-ID), and then sending the message.</t>
</list></t>
-->
<!--
<section anchor="sec-via-list" title="Via Lists">
<t>
[TODO: BBL; I would merge this into the symmetric section
and try to trim a bit.]
</t>
<t>In a general messaging system, messages need a source and a
destination and peers need to be able to send a response to the peer
that sent the request. This can be particularly tricky in overlay
networks when a new peer is joining, or the overlay network is
stabilizing and different peers have different ideas on what the
overlay topology is. A simple and reliable way to make sure that a
response can reach the node that sent the request in these
situations is to have the response traverse the reverse path of the
request.</t>
<t>The approach used here is to have each node the request traverses
add its Node-ID to the "via list" in the request. Then the response
is routed by looking at the list and using it as list of peers that
the response will be routed thorough. To support this, each message
has a destination list of nodes it needs to be routed through as
well as a via list of what nodes it has traversed.</t>
<t>When a peer receives a message from the Transport Layer, it adds
the Node-ID of the node it received the message from to the end of
the via list. When a peer goes to transmit a message to the
Transport Layer, it looks at the first entry on the destination
list. If the entry is this peer, it removes this entry from the list
and looks at the next entry and if the entry is not this peer, it
sends the message to the first peer on the destination list.</t>
<t>When a peer goes to send a response to a request, it can simply
copy the via list in reverse to form the destination list for the
response if it wishes to route the response along the reverse path
as the request.</t>
<t>Peers that are willing to maintain state may do list compression
for privacy reason and to reduce the message size. They do this by
taking some number of entries off the via list and replacing them
with a unique entry that this peer can later identify. Later, if the
peer sees the unique entry in a destination list, it removes the
unique entry and replaces it with the all the entries removed from
the original via list (and reverses the order of these entries).
Note that this technique will generally require storing some
per-message state on the intermediate peer, so this is a
bandwidth/per-peer state tradeoff. The exception is if the list is
not compressed but rather the Node-IDs are simply encrypted.</t>
<t>The via list approach provides several features. First it allows
a response to follow the same path as the request. This is
particularly important for peers that are sending requests while
they are joining and before other peers can route to them as well as
situations where message are being exchanged to stabilize the
overlay network. It also makes it easier to diagnose and manage the
system when all peers see the response to any request they
forward.</t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:39:08 |