1 / 6

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

GIMPS State machine draft-fu-nsis-ntlp-statemachine-01.txt. Xiaoming Fu, Tseno Tsenov, Hannes Tschofenig, Cedric Aoun, Elwyn Davies. 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

kyle-freeman
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 IETF 62nd March 2005

  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 IETF 62nd March 2005

  4. 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

  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 IETF 62nd March 2005

  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 editor’s queue • PANA: draft-ohba-pana-statemachine-01 IETF 62nd March 2005

More Related