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 draft-xiao-p2psip-client-routing-00.txt 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 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 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 (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract 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 overlay. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 overlay. 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 responsibility o and Pure Client: nodes without both routing and storage responsibility 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 clients. 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 overlay. +--------+ +--------+ +--------+ | 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 ''sip:alice@example.org -> 1234''in the registration, where ''sip:alice@example.org'' 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: ''sip:alice@example.org - > 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)} SipRegistrationType; 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 [I-D.draft-ietf-p2psip-sip]. 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 low. 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 China Phone: +86 10 84055824 Email: lin.xiao@nsn.com Yunfei Zhang China Mobil China Phone: 86 13601032119 Email: zhangyunfei@chinamobile.com Xiao Expires November 13, 2009 [Page 13]