IETF 62nd March 2005

GIMPS State machinedraft-fu-nsis-ntlp-statemachine-01.txt

Xiaoming Fu, Tseno Tsenov, Hannes Tschofenig, Cedric Aoun,

Elwyn Davies

IETF 62nd March 2005

Why do we need to document it?

• Two main goals: Short term: Specification needs to be validated 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 62nd March 2005

State machine modeling and representation

• Two modeling paradigms: 1 - Signaling initiator, intermediary and responder 2 - Query node and responder node

Case 1 works but appears to be unnecessarily complex seems to be appropriate to the NSLPs.

The next version of the GIMPS state machine will document use paradigm 2

• Current representation aspects: The FSM handles GIMPS messages that match a Message

Routing State's MRI and NSLPID No protocol errors are currently handled Not all objects included in a message are shown

Only those that are significant for the case are shown

IETF 62nd March 2005

GIMPS state machine - open issues

• Lost Confirm message - elaborated in <draft-ietf-nsis-ntlp-05.txt> No retransmission of Response message in general 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 Needs to cover periodic refresh of MA

• Last node is assumed to be the flow receiver 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 disallowing piggybacking if query-cookie is desired and used

IETF 62nd 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: Roke Manor/Siemens NEC Open source project: CLEO (INT-GET/Goettingen) Elwyn Davies

IETF 62nd March 2005

Next steps

• Is this document useful?

• Should this document become a WG document towards an informational RFC? 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