P2PSIP Working Group L. Li Internet-Draft Y. Peng Intended status: Standards Track J. Wang Expires: May 3, 2012 ZTE Corporation October 31, 2011 RELOAD Client Extension draft-li-p2psip-client-extension-01 Abstract This draft describes mechanisms of multiple access peers and backup access peer. This draft also proposes additional ways 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 May 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 carefully, as they describe your rights and restrictions with respect to this document. Li, et al. Expires May 3, 2012 [Page 1] Internet-Draft RELOAD Client Extension October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multiple Access Peers . . . . . . . . . . . . . . . . . . . . . 3 4. Backup Access Peer . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Using Responsible Peer as Access Peer . . . . . . . . . . . 4 4.2. Using Arbitrary Peer as Access Peer . . . . . . . . . . . . 5 5. Direct Routing to Client or Access Peer . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Li, et al. Expires May 3, 2012 [Page 2] Internet-Draft RELOAD Client Extension October 2011 1. Introduction RELOAD base draft [I-D.ietf-p2psip-base] has defined the client behavior and two ways to route message to client. One way is using the responsible peer of client's Node ID's as access peer, the other way is using arbitary peer as access peer. Using arbitary peer allows client to choose a access peer better than its responsible peer in terms of RTT, load. If a node wants to send RELOAD message to a client using arbitary peer as access peer, the node must know both the client's node ID and the client's access peer's node ID. 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 in these drafts. This draft describes the mechanisms of multiple access peers, backup access peer and switching access peer. This draft also proposes additional ways to route message to client. 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 [RFC2119]. We use the terminology and definitions from the RELOAD base protocol [I-D.ietf-p2psip-base] extensively in this document. 3. Multiple Access Peers Mutiple access peers allow load sharing and avoid single point of failure. If a sender (say node A) wants to send message to the client, it first obtains the client's node ID and 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 a chosen access peer's node ID and the client'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 from sender's node ID to access peer's node ID, etc. If sending fails due to the failing of an access peer, sender can choose another access peer's node ID to reconstruct destination list and send the message again. An example of using multiple access peers is shown in the figure below. Li, et al. Expires May 3, 2012 [Page 3] Internet-Draft RELOAD Client Extension October 2011 A B C(AP) D E(AP) Z(client) -+----------+------------+------+--------+--------+- | | | | | Attach | | | |<-----|--------+--------| | | | | | Attach | | | | | |<-------| |--------->| | | | | |Dest=C,Z | \|/ | | | | |----------->X | | | | | Dest=C,Z / \ | | | | | | | | |----------------------------->| | | | Dest=E,Z |------->| | | |Dest=E,Z| | | | |------->| | | | Dest=Z | 4. Backup Access Peer 4.1. Using Responsible Peer as Access Peer A client may attachs to both its responsible peer and responsible peer backup. The responsible peer backup is the peer would be responsible for the client's node ID, if the client's current responsible peer fails. If the RELOAD overlay uses CHORD algorithm, the responsible peer backup is the successor of responsible peer. As shown in the figure below, with this backup mechanism, messages destinated to the client can be automatically sent to the client via responsible peer backup if responsible peer fails. H Z A F G(AP/RP) backup AP/RP client -+----------+------------+---------------+--------+- | | | Attach | | | | |<--------------+--------| | | | | | | | | | Attach | | | | |<-------| |--------->| | | | | Dest=Z | \|/ | | | |----------->X | | | | Dest=Z / \ | | | | | | | |--------------------------->| | | | Dest=Z | | | | |------->| | | | Dest=Z | Li, et al. Expires May 3, 2012 [Page 4] Internet-Draft RELOAD Client Extension October 2011 4.2. Using Arbitrary Peer as Access Peer In RELOAD base draft, a client's access peer is located via access peer's ID if the client using arbitrary peer as its access peer. This document proposes to locate an access peer with a resource ID named access resource ID. Client uses the response peer of access resource ID as access peer, and attaches to the backup response peer of access resource ID, which acts as the client's backup access peer. With a destination list containing a client's access resource ID and the client's node ID, messages can be routed to the client. If current access peer fails, messages sent to the client still be routed by its backup access peer. E Z A C D(AP) backup AP client -+--------------------+---------------------+---------------+--------+- | | | Attach | | | | |<--------------+--------| | | | | | | | | | Attach | | | | |<-------| |------------------->| | | | |Dest=D(as res ID),Z | \|/ | | | |-------------------->X | | | |Dest=D(as res ID),Z / \ | | | | | | | |------------------------------------>| | | | Dest=D(as res ID),Z | | | | |------->| | | | Dest=Z | An example is shown in above figure. In this example, the RELOAD overlay uses CHORD algorithm, and client Z's access peer is node D. Client Z publishes its node ID and access resource ID D, which is equal to node D's node ID. Messages sent to Z are all routed via node D unless D fails. If node D fails, messages sent to Z will be routed via node D's backup node E. 5. Direct Routing to Client or Access Peer As shown in the figure below, if a client is publicly accessible, messages can be routed from the sender to the client directly. To send messages to the client, the sender 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 the sender fetches them from overlay. Then the sender sends RELOAD messages to the client directly. Li, et al. Expires May 3, 2012 [Page 5] Internet-Draft RELOAD Client Extension October 2011 A Z(client) -+------------------------------+ | | +-----------+------------+ | |Obtain client's node ID | | | and IP address | | +-----------+------------+ | | | | Attach | |----------------------------->| | | |----------------------------->| | Dest=Z | | | As shown in the figure below, if a client's access peer is publicly accessible, messages can be routed from the sender to the client's access peer directly, and the client's access peer route messages to the client . To send messages to the client, the sender first obtains the client's access peer's IP address via some kind of mechanism. For example, the client stores its access peer's IP address and node ID in the overlay using some kind of usage, and the sender fetches them from overlay. Then the sender sends RELOAD messages to the client's access peer directly. A E Z(client) -+------------------------------+--------+ | | | +-----------+------------+ | | |Obtain client's node ID,| | | | client's AP's node ID | | | | and AP's IP address | | | +-----------+------------+ | | | Attach | | |----------------------------->| | | | | |----------------------------->| | | Dest=E,Z |------->| | | Dest=Z | 6. Security Considerations TBD 7. IANA Considerations Li, et al. Expires May 3, 2012 [Page 6] Internet-Draft RELOAD Client Extension October 2011 8. 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-19 (work in progress), October 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-06 (work in progress), Jul 2011. [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 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 May 3, 2012 [Page 7]