Network Working Group Hewen. Zheng
Internet-Draft Xingfeng. Jiang
Intended status: Standards Track Huawei Technologies
Expires: June 13, 2008 December 11, 2007
Diagnose P2PSIP Overlay Network Failures
draft-zheng-p2psip-diagnose-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 June 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes a simple and efficient mechanism that can be
used to detect and localize failures in P2PSIP overlay network. This
document mainly consists of two parts: information carried in a
P2PSIP Peer "Echo request" message and "Echo response" message for
the purpose of fault detection and localization, and mechanisms for
processing those messages.
Zheng & Jiang Expires June 13, 2008 [Page 1]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Functions . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Packets Formats . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Message Attributes . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Response Attribute . . . . . . . . . . . . . . . . . . 6
5.2.2. Echo Attribute . . . . . . . . . . . . . . . . . . . . 7
5.2.3. Respond Peer Info Attribute . . . . . . . . . . . . . 10
6. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Echo request . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Echo response . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Echo response from the terminator peer . . . . . . . . 13
6.2.2. Echo response from the intermediate peer . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. P2PSIP Ping . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. P2PSIP Traceroute . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Zheng & Jiang Expires June 13, 2008 [Page 2]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
1. Introduction
Service is provisioned by more than one peers collectively in the
P2PSIP overlay network, this mode avoids "a single point of failure"
introduced by the traditional Client/Server mode. "Collectivity"
means that the failure occurred in one peer can not impact service
provided by the overlay network, i.e., most peers can continuously
and normally be served by the overlay network, but some peer or peers
are impacted. The quality of service provided by the overlay network
will degrade or even be interrupted due to the failure. Considering
the complexity of service provisioning in the overlay network, a
diagnostics system is more desirable for the overlay network than the
usual network adopting Client/Server mode.
This document describes a simple and efficient mechanism that can be
used to detect and localize failures in P2PSIP overlay network, i.e.,
this document describes a P2PSIP diagnostics protocol. This document
mainly consists of two parts: information carried in a P2PSIP Peer
"Echo request" message and "Echo response" message for the purpose of
fault detection and localization, and mechanisms for processing those
messages. An important consideration in this design is that P2PSIP
Peer Echo requests follow the same data path that normal P2PSIP peer
protocol packets would traverse.
2. Overview of Functions
As one diagnostics protocol, P2PSIP diagnostics protocol is mainly
used to detect and localize failures in P2PSIP overlay network. It
provides mechanisms to detect and localize malfunctioning or badly
behaving peers including disabled peers, congested peer and
misrouting peers. It provides a mechanism to detect connectivity to
the specified peer, a mechanism to detect availabilities of specified
resource record and a mechanism to discover P2PSIP overlay topology
and responding underlay topology.
P2PSIP diagnostics protocol reuses P2PSIP peer protocol [I-D.jiang-
p2psip-sep]; essentially it reuses P2PSIP peer protocol specification
and then introduces one new type of message (i.e., Echo message).
P2PSIP diagnostics protocol strictly follows the P2PSIP peer protocol
specification on the messages routing, transporting and NAT traverse
etc.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Zheng & Jiang Expires June 13, 2008 [Page 3]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
document are to be interpreted as described in [RFC2119].
The other concepts used in this document are compatible with P2PSIP
Work Group Draft "Concepts and Terminology for Peer to Peer SIP"
[I-D.ietf-p2psip-concepts].
4. 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 descriptions in the "Security requirements in P2PSIP"
[I-D.matuszewski-p2psip-security- requirement] and "Security
Mechanisms for Peer to Peer SIP"[I-D.jennins-p2psip-security-
mechanisms], there are some malfunctioning or badly behaving peers in
the P2PSIP overlay, those peers may be disabled peers, congested peer
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
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 basing 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,
it is evidently not enough for overlay network.
One general P2PSIP overlay diagnostics protocol supporting periodical
Zheng & Jiang Expires June 13, 2008 [Page 4]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
method and on-demand method for node failures and network failures is
desirable, especially for P2PSIP overlay network operator. This
document describe one general P2PSIP overlay diagnostics protocol
basing on P2PSIP peer protocol, at some degree, it is a good
complementation for some keep-alive algorithms in the P2PSIP peer
protocol implementation.
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 and a "traceroute" mode for diagnose P2PSIP
overlay network.
The basic idea is to transmit a P2PSIP peer protocol request message
(Echo request message) along the same path which all other P2PSIP
peer protocol request messages would traverse. In "Ping" mode, an
Echo request message are forwarded by the intermediate peers along
the path and then terminated by the last peer, and after local
diagnosis, the last peer returns an Echo response message. In
"Traceroute" mode, an Echo request message is received and disposed
by each peer along the path, and after completing diagnosis procedure
using predetermined method, each peer along the path returns an Echo
response message with local diagnostics information including the
result and causes if existing.
One way these tools can be used is to detect the connectivity to the
specified peer or the availability of the specified resource-record
through P2PSIP Ping operation once the overlay network receives some
alarms about overlay service degradation or interruption, if the ping
fails, one can then initiate a P2PSIP Traceroute to determine where
the fault lies.
5. Packets Formats
This document reuses P2PSIP peer protocol to carry diagnostics
information. Considering special usage due to diagnostics, this
document extends P2PSIP peer protocol by introducing one new type of
message and some attributes.
5.1. Message Header
The mechanism defined in this document follows P2PSIP peer protocol
specification, the introduced message whatever request form or
Zheng & Jiang Expires June 13, 2008 [Page 5]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
response form adopts the same message format with existing P2PSIP
peer protocol messages, those message uses the common header.
Different types of messages convey different contents according to
the protocol design, and then those different contents are described
by different TLV (Type-Length-Value) style objects combinations.
Those objects are called as "Attributes". Please refer to P2PSIP
peer protocol [I-D.jiang-p2psip-sep] for the detailed format of
Message Header.
This document introduces one new type of message as below:
Message Type Name
11 Echo
5.2. Message Attributes
As P2PSIP peer protocol, A P2PSIP diagnostics protocol message
contains zero, one or multiple Attributes which describe the
specified contents. All attributes follow P2PSIP peer protocol
specification and adopt TLV style. Please refer to P2PSIP peer
protocol [I-D.jiang- p2psip-sep] for the detailed format of Message
Attributes.
This document introduces two new types of attributes as below:
Attribute Type Name
15 Echo
16 Respond Peer Info
In addition to the newly introduced Echo attribute, this document
extends the Response attribute defined in P2PSIP peer protocol
specification.
5.2.1. Response Attribute
This document extends the Response attribute defined in the P2PSIP
peer protocol specification to describe the result of diagnostics as
Figure 1.
Zheng & Jiang Expires June 13, 2008 [Page 6]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved |Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response code | Response sub-code |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+
Figure 1 Response Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 7 (0x07);
Length (16 bits): the length in bytes of this attribute;
Response Code (16 bits): response code determined by the initiator,
this field is necessary for any response attribute;
Response Sub-Code (16 bits): response sub-code determined by the
initiator, this field is optional for one response attribute.
This document introduces new response codes as below:
Response Code Meaning
414 Underlay Destination Unreachable
415 Underlay Time exceeded
416 Upstream Misrouting
417 Loop detected
419 TTL hops exceeded
This document introduces response sub-codes for response code 414 as
below:
Response Sub-Code Meaning
0 net unreachable
1 host unreachable
2 protocol unreachable
3 port unreachable
4 fragmentation needed
5 source route failed
5.2.2. Echo Attribute
This document introduces Echo attribute to describe diagnosing
control information, including but not limited to: the forward mode
of the Echo request message, the reply mode of the Echo response
message, the reply rule to generate the Echo response message, the
Zheng & Jiang Expires June 13, 2008 [Page 7]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
timestamp of initiating the Echo request message, the timestamp of
receiving the Echo request message, the lifetime of the Echo request
message in the overlay and the expiration time of the Echo request
message.
The Echo attribute format is shown as Figure 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|U|P|Reserved |Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward mode | Reply mode | Reply rule | Underlay TTL |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+
| TimeStamp Initiated (seconds) |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+
| TimeStamp Initiated (microseconds) |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration time (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration time (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Echo Attribute Format
M-flag: the value is 1;
U-flag: indicate whether the receiver of Echo request message needs
to carry information of its immediate upstream peer in the following
Echo response message. If set (U=1), the Echo response message must
carry information of its immediate upstream peer such as Peer-ID;
P-flag: indicate whether the intermediate peer continues to forward
the Echo request message when it detects misrouting behavior of its
immediate upstream peer for this Echo request message. If set (P=1),
the intermediate peer continues to forward the Echo request message
upon detecting misrouting behavior of its immediate upstream peer;
otherwise the intermediate peer stops forwarding. Certainly the
intermediate peer should stop forwarding any received Echo request
message once detecting looping even when P-flag is set;
Reserved (5 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 15 (0x0F);
Zheng & Jiang Expires June 13, 2008 [Page 8]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
Length (16 bits): the length in bytes of this attribute;
Forward mode (8 bits): indicate the Echo request message overlay
routing mode specified by the initiator. It does not impact the
overlay routing behavior of any Echo response message;
Reply mode (8 bits): indicate the Echo response message returning
mode specified by the initiator. It does not impact the routing
behavior of any Echo request message;
Reply rule (8 bits): indicate the Echo request message process policy
specified by the initiator;
Underlay TTL (8 bits): indicate the underlay TTL which the Echo
request message forwarded by the intermediate peer adopts, it is
specified by the initiator;
Timestamp Initiated (64 bits): the time-of-day (in seconds and
microseconds, according to the sender's clock) in NTP format
[RFC2030] when the P2PSIP Overlay Echo request is sent。It can
be carried in the Echo response message from the receiver; certainly
it first appears in the Echo request message;
Timestamp Received (64 bits): it is in an Echo response message and
the time-of-day (according to the receiver's clock) in NTP format
[RFC2030] that the corresponding the P2PSIP Overlay Echo request was
received;
Expiration time (64 bits): the expiration time of Echo request
message, it is the time-of-day in NTP format [RFC2030]. If the time
receiving this Echo request message is equal or later than the
expiration time indicated by this field of the Echo request message,
this message should be discarded silently. In the Traceroute mode
described in the following sections, the immediate node updates this
field in the forwarding message with the new value which is the sum
of Timestamp Received and Life time.
This document defines those forward modes as below:
Zheng & Jiang Expires June 13, 2008 [Page 9]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
Forward mode Meaning
0 Choice by the receiver
1 Recursive
2 Iterative
3 Preferable recursive
4 Preferable iterative
This document defines those reply modes as below:
Reply mode Meaning
0 Determined by the receiver
1 Reply via IP directly
2 Reply via Overlay
This document defines those reply rules as below:
Reply rule Meaning
1 Do not reply except last peer
2 Immediately reply
5.2.3. Respond Peer Info Attribute
This document introduces Respond Peer attribute to describe Peer
information such as Peer-ID.
Respond Peer Info attribute is also a composite attribute. Like the
Source Peer Info attribute and Destination Peer Info attribute, it
may be also comprised of Peer-ID attribute, Peer Service Capability
attribute and several Peer Address Info attributes, the Peer-ID
attribute and at least one Peer Address Info attribute are necessary
among them.
The Respond Peer Info attribute format is shown as Figure 3.
Zheng & Jiang Expires June 13, 2008 [Page 10]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|U|D|Reserved |Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer service capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info - 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info - N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Respond Peer Info attribute format
M-flag: the value is 1;
U-flag: indicate whether this attribute describe the immediate
upstream peer of the initiator generating this attribute. If set
(U=1), the attribute is used to describe the immediate upstream peer
on the path;
D-flag: indicate whether this attribute describe the immediate
downstream peer of the initiator generating this attribute (e.g.
next-hop peer in the overlay forwarding path). If set (D=1), the
attribute is used to describe the immediate downstream peer on the
path. If U=0 and D=0, the attribute is used to describe the peer
itself (i.e. the attribute generator);
Reserved (5 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 16 (0x10);
Length (16 bits): the length in bytes of this attribute.
6. Message
All P2PSIP peer protocol messages use the common message header after
which zero, one or more TLV-style attributes follow. Each type of
message contains the request form and its response form.
This document introduces one new type of message to detect and
localize failures in P2PSIP overlay network. It is called "Echo"
message, including "Echo request" form and "Echo response" form.
Zheng & Jiang Expires June 13, 2008 [Page 11]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
6.1. Echo request
An Echo request message is used to detect possible failures in the
specified path of P2PSIP overlay network, including disabled peers,
congested peers, misrouting behavior and underlying network faults.
An Echo request message is also used to discover the topology of the
specified path and check the reachability to the specified peer or
the availability of the specified resource-record.
An Echo request message is normal P2PSIP peer protocol message; it
can be initiated by any formal peer supporting P2PSIP peer protocol
specification in the P2PSIP overlay network.
An Echo request message must contain a message header and an Echo
attribute.
Echo request =
Message Header
Echo Attribute
6.2. Echo response
An Echo response message is used to convey local diagnostics
information including result, causes and possible other assistant
information.
One implementation to estimate whether one peer is disabled is that
the initiator of an Echo request message uses local timer to
determine whether the expected Echo response message is expired,
i.e., the peer thinks that the specified peer is disabled if it does
not receive the Echo response message before the local timer expires
started when issuing an Echo request message to the specified peer in
the P2PSIP overlay network. This local timer can be updated in the
specified interval by the Echo response message from the intermediate
peers in the "Traceroute" mode; the interval is set by the initiator
of the Echo request message and indicated by the Life time field of
the Echo attribute.
Any intermediate peer which forwards an Echo request message must not
modify the message body except updating Expiration time field of the
Echo attribute.
An Echo response message must contain a message header, a Response
attribute, an Echo attribute and one or more Respond Peer Info
attributes. It may contain a Resource Info attribute and a Status
attribute. If the peer is one immediate peer, the Echo response
message must contain three Respond Peer Info attributes to describe
self, immediate upstream peer and next-hop peer individually. If the
Zheng & Jiang Expires June 13, 2008 [Page 12]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
peer is the last peer terminating the Echo request message, the Echo
message must contain two Respond Peer Info attributes to describe
self and immediate upstream peer. In the following section, the last
peer terminating the Echo request message is called as the
"terminator peer", in comparison with "intermediate peer" and
"initiator peer" or "initiator".
Echo response =
Message Header
Response Attribute
Echo Attribute
Respond Peer Info Attribute
[Resource Info Attribute]
[Status Attribute]
6.2.1. Echo response from the terminator peer
When an Echo request message arrived at a peer, if the peer's
responsible ID space covers the destination ID of the Echo request
message or the peer finds that the destination ID is unreachable in
the P2PSIP overlay (e.g., detecting loop), then the peer constructs
and returns an Echo response message using the specified Reply mode
indicated by the Echo request message when the Reply rule field of
the received Echo attribute is not Zero, or the peer does not give
any response when the Reply rule field is Zero.
The Echo response message must carry a Response attribute, a Respond
Peer Info attribute describing the receiver of the Echo request
message, an Echo attribute containing Time Received field and Time
Initiated field copied from the received Echo request message.
The returning Echo response message further must carry a Resource
attribute when the responsible resource-record exists in the peer.
If the Echo response message does not carry any Resource attribute,
it means that the resource-record whose Resource-ID is equal to the
destination ID of the Echo request message does not exist in the
peer.
If the peer finds that it is bush or congested, the returning Echo
response message must carry a Status attribute.
If the peer finds that its immediate upstream peer behaves with
misrouting, the returning Echo response message must carry a Response
attribute with the response code 416 "Upstream Misrouting" and a
Respond Peer Info attribute describing information of its immediate
upstream peer.
Zheng & Jiang Expires June 13, 2008 [Page 13]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
6.2.2. Echo response from the intermediate peer
When an Echo request message arrived at a peer, if the peer's
responsible ID space does not cover the destination ID of the Echo
request message, then the peer continues to forward this Echo Request
message according to the specified Forward mode field in the received
Echo request message.
The peer should return an Echo response message carrying a Response
attribute with the response code 414 "Underlay Destination
Unreachable" when it receives an ICMP message with "Destination
Unreachable" information after forwarding the received Echo request
message.
The peer should return an Echo response message carrying a Response
attribute with the response code 415 "Underlay Time Exceeded" when it
receives an ICMP message with "Time Exceeded" information after
forwarding the received Echo request message.
When an Echo request message arrived at a peer, if the peer's
responsible ID space does not cover the destination ID of the Echo
request message and the value of received Reply rule field is 2, then
the peer must construct and return an Echo response besides
continuing to forward the Echo request message.
The Echo response message must carry a Response attribute, a Respond
Peer Info attribute describing the receiver of the Echo request
message, a Respond Peer Info attribute describing the immediate
downstream peer (i.e. next hop to forward the Echo request message in
the P2PSIP overlay network), an Echo attribute containing Time
Received field and Time Initiated field copied from the received Echo
request message.
The returning Echo response message must carry a Resource attribute
when the responsible resource-record exists in the peer. If the Echo
response message does not carry any Resource attribute, it means that
the resource-record whose Resource-ID is equal with the destination
ID of the Echo request message does not exist in the peer.
If the peer finds that it is bush or congested, the returning Echo
response message must carry a Status attribute.
If the peer finds that its immediate upstream peer behaves with
misrouting, the returning Echo response message must carry a Response
attribute with the response code 416 "Upstream Misrouting" and
Respond Peer Info attribute describing information of its immediate
upstream peer.
Zheng & Jiang Expires June 13, 2008 [Page 14]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
7. Security Considerations
One feasible P2PSIP Traceroute implementation basing on the value of
"Reply Rule" field 2 "Immediately reply" (Section 9.2) may cause DoS
attack to the initiator, though this implementation is more efficient
than traditional Traceroute operation of Internet using pacing ICMP
message.
An advice is to use the efficient Traceroute operation in
administrated P2PSIP overlay and use the pacing-style Traceroute
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 the it is very hard for the attacker to
know the accurate Peer-IDs and attack most of all peers
simultaneously.
8. IANA Considerations
Message Type: this document introduces a new type of message as
below:
Message Type Name
11 Echo
Attribute Type: this document introduces two new types of attributes
as below:
Attribute Type Name
15 Echo
16 Respond Peer Info
Response Code: this document introduces some new response definitions
as below:
Result Code Name
414 Underlay Destination Unreachable
415 Underlay Time exceeded
416 Upstream Misrouting
417 Loop detected
419 TTL hops exceeded
Response Sub-Code: this document defines response sub-codes for the
response code 414 "Underlay Destination Unreachable" as below:
Zheng & Jiang Expires June 13, 2008 [Page 15]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
Response Sub-Code Meaning
0 net unreachable
1 host unreachable
2 protocol unreachable
3 port unreachable
4 fragmentation needed
5 source route failed
9. Examples
9.1. P2PSIP Ping
Any peer supporting P2PSIP diagnostics protocol can use P2PSIP Ping
operation to check the reachablity to the specified peer in the
overlay or the availability of the specified resource-record.
In the normal P2PSIP Ping operation, a peer constructs and issues an
Echo request message to the specified destination ID. The
destination ID of the Echo request message is the specified Peer-ID
or Resource-ID, the source ID of the Echo request message is the
Peer-ID of the initiator. The "Reply Rule" value must be 1 "Do not
reply except last peer", and the initiator determines the "Forward
mode", "Reply mode" and "Underlay TTL" of the Echo request message by
itself. Any intermediate peer does only simply forward this message
to its next hop in the overlay and not disposes this Echo request
message until the message arrives at the terminator peer who may be
the destination peer or one peer who finds that the destination ID is
unreachable, eventually the terminator peer returns an Echo response
message.
Here is an example of a P2PSIP Ping operation; it is shown as Figure
4:
Zheng & Jiang Expires June 13, 2008 [Page 16]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
Peer-1 Peer-2 Peer-3 Peer-4
| | | |
| (1).Echo Request | | |
|------------------->| | |
| | (2).Echo Request | |
| |------------------->| |
| | | (3).Echo Request |
| | |------------------->|
| | | |
| | | (4).Echo Response |
|<-------------------|--------------------|--------------------|
| | | |
Figure 4 P2PSIP Ping example
The overlay network operator may use P2PSIP Ping operation to measure
the message transmission delay and jitter between two specified
peers.
9.2. P2PSIP Traceroute
Any peer supporting P2PSIP diagnostics protocol can use P2PSIP
traceroute operation to detect and localize malfunctioning or badly
behaving peers including disabled peers, congested peers and
misrouting peers, or detect and localize network failure, or to
discover the topology of the specified path in the overlay network.
In one possible P2PSIP Traceroute operation, a peer constructs and
issues an Echo request message to the specified destination ID. The
destination ID in the Echo request message is the specified Peer-ID
or Resource-ID, the source ID in the Echo request message is the
Peer-ID of the initiator. The value of "Reply Rule" field must be 2
"Immediately reply", and the initiator determines the "Forward mode",
"Reply mode" and "Underlay TTL" of the Echo request message by
itself. Any intermediate peer does dispose this Echo request
message, i.e., forwards this message to its next hop in the overlay
and then returns an Echo response message. The terminator peer for
the Echo request message is the destination peer or one peer who
finds that the destination ID is unreachable; eventually the
terminator peer returns an Echo response message.
Here is an example of a P2PSIP Traceroute operation; it is shown as
Figure 5:
Zheng & Jiang Expires June 13, 2008 [Page 17]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
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 |
|<-------------------|--------------------|--------------------|
| | | |
Figure 5 P2PSIP Traceroute example
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 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.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[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.matuszewski-p2psip-security-requirement] M. Matuszewski,
"Security requirements in P2PSIP",
draft-matuszewski-p2psip-security-requirements-01 (work in progress),
July 2007
[I-D.jennins-p2psip-security-mechanisms] C. Jennings, "Security
Zheng & Jiang Expires June 13, 2008 [Page 18]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
Mechanisms for Peer to Peer SIP", draft-jennings-p2psip-security-00
(work in progress), February 2007
[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
[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
10.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.bryan-p2psip-reload] Bryan, D., "REsource LOcation And Discovery
(RELOAD)", draft-bryan-p2psip-reload-00 (work in progress), June
2007.
[I-D.baset-p2psip-p2pp] S. Baset, "Peer-to-Peer Protocol (P2PP)",
draft-baset-p2psip-p2pp-00 (work in progress), July 2007.
[I-D.Jennings-p2psip-asp] C. Jennings, "Address Settlement by Peer to
Peer", draft-jennings-p2psip-asp-00 (work in progress), July 2007.
Zheng & Jiang Expires June 13, 2008 [Page 19]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 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.
Authors' Addresses
Zheng Hewen
Huawei Technologies
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
PRC
Phone: +86-25-84565467
Fax: +86-25-84565848
Email: hwzheng@huawei.com
Jiang Xingfeng
Huawei Technologies
Baixia Road No.91
Nanjing, Jiangsu Province 210001
PRC
Phone: +86-25-84565468
Fax: +86-25-84565848
Email: jiang.x.f@huawei.com
Zheng & Jiang Expires June 13, 2008 [Page 20]
Internet-Draft Diagnose P2PSIP Overlay Network Failures December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Zheng & Jiang Expires June 13, 2008 [Page 21]