One document matched: draft-zheng-p2psip-diagnose-04.txt
Differences from draft-zheng-p2psip-diagnose-03.txt
P2PSIP H. Song
Internet-Draft X. Jiang
Intended status: Standards Track Huawei
Expires: June 2009
December 16, 2008
Diagnose P2PSIP Overlay Network
draft-zheng-p2psip-diagnose-04.txt
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 June 16, 2009.
Abstract
This document describes P2PSIP diagnostics. It describes the usage
scenarios and defines several simple methods for the diagnostics in
P2PSIP overlay network. It also describes types of diagnostic
information which are useful for the connection and node status
monitoring. An optional diagnostic server is also defined for the
overview of the overall health of the overlay. The methods and
message formats are specified as extensions to P2PSIP base protocol
RELOAD.
Song, et al. Expires June 16, 2009 [Page 1]
Internet-Draft P2PSIP DIAGNOSE December 2008
Table of Contents
1. Introduction................................................3
1.1. Usage Scenarios........................................3
2. Terminology.................................................4
3. Motivation..................................................4
4. Overview of Functions.......................................5
5. Packets Formats.............................................7
5.1. Message Codes..........................................7
5.2. Message payloads.......................................8
5.2.1. Error Codes and Sub-Codes.........................8
5.2.2. diagnostics information...........................9
6. Message....................................................10
6.1. Inspect...............................................10
6.2. Path_Track............................................12
6.3. Echo..................................................15
6.4. Error responses.......................................17
7. Diagnostic Server..........................................18
8. Security Considerations....................................18
9. IANA Considerations........................................18
10. Acknowledgments...........................................19
11. References................................................20
11.1. Normative References.................................20
11.2. Informative References...............................21
Author's Addresses............................................22
Song, et al. Expires June 16, 2009 [Page 2]
Internet-Draft P2PSIP DIAGNOSE December 2008
1. Introduction
P2P systems are self-organizing and ideally require no network
management in the traditional sense to set up and to configure
individual P2P nodes. P2P service providers may however contemplate
usage scenarios where some monitoring and diagnostics are required.
We present a simple connectivity test and some useful diagnostic
information that may be used in such diagnostics.
1.1. Usage Scenarios
The common usage scenarios for P2P diagnostics can be broadly
categorized in three classes:
a. Automatic diagnostics built into the P2P overlay routing protocol.
Nodes perform periodic checks of known neighbors and remove those
nodes from the routing tables that fail to respond to connectivity
checks [Handling Churn in a DHT]. The unresponsive nodes may however
be only temporarily disabled due to some local cryptographic
processing overload, disk processing overload or link overload. It is
therefore useful to repeat the connectivity checks to see if such
nodes have recovered and can be again placed in the routing tables.
This process is known as 'failed node recovery' and it can be
optimized as described in the reference [Handling Churn in a DHT].
b. P2P system diagnostics to check the overall health of the P2P
overlay network, the consumption of network bandwidth, problem links
and also checks for abusive or malicious nodes. This is not a trivial
problem and has been studied in detail for content and streaming P2P
overlays, such as for example in [Diagnostic Framework].
Similar work has been reported more recently for P2PSIP overlays as
applied to the P2PP protocol [Diagnostics and NAT traversal in P2PP].
c. Diagnostics for a particular node to follow up an individual user
complaint. In this case a technical support person may use a desktop
sharing application with the permission of the user to determine
remotely the health and possible problems with the malfunctioning
node. Part of the remote diagnostics may consist of simple
connectivity tests with other nodes in the P2PSIP overlay. The simple
connectivity tests are not dependent on the type of P2PSIP overlay
and they are the topic of this memo. Note however that other tests
may be required as well, such as checking the health and performance
of the user's computer or mobile device and also checking the link
bandwidth connecting the user to the Internet.
Song, et al. Expires June 16, 2009 [Page 3]
Internet-Draft P2PSIP DIAGNOSE December 2008
2. Terminology
The concepts used in this document are compatible with "Concepts and
Terminology for Peer to Peer SIP" [I-D.ietf-p2psip-concepts] and the
P2PSIP base protocol RELOAD[I-D.ietf-p2psip-base].
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 [1].
3. Motivation
In the last few years, overlay networks have rapidly evolved and
emerged as a promising platform to deploy new applications and
services in the Internet. One of the reasons overlay networks are
seen as an excellent platform for large scale distributed systems is
their resilience in the presence of failures. This resilience has
three aspects: data replication, routing recovery, and static
resilience. Routing recovery algorithms are used to repopulate the
routing table with live nodes when failures are detected. Static
resilience measures the extent to which an overlay can route around
failures even before the recovery algorithm repairs the routing table.
Both routing recovery and static resilience relies on accurate and
timely detection of failures.
As described in "Security requirements in P2PSIP" [I-D.matuszewski-
p2psip-security-requirement], there are some malfunctioning or badly
behaving peers in P2PSIP overlay, those peers may be disabled peers,
congested peers or peers behaving with misrouting, and the impact of
those peers in the overlay network is degradation of quality of
service provided collectively by the peers in the overlay network or
interruption of those services. It is desirable to identify
malfunctioning or badly behaving peers through some diagnostics tools,
and exclude or reject them from the P2PSIP system. Besides those
faults, node failures may be caused by underlying failures, for
example, when the IP layer routing failover speed after link failures
is very slow, then the recovery from the incorrect overlay topology
may also be slow. Moreover, if a backbone link fails and the failover
is slow, the network may be partitioned, which may lead to partitions
of overlay topologies and inconsistent routing results between
different partitioned components.
Some keep-alive algorithms based on periodically probe and
acknowledge enable accurate and timely detection of failures of one
peer's neighbors [Overlay-Failure-Detection], but those algorithms
only can detect the disabled neighbors using the periodical method,
Song, et al. Expires June 16, 2009 [Page 4]
Internet-Draft P2PSIP DIAGNOSE December 2008
it may not be enough for operating the overlay network by service
providers.
One general P2PSIP overlay diagnostics protocol supporting periodical
method and on-demand method for node failures and network failures is
desirable. This document describes one general P2PSIP overlay
diagnostics protocol useful for P2PSIP base protocol and it is a good
match for some keep-alive algorithms in the P2P or P2PSIP overlay
itself.
4. Overview of Functions
As a diagnostics protocol, P2PSIP diagnostics protocol is mainly used
to detect and localize failures or monitor performance in P2PSIP
overlay network. It provides mechanisms to detect and localize
malfunctioning or badly behaving peers including disabled peers,
congested peers and misrouting peers. It provides a mechanism to
detect direct connectivity or connectivity to the specified peer, a
mechanism to detect availabilities of specified resource records and
a mechanism to discover P2PSIP overlay topology and the underlay
topology failures.
The P2PSIP diagnostics protocol defines Inspect and Path_Track
methods for connection quality check and retrieval of diagnostic
information, as well as Echo method for efficient diagnostics in the
administrative overlay and the Error response to these methods.
Essentially it reuses P2PSIP base protocol specification and then
introduces the new diagnostics methods. P2PSIP diagnostics protocol
strictly follows the P2PSIP base protocol specification on the
messages routing, transporting and NAT traversal etc. The diagnostic
methods are however P2PSIP protocol independent.
In this document, we mainly describe how to detect and localize those
failures including disabled peers, congested peers, misrouting
behaviors and underlying network faults in P2PSIP overlay network
through a simple and efficient mechanism. This mechanism is modeled
after the ping/traceroute paradigm: ping (ICMP echo request [RFC792])
is used for connectivity checks, and traceroute is used for hop-by-
hop fault localization as well as path tracing. This document
specifies a "ping" mode (by defining the Inspect method) and a
"traceroute" mode (implemented differently with trusted overlays such
Song, et al. Expires June 16, 2009 [Page 5]
Internet-Draft P2PSIP DIAGNOSE December 2008
as operator deployed P2PSIP overlays, compared with untrusted
overlays)for diagnosing P2PSIP overlay network.
An Inspect request message is forwarded by the intermediate peers
along the path and then terminated by the responsible peer, and after
optional local diagnostics, the responsible peer returns an Inspect
response message. If an error is found when routing, an Error
response is sent to the initiator node by the intermediate peer.
In "Traceroute" mode, we classify the diagnostics into two
application scenarios.
(1) In trusted p2p overlays, we use an Echo request message, it is
received and disposed by each peer along the routing path, and each
peer along the path returns an Echo response message with optional
local diagnostics information including the result and causes if
existing.
(2) In untrusted p2p overlays, we define a simple Path_Track method
for retrieving diagnostics information iteratively. First, the
initiating node asks its neighbor A which is the next hop node to the
destination ID, and then retrieve the next hop node B information,
along with optional diagnostic information of A, to the initiator
node. Then the initiator node asks the next hop node B(directly or
symmetric routing) to get the further next hop node C information and
diagnostic information of B. This step can be iterative until the
request reaches responsible node D for the destination ID, and
retrieve diagnostic information of node D, or terminates by some
failures that prevent the process.
One approach these tools can be used is to detect the connectivity to
the specified peer or the availability of the specified resource-
record through P2PSIP Inspect operation once the overlay network
receives some alarms about overlay service degradation or
interruption, if the Inspect fails, one can then send a P2PSIP
Traceroute(iterative Path_Track or Echo) to determine where the fault
lies.
The diagnostic information MUST be only provided to authorized peers.
Some diagnostic information can be authorized to all the participants
in the P2PSIP overlay, and some other diagnostic information can only
be provided to the authorization peer list of each diagnostic
information according to the local or overlay policy. The
Song, et al. Expires June 16, 2009 [Page 6]
Internet-Draft P2PSIP DIAGNOSE December 2008
authorization mainly depends on the kinds of the diagnostic
information and the administrative considerations.
5. Packets Formats
This document extends the P2PSIP base protocol to carry diagnostics
information. Considering special usage of diagnostics, this document
defines three simple methods Inspect, Path_Track and Echo, as well as
related Error codes and some useful diagnostics information.
As described in the P2PSIP base protocol, each message has three
parts. This specification is consistent with the format.
+-------------------------+
| Forwarding Header |
+-------------------------+
| Message Contents |
+-------------------------+
| Signature |
+-------------------------+
5.1. Message Codes
The mechanism defined in this document follows P2PSIP base protocol
specification, the new request and response message use the message
format specified in P2PSIP base protocol messages. Different types of
messages convey different message contents following the forwarding
header according to the protocol design. Please refer to P2PSIP base
protocol [I-D.ietf-p2psip-base] for the detailed format of forwarding
header.
This document reuses the Error response in the base protocol and
defines new Error codes to carry different failure reports to the
initiator node when failure is detected during diagnostics.
Name Message Code
Error 0xFFFF
This document introduces three types of message:
Song, et al. Expires June 16, 2009 [Page 7]
Internet-Draft P2PSIP DIAGNOSE December 2008
Name Message Code
Inspect request 29
Inspect response 30
Path_Track request 31
Path_Track response 32
Echo request 33
Echo response 34
The final message code will be assigned by IANA as specified in
section 14.4 of [I-D.ietf-p2psip-base].
5.2. Message payloads
As an extension to P2PSIP base protocol, a P2PSIP diagnostics
protocol message content contains one message code following by its
payloads. Please refer to P2PSIP base protocol [I-D.ietf-p2psip-base]
for the detailed format of Message Contents.
In addition to the newly introduced methods, this document extends
the Error codes defined in P2PSIP base protocol specification.
5.2.1. Error Codes and Sub-Codes
This document extends the Error response method defined in the P2PSIP
base protocol specification to describe the result of diagnostics.
This document introduces new Error Codes as below:
Code Value Error Code Name
8 Underlay Destination Unreachable
9 Underlay Time exceeded
10 Message Expired
11 Upstream Misrouting
12 Loop detected
13 TTL hops exceeded
The final error codes will be assigned by IANA as specified in
section 14.5 of the p2psip base protocol [I-D.ietf-p2psip-base].
This document introduces several types of error information in the
error_info field for Error Code 8 as an example:
Song, et al. Expires June 16, 2009 [Page 8]
Internet-Draft P2PSIP DIAGNOSE December 2008
error_info:
net unreachable
host unreachable
protocol unreachable
port unreachable
fragmentation needed
source route failed
Editor note: We may need more discussion here to see if we need to
define an additional sub-code field for the error information. Sub-
code is easier for the machine to process while various text is
comfortable for a man to read.
5.2.2. diagnostics information
This document introduces some new diagnostics information conveyed in
the message payload, including: the number of hops that the message
traverses, the underlay TTL specified, the timestamp of initiating
the request message, the timestamp of receiving the request message,
and the expiration time of the request message, the processing power,
the bandwidth, the number of entries in one's neighbor table, etc.
They are defined as below. Additional diagnostic information have
been proposed in section 9 of the p2psip base protocol draft [I-
D.ietf-p2psip-base].
HopCounter (8 bits): This byte only appears in diagnostic responses.
It must be exactly copied from the TTL field of the forwarding header
in the received request. Then this information is sent back to the
request initiator to compute the hops that the message traverses in
the overlay.
UnderlayTTL (8 bits): It indicates the underlay TTL which the
intermediate peer must adopt when forwarding the diagnostic requests,
it is specified by the initiator. If the value is 0, then the
intermediate peer must ignore this field, and use the underlay TTL
with its local configuration.
TimestampInitiated (64 bits): The time-of-day (in seconds and
microseconds, according to the sender's clock) in NTP timestamp
format [RFC4330] when the P2PSIP Overlay diagnostic request is sent.
It can be carried in the diagnostic response message from the
receiver; certainly it first appears in the diagnostic request
message;
Song, et al. Expires June 16, 2009 [Page 9]
Internet-Draft P2PSIP DIAGNOSE December 2008
TimestampReceived (64 bits): it is in a diagnostic response message
as the time-of-day (according to the receiver's clock) in NTP
timestamp format [RFC4330] that corresponds to the time that the
P2PSIP Overlay diagnostic request was received;
Expiration(64 bits): the expiration time of the request message, it
is the time-of-day in NTP timestamp format [RFC4330]. It can be used
to mitigate the replay attack to the destination peer and overlay
network.
ProcessPower (32 bits): A single value element containing an unsigned
32-bit integer specifying the processing power of the node in unit of
MIPS.
Bandwidth (32 bits): A single value element containing an unsigned
32-bit integer specifying the bandwidth of the node in unit of Kbps.
Routing_Table_Size (32 bits): A single value element containing an
unsigned 32-bit integer representing the number of peers in the
peer's routing table. The administrator of the overlay may be
interested in statistics of this value for the consideration such as
routing efficiency.
StatusInfo (8 bits): A single value element containing an unsigned
byte representing whether or not the node is in congestion status.
6. Message
All P2PSIP base protocol requests and responses use the common
forwarding header followed by the message contents.
This document defines Inspect and Path_Track methods, and introduces
the new Echo message to detect and localize failures in P2PSIP
overlay network. The Error Codes to these requests are defined in
section 5.2.1 of this spec.
6.1. Inspect
In P2PSIP base protocol, Ping is used to test connectivity along a
path. However, connectivity quality can not be measured well without
some useful information, such as the timestamp and HopCounter. Here
we define a new method Inspect for connectivity quality check
purposes. See below for the Inspect formats.
Song, et al. Expires June 16, 2009 [Page 10]
Internet-Draft P2PSIP DIAGNOSE December 2008
Inspect Request:
struct {
uint8 UnderlayTTL;
uint64 TimestampInitiated;
uint64 Expiration;
} InspectReq;
Inspect Response:
struct {
uint8 HopCounter;
uint64 TimestampReceived;
uint64 Expiration;
}InspectAns;
Any intermediate node which receives the Inspect request must adopt
the UnderlayTTL for the next hop forwarding. If the value equals to 0,
the intermediate peer must ignore this value and determine the
underlay TTL using local configuration. The requirement here is that
one may want to limit each hop underlay TTL from the initiator to the
destination, if the underlay TTL expires somewhere, one may think
that the link there is not of good quality.
Each intermediate peer receiving the Inspect request/response should
check the Expiration value (NTP format) to determine if the message
expired. If the message expired, the intermediate peer should
generate a "Message Expired" Error to the initiator node, and discard
the message. The responsible node for the request or response MUST
check this value to determine if this message should be ignored.
The responsible peer of the Inspect request must exactly copy the TTL
field value in the forwarding header to the HopCounter value in the
response, and meanwhile, it should generate a NTP format timestamp to
indicate the received time.
The initiator node, as well as the responding peer, can compute the
overlay One-Way-Delay time through the value in TimestampReceived and
the TimestampInitiated field.
Editor note: We need more discussion here because time
synchronization is a barrier in open Internet environment, while in
the operator's network, it is not so tricky.
The initiator node receiving the Inspect response must check the
HopCounter field and compute the overlay hops to the destination peer
for the statistics of connectivity quality from the perspective of
overlay hops.
Song, et al. Expires June 16, 2009 [Page 11]
Internet-Draft P2PSIP DIAGNOSE December 2008
Inspect is also used to detect possible failures in the specified
path of P2PSIP overlay network. If disabled peers, misrouting
behavior and underlying network faults are detected during the
routing process, the Error responses with Error codes and
descriptions, must be sent to the initiator node immediately. See
section 6.4 for the details.
6.2. Path_Track
We define a simple Path_Track method to retrieve the diagnostic
information from the intermediate peers along the routing path. At
each step of the Path_Track request, the responsible peer responds to
the initiator node with the status information of itself whether or
not congested , its processing power, its available bandwidth, the
number of entries in its neighbor table, its uptime, his identity and
network address information, and the next hop peer information.
Peer-1 Peer-2 Peer-3 Peer-4
| | | |
|(1).Path_Track Req | | |
|------------------->| | |
|(2).Path_Track ans | | |
|<-------------------| | |
| |(3).Path_Track Req | |
|--------------------|------------------->| |
| |(4).Path_Track Ans | |
|<-------------------|--------------------| |
| | |(5).Path_Track Req |
|--------------------|--------------------|------------------->|
| | |(6).Path_Track Ans |
|<-------------------|--------------------|--------------------|
| | | |
Path_Track example
A Path_Track request must specify which diagnostic information is
requested by setting different bits in the flag contained in the
Path_Track request payload. If the flag is clear, then the Path_Track
request is only used for asking the next hop information, in this
case the iterative mode of Path_Track is used only for checking the
liveness of the peers along the routing path. The Path_Track request
can be routed directly or through the overlay based on the local
policy of the initiator node.
Song, et al. Expires June 16, 2009 [Page 12]
Internet-Draft P2PSIP DIAGNOSE December 2008
Path_Track request:
struct {
Destination destination;
Uint32 dFlags;
uint64 Expiration;
} RathTrackReq;
destination : The destination which the requester is interested in.
This may be any valid destination object, including a Node-ID,
compressed ids, or Resource-ID.
dFlags : An unsigned 32-bit integer indicating which kind of
diagnostic information the initiator interested in. The initiator
sets different bits to retrieve different kinds of diagnostic
information. If dFlags is clear, then no diagnostic information is
conveyed in the Path_Track response. If dFlag is set to 0xFFFFFFFF,
then all diagnostic information kinds are requested. The kinds of
diagnostic information including: status information, its processing
power, its available bandwidth, the number of entries in its neighbor
table, its uptime, etc. The mapping between the bits in the dFlags
and the diagnostic information kind is as below:
StatusInfo Flag(0x0001) : if set, the status information of
the responding peer is requested;
Routing_Table_Size Flag(0x0002) : if set, the number of
entries in the responding peer's neighbor is requested;
ProcessPower Flag(0x0004) : if set, the processing power
information of the responding peer is requested;
Bandwidth Flag(0x0008) : if set, the bandwidth information of
the responding peer is requested;
[TODO: The bits in the dFlags should also map to the diagnostic
information defined in section 9 of p2psip base draft.]
A response to a successful PathTrackReq is a PathTrackAns message.
There is a general diagnostic information part based on the flags.
Song, et al. Expires June 16, 2009 [Page 13]
Internet-Draft P2PSIP DIAGNOSE December 2008
Path_Track response:
struct {
Destination next_hop;
Diagnostic_Info diag_info_list<0..2^5-1>;
uint64 Expiration;
} RathTrackAns;
next_hop : The information of the next hop node from the responding
intermediate peer to the destination node. If the responding peer is the
responsible peer for the destination ID, then the next_hop node ID
equals the responding node ID, and after that the initiator must stop
the iterative process.
diag_info_list: The diagnostic information from the responding peer.
The TLV structure for Diagnostic_Info is as the following:
struct {
uint8 Kind-ID;
uint8 length;
Opaque diagnosic_information<0..2^8-1>;
} Diagnostic_Info;
Various kinds of diagnostic information can be retrieved, some of them
are defined in this document, and some of them are defined in the p2psip
base draft. This document introduces additional three new data kind-IDs
as below:
Kind Kind-ID
StatusInfo 16
ProcessPower 17
Bandwidth 18
The final kind-IDs will be assigned by IANA as specified in section
14.2 of the p2psip base protocol [I-D.ietf-p2psip-base].
As for the Path_Track responses, whether or not sending back certain
kind of diagnostic information to the initiator node depends on (1)
the dFlags (2)the authorization policy.
Failures may be detected during the process, after that an Error
response should be reported to the initiator node immediately.
Song, et al. Expires June 16, 2009 [Page 14]
Internet-Draft P2PSIP DIAGNOSE December 2008
6.3. Echo
An Echo request message is used to retrieve the diagnostic
information of the specified path in administrative p2p overlays
where all the peers in the overlay are trusted or based on specific
authorization. For example, it can be used in a p2p overlay where all
peers deployed by the operator to provide services to the
customers(clients), where the diagnostics happens between peers in
the p2p overlay. For the untrusted p2p overlays, the Echo method must
be used with care for the consideration of potential DoS attack.
An Echo request is normal P2PSIP base protocol message; it can be
initiated by any node in the administrative p2p overlay which
supports P2PSIP base protocol specification.
An Echo request must specify which diagnostic information it is
interested in by setting different bits in the dFlags contained in
the request payload. If all diagnostic flags are clear, the response
is a simple Echo response containing no additional diagnostic
information.
Any intermediate peer along the Echo request path should forward the
Echo request to the next hop, and then returns an Echo response to
the initiator node, along with the diagnostic information indicated
by the dFlags in the Echo request.
As for the Echo responses, whether or not sending back certain kind
of diagnostic information to the initiator node depends on (1) the
dFlags (2)the authorization policy.
Any Echo request/response whose time in the Expiration field expired
should be ignored.
Song, et al. Expires June 16, 2009 [Page 15]
Internet-Draft P2PSIP DIAGNOSE December 2008
Peer-1 Peer-2 Peer-3 Peer-4
| | | |
| (1).Echo Request | | |
|------------------->| | |
| | (2).Echo Request | |
| |------------------->| |
| (3).Echo Response | | |
|<-------------------| | |
| | | (4).Echo Request |
| | |------------------->|
| | (5).Echo Response | |
|<-------------------|--------------------| |
| | | (6).Echo Response |
|<-------------------|--------------------|--------------------|
| | | |
P2PSIP Echo example
Echo request:
Struct {
Uint32 dFlags;
uint64 Expiration;
}EchoReq
dFlags (32 bits): An unsigned 16-bit integer indicating which kind of
diagnostic information the initiator interested in. The initiator
sets different bits to retrieve different kinds of diagnostic
information. If dFlags is clear, then no diagnostic information is
conveyed in the Echo response. See section 6.2 for the mapping
between the bits in the dFlags and the diagnostic information kinds.
Expiration: See section 5.2.2 for the meaning.
Echo response:
Struct {
Diagnostic_Info diag_info_list<0..2^5-1>;
uint64 Expiration;
}EchoAns
The peer may find misrouting behaviors or the underlay failures
during the Echo process, then an Error response should be generated
and send back to the initiator node. See section 6.4 for details.
Song, et al. Expires June 16, 2009 [Page 16]
Internet-Draft P2PSIP DIAGNOSE December 2008
6.4. Error responses
In p2psip overlay, the error response can be generated by the
intermediate peer or responsible peer, to a diagnostic message or
other messages. All error responses contain the Error code followed
by the subcode and descriptions if existed.
When a request arrives at a peer, if the peer's responsible ID space
does not cover the destination ID of the request, then the peer
continues to forward this request according to the overlay specified
routing mode.
When a request arrives at a peer, the peer may find some connectivity
failures or malfunction peers through the analysis of via list or
underlay error messages. The peer should report the error responses
to the initiator node. The malfunction node information should also
be reported to the initiator node in the error message payload.
The peer should return an Error response with the Error Code 8
"Underlay Destination Unreachable" when it receives an ICMP message
with "Destination Unreachable" information after forwarding the
received request.
The peer should return an Error response with the Error Code 9
"Underlay Time Exceeded" when it receives an ICMP message with "Time
Exceeded" information after forwarding the received request.
The peer should return an Error response with the Error Code 10
"Message Expired" when it finds that the message expires the time
field Expiration contained in the message payload.
The peer should return an Error response with Error Code 11 "Upstream
Misrouting" when it finds its upstream peer disobeys the routing
rules defined in the overlay. The immediate upstream peer information
should also be conveyed to the initiator node.
The peer should return an Error response with Error Code 12 "Loop
detected" when it finds a loop through the analysis of via list.
The peer should return an Error response with Error Code 13 "TTL hops
exceeded" when it finds that the TTL field value is no more than 0
when forwarding.
Song, et al. Expires June 16, 2009 [Page 17]
Internet-Draft P2PSIP DIAGNOSE December 2008
7. Diagnostic Server
For analyzing the overall health of the overlay network, a
diagnostic server can be used. The diagnostic server will collect
diagnostic information gathered, for example using the protocol
specified in this document, from the overlay nodes.
Administrator of the overlay can get a clear knowledge of the
overlay and take certain strategy when the overall performance of
the overlay changes(e.g. change the ratio of number between peers
and clients when most peers are in "busy" status).
Through the statistic information, the diagnostic server also knows
whether the overall storage or processing power is enough or not
for the overlay requirement.
It can also affirm the malfunction node through the statistics of
diagnostic information and degrade that peer to be a client or
eject it from the overlay.
A protocol between the diagnostic server and the overlay nodes is
needed.
8. Security Considerations
The Echo method may potentially cause DoS attack to the initiator,
though this implementation is more efficient than using iterative
mode of Path_Track operation.
An advice is to use the efficient Echo operation in administrated
P2PSIP overlay and use the pacing-style Path_Track operation in the
untrustworthy P2PSIP overlay network, certainly, the probability of
this type of DoS attack is very low because the overlay is
distributed and then it is very hard for the attacker to know the
accurate Peer-IDs and attack most of all peers simultaneously.
9. IANA Considerations
Message Code: this document introduces three new type of message to
the "RELOAD Message Code" Registry as below:
Song, et al. Expires June 16, 2009 [Page 18]
Internet-Draft P2PSIP DIAGNOSE December 2008
+-------------------+----------------+----------+
| Message Code Name | Code Value | RFC |
+-------------------+----------------+----------+
| inspect_req | 29 | RFC-AAAA |
| inspect_ans | 30 | RFC-AAAA |
| path_track_req | 31 | RFC-AAAA |
| path_track_ans | 32 | RFC-AAAA |
| echo_req | 33 | RFC-AAAA |
| echo_ans | 34 | RFC-AAAA |
+-------------------+----------------+----------+
Error Code: this document introduces some new Error Codes to the
"RELOAD Message Code" Registry as below:
Code Value Error Code Name
8 Underlay Destination Unreachable
9 Underlay Time exceeded
10 Message Expired
11 Upstream Misrouting
12 Loop detected
13 TTL hops exceeded
Data Kind-ID: This document introduces additional data kind-IDs to the
"RELOAD Data Kind-ID" Registry as below:
Kind Kind-ID
StatusInfo 16
ProcessPower 17
Bandwidth 18
10. Acknowledgments
We would like to thank Zheng Hewen for the contribution of the
initial version of this draft. We would also like to thank Bruce
Lowekamp, Salman Baset, Henning Schulzrinne, Roni Even and Jiang
Haifeng for the email discussion and their valued comments, and thank
Henry Sinnreich for contributing to the usage scenarios in the
Introduction.
Song, et al. Expires June 16, 2009 [Page 19]
Internet-Draft P2PSIP DIAGNOSE December 2008
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC792] Postel, J., "Internet Control Message Protocol", STD5, RFC
792, September 1981.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4981] J. Risson, "Survey of Research towards Robust Peer-to-Peer
Networks: Search Methods", RFC 4981, September 2007.
[I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for
Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in
progress), June 2007.
[I-D.ietf-p2psip-base] Jennings, C., "REsource LOcation And Discovery
(RELOAD) Base Protocol", draft-ietf-p2psip-base-01 (work in
progress), December 2008.
[I-D.jiang-p2psip-sep] X. Jiang, "Service Extensible P2P Peer
Protocol", draft-jiang-p2psip-sep-00 (work in progress),
November 2007.
[I-D.bryan-p2psip-requirement] D. Bryan, "P2PSIP Protocol Framework
and Requirements", draft-bryan-p2psip-requirements-00 (work
in progress), July 2007
Song, et al. Expires June 16, 2009 [Page 20]
Internet-Draft P2PSIP DIAGNOSE December 2008
[Overlay-Failure-Detection] S. Zhuang, "On failure detection
algorithms in overlay networks", Proc. IEEE Infocomm, Mar
13-17 2005.
[P2PSIP-Concepts-Terminology] Dean Willis, "P2PSIP Concepts and
Terminology",
http://www3.ietf.org/proceedings/07jul/slides/p2psip-
13.pdf, July 2007
[Handling Churn in a DHT] S. Rhea et al: "Handling Churn in a DHT".
USENIX Annual Conference, June 2004
[Diagnostic Framework] X. Jin et al: "A Diagnostic Framework for
Peer-to-Peer Streaming", Hong Kong University and Microsoft,
2005
[Diagnostics and NAT traversal in P2PP] G. Gupta et al: "Diagnostics
and NAT Traversal in P2PP - Design and Implementation."
Columbia University Report. June 2008
11.2. Informative References
[I-D.ietf-behave-rfc3489bis] Rosenberg, J., Huitema, C., Mahy, R.,
and D. Wing, "Simple Traversal Underneath Network Address
Translators (NAT) (STUN)", draft-ietf-behave- rfc3489bis-08
(work in progress), July 2007.
[I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and C. Huitema,
"Obtaining Relay Addresses from Simple Traversal Underneath
NAT (STUN)", draft-ietf-behave-turn-04 (work in progress),
July 2007.
[I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity
Establishment (ICE): A Methodology for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-17 (work in progress), July 2007
[I-D.bryan-p2psip-dsip] Bryan, D., "dSIP: A P2P Approach to SIP
Registration and Resource Location", draft-bryan-p2psip-
dsip-00 (work in progress), February 2007.
[I-D.baset-p2psip-p2pp] S. Baset, "Peer-to-Peer Protocol (P2PP)",
draft-baset-p2psip-p2pp-00 (work in progress), July 2007.
Song, et al. Expires June 16, 2009 [Page 21]
Internet-Draft P2PSIP DIAGNOSE December 2008
[I-D.Jennings-p2psip-asp] C. Jennings, "Address Settlement by Peer to
Peer", draft-jennings-p2psip-asp-00 (work in progress),
July 2007.
[I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP
Extensions for Implementing a Passive P2PSIP Overlay
Network based on the CAN Distributed Hash Table", draft-
marocco-p2psip-xpp-pcan-00 (work in progress), June 2007.
[I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport
Function in P2PSIP using HIP for Multi-Hop Overlay Routing",
draft-matthews-p2psip-hip-hop-00 (work in progress), June
2007.
[I-D.matuszewski-p2psip-security-requirement] M. Matuszewski,
"Security requirements in P2PSIP", draft-matuszewski-
p2psip-security-requirements-04 (work in progress),
November 2008
Author's Addresses
Haibin Song
Huawei
10F, Huihong Mansion, No. 91 Baixia Rd., Nanjing, China
Phone: +86-25-84565867
Email: melodysong@huawei.com
Xingfeng Jiang
Huawei
10F, Huihong Mansion, No. 91 Baixia Rd., Nanjing, China
Phone: +86-25-84565868
Email: jiang.x.f@huawei.com
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
Song, et al. Expires June 16, 2009 [Page 22]
Internet-Draft P2PSIP DIAGNOSE December 2008
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.
Song, et al. Expires June 16, 2009 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 21:19:15 |