NSIS I. Juchem Internet-Draft S. Willert Expires: August 5, 2005 X. Fu Univ. Goettingen Feb 2005 A stateless Ping Client for simple tests of GIMPS implementations draft-juchem-nsis-ping-tool-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract When implementing signaling protocols such as CASP or GIMPS, implementers need a way to test the functionality and measure the runtime properties of their own implementations. In this document, we try to provide a sketch for such a testing tool, a simple, stateless Ping Client, which works similar to ICMP Ping messages. Juchem, et al. Expires August 5, 2005 [Page 1] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Additions to the GIMPS protocol . . . . . . . . . . . . . 6 2.2 Detailed message format of the Ping Client Object . . . . 6 2.3 Behaviour of nodes running the Ping Client . . . . . . . . 7 3. Possible extension to the ping client's functionality . . . . 9 4. Summary and Open Issues . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Normative References . . . . . . . . . . . . . . . . . . . 13 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Juchem, et al. Expires August 5, 2005 [Page 2] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 1. Introduction This document describes a design for the implementation of a simple and basic stateless Ping client for traversal of General Internet Messaging Protocol for Signaling (GIMPS) [1] aware network nodes. In the NSIS two-layer architecture, GIMPS is being defined as the fundamental building block to provide generic signaling services for various signaling applications. Without implementing any full-fledged signaling application, implementers of GIMPS may want to test the functionality and run-time properties of the protocols. The Ping client, first being developed as a testing tool in our implementation of the Cross Application Signaling Protocol (CASP) [2], suffices this need. This tool is able to traverse each CASP/GIMPS aware node from initiator to responder and collect useful information about the signaling behaviour e.g., information about the signaling-aware hops and processing latency. It would be useful to have such a traversal client that offers the possibility to test pure NTLP semantics with minimal interference from NSLP layer clients. The functionality of such a 'Ping Client' would be rather simple, details will be described later in this document. With this simplicity in mind, the authors introduce an updated version of the 'Null Service Type' as described in RFC2997 [3] ported to the GIMPS message format. Juchem, et al. Expires August 5, 2005 [Page 3] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 2. Design Overview The design of the Ping Client should follow these basic rules: simplicity for reduction of overhead portability for interaction with different Signaling protocols Two new GIMPS message type are proposed for the Ping Client (type TBA). It is assumed all GIMPS-aware nodes will be able to support those Ping Client messages. To be able to collect and transport necessary testing data, two new GIMPS objects will also be introduced. Details about the objects format will be described later. Figure 1 shows the basic concept of the packet flow, where the Initiator sends data packets along the path through other GIMPS-aware nodes until they reach the Responder. This Responder will then send it's response message back to the Initiator along the very same path. +---------+ +---------+ +---------+ +---------+ | |>>>>| |> ... >| |>>>>| | |Initiator| | Hop 1 | | Hop N | |Responder| | |<<<<| |< ... <| |<<<<| | +---------+ +---------+ +---------+ +---------+ Figure 1. Packet flow overview With GIMPS having a two-layer architecture with a signal layer, called NSIS signaling Layer Protocol (NSLP) and a transport layer, called NSIS transport Layer Protocol (NTLP) the Ping Client will reside in the signaling layer. There it will process messages carrying the Objects with the object ID it was assigned and pass them on to the next hop. Note that the Client will not install any state on the node it is running on. It is therefore a stateless Ping Client. Actions by the Ping Client will be triggered by a REQUEST message originating from the Initiator and destined to the Responder. The Responder will answer with a RESPONSE message. The behaviour of the Ping Client will be different for each direction of the data flow. After a REQUEST message, packets traversing from Initiator to Responder will be processed by each Ping Client the way to the destination. Each Hop's client will add the following information to the carried GIMPS object: It's own IP-address Juchem, et al. Expires August 5, 2005 [Page 4] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 A timestamp with the current time since the Epoch (00:00:00 UTC,January 1, 1970) in seconds. This Information will be preserved until the packet reaches the Responder who will generate a RESPONSE message. This RESPONSE message will include the complete Information that was collected so far and will be send back along the path. Nodes on the way back to the Initiator will again add the same information to the carried object. With the previously collected information, each node knows the IP address of its previous hop and can pass the object along the correct path. When the object reaches the Initiator, it will contain IP-addresses and timestamps from every node on the path and back. The Initiator then substracts the timestamp collected on the way to the Responder from the value added on the path back to the Initiator. This is divided by two (because we then have the time for the path to and from) and this value will be substracted from the equally computed value of the previous hop on the way back (see the following figure). T1 T1 T1 T1 T1 +--+ +--+ +--+ +--+ +--+ |I |>>|1 |>>|2 |>>|3 |>> ...>>|R | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ |I |<<|1 |<<|2 |<<|3 |<< ...<<|R | +--+ +--+ +--+ +--+ +--+ T2 T2 T2 T2 T2 so T0 for each hop would be (T2-T1) / 2 and T0 for hop N would be ((T2-T1)/2 ) - (T0 of hop N+1) Figure 2. An example of timestamp use With this information, it will be easy to measure traversal costs of the implementation the Ping Client is running on as well as receiving a sign of life from each node on the path. Because the proposed Ping Client is stateless, nodes are not subject to any alterations after the RESPONSE message has passed them. This means that no more messages are needed. Juchem, et al. Expires August 5, 2005 [Page 5] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 2.1 Additions to the GIMPS protocol Changes to the GIMPS protocol are fairly limited. As we proposed, only two new Object Ids, one for Ping Client REQUEST message and one for Ping Client RESPONSE message, and a new Object format have to be added. Because GIMPS' NSLP header format includes simply a message type with optional processing flags no changes are needed. 2.2 Detailed message format of the Ping Client Object As described in chapter 2.1, two types of information will be added to the Ping client object by each node: IP-address and timestamp. Also, the number of hops, meaning the amount of nodes the packet traversed, should be present in such an object. This does not only give additional information but can also serve as safety measure: If the amount of hops is not an even number after the Object returned to the Initiator, this will mean that one hop on the path was left. Which one can be identified by comparing the IP-addresses of the forward and backward paths the object was transported. The following illustration shows the format of such a Ping Client Object for a REQUEST message: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | number of hops | reserved | +---------------------------------------------------------------+ | IP-address of initiator (16 bytes) | | | | | +---------------------------------------------------------------+ | timestamp from Initiator | +---------------------------------------------------------------+ | IP-address of first hop(16 bytes) | | | | | +---------------------------------------------------------------+ | timestamp from first hop | +---------------------------------------------------------------+ . . . +---------------------------------------------------------------+ | IP-address of Nth hop(16 bytes) | | | | | +---------------------------------------------------------------+ Juchem, et al. Expires August 5, 2005 [Page 6] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 | timestamp from Nth hop | +---------------------------------------------------------------+ Note that for compatibility with IPv4 and IPv6 the size of each IP- address field will be 16 bytes. Also on most systems time_t has a size of 4 bytes so each timestamp occupies 4 bytes. The 'reserved' field in the message could be used to extend the functionality of the client according to the implementers' needs. The format for RESPONSE messages is similar to the REQUEST messages' design: It will include the whole REQUEST message object and each hop including the responder will add the following data: +---------------------------------------------------------------+ | IP-address(16 bytes) | | | | | +---------------------------------------------------------------+ | timestamp | +---------------------------------------------------------------+ 2.3 Behaviour of nodes running the Ping Client There are three entities along the path from Initiator to Responder. Detailed actions for each of those will be described here: Behaviour for Initiator: Create Ping Client REQUEST object Get information about next hop Initialize REQUEST object with own IP-address and timestamp Send object to next hop RESPONSE object received Collect information from RESPONSE object Compare value 'number of hops' field with amount of traversed hops Parse collected data Behaviour for intermediate nodes Receive Ping Client object Check whether it is a REQUEST or a RESPONSE object REQUEST object Increase number of hops field by 1 Add own IP-address and timestamp at the end of object Send object to next hop RESPONSE object Juchem, et al. Expires August 5, 2005 [Page 7] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 Increase number of hops field by 1 Retrieve IP-address of next hop from Object Add own IP-address and timestamp at the end of object Send object to next hop Behaviour for responder Receive REQUEST object and copy content to newly created RESPONSE object Retrieve IP-address of first hop for RESPONSE from Object Add own IP-address and timestamp to RESPONSE object Send object to next hop Juchem, et al. Expires August 5, 2005 [Page 8] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 3. Possible extension to the ping client's functionality Because our proposed design is quite basic, it is possible to extend the functionality of the client. For example, it could be easily turned into a stateful client by using the 'reserved' field in the REQUEST and RESPONSE objects. A possible function of the Ping Client could then be that it is installing a state on every GIMPS-aware hop it is passing after the REQUEST message was issued and delete each of the state on the way backwards after the Responder sent the RESPONSE message. Juchem, et al. Expires August 5, 2005 [Page 9] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 4. Summary and Open Issues We have shown in this document how a testing client for GIMPS implementations could be designed. Our intentions were to keep it as simple and therefore as portable and extensible as possible. The Ping Client will be able to help GIMPS implementers test their own implementation as well as compare it to others in terms of runtime properties. Further additions to the Ping Client could be support for tunnelling devices along the GIMPS path and an updated design for a stateful client. Also, the issue of GIMPS tunneling nodes will have to be addressed as well as a possible enhancement of the packet format for easier distinguishing of IPv4 and v6. Juchem, et al. Expires August 5, 2005 [Page 10] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 5. Security Considerations A future versions of this document will add security relevant considerations. Juchem, et al. Expires August 5, 2005 [Page 11] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 6. Acknowledgments The authors would like to thank everbody giving their feedback and commenting on this. Juchem, et al. Expires August 5, 2005 [Page 12] Internet-Draft Ping Testing Tool for GIMPS Feb 2005 7. References 7.1 Normative References [1] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", Internet-Draft draft-ietf-nsis-ntlp-04, October 2004. [2] Schulzrinne, H. and et al., "CASP - Cross-Application Signaling Protocol", Internet-Draft draft-schulzrinne-nsis-casp-01, 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 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 Juchem, et al. Expires August 5, 2005 [Page 13] Internet-Draft Ping Testing Tool for GIMPS Feb 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. Juchem, et al. Expires August 5, 2005 [Page 14]