idnits 2.17.1 draft-ietf-nsis-ntlp-statemachine-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 979. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2008) is 5908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS T. Tsenov 3 Internet-Draft H. Tschofenig 4 Expires: August 25, 2008 Nokia Siemens Networks 5 X. Fu 6 Univ. Goettingen 7 C. Aoun 8 E. Davies 9 Folly Consulting 10 February 22, 2008 12 GIST State Machine 13 draft-ietf-nsis-ntlp-statemachine-05.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 25, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes the state machines for the General Internet 47 Signaling Transport (GIST). The states of GIST nodes for a given flow 48 and their transitions are presented in order to illustrate how GIST 49 may be implemented. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Notational conventions used in state diagrams . . . . . . . 3 56 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 5 57 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 7 59 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 9 60 5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6. State machines . . . . . . . . . . . . . . . . . . . . . . . 12 62 6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 12 63 6.2 State machine for GIST querying node . . . . . . . . . . . 12 64 6.3 State machine for GIST responding node . . . . . . . . . . 13 65 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 66 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 67 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 11.1 Normative References . . . . . . . . . . . . . . . . . . 16 71 11.2 Informative References . . . . . . . . . . . . . . . . . 16 72 Appendix A. ASCII versions of the state diagrams . . . . . . . . 17 73 A.1 State machine for GIST querying node (Figure 2) . . . . 17 74 A.2 State Machine for GIST responding node (Figure 3) . . . 20 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 76 Intellectual Property and Copyright Statements . . . . . . . 24 78 1. Introduction 80 This document describes the state machines for GIST [1], trying to 81 show how GIST can be implemented to support its deployment. The 82 state machines described in this document are illustrative of how the 83 GIST protocol defined in [1] may be implemented for the GIST nodes in 84 different locations of a flow path. Where there are differences [1] 85 are authoritative. The state machines are informative only. 86 Implementations may achieve the same results using different methods. 88 There are two types of possible entities for GIST signaling: 90 - GIST querying node - GIST node that initiates the discovery of the 91 next peer; 93 - GIST responding node - GIST node that is the discovered next peer; 95 We describe a set of state machines for these entities to illustrate 96 how GIST may be implemented. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [2]. 104 3. Notational conventions used in state diagrams 106 The following text is reused from [3] and the state diagrams are 107 based on the conventions specified in [4], Section 8.2.1. Additional 108 state machine details are taken from [5]. 110 The complete text is reproduced here: 112 State diagrams are used to represent the operation of the protocol by 113 a number of cooperating state machines each comprising a group of 114 connected, mutually exclusive states. Only one state of each machine 115 can be active at any given time. 117 All permissible transitions between states are represented by arrows, 118 the arrowhead denoting the direction of the possible transition. 119 Labels attached to arrows denote the condition(s) that must be met in 120 order for the transition to take place. All conditions are 121 expressions that evaluate to TRUE or FALSE; if a condition evaluates 122 to TRUE, then the condition is met. The label UCT denotes an 123 unconditional transition (i.e., UCT always evaluates to TRUE). A 124 transition that is global in nature (i.e., a transition that occurs 125 from any of the possible states if the condition attached to the 126 arrow is met) is denoted by an open arrow; i.e., no specific state is 127 identified as the origin of the transition. When the condition 128 associated with a global transition is met, it supersedes all other 129 exit conditions including UCT. The special global condition BEGIN 130 supersedes all other global conditions, and once asserted remains 131 asserted until all state blocks have executed to the point that 132 variable assignments and other consequences of their execution remain 133 unchanged. 135 On entry to a state, the procedures defined for the state (if any) 136 are executed exactly once, in the order that they appear on the page. 137 Each action is deemed to be atomic; i.e., execution of a procedure 138 completes before the next sequential procedure starts to execute. No 139 procedures execute outside of a state block. The procedures in only 140 one state block execute at a time, even if the conditions for 141 execution of state blocks in different state machines are satisfied, 142 and all procedures in an executing state block complete execution 143 before the transition to and execution of any other state block 144 occurs, i.e., the execution of any state block appears to be atomic 145 with respect to the execution of any other state block and the 146 transition condition to that state from the previous state is TRUE 147 when execution commences. The order of execution of state blocks in 148 different state machines is undefined except as constrained by their 149 transition conditions. A variable that is set to a particular value 150 in a state block retains this value until a subsequent state block 151 executes a procedure that modifies the value. 153 On completion of all of the procedures within a state, all exit 154 conditions for the state (including all conditions associated with 155 global transitions) are evaluated continuously until one of the 156 conditions is met. The label ELSE denotes a transition that occurs 157 if none of the other conditions for transitions from the state are 158 met (i.e., ELSE evaluates to TRUE if all other possible exit 159 conditions from the state evaluate to FALSE). Where two or more exit 160 conditions with the same level of precedence become TRUE 161 simultaneously, the choice as to which exit condition causes the 162 state transition to take place is arbitrary. 164 In addition to the above notation, there are a couple of 165 clarifications specific to this document. First, all boolean 166 variables are initialized to FALSE before the state machine execution 167 begins. Second, the following notational shorthand is specific to 168 this document: 170 = | | ... 172 Execution of a statement of this form will result in 173 having a value of exactly one of the expressions. The logic for 174 which of those expressions gets executed is outside of the state 175 machine and could be environmental, configurable, or based on 176 another state machine such as that of the method. 178 4. State Machine Symbols 180 MA 181 Messaging Association 183 Upstream/Downstream MRS 184 Message Routing State with upstream/downstream peer state info 186 ( ) 187 Used to force the precedence of operators in Boolean expressions 188 and to delimit the argument(s) of actions within state boxes. 190 ; 191 Used as a terminating delimiter for actions within state boxes. 192 Where a state box contains multiple actions, the order of 193 execution follows the normal English language conventions for 194 reading text. 196 = 197 Assignment action. The value of the expression to the right of 198 the operator is assigned to the variable to the left of the 199 operator. Where this operator is used to define multiple 200 assignments, e.g., a = b = X the action causes the value of the 201 expression following the right-most assignment operator to be 202 assigned to all of the variables that appear to the left of the 203 right-most assignment operator. 205 ! 206 Logical NOT operator. 208 && 209 Logical AND operator. 211 || 212 Logical OR operator. 214 if...then... 215 Conditional action. If the Boolean expression following the if 216 evaluates to TRUE, then the action following the then is executed. 218 { statement 1, ... statement N } 219 Compound statement. Braces are used to group statements that are 220 executed together as if they were a single statement. 222 != 223 Inequality. Evaluates to TRUE if the expression to the left of 224 the operator is not equal in value to the expression to the right. 226 == 227 Equality. Evaluates to TRUE if the expression to the left of the 228 operator is equal in value to the expression to the right. 230 > 231 Greater than. Evaluates to TRUE if the value of the expression to 232 the left of the operator is greater than the value of the 233 expression to the right. 235 <= 236 Less than or equal to. Evaluates to TRUE if the value of the 237 expression to the left of the operator is either less than or 238 equal to the value of the expression to the right. 240 ++ 241 Increment the preceding integer operator by 1. 243 + 244 Arithmetic addition operator. 246 & 247 Bitwise AND operator. 249 5. Common Rules 251 Throughout the document we use terms defined in the [1], such as 252 Query, Response, Confirm. 254 State machine represents handling of GIST messages that match a 255 Message Routing State's MRI, NSLPID and SID and with no protocol 256 errors. Separate parallel instances of the state machines should 257 handle messages for different Message Routing States. 259 The state machine states represent the upstream/downstream peers 260 states of the Message Routing State. 262 For simplification not all objects included in a message are shown. 263 Only those that are significant for the case are shown. State 264 machines do not present handling of messages that are not significant 265 for management of the states. 267 Presented in this document state machines do not cover all functions 268 of a GIST node. Functionality of message forwarding, ROA processing, 269 transmission of NSLP data without MRS establishment and providing of 270 the received messages to the appropriate MRS, we refer as "Lower 271 level pre-processing" step. The interaction of this step with the 272 presented here state machines is defined as follows: 274 Pre-processing provides to the appropriate MRS FSM only the messages 275 which are matched against waiting Query/Response cookies, or 276 established MRS MRI+NSLPID+SID primary key. This is presented by 277 "rx_*" events in the state machines. 279 5.1 Common Procedures 281 Tg_SendMsg: 282 NSLP/GIST API message that request transmission of a NSLP message. 284 Tg_SetStateLifetime(time_period): 285 NSLP/GIST API message providing info for the Lifetime of an RS, 286 required by the application. "Time_period = 0" represents the 287 cancellation of established RSs/MAs (invoked by NSLP application). 289 Tg_MessageStatus: 290 NSLP/GIST API message informing NSLP application of unsuccessful 291 delivery of a message 293 Tg_RecvMsg: 294 NSLP/GIST API message that provides received message to the NSLP 296 Tg_NetworkNotification: 297 NSLP/GIST API message that informs NSLP for change in MRS 299 Tx_Query: 300 Transmit of Query message 302 Tx_Response: 303 Transmit of Response message 305 Tx_Confirm: 306 Transmit of Confirm message 308 Rx_Query: 309 Receive of Query message 311 Rx_Response: 312 Receive of Response message 314 Rx_Confirm: 315 Receive of Confirm message 317 Tx_Error: 319 Transmit of Error message 321 Rx_Error: 322 Receive of Error message 324 Queue NSLP info: 325 Save NLSP messages in a queue until a required MA association is 326 established 328 Tx_Data: 329 Transmit of Data message 331 Rx_Data: 332 Receive of Data message 334 T_Inactive_QNode: 335 Message Routing State lifetime timer in Querying Node 337 T_Expired_RNode: 338 Message Routing State lifetime timer in Responding Node 340 T_Refresh_QNode: 341 Message Routing State refresh timer in Querying Node 343 T_No_Response: 344 Timer for the waiting period for Response message in Querying Node 346 T_No_Confirm: 347 Timer for the waiting period for Confirm message in Responding 348 Node 350 Install downstream/upstream MRS: 351 Install new Message Routing State and save the corespoding peer 352 state info (IP address and UDP port or pointer to the used MA) for 353 the current Message Routing State or update the coresponding peer 354 state info. 356 DELETE MRS: 357 Delete installed downstream/upstream peer's info for the current 358 Message Routing State and delete the Message Routing State if 359 required. 361 Established MA: 362 A Message Association (MA) is established between the current node 363 and its upstream peer. The initiator for the establishment is the 364 upstream peer. Re-use existing MA: An existing MA between the 365 current node and its peer is re-used. 367 DELETE MA: 368 Delete/disconnect used MA. 370 Stop using shared MA: 371 Stop using shared MA. If the shared MA is no more used by any 372 other MRSs, it depends on the local policy whether it is deleted 373 or kept. 375 REFRESH MRS: 376 Refreshes installed MRS. 378 Tg_MA_Error: 379 Error event with used MA. 381 Tg_InvalidRoutingState: 382 Notification from NSLP application for path change 384 Tg_Establish_MA: 385 Trigers establishment of MA. 387 Tg_MA_Established: 388 MA has been successfully established. 390 Tg_ERROR: 391 General Error event / system level error. 393 No_MRS_Installed: 394 Error response, send by the Responding node indicating lost 395 Confirm message. 397 5.2 Common Variables 399 It is assumed that the type of mode and destination info (which need 400 to be taken from the application parameters and local GIST policy)is 401 provided. This is represented by the common variables Dmode, Cmode, 402 MAinfo, MApresent and Refresh. 404 Cmode: 405 The message MUST be transmitted in Cmode. This is specified by 406 "Message transfer attributes" set to any of the following values: 408 "Reliability" is set to TRUE. 410 "Security" is set to values that request secure handling of a 411 message. 413 "Local processing" is set to values that require services offered 414 by Cmode (e.g., congestion control). [1] 416 Dmode: 417 The message MUST be transmitted in Dmode. This is specified by 418 local policy rules and in case that the "Message transfer 419 attributes" are not set to any of the following values: 421 "Reliability" is set to TRUE. 423 "Security" is set to values that request special security handling 424 of a message. 426 "Local processing" is set to values that require services offered 427 by Cmode [1] 429 MAinfo: 430 GIST message parameters describing the required MA or proposed MA 431 e.g. "Stack-proposal" and "Stack-Configuration-Data". 433 NSLPdata: 434 NSLP application data. 436 RespCookie: 437 Responder Cookie that is being sent by the Responding node with 438 the Response message in case that its local policy requires a 439 confirmation from the querying node. 441 ConfirmRequired: 442 Confirm message is required by the local policy rule for 443 installation of the new MRS. 445 NewPeer: 446 Response message is received from new responding peer. 448 MAexist: 449 Existing MA will be reused. 451 CheckPeerInfo: 452 The sender of the received data message is matched against the 453 installed peer info in the MRS. 455 UpstreamPeerInstalled: 456 Upstream peer info is installed in the MRS. 458 5.3 Constants 459 6. State machines 461 The following section presents the state machine diagrams of GIST 462 peers. 464 6.1 Diagram notations 466 (see the .pdf version for missing diagram or 467 refer to Appendix A if reading the .txt version) 469 Figure 1: Diagram notations 471 6.2 State machine for GIST querying node 473 The following is a diagram of the GIST querying node state machine. 474 Also included is clarification of notation. 476 (see the .pdf version for missing diagram or 477 refer to Appendix A.1 if reading the .txt version) 479 Figure 1: GIST Querying Node State Machine 481 *) Response and Comfirm messages might be send either in Dmode or 482 Cmode, before or after MA establishment depending on nodes local 483 3-way handshake policy and the availability of MAs to be reused. 484 See draft for details. 485 **) Depending on the local policy NSLPdata might be send as payload 486 of Query and Confirm messages. (piggybacking) 487 1) Initial request from NSLP is received, which triggers Query 488 messages requesting either D_mode or C_mode. Depending on nodes 489 local policy NSLP data might be piggybacked in the Query 490 requesting D_mode. Query may carry Mainfo if C_mode transport is 491 needed. 492 2) Response message is received. If C_mode connection must be 493 established and there is no available MA to be reused, MA 494 establishment is initiated and waited to be completed. 495 3) Response message is received. If D_mode connection is requested or 496 available MA can be reused for requested C_mode, the MRS is 497 established. 498 4) No_Response timer expires. Query is resent. 499 5) No_Response timer expires and maximum number of retries has been 500 reached. NSLP application is notified for the GIST peer discovery 501 failure. 502 6) NSLP data is queued, because downstream peer is not discovered or 503 required MA is still not established. 504 7) Data message is received. It is checked if its sender matches the 505 installed downstream peer info in the MRS and then processed. In 506 WaitResponse state, this event might happen in the process of MA 507 upgrade, when the downstream peer is still not aware of 508 establishment of the new MA. 509 8) Provided NSLP data is sent via Data message towards downstream 510 GIST peer. 511 9) Refresh_QNode timer expires. Query message is sent. 512 10) Response message from the downstream GIST peer is received. The 513 peer is not changed. MRS is refreshed (Refresh_QNode timer is 514 restarted). 515 11) Path change detected. Response message from a new downstream GIST 516 peer is received. D_mode is requested or existing MA can be reused 517 for requested C_mode. 518 12) Path change detected. Response message from a new downstream GIST 519 peer is received. A new MA must be established for requested 520 C_mode. 521 13) Requested by NSLP application transport parameters requires 522 upgrade of established MRS from D_mode/C_mode to C_mode. NSLP 523 application notifies GIST for path change. Downstream GIST peer 524 discovery is initiated. 525 14) Sent Confirm message has not been received by downstream GIST 526 peer. Confirm message is resent. 527 15) MRS lifetime expires. Notification by NSLP application that MRS 528 is no longer needed. 529 16) MA is established. 530 17) MA establishment failure. 532 6.3 State machine for GIST responding node 534 The following is a diagram of the GIST responding node state machine. 535 Also included is clarification of notation. 537 (see the .pdf version for missing diagram or 538 refer to Appendix A.2 if reading the .txt version) 540 Figure 3: GIST Responding Node State Machine 542 1) A Query message is received. Explicit Confirm message is required 543 for MRS installation, based on the local policy. Query message 544 might carry piggybacked NSLP data which is provided to the NSLP 545 application. 546 2) A Query message is received. MRS is installed immediately, based 547 on the local policy. Query message might carry piggybacked NSLP 548 data which is provided to the NSLP application. 549 3) Confirm message is received which causes installation of the 550 complete MRS or just installation of the used MA as a upstream 551 peer info. 552 4) Sent Response message has not been received by upstream GIST peer. 553 Response message is resent. 554 5) In case of lost Confirm message, data messages might be received 555 from the upstream GIST node (it is unaware of the lost Confirm 556 message). Response indicating the loss of the Confirm is sent back 557 to the upstream GIST node. 558 6) No_Confirm timer expires. Note that all cases of lost handshake 559 GIST messages are handled only by GIST querying node via resend of 560 Query message. 561 7) NSLP data is sent if discovery process is successfully 562 accomplished or is queued if Confirm message is still expected to 563 confirm establishment of MA. 564 8) Data messages are accepted only if complete MRS is installed, 565 e.g., there is installed upstream peer info. If not, then Confirm 566 message is expected and data message wont be accepted. Response 567 indicating the loss of the Confirm is sent back to the upstream 568 GIST node. 569 9) Change of the upstream GIST node (e.g., path change). Local policy 570 does not need explicit Confirm message for MRS installation. MRS 571 data is updated. 572 10) Change of the upstream GIST node or request for change of the 573 used connection mode (from D_mode/C_mode to better C_mode). Local 574 policy requires explicit Confirm message for MRS installation. 575 11) Request for change of the used connection mode (from 576 D_mode/C_mode to better C_mode). Local policy does not need 577 explicit Confirm message for MRS installation. MRS data is 578 updated. 579 12) MRS lifetime expires. Notification by NSLP application that MRS 580 is no longer needed. 582 8. Security Considerations 584 This document does not raise new security considerations. Any 585 security concerns with GIST are likely reflected in security related 586 NSIS work already (such as [1] or [6]). 588 9. Open Issues 590 We have left for further version of the document the following 591 issues: 593 1. The FSM that handles the management of a MA is considered in the 594 document (e.g., tg_Establish_MA, tg_MA_established events), but it 595 is not currently explicitely presented. It is left for future 596 version of the document. 597 2. Functionality of, as referred in the document "Lower level pre- 598 processing" (Section 5), namely message forwarding, RAO 599 processing, transmission of NSLP data without MRS establishment 600 and providing of the received messages to the appropriate MRS is 601 left for future version of the document. 603 10. Contributors 605 Christian Dickmann contributed to refining of the state machine since 606 01 version. 608 11. Acknowledgments 610 The authors would like to thank Robert Hancock, Ingo Juchem, Andreas 611 Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd 612 Schloer for their insightful comments. 614 12. References 616 12.1. Normative References 618 [1] Schulzrinne, H., "GIST: General Internet Signaling 619 Transport", draft-ietf-nsis-ntlp-15 (work in progress), 620 February 2008. 622 [2] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 11.2. Informative References 627 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 628 "State Machines for Extensible Authentication Protocol 629 (EAP) Peer and Authenticator", draft-ietf-eap- 630 statemachine-06 (work in progress), December 2004. 632 [4] Institute of Electrical and Electronics Engineers, "DRAFT 633 Standard for Local and Metropolitan Area Networks: Port- 634 Based 635 Network Access Control (Revision)", IEEE 802-1X-REV/D11, 636 July 2004. 638 [5] Ohba, Y., "State Machines for Protocol for Carrying 639 Authentication for Network Access (PANA)", 640 draft-ohba-pana-statemachine-01 (work in progress), 641 February 2005. 643 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for 644 NSIS", draft-ietf-nsis-threats-06 (work in progress), 645 October 2004. 647 Appendix A. ASCII versions of state diagrams 649 This appendix contains the state diagrams in ASCII format. Please 650 use the PDF version whenever possible: it is much easier to 651 understand. 653 For each state there is a separate table that lists in each row: 654 - an event that triggers a transition, 655 - actions taken as a result of the incoming event, 656 - and the new state at which the transitions ends. 658 A.1. State machine for GIST querying node (Figure 2) 660 ----------- 661 State: IDLE 662 ----------- 664 Condition Action State Note 665 ------------------------+-------------------------+-----------+--- 666 tg_SendMsg |tx_Query |Wait |1) 667 |start T_No_Response |Response |** 668 |Queue NSLP data | | 669 | | | 670 Tg_ERROR |Delete MRS |IDLE | 671 |IF (MA is used) | | 672 | ((Delete MA)|| | | 673 | (Stop using shared MA))| | 674 |Tg_NetworkNotification | | 675 | | | 676 ------------------------+-------------------------+-----------+--- 678 ----------- 679 State: WaitResponse 680 ----------- 682 Condition Action State Note 683 ------------------------+-------------------------+-----------+--- 684 rx_Response(MAinfo)&& |tg_Establish_MA |Wait MA |* 685 (!MAexist) |(tx_Confirm) |Establish. |2) 686 | | | 687 | | | 688 rx_Response)|| |Install MRS |Established|3) 689 (rx_Response(MAinfo)&& |IF (RespCookie) |Downstream | 690 (MAexist)) | tx_Confirm(RespCookie)|MRS | 691 |tx_Data(Queued NSLP data)| | 692 | | | 694 (timeout T_No_Response) |Tx_Query |Wait |4) 695 &&(!MaxRetry) |restart T_No_Response |Response | 696 | | | 697 (timeout T_No_Response) |tg_MessageStatus |IDLE |5) 698 &&(MaxRetry) | | | 699 | | | 700 tg_SendMsg |Queue NSLP data |Wait |6) 701 | |Response | 702 | | | 703 rx_Data |IF(CheckPeerInfo) |Wait |7) 704 | tg_RecvMsg to Appl.|Response | 705 | | | 706 Tg_ERROR |(Delete MRS) |IDLE | 707 |IF (MA is used) | | 708 | ((Delete MA)|| | | 709 | (Stop using shared MA))| | 710 |Tg_NetworkNotification | | 711 | | | 712 ------------------------+-------------------------+-----------+--- 714 ----------- 715 State: Established Downstream MRS 716 ----------- 718 Condition Action State Note 719 ------------------------+-------------------------+-----------+--- 720 tg_SendMsg |tx_Data |Established|8) 721 |restart T_Inactive_QNode |Downstream | 722 | |MRS | 723 | | | 724 timeout T_Refresh_QNode |tx_Query |Established|9) 725 | |Downstream | 726 | |MRS | 727 | | | 728 (rx_Response)&& |Refresh MRS |Established|10) 729 (!NewPeer) |restart T_Inactive_QNode |Downstream | 730 | |MRS | 731 | | | 732 (rx_Response)|| |IF (MA is used) |Established|11) 733 (rx_Response(Mainfo)&& | (Delete MA)|| |Downstream | 734 (MAexist)))&&(NewPeer) | (Stop using shared MA)|MRS | 735 |Install MRS | | 736 |restart T_Inactive_QNode | | 737 |IF (RespCookie) | | 738 | tx_Confirm(RespCookie)| | 739 | | | 740 (rx_Response(MAinfo)&& |((Delete MA)|| |Wait MA |12) 741 (NewPeer)&&(!MA_exist)) |(Stop using shared MA)) |Establish. |* 742 |tg_Establish_MA | | 743 |(tx_Confirm) | | 744 | | | 745 ((tg_SendMsg)&&(Cmode)&&|tx_Query |Wait |13) 746 (!MAexist))|| |Queue NSLP data |Response | 747 (tg_MA_error)|| | | | 748 (tg_InvalidRoutingState)| | | 749 | | | 750 rx_Response(No_MRS_ |tx_Confirm(RespCookie) |Established|14) 751 installed)|tx_Data(Queued NSLP data)|Downstream | 752 | |MRS | 753 | | | 754 (timeout T_Inactive_ |Delete MRS |IDLE |15) 755 QNode)|||IF (MA is used) | | 756 (tg_SetStateLifetime(0))| (Delete MA)|| | | 757 | (Stop using shared MA)| | 758 |Tg_NetworkNotification | | 759 | | | 760 rx_Data |IF(CheckPeerInfo) |Established|7) 761 | tg_RecvMsg to Appl.|Downstream | 762 | |MRS | 763 | | | 764 Tg_ERROR |(Delete MRS) |IDLE | 765 |IF (MA is used) | | 766 | ((Delete MA)|| | | 767 | (Stop using shared MA))| | 768 |Tg_NetworkNotification | | 769 | | | 770 ------------------------+-------------------------+-----------+--- 772 ----------- 773 State: Wait MA Establishment 774 ----------- 776 Condition Action State Note 777 ------------------------+-------------------------+-----------+--- 778 tg_MA_Established |Install MRS |Established|16) 779 |(tx_Confirm) |Downstream |* 780 |tx_Data(Queued NSLP data)|MRS | 781 | | | 782 tg_MA_error |Delete MRS |IDLE |17) 783 |tg_MessageStatus | | 784 | | | 785 tg_SendMsg |Queue NSLP data |Wait MA |6) 786 | |Establish. | 787 | | | 788 Tg_ERROR |Delete MRS |IDLE | 789 |IF (MA is used) | | 790 | ((Delete MA)|| | | 791 | (Stop using shared MA))| | 792 |Tg_NetworkNotification | | 793 | | | 794 ------------------------+-------------------------+-----------+--- 796 Figure 4 798 A.2. State Machine for GIST responding node (Figure 3) 800 ----------- 801 State: IDLE 802 ----------- 804 Condition Action State Note 805 ------------------------+-------------------------+-----------+--- 806 rx_Query&& |tx_Response |Wait |1) 807 (ConfirmRequired) |start T_No_Confirm |Confirm | 808 |IF(NSLPdata) | | 809 | tg_RecvMsg(NSLPdata)| | 810 | to Appl.| | 811 | | | 812 rx_Query&& |tx_Response |Established|2) 813 (!ConfirmRequired) |Install MRS |Upstream | 814 |IF(NSLPdata) |MRS | 815 | tg_RecvMsg(NSLPdata)| | 816 | to Appl.| | 817 | | | 818 ------------------------+-------------------------+-----------+--- 820 ----------- 821 State: WAIT CONFIRM 822 ----------- 824 Condition Action State Note 825 ------------------------+-------------------------+-----------+--- 826 rx_Confirm |Install Upstream MRS |Established|3) 827 | |Upstream | 828 | |MRS | 829 | | | 831 rx_Query&& |tx_Response |Wait |4) 832 (ConfirmRequired) |start T_No_Confirm |Confirm | 833 |IF(NSLPdata) | | 834 | tg_RecvMsg(NSLPdata)| | 835 | to Appl.| | 836 | | | 837 rx_Data |tx_Error(No_MRS_ |Wait |5) 838 | installed)|Confirm | 839 | | | 840 timeout T_No_Confirm | |IDLE |6) 841 | | | 842 ------------------------+-------------------------+-----------+--- 844 ----------- 845 State: Established Upstream MRS 846 ----------- 848 Condition Action State Note 849 ------------------------+-------------------------+-----------+--- 850 tg_SendMsg |IF(!UpstreamPeerInfo) |Established|7) 851 | Queue NSLP data |Upstream | 852 |ELSE tx_Data |MRS | 853 | | | 854 rx_Data |IF(UpstreamPeerInfo) |Established|8) 855 | (tg_RecvMsg to Appl.)|Upstream | 856 | &&(restart_T_Expire_ |MRS | 857 | RNode)| | 858 |ELSE | | 859 | tx_Error(No_MRS_ | | 860 | installed)| | 861 | | | 862 rx_Query |IF (NewPeer) |Established|9) 863 | Update UpstreamPeerInfo|Upstream | 864 |tx_Response |MRS | 865 |restart T_Expire_RNode | | 866 | | | 867 (rx_Query)&& |Delete MRS |Wait | 868 (ConfirmRequired) |tx_Response |Confirm | 869 |start T_No_Confirm | | 870 |IF(MA is used) | | 871 | (Delete MA)|| | | 872 | (Stop using shared MA)| | 873 |IF(NSLPdata) | | 874 | tg_RecvMsg(NSLPdata) | | 875 | to Appl.| | 876 | | | 878 rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established|11) 879 (!ConfirmRequired) |restart T_Expire_RNode |Upstream | 880 |tx_Response(MAinfo) |MRS | 881 | | | 882 (timeout T_Expire_RNode)|Delete MRS |IDLE |12) 883 || |tg_NetworkNotification | | 884 (tg_SetStateLifetime(0))|IF(MA is used) | | 885 | (Delete MA)|| | | 886 | (Stop using shared MA)| | 887 | | | 888 rx_Confirm |Install UpstreamPeerInfo |Established|3) 889 |tx_Data(queued_NSLP_data)|Upstream | 890 | |MRS | 891 | | | 892 Tg_ERROR |(Delete MRS) |IDLE | 893 |IF (MA is used) | | 894 | ((Delete MA)|| | | 895 | (Stop using shared MA))| | 896 |Tg_NetworkNotification | | 897 | | | 898 ------------------------+-------------------------+-----------+--- 900 Figure 5 902 Authors' Addresses 904 Tseno Tsenov 905 Sofia, 906 Bulgaria 908 Email: tseno.tsenov@mytum.de 910 Hannes Tschofenig 911 Nokia Siemens Networks 912 Linnoitustie 6 913 Espoo 02600 914 Finland 916 Email: Hannes.Tschofenig@nsn.com 918 Xiaoming Fu 919 University of Goettingen 920 Computer Networks Group 921 Lotzestr. 16-18 922 Goettingen 37083 923 Germany 925 Email: fu@cs.uni-goettingen.de 927 Cedric Aoun 928 Paris 929 France 931 Email: cedric@caoun.net 933 Elwyn B. Davies 934 Folly Consulting 935 Soham, Cambs 936 UK 938 Phone: +44 7889 488 335 939 Email: elwynd@dial.pipex.com 941 Full Copyright Statement 943 Copyright (C) The IETF Trust (2008). 945 This document is subject to the rights, licenses and restrictions 946 contained in BCP 78, and except as set forth therein, the authors 947 retain all their rights. 949 This document and the information contained herein are provided on an 950 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 951 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 952 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 953 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 954 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 955 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 957 Intellectual Property 959 The IETF takes no position regarding the validity or scope of any 960 Intellectual Property Rights or other rights that might be claimed to 961 pertain to the implementation or use of the technology described in 962 this document or the extent to which any license under such rights 963 might or might not be available; nor does it represent that it has 964 made any independent effort to identify any such rights. Information 965 on the procedures with respect to rights in RFC documents can be 966 found in BCP 78 and BCP 79. 968 Copies of IPR disclosures made to the IETF Secretariat and any 969 assurances of licenses to be made available, or the result of an 970 attempt made to obtain a general license or permission for the use of 971 such proprietary rights by implementers or users of this 972 specification can be obtained from the IETF on-line IPR repository at 973 http://www.ietf.org/ipr. 975 The IETF invites any interested party to bring to its attention any 976 copyrights, patents or patent applications, or other proprietary 977 rights that may cover technology that may be required to implement 978 this standard. Please address the information to the IETF at ietf- 979 ipr@ietf.org. 981 Acknowledgment 983 Funding for the RFC Editor function is provided by the IETF 984 Administrative Support Activity (IASA).