Nsis_Imp January 2005

nsis_imp@informatik.uni-goettingen.de

12 participants
19 discussions

web page recent changes
by Bernd Schloer 04 Mar '05

04 Mar '05

Also this mail might be lost: Hi list, please note the button 'recent changes' http://cleo-project.org/browse/recent_changes.html on cleo-project.org. This is a good entry to the web page as you see here what's going on and where progress was made. bye, Bernd

6 19

[Fwd: [NSIS_FSM] a "tutorial" to NSIS/GIMPS]
by Xiaoming Fu 19 Feb '05

19 Feb '05

sorry to all@cleo: was sent to a wrong list -------- Original Message -------- Subject: [NSIS_FSM] a "tutorial" to NSIS/GIMPS Date: Tue, 25 Jan 2005 17:34:34 +0100 From: Xiaoming Fu <fu(a)cs.uni-goettingen.de> Reply-To: NSIS FSM discussion mailing list <nsis_fsm(a)informatik.uni-goettingen.de> To: NSIS FSM discussion mailing list <nsis_fsm(a)informatik.uni-goettingen.de> Hi all, Please find attached a "tutorial" I made for the convenience of NSIS newbies in the cleo team to understand a bit about GIMPS basic operation and its background. Note this is only meant for CLEO, not elsewhere: please keep it confidentially! HT/CA/Tseno/SW: you may point out any incorrect or better info to me (and certainly we can update it). If you have any questions to the information (esp. "routine"), feel free to ask us. BTW - I am away this Thursday and Friday again Xiaoming _______________________________________________ Nsis_fsm mailing list Nsis_fsm(a)informatik.uni-goettingen.de http://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_fsm

2 4

AW: [Nsis_imp] Meeting Minutes
by Tschofenig Hannes 22 Jan '05

22 Jan '05

hi sebastian, here they are - copied from jabber. ciao hannes > -----Ursprüngliche Nachricht----- > Von: Sebastian Willert [mailto:willert@gmail.com] > Gesendet: Samstag, 22. Januar 2005 18:48 > An: Cleo Project > Betreff: [Nsis_imp] Meeting Minutes > > > Hi all, > > can someone please post the meeting minutes to cleo-project.org? > > Thanks, > Sebastian > > _______________________________________________ > Nsis_imp mailing list > Nsis_imp(a)informatik.uni-goettingen.de > http://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp >

1 0

Meeting Minutes
by Sebastian Willert 22 Jan '05

22 Jan '05

Hi all, can someone please post the meeting minutes to cleo-project.org? Thanks, Sebastian

1 0

GIMPS ping client
by Bernd Schloer 21 Jan '05

21 Jan '05

Hi, can someone of you start programming a simple ping client?

1 0

web page & jabber meetings
by Bernd Schloer 19 Jan '05

19 Jan '05

Hi list, some of you didn't get this mail because my mail-client used a wrong date. sorry for this ! bye, Bernd Hi list, a new WiKi to collect links is added to the web page. It will be linked to a button soon. http://cleo-project.org/?LinkList Please post your links here so other can also access them. And please add your files like pdf,.. to http://cleo-project.org/?FileBase I suggest that we're meeting every Thursday 14:00 in the jabber room cleo-project.org(a)private.jabber.org A personal meeting (1-2 developer(s) and me) should also be held once a week. bye, Bernd

1 0

XORP state machines
by Elwyn Davies 19 Jan '05

19 Jan '05

Hi. As promised I had a look at the XORP implementation of the BGP state machine. It is actually a straightforward implementation of a state machine class such as i have seen many times before. A class is defined to hold all the state associated with each instance of the state machine. In BGP this is tied to a peer and a socket connection, but that wouldn't be the case exactly in GIMPS. The class data contains references for all the associated timers as well as the actual state variable. The possible states and events are defined as enumerated types and there is an event handler routine for each possible event.. these routines are then called in line from appropriate parts of the code. The incoming messages are handled by linking a callback to the socket that receives them... likewise timers are created when the peer enters the correct state and the timer events are linked back to the state machine by callbacks. The actions on state transition are handled by a central set_state transition routine: the routine is relatively simple in this case because there are relatively few transitions. The structure would (IMHO) work pretty well for GIMPS and would not require much effort.. The main difference is that the socket message processing would have to be separated and a look up done to determine the right state machine instance to activate depending on the traffic descriptor, rther then the sockets being tied one to one to the peer and state machine. The main problem for the future is handling the source/middle/end distinction between state machines nicely because each node is quite likely to have some of each. However this is just an opportunity for neat design rather than a serious issue. I am checking the state machine diagrams next and will make a start on some implementation shortly. Regards, Elwyn

1 0

router alert option: way of IANA registry
by Xiaoming Fu 18 Jan '05

18 Jan '05

http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue4 This issue involves with Query message encapsulation and processing. The question is, whether it should be pre-assigned as Per-NSLPtype (for example, for QoS NSLP ), or more coarse-grained, Previously, router alert option 0 is used for per-flow RSVP & IGMPv2 processing, 1 is used for aggregated RSVP processing. RSVP uses a new IP protocol number 46 (aggregated RSVP 134). My suggestion is - Use one undefined UDP port number as standard port for GIMPS query requests for any given NSLP, and (if we need,) use another for non-NSLP related GIMPS query messages. - Follow per-NSLPtype way as in RSVP, namely: when a packet with GIMPS-(pre-)allocated RAO value arrives, a GIMPS node processes it and afterwards, depending on 1) GIMPS semantics - whether to forward or not; 2) follow the IP routing table max-prefix match to send it onwards. At least for the implementation for March. Any suggestion? Or we should send a mail to Henning/Robert and/or the WG. Xiaoming

3 2

Re: [Nsis_imp] gimps_prototype.vsd
by Xiaoming Fu 18 Jan '05

18 Jan '05

Please find attached both PDF & vsd version (with some minor changes). There might be some finer-grained way for "message processing" and better way of presenting "event handling", it's up for you folks - Xiaoming Bernd Schloer wrote: > >> sorry - timer event should be also handled there (should be simpler >> than "message processing" block - typically refresh or remove of a >> corresponding state and/or send a refresh message). See update > > > Could you please provide this gimps_prototype.vsd also as pdf?

3 3

gimps_prototype.vsd
by Xiaoming Fu 13 Jan '05

13 Jan '05

sorry - timer event should be also handled there (should be simpler than "message processing" block - typically refresh or remove of a corresponding state and/or send a refresh message). See update

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp January 2005