NSIS T. Tsenov
Internet-Draft H. Tschofenig
Intended status: Informational Nokia Siemens Networks
Expires: August 10, 2010 X. Fu
Univ. Goettingen
C. Aoun
E. Davies
Folly Consulting
February 10, 2010
GIST State Machine
draft-ietf-nsis-ntlp-statemachine-09.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 10, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Tsenov, et al. Expires August 10, 2010 [Page 1]
Internet-Draft GIST State Machine February 2010
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
This document describes the state machines for the General Internet
Signaling Transport (GIST). The states of GIST nodes for a given flow
and their transitions are presented in order to illustrate how GIST
may be implemented.
Tsenov, et al. Expires August 10, 2010 [Page 2]
Internet-Draft GIST State Machine February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Notational conventions used in state diagrams . . . . . . . 4
4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 6
5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8
5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 10
6. State machines . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 12
6.2 State machine for GIST querying node . . . . . . . . . . . 12
6.3 State machine for GIST responding node . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1 Normative References . . . . . . . . . . . . . . . . . . 19
11.2 Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. ASCII versions of the state diagrams . . . . . . . . 20
A.1 State machine for GIST querying node (Figure 2) . . . . 20
A.2 State Machine for GIST responding node (Figure 3) . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
Tsenov, et al. Expires August 10, 2010 [Page 3]
Internet-Draft GIST State Machine February 2010
1. Introduction
The state machines described in this document are illustrative of how
the GIST protocol defined in [1] may be implemented for the GIST
nodes in different locations of a flow path. Where there are
differences - [1] is authoritative. The state machines are
informative only. Implementations may achieve the same results using
different methods.
There are two types of possible entities for GIST signaling:
- GIST querying node - GIST node that initiates the discovery of the
next peer;
- GIST responding node - GIST node that is the discovered next peer;
We describe a set of state machines for these entities to illustrate
how GIST may be implemented.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
3. Notational conventions used in state diagrams
The following text is reused from [3] and the state diagrams are
based on the conventions specified in [4], Section 8.2.1. Additional
state machine details are taken from [5].
The complete text is reproduced here:
State diagrams are used to represent the operation of the protocol by
a number of cooperating state machines each comprising a group of
connected, mutually exclusive states. Only one state of each machine
can be active at any given time.
All permissible transitions between states are represented by arrows,
the arrowhead denoting the direction of the possible transition.
Labels attached to arrows denote the condition(s) that must be met in
order for the transition to take place. All conditions are
expressions that evaluate to TRUE or FALSE; if a condition evaluates
to TRUE, then the condition is met. The label UCT denotes an
unconditional transition (i.e., UCT always evaluates to TRUE). A
transition that is global in nature (i.e., a transition that occurs
from any of the possible states if the condition attached to the
arrow is met) is denoted by an open arrow; i.e., no specific state is
Tsenov, et al. Expires August 10, 2010 [Page 4]
Internet-Draft GIST State Machine February 2010
identified as the origin of the transition. When the condition
associated with a global transition is met, it supersedes all other
exit conditions including UCT. The special global condition BEGIN
supersedes all other global conditions, and once asserted remains
asserted until all state blocks have executed to the point that
variable assignments and other consequences of their execution remain
unchanged.
On entry to a state, the procedures defined for the state (if any)
are executed exactly once, in the order that they appear on the page.
Each action is deemed to be atomic; i.e., execution of a procedure
completes before the next sequential procedure starts to execute. No
procedures execute outside of a state block. The procedures in only
one state block execute at a time, even if the conditions for
execution of state blocks in different state machines are satisfied,
and all procedures in an executing state block complete execution
before the transition to and execution of any other state block
occurs, i.e., the execution of any state block appears to be atomic
with respect to the execution of any other state block and the
transition condition to that state from the previous state is TRUE
when execution commences. The order of execution of state blocks in
different state machines is undefined except as constrained by their
transition conditions. A variable that is set to a particular value
in a state block retains this value until a subsequent state block
executes a procedure that modifies the value.
On completion of all of the procedures within a state, all exit
conditions for the state (including all conditions associated with
global transitions) are evaluated continuously until one of the
conditions is met. The label ELSE denotes a transition that occurs
if none of the other conditions for transitions from the state are
met (i.e., ELSE evaluates to TRUE if all other possible exit
conditions from the state evaluate to FALSE). Where two or more exit
conditions with the same level of precedence become TRUE
simultaneously, the choice as to which exit condition causes the
state transition to take place is arbitrary.
In addition to the above notation, there are a couple of
clarifications specific to this document. First, all boolean
variables are initialized to FALSE before the state machine execution
begins. Second, the following notational shorthand is specific to
this document:
<variable> = <expression1> | <expression2> | ...
Execution of a statement of this form will result in <variable>
having a value of exactly one of the expressions. The logic for
which of those expressions gets executed is outside of the state
Tsenov, et al. Expires August 10, 2010 [Page 5]
Internet-Draft GIST State Machine February 2010
machine and could be environmental, configurable, or based on
another state machine such as that of the method.
4. State Machine Symbols
( )
Used to force the precedence of operators in Boolean expressions
and to delimit the argument(s) of actions within state boxes.
;
Used as a terminating delimiter for actions within state boxes.
Where a state box contains multiple actions, the order of
execution follows the normal English language conventions for
reading text.
=
Assignment action. The value of the expression to the right of
the operator is assigned to the variable to the left of the
operator. Where this operator is used to define multiple
assignments, e.g., a = b = X the action causes the value of the
expression following the right-most assignment operator to be
assigned to all of the variables that appear to the left of the
right-most assignment operator.
!
Logical NOT operator.
&&
Logical AND operator.
||
Logical OR operator.
if...then...
Conditional action. If the Boolean expression following the if
evaluates to TRUE, then the action following the then is executed.
{ statement 1, ... statement N }
Compound statement. Braces are used to group statements that are
executed together as if they were a single statement.
!=
Inequality. Evaluates to TRUE if the expression to the left of
the operator is not equal in value to the expression to the right.
==
Equality. Evaluates to TRUE if the expression to the left of the
operator is equal in value to the expression to the right.
Tsenov, et al. Expires August 10, 2010 [Page 6]
Internet-Draft GIST State Machine February 2010
>
Greater than. Evaluates to TRUE if the value of the expression to
the left of the operator is greater than the value of the
expression to the right.
<=
Less than or equal to. Evaluates to TRUE if the value of the
expression to the left of the operator is either less than or
equal to the value of the expression to the right.
++
Increment the preceding integer operator by 1.
+
Arithmetic addition operator.
&
Bitwise AND operator.
5. Common Rules
Throughout the document we use terms defined in the [1], such as
Query, Response, Confirm.
State machine represents handling of GIST messages that match a
Message Routing State's MRI, NSLPID and SID and with no protocol
errors. Separate parallel instances of the state machines should
handle messages for different Message Routing States.
The state machine states represent the upstream/downstream peers
states of the Message Routing State.
For simplification not all objects included in a message are shown.
Only those that are significant for the case are shown. State
machines do not present handling of messages that are not significant
for management of the states.
Presented in this document state machines do not cover all functions
of a GIST node. Functionality of message forwarding, transmission of
NSLP data without MRS establishment and providing of the received
messages to the appropriate MRS, we refer as "Lower level pre-
processing" step. Pre-processing provides to the appropriate MRS FSM
only the messages which are matched against waiting Query/Response
cookies, or established MRS MRI+NSLPID+SID primary key. This is
presented by "rx_*" events in the state machines.
Management of a MA is considered in the document (e.g.,
tg_Establish_MA, tg_MA_established events), but its FSM is not
Tsenov, et al. Expires August 10, 2010 [Page 7]
Internet-Draft GIST State Machine February 2010
explicitly presented.
5.1 Common Procedures
Tg_SendMsg:
NSLP/GIST API message that request transmission of a NSLP message.
Tg_SetStateLifetime(time_period):
NSLP/GIST API message providing info for the Lifetime of an RS,
required by the application. "Time_period = 0" represents the
cancellation of established RSs/MAs (invoked by NSLP application).
Tg_MessageStatus:
NSLP/GIST API message informing NSLP application of unsuccessful
delivery of a message
Tg_RecvMsg:
NSLP/GIST API message that provides received message to the NSLP
Tg_NetworkNotification:
NSLP/GIST API message that informs NSLP for change in MRS
Tx_Query:
Transmit of Query message
Tx_Response:
Transmit of Response message
Tx_Confirm:
Transmit of Confirm message
Rx_Query:
Receive of Query message
Rx_Response:
Receive of Response message
Rx_Confirm:
Receive of Confirm message
Tx_Error:
Transmit of Error message
Rx_Error:
Receive of Error message
Queue NSLP info:
Save NLSP messages in a queue until a required MA association is
Tsenov, et al. Expires August 10, 2010 [Page 8]
Internet-Draft GIST State Machine February 2010
established
Tx_Data:
Transmit of Data message
Rx_Data:
Receive of Data message
T_Inactive_QNode:
Message Routing State lifetime timer in Querying Node
T_Expired_RNode:
Message Routing State lifetime timer in Responding Node
T_Refresh_QNode:
Message Routing State refresh timer in Querying Node
T_No_Response:
Timer for the waiting period for Response message in Querying Node
T_No_Confirm:
Timer for the waiting period for Confirm message in Responding
Node
Install downstream/upstream MRS:
Install new Message Routing State and save the corespoding peer
state info (IP address and UDP port or pointer to the used MA) for
the current Message Routing State or update the coresponding peer
state info.
DELETE MRS:
Delete installed downstream/upstream peer's info for the current
Message Routing State and delete the Message Routing State if
required.
Established MA:
A Message Association (MA) is established between the current node
and its upstream peer. The initiator for the establishment is the
upstream peer.
Re-use existing MA:
An existing MA between the current node and its peer is re-used.
DELETE MA:
Delete/disconnect used MA.
Stop using shared MA:
Stop using shared MA. If the shared MA is no more used by any
Tsenov, et al. Expires August 10, 2010 [Page 9]
Internet-Draft GIST State Machine February 2010
other MRSs, it depends on the local policy whether it is deleted
or kept.
REFRESH MRS:
Refreshes installed MRS.
Tg_MA_Error:
Error event with used MA.
Tg_InvalidRoutingState:
Notification from NSLP application for path change
Tg_Establish_MA:
Trigers establishment of MA.
Tg_MA_Established:
MA has been successfully established.
Tg_ERROR:
General Error event / system level error.
No_MRS_Installed:
Error response, send by the Responding node indicating lost
Confirm message.
5.2 Common Variables
It is assumed that the type of mode and destination info (which need
to be taken from the application parameters and local GIST policy)is
provided. This is represented by the common variables Dmode, Cmode,
MAinfo, MApresent and Refresh.
Cmode:
The message MUST be transmitted in Cmode. This is specified by
"Message transfer attributes" set to any of the following values:
"Reliability" is set to TRUE.
"Security" is set to values that request secure handling of a
message.
"Local processing" is set to values that require services offered
by Cmode (e.g., congestion control). [1]
Dmode:
The message MUST be transmitted in Dmode. This is specified by
local policy rules and in case that the "Message transfer
attributes" are not set to any of the following values:
Tsenov, et al. Expires August 10, 2010 [Page 10]
Internet-Draft GIST State Machine February 2010
"Reliability" is set to TRUE.
"Security" is set to values that request special security handling
of a message.
"Local processing" is set to values that require services offered
by Cmode [1]
MAinfo:
GIST message parameters describing the required MA or proposed MA
e.g. "Stack-proposal" and "Stack-Configuration-Data".
NSLPdata:
NSLP application data.
RespCookie:
Responder Cookie that is being sent by the Responding node with
the Response message in case that its local policy requires a
confirmation from the querying node.
ConfirmRequired:
Confirm message is required by the local policy rule for
installation of the new MRS.
NewPeer:
Response message is received from new responding peer.
MAexist:
Existing MA will be reused.
CheckPeerInfo:
The sender of the received data message is matched against the
installed peer info in the MRS.
UpstreamPeerInstalled:
Upstream peer info is installed in the MRS.
Tsenov, et al. Expires August 10, 2010 [Page 11]
Internet-Draft GIST State Machine February 2010
6. State machines
The following section presents the state machine diagrams of GIST
peers.
6.1 Diagram notations
+--------------------------------+
| STATE |
+--------------+-----------------+
|
|
ooooo
o N o Transition N
ooooo
|
v
+--------------------------------+
| STATE |
+--------------------------------+
Figure 1: Diagram notations
6.2 State machine for GIST querying node
GIST querying node state machine diagram is depicted bellow.
Transition description follows.
For .txt version, please refer to Appendix A.1 for complete
transition details (triggering event, action taken and variables
status).
Tsenov, et al. Expires August 10, 2010 [Page 12]
Internet-Draft GIST State Machine February 2010
+-----------+ ooooo
| Any State +----------o 18 o
+-----------+ ooooo
|
v
+-----------------------------------------------------------------+
| IDLE |
+--+--------------------------------------------------------------+
| ^ ^ ^
| | | |
ooooo ooooo ooooo ooooo ooooo | |
o 1 o o 2 o +o 3 o+ +o 4 o+ +o 5 o+ | |
ooooo ooooo | ooooo | | ooooo | | ooooo | | |
| | | | | | | | | |
v | | v | v | v | |
+-----------+-----+----------+----------+--------+ | |
| Wait Response | | |
+--+-------------------------------------+-------+ | |
| ^ | | |
| | | | |
ooooo | ooooo ooooo ooooo |
o 6 o | +o 5 o+ o 7 o o 8 o |
ooooo | | ooooo | ooooo ooooo |
| | | | | | |
| | | v v | |
| | +----+-------------------------------+---+ |
| | | Wait MA Establishment | |
| | +------------------------------+---------+ |
| | ^ | |
| | | | |
| ooooo ooooo ooooo ooooo ooooo
| o 9 o o 11 o +o 13 o+ o 12 o o 10 o
| ooooo ooooo | ooooo | ooooo ooooo
| | | | | | |
v | | | v v |
+----------+----------+--------+------------------------------+---+
| Established Downstream MRS |
+--+-----------+-----------+-----------+-----------+--------------+
| ^ | ^ | ^ | ^ | ^
| | | | | | | | | |
| ooooo | | ooooo | | ooooo | | ooooo | | ooooo |
+o 16 o+ +o 14 o+ +o 15 o+ +o 4 o+ +o 17 o+
ooooo ooooo ooooo ooooo ooooo
Figure 1: GIST Querying Node State Machine
1**) Initial request from NSLP application is received, which
triggers Query messages requesting either D_mode or C_mode.
Tsenov, et al. Expires August 10, 2010 [Page 13]
Internet-Draft GIST State Machine February 2010
Depending on nodes local policy NSLP data might be piggybacked in
the Query requesting D_mode. Query may carry MAinfo if C_mode
transport is needed.
2) No_Response timer expires and maximum number of retries has been
reached. NSLP application is notified for the GIST peer discovery
failure.
3) No_Response timer expires. Query is resent.
4) Data message is received. It is checked if its sender matches the
installed downstream peer info in the MRS and then processed. In
WaitResponse state, this event might happen in the process of MA
upgrade, when the downstream peer is still not aware of
establishment of the new MA.
5) NSLP application requests sending data. NSLP data is queued,
because downstream peer is not discovered or required MA is still
not established.
6) Response message is received. If D_mode connection is requested or
available MA can be reused for requested C_mode, the MRS is
established.
7*) Response message is received. If C_mode connection must be
established and there is no available MA to be reused, MA
establishment is initiated and waited to be completed.
8) MA establishment failure. NSLP application is notified for
unsuccessful message delivery.
9) NSLP application requests sending data and requested transport
parameters require upgrade of established MRS from D_mode/C_mode
to C_mode. Or NSLP application notifies GIST for path change.
Downstream GIST peer discovery is initiated.
10) MRS lifetime expires or NSLP application notifies that MRS is no
longer needed. MRS is deleted. If not needed, MA is deleted, too.
NSLP application is notified for MRS change.
11*) Path change detected. Response message from a new downstream
GIST peer is received. A new MA must be established for requested
C_mode.
12*) MA is established. MRS is installed. Queued NSLP data is sent.
13) Refresh_QNode timer expires. Query message is sent.
14) NSLP application provides data for sending. It is sent via Data
message towards downstream GIST peer.
15) Response message from the downstream GIST peer is received. The
peer is not changed. MRS is refreshed (Refresh_QNode timer is
restarted).
16) Path change detected. Response message from a new downstream GIST
peer is received. D_mode is requested or existing MA can be reused
for requested C_mode.
17) Sent Confirm message has not been received by downstream GIST
peer. Confirm message is resent.
18) General error or system level error occurs. MRS is deleted. If
not needed, MA is deleted, too. NSLP application is notified for
MRS change.
Tsenov, et al. Expires August 10, 2010 [Page 14]
Internet-Draft GIST State Machine February 2010
Remarks:
*) Response and Comfirm messages might be sent either in Dmode or
Cmode, before or after MA establishment depending on node's local
3-way handshake policy and the availability of MAs to be reused. See
draft for details.
**) Depending on the local policy NSLPdata might be send as payload
of Query and Confirm messages (piggybacking).
6.3 State machine for GIST responding node
GIST responding node state machine diagram is depicted bellow.
Transition description follows.
For .txt version, please refer to Appendix A.2 for complete
transition details (triggering event, action taken and variables
status).
Tsenov, et al. Expires August 10, 2010 [Page 15]
Internet-Draft GIST State Machine February 2010
+-----------+ ooooo
| Any State +----------o 13 o
+-----------+ ooooo
|
v
+-----------------------------------------------------------------+
| IDLE |
+--+-------------------------------+------------------------------+
| ^ | ^
| | | |
ooooo | ooooo ooooo ooooo
o 1 o | o 2 o +o 4 o+ o 3 o
ooooo | ooooo | ooooo | ooooo
| | | | | |
| | v | v |
| | +--------------------+---------------+---+
| | | Wait Confirm |
| | +---------+------------------+-----------+
| | | ^ | ^
| | | | | |
| ooooo ooooo ooooo ooooo | ooooo |
| +o 5 o+ o 8 o o 5 o o 7 o +o 6 o+
| | ooooo | ooooo ooooo ooooo ooooo
| | | | | |
v | v | v |
+------+-------------+------------------------+-------------------+
| Established Upstream MRS |
+------+-------------+-------------+------------+-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| ooooo | | ooooo | | ooooo | | ooooo |
+o 9 o+ +o 11 o+ +o 12 o+ +o 10 o+
ooooo ooooo ooooo ooooo
Figure 3: GIST Responding Node State Machine
1) A Query message is received. MRS is installed immediately, based
on the local policy. Query message might carry piggybacked NSLP
data which is provided to the NSLP application.
2) A Query message is received. Explicit Confirm message is required
for MRS installation, based on the local policy. Query message
might carry piggybacked NSLP data which is provided to the NSLP
application.
3) No_Confirm timer expires. Note that all cases of lost handshake
GIST messages are handled only by GIST querying node via resend of
Query message.
4) A Query message is received again. This means that sent Response
message has not been received by upstream GIST peer. Response
Tsenov, et al. Expires August 10, 2010 [Page 16]
Internet-Draft GIST State Machine February 2010
message is resent.
5) Confirm message is received which causes installation of the
complete MRS or just installation of the used MA as a upstream
peer info.
6) In case of lost Confirm message, data messages might be received
from the upstream GIST node (it is unaware of the lost Confirm
message). Response indicating the loss of the Confirm is sent back
to the upstream GIST node.
7) A Query message is received with request for change of the used
connection mode (from D_mode/C_mode to better C_mode) or from new
upstream GIST node. Local policy requires explicit Confirm message
for MRS installation.
8) MRS lifetime expires or NSLP application notifies that MRS is no
longer needed. MRS is deleted. If used and not needed, MA is
deleted, too. NSLP application is notified for MRS change.
9) Data for sending is received from NSLP application. NSLP data is
sent if discovery process is successfully accomplished or is
queued if Confirm message is still expected to confirm
establishment of MA.
10) A Query message is received. If it is sent from new upstream GIST
node there is path change. Local policy does not need explicit
Confirm message for MRS installation. MRS data is updated.
11) A Query message is received with request for change of the used
connection mode (from D_mode/C_mode to better C_mode). Local
policy does not need explicit Confirm message for MRS
installation. MRS data is updated.
12) A Data message is received. Data messages are accepted only if
complete MRS is installed, e.g., there is installed upstream peer
info. If not, then Confirm message is expected and data message
wont be accepted. Response indicating the loss of the Confirm is
sent back to the upstream GIST node.
13) General error or system level error occurs. MRS is deleted. If
not needed, MA is deleted, too. NSLP application is notified for
MRS change.
7. Security Considerations
This document does not raise new security considerations. Any
security concerns with GIST are likely reflected in security related
NSIS work already (such as [1] or [6]).
8. IANA Considerations
This document has no actions for IANA.
9. Contributors
Christian Dickmann contributed to refining of the state machine since
Tsenov, et al. Expires August 10, 2010 [Page 17]
Internet-Draft GIST State Machine February 2010
01 version.
10. Acknowledgments
The authors would like to thank Robert Hancock, Ingo Juchem, Andreas
Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd
Schloer for their insightful comments.
Tsenov, et al. Expires August 10, 2010 [Page 18]
Internet-Draft GIST State Machine February 2010
11. References
11.1. Normative References
[1] Schulzrinne, H., "GIST: General Internet Signaling
Transport", draft-ietf-nsis-ntlp-20 (work in progress),
December 2009.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC4137, August 2005.
[4] Institute of Electrical and Electronics Engineers,
"Standard for Local and Metropolitan Area Networks: Port-
Based Network Access Control", IEEE 802-1X-2004, December
2004.
[5] Fajardo, V., Ohba, Y. and R. Marin-Lopez, "State Machines
for Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5609, August 2009.
[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for
NSIS", RFC 4081, June 2005.
Tsenov, et al. Expires August 10, 2010 [Page 19]
Internet-Draft GIST State Machine February 2010
Appendix A. ASCII versions of state diagrams
This appendix contains the state diagrams in ASCII format. Please
use the PDF version whenever possible: it is much easier to
understand.
For each state there is a separate table that lists in each row:
- an event that triggers a transition,
- actions taken as a result of the incoming event,
- and the new state at which the transitions ends.
A.1. State machine for GIST querying node (Figure 2)
-----------
State: IDLE
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
1) |tg_SendMsg |tx_Query |Wait
** | |start T_No_Response |Response
| |Queue NSLP data |
| | |
18)|Tg_ERROR |Delete MRS |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------
-----------
State: WaitResponse
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
2) |(timeout T_No_Response) |tg_MessageStatus |IDLE
|&&(MaxRetry) | |
| | |
3) |(timeout T_No_Response) |Tx_Query |Wait
|&&(!MaxRetry) |restart T_No_Response |Response
| | |
4) |rx_Data |IF(CheckPeerInfo) |Wait
| | tg_RecvMsg to Appl.|Response
Tsenov, et al. Expires August 10, 2010 [Page 20]
Internet-Draft GIST State Machine February 2010
| | |
5) |tg_SendMsg |Queue NSLP data |Wait
| | |Response
| | |
6) |rx_Response)|| |Install MRS |Established
|(rx_Response(MAinfo)&& |IF (RespCookie) |Downstream
|(MAexist)) | tx_Confirm(RespCookie)|MRS
| |tx_Data(Queued NSLP data)|
| | |
7) |rx_Response(MAinfo)&& |tg_Establish_MA |Wait MA
* |(!MAexist) |(tx_Confirm) |Establish.
| | |
| | |
18)|Tg_ERROR |(Delete MRS) |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------
-----------
State: Established Downstream MRS
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
4) |rx_Data |IF(CheckPeerInfo) |Established
| | tg_RecvMsg to Appl.|Downstream
| | |MRS
| | |
9) |((tg_SendMsg)&&(Cmode)&&|tx_Query |Wait
|(!MAexist))|| |Queue NSLP data |Response
|(tg_MA_error)|| | |
|(tg_InvalidRoutingState)| |
| | |
10)|(timeout T_Inactive_ |Delete MRS |IDLE
| QNode)|||IF (MA is used) |
|(tg_SetStateLifetime(0))| (Delete MA)|| |
| | (Stop using shared MA)|
| |Tg_NetworkNotification |
| | |
11)|(rx_Response(MAinfo)&& |((Delete MA)|| |Wait MA
* |(NewPeer)&&(!MA_exist)) |(Stop using shared MA)) |Establish.
Tsenov, et al. Expires August 10, 2010 [Page 21]
Internet-Draft GIST State Machine February 2010
| |tg_Establish_MA |
| |(tx_Confirm) |
| | |
13)|timeout T_Refresh_QNode |tx_Query |Established
| | |Downstream
| | |MRS
| | |
14)|tg_SendMsg |tx_Data |Established
| |restart T_Inactive_QNode |Downstream
| | |MRS
| | |
15)|(rx_Response)&& |Refresh MRS |Established
|(!NewPeer) |restart T_Inactive_QNode |Downstream
| | |MRS
| | |
16)|(rx_Response)|| |IF (MA is used) |Established
|(rx_Response(Mainfo)&& | (Delete MA)|| |Downstream
|(MAexist)))&&(NewPeer) | (Stop using shared MA)|MRS
| |Install MRS |
| |restart T_Inactive_QNode |
| |IF (RespCookie) |
| | tx_Confirm(RespCookie)|
| | |
17)|rx_Response(No_MRS_ |tx_Confirm(RespCookie) |Established
| installed)|tx_Data(Queued NSLP data)|Downstream
| | |MRS
| | |
18)|Tg_ERROR |(Delete MRS) |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------
-----------
State: Wait MA Establishment
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
5) |tg_SendMsg |Queue NSLP data |Wait MA
| | |Establish.
| | |
8) |tg_MA_error |Delete MRS |IDLE
| |tg_MessageStatus |
Tsenov, et al. Expires August 10, 2010 [Page 22]
Internet-Draft GIST State Machine February 2010
| | |
12)|tg_MA_Established |Install MRS |Established
* | |(tx_Confirm) |Downstream
| |tx_Data(Queued NSLP data)|MRS
| | |
18)|Tg_ERROR |Delete MRS |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------
Figure 4
A.2. State Machine for GIST responding node (Figure 3)
-----------
State: IDLE
-----------
+Transition
| |Condition |Action |State
v--+------------------------+-------------------------+-----------
1) |rx_Query&& |tx_Response |Established
|(!ConfirmRequired) |Install MRS |Upstream
| |IF(NSLPdata) |MRS
| | tg_RecvMsg(NSLPdata)|
| | to Appl.|
| | |
2) |rx_Query&& |tx_Response |Wait
|(ConfirmRequired) |start T_No_Confirm |Confirm
| |IF(NSLPdata) |
| | tg_RecvMsg(NSLPdata)|
| | to Appl.|
| | |
---+------------------------+-------------------------+-----------
-----------
State: WAIT CONFIRM
-----------
+Transition
| |Condition |Action |State
v--+------------------------+-------------------------+-----------
3) |timeout T_No_Confirm | |IDLE
| | |
Tsenov, et al. Expires August 10, 2010 [Page 23]
Internet-Draft GIST State Machine February 2010
4) |rx_Query&& |tx_Response |Wait
|(ConfirmRequired) |start T_No_Confirm |Confirm
| |IF(NSLPdata) |
| | tg_RecvMsg(NSLPdata)|
| | to Appl.|
| | |
5) |rx_Confirm |Install Upstream MRS |Established
| | |Upstream
| | |MRS
| | |
6) |rx_Data |tx_Error(No_MRS_ |Wait
| | installed)|Confirm
| | |
---+------------------------+-------------------------+-----------
-----------
State: Established Upstream MRS
-----------
+Transition
| |Condition |Action |State
v--+------------------------+-------------------------+-----------
5) |rx_Confirm |Install UpstreamPeerInfo |Established
| |tx_Data(queued_NSLP_data)|Upstream
| | |MRS
| | |
7) |(rx_Query)&& |Delete MRS |Wait
|(ConfirmRequired) |tx_Response |Confirm
| |start T_No_Confirm |
| |IF(MA is used) |
| | (Delete MA)|| |
| | (Stop using shared MA)|
| |IF(NSLPdata) |
| | tg_RecvMsg(NSLPdata) |
| | to Appl.|
| | |
8) |(timeout T_Expire_RNode)|Delete MRS |IDLE
||| |tg_NetworkNotification |
|(tg_SetStateLifetime(0))|IF(MA is used) |
| | (Delete MA)|| |
| | (Stop using shared MA)|
| | |
9) |tg_SendMsg |IF(!UpstreamPeerInfo) |Established
| | Queue NSLP data |Upstream
| |ELSE tx_Data |MRS
| | |
Tsenov, et al. Expires August 10, 2010 [Page 24]
Internet-Draft GIST State Machine February 2010
10)|rx_Query |IF (NewPeer) |Established
| | Update UpstreamPeerInfo|Upstream
| |tx_Response |MRS
| |restart T_Expire_RNode |
| | |
11)|rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established
|(!ConfirmRequired) |restart T_Expire_RNode |Upstream
| |tx_Response(MAinfo) |MRS
| | |
12)|rx_Data |IF(UpstreamPeerInfo) |Established
| | (tg_RecvMsg to Appl.)|Upstream
| | &&(restart_T_Expire_ |MRS
| | RNode)|
| |ELSE |
| | tx_Error(No_MRS_ |
| | installed)|
| | |
13)|Tg_ERROR |(Delete MRS) |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------
Figure 5
Tsenov, et al. Expires August 10, 2010 [Page 25]
Internet-Draft GIST State Machine February 2010
Authors' Addresses
Tseno Tsenov
Sofia, Bulgaria
Email: tseno.tsenov@mytum.de
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Email: Hannes.Tschofenig@nsn.com
Xiaoming Fu
University of Goettingen
Computer Networks Group
Goldschmidtstr. 7
Goettingen 37077
Germany
Email: fu@cs.uni-goettingen.de
Cedric Aoun
Paris, France
Email: cedric@caoun.net
Elwyn B. Davies
Folly Consulting
Soham, Cambs, UK
Phone: +44 7889 488 335
Email: elwynd@dial.pipex.com
Tsenov, et al. Expires August 10, 2010 [Page 26]