doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc5972.txt b/doc/rfc/rfc5972.txt
new file mode 100644
index 0000000..8f086b3
--- /dev/null
+++ b/doc/rfc/rfc5972.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         T. Tsenov
+Request for Comments: 5972                                 H. Tschofenig
+Category: Informational                            Nokia Siemens Network
+ISSN: 2070-1721                                               X. Fu, Ed.
+                                                        Univ. Goettingen
+                                                                 C. Aoun
+                                                              Consultant
+                                                               E. Davies
+                                                        Folly Consulting
+                                                            October 2010
+
+
+       General Internet Signaling Transport (GIST) State Machine
+
+Abstract
+
+   This document describes 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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5972.
+
+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
+
+
+
+Tsenov, et al.                Informational                     [Page 1]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   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
+   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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. Notational Conventions Used in State Diagrams ...................3
+   4. State Machine Symbols ...........................................5
+   5. Common Rules ....................................................6
+      5.1. Common Procedures ..........................................7
+      5.2. Common Events ..............................................8
+      5.3. Common Variables ...........................................9
+   6. State Machines .................................................11
+      6.1. Diagram Notations .........................................12
+      6.2. State Machine for GIST Querying Node ......................12
+      6.3. State Machine for GIST Responding Node ....................16
+   7. Security Considerations ........................................18
+   8. Acknowledgments ................................................18
+   9. References .....................................................18
+      9.1. Normative References ......................................18
+      9.2. Informative References ....................................18
+   Appendix A. State Transition Tables ...............................20
+      A.1. State Transition Tables for GIST Querying Node ............20
+      A.2. State Transition Tables for GIST Responding Node ..........24
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                     [Page 2]
+
+RFC 5972                   GIST State Machine               October 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].
+
+   RFC 4137 [3] reproduced the following text from Section 8.2.1 of IEEE
+   802-1X-2004 [4].
+
+      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
+
+
+
+Tsenov, et al.                Informational                     [Page 3]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+      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 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 it 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 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.  That is, 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 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:
+
+
+
+
+Tsenov, et al.                Informational                     [Page 4]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   <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
+      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.
+
+
+
+
+
+Tsenov, et al.                Informational                     [Page 5]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   !=
+      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.
+
+   >
+      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 [1], such as Query,
+   Response, and Confirm.
+
+   The state machine represents the handling of GIST messages that match
+   a Message Routing State's Message Routing Information (MRI), NSIS
+   Signaling Layer Protocol identifier (NSLPID), and session identifier
+   (SID) and with no protocol errors.  Separate parallel instances of
+   the state machines should handle messages for different Message
+   Routing States (MRSs).
+
+   The state machine represents the states and transitions of the
+   upstream and downstream peers 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.
+
+
+
+
+
+Tsenov, et al.                Informational                     [Page 6]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   The state machines presented in this document 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 to as "lower-
+   level pre-processing" step.  Pre-processing provides to the
+   appropriate MRS state machine only the messages that are matched
+   against waiting Query/Response cookies, or the triplet (MRI, NSLPID,
+   SID) of the established MRS.  This is represented by "rx_*" events in
+   the state machines.
+
+   Management of messaging associations (MAs) is considered in the
+   document via procedures, events, and variables, which describe MA
+   interaction with the MRS state machines.  A state machine for MA
+   management is not explicitly presented.
+
+5.1.  Common Procedures
+
+   Tx_Query:
+      Transmit of Query message.
+
+   Tx_Response:
+      Transmit of Response message.
+
+   Tx_Confirm:
+      Transmit of Confirm message.
+
+   Tx_Data:
+      Transmit of Data message.
+
+   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 NSLP
+      application.
+
+   Tg_NetworkNotification:
+      NSLP/GIST API message that informs NSLP application of change in
+      MRS.
+
+   Install downstream/upstream MRS:
+      Install new Message Routing State and save the corresponding peer
+      state info (IP address and UDP port, or pointer to the used MA)
+      for the current Message Routing State or update the corresponding
+      peer state info.
+
+
+
+
+
+Tsenov, et al.                Informational                     [Page 7]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   Delete MRS:
+      Delete installed downstream/upstream peer's info for the current
+      Message Routing State, and delete the Message Routing State if
+      required.
+
+   Refresh MRS:
+      Refreshes installed MRS.
+
+   Queue NSLP info:
+      Save NSLP messages in a queue until conditions for their sending
+      are present, e.g., a required MA association is established.
+
+   CheckPeerInfo:
+      The sender of the received data message is matched against the
+      installed peer info in the MRS.
+
+   Delete MA:
+      Delete/disconnect used MA.
+
+   Stop using shared MA:
+      Stop using shared MA.  If the shared MA is no longer being used by
+      any other MRSs, it depends on the local policy whether it is
+      deleted or kept.
+
+   Tg_Establish_MA:
+      Triggers establishment of a new MA.
+
+   Start/Restart a timer variable (Section 5.3):
+      Start/Restart of a certain timer.
+
+   Install/Update/Delete UpstreamPeerInfo variable (Section 5.3):
+      Management of upstream peer info in state machine of responding
+      node.
+
+5.2.  Common Events
+
+   Rx_Query:
+      Receive of Query message.
+
+   Rx_Response:
+      Receive of Response message.
+
+   Rx_Confirm:
+      Receive of Confirm message.
+
+   Rx_Data:
+      Receive of Data message.
+
+
+
+
+Tsenov, et al.                Informational                     [Page 8]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   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:
+      General Error event / system level error.
+
+   Tg_MA_Established:
+      A new MA has been successfully established.
+
+   Tg_MA_Error:
+      Error event with used MA.
+
+   Timeout a timer variable (Section 5.3):
+      Timeout of a certain timer.
+
+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 D-mode, C-mode, and MAinfo.
+
+   C-mode:
+      The message MUST be transmitted in C-mode.  This is specified by
+      "Message transfer attributes" set by NSLP application to any of
+      the following values:
+
+      "Reliability" is set to TRUE.
+
+
+
+
+Tsenov, et al.                Informational                     [Page 9]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+      "Security" is set to values that request secure handling of a
+      message.
+
+      "Local processing" is set to values that require services offered
+      by C-mode (e.g., congestion control) [1].
+
+   D-mode:
+      The message MUST be transmitted in D-mode.  This is specified by
+      local policy rules.  If the "Message transfer attributes" are not
+      set by NSLP application to any of the following values, then:
+
+      "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 C-mode [1].
+
+   MAinfo:
+      GIST message parameters describing the required MA or proposed MA,
+      e.g., "Stack-proposal" and "Stack-Configuration-Data" [1].
+
+   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:
+      Indicator that a Confirm message is required by the local policy
+      rule for installation of a new MRS.
+
+   NewPeer:
+      Indicator that a Response message is received from a new
+      responding peer.
+
+   MAexist:
+      Indicator that an existing MA will be reused in data transfer
+      between peers.
+
+   UpstreamPeerInfo:
+      Upstream peer info that is saved in an established MRS.
+
+   T_Inactive_QNode:
+      Message Routing State lifetime timer in querying node.
+
+
+
+Tsenov, et al.                Informational                    [Page 10]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   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
+
+   The following section presents the state machine diagrams of GIST
+   peers.  RFC 5972 is published as a .txt file.  A supplementary .pdf
+   is being published as well.
+
+   In the .pdf document, the state machine diagrams are depicted in
+   detail.  All state machine information (triggering event, action
+   taken, and variable status) is represented in 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 variable 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 11]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+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
+
+   The state machine diagram of the GIST querying node is below.
+   Transition descriptions follow.
+
+   Please refer to Appendix A.1 for complete transition details
+   (triggering event, action taken, and variable status).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 12]
+
+RFC 5972                   GIST State Machine               October 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 2: State Machine for GIST Querying Node
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 13]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   1**) An initial request from the NSLP application is received, which
+        triggers Query messages requesting either D-mode or C-mode.
+        Depending on the node's local policy, the NSLP data might be
+        piggybacked in the Query requesting D-mode.  The Query may carry
+        MAinfo if C-mode transport is needed.
+
+   2)   T_No_Response timer expires, and the maximum number of retries
+        has been reached.  The NSLP application is notified of the GIST
+        peer discovery failure.
+
+   3)   T_No_Response timer expires.  The Query is resent.
+
+   4)   A Data message is received.  It is checked to see whether its
+        sender matches the installed downstream peer info in the MRS; if
+        so, it is processed.  In WaitResponse state, this event might
+        happen in the process of an MA upgrade, when the downstream peer
+        is still not aware of establishment of the new MA.
+
+   5)   The NSLP application provides data for sending.  NSLP data is
+        queued because the downstream peer is not discovered or the
+        required MA is still not established.
+
+   6)   A Response message is received.  If a D-mode connection is
+        requested or the available MA can be reused for the requested
+        C-mode, the MRS is established.
+
+   7*)  Response message is received.  If a C-mode connection must be
+        established, and there is no available MA to be reused, MA
+        establishment is initiated and the system waits for it to be
+        completed.
+
+   8)   MA establishment fails.  NSLP application is notified for
+        unsuccessful message delivery.
+
+   9)   The NSLP application provides data for sending, and the
+        requested transport parameters require an upgrade of the
+        established MRS from D-mode/C-mode to C-mode.  Or, the NSLP
+        application notifies the GIST instance of the path change.  As a
+        result, downstream GIST peer discovery is initiated.
+
+   10)  The MRS lifetime expires or the NSLP application notifies that
+        the MRS is no longer needed.  The MRS is deleted.  If not
+        needed, the MA is deleted, too.  The NSLP application is
+        notified of the MRS change.
+
+   11*) The path change is detected as a Response message from a new
+        downstream GIST peer is received.  A new MA must be established
+        for the requested C-mode.
+
+
+
+Tsenov, et al.                Informational                    [Page 14]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   12*) A new MA is established.  The MRS is installed.  The queued NSLP
+        data is sent.
+
+   13)  T_Refresh_QNode timer expires.  The Query message is sent.
+
+   14)  The NSLP application provides data for sending.  It is sent via
+        Data message towards the downstream GIST peer.
+
+   15)  The Response message from the downstream GIST peer is received.
+        The peer is not changed.  The MRS is refreshed (T_Refresh_QNode
+        timer is restarted).
+
+   16)  The path change is detected as a Response message from a new
+        downstream GIST peer is received.  D-mode is requested, or the
+        existing MA can be reused for the requested C-mode.
+
+   17)  The responding peer indicates that it has not received a Confirm
+        message and it has no established upstream MRS.  The Confirm
+        message is resent.
+
+   18)  A general error or system-level error occurs.  The MRS is
+        deleted.  If not needed, the MA is deleted, too.  The NSLP
+        application is notified of the MRS change.
+
+   Remarks:
+
+   *)  Response and Confirm messages might be sent either in D-mode or
+       C-mode, before or after MA establishment, depending on the node's
+       local three-way handshake policy and the availability of the MAs
+       to be reused.  See [1] for details.
+
+   **) Depending on GIST local policy, NSLPdata might be sent as the
+       payload of Query and Confirm messages (piggybacking).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 15]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+6.3.  State Machine for GIST Responding Node
+
+   The GIST responding node state machine diagram is below.  Transition
+   descriptions follow.
+
+   Please refer to Appendix A.2 for complete transition details
+   (triggering event, action taken, and variable status).
+
+   +-----------+           ooooo
+   | Any State +----------o  14 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  13 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: State Machine for GIST Responding Node
+
+   1) A Query message is received.  The MRS is installed immediately
+      because local policy permits it.  The Query message might carry
+      piggybacked NSLP data that will be provided to the NSLP
+      application.
+
+
+
+Tsenov, et al.                Informational                    [Page 16]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   2) A Query message is received.  Local policy requires an explicit
+      Confirm message for MRS installation.  The Query message might
+      carry piggybacked NSLP data that will be provided to the NSLP
+      application.
+
+   3) T_No_Confirm timer expires.  Note that all cases of lost handshake
+      GIST messages are handled only by the GIST querying node via
+      resend of the Query message.
+
+   4) A Query message is received again.  This means that the sent
+      Response message has not been received by the upstream GIST peer.
+      The Response message is resent.
+
+   5) A Confirm message is received that causes installation of the
+      upstream MRS.
+
+   6) In case of a lost Confirm message, data messages might be received
+      from the upstream GIST node (it is unaware of the lost Confirm
+      message).  A Response message indicating the loss of the Confirm
+      is sent back to the upstream GIST node.
+
+   7) A Query message is received (from either an existing upstream GIST
+      node or a new upstream GIST node) with a request to change the
+      used GIST operation mode (from D-mode/C-mode to C-mode, if
+      available; otherwise, it stays the same).  Local policy requires
+      an explicit Confirm message for MRS installation.
+
+   8) The MRS lifetime expires or the NSLP application notifies that the
+      MRS is no longer needed.  The MRS is deleted.  If used and not
+      needed, the MA is deleted, too.  The NSLP application is notified
+      of the MRS change.
+
+   9) The NSLP application provides data for sending.  NSLP data is sent
+      if the discovery process is successfully accomplished, or it is
+      queued if a Confirm message is still expected to confirm
+      establishment of an MA.
+
+   10) A Query message is received.  If it is sent from a new upstream
+       GIST node, then there is a path change.  Local policy does not
+       need an explicit Confirm message for MRS installation.  The MRS
+       data is updated.
+
+   11) A Query message is received with a request to change the used
+       GIST operation mode (from D-mode/C-mode to C-mode, if available;
+       otherwise, it stays the same).  Local policy does not need an
+       explicit Confirm message for MRS installation.  The MRS data is
+       updated.
+
+
+
+
+Tsenov, et al.                Informational                    [Page 17]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   12) A Data message is received.  Data messages are accepted only if
+       the complete MRS is installed, e.g., the upstream peer info is
+       installed.  If not, then a Confirm message is expected and the
+       Data message is not accepted.  A Response message indicating the
+       loss of the Confirm is sent back to the upstream GIST node.
+
+   13) A Confirm message is received.  It accomplishes assignment of an
+       existing MA (or establishment of a new MA) needed for data
+       transfer between peers.  The information for the used MA is
+       installed as the upstream peer info.
+
+   14) A general error or system-level error occurs.  The MRS is
+       deleted.  If not needed, the MA is deleted, too.  The NSLP
+       application is notified of the MRS change.
+
+7.  Security Considerations
+
+   This document does not raise new security considerations.  Security
+   considerations are addressed in the GIST specification [1] and in
+   [6].
+
+8.  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
+   Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi, and Bernd
+   Schloer for their insightful comments.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
+        Signalling Transport", RFC 5971, October 2010.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+9.2.  Informative References
+
+   [3]  Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State
+        Machines for Extensible Authentication Protocol (EAP) Peer and
+        Authenticator", RFC 4137, August 2005.
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 18]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   [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., Ed., Ohba, Y., and R. Marin-Lopez, "State Machines
+        for the Protocol for Carrying Authentication for Network Access
+        (PANA)", RFC 5609, August 2009.
+
+   [6]  Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
+        Steps in Signaling (NSIS)", RFC 4081, June 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 19]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+Appendix A.  State Transition Tables
+
+   The state transition tables below represent the state diagrams in
+   ASCII format.  Please use the .pdf version whenever possible.  It is
+   the clearer representation of the state machine.
+
+   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 Transition Tables for GIST Querying Node
+
+   Please refer to the state machine diagram in 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   |
+      |                        |                         |
+   ---+------------------------+-------------------------+-----------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 20]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   -----------
+   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
+      |                        |                         |
+   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   |
+      |                        |                         |
+   ---+------------------------+-------------------------+-----------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 21]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   -----------
+   State: Established Downstream MRS
+   -----------
+
+   +Transition
+   |  |Condition               |Action                   |State
+   V--+------------------------+-------------------------+-----------
+   4) |rx_Data                 |IF(CheckPeerInfo)        |Established
+      |                        |      tg_RecvMsg to Appl.|Downstream
+      |                        |                         |MRS
+      |                        |                         |
+   9) |((tg_SendMsg)&&(C-mode) |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.
+      |                        |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)|
+      |                        |                         |
+
+
+
+
+Tsenov, et al.                Informational                    [Page 22]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   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         |
+      |                        |                         |
+   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   |
+      |                        |                         |
+   ---+------------------------+-------------------------+-----------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 23]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+A.2.  State Transition Tables for GIST Responding Node
+
+   Please refer to the state machine diagram in 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
+      |                        |                         |
+   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_Response(No_MRS_      |Wait
+      |                        |               installed)|Confirm
+      |                        |                         |
+
+
+
+Tsenov, et al.                Informational                    [Page 24]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   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
+   -----------
+
+   +Transition
+   |  |Condition               |Action                   |State
+   v--+------------------------+-------------------------+-----------
+   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
+      |                        |                         |
+   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
+      |                        |                         |
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 25]
+
+RFC 5972                   GIST State Machine               October 2010
+
+
+   12)|rx_Data                 |IF(UpstreamPeerInfo)     |Established
+      |                        |    (tg_RecvMsg to Appl.)|Upstream
+      |                        |    &&(restart_T_Expire_ |MRS
+      |                        |                   RNode)|
+      |                        |ELSE                     |
+      |                        |    tx_Error(No_MRS_     |
+      |                        |               installed)|
+      |                        |                         |
+   13)|rx_Confirm              |Install UpstreamPeerInfo |Established
+      |                        |tx_Data(queued_NSLP_data)|Upstream
+      |                        |                         |MRS
+      |                        |                         |
+   14)|(Tg_ERROR)||            |(Delete MRS)             |IDLE
+      |(Tg_MA_Error)           |IF (MA is used)          |
+      |                        |  ((Delete MA)||         |
+      |                        |  (Stop using shared MA))|
+      |                        |Tg_NetworkNotification   |
+      |                        |                         |
+   ---+------------------------+-------------------------+-----------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 26]
+
+RFC 5972                   GIST State Machine               October 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 (editor)
+   University of Goettingen
+   Computer Networks Group
+   Goldschmidtstr. 7
+   Goettingen 37077
+   Germany
+
+   EMail: fu@cs.uni-goettingen.de
+
+
+   Cedric Aoun
+   Consultant
+   Paris, France
+
+   EMail: cedaoun@yahoo.fr
+
+
+   Elwyn B. Davies
+   Folly Consulting
+   Soham, Cambs, UK
+
+   Phone: +44 7889 488 335
+   EMail: elwynd@dial.pipex.com
+
+
+
+
+
+
+
+
+
+
+
+Tsenov, et al.                Informational                    [Page 27]
+