P2PSIP Working Group H. Song Internet-Draft Huawei Intended status: Standards Track February 27, 2010 Expires: August 31, 2010 P2PSIP Bootstrap Status Maintenance draft-song-p2psip-bootstrap-status-maintenance-00 Abstract In order to join the overlay, a joining peer/client has to find the enrollment server first, and then acquire the configuration file from the enrollment server where it can find the bootstrap peers' information, and after that it contact a bootstrap node to route the join request message to join the overlay. However, nodes in P2PSIP overlay network are dynamic. They can leave gracefully or abruptly at any time. This document focuses on the bootstrap server mechanism and proposes a mechanism to select proper bootstrap peers and improve the availability of bootstrap nodes through bootstrap peer status maintenance. 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 August 31, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Song Expires August 31, 2010 [Page 1] Internet-Draft P2PSIP Bootstrap Status Maintenance February 2010 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 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Bootstrap status maintenance . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Message Process . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. peer messages . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Message to identify the peer itself as a capable bootstrap peer . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Message for bootstrap peer to report busy status . . . 5 3.2. Enrollment server messages . . . . . . . . . . . . . . . . 5 3.2.1. Message to check the aliveness of the bootstrap peer . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Message to notify the election of a bootstrap peer . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Song Expires August 31, 2010 [Page 2] Internet-Draft P2PSIP Bootstrap Status Maintenance February 2010 1. Introduction 1.1. Background The base draft [I-D.ietf-p2psip-base] introduces a few mechanisms for bootstrap. A joining peer can use the bootstrap peer list from the configuration file, or uses its previous cached neighbor peers to bootstrap, or use the multicast or broadcast mechanism to acquire bootstrap peers. Another draft [I-D.matthews-p2psip-bootstrap-mechanisms] also proposed bootstrap server and multicast mechanisms. The simplest way is to use the bootstrap peer information from the configuration file, but there are a few open questions here. a. How to get the bootstrap peer and which peers are qualified as bootstrap peers? There are a few requirements for a capable bootstrap peer here. (a.1) According to the base draft and mailing list discussion, the address of the bootstrap peer in the configuration file must be publicly reachable. It is very hard to find a technique can ensure that in every deployment scenarios. But in real world, each application may look its own deployment scenario and design its own way to select the "publicly reachable" peers according to real environment. (a.2) it should be online. (a.3) it should have enough available processing resources b. How to maintain the bootstrap peer list info to keep them valid to use? Peers in the overlay are dynamic, and each peer can leave the overlay abruptly at anytime. This is the main concern of this document. c. How to avoid hot spot problem on a specific bootstrap peer when a bunch of peers join simultaneously? This document will try to solve the above questions by giving a promising solution. 1.2. Bootstrap status maintenance Here is the procedure of the mechanism proposed by this document. (Assume that the overlay operator configures a fixed number of bootstrap peers in the configuration file, say N) a. After each joining peer joins the overlay network successfully. Each joining peer will send a message to a TURN server. This TURN server could be a peer with publicly reachable address found in the overlay, or a server provided by the overlay operator. If the reflexive peer address is the same with its local address, then it sends a message to the enrollment server to report its processing Song Expires August 31, 2010 [Page 3] Internet-Draft P2PSIP Bootstrap Status Maintenance February 2010 resources and identifies itself as a candidate bootstrap peer. b. Enrollment server selects a bootstrap peer from its local candidate bootstrap peer database, and then send a message to check the aliveness of this peer. And finally it gets N live bootstrap peers. And send notifications to the N bootstrap peers. We should reuse the existing messages whenever possible here to notify the bootstrap peer about its election of the bootstrap peer role. c. The N bootstrap peers are listed in the bootstrap peer list. They report their busy status to the enrollment server in period. And enrollment server uses round robin mechanism to change their sequence in the list for load balance. We should reuse the existing messages whenever possible to do the status report mentioned here. d. If the enrollment server has not received the report from a certain bootstrap peer for several periods, or find a bootstrap peer is congested according to its report, or receive a notification that the specific bootstrap peer is about to leave the overly, then the enrollment server will select another bootstrap peer from the capable bootstrap peer database to replace the invalid or congested one. The enrollment server still needs to check the aliveness of this new candidate and then notify it about its election as the bootstrap peer. There should be a way to keep the number of bootstrap peer candidates within a limited number, say M. So the enrollment server should prioritize the candidate peers, and remove the candidate peers in the rear of the list after the first M peers. And the list should be refreshed in period. However, this is an internal implementation issue. 2. Terminology The concepts used in this document are compatible with "Concepts and Terminology for Peer to Peer SIP" [I-D.ietf-p2psip-concepts] and the P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base]. 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]. 3. Message Process Song Expires August 31, 2010 [Page 4] Internet-Draft P2PSIP Bootstrap Status Maintenance February 2010 3.1. peer messages These messages are generated by the bootstrap peer or bootstrap peer candidates and be sent to the enrollment server. 3.1.1. Message to identify the peer itself as a capable bootstrap peer Open question: Shall we extend PING message here? 3.1.2. Message for bootstrap peer to report busy status Open question: shall we extend PING message here? 3.2. Enrollment server messages These messages are generated by the enrollment server and be sent to the bootstrap peers. 3.2.1. Message to check the aliveness of the bootstrap peer The enrollment server just send an Inspect message [I-D.ietf-p2psip-diagnostics], and sets the destination ID with the bootstrap peer's peer ID, send it directly to this bootstrap peer's IP address. (1) If the enrollment server receives an Inspect response with the source ID using the bootstrap peer's peer ID, then this bootstrap peer is alive. (2) If the enrollment server does not receive any response, it will try several times, till it can ensure that the peer has left the overlay. Or finally get a response. 3.2.2. Message to notify the election of a bootstrap peer Open question: shall we extend PING message here? , that means, the peer received this message will have to deal with upcoming Join message thereafter and has to report its busy status to the enrollment server in period. 4. Security Considerations The enrollment server and the bootstrap peer have to do mutual authentication when communicate with each other to prevent from Song Expires August 31, 2010 [Page 5] Internet-Draft P2PSIP Bootstrap Status Maintenance February 2010 identity attacks. 5. IANA Considerations There is no IANA consideration in this document. 6. Acknowledgments The author would like to thank David Bryan for comments. And would also like to thank people contribute to previous discussion on this topic in the list. 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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [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-07 (work in progress), February 2010. [I-D.ietf-p2psip-diagnostics] Yongchao, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP Overlay Diagnostics", draft-ietf-p2psip-diagnostics-02 (work in progress), December 2009. 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-02 (work in progress), July 2008. [I-D.matthews-p2psip-bootstrap-mechanisms] Cooper, E., "Bootstrap Mechanisms for P2PSIP", draft-matthews-p2psip-bootstrap-mechanisms-00 (work in Song Expires August 31, 2010 [Page 6] Internet-Draft P2PSIP Bootstrap Status Maintenance February 2010 progress), February 2007. Author's Address Song Haibin Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565867 Fax: +86-25-84565085 Email: melodysong@huawei.com Song Expires August 31, 2010 [Page 7]