(Proposed) P2PSIP Working Group                                 D. Bryan
Internet-Draft                               SIPeerior Technologies  and
Intended status: Informational               College of William and Mary
Expires: April 25, 2007                                      P. Matthews
                                                                   Avaya
                                                                 E. Shim
                                        Panasonic Digital Networking Lab
                                                               D. Willis
                                                           Cisco Systems
                                                        October 22, 2006


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

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 25, 2007.

Copyright Notice

   Copyright (C) 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



Bryan, et al.            Expires April 25, 2007                 [Page 1]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


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






































Bryan, et al.            Expires April 25, 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  . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  The P2PSIP protocols . . . . . . . . . . . . . . . . . . . 14
     3.4.  Example Signalling Message Flows . . . . . . . . . . . . . 15
       3.4.1.  P2PSIP Peer contacts P2PSIP Peer . . . . . . . . . . . 15
       3.4.2.  P2PSIP Client contacts P2PSIP Peer . . . . . . . . . . 16
       3.4.3.  Conventional SIP Device using a Proxy Peer . . . . . . 18
       3.4.4.  Conventional SIP Device Using a Redirect Peer  . . . . 19
     3.5.  Conceptual Outline of Operations . . . . . . . . . . . . . 21
       3.5.1.  Enrolling and Inserting an P2PSIP Peer . . . . . . . . 21
       3.5.2.  More on The Difference Between a Peer, Client, and
               User Agent . . . . . . . . . . . . . . . . . . . . . . 22
       3.5.3.  Enrolling a User and Inserting a P2PSIP User Agent . . 23
       3.5.4.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . 23

   4.  Questions  . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     4.1.  PP2PSIP Peer Protocol  . . . . . . . . . . . . . . . . . . 24
     4.2.  P2PSIP Client Protocol . . . . . . . . . . . . . . . . . . 25
     4.3.  How Do We Find Gateways? . . . . . . . . . . . . . . . . . 25
     4.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 25
     4.5.  Cryptotransparency . . . . . . . . . . . . . . . . . . . . 25
     4.6.  Record Formats . . . . . . . . . . . . . . . . . . . . . . 26
     4.7.  Peer and Client Enrollment Protocols . . . . . . . . . . . 26
     4.8.  Peer and User Credentials  . . . . . . . . . . . . . . . . 26
     4.9.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 26
     4.10. Credential Recovery  . . . . . . . . . . . . . . . . . . . 26
     4.11. Overlapping Domains  . . . . . . . . . . . . . . . . . . . 26
     4.12. Hybrid Domains . . . . . . . . . . . . . . . . . . . . . . 27
     4.13. Admissions Control . . . . . . . . . . . . . . . . . . . . 27
     4.14. Users versus Resources . . . . . . . . . . . . . . . . . . 27

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28




Bryan, et al.            Expires April 25, 2007                 [Page 3]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 31

















































Bryan, et al.            Expires April 25, 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 the 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 problem of locating the correspondent.  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

   This section defines a number of concepts that are key to understand
   the P2PSIP work.

      OPEN ISSUE: There is still much debate around the names attached
      to some of these concepts.  (For now, the recommendation is to
      concentrate on the concepts and not worry too much about the
      names).




Bryan, et al.            Expires April 25, 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 [18]) 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 suite of communications protocols related to the Session
      Initiation Protocol (SIP) [3] that extends SIP by using peer-to-
      peer techniques for resolving the targets of SIP requests.  The
      exact contents of this protocol suite are still under discussion,
      but is likely to include the P2PSIP Peer Protocol and the P2PSIP
      Client Protocol (see definitions below).

   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.

   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.  A notable
      property of P2PSIP Peers is that they can be fully functional
      peers while residing behind NATs.  Contrast this with some other



Bryan, et al.            Expires April 25, 2007                 [Page 6]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


      P2P systems which make a distinction between "peer" and "super-
      peer" (or "node" and "super-node") where the latter must have a
      public IP address.

   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 by having an association (details TBD) with one or
      more P2PSIP peers.  Using these peers, the client can request the
      insertion of routing information (put in a Contact), or request
      the retrieval of routing information (get a Contact).  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 entity (e.g., user agent or proxy or
      ...).  A P2PSIP Client is a logical subset of a P2PSIP Peer;
      anything a P2PSIP Client can do, a P2PSIP Peer can do as well.
      Note that a P2PSIP Client is not necessarily a SIP UAC.

         OPEN ISSUE: The name for this concept is very much under
         debate.  It conflicts with the usage of this name in SIP, and
         it suggest that a peer should be called a "server".

   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.

         OPEN ISSUE: There is still a lot of uncertainty and debate
         around the difference, if any, between a "resource" and a
         "user".  Even this document (which is the product of multiple
         authors) is inconsistent, sometimes treating them as more or
         less the same thing, and sometimes treating them as distinct
         concepts.

   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.

   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.
      (Note: This is often called a "Node-ID" in the P2P literature).




Bryan, et al.            Expires April 25, 2007                 [Page 7]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   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.

   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,
      used to map a P2PSIP Resource to the P2PSIP Peer that stores it.

   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
      P2PSIP Peer or Client at which the user or resource is presumed
      reachable (e.g., a "user routing record" like a SIP "Contact:").
      Others might store presence information.  The types, usages, and
      formats of the records are a question for future study.

   P2PSIP User Agent (UA):  A SIP user agent (UA) 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.

   P2PSIP Peer Protocol:  The protocol spoken between P2PSIP Overlay
      peers to share information and organize the P2PSIP Overlay
      Network.

   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



Bryan, et al.            Expires April 25, 2007                 [Page 8]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


      some designs.

   P2PSIP Neighbors:  The set of P2PSIP Peers that either a P2PSIP Peer
      or P2PSIP Client know of directly and can reach without further
      lookups.

   P2PSIP Bootstrap Peer:  A P2PSIP Peer in the P2PSIP Overlay which is
      willing to help new Peers join the Overlay or help new Clients
      find Peers to associate with.  A node that wishes to become a Peer
      or Client contacts a P2PSIP Bootstrap Peer and, with the help this
      Bootstrap Peer, gets the information it requires to become a fully
      functioning Peer or Client (the details of this process is still
      TBD).  The new Peer or Client may locate a P2PSIP Bootstrap Peer
      through multicast, though a P2PSIP Bootstrap Server, or through
      other means.

   P2PSIP Bootstrap Server:  A network node used by other nodes which
      are attempting to contact a P2PSIP Bootstrap Peer.  It may return
      the address of a P2PSIP Bootstrap Peer, or act as a proxy to relay
      messages to and from the Bootstrap Peer, or act as a Bootstrap
      Peer itself.  The P2PSIP Bootstrap Peer itself should be a fairly
      stable and well-known host.  To be useful, there must be an easy
      way to other nodes to locate it -- one way this might happen is
      for it to have a well-known DNS entry.  A P2PSIP Bootstrap Server
      may or may not also be a P2PSIP Peer or P2PSIP Client in one or
      more P2PSIP Overlays.

   P2PSIP Peer Insertion:  The act of inserting a P2PSIP 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.  During the insertion process, the overlay may
      challenge the peer to prove that it is really allowed to insert
      itself into the overlay.  (Note: In the P2P literature, this
      operation is often called "joining" or "registering" with the
      overlay).

         OPEN ISSUE: Some people are proposing that the name for this
         concept should be "P2PSIP Peer Admission" to better capture the
         fact that the Overlay can reject the peer if it does not have
         the correct credentials.






Bryan, et al.            Expires April 25, 2007                 [Page 9]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   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.

   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.

   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
      of identifier or credentials by the client (contrast to P2PSIP
      Resource Record Insertion).


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 media
       sessions.  For example, an RTP relay 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.





Bryan, et al.            Expires April 25, 2007                [Page 10]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   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.





































Bryan, et al.            Expires April 25, 2007                [Page 11]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


                                                  --->PSTN
     +------+    N     +------+     +---------+  /
     |      |    A     |      |     | Gateway |-/
     |  UA  |####T#####|  UA  |#####|   Peer  |########
     | Peer |    N     | Peer |     |    G    |       #   P2PSIP
     |  E   |    A     |  F   |     +---------+       #   Client
     |      |    T     |      |                       #   Protocol
     +------+    N     +------+                       #    |
        #        A                                    #    |
      NATNATNATNAT                                    #    |
        #                                             #    |   \__/
      NATNATNATNAT                              +-------+  v   /  \
        #        N                              |       |=====/ UA \
     +------+    A       P2PSIP Overlay         |       |    /Client\
     |      |    T                              | Peer  |    |___C__|
     |  UA  |    N        Route Data            |   Q   |
     | Peer |    A                              +-------+
     |  D   |    T  P2PSIP Peer Protocol              #
     |      |    N                                    #
     +------+    A                                    #
        #        T                                    #
        #        N    +-------+        +-------+      #
        #        A    |       |        |       |      #
        #########T####| Proxy |########| Redir |#######
                 N    | Peer  |        | Peer  |
                 A    |   P   |        |   R   |
                 T    +-------+        +-------+


                  \__/
                   /\
                  /  \
                 / 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.




Bryan, et al.            Expires April 25, 2007                [Page 12]


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 may no difference
   between UA client "C" and standard SIP UA "A".

   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
   distinct entity.



Bryan, et al.            Expires April 25, 2007                [Page 13]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


3.3.  The P2PSIP protocols

   This document describes two new protocols: the P2PSIP Peer Protocol
   and the P2PSIP Client Protocol.

   The P2PSIP Peer Protocol is spoken between peers.  The details of
   this protocol are TBD, but the protocol needs to support, at a
   minimum, the following actions:

   o  Enrolling a Peer in the Overlay

   o  Inserting a P2PSIP Peer into the Overlay

   o  Enrolling a Resource or User in the Overlay

   o  Inserting a Resource or User into the Overlay

   o  Retrieve information about a Resource or User from the Overlay

   The P2PSIP Client Protocol is spoken between a Client and a Peer.  It
   is used by the Client to request service from the P2PSIP Overlay.
   This protocol is logically a subset of the Peer protocol, in that the
   actions that it supports are a strict subset of the actions supported
   by the Peer Protocol.  These actions are:

   o  Enrolling a Resource or User in the Overlay

   o  Inserting a Resource or User into the Overlay

   o  Retrieve information about a Resource or User from the Overlay

   The details of the Client Protocol are also TBD.  Some people have
   proposed that the Client Protocol could be SIP.

   Finally, it should be re-iterated that the Client Protocol is a
   strict subset of the Peer Protocol (at least logically, the two may
   differ syntactically).  This has two consequences:

   o  A peer can do anything a client can do.  In particular, it is
      quite possible to establish a SIP session between two peers.

   o  It is possible to have a P2PSIP Overlay that consists of just
      peers.  However, it is NOT possible to have a P2PSIP Overlay that
      consists of just clients, since a client can only connect to a
      peer.






Bryan, et al.            Expires April 25, 2007                [Page 14]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


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

   As the working group makes various design decisions, the authors will
   update this document with more details on the various message flows.

   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.4.2 is not needed.

3.4.1.  P2PSIP Peer contacts P2PSIP Peer

   The following diagram shows P2PSIP UA Peer "E" placing a call to a
   user which is currently using the SIP UA on peer "F".  The steps in
   this operation are:

   1.  UA Peer "E" first uses the P2PSIP Peer Protocol to communicate
       among the peers and obtain the location of the user.  As a result
       of this operation, it is determined that the user is currently
       using the SIP UA on peer "F".  (The flow is 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.



















Bryan, et al.            Expires April 25, 2007                [Page 15]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


           SIP INVITE/200 OK
          /----------------\
         /                  \                     --->PSTN
     +------+    N     +------+     +---------+  /
     |      |    A     |      |     | Gateway |-/
     |  UA  |####T#####|  UA  |#####|   Peer  |########
     | Peer |    N     | Peer |     |    G    |       #   P2PSIP
     |  E   |    A     |  F   |     +---------+       #   Client
     |      |    T     |      |                       #   Protocol
     +------+    N     +------+                       #    |
        #        A                                    #    |
      NATNATNATNAT                                    #    |
        #                                             #    |   \__/
      NATNATNATNAT                              +-------+  v   /  \
        #        N                              |       |=====/ UA \
     +------+    A       P2PSIP Overlay         |       |    /Client\
     |      |    T                              | Peer  |    |___C__|
     |  UA  |    N        Route Data            |   Q   |
     | Peer |    A                              +-------+
     |  D   |    T  P2PSIP Peer Protocol              #
     |      |    N                                    #
     +------+    A                                    #
        #        T                                    #
        #        N    +-------+        +-------+      #
        #        A    |       |        |       |      #
        #########T####| Proxy |########| Redir |#######
                 N    | Peer  |        | Peer  |
                 A    |   P   |        |   R   |
                 T    +-------+        +-------+


   Figure: P2PSIP Peer to Peer

3.4.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.4.3 and Section 3.4.4, covering conventional SIP access are
   all that are required.

   The following diagram shows P2PSIP UA Client "C" placing a call to a
   user which is currently using the SIP UA on Peer "F".  The steps are:

   1.  "C" first sends a request to peer "Q" for the location of the
       user it wishes to contact.  This request is sent using the P2PSIP
       Client Protocol.





Bryan, et al.            Expires April 25, 2007                [Page 16]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   2.  Some messages are exchanged among peer "Q" and other peers in the
       overlay using the P2PSIP Peer Protocol to perform the lookup.
       The details of this operation are not shown as this will depend
       on the protocol designed.

   3.  Peer "Q" returns a response to Client "C" (using the P2PSIP
       Client Protocol) saying that the user is currently using the SIP
       UA on Peer "F".

   4.  "C" then establishes a session directly with "F" using a
       conventional SIP INVITE/200 OK mechanism.



                                     SIP INVITE/200 OK
                             /----------------------------------------+
                            /                                         |
                           /                      --->PSTN            |
     +------+    N     +------+     +---------+  /                    |
     |      |    A     |      |     | Gateway |-/                     |
     |  UA  |####T#####|  UA  |#####|   Peer  |########               |
     | Peer |    N     | Peer |     |    G    |       #   P2PSIP      |
     |  E   |    A     |  F   |     +---------+       #   Client      |
     |      |    T     |      |                       #   Protocol    |
     +------+    N     +------+                       #    |          |
        #        A                                    #    |          |
      NATNATNATNAT                                    #    |          |
        #                                             #    |   \__/   |
      NATNATNATNAT                              +-------+  v   /  \   |
        #        N                              |       |=====/ UA \  /
     +------+    A       P2PSIP Overlay         |       |    /Client\/
     |      |    T                              | Peer  |    |___C__|
     |  UA  |    N        Route Data            |   Q   |
     | Peer |    A                              +-------+
     |  D   |    T  P2PSIP Peer Protocol              #
     |      |    N                                    #
     +------+    A                                    #
        #        T                                    #
        #        N    +-------+        +-------+      #
        #        A    |       |        |       |      #
        #########T####| Proxy |########| Redir |#######
                 N    | Peer  |        | Peer  |
                 A    |   P   |        |   R   |
                 T    +-------+        +-------+


   Figure: P2PSIP Client to Peer




Bryan, et al.            Expires April 25, 2007                [Page 17]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


3.4.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".  The steps in this example
   are:

   1.  "A" sends a conventional SIP INVITE to Proxy Peer "P".

   2.  Proxy Peer "P" uses the P2PSIP Overlay Protocol to locate the
       target.  (The flow is 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".





































Bryan, et al.            Expires April 25, 2007                [Page 18]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


                                                  --->PSTN
     +------+    N     +------+     +---------+  /
     |      |    A     |      |     | Gateway |-/
     |  UA  |####T#####|  UA  |#####|   Peer  |########
     | Peer |    N     | Peer |     |    G    |       #   P2PSIP
     |  E   |    A     |  F   |     +---------+       #   Client
     |      |    T     |      |                       #   Protocol
     +------+    N     +------+                       #    |
        #        A        |                           #    |
      NATNATNATNAT        |                           #    |
        #                 |                           #    |   \__/
      NATNATNATNAT        |                     +-------+  v   /  \
        #        N        |                     |       |=====/ UA \
     +------+    A       P2PSIP Overlay         |       |    /Client\
     |      |    T        |                     | Peer  |    |___C__|
     |  UA  |    N        |                     |   Q   |
     | Peer |    A        |                     +-------+
     |  D   |    T        | SIP INVITE/200 OK         #
     |      |    N        |                           #
     +------+    A        |                           #
        #        T        |                           #
        #        N    +-------+        +-------+      #
        #        A    |       |        |       |      #
        #########T####| Proxy |########| Redir |#######
                 N    | Peer  |        | Peer  |
                 A    |   P   |        |   R   |
                 T    +-------+        +-------+
                          /
                         /
                  \__/  / SIP INVITE/200 OK
                   /\  /
                  /  \/
                 / UA \
                /______\
                SIP UA A


   Figure: Proxied SIP dialog from SIP UA to P2PSIP UA through Peer
   Proxy

3.4.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".





Bryan, et al.            Expires April 25, 2007                [Page 19]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   2.  Redirect Peer "R" uses the P2PSIP Peer Protocol to locate the
       target, in this case P2PSIP Client UA "C".  (The flow is not
       shown as this will depend on the protocol designed).  In contrast
       to the Proxy peer example above, "R" 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.








































Bryan, et al.            Expires April 25, 2007                [Page 20]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


                                                  --->PSTN
     +------+    N     +------+     +---------+  /
     |      |    A     |      |     | Gateway |-/
     |  UA  |####T#####|  UA  |#####|   Peer  |########
     | Peer |    N     | Peer |     |    G    |       #   P2PSIP
     |  E   |    A     |  F   |     +---------+       #   Client
     |      |    T     |      |                       #   Protocol
     +------+    N     +------+                       #    |
        #        A                                    #    |
      NATNATNATNAT                                    #    |
        #                                             #    |   \__/
      NATNATNATNAT                              +-------+  v   /  \
        #        N                              |       |=====/ UA \
     +------+    A       P2PSIP Overlay         |       |    /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 |#######          |
                 N    | Peer  |        | Peer  |                /
                 A    |   P   |        |   R   |               /
                 T    +-------+        +-------+              /
                                            \                /
                                             \              /
                              1) SIP INVITE   \    \__/    /
                                 /302 Moved    \    /\    /
                                                \  /  \  /
                                                 \/ UA \/
                                                 /______\
                                                 SIP UA A


   Figure: Redirect from P2PSIP Overlay

3.5.  Conceptual Outline of Operations

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



Bryan, et al.            Expires April 25, 2007                [Page 21]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   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 with
   a P2PSIP Bootstrap Peer (possibly with the aid of a P2PSIP 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.5.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 and put
   information.  The peers speak the P2PSIP Peer Protocol, which can
   express all the necessary routing and storage operations required for
   the overlay.  Clients speak the P2PSIP Client protocol, which is
   presumably a subset of the peer protocol, and is limited to storage
   insertion (put) and storage retrieval (get).  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.

   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 Peer Protocol, eliminating the need for another
   protocol.







Bryan, et al.            Expires April 25, 2007                [Page 22]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


3.5.3.  Enrolling a User and Inserting a P2PSIP User Agent

   P2PSIP Clients and Peers are the nodes of a P2PSIP Overlay.  Users
   are named entities that are associated with a Peer or 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 or 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.5.4.  Bootstrapping

   If a client or peer is just starting up and wants to join the
   overlay, then it first needs to find a P2PSIP Bootstrap Peer.
   Locating a P2PSIP Bootstrap Peer might be done in a number of ways:

   o  By remembering peers that were part of the overlay the last time
      the node was part of the overlay;

   o  Through a multicast discovery mechanism (e.g., something similar
      to the OSPF Hello protocol);




Bryan, et al.            Expires April 25, 2007                [Page 23]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   o  Through manual configuration; or

   o  By contacting a P2PSIP Bootstrap Server, and using it to locate a
      bootstrap peer.

   A client or peer might reasonably try each of the methods (and
   perhaps others) in some order or in parallel until it succeeds in
   finding a bootstrap peer.

   Like a bootstrap peer, there are many ways that a peer or client
   could locate a P2PSIP Bootstrap Server.  One likely method is for the
   peer to do a DNS lookup on a well-known URL.

   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.

   Ideally, the mechanism for locating a bootstrap peer and handling a
   new peer or client will attempt to distribute the load evenly across
   the various nodes involved.


4.  Questions

   This section lists some of the open issues that the proposed P2PSIP
   Working Group will have to address in the process of defining the
   Peer and Client protocols.

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?







Bryan, et al.            Expires April 25, 2007                [Page 24]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


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 Do We Find Gateways?

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

4.4.  NAT Traversal

   We assume that some or even many peers will be behind NATs.  NATs
   introduce two problems: a) how to learn the address and port that can
   be used to reach the peer or client, and b) how to set up the
   necessary permissions (or "filtering entries") in the NAT to allow
   inbound packets.  The IETF is currently defining the basic tools to
   solve these problems, namely the STUN/TURN/ICE suite of protocols
   [15] [14] [16] and the SIP-Outbound mechanism [17].  What the working
   group needs to do is work out how to use these tools to allow
   communication to peers behind NATs.  In particular:

   1.  How to send P2PSIP Peer Protocol or P2PSIP Client Protocol
       messages between two peers or clients which may be behind
       different NATs?

   2.  How to send SIP messages between two peers or clients which may
       be behind different NATs?

   3.  How to locate STUN servers and media relays, especially when
       these may be services offered by peers or clients?

   We presume that the question of how to send media between two peers
   or clients is already solved by the STUN/TURN/ICE suite of protocols,
   assuming that the necessary STUN servers and media relays can be
   located.

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






Bryan, et al.            Expires April 25, 2007                [Page 25]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


4.6.  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.7.  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.8.  Peer and User Credentials

   We believe that some form of credential will be used for
   authenticating peers and users in each P2PSIP Overlay.  It remains to
   be determined what the characteristics of the certificates will need
   to be, and the use of self-signed vs. CA-produced certificates
   remains an open issue.

4.9.  Bootstrapping

   We know that sometimes peers or clients will start up without
   knowledge of how to find a peer for insertion.  In this case, what is
   the mechanism that a new peer or client uses to find a P2PSIP
   Bootstrap peer?

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





Bryan, et al.            Expires April 25, 2007                [Page 26]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


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

   A related question is whether a UA could use the same AOR in
   conventional SIP and in P2PSIP?

4.13.  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.14.  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?


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



Bryan, et al.            Expires April 25, 2007                [Page 27]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   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.

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



Bryan, et al.            Expires April 25, 2007                [Page 28]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


         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]  Rosenberg, J., "Simple Traversal Underneath Network Address
         Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04
         (work in progress), July 2006.

   [16]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Network  Address Translator (NAT) Traversal for
         Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in
         progress), October 2006.

   [17]  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

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


Authors' Addresses

   David A. Bryan
   SIPeerior Technologies  and College of William and Mary
   3000 Easter Circle
   Williamsburg, Virginia  23188
   USA

   Phone: unlisted
   Email: bryan@ethernot.org









Bryan, et al.            Expires April 25, 2007                [Page 29]


Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   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 Lab
   Two Research Way, 3rd Floor
   Princeton, New Jersey  08540
   USA

   Phone: unlisted
   Email: eunsoo@research.panasonic.com


   Dean Willis
   Cisco Systems
   3100 Independence Pkwy #311-164
   Plano, Texas  75075
   USA

   Phone: unlisted
   Email: dean.willis@softarmor.com























Bryan, et al.            Expires April 25, 2007                [Page 30]


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





Bryan, et al.            Expires April 25, 2007                [Page 31]