TOC 
NSISC. Dickmann
Internet-DraftI. Juchem
Expires: November 18, 2005S. Willert
 X. Fu
 Univ. Goettingen
 May 17, 2005

A stateless Ping tool for simple tests of GIMPS implementations

draft-juchem-nsis-ping-tool-01.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 November 18, 2005.

Copyright Notice

Copyright © The Internet Society (2005).

Abstract

When implementing signaling protocols such as CASP or GIMPS, implementors need a way to test the functionality and measure the performance of their own implementations. In this document, we try to provide a sketch for such a testing tool, a simple, stateless Ping Protocol, which works similar to ICMP Ping. This tool is able to traverse a path from a source to a destination along signaling aware network nodes and collect various data that could be useful for identifying each node it is passing.



Table of Contents

1.  Introduction
2.  Design Overview
    2.1  Ping message format
    2.2  Behaviour of nodes running the Ping tool
3.  Possible extension to the current ping functionality
4.  Summary and Open Issues
5.  Security Considerations
6.  Acknowledgments
7.  References
    7.1  Normative References
    7.2  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

This document describes a design for the implementation of a simple and basic stateless Ping tool for traversal of General Internet Messaging Protocol for Signaling (GIMPS) [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.) aware network nodes.

In the NSIS two-layer architecture, GIMPS is being developed as the fundamental building block to provide generic signaling services for various signaling applications. Without implementing any full-fledged signaling application, GIMPS implementors may want to test the functionality and run-time properties of the protocol. A tool for such purposes, so-called "Ping Tool" in the document, which is inspired by the ping client done in the implementation of the Cross Application Signaling Protocol (CASP) [2] (Schulzrinne, H. and et al., “CASP - Cross-Application Signaling Protocol,” March 2003.) at Univ Goettingen, suffices this need.

An implementation of the ping tool is able to traverse each GIMPS aware node from initiator to responder and back to the initator. Useful information about the signaling behaviour e.g., information about the signaling-aware hops and GIMPS layer processing delays is collected while traversing the network.

The initial functionality of such a Ping tool would be rather simple; details will be described later in this document. With this simplicity in mind, we reused the concept of the 'Null Service Type' as described in RFC2997 [3] (Bernet, Y., Smith, A., and B. Davie, “Specification of the Null Service Type,” November 2000.).



 TOC 

2. Design Overview

The design of the Ping tool should follow these basic rules:

simplicity (with a minimal overhead)

testing as many properties of GIMPS as possible

The ping tool proposed in this draft uses the layered structure of NSIS, and is defined as a simple NSIS signaling Layer Protocol (NSLP) application. The ping tool uses the common API to communicate with the NSIS transport Layer Protocol (NTLP) and so it is able to test the functionality of GIMPS from the NSLPs' point of view.

The ping tool consists of two parts. The 'Ping Daemon' is the NSLP application that does the real work of sending and receiving ping messages. The 'Ping Client' as a user side program is used to trigger the 'Ping Daemon' in a GIMPS node to send ping messages. Additionally the 'Ping Client' can perform the anlysis of the collected data.

Figure 1 shows the layering of the ping tool and the common packet flow provided by GIMPS, where the Initiator sends data packets along the path through GIMPS-aware nodes until they reach the Responder. This Responser will send its response message upstream back to the Initiator.

+---------+
|  Ping   |
|  Client |
+---------+
   v   ^
+---------+    +---------+       +---------+    +---------+
|  Ping   |    |  Ping   |       |  Ping   |    |  Ping   |
|  Daemon |    |  Daemon |       |  Daemon |    |  Daemon |
+---------+    +---------+       +---------+    +---------+
   v   ^          v   ^             v   ^          v   ^
+---------+    +---------+       +---------+    +---------+
|         |<<<<|         |< ... <|         |<<<<|         |
|Initiator|    |  Hop 1  |       |  Hop N  |    |Responder|
|         |>>>>|         |> ... >|         |>>>>|         |
+---------+    +---------+       +---------+    +---------+


Figure 1: Ping tool layering and packet flow overview

The proposed ping tool uses the transport mechanisms provided by GIMPS. Unlike the end-to-end delivery provided by the IP, ping messages are sent hop-to-hop in GIMPS nodes. At each node running the "Ping Daemon", received ping messages are passed to the NSLP level, which decides which action should be taken next. Thus, Ping tool offers traceroute-like path discovery without adding any feature in GIMPS.

So the operation of the ping tool is as follows: The initiator sends a NSLP data message (using the ping message format described later) downstream towards the destination. The ping message is passed to each hop's 'Ping Daemon', which will add the following information to the data message:

Its own IP-address

A timestamp with the current time since the Epoch (00:00:00 UTC,January 1, 1970) in microseconds.

When the ping message arrives at the receiver, the receiver adds its own information same as any other node and changes the direction from downstream to upstream. The nodes are passed in reverse order and again every hop adds its own information. The intermediate nodes do not change the sending direction of a ping message, so it finally arrives at the initiator. The collected data is passed to the 'Ping Client' which is able to calculate round trip times (RTTs) from the data collected along the path. Figure 2 shows a calculation example.



	  t1(0)  t1(1)  t1(2)  t1(3)         t1(N)
          +---+  +---+  +---+  +---+         +---+
          | I |>>| 1 |>>| 2 |>>| 3 |>> ... >>| R |
          +---+  +---+  +---+  +---+         +---+
                                               v
          +---+  +---+  +---+  +---+         +---+
          | I |<<| 1 |<<| 2 |<<| 3 |<< ... <<| R |
          +---+  +---+  +---+  +---+         +---+
          t2(0)  t2(1)  t2(2)  t2(3)         t2(N)

  t1(x) is the timestamp inserted by hop x in downstream direction
  t2(x) is the timestamp inserted by hop x in upstream direction
  where t1(N) = t2(N)

  overall RTT for node x is: RTT(x) = t2(x) - t1(x)
  hop-to-hop RTT for nodes x and y (x < y) can be computet by:
  h2hRTT(x, y) = RTT(x) - RTT(y)

          Figure 2. An example of timestamp use

Note that the 'Ping Daemon' will not install any state in the NSLP level on the node it is running on, except for the initiator node. The Ping tool is therefore stateless. However the underlying GIMPS layer may, and probably will, install state according to GIMPS specifications, e.g., for reverse message routing.

2.1 Ping message format

The ping message format is used in downstream and upstream direction and is extended by every node on the path. As described above, currently two types of information are added to the Ping tool message by each node: IP-address and timestamp. Also, the number of hops, meaning the amount of nodes the packet traversed, and the message length should be present in such an message. Having both hop and length information adds redundancy but can help data analysis in the ping client. To support future extensions of the ping message format, a version number is attached. This draft represents version 1 in this context. Finally a sequence number is added to the ping message. This can be used to identify single ping messages if multiple pings are send concurrently. Figure 3 shows the ping message format in its final form when returning to the initiator. The IP-address and timestamp block for each hop are added to the message while traversing the GIMPS network.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |     Hops      |     Length    |     Seq#      |
+---------------------------------------------------------------+
| IP-address of initiator (16 bytes)                            |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
| timestamp from Initiator                                      |
|                                                               |
+---------------------------------------------------------------+
| IP-address of first hop(16 bytes)                             |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
| timestamp from of first hop                                   |
|                                                               |
+---------------------------------------------------------------+
.                                                               .
.                                                               .
.                                                               .
+---------------------------------------------------------------+
| IP-address of Nth hop(16 bytes)                               |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
| timestamp from Nth hop                                        |
|                                                               |
+---------------------------------------------------------------+
| IP-address of (N-1)th hop(16 bytes)                           |
| (direction of traversal changed to upstream)                  |
|                                                               |
+---------------------------------------------------------------+
| timestamp from (N-1)th hop                                    |
|                                                               |
+---------------------------------------------------------------+
.                                                               .
.                                                               .
.                                                               .
+---------------------------------------------------------------+
| IP-address of initiator (16 bytes)                            |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
| timestamp from Initiator                                      |
|                                                               |
+---------------------------------------------------------------+

          Figure 3. Ping message format

Note that for compatibility with IPv4 and IPv6 the size of each IP- address field will be 16 bytes. The timestamp uses 4 bytes for seconds since Epoch (00:00:00 UTC,January 1, 1970) and additional 4 bytes for microseconds. This example shows that each hop, except the Nth one, adds a timestamp twice, due to the fact that each hop is passed twice, one time in downstream and another time in upstream direction. Using this information, one can calculate round trip times (RTT) for every node very easily.

2.2 Behaviour of nodes running the Ping tool

There are four entities involved in a ping session. Detailed actions for each of those will be described here:

Behahviour of 'Ping Client':

Contact 'Ping Daemon' on local node

Request sending ping message with specified receiver and sequence number

Wait for response from 'Ping Daemon'

Process collected data and generate result output

Behahviour of 'Ping Daemon' on the Initiator node:

Create Ping message

Add own IP-address and timestamp

Send message downstream towards receiver

Wait for message to return

Pass message to the 'Ping Client' who requested the ping

Behahviour of 'Ping Daemon' on intermediate nodes

Receive Ping message

Increase number of hops field by 1

Add own IP-address and timestamp at the end of the message

Adjust length field

Forward message in the same direction it arrived

Behahviour of 'Ping Daemon' on receiver node

Receive Ping message

Increase number of hops field by 1

Add own IP-address and timestamp at the end of the message

Adjust length field

Send the message in upstream direction



 TOC 

3. Possible extension to the current ping functionality

Ping messages are currently only used for collecting hop and processing delay information. Further extensions for this ping tool are possible but require properly addressing security concerns:

Collect GIMPS layer state information (although this has some implication of voliation)

Collect all or selected NSLPs' state information

On the other hand, the Ping tool could be turned into a stateful tool. A possible function of the Ping tool could then be that it is installing a state on every GIMPS-aware hop it is passing on the way to the Ping message receiver and delete each of the state on the way backwards to the initiator.



 TOC 

4. Summary and Open Issues

We have shown in this document how a testing tool for GIMPS implementations could be designed. Our intentions were to keep it as simple and therefore as portable and extensible as possible. The Ping tool will be able to help GIMPS implementors test their own implementation as well as compare it to others in terms of functionality and basic performance.

Further additions to the Ping tool could be support for tunnelling devices along the GIMPS path and an updated design for a stateful protocol.



 TOC 

5. Security Considerations

A future versions of this document will add security relevant considerations.



 TOC 

6. Acknowledgments

The authors would like to thank Bernd Schloer, Andreas Westermaier and Henning Peters for their feedback.



 TOC 

7. References



 TOC 

7.1 Normative References

[1] Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” draft-ietf-nsis-ntlp-05 (work in progress), February 2005.
[2] Schulzrinne, H. and et al., “CASP - Cross-Application Signaling Protocol,” draft-schulzrinne-nsis-casp-01 (work in progress), March 2003.


 TOC 

7.2 Informative References

[3] Bernet, Y., Smith, A., and B. Davie, “Specification of the Null Service Type,” RFC 2997, November 2000.


 TOC 

Authors' Addresses

  Christian Dickmann
  University of Goettingen
  Telematics Group
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  mail@christian-dickmann.de
  
  Ingo Juchem
  University of Goettingen
  Telematics Group
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  ijuchem@cs.uni-goettingen.de
  
  Sebastian Willert
  University of Goettingen
  Telematics Group
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  swillert@cs.uni-goettingen.de
  
  Xiaoming Fu
  University of Goettingen
  Telematics Group
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  fu@cs.uni-goettingen.de


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment