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]