< draft-ietf-nsis-ntlp-statemachine-09.txt		draft-ietf-nsis-ntlp-statemachine-10.txt >
	NSIS T. Tsenov		NSIS T. Tsenov
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Informational Nokia Siemens Networks		Intended status: Informational Nokia Siemens Networks
	Expires: August 10, 2010 X. Fu		Expires: October 24, 2010 X. Fu (Ed.)
	Univ. Goettingen		Univ. Goettingen
	C. Aoun		C. Aoun
	E. Davies		E. Davies
	Folly Consulting		Folly Consulting
	February 10, 2010		April 24, 2010
	GIST State Machine		GIST State Machine
	draft-ietf-nsis-ntlp-statemachine-09.txt		draft-ietf-nsis-ntlp-statemachine-10.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Abstract		Abstract
	This document describes the state machines for the General Internet		This document describes state machines for the General Internet
	Signaling Transport (GIST). The states of GIST nodes for a given flow		Signaling Transport (GIST). The states of GIST nodes for a given flow
	and their transitions are presented in order to illustrate how GIST		and their transitions are presented in order to illustrate how GIST
	may be implemented.		may be implemented.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Notational conventions used in state diagrams . . . . . . . 4		3. Notational conventions used in state diagrams . . . . . . . 4
	4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 6		4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 6
	5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8		5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8
	5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 10		5.2 Common Events . . . . . . . . . . . . . . . . . . . . . . 9
			5.3 Common Variables . . . . . . . . . . . . . . . . . . . . . 10
	6. State machines . . . . . . . . . . . . . . . . . . . . . . . 12		6. State machines . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 12		6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 12
	6.2 State machine for GIST querying node . . . . . . . . . . . 12		6.2 State machine for GIST querying node . . . . . . . . . . . 12
	6.3 State machine for GIST responding node . . . . . . . . . . 15		6.3 State machine for GIST responding node . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		10.1 Normative References . . . . . . . . . . . . . . . . . . 19
	11.1 Normative References . . . . . . . . . . . . . . . . . . 19		10.2 Informative References . . . . . . . . . . . . . . . . . 19
	11.2 Informative References . . . . . . . . . . . . . . . . . 19		Appendix A. State transition tables . . . . . . . . . . . . . . 20
	Appendix A. ASCII versions of the state diagrams . . . . . . . . 20		A.1 State transition tables for GIST querying node . . . . . 20
	A.1 State machine for GIST querying node (Figure 2) . . . . 20		A.2 State transition tables for GIST responding node . . . . 23
	A.2 State Machine for GIST responding node (Figure 3) . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	The state machines described in this document are illustrative of how		The state machines described in this document are illustrative of how
	the GIST protocol defined in [1] may be implemented for the GIST		the GIST protocol defined in [1] may be implemented for the GIST
	nodes in different locations of a flow path. Where there are		nodes in different locations of a flow path. Where there are
	differences - [1] is authoritative. The state machines are		differences - [1] is authoritative. The state machines are
	informative only. Implementations may achieve the same results using		informative only. Implementations may achieve the same results using
	different methods.		different methods.
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 42 ¶
	handle messages for different Message Routing States.		handle messages for different Message Routing States.
	The state machine states represent the upstream/downstream peers		The state machine states represent the upstream/downstream peers
	states of the Message Routing State.		states of the Message Routing State.
	For simplification not all objects included in a message are shown.		For simplification not all objects included in a message are shown.
	Only those that are significant for the case are shown. State		Only those that are significant for the case are shown. State
	machines do not present handling of messages that are not significant		machines do not present handling of messages that are not significant
	for management of the states.		for management of the states.
	Presented in this document state machines do not cover all functions		The state machines presented in this document do not cover all
	of a GIST node. Functionality of message forwarding, transmission of		functions of a GIST node. Functionality of message forwarding,
	NSLP data without MRS establishment and providing of the received		transmission of NSLP data without MRS establishment and providing of
	messages to the appropriate MRS, we refer as "Lower level pre-		the received messages to the appropriate MRS, we refer as "Lower
	processing" step. Pre-processing provides to the appropriate MRS FSM		level pre-processing" step. Pre-processing provides to the
	only the messages which are matched against waiting Query/Response		appropriate MRS state machine only the messages which are matched
	cookies, or established MRS MRI+NSLPID+SID primary key. This is		against waiting Query/Response cookies, or established MRS
	presented by "rx_*" events in the state machines.		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.,		Management of Messaging Associations (MA) is considered in the
	tg_Establish_MA, tg_MA_established events), but its FSM is not		document via procedures, events and variables, which describe MA
	explicitly presented.		interaction with the MRS state machines. A state machine for MA
			management is not explicitly presented.
	5.1 Common Procedures		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:		Tx_Query:
	Transmit of Query message		Transmit of Query message
	Tx_Response:		Tx_Response:
	Transmit of Response message		Transmit of Response message
	Tx_Confirm:		Tx_Confirm:
	Transmit of Confirm message		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
	established
	Tx_Data:		Tx_Data:
	Transmit of Data message		Transmit of Data message
	Rx_Data:		Tg_MessageStatus:
	Receive of Data message		NSLP/GIST API message informing NSLP application for unsuccessful
			delivery of a 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:		Tg_RecvMsg:
	Timer for the waiting period for Response message in Querying Node		NSLP/GIST API message that provides received message to the NSLP
			application
	T_No_Confirm:		Tg_NetworkNotification:
	Timer for the waiting period for Confirm message in Responding		NSLP/GIST API message that informs NSLP application for change in
	Node		MRS
	Install downstream/upstream MRS:		Install downstream/upstream MRS:
	Install new Message Routing State and save the corespoding peer		Install new Message Routing State and save the corespoding peer
	state info (IP address and UDP port or pointer to the used MA) for		state info (IP address and UDP port or pointer to the used MA) for
	the current Message Routing State or update the coresponding peer		the current Message Routing State or update the coresponding peer
	state info.		state info.
	DELETE MRS:		Delete MRS:
	Delete installed downstream/upstream peer's info for the current		Delete installed downstream/upstream peer's info for the current
	Message Routing State and delete the Message Routing State if		Message Routing State and delete the Message Routing State if
	required.		required.
	Established MA:		Refresh MRS:
	A Message Association (MA) is established between the current node		Refreshes installed MRS.
	and its upstream peer. The initiator for the establishment is the
	upstream peer.
	Re-use existing MA:		Queue NSLP info:
	An existing MA between the current node and its peer is re-used.		Save NLSP messages in a queue until conditions for their sending
			are present, e.g. a required MA association is established.
	DELETE MA:		CheckPeerInfo:
			The sender of the received data message is matched against the
			installed peer info in the MRS.
			Delete MA:
	Delete/disconnect used MA.		Delete/disconnect used MA.
	Stop using shared MA:		Stop using shared MA:
	Stop using shared MA. If the shared MA is no more used by any		Stop using shared MA. If the shared MA is no more used by any
	other MRSs, it depends on the local policy whether it is deleted		other MRSs, it depends on the local policy whether it is deleted
	or kept.		or kept.
	REFRESH MRS:		Tg_Establish_MA:
	Refreshes installed MRS.		Trigers establishment of a new MA.
	Tg_MA_Error:		Start/Restart a timer variable (Section 5.3):
	Error event with used MA.		Start/Restart of a certain timer.
	Tg_InvalidRoutingState:		Install/Update/Delete UpstreamPeerInfo variable (Section 5.3):
	Notification from NSLP application for path change		Management of upstream peer info in responding node state machine.
	Tg_Establish_MA:		5.2 Common Events
	Trigers establishment of MA.
	Tg_MA_Established:		Rx_Query:
	MA has been successfully established.		Receive of Query message
			Rx_Response:
			Receive of Response message
			Rx_Confirm:
			Receive of Confirm message
			Rx_Data:
			Receive of Data message
			Tg_SendMsg:
			NSLP/GIST API message from NSLP application that requests
			transmission of a NSLP message.
			Tg_SetStateLifetime(time_period):
			NSLP/GIST API message providing info for the lifetime of a Routing
			State (RS), required by the application. "Time_period = 0"
			represents the cancellation of established RSs/MAs, invoked by the
			NSLP application.
			Tg_InvalidRoutingState:
			NSLP/GIST API notification from NSLP application for path change.
	Tg_ERROR:		Tg_ERROR:
	General Error event / system level error.		General Error event / system level error.
	No_MRS_Installed:		Tg_MA_Established:
	Error response, send by the Responding node indicating lost		A new MA has been successfully established.
	Confirm message.
	5.2 Common Variables		Tg_MA_Error:
			Error event with used MA.
	It is assumed that the type of mode and destination info (which need		Timeout a timer variable (Section 5.3):
	to be taken from the application parameters and local GIST policy)is		Timeout of a certain timer.
	provided. This is represented by the common variables Dmode, Cmode,
	MAinfo, MApresent and Refresh.		5.3 Common Variables
			Variables listed in this section are defined as:
			- Specific information carried in the received messages.
			- Conditions that are results of processes not defined in the state
			machine model.
			State machine logic is based on these general conditions and message
			parameters.
			The type of mode and destination info is determined by NSLP
			application parameters and local GIST policy. Here it is represented
			by the common variables Dmode, Cmode and MAinfo.
	Cmode:		Cmode:
	The message MUST be transmitted in Cmode. This is specified by		The message MUST be transmitted in Cmode. This is specified by
	"Message transfer attributes" set to any of the following values:		"Message transfer attributes" set by NSLP application to any of
			the following values:
	"Reliability" is set to TRUE.		"Reliability" is set to TRUE.
	"Security" is set to values that request secure handling of a		"Security" is set to values that request secure handling of a
	message.		message.
	"Local processing" is set to values that require services offered		"Local processing" is set to values that require services offered
	by Cmode (e.g., congestion control). [1]		by Cmode (e.g., congestion control). [1]
	Dmode:		Dmode:
	The message MUST be transmitted in Dmode. This is specified by		The message MUST be transmitted in Dmode. This is specified by
	local policy rules and in case that the "Message transfer		local policy rules and in case that the "Message transfer
	attributes" are not set to any of the following values:		attributes" are not set by NSLP application to any of the
			following values:
	"Reliability" is set to TRUE.		"Reliability" is set to TRUE.
	"Security" is set to values that request special security handling		"Security" is set to values that request special security handling
	of a message.		of a message.
	"Local processing" is set to values that require services offered		"Local processing" is set to values that require services offered
	by Cmode [1]		by Cmode [1]
	MAinfo:		MAinfo:
	GIST message parameters describing the required MA or proposed MA		GIST message parameters describing the required MA or proposed MA,
	e.g. "Stack-proposal" and "Stack-Configuration-Data".		e.g., "Stack-proposal" and "Stack-Configuration-Data" [1].
	NSLPdata:		NSLPdata:
	NSLP application data.		NSLP application data.
	RespCookie:		RespCookie:
	Responder Cookie that is being sent by the Responding node with		Responder Cookie that is being sent by the responding node with
	the Response message in case that its local policy requires a		the Response message in case that its local policy requires a
	confirmation from the querying node.		confirmation from the querying node.
	ConfirmRequired:		ConfirmRequired:
	Confirm message is required by the local policy rule for		Indicator that a Confirm message is required by the local policy
	installation of the new MRS.		rule for installation of a new MRS.
	NewPeer:		NewPeer:
	Response message is received from new responding peer.		Indicator that a Response message is received from new responding
			peer.
	MAexist:		MAexist:
	Existing MA will be reused.		Indicator that an existing MA will be reused in data transfer
			between peers.
	CheckPeerInfo:		UpstreamPeerInfo:
	The sender of the received data message is matched against the		Upstream peer info that is saved in an established MRS.
	installed peer info in the MRS.
	UpstreamPeerInstalled:		T_Inactive_QNode:
	Upstream peer info is installed in the MRS.		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
			No_MRS_Installed:
			Data sent by responding node via a Response message that indicates
			loss of Confirm message.
	6. State machines		6. State machines
	The following section presents the state machine diagrams of GIST		The following section presents the state machine diagrams of GIST
	peers.		peers. The document is issued in two formats - .pdf and .txt.
			In the .pdf document, the state machine diagrams are depicted in
			details in this section. All state machine information (triggering
			event, action taken and variables status) is visualized on the
			diagrams.
			In the .txt document, state machine diagrams depict only transition
			numbers. Following each diagram is a list of state transition
			descriptions. Complete transition details (triggering event, action
			taken and variables status) are given in state transition tables in
			Appendix A.
			Please use the .pdf version whenever possible. It is the clearer
			representation of the state machine. In case of a difference between
			the two documents, please refer to the .pdf version.
	6.1 Diagram notations		6.1 Diagram notations
	+--------------------------------+		+--------------------------------+
	| STATE |		| STATE |
	+--------------+-----------------+		+--------------+-----------------+
	|		|
	|		|
	ooooo		ooooo
	o N o Transition N		o N o Transition N
	skipping to change at page 12, line 30 ¶		skipping to change at page 12, line 49 ¶
	|		|
	v		v
	+--------------------------------+		+--------------------------------+
	| STATE |		| STATE |
	+--------------------------------+		+--------------------------------+
	Figure 1: Diagram notations		Figure 1: Diagram notations
	6.2 State machine for GIST querying node		6.2 State machine for GIST querying node
	GIST querying node state machine diagram is depicted bellow.		GIST querying node state machine diagram is depicted below.
	Transition description follows.		Transition descriptions follow.
	For .txt version, please refer to Appendix A.1 for complete		For .txt version, please refer to Appendix A.1 for complete
	transition details (triggering event, action taken and variables		transition details (triggering event, action taken and variables
	status).		status).
	+-----------+ ooooo		+-----------+ ooooo
	| Any State +----------o 18 o		| Any State +----------o 18 o
	+-----------+ ooooo		+-----------+ ooooo
	|		|
	v		v
	skipping to change at page 13, line 48 ¶		skipping to change at page 14, line 4 ¶
	| | | | | | |		| | | | | | |
	v | | | v v |		v | | | v v |
	+----------+----------+--------+------------------------------+---+		+----------+----------+--------+------------------------------+---+
	| Established Downstream MRS |		| Established Downstream MRS |
	+--+-----------+-----------+-----------+-----------+--------------+		+--+-----------+-----------+-----------+-----------+--------------+
	| ^ | ^ | ^ | ^ | ^		| ^ | ^ | ^ | ^ | ^
	| | | | | | | | | |		| | | | | | | | | |
	| ooooo | | ooooo | | ooooo | | ooooo | | ooooo |		| ooooo | | ooooo | | ooooo | | ooooo | | ooooo |
	+o 16 o+ +o 14 o+ +o 15 o+ +o 4 o+ +o 17 o+		+o 16 o+ +o 14 o+ +o 15 o+ +o 4 o+ +o 17 o+
	ooooo ooooo ooooo ooooo ooooo		ooooo ooooo ooooo ooooo ooooo
			Figure 2: GIST Querying Node State Machine
	Figure 1: GIST Querying Node State Machine
	1**) Initial request from NSLP application is received, which		1**) Initial request from NSLP application is received, which
	triggers Query messages requesting either D_mode or C_mode.		triggers Query messages requesting either Dmode or Cmode.
	Depending on nodes local policy NSLP data might be piggybacked in		Depending on nodes local policy NSLP data might be piggybacked in
	the Query requesting D_mode. Query may carry MAinfo if C_mode		the Query requesting Dmode. Query may carry MAinfo if Cmode
	transport is needed.		transport is needed.
	2) No_Response timer expires and maximum number of retries has been		2) T_No_Response timer expires and maximum number of retries has been
	reached. NSLP application is notified for the GIST peer discovery		reached. NSLP application is notified for the GIST peer discovery
	failure.		failure.
	3) No_Response timer expires. Query is resent.		3) T_No_Response timer expires. Query is resent.
	4) Data message is received. It is checked if its sender matches the		4) Data message is received. It is checked if its sender matches the
	installed downstream peer info in the MRS and then processed. In		installed downstream peer info in the MRS and then processed. In
	WaitResponse state, this event might happen in the process of MA		WaitResponse state, this event might happen in the process of MA
	upgrade, when the downstream peer is still not aware of		upgrade, when the downstream peer is still not aware of
	establishment of the new MA.		establishment of the new MA.
	5) NSLP application requests sending data. NSLP data is queued,		5) NSLP application provides data for sending. NSLP data is queued,
	because downstream peer is not discovered or required MA is still		because downstream peer is not discovered or required MA is still
	not established.		not established.
	6) Response message is received. If D_mode connection is requested or		6) Response message is received. If Dmode connection is requested or
	available MA can be reused for requested C_mode, the MRS is		available MA can be reused for requested Cmode, the MRS is
	established.		established.
	7*) Response message is received. If C_mode connection must be		7*) Response message is received. If Cmode connection must be
	established and there is no available MA to be reused, MA		established and there is no available MA to be reused, MA
	establishment is initiated and waited to be completed.		establishment is initiated and waited to be completed.
	8) MA establishment failure. NSLP application is notified for		8) A MA establishment fails. NSLP application is notified for
	unsuccessful message delivery.		unsuccessful message delivery.
	9) NSLP application requests sending data and requested transport		9) NSLP application provides data for sending and requested transport
	parameters require upgrade of established MRS from D_mode/C_mode		parameters require upgrade of established MRS from Dmode/Cmode to
	to C_mode. Or NSLP application notifies GIST for path change.		Cmode. Or NSLP application notifies GIST for path change. As a
	Downstream GIST peer discovery is initiated.		result downstream GIST peer discovery is initiated.
	10) MRS lifetime expires or NSLP application notifies that MRS is no		10) MRS lifetime expires or NSLP application notifies that MRS is no
	longer needed. MRS is deleted. If not needed, MA is deleted, too.		longer needed. MRS is deleted. If not needed, MA is deleted, too.
	NSLP application is notified for MRS change.		NSLP application is notified for MRS change.
	11*) Path change detected. Response message from a new downstream		11*) Path change detected as a Response message from a new downstream
	GIST peer is received. A new MA must be established for requested		GIST peer is received. A new MA must be established for requested
	C_mode.		Cmode.
	12*) MA is established. MRS is installed. Queued NSLP data is sent.		12*) A new MA is established. MRS is installed. Queued NSLP data is
	13) Refresh_QNode timer expires. Query message is sent.		sent.
			13) T_Refresh_QNode timer expires. Query message is sent.
	14) NSLP application provides data for sending. It is sent via Data		14) NSLP application provides data for sending. It is sent via Data
	message towards downstream GIST peer.		message towards downstream GIST peer.
	15) Response message from the downstream GIST peer is received. The		15) Response message from the downstream GIST peer is received. The
	peer is not changed. MRS is refreshed (Refresh_QNode timer is		peer is not changed. MRS is refreshed (T_Refresh_QNode timer is
	restarted).		restarted).
	16) Path change detected. Response message from a new downstream GIST		16) Path change detected as a Response message from a new downstream
	peer is received. D_mode is requested or existing MA can be reused		GIST peer is received. Dmode is requested or existing MA can be
	for requested C_mode.		reused for requested Cmode.
	17) Sent Confirm message has not been received by downstream GIST
	peer. Confirm message is resent.		17) Responding peer indicates that it has not received a Confirm
			message and it has no established upstream MRS. Confirm message is
			resent.
	18) General error or system level error occurs. MRS is deleted. If		18) General error or system level error occurs. MRS is deleted. If
	not needed, MA is deleted, too. NSLP application is notified for		not needed, MA is deleted, too. NSLP application is notified for
	MRS change.		the MRS change.
	Remarks:		Remarks:
	*) Response and Comfirm messages might be sent either in Dmode or		*) Response and Confirm messages might be sent either in Dmode or
	Cmode, before or after MA establishment depending on node's local		Cmode, before or after MA establishment depending on nodes local
	3-way handshake policy and the availability of MAs to be reused. See		3-way handshake policy and the availability of MAs to be reused. See
	draft for details.		[1] for details.
	**) Depending on the local policy NSLPdata might be send as payload		**) Depending on GIST local policy, NSLPdata might be send as payload
	of Query and Confirm messages (piggybacking).		of Query and Confirm messages (piggybacking).
	6.3 State machine for GIST responding node		6.3 State machine for GIST responding node
	GIST responding node state machine diagram is depicted bellow.		GIST responding node state machine diagram is depicted below.
	Transition description follows.		Transition descriptions follow.
	For .txt version, please refer to Appendix A.2 for complete		For .txt version, please refer to Appendix A.2 for complete
	transition details (triggering event, action taken and variables		transition details (triggering event, action taken and variables
	status).		status).
	+-----------+ ooooo		+-----------+ ooooo
	| Any State +----------o 13 o		| Any State +----------o 14 o
	+-----------+ ooooo		+-----------+ ooooo
	|		|
	v		v
	+-----------------------------------------------------------------+		+-----------------------------------------------------------------+
	| IDLE |		| IDLE |
	+--+-------------------------------+------------------------------+		+--+-------------------------------+------------------------------+
	| ^ | ^		| ^ | ^
	| | | |		| | | |
	ooooo | ooooo ooooo ooooo		ooooo | ooooo ooooo ooooo
	o 1 o | o 2 o +o 4 o+ o 3 o		o 1 o | o 2 o +o 4 o+ o 3 o
	ooooo | ooooo | ooooo | ooooo		ooooo | ooooo | ooooo | ooooo
	| | | | | |		| | | | | |
	| | v | v |		| | v | v |
	| | +--------------------+---------------+---+		| | +--------------------+---------------+---+
	| | | Wait Confirm |		| | | Wait Confirm |
	| | +---------+------------------+-----------+		| | +---------+------------------+-----------+
	| | | ^ | ^		| | | ^ | ^
	| | | | | |		| | | | | |
	| ooooo ooooo ooooo ooooo | ooooo |		| ooooo ooooo ooooo ooooo | ooooo |
	| +o 5 o+ o 8 o o 5 o o 7 o +o 6 o+		| +o 13 o+ o 8 o o 5 o o 7 o +o 6 o+
	| | ooooo | ooooo ooooo ooooo ooooo		| | ooooo | ooooo ooooo ooooo ooooo
	| | | | | |		| | | | | |
	v | v | v |		v | v | v |
	+------+-------------+------------------------+-------------------+		+------+-------------+------------------------+-------------------+
	| Established Upstream MRS |		| Established Upstream MRS |
	+------+-------------+-------------+------------+-----------------+		+------+-------------+-------------+------------+-----------------+
	| ^ | ^ | ^ | ^		| ^ | ^ | ^ | ^
	| | | | | | | |		| | | | | | | |
	| ooooo | | ooooo | | ooooo | | ooooo |		| ooooo | | ooooo | | ooooo | | ooooo |
	+o 9 o+ +o 11 o+ +o 12 o+ +o 10 o+		+o 9 o+ +o 11 o+ +o 12 o+ +o 10 o+
	ooooo ooooo ooooo ooooo		ooooo ooooo ooooo ooooo
	Figure 3: GIST Responding Node State Machine		Figure 3: GIST Responding Node State Machine
	1) A Query message is received. MRS is installed immediately, based		1) A Query message is received. MRS is installed immediately, because
	on the local policy. Query message might carry piggybacked NSLP		local policy permits it. Query message might carry piggybacked
	data which is provided to the NSLP application.		NSLP data which is provided to the NSLP application.
	2) A Query message is received. Explicit Confirm message is required		2) A Query message is received. Local policy requires explicit
	for MRS installation, based on the local policy. Query message		Confirm message for MRS installation. Query message might carry
	might carry piggybacked NSLP data which is provided to the NSLP		piggybacked NSLP data which is provided to the NSLP application.
	application.		3) T_No_Confirm timer expires. Note that all cases of lost handshake
	3) No_Confirm timer expires. Note that all cases of lost handshake
	GIST messages are handled only by GIST querying node via resend of		GIST messages are handled only by GIST querying node via resend of
	Query message.		Query message.
	4) A Query message is received again. This means that sent Response		4) A Query message is received again. This means that sent Response
	message has not been received by upstream GIST peer. Response		message has not been received by upstream GIST peer. Response
	message is resent.		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		5) A Confirm message is received which causes installation of the
	peer info.		upstream MRS.
	6) In case of lost Confirm message, data messages might be received		6) In case of lost Confirm message, data messages might be received
	from the upstream GIST node (it is unaware of the lost Confirm		from the upstream GIST node (it is unaware of the lost Confirm
	message). Response indicating the loss of the Confirm is sent back		message). Response indicating the loss of the Confirm is sent back
	to the upstream GIST node.		to the upstream GIST node.
	7) A Query message is received with request for change of the used		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		connection mode (from Dmode/Cmode to better Cmode) or from new
	upstream GIST node. Local policy requires explicit Confirm message		upstream GIST node. Local policy requires explicit Confirm message
	for MRS installation.		for MRS installation.
	8) MRS lifetime expires or NSLP application notifies that MRS is no		8) MRS lifetime expires or NSLP application notifies that MRS is no
	longer needed. MRS is deleted. If used and not needed, MA is		longer needed. MRS is deleted. If used and not needed, MA is
	deleted, too. NSLP application is notified for MRS change.		deleted, too. NSLP application is notified for MRS change.
	9) Data for sending is received from NSLP application. NSLP data is		9) NSLP application provides data for sending. NSLP data is sent if
	sent if discovery process is successfully accomplished or is		discovery process is successfully accomplished or it is queued if
	queued if Confirm message is still expected to confirm		Confirm message is still expected to confirm establishment of a
	establishment of MA.		MA.
	10) A Query message is received. If it is sent from new upstream GIST		10) A Query message is received. If it is sent from a new upstream
	node there is path change. Local policy does not need explicit		GIST node then there is a path change. Local policy does not need
	Confirm message for MRS installation. MRS data is updated.		explicit Confirm message for MRS installation. MRS data is
			updated.
	11) A Query message is received with request for change of the used		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		connection mode (from Dmode/Cmode to better Cmode). Local policy
	policy does not need explicit Confirm message for MRS		does not need explicit Confirm message for MRS installation. MRS
	installation. MRS data is updated.		data is updated.
	12) A Data message is received. Data messages are accepted only if		12) A Data message is received. Data messages are accepted only if
	complete MRS is installed, e.g., there is installed upstream peer		complete MRS is installed, e.g., there is installed upstream peer
	info. If not, then Confirm message is expected and data message		info. If not, then Confirm message is expected and Data message is
	wont be accepted. Response indicating the loss of the Confirm is		not accepted. Response indicating the loss of the Confirm is sent
	sent back to the upstream GIST node.		back to the upstream GIST node.
	13) General error or system level error occurs. MRS is deleted. If		13) A Confirm message is received. It accomplishes assignment of an
			existing MA (or establishment of a new MA) needed for data
			transferring between peers. The information for the used MA is
			installed as upstream peer info.
			14) General error or system level error occurs. MRS is deleted. If
	not needed, MA is deleted, too. NSLP application is notified for		not needed, MA is deleted, too. NSLP application is notified for
	MRS change.		MRS change.
	7. Security Considerations		7. Security Considerations
	This document does not raise new security considerations. Any		This document does not raise new security considerations. Security
	security concerns with GIST are likely reflected in security related		considerations are addressed in GIST specification [1] and in [6].
	NSIS work already (such as [1] or [6]).
	8. IANA Considerations		8. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	9. Contributors		9. Acknowledgments
	Christian Dickmann contributed to refining of the state machine since
	01 version.
	10. Acknowledgments		The authors would like to thank Christian Dickmann who contributed to
			refining of the state machine.
	The authors would like to thank Robert Hancock, Ingo Juchem, Andreas		The authors would like to thank Robert Hancock, Ingo Juchem, Andreas
	Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd		Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd
	Schloer for their insightful comments.		Schloer for their insightful comments.
	11. References		10. References
	11.1. Normative References		10.1. Normative References
	[1] Schulzrinne, H., "GIST: General Internet Signaling		[1] Schulzrinne, H., "GIST: General Internet Signaling
	Transport", draft-ietf-nsis-ntlp-20 (work in progress),		Transport", draft-ietf-nsis-ntlp-20 (work in progress),
	December 2009.		December 2009.
	[2] Bradner, S., "Key words for use in RFCs to Indicate		[2] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	11.2. Informative References		10.2. Informative References
	[3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,		[3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
	"State Machines for Extensible Authentication Protocol		"State Machines for Extensible Authentication Protocol
	(EAP) Peer and Authenticator", RFC4137, August 2005.		(EAP) Peer and Authenticator", RFC4137, August 2005.
	[4] Institute of Electrical and Electronics Engineers,		[4] Institute of Electrical and Electronics Engineers,
	"Standard for Local and Metropolitan Area Networks: Port-		"Standard for Local and Metropolitan Area Networks: Port-
	Based Network Access Control", IEEE 802-1X-2004, December		Based Network Access Control", IEEE 802-1X-2004, December
	2004.		2004.
	[5] Fajardo, V., Ohba, Y. and R. Marin-Lopez, "State Machines		[5] Fajardo, V., Ohba, Y. and R. Marin-Lopez, "State Machines
	for Protocol for Carrying Authentication for Network		for Protocol for Carrying Authentication for Network
	Access (PANA)", RFC 5609, August 2009.		Access (PANA)", RFC 5609, August 2009.
	[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for		[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for
	NSIS", RFC 4081, June 2005.		NSIS", RFC 4081, June 2005.
	Appendix A. ASCII versions of state diagrams		Appendix A. State transition tables
	This appendix contains the state diagrams in ASCII format. Please		State transition tables given below represent the state diagrams in
	use the PDF version whenever possible: it is much easier to		ASCII format. Please use the .pdf version whenever possible. It is
	understand.		the clearer representation of the state machine.
	For each state there is a separate table that lists in each row:		For each state there is a separate table that lists in each row:
	- an event that triggers a transition,		- an event that triggers a transition,
	- actions taken as a result of the incoming event,		- actions taken as a result of the incoming event,
	- and the new state at which the transitions ends.		- and the new state at which the transitions ends.
	A.1. State machine for GIST querying node (Figure 2)		A.1. State transition tables for GIST querying node
			Please refer to state machine diagram on Figure 2.
	-----------		-----------
	State: IDLE		State: IDLE
	-----------		-----------
	+Transition		+Transition
	| |Condition |Action |State		| |Condition |Action |State
	V--+------------------------+-------------------------+-----------		V--+------------------------+-------------------------+-----------
	1) |tg_SendMsg |tx_Query |Wait		1) |tg_SendMsg |tx_Query |Wait
	** | |start T_No_Response |Response		** | |start T_No_Response |Response
	skipping to change at page 22, line 50 ¶		skipping to change at page 23, line 4 ¶
	-----------		-----------
	State: Wait MA Establishment		State: Wait MA Establishment
	-----------		-----------
	+Transition		+Transition
	| |Condition |Action |State		| |Condition |Action |State
	V--+------------------------+-------------------------+-----------		V--+------------------------+-------------------------+-----------
	5) |tg_SendMsg |Queue NSLP data |Wait MA		5) |tg_SendMsg |Queue NSLP data |Wait MA
	| | |Establish.		| | |Establish.
	| | |		| | |
	8) |tg_MA_error |Delete MRS |IDLE		8) |tg_MA_error |Delete MRS |IDLE
	| |tg_MessageStatus |		| |tg_MessageStatus |
	| | |		| | |
	12)|tg_MA_Established |Install MRS |Established		12)|tg_MA_Established |Install MRS |Established
	* | |(tx_Confirm) |Downstream		* | |(tx_Confirm) |Downstream
	| |tx_Data(Queued NSLP data)|MRS		| |tx_Data(Queued NSLP data)|MRS
	| | |		| | |
	18)|Tg_ERROR |Delete MRS |IDLE		18)|Tg_ERROR |Delete MRS |IDLE
	| |IF (MA is used) |		| |IF (MA is used) |
	| | ((Delete MA)|| |		| | ((Delete MA)|| |
	| | (Stop using shared MA))|		| | (Stop using shared MA))|
	| |Tg_NetworkNotification |		| |Tg_NetworkNotification |
	| | |		| | |
	---+------------------------+-------------------------+-----------		---+------------------------+-------------------------+-----------
	Figure 4
	A.2. State Machine for GIST responding node (Figure 3)		A.2. State transition tables for GIST responding node
			Please refer to state machine diagram on Figure 3.
	-----------		-----------
	State: IDLE		State: IDLE
	-----------		-----------
	+Transition		+Transition
	| |Condition |Action |State		| |Condition |Action |State
	v--+------------------------+-------------------------+-----------		v--+------------------------+-------------------------+-----------
	1) |rx_Query&& |tx_Response |Established		1) |rx_Query&& |tx_Response |Established
	|(!ConfirmRequired) |Install MRS |Upstream		|(!ConfirmRequired) |Install MRS |Upstream
	skipping to change at page 24, line 4 ¶		skipping to change at page 24, line 8 ¶
	-----------		-----------
	State: WAIT CONFIRM		State: WAIT CONFIRM
	-----------		-----------
	+Transition		+Transition
	| |Condition |Action |State		| |Condition |Action |State
	v--+------------------------+-------------------------+-----------		v--+------------------------+-------------------------+-----------
	3) |timeout T_No_Confirm | |IDLE		3) |timeout T_No_Confirm | |IDLE
	| | |		| | |
	4) |rx_Query&& |tx_Response |Wait		4) |rx_Query&& |tx_Response |Wait
	|(ConfirmRequired) |start T_No_Confirm |Confirm		|(ConfirmRequired) |start T_No_Confirm |Confirm
	| |IF(NSLPdata) |		| |IF(NSLPdata) |
	| | tg_RecvMsg(NSLPdata)|		| | tg_RecvMsg(NSLPdata)|
	| | to Appl.|		| | to Appl.|
	| | |		| | |
	5) |rx_Confirm |Install Upstream MRS |Established		5) |rx_Confirm |Install Upstream MRS |Established
	| | |Upstream		| | |Upstream
	| | |MRS		| | |MRS
	| | |		| | |
	6) |rx_Data |tx_Error(No_MRS_ |Wait		6) |rx_Data |tx_Response(No_MRS_ |Wait
	| | installed)|Confirm		| | installed)|Confirm
	| | |		| | |
			14)|(Tg_ERROR)|| |(Delete MRS) |IDLE
			|(Tg_MA_Error) |IF (MA is used) |
			| | ((Delete MA)|| |
			| | (Stop using shared MA))|
			| |Tg_NetworkNotification |
			| | |
	---+------------------------+-------------------------+-----------		---+------------------------+-------------------------+-----------
	-----------		-----------
	State: Established Upstream MRS		State: Established Upstream MRS
	-----------		-----------
	+Transition		+Transition
	| |Condition |Action |State		| |Condition |Action |State
	v--+------------------------+-------------------------+-----------		v--+------------------------+-------------------------+-----------
	5) |rx_Confirm |Install UpstreamPeerInfo |Established
	| |tx_Data(queued_NSLP_data)|Upstream
	| | |MRS
	| | |
	7) |(rx_Query)&& |Delete MRS |Wait		7) |(rx_Query)&& |Delete MRS |Wait
	|(ConfirmRequired) |tx_Response |Confirm		|(ConfirmRequired) |tx_Response |Confirm
	| |start T_No_Confirm |		| |start T_No_Confirm |
	| |IF(MA is used) |		| |IF(MA is used) |
	| | (Delete MA)|| |		| | (Delete MA)|| |
	| | (Stop using shared MA)|		| | (Stop using shared MA)|
	| |IF(NSLPdata) |		| |IF(NSLPdata) |
	| | tg_RecvMsg(NSLPdata) |		| | tg_RecvMsg(NSLPdata) |
	| | to Appl.|		| | to Appl.|
	| | |		| | |
	skipping to change at page 25, line 4 ¶		skipping to change at page 25, line 10 ¶
	8) |(timeout T_Expire_RNode)|Delete MRS |IDLE		8) |(timeout T_Expire_RNode)|Delete MRS |IDLE
	||| |tg_NetworkNotification |		||| |tg_NetworkNotification |
	|(tg_SetStateLifetime(0))|IF(MA is used) |		|(tg_SetStateLifetime(0))|IF(MA is used) |
	| | (Delete MA)|| |		| | (Delete MA)|| |
	| | (Stop using shared MA)|		| | (Stop using shared MA)|
	| | |		| | |
	9) |tg_SendMsg |IF(!UpstreamPeerInfo) |Established		9) |tg_SendMsg |IF(!UpstreamPeerInfo) |Established
	| | Queue NSLP data |Upstream		| | Queue NSLP data |Upstream
	| |ELSE tx_Data |MRS		| |ELSE tx_Data |MRS
	| | |		| | |
	10)|rx_Query |IF (NewPeer) |Established		10)|rx_Query |IF (NewPeer) |Established
	| | Update UpstreamPeerInfo|Upstream		| | Update UpstreamPeerInfo|Upstream
	| |tx_Response |MRS		| |tx_Response |MRS
	| |restart T_Expire_RNode |		| |restart T_Expire_RNode |
	| | |		| | |
	11)|rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established		11)|rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established
	|(!ConfirmRequired) |restart T_Expire_RNode |Upstream		|(!ConfirmRequired) |restart T_Expire_RNode |Upstream
	| |tx_Response(MAinfo) |MRS		| |tx_Response(MAinfo) |MRS
	| | |		| | |
	12)|rx_Data |IF(UpstreamPeerInfo) |Established		12)|rx_Data |IF(UpstreamPeerInfo) |Established
	| | (tg_RecvMsg to Appl.)|Upstream		| | (tg_RecvMsg to Appl.)|Upstream
	| | &&(restart_T_Expire_ |MRS		| | &&(restart_T_Expire_ |MRS
	| | RNode)|		| | RNode)|
	| |ELSE |		| |ELSE |
	| | tx_Error(No_MRS_ |		| | tx_Error(No_MRS_ |
	| | installed)|		| | installed)|
	| | |		| | |
	13)|Tg_ERROR |(Delete MRS) |IDLE		13)|rx_Confirm |Install UpstreamPeerInfo |Established
	| |IF (MA is used) |		| |tx_Data(queued_NSLP_data)|Upstream
			| | |MRS
			| | |
			14)|(Tg_ERROR)|| |(Delete MRS) |IDLE
			|(Tg_MA_Error) |IF (MA is used) |
	| | ((Delete MA)|| |		| | ((Delete MA)|| |
	| | (Stop using shared MA))|		| | (Stop using shared MA))|
	| |Tg_NetworkNotification |		| |Tg_NetworkNotification |
	| | |		| | |
	---+------------------------+-------------------------+-----------		---+------------------------+-------------------------+-----------
	Figure 5
	Authors' Addresses		Authors' Addresses
	Tseno Tsenov		Tseno Tsenov
	Sofia, Bulgaria		Sofia, Bulgaria
	Email: tseno.tsenov@mytum.de		Email: tseno.tsenov@mytum.de
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Email: Hannes.Tschofenig@nsn.com		Email: Hannes.Tschofenig@nsn.com
	Xiaoming Fu		Xiaoming Fu (editor)
	University of Goettingen		University of Goettingen
	Computer Networks Group		Computer Networks Group
	Goldschmidtstr. 7		Goldschmidtstr. 7
	Goettingen 37077		Goettingen 37077
	Germany		Germany
	Email: fu@cs.uni-goettingen.de		Email: fu@cs.uni-goettingen.de
	Cedric Aoun		Cedric Aoun
	Paris, France		Paris, France
End of changes. 84 change blocks.
	214 lines changed or deleted		252 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/