NSIS T. Tsenov Internet-Draft H. Tschofenig Expires: August 25, 2005 Siemens X. Fu Univ. Goettingen C. Aoun Nortel E. Davies Folly Consulting February 21, 2005 GIMPS State Machine draft-fu-nsis-ntlp-statemachine-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Tsenov, et al. Expires August 25, 2005 [Page 1] Internet-Draft GIMPS State Machine February 2005 This document describes the state machines for the General Internet Messaging Protocol for Signaling (GIMPS). The states of GIMPS nodes for a given flow and their transitions are presented in order to illustrate how GIMPS may be implemented. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Notational conventions used in state diagrams . . . . . . . 5 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 7 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 9 5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Default state machines for soft state handling . . . . . . . 11 7. State machine for the first GIMPS node in the flow path . . 12 8. State machines for intermediate GIMPS nodes . . . . . . . . 15 8.1 GIMSP intermediate node state machine . . . . . . . . . . 15 8.2 GIMPS intermediate node. State machine for refresh of soft states and waiting timeouts events . . . . . . . . . 15 8.3 GIMPS intermediate node. State machine for soft state deletion transition . . . . . . . . . . . . . . . . . . . 18 9. State machine for the last GIMPS node in the flow path . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . 23 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1 Normative References . . . . . . . . . . . . . . . . . . 26 13.2 Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . 28 Tsenov, et al. Expires August 25, 2005 [Page 2] Internet-Draft GIMPS State Machine February 2005 1. Introduction This document describes the state machines for GIMPS [1], trying to show how GIMPS can be implemented to support its deployment. The state machines described in this document are illustrative of how the GIMPS protocol defined in [1] may be implemented for the GIMPS 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 3 types of possible entities for GIMPS signaling: The first node that speaks GIMPS in the path from FlowSender to the FlowReceiver (it is assumed that it has only downstream MessageRoutingState(MRS) which MAY use MessagingAssociation(MA) for the given flow); Intermediate GIMPS node; The last node that speaks GIMPS in the path from the FlowSender to the FlowReceiver (it is assumed that it has only upstream MessageRoutingState which MAY use MessagingAssociation(MA) for the given flow). We describe a set of state machines for these entities to illustrate how GIMPS may be implemented. Tsenov, et al. Expires August 25, 2005 [Page 3] Internet-Draft GIMPS State Machine February 2005 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]. Tsenov, et al. Expires August 25, 2005 [Page 4] Internet-Draft GIMPS State Machine February 2005 3. Notational conventions used in state diagrams The following text is reused from [3] and the state diagrams are based on the conventions specified in [4], Section 8.2.1. Additional state machine details are taken from [5]. The complete text is reproduced here: State diagrams are used to represent the operation of the protocol by a number of cooperating state machines each comprising a group of connected, mutually exclusive states. Only one state of each machine can be active at any given time. All permissible transitions between states are represented by arrows, the arrowhead denoting the direction of the possible transition. Labels attached to arrows denote the condition(s) that must be met in order for the transition to take place. All conditions are expressions that evaluate to TRUE or FALSE; if a condition evaluates to TRUE, then the condition is met. The label UCT denotes an unconditional transition (i.e., UCT always evaluates to TRUE). A transition that is global in nature (i.e., a transition that occurs from any of the possible states if the condition attached to the arrow is met) is denoted by an open arrow; i.e., no specific state is 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 Tsenov, et al. Expires August 25, 2005 [Page 5] Internet-Draft GIMPS State Machine February 2005 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: = | | ... Execution of a statement of this form will result in 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. Tsenov, et al. Expires August 25, 2005 [Page 6] Internet-Draft GIMPS State Machine February 2005 4. State Machine Symbols *_up means the message is sent in upstream direction or received from upstream direction *_down means the message is sent in downstream direction or received from downstream direction MA means "Messaging Association" Upstream/Downstream MRS: means "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 language conventions for reading text. = Assignment action. The value of the expression to the right of the operator is assigned to the variable to the left of the operator. Where this operator is used to define multiple assignments, e.g., a = b = X the action causes the value of the expression following the right-most assignment operator to be assigned to all of the variables that appear to the left of the right-most assignment operator. ! Logical NOT operator. && Logical AND operator. || Logical OR operator. if...then... Conditional action. If the Boolean expression following the if evaluates to TRUE, then the action following the then is executed. \{ statement 1, ... statement N \} Compound statement. Braces are used to group statements that are executed together as if they were a single statement. != Inequality. Evaluates to TRUE if the expression to the left of the operator is not equal in value to the expression to the right. == Equality. Evaluates to TRUE if the expression to the left of the operator is equal in value to the expression to the right. > 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. UCT Creation of a new state machine when the NSLP application creates a new session. This is propagated through all the NSIS nodes as the first Query message traverses the path. Tsenov, et al. Expires August 25, 2005 [Page 7] Internet-Draft GIMPS State Machine February 2005 5. Common Rules Throughout the document we use terms defined in the [1], such as Query, Response, Confirm. State machine represents handling of GIMPS messages that match a Message Routing State's MRI and NSLPID 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. Since the peer states have separate maintenance for refreshment and expiration we decided that it is a appropriate to explicitly assign them to different state machine states. 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. 5.1 Common Procedures Tg_SendMsg: NSLP/GIMPS API message that requests transmission of a NSLP message Tg_SetStateLifetime(time_period): NSLP/GIMPS 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_MessageDeliveryError: NSLP/GIMPS API message informing NSLP application of unsuccessful delivery of a message Tg_RecvMsg: NSLP/GIMPS API message that provides received message to the NSLP Tg_NetworkNotification: NSLP/GIMPS API message that informs NSLP of a change in MRS Tx_Query_Dmode: Transmit Query message in Dmode Tx_Response_Dmode: Transmit Response message in Dmode Tx_Confirm_Dmode: Transmit Confirm message in Dmode Rx_Query_Dmode: Reception of Query message in Dmode Rx_Response_Dmode: Reception of Response message in Dmode Rx_Confirm_Cmode: Reception of Confirm message in Dmode Tx_Response_Cmode: Transmit Response message in Cmode (via MA) Tx_Confirm_Cmode: Transmit Confirm message in Cmode (via MA) Rx_Response_Cmode: Reception of Response message in Cmode (via MA) Rx_Confirm_Cmode: Reception of Confirm message in Cmode (via MA) Tsenov, et al. Expires August 25, 2005 [Page 8] Internet-Draft GIMPS State Machine February 2005 Queue NSLP msg info: Save NLSP messages in a queue until a required MA association is established Tx_Msg_Cmode: Transmit message in Cmode (via MA) Rx_Msg_Cmode: Reception of message in Cmode (via MA) Tx_Msg_Dmode: Transmit message in Dmode Rx_Msg_Dmode: Reception of message in Dmode TIMEOUT_MRSlifetime: Expiration of the lifetime timer of the upstream/downstream peer state info of the Message Routing State. TIMEOUT_MRS+MA_lifetime: Expiration of the lifetime timer of the upstream/downstream peer state info of the Message Routing State, where MA is used. TIMEOUT_Refresh: Refresh interval timer expiration TIMEOUT_WaitResponse: Expiration of Timer for the waiting period for Response message TIMEOUT_WaitConfirm: Expiration of Timer for the waiting period for Confirm message Install downstream/upstream MRS: Install new Message Routing State and save the corespoding peer state info or for the current Message Routing State, update the coresponding peer state info. For upstream peer, peer state info could be an IP address and UDP port and for downstream peer it is null. It will be used for Datagram mode. Install upstream/downstream MRS+MA: Install new Message Routing State and save the pointer to the used MA into the corespoding peer state info or for the current Message Routing State, update the coresponding peer state info with the pointer to the used MA. It will be used for Connection mode. DELETE MRS: Delete installed downstream/upstream peer's info for the current Message Routing State and delete the Message Routing State if required. Establish MA: Establish Message Association (MA) between current node and its downstream peer Established MA: A Message Association (MA) is established between the current node and its upstream peer. The initiator for the establishment is the upstream peer. Re-use existing MA: An existing MA between the current node and its peer is re-used DELETE MA: Delete/disconnect used MA Stop using shared MA: Stop using shared MA. If the shared MA is no more used by any other MRSs, it depends on the local policy whether it is deleted or kept. REFRESH MRS: Refreshes installed MRS SetRespCookie: Based on node's local policy the ResponderCookie is set in the Response message that is being sent. 5.2 Common Variables It is assumed that the type of mode and destination info (which need Tsenov, et al. Expires August 25, 2005 [Page 9] Internet-Draft GIMPS State Machine February 2005 to be taken from the application parameters and local GIMPS policy) is provided. This is represented by the common variables Dmode, Cmode, MAinfo, MApresent and Refresh. Dmode: The message MUST be transmitted in Dmode. This is specified by "Message transfer attributes" set to the following values: Reliability: is set to FALSE Security: is set to values that do not request special security handling of a message. Local processing: is set to values that do not require services offered by Cmode [1] 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] MApresent: Used for re-use of MAs. It shows that there is a perfect match between the Node Addressing Object (NAO) of an existing association and the NAO provided in the GIMPS Query Dmode message (section 4.4.2 of [1]). MAinfo: GIMPS message parameters describing the required MA or proposed MA e.g. "Stack-proposal" and "Node-addressing". This list of GIMPS parameters is not complete. A full mapping is left for future version of the document. 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. Refresh: This variable specifies that the message is for refresh purposes Downstream: Specifies that message must be sent in downstream direction Upstream: Specifies that message must be sent in upstream direction. MaxRetry Specifies that multiple TIMEOUT_WaitResponse or TIMEOUT_WaitConfirm events have occurred and the sum of the amounts of time waited by during these timeouts exceeds the maximum time set to wait for the connection to be established. Exponential backoff is specified so that the timeouts increase for each repeat. 5.3 Constants Tsenov, et al. Expires August 25, 2005 [Page 10] Internet-Draft GIMPS State Machine February 2005 6. Default state machines for soft state handling This section presents the default state machines for any "established MRS state" in a GIMPS nodes. Whenever possible, they are not repeated in subsequent sections for simplicity. ------------------- State: State_Estab ------------------- Condition Action State ------------------------+-------------------------+------------ (tg_SendMsg) && (Cmode) |tx_Msg_Cmode_up |State_Estab && (Upstream) | | | | (tg_SendMsg) && (Cmode) |tx_Msg_Cmode_down |State_Estab && (Downstream) | | | | (tg_SendMsg) && (Dmode) |tx_Msg_Dmode_up |State_Estab && (Upstream) | | | | (tg_SendMsg) && (Dmode) |tx_Msg_Dmode_down |State_Estab && (Downstream) | | | | rx_Msg_Dmode |Refresh RS |State_Estab | tg_RecvMsg to Appl. | | | rx_Msg_Cmode |Refresh RS and MRS |State_Estab | tg_RecvMsg to Appl. | ------------------------+-------------------------+------------ Tsenov, et al. Expires August 25, 2005 [Page 11] Internet-Draft GIMPS State Machine February 2005 7. State machine for the first GIMPS node in the flow path ----------- State: INIT ----------- Condition Action State ------------------------+-------------------------+------------ UCT | initialize variables |IDLE ------------------------+-------------------------+------------ ----------- State: IDLE ----------- Condition Action State ------------------------+-------------------------+------------- (tg_SendMsg) && (Dmode) |tx_Query_Dmode(NSLPdata) |WAITRESP2 | | (tg_SendMsg) && (Cmode) |tx_Query_Dmode(MArequest)|WAITRESP1 | Queue NSLP msg data | ------------------------+-------------------------+------------- ---------------- State: WAITRESP1 ---------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_WaitResponse)&&|tg_MessageDeliveryError |IDLE (MaxRetry) | | | | ((rx_Response_Dmode |tx_Confirm_Cmode, |DownMRS_Estab (MAinfo)) && | tx_queued_Msg_cmode, |+DownMA_Estab (Establish MA)) || | install MRS+MA | (rx_Response_Cmode | | (MAinfo)) && | | (Re-use existing MA))| | | | (TIMEOUT_WaitResponse)&&|tx_Query_Dmode_down |WAITRESP1 (!MaxRetry) | | ------------------------+-------------------------+------------ Tsenov, et al. Expires August 25, 2005 [Page 12] Internet-Draft GIMPS State Machine February 2005 ---------------- State: WAITRESP2 ---------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_WaitResponse)&&|tg_MessageDeliveryError |IDLE (MaxRetry) | | | | (rx_Response_Dmode |if (respCookie) |DownMRS_Estab (Response Cookie) | (tx_confirm_Dmode && | | install MRS) | | | (TIMEOUT_WaitResponse)&&|tx_Query_Dmode_down |WAITRESP2 (!MaxRetry) | (NSLP_Data) | ------------------------+-------------------------+------------ -------------------------------------------------------------- State: UpMRS_Estab + UpMA_Estab + DownMRS_Estab + DownMA_Estab -------------------------------------------------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_MRSLifetime)|| |Delete MRSs, |IDLE (tg_SetStateLifetime(0))| ((Delete MA) || (Stop | | using shared MA))**, | | tg_Network Notification | | | (TIMEOUT_Refresh) |* |UpMARS_Estab | |+UpMA_Estab+ | |DownMRS_Esta | |+DownMA_Esta ------------------------+-------------------------+------------ Note: * Open issue: How is the refresh of MRS that uses MA handled? For refreshment, only Dmode msgs are used? (-04 spec p.26/Sec 4.4.3). ** Depending on local policy. Tsenov, et al. Expires August 25, 2005 [Page 13] Internet-Draft GIMPS State Machine February 2005 -------------------- STATE: DownMRS_Estab -------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_MRSLifetime)|| |Delete MRS, |IDLE (tg_SetStateLifetime(0))| tg_Network Notification | | | (Timeout_Refresh) |tx_Query_Dmode(Refresh) |DownMRS_Estab | | (rx_Response_Dmode |Refresh MRS |DownMRS_Estab (Refresh)) | | | | (rx_Response_Dmode |tx_Confirm_Dmode |DownMRS_Estab (RespCookie)) | (RespCookie) | ------------------------+-------------------------+------------ Tsenov, et al. Expires August 25, 2005 [Page 14] Internet-Draft GIMPS State Machine February 2005 8. State machines for intermediate GIMPS nodes 8.1 GIMSP intermediate node state machine gimps_node_intermediate diagram placed here 8.2 GIMPS intermediate node. State machine for refresh of soft states and waiting timeouts events The state machine represents actions taken in case of the following events: - Timeout Refresh events for established MRS - Timeout events for waiting states - Reception of refresh messages - Reception of resent messages ------------------ State: WaitConfirm ------------------ Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_WaitConfirm) &&|tg_NetworkNotification, |WaitConfirm (!MaxRetry) | (tx_Response_Dmode_up | | (RespCookie))|| | | (tx_Response_Dmode_up | | (MAinfo)) || | | (tx_Response_Cmode_up | | (MAinfo)) || | | | (TIMEOUT_WaitConfirm) &&|tg_MessageDeliveryError |IDLE (MaxRetry) | | ------------------------+-------------------------+------------ Tsenov, et al. Expires August 25, 2005 [Page 15] Internet-Draft GIMPS State Machine February 2005 ---------------------------------- State: UpMRS_Estab + DownMRS_Estab ---------------------------------- Condition Action State ------------------------+-------------------------+------------ rx_Query_Dmode_up |Refresh UpMRS, |UpMRS_Estab+ (Refresh) | tx_Response_up(Refresh) |DownMRS_Esta | | rx_Query_Dmode_down |Refresh downMRS, |UpMRS_Estab+ (Refresh) |tx_Response_down(Refresh)|DownMRS_Esta | | (TIMEOUT_Refresh) |tx_Query_Dmode_down |WaitConfirm+ | (Refresh) |DownMRS_Esta ------------------------+-------------------------+------------ ------------------------------------------------- State: UpMRS_Estab + DownMRS_Estab + DownMA_Estab ------------------------------------------------- Condition Action State ------------------------+-------------------------+------------ rx_Query_Dmode_up |Refresh UpMRS, |UpMRS_Estab+ (Refresh) | tx_Response_up(Refresh) |DownMRS_Esta | |+DownMA_Esta | | (TIMEOUT_Refresh) |* |UpMRS_Estab+ | |DownMRS_Esta | |+DownMA_Esta ------------------------+-------------------------+------------ Note: * Open issue: How is the refresh of MRS that uses MA handled? For refreshment, only Dmode msgs are used? (-04 spec p.26/Sec 4.4.3). -------------------------------------------------------------- State: UpMRS_Estab + UpMA_Estab + DownMRS_Estab + DownMA_Estab -------------------------------------------------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_Refresh) |* |UpMARS_Estab | |+UpMA_Estab+ | |DownMRS_Esta | |+DownMA_Esta ------------------------+-------------------------+------------ Note: * Open issue: How is the refresh of MRS that uses MA Tsenov, et al. Expires August 25, 2005 [Page 16] Internet-Draft GIMPS State Machine February 2005 handled? For refreshment, only Dmode msgs are used? (-04 spec p.26/Sec 4.4.3). ------------------------------------------------- State: UpMRS_Estab + UpMA_Estab + DownMRS_Estab ------------------------------------------------- Condition Action State ------------------------+-------------------------+------------ rx_Query_Dmode_up |Refresh DownMRS |UpMRS_Estab+ (Refresh) | | UpMA_Estab+ | |DownMRS_Esta | | (TIMEOUT_Refresh) |tx_Query_Dmode_down |UpMRS_Estab+ | (Refresh) | UpMA_Estab+ | |DownMRS_Esta ------------------------+-------------------------+------------ ------------------ State: UpMRS_Estab ------------------ Condition Action State ------------------------+-------------------------+------------ rx_Query_Dmode_up |Refresh UpMRS |UpMRS_Estab (Refresh) | tx_Response_up(Refresh) | | | ------------------------+-------------------------+------------ Tsenov, et al. Expires August 25, 2005 [Page 17] Internet-Draft GIMPS State Machine February 2005 ----------------------------------------- State: UpMRS_Estab + WaitResp_for_DownMRS ----------------------------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_WaitResponse)&&|tg_NetworkNotification, |UpMRS_Estab (MaxRetry) | | | | (TIMEOUT_WaitResponse)&&|tx_Query_Dmode_down |UpMRS_Estab (!MaxRetry) | (NSLPinfo) | + | | WaitResp_ | | for_DownMRS | | rx_Query_Dmode_up |Refresh UpMRS |UpMRS_Estab (Refresh) | tx_Response_up(Refresh) | + | | WaitResp_ | | for_DownMRS ------------------------+-------------------------+------------ ---------------------------------------------- State: UpMRS+UpMA_Estab + WaitResp_for_DownMRS ---------------------------------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_WaitResponse)&&|tg_NetworkNotification, |UpMRS_Estab (MaxRetry) | (tx_Response_Dmode_up |+UpMA_Estab | (RespCookie))|| | | (tx_Response_Dmode_up | | (MAinfo)) || | | (tx_Response_Cmode_up | | (MAinfo)) || | | | (TIMEOUT_WaitResponse)&&|tx_Query_Dmode_down |UpMRS+UpMA_ (!MaxRetry) | (NSLPinfo) | Estab + | | WaitResp_ | | for_DownMRS ------------------------+-------------------------+------------ 8.3 GIMPS intermediate node. State machine for soft state deletion transition The state machine represents the deletion transition from any bi/uni-directional ESTABLISHED state to IDLE or uni-directional state in the Intermediate GIMPS node. Since in GIMPS there can be Tsenov, et al. Expires August 25, 2005 [Page 18] Internet-Draft GIMPS State Machine February 2005 different combinations of MRS (established or not) and MRS+MA (established or not) states in both DIRECTIONs (up- and downstream), there are 8 sub-states in total, all being soft states (subject to expiration unless refreshes). The combination of different state variables, are not fully elaborated here for simplicity. ---------------- STATE: MRS_Estab ---------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_MRSLifetime)|| |Delete MRS, |IDLE (tg_SetStateLifetime(0))| tg_Network Notification | ------------------------+-------------------------+------------ ---------------------------- STATE: MRS_Estab + MRS_Estab ---------------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_MRSLifetime)* |Delete MRSs, |MRS_Estab | tg_Network Notification | | | tg_SetStateLifetime(0) |Delete MRS, |IDLE | tg_Network Notification | ------------------------+-------------------------+------------ Note: * This transition goes to MRS established state only for the other DIRECTION. ------------------- STATE: MRS_MA_Estab ------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_MRSLifetime)|| |Delete MRSs, |IDLE (tg_SetStateLifetime(0))|(Delete MA)||(Stop | | using shared MA))*, | | tg_Network Notification | ------------------------+-------------------------+------------ Note: ** Which one of the either action should be taken depends on local policy in the node. Tsenov, et al. Expires August 25, 2005 [Page 19] Internet-Draft GIMPS State Machine February 2005 ------------------------------- STATE: MRS_Estab + MRS_MA_Estab ------------------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_MRS+MALifetime)*|Delete MRSs, |MRS_Estab | ((Delete MA) || (Stop | | using shared MA))**, | | tg_Network Notification | | | (TIMEOUT_MRSLifetime)*** |Delete MRS, |MRS_MA_Estab | tg_Network Notification | | | tg_SetStateLifetime(0) |Delete MRSs, |IDLE | ((Delete MA) || (Stop | | using shared MA))**, | | tg_Network Notification | ------------------------+-------------------------+------------ Note: * This transition goes to MRS established state only for the other DIRECTION. ** Which one of the either action should be taken depends on local policy in the node. ***This transition goes to MRS+MA established state only for the other DIRECTION. ------------------------------- STATE: MRS_Estab + MRS_MA_Estab ------------------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_MRS+MALifetime)*|Delete MRSs, |MRS_MA_Estab | ((Delete MA) || (Stop | | using shared MA))**, | | tg_Network Notification | | | tg_SetStateLifetime(0) |Delete MRSs, |IDLE | ((Delete MA) || (Stop | | using shared MA))**, | | tg_Network Notification | ------------------------+-------------------------+------------ Note: * This transition goes to MRS+MA established state only for the other DIRECTION. ** Which one of the either action should be taken depends on local policy in the node. Tsenov, et al. Expires August 25, 2005 [Page 20] Internet-Draft GIMPS State Machine February 2005 9. State machine for the last GIMPS node in the flow path ----------- State: INIT ----------- Condition Action State ------------------------+-------------------------+------------ UCT | initialize variables |IDLE ------------------------+-------------------------+------------ ----------- State: IDLE ----------- Condition Action State ------------------------+-------------------------+------------- (rx_Query_Dmode_up |Re-use existing MA, |WaitConfirm (MAinfo)) && | tx_Response_Dmode_up | (MApresent) | | | | rx_Query_Dmode_up |tg_RecvMsg(NSLP info) to |WaitConfirm (NSLPinfo) && | Appl., tx_Response_Dmode| (SetRespCookie) | (RespCookie) | | | rx_Query_Dmode |tx_Response_Dmode(MAinfo)|WaitConfirm (!MArequest) | | | | (rx_Query_Dmode_up |tg_RecvMsg to App., |WaitConfirm (MArequest)) && | tx_Response_Dmode_up | (!MApresent) | (MAinfo), Establish RS | | | rx_Query_Dmode_up |tg_RecvMsg(NSLP info) to |UpMRS_Estab (NSLPinfo) && | Appl.,tx_Response_Dmode,| (!SetRespCookie) | Install MRS | ------------------------+-------------------------+------------- Tsenov, et al. Expires August 25, 2005 [Page 21] Internet-Draft GIMPS State Machine February 2005 --------------------- State: UpMRS_MA_Estab --------------------- Condition Action State ------------------------+-------------------------+------------ (TIMEOUT_RSstate) || |Delete MRS, (*(Delete MA)|IDLE (tg_SetStateLifeTime(0))|||(Stop using sharedMA)),| |tg_NetworkNotification | ------------------------+-------------------------+------------ Note: * Which one of the either action should be taken depends on local policy in the node. ----------------- State: UpMRS_Estab (Upstream MRS Established) ----------------- Condition Action State ------------------------+-------------------------+------------ (Timeout_MRSLifetime)|| |Delete MRS, |IDLE (tg_SetStateLifetime(0))| tg_NetworkNotification | | | rx_Query_Dmode_up |Refresh UpMRS |UpMRS_Estab (Refresh) | tx_Response_up(Refresh) | ------------------------+-------------------------+------------ ------------------ State: WaitConfirm (waiting for the handshake completion) ------------------ Condition Action State ------------------------+-------------------------+------------ (Timeout_WaitConfirm)&& |tg_NetworkNotification |IDLE (MaxRetry) | | | | rx_Confirm_Dmode_up |Install UpMRS |UpMRS_Estab | | (Timeout_WaitConfirm)&& |(tx_Response_Cmode |WaitConfirm (!MaxRetry) |(MAinfo))||(tx_Response_ | |Dmode(RespCookie))|| | |(tx_Response_Dmode(MAinfo)| ------------------------+-------------------------+------------ Tsenov, et al. Expires August 25, 2005 [Page 22] Internet-Draft GIMPS State Machine February 2005 10. Security Considerations This document does not raise new security considerations. Any security concerns with GIMPS are likely reflected in security related NSIS work already (such as [1] or [6]). For the time being, the state machines described in this document do not consider the security aspect of GMIPS protocol itself. A future versions of this document will add security relevant states and state transitions. Tsenov, et al. Expires August 25, 2005 [Page 23] Internet-Draft GIMPS State Machine February 2005 11. Open Issues Refreshment of Messaging Association (MA) state is currently not elaborated in the document (according to current GIMPS spec, there can be an idle timer but tearing down a MA can depend on a node's local policy). Piggybacking of NSLP data in the discovery Query message in Datagram mode. When it is possible? Currently we assume that piggybacking is used when a Datagram mode is used (but for no cookie cases). Further consideration needs to check whether piggybacking and usage of Query/Response cookie could be combined. Handling of lost GIMPS-Confirm message. It is an open issue in the GIMPS draft. Currently we provide retransmission of the Response message, which is not desired due to DoS attack vulnerability. This issue may require further consideration in the base specification. Route change and local repair mechnanisms need further consideration. At this stage, normal GIMPS messages that carry NSLP data are not presented for all states. A default rules for handling of such messages at any "ESTABLISHED STATE" is provided. Messages exchanged through NSLP/GIMPS API are not completely described, too. These issues, together with bypassing handling, are left for future versions of the document. We assume that the node closest to the flow receiver is the data sender node. If it is not (i.e., proxy mode), how does a NSIS node know that it is the nearest to the flow receiver? Tsenov, et al. Expires August 25, 2005 [Page 24] Internet-Draft GIMPS State Machine February 2005 12. Acknowledgments The authors would like to thank Robert Hancock, Ingo Juchem, Andreas Westermaier, Alexander Zrim, Julien Abeille and Youssef Abidi for their insightful comments. Tsenov, et al. Expires August 25, 2005 [Page 25] Internet-Draft GIMPS State Machine February 2005 13. References 13.1 Normative References [1] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", Internet-Draft draft-ietf-nsis-ntlp-04, October 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 13.2 Informative References [3] Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", Internet-Draft draft-ietf-eap-statemachine-06, 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/D9, January 2004. [5] Ohba, Y., "State Machines for Protocol for Carrying Authentication for Network Access (PANA)", Internet-Draft draft-ohba-pana-statemachine-01, February 2005. [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", Internet-Draft draft-ietf-nsis-threats-06, October 2004. Authors' Addresses Tseno Tsenov Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: tseno.tsenov@mytum.de Tsenov, et al. Expires August 25, 2005 [Page 26] Internet-Draft GIMPS State Machine February 2005 Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: Hannes.Tschofenig@siemens.com Xiaoming Fu University of Goettingen Telematics Group Lotzestr. 16-18 Goettingen 37083 Germany Email: fu@cs.uni-goettingen.de Cedric Aoun Nortel France Email: cedric.aoun@nortel.com Elwyn B. Davies Folly Consulting Soham, Cambs UK Phone: +44 7889 488 335 Email: elwynd@dial.pipex.com Tsenov, et al. Expires August 25, 2005 [Page 27] Internet-Draft GIMPS State Machine February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Tsenov, et al. Expires August 25, 2005 [Page 28]