P2PSIP B. Lowekamp
Internet-Draft SIPeerior Technologies
Intended status: Standards Track October 27, 2008
Expires: April 30, 2009
RELOAD Node Operations Proposal
draft-lowekamp-p2psip-nodefetch-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 30, 2009.
Abstract
This document defines a set of methods for Node-specific operations
as part of the REsource LOcation And Discovery (RELOAD) protocol.
This document defines NodeFetch, NodeStore, and NodeRemove methods
that allows manipuation of Node specific usage data. These methods
will be useful for multiple diagnostic, administrative, and discovery
usages. Because of their usefulness for a variety of expected
usages, these methods are advanced for inclusion in the base RELOAD
protocol.
Lowekamp Expires April 30, 2009 [Page 1]
Internet-Draft RELOAD NodeFetch October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Need for New Methods . . . . . . . . . . . . . . . . . . . . . 4
5. New Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. NodeFetch . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. Request Definition . . . . . . . . . . . . . . . . . . 5
5.1.2. Response Definition . . . . . . . . . . . . . . . . . . 5
5.2. NodeStore . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2.1. Request Definition . . . . . . . . . . . . . . . . . . 5
5.2.2. Response Definition . . . . . . . . . . . . . . . . . . 5
5.3. NodeRemove . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3.1. Request Definition . . . . . . . . . . . . . . . . . . 6
5.3.2. Response Definition . . . . . . . . . . . . . . . . . . 6
6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Message Codes . . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Lowekamp Expires April 30, 2009 [Page 2]
Internet-Draft RELOAD NodeFetch October 2008
1. Introduction
The base RELOAD protocol [I-D.ietf-p2psip-base] defines Fetch, Store,
and Remove operations that operate on resources identified by
Resource-ID. However, there are a number of other operations,
including diagnostic usages proposed in the base RELOAD draft and
[I-D.zheng-p2psip-diagnose] that require the ability to query for
information particular to a specific peer, rather than for
information stored indexed by Resource-ID. Such queries may be sent
to either a previously-known Node-ID or to the peer responsible for a
particular Resource-ID. The NodeFetch, NodeStore, and NodeRemove
operations described here are intended to support these operations.
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].
3. Motivation
A variety of scenarios motivate the need for node-specific
operations:
Diagnostics Diagnostics have been proposed in [I-D.ietf-p2psip-base]
and [I-D.zheng-p2psip-diagnose]. The breadth of diagnostics
proposed, and the needs of the wide variety of deployment
scenarios envisioned for P2PSIP [I-D.ietf-p2psip-concepts] seems
to imply that there will be multiple diagnostic usages described
in different drafts. Therefore, it seems desireable to propose a
common set of methods in the base draft that all diagnostic usages
can reference.
Administration There is a spectrum of operations that range from
diagnostic to administrative control over nodes. While some
application scenarios imply little central control, others assume
the existence of an authorized administrator to control nodes in
the overlay [I-D.ietf-p2psip-concepts]. Providing these methods
will allow future usages to rely on the same fundamental methods
already required for diagnostic purposes.
Discovery & Placement P2P applications frequently require some form
of service discovery. Equally important as service discovery is
service placement. While some algorithms for performing such
operations store location data indexed by Resource-ID
[opendht-sigcomm05], others rely on the ability to send Fetch or
Store operations to a peer responsible for a particular
Resource-ID (an operation not supported by the current Store and
Fetch) [placement-iptps05].
Lowekamp Expires April 30, 2009 [Page 3]
Internet-Draft RELOAD NodeFetch October 2008
4. Need for New Methods
One possibility is to extend the existing Fetch/Store/Remove
operations to support per-node behavior. A variety of possibilities
exist: allowing usages to specify whether each kind refers to node-
specific or Resource-ID indexed objects, adding a flag to the request
structures indicating that the request is node-specific, or reserving
a portion of the kind-space to identify node-specific operations.
Unfortunately, each of these proposals adds complexity to the
existing protocol encoding or assumes a particular architecture where
the storage component does not make decisions without interaction
with a usage module.
A particular challenge in providing node-specific operations is
routing a node-specific request to the peer responsible for a
particular Resource-ID. While some node-specific requests are routed
to a known Node-ID, others will be routed simply to a Resource-ID and
will therefore have no encoding of the Node-ID of the node being
queried in the message. Therefore, a node cannot examind the
FetchReq, for example, to see if the queried resource matches its
Node-ID, and thus deduce the request is for node-specific
information.
One possibility for providing operations that refer to node-specific
data on a peer responsible for a given Resource-ID is to perform two
separate operations, a Probe followed by a node-specific Fetch to a
particular Node-ID. However, this two-phase approach may fail in
diagnostic situations where the overlay is unstable---if these
methods are being used to determine the reasons for the instability,
it is likely to be far more useful to have an atomic NodeFetch that
returns the diagnostic information on the node that is reached by the
first query rather than assuming that consecutive queries will reach
the same node.
Therefore, to reduce the complexity of supporting node-specific
operations, a new set of methods are proposed that are exclusively
for node-specific operations. A node receiving such a method will
always know to process it in the appropriate manner, regardless of
its particular implementation. Furthermore, although the methods are
different, most of the message structure is shared with the base
Fetch/Store/Remove operations, thus minimizing additional
implementation complexity.
5. New Methods
NodeFetch is required for all proposed usage scenarios. NodeStore
and NodeRemove are required for the administrative and discovery/
Lowekamp Expires April 30, 2009 [Page 4]
Internet-Draft RELOAD NodeFetch October 2008
placement usage scenarios.
The bodies of each of the messages are essentially identical to their
Resource-ID counterparts, except for the lack of encoded ResourceId's
in the objects.
5.1. NodeFetch
5.1.1. Request Definition
struct {
StoredDataSpecifier specifiers<0..2^16-1>;
} NodeFetchReq;
5.1.2. Response Definition
struct {
FetchKindResponse kind_responses<0..2^32-1>;
} NodeFetchAns;
5.2. NodeStore
5.2.1. Request Definition
struct {
StoreKindData kind_data<0..2^32-1>;
} NodeStoreReq;
5.2.2. Response Definition
struct {
KindId kind;
uint64 generation_counter;
} NoteStoreKindResponse;
struct {
NodeStoreKindResponse kind_responses<0..2^16-1>;
} StoreAns;
Lowekamp Expires April 30, 2009 [Page 5]
Internet-Draft RELOAD NodeFetch October 2008
5.3. NodeRemove
5.3.1. Request Definition
struct {
StoredDataSpecifier specifiers<0..2^16-1>;
} NodeRemoveReq;
5.3.2. Response Definition
struct {
NoteStoreKindResponse kind_responses<0..2^16-1>;
} RemoveAns;
6. Security
There are inherent security risks in disclosing operational data
through a Diagnostic fetch, and additional risks in allowing remote
administration of a node. Usages relying on these methods will need
to identify the risks involve and specify appropriate authorization
mechanisms (presumably based on the certificate model used for
identification and authorization in RELOAD) for ensuring that such
operations are performed only by authorized entities.
7. IANA Considerations
This section contains the new code points registered by this
document. [NOTE TO IANA/RFC-EDITOR: Please replace RFC-AAAA with
the RFC number for this specification in the following list.]
7.1. Message Codes
IANA SHALL add the follwoing to the a"RELOAD Message Code" Registry:
Lowekamp Expires April 30, 2009 [Page 6]
Internet-Draft RELOAD NodeFetch October 2008
+-------------------+------------+----------+
| Message Code Name | Code Value | RFC |
+-------------------+------------+----------+
| node_store_req | 29 | RFC-AAAA |
| node_store_ans | 30 | RFC-AAAA |
| node_fetch_req | 31 | RFC-AAAA |
| node_fetch_ans | 32 | RFC-AAAA |
| node_remove_req | 33 | RFC-AAAA |
| node_remove_ans | 34 | RFC-AAAA |
+-------------------+------------+----------+
8. Acknowledgments
This proposal has evolved from discussions with Cullen Jennings, Eric
Rescorla, Song Haibin, Jiang Xingfeng, and David Bryan. Eric
Rescorla wrote the message PDUs.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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-00 (work in
progress), October 2008.
9.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.zheng-p2psip-diagnose]
Yongchao, S., Zhang, H., and X. Jiang, "Diagnose P2PSIP
Overlay Network Failures", draft-zheng-p2psip-diagnose-02
(work in progress), July 2008.
[opendht-sigcomm05]
Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J.,
Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu,
Lowekamp Expires April 30, 2009 [Page 7]
Internet-Draft RELOAD NodeFetch October 2008
"OpenDHT: A Public DHT and its Uses", SIGCOMM'05.
[placement-iptps05]
Pietzuch, P., Shneidman, J., Ledlie, J., Welsh, M.,
Seltzer, M., and M. Roussopoulos, "Evaluating DHT-Based
Service Placement for Stream-Based Overlays", IPTPS'05.
Author's Address
Bruce B. Lowekamp
SIPeerior Technologies
5251-18 John Tyler Highway #330
Williamsburg, VA 23185
USA
Email: bbl@lowekamp.net
Lowekamp Expires April 30, 2009 [Page 8]
Internet-Draft RELOAD NodeFetch October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Lowekamp Expires April 30, 2009 [Page 9]