[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fu-nsis-ntlp-statemachine) 00 01 02 03 04 05 06 07 08 09 10 RFC 5972

NSIS                                                           T. Tsenov
Internet-Draft                                             H. Tschofenig
Expires: August 25, 2008                          Nokia Siemens Networks
                                                                   X. Fu
                                                        Univ. Goettingen
                                                                 C. Aoun
                                                               E. Davies
                                                        Folly Consulting
                                                       February 22, 2008

                           GIST State Machine
                draft-ietf-nsis-ntlp-statemachine-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes the state machines for the General Internet
   Signaling Transport (GIST). The states of GIST nodes for a given flow
   and their transitions are presented in order to illustrate how GIST
   may be implemented.






Tsenov, et al.           Expires August 25, 2008                [Page 1]

Internet-Draft             GIST State Machine              February 2008


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 Variables . . . . . . . . . . . . . . . . . . . . .   9
     5.3  Constants  . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.   State machines . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1  Diagram notations  . . . . . . . . . . . . . . . . . . . .  12
     6.2  State machine for GIST querying node . . . . . . . . . . .  12
     6.3  State machine for GIST responding node . . . . . . . . . .  13
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  14
   8.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  15
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  15
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1   Normative References . . . . . . . . . . . . . . . . . .  16
     11.2   Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  ASCII versions of the state diagrams . . . . . . . .  17
     A.1    State machine for GIST querying node (Figure 2)  . . . .  17
     A.2    State Machine for GIST responding node (Figure 3)  . . .  20
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  23
        Intellectual Property and Copyright Statements . . . . . . .  24

























Tsenov, et al.           Expires August 25, 2008                [Page 2]

Internet-Draft             GIST State Machine              February 2008


1.  Introduction

   This document describes the state machines for GIST [1], trying to
   show how GIST can be implemented to support its deployment.  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]
   are authoritative.  The state machines are informative only.
   Implementations may achieve the same results using different methods.

   There are two types of possible entities for GIST signaling:

   - GIST querying node - GIST node that initiates the discovery of the
   next peer;

   - GIST responding node - GIST node that is the discovered next peer;

   We describe a set of state machines for these entities to illustrate
   how GIST may be implemented.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [2].

3.  Notational conventions used in state diagrams

   The following text is reused from [3] and the state diagrams are
   based on the conventions specified in [4], Section 8.2.1.  Additional
   state machine details are taken from [5].

   The complete text is reproduced here:

   State diagrams are used to represent the operation of the protocol by
   a number of cooperating state machines each comprising a group of
   connected, mutually exclusive states.  Only one state of each machine
   can be active at any given time.

   All permissible transitions between states are represented by arrows,
   the arrowhead denoting the direction of the possible transition.
   Labels attached to arrows denote the condition(s) that must be met in
   order for the transition to take place.  All conditions are
   expressions that evaluate to TRUE or FALSE; if a condition evaluates
   to TRUE, then the condition is met.  The label UCT denotes an
   unconditional transition (i.e., UCT always evaluates to TRUE).  A
   transition that is global in nature (i.e., a transition that occurs
   from any of the possible states if the condition attached to the



Tsenov, et al.           Expires August 25, 2008                [Page 3]

Internet-Draft             GIST State Machine              February 2008


   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 remains
   asserted until all state blocks have executed to the point that
   variable assignments and other consequences of their execution remain
   unchanged.

   On entry to a state, the procedures defined for the state (if any)
   are executed exactly once, in the order that they appear on the page.
   Each action is deemed to be atomic; i.e., execution of a procedure
   completes before the next sequential procedure starts to execute.  No
   procedures execute outside of a state block.  The procedures in only
   one state block execute at a time, even if the conditions for
   execution of state blocks in different state machines are satisfied,
   and all procedures in an executing state block complete execution
   before the transition to and execution of any other state block
   occurs, i.e., the execution of any state block appears to be atomic
   with respect to the execution of any other state block and the
   transition condition to that state from the previous state is TRUE
   when execution commences.  The order of execution of state blocks in
   different state machines is undefined except as constrained by their
   transition conditions.  A variable that is set to a particular value
   in a state block retains this value until a subsequent state block
   executes a procedure that modifies the value.

   On completion of all of the procedures within a state, all exit
   conditions for the state (including all conditions associated with
   global transitions) are evaluated continuously until one of the
   conditions is met.  The label ELSE denotes a transition that occurs
   if none of the other conditions for transitions from the state are
   met (i.e., ELSE evaluates to TRUE if all other possible exit
   conditions from the state evaluate to FALSE).  Where two or more exit
   conditions with the same level of precedence become TRUE
   simultaneously, the choice as to which exit condition causes the
   state transition to take place is arbitrary.

   In addition to the above notation, there are a couple of
   clarifications specific to this document.  First, all boolean
   variables are initialized to FALSE before the state machine execution
   begins.  Second, the following notational shorthand is specific to
   this document:

   <variable> = <expression1> | <expression2> | ...

      Execution of a statement of this form will result in <variable>
      having a value of exactly one of the expressions.  The logic for



Tsenov, et al.           Expires August 25, 2008                [Page 4]

Internet-Draft             GIST State Machine              February 2008


      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

   MA
      Messaging Association

   Upstream/Downstream MRS
      Message Routing State with upstream/downstream peer state info

   ( )
      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.           Expires August 25, 2008                [Page 5]

Internet-Draft             GIST State Machine              February 2008


   !=
      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 the [1], such as
   Query, Response, Confirm.

   State machine represents handling of GIST messages that match a
   Message Routing State's MRI, NSLPID and SID and with no protocol
   errors. Separate parallel instances of the state machines should
   handle messages for different Message Routing States.

   The state machine states represent the upstream/downstream peers
   states of the Message Routing State.

   For simplification not all objects included in a message are shown.
   Only those that are significant for the case are shown.  State
   machines do not present handling of messages that are not significant
   for management of the states.

   Presented in this document state machines do not cover all functions
   of a GIST node.  Functionality of message forwarding, ROA processing,
   transmission of NSLP data without MRS establishment and providing of



Tsenov, et al.           Expires August 25, 2008                [Page 6]

Internet-Draft             GIST State Machine              February 2008


   the received messages to the appropriate MRS, we refer as "Lower
   level pre-processing" step.  The interaction of this step with the
   presented here state machines is defined as follows:

   Pre-processing provides to the appropriate MRS FSM only the messages
   which are matched against waiting Query/Response cookies, or
   established MRS MRI+NSLPID+SID primary key.  This is presented by
   "rx_*" events in the state machines.

5.1  Common Procedures

   Tg_SendMsg:
      NSLP/GIST API message that request transmission of a NSLP message.

   Tg_SetStateLifetime(time_period):
      NSLP/GIST API message providing info for the Lifetime of an RS,
      required by the application. "Time_period = 0" represents the
      cancellation of established RSs/MAs (invoked by NSLP application).

   Tg_MessageStatus:
      NSLP/GIST API message informing NSLP application of unsuccessful
      delivery of a message

   Tg_RecvMsg:
      NSLP/GIST API message that provides received message to the NSLP

   Tg_NetworkNotification:
      NSLP/GIST API message that informs NSLP for change in MRS

   Tx_Query:
      Transmit of Query message

   Tx_Response:
      Transmit of Response message

   Tx_Confirm:
      Transmit of Confirm message

   Rx_Query:
      Receive of Query message

   Rx_Response:
      Receive of Response message

   Rx_Confirm:
      Receive of Confirm message

   Tx_Error:



Tsenov, et al.           Expires August 25, 2008                [Page 7]

Internet-Draft             GIST State Machine              February 2008


      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:
      Transmit of Data message

   Rx_Data:
      Receive of Data message

   T_Inactive_QNode:
      Message Routing State lifetime timer in Querying Node

   T_Expired_RNode:
      Message Routing State lifetime timer in Responding Node

   T_Refresh_QNode:
      Message Routing State refresh timer in Querying Node

   T_No_Response:
      Timer for the waiting period for Response message in Querying Node

   T_No_Confirm:
      Timer for the waiting period for Confirm message in Responding
      Node

   Install downstream/upstream MRS:
      Install new Message Routing State and save the corespoding peer
      state info (IP address and UDP port or pointer to the used MA) for
      the current Message Routing State or update the coresponding peer
      state info.

   DELETE MRS:
      Delete installed downstream/upstream peer's info for the current
      Message Routing State and delete the Message Routing State if
      required.

   Established MA:
      A Message Association (MA) is established between the current node
      and its upstream peer.  The initiator for the establishment is the
      upstream peer.  Re-use existing MA: An existing MA between the
      current node and its peer is re-used.




Tsenov, et al.           Expires August 25, 2008                [Page 8]

Internet-Draft             GIST State Machine              February 2008


   DELETE MA:
      Delete/disconnect used MA.

   Stop using shared MA:
      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
      or kept.

   REFRESH MRS:
      Refreshes installed MRS.

   Tg_MA_Error:
      Error event with used MA.

   Tg_InvalidRoutingState:
      Notification from NSLP application for path change

   Tg_Establish_MA:
      Trigers establishment of MA.

   Tg_MA_Established:
      MA has been successfully established.

   Tg_ERROR:
      General Error event / system level error.

   No_MRS_Installed:
      Error response, send by the Responding node indicating lost
      Confirm message.

5.2  Common Variables

   It is assumed that the type of mode and destination info (which need
   to be taken from the application parameters and local GIST policy)is
   provided.  This is represented by the common variables Dmode, Cmode,
   MAinfo, MApresent and Refresh.

   Cmode:
      The message MUST be transmitted in Cmode.  This is specified by
      "Message transfer attributes" set to any of the following values:

      "Reliability" is set to TRUE.

      "Security" is set to values that request secure handling of a
      message.

      "Local processing" is set to values that require services offered
      by Cmode (e.g., congestion control). [1]



Tsenov, et al.           Expires August 25, 2008                [Page 9]

Internet-Draft             GIST State Machine              February 2008


   Dmode:
      The message MUST be transmitted in Dmode.  This is specified by
      local policy rules and in case that the "Message transfer
      attributes" are not set to any of the following values:

      "Reliability" is set to TRUE.

      "Security" is set to values that request special security handling
         of a message.

      "Local processing" is set to values that require services offered
         by Cmode [1]

   MAinfo:
      GIST message parameters describing the required MA or proposed MA
      e.g. "Stack-proposal" and "Stack-Configuration-Data".

   NSLPdata:
      NSLP application data.

   RespCookie:
      Responder Cookie that is being sent by the Responding node with
      the Response message in case that its local policy requires a
      confirmation from the querying node.

   ConfirmRequired:
      Confirm message is required by the local policy rule for
      installation of the new MRS.

   NewPeer:
      Response message is received from new responding peer.

   MAexist:
      Existing MA will be reused.

   CheckPeerInfo:
      The sender of the received data message is matched against the
      installed peer info in the MRS.

   UpstreamPeerInstalled:
      Upstream peer info is installed in the MRS.


5.3  Constants







Tsenov, et al.           Expires August 25, 2008               [Page 10]

Internet-Draft             GIST State Machine              February 2008


6.  State machines

   The following section presents the state machine diagrams of GIST
   peers.

6.1  Diagram notations

              (see the .pdf version for missing diagram or
            refer to Appendix A if reading the .txt version)

                      Figure 1: Diagram notations

6.2  State machine for GIST querying node

   The following is a diagram of the GIST querying node state machine.
   Also included is clarification of notation.

              (see the .pdf version for missing diagram or
           refer to Appendix A.1 if reading the .txt version)

               Figure 1: GIST Querying Node State Machine

   *) Response and Comfirm messages might be send either in Dmode or
      Cmode, before or after MA establishment depending on nodes local
      3-way handshake policy and the availability of MAs to be reused.
      See draft for details.
   **) Depending on the local policy NSLPdata might be send as payload
      of Query and Confirm messages. (piggybacking)
   1) Initial request from NSLP is received, which triggers Query
      messages requesting either D_mode or C_mode. Depending on nodes
      local policy NSLP data might be piggybacked in the Query
      requesting D_mode. Query may carry Mainfo if C_mode transport is
      needed.
   2) Response message is received. If C_mode connection must be
      established and there is no available MA to be reused, MA
      establishment is initiated and waited to be completed.
   3) Response message is received. If D_mode connection is requested or
      available MA can be reused for requested C_mode, the MRS is
      established.
   4) No_Response timer expires. Query is resent.
   5) No_Response timer expires and maximum number of retries has been
      reached. NSLP application is notified for the GIST peer discovery
      failure.
   6) NSLP data is queued, because downstream peer is not discovered or
      required MA is still not established.
   7) Data message is received. It is checked if its sender matches the
      installed downstream peer info in the MRS and then processed. In
      WaitResponse state, this event might happen in the process of MA



Tsenov, et al.           Expires August 25, 2008               [Page 11]

Internet-Draft             GIST State Machine              February 2008


      upgrade, when the downstream peer is still not aware of
      establishment of the new MA.
   8) Provided NSLP data is sent via Data message towards downstream
      GIST peer.
   9) Refresh_QNode timer expires. Query message is sent.
   10) Response message from the downstream GIST peer is received. The
      peer is not changed. MRS is refreshed (Refresh_QNode timer is
      restarted).
   11) Path change detected. Response message from a new downstream GIST
      peer is received. D_mode is requested or existing MA can be reused
      for requested C_mode.
   12) Path change detected. Response message from a new downstream GIST
      peer is received. A new MA must be established for requested
      C_mode.
   13) Requested by NSLP application transport parameters requires
      upgrade of established MRS from D_mode/C_mode to C_mode. NSLP
      application notifies GIST for path change. Downstream GIST peer
      discovery is initiated.
   14) Sent Confirm message has not been received by downstream GIST
      peer. Confirm message is resent.
   15) MRS lifetime expires. Notification by NSLP application that MRS
      is no longer needed.
   16) MA is established.
   17) MA establishment failure.

6.3  State machine for GIST responding node

   The following is a diagram of the GIST responding node state machine.
   Also included is clarification of notation.

              (see the .pdf version for missing diagram or
           refer to Appendix A.2 if reading the .txt version)

              Figure 3: GIST Responding Node State Machine

   1) A Query message is received. Explicit Confirm message is required
      for MRS installation, based on the local policy. Query message
      might carry piggybacked NSLP data which is provided to the NSLP
      application.
   2)  A Query message is received. MRS is installed immediately, based
      on the local policy. Query message might carry piggybacked NSLP
      data which is provided to the NSLP application.
   3) Confirm message is received which causes installation of the
      complete MRS or just installation of the used MA as a upstream
      peer info.
   4) Sent Response message has not been received by upstream GIST peer.
      Response message is resent.
   5)  In case of lost Confirm message, data messages might be received



Tsenov, et al.           Expires August 25, 2008               [Page 12]

Internet-Draft             GIST State Machine              February 2008


      from the upstream GIST node (it is unaware of the lost Confirm
      message). Response indicating the loss of the Confirm is sent back
      to the upstream GIST node.
   6) No_Confirm timer expires. Note that all cases of lost handshake
      GIST messages are handled only by GIST querying node via resend of
      Query message.
   7) NSLP data is sent if discovery process is successfully
      accomplished or is queued if Confirm message is still expected to
      confirm establishment of MA.
   8) Data messages are accepted only if complete MRS is installed,
      e.g., there is installed upstream peer info. If not, then Confirm
      message is expected and data message wont be accepted. Response
      indicating the loss of the Confirm is sent back to the upstream
      GIST node.
   9) Change of the upstream GIST node (e.g., path change). Local policy
      does not need explicit Confirm message for MRS installation. MRS
      data is updated.
   10) Change of the upstream GIST node or request for change of the
      used connection mode (from D_mode/C_mode to better C_mode). Local
      policy requires explicit Confirm message for MRS installation.
   11) Request for change of the used connection mode (from
      D_mode/C_mode to better C_mode). Local policy does not need
      explicit Confirm message for MRS installation. MRS data is
      updated.
   12)  MRS lifetime expires. Notification by NSLP application that MRS
      is no longer needed.

8.  Security Considerations

   This document does not raise new security considerations. Any
   security concerns with GIST are likely reflected in security related
   NSIS work already (such as [1] or [6]).

9.  Open Issues

   We have left for further version of the document the following
   issues:

   1. The FSM that handles the management of a MA is considered in the
      document (e.g., tg_Establish_MA, tg_MA_established events), but it
      is not currently explicitely presented.  It is left for future
      version of the document.
   2. Functionality of, as referred in the document "Lower level pre-
      processing" (Section 5), namely message forwarding, RAO
      processing, transmission of NSLP data without MRS establishment
      and providing of the received messages to the appropriate MRS is
      left for future version of the document.




Tsenov, et al.           Expires August 25, 2008               [Page 13]

Internet-Draft             GIST State Machine              February 2008


10.  Contributors

   Christian Dickmann contributed to refining of the state machine since
   01 version.

11.  Acknowledgments

   The authors would like to thank Robert Hancock, Ingo Juchem, Andreas
   Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd
   Schloer for their insightful comments.









































Tsenov, et al.           Expires August 25, 2008               [Page 14]

Internet-Draft             GIST State Machine              February 2008


12.  References

12.1.  Normative References

   [1]         Schulzrinne, H., "GIST: General Internet Signaling
               Transport", draft-ietf-nsis-ntlp-15 (work in progress),
               February 2008.

   [2]         Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [3]         Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
               "State Machines for Extensible Authentication Protocol
               (EAP) Peer and Authenticator", draft-ietf-eap-
               statemachine-06 (work in progress), December 2004.

   [4]         Institute of Electrical and Electronics Engineers, "DRAFT
                Standard for Local and Metropolitan Area Networks: Port-
               Based
                Network Access Control (Revision)", IEEE 802-1X-REV/D11,
               July 2004.

   [5]         Ohba, Y., "State Machines for Protocol for Carrying
               Authentication for Network Access  (PANA)",
                draft-ohba-pana-statemachine-01 (work in progress),
               February 2005.

   [6]         Tschofenig, H. and D. Kroeselberg, "Security Threats for
               NSIS", draft-ietf-nsis-threats-06 (work in progress),
               October 2004.



















Tsenov, et al.           Expires August 25, 2008               [Page 15]

Internet-Draft             GIST State Machine              February 2008


Appendix A. ASCII versions of state diagrams

   This appendix contains the state diagrams in ASCII format.  Please
   use the PDF version whenever possible: it is much easier to
   understand.

   For each state there is a separate table that lists in each row:
   - an event that triggers a transition,
   - actions taken as a result of the incoming event,
   - and the new state at which the transitions ends.

A.1.  State machine for GIST querying node (Figure 2)

-----------
State: IDLE
-----------

Condition                Action                    State      Note
------------------------+-------------------------+-----------+---
tg_SendMsg              |tx_Query                 |Wait       |1)
                        |start T_No_Response      |Response   |**
                        |Queue NSLP data          |           |
                        |                         |           |
Tg_ERROR                |Delete MRS               |IDLE       |
                        |IF (MA is used)          |           |
                        |  ((Delete MA)||         |           |
                        |  (Stop using shared MA))|           |
                        |Tg_NetworkNotification   |           |
                        |                         |           |
------------------------+-------------------------+-----------+---



-----------
State: WaitResponse
-----------

Condition                Action                    State      Note
------------------------+-------------------------+-----------+---
rx_Response(MAinfo)&&   |tg_Establish_MA          |Wait MA    |*
(!MAexist)              |(tx_Confirm)             |Establish. |2)
                        |                         |           |
                        |                         |           |
rx_Response)||          |Install MRS              |Established|3)
(rx_Response(MAinfo)&&  |IF (RespCookie)          |Downstream |
(MAexist))              |   tx_Confirm(RespCookie)|MRS        |
                        |tx_Data(Queued NSLP data)|           |
                        |                         |           |



Tsenov, et al.           Expires August 25, 2008               [Page 16]

Internet-Draft             GIST State Machine              February 2008


(timeout T_No_Response) |Tx_Query                 |Wait       |4)
&&(!MaxRetry)           |restart T_No_Response    |Response   |
                        |                         |           |
(timeout T_No_Response) |tg_MessageStatus         |IDLE       |5)
&&(MaxRetry)            |                         |           |
                        |                         |           |
tg_SendMsg              |Queue NSLP data          |Wait       |6)
                        |                         |Response   |
                        |                         |           |
rx_Data                 |IF(CheckPeerInfo)        |Wait       |7)
                        |      tg_RecvMsg to Appl.|Response   |
                        |                         |           |
Tg_ERROR                |(Delete MRS)             |IDLE       |
                        |IF (MA is used)          |           |
                        |  ((Delete MA)||         |           |
                        |  (Stop using shared MA))|           |
                        |Tg_NetworkNotification   |           |
                        |                         |           |
------------------------+-------------------------+-----------+---





-----------
State: Established Downstream MRS
-----------

Condition                Action                    State      Note
------------------------+-------------------------+-----------+---
tg_SendMsg              |tx_Data                  |Established|8)
                        |restart T_Inactive_QNode |Downstream |
                        |                         |MRS        |
                        |                         |           |
timeout T_Refresh_QNode |tx_Query                 |Established|9)
                        |                         |Downstream |
                        |                         |MRS        |
                        |                         |           |
(rx_Response)&&         |Refresh MRS              |Established|10)
(!NewPeer)              |restart T_Inactive_QNode |Downstream |
                        |                         |MRS        |
                        |                         |           |
(rx_Response)||         |IF (MA is used)          |Established|11)
(rx_Response(Mainfo)&&  |   (Delete MA)||         |Downstream |
(MAexist)))&&(NewPeer)  |   (Stop using shared MA)|MRS        |
                        |Install MRS              |           |
                        |restart T_Inactive_QNode |           |
                        |IF (RespCookie)          |           |



Tsenov, et al.           Expires August 25, 2008               [Page 17]

Internet-Draft             GIST State Machine              February 2008


                        |   tx_Confirm(RespCookie)|           |
                        |                         |           |
(rx_Response(MAinfo)&&  |((Delete MA)||           |Wait MA    |12)
(NewPeer)&&(!MA_exist)) |(Stop using shared MA))  |Establish. |*
                        |tg_Establish_MA          |           |
                        |(tx_Confirm)             |           |
                        |                         |           |
((tg_SendMsg)&&(Cmode)&&|tx_Query                 |Wait       |13)
(!MAexist))||           |Queue NSLP data          |Response   |
(tg_MA_error)||         |                         |           |
(tg_InvalidRoutingState)|                         |           |
                        |                         |           |
rx_Response(No_MRS_     |tx_Confirm(RespCookie)   |Established|14)
              installed)|tx_Data(Queued NSLP data)|Downstream |
                        |                         |MRS        |
                        |                         |           |
(timeout T_Inactive_    |Delete MRS               |IDLE       |15)
                QNode)|||IF (MA is used)          |           |
(tg_SetStateLifetime(0))|   (Delete MA)||         |           |
                        |   (Stop using shared MA)|           |
                        |Tg_NetworkNotification   |           |
                        |                         |           |
rx_Data                 |IF(CheckPeerInfo)        |Established|7)
                        |      tg_RecvMsg to Appl.|Downstream |
                        |                         |MRS        |
                        |                         |           |
Tg_ERROR                |(Delete MRS)             |IDLE       |
                        |IF (MA is used)          |           |
                        |  ((Delete MA)||         |           |
                        |  (Stop using shared MA))|           |
                        |Tg_NetworkNotification   |           |
                        |                         |           |
------------------------+-------------------------+-----------+---



-----------
State: Wait MA Establishment
-----------

Condition                Action                    State      Note
------------------------+-------------------------+-----------+---
tg_MA_Established       |Install MRS              |Established|16)
                        |(tx_Confirm)             |Downstream |*
                        |tx_Data(Queued NSLP data)|MRS        |
                        |                         |           |
tg_MA_error             |Delete MRS               |IDLE       |17)
                        |tg_MessageStatus         |           |



Tsenov, et al.           Expires August 25, 2008               [Page 18]

Internet-Draft             GIST State Machine              February 2008


                        |                         |           |
tg_SendMsg              |Queue NSLP data          |Wait MA    |6)
                        |                         |Establish. |
                        |                         |           |
Tg_ERROR                |Delete MRS               |IDLE       |
                        |IF (MA is used)          |           |
                        |  ((Delete MA)||         |           |
                        |  (Stop using shared MA))|           |
                        |Tg_NetworkNotification   |           |
                        |                         |           |
------------------------+-------------------------+-----------+---

                                Figure 4

A.2.  State Machine for GIST responding node (Figure 3)

-----------
State: IDLE
-----------

Condition                Action                    State      Note
------------------------+-------------------------+-----------+---
rx_Query&&              |tx_Response              |Wait       |1)
(ConfirmRequired)       |start T_No_Confirm       |Confirm    |
                        |IF(NSLPdata)             |           |
                        |     tg_RecvMsg(NSLPdata)|           |
                        |                 to Appl.|           |
                        |                         |           |
rx_Query&&              |tx_Response              |Established|2)
(!ConfirmRequired)      |Install MRS              |Upstream   |
                        |IF(NSLPdata)             |MRS        |
                        |     tg_RecvMsg(NSLPdata)|           |
                        |                 to Appl.|           |
                        |                         |           |
------------------------+-------------------------+-----------+---



-----------
State: WAIT CONFIRM
-----------

Condition                Action                    State      Note
------------------------+-------------------------+-----------+---
rx_Confirm              |Install Upstream MRS     |Established|3)
                        |                         |Upstream   |
                        |                         |MRS        |
                        |                         |           |



Tsenov, et al.           Expires August 25, 2008               [Page 19]

Internet-Draft             GIST State Machine              February 2008


rx_Query&&              |tx_Response              |Wait       |4)
(ConfirmRequired)       |start T_No_Confirm       |Confirm    |
                        |IF(NSLPdata)             |           |
                        |     tg_RecvMsg(NSLPdata)|           |
                        |                 to Appl.|           |
                        |                         |           |
rx_Data                 |tx_Error(No_MRS_         |Wait       |5)
                        |               installed)|Confirm    |
                        |                         |           |
timeout T_No_Confirm    |                         |IDLE       |6)
                        |                         |           |
------------------------+-------------------------+-----------+---



-----------
State: Established Upstream MRS
-----------

Condition                Action                    State      Note
------------------------+-------------------------+-----------+---
tg_SendMsg              |IF(!UpstreamPeerInfo)    |Established|7)
                        |    Queue NSLP data      |Upstream   |
                        |ELSE tx_Data             |MRS        |
                        |                         |           |
rx_Data                 |IF(UpstreamPeerInfo)     |Established|8)
                        |    (tg_RecvMsg to Appl.)|Upstream   |
                        |    &&(restart_T_Expire_ |MRS        |
                        |                   RNode)|           |
                        |ELSE                     |           |
                        |    tx_Error(No_MRS_     |           |
                        |               installed)|           |
                        |                         |           |
rx_Query                |IF (NewPeer)             |Established|9)
                        |  Update UpstreamPeerInfo|Upstream   |
                        |tx_Response              |MRS        |
                        |restart T_Expire_RNode   |           |
                        |                         |           |
(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.|           |
                        |                         |           |



Tsenov, et al.           Expires August 25, 2008               [Page 20]

Internet-Draft             GIST State Machine              February 2008


rx_Query(MAinfo)&&      |Delete UpstreamPeerInfo  |Established|11)
(!ConfirmRequired)      |restart T_Expire_RNode   |Upstream   |
                        |tx_Response(MAinfo)      |MRS        |
                        |                         |           |
(timeout T_Expire_RNode)|Delete MRS               |IDLE       |12)
||                      |tg_NetworkNotification   |           |
(tg_SetStateLifetime(0))|IF(MA is used)           |           |
                        |   (Delete MA)||         |           |
                        |   (Stop using shared MA)|           |
                        |                         |           |
rx_Confirm              |Install UpstreamPeerInfo |Established|3)
                        |tx_Data(queued_NSLP_data)|Upstream   |
                        |                         |MRS        |
                        |                         |           |
Tg_ERROR                |(Delete MRS)             |IDLE       |
                        |IF (MA is used)          |           |
                        |  ((Delete MA)||         |           |
                        |  (Stop using shared MA))|           |
                        |Tg_NetworkNotification   |           |
                        |                         |           |
------------------------+-------------------------+-----------+---

                                Figure 5




























Tsenov, et al.           Expires August 25, 2008               [Page 21]

Internet-Draft             GIST State Machine              February 2008


Authors' Addresses

   Tseno Tsenov
   Sofia,
   Bulgaria

   Email: tseno.tsenov@mytum.de


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Email: Hannes.Tschofenig@nsn.com


   Xiaoming Fu
   University of Goettingen
   Computer Networks Group
   Lotzestr. 16-18
   Goettingen  37083
   Germany

   Email: fu@cs.uni-goettingen.de


   Cedric Aoun
   Paris
   France

   Email: cedric@caoun.net


   Elwyn B. Davies
   Folly Consulting
   Soham, Cambs
   UK

   Phone: +44 7889 488 335
   Email: elwynd@dial.pipex.com









Tsenov, et al.           Expires August 25, 2008               [Page 22]

Internet-Draft             GIST State Machine              February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).






Tsenov, et al.           Expires August 25, 2008               [Page 23]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/