[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 draft-ietf-p2psip-concepts

SIPPING Working Group                                     D. Willis, Ed.
Internet-Draft                                             Cisco Systems
Expires: December 9, 2006                                       D. Byran
                                         P2PSIP.org and William and Mary
                                          Department of Computer Science
                                                             P. Matthews
                                                                   Avaya
                                                                 E. Shim
                                            Panasonic Digital Networking
                                                              Laboratory
                                                            June 7, 2006


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

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 December 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines concepts and terminology for use of the Session



Willis, et al.          Expires December 9, 2006                [Page 1]


Internet-Draft       P2PSIP Concepts and Terminology           June 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 December 9, 2006                [Page 2]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4

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

   4.  Questions  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Definition of P2PSIP Overlay Peer Enrollment . . . . . . . 12
     4.2.  PP2PSIP Overlay Peer Protocol  . . . . . . . . . . . . . . 13
     4.3.  P2PSIP Overlay Client Protocol . . . . . . . . . . . . . . 13
     4.4.  Universal Routing: . . . . . . . . . . . . . . . . . . . . 13
     4.5.  How To Find Media Relays?  . . . . . . . . . . . . . . . . 13
     4.6.  How Do We Find Gateways? . . . . . . . . . . . . . . . . . 13
     4.7.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 13
     4.8.  Cryptotransparency . . . . . . . . . . . . . . . . . . . . 13
     4.9.  Record Formats . . . . . . . . . . . . . . . . . . . . . . 13
     4.10. Peer-Adjacency Through NATs  . . . . . . . . . . . . . . . 14
     4.11. Peer and Client Enrollment Protocols . . . . . . . . . . . 14
     4.12. Peer and User Credentials  . . . . . . . . . . . . . . . . 14
     4.13. Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 14

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18




Willis, et al.          Expires December 9, 2006                [Page 3]


Internet-Draft       P2PSIP Concepts and Terminology           June 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.

   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].


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



Willis, et al.          Expires December 9, 2006                [Page 4]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


      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>

   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.  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, request the retrieval of routing information
      (Contacts), 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



Willis, et al.          Expires December 9, 2006                [Page 5]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


      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.  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 a
      functional subset of the P2P Overlay Peer Protocol, but may differ
      in syntax and protocol implementation (i.e., may not be
      syntactically related).  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





Willis, et al.          Expires December 9, 2006                [Page 6]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   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
      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: boostrap 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] "Contact:" and a "Path:" [6].  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.






Willis, et al.          Expires December 9, 2006                [Page 7]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   P2PSIP Overlay Resource Enrollment: The initial one-time process a
      P2PSIP Overlay Resource (such as a 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: resource enrollment.


3.  Discussion

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]

   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
       INVITE 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.

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.









Willis, et al.          Expires December 9, 2006                [Page 8]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


                                            --->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





   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 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



Willis, et al.          Expires December 9, 2006                [Page 9]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   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.

3.3.  Conceptual Outline of Operations

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.

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 (get), storage retrieval (put), and message routing (send).

   Some peers and some clients may be coupled to P2PSIP Overlay User
   Agents making them capable of sending and receiving conventional SIP
   messages (as per a SIP UA) using conventional SIP resolution
   procedures and 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,



Willis, et al.          Expires December 9, 2006               [Page 10]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   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.

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

   Clients 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.

   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.

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 that 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



Willis, et al.          Expires December 9, 2006               [Page 11]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   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.

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.

   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.


4.  Questions

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



Willis, et al.          Expires December 9, 2006               [Page 12]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   split off the UA from the Peer and Client nodes.  What would a better
   definition look like?

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?

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.

4.4.  Universal Routing:

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

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?

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.

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?

4.8.  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.9.  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



Willis, et al.          Expires December 9, 2006               [Page 13]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   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.10.  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]
   usable?

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?

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?

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?


5.  Security Considerations

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


6.  IANA Considerations

   This document raises no IANA considerations.  Yet.


7.  Acknowledgements




Willis, et al.          Expires December 9, 2006               [Page 14]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   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.


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.

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.



Willis, et al.          Expires December 9, 2006               [Page 15]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


   [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
         of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in
         progress), March 2006.

   [14]  Jennings, C. and R. Mahy, "Managing Client Initiated
         Connections in the Session Initiation Protocol  (SIP)",
         draft-ietf-sip-outbound-03 (work in progress), March 2006.

URIs

   [16]  <http://en.wikipedia.org/wiki/File_sharing>
































Willis, et al.          Expires December 9, 2006               [Page 16]


Internet-Draft       P2PSIP Concepts and Terminology           June 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 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











Willis, et al.          Expires December 9, 2006               [Page 17]


Internet-Draft       P2PSIP Concepts and Terminology           June 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Willis, et al.          Expires December 9, 2006               [Page 18]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/