idnits 2.17.1 draft-zheng-p2psip-diagnose-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 956. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 290 has weird spacing: '...Inspect req...' == Line 291 has weird spacing: '...Inspect res...' == Line 569 has weird spacing: '... Opaque dia...' == Line 661 has weird spacing: '...ic_Info diag_...' == Line 937 has weird spacing: '...imed to pert...' == (10 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 16, 2008) is 5609 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC4981' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'I-D.jiang-p2psip-sep' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-requirement' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'P2PSIP-Concepts-Terminology' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-rfc3489bis' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-turn' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-ice' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-dsip' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'I-D.baset-p2psip-p2pp' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'I-D.Jennings-p2psip-asp' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'I-D.marocco-p2psip-xpp-pcan' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'I-D.matthews-p2psip-hip-hop' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'I-D.matuszewski-p2psip-security-requirement' is defined on line 897, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4330 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 4981 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-00 ** Downref: Normative reference to an Informational draft: draft-ietf-p2psip-concepts (ref. 'I-D.ietf-p2psip-concepts') == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-01 == Outdated reference: A later version (-01) exists of draft-jiang-p2psip-sep-00 ** Downref: Normative reference to an Informational draft: draft-bryan-p2psip-requirements (ref. 'I-D.bryan-p2psip-requirement') -- Possible downref: Non-RFC (?) normative reference: ref. 'Overlay-Failure-Detection' -- Possible downref: Non-RFC (?) normative reference: ref. 'P2PSIP-Concepts-Terminology' -- No information found for draft-ietf-behave- - is the name correct? == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-17 == Outdated reference: A later version (-01) exists of draft-baset-p2psip-p2pp-00 == Outdated reference: A later version (-01) exists of draft-marocco-p2psip-xpp-pcan-00 == Outdated reference: A later version (-06) exists of draft-matuszewski-p2psip-security-requirements-04 Summary: 10 errors (**), 0 flaws (~~), 32 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP H. Song 3 Internet-Draft X. Jiang 4 Intended status: Standards Track Huawei 5 Expires: June 2009 6 December 16, 2008 8 Diagnose P2PSIP Overlay Network 9 draft-zheng-p2psip-diagnose-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 16, 2009. 36 Abstract 38 This document describes P2PSIP diagnostics. It describes the usage 39 scenarios and defines several simple methods for the diagnostics in 40 P2PSIP overlay network. It also describes types of diagnostic 41 information which are useful for the connection and node status 42 monitoring. An optional diagnostic server is also defined for the 43 overview of the overall health of the overlay. The methods and 44 message formats are specified as extensions to P2PSIP base protocol 45 RELOAD. 47 Table of Contents 49 1. Introduction................................................3 50 1.1. Usage Scenarios........................................3 51 2. Terminology.................................................4 52 3. Motivation..................................................4 53 4. Overview of Functions.......................................5 54 5. Packets Formats.............................................7 55 5.1. Message Codes..........................................7 56 5.2. Message payloads.......................................8 57 5.2.1. Error Codes and Sub-Codes.........................8 58 5.2.2. diagnostics information...........................9 59 6. Message....................................................10 60 6.1. Inspect...............................................10 61 6.2. Path_Track............................................12 62 6.3. Echo..................................................15 63 6.4. Error responses.......................................17 64 7. Diagnostic Server..........................................18 65 8. Security Considerations....................................18 66 9. IANA Considerations........................................18 67 10. Acknowledgments...........................................19 68 11. References................................................20 69 11.1. Normative References.................................20 70 11.2. Informative References...............................21 71 Author's Addresses............................................22 73 1. Introduction 75 P2P systems are self-organizing and ideally require no network 76 management in the traditional sense to set up and to configure 77 individual P2P nodes. P2P service providers may however contemplate 78 usage scenarios where some monitoring and diagnostics are required. 79 We present a simple connectivity test and some useful diagnostic 80 information that may be used in such diagnostics. 82 1.1. Usage Scenarios 84 The common usage scenarios for P2P diagnostics can be broadly 85 categorized in three classes: 87 a. Automatic diagnostics built into the P2P overlay routing protocol. 88 Nodes perform periodic checks of known neighbors and remove those 89 nodes from the routing tables that fail to respond to connectivity 90 checks [Handling Churn in a DHT]. The unresponsive nodes may however 91 be only temporarily disabled due to some local cryptographic 92 processing overload, disk processing overload or link overload. It is 93 therefore useful to repeat the connectivity checks to see if such 94 nodes have recovered and can be again placed in the routing tables. 95 This process is known as 'failed node recovery' and it can be 96 optimized as described in the reference [Handling Churn in a DHT]. 98 b. P2P system diagnostics to check the overall health of the P2P 99 overlay network, the consumption of network bandwidth, problem links 100 and also checks for abusive or malicious nodes. This is not a trivial 101 problem and has been studied in detail for content and streaming P2P 102 overlays, such as for example in [Diagnostic Framework]. 104 Similar work has been reported more recently for P2PSIP overlays as 105 applied to the P2PP protocol [Diagnostics and NAT traversal in P2PP]. 107 c. Diagnostics for a particular node to follow up an individual user 108 complaint. In this case a technical support person may use a desktop 109 sharing application with the permission of the user to determine 110 remotely the health and possible problems with the malfunctioning 111 node. Part of the remote diagnostics may consist of simple 112 connectivity tests with other nodes in the P2PSIP overlay. The simple 113 connectivity tests are not dependent on the type of P2PSIP overlay 114 and they are the topic of this memo. Note however that other tests 115 may be required as well, such as checking the health and performance 116 of the user's computer or mobile device and also checking the link 117 bandwidth connecting the user to the Internet. 119 2. Terminology 121 The concepts used in this document are compatible with "Concepts and 122 Terminology for Peer to Peer SIP" [I-D.ietf-p2psip-concepts] and the 123 P2PSIP base protocol RELOAD[I-D.ietf-p2psip-base]. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC-2119 [1]. 129 3. Motivation 131 In the last few years, overlay networks have rapidly evolved and 132 emerged as a promising platform to deploy new applications and 133 services in the Internet. One of the reasons overlay networks are 134 seen as an excellent platform for large scale distributed systems is 135 their resilience in the presence of failures. This resilience has 136 three aspects: data replication, routing recovery, and static 137 resilience. Routing recovery algorithms are used to repopulate the 138 routing table with live nodes when failures are detected. Static 139 resilience measures the extent to which an overlay can route around 140 failures even before the recovery algorithm repairs the routing table. 141 Both routing recovery and static resilience relies on accurate and 142 timely detection of failures. 144 As described in "Security requirements in P2PSIP" [I-D.matuszewski- 145 p2psip-security-requirement], there are some malfunctioning or badly 146 behaving peers in P2PSIP overlay, those peers may be disabled peers, 147 congested peers or peers behaving with misrouting, and the impact of 148 those peers in the overlay network is degradation of quality of 149 service provided collectively by the peers in the overlay network or 150 interruption of those services. It is desirable to identify 151 malfunctioning or badly behaving peers through some diagnostics tools, 152 and exclude or reject them from the P2PSIP system. Besides those 153 faults, node failures may be caused by underlying failures, for 154 example, when the IP layer routing failover speed after link failures 155 is very slow, then the recovery from the incorrect overlay topology 156 may also be slow. Moreover, if a backbone link fails and the failover 157 is slow, the network may be partitioned, which may lead to partitions 158 of overlay topologies and inconsistent routing results between 159 different partitioned components. 161 Some keep-alive algorithms based on periodically probe and 162 acknowledge enable accurate and timely detection of failures of one 163 peer's neighbors [Overlay-Failure-Detection], but those algorithms 164 only can detect the disabled neighbors using the periodical method, 165 it may not be enough for operating the overlay network by service 166 providers. 168 One general P2PSIP overlay diagnostics protocol supporting periodical 169 method and on-demand method for node failures and network failures is 170 desirable. This document describes one general P2PSIP overlay 171 diagnostics protocol useful for P2PSIP base protocol and it is a good 172 match for some keep-alive algorithms in the P2P or P2PSIP overlay 173 itself. 175 4. Overview of Functions 177 As a diagnostics protocol, P2PSIP diagnostics protocol is mainly used 178 to detect and localize failures or monitor performance in P2PSIP 179 overlay network. It provides mechanisms to detect and localize 180 malfunctioning or badly behaving peers including disabled peers, 181 congested peers and misrouting peers. It provides a mechanism to 182 detect direct connectivity or connectivity to the specified peer, a 183 mechanism to detect availabilities of specified resource records and 184 a mechanism to discover P2PSIP overlay topology and the underlay 185 topology failures. 187 The P2PSIP diagnostics protocol defines Inspect and Path_Track 188 methods for connection quality check and retrieval of diagnostic 189 information, as well as Echo method for efficient diagnostics in the 190 administrative overlay and the Error response to these methods. 191 Essentially it reuses P2PSIP base protocol specification and then 192 introduces the new diagnostics methods. P2PSIP diagnostics protocol 193 strictly follows the P2PSIP base protocol specification on the 194 messages routing, transporting and NAT traversal etc. The diagnostic 195 methods are however P2PSIP protocol independent. 197 In this document, we mainly describe how to detect and localize those 198 failures including disabled peers, congested peers, misrouting 199 behaviors and underlying network faults in P2PSIP overlay network 200 through a simple and efficient mechanism. This mechanism is modeled 201 after the ping/traceroute paradigm: ping (ICMP echo request [RFC792]) 202 is used for connectivity checks, and traceroute is used for hop-by- 203 hop fault localization as well as path tracing. This document 204 specifies a "ping" mode (by defining the Inspect method) and a 205 "traceroute" mode (implemented differently with trusted overlays such 206 as operator deployed P2PSIP overlays, compared with untrusted 207 overlays)for diagnosing P2PSIP overlay network. 209 An Inspect request message is forwarded by the intermediate peers 210 along the path and then terminated by the responsible peer, and after 211 optional local diagnostics, the responsible peer returns an Inspect 212 response message. If an error is found when routing, an Error 213 response is sent to the initiator node by the intermediate peer. 215 In "Traceroute" mode, we classify the diagnostics into two 216 application scenarios. 218 (1) In trusted p2p overlays, we use an Echo request message, it is 219 received and disposed by each peer along the routing path, and each 220 peer along the path returns an Echo response message with optional 221 local diagnostics information including the result and causes if 222 existing. 224 (2) In untrusted p2p overlays, we define a simple Path_Track method 225 for retrieving diagnostics information iteratively. First, the 226 initiating node asks its neighbor A which is the next hop node to the 227 destination ID, and then retrieve the next hop node B information, 228 along with optional diagnostic information of A, to the initiator 229 node. Then the initiator node asks the next hop node B(directly or 230 symmetric routing) to get the further next hop node C information and 231 diagnostic information of B. This step can be iterative until the 232 request reaches responsible node D for the destination ID, and 233 retrieve diagnostic information of node D, or terminates by some 234 failures that prevent the process. 236 One approach these tools can be used is to detect the connectivity to 237 the specified peer or the availability of the specified resource- 238 record through P2PSIP Inspect operation once the overlay network 239 receives some alarms about overlay service degradation or 240 interruption, if the Inspect fails, one can then send a P2PSIP 241 Traceroute(iterative Path_Track or Echo) to determine where the fault 242 lies. 244 The diagnostic information MUST be only provided to authorized peers. 245 Some diagnostic information can be authorized to all the participants 246 in the P2PSIP overlay, and some other diagnostic information can only 247 be provided to the authorization peer list of each diagnostic 248 information according to the local or overlay policy. The 249 authorization mainly depends on the kinds of the diagnostic 250 information and the administrative considerations. 252 5. Packets Formats 254 This document extends the P2PSIP base protocol to carry diagnostics 255 information. Considering special usage of diagnostics, this document 256 defines three simple methods Inspect, Path_Track and Echo, as well as 257 related Error codes and some useful diagnostics information. 259 As described in the P2PSIP base protocol, each message has three 260 parts. This specification is consistent with the format. 262 +-------------------------+ 263 | Forwarding Header | 264 +-------------------------+ 265 | Message Contents | 266 +-------------------------+ 267 | Signature | 268 +-------------------------+ 270 5.1. Message Codes 272 The mechanism defined in this document follows P2PSIP base protocol 273 specification, the new request and response message use the message 274 format specified in P2PSIP base protocol messages. Different types of 275 messages convey different message contents following the forwarding 276 header according to the protocol design. Please refer to P2PSIP base 277 protocol [I-D.ietf-p2psip-base] for the detailed format of forwarding 278 header. 280 This document reuses the Error response in the base protocol and 281 defines new Error codes to carry different failure reports to the 282 initiator node when failure is detected during diagnostics. 284 Name Message Code 285 Error 0xFFFF 287 This document introduces three types of message: 289 Name Message Code 290 Inspect request 29 291 Inspect response 30 292 Path_Track request 31 293 Path_Track response 32 294 Echo request 33 295 Echo response 34 297 The final message code will be assigned by IANA as specified in 298 section 14.4 of [I-D.ietf-p2psip-base]. 300 5.2. Message payloads 302 As an extension to P2PSIP base protocol, a P2PSIP diagnostics 303 protocol message content contains one message code following by its 304 payloads. Please refer to P2PSIP base protocol [I-D.ietf-p2psip-base] 305 for the detailed format of Message Contents. 307 In addition to the newly introduced methods, this document extends 308 the Error codes defined in P2PSIP base protocol specification. 310 5.2.1. Error Codes and Sub-Codes 312 This document extends the Error response method defined in the P2PSIP 313 base protocol specification to describe the result of diagnostics. 315 This document introduces new Error Codes as below: 317 Code Value Error Code Name 318 8 Underlay Destination Unreachable 319 9 Underlay Time exceeded 320 10 Message Expired 321 11 Upstream Misrouting 322 12 Loop detected 323 13 TTL hops exceeded 325 The final error codes will be assigned by IANA as specified in 326 section 14.5 of the p2psip base protocol [I-D.ietf-p2psip-base]. 328 This document introduces several types of error information in the 329 error_info field for Error Code 8 as an example: 331 error_info: 333 net unreachable 334 host unreachable 335 protocol unreachable 336 port unreachable 337 fragmentation needed 338 source route failed 340 Editor note: We may need more discussion here to see if we need to 341 define an additional sub-code field for the error information. Sub- 342 code is easier for the machine to process while various text is 343 comfortable for a man to read. 345 5.2.2. diagnostics information 347 This document introduces some new diagnostics information conveyed in 348 the message payload, including: the number of hops that the message 349 traverses, the underlay TTL specified, the timestamp of initiating 350 the request message, the timestamp of receiving the request message, 351 and the expiration time of the request message, the processing power, 352 the bandwidth, the number of entries in one's neighbor table, etc. 353 They are defined as below. Additional diagnostic information have 354 been proposed in section 9 of the p2psip base protocol draft [I- 355 D.ietf-p2psip-base]. 357 HopCounter (8 bits): This byte only appears in diagnostic responses. 358 It must be exactly copied from the TTL field of the forwarding header 359 in the received request. Then this information is sent back to the 360 request initiator to compute the hops that the message traverses in 361 the overlay. 363 UnderlayTTL (8 bits): It indicates the underlay TTL which the 364 intermediate peer must adopt when forwarding the diagnostic requests, 365 it is specified by the initiator. If the value is 0, then the 366 intermediate peer must ignore this field, and use the underlay TTL 367 with its local configuration. 369 TimestampInitiated (64 bits): The time-of-day (in seconds and 370 microseconds, according to the sender's clock) in NTP timestamp 371 format [RFC4330] when the P2PSIP Overlay diagnostic request is sent. 372 It can be carried in the diagnostic response message from the 373 receiver; certainly it first appears in the diagnostic request 374 message; 375 TimestampReceived (64 bits): it is in a diagnostic response message 376 as the time-of-day (according to the receiver's clock) in NTP 377 timestamp format [RFC4330] that corresponds to the time that the 378 P2PSIP Overlay diagnostic request was received; 380 Expiration(64 bits): the expiration time of the request message, it 381 is the time-of-day in NTP timestamp format [RFC4330]. It can be used 382 to mitigate the replay attack to the destination peer and overlay 383 network. 385 ProcessPower (32 bits): A single value element containing an unsigned 386 32-bit integer specifying the processing power of the node in unit of 387 MIPS. 389 Bandwidth (32 bits): A single value element containing an unsigned 390 32-bit integer specifying the bandwidth of the node in unit of Kbps. 392 Routing_Table_Size (32 bits): A single value element containing an 393 unsigned 32-bit integer representing the number of peers in the 394 peer's routing table. The administrator of the overlay may be 395 interested in statistics of this value for the consideration such as 396 routing efficiency. 398 StatusInfo (8 bits): A single value element containing an unsigned 399 byte representing whether or not the node is in congestion status. 401 6. Message 403 All P2PSIP base protocol requests and responses use the common 404 forwarding header followed by the message contents. 406 This document defines Inspect and Path_Track methods, and introduces 407 the new Echo message to detect and localize failures in P2PSIP 408 overlay network. The Error Codes to these requests are defined in 409 section 5.2.1 of this spec. 411 6.1. Inspect 413 In P2PSIP base protocol, Ping is used to test connectivity along a 414 path. However, connectivity quality can not be measured well without 415 some useful information, such as the timestamp and HopCounter. Here 416 we define a new method Inspect for connectivity quality check 417 purposes. See below for the Inspect formats. 419 Inspect Request: 420 struct { 421 uint8 UnderlayTTL; 422 uint64 TimestampInitiated; 423 uint64 Expiration; 424 } InspectReq; 426 Inspect Response: 427 struct { 428 uint8 HopCounter; 429 uint64 TimestampReceived; 430 uint64 Expiration; 431 }InspectAns; 433 Any intermediate node which receives the Inspect request must adopt 434 the UnderlayTTL for the next hop forwarding. If the value equals to 0, 435 the intermediate peer must ignore this value and determine the 436 underlay TTL using local configuration. The requirement here is that 437 one may want to limit each hop underlay TTL from the initiator to the 438 destination, if the underlay TTL expires somewhere, one may think 439 that the link there is not of good quality. 441 Each intermediate peer receiving the Inspect request/response should 442 check the Expiration value (NTP format) to determine if the message 443 expired. If the message expired, the intermediate peer should 444 generate a "Message Expired" Error to the initiator node, and discard 445 the message. The responsible node for the request or response MUST 446 check this value to determine if this message should be ignored. 448 The responsible peer of the Inspect request must exactly copy the TTL 449 field value in the forwarding header to the HopCounter value in the 450 response, and meanwhile, it should generate a NTP format timestamp to 451 indicate the received time. 453 The initiator node, as well as the responding peer, can compute the 454 overlay One-Way-Delay time through the value in TimestampReceived and 455 the TimestampInitiated field. 457 Editor note: We need more discussion here because time 458 synchronization is a barrier in open Internet environment, while in 459 the operator's network, it is not so tricky. 461 The initiator node receiving the Inspect response must check the 462 HopCounter field and compute the overlay hops to the destination peer 463 for the statistics of connectivity quality from the perspective of 464 overlay hops. 466 Inspect is also used to detect possible failures in the specified 467 path of P2PSIP overlay network. If disabled peers, misrouting 468 behavior and underlying network faults are detected during the 469 routing process, the Error responses with Error codes and 470 descriptions, must be sent to the initiator node immediately. See 471 section 6.4 for the details. 473 6.2. Path_Track 475 We define a simple Path_Track method to retrieve the diagnostic 476 information from the intermediate peers along the routing path. At 477 each step of the Path_Track request, the responsible peer responds to 478 the initiator node with the status information of itself whether or 479 not congested , its processing power, its available bandwidth, the 480 number of entries in its neighbor table, its uptime, his identity and 481 network address information, and the next hop peer information. 483 Peer-1 Peer-2 Peer-3 Peer-4 484 | | | | 485 |(1).Path_Track Req | | | 486 |------------------->| | | 487 |(2).Path_Track ans | | | 488 |<-------------------| | | 489 | |(3).Path_Track Req | | 490 |--------------------|------------------->| | 491 | |(4).Path_Track Ans | | 492 |<-------------------|--------------------| | 493 | | |(5).Path_Track Req | 494 |--------------------|--------------------|------------------->| 495 | | |(6).Path_Track Ans | 496 |<-------------------|--------------------|--------------------| 497 | | | | 499 Path_Track example 501 A Path_Track request must specify which diagnostic information is 502 requested by setting different bits in the flag contained in the 503 Path_Track request payload. If the flag is clear, then the Path_Track 504 request is only used for asking the next hop information, in this 505 case the iterative mode of Path_Track is used only for checking the 506 liveness of the peers along the routing path. The Path_Track request 507 can be routed directly or through the overlay based on the local 508 policy of the initiator node. 510 Path_Track request: 511 struct { 512 Destination destination; 513 Uint32 dFlags; 514 uint64 Expiration; 515 } RathTrackReq; 517 destination : The destination which the requester is interested in. 518 This may be any valid destination object, including a Node-ID, 519 compressed ids, or Resource-ID. 521 dFlags : An unsigned 32-bit integer indicating which kind of 522 diagnostic information the initiator interested in. The initiator 523 sets different bits to retrieve different kinds of diagnostic 524 information. If dFlags is clear, then no diagnostic information is 525 conveyed in the Path_Track response. If dFlag is set to 0xFFFFFFFF, 526 then all diagnostic information kinds are requested. The kinds of 527 diagnostic information including: status information, its processing 528 power, its available bandwidth, the number of entries in its neighbor 529 table, its uptime, etc. The mapping between the bits in the dFlags 530 and the diagnostic information kind is as below: 532 StatusInfo Flag(0x0001) : if set, the status information of 533 the responding peer is requested; 535 Routing_Table_Size Flag(0x0002) : if set, the number of 536 entries in the responding peer's neighbor is requested; 538 ProcessPower Flag(0x0004) : if set, the processing power 539 information of the responding peer is requested; 541 Bandwidth Flag(0x0008) : if set, the bandwidth information of 542 the responding peer is requested; 544 [TODO: The bits in the dFlags should also map to the diagnostic 545 information defined in section 9 of p2psip base draft.] 547 A response to a successful PathTrackReq is a PathTrackAns message. 548 There is a general diagnostic information part based on the flags. 550 Path_Track response: 551 struct { 552 Destination next_hop; 553 Diagnostic_Info diag_info_list<0..2^5-1>; 554 uint64 Expiration; 555 } RathTrackAns; 557 next_hop : The information of the next hop node from the responding 558 intermediate peer to the destination node. If the responding peer is the 559 responsible peer for the destination ID, then the next_hop node ID 560 equals the responding node ID, and after that the initiator must stop 561 the iterative process. 563 diag_info_list: The diagnostic information from the responding peer. 565 The TLV structure for Diagnostic_Info is as the following: 566 struct { 567 uint8 Kind-ID; 568 uint8 length; 569 Opaque diagnosic_information<0..2^8-1>; 570 } Diagnostic_Info; 572 Various kinds of diagnostic information can be retrieved, some of them 573 are defined in this document, and some of them are defined in the p2psip 574 base draft. This document introduces additional three new data kind-IDs 575 as below: 577 Kind Kind-ID 579 StatusInfo 16 580 ProcessPower 17 581 Bandwidth 18 583 The final kind-IDs will be assigned by IANA as specified in section 584 14.2 of the p2psip base protocol [I-D.ietf-p2psip-base]. 586 As for the Path_Track responses, whether or not sending back certain 587 kind of diagnostic information to the initiator node depends on (1) 588 the dFlags (2)the authorization policy. 590 Failures may be detected during the process, after that an Error 591 response should be reported to the initiator node immediately. 593 6.3. Echo 595 An Echo request message is used to retrieve the diagnostic 596 information of the specified path in administrative p2p overlays 597 where all the peers in the overlay are trusted or based on specific 598 authorization. For example, it can be used in a p2p overlay where all 599 peers deployed by the operator to provide services to the 600 customers(clients), where the diagnostics happens between peers in 601 the p2p overlay. For the untrusted p2p overlays, the Echo method must 602 be used with care for the consideration of potential DoS attack. 604 An Echo request is normal P2PSIP base protocol message; it can be 605 initiated by any node in the administrative p2p overlay which 606 supports P2PSIP base protocol specification. 608 An Echo request must specify which diagnostic information it is 609 interested in by setting different bits in the dFlags contained in 610 the request payload. If all diagnostic flags are clear, the response 611 is a simple Echo response containing no additional diagnostic 612 information. 614 Any intermediate peer along the Echo request path should forward the 615 Echo request to the next hop, and then returns an Echo response to 616 the initiator node, along with the diagnostic information indicated 617 by the dFlags in the Echo request. 619 As for the Echo responses, whether or not sending back certain kind 620 of diagnostic information to the initiator node depends on (1) the 621 dFlags (2)the authorization policy. 623 Any Echo request/response whose time in the Expiration field expired 624 should be ignored. 626 Peer-1 Peer-2 Peer-3 Peer-4 627 | | | | 628 | (1).Echo Request | | | 629 |------------------->| | | 630 | | (2).Echo Request | | 631 | |------------------->| | 632 | (3).Echo Response | | | 633 |<-------------------| | | 634 | | | (4).Echo Request | 635 | | |------------------->| 636 | | (5).Echo Response | | 637 |<-------------------|--------------------| | 638 | | | (6).Echo Response | 639 |<-------------------|--------------------|--------------------| 640 | | | | 642 P2PSIP Echo example 644 Echo request: 645 Struct { 646 Uint32 dFlags; 647 uint64 Expiration; 648 }EchoReq 650 dFlags (32 bits): An unsigned 16-bit integer indicating which kind of 651 diagnostic information the initiator interested in. The initiator 652 sets different bits to retrieve different kinds of diagnostic 653 information. If dFlags is clear, then no diagnostic information is 654 conveyed in the Echo response. See section 6.2 for the mapping 655 between the bits in the dFlags and the diagnostic information kinds. 657 Expiration: See section 5.2.2 for the meaning. 659 Echo response: 660 Struct { 661 Diagnostic_Info diag_info_list<0..2^5-1>; 662 uint64 Expiration; 663 }EchoAns 665 The peer may find misrouting behaviors or the underlay failures 666 during the Echo process, then an Error response should be generated 667 and send back to the initiator node. See section 6.4 for details. 669 6.4. Error responses 671 In p2psip overlay, the error response can be generated by the 672 intermediate peer or responsible peer, to a diagnostic message or 673 other messages. All error responses contain the Error code followed 674 by the subcode and descriptions if existed. 676 When a request arrives at a peer, if the peer's responsible ID space 677 does not cover the destination ID of the request, then the peer 678 continues to forward this request according to the overlay specified 679 routing mode. 681 When a request arrives at a peer, the peer may find some connectivity 682 failures or malfunction peers through the analysis of via list or 683 underlay error messages. The peer should report the error responses 684 to the initiator node. The malfunction node information should also 685 be reported to the initiator node in the error message payload. 687 The peer should return an Error response with the Error Code 8 688 "Underlay Destination Unreachable" when it receives an ICMP message 689 with "Destination Unreachable" information after forwarding the 690 received request. 692 The peer should return an Error response with the Error Code 9 693 "Underlay Time Exceeded" when it receives an ICMP message with "Time 694 Exceeded" information after forwarding the received request. 696 The peer should return an Error response with the Error Code 10 697 "Message Expired" when it finds that the message expires the time 698 field Expiration contained in the message payload. 700 The peer should return an Error response with Error Code 11 "Upstream 701 Misrouting" when it finds its upstream peer disobeys the routing 702 rules defined in the overlay. The immediate upstream peer information 703 should also be conveyed to the initiator node. 705 The peer should return an Error response with Error Code 12 "Loop 706 detected" when it finds a loop through the analysis of via list. 708 The peer should return an Error response with Error Code 13 "TTL hops 709 exceeded" when it finds that the TTL field value is no more than 0 710 when forwarding. 712 7. Diagnostic Server 714 For analyzing the overall health of the overlay network, a 715 diagnostic server can be used. The diagnostic server will collect 716 diagnostic information gathered, for example using the protocol 717 specified in this document, from the overlay nodes. 719 Administrator of the overlay can get a clear knowledge of the 720 overlay and take certain strategy when the overall performance of 721 the overlay changes(e.g. change the ratio of number between peers 722 and clients when most peers are in "busy" status). 724 Through the statistic information, the diagnostic server also knows 725 whether the overall storage or processing power is enough or not 726 for the overlay requirement. 728 It can also affirm the malfunction node through the statistics of 729 diagnostic information and degrade that peer to be a client or 730 eject it from the overlay. 732 A protocol between the diagnostic server and the overlay nodes is 733 needed. 735 8. Security Considerations 737 The Echo method may potentially cause DoS attack to the initiator, 738 though this implementation is more efficient than using iterative 739 mode of Path_Track operation. 741 An advice is to use the efficient Echo operation in administrated 742 P2PSIP overlay and use the pacing-style Path_Track operation in the 743 untrustworthy P2PSIP overlay network, certainly, the probability of 744 this type of DoS attack is very low because the overlay is 745 distributed and then it is very hard for the attacker to know the 746 accurate Peer-IDs and attack most of all peers simultaneously. 748 9. IANA Considerations 750 Message Code: this document introduces three new type of message to 751 the "RELOAD Message Code" Registry as below: 753 +-------------------+----------------+----------+ 754 | Message Code Name | Code Value | RFC | 755 +-------------------+----------------+----------+ 756 | inspect_req | 29 | RFC-AAAA | 757 | inspect_ans | 30 | RFC-AAAA | 758 | path_track_req | 31 | RFC-AAAA | 759 | path_track_ans | 32 | RFC-AAAA | 760 | echo_req | 33 | RFC-AAAA | 761 | echo_ans | 34 | RFC-AAAA | 762 +-------------------+----------------+----------+ 764 Error Code: this document introduces some new Error Codes to the 765 "RELOAD Message Code" Registry as below: 767 Code Value Error Code Name 768 8 Underlay Destination Unreachable 769 9 Underlay Time exceeded 770 10 Message Expired 771 11 Upstream Misrouting 772 12 Loop detected 773 13 TTL hops exceeded 775 Data Kind-ID: This document introduces additional data kind-IDs to the 776 "RELOAD Data Kind-ID" Registry as below: 778 Kind Kind-ID 779 StatusInfo 16 780 ProcessPower 17 781 Bandwidth 18 783 10. Acknowledgments 785 We would like to thank Zheng Hewen for the contribution of the 786 initial version of this draft. We would also like to thank Bruce 787 Lowekamp, Salman Baset, Henning Schulzrinne, Roni Even and Jiang 788 Haifeng for the email discussion and their valued comments, and thank 789 Henry Sinnreich for contributing to the usage scenarios in the 790 Introduction. 792 11. References 794 11.1. Normative References 796 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 797 Levels", BCP 14, RFC 2119, March 1997. 799 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 800 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 801 Demon Internet Ltd., November 1997. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, March 1997. 806 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 807 Syntax Specifications: ABNF", RFC 2234, Internet Mail 808 Consortium and Demon Internet Ltd., November 1997. 810 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 811 Peterson, J., Sparks, R., Handley, M., and E. Schooler, 812 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 814 [RFC792] Postel, J., "Internet Control Message Protocol", STD5, RFC 815 792, September 1981. 817 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 818 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 820 [RFC4981] J. Risson, "Survey of Research towards Robust Peer-to-Peer 821 Networks: Search Methods", RFC 4981, September 2007. 823 [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for 824 Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in 825 progress), June 2007. 827 [I-D.ietf-p2psip-base] Jennings, C., "REsource LOcation And Discovery 828 (RELOAD) Base Protocol", draft-ietf-p2psip-base-01 (work in 829 progress), December 2008. 831 [I-D.jiang-p2psip-sep] X. Jiang, "Service Extensible P2P Peer 832 Protocol", draft-jiang-p2psip-sep-00 (work in progress), 833 November 2007. 835 [I-D.bryan-p2psip-requirement] D. Bryan, "P2PSIP Protocol Framework 836 and Requirements", draft-bryan-p2psip-requirements-00 (work 837 in progress), July 2007 839 [Overlay-Failure-Detection] S. Zhuang, "On failure detection 840 algorithms in overlay networks", Proc. IEEE Infocomm, Mar 841 13-17 2005. 843 [P2PSIP-Concepts-Terminology] Dean Willis, "P2PSIP Concepts and 844 Terminology", 845 http://www3.ietf.org/proceedings/07jul/slides/p2psip- 846 13.pdf, July 2007 848 [Handling Churn in a DHT] S. Rhea et al: "Handling Churn in a DHT". 849 USENIX Annual Conference, June 2004 851 [Diagnostic Framework] X. Jin et al: "A Diagnostic Framework for 852 Peer-to-Peer Streaming", Hong Kong University and Microsoft, 853 2005 855 [Diagnostics and NAT traversal in P2PP] G. Gupta et al: "Diagnostics 856 and NAT Traversal in P2PP - Design and Implementation." 857 Columbia University Report. June 2008 859 11.2. Informative References 861 [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Huitema, C., Mahy, R., 862 and D. Wing, "Simple Traversal Underneath Network Address 863 Translators (NAT) (STUN)", draft-ietf-behave- rfc3489bis-08 864 (work in progress), July 2007. 866 [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and C. Huitema, 867 "Obtaining Relay Addresses from Simple Traversal Underneath 868 NAT (STUN)", draft-ietf-behave-turn-04 (work in progress), 869 July 2007. 871 [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity 872 Establishment (ICE): A Methodology for Network Address 873 Translator (NAT) Traversal for Offer/Answer Protocols", 874 draft-ietf-mmusic-ice-17 (work in progress), July 2007 876 [I-D.bryan-p2psip-dsip] Bryan, D., "dSIP: A P2P Approach to SIP 877 Registration and Resource Location", draft-bryan-p2psip- 878 dsip-00 (work in progress), February 2007. 880 [I-D.baset-p2psip-p2pp] S. Baset, "Peer-to-Peer Protocol (P2PP)", 881 draft-baset-p2psip-p2pp-00 (work in progress), July 2007. 883 [I-D.Jennings-p2psip-asp] C. Jennings, "Address Settlement by Peer to 884 Peer", draft-jennings-p2psip-asp-00 (work in progress), 885 July 2007. 887 [I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP 888 Extensions for Implementing a Passive P2PSIP Overlay 889 Network based on the CAN Distributed Hash Table", draft- 890 marocco-p2psip-xpp-pcan-00 (work in progress), June 2007. 892 [I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport 893 Function in P2PSIP using HIP for Multi-Hop Overlay Routing", 894 draft-matthews-p2psip-hip-hop-00 (work in progress), June 895 2007. 897 [I-D.matuszewski-p2psip-security-requirement] M. Matuszewski, 898 "Security requirements in P2PSIP", draft-matuszewski- 899 p2psip-security-requirements-04 (work in progress), 900 November 2008 902 Author's Addresses 904 Haibin Song 905 Huawei 906 10F, Huihong Mansion, No. 91 Baixia Rd., Nanjing, China 907 Phone: +86-25-84565867 908 Email: melodysong@huawei.com 910 Xingfeng Jiang 911 Huawei 912 10F, Huihong Mansion, No. 91 Baixia Rd., Nanjing, China 913 Phone: +86-25-84565868 914 Email: jiang.x.f@huawei.com 916 Full Copyright Statement 918 Copyright (C) The IETF Trust (2008). 920 This document is subject to the rights, licenses and restrictions 921 contained in BCP 78, and except as set forth therein, the authors 922 retain all their rights. 924 This document and the information contained herein are provided 925 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 926 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 927 SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 928 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 929 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 930 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 931 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 933 Intellectual Property 935 The IETF takes no position regarding the validity or scope of any 936 Intellectual Property Rights or other rights that might be 937 claimed to pertain to the implementation or use of the 938 technology described in this document or the extent to which 939 any license under such rights might or might not be available; 940 nor does it represent that it has made any independent effort 941 to identify any such rights. Information on the procedures 942 with respect to rights in RFC documents can be found in BCP 78 943 and BCP 79. 945 Copies of IPR disclosures made to the IETF Secretariat and any 946 assurances of licenses to be made available, or the result of an 947 attempt made to obtain a general license or permission for the 948 use of such proprietary rights by implementers or users of this 949 specification can be obtained from the IETF on-line IPR 950 repository at http://www.ietf.org/ipr. 952 The IETF invites any interested party to bring to its attention 953 any copyrights, patents or patent applications, or other 954 proprietary rights that may cover technology that may be 955 required to implement this standard. Please address the 956 information to the IETF at ietf-ipr@ietf.org.