TOC 
SIPPING Working GroupD. Willis, Ed.
Internet-DraftCisco Systems
Intended status: ExperimentalD. Bryan
Expires: February 2, 2007P2PSIP.org and William and Mary
 Department of Computer
 Science
 P. Matthews
 Avaya
 E. Shim
 Panasonic Digital Networking
 Laboratory
 August 2006


Concepts and Terminology for Peer to Peer SIP
draft-willis-p2psip-concepts-01

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 February 2, 2007.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document defines concepts and terminology for use of the Session 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



Table of Contents

1.  Background

2.  Definitions

3.  Discussion
    3.1.  What Kinds of P2PSIP Overlay Peers and Clients Might Exist?
    3.2.  Reference Model
    3.3.  Conceptual Outline of Operations
        3.3.1.  Enrolling and Inserting an P2PSIP Overlay Peer
        3.3.2.  More on The Difference Between a Peer, Client, and User Agent
        3.3.3.  Enrolling a User and Inserting a P2PSIP Overlay User Agent
        3.3.4.  Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP Overlay Client UA
        3.3.5.  Bootstrapping

4.  Questions
    4.1.  Definition of P2PSIP Overlay Peer Enrollment
    4.2.  PP2PSIP Overlay Peer Protocol
    4.3.  P2PSIP Overlay Client Protocol
    4.4.  Universal Routing:
    4.5.  How To Find Media Relays?
    4.6.  How Do We Find Gateways?
    4.7.  NAT Traversal
    4.8.  Peer-Adjacency Through NATs
    4.9.  Cryptotransparency
    4.10.  Record Formats
    4.11.  Peer and Client Enrollment Protocols
    4.12.  Peer and User Credentials
    4.13.  Bootstrapping
    4.14.  Credential Recovery
    4.15.  Overlapping Domains
    4.16.  Hybrid Domains
    4.17.  Admissions Control
    4.18.  Users versus Resources

5.  Security Considerations

6.  IANA Considerations

7.  Acknowledgements

8.  References
    8.1.  Normative References
    8.2.  Informative References

§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

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] (Berners-Lee, T., Masinter, L., and M. McCahill, “Uniform Resource Locators (URL),” December 1994.).

The Session Initiation Protocol (SIP) [3] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.). SIP's location process [5] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) 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] (Bryan, D., “A P2P Approach to SIP Registration and Resource Location,” March 2006.) [8] (Shim, E., “An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP),” March 2006.) [9] (Sinnreich, H. and A. Johnston, “SIP, P2P, and Internet Communications,” March 2006.) [10] (Matthews, P., “Industrial-Strength P2P SIP,” February 2005.) have proposed using peer-to-peer (P2P) [11] (Risson, J. and T. Moors, “Survey of Research towards Robust Peer-to-Peer Networks: Search Methods,” March 2006.) approaches to solving the correspondent discovery problem.

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 [12] (Rescorla, E. and IAB, “Writing Protocol Models,” June 2005.).



 TOC 

2.  Definitions

Defined terms include:

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) 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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. Short form: overlay.
P2PSIP Overlay Identifier:
Information that identifies a specific P2PSIP Overlay. This is presumed in the general case to be scoped to a name within the DNS, but other scopes may apply, particularly in ad-hoc environments. Short forms: overlay identifier, overlay ID.
P2PSIP Overlay 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 Overlay Peer is presumed to have a unique identifier within the P2PSIP Overlay. Each P2PSIP Overlay Peer may or may not be coupled to one or more P2PSIP Overlay 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. Short forms: overlay peer, supernode, P2PSIP peer, peer.
P2PSIP Overlay Peer Key:
Information (perhaps a string, number or URI) that uniquely identifies each P2PSIP Overlay Peer within a given P2PSIP Overlay. These keys are completely independent of identifier of any user of a user agent coupled to a peer. Short forms: P2PSIP peer key, overlay peer key, peer key.
P2PSIP Overlay Client:
A node participating in a P2PSIP Overlay that provides neither routing nor route storage and retrieval functions to that P2PSIP Overlay. The P2PSIP Overlay 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 Overlay Peer, the client is presumed not to have a unique identifier or "key" within the overlay. A P2PSIP Overlay Client may be coupled to one or more P2PSIP Overlay User Agents. Short forms: overlay client, P2PSIP client, client.
P2PSIP Overlay User Agent:
A SIP user agent that is coupled to a P2PSIP Overlay Peer or P2PSIP Overlay 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 Overlay SUer Agent differs from a conventional SIP user agent in that it is coupled directly to a P2PSIP Overlay Peer or P2PSIP Overlay Client, and can therefore directly interact with a P2PSIP Overlay, which a conventional SIP UA cannot do. P2PSIP Overlay User Agents are presumed to have no distinguished name or identifier. Short forms: overlay UA, P2PSIP UA.
P2PSIP Overlay 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. Short forms: overlay user, P2PSIP user.
P2PSIP Overlay User Identifier:
A distinguished name that identifies a specific P2PSIP Overlay User within a given P2PSIP Overlay. This is presumed to be a URI scoped to the P2PSIP Overlay Identifier. This is presumably the same as a SIP Address of Record, or AOR Short forms: overlay user identifier, P2PSIP user identifier, P2PSIP user-ID, P2PSIP AOR.
P2PSIP Overlay User Record:
A block of data, stored in the data mechanism of the P2PSIP Overlay, that includes information relevant to a specific user. We presume that there may be multiple types of user 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 Overlay Peer Protocol:
The protocol spoken between P2P Overlay peers to share information and organize the P2P Overlay Network. Short form: peer protocol.
P2PSIP Overlay Client Protocol:
The protocol spoken between P2P Overlay Clients and the P2P Overlay Peer they use to place into or retrieve information from the P2P Overlay Network. This is presumably a functional subset of the P2P Overlay 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 Overlay Peer Protocol and the P2PSIP Overlay Client Protocol remains an open question and is expected to be a principle topic of the detailed design work. Short form: client protocol.
P2PSIP Overlay Neighbors:
The set of P2P Overlay Peers that either a P2P Overlay Peer or P2P Overlay Client know of directly and can reach without further lookups. Short form: neighbor
P2PSIP Overlay Bootstrap Server:
A network node used by P2PSIP Overlay Peers or Clients who are attempting to enter to locate an entry into the P2P 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 quasi-stable and well known host, located using a configuration or discovered via , DNS, broadcast, or other mechanism. Example: a P2PSIP Overlay Peer that reboots and has no knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to find other peers in the P2P Overlay Network and establish P2PSIP Overlay Peer Insertion. (Note: An overlay peer might or might not provide this functionality). Short forms: bootstrap server, boot server.
P2PSIP Overlay 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. In general, this routing structure maps the peer's P2PSIP Overlay Peer Key to the IP address or DNS name of the peer. 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. Short form: peer insertion.
P2PSIP Overlay User Record Insertion:
The act of inserting a record for a P2PSIP Overlay User into the data maintained by the P2PSIP Overlay Peers. Following insertion, the data stored at one or more peers will contain a record (such as a P2PSIP Overlay User Routing Record), keyed at least in part by a P2PSIP Overlay User Identifier. Short form: User record insertion.
P2PSIP Overlay User Routing Record:
A P2PSIP overlay user record that provides a routing vector that points to a P2PSIP UA where the user can presumably be reached. This is analogous to the combination of a SIP [3] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) "Contact:" and a "Path:" [6] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.). The P2PSIP equivalent of a SIP registration process would be the insertion of an overlay user routing record into the overlay. Short form: user route record or user route.
P2PSIP Overlay Peer Enrollment:
The initial one-time process a P2PSIP Overlay Peer follows to obtain an identifier and credentials, if any, within a P2PSIP Overlay. This is not performed each time the peer comes online, only the first time they do so, or following a loss of identifier or credentials by the peer. Short form: peer enrollment.
P2PSIP Overlay User Enrollment:
The initial one-time process a P2PSIP Overlay User 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 of identifier or credentials by the client. Short form: user enrollment.


 TOC 

3.  Discussion



 TOC 

3.1.  What Kinds of P2PSIP Overlay Peers and Clients Might Exist?

In general, P2PSIP nodes might have the same sorts of duties and profiles 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.
  2. Media relay: a peer or client capable of relaying RTP sessions, as described in [13] (Rosenberg, J., “Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN),” October 2006.)
  3. Gateway: a peer or client that converts from P2PSIP to some other protocol, such as PSTN.
  4. Redirector or Location Server: a peer or client that, given a SIP (or other SIP request) to a P2PSIP overlay resource identifier, returns the route to a resource in a 302 or 305 response.
  5. Registrar: A peer or client that processes SIP REGISTER requests, either storing or retrieving the contact information to/from the routing data of the P2PSIP Overlay.
  6. Proxy: A peer or client that accepts SIP requests, resolves the next hop or hops using the routing information of the P2PSIP Overlay, and passes the request on towards the next hop.


 TOC 

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 two conventional SIP user agents.





                                         --->PSTN
                             -----------/
                             | Gateway |
 ________          ----------|   Peer  |-------------
 |      |          |         |         |             |Client Protocol
 |  UA  |\         |         -----------             |  GET/PUT
 | Peer |\\|N|-----                                  |  |
 |______| \|A|                                       |  |   \__/
           |T| ----                                  |  v   /  \
     Peer Protocol/                                  |---- / UA \
                /           P2PSIP Overlay           |    /Client\
           |N|/                                      |    |______|
 -------- /|A|------          Route Data             |        ^
 |      |//|T| ____|___                              |        |
 |  UA  |/     |      |                              |        |
 | Peer |      |  UA  |                              |        |
 --------      | Peer |                              |        |
               |______|                              |        |
                   |                                 |        |SIP
     Peer Protocol |   ---------        ---------    |        |
                   |   |       |        |       |    |        |
                   ----| Proxy |----- --| Redir |----|        |
                       | Peer  |        | Peer  |    |        |
                       |       |        |       |             |
                       ---------        ----------            |
                      /                         \            /
                     /                           \          /
              \__/  / SIP                     SIP \  \__/  /
               /\  /                               \  /\  /
              /  \/                                 \/  \/
             / UA \                                 / UA \
            /______\                               /______\
            SIP UA A                               SIP UA B




Figure: Reference Model

Here, the large rectangle represents the P2PSIP Overlay and its associated routing data. Around the periphery of the P2PSIP Overlay rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN gateway, a user-agent, a proxy, and a redirector. To the left we have two UA peers are behind network address translator. On the right side, we have a P2PSIP Overlay "UA client", which uses the P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay. Below, we have conventional SIP UA "A", which has used SIP to interact with the Proxy Peer and establish a dialog with the UA peer, and SIP UA "B" which has been redirected by the Redirect Peer and set up a dialog with the UA Client. Note that the Proxy Peer and the UA Peer interact using the P2PSIP Overlay Peer Protocol, which is also presumably used on the keepalive links between the UA Peers and their neighbors.

Both the "Proxy Peer" and "Redir Peer" serve as adapters between ordinary SIP devices and the the P2PSIP Overlay. Each accepts 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).

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 Overlay Client, or even in a traditional SIP UA that is reached via P2P (using a P2P proxy or redirector) or conventional SIP mechanisms.



 TOC 

3.3.  Conceptual Outline of Operations



 TOC 

3.3.1.  Enrolling and Inserting an P2PSIP Overlay 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 (do we need one?), but we know that once the process is complete, the new peer will have at least a P2PSIP Overlay Peer Key and 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 and process 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 ends up connected to the overlay, with 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.



 TOC 

3.3.2.  More on The Difference Between a Peer, Client, and User Agent

P2PSIP Overlay Peers directly interact with and contain the routing and storage fabric of the overlay. P2PSIP Overlay Clients just use the routing and storage facilities provided by the peers. The peers speak the P2PSIP Overlay Peer Protocol, which presumably has a full range of expressivity for the routing and storage facilities of the overlay. Clients speak the P2PSIP Overlay 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 peers and some clients may be coupled to SIP user agents, making them P2PSIP Overlay 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 Overlay 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 Overlay Peers, each of which is coupled to a SIP proxy/registrar function.



 TOC 

3.3.3.  Enrolling a User and Inserting a P2PSIP Overlay User Agent

Clients and Peers are 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.

Once a user is enrolled, the user may exercise a P2PSIP Overlay User Agent to insert into the P2PSIP Overlay. We currently have no protocol for this, and need one. The P2PSIP UA exercises either a P2PSIP Overlay Peer or P2PSIP Overlay 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 might even be doable using 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.



 TOC 

3.3.4.  Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP Overlay Client UA

Assume we have two users, Alice and Bob, who have successfully enrolled and inserted themselves into a P2PSIP Overlay using clients. Alice wants to call Bob, and enters Bob's user identity (AOR) into her client. Alice's client does not have current knowledge of a route-set to Bob's client(s), so it needs to discover one. Alice's Client then does a GET operation on Bob's identity, using a previously-discovered peer, or using whatever procedures are needed (such as RFC 3263, a bootstrap server, etc.) to find a peer. Alice's client send the GET request to the selected peer.

The peer transforms the requested identity into a key, presumably by hashing it, and determines the peer ID at which the resource (a route-set) is most likely stored. The first peer then asks the second peer to return the desired resource. The second peer may return the desired resource, return a pointer to another peer, or pass the request recursively on to another peer for resolution. Eventually, some peer returns a resource containing a route-set for Bob, and the first peer returns this to Alice's client.

Alice then sends a SIP INVITE with a request-URI equal to Bob's user identity, and populated with a route from the returned route-set. Bob's client returns a SIP response, and we proceed with SIP as usual.



 TOC 

3.3.5.  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 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 Overlay 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 Overlay User Agent with one or more associated P2PSIP Overlay User Identifiers. The next step then is to insert a P2PSIP Overlay User Routing Record (a Contact:) into the P2PSIP Overlay.



 TOC 

4.  Questions



 TOC 

4.1.  Definition of P2PSIP Overlay Peer Enrollment

The definition for P2PSIP Overlay Peer Enrollment in the above section doesn't sound quite right. It predates a decision made to split off the UA from the Peer and Client nodes. What would a better definition look like?



 TOC 

4.2.  PP2PSIP Overlay Peer Protocol

This may or may not be SIP. What should it be? Alternatives include SIP, OpenDHT, or something else. Do we need to define a new protocol?



 TOC 

4.3.  P2PSIP Overlay 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.



 TOC 

4.4.  Universal Routing:

Do all P2PSIP Overlay Peers route requests? How about clients?



 TOC 

4.5.  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?



 TOC 

4.6.  How Do We Find Gateways?

This needs to be not only netpath efficient, but also embodies elements of the TRIP and SPEERMINT problems.



 TOC 

4.7.  NAT Traversal

Some peers or clients may be isolated by NATs from other peers or clients. How do we structure persistent keepalive connections to them? Is it enough to maintain links to left and right neighbors and construct dual routes?



 TOC 

4.8.  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" [14] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” June 2006.) usable?



 TOC 

4.9.  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?



 TOC 

4.10.  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?



 TOC 

4.11.  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?



 TOC 

4.12.  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?



 TOC 

4.13.  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 a bootstrap mechanism or mechanisms? Do we need to define supporting protocols?



 TOC 

4.14.  Credential Recovery

One reader suggested that we extend the definition of P2PSIP Overlay 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 Overlay Peer Key. 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.



 TOC 

4.15.  Overlapping Domains

If the P2PSIP Overlay 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?



 TOC 

4.16.  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 overlay SIP? 5) When conventional and P2PSIP are run together, shall the existing redir servers keep their local databases or switch to the overlay storage.



 TOC 

4.17.  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?



 TOC 

4.18.  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?



 TOC 

5.  Security Considerations

This specification probably has all sorts of security requirements that we just haven't gotten to.



 TOC 

6.  IANA Considerations

This document raises no IANA considerations. Yet.



 TOC 

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 Henning Schulzrinne and Cullen Jennings, both of whom spent many long pain-filled hours on the phone with us.



 TOC 

8.  References



 TOC 

8.1. Normative References

[1] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[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.


 TOC 

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] Rescorla, E. and IAB, “Writing Protocol Models,” RFC 4101, June 2005.
[13] Rosenberg, J., “Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN),” draft-ietf-behave-turn-02 (work in progress), October 2006.
[14] 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.


 TOC 

Authors' Addresses

  Dean Willis (editor)
  Cisco Systems
  3100 Independence Pkwy #311-164
  Plano, Texas 75075
  USA
Phone:  unlisted
Email:  dean.willis@softarmor.com
  
  David Bryan
  P2PSIP.org and William and Mary Department of Computer Science
  P.O. Box 6741
  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


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment