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

Versions: 00 01

P2PSIP                                                   XingFeng. Jiang
Internet-Draft                                              HeWen. Zheng
Intended status: Standards Track                            Huawei Tech.
Expires: August 4, 2008                                        C. Macian
                                                              V. Pascual
                                                 Pompeu Fabra University
                                                       February  1, 2008


                  Service Extensible P2P Peer Protocol
                     draft-jiang-p2psip-sep-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 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes the Service Extensible Protocol (SEP), which
   is the peer protocol spoken between P2PSIP Overlay peers to share
   information and organize the P2PSIP Overlay Network.  SEP uses a
   flexible forwarding mechanism to avoid congestion in the Overlay.  It
   also proposes a general service discovery method and a built-in NAT



Jiang, et al.            Expires August 4, 2008                 [Page 1]


Internet-Draft                 P2PSIP SEP                 February  2008


   traversal mechanism.  By using these methods, SEP tries to improve
   the success rate and reduce the latency of the transaction.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Routing States . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Data Operations  . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Data Transfer During the Overlay Churn . . . . . . . . . .  7
   4.  Design Choice  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Service Discovery  . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Relaying Peer  . . . . . . . . . . . . . . . . . . . . . . 10
       4.2.1.  Cases in which Relaying Peers Help . . . . . . . . . . 10
       4.2.2.  Locating  Relaying Peer  . . . . . . . . . . . . . . . 10
       4.2.3.  How to Use Relaying Peer . . . . . . . . . . . . . . . 11
     4.3.  Routing Mode . . . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  Flexible Routing Mechanism . . . . . . . . . . . . . . . . 12
     4.5.  End-to-end Reliability . . . . . . . . . . . . . . . . . . 12
   5.  Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Message Header . . . . . . . . . . . . . . . . . . . . . . 14
     5.2.  Message Attribute  . . . . . . . . . . . . . . . . . . . . 15
       5.2.1.  TLV Format . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.2.  Peer Address Info  . . . . . . . . . . . . . . . . . . 15
       5.2.3.  Peer service capability  . . . . . . . . . . . . . . . 16
       5.2.4.  Peer-ID  . . . . . . . . . . . . . . . . . . . . . . . 17
       5.2.5.  Source Peer Info . . . . . . . . . . . . . . . . . . . 17
       5.2.6.  Destination Peer Info  . . . . . . . . . . . . . . . . 18
       5.2.7.  Resource Info  . . . . . . . . . . . . . . . . . . . . 18
       5.2.8.  Negotiation Info . . . . . . . . . . . . . . . . . . . 20
       5.2.9.  Response Attribute . . . . . . . . . . . . . . . . . . 20
       5.2.10. Service Peer Info  . . . . . . . . . . . . . . . . . . 20
       5.2.11. Relaying Peer Info . . . . . . . . . . . . . . . . . . 22
       5.2.12. Source Reflexive Address attribute . . . . . . . . . . 22
       5.2.13. Routing table  . . . . . . . . . . . . . . . . . . . . 23
       5.2.14. Status Info  . . . . . . . . . . . . . . . . . . . . . 23
       5.2.15. Event Info . . . . . . . . . . . . . . . . . . . . . . 23
       5.2.16. Update Type  . . . . . . . . . . . . . . . . . . . . . 24
       5.2.17. Overlay Configuration Info . . . . . . . . . . . . . . 24
   6.  Peer Protocol Message  . . . . . . . . . . . . . . . . . . . . 25
     6.1.  Overlay Maintenance  . . . . . . . . . . . . . . . . . . . 25
       6.1.1.  JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 25
       6.1.2.  LEAVE  . . . . . . . . . . . . . . . . . . . . . . . . 27
       6.1.3.  KEEPALIVE  . . . . . . . . . . . . . . . . . . . . . . 28
       6.1.4.  NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 29
       6.1.5.  UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 29



Jiang, et al.            Expires August 4, 2008                 [Page 2]


Internet-Draft                 P2PSIP SEP                 February  2008


       6.1.6.  SearchPeer . . . . . . . . . . . . . . . . . . . . . . 30
       6.1.7.  TRANSFER . . . . . . . . . . . . . . . . . . . . . . . 31
     6.2.  Data Operations  . . . . . . . . . . . . . . . . . . . . . 31
       6.2.1.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 32
       6.2.2.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 32
       6.2.3.  REMOVE . . . . . . . . . . . . . . . . . . . . . . . . 33
     6.3.  Additional messages  . . . . . . . . . . . . . . . . . . . 33
       6.3.1.  LookUpServicePeer  . . . . . . . . . . . . . . . . . . 33
   7.  Routing Operations . . . . . . . . . . . . . . . . . . . . . . 35
     7.1.  Request Routing  . . . . . . . . . . . . . . . . . . . . . 35
     7.2.  Response Routing . . . . . . . . . . . . . . . . . . . . . 36
       7.2.1.  Response Routing on the Destination Peer . . . . . . . 36
       7.2.2.  Response Routing on the Intermediate Peer  . . . . . . 36
   8.  General Peer Behavior  . . . . . . . . . . . . . . . . . . . . 37
     8.1.  Source Peer Behavior . . . . . . . . . . . . . . . . . . . 37
       8.1.1.  Generating the Request and Sending the Request . . . . 37
       8.1.2.  Processing the Response  . . . . . . . . . . . . . . . 38
     8.2.  Intermediate Peer Behavior . . . . . . . . . . . . . . . . 39
       8.2.1.  Request Processing . . . . . . . . . . . . . . . . . . 39
       8.2.2.  Response Processing  . . . . . . . . . . . . . . . . . 39
     8.3.  Destination Peer Behavior  . . . . . . . . . . . . . . . . 40
       8.3.1.  Request Processing . . . . . . . . . . . . . . . . . . 40
       8.3.2.  Response Generation and Sending the Response . . . . . 40
   9.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . . . 40
     9.1.  Gather ICE candidates  . . . . . . . . . . . . . . . . . . 41
     9.2.  Response from the Destination Peer to the Source Peer  . . 42
       9.2.1.  How to Make JOIN Response Return to Source Peer  . . . 42
     9.3.  Exchange Candidates for the Direct Communication . . . . . 43
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 43
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 44
     13.2. Informative References . . . . . . . . . . . . . . . . . . 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 46















Jiang, et al.            Expires August 4, 2008                 [Page 3]


Internet-Draft                 P2PSIP SEP                 February  2008


1.  Introduction

   This document proposes a Service Extensible Protocol (SEP), which is
   spoken between P2PSIP peers.  The SEP conforms to the definition of
   P2PSIP Peer protocol in [concept].  Like the definition, SEP not only
   maintains the P2PSIP overlay topology, but also provides distributed
   database service.

   1.  SEP uses a flexible packet forwarding mechanism so that peers
       could choose the best peer to route the packet further.  For
       example, if a peer selects a downstream peer which has no enough
       resource at that time, then the requests may be discarded by the
       downstream peer.  So the upstream peer could choose another
       downstream peer which is in good condition.
   2.  In P2PSIP, peers offer storage and transport services to allow
       the distributed database function and distributed transport
       function to be implemented.  It is expected that individual peers
       may also offer other services.  SEP provides a common method for
       service discovery, i.e. to discover which peers could provide a
       specific service.  Some of these additional services (for
       example, a STUN server [STUN]) may be required to allow the
       overlay to form and operate, while others (for example, a
       voicemail service) may be enhancements to the basic P2PSIP
       functionality [concept].
   3.  The routing modes taken by the SEP attempts to make the
       transaction with lower latency and higher success rate even if
       the intermediate peers fail or NATs are between the source and
       the destination peers.


2.  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 RFC 2119 [1].

   Some of the terminologies are borrowed from the [concept].

   O Routing states: it is a general description of the information used
   to route packets through the overlay.  Several kinds of routing
   states exist.  Routing table and neighbor table are two examples.

   O Service peer: peers who provide one or more services in addition to
   routing and storage service.

   O Public peer: peers who are on the public Internet.  In case P2PSIP
   system uses a private addressing scheme, the address realm is also
   considered public if the peers in the realm could be reached by any



Jiang, et al.            Expires August 4, 2008                 [Page 4]


Internet-Draft                 P2PSIP SEP                 February  2008


   other peer.

   O Upstream peer/downstream peer: they are paired with each other.
   Downstream peers often appear in the routing states of a upstream
   peer and receives packets from upstream peer directly.

   O Transaction: a transaction is initiated by the source peer and
   comprises a request and several responses.  Transaction is an end-to-
   end concept and is uniquely identified by the tuple, including a
   source peer-ID, a destination ID, a message type, transaction ID
   (chosen by the source peer).

   O Relaying peer: peers are willing to relay response destined to the
   source peer of the request.  One example of relaying peers is a peer
   which is located on the public Internet and could be directly reached
   by any peer without any prior negotiations between them so long as
   other peers have the relay peer's transport address.

   O Dialog: is a peer-to-peer long-term relationship between two peers
   and is uniquely identified by a dialog identifier.  It represents a
   context that facilitates the sequencing of messages (i.e. maintain
   states) between the peers and proper routing of requests between both
   of them.  Not all peer protocol requests create dialogs.  The
   requests that create the dialogs need well-defined mechanisms of
   establishing and tearing down the dialog.  An example of a dialog may
   be the long-term relationship between a peer X and its replica Y.
   Peer X is a responsible peer which has several replicas (Peers which
   are responsible for maintaining and storing the same information)
   within the overlay.  Peer X may establish a long-term relationship
   (i.e. one dialog) with each replica and may need to maintain their
   information and state.  When a replica Y decides to stop serving as
   such or Peer X decides to leave the overlay, the dialog should be
   torn down.  Other example may be when a peer joins or (gracefully)
   leaves the P2P overlay network, data transfer operations will be
   triggered.  The joining peer will be responsible for some <key,
   value> pairs and the leaving node SHOULD transfer its stored <key,
   value> pairs to its neighbors.  When several transfer transactions
   take place between two nodes a dialog may be established to keep
   control over the status of the relationship.


3.  Overview

   Each peer in the overlay keeps its own routing states, including a
   routing table, a neighbor table or other states which are maintained
   by the DHT algorithms.  According to the DHT algorithms, the peer
   must learn other peers' information and communicate with them.  So
   the routing states not only keep the network reachability information



Jiang, et al.            Expires August 4, 2008                 [Page 5]


Internet-Draft                 P2PSIP SEP                 February  2008


   of its downstream peers, but can also be extended to store other
   information of its downstream peers, for example, service capability,
   processing status, etc.

   Peers with heterogeneous capability make up of the P2PSIP overlay.
   SEP attempts to benefit from the heterogeneity among the peers and
   mitigates the bad effect resulting from it at the same time.  Some
   peers could provide other service in addition to the routing and
   storage service which are the required services for peers.  These
   additional services include STUN, STUN Relay, etc, which are needed
   by other peers, for example, which are behind the NAT.  In terms of
   processing resource, such as bandwidth, CPU cycles, they are also
   heterogeneous.  This kind of heterogeneity may make the less powerful
   peer congested by the messages from the more powerful peers and fail
   the transactions processed by the congested peers.  In this case, a
   simple flow control mechanism between immediate peers combined with a
   flexible forwarding mechanism would make the situation better.

   The communication between peers may not work in the presence of the
   NAT.  The IETF has developed the STUN/TURN/ICE protocols to address
   this problem.  SEP works with these proposals and also provides a
   relay peers to facilitate the NAT traversal.

3.1.  Routing States

   Each peer should maintain routing states and route packets by
   choosing the next hop peer from the routing states.  The routing
   states should be updated as the overlay topology changes.  Here, we
   give an example data organization of routing states, and explain each
   item in the entry.  Although this is an implementation issue,
   comprehension on the routing states will make reader understand SEP
   easier.

   In current DHT algorithms, there are often two kinds of routing
   states: routing table and neighbor table.  Routing table is often
   asymmetric and neighbor table is symmetric.  Peers in the routing
   states are also called P2PSIP neighbors defined in the [concept].  It
   means the peer could reach these peers directly without further
   lookup.

   The routing states are often comprised of several entries.  Each
   entry keeps the information about the P2PSIP neighbors.  The
   information about the P2PSIP neighbors might be organized as follows.

   O Peer-ID: which uniquely identifies a peer in the overlay.

   O Workable candidate pairs: this item records several candidate pairs
   which are found by using ICE procedure.  By using them, peers could



Jiang, et al.            Expires August 4, 2008                 [Page 6]


Internet-Draft                 P2PSIP SEP                 February  2008


   communicate with its neighbors directly.  Two or more workable
   candidate pairs could improve the stability of the P2PSIP peer
   control connection.

   O Current processing status: this item reflects the processing status
   of the peer's neighbors.  The possible status may be simply
   classified into normal or busy.  They also may be measured by some
   quantitative parameters, such as CPU idle percentage, available
   bandwidth, etc.

   O Service capability: it gives information about additional services
   supported by the peer.  Having this kind of information in mind, the
   peer learns which neighbors could provide a specific service.

   Note: here, we just list some basic items of the information about
   the P2PSIP neighbors.  This information is not exhaustive and will be
   extended to support new functions if needed.

3.2.  Data Operations

   A peer may put multiple resource objects in the overlay under the
   same resource ID, and some peers may put various resource objects
   with the same resource ID.  Therefore, there may be multiple resource
   objects under the same resource ID.  SEP uses the owner identity and
   hash code accompanied with resource ID to locate the unique resource
   object.

   A resource object in the P2P overlay network can be any type of data,
   such as a contact address, a file, etc.  The size varies from one
   resource object to another.  Resource objects with small size can
   directly be put to or got from the overlay by carrying them in the
   PUT or GET message.  If the size is over some limit, it's more
   efficient to exchange the resource object using a direct connection.
   SEP supports both kinds of operation.  Negotiation information is put
   into the PUT or GET message to negotiate a direct data transport for
   the latter.

   The resource objects should be transferred from one peer to another
   when the overlay churns.  But the sending peer may not be aware of
   the state of the receiving peer, and whether the receiving peer is
   really responsible for the <key, value> pairs to be transferred.  SEP
   provides a TRANSFER operation with negotiation capability to solve
   these problems.

3.3.  Data Transfer During the Overlay Churn

   In P2P overlay, peers can join and leave the overlay at any time.
   Therefore two operations of data moving and routing states update



Jiang, et al.            Expires August 4, 2008                 [Page 7]


Internet-Draft                 P2PSIP SEP                 February  2008


   should be performed accordingly.  During the churn, some data may be
   placed on the wrong peer because the two operations can't keep pace
   with each other.  In the meantime, a lookup operation for a key may
   fail in that the data associated with the key is not on the correct
   root peer.

   SEP attempts to reduce the failure possibility of the transaction
   during the overlay churn.  The idea is to make the joining peer or
   leaving peer work together with its neighbors to serve the coming
   lookup operations.  For example, when a peer is about to leave the
   network, it could transfer <key, value> pairs to its neighbors and
   notify other peers its departure simultaneously.  Before the transfer
   completes, both the leaving peer and its neighbors may be the target
   of the lookup operation due to routing states update in other peers.
   So they could serve the lookup operation together by leading the
   requests to which if they have no answer to the others.


4.  Design Choice

   In this section, some considerations about the SEP's design are
   presented.  The principle behind the design is to make the
   transaction with shorter latency and higher success rate even in the
   environment where peers churn frequently and some peers may be
   overloaded by traffic.  So we choose the semi-recursive routing mode
   combined with overlay native routing mode and propose a flexible
   forwarding mechanism to avoid the congestion in the overlay.  Other
   design choices such as end-to-end reliability and service discovery
   are also discussed in this section.

4.1.  Service Discovery

   The nature of peer-to-peer computing is that each peer offers
   services to other peers to allow the overlay to collectively provide
   larger functions [concept].  For example, routing and storage service
   provided by each peer enable the distributed database function of the
   overlay, where any peer may store any data under a key and any other
   peer may fetch it using the same key.  Since there exists
   heterogeneity in peers' capabilities, as pointed out by the
   descriptions in section 2.1 of [concept], some additional services
   other than routing and storage will be needed.  Thus, two kind of
   services may exist: those well-known and common in most overlays and
   required to allow the overlay to form and operate (for example, a
   STUN server [rfc3489bis]), and others which are enhancements to the
   basic P2PSIP functionality (for example, a voicemail service) and are
   specific for a given overlay.  In both cases, service discovery
   procedures are required in order to discover services and their
   operation.  SEP proposes three methods to do the service discovery,



Jiang, et al.            Expires August 4, 2008                 [Page 8]


Internet-Draft                 P2PSIP SEP                 February  2008


   i.e. service search based on well-known service names, random walk
   through the overlay and neighbors' service publication.

   The first method consists on performing a regular overlay search
   based on the well-known Resource ID of a given service.  To that end,
   the responsible node must have previously published (i.e., PUT) the
   Resource ID in the overlay.The second one, random walk through the
   overlay, tries to get the Peer ID of the responsible service peers by
   walking hop-by-hop through the ovelay and getting information
   provided by intermediate peers until one peer gives a response.  In
   the last method, each peer's routing state intends to store its
   neighbors' service capabilities, i.e. which kinds of service its
   neighbors could provide.  Then, the service capability information is
   advertised through the overlay maintenance mechanism as is described
   in section 3.1.

   SEP provides a message LookUpServicePeer for the peer to attempt to
   collect the service peers providing a non-well-known service by
   walking through the overlay.  The peer in need of a specific service
   will send a LookUpServicePeer message in which the service taxonomy
   type is indicated and the destination ID could be chosen at random.
   Then the intermediate peers receiving the message will check whether
   there are peers in its routing states providing the desired service.
   If there is at least one peer, the intermediate peer would insert the
   information in the request and route the request further.  In the
   end, the destination peer will return the information to the source
   peer in the response.  So, the service discovery is made by randomly
   routing the packet through the overlay.  The source peer could try
   different destination IDs and make sure to get more service peers'
   information.  If LookUpServicePeer messages are sent several times,
   we could choose different destination IDs to make the message go
   through different paths, so that the source peer will have a chance
   to ask more peers.

   What information SEP intends to get is to learn the reachability
   information of these service peers.  It does not care about whether
   the service peers are capable of serving the peers in need of this
   service at the moment.  With several service peers in mind, the peer
   in need of the service could try all service peers until it gets
   served.  As for how to choose the best service peer, it is hard to
   achieve.  But in SEP, if every peer which provides a specific service
   could update its service status and keep it in the routing states as
   described in section 2.1, the peers who look for service peers may
   choose based on their associated service status.  Service delivery is
   done by setting up a session to a service provider peer or any other
   way of interaction with the specified peer.  This procedure is out of
   the scope of this draft.  However, in this process the current status
   of the service COULD be communicated, so that the requesting node can



Jiang, et al.            Expires August 4, 2008                 [Page 9]


Internet-Draft                 P2PSIP SEP                 February  2008


   make an updated decision as to which serving node to contact.

4.2.  Relaying Peer

   Some peers may be visited directly by other peers.  This kind of
   peers will help communications between peers who need to exchange
   information, but have no direct connection yet.  These peers could
   relay messages between peers mentioned above.  Here, we call these
   peers realying peer.

4.2.1.  Cases in which Relaying Peers Help

   The use of relaying peer could help message traverse NAT and reach
   its recipient.  Further, it could also improve transactions'
   reliability due to fewer hops.  Here, we list cases where relaying
   peers are suited to be applied.

   1.  In semi-recursive routing mode, if the source peer sending a
       request is behind NAT, the response is hard to be returned to the
       source peer directly.  With the use of a relaying peer, the
       relaying peer receives the response from a peer and relays it to
       the source peer.
   2.  In recursive routing mode, peers often use the reverse
       connections to its upstream peers to route the response.
       However, the reverse connections may break down when the peer
       receives a response.  The reasons for the breakdown are various,
       for example, when the upstream peer has left the overlay, or TURN
       server between two peers has failed, or NATs between two peers
       reboot, etc.  In this case, the peer could attempt to send the
       response to the source peer with the hlep from a relaying peer.

4.2.2.  Locating  Relaying Peer

   Before asking for help from relaying peers, a peer should locate
   where the relaying peers are.  There are two requirements on the
   peers who are eligible for a relaying peer.

   1.  The peer SHOULD have a unrestricted connectivity.  It may be on
       the Internet or behind the p2p-friendly NAT.  All in all, other
       peer could reach it so long as they have relaying peers'
       transport address.
   2.  The relaying peer SHOULD know how to send a response to the
       source peer when the source peer is behind NAT.  It could be
       achieved at least by two means.  One is to choose its own
       neighbor peer as its relaying peer because they have already
       established direct connections.  The other is to send the request
       directly to the its chosen relaying peer and the relaying peer
       keeps state of the source peer's transport address based on the



Jiang, et al.            Expires August 4, 2008                [Page 10]


Internet-Draft                 P2PSIP SEP                 February  2008


       incoming request or carry the address in the request and get from
       the response again the source peer's transport address which will
       be used to relay response to the source peer.

   We could think of the relaying peer as a service, so service
   discovery method in section 4.1 could be used to locate relaying
   peer.  On the other side, the peer could also check whether there are
   peers which could be relaying peers in its neighbor peer set.

4.2.3.  How to Use Relaying Peer

   A few general steps will be followed if the peer want to get the help
   from the relaying peer.
   1.  Locating relaying peers first;
   2.  The peer stores the information about its chosen relaying peer in
       the request and convey them to other peer which may send it
       response back directly;
   3.  Based on whether direct connection between the peer and the
       relaying peer exists or not, the peer may either send the request
       directly to the relaying peer or not;
   4.  The destination peer will send the response to the relaying peer
       which has been communicated to the destination peer in the
       request.

4.3.  Routing Mode

   Several routing modes are often used to realize the P2PSIP
   transaction.  P2PSIP requests have to be routed through the overlay
   by using the overlay routing states, but the responses have several
   choices to return to the source peer, either directly or in the
   reverse path or in a sepearte path based on the source peer ID.

   In the following figure, we compare four routing modes from three
   perspectives: difficulty of NAT traversal, resilient from the failure
   of intermediate peers and the latency of the transaction.

   +----------------+--------------+---------------------+-------------+
   | Routing Mode   | Difficulty   | Resilient from the  | Latency of  |
   |                | of NAT       | failure of          | the         |
   |                | traversal    | intermediate peers  | transaction |
   +----------------+--------------+---------------------+-------------+
   | iterative      | high         | high                | high        |
   | recursive      | low          | high                | medium      |
   | semi-recursive | medium       | high                | low         |
   | overlay native | low          | high                | high        |
   +----------------+--------------+---------------------+-------------+

             Figure 1 the comparison of the four routing modes



Jiang, et al.            Expires August 4, 2008                [Page 11]


Internet-Draft                 P2PSIP SEP                 February  2008


   For iterative mode, NAT traversal is a big problem and the
   transaction latency is higher.  Recursive mode has little trouble in
   traversing NAT, but transaction will be prolonged due to the
   breakdown of any reverse connection in the reverse path.  As for
   overlay native mode, the response is still routed to the source peer
   through the overlay and hence the transaction's latency is also high.
   Semi-recursive mode has good balance between the three perspectives.
   The response is returned to the source peer directly.  The only
   problem in the semi-recursive mode is that the response may not reach
   the source peer due to the existence of NAT.

   SEP takes the two routing modes from them, semi-recursive mode and
   overlay native routing mode.  In most cases, semi-recursive mode
   works.  Overlay native mode may be used once semi-recursive mode has
   failed.  As for NAT traversal in semi-recursive mode, SEP's solution
   is for the source peer to convey some relaying peers to the
   destination peer so that the destination peer could send the response
   to these peers who relays the response to the source peer.  Of
   course, if the source peer is on the public Internet, the destination
   peer could reach the source peer directly.

4.4.  Flexible Routing Mechanism

   Because of the heterogeneity in peers' bandwidth, processing power
   and traffic load, some less powerful peers may be overloaded by
   excess messages.  Under this condition, the connection between the
   peer with its overloaded downstream peers seems in a good state, but
   its processing capability has decreased greatly.  If the upstream
   peer still route message to the overloaded downstream peer, the
   message may be discarded or experience longer delay.

   On the other hand, there are often a great number of paths between
   two peers in the overlay.  The peer will have several downstream
   peers at hand as its candidate next hop peers when routing a specific
   message.  So it could choose the next hop peer based on the
   downstream current status.

   SEP supports status notification from the downstream peers and also
   do flexible routing based on the advertised status.

4.5.  End-to-end Reliability

   Reliability is very important for the transaction in the peer
   protocol.  The transaction comprises of requests and responses.
   Because peer protocol messages will be delivered to the destination
   hop-by-hop, it is hard to achieve end-to-end reliability for the
   transaction.  The reason for this is that source peer does not know
   where the destination peer is before the request really reaches the



Jiang, et al.            Expires August 4, 2008                [Page 12]


Internet-Draft                 P2PSIP SEP                 February  2008


   destination.  So it could not rely on TCP to ensure end-to-end
   reliability.  Although every hop in the path could be TCP
   connections, it only guarantees the reliability between the immediate
   peers.  The behavior of the intermediate peers may break the end-to-
   end reliability, for example, dropping packets.

   It seems that application retransmission mechanism is the only answer
   to the end-to-end reliability.  If the source peer could not receive
   the response within the expected time, it could retransmit the
   request.  It works for the simple request-response communication.

   Open issue 1: how does the source peer set the retransmission timeout
   timer?  Does the value used in the conventional SIP work well in P2P
   case?


5.  Message Syntax

   SEP protocol messages comprises of two parts: message header and some
   attributes expressed in a TLV style.

   O Message header: it contains some information for forwarding
   operations, for example, destination ID, message type and some
   options; and other information used to for the source peer to match
   the response with the request, including source peer ID, destination
   ID, transaction ID.

   O Attributes: in order to make SEP extensible, TLV-style attributes
   is used to express attributes.  In order to support new operations,
   we are not only able to add new messages, but able to add new
   attributes.  Every attribute may be composed of other attributes with
   the TLV-style.



















Jiang, et al.            Expires August 4, 2008                [Page 13]


Internet-Draft                 P2PSIP SEP                 February  2008


5.1.  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|   Reserved  | Message Type  |      TTL      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Message Length          |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Transaction-ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Source Peer ID = 128bit                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Destination ID = 128bit                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version (4 bit): Indicates the version of the SEP protocol.  The
   current version is 0x01;

   R (1 bit): If it is set, used to indicate that this message is a
   response.

   H (1 bit): If it is set, used to indicate to the intermediate peers
   that this message should be processed in terms of the message type in
   addition to forwarding operation.

   D (1 bit): If it is set, it indicates to the destination peer that
   the source peer thinks that a direct connection SHOULD be negotiated
   and established after this transaction.

   F (1 bit): If it is set, it means the response should be processed in
   the relay mode.

   J (1 bit): If it is set, it means that it has been processed only by
   the source peer.

   Message type (8 bit): type of the message.

   TTL (8 bit): time-to-live.  It indicates the number of hops which a
   message is allowed to traverse before it is discarded.

   Message Length (16 bit): indicates the length of the message,
   including the message header and the following variable attributes.

   Transaction-ID (32 bit): It is randomly assigned by the source peer
   and in order to match the response with the request.

   Source Peer-ID (128 bit): indicates the Peer-ID of the source peer



Jiang, et al.            Expires August 4, 2008                [Page 14]


Internet-Draft                 P2PSIP SEP                 February  2008


   who initiates the request.

   Destination ID (128 bit): either a destination Peer-ID or a
   destination key.  Its function is for the P2P overlay to get the
   packet delivered to the destination peer.

5.2.  Message Attribute

   In this draft, we define several message attributes that are
   expressed in a TLV-style.

5.2.1.  TLV Format

       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +  Value - variable length                                      +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M (1 bit): It indicates that the attribute MUST be understood by the
   peers who intend to process them.  If the attribute could not be
   understood by the processing peers, the message MUST be discarded or
   return a error response.

   Type (8 bit): It indicates the type of the attribute.

   Length (16 bit): the byte length of the attribute.

5.2.2.  Peer Address Info

   Attribute type: 0x00 ( to be assigned by IANA)
















Jiang, et al.            Expires August 4, 2008                [Page 15]


Internet-Draft                 P2PSIP SEP                 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              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Trans |  Type |   Reserved    |            Port               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Priority                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   IPv4  Address                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Trans (4 bit): it indicates the type of the transport protocol.  In
   this draft, we define two types: 0x00(TCP), 0x01(UDP).

   Type (4 bit): host (0x0), server reflexive (0x01), peer reflexive
   (0x02), relayed address (0x03).  The classification is the same as
   that in [ICE].

   Port (16bit): the port on which this peer listens for requests.

   Priority (32bit): It is used by ICE procedure to sort the candidate
   pair.  It is computed as suggested in [ICE].

   IPv4 Address: the IPv4 address of the peer.

5.2.3.  Peer service capability

   Attribute type: 0x01 ( to be assigned by IANA)

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

   This attribute is to express which services the peer could provide to
   the other peers.  Every bit in the value is used to indicate a
   specific service.  In this draft, we recommend the length of this
   attribute is 16 bit long and three services are defined.

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

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



Jiang, et al.            Expires August 4, 2008                [Page 16]


Internet-Draft                 P2PSIP SEP                 February  2008


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

5.2.4.  Peer-ID

   Attribute type: 0x02 ( to be assigned by IANA)

        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              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Peer-ID = 128bit                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Peer-ID conveys the Peer-ID of the specific peer.  The length of this
   field is 128bit.  Although not all DHT algorithms use 128 bit as the
   length of the Peer-ID, we think that 128 bit works for all DHT
   algorithms.

5.2.5.  Source Peer Info

   Source Peer Info is a composite attributes.  It is comprised of
   Peer-ID attribute, peer service capability attribute and several peer
   address info attributes.  This attribute carries a few source peer
   related information to other peers.

   Attribute type: 0x03 ( to be assigned by IANA)

       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Peer-ID                                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Peer service capability                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Peer Address Info - 1                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   ............                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Peer Address Info - N                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Jiang, et al.            Expires August 4, 2008                [Page 17]


Internet-Draft                 P2PSIP SEP                 February  2008


5.2.6.  Destination Peer Info

   Destination Peer Info is also a composite attribute.  Like the source
   peer info attribute, it is also comprised of Peer-ID attribute, peer
   service capability attribute and several peer address info
   attributes.  This attribute carries a few destination peer related
   information to the source peer.

   Attribute type: 0x04 ( to be assigned by IANA)

       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Peer-ID                                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Peer service capability                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Peer Address Info - 1                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   ............                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Peer Address Info - N                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.7.  Resource Info

   Attribute type: 0x05 ( to be assigned by IANA)






















Jiang, et al.            Expires August 4, 2008                [Page 18]


Internet-Draft                 P2PSIP SEP                 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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|O|H|C|      Value Type       |         Value Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                      Resource ID(16Bytes)                     +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Expiration Time(4Bytes,Optional)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +              Owner Identity(16Bytes,Optional)                 +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                 Hash Code(16Bytes,Optional)                   +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +              Value Content(variable length,Optional)          +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E (1 bit): If this bit is set, Expiration Time field MUST be
   included; otherwise not.

   O (1 bit): If this bit is set, Owner Identity field MUST be included;
   otherwise not.

   H (1 bit): If this bit is set, Hash Code field MUST be included;
   otherwise not.

   C (1 bit): If this bit is set, Value Content field MUST be included;
   otherwise not.

   Value Type: A 12-bit value, the type of application in which the
   value is used.  How to assign this value depends on the content to be
   stored in the overlay.  It will be developed in the later version.

   Value length: The number of Bytes in the value.

   Resource ID: A 16-byte value, the hash function result of the
   resource unique property.

   Expiration Time: Optional in the Resource Info, A 4-byte value



Jiang, et al.            Expires August 4, 2008                [Page 19]


Internet-Draft                 P2PSIP SEP                 February  2008


   indicate the expiration time of the resource object.

   Owner Identity: it specifies the owner of the Resource object.

   Hash Code: It is computed by hashing the resource objects.  It is
   used for integrity check.  A resource object must be put into the
   overlay with its owner identity and the hash code of the resource
   object.  The owner uses the owner identity and the hash code to
   refresh and modify the unique resource object, because a user may put
   several resource objects under the same resource ID.

   Value Content: when presented, its length is specified by the "Value
   Length" parameter.

5.2.8.  Negotiation Info

   Attribute type: 0x06 ( to be assigned by IANA)

   This attribute is used to negotiate the transport parameters for PUT
   or GET or TRANSFER operations.  Its format is to be determined.

5.2.9.  Response Attribute

   Attribute type: 0x07 ( to be assigned by IANA)

      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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Response code          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The following response codes are defined in this version.

   200: Successful request;

   401: Bad parameters;

   402: Could not find the corresponding data;

   403: The request is rejected for some reason;

5.2.10.  Service Peer Info

   Attribute type: 0x08 ( to be assigned by IANA)






Jiang, et al.            Expires August 4, 2008                [Page 20]


Internet-Draft                 P2PSIP SEP                 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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Num of Peers | Service Type  |   Max. Num    |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                      Peer-ID attribute  1                    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                Peer Address Info attribute 1                //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                     .............                           //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                      .............                          //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                      Peer-ID attribute N                    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                 Peer Address Info attribute N               //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   It is also a composite attribute.  It intends to collect the
   reachability information of peers which could support the service
   specified in the attribute.

   O Num of Peers (8 bit): this field records how many peers in this
   attribute.  It is set to zero while the source peer creates this
   attribute.  The number will be modified by the intermediate peers and
   destination peers when new peers are added.  This attribute should be
   returned to the source peer in the response from the destination
   peer.

   O Service type (8 bit): this field indicates which type of service
   the source peer wants to know.  In this draft, three service types
   are recommended.  They are STUN (0x00), TRUN relay (0x01) and
   Relaying Peer (0x02).

   O Max. Num (8 bit): this field indicates the maximum number of the
   service peers what the source peer wants.

   O Peer-ID attribute: this field has a type of Peer-ID attribute and
   records the Peer-ID information of the peers who provides the
   specified type of service.

   O Peer address info attribute: this field has a type of Peer Address
   Info attribute and records the transport address of the peers who
   could provide the specified type of service.





Jiang, et al.            Expires August 4, 2008                [Page 21]


Internet-Draft                 P2PSIP SEP                 February  2008


5.2.11.  Relaying Peer Info

   Attribute type: 0x09 ( to be assigned by IANA)

       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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Num of Peers |              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Peer Address Info attribute 1                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       .............                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       .............                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Peer Address Info attribute N                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This attributes intends to convey relaying peer information to the
   peer which would return response to the source peer directly.

   O Num of Peers: this field records the number of relaying peers
   supplied by the source peer.  It won't be changeed in transit.

   O Peer Address Info attribute: this filed has a type of the Peer
   Address Info attribute and records the reachability information of
   the relaying peers.

5.2.12.  Source Reflexive Address attribute

   Attribute type: 0x0A ( to be assigned by IANA)

       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Port             | Transport pro.|   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This attribute is often used in the case where bootstrap peer
   processes the JOIN request and record the source transport address of
   the JOIN request including IP address and the port observed by
   bootstrap peer.  This attribute will be delivered in the request and



Jiang, et al.            Expires August 4, 2008                [Page 22]


Internet-Draft                 P2PSIP SEP                 February  2008


   later in response unmodified.  When the Join response returns to the
   bootstrap peer, it will check this attribute and make it as the
   destination transport address of the JOIN response relayed by the
   bootstrap peer.  In this way, bootstrap peer won't keep state for the
   joining peer and make the response return to the Joining peer even
   though the Joining peer is behind NAT.

   O Port (16 bit): the port number observed by the bootstrap peer.

   O Transport Pro. : The type of transport protocol.  In this draft,
   two types are defined.  TCP (0x00) and UDP (0x01).

   O IPv4 address: the IP address observed by the bootstrap peer.

5.2.13.  Routing table

   Attribute type: 0x0B ( to be assigned by IANA)

   The attribute format depends on detailed DHT algorithm, so its format
   is TBD.

5.2.14.  Status Info

   Attribute type: 0x0C ( to be assigned by IANA)

      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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Congestion State        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Congestion State: indicates the current state of a peer. 0x00, a peer
   which states the peer is in good condition; 0x01, which means the
   peer is busy;.

5.2.15.  Event Info

   Attribute type: 0x0D ( to be assigned by IANA)











Jiang, et al.            Expires August 4, 2008                [Page 23]


Internet-Draft                 P2PSIP SEP                 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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Event  Type   |   Event Description (Variable length)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   O Event Type: Indicates that what kind of event has happened. 0x00
   means the sending peer is about to leave the overlay.  Others TBD.

   O Event Description: give the detailed description of this event.  It
   is informational.

5.2.16.  Update Type

   Attribute type: 0x0E ( to be assigned by IANA)

       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Update Type   |
      +-+-+-+-+-+-+-+-+

   Update Type: indicate what kind of Update operation the sending peer
   want the destination peer do. 0x00 means the receiving peer should
   check whether it should update its routing state; 0x01 means the
   sending peer requests routing table of the receving peer.

5.2.17.  Overlay Configuration Info

   Attribute type: 0x0F ( to be assigned by IANA)

















Jiang, et al.            Expires August 4, 2008                [Page 24]


Internet-Draft                 P2PSIP SEP                 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              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Num of DHT Algorithms        |   Reserved                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 DHT Algorithm Attribute 1                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       .............                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       .............                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 DHT Algorithm attribute N                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Other configuration parameters                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (Authentication credentials, etc.)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Num of Algorithms: The length of the DHT Algorithm Attribute list (N)
   The DHT Algorithm attribute is tbd, and could be dependent upon the
   characteristics of each DHT and its associated hash functions.

   The element MAY also contain additional configuration parameters,
   such as the authentication credentials of the joining node, an
   overlay ID specifying the Overlay to join (supposing that the
   bootstrap server is the admitting node for several overlays), etc.


6.  Peer Protocol Message

6.1.  Overlay Maintenance

6.1.1.  JOIN

   A peer MUST learn some necessary information before it wants to join
   the overlay, such as DHT algorithm, bootstrap peer list, its Peer ID,
   hash algorithm used to get the key and the like.  It could get that
   information by enrollment procedure or some other means which is not
   within the scope of this draft.  In SEP, the bootstrap peer MUST be
   on the public Internet.

   The joining procedure follows the general rules for setting up a
   session using SIP, combined with the authentication procedure: A
   first message is sent, specifying the desire to join and a summary of
   the joining node's capabilities; a challenge is sent back to the
   sender, and a new request containing the necessary credentials is



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


Internet-Draft                 P2PSIP SEP                 February  2008


   resent to the entry point to the network.  Finally, a response with
   the chosen communication parameters is sent to the joining node,
   serving as acknowledgment.

   The joining peer send an initial JOIN request to the bootstrap peer.
   This initial JOIN includes the Overlay Configuration Info attribute,
   containing the full list of supported DHT algorithms, in priority
   order, as well as supported hash functions.  Other Overlay-relevant
   configuration elements MAY also be included (tbd; e.g. the
   authentication credentials of the joining node).  The joining node
   MUST leave the Source Peer ID and Destination ID empty, since it
   initially does not know its own Peer ID.

   The bootstrap server, upon receiving the JOIN message, checks the
   Overlay Configuration Info element and compares it with the actual
   Overlay configuration parameters.  If this is the first joining node,
   then the initial joining node MAY define the working parameters for
   the Overlay, if the bootstrap node so allows.  Otherwise, the
   bootstrap node defines the working parameters.  How the bootstrap
   node gets this configuration information is out of the scope of this
   draft.  Nevertheless, manual configuration, taking into account
   factors such as the application scenario, number of potential peers,
   expected geographical distribution, etc.  MAY be taken into account.

   The bootstrap server then sends a JOIN Response to the joining node,
   including the Overlay Configuration Info attribute.  This attribute
   MUST contain the selected set of Overlay working parameters,
   including the chosen DHT algorithm and the hash function to calculate
   the Peer ID.

   Upon receiving the response, the joining node MUST calculate its own
   Peer ID according to the hash function and the DHT algorithm.  It
   MUST send a second JOIN message to the bootstrap peer, filling the
   Source Peer ID and the Destination ID with its own Peer ID.  If the
   joining peer is behind a NAT, it SHOULD set D flag in the message
   header to indicate to the destination peer that they should start an
   ICE negotiation with each other to find a direct connection for later
   communication.  Source Peer Info MUST be carried in the JOIN request.













Jiang, et al.            Expires August 4, 2008                [Page 26]


Internet-Draft                 P2PSIP SEP                 February  2008


   Join request =
                  Message Header
                  Overlay Configuration Info
                  Source Peer Info
                  [Relaying Peer Info]
                  [Source Reflexive Address]

   When a peer receives JOIN request, it checks the Destination ID to
   determine whether it is the destination of the join request. if it is
   not, the peer forwards the message to next peer which is closer to
   the destination.  If the peer is the destination of the JOIN request,
   the peer processes the message and sends JOIN response to the joining
   peer.The destination peer often sends its routing table to the
   joining peer in the response.  If the destination peer learns that
   source peer is behind NAT by check the Source Peer Info, it MUST set
   the D flag in the response.

   Join response =
                      Message Header
                      Overlay Configuration Info
                      Response Attribute
                      Destination Peer Info
                      [Source Reflexive Address]
                      [Routing Table]

   In the end, the joining peer receives the response.  If it is a 200
   OK response, the joining peer MAY use the routing table in the
   response to construct its own routing table.  If the D flag is set in
   the response, the joining peer SHOULD start ICE procedure to find out
   a direct path between them.

   JOIN operation will trigger data transfer from other peers to the
   joining peer.  These peers who will transfer data to the joining
   peers are often the neighbors of the joining peer.  After the
   transfer finishes, these neighbors will update their routing table to
   reflect the existence of the joining peer.

6.1.2.  LEAVE

   Before it leaves the overlay, a peer should transfer all the data to
   other peers, and other peers should update their routing table.  So
   the leave process MAY include the following steps:

   1.  The leaving peer sends LEAVE request to its neighbor peer(s);
   2.  the neighbor peer(s) expands the key region and updates the
       routing table;





Jiang, et al.            Expires August 4, 2008                [Page 27]


Internet-Draft                 P2PSIP SEP                 February  2008


   3.  the leaving peer notifies its upstream peers its departure;
   4.  the leaving peer starts data transfer process;
   5.  the leaving peer and the neighbor peer work together to serve the
       new requests;
   6.  After data transfer finishes, the leaving peer leaves the
       overlay;

   A leaving peer sends leave message to it's neighbor peers which
   depend on the DHT algorithms in use.

    Leave request =
                    Message Header
                    Source Peer Info

   The peer receiving the LEAVE message SHOULD consider whether it's
   responsible space in the overlay has changed due to the source peer's
   leave and then expand the responsible space accordingly.  If the
   neighbor peer receives message, the peer MAY either reply this
   request on its own if the associated data has been transferred from
   the leaving peer, or lead this request to the leaving peer.

   Leave response =
                    Message Header
                    Response Attribute
                    Destination Peer Info

   When the leaving peer receives the response, it could start data
   transfer operation to its neighbors and at the same time, it could
   notify any of its upstream peers its departure to accelerate the
   convergence of the overlay.  Before the transfer finishes, the
   leaving peer and its neighbors could work together to serve the
   requests in the overlay.  (TO DO: how they work together with various
   messages is to be developed further.)

   Open issue: How do the leaving peer and the neighbor peer work
   together to serve the new request?

6.1.3.  KEEPALIVE

   KEEPALIVE message is used by a peer to make sure whether the neighbor
   peers are still alive.  If a peer has not received KEEPALIVE response
   from the destination peer for several times, it could conclude that
   the destination peer is not alive and then should start to update its
   routing or neighbor table.  After receiving KEEPALVIE request, the
   destination peer MUST convey its status information in the KEEPALVIE
   response.  If a peer has received a KEEPALIVE message with a peer's
   current status which shows this peer is in the busy state, the peer
   SHOULD not forward packets to that congested peer until that peer



Jiang, et al.            Expires August 4, 2008                [Page 28]


Internet-Draft                 P2PSIP SEP                 February  2008


   reaches the normal state again.

   KEEPALIVE Request =
                       Message Header
                       Source Peer Info

   (preamble)
   KEEPALIVE Response =
                        Message Header
                        Response Attriubute
                        Destination Peer Info
                        Status info
   (postamble)

6.1.4.  NOTIFY

   The continuity and quality of service contributed by a peer is
   concerned by the other peers in the overlay.  After receiving an
   indication that a specified peer is interested in the status of the
   contributed service, the peer who contributed the service starts to
   monitor its service status for the specified peer, and then it
   informs the specified peer about the interesting service status
   information through a NOTIFY message when it finds that the service
   status changes (e.g. service quality degraded or service
   interrupted).  Those information includes: a)an event means that the
   peer will leave; b)an event means that the peer is coming into
   congestion state, etc.

   NOTIFY message =
                    Message Header
                    Source Peer Info
                    [EVENT] [STATUS INFO]

   When receiving notify message, peer MAY choose to update
   corresponding status according to the information in the request.

   Open Issue: As proposed in the section 4.4, current status
   advertisement from downstream peers will be useful to ease the
   congestion of the downstream peers.  How do these downstream peers
   measure its status?  When is the right time for them to advertise the
   status change?

6.1.5.  UPDATE

   UPDATE message is used to notify its existence in the overlay to its
   neighbors or request routing table from its neighbors.  The target
   peers of the UPDATE request depends on the DHT algorithms.  For
   example, neighbor may just mean the successor or predecessor in



Jiang, et al.            Expires August 4, 2008                [Page 29]


Internet-Draft                 P2PSIP SEP                 February  2008


   Chord, but it means all peers in its leaf set in Pastry.

   UPDATE provides two options for peers to update its own or its
   neighbors routing states.  One option is for the peer to notify its
   existence to its neighbors.  For example, after the joining peer
   finished JOIN transaction in Pastry, it should notify other neighbors
   to let them update its leaf set.  The other option is for the peer to
   request routing table from its neighbors.  In Pastry, peers may want
   to update its routing states after it checks some peers have been
   dead.  They often request routing table from its neighbors to achieve
   this.  Of course, SEP could support the two options in the single
   UPDATE transaction.

   Before UPDATE request is sent, the source peer should set the UPDATE
   Type attribute to determine option type.

   When the destination peer receives the UPDATE request, it first
   checks the UPDATE Type.  If the UPDATE is for a routing table, the
   destination peer should convey the routing table according to the
   request in the response.

   UPDATE Request =
                    Message Header
                    Source Peer Info
                    Update Type

   UPDATE Response =
                      Message Header
                      Response Attribute
                      Destination Peer Info
                      Update Type
                      [Routing-table]

6.1.6.  SearchPeer

   One Peer sends a SearchPeer request to find the responsible peer for
   a destination ID.  The destination peer information MAY be used to
   maintain the overlay routing table.  The source peer MAY establish a
   direct connection with the destination peer.  If it is the case, the
   D flag MUST be set to indicate to the responsible peer they SHOULD
   exchange ICE candidate for the NAT traversal.  In Chord, one peer
   uses SearchPeer request to lookup the responsible peer for its finger
   table.  The responsible peer MUST make a response to the request with
   its own peer information.  Current status of the responsible peer MAY
   also be included in the response.






Jiang, et al.            Expires August 4, 2008                [Page 30]


Internet-Draft                 P2PSIP SEP                 February  2008


   SearchPeer Request =
                        Message Header
                        Source Peer Info
                        [Relaying Peer Info]

   SearchPeer Response =
                         Message Header
                         Response Attribute
                         Destination Peer Info
                         [Status Info]

6.1.7.  TRANSFER

   When a peer joins or leaves the P2P overlay network, data transfer
   operation will be triggered.  The joining peer will be responsible
   for some <key, value> pairs and the leaving node SHOULD transfer its
   stored<key, value> pairs to its neighbors.  When the transfer
   operation takes place, the source peer does not know whether the peer
   receiving the <key, value> pair is leaving the overlay or it is busy.
   So SEP provides a mechanism to make both peers could negotiate some
   transfer parameters and the time when will the tranfer start.

   The source peer sends a TRANSFER request with the negotiation of the
   range of the resource ID to be transferred and the destination peer
   responds with the negotiation result by taking its current state into
   account.  If the the destination peer is about to leave the overlay,
   it MAY reject the request and sugguest the source peer tries another
   peer some time later.  The destination MAY accept, redirect or deny
   the transfer operation.  After that, the source peer transfers
   resource objects to the destination peer if the request was accepted.
   Peers MAY also negotiate transport parameters, such as transport
   protocol, to transfer resource objects.

   TRANSFER Request =
                      Message Header
                      Source Peer Info
                      [Negotiation Info]
                      [Resource Info]

   TRANSFER Response =
                       Message Header
                       Destination Peer Info
                       [Negotiation Info]

6.2.  Data Operations






Jiang, et al.            Expires August 4, 2008                [Page 31]


Internet-Draft                 P2PSIP SEP                 February  2008


6.2.1.  PUT

   A peer sends a PUT request to publish its resource object in the P2P
   overlay.  A peer may also send a PUT request to refresh or modify the
   resource object.  A hash code must be used with the owner identity to
   identify the unique resource object under the same resource ID.
   Every resource object has an owner identity to verify the owner of
   the resource object and a hash code to check the integrity of the
   resource object.  Every resource object also has an expiration time.
   One peer can refresh the resource object by modifying the expiration
   time, otherwise the destination peer SHOULD remove the resource
   object when it expires.

   A PUT request may take the resource object within the request.  A PUT
   request may also include negotiation information to negotiate the
   transport parameter to set up a direct connection between the source
   peer and the destination peer, and then the resource object
   transports through a direct connection.  When the resource object
   transport completes, the source peer may notify the destination peer
   of the completion.  When the put request is used to refresh the
   resource object, there is no resource object in the request but the
   resource ID, expiration time, owner identity and hash code are
   needed.

   PUT Request =
                 Message Header
                 Source Peer Info
                 [Relaying Peer Info]
                 Resource Info
                 [Negotiation Info]

   PUT Response =
                  Message Header
                  Response Attribute
                  Destination Peer Info
                  [Negotiation Info]

6.2.2.  GET

   The source peer sends a GET message with the resource ID and content
   type to retrieve the resource object.  The resource objects can be
   sent back with the Get response.  If the size of the resource objects
   is large(over some limit), the transport parameters can be negotiated
   using the GET request and response to figure out the transport type
   of the resource objects in a following direct connection.  When the
   resource objects transport completes, the source peer must notify the
   destination peer of the completion.




Jiang, et al.            Expires August 4, 2008                [Page 32]


Internet-Draft                 P2PSIP SEP                 February  2008


   GET Request =
                  Message Header
                  Source Peer Info
                  [Relaying Peer Info]
                  Resource Info
                  [Negotiation Info]

   GET Response =
                  Message Header
                  Response Attribute
                  Destination Peer Info
                  [Resource Info] [Negotiation Info]

6.2.3.  REMOVE

   A peer sends a REMOVE request to delete the resource object in the
   P2P overlay network.  A resource ID is used to locate in which peer
   the resource object is stored.  The owner identity and the hash code
   is used to distinguish the resource object from others under the same
   resource ID.  One responsible peer should delete all information
   about the resource object including replicas immediately when it
   receives the remove request.

   REMOVE Request =
                    Message Header
                    Source Peer Info
                    [Relaying Peer Info]
                    Resource Info

   REMOVE Response =
                     Message Header
                     Response Attribute
                     Destination Peer Info

6.3.  Additional messages

6.3.1.  LookUpServicePeer

   Some messages could be used to discover service peers who could
   provide a specific service, for example, STUN or TURN Relay service.
   Source peer MUST carry Service Peer Info in the request.  In SEP, we
   choose the LookUpServicePeer to collect the service peer's
   information.  This message will be forwarded through the overlay in a
   hop-by-hop way, so intermediate peers and the destination peer could
   collect the service peers based on its local knowledge of the
   overlay.  Every peer other than the source peer SHOULD put the
   searched results in the Service Peer Info attributes which will be
   returned back to the source peer.



Jiang, et al.            Expires August 4, 2008                [Page 33]


Internet-Draft                 P2PSIP SEP                 February  2008


   The source peer MUST insert a Service Peer Info attribute in the
   request to collect service peers whose types may be STUN, STUN relay,
   etc, and send it to the destination peer by choosing a given
   destination ID.  The source peer should specify the maximum number of
   service peers in the request.  If the number of peers reaches the
   maximum number, the successive intermediate peer or destination peer
   won't need to find satisfied peers.  In the resulting Service Peer
   Info attribute, none of the peer has the same Peer-ID attribute.  If
   the successive intermediate peer or the destination peer finds the
   service peer has already been in the Service Peer Info attribute,
   they MUST not be put into the Service Peer info attribute.

   When the peers process LookUpServicePeer request or response, some
   message-specific actions should be done in addition to basic actions
   proposed in section 9.

   The source peer SHOULD choose a destination ID which will determine
   the path the request will traverse.  The source peer SHOULD set the H
   flags in the message header and put in the request a Service Peer
   Info attribute which SHOULD set the maximum number of the expected
   service peers.  When source peer receives the response, it should
   check whether Service Peer Info attribute exists.  If it is, the
   source peer gets service peers from it for later use.

   While intermediate peers and the destination peer receive the
   LookUpServicePeer request, it first checks if the number in the
   Service Peer attribute reaches the maximum value.  If it is not the
   case, the intermediate peer should get the service type what the
   source peer wants and try to search the satisfied peers in the
   locally stored states.  If the intermediate peer gets some service
   peers, it should put it in the Service Peer info attribute.  If the
   number of the discovered peers equals the maximum number, they will
   not be put in the attribute.  At the same time, every intermediate
   peer or the destination peer should guarantee that every service peer
   is unique in this set.

   When the destination peer generates the response, it should carry the
   Service Peer attribute which is copied from the request unmodified.
   In the end, the discovered service peers are learned by the source
   peer by carrying them in the Service Peer Info attribute.











Jiang, et al.            Expires August 4, 2008                [Page 34]


Internet-Draft                 P2PSIP SEP                 February  2008


   LookUpServicePeer Request =
                                Message Header
                                Source Peer Info
                                Service Peer Info
                                [Relaying Peer Info]

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


7.  Routing Operations

   Routing operation is the basic and the important function of the peer
   in the overlay.  Peers choose the next hop peer for the packet
   regardless of where packets are from.  The packets as the input to
   the routing operation may come from the upper applications in the
   same peer, or from the network.  But the general forwarding operation
   applies to all of them.

   SEP protocol takes the semi-recursive and overlay native routing
   modes by considering the difficulty of NAT traversal and simultaneous
   failures of the intermediate peers.

7.1.  Request Routing

   If the packet is a request, it should be routed through the overlay
   by looking up the downstream peer based on the destination-ID in the
   packet.  The destination ID may be a Resource-ID or a Peer-ID which
   depends on the message type.

   In order to improve the reliability of the packets, SEP makes a
   flexible routing decision, not only complying with the DHT
   algorithms, but also based on the status of the downstream peers.
   The flexible routing operations may introduce latency for the packet,
   but it does improve the reliability.  Certainly, the tradeoff between
   the reliability and the additional latency from the additional hops
   should be evaluated independently by the routing peer.

   Note: if there are several candidate downstream peers at the same
   level in the overlay, for example, peers in the successor list in
   chord, the flexible routing operation would not introduce additional
   significant latency.

   The routing rules for the request are listed as follows:





Jiang, et al.            Expires August 4, 2008                [Page 35]


Internet-Draft                 P2PSIP SEP                 February  2008


   1.  Get the destination ID from the request;
   2.  Check whether the peer itself is responsible for the destination
       ID.  If it is, then deliver the packet up to the message specific
       function;
   3.  If it is not, get a few downstream peers closer to the
       destination ID in the routing states and get their associated
       processing status;
   4.  It is up to the implementation to decide which peer the request
       will be sent to by evaluating the trade-off between the
       reliability and the latency;

7.2.  Response Routing

   If the packet is a response, the first choice is to send the response
   back to the source peer directly, because the destination peer could
   get IP address of the source peer from the Peer Address Info
   attribute.  Due to the existence of the NAT, response MAY be returned
   to source peer by using some special mechnisms.  The routing behavior
   on intermediate peers or destination peer is different which are
   described below respectively.

7.2.1.  Response Routing on the Destination Peer

   1.  Before the destination peer sends the response back to the source
       peer, it should check the N flag of Service Capability Info to
       learn whether the source peer is on the public Internet;
   2.  If the source peer is on the public Internet, the transport
       address in the Peer address Info could be used to send the
       response back directly.
   3.  If the source peer is behind the NAT, the destination peer checks
       whether the Relaying Peer Info attribute is carried in the
       request.  If the destination peer has not found them, the
       response should be sent back by routing through the overlay and F
       flag in the message header MUST be cleared.
   4.  If the Relaying Peer Info is carried in the request, then
       destination peer could send the response to the transport address
       of these relaying peers which will relay the response to the
       source peer and the F flag MUST be set.  Note: destination peer
       could send the response to these relaying peers parallelly or
       sequentially.  The response could also be returned by using
       overlay native routing.  It is up to the destination peer to
       choose the right ways to send the response back.

7.2.2.  Response Routing on the Intermediate Peer

   1.  The intermediate peers check the F flag in the message header
       first.  If it is cleared, the response SHOULD be treated via
       overlay routing according to the forwarding rule described in the



Jiang, et al.            Expires August 4, 2008                [Page 36]


Internet-Draft                 P2PSIP SEP                 February  2008


       section 8.1.
   2.  If the F flag is set, it means that the response want to be
       relayed by the intermediate peer to the source peer.  So the
       intermediate peer gets the source peer-ID and checks whether the
       peer has the direct connection with the source peer.
   3.  If the direct connection exists, the intermediate peer sends the
       response to the source peer through the established connection
       with it.
   4.  If there is no direct connection between them, then it will check
       whether Source Reflexive attribute is carried in the response.
       If the Source Reflexive attribute exists, the intermediate peer
       will send the response directly to the transport address recorded
       in the Source Reflexive attribute;
   5.  If it does not exist, the intermediate peer MAY discard the
       response silently.  The intermediate peer also route the packet
       further based on the source peer ID.


8.  General Peer Behavior

   A few kinds of peers are involved in the transaction, including
   source peer, destination peer, intermediate peers.  The request is
   generated by the source peer and then forwarded through the overlay
   by traversing several intermediate peers and reaches the destination
   peer in the end.  The response from the destination peer may either
   be sent via IP routing, or forwarded by the intermediate peers
   through the overlay.  In this section, we give the general behavior
   of the peers who plays different roles in the transaction.

8.1.  Source Peer Behavior

8.1.1.  Generating the Request and Sending the Request

   The fields in the message header and some required attributes of the
   new message MUST be determined before the message would be sent.

   O Version: the current version number is 1;

   O F flag: this bit MUST be cleared in the request;

   O D flag: If the source peer realizes that it is behind NAT and needs
   a direct connection with destination peer after this transaction
   completes, the D flag MUST be set.

   O H flag: If the source peer wants the intermediate peers to process
   this message hop-by-hop, the H flag MUST be set.

   O R flag: this bit MUST be cleared in the request.



Jiang, et al.            Expires August 4, 2008                [Page 37]


Internet-Draft                 P2PSIP SEP                 February  2008


   O J flag: if this is the JOIN request, it should be set.

   O TTL: Every overlay MAY specify a default TTL in terms of the size
   of the overlay peers.  This default values MAY be obtained through
   the enrollment procedure.  It is up to the source peer to decide the
   value of the TTL.

   O Transaction ID: a 32 bit random number which is used to match the
   response with the request.  The method to get the transaction ID is
   implementation dependent.

   After the requests are generated, the routing operation described in
   section 8 MUST be followed to find out who is the next peer to the
   destination ID, and then send the requests directly to the next peer
   by using the established control connection between them.

   Source peer should keep the state for the request and wait for the
   response.  In order to make sure the reliability, the source peer MAY
   set a retransmit timer.  If the timer fires, the source peer should
   send the request again until maximum retransmit times reached.

8.1.2.  Processing the Response

   When the peer receives a response from the network, the routing
   operation will decide how to process it.  If the Source Peer ID in
   the response equals to the Peer ID of the routing peer, the routing
   peer knows it is the destination of the response and it will deliver
   the response to the upper layer and perform the message-specific
   processing.

   Before the message-specific processing, the peer MUST check the
   message in the following rules:

   1.  Check the value in the TTL field whether it is zero.  If it is,
       dicard the response.
   2.  Make sure Destination Peer Info attribute and the Response
       Attribute are carried in the response.  If any of them
       disappears, the peer MUST discard the response.
   3.  Extract Source Peer ID, destination ID, transaction ID and the
       message type from the message header, and match them with the
       pending requests.  If there is no matched one, it means that the
       response MAY either arrive at a wrong destination or be a delayed
       response, therefore the response MUST be discarded.  If there is
       a matched one, the response should be processed according to the
       message-specific procedure;






Jiang, et al.            Expires August 4, 2008                [Page 38]


Internet-Draft                 P2PSIP SEP                 February  2008


8.2.  Intermediate Peer Behavior

   When the peer receives a message from the network, it first checks if
   it is the destination of the message.  If it is not, it plays the
   intermediate peer role.  For the intermediate peer, the main task is
   to forward the message through the overlay or relay the messages to
   their destination.

   SEP introduces the hop-by-hop option which means that the
   intermediate peers should perform some message-specific actions in
   addition to routing operations.  These message-specific actions would
   provide some information which will be carried in the message and
   learned by the source peer in the end.  For example, source peer MAY
   want to get a route log of a request, so every intermediate peer
   should put itself into the request and later the route log will be
   returned to source peer.

   SEP also sets a J flag in the JOIN request which means that the JOIN
   request has not been processed by any peer in this overlay.  So when
   a peer receives a JOIN request, it would take the role of the
   bootstrap peer if J flag is set.  What the bootstrap peer could do to
   the JOIN request is to clear the J flag and get the source transport
   address of the JOIN request, and then record it into the Source
   Reflexive Address attribute in the request.

   Intermediate peer could decide whether the message is a request or
   response by only looking at the R flag in the message header.

8.2.1.  Request Processing

   When the intermediate peer receives a request, it first checks
   whether the hop-by-hop flag is set.  If it is set, it should perform
   some message-specific actions according to the message type.  Whether
   the H flag is set or not, the basic routing operations MUST be
   performed.

   The intermediate peer should also check the J flag if the message is
   JOIN request.  If the J flag is set, the intermediate peer should do
   some message-specific action.  If it is not set, only basic routing
   operations is performed.

   The TTL should be decreased by 1 and if the result is 0, the
   intermediate peer MUST discard the request.

8.2.2.  Response Processing

   When the intermediate peer receives a response, it should check the F
   flag and determined what kinds of routing mode will be preferred by



Jiang, et al.            Expires August 4, 2008                [Page 39]


Internet-Draft                 P2PSIP SEP                 February  2008


   the destination peer.  If F flag is set, it means the response should
   be relayed by the intermediate peer; if it is not, the response
   should be routed on the overlay level like what the requests are
   treated.

8.3.  Destination Peer Behavior

8.3.1.  Request Processing

   When the peer receives a request, it should consult their routing
   states to decide whether it is the destination peer for the request.
   If it is the destination peer, some routine checks MUST be performed
   before the message-specific actions are to be performed.

   1.  Check whether TTL is zero.  If it is, MUST discard the message;
   2.  Check whether the Source Peer Info attribute is in the request.
       If it is absent, MUST discard the message;

8.3.2.  Response Generation and Sending the Response

   After processing the request, the destination SHOULD send a response
   to the source peer.  The rules below should be followed:

   1.  The Source Peer, Destination ID, message type and the transaction
       ID MUST not be changed in the response.  These fields should be
       kept the same as the request.
   2.  Response Attribute MUST be included in the response;
   3.  Destination Peer Info MUST be included in the response.

   How to send the response depends on the routing modes chosen by the
   destination peer.  Please refer to the section 7.2.1 for more detail.


9.  NAT Traversal

   The existence of NAT makes the communication between peers becomes
   harder.  IETF has developed a suite of tools, STUN/TURN/ICE to
   address the issue.  SEP intends to reuse these tools and work with
   them in a harmonious way.  For example, SEP provides a method to
   exchange the candidate for the ICE protocol and SEP has the
   capability for the peer to discover the STUN or TURN server.

   An overlay is made up of the peers and the connections between peers.
   Peers could reach its neighbors directly.  For some operations like
   GET or PUT, source peers may only request the service provided by the
   destination peer and would not communicate with the destination peer
   any more.  In that case, the requests are delivered over the
   established connections and later reach the destination peer.  There



Jiang, et al.            Expires August 4, 2008                [Page 40]


Internet-Draft                 P2PSIP SEP                 February  2008


   is nothing needed to do to address the NAT traversal of the request.
   But for the response, if it is forwarded on the overlay layer, it
   also would not be interfered by the existence of the NAT for the same
   reason as the request; But if it is forwarded on the IP layer, NAT
   MAY fail the response.  SEP introduces relaying peers to make
   response go back to the source peer by traversing NAT.

   For some other operations like JOIN, SearchPeer, source peers not
   only request the service provided by the destination peer, but also
   expect the direct connection between them.  If a new peer wants to
   join the overlay, it sends JOIN request to the destination peer.  The
   destination peer for the request must be the new peer's neighbor;
   therefore they would communicate directly later.  SEP provides a
   method to exchange the candidates for the source peers and
   destination peers and ICE could make use of them to attempt to find
   out one or more candidate pairs by which they could reach each other
   directly even in the presence of NAT between them.

   Before a peer joins the overlay, it should initiate an enrollment
   procedure.  The joining peer MUST learn some bootstrap peers with
   public address.  These public bootstrap peers could provide STUN
   service for other peers, therefore the joining peer could learn
   whether it is behind NAT or not with the help from these public
   bootstrap peer or some other STUN servers.

   The peer MAY uses STUN protocol to detect whether it is behind the
   NAT.  If it is, it may need a TURN server if it is behind a p2p-
   unfriendly NAT.  Service peer discovery method proposed in SEP could
   be used to find service peers which could provide TURN service.
   Alternatively, it also could get a TURN server in other ways, for
   example, from the enrollment server.

9.1.  Gather ICE candidates

   A peer could learn whether it is behind NAT by means of STUN.  If it
   is, it should gather ICE candidates and put them into the Source Peer
   Info or Destination Peer Info respectively.  By using these two
   attributes, the source peer and the destination peer could exchange
   the ICE candidates with each other and the ICE process would be
   started as suggested by [ICE].

   The method to gather ICE candidates is similar to that described in
   [ICE].  ICE candidates are often carried by using SDP, but the Peer
   Address Info is used in the SEP.







Jiang, et al.            Expires August 4, 2008                [Page 41]


Internet-Draft                 P2PSIP SEP                 February  2008


9.2.  Response from the Destination Peer to the Source Peer

   If the source peer is on the public Internet, the response could be
   sent back directly from the destination peer to the source peer.  If
   the source peer is behind the NAT, it should either relies on the
   relaying peer to relay response or use the overlay native routing.
   It should follow the routing operations described in section 7.

9.2.1.  How to Make JOIN Response Return to Source Peer

   JOIN message has a little difference from other message, because the
   joining peer has not joined the overlay and has no neighbors at that
   time.  What the joining peer knows are only one or more bootstrap
   peers which are required to be on the public Internet.

   In order to make the JOIN response return to the source peer in the
   presence of NAT, the joining peer SHOULD set the J flag in the
   message header to show that the JOIN request has not been processed
   by any peer in the overlay.  In the meantime, the joining peer SHOULD
   get the transport address of the bootstrap peer which will be the
   next hop of the JOIN request and fill it into the Relaying Peer Info.
   After finishing above tasks, the joining peer sends the JOIN request
   to the bootstrap peer.

   The bootstrap peer SHOULD check the J flag and decide whether it is
   the bootstrap peer of the JOIN request.  If it is the bootstrap peer,
   it should record the source transport address of the JOIN request and
   fill it into the Source Reflexive Address attribute.  The J flag MUST
   be cleared by the bootstrap peer.

   When the destination peer receives the JOIN request, if the source
   peer is behind NAT, sending the response by routing through the
   overlay won't make sense in that the joining peer has not been known
   by any peer in the overlay.  So the only choice in SEP is for
   destination peer to relay the response to the source peer with the
   help of the relaying peer.  In that case, the destination peer will
   send the response directly to the relaying peer and SHOULD put the
   Source Reflexive Address attribute unmodified into the response.

   After the bootstrap peer (now, it plays relaying peer role) receives
   JOIN response, it checks whether Source Reflexive Address attribute
   is carried in the response.  If it is, JOIN response will be
   forwarded to the transport address which could be got from the Source
   Reflexive Address.  Then the JOIN response returns to the source
   peer.






Jiang, et al.            Expires August 4, 2008                [Page 42]


Internet-Draft                 P2PSIP SEP                 February  2008


9.3.  Exchange Candidates for the Direct Communication

   Some operations may require a direct connection after the associated
   transaction finishes.  But due to the existence of NAT, both peers
   should exchange their own candidates with each other and then use ICE
   to find out one or more workable candidate pairs.  The transaction
   before the direct connection could be used as a signaling channel to
   exchange candidates.  In order to achieve this, the source peer
   SHOULD set the D flag in the message header if it requires a later
   direct connection with the destination peer.

   After exchange candidates, ICE process will be started.  (TO DO: how
   is SEP seamlessly integrated with the ICE process will explored in
   the next version.)


10.  Security Considerations

   Security considerations will be dicussed in the next version.


11.  IANA Considerations

                   +-------------------+--------------+
                   | Message           | Message Type |
                   +-------------------+--------------+
                   | JOIN              | 0            |
                   | LEAVE             | 1            |
                   | KEEPALIVE         | 2            |
                   | NOTIFY            | 3            |
                   | UPDATE            | 4            |
                   | SearchPeer        | 5            |
                   | TRANSFER          | 6            |
                   | PUT               | 7            |
                   | GET               | 8            |
                   | REMOVE            | 9            |
                   | LookUpServicePeer | 10           |
                   +-------------------+--------------+


12.  Acknowledgements

   A team of guys contribute to this documents.  Thanks for the effort
   from Alex, Watw, Justin and Rake.







Jiang, et al.            Expires August 4, 2008                [Page 43]


Internet-Draft                 P2PSIP SEP                 February  2008


13.  References

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

   [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
   Methodology for Network Address Translator (NAT) Traversal for Offer/
   Answer Protocols", Internet Draft draft-ietf-mmusic-ice (Work in
   Progress).

   [Concept] Bryan, D., Matthews, P., Shim, E., Willis, D., " Concepts
   and Terminology for Peer to Peer SIP " Internet Draft
   draft-ietf-p2psip-concepts-00 (Work in progress)

   [STUN] Rosenberg, J., Huitema, C., Mahy, R., Willis, D., "Session
   Traversal Utilities for (NAT) (STUN)" Internet Draft
   draft-ietf-behave-rfc3489bis (Work in Progress)

   [TURN] Rosenberg, J., Mahy, R., Huitema, C., "Obtaining Relay
   Addresses from Simple Traversal Underneath NAT (STUN)" Internet Draft
   draft-ietf-behave-turn(Work in Progress)

13.2.  Informative References

   [STUN Discovery] XingFeng Jiang, "A mechanism to discover STUN/TURN
   nodes in P2PSIP" Internet Draft draft-jiang-p2psip-STUN-discovery
   (Work in Progress)


Authors' Addresses

   XingFeng Jiang
   Huawei Tech.
   Huihong Mansion,No.91 Baixia Rd.
   Nanjing, Jiangsu  210001
   P.R.China

   Phone: +86(25)84565468
   Email: jiang.x.f@huawei.com






Jiang, et al.            Expires August 4, 2008                [Page 44]


Internet-Draft                 P2PSIP SEP                 February  2008


   HeWen Zheng
   Huawei Tech.
   Huihong Mansion,No.91 Baixia Rd.
   Nanjing, Jiangsu  P.R.China


   Phone: +86(25)84565467
   Email: hwzheng@huawei.com


   Carlos Macian Ruiz
   Pompeu Fabra University
   Barcelona, Passeig de la Circumval.lacio  8 08003
   Spain

   Phone: +34-93-5421498
   Fax:   +34-93-5422517
   Email: carlos.macian@upf.edu


   Victor Pascual Avila
   Pompeu Fabra University
   Barcelona, Passeig de la Circumval.lacio  8 08003
   Spain

   Phone: +34-93-5421561
   Fax:   +34-93-5422517
   Email: victor.pascuala@upf.edu























Jiang, et al.            Expires August 4, 2008                [Page 45]


Internet-Draft                 P2PSIP SEP                 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Jiang, et al.            Expires August 4, 2008                [Page 46]


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