Internet DRAFT - draft-juchem-nsis-ping-tool
draft-juchem-nsis-ping-tool
NSIS C. Dickmann
Internet-Draft I. Juchem
Expires: January 18, 2006 S. Willert
X. Fu
Univ. Goettingen
July 2005
A stateless Ping tool for simple tests of GIMPS implementations
draft-juchem-nsis-ping-tool-02.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 January 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
When implementing signaling protocols such as 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" NSLP,
which works similar to ICMP Ping. This tool is able to traverse a
path from a source to a destination along signaling aware network
Dickmann, et al. Expires January 18, 2006 [Page 1]
Internet-Draft Ping Tool for GIMPS July 2005
nodes and collect various data that could be useful for identifying
each node it is passing.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Ping message format . . . . . . . . . . . . . . . . . . . 5
2.1.1 Supported objects . . . . . . . . . . . . . . . . . . 6
2.1.2 Ping message example . . . . . . . . . . . . . . . . . 7
2.2 Behaviour of nodes running the Ping tool . . . . . . . . . 9
3. Possible extension to the current ping functionality . . . . . 10
4. Summary and Open Issues . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1 Normative References . . . . . . . . . . . . . . . . . . . 11
7.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13
Dickmann, et al. Expires January 18, 2006 [Page 2]
Internet-Draft Ping Tool for GIMPS July 2005
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] 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] 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].
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
Dickmann, et al. Expires January 18, 2006 [Page 3]
Internet-Draft Ping Tool for GIMPS July 2005
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, the
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 downstream towards the destination. This NSLP
data message uses the ping message format described later and starts
with a list of requested information, that every node should add. So
the ping message is passed to the 'Ping Daemon' of each hop on the
path. The 'Ping Daemon' will add the requested information to the
data message. The requested information might include, but is not
limited to:
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
Dickmann, et al. Expires January 18, 2006 [Page 4]
Internet-Draft Ping Tool for GIMPS July 2005
arrives at the initiator. The collected data is passed to the 'Ping
Client' which is able to calculate round trip times (RTTs) from the
collected timestamps 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. The message consists of
three parts. The common header, a list of object headers and the
data part. The common header contains a version number for further
extensions and this draft represents version 1 in this context. In
addition, the common header contains the number of hops, meaning the
amount of nodes the packet traversed, the message length (in number
of bytes), a sequence number as well as the number of objects every
hop should add. The sequence number can be used to identify single
ping messages if multiple pings are sent concurrently. The common
header is shown in figure 3.
Dickmann, et al. Expires January 18, 2006 [Page 5]
Internet-Draft Ping Tool for GIMPS July 2005
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 | # of objects |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Common header of ping message
The common header is followed by a list of object headers. The
object header contains a type and a length (in number of bytes)
field. The byte format is given in figure 4. The existing objects
and the values assigned for the type field are given later.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Object header of ping message
The data part of the message is extended by every hop. The node
reads the list of objects and needs to add all the requested
information. If the node does not support one of the requested
objects, an empty object of the specified length is used instead.
This way, every hop adds a fixed number of bytes to the message and
so backward compatibility is guaranteed. Traversed nodes should
regard the received ping message read-only and just add their
information at the end of the message. The hop count and length
field in the common header are the only exceptions from this rule.
2.1.1 Supported objects
A few objects are predefined in this draft and MUST be supported by
all implementations. Currently the list objects is limited to an IP-
address object and the timestamp object.
2.1.1.1 The IP-address object
Dickmann, et al. Expires January 18, 2006 [Page 6]
Internet-Draft Ping Tool for GIMPS July 2005
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
+---------------------------------------------------------------+
| IP-address (16 bytes) |
| |
| |
| |
+---------------------------------------------------------------+
Figure 5. IP-address object (type = 1)
Figure 5 shows the byte format of the IP-address object. It contains
either an IPv4 or IPv6 address and has a fixed length of 16 bytes.
The type value for this object is 1.
2.1.1.2 The timestamp object
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
+---------------------------------------------------------------+
| Timestamp (8 bytes) |
| |
+---------------------------------------------------------------+
Figure 6. Timestamp object (type = 2)
Figure 6 depicts the byte format of the IP-address object. The
timestamp uses 4 bytes for seconds since Epoch (00:00:00 UTC,January
1, 1970) and additional 4 bytes for microseconds. The assigned type
value is 2.
2.1.2 Ping message example
Figure 7 shows an example ping message containing the IP-address and
timestamp object. The shown format is 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 | # of obj = 2 |
+---------------------------------------------------------------+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 (IP-address) | Length = 16 |
Dickmann, et al. Expires January 18, 2006 [Page 7]
Internet-Draft Ping Tool for GIMPS July 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 2 (Timestamp) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
Dickmann, et al. Expires January 18, 2006 [Page 8]
Internet-Draft Ping Tool for GIMPS July 2005
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Ping message format
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:
Behaviour 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
Behaviour of 'Ping Daemon' on the Initiator node:
Create Ping message
Add own requested objects (e.g. IP-address and timestamp)
Send message downstream towards receiver
Wait for message to return
Pass message to the 'Ping Client' who requested the ping
Behaviour of 'Ping Daemon' on intermediate nodes
Receive Ping message
Increase number of hops field by 1
Add own requested objects (e.g. IP-address and timestamp) at the
end of the message
Adjust length field
Forward message in the same direction it arrived
Behaviour of 'Ping Daemon' on receiver node
Receive Ping message
Increase number of hops field by 1
Add own requested objects (e.g. IP-address and timestamp) at the
end of the message
Adjust length field
Send the message in upstream direction
Dickmann, et al. Expires January 18, 2006 [Page 9]
Internet-Draft Ping Tool for GIMPS July 2005
3. Possible extension to the current ping functionality
Ping messages are currently only used for collecting topological
location and processing delays. Further extensions for this ping
tool include more objects, that nodes can support. The format is
flexible enough to be backward compatible for the case that nodes do
not support new or special objects. However these extensions require
properly addressing security concerns. Possible objects might
contain information about:
GIMPS layer state information (although this has some implication
of voliation)
All or selected NSLPs' state information
Information about the host GIMPS is running on
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.
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.
5. Security Considerations
A future versions of this document will add security relevant
considerations.
6. Acknowledgments
The authors would like to thank Bernd Schloer, Andreas Westermaier
and Henning Peters for their feedback.
7. References
Dickmann, et al. Expires January 18, 2006 [Page 10]
Internet-Draft Ping Tool for GIMPS July 2005
7.1 Normative References
[1] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work
in progress), May 2005.
[2] Schulzrinne, H. and et al., "CASP - Cross-Application Signaling
Protocol", draft-schulzrinne-nsis-casp-01 (work in progress),
March 2003.
7.2 Informative References
[3] Bernet, Y., Smith, A., and B. Davie, "Specification of the Null
Service Type", RFC 2997, November 2000.
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
Dickmann, et al. Expires January 18, 2006 [Page 11]
Internet-Draft Ping Tool for GIMPS July 2005
Xiaoming Fu
University of Goettingen
Telematics Group
Lotzestr. 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
Dickmann, et al. Expires January 18, 2006 [Page 12]
Internet-Draft Ping Tool for GIMPS July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dickmann, et al. Expires January 18, 2006 [Page 13]
