One document matched: draft-juchem-nsis-ping-tool-01.txt
Differences from draft-juchem-nsis-ping-tool-00.txt
NSIS C. Dickmann
Internet-Draft I. Juchem
Expires: November 18, 2005 S. 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 (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 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
Dickmann, et al. Expires November 18, 2005 [Page 1]
Internet-Draft Ping Tool for GIMPS May 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.2 Behaviour of nodes running the Ping tool . . . . . . . . . 7
3. Possible extension to the current ping functionality . . . . . 7
4. Summary and Open Issues . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Dickmann, et al. Expires November 18, 2005 [Page 2]
Internet-Draft Ping Tool for GIMPS May 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 November 18, 2005 [Page 3]
Internet-Draft Ping Tool for GIMPS May 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, 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.
Dickmann, et al. Expires November 18, 2005 [Page 4]
Internet-Draft Ping Tool for GIMPS May 2005
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
Dickmann, et al. Expires November 18, 2005 [Page 5]
Internet-Draft Ping Tool for GIMPS May 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Dickmann, et al. Expires November 18, 2005 [Page 6]
Internet-Draft Ping Tool for GIMPS May 2005
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
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:
Dickmann, et al. Expires November 18, 2005 [Page 7]
Internet-Draft Ping Tool for GIMPS May 2005
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.
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
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.
Dickmann, et al. Expires November 18, 2005 [Page 8]
Internet-Draft Ping Tool for GIMPS May 2005
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
Xiaoming Fu
University of Goettingen
Telematics Group
Lotzestr. 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
Dickmann, et al. Expires November 18, 2005 [Page 9]
Internet-Draft Ping Tool for GIMPS May 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 November 18, 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 14:32:37 |