Network Diagnostics

TECHNICAL FIELD

The invention relates to the field of network diagnostics, and in particular to network diagnostics in peer-to-peer networks.

BACKGROUND

Today P2P (Peer-to-peer) networks are utilized in various ways. Perhaps the two most important usage scenarios are file sharing and interpersonal communication. Typically the file sharing is implemented with specific, non-standardized applications such as eMule and BitTorrent. Interpersonal communication can be performed using non- standardized applications such as Skype, but in the future it will be possible to use standardized technology, namely P2PSIP (Peer-to-Peer Session Initiation Protocol), for communication in overlay networks.

P2PSIP combines SIP (Session Initiation Protocol) and P2P technologies. For a description of SIP, see J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol," RFC 3261 (Proposed Standard), Internet Engineering Task Force, June 2002, http://www.rfc-editor.org/rfc/rfc3261.txt (Referenced May 31 2007). This combination reduces, or removes completely, the need for centralized servers, such as the ones used in the IP Multimedia Subsystem (IMS), by pushing most, or all, functionality to the end devices.

Although it will be possible to build isolated P2PSIP networks, it is expected that a number of them will be connected in some way to existing SIP-based networks such as the IMS. This way, IMS users and P2PSIP users will be able to communicate between IMS and P2PSIP networks seamlessly.

The main enabler for P2PSIP is the emergence of DHT (Distributed Hast Table) algorithms, such as Chord (see R. Stoica, D. Morris, M. Karger, F. Kaashoek, and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications," in Proceedings of the ACM SIGCOMM '01 Conference, San Diego, California, Aug. 2001 , pp. 149,

http://pdos.csail.mit.edu/papers/chord:sigcomm01/chord_si gcomm.pdf). An early discussion of P2PSIP can be found in K. Singh and H. Schulzrinne, "Peer-to-peer Internet Telephony Using SIP," in NOSSDAV '05: Proceedings of the international workshop on Network and operating systems support for digital audio and video. New York, NY, USA: ACM Press, 2005, pp. 63-68, http://www1.cs.columbia.edu/~kns10/publication/sip-p2p-short .pdf. Since then, a number of papers have been published, for example D. A. Bryan, B. Lowekamp, and C. Jennings, "SOSIMPLE: A Serverless, Standards-based, P2P SIP Communication System," in Proceedings of the 2005 International Workshop on Advanced Architectures and Algorithms for Internet Delivery and Applications (AAA-IDEA 2005), June 2005, http://www.cs.wm.edu/~bryan/pubs/bryan-AAA-IDEA2005.pdf.

P2PSIP technology will be standardized in the IETF (Internet Engineering Task Force). A P2PSIP working group was chartered in March 2007. Despite the fact that the P2PSIP working has not existed very long, there are already several drafts targeting aspects of P2PSIP, for example D. Bryan, P. Matthews, E. Shim, and D. Willis, Concepts and Terminology for Peer to Peer SIP, draft-ietf-p2psip-concepts-01 , November 15, 2007, Work-in-progress, http://www.ietf.org/internet-drafts/draft-ietf- p2psip-concepts-01.txt; C. Jennings, B. Lowekamp, E. Rescorla, J. Rosenberg, S. Baset, and H. Schulzrinne, REsource LOcation And Discovery (RELOAD), draft-bryan- p2psip-reload-03, February 24, 2008, Work-in-progress, http://www.ietf.org/internet- drafts/draft-bryan-p2psip-reload-03.txt; and M. Matuszewski, J-E. Ekberg, and P. Laitinen, Security requirements in P2PSIP, draft-matuszewski-p2psip-security- requirements-02, November 19, 2007, Work-in-progress, http://www.ietf.org/internet- drafts/draft-matuszewski-p2psip-security-requirements-02.txt .

The gathering of diagnostic information is very different in centralized networks (e.g., a typical client-server SIP network) and in decentralized, P2P networks (e.g. a P2PSIP network). In a typical SIP network, a central server knows the network topology and can establish a connection to any node when required. However, in a P2PSIP network, there is no entity that would have even nearly comprehensive knowledge about the network topology (a typical P2P node know only a very, very small fraction from the network topology). As a result of this, in a decentralized P2P network the network topology has to be learned at the same time as the diagnostic information is gathered.

Currently, decentralized P2P networks do not have the ability to gather diagnostic information. Yongchao Song, Hewen Zheng, and Xingfeng Jiang, "Diagnose P2PSIP Overlay Network Failures", draft-zheng-p2psip-diagnose-01 , Internet Engineering Task Force, February 23, 2008, Work-in-progress, http://www.ietf.org/internet-drafts/draft- zheng-p2psip-diagnose-01.txt describes only a way to implement ping and traceroute on an overlay layer. However, a way to gather diagnostic information is not defined.

SUMMARY

The inventors have realised the problems associated with the prior art and devised a method and apparatus for gathering diagnostic information in a non centralized network such as a peer-to-peer network.

According to a first aspect of the invention, there is provided a method of gathering diagnostic information in a peer-to-peer network. A network node receives a request message requesting diagnostic information. The node gathers diagnostic information and adds the information to the request message. The node then resolves a next hop for the request message to a further node, and sends the request message to the further node. In this way, the diagnostic information is built up in the message for each node that the message traverses, until the message is returned to a monitoring node.

As an option, the method includes the step of determining whether a condition to stop gathering information from further nodes has been met. If so, then the request message is sent to a diagnostics monitoring node. An example of such a condition is whether the size of the request message has exceeded a predetermined size limit.

The diagnostics information optionally includes, for example, any of an uptime of the node, a history of online and offline cycles, a ratio between successful and failed procedures, information relating to failed procedures, error codes, and information related to time and situation when an error code was generated.

In order to assist the node in determining the next hop, the request message optionally contains policy information informing the node of a policy for resolving the next hop for the request message.

The method is particularly suitable for use in a peer-to-peer Session Initiation Protocol network, and such a network is optionally operatively connected to an IP Multimedia Subsystem network. In this situation, diagnostics monitoring node is optionally located in the IP Multimedia Subsystem network.

According to a second aspect of the invention, there is provided a node for use in a peer-to-peer network. The node is provided with a receiver for receiving a request message requesting diagnostic information. A processor is also provided for gathering diagnostic information, adding the information to the request message, and resolving a next hop for the request message to a further node. A transmitter is provided for sending the request message to the further node. The node optionally comprises a memory for storing diagnostics information. As a further option, the node is provided with a second transmitter for sending a diagnostic information message to a monitoring node, the diagnostic information message including the diagnostic information obtained from the request message. The processor is optionally arranged to determine whether a predetermined condition (for example, message size) has been met prior to sending the diagnostic information message to the monitoring node.

According to a third aspect of the invention, there is provided a monitoring node for use in a peer-to-peer network. The monitoring node comprises a processor arranged to generate a request message. The request message includes a request for diagnostic information from at least one other node in the peer-to-peer network. A transmitter is also provided for sending the request message to the further node, and a receiver is provided for receiving from a remote node a response to the request message.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates schematically in a block diagram a peer-to-peer network according to an embodiment of the invention;

Figure 2 is a signalling diagram illustrating an embodiment of the invention;

Figure 3 illustrates a request message structure according to an embodiment of the invention;

Figure 4 is a flow diagram showing the steps taken by a peer-to-peer node according to an embodiment of the invention.

Figure 5 illustrates schematically in a block diagram a node according to an embodiment of the invention; and

Figure 6 illustrates schematically in a block diagram a monitoring node according to an embodiment of the invention.

DETAILED DESCRIPTION

The following description assumes a peer-to-peer (P2P) network, and uses P2PSIP technology as an example. However, it will be appreciated by a person skilled in the art that the principles described for obtaining diagnostic information in a P2P network could be applied to communications technologies other than P2PSIP.

A Crawler-like Mechanism for Gathering Diagnostic information in P2P Networks, referred to herein as CrawlDiag, provides an efficient way of gathering diagnostic information in P2P networks. The diagnostic information, in this context, contains, for example, the following items:

• Uptime of the nodes, and the history of online/offline cycles.

• The ratio between successful and failed procedures (note: the procedure could be, e.g., a file retrieval or a call setup).

• Information about the failed procedures. For example, procedure type, execution time, and related error codes.

• General error codes, related situation, and time.

• Information related to error situations in the node (not necessarily related to P2P operations).

Note that the above list should not be considered exhaustive, but illustrative of the types of diagnostic information that can be gathered.

One possible way to implement CrawlDiag is to create a new method for a Peer

Protocol, which is used between the nodes in a P2P network. For example, a REsource LOcation And Discovery (RELOAD) protocol (see C. Jennings, B.

Lowekamp, E. Rescorla, J. Rosenberg, S. Baset, and H. Schulzrinne, REsource

Location And Discovery (RELOAD), draft-bryan-p2psip-reload-03, February 24, 2008, Work-in-progress, http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reloa d-03.txt) could have a new method caller "CrawlDiag".

Referring to Figure 1 , the gathering of diagnostic information is performed by 'crawling' from one node to another until the size limit of a CrawlDiag packet is reached, or some other condition for ending the crawling is met. One or more node(s) in a P2P network 1 act as a monitoring node 2. The monitoring node 2 could be, for example, operated by a telecom operator's personnel.

The monitoring node 2 sends CrawlDiag requests according to a policy (e.g., it can send a new CrawlDiag request when it receives a reply to the previous CrawlDiag message). When nodes (such as Na, Nb etc.) in the P2P network 1 (e.g., mobile phones) receive a CrawlDiag request, they add their diagnostic information to the request and pass it forward to a next hop node. The selection of the next hop node is made according to a policy (e.g., the next hop node can be the next node in the overlay ID space). In an embodiment of the invention, this policy is indicated in the CrawlDiag requests.

In Figure 1 , the monitoring node 2 sends out a CrawlDiag request S1 to node Na, which adds diagnostic information and sends S2 the request to Nb. Nb also adds diagnostic information and sends S3 the request to Nc. Once Nc has added its diagnostic information, a condition to stop crawling is met, and so a response S4 is sent to the monitoring node 2 including the diagnostic information for Na, Nb and Nc. The monitoring node 2 can then send a new request S5 to further nodes in order to gather more information.

Figure 2 is a signalling diagram showing the signalling corresponding to the operation of Figure 1. The Na, Nb, and Nc in square brackets below the arrows denote the gathered diagnostic information (e.g., uptime, success/failure ratio, etc.) from the corresponding nodes Na, Nb, Nc etc.

The structure of a CrawlDiag request sent from Nb to Nc (request S3 in Figures 1 and

2) is illustrated schematically in Figure 3. It contains a header part 3 and a payload part 4. The payload 4 includes the diagnostic information 5, 6 from the nodes to which

the request has already been sent. A possible implementation of this method is to create a new method in a P2P protocol.

The operations that a P2P node performs when receiving a CrawlDiag request are illustrated in the flow diagram of Figure 4. This figure presents the operations taken by node Nb (in Figures 1 and 2). Each node that receives a CrawlDiag request adds its own diagnostic information into the packet, and then forwards it to a next hop node or returns it to the original sender (origin).

When Nb receives S2 a CrawlDiag request from Na, it firstly determines S6 whether the packet containing the request is a CrawlDiag packet. If not then normal processing of the packet occurs S7. If it is a CrawlDiag packet, then Nb gathers requested diagnostic information S8 and writes it to the packet. A reply is sent back to the monitoring node 2 if a condition for ending the crawling is met. In this example the crawling ends when a size limit of the packet is exceeded (this is evaluated in step S9). However, there may be alternative or additional conditions for ending the crawling. Examples of other conditions include any of:

• Fixed hop count: If the request has already travelled n hops, then the reply is sent to the monitoring node 2; • Unfair number of requests: If the node has replied to a predetermined amount of diagnostics requests within a predetermined time scale, it can refuse to reply to new message within a given time window; and

• Local policy: The node may refuse to forward the request on the grounds of local policy, for example the monitoring node is unknown to the node. In this case, the node will simply reply, optionally with an error code.

If the condition is met (in this example, the packet exceeds the size limit), then it is returned S10 to the monitoring node 2. If the packet does not exceed the size limit, then the next hop is resolved S1 1 according to policies included in the request, and the request with Nb's diagnostic information is sent S3 to Nc.

Referring to Figure 5 herein, there is illustrated schematically in a block diagram a P2P node according to an embodiment of the invention. The node (in this example, Na) is provided with a receiver 7 that receives a CrawlDiag request. A processor 8 is arranged to gather diagnostics information, add the diagnostics information to the CrawlDiag request, and determine a next hop for the CrawlDiag request. Relevant

information may be retrieved from a memory 9 in the node. A transmitter 10 is also provided for sending the request to a further node in the P2P network. A second transmitter 11 may be provided for sending the reply to the monitoring node 2. Of course, the second transmitter may be a separate physical entity from the first transmitter 10, or the two transmitting functions may be embodied in a single transmitter.

Figure 6 illustrates a monitoring node 2 according to an embodiment of the invention. The monitoring node 2 is provided with a processor 12 for generating a request message requesting diagnostic information. A transmitter 13 is provided for sending the request message to node Na, and a receiver 14 is provided for receiving from a remote node a response to the request message.

The invention combines 'crawling' and gathering of diagnostic information, and provides ability to efficiently gather diagnostic information from nodes in P2P networks.

It will be appreciated by a person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the present invention.

The following abbreviations have been used in the above description:

CrawlDiag Crawler-like Mechanism for Gathering Diagnostic information in P2P

Networks DHT Distributed Hash Table

IETF Internet Engineering Task Force

Nx Node x

P2P Peer-to-peer

P2PSIP Peer-to-peer Session Initiation Protocol RELOAD REsource LOcation And Discovery

SIP Session Initiation Protocol