GIMPS State machine draft-fu-nsis-ntlp-statemachine-01.txt

1
GIMPS State machinedraft-fu-nsis-ntlp-statemachin
e-01.txt

• Xiaoming Fu, Tseno Tsenov, Hannes Tschofenig,
  Cedric Aoun, Elwyn Davies

2
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

3
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

4
GIMPS state machine - open issues

• Lost Confirm message - elaborated in
  ltdraft-ietf-nsis-ntlp-05.txtgt
• 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

5
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

6
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 editors queue
• PANA draft-ohba-pana-statemachine-01