SIPPING Working Group D. Willis, Ed.
Internet-Draft Cisco Systems
Intended status: Experimental D. Bryan
Expires: April 15, 2007 SIPeerior Technologies and William
& Mary
P. Matthews
Avaya
E. Shim
Panasonic Digital Networking
Laboratory
October 12, 2006
Concepts and Terminology for Peer to Peer SIP
draft-willis-p2psip-concepts-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines concepts and terminology for use of the Session
Willis, et al. Expires April 15, 2007 [Page 1]
Internet-Draft P2PSIP Concepts and Terminology October 2006
Initiation Protocol in a peer-to-peer environment where the
traditional proxy-registrar function is replaced by a distributed
mechanism that might be implemented using a distributed hash table or
other distributed data mechanism with similar external properties.
This document includes a high-level view of the functional
relationships between the network elements defined herein, a
conceptual model of operations, and an outline of the related open
problems that might be addressed by an IETF working group.
Requirements Language
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 [1].
Willis, et al. Expires April 15, 2007 [Page 2]
Internet-Draft P2PSIP Concepts and Terminology October 2006
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. What Kinds of P2PSIP Peers and Clients Might Exist? . . . 10
3.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 10
3.3. Example Signalling Message Flows . . . . . . . . . . . . . 13
3.3.1. P2PSIP Peer contacts P2PSIP Peer . . . . . . . . . . . 13
3.3.2. P2PSIP Client contacts P2PSIP Peer . . . . . . . . . . 14
3.3.3. Conventional SIP Device using a Proxy Peer . . . . . . 15
3.3.4. Conventional SIP Device Using a Redirect Peer . . . . 16
3.4. Conceptual Outline of Operations . . . . . . . . . . . . . 18
3.4.1. Enrolling and Inserting an P2PSIP Peer . . . . . . . . 18
3.4.2. More on The Difference Between a Peer, Client, and
User Agent . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3. Enrolling a User and Inserting a P2PSIP User Agent . . 19
3.4.4. Bootstrapping . . . . . . . . . . . . . . . . . . . . 19
4. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. PP2PSIP Peer Protocol . . . . . . . . . . . . . . . . . . 20
4.2. P2PSIP Client Protocol . . . . . . . . . . . . . . . . . . 20
4.3. How To Find Media Relays? . . . . . . . . . . . . . . . . 20
4.4. How Do We Find Gateways? . . . . . . . . . . . . . . . . . 21
4.5. Peer-Adjacency Through NATs . . . . . . . . . . . . . . . 21
4.6. Cryptotransparency . . . . . . . . . . . . . . . . . . . . 21
4.7. Record Formats . . . . . . . . . . . . . . . . . . . . . . 21
4.8. Peer and Client Enrollment Protocols . . . . . . . . . . . 21
4.9. Peer and User Credentials . . . . . . . . . . . . . . . . 21
4.10. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21
4.11. Credential Recovery . . . . . . . . . . . . . . . . . . . 22
4.12. Overlapping Domains . . . . . . . . . . . . . . . . . . . 22
4.13. Hybrid Domains . . . . . . . . . . . . . . . . . . . . . . 22
4.14. Admissions Control . . . . . . . . . . . . . . . . . . . . 22
4.15. Users versus Resources . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Willis, et al. Expires April 15, 2007 [Page 3]
Internet-Draft P2PSIP Concepts and Terminology October 2006
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Willis, et al. Expires April 15, 2007 [Page 4]
Internet-Draft P2PSIP Concepts and Terminology October 2006
1. Background
One of the fundamental problems in multimedia communications between
Internet nodes is that of a discovering the IP address at which a
given correspondent can be reached. Correspondents are frequently
identified by distinguished names, perhaps represented in the form of
a universal resource indicator (URI) [2].
The Session Initiation Protocol (SIP) [3] commonly addresses this
task assuming that the domain part of the URI indicates an internet
host address or internet domain name using the Domain Name System
(DNS) [4]. SIP's location process [5] assumes that host part of the
URI indicates either the target SIP user agent (UA), or a proxy that
has knowledge of how to to reach the target UA, presumably gained
through SIP's registration process.
This approach, referred to herein as "Conventional SIP" or "Client/
Server SIP", assumes a relatively fixed hierarchy of SIP routing
proxies (servers) and SIP user agents (clients). The routing proxies
are typically resolvable using conventional Internet mechanisms with
static IP addresses and associated DNS entries. This structure may
not be ideal in all cases, including specifically ad-hoc, serverless,
and reduced-administration scenarios. As an alternative, several
authors [7] [8] [9] [10] have proposed using peer-to-peer (P2P) [11]
approaches to solving the correspondent discovery problem. The
motivations for a P2P approach in SIP have been documented in [12].
This document offers a consolidation of the more important terms and
concepts from several of the above documents, presented in the
context of a reference model for peer-to-peer SIP (P2PSIP). It is
intended that this document serve as a starting point for describing
the work needed to resolve a number of open questions such that an
IETF working group could be chartered to do the work needed to
resolve these questions and present a standard solution. The authors
believe that this goal is roughly consistent with that of a Protocol
Model as defined in [13].
2. Definitions
We provide a list of terms used, as well as alternate forms that have
been used for these in drafts or discussions. In general, the
thought is to use the primary suggested form for clarity -- we have
included the other forms for simplicity and to provide a "mapping" to
existing drafts. Defined terms include:
Willis, et al. Expires April 15, 2007 [Page 5]
Internet-Draft P2PSIP Concepts and Terminology October 2006
Overlay Network: An overlay network is a computer network which is
built on top of another network. Nodes in the overlay can be
thought of as being connected by virtual or logical links, each of
which corresponds to a path, perhaps through many physical links,
in the underlying network. For example, many peer-to-peer
networks are overlay networks because they run on top of the
Internet. Dial-up Internet is an overlay upon the telephone
network. <http://en.wikipedia.org/wiki/P2P_overlay>
P2P Network: A peer-to-peer (or P2P) computer network is a network
that relies primarily on the computing power and bandwidth of the
participants in the network rather than concentrating it in a
relatively low number of servers. P2P networks are typically used
for connecting nodes via largely ad hoc connections. Such
networks are useful for many purposes. Sharing content files (see
file sharing [16]) containing audio, video, data or anything in
digital format is very common, and realtime data, such as
telephony traffic, is also passed using P2P technology.
<http://en.wikipedia.org/wiki/Peer-to-peer>. A P2P Network may
also be called a "P2P Overlay" or "P2P Overlay Network" or "P2P
Network Overlay" , since its organization is not at the physical
layer, but is instead "on top of" an existing Internet Protocol
network.
P2PSIP: A communications protocol related to the Session Initiation
Protocol (sip) [3] that extends SIP by using peer-to-peer
techniques for resolving the targets of SIP requests.
P2PSIP Overlay: A P2PSIP Overlay is an association, collection, or
federation of nodes that provides SIP registration, SIP request
routing, and similar functions using a P2P organization, as
defined by "P2P Network" above. Other forms: overlay.
P2PSIP Peer: A node participating in a P2PSIP Overlay that provides
storage and routing services (fully participates in the P2P
routing) to other nodes in that P2PSIP Overlay. Each P2PSIP Peer
is presumed to have a unique identifier within the P2PSIP Overlay.
Each P2PSIP Peer may or may not be coupled to one or more P2PSIP
User Agents. Within the P2PSIP Overlay, the peer is capable of
performing several different operations, including: joining and
leaving the overlay, routing requests within the overlay, storing
information on behalf of the overlay, putting information into the
overlay, and getting information from the overlay. Other forms:
overlay peer or node, peer or node, superpeer or supernode (in
systems with peers and clients), peer.
Willis, et al. Expires April 15, 2007 [Page 6]
Internet-Draft P2PSIP Concepts and Terminology October 2006
P2PSIP Client: A node participating in a P2PSIP Overlay that
provides neither routing nor route storage and retrieval functions
to that P2PSIP Overlay. The P2PSIP Client interacts with the
P2PSIP Overlay only to request the insertion of routing
information (put in a Contact), request the retrieval of routing
information (get a Contact), or to request the routing of a
message to elsewhere in the P2PSIP Overlay. Unlike the P2PSIP
Peer, the client is presumed not to have a unique identifier
within the overlay. In cases where conventional SIP is used for
the P2PSIP Client protocol, this entity could be identical to a
standard SIP user agent. A P2PSIP Client may be coupled to one or
more P2PSIP Overlay User Agents. A P2PSIP Client is a logical
subset of a P2PSIP Peer; anything a P2PSIP Client can do, a P2PSIP
Peer can do as well. Other forms: overlay client, client.
P2PSIP Resource (User): An addressable user endpoint, entity,
service, or function within a P2PSIP Overlay. Examples include
but are not limited to humans, automata, bridges, mixers, media
relays, gateways, and media storage. Other forms: resource
(user).
P2PSIP Overlay Identifier: Information that identifies a specific
P2PSIP Overlay. All the P2PSIP Peers in a particular P2PSIP
Overlay have the same P2PSIP Overlay Identifier. This is may be
scoped to a name within the DNS, but other scopes may apply,
particularly in ad-hoc environments. Short forms: overlay name,
overlay identifier, overlay ID.
P2PSIP Peer-ID: Information that uniquely identifies each P2PSIP
Peer within a given P2PSIP Overlay. This value is not human-
friendly -- in a DHT approach, this is a numeric value in the hash
space. These Peer-IDs are completely independent of the
identifier of any user of a user agent associated with a peer.
Other forms: Node-ID
P2PSIP Resource (User) Name: A distinguished, human readable name
that identifies a specific P2PSIP Resource or User within a given
P2PSIP Overlay. This is presumed to be a URI scoped to the P2PSIP
Overlay Identifier. This is presumably the same or very similar
to a SIP Address of Record, or AOR. Other forms: overlay resource
(user) name, P2PSIP AOR.
P2PSIP Resource-ID: A non-human friendly value that uniquely
determines which P2PSIP Peer is responsible for storing
information about this resource (user). In a DHT approach, this
is a numeric value in the hash space resulting from hashing the
P2PSIP Resource Name. Since Resource-ID is in the same space as
the P2PSIP Peer-ID, it allows for a mapping between the values,
Willis, et al. Expires April 15, 2007 [Page 7]
Internet-Draft P2PSIP Concepts and Terminology October 2006
used to map a P2PSIP Resource to the P2PSIP Peer that stores it.
Other forms: P2PSIP User-ID.
P2PSIP Resource (User) Record: A block of data, stored using the
data mechanism of the P2PSIP Overlay, that includes information
relevant to a specific resource. We presume that there may be
multiple types of resource records. Some may describe routes to a
client at which the user is presumed reachable (a "user routing
record", like a SIP "Contact:"). Others might store presence
information. The types, usages, and formats of user records are a
question for future study.
P2PSIP User Agent: A SIP user agent that is coupled with or
incorporates a P2PSIP Peer or P2PSIP Client, such that the peer or
client can assist the UA with registration (storage of a route to
users of the UA) and/or routing of requests using the P2PSIP
Overlay. A P2PSIP User Agent differs from a conventional SIP user
agent in that it is coupled directly to a P2PSIP Peer or P2PSIP
Client, and can therefore directly interact with a P2PSIP Overlay,
which a conventional SIP UA cannot do. P2PSIP User Agents do not
themselves have a distinguished name or identifier, although the
P2PSIP User associated with it may, and if it is associated with a
P2PSIP Peer, that peer may as well. Other forms: overlay UA,
P2PSIP UA.
P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay
peers to share information and organize the P2PSIP Overlay
Network. Short form: peer protocol.
P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients
and the P2PSIP Peer they use to store or retrieve information from
the P2P Overlay. This is a functional subset of the P2P Peer
Protocol, but may differ in syntax and protocol implementation
(i.e., may not be syntactically related). Note that the precise
relationship between the P2PSIP Peer Protocol and the P2PSIP
Client Protocol (the same? subset?) remains an open question and
is expected to be a principle topic of the detailed design work.
This protocol may not exist (it may simply be conventional SIP) in
some designs. Short form: client protocol.
P2PSIP Overlay Neighbors: The set of P2PSIP Peers that either a
P2PSIP Peer or P2PSIP Client know of directly and can reach
without further lookups. Short form: neighbor
P2PSIP Bootstrap Server: A network node used by P2PSIP Peers or
Clients who are attempting to locate an entry into the P2PSIP
Overlay Network. It may return an entry point (address of a Peer)
to the P2PSIP Overlay or act as one itself. This should be a
Willis, et al. Expires April 15, 2007 [Page 8]
Internet-Draft P2PSIP Concepts and Terminology October 2006
quasi-stable and well known host, located using a configuration or
discovered via , DNS, broadcast, or other mechanism. This is a
logical role, meaning it can be implemented as a P2PSIP Peer, as a
standalone server, etc., but not every peer must provide this
functionality. Example: a P2PSIP Peer that reboots and has no
knowledge of other peers uses a P2PSIP Bootstrap Server to find
other peers in the P2P Overlay Network and establish P2PSIP Peer
Insertion. Other forms: bootstrap peer or node.
P2PSIP Resource (User) Record: A P2PSIP overlay user record that
provides a routing vector that points to a location where the
resource can presumably be reached. This is analogous to the
combination of a SIP [3] "Contact:" and a "Path:" [6]. The P2PSIP
equivalent of a SIP registration process would be the insertion of
an P2PSIP Resource Record into the overlay. Other forms: resource
(user) record, resource (user) registration.
P2PSIP Peer Insertion: The act of inserting a P2PSIP Overlay Peer
into the current routing structure (presumably a distributed
database or hash table) of a P2PSIP Overlay. For example, the
routing structure map the peer's IP address or DNS name to the
peer's P2PSIP Peer-ID. During insertion, the peer discovers its
P2PSIP Overlay neighbors. Following insertion, the peer will be
able to store user records (such as routing information), query
other peers for user records, and pass requests to route messages
to other peers. Other forms: peer or node registration, peer or
node join.
P2PSIP Resource (User) Record Insertion: The act of inserting a
record for a P2PSIP Resource (User) into the data maintained by
the P2PSIP Peers. Following insertion, the data stored at one or
more peers will contain a record (such as a P2PSIP Resource
Routing Record), keyed at least in part by a P2PSIP User
Identifier. Other forms: Resource registration, User record
insertion.
P2PSIP Peer Enrollment: The initial one-time process a P2PSIP Peer
follows to obtain an identifier and credentials, if any, within a
P2PSIP Overlay. This is not performed each time the peer comes
online (contrast to P2PSIP Peer Insertion above), but only the
first time they do so, or following a loss of identifier or
credentials by the peer. Other forms: node enrollment, peer
enrollment.
P2PSIP Resource (User) Enrollment: The initial one-time process a
P2PSIP Resource follows to obtain a unique identifier within a
P2PSIP Overlay. This is not performed each time the resource
comes online, only the first time they do so, or following a loss
Willis, et al. Expires April 15, 2007 [Page 9]
Internet-Draft P2PSIP Concepts and Terminology October 2006
of identifier or credentials by the client (contrast to P2PSIP
Resource Record Insertion). Other forms: user enrollment.
3. Discussion
3.1. What Kinds of P2PSIP Peers and Clients Might Exist?
In general, P2PSIP nodes might have the same sorts of duties/logical
roles as traditional client-server SIP nodes. This includes but is
not limited to:
1. User Agent: a phone, voice mail server, bridge, or other device
that initiates or terminates session requests. This could be a
P2PSIP Client (only performs GET/PUT of data) or P2PSIP Peer
(participates in storing data as well)
2. Media relay: a P2PSIP peer or client capable of relaying RTP
sessions, as described in [14]
3. Gateway: a P2PSIP peer or client that converts from P2PSIP to
some other protocol, such as PSTN (Public Switched Telephone
Network).
4. Redirector: a P2PSIP peer or client that accepts SIP requests
(such as INVITE) for a P2PSIP resource identifier, searches the
overlay, and returns the route to the resource in a 302 or 305
response.
5. Proxy: a P2PSIP peer or client that accepts SIP requests (such as
INVITE) for a P2PSIP resource identifier, searches the overlay,
and forwards (proxies) the request to that resource.
6. Registrar: A peer or client that processes SIP REGISTER requests
from non-P2P aware entities, either storing or retrieving the
contact information to/from the routing data of the P2PSIP
Overlay.
3.2. Reference Model
The following diagram depicts a reference or "boxes and arrows" model
showing several of the above peer and client types, along with a
conventional SIP user agent.
Willis, et al. Expires April 15, 2007 [Page 10]
Internet-Draft P2PSIP Concepts and Terminology October 2006
--->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # Client Protocol
| E | A | F | +---------+ # GET/PUT
| | T | | # |
+------+ N +------+ # |
# A # |
NATNATNATNAT # |
# # | \__/
NATNATNATNAT +-------+ v / \
# N | |=====/ UA \
+------+ A P2PSIP Overlay | Proxy | /Client\
| | T | Peer | |___C__|
| UA | N Route Data | Q |
| Peer | A +-------+
| D | T P2PSIP Peer Protocol #
| | N #
+------+ A #
# T #
# N +-------+ +-------+ #
# A | | | | #
#########T####| Proxy |########| Redir |#######
| Peer | | Peer |
| P | | R |
+-------+ +-------+
\__/
/\
/ \
/ UA \
/______\
SIP UA A
Figure: P2PSIP Overlay Reference Model
Here, the large perimeter depicted by "#" represents a stylized view
of the P2PSIP Overlay and its associated routing data (the actual
connections could be a mesh, ring, or some other structure). Around
the periphery of the P2PSIP Overlay rectangle, we have a number of
P2PSIP Peers -- a PSTN gateway peer "G", three user-agent peers "D",
"E" and "F", two proxy peers "P" and "Q", and a redirector peer "R".
Note that because these are all P2PSIP Peers, each is responsible for
helping store some information of the P2PSIP Overlay.
Willis, et al. Expires April 15, 2007 [Page 11]
Internet-Draft P2PSIP Concepts and Terminology October 2006
To the left, two of the peers ("D" and "E") are behind network
address translators. These peers are included in the P2PSIP overlay
and thus participate in storing information, despite being behind the
NATs.
Below the P2PSIP Overlay, we have a conventional SIP UA "A" which is
not part of the P2PSIP Overlay, either directly as a peer or
indirectly as a client. It speaks neither the P2PSIP Peer nor P2PSIP
Client protocols. Instead, it uses pure (unmodified/extended) SIP to
interact with with the P2PSIP Overlay.
On the right side, we have a P2PSIP UA client "C", which uses the
P2PSIP Client Protocol depicted by "=" to communicate with Proxy Peer
"Q". The P2PSIP Client protocol only allows for gets and puts to the
overlay. Therefore, "C" does NOT participate directly in/store
information in the overlay. In a solution where the P2PSIP Client
Protocol is SIP, such as is proposed in [7], there is no difference
between UA client "C" and standard SIP UAs "A", and the special
P2PSIP client protocol is not needed.
Note that in some scenarios, the P2PSIP Peers involved in the overlay
might use a keepalive mechanism to ensure that messages to neighbors
can pass through NATs. Presumably, these messages will be in the
form of the P2PSIP Peer protocol.
Both the "Proxy Peers" and "Redirect Peers" can serve as adapters
between ordinary SIP devices and the the P2PSIP Overlay. Each
accepts standard SIP requests and resolves the next-hop by using the
P2PSIP overlay Peer Protocol to interact with the routing knowledge
of the P2PSIP Overlay, then processes the SIP requests as appropriate
(proxying or redirecting towards the next-hop). Note that proxy
operation is bidirectional - the proxy may be forwarding a request
from an ordinary SIP device to the P2PSIP overlay, or from the P2PSIP
overlay to an ordinary SIP device.
The Gateway Peer provides a similar sort of adaptation to and from
the public switched telephone network (PSTN). However, there is a
subtle distinction. The gateway function itself can be viewed as a
"user" or within the P2PSIP overlay, and is addressed using a P2PSIP
Overlay User Identifier. This gateway functionality could also be
located in a P2PSIP Client, or even in a traditional SIP UA that is
reached via P2P (using a P2P proxy or redirector) or conventional SIP
mechanisms.
The functions of various types of peers (redirect, UA, proxy,
gateway) are logical roles. There is no reason a particular
implementation could not support one, several, or all of these
functions in one entity. For clarity, we show each as a fully
Willis, et al. Expires April 15, 2007 [Page 12]
Internet-Draft P2PSIP Concepts and Terminology October 2006
distinct entity.
3.3. Example Signalling Message Flows
The following show very high level examples of message flows for
various interactions of devices within the reference model. In each
case, we DO NOT show the flow of messages exchanged between P2PSIP
peers to lookup information, since the exact nature of these flows
and even who the messages would flow between will be a function of
the particular data structure and protocol that is selected. We do
however indicate when the lookups occur. This leads to the somewhat
odd situation of a diagram having numbered flows to indicate
ordering, but some numbers missing. This is regrettable, but we
aren't sure how else to do this since we cannot currently know what
the lookup flows will look like in the final P2PSIP Peer protocol.
In a solution where the P2PSIP Client Protocol is some protocol other
than SIP, all of the following example flows are needed. In a design
where unmodified SIP is used for the P2PSIP Client, Section
Section 3.3.2 is not needed.
3.3.1. P2PSIP Peer contacts P2PSIP Peer
The following diagram shows P2PSIP UA Peer "E" placing a call to
P2PSIP UA Peer "F". 1) UA Peer "E" first uses the P2PSIP Peer
protocol to communicate among the peers and obtain the location of
"F" (flow not shown as this will depend on the protocol designed). 2)
"E" then establishes a session directly with "F" using a conventional
SIP INVITE/200 OK mechanism.
Willis, et al. Expires April 15, 2007 [Page 13]
Internet-Draft P2PSIP Concepts and Terminology October 2006
2) SIP INVITE/200 OK
/----------------\
/ \ --->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # Client Protocol
| E | A | F | +---------+ # GET/PUT
| | T | | # |
+------+ N +------+ # |
# A # |
NATNATNATNAT # |
# # | \__/
NATNATNATNAT +-------+ v / \
# N | |=====/ UA \
+------+ A P2PSIP Overlay | Proxy | /Client\
| | T | Peer | |___C__|
| UA | N Route Data | Q |
| Peer | A +-------+
| D | T P2PSIP Peer Protocol #
| | N #
+------+ A #
# T #
# N +-------+ +-------+ #
# A | | | | #
#########T####| Proxy |########| Redir |#######
| Peer | | Peer |
| P | | R |
+-------+ +-------+
Figure: P2PSIP Peer to Peer
3.3.2. P2PSIP Client contacts P2PSIP Peer
NOTE: In a design where unmodified SIP is used for the P2PSIP Client
protocol, this case does not exist/is not needed. Sections
Section 3.3.3 and Section 3.3.4, covering conventional SIP access are
all that are required.
The following diagram shows P2PSIP UA Client "C" placing a call to
P2PSIP UA Peer "F". 1) "C" first sends a GET request using the P2P
Client GET/PUT protocol to a Peer in the overlay, in this case "Q".
2) Some messages are exchanged among client "C" and the peers in the
overlay to perform the lookup (flow not shown as this will depend on
the protocol designed), and the address of "F" is passed back to "C"
using the P2PSIP Client protocol. 3) "C" then establishes a session
directly with "F" using a conventional SIP INVITE/200 OK mechanism.
Willis, et al. Expires April 15, 2007 [Page 14]
Internet-Draft P2PSIP Concepts and Terminology October 2006
3) SIP INVITE/200 OK
/---------------------------------------------+
/ |
/ --->PSTN |
+------+ N +------+ +---------+ / |
| | A | | | Gateway |-/ |
| UA |####T#####| UA |#####| Peer |######## |
| Peer | N | Peer | | G | # 1) Client Protocol |
| E | A | F | +---------+ # GET |
| | T | | # | |
+------+ N +------+ # | |
# A # | /
NATNATNATNAT # | /
# # | \__/ /
NATNATNATNAT +-------+ v / \ /
# N | |=====/ UA \ /
+------+ A P2PSIP Overlay | Proxy | /Client\/
| | T | Peer | |___C__|
| UA | N Route Data | Q |
| Peer | A +-------+
| D | T P2PSIP Peer Protocol #
| | N #
+------+ A #
# T #
# N +-------+ +-------+ #
# A | | | | #
#########T####| Proxy |########| Redir |#######
| Peer | | Peer |
| P | | R |
+-------+ +-------+
Figure: P2PSIP Client to Peer
3.3.3. Conventional SIP Device using a Proxy Peer
The following diagram shows a conventional SIP device, SIP UA "A",
establishing a dialog with UA Peer "F". 1) "A" sends a conventional
SIP INVITE to Proxy Peer "P". 2) Proxy Peer "P" uses the P2PSIP
Overlay Protocol to locate the target (flow not shown as this will
depend on the protocol designed), in this case UA Peer "F". 3) "P"
forwards the SIP request to the destination and proxies the response
back to "A".
Willis, et al. Expires April 15, 2007 [Page 15]
Internet-Draft P2PSIP Concepts and Terminology October 2006
--->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # Client Protocol
| E | A | F | +---------+ # GET/PUT
| | T | | # |
+------+ N +------+ # |
# A | # |
NATNATNATNAT | # |
# | # | \__/
NATNATNATNAT | +-------+ v / \
# N | | |=====/ UA \
+------+ A P2PSIP Overlay | Proxy | /Client\
| | T | | Peer | |___C__|
| UA | N | | Q |
| Peer | A | +-------+
| D | T |3) SIP INVITE/200 OK #
| | N | #
+------+ A | #
# T | #
# N +-------+ +-------+ #
# A | | | | #
#########T####| Proxy |########| Redir |#######
| Peer | | Peer |
| P | | R |
+-------+ +-------+
/
/
\__/ / 1) SIP INVITE/200 OK
/\ /
/ \/
/ UA \
/______\
SIP UA A
Figure: Proxied SIP dialog from SIP UA to P2PSIP UA through Peer
Proxy
3.3.4. Conventional SIP Device Using a Redirect Peer
The following diagram shows a second conventional SIP device, SIP UA
"A" establishing a dialog with a P2PSIP Client UA "C". 1) "A" sends a
conventional SIP INVITE to the Redirect Peer "R". 2) Redirect Peer
"R" uses the P2PSIP Peer Protocol to locate the target (flow not
shown as this will depend on the protocol designed), in this case
P2PSIP Client UA "C". In contrast to the Proxy peer above, "R"
Willis, et al. Expires April 15, 2007 [Page 16]
Internet-Draft P2PSIP Concepts and Terminology October 2006
returns the result of the lookup to "A" as a 302 Moved message, with
a contact of "C" (the conventional SIP 302 mechanism), rather than
proxying the request for "A". 3) The conventional SIP UA "A" device
can then establish the dialog directly with UA Client "C", even
though "A" has no awareness of the P2PSIP Overlay, or of the P2PSIP
Client Protocol.
--->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # Client Protocol
| E | A | F | +---------+ # GET/PUT
| | T | | # |
+------+ N +------+ # |
# A # |
NATNATNATNAT # |
# # | \__/
NATNATNATNAT +-------+ v / \
# N | |=====/ UA \
+------+ A P2PSIP Overlay | Proxy | /Client\
| | T | Peer | |___C__|
| UA | N Route Data | Q | |
| Peer | A +-------+ |
| D | T P2PSIP Peer Protocol # |
| | N # 3) SIP INVITE
+------+ A # /200 OK
# T # |
# N +-------+ +-------+ # |
# A | | | | # |
#########T####| Proxy |########| Redir |####### |
| Peer | | Peer | /
| P | | R | /
+-------+ +-------+ /
\ /
\ /
1) SIP INVITE \ \__/ /
/302 Moved \ /\ /
\ / \ /
\/ UA \/
/______\
SIP UA A
Figure: Redirect from P2PSIP Overlay
Willis, et al. Expires April 15, 2007 [Page 17]
Internet-Draft P2PSIP Concepts and Terminology October 2006
3.4. Conceptual Outline of Operations
3.4.1. Enrolling and Inserting an P2PSIP Peer
Peers are the full-function "routing and storage" nodes of a P2PSIP
Overlay. When a new peer is first created, it must enroll in the
P2PSIP Overlay. We currently have no defined mechanism for this
(should this group define one?), but we know that once the process is
complete, the new peer will have at least a P2PSIP Peer-ID and
optionally a set of credentials.
After enrollment, each time the peer connects to the overlay, it must
insert itself. We don't have a defined protocol mechanism for this,
and assume we need one. Presumably the inserting peer connects to
one or more existing peers (possibly with the aid of a bootstrap
server) presents its credentials, and after exchanging some messages
with other P2PSIP Peers, ends up connected to the overlay. It will
then have some knowledge of neighbors (successor, precursor, finger
tables, or whatever the distribution mechanism defines) and is able
to store data on behalf of and route requests to other nodes in the
P2PSIP overlay.
3.4.2. More on The Difference Between a Peer, Client, and User Agent
P2PSIP Peers directly interact with and contain the routing and
storage fabric of the overlay. P2PSIP Clients simply use the routing
and storage facilities provided by the peers to get/put information.
The peers speak the P2PSIP Peer Protocol, which presumably has a full
range of expressivity for the routing and storage facilities of the
overlay. Clients speak the P2PSIP Client protocol, which is
presumably a subset of the peer protocol, and is limited to storage
insertion (put), storage retrieval (get), and message routing (send).
Some designs do not require a separate client protocol.
Some peers and some clients may be coupled to SIP user agents, making
them P2PSIP User Agents capable of both sending and receiving
conventional SIP messages (as per a SIP UA) using conventional SIP
resolution procedures and of using the resolution facilities provided
by the overlay.
The mix and configuration of peers, clients, and P2PSIP UAs is
expected to vary depending on the deployment scenario. For example,
an ad-hoc scenario might deploy nothing but P2PSIP Peers, each of
which is coupled to a P2PSIP User Agent, using a broadcast or
multicast bootstrap mechanism. Another common scenario, the "self
organizing proxy farm", might consist of P2PSIP Peers, each of which
is coupled to a SIP proxy/registrar function.
Willis, et al. Expires April 15, 2007 [Page 18]
Internet-Draft P2PSIP Concepts and Terminology October 2006
Some of the systems proposed that use SIP for the P2PSIP Client
protocol essentially remove that protocol from their design.
Standard SIP messages are sent to a proxy or redirect server which
speaks the P2PSIP server protocol, eliminating the need for another
protocol.
3.4.3. Enrolling a User and Inserting a P2PSIP User Agent
Clients and Peers are devices, the "end points" or "user agents" of a
P2PSIP Overlay. Users are the named entities that participate in a
P2PSIP overlay using a client.
To get started, users must be enrolled in the overlay. We do not
have a process or protocol for this, nor are we certain we need a
standardized mechanism. We presume that after enrollment, the user
has a distinguished name within the overlay (example:
sip:bob@example.com) and a set of credentials useful for
authenticating its usage of the distinguished name. One possible
mechanism for these credentials would be an x.509 certificate. It
might also be possible to use a PGP key, a password, or some other
mechanism. Presumably following enrollment, the user is also
equipped with the information needed to connect to the overlay, such
as the address of a bootstrap server. Whether this startup
information is delivered as a part of enrollment of through some
separate configuration process remains an open question, and it is
not clear it is within the scope of the proposed WG.
Once a user is enrolled, the user may exercise a P2PSIP User Agent to
insert into the P2PSIP Overlay. We currently have no protocol
mechanism for this, and need to define one. The P2PSIP UA exercises
the associated P2PSIP Peer or P2PSIP Client to execute the
"registration" function and insert a route for the user into the
P2PSIP overlay. This function is described as a "PUT" request, and
results in the storage of an authenticated route-set for the user in
the P2PSIP overlay, such that the terminus of the route is the URI of
the user at the P2PSIP UA. This is analogous to "registration" in a
classic SIP environment, and one mechanism proposed is in fact to use
the SIP REGISTER method. Presumably, the P2PSIP UA connects to a
peer or client and uses the user's credentials to authenticate a
route-set (Contact: plus Path:) to itself, and the peer or client
stores the route-set into the overlay, using a key derived from the
user's identity.
3.4.4. Bootstrapping
If a client or peer is just starting up and has no knowledge of how
to reach the other nodes of the overlay, it may exercise a bootstrap
server to find one. Presumably it discovers the bootstrap server by
Willis, et al. Expires April 15, 2007 [Page 19]
Internet-Draft P2PSIP Concepts and Terminology October 2006
some mechanism such as a DNS lookup, multicast, broadcast or
configuration, then queries the bootstrap server and receives an
address for a peer or set of peers that can be used to reach the
overlay. Ideally, these target peers will be selected from a
relatively large pool of peers that are currently online and
reachable.
After discovering the address of a peer, the behavior of the starting
node will vary depending on whether it is intending to be a peer or a
client. If it is intending to be a peer, it goes into the P2PSIP
Peer Insertion process, at the conclusion of which it is actively
participating in the target overlay as a peer and is capable of
routing requests and storing records on behalf of the P2PSIP overlay.
If it is intending to be a client, it does not bother with insertion,
but merely contacts the discovered peer in order to use the overlay.
In the typical case, the peer or client coming up is also a P2PSIP
User Agent with one or more associated P2PSIP Resource (User)
Identifiers. The next step then is to insert a P2PSIP Resource
Record (a Contact:) into the P2PSIP Overlay.
We may wish to have a mechanism in place where a particular bootstrap
server can send a redirect response, offloading a heavily loaded
server.
4. Questions
4.1. PP2PSIP Peer Protocol
This may or may not be SIP. What should it be? Alternatives include
SIP, a full IETF protocol based on OpenDHT, or something else. Do we
need to define a new protocol? Will implementors want to implement a
new protocol?
4.2. P2PSIP Client Protocol
This may or may not be SIP. What should it be? It defines only GET/
PUT operations, which could be done using SIP REGISTER transactions.
Essentially disappears if we do select SIP.
4.3. How To Find Media Relays?
This needs to be net-path efficient. Is this possible? Is it enough
just to construct a key with a "relay" identifier? What sorts of
access controls do we need on media relays?
Willis, et al. Expires April 15, 2007 [Page 20]
Internet-Draft P2PSIP Concepts and Terminology October 2006
4.4. How Do We Find Gateways?
This needs to be not only netpath efficient, but also embodies
elements of the TRIP and SPEERMINT problems.
4.5. Peer-Adjacency Through NATs
We assume that some or even many peers will be behind NATs, and
therefore reached through peer-to-peer routing. How do we keep alive
the NAT-crossing peer bindings? Is some variant of "outbound" [15]
usable?
4.6. Cryptotransparency
When forwarding requests, are the bodies of the requests visible to
peers? If so, this creates substantial security problems that the
deployers of conventional SIP have been willing to mostly ignore.
Can we make peers cryptotransparent (like HTTP proxies) when security
is requested?
4.7. Record Formats
Clearly we need user routing records stored into the P2PSIP overlay.
Do we need other sorts of record? If so, what? How do we
differentiate between or classify records? Do we end up with many
records per user per client, or do we aggregate the per-client or
per-user view using something like XML?
4.8. Peer and Client Enrollment Protocols
We know that we need to enroll peer and client nodes into a P2PSIP
Overlay. Do we define a protocol or process for this, assume it will
happen externally, or just provide an existence-proof argument?
4.9. Peer and User Credentials
We believe we need some sort of credentials for authenticating peers
and users of each P2PSIP Overlay. What should we use for these
credentials? Certificates? PGP keys? Passwords? If certificates,
should these be signed by a CA associated with the overlay, or can
self-signed certificates work in some or all cases? Do we need to
specify a standard credential format, or should we allow different
implementations to use different credential formats?
4.10. Bootstrapping
We know that sometimes peers or clients will start up without
knowledge of how to find a peer for insertion. Do we need to define
Willis, et al. Expires April 15, 2007 [Page 21]
Internet-Draft P2PSIP Concepts and Terminology October 2006
a bootstrap mechanism or mechanisms? Do we need to define supporting
protocols?
4.11. Credential Recovery
One reader suggested that we extend the definition of P2PSIP Peer
Enrollment to cover the case where a previously-inserted peer has
lost its credentials (through, perhaps, being moved to a different
host) and wishes to recover them without necessarily creating a new
P2PSIP Peer-ID. The editors are inclined to believe that this is an
operational issue, not a matter of definition, but would like to seek
a broader consensus before concluding the topic. A similar question
applies to user enrollment.
4.12. Overlapping Domains
If the P2PSIP Resource (User) Identifier is not scoped to a single
DNS domain, this would appear to allow nodes from two or more
apparent domains to share a single P2PSIP Overlay. What, if
anything, do we need to say about this mode of operation?
4.13. Hybrid Domains
It appears possible to have some hosts within a domain using
conventional SIP and some using P2PSIP. This potentially raises a
number of questions: 1) What should happen if we want to run a P2PSIP
overlay in an existing SIP domain? 2) Do the existing redir/proxy
servers need to be coupled with a peer layer? 3) When would an
overlay peer want to discover them as opposed to looking in the
overlay? 4) Is better not to run conventional SIP with P2PSIP? 5)
When conventional and P2PSIP are run together, shall the existing
redir servers keep their local databases or switch to the overlay
storage.
4.14. Admissions Control
What do we need to say about admissions control with respect to the
enrollment of peers and users? Do we need to discuss per-call
admissions control in a P2P environment?
4.15. Users versus Resources
This model presumes that all addressable elements, aka "users", are
unique. Are their other classes of resources that need some sort of
class-addressable identifier that does not refer to a unique user?
Willis, et al. Expires April 15, 2007 [Page 22]
Internet-Draft P2PSIP Concepts and Terminology October 2006
5. Security Considerations
Building a P2PSIP system has many security considerations, many of
which we have only begun to consider. We anticipate that the
protocol documents describing the actual protocols will deal more
thoroughly with security topics.
6. IANA Considerations
This document presently raises no IANA considerations.
7. Acknowledgements
This document draws heavily from the contributions of many
participants in the P2PSIP Mailing List but the authors are
especially grateful for the support of Spencer Dawkins, Cullen
Jennings, and Henning Schulzrinne, all of whom spent time on phone
calls about this document or provided text. Additionally, Spencer
provided a large portion of the ASCII art contained in this document.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[4] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
Willis, et al. Expires April 15, 2007 [Page 23]
Internet-Draft P2PSIP Concepts and Terminology October 2006
8.2. Informative References
[7] Bryan, D., "A P2P Approach to SIP Registration and Resource
Location", draft-bryan-sipping-p2p-02 (work in progress),
March 2006.
[8] Shim, E., "An Architecture for Peer-to-Peer Session Initiation
Protocol (P2P SIP)", draft-shim-sipping-p2p-arch-00 (work in
progress), March 2006.
[9] Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet
Communications", draft-johnston-sipping-p2p-ipcom-02 (work in
progress), March 2006.
[10] Matthews, P., "Industrial-Strength P2P SIP",
draft-matthews-sipping-p2p-industrial-strength-00 (work in
progress), February 2005.
[11] Risson, J. and T. Moors, "Survey of Research towards Robust
Peer-to-Peer Networks: Search Methods",
draft-irtf-p2prg-survey-search-00 (work in progress),
March 2006.
[12] Bryan, D., "Use Cases for Peer-to-Peer Session Initiation
Protocol (P2P SIP)", draft-bryan-sipping-p2p-usecases-00 (work
in progress), December 2005.
[13] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005.
[14] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
progress), October 2006.
[15] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-04 (work in progress), June 2006.
URIs
[16] <http://en.wikipedia.org/wiki/File_sharing>
Willis, et al. Expires April 15, 2007 [Page 24]
Internet-Draft P2PSIP Concepts and Terminology October 2006
Authors' Addresses
Dean Willis (editor)
Cisco Systems
3100 Independence Pkwy #311-164
Plano, Texas 75075
USA
Phone: unlisted
Email: dean.willis@softarmor.com
David A. Bryan
SIPeerior Technologies and William & Mary
3000 Easter Circle
Williamsburg, Virginia 23188
USA
Phone: unlisted
Email: bryan@ethernot.org
Philip Matthews
Avaya
100 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x224
Email: philip_matthews@magma.ca
Eunsoo Shim
Panasonic Digital Networking Laboratory
Two Research Way, 3rd Floor
Princeton, New Jersey 08540
USA
Phone: unlisted
Email: eunsoo@research.panasonic.com
Willis, et al. Expires April 15, 2007 [Page 25]
Internet-Draft P2PSIP Concepts and Terminology October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Willis, et al. Expires April 15, 2007 [Page 26]