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

Versions: 00 01

Network Working Group                                     Yongchao. Song
Internet-Draft                                           Xingfeng. Jiang
Intended status: Standards Track                            Hewen. Zheng
Expires: August 25, 2008                                          Huawei
                                                               Hui. Deng
                                                            China Mobile
                                                       February 22, 2008


                         P2PSIP Client Protocol
                 draft-zheng-p2psip-client-protocol-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2008.

Abstract

   This document defines P2PSIP client protocol, one protocol for
   client-peer communication, which is used to create, implement and
   maintain the services between a client and its associated peers.









Song, et al.             Expires August 25, 2008                [Page 1]


Internet-Draft           P2PSIP Client Protocol            February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of Functions  . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Overview of Protocol . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  High-level Descriptions  . . . . . . . . . . . . . . . . .  7
     4.2.  Messages Routing . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Messages Transporting  . . . . . . . . . . . . . . . . . .  8
     4.4.  Enrollment and Bootstrap . . . . . . . . . . . . . . . . .  8
     4.5.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  9
     4.6.  Node Capability  . . . . . . . . . . . . . . . . . . . . . 10
     4.7.  Node Status  . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Packets Formats  . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Message Header . . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Message Attributes . . . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Response Attribute . . . . . . . . . . . . . . . . . . 12
       5.2.2.  Status Attribute . . . . . . . . . . . . . . . . . . . 13
       5.2.3.  Service Capability . . . . . . . . . . . . . . . . . . 14
       5.2.4.  Uptime Attribute . . . . . . . . . . . . . . . . . . . 15
       5.2.5.  Overlay Info Attribute . . . . . . . . . . . . . . . . 15
       5.2.6.  Security Attribute . . . . . . . . . . . . . . . . . . 16
   6.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  Inquire  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.2.  Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.3.  Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 21
     6.4.  Notify . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     6.5.  Leave  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     6.6.  Put  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     6.7.  Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     6.8.  Get  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     6.9.  LookUpServicePeer  . . . . . . . . . . . . . . . . . . . . 25
   7.  Contribute Storage Capacity  . . . . . . . . . . . . . . . . . 26
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     12.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 33









Song, et al.             Expires August 25, 2008                [Page 2]


Internet-Draft           P2PSIP Client Protocol            February 2008


1.  Introduction

   Conventional centralized function is provided by a single node using
   Client/Server mode, e.g.  STUN and FTP.  Distributed function is
   provided by many nodes using peer-to-peer mode, in this mode, each
   node contributes its services to other nodes to allow the overlay
   consisting of all individual nodes to collectively provide function,
   e.g.  P2PSIP.  A node can solely provide centralized function, but it
   must cooperate with other nodes to collectively provide distributed
   function.

   In P2PSIP, nodes participating in a P2PSIP Overlay that provides
   storage and transport services to other nodes in that P2PSIP Overlay
   are called P2PSIP peers.  P2PSIP overlay can provision services to
   nodes that participate in the overlay but don't provide distributed
   transport service in the overlay, those nodes are called P2PSIP
   Clients, and at the same time those P2PSIP Peers which are associated
   with P2PSIP Clients and provide P2PSIP functions to P2PSIP Clients
   are called Host Peers or Associated Peers.  Host Peers or Associated
   Peers must be P2PSIP neighbors of P2PSIP Clients.  In this document,
   we call P2PSIP Peer as Peer and P2PSIP Client as Client unless
   special explanation.

   Essentially Peers are P2PSIP overlay routing nodes, and Clients are
   non-overlay-routing nodes [P2PSIP-Concepts-Terminology].  Any Peer
   owns a unique identifier known as Peer-ID in P2PSIP overlay, and
   P2PSIP overlay is transparent to Clients.

   Peers participate in structuring P2PSIP overlay, they collectively
   provide P2PSIP overlay functions - distributed storage function and
   distributed transport function, the peers in the overlay collectively
   run a distributed database algorithm.  Clients participate in the
   P2PSIP overlay, but they are unable or unwilling to provide
   distributed storage function or distributed transport function.

   A client interacts with the P2PSIP overlay through an associated peer
   (or perhaps several peers) using the client protocol.  The client
   does not run the distributed database algorithm, and is not involved
   in routing messages to other peers or clients.  Through interactions
   with its associated peer, a client can insert, modify, examine, and
   remove resource records.

   What services a client can contribute to the overlay can be found in
   the client draft[I-D.pascual-p2psip-clients].  We support the
   function that a client can contribute its storage space to its
   associated peer in our p2psip client protocol.  It can be easily
   realized by sending a PUT or Get message from a peer to its
   associated client after receiving knowleadge of the contributable



Song, et al.             Expires August 25, 2008                [Page 3]


Internet-Draft           P2PSIP Client Protocol            February 2008


   storage space from its associated client.

   P2PSIP client protocol is used to create, implement and maintain the
   services between a client and its associated peer.

   One communication protocol known as "P2PSIP Peer protocol" is used to
   create and maintain all participant peers topology and distributed
   function in the overlay, i.e., to share information and organize
   P2PSIP overlay network.  It has been agreed that the client protocol
   is a functional subset of the P2P Peer Protocol, but may differ in
   syntax and protocol implementation (i.e., may not be syntactically
   related).

   This document defines the P2PSIP client protocol basing on one P2PSIP
   peer protocol "Service Extensible P2P Peer Protocol" [I-D. jiang-
   p2psip-sep], i.e. the defined P2PSIP client protocol reuses the
   P2PSIP peer protocol if possible, and certainly they may be different
   in syntax.


2.  Overview of Functions

   P2PSIP client protocol is used to communicate between a client and
   its associated peer depicted as Figure 1, the peer Q is not coupled
   with SIP entity such as SIP UA, SIP proxy or SIP redirector, but the
   client C is coupled with SIP UA, and the client C uses P2PSIP client
   protocol to retrieve the callee's contact info from P2PSIP overlay
   through Peer Q.























Song, et al.             Expires August 25, 2008                [Page 4]


Internet-Draft           P2PSIP Client Protocol            February 2008


                                                     --->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         | Peer  |    /Client\
        |      |    T                              |   Q   |    |___C__|
        |  UA  |    N                              |       |
        | Peer |    A                              +-------+
        |  D   |    T                                    #
        |      |    N                                    #
        +------+    A                                    # P2PSIP
           #        T                                    # Peer
           #        N    +-------+        +-------+      # Protocol
           #        A    |       |        |       |      #
           #########T####| Proxy |########| Redir |#######
                    N    | Peer  |        | Peer  |
                    A    |   P   |        |   R   |
                    T    +-------+        +-------+
                           |                 /
                           | SIP            /
                     \__/  /               /
                      /\  / ______________/ SIP
                     /  \/ /
                    / UA \/
                   /______\
                   SIP UA A

            Figure1 P2PSIP Overlay Reference Model

   P2PSIP client protocol:

   O Provides a bootstrap mechanism for clients to join the overlay.  A
   centralized bootstrap server mechanism is proposed in this draft.

   O Provides mechanisms for clients to create, maintain and terminate
   service relationship with the selected associated peer.

   O Provides a mechanism for clients to publish/retrieve resource
   records to/from the overlay through its associated peer.



Song, et al.             Expires August 25, 2008                [Page 5]


Internet-Draft           P2PSIP Client Protocol            February 2008


   O Provides a mechanism for clients to get candidate associated peers
   through its now associated peer.  Any peer that is willing to be a
   candidate associated peer advertise its service in the
   overlay(SEP[I-D. jiang-p2psip-sep] provides a general service
   advertisement and lookup mechanism).  A client sends a
   LookUpServicePeer request to find its candidate associated peers.

   O Provides a notification mechanism for a client to choose one best
   service peer from its multiple associated peers.  When a peer or a
   client changes its status due to some reasons, it must generate a
   Notify message to its associated client/peer.  (Open Issue: Is there
   a Primary associated Peer among a client's multiple associated peers,
   a client should get service through this primary peer until it fails?
   Or it is just the client's local policy to choose which peer to serve
   him? ).  The notification can also be used for other purposes.

   O If possible and required, provides a mechanism for a peer to store/
   retrieve resource records to/from its associated clients.

   O If possible and required, e.g. there are many clients associated
   with a same peer and communication among these clients are regular.
   The peer can store the resource objects that its associated clients
   published on both itself and the overlay.  Then it can resolve many
   requests from its associated clients locally, and if it can't, it
   tries to get a result from the overlay.


3.  Terminology

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

   This section defines some key concepts using in this document.

   Host Peer: A peer that provides P2PSIP overlay function to clients,
   it is also called as "associated peer".  A client can have more than
   one host peer.

   Host Peer Candidate: A peer that has the ability of providing P2PSIP
   overlay function to clients.  A client can learn multiple Host Peer
   Candidates through a bootstrap server, or through its Host Peer.  A
   client can choose one or more Host Peer Candidate(s) to be its Host
   Peer(s).  It also has the name "candidate host peer", or "candidate
   associated peer".

   P2PSIP Overlay Services: Those distributed functions that provided
   collectively by all peers in the P2PSIP overlay, such as distributed



Song, et al.             Expires August 25, 2008                [Page 6]


Internet-Draft           P2PSIP Client Protocol            February 2008


   storage function, distributed transport function.

   Resource Name: A human-friendly name that unique resource, such as
   URI.

   The other concepts used in this document are compatible with P2PSIP
   Work Group Draft "Concepts and Terminology for Peer to Peer SIP"
   [I-D.ietf-p2psip-concepts].


4.  Overview of Protocol

4.1.  High-level Descriptions

   From the viewpoint of service provision, P2PSIP client protocol
   mainly meets three basic requirements:

   (1).Client-peer relationship maintenance, this protocol should
   provide mechanisms to maintain service relationship between a client
   and its host peer;

   (2).Resource publication and retrieve, this protocol should provide a
   mechanism for a client to publish/retrieve resource records to/from
   the overlay through its host peer, a mechanism for a peer to store
   and retrieve resource records to and from its associated clients;

   (3).Heterogeneous network support, this protocol should provide a
   mechanism for a client to learn candidate host peers' capability and
   status to select one or more appropriate peers as its host peers, a
   mechanism for a peer to learn its clients' capability (i.e.,
   contributable storage capacity) to enlarge its storage capability.

   Multiple clients can have the same host peer and one client can also
   have multiple host peers.  One peer can serve more than one client
   simultaneously, one client can communicate with more than one peer
   simultaneously to enhance redundancy for service continuity.

   P2PSIP client protocol is a request-response protocol.  Requests from
   clients are responded with necessary response info by its host peer
   or any responsible peer in the overlay network.  Requests sent
   directly from a peer to its associated client are responded with
   required response info by its associated client.  Message routing is
   described in Section 4.3.

   Host peer candidates for a client are learned from its bootstrap
   server or through its host peers.

   A client can provide capability info such as network bandwidth,



Song, et al.             Expires August 25, 2008                [Page 7]


Internet-Draft           P2PSIP Client Protocol            February 2008


   contributable storage capacity to its host peer.  A peer must provide
   status info (e.g., congestion status info based on CPU utilization)
   to its clients so that clients can do appropriate actions based upon
   some policies to guarantee uninterrupted overlay service.

4.2.  Messages Routing

   A client sends requests using IP routing directly to its host peer,
   the host peer returns responses using IP routing directly to the
   client.  The host peer tries to locally resolve the requests if
   possible; it tries to get the results from the P2PSIP overlay when
   failed to resolve the requests itself.

   A client may require that the response from the responsible peer must
   come back to it via IP routing directly, it can include its contact
   address such as IP address and port in the request for this purpose.

   A peer sends out a request using IP routing directly to one client,
   the client dispose the request and then returns the response using IP
   routing directly to the host peer.

   Requests and responses are limited to between a client and its host
   peer and use IP routing.

4.3.  Messages Transporting

   P2PSIP client protocol proposed in this document follows the messages
   transporting specification defined in the SEP protocol [I-D. jiang-
   p2psip-sep], e.g. they adopt the same transport layer listening port.

4.4.  Enrollment and Bootstrap

   When a client wishes to use the service of the overlay, it must get a
   client ID from the Enrollment server.  And then it must contact the
   bootstrap server to get some host peer candidates information.  It
   inquire these host peer candidates to choose its host peers and it
   get the service of the overlay from its host peers.  A client can
   have multiple host peers.  Enrollment server and bootstrap server may
   be collocated in one entity.  We just propose this kind of mechanism
   using centralized server for simplicity.  We agree that there are
   none centralized mechanisms(e.g. mDNS) for the enrollment and
   bootstrap and they are very useful in the specific application
   scenarios.

   The enrollment and bootstrap procedure MUST address two issues.  One
   is to issue a client ID which does not conflict with the existing
   client ID to the joining client, as for the security considerations,
   some additional mechanism may be added(e.g. with a signed



Song, et al.             Expires August 25, 2008                [Page 8]


Internet-Draft           P2PSIP Client Protocol            February 2008


   certificate).  The other is to learn candidate host peers information
   and choose one or more to be the host peer(s).

   There are some proposed methods are not based on the Bootstrap Server
   Mechanism.  Some of them are listed in the following:

   (1).Static Locations: Some number of peers in the overlay may be
   persistent and have well known addresses.  These addresses could be
   configured into the client application or obtained using an out-of-
   band mechanism such as a web page;

   (2).Cached Peers: While this mechanism cannot be used when a client
   runs the first time, on subsequent attempts to join the overlay a
   client might attempt to use a previously contacted host peer as a
   host peer candidates;

   (3).Broadcast/multicast mechanisms: Clients can use a broadcast or
   another local discovery mechanism to locate the initial peers;

   (4).DNS: An overlay can list well-known and capable peers in
   appropriate DNS entries so that current host peers can be located by
   any client when it wishes to use the overlay's service.  DNS-SD
   bootstrapping mechanism[I-D.garcia-p2psip-dns-sd-bootstrapping] is an
   example.

   When a client finds some peers as host peer candidates, it MUST
   decide which of them to be the host peer(s) through the inquiry
   result with each host peer candidates.

4.5.  NAT Traversal

   In P2PSIP, it is possible that some clients are behind NAT and some
   peers are behind NAT.

   If some clients are behind NAT and its host peer is reachable, NAT is
   not a problem because the client can send requests to the host peer
   and the response can be sent back through the host peer.

   If some peers are behind NAT, the problem is how to set up a
   connection between the client and the NATed host peer.  STUN
   [I-D.ietf-behave-rfc3489bis], TURN [I-D.ietf-behave-turn] and ICE
   [I-D.ietf-mmusic-ice] can be used to solve this problem.

   NAT traversal is relevant to network deployment; the implementer may
   use an Enrollment Server to publish reachable contact info of peers
   behind NAT.  We suggest that peers with global addresses should be
   preferred as candidate host peers, but peers behind NAT should also
   be taken into account to ensure enough service peers.



Song, et al.             Expires August 25, 2008                [Page 9]


Internet-Draft           P2PSIP Client Protocol            February 2008


4.6.  Node Capability

   The capabilities of host peer obviously impact the QoS of P2PSIP
   overlay service for its clients.  Clients need to learn the
   capabilities of candidate host peers such as link bandwidth so that
   the clients choose one or more peers with better capabilities to be
   its host peers.

   The capability of a client (i.e., contributable storage capacity)
   directly impacts its associated peers' decision whether and how to
   use clients to expand their storage capacity.

4.7.  Node Status

   In fact, the most important factor impacting QoS of P2PSIP overlay
   service for clients is peers' status, such as congestion info, peer-
   to-overlay connectivity etc.

   Upon perceiving the service degrading event or the service
   interruption event of host peer timely, clients can choose other
   peers as host peers to keep continuous QoS of providing P2PSIP
   overlay service.


5.  Packets Formats

   On packets formats, P2PSIP client protocol follows P2PSIP peer
   protocol specification, the introduced messages adopt the same
   message format with existing P2PSIP peer protocol messages, and those
   message uses the common message header.  Different types of messages
   convey different contents according to the protocol design, and then
   those different contents are described by different TLV (Type-Length-
   Value) style objects combinations.  Those objects are called as
   "Attributes".

   P2PSIP client protocol reuses messages (including format and
   semantic) defined the P2PSIP peer protocol if possible, extend them
   and introduce new types of messages if necessary.

5.1.  Message Header

   P2PSIP client protocol messages also use a common message header,
   after which some TLV style attributes follow, as in the P2PSIP peer
   protocol.

   P2PSIP client protocol reuses the message header defined in the
   P2PSIP peer protocol.  At the same time it introduces two control
   flags - 'C' flag and 'E' flag.  The message header format is depicted



Song, et al.             Expires August 25, 2008               [Page 10]


Internet-Draft           P2PSIP Client Protocol            February 2008


   as Figure 2.  Please refer to P2PSIP peer protocol [I-D.jiang-p2psip-
   sep] for the detailed format of message header.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|R|H|D|F|J|C|E|Reserved | Message Type  |      TTL      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Message Length          |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Transaction-ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source ID = 128bit                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Destination ID = 128bit                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 2 Message Header Format

   C-flag (1 bit): If it is set, it means that this message is P2PSIP
   client protocol message;

   E-flag (1 bit): If it is set, it means that suppressing response
   message is desirable, for example, a Notify request message from a
   peer to its client can require the client to suppress response
   message through setting E flag.

   Source ID: If the message is generated by a peer, the source ID is
   filled with the source peer ID, if the message is generated by a
   client, the source ID is filled with the client ID.

   This document introduces one new type of message as below:

                         Message Type       Name
                         12                Inquire
   If the message's final destination is the associated peer or client,
   e.g. it's a Notify message, then the destination ID is filled with
   the associated peer's ID or associated client's ID.  If the message's
   destination is a peer that responsible for the searched resource
   object, e.g. it's a Get message generated by a client, then the
   destination ID is filled with the resource ID of the searched
   resource object.

5.2.  Message Attributes

   As P2PSIP peer protocol, P2PSIP client protocol message contains
   zero, one or multiple Attributes which describe the specified



Song, et al.             Expires August 25, 2008               [Page 11]


Internet-Draft           P2PSIP Client Protocol            February 2008


   contents.  All attributes follow P2PSIP peer protocol specification
   and adopt TLV style.  Please refer to P2PSIP peer protocol
   [I-D.jiang-p2psip-sep] for the detailed format of Message Attributes.

   This document introduces three new types of attributes as below:

                      Attribute Type     Name
                      17                 Uptime
                      18                 Overlay Info
                      19                 Security

   In addition to the newly introduced Client attribute, Security
   attribute, Uptime attribute and Overlay Info attribute, this document
   extends the Response attribute, Status attribute, and Service
   Capability attribute defined in P2PSIP peer protocol specification.
   Every attribute in SEP peer protocol can also be used in P2PSIP
   client protocol without change except that its meaning is not limited
   only to the peer, but adapted to both peer and client.

5.2.1.  Response Attribute

   This document extends the Response attribute defined in the P2PSIP
   peer protocol to describe the result of disposing the P2PSIP client
   protocol request message.

   Response attribute format is shown as Figure 3:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |Attribute Type |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Response code         |       Response sub-code       |
       +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+

                       Figure 3 Response Attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Attribute Type (8 bits): the value is 7 (0x07);

   Length (16 bits): the length in bytes of this attribute;

   Response Code (16 bits): response code determined by the initiator,
   this field is necessary for any response attribute;




Song, et al.             Expires August 25, 2008               [Page 12]


Internet-Draft           P2PSIP Client Protocol            February 2008


   Response Sub-Code (16 bits): response sub-code determined by the
   initiator, this field is optional for one response attribute.

   This document introduces new response codes as below:

               Response Code      Meaning
               404                Authentication Required
               405                Authentication Failed
               406                Contributed Space Required
               407                Not Found
               408                Request Failed
               409                Request Rejected
               410                Join Request Deferred
               431                Leave Request Deferred
               432                Overlay Service Interrupt
               433                Message Too Large
               434                Unrecognized message type
               435                Unrecognized object type
               436                Request Timeout

5.2.2.  Status Attribute

   This document extends the Response attribute defined in the P2PSIP
   peer protocol to describe the status of a peer (e.g., congestion, or
   overlay service interrupt).

   Status attribute format is shown as Figure 4:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Type      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Status Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4 Status Attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Attribute Type (8 bits): the value is 12 (0x0C);

   Length (16 bits): the length in bytes of this attribute;

   Status Code (16 bits): indicates the current state of a peer.  The
   value 0x00 means that the peer is in good condition; the value 0x01



Song, et al.             Expires August 25, 2008               [Page 13]


Internet-Draft           P2PSIP Client Protocol            February 2008


   means that the peer is busy.

   This document introduces a new type of status codes as below:

               Status Code         Meanings
               2                   Overlay Service Interrupt

5.2.3.  Service Capability

   This document extends the Peer Service Capability attribute defined
   in the P2PSIP peer protocol to describe the service capability of a
   peer or a client (e.g., provide the service of a TURN server, or a
   client can contribute certain space of storage to the associated peer
   ).

   Service capability attribute format is shown as Figure 5:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |M|  Reserved   |     Type      |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |N|S|T|H|C|   Reserved          |  Contributable Storage Space  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Contributable Storage Space |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 5 Service Capability attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Attribute Type (8 bits): the value is 0x01;

   Length (16 bits): the length in bytes of this attribute;

   N (1 bit): if N flag is set, it means the node is behind NAT.
   Otherwise the node is on the public Internet.

   S (1 bit): STUN service.  If it is set, it means the peer supports
   STUN service.

   T (1 bit): STUN relay service.  When it is set, it means the peer
   supports STUN relay service.

   H(1 bit): Host peer service.  If this bit is set, it means that the



Song, et al.             Expires August 25, 2008               [Page 14]


Internet-Draft           P2PSIP Client Protocol            February 2008


   peer supports host peer service, it can be chosen as a host peer
   candidate.

   C(1 bit): Contributable storage.  If it is set, the size of storage
   space(32bits integer in bytes) that the client can provide to its
   associated peer is following the reserved field.

5.2.4.  Uptime Attribute

   This document introduces a new type of attribute to describe the
   uptime of a node, this attribute is called as "Uptime attribute", and
   its format is shown as Figure 6:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Type      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Uptime(seconds)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6 Uptime Attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Attribute Type (8 bits): the value is 17 (0x11);

   Length (16 bits): the length in bytes of this attribute;

   Uptime (16 bits): the uptime of the node in seconds.

5.2.5.  Overlay Info Attribute

   This document introduces a new type of attribute to describe the
   information of the overlay network which a peer participates in or a
   client wants to access, this attribute is called as "Overlay Info
   attribute", and its format is shown as Figure 7:












Song, et al.             Expires August 25, 2008               [Page 15]


Internet-Draft           P2PSIP Client Protocol            February 2008


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Type      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Hash algorithm |                 Overlay ID                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Overlay Name  (variable length)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7 Overlay Info Attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Attribute Type (8 bits): the value is 18 (0x12);

   Length (16 bits): the length in bytes of this attribute;

   Hash algorithm (8 bits): the hash algorithm used by the P2PSIP
   overlay.  The destination ID field of the message is the hashing
   result of the resource name when the message is used to retrieve a
   resource object in the overlay. 0x00 is reserved, 0x01 for SHA-1;

   Overlay ID (24 bits): an identifier that uniquely identifies each
   P2PSIP overlay network.  This value is not human-friendly;

   Overlay Name: A human-friendly name that identifies a specific P2PSIP
   Overlay.  This is in the format of (a portion of) a URI, but may or
   may not have a related record in the DNS.  This field is optional in
   an Overlay Info attribute.

5.2.6.  Security Attribute

   This document introduces a new type of attribute to describe the
   security information for a node, this attribute is called as
   "Security attribute", and its header format is shown as Figure 8:













Song, et al.             Expires August 25, 2008               [Page 16]


Internet-Draft           P2PSIP Client Protocol            February 2008


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Type      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8 Security Attribute Header Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Attribute Type (8 bits): the value is 19(0x13);

   Length (16 bits): the length in bytes of this attribute including its
   sub attributes.

   A Security attribute is a composite attribute; it owns some private
   sub-attribute especially for itself.  This document defines several
   sub-attributes for Security attribute: authentication & crypto type,
   username, password, challenge.

   Authentication & Crypto Type Sub-Attribute Format is shown as Figure
   9:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Sub-Type  |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Auth Type   |  Crypto Type  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 9 Authentication & Crypto Type Sub-Attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Sub-attribute Type (8 bits): the value is 1 (0x01);

   Length (16 bits): the length in bytes of this sub-attribute;

   Auth Type (8 bits): authentication type.  This document defines two
   types of authentication: 1 for PAP; 2 for CHAP.  The value Zero means
   that no any authentication is required;

   Crypto Type (8 bits): crypto algorithm.  This document defines 2



Song, et al.             Expires August 25, 2008               [Page 17]


Internet-Draft           P2PSIP Client Protocol            February 2008


   types of crypto algorithms: 1 for DES, 2 for RC4.  The value Zero
   means that no any crypto algorithm is required and specified.  The
   crypto algorithm is used to encrypt/decrypt the P2PSIP client
   protocol message over the transport layer.

   Username Sub-Attribute Format is shown as Figure 10:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Sub-Type  |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Username (variable length)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10 Username Sub-Attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Sub-attribute Type (8 bits): the value is 2 (0x02);

   Length (16 bits): the length in bytes of this sub-attribute;

   Username: the human-friendly string which uniquely identifies the
   P2PSIP client.

   Password Sub-Attribute is shown as Figure 11:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Sub-Type  |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Password (variable length)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 11 Password Sub-Attribute Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Sub-attribute Type (8 bits): the value is 3 (0x03);

   Length (16 bits): the length in bytes of this sub-attribute;




Song, et al.             Expires August 25, 2008               [Page 18]


Internet-Draft           P2PSIP Client Protocol            February 2008


   Password: the human-friendly password of the user.

   Challenge Sub-Attribute Format is shown as Figure 12:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|  Reserved   |     Sub-Type  |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Challenge (variable length)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 12 Challenge Sub-Object Format

   M-flag: the value is 1;

   Reserved (7 bits): those bits are reserved and ignored;

   Sub-attribute Type (8 bits): the value is 4 (0x04);

   Length (16 bits): the length in bytes of this sub-attribute;

   Challenge: a non-human-friendly challenge in binary.


6.  Messages

   P2PSIP client protocol reuses Join, Leave, Keep-alive and Notify
   messages to maintain topology, it reuses Put, Get and Remove messages
   to operate resource records.  It reuses LookUpServicePeer message to
   look up peers or clients that can provide certain services in the
   overlay(e.g.  STUN server, TURN server, host peer candidates).
   Besides those messages, it introduces one new type of message -
   Inquire and some attributes.

   Each type of message contains the request form and its response form.
   The request messages are used to require the specified receiver to
   dispose the specified event or provide the specified info, and the
   response messages are used to return the initiator the disposal
   result.

6.1.  Inquire

   The introduced Inquire messages are used to request capabilities
   info, status info and P2PSIP overlay info of candidate host peers.

   A client must generate one Inquire message to obtain service
   capabilities info, status info and P2PSIP overlay info of the peer



Song, et al.             Expires August 25, 2008               [Page 19]


Internet-Draft           P2PSIP Client Protocol            February 2008


   before establishing service relationship between the client and its
   host peer candidate.

   Upon the receipt of an Inquire message, the peer returns directly a
   response message with possible info to the client.

   An Inquire request message must contain a message header; it may
   contain a source peer Info attribute and a Security attribute.  If
   the initiator is a client, the "Peer ID" field in the Source Peer
   Info is actually a Client ID, and other fields are suchlike.

   Inquire request = Message Header
                    [Source Peer Info Attribute]
                    [Security Attribute]

   An Inquire response message must contain a message header and a
   Response attribute; it may contain a Destination Peer Info attribute
   and a Status attribute.

   Inquire response = Message Header
                     Response Attribute
                     [Destination Peer Info Attribute]
                     [Status Attribute]

6.2.  Join

   In this document, Join messages are reused to create service
   relationship with the selected host peer.

   After obtaining interesting info of candidate host peers by Inquire
   messages, a client choose one or more peers as host peers according
   to local policy such as capabilities of candidate host peers,
   response delay of candidate host peers, then it structures and sends
   out a Join message to the selected peer to setup service
   relationship.

   Upon the receipt of a Join message without any required
   authentication info from a client, the peer may return a Join
   response message with the response code "405 Authentication Required"
   to require authentication info from the client, the response message
   uses a Security attribute to indicate specified authentication type.

   Upon the receipt of a Join message without the required contributable
   storage info from a client, the peer may return a Join response
   message with the response code "406 Contributed Space Required" to
   require contributable storage capacity from the client.

   Upon the receipt of a Join message, the peer may return a Join



Song, et al.             Expires August 25, 2008               [Page 20]


Internet-Draft           P2PSIP Client Protocol            February 2008


   response message with the response code "410 Join Request Deferred"
   when the peer finds itself busy or considers other causes.

   A client must provide the required authentication info in the
   following Join message according to the received Security attribute
   in the response message with the response code 405.

   A client must provide contributable storage capacity info in the
   following Join message according to the received response message
   with the response code 406.

   A client may resend another Join message after the specified interval
   according to the received response message with the response code
   410.

   After receiving a Join message from a client, the peer returns a Join
   response message with the response code "200 OK" when the peer is
   ready to serve the client.

   A Join request message must contain a message header and a Source
   Peer Info attribute; it may contain a Security attribute and an
   Overlay Info Attribute.

   Join request = Message Header
                 Source Peer Info Attribute
                 [Security Attribute]
                 [Overlay Info Attribute]

   A Join response message must contain a message header and a Response
   attribute; it may contain a Destination Peer Info attribute.

   Join response = Message Header
                   Response Attribute
                   [Destination Peer Info Attribute]

6.3.  Keep-alive

   In this document, Keep-alive messages are sent out periodically to
   check the availability for a client and its host peers, especially
   when one or more nodes are behind NAT.  Certainly any other P2PSIP
   client messages can be used to check the availability, the keep-alive
   timer between two immediate nodes (i.e., a client and its host peer)
   can be heuristics.

   A Keep-alive request message must contain a message header; it may
   contain a Status attribute and a Source Peer Info attribute.





Song, et al.             Expires August 25, 2008               [Page 21]


Internet-Draft           P2PSIP Client Protocol            February 2008


   Keep-alive request = Message Header
                       [Status Attribute]
                       [Source Peer Info Attribute]

   A Keep-alive response message must contain a message header; it may
   contain a Status attribute a Destination Peer Info attribute.

   Keep-alive response = Message Header
                        [Status Attribute]
                        [Destination Peer Info Attribute]

6.4.  Notify

   In this document, Notify messages are reused to announce the host
   peer's event such as the congestion event or the overlay connection
   unexpected disruption event.

   A client concerns about the continuity and quality of P2PSIP overlay
   service provided by its host peer.  A client may access multiple
   peers to enhance redundancy of P2PSIP overlay service, and at the
   same time a client expresses implicitly its interest in monitoring
   the status of P2PSIP overlay service provided by its host peer
   through a Join message.  After a client joins the overlay, the
   associated peer monitors its service status for this client.  When
   the peer finds that the service status changes (e.g. congested or its
   overlay connection disrupted by itself or others), the peer sends out
   a Notify message to tell its client the service status change (e.g.
   service degradation due to the congestion or the service interruption
   due to the disconnection from the overlay network), the client then
   choose other appropriate peers as host peers to avoid impacting
   negatively the continuity and quality of P2PSIP overlay service.

   A Notify request may indicate that the response is suppressed.

   A Notify request must contain a message header and a Status
   attribute.

   Notify request = Message Header
                    Status Attribute

   A Notify response message must contain a message header and a
   Response attribute.









Song, et al.             Expires August 25, 2008               [Page 22]


Internet-Draft           P2PSIP Client Protocol            February 2008


   Notify response = Message Header
                     Response Attribute

6.5.  Leave

   In this document, Leave message are reused to tell the host peer that
   the client wants to terminate the service relationship between the
   client and the peer.

   Before sending out a Leave message, a client may use Remove messages
   to remove the published resource records by itself through the host
   peer.

   The host peer returns a Leave response message with the response code
   "200 OK" if it is ready for the client's leave.  If the client
   contributes its storage space to the host peer, the host peer need
   retrieve those resource records stored in the contributed storage
   space of the client before the client leave.

   Upon the receipt of a Leave response message with the response code
   "409 Leave Request Deferred", the client may resend out another Leave
   message after some time.

   A Leave request message must contain a message header; it may contain
   a Source Peer Info attribute.

   Leave request = Message Header
                  [Source Peer Info Attribute]

   A Leave response message must contain a message header and a Response
   attribute.

   Leave response = Message Header
                    Response Attribute

6.6.  Put

   In this document, Put messages are used to insert and modify resource
   records between a client and its host peer.

   A client uses Put messages to insert and modify the resource records
   through its host peer.  A peer uses Put messages to transfer resource
   records to the client, update the transferred resource records on the
   client.

   The resource records should be deleted when it expires.

   A host peer may locally cache the resource records published by its



Song, et al.             Expires August 25, 2008               [Page 23]


Internet-Draft           P2PSIP Client Protocol            February 2008


   clients, and then the host peer prefers locating the resource records
   first locally on itself than in the overlay when receiving the
   consequent requests for the resource records from its other clients,
   at last the host peer returns the requested resource records within
   the response messages, it is more effective especially for local
   communication between clients served by the same host peer.

   A Put request message must contain a message header and a Resource
   Info attribute.  It may contain a Source Peer Info attribute.

   Put request = Message Header
                 Resource Info Attribute
                 [Source Peer Info Attribute]
                 [Destination Info Attribute]

   A Put response message must contain a message header and a Response
   attribute.

   Put response = Message Header
                  Response Attribute

6.7.  Remove

   In this document, Remove messages are used to remove resource records
   between a client and its host peer.

   A client uses Remove messages to remove the resource records through
   its host peer.  A peer uses Remove messages to remove resource
   records to the client.

   A Remove message should remove cached resource records published by
   clients on a peer.

   A Remove request message must contain a message header and a Resource
   Info attribute.  It may contain a Source Peer Info attribute.

   Remove request = Message Header
                    Resource Info Attribute
                    [Source Peer Info Attribute]

   A Remove response message must contain a message header and a
   Response attribute.









Song, et al.             Expires August 25, 2008               [Page 24]


Internet-Draft           P2PSIP Client Protocol            February 2008


   Remove response = Message Header
                     Response Attribute

6.8.  Get

   In this document, Get messages are reused to retrieve the specified
   resource records.

   A client uses Get messages to obtain the specified resource record
   from the P2PSIP overlay through the host peer.  A peer uses Get
   messages to obtain the specified resource record from its clients.

   A Get request message must contain a message header and a Resource
   Info attribute.  It may contain a Source Peer Info attribute.

   Get request = Message Header
                 Resource Info Attribute
                 [Source Peer Info Attribute]

   A Get response message must contain a message header, a Response
   attribute and a Resource Info attribute.

   Get response = Message Header
                  Response Attribute
                  Resource Info Attribute

6.9.  LookUpServicePeer

   As the SEP peer protocol, a client sends a LookUpServicePeer request
   to its associated peer to lookup peers that have the certain service
   capability in the overlay, e.g.  STUN server, TURN server and so on.
   A client can also get its host peer candidates with this request.

   A LookUpServicePeer request must contain a message header and a
   Service Peer Info attribute.

   LookUpServicePeer Request = Message Header
                               Service Peer Info
                               Source Peer Info

   A LookUpServicePeer response must contain a message header and a
   Source Peer Info.  If service peers are found in the overlay, the
   result is returned to the source peer with a Service Peer Info
   attribute.







Song, et al.             Expires August 25, 2008               [Page 25]


Internet-Draft           P2PSIP Client Protocol            February 2008


   LookUpServicePeer Response = Message Header
                                Source Peer Info
                                [Service Peer Info]


7.  Contribute Storage Capacity

   Some strong P2PSIP clients may be able and willing to share storage
   pressure for its host peer, but those clients do not run distributed
   database algorithm, they only simply contribute their storage
   capacity for host peers.

   When a client joins its host peer, the client tells the peer its
   contributable storage capacity in the Join message.  If a Join
   message does not carry this info, the peer can return a Join response
   message with the response code "406 Contributed Space Requested" to
   require this info in the following Join message.

   A peer uses Put message to store resource records into its clients;
   the clients return results with Put response messages.

   A peer uses Resource-ID through Get messages to retrieve resource
   records from its clients; the clients return results with Get
   response messages.


8.  Acknowledgments

   Some of the consideration in the draft came from the discussion in
   the P2PSIP mailing list.  Thanks to Spencer Dawkins, Victor Pascual.


9.  Security Considerations

   We can't complete all security considerations section in this
   revision, but in at least some application scenarios, client
   vulnerability to peers would be of concern to a network operator, and
   the current version focuses on peer vulnerabilities to clients.

   Currently those threats from clients mainly include:

   (1).DoS Attack

   DoS attack appears on the host peer when malicious clients send out
   Inquire or Join messages to the host peer simultaneously.  It may be
   weakened using some enrollment control, but there is no any efficient
   method to resolve it.




Song, et al.             Expires August 25, 2008               [Page 26]


Internet-Draft           P2PSIP Client Protocol            February 2008


   (2).Cheat Attack

   Cheat attack appears on the host peer when malicious clients
   counterfeit authenticated clients.  One method to resolve this
   problem is to use encryption to keep communication privacy.


10.  IANA Considerations

   Message Type: this document introduces a new type of message as
   below:

   Message Type       Name
   12                Inquire

   Attribute Type: this document introduces two new types of attributes
   as below:

   Attribute Type       Name
   17                 Uptime
   18                 Overlay Info
   19                 Security

   Response Code: this document introduces some new response definitions
   as below:

   Response Code        Name
   404                Authentication Required
   405                Authentication Failed
   406                Contributed Space Required
   407                Not Found
   408                Request Failed
   409                Request Rejected
   410                Join Request Deferred
   431                Leave Request Deferred
   432                Overlay Service Interrupt
   433                Message Too Large
   434                Unrecognized message type
   435                Unrecognized object type
   436                Request Timeout


11.  Appendix

   Here is a sample of P2PSIP client protocol, depicted as Figure 13.

   Client-1            Peer-1               Peer-2              Peer-3
    |                    |                     |                     |



Song, et al.             Expires August 25, 2008               [Page 27]


Internet-Draft           P2PSIP Client Protocol            February 2008


    |    (1).Inquire     |                     |                     |
    |------------------->|                     |                     |
    |                    |    (2).Inquire      |                     |
    |--------------------|-------------------->|                     |
    |                    |                     |                     |
    | (3).Response w/200 |                     |                     |
    |<-------------------|                     |                     |
    |                    |  (4).Response w/200 |                     |
    |<-------------------|---------------------|                     |
    |                    |                     |                     |
    |                    |    (5).Join         |                     |
    |--------------------|-------------------->|                     |
    |                    |  (6).Response w/404 |                     |
    |<-------------------|---------------------|                     |
    |                    |                     |                     |
    |                    |    (7).Join         |                     |
    |--------------------|-------------------->|                     |
    |                    |  (8).Response w/200 |                     |
    |<-------------------|---------------------|                     |
    |                    |                     |                     |
    |                    |    (9).Put          |                     |
    |--------------------|-------------------->|                     |
    |                    |                     |     (10).Put        |
    |                    |                     |-------------------->|
    |                    |                     | (11).Response w/200 |
    |                    |                     |<--------------------|
    |                    | (12).Response w/200 |                     |
    |<-------------------|---------------------|                     |
    |                    |                     |                     |
    |                    |    (13).Get         |                     |
    |--------------------|-------------------->|                     |
    |                    |    (14).Get         |                     |
    |                    |<--------------------|                     |
    |                    | (15).Response w/200 |                     |
    |                    |-------------------->|                     |
    |                    | (16).Response w/200 |                     |
    |<-------------------|---------------------|                     |
    |                    |                     |                     |
    |                    |  (17).Keep-alive    |                     |
    |--------------------|-------------------->|                     |
    |                    | (18).Response w/200 |                     |
    |<-------------------|---------------------|                     |
    |                    |                     |                     |
    |                    |  (19).Keep-alive    |                     |
    |--------------------|-------------------->|                     |
    |                    | (20).Response w/200 |                     |
    |<-------------------|---------------------|                     |
    |                    |                     |                     |



Song, et al.             Expires August 25, 2008               [Page 28]


Internet-Draft           P2PSIP Client Protocol            February 2008


    |                    |                (Congest)                  |
    |                    |  (21).Notify        |                     |
    |<-------------------|---------------------|                     |
    |                    | (22).Response w/200 |                     |
    |--------------------|-------------------->|                     |
    |    (23).Join       |                     |                     |
    |------------------->|                     |                     |
    |(24).Response w/404 |                     |                     |
    |<-------------------|                     |                     |
    |    (25).Join       |                     |                     |
    |------------------->|                     |                     |
    |(26).Response w/200 |                     |                     |
    |<-------------------|                     |                     |
    |                    |                     |                     |


                   Figure 13 P2PSIP Client Protocol Sample


12.  References

12.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
   Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
   Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January
   2005.

   [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
   of Extensions to the Session Initiation Protocol (SIP)", RFC 4485,
   May 2006.

   [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Huitema, C., Mahy, R.,
   and D. Wing, "Simple Traversal Underneath Network Address Translators
   (NAT) (STUN)", draft-ietf-behave- rfc3489bis-08 (work in progress),
   July 2007.

   [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for
   Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in progress),



Song, et al.             Expires August 25, 2008               [Page 29]


Internet-Draft           P2PSIP Client Protocol            February 2008


   June 2007.

   [I-D.pascual-p2psip-clients] Pascual, V., "P2PSIP Clients",
   draft-pascual-p2psip-clients-01 (work in progress), February 2008.

   [I-D.jiang-p2psip-sep] X. Jiang, "Service Extensible P2P Peer
   Protocol", draft-jiang-p2psip-sep-00 (work in progress), November
   2007.

   [I-D.garcia-p2psip-dns-sd-bootstrapping], "P2PSIP bootstrapping using
   DNS-SD", draft-garcia-p2psip-dns-sd-bootstrapping-00(work in
   progress), October 2007.

   [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and C. Huitema,
   "Obtaining Relay Addresses from Simple Traversal Underneath NAT
   (STUN)", draft-ietf-behave-turn-04 (work in progress), July 2007.

   [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity
   Establishment (ICE): A Methodology for Network Address Translator
   (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-17
   (work in progress), July 2007

   [I-D.bryan-p2psip-requirement] D. Bryan, "P2PSIP Protocol Framework
   and Requirements", draft-bryan-p2psip-requirements-00 (work in
   progress), July 2007

   [P2PSIP-Concepts-Terminology] Dean Willis, "P2PSIP Concepts and
   Terminology",
   http://www3.ietf.org/proceedings/07jul/slides/p2psip-13.pdf, July
   2007

12.2.  Informative References

   [I-D.bryan-p2psip-dsip] Bryan, D., "dSIP: A P2P Approach to SIP
   Registration and Resource Location", draft-bryan-p2psip-dsip-00 (work
   in progress), February 2007.

   [I-D.bryan-p2psip-reload] Bryan, D., "REsource LOcation And Discovery
   (RELOAD)", draft-bryan-p2psip-reload-00 (work in progress), June
   2007.

   [I-D.baset-p2psip-p2pp] S. Baset, "Peer-to-Peer Protocol (P2PP)",
   draft-baset-p2psip-p2pp-00 (work in progress), July 2007.

   [I-D.Jennings-p2psip-asp] C. Jennings, "Address Settlement by Peer to
   Peer", draft-jennings-p2psip-asp-00 (work in progress), July 2007.

   [I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP



Song, et al.             Expires August 25, 2008               [Page 30]


Internet-Draft           P2PSIP Client Protocol            February 2008


   Extensions for Implementing a Passive P2PSIP Overlay Network based on
   the CAN Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00
   (work in progress), June 2007.

   [I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport
   Function in P2PSIP using HIP for Multi-Hop Overlay Routing",
   draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007.


Authors' Addresses

   Song Yongchao
   Huawei
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-84565081
   Fax:   +86-25-84565070
   Email: melodysong@huawei.com


   Jiang Xingfeng
   Huawei
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-84565079
   Fax:   +86-25-84565070
   Email: jiang.x.f@huawei.com


   Zheng Hewen
   Huawei
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-84565467
   Fax:   +86-25-84565354
   Email: hwzheng@huawei.com









Song, et al.             Expires August 25, 2008               [Page 31]


Internet-Draft           P2PSIP Client Protocol            February 2008


   Hui Deng
   China Mobile
   53A, Xibianmennei Ave. Xuanwu District
   Beijing  100053
   P.R.China

   Email: denghui@chinamobile.com












































Song, et al.             Expires August 25, 2008               [Page 32]


Internet-Draft           P2PSIP Client Protocol            February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.











Song, et al.             Expires August 25, 2008               [Page 33]


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