Internet DRAFT - draft-xiao-p2psip-client-routing


Network Working Group                                          L.Xiao 
Internet Draft                                  Nokia Siemens Networks 
Intended status: Standards Track                               Y.Zhang 
Expires: November 2009                                      China Mobile 
                                                            May 13, 2009 
                    A P2PSIP Client Routing for Reload 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and 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 

   The list of Internet-Draft Shadow Directories can be accessed at 

   This Internet-Draft will expire on November 13, 2009. 

Copyright and License Notice 

   Copyright (c) 2009 IETF Trust and the persons identified as the 
   document authors.  All rights reserved. 

   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents in effect on the date of 
   publication of this document ( 
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 



   This document analyses the routing requirements of different types of 
   clients, and then proposes a P2P client routing mechanism for 
Xiao                  Expires November 13, 2009               [Page 1] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

   REsource LOcation And Discovery (RELOAD). This mechanism is designed 
   to solve the issues in one of the client routing options described in 
   the RELOAD Base protocol [I-D.ietf-p2psip-base], where clients are 
   allowed to connect with arbitrary peers. The solution is to store the 
   information of a client's Attached Peer in the overlay together with 
   the registration data of the client. The extension could be deployed 
   on SIP usage of RELOAD easily [I-D.draft-ietf-p2psip-sip].  

Table of Contents 

   1. Introduction................................................2 
   2. Terminology.................................................3 
   3. Client Overview.............................................4 
      3.1. Client Types...........................................4 
      3.2. Routing Consideration..................................5 
         3.2.1. Routing Client....................................5 
         3.2.2. Storage Client....................................6 
         3.2.3. Pure Client.......................................7 
   4. Client Routing..............................................8 
      4.1. Client Registration....................................9 
      4.2. Client Looking Up......................................10 
      4.3. Attaching Information Updating.........................11 
   5. Security....................................................12 
   6. Acknowledgments.............................................12 
   7. References..................................................12 
      7.1. Normative References...................................12 
      7.2. Informative References.................................12 

1. Introduction 

   Two basic client routing options are given for locating a client in a 
   P2P overlay in RELOAD Base protocol. They are, actually, designed to 
   solve the client routing issues in two different scenarios.  


   In the first option, client is connected directly on the peer that 
   responsible for the client's Node-ID. The position of a client in the 
   overly is determined completely by the topology algorithm and its 
   Node-ID. It can be located with its Node-ID by the same means as a 
   normal peer. Therefore, a unified RELOAD routing protocol can be used.  


Xiao                  Expires November 13, 2009               [Page 2] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

   However, due to the existence of NATs and firewalls, and the mobile 
   characteristics of some clients, it is not always possible to form 
   and maintain direct connections for clients with any other peer. It 
   is the reason that why RELOAD Base protocol allows a client to 
   establish a connection with an arbitrary peer in the overlay. The 
   connections perhaps are based on network proximity or other 
   requirements of the applications. The routing protocol used in such a 
   scenario is called Client Routing protocol in this document to simply 
   distinguish the unified routing protocol used in a pure structured 


   This document tries to define the Client Routing protocol for 
   locating a client that connects with an arbitrary peer in an overlay. 
   The classification, behaviors and requirements of different types of 
   RELOAD clients are also discussed and analyzed in order to clarify 
   the scope of the issues to be solved. Only the clients without both 
   routing and storage responsibilities in the overlay are suitable to 
   deploy such routing protocol. A simple extension is made in SIP usage 
   of RELOAD to support the storage of the mapping between the client 
   and its Attached Peer. An efficient connection management mechanism 
   is required to trigger the update of the attaching relationship 
   between the client and peer. 


2. Terminology 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   document are to be interpreted as described in RFC 2119 [RFC 2119]. 


   We use the terminology and definitions from Concepts and Terminology 
   for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 
   Protocol [I-D.ietf-p2psip-base] extensively in this document. Other 
   terms used in this document are defined inline when used and are also 
   defined below for reference. 


   Attached Peer: It is an arbitrary peer that has a direct connection 
   with a client node in the overlay. Attached Peer is responsible for 
   the routing to its attached client. 

Xiao                  Expires November 13, 2009               [Page 3] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 


   Client Routing: Client Routing in RELOAD is a routing protocol to 
   locate a client node connected with an arbitrary peer in the overlay. 


3. Client Overview 

   There is a wide variety of reasons a node may act as a client rather 
   than as a peer [I-D.pascual-p2psip-clients].It is important to notice 
   that unwillingness is not the only reason. At the most scenarios, the 
   limited capability (e.g., limited storage memory, bandwidth, battery, 
   and computing ability) and special features (e.g., mobility) of the 
   nodes are in serious consideration. RELOAD allows this kind of nodes 
   to take part in the P2P overlay with limited functionalities compared 
   to a normal peer. Due to their different roles in the overlay, not 
   all the clients can deploy the proposed Client Routing mechanism. 
   This section classifies the clients according to their different 
   capabilities and functionalities in the overlay, analyzes the 
   behaviors of different types of clients and clarifies the scope of 
   the proposed Client Routing protocol.   


3.1. Client Types 

   According to the definition of client in RELOAD Base, a client is a 
   host that is able to store data in and retrieve data from the overlay 
   but which is not participating in routing or data storage for the 


   Therefore, we can classify clients into tree types: 

   o Routing Client: nodes taking part in the routing of the overlay, 
      but no storage responsibility 

   o Storage Client: nodes can store data for others, but no routing 

   o and Pure Client: nodes without both routing and storage 


Xiao                  Expires November 13, 2009               [Page 4] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

   Normally, there are two critical factors to assess if a node is 
   suitable to act as a peer: capabilities (e.g. storage, computing and 
   battery capabilities) and connections (if it can keep stable 
   connections with other nodes with sufficient bandwidth). If a node 
   has limited storage capability but has stable and sufficient 
   bandwidth connections, it can works as Routing Client. Or if the node 
   has less stable connection with others but has sufficient storage 
   capacity, it falls into the type of Storage Client. And most mobile 
   terminals, e.g. handsets and PDAs, which can supply neither storage 
   nor stable connections, may work as Pure Clients. 


3.2. Routing Consideration 

   Different responsibilities and behaviors of the three client types 
   decide the positions they may appear in an overlay topology, which 
   brings different routing requirements and consideration for the 


3.2.1. Routing Client 

   Because this kind of clients works as routing nodes in the overlay, 
   they must take part in the overlay construction. In a structured P2P 
   overlay, any routing node must maintain direct connections with some 
   neighbors to construct the overlay. In order to keep the intrinsic 
   logic of the structured P2P topology, the Routing Client must be 
   located at the position determined by the overlay algorithm and its 
   Node-ID. Obviously, a unified routing protocol is sufficient for both 
   peer and client in such a scenario, which is described in the first 
   option of RELOAD client routing in RELOAD Base draft.  


   Note that, since this type of client keeps its routing capability in 
   the overlay, it should have the ability to form and maintain stable 
   connections with other peers. It is not necessary for them to connect 
   the overly with an arbitrary peer. So, this scenario is NOT in the 
   scope of the proposed Client Routing. 


   For instance, in Figure 1, Node 85 works as Routing Client, it must 
   be located between Node 70 and Node 90, in order to forward routing 
   request/reply messages properly. 
Xiao                  Expires November 13, 2009               [Page 5] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 


          +--------+              +--------+              +--------+ 
          | Node 40|--------------| Node 50|--------------| Node 60| 
          +--------+              +--------+              +--------+ 
              |                                               | 
              |                                               | 
          +--------+              +--------+              +--------+ 
          | Node 70|--------------| Node 85|--------------| Node 90| 
          +--------+              |(Client)|              +--------+ 
    Figure 1 Client node 85 is located orderly by DHT algorithm to serve 
                                as a router 


3.2.2. Storage Client 

   This kind of clients has no responsibility to route for other nodes. 
   It seems that the clients could appear at any position in the overlay, 
   without considering the structure organized by overlay algorithm. 
   However, if we want to access the data stored in the client, how can 
   we find the client with the DHT algorithm if only an arbitrary 
   connection is maintained by the client to the overlay?  Obviously, if 
   the DHT mapping is built on the stored resource and the client ID, 
   the dynamic position of the client will increase the difficulty to 
   locate the data resource. Note that, the requestor of the data 
   resource has no idea about this dynamic and will use normal DHT 
   algorithm to locate the data.  


   In this scenario, it is suggested that, mappings are only formed 
   between normal peers and data resources. Storage Clients work only as 
   supplements of peers' storage, where the dialogs between clients and 
   its attached peers for resource data storage and fetching are 
   invisible by others. The same suggestion is also made in [I-
   D.pascual-p2psip-clients], where the Storage Client serves as a 
   remote storage for its associate peer. 


   For instance, in Figure 2, client Node 15 stores some resource for 
   its associated peer Node 80 and serves only as a remote storage of 
   peer Node 80. The mapping relationship is built between the Node ID 

Xiao                  Expires November 13, 2009               [Page 6] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

   80 and the resource ID of the stored data. Peer 80 is the only 
   interface for others to access the data resources. 


         +--------+              +--------+              +--------+ 
         | Node 40|--------------| Node 50|--------------| Node 60| 
         +--------+              +--------+              +--------+ 
             |                                               | 
             |                 +-------------+               | 
         +--------+            | +--------+  |           +--------+ 
         | Node 70|------------|-| Node 80|--|-----------| Node 90| 
         +--------+            | +--------+  |           +--------+ 
                               |     |       | 
                               | +--------+  | 
                               | | Node 15|  | 
                               | |(Client)|  | 
                               | +--------+  | 
                               | Resource 75 | 
      Figure 2 Client Node 15 works as remote storage for Peer Node 80 


   So, in this scenario, there is no direct access for Storage Clients 
   in the overlay. The Attached Peer can handle the data requests as a 
   public interface, no matter if the data is actually stored in its 
   attached client. It is actually a peer routing issue which is out of 
   the scope of the proposed Client Routing protocol. The communication 
   between the peer and its remote storage client should be specified in 
   another draft. 


   However, if the storage client is directly called by another node, 
   e.g., as a SIP callee, it actually can be considered as a Pure Client, 
   which is discussed in the following section. 


3.2.3. Pure Client 

   Actually, RELOAD Client Routing protocol is just designed for Pure 
   Clients, where client always work at an end of a communication. Its 
   position in the overlay does not affect the discovery of any other 

Xiao                  Expires November 13, 2009               [Page 7] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

   nodes or resources except the client node itself, which gives more 
   freedom for such clients to choose arbitrary attached peers.  


   The topology model of Pure Client communication is shown in Figure 3. 
   Node 10 and Node 20 are two clients in the overlay. They neither have 
   routing functionality nor store data for any other node. There is no 
   problem for such clients to start a request for other nodes or data 
   resources by overlay algorithm. However, if they are requested by 
   other nodes, a method is required to locate their current positions, 
   which can not be solved only by a structured overlay algorithm. Due 
   to all the peers in the overlay are strictly constructed by an 
   overlay algorithm, the Attached Peer can be located easily in the 
   overlay which can work as a relay to the client. The mapping 
   information should be published by the client somewhere in the 


          +--------+           +--------+            +--------+ 
          | Node 40|-----------| Node 50|------------| Node 60| 
          +--------+           +--------+            +--------+ 
              |                                           | 
              |                                           | 
          +--------+           +--------+            +--------+ 
          | Node 70|-----------| Node 80|------------| Node 90| 
          +----+---+           +--------+            +---+----+ 
     Attached Peer of node 10                  Attached Peer of node 20 
               |                                         | 
               |                                         |   
          +--------+                                 +--------+ 
          | Node 10|                                 | Node 20| 
          |(Client)|                                 |(Client)| 
          +--------+                                 +--------+ 
            Figure 3 Pure clients attached with arbitrary peers 


4. Client Routing 

   According to the discussion in Section 3, the scope of the Client 
   Routing protocol is clearly focused on locating pure clients in the 
   overlay. The procedure of mapping relationship publication and 
   communication establishment is almost the same with that described in 
   SIP usage for RELOAD [I-D. draft-ietf-p2psip-sip]. The client here is 
Xiao                  Expires November 13, 2009               [Page 8] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

   actually the same as a callee in the SIP usage, except that the 
   client can appear at an arbitrary position in the overlay. In SIP 
   usage, the registration resource of a user is always fetched by a 
   caller to locate the user in overlay. It is very convenient if the 
   mapping relationship of the client and its Attached Peer is stored 
   together with the registration. Therefore small extension could be 
   done base on the SIP usage for Pure Client routing. 


4.1. Client Registration 

   As the example described in SIP usage draft [I-D.draft-ietf-p2psip-
   sip], Alice stores the mapping '' -> 1234''in the 
   registration, where '''' is Alice's AoR and ''1234'' 
   is Alice's node ID. Any node calling Alice should fetch the resource 
   in the overlay according to Alice's AoR, and contact node 1234 to set 
   up the call. But if node 1234 is a client attached with a peer, e.g., 
   Peer 4567, it is difficult to find the client with only node ID 1234. 
   An additional mapping should be given to build a relationship between 
   the client 1234 with its attached peer 4567: '' -
   > 4567-> 1234''. Therefore, the content of the destination list stored 
   in the mapping should not be only a single node ID. It also could be 
   a list with multiple Node IDs (normally two node IDs are enough for 
   Client Routing proposed in the draft, and extension is allowed for 
   other usages). A minor modification is done to the ''SipRegistration 
   structure'' of the RELOAD SIP usage to allow multiple values in 
   ''destination_list''. The extended structure is shown as followed. 


enum {sip_registration_uri (1), sip_registration_route (2), (255)} 


       select (SipRegistration.type) { 

         case sip_registration_uri:  

           opaque               uri<0..2^16-1>; 


         case sip_registration_route: 

           opaque               contact_prefs<0..2^16-1>; 
Xiao                  Expires November 13, 2009               [Page 9] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

           Destination          destination_list [dest_list_length]; 

       } SipRegistrationData; 


       struct { 

          SipRegistrationType   type; 

          uint16                length; 

          SipRegistrationData   data; 

      } SipRegistration; 


   When the registration type is selected as ''sip_registration_route'', 
   the contents of the registration data are an opaque string containing 
   the callee's contact preferences and a destination list for the peer. 
   The ''destination_list'' here is extended to store both the Node ID of 
   the Attached Peer's and that of the client's. Therefore, in the above 
   example, the registration of Alice should include a destination_list 
   with two elements: destination_list [0] = 4567 and  destination_list 
   [1] = 1234. 


4.2. Client Looking Up 

   The Client looking up process follows up the description in SIP Usage 


   When a RELOAD user wishes to call another user, it first checks the 
   domain part of the AOR to make sure it matches the domain name of the 
   overlay. Then it performs a Fetch for kind SIP-REGISTRATION at the 
   Resource-ID corresponding to the AOR. The destination list in the 
   registration data includes Node IDs of both the client's and its 
   Attached Peer's, which leads the route to the client via its 
   Attaching Peer. 


Xiao                  Expires November 13, 2009              [Page 10] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 

4.3. Attaching Information Updating 

   The reason why RELOAD allows a client to connect with arbitrary peers 
   in the overlay is that the client may not form or keep a direct and 
   constant connection with its responsible peer in the overlay. Most of 
   the mobile terminals, e.g. handsets, could work in this mode, because 
   the mobility feature increases the possibility of losing direct 
   connections. The optional mechanism to build an attaching 
   relationship between clients with arbitrary peer brings a big 
   flexibility for RELOAD.  


   Keeping the attaching relationship information updated in the overlay 
   is essential in order to locate clients efficiently: 

   o As a client getting connected to the overlay for the first time, 
      connections could be built by the overlay algorithm with the help 
      of bootstrap peers. A peer with topology proximity could be 
      selected as its Attached Peer. Other connections should also be 
      enriched during this time as described in RELOAD Base. 

   o The attaching relationship between the client and the peer should 
      be stored in the overlay together with the client's registration 
      information. It is the extension of the SIP Usage of RELOAD  

   o A connection maintenance mechanism should be used for the client 
      to maintain connections to other peers, including its Attached 
      Peer. RELOAD Base has a series of specifications for connection 
      and topology maintenance that can be used here. Any particular 
      scheme should be defined in a specific P2P Overlay Plugin. 

   o Once the disconnection of the link between client and its 
      attaching peer is detected, the client should select another 
      arbitrary peer from those who still have direct connection with it. 

   o Once a new attaching peer was selected by the client, a 
      registration message would be send out to update the existing 
      information store in the overlay. 


   Note that, the efficiency of the algorithm depends on how quick the 
   disconnection with the attached peer could be detected. Therefore, 
   the frequency of the connection status diagnostic could not be too 

Xiao                  Expires November 13, 2009              [Page 11] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 


5. Security  


   Security consideration please reference that in the draft of Sip 
   usage of RELOAD [I-D.draft-ietf-p2psip-sip]. 


6. References 

6.1. Normative References 

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

    [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 
             Baset, S., and H. Schulzrinne, "REsource LOcation And 
             Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-
             02 (work in progress), March 2009. 

    [I-D.draft-ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., 
             Baset, S., and H. Schulzrinne, ''A SIP Usage for RELOAD'' 
             draft-ietf-p2psip-sip-01,(work in progress), March 2009. 


6.2. Informative References 

    [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, 
             D., and S. Dawkins, "Concepts and Terminology for Peer to 
             Peer SIP", draft-ietf-p2psip-concepts-02 (work in progress), 
             July 2008. 

    [I-D.pascual-p2psip-clients] Pascual, V., Matuszewski, M., Shim, E., 
             Zhang, H., and S. Yongchao, "P2PSIP Clients", draft-
             pascual-p2psip-clients-01 (work in progress),February 2008. 


7. Acknowledgments 

   This draft is generated as an output of NSN's PeaCe project, which 
   also got support and help from Sherry Shen, Christian Schmidt, Jouni 
   Korhonen and CMCC's DSN project team. 
Xiao                  Expires November 13, 2009              [Page 12] 
Internet-Draft   A P2PSIP Client Routing for Reload           May 2009 


Authors' Addresses 

   Lin Xiao 
   Nokia Siemens Network 
   Phone: +86 10 84055824 

   Yunfei Zhang 
   China Mobil 
   Phone: 86 13601032119 


Xiao                  Expires November 13, 2009              [Page 13]