GIMPS State machine draftfunsisntlpstatemachine01 txt Xiaoming Fu Tsenov

GIMPS State machine draft-fu-nsis-ntlp-statemachine-01. txt Xiaoming Fu, Tsenov, Hannes Tschofenig, Cedric Aoun, Elwyn Davies IETF 62 nd March 2005

Why do we need to document it? • Two main goals: w Short term: Specification needs to be validated w Long term: future implementors need to be guided • The proposed state machine provides a reference model and should not be seen as a mandatory state machine modeling IETF 62 nd March 2005

State machine modeling and representation • Two modeling paradigms: § 1 - Signaling initiator, intermediary and responder § 2 - Query node and responder node w Case 1 works but appears to be unnecessarily complex § seems to be appropriate to the NSLPs. w The next version of the GIMPS state machine will document use paradigm 2 • Current representation aspects: w The FSM handles GIMPS messages that match a Message Routing State's MRI and NSLPID w No protocol errors are currently handled w Not all objects included in a message are shown § Only those that are significant for the case are shown IETF 62 nd March 2005

GIMPS state machine - open issues • Lost Confirm message - elaborated in <draft-ietf-nsis-ntlp-05. txt> w No retransmission of Response message in general w Retransmission of the lost Confirm message (the loss detected at the reception of the first signaling message after the loss) • Separate FSM for the MA might be useful w Needs to cover periodic refresh of MA • Last node is assumed to be the flow receiver w FSM extensions would be required in the current model but not in model 2) • Piggybacking of NSLP data in Query message - interaction with Query/Response cookies handshake procedure w disallowing piggybacking if query-cookie is desired and used IETF 62 nd March 2005

Next steps • Simplify the overall state machine to Query node and Responder node state machines • Add the MA state machine • Add data structure definition and relations • Validate the reference state machine model with the currently known NTLP implementations: w Roke Manor/Siemens w NEC w Open source project: CLEO (INT-GET/Goettingen) w Elwyn Davies IETF 62 nd March 2005

Next steps • Is this document useful? • Should this document become a WG document towards an informational RFC? w Protocol state machine documents have proven to be very useful for implementors as API description and high level FSM description in the protocol specification documents are not sufficient: § LDAP State machine: RFC 3215 § EAP: draft-ietf-eap-statemachine-06. txt currently in RFC editor’s queue § PANA: draft-ohba-pana-statemachine-01 IETF 62 nd March 2005