draft-willis-p2psip-concepts-02(1012).txt

IETF12号的文档

      overlay identifier, overlay ID.

   P2PSIP Peer-ID:  Information that uniquely identifies each P2PSIP
      Peer within a given P2PSIP Overlay.  This value is not human-
      friendly -- in a DHT approach, this is a numeric value in the hash
      space.  These Peer-IDs are completely independent of the
      identifier of any user of a user agent associated with a peer.
      Other forms: Node-ID

   P2PSIP Resource (User) Name:  A distinguished, human readable name
      that identifies a specific P2PSIP Resource or User within a given
      P2PSIP Overlay.  This is presumed to be a URI scoped to the P2PSIP
      Overlay Identifier.  This is presumably the same or very similar
      to a SIP Address of Record, or AOR.  Other forms: overlay resource
      (user) name, P2PSIP AOR.

   P2PSIP Resource-ID:  A non-human friendly value that uniquely
      determines which P2PSIP Peer is responsible for storing
      information about this resource (user).  In a DHT approach, this
      is a numeric value in the hash space resulting from hashing the
      P2PSIP Resource Name.  Since Resource-ID is in the same space as
      the P2PSIP Peer-ID, it allows for a mapping between the values,



Willis, et al.           Expires April 15, 2007                 [Page 7]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


      used to map a P2PSIP Resource to the P2PSIP Peer that stores it.
      Other forms: P2PSIP User-ID.

   P2PSIP Resource (User) Record:  A block of data, stored using the
      data mechanism of the P2PSIP Overlay, that includes information
      relevant to a specific resource.  We presume that there may be
      multiple types of resource records.  Some may describe routes to a
      client at which the user is presumed reachable (a "user routing
      record", like a SIP "Contact:").  Others might store presence
      information.  The types, usages, and formats of user records are a
      question for future study.

   P2PSIP User Agent:  A SIP user agent that is coupled with or
      incorporates a P2PSIP Peer or P2PSIP Client, such that the peer or
      client can assist the UA with registration (storage of a route to
      users of the UA) and/or routing of requests using the P2PSIP
      Overlay.  A P2PSIP User Agent differs from a conventional SIP user
      agent in that it is coupled directly to a P2PSIP Peer or P2PSIP
      Client, and can therefore directly interact with a P2PSIP Overlay,
      which a conventional SIP UA cannot do.  P2PSIP User Agents do not
      themselves have a distinguished name or identifier, although the
      P2PSIP User associated with it may, and if it is associated with a
      P2PSIP Peer, that peer may as well.  Other forms: overlay UA,
      P2PSIP UA.

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

   P2PSIP Client Protocol:  The protocol spoken between P2PSIP Clients
      and the P2PSIP Peer they use to store or retrieve information from
      the P2P Overlay.  This is a functional subset of the P2P Peer
      Protocol, but may differ in syntax and protocol implementation
      (i.e., may not be syntactically related).  Note that the precise
      relationship between the P2PSIP Peer Protocol and the P2PSIP
      Client Protocol (the same? subset?) remains an open question and
      is expected to be a principle topic of the detailed design work.
      This protocol may not exist (it may simply be conventional SIP) in
      some designs.  Short form: client protocol.

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

   P2PSIP Bootstrap Server:  A network node used by P2PSIP Peers or
      Clients who are attempting to locate an entry into the P2PSIP
      Overlay Network.  It may return an entry point (address of a Peer)
      to the P2PSIP Overlay or act as one itself.  This should be a



Willis, et al.           Expires April 15, 2007                 [Page 8]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


      quasi-stable and well known host, located using a configuration or
      discovered via , DNS, broadcast, or other mechanism.  This is a
      logical role, meaning it can be implemented as a P2PSIP Peer, as a
      standalone server, etc., but not every peer must provide this
      functionality.  Example: a P2PSIP Peer that reboots and has no
      knowledge of other peers uses a P2PSIP Bootstrap Server to find
      other peers in the P2P Overlay Network and establish P2PSIP Peer
      Insertion.  Other forms: bootstrap peer or node.

   P2PSIP Resource (User) Record:  A P2PSIP overlay user record that
      provides a routing vector that points to a location where the
      resource can presumably be reached.  This is analogous to the
      combination of a SIP [3] "Contact:" and a "Path:" [6].  The P2PSIP
      equivalent of a SIP registration process would be the insertion of
      an P2PSIP Resource Record into the overlay.  Other forms: resource
      (user) record, resource (user) registration.

   P2PSIP Peer Insertion:  The act of inserting a P2PSIP Overlay Peer
      into the current routing structure (presumably a distributed
      database or hash table) of a P2PSIP Overlay.  For example, the
      routing structure map the peer's IP address or DNS name to the
      peer's P2PSIP Peer-ID.  During insertion, the peer discovers its
      P2PSIP Overlay neighbors.  Following insertion, the peer will be
      able to store user records (such as routing information), query
      other peers for user records, and pass requests to route messages
      to other peers.  Other forms: peer or node registration, peer or
      node join.

   P2PSIP Resource (User) Record Insertion:  The act of inserting a
      record for a P2PSIP Resource (User) into the data maintained by
      the P2PSIP Peers.  Following insertion, the data stored at one or
      more peers will contain a record (such as a P2PSIP Resource
      Routing Record), keyed at least in part by a P2PSIP User
      Identifier.  Other forms: Resource registration, User record
      insertion.

   P2PSIP Peer Enrollment:  The initial one-time process a P2PSIP Peer
      follows to obtain an identifier and credentials, if any, within a
      P2PSIP Overlay.  This is not performed each time the peer comes
      online (contrast to P2PSIP Peer Insertion above), but only the
      first time they do so, or following a loss of identifier or
      credentials by the peer.  Other forms: node enrollment, peer
      enrollment.

   P2PSIP Resource (User) Enrollment:  The initial one-time process a
      P2PSIP Resource follows to obtain a unique identifier within a
      P2PSIP Overlay.  This is not performed each time the resource
      comes online, only the first time they do so, or following a loss



Willis, et al.           Expires April 15, 2007                 [Page 9]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


      of identifier or credentials by the client (contrast to P2PSIP
      Resource Record Insertion).  Other forms: user enrollment.


3.  Discussion

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

   In general, P2PSIP nodes might have the same sorts of duties/logical
   roles as traditional client-server SIP nodes.  This includes but is
   not limited to:

   1.  User Agent: a phone, voice mail server, bridge, or other device
       that initiates or terminates session requests.  This could be a
       P2PSIP Client (only performs GET/PUT of data) or P2PSIP Peer
       (participates in storing data as well)

   2.  Media relay: a P2PSIP peer or client capable of relaying RTP
       sessions, as described in [14]

   3.  Gateway: a P2PSIP peer or client that converts from P2PSIP to
       some other protocol, such as PSTN (Public Switched Telephone
       Network).

   4.  Redirector: a P2PSIP peer or client that accepts SIP requests
       (such as INVITE) for a P2PSIP resource identifier, searches the
       overlay, and returns the route to the resource in a 302 or 305
       response.

   5.  Proxy: a P2PSIP peer or client that accepts SIP requests (such as
       INVITE) for a P2PSIP resource identifier, searches the overlay,
       and forwards (proxies) the request to that resource.

   6.  Registrar: A peer or client that processes SIP REGISTER requests
       from non-P2P aware entities, either storing or retrieving the
       contact information to/from the routing data of the P2PSIP
       Overlay.

3.2.  Reference Model

   The following diagram depicts a reference or "boxes and arrows" model
   showing several of the above peer and client types, along with a
   conventional SIP user agent.








Willis, et al.           Expires April 15, 2007                [Page 10]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


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


                  \__/
                   /\
                  /  \
                 / UA \
                /______\
                SIP UA A


   Figure: P2PSIP Overlay Reference Model

   Here, the large perimeter depicted by "#" represents a stylized view
   of the P2PSIP Overlay and its associated routing data (the actual
   connections could be a mesh, ring, or some other structure).  Around
   the periphery of the P2PSIP Overlay rectangle, we have a number of
   P2PSIP Peers -- a PSTN gateway peer "G", three user-agent peers "D",
   "E" and "F", two proxy peers "P" and "Q", and a redirector peer "R".
   Note that because these are all P2PSIP Peers, each is responsible for
   helping store some information of the P2PSIP Overlay.




Willis, et al.           Expires April 15, 2007                [Page 11]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   To the left, two of the peers ("D" and "E") are behind network
   address translators.  These peers are included in the P2PSIP overlay
   and thus participate in storing information, despite being behind the
   NATs.

   Below the P2PSIP Overlay, we have a conventional SIP UA "A" which is
   not part of the P2PSIP Overlay, either directly as a peer or
   indirectly as a client.  It speaks neither the P2PSIP Peer nor P2PSIP
   Client protocols.  Instead, it uses pure (unmodified/extended) SIP to
   interact with with the P2PSIP Overlay.

   On the right side, we have a P2PSIP UA client "C", which uses the
   P2PSIP Client Protocol depicted by "=" to communicate with Proxy Peer
   "Q".  The P2PSIP Client protocol only allows for gets and puts to the
   overlay.  Therefore, "C" does NOT participate directly in/store
   information in the overlay.  In a solution where the P2PSIP Client
   Protocol is SIP, such as is proposed in [7], there is no difference
   between UA client "C" and standard SIP UAs "A", and the special
   P2PSIP client protocol is not needed.

   Note that in some scenarios, the P2PSIP Peers involved in the overlay
   might use a keepalive mechanism to ensure that messages to neighbors
   can pass through NATs.  Presumably, these messages will be in the
   form of the P2PSIP Peer protocol.

   Both the "Proxy Peers" and "Redirect Peers" can serve as adapters
   between ordinary SIP devices and the the P2PSIP Overlay.  Each
   accepts standard SIP requests and resolves the next-hop by using the
   P2PSIP overlay Peer Protocol to interact with the routing knowledge
   of the P2PSIP Overlay, then processes the SIP requests as appropriate
   (proxying or redirecting towards the next-hop).  Note that proxy
   operation is bidirectional - the proxy may be forwarding a request
   from an ordinary SIP device to the P2PSIP overlay, or from the P2PSIP
   overlay to an ordinary SIP device.

   The Gateway Peer provides a similar sort of adaptation to and from
   the public switched telephone network (PSTN).  However, there is a
   subtle distinction.  The gateway function itself can be viewed as a
   "user" or within the P2PSIP overlay, and is addressed using a P2PSIP
   Overlay User Identifier.  This gateway functionality could also be
   located in a P2PSIP Client, or even in a traditional SIP UA that is
   reached via P2P (using a P2P proxy or redirector) or conventional SIP
   mechanisms.

   The functions of various types of peers (redirect, UA, proxy,
   gateway) are logical roles.  There is no reason a particular
   implementation could not support one, several, or all of these
   functions in one entity.  For clarity, we show each as a fully



Willis, et al.           Expires April 15, 2007                [Page 12]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   distinct entity.

3.3.  Example Signalling Message Flows

   The following show very high level examples of message flows for
   various interactions of devices within the reference model.  In each
   case, we DO NOT show the flow of messages exchanged between P2PSIP
   peers to lookup information, since the exact nature of these flows
   and even who the messages would flow between will be a function of
   the particular data structure and protocol that is selected.  We do
   however indicate when the lookups occur.  This leads to the somewhat
   odd situation of a diagram having numbered flows to indicate
   ordering, but some numbers missing.  This is regrettable, but we
   aren't sure how else to do this since we cannot currently know what
   the lookup flows will look like in the final P2PSIP Peer protocol.

   In a solution where the P2PSIP Client Protocol is some protocol other
   than SIP, all of the following example flows are needed.  In a design
   where unmodified SIP is used for the P2PSIP Client, Section
   Section 3.3.2 is not needed.

3.3.1.  P2PSIP Peer contacts P2PSIP Peer

   The following diagram shows P2PSIP UA Peer "E" placing a call to
   P2PSIP UA Peer "F". 1) UA Peer "E" first uses the P2PSIP Peer
   protocol to communicate among the peers and obtain the location of
   "F" (flow not shown as this will depend on the protocol designed). 2)
   "E" then establishes a session directly with "F" using a conventional
   SIP INVITE/200 OK mechanism.






















Willis, et al.           Expires April 15, 2007                [Page 13]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006