Internet DRAFT - draft-xiao-ppsp-reload-distributed-tracker
draft-xiao-ppsp-reload-distributed-tracker
PPSP L.Xiao
Internet Draft Nokia Siemens Networks
Intended status: Informational D.Bryan
Expires: April 26, 2012 Cogent Force, LLC/Huawei
Y.Gu
Huawei
X.Tai
China Mobile/BUPT
October 25, 2011
A PPSP Tracker Usage for Reload
draft-xiao-ppsp-reload-distributed-tracker-03
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 April 26, 2012.
Copyright Notice
Copyright (c) 2010 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.
Xiao Expires April 26,2012 [Page 1]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
This document may not be modified, and derivative works of it may not
be created, and it may not be published except as an Internet-Draft.
Abstract
This document defines PPSP tracker usages for REsource LOcation And
Discovery (RELOAD). Although PPSP assumes a centralized tracker from
peer's point of view, the logical centralized tracker could be realized
by a cluster of geographically distributed trackers. In this draft, we
design distributed trackers system, which are organized by RELOAD. It
provides lookup service for file/channel indexes and Peer Status among
the distributed trackers.
Table of Contents
1. Introduction ................................................ 2
2. Terminology and Conventions.................................. 4
3. Content Information Registration and Update.................. 5
3.1. Data structure of ContentRegistration................... 5
3.2. Message flows .......................................... 7
4. Lookup Content Index (a Swarm)............................... 8
5. Peer Status Registration, Update and Lookup.................. 9
5.1. Data Structure of PeerStatusIndex...................... 10
6. Kind Definition ............................................ 10
6.1. CONTENT-REGISTRATION Kind Definition................... 10
6.2. PEER-STATUS Kind Definition............................ 10
7. Security Considerations..................................... 11
8. IANA Considerations ........................................ 11
9. Acknowledgments ............................................ 11
9.1. Normative References................................... 12
9.2. Informative References................................. 12
Author's Addresses ............................................ 13
1. Introduction
PPSP assumes that a centralized 'tracker' is used to communicate with
the PPSP Peers for content registration and location. The content
index is stored in the tracker with location information that which
peers have the content.
However, the logically centralized 'tracker' could be also realized
by a cluster of geographically distributed trackers or deployed in
multiple servers in a data center, which can increase the content
availability, the service robustness and the network scalability or
reliability. The management and locating of index information are
totally internal behaviors of the tracker cluster, which is invisible
Xiao Expires April 21, 2012 [Page 2]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
to PPSP Peers. The signaling between PPSP Peers and trackers is still
the simple request/reply mechanism defined in PPSP tracker protocols.
Therefore, the Tracker Nodes themselves construct and maintain a P2P
overlay as shown in Figure 1. This document is to define the
behaviors of the tracker overlay as a usage for RELOAD. Because all
protocols this draft applies to - the PPSP tracker protocol, PPSP
peer protocol and RELOAD - are still changing, this draft will
certainly change in the future, and is very much a work in progress.
The authors encourage list discussion of the draft and any
suggestions are welcome.
Tracker1 Tracker6
-- --
---| |------| |---
| -- -- |
| |
-- --
Tracker2 | | Tracker Overlay | | Tracker5
-- --
| |
| -- -- |
---| |------| |---
Tracker3 -- -- Tracker4
/ \ \
/ \ \
/ \ \
----- ----- -----
|Peer1| |Peer2| |Peer3|
----- ----- -----
Figure 1 PPSP Peers connect with Tracker Overlay by Tracker
Protocol
The document tries to handle the data maintenance for two kinds of
information: content index and PPSP peer status, among a cluster of
distributed trackers. Four basic functions in tracker overlay are
defined as follows:
Xiao Expires April 21, 2012 [Page 3]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
o Content/ channel index information registration: PPSP Peers
registrar/update their contents/channels to a Connection Tracker.(How
to find the initial tracker locally is out of scope.) This tracker
takes the advantage of the RELOAD data storage functionality to store
the index information to tracker nodes in the tracker overly
accordingly. At the same time, the local Connection Tracker keeps a
copy of local peer's content information for traffic localization.
o Look up a content/channel index: Once a PPSP Peer search for
certain content/channel, it makes the request to a local Connection
Tracker as defined in PPSP tracker protocol. If the swarm cannot be
found or there is not enough peer records for such swarm in the
Connection Tracker locally, the tracker will further locate the
required index information in the tracker overlay on behalf of the
requesting PPSP Peer. Once the full Peer List is fetched, the PPSP
Peer will set up communications with the PPSP Peers in the Peer List
as defined in PPSP Peer protocol;
o PPSP peer status registration: PPSP Peers registrar/update their
status in the tracker overlay. All PPSP peers should firstly
register their status to the local Connection Tracker. In order to
enable this information being aware globally, the Connection Tracker
should then store the position of the PPSP peer's status in the
tracker overlay according to RELOAD scheme. The following peer
status updates are only sent to the local Connection Tracker, the
RELOAD based tracker overlay here only offers a way for remote nodes
to find the location of requested peer status.
o Look up status of a certain peer: the tracker overlay can look up
the status of a certain PPSP Peer. If the peer status cannot be
found in the local Connection Tracker (that means it's not a local
peer), the local tracker then searches the Status Position Tracker
for the requested peer in the tracker overlay by RELOAD, which gives
a route to access the status of the remote peer.
2. Terminology and Conventions
This document makes extensive use of the terminology and definitions
from the RELOAD Base Protocol [I-D.ietf-p2psip-base], PPSP
Requirements and Problem Statements [I-D.ietf-ppsp-problem-
statement][I-D.ietf-ppsp-reqs] and the Gu PPSP Tracker Protocol
proposal [I-D.gu-ppsp-tracker-protocol].
This document defines the following additional terminology:
Xiao Expires April 21, 2012 [Page 4]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
PPSP Peer: The peer in PPSP protocol for content sharing and
distribution among swarms.
Tracker Node: The RELOAD Node with PPSP tracker usage. Each Tracker
Node takes the responsibility to store and maintain certain
content/channel index.
Tracker Overlay: A RELOAD overlay constructed by Tracker Nodes. This
Overlay is logically separated with overlay formed by PPSP Peers.
Connection Tracker: The Tracker Node to which the PPSP Peer will
connect when it wants to join the PPSP system.
Swarm Tracker: The Tracker Node who is responsible for the swarm in
the overlay, and stores the content information (e.g. Peerlist) of
the swarm.
Status Position Tracker: A Tracker Node which is responsible to
store the Position of certain peers' status of a particular list of
Peers.
3. Content Information Registration and Update
To fulfill the functions of content information registration and
update mentioned in Section 1, Tracker Node must maintain such
resources related to peers;
Content Registration: Information about the content which belongs to
a specific swarm. It can be stored in a data structure denoted as
ContentRegistration, which primarily includes an identification of
the swarm, a name of the content, and a Peer List.
3.1. Data structure of ContentRegistration
Structure The data structure of ContentRegistration uses the RELOAD
dictionary kind whereas the DictionaryKey value is the Swarm ID of
the content required. The data structure of type ContentRegistration
is shown as follows:
struct{
Uint32 index;
ChunkID chunk_id;
Xiao Expires April 21, 2012 [Page 5]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
}ArrayChunkListData;
struct{
PeerID peer_id;
ArrayChunkListData chunklist_data;
}PeerListData;
struct{
uint16 length;
PeerListData peerlist_data;
}PeerList;
struct {
uint16 length;
opaque content_name<0..2^16-1>;
PeerList peerlist <0..2^16-1>;
} ContentRegistration;
The content of the PeerList structure are as follows:
length
the length of the data structure
content_name
the name of the content
peerlist
Xiao Expires April 21, 2012 [Page 6]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
the content of Peer List
3.2. Message flows
When a PPSP Peer wishes to share its contents to others, it will
inform Tracker Overlay with the swarm information of the contents,
then Swarm Tracker need to add this PPSP Peer into the corresponding
Peer List to the swarm, or create a new swarm when there is no record
of the swarm. A local record of the swarm may also be set up at the
Connection tracker. Correspondingly, When a PPSP Peer deletes some
old contents locally, it will inform Tracker Overlay that it would
like to leave from a particular swarm, then both Connection Tracker
and Swarm Tracker need to delete this PPSP Peer from the
corresponding Peer List which is defined in the requirement of PPSP
[I-D.ietf-ppsp-reqs].
An example is given as the figure has shown below:
1. PPSP Peer wants to join into a swarm to share the content, first
it will send a PPSP message "Join" with a Swarm-ID to TrackerA, which
is a connection tracker of the Tracker Overlay for PPSP Peer connects
to;
2. TrackerA first handles the registration locally, then finds the
Swarm Tracker by mapping the swarm ID to node ID of the Swarm Tracker,
to forward the request. So TrackerA sends a RELOAD message "StoreReq"
to TrackerB who is the Swarm Tracker for the content swarm;
3. When Swarm Tracker (TrackerB) receives the request (or if
TrackerA is responsible for the Peer List of the swarm,
TrackerB=TrackerA), it searches locally the Peer List of the swarm
whose ID is the Swarm-ID, then add the Node-ID of the PPSP Peer into
the Peer List or delete it from that, and send the result of the
operation (e.g. successful or failed) in a RELOAD message
"StoreReqAns" to TrackerA through Tracker Overlay;
4. Finally, TrackerA analyses the received message, and responds to
the requesting Peer by a corresponding PPSP message: "Successful
(OK)" or some error messages.
Note: When PPSP Peer is the first node of the swarm, which means it
is the first one who stores this kind of content in the network,
TrackerB doesn't have records of the new swarm, TrackerB will create
a new ContentRegistration for the swarm locally, and put the
identification of PPSP Peer into Peer List of this new
Xiao Expires April 21, 2012 [Page 7]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
ContentRegistration, then send the result of the operation (e.g.
successful or failed) in a RELOAD message "StoreReqAns" to TrackerA
through Tracker Overlay.
(connection) (overlay) (swarm)
PPSP Peer TrackerA TrackerX TrackerB
--------------------------------------------------------------
--JOIN-> |keep a copy|
--StoreReq->
--StoreReq->
<-StoreReqAns--
<-StoreReqAns--
<-SUCCESSFUL(OK) -
Figure 2 Content Information Registration and Update
If PPSP Peer wishes to update content information, for example, list
of chunks it has, it sends a PPSP message "JOIN_CHUNK" to TrackerA.
TrackerA makes update in its local table, and then sends the
corresponding RELOAD message to TrackerB to update the detailed
chunk-IDs in the Swarm according to the request message.
4. Lookup Content Index (a Swarm)
When a PPSP Peer wants to use some streaming service, which means it
wants to download some interested contents from the system, it
firstly needs to get related Peer List from Tracker Overlay. As the
figure has shown below:
1) PPSP Peer wants to watch a video belonging to a swarm with a
Swarm-ID, firstly it sends a PPSP message "Find" with the Swarm-ID to
Connection TrackerA;
2) If TrackerA has enough local peer record for swarm, it can reply
the request directly. Or it maps the Swarm-ID into a Node-ID to
identify the Swarm Tracker, TrackerB, which stores the Peer List of
the requested swarm. It then sends a RELOAD message "FetchReq" to
TrackerB;
Xiao Expires April 21, 2012 [Page 8]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
3) When Swarm TrackerB receives the request (or if TrackerA is
responsible for the Peer List of the swarm, TrackerbB=TrackerA), it
searches the Peer List of the swarm locally, then send the Peer List
which is organized by the data structure of PeerList in a RELOAD
message "FetchReqAns" to TrackerA through Tracker Overlay;
4) Finally, TrackerA analyses the received PeerList structure, and
reconstructs it into a PPSP message "Successful(OK)", then forwards
it to the PPSP Peer.
(connection) (overlay) (swarm)
PPSP Peer TrackerA TrackerX TrackerB
--------------------------------------------------------------
--Find->
<-SUCCESSFUL(OK) |or| --FetchReq->
--FetchReq->
<-FetchReqAns--
<-FetchReqAns--
<-SUCCESSFUL(OK)-
Figure 3 Content Information Lookup
5. Peer Status Registration, Update and Lookup
To fulfill the functions of peer status registration, update and
lookup mentioned above, Tracker Node must maintain such resource
related to peers:
Information about status of peers: the local Connection Tracker takes
the responsibility to maintain the PPSP Peer status locally,
including online time, link status, node capability and other
streaming parameters, etc. It can be stored in a data structure
denoted as PeerStatus.
Position of PPSP peer status: each PPSP Peer can be mapped to a
Status Position Tracker in the tracker overlay. The status Position
Tracker takes responsibility to only record the route (i.e., the
address of the local Connection Tracker of the Peer) to access the
PPSP Peer status.
Xiao Expires April 21, 2012 [Page 9]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
5.1. Data Structure of PeerStatusIndex
The data structure of PeerStatusIndex uses the RELOAD dictionary kind
whereas the DictionaryKey value is the Peer ID. The data structure
of type PeerStatusIndex is shown as follows:
struct{
TrackerID Connection_Tracker_ID;
}PeerStatusIndex;
The content of the PeerStatusIndex structure are as follows:
trackerID the ID of the Peer's Connection Tracker;
6. Kind Definition
6.1. CONTENT-REGISTRATION Kind Definition
This section defines the CONTENT-REGISTRATION kind.
o Name: CONTENT-REGISTRATION
o Kind IDs: The Resource Name for the CONTENT-REGISTRATION Kind-ID
is Swarm Name. The data stored is a CONTENT-REGISTRATION, which
contains a identification of the swarm, a name of the content, and a
list of PPSP Peer-IDs with or not a list of chunk-IDs for each PPSP
Peer to show which chunks the PPSP Peer has.
o Data Model: The data model for the CONTENT-REGISTRATION Kind-ID is
dictionary. The dictionary key is the Swarm-ID of the peer action as
focus.
o Access Control: USER-NODE-MATCH.
6.2. PEER-STATUS Kind Definition
This section defines the PEER-STATUS kind.
o Name: PEER-STATUS
Xiao Expires April 21, 2012 [Page 10]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
o Kind IDs: The Resource Name for the PEER-STATUS Kind-ID is Peer
Status. The data stored is a PEER-STATUS, which contains a
identification of the peer and a identification of the peer's
connection tracker.
o Data Model: The data model for the PEER-STATUS Kind-ID is
dictionary. The dictionary key is the Peer-ID.
o Access Control: USER-NODE-MATCH.
7. Security Considerations
This document does not currently introduce security considerations.
8. IANA Considerations
This document does not specify IANA considerations.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Xiao Expires April 21, 2012 [Page 11]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
References
9.1. Normative References
[1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams,
C., and L. Xiao, "P2P Streaming Protocol (PPSP) Requirements",
draft-ietf-ppsp-reqs-03 (work in progress), July 2011.
[3] [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N.,
Camarillo, G., Seng, J., and Y. Yang, "Problem Statement of P2P
Streaming Protocol (PPSP)", draft-ietf-ppsp-problem-statement-
03 (work in progress), August 2011.
[4] [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-18 (work in
progress), August 2011.
[5] [I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang,
Y., and H. liao, "Tracker Protocol", draft-gu-ppsp-tracker-
protocol-04 (work in progress), May 2011.
9.2. Informative References
Xiao Expires April 21, 2012 [Page 12]
Internet-Draft A PPSP Tracker Usage for Reload October 2011
Author's Addresses
Lin Xiao
Nokia Siemens Networks
No.14 Jiuxianqiao Road
Beijing, 100016
P.R.China
Phone: +86-13810361287
Email: lin.xiao@nsn.com
David A. Bryan
Cogent Force, LLC / Huawei
Email: dbryan@ethernot.org
Yingjie Gu
Huawei
No. 101 Software Avenue
Nanjing, Jiangsu Province 210012
P.R.China
Phone: +86-25-56624760
Email: guyingjie@huawei.com
Xuan Tai
China Mobile/BUPT
Phone: +86-13581762082
Email: taixuanyueshi@gmail.com
Xiao Expires April 21, 2012 [Page 13]
