Nsis_Imp May 2005

nsis_imp@informatik.uni-goettingen.de

8 participants
5 discussions

RE: [Nsis_imp] ping tool I-D update
by Christian Dickmann 19 May '05

19 May '05

Hi Constantin, > Figure 2 lacks an explanation of the variables. What is T0? What is the > intention of the formula 'and T0 for hop N would be ((T2-T1)/2 ) - (T0 of > hop N+1)'. I'm currently wondering why the RTT/2 of the subsequent node is > being substracted. > you are absolutely right ;) I did not understand the figure either. I just forgot to update it. Have a look at 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) 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 Is this better? > I suggest that you make the Ping message format a bit more clear in Fig 3. > It might be confusing that there is the IP address of the current node and > in the next field, one can find the IP address of the previous hop. I know > that this is due to the upstream direction but I think that adding a > downstream field, the NR field and an upstream field makes it more > understandable. I do not get what you mean. Could you give a more detailed view? Christian Dickmann

2 1

draft-fu-nsis-ntlp-statemachine-02 pre-release version
by Tseno Tsenov 17 May '05

17 May '05

Hi all, Pls. find attached the gimps fsm draft v-02 included. I think we should submit it today, so any final comments are highly appreciated. !Take a look at the included gimps_state_machine_info.txt file.! Greetigns, tseno_

2 1

ping tool I-D update
by Xiaoming Fu 17 May '05

17 May '05

Hi all, Christian has updated the ping tool I-D and intends to submit it today. Any suggestions, comments appreciated. Regards Xiaoming 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 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 Dickmann, et al. Expires November 18, 2005 [Page 1] Internet-Draft Ping Tool for GIMPS May 2005 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 Ping message format . . . . . . . . . . . . . . . . . . . 6 2.2 Behaviour of nodes running the Ping tool . . . . . . . . . 7 3. Summary and Open Issues . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1 Normative References . . . . . . . . . . . . . . . . . . . 12 6.2 Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 14 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]. Dickmann, et al. Expires November 18, 2005 [Page 3] Internet-Draft Ping Tool for GIMPS May 2005 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 Dickmann, et al. Expires November 18, 2005 [Page 4] Internet-Draft Ping Tool for GIMPS May 2005 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 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 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. Dickmann, et al. Expires November 18, 2005 [Page 5] Internet-Draft Ping Tool for GIMPS May 2005 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 | | | Dickmann, et al. Expires November 18, 2005 [Page 6] Internet-Draft Ping Tool for GIMPS May 2005 +---------------------------------------------------------------+ | IP-address of (N-1)th hop(16 bytes) | | | | | +---------------------------------------------------------------+ | 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: Dickmann, et al. Expires November 18, 2005 [Page 7] Internet-Draft Ping Tool for GIMPS May 2005 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 Dickmann, et al. Expires November 18, 2005 [Page 8] Internet-Draft Ping Tool for GIMPS May 2005 3. Summary and Open Issues We have shown in this document how a testing protocol for GIMPS implementations could be designed. Our intentions were to keep it as simple and therefore as portable and extensible as possible. The Ping protocol will be able to help GIMPS implementors test their own implementation as well as compare it to others in terms of performance and scalability. Further additions to the Ping tool could be support for tunnelling devices along the GIMPS path and an updated design for a stateful protocol. Dickmann, et al. Expires November 18, 2005 [Page 9] Internet-Draft Ping Tool for GIMPS May 2005 4. Security Considerations A future versions of this document will add security relevant considerations. Dickmann, et al. Expires November 18, 2005 [Page 10] Internet-Draft Ping Tool for GIMPS May 2005 5. Acknowledgments The authors would like to thank Bernd Schloer, Andreas Westermaier and Henning Peters for their feedback. Dickmann, et al. Expires November 18, 2005 [Page 11] Internet-Draft Ping Tool for GIMPS May 2005 6. References 6.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. 6.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(a)christian-dickmann.de Ingo Juchem University of Goettingen Telematics Group Lotzestr. 16-18 Goettingen 37083 Germany Email: ijuchem(a)cs.uni-goettingen.de Dickmann, et al. Expires November 18, 2005 [Page 12] Internet-Draft Ping Tool for GIMPS May 2005 Sebastian Willert University of Goettingen Telematics Group Lotzestr. 16-18 Goettingen 37083 Germany Email: swillert(a)cs.uni-goettingen.de Xiaoming Fu University of Goettingen Telematics Group Lotzestr. 16-18 Goettingen 37083 Germany Email: fu(a)cs.uni-goettingen.de Dickmann, et al. Expires November 18, 2005 [Page 13] 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(a)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 14]

2 1

gimps ethereal dissector preview
by Henning Peters 17 May '05

17 May '05

Dear all, due to request of Xiaoming Fu I've been working on an ethereal protocol dissector for the gimps protocol since last week. I would like to share a first preview with you. Here you can get an impression of how it looks like: http://user.informatik.uni-goettingen.de/~hpeters/images/gimps.png It's use is mainly focused on debugging the ongoing implementation. Christian and I already found today that there exists an issue with byte ordering and alignment in the code through this way. I think it might be a valuable tool for analyzing gimps packets while implementing new features. You can get the latest version running by checking out the new working/ethereal directory via CVS and a current ethereal copy via SVN. Simply copy the contents of working/ethereal (cleo/gimps) into epan/dissectors (ethereal) and run "./autogen; ./configure; make". A captured libpcap session can be found at working/gimpsCapture. The current features are limited to analyzation of following headers and objects (without optional fields): - Common Header - Standard Object Header - MRI - NAO - Session It's not stable, but already usable. I would be glad to get feedback about it (GUI, features, etc.). Due to the issues mentioned above some values may seem weird, but they are just displayed correctly as there is a network-byte-order to host-byte-order conversion that the current gimps implementation lacks of. Henning PS: Because this is my first posting to this mailing list and probably most of you do not know me, yet: I am a bachelor student at University of Göttingen in 4th semester and interested in computer networks. As time allows, I will try to contribute to the NSIS effort. I am in close contact with Christian as we share some courses with each other. PETERS Henning Reitstallstrasse 2 37073 Goettingen GERMANY +49 551 8207631 +49 163 5812105 (mobile)

1 0

gimps fsm draft new 2-peer model
by Tseno Tsenov 16 May '05

16 May '05

Hi, After todays discussion with Andy and Christian, we have new versions of the FSM adopting the 2-peer model. Current version try to cover the case of C_mode upgrade (see more datails into the files). We identified it as an open issue which is not discussed in the gimps-draft. Xiaoming, what are the next steps if we want to have a fsm-draft version for the interim meeting? Greetings, tseno_ Original Message: Hi, I hope its not to late, but I think I found another issue. FSM at querying node, state WaitResponse. There should be an eventhandling for tg_SendMsg. Am I wrong? Christian > -----Original Message----- > From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de] > Sent: Tuesday, May 10, 2005 4:52 PM > To: fu(a)cs.uni-goettingen.de; Tschofenig Hannes > Cc: Christian Dickmann > Subject: Re: gimps fsm > > > Hi all, > > I have reviewed the diagrams of the fsms of the prototype and discussed > them with Christian. > I worked on the update version of the FSMs based on 2-peers model. > Pls. find attached the visio files. Hopefully we can discuss it soon. > > greetings, > tseno_ > > > > Original Message: > > hi tseno, hi hannes > > christian has made some suggestions for updating the state machine > (to 2 > types of entities only) and implemented in the prototype. please > take a > look and comment. hannes - is it that the submission of update IDs > needs > to be done this week for being able to discuss in interim meeting? > > xiaoming > > > -- > Tseno V. Tsenov > MSCE, Technical University of Munich > > cell: +49 177 5964625 > e-mail: tseno.tsenov(a)mytum.de -- Tseno V. Tsenov MSCE, Technical University of Munich cell: +49 177 5964625 e-mail: tseno.tsenov(a)mytum.de

6 18

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp May 2005