P2PSIP Working Group L. Li Internet-Draft Y. Peng Intended status: Standards Track J. Wang Expires: January 5, 2012 ZTE Corporation July 4, 2011 RELOAD Client Extension draft-li-p2psip-client-extension-00 Abstract This draft describes mechanisms of client using multiple access peer and changing access peer. This draft also proposes an additional way to route message to client. 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 5, 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 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. Li, et al. Expires January 5, 2012 [Page 1] Internet-Draft RELOAD Client Extension July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multiple Access Peers . . . . . . . . . . . . . . . . . . . . . 3 3. Direct Routing to Client . . . . . . . . . . . . . . . . . . . 3 4. Changing Access Peer . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 Li, et al. Expires January 5, 2012 [Page 2] Internet-Draft RELOAD Client Extension July 2011 1. Introduction RELOAD base draft [I-D.ietf-p2psip-base] has defined the client behavior and two ways to route message to client. SIP usage draft [I-D.ietf-p2psip-sip] defines how SIP application publishes and obtains the route to SIP user's node (peer or client). However, some client related mechanisms are not described or detailed. This draft describes the mechanisms of using multiple access peer and changing access peer. This draft also proposes an additional way to route message to client. 2. Multiple Access Peers To allow load sharing and avoid single point of failure, a client should use multiple access peers. If a node (say node A) wants to send message to the client, it first obtains the client's access peer list via some kind of mechanism. For example, the client stores its access peer list and node ID in the overlay using some kind of usage, and A fetches the list from overlay. Then A sends message to next hop with destination list containing the client's node ID and a chosen access peer's node ID. The access peer in destination list may be chosen from access peer list randomly or based on some kind of criterion like the capacity of access peer, the distance to access peer's node ID, etc. If a sending fails due to the failing of an access peer, A can choose another access peer's node ID to reconstruct destination list and send the message again. 3. Direct Routing to Client If a client is publicly accessible, direct routing can be used to send message to the client. To send messages to the client, A RELOAD node first obtains the client's IP address via some kind of mechanism. For example, the client stores its IP address and node ID in the overlay using some kind of usage, and A fetches the list from overlay. Then the node sends RELOAD messages to the client directly. 4. Changing Access Peer A client MUST changing access peer happens if detects its current access peer fails. A client may change its access peer to a more desirable peer (e.g. a nearby access peer, a light loaded peer). The changing may be Li, et al. Expires January 5, 2012 [Page 3] Internet-Draft RELOAD Client Extension July 2011 initiated by the client or its access peer. If it's initiated by access peer, access peer may use UPDATE method to notify the client. If access peer is determined by client's node ID, access peer would change when responsible peer of client's node ID changes. If a client's access peer is no longer responsible for the client's node ID, access peer MUST notifies the client with UPDATE method. Then the client attaches to the peer responsible for the client's node ID. 5. Security Considerations TBD 6. IANA Considerations 7. Normative References [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. [I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", draft-ietf-p2psip-sip-05 (work in progress), Jul 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Lichun Li ZTE Corporation RD Building 1,Zijinghua Road No.68 Yuhuatai District,Nanjing 210012 P.R.China Email: li.lichun1@zte.com.cn Li, et al. Expires January 5, 2012 [Page 4] Internet-Draft RELOAD Client Extension July 2011 Yonglin Peng ZTE Corporation RD Building 1,Zijinghua Road No.68 Yuhuatai District,Nanjing 210012 P.R.China Email: peng.yonglin@zte.com.cn Jun Wang ZTE Corporation RD Building 1,Zijinghua Road No.68 Yuhuatai District,Nanjing 210012 P.R.China Email: wang.jun17@zte.com.cn Li, et al. Expires January 5, 2012 [Page 5]