P2PSIP Working Group J. Peng Internet-Draft L. Deng Intended status: Standards Track L. Le Expires: January 3, 2012 G. Li China Mobile July 2, 2011 Proposals for RELOAD to support Promotion and Demotion for User-owned Nodes draft-peng-p2psip-promotion-00 Abstract This document proposes extensions to RELOAD to support flexible client promotion and demotion modes. RELOAD aims at providing a uniform protocol for both overlay clients and peers, where promotion of a client to peer is triggered and completed at the client's pleasure. It is proposed that RELOAD provide a more restrictive framework to enable passive promotion and demotion, where decisions are made by the network rather than individual user-owned nodes. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 3, 2012. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Peng, et al. Expires January 3, 2012 [Page 1] Internet-Draft RELOAD Promotion July 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Passive promotion instead of active promotion . . . . . . 5 3.2. Passive demotion as well as active demotion . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Peng, et al. Expires January 3, 2012 [Page 2] Internet-Draft RELOAD Promotion July 2011 1. Introduction RELOAD[I-D.ietf-p2psip-base], a peer-to-peer (P2P) signaling protocol for use on the Internet, provides a generic, self-organizing overlay network service, allowing nodes to efficiently route messages to other nodes and to efficiently store and retrieve data in the overlay. There are two types of roles in the RELOAD architecture: peer and client. Clients are merely users of the basic messaging and storage function provided by the overlay, while peers (i.e. non-client nodes) are active participants of the serving overlay as they collaborate in a P2P manner to serve one another. For Internet services on the basis of a RELOAD-enabled P2P overlay, it is appealing to exploit the collectively abundant resources of UNs (i.e. user-owned nodes) to further reduce service operator's CAPEX (i.e. capital expenses on dedicated serving equipment), thus indicating an application scenario for on-demand passive client promotion. On the other hand, due to the distributed nature of P2P overlays, undesirable implications often arises after imprudent peer exits, demanding for regulated passive peer demotion to client in reverse. However, unlike normal clients in RELOAD overlay, individual UNs are featured with more restrictive resource limits, considerable capability heterogeneity, and diverse interest groups, whose promotion/demotion demands for more restrictive regulations than the simple active client promotion facility defined in RELOAD. A SIP usage could be used to illustrate the UN-oriented promotion/ demotion problem, where a UN-oriented client refers to a user-owned node attached originally for SIP UAs, while a peer refers to a dedicated SIP servers or UN-promoted SIP servants of the RELOAD overlay. In this draft, the basic problems for promoting/demoting User-owned clients to/from serving peers using the currently available mechanism are outlined from the overlay operator's point of view, followed by a detailed analysis of specific functionality requirements. Potential extensions to RELOAD are summarized in Section 5. Relevant security considerations are stated in Section 6. Peng, et al. Expires January 3, 2012 [Page 3] Internet-Draft RELOAD Promotion July 2011 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 [RFC2119]. Peng, et al. Expires January 3, 2012 [Page 4] Internet-Draft RELOAD Promotion July 2011 3. Problem Statement 3.1. Passive promotion instead of active promotion Since a UN generally lacks the incentive to serve others proactively as a result of its relatively bounded resources in combination with the autonomous and self-centered nature of its individual owner, the UN-oriented promotion procedures are expected to be largely triggered from the overlay network side for the benefit of the servicing system as a whole. Restrictive regulations are needed in the passive procedure for UN-oriented client promotion. Firstly, a UN may be incapable of or malfunctioning in serving others. Secondly, a UN may be preferred not to become a peer for the sake of network considerations, e.g. a moderate network size may be preferred to remain efficient overlay routing. The simple join-update method allows for active promotion only, where an successfully attached client (either UN-oriented or not), spontaneously initiates the promotion procedure by sending JoinReq messages to expected overlay neighboring peers and indicates its ready-to-go status as a serving peer by sending UpdateReq messages with revised routing information. It is therefore proposed that the promoter (e.g. an overloading peer) rather than the UN in question triggers the correspondent passive promotion procedure, and the promoted UN is selected from a potentially large client group of candidates and certified by the promoter to other peers in the overlay to be recognized as an authorized peer. Potential extensions to RELOAD include extensions to certain kinds of messages (e.g. Probe and Join) in order to support the passive client promotion procedure. 3.2. Passive demotion as well as active demotion For a successfully promoted UN peer, one of the following two demotion scenarios would ultimately terminates its current peering service in the RELOAD overlay. o Active demotion decision from the UN side, that the user/UN decides to cease being a peer, for instance: * Case 1: if the user perceives a considerable decrease in user experience; or * Case 2: if the UN terminal runs out of battery. Peng, et al. Expires January 3, 2012 [Page 5] Internet-Draft RELOAD Promotion July 2011 o Passive demotion decision from the overlay side to get rid of unnecessary UN-promoted peers, for instance: * Case 3: Overlay decides to shrinks its peer group to maintain a tolerable routing delay; * Case 4: Overlay decides to exclude the peer(s) for unsatisfactory service provision. The current leave-without-response method fits well in the active demotion scenarios, where a peer (either promoted earlier from UN- oriented client or not), spontaneously initiates the demotion procedure by sending LeaveReq messages to its overlay neighboring peers and be free to go without any further confirmation. This simple but kind of abrupt mode is ungracefull in comparison with another mode of peer demotion mode (i.e. graceful mode, where the demoting peer takes an active part in the data migration and routing update for the resultant overlay adaptation before its physical exit. It is therefore proposed to add support to allow for both active and passive peer demotion procedures for UN-oriented peers. Moreover, graceful demotion mode is highly preferable for passive demotion scenarios. Potential extensions to RELOAD include extensions to current method (e.g. extension to LeaveReq message or may be introduction of new types of messages such as explicit LeaveRes messages) to support peers graceful demotion mode. Peng, et al. Expires January 3, 2012 [Page 6] Internet-Draft RELOAD Promotion July 2011 4. Security Considerations As stated above, the group of UNs manifests diversity in both physical capabilities and public morals in terms of serving as an overlay peer. Hence, it is reasonable to conduct explicit authorization to distinguish a promotion candidate's potential to serve as a peer from normal UN clients on one hand, and guarantee timely revocation to limit the impact of a misbehaving promoted UN- oriented peer on the other hand. It is therefore proposed that: o a qualified UN acquires a separate peer certificate to attest its capabilities and willingness to serve as a peer; and o a UN-promoted peer's certificate is revoked if it fails to deliver expected performance while its client certificate remains intact. Potential extensions to RELOAD include separate peer certification and proactive certificate revocation. Peng, et al. Expires January 3, 2012 [Page 7] Internet-Draft RELOAD Promotion July 2011 5. IANA Considerations There are no IANA considerations associated to this memo. Peng, et al. Expires January 3, 2012 [Page 8] Internet-Draft RELOAD Promotion July 2011 6. Acknowledgements Peng, et al. Expires January 3, 2012 [Page 9] Internet-Draft RELOAD Promotion July 2011 7. References 7.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-15 (work in progress), May 2011. 7.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-03 (work in progress), October 2010. Peng, et al. Expires January 3, 2012 [Page 10] Internet-Draft RELOAD Promotion July 2011 Authors' Addresses Jin Peng China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 P.R.China Email: Penjin@chinamobile.com Lingli Deng China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 P.R.China Email: Denglingli@chinamobile.com Lifeng Le China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 P.R.China Email: Lelifeng@chinamobile.com Gang Li China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 P.R.China Email: Ligangyf@chinamobile.com Peng, et al. Expires January 3, 2012 [Page 11]