Internet DRAFT - draft-li-p2psip-client-extension
draft-li-p2psip-client-extension
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]
