idnits 2.17.1 draft-ietf-nsis-ntlp-statemachine-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (July 27, 2009) is 5388 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-pana-statemachine-12 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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 Intended status: Informational Nokia Siemens Networks 5 Expires: January 27, 2010 X. Fu, Ed. 6 Univ. Goettingen 7 C. Aoun 8 E. Davies 9 Folly Consulting 10 July 27, 2009 12 GIST State Machine 13 draft-ietf-nsis-ntlp-statemachine-08.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 27, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes the state machines for the General Internet 52 Signaling Transport (GIST). The states of GIST nodes for a given flow 53 and their transitions are presented in order to illustrate how GIST 54 may be implemented. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Notational conventions used in state diagrams . . . . . . . 4 61 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 6 62 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8 64 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 10 65 6. State machines . . . . . . . . . . . . . . . . . . . . . . . 11 66 6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 11 67 6.2 State machine for GIST querying node . . . . . . . . . . . 12 68 6.3 State machine for GIST responding node . . . . . . . . . . 13 69 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 11.1 Normative References . . . . . . . . . . . . . . . . . . 15 75 11.2 Informative References . . . . . . . . . . . . . . . . . 15 76 Appendix A. ASCII versions of the state diagrams . . . . . . . . 16 77 A.1 State machine for GIST querying node (Figure 2) . . . . 16 78 A.2 State Machine for GIST responding node (Figure 3) . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 The state machines described in this document are illustrative of how 84 the GIST protocol defined in [1] may be implemented for the GIST 85 nodes in different locations of a flow path. Where there are 86 differences - [1] is authoritative. The state machines are 87 informative only. Implementations may achieve the same results using 88 different methods. 90 There are two types of possible entities for GIST signaling: 92 - GIST querying node - GIST node that initiates the discovery of the 93 next peer; 95 - GIST responding node - GIST node that is the discovered next peer; 97 We describe a set of state machines for these entities to illustrate 98 how GIST may be implemented. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [2]. 106 3. Notational conventions used in state diagrams 108 The following text is reused from [3] and the state diagrams are 109 based on the conventions specified in [4], Section 8.2.1. Additional 110 state machine details are taken from [5]. 112 The complete text is reproduced here: 114 State diagrams are used to represent the operation of the protocol by 115 a number of cooperating state machines each comprising a group of 116 connected, mutually exclusive states. Only one state of each machine 117 can be active at any given time. 119 All permissible transitions between states are represented by arrows, 120 the arrowhead denoting the direction of the possible transition. 121 Labels attached to arrows denote the condition(s) that must be met in 122 order for the transition to take place. All conditions are 123 expressions that evaluate to TRUE or FALSE; if a condition evaluates 124 to TRUE, then the condition is met. The label UCT denotes an 125 unconditional transition (i.e., UCT always evaluates to TRUE). A 126 transition that is global in nature (i.e., a transition that occurs 127 from any of the possible states if the condition attached to the 128 arrow is met) is denoted by an open arrow; i.e., no specific state is 129 identified as the origin of the transition. When the condition 130 associated with a global transition is met, it supersedes all other 131 exit conditions including UCT. The special global condition BEGIN 132 supersedes all other global conditions, and once asserted remains 133 asserted until all state blocks have executed to the point that 134 variable assignments and other consequences of their execution remain 135 unchanged. 137 On entry to a state, the procedures defined for the state (if any) 138 are executed exactly once, in the order that they appear on the page. 139 Each action is deemed to be atomic; i.e., execution of a procedure 140 completes before the next sequential procedure starts to execute. No 141 procedures execute outside of a state block. The procedures in only 142 one state block execute at a time, even if the conditions for 143 execution of state blocks in different state machines are satisfied, 144 and all procedures in an executing state block complete execution 145 before the transition to and execution of any other state block 146 occurs, i.e., the execution of any state block appears to be atomic 147 with respect to the execution of any other state block and the 148 transition condition to that state from the previous state is TRUE 149 when execution commences. The order of execution of state blocks in 150 different state machines is undefined except as constrained by their 151 transition conditions. A variable that is set to a particular value 152 in a state block retains this value until a subsequent state block 153 executes a procedure that modifies the value. 155 On completion of all of the procedures within a state, all exit 156 conditions for the state (including all conditions associated with 157 global transitions) are evaluated continuously until one of the 158 conditions is met. The label ELSE denotes a transition that occurs 159 if none of the other conditions for transitions from the state are 160 met (i.e., ELSE evaluates to TRUE if all other possible exit 161 conditions from the state evaluate to FALSE). Where two or more exit 162 conditions with the same level of precedence become TRUE 163 simultaneously, the choice as to which exit condition causes the 164 state transition to take place is arbitrary. 166 In addition to the above notation, there are a couple of 167 clarifications specific to this document. First, all boolean 168 variables are initialized to FALSE before the state machine execution 169 begins. Second, the following notational shorthand is specific to 170 this document: 172 = | | ... 174 Execution of a statement of this form will result in 175 having a value of exactly one of the expressions. The logic for 176 which of those expressions gets executed is outside of the state 177 machine and could be environmental, configurable, or based on 178 another state machine such as that of the method. 180 4. State Machine Symbols 182 ( ) 183 Used to force the precedence of operators in Boolean expressions 184 and to delimit the argument(s) of actions within state boxes. 186 ; 187 Used as a terminating delimiter for actions within state boxes. 188 Where a state box contains multiple actions, the order of 189 execution follows the normal English language conventions for 190 reading text. 192 = 193 Assignment action. The value of the expression to the right of 194 the operator is assigned to the variable to the left of the 195 operator. Where this operator is used to define multiple 196 assignments, e.g., a = b = X the action causes the value of the 197 expression following the right-most assignment operator to be 198 assigned to all of the variables that appear to the left of the 199 right-most assignment operator. 201 ! 202 Logical NOT operator. 204 && 205 Logical AND operator. 207 || 208 Logical OR operator. 210 if...then... 211 Conditional action. If the Boolean expression following the if 212 evaluates to TRUE, then the action following the then is executed. 214 { statement 1, ... statement N } 215 Compound statement. Braces are used to group statements that are 216 executed together as if they were a single statement. 218 != 219 Inequality. Evaluates to TRUE if the expression to the left of 220 the operator is not equal in value to the expression to the right. 222 == 223 Equality. Evaluates to TRUE if the expression to the left of the 224 operator is equal in value to the expression to the right. 226 > 227 Greater than. Evaluates to TRUE if the value of the expression to 228 the left of the operator is greater than the value of the 229 expression to the right. 231 <= 232 Less than or equal to. Evaluates to TRUE if the value of the 233 expression to the left of the operator is either less than or 234 equal to the value of the expression to the right. 236 ++ 237 Increment the preceding integer operator by 1. 239 + 240 Arithmetic addition operator. 242 & 243 Bitwise AND operator. 245 5. Common Rules 247 Throughout the document we use terms defined in the [1], such as 248 Query, Response, Confirm. 250 State machine represents handling of GIST messages that match a 251 Message Routing State's MRI, NSLPID and SID and with no protocol 252 errors. Separate parallel instances of the state machines should 253 handle messages for different Message Routing States. 255 The state machine states represent the upstream/downstream peers 256 states of the Message Routing State. 258 For simplification not all objects included in a message are shown. 259 Only those that are significant for the case are shown. State 260 machines do not present handling of messages that are not significant 261 for management of the states. 263 Presented in this document state machines do not cover all functions 264 of a GIST node. Functionality of message forwarding, transmission of 265 NSLP data without MRS establishment and providing of the received 266 messages to the appropriate MRS, we refer as "Lower level pre- 267 processing" step. Pre-processing provides to the appropriate MRS FSM 268 only the messages which are matched against waiting Query/Response 269 cookies, or established MRS MRI+NSLPID+SID primary key. This is 270 presented by "rx_*" events in the state machines. 272 Management of a MA is considered in the document (e.g., 273 tg_Establish_MA, tg_MA_established events), but its FSM is not 274 explicitly presented. 276 5.1 Common Procedures 278 Tg_SendMsg: 279 NSLP/GIST API message that request transmission of a NSLP message. 281 Tg_SetStateLifetime(time_period): 282 NSLP/GIST API message providing info for the Lifetime of an RS, 283 required by the application. "Time_period = 0" represents the 284 cancellation of established RSs/MAs (invoked by NSLP application). 286 Tg_MessageStatus: 287 NSLP/GIST API message informing NSLP application of unsuccessful 288 delivery of a message 290 Tg_RecvMsg: 291 NSLP/GIST API message that provides received message to the NSLP 293 Tg_NetworkNotification: 294 NSLP/GIST API message that informs NSLP for change in MRS 296 Tx_Query: 297 Transmit of Query message 299 Tx_Response: 300 Transmit of Response message 302 Tx_Confirm: 303 Transmit of Confirm message 305 Rx_Query: 306 Receive of Query message 308 Rx_Response: 309 Receive of Response message 311 Rx_Confirm: 312 Receive of Confirm message 314 Tx_Error: 315 Transmit of Error message 317 Rx_Error: 318 Receive of Error message 320 Queue NSLP info: 321 Save NLSP messages in a queue until a required MA association is 322 established 324 Tx_Data: 325 Transmit of Data message 327 Rx_Data: 328 Receive of Data message 330 T_Inactive_QNode: 331 Message Routing State lifetime timer in Querying Node 333 T_Expired_RNode: 334 Message Routing State lifetime timer in Responding Node 336 T_Refresh_QNode: 337 Message Routing State refresh timer in Querying Node 339 T_No_Response: 340 Timer for the waiting period for Response message in Querying Node 342 T_No_Confirm: 343 Timer for the waiting period for Confirm message in Responding 344 Node 346 Install downstream/upstream MRS: 347 Install new Message Routing State and save the corespoding peer 348 state info (IP address and UDP port or pointer to the used MA) for 349 the current Message Routing State or update the coresponding peer 350 state info. 352 DELETE MRS: 353 Delete installed downstream/upstream peer's info for the current 354 Message Routing State and delete the Message Routing State if 355 required. 357 Established MA: 358 A Message Association (MA) is established between the current node 359 and its upstream peer. The initiator for the establishment is the 360 upstream peer. 362 Re-use existing MA: 363 An existing MA between the current node and its peer is re-used. 365 DELETE MA: 366 Delete/disconnect used MA. 368 Stop using shared MA: 369 Stop using shared MA. If the shared MA is no more used by any 370 other MRSs, it depends on the local policy whether it is deleted 371 or kept. 373 REFRESH MRS: 374 Refreshes installed MRS. 376 Tg_MA_Error: 377 Error event with used MA. 379 Tg_InvalidRoutingState: 380 Notification from NSLP application for path change 382 Tg_Establish_MA: 383 Trigers establishment of MA. 385 Tg_MA_Established: 386 MA has been successfully established. 388 Tg_ERROR: 389 General Error event / system level error. 391 No_MRS_Installed: 392 Error response, send by the Responding node indicating lost 393 Confirm message. 395 5.2 Common Variables 397 It is assumed that the type of mode and destination info (which need 398 to be taken from the application parameters and local GIST policy)is 399 provided. This is represented by the common variables Dmode, Cmode, 400 MAinfo, MApresent and Refresh. 402 Cmode: 403 The message MUST be transmitted in Cmode. This is specified by 404 "Message transfer attributes" set to any of the following values: 406 "Reliability" is set to TRUE. 408 "Security" is set to values that request secure handling of a 409 message. 411 "Local processing" is set to values that require services offered 412 by Cmode (e.g., congestion control). [1] 414 Dmode: 415 The message MUST be transmitted in Dmode. This is specified by 416 local policy rules and in case that the "Message transfer 417 attributes" are not set to any of the following values: 419 "Reliability" is set to TRUE. 421 "Security" is set to values that request special security handling 422 of a message. 424 "Local processing" is set to values that require services offered 425 by Cmode [1] 427 MAinfo: 428 GIST message parameters describing the required MA or proposed MA 429 e.g. "Stack-proposal" and "Stack-Configuration-Data". 431 NSLPdata: 432 NSLP application data. 434 RespCookie: 435 Responder Cookie that is being sent by the Responding node with 436 the Response message in case that its local policy requires a 437 confirmation from the querying node. 439 ConfirmRequired: 440 Confirm message is required by the local policy rule for 441 installation of the new MRS. 443 NewPeer: 444 Response message is received from new responding peer. 446 MAexist: 447 Existing MA will be reused. 449 CheckPeerInfo: 450 The sender of the received data message is matched against the 451 installed peer info in the MRS. 453 UpstreamPeerInstalled: 454 Upstream peer info is installed in the MRS. 456 6. State machines 458 The following section presents the state machine diagrams of GIST 459 peers. 461 6.1 Diagram notations 463 (see the .pdf version for missing diagram or 464 refer to Appendix A if reading the .txt version) 465 Figure 1: Diagram notations 467 6.2 State machine for GIST querying node 469 The following is a diagram of the GIST querying node state machine. 470 Also included is clarification of notation. 472 (see the .pdf version for missing diagram or 473 refer to Appendix A.1 if reading the .txt version) 475 Figure 1: GIST Querying Node State Machine 477 *) Response and Comfirm messages might be send either in Dmode or 478 Cmode, before or after MA establishment depending on node s local 479 3-way handshake policy and the availability of MAs to be reused. 480 See draft for details. 481 **) Depending on the local policy NSLPdata might be send as payload 482 of Query and Confirm messages. (piggybacking) 483 1) Initial request from NSLP is received, which triggers Query 484 messages requesting either D_mode or C_mode. Depending on node s 485 local policy NSLP data might be piggybacked in the Query 486 requesting D_mode. Query may carry Mainfo if C_mode transport is 487 needed. 488 2) Response message is received. If C_mode connection must be 489 established and there is no available MA to be reused, MA 490 establishment is initiated and waited to be completed. 491 3) Response message is received. If D_mode connection is requested or 492 available MA can be reused for requested C_mode, the MRS is 493 established. 494 4) No_Response timer expires. Query is resent. 495 5) No_Response timer expires and maximum number of retries has been 496 reached. NSLP application is notified for the GIST peer discovery 497 failure. 498 6) NSLP data is queued, because downstream peer is not discovered or 499 required MA is still not established. 500 7) Data message is received. It is checked if its sender matches the 501 installed downstream peer info in the MRS and then processed. In 502 WaitResponse state, this event might happen in the process of MA 503 upgrade, when the downstream peer is still not aware of 504 establishment of the new MA. 505 8) Provided NSLP data is sent via Data message towards downstream 506 GIST peer. 507 9) Refresh_QNode timer expires. Query message is sent. 508 10) Response message from the downstream GIST peer is received. The 509 peer is not changed. MRS is refreshed (Refresh_QNode timer is 510 restarted). 511 11) Path change detected. Response message from a new downstream GIST 512 peer is received. D_mode is requested or existing MA can be reused 513 for requested C_mode. 514 12) Path change detected. Response message from a new downstream GIST 515 peer is received. A new MA must be established for requested 516 C_mode. 517 13) Requested by NSLP application transport parameters requires 518 upgrade of established MRS from D_mode/C_mode to C_mode. NSLP 519 application notifies GIST for path change. Downstream GIST peer 520 discovery is initiated. 521 14) Sent Confirm message has not been received by downstream GIST 522 peer. Confirm message is resent. 523 15) MRS lifetime expires. Notification by NSLP application that MRS 524 is no longer needed. 525 16) MA is established. 526 17) MA establishment failure. 528 6.3 State machine for GIST responding node 530 The following is a diagram of the GIST responding node state machine. 531 Also included is clarification of notation. 533 (see the .pdf version for missing diagram or 534 refer to Appendix A.2 if reading the .txt version) 536 Figure 3: GIST Responding Node State Machine 538 1) A Query message is received. Explicit Confirm message is required 539 for MRS installation, based on the local policy. Query message 540 might carry piggybacked NSLP data which is provided to the NSLP 541 application. 542 2) A Query message is received. MRS is installed immediately, based 543 on the local policy. Query message might carry piggybacked NSLP 544 data which is provided to the NSLP application. 545 3) Confirm message is received which causes installation of the 546 complete MRS or just installation of the used MA as a upstream 547 peer info. 548 4) Sent Response message has not been received by upstream GIST peer. 549 Response message is resent. 550 5) In case of lost Confirm message, data messages might be received 551 from the upstream GIST node (it is unaware of the lost Confirm 552 message). Response indicating the loss of the Confirm is sent back 553 to the upstream GIST node. 554 6) No_Confirm timer expires. Note that all cases of lost handshake 555 GIST messages are handled only by GIST querying node via resend of 556 Query message. 557 7) NSLP data is sent if discovery process is successfully 558 accomplished or is queued if Confirm message is still expected to 559 confirm establishment of MA. 560 8) Data messages are accepted only if complete MRS is installed, 561 e.g., there is installed upstream peer info. If not, then Confirm 562 message is expected and data message won t be accepted. Response 563 indicating the loss of the Confirm is sent back to the upstream 564 GIST node. 565 9) Change of the upstream GIST node (e.g., path change). Local policy 566 does not need explicit Confirm message for MRS installation. MRS 567 data is updated. 568 10) Change of the upstream GIST node or request for change of the 569 used connection mode (from D_mode/C_mode to better C_mode). Local 570 policy requires explicit Confirm message for MRS installation. 571 11) Request for change of the used connection mode (from 572 D_mode/C_mode to better C_mode). Local policy does not need 573 explicit Confirm message for MRS installation. MRS data is 574 updated. 575 12) MRS lifetime expires. Notification by NSLP application that MRS 576 is no longer needed. 578 7. Security Considerations 580 This document does not raise new security considerations. Any 581 security concerns with GIST are likely reflected in security related 582 NSIS work already (such as [1] or [6]). 584 8. IANA Considerations 586 This document has no actions for IANA. 588 9. Contributors 590 Christian Dickmann contributed to refining of the state machine since 591 01 version. 593 10. Acknowledgments 595 The authors would like to thank Robert Hancock, Ingo Juchem, Andreas 596 Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd 597 Schloer for their insightful comments. 599 11. References 601 11.1. Normative References 603 [1] Schulzrinne, H., "GIST: General Internet Signaling 604 Transport", draft-ietf-nsis-ntlp-20 (work in progress), 605 June 2009. 607 [2] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 11.2. Informative References 612 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 613 "State Machines for Extensible Authentication Protocol 614 (EAP) Peer and Authenticator", RFC4137, August 2005. 616 [4] Institute of Electrical and Electronics Engineers, 617 "Standard for Local and Metropolitan Area Networks: Port- 618 Based 619 Network Access Control", IEEE 802-1X-2004, December 620 2004. 622 [5] Fajardo, V., Ohba, Y. and R. Lopez, "State Machines for 623 Protocol for Carrying Authentication for Network Access 624 (PANA)", 625 draft-ietf-pana-statemachine-12 (work in progress), 626 April 2009. 628 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for 629 NSIS", RFC 4081, June 2005. 631 Appendix A. ASCII versions of state diagrams 633 This appendix contains the state diagrams in ASCII format. Please 634 use the PDF version whenever possible: it is much easier to 635 understand. 637 For each state there is a separate table that lists in each row: 638 - an event that triggers a transition, 639 - actions taken as a result of the incoming event, 640 - and the new state at which the transitions ends. 642 A.1. State machine for GIST querying node (Figure 2) 644 ----------- 645 State: IDLE 646 ----------- 648 Condition Action State Note 649 ------------------------+-------------------------+-----------+--- 650 tg_SendMsg |tx_Query |Wait |1) 651 |start T_No_Response |Response |** 652 |Queue NSLP data | | 653 | | | 654 Tg_ERROR |Delete MRS |IDLE | 655 |IF (MA is used) | | 656 | ((Delete MA)|| | | 657 | (Stop using shared MA))| | 658 |Tg_NetworkNotification | | 659 | | | 660 ------------------------+-------------------------+-----------+--- 662 ----------- 663 State: WaitResponse 664 ----------- 666 Condition Action State Note 667 ------------------------+-------------------------+-----------+--- 668 rx_Response(MAinfo)&& |tg_Establish_MA |Wait MA |* 669 (!MAexist) |(tx_Confirm) |Establish. |2) 670 | | | 671 | | | 672 rx_Response)|| |Install MRS |Established|3) 673 (rx_Response(MAinfo)&& |IF (RespCookie) |Downstream | 674 (MAexist)) | tx_Confirm(RespCookie)|MRS | 675 |tx_Data(Queued NSLP data)| | 676 | | | 678 (timeout T_No_Response) |Tx_Query |Wait |4) 679 &&(!MaxRetry) |restart T_No_Response |Response | 680 | | | 681 (timeout T_No_Response) |tg_MessageStatus |IDLE |5) 682 &&(MaxRetry) | | | 683 | | | 684 tg_SendMsg |Queue NSLP data |Wait |6) 685 | |Response | 686 | | | 687 rx_Data |IF(CheckPeerInfo) |Wait |7) 688 | tg_RecvMsg to Appl.|Response | 689 | | | 690 Tg_ERROR |(Delete MRS) |IDLE | 691 |IF (MA is used) | | 692 | ((Delete MA)|| | | 693 | (Stop using shared MA))| | 694 |Tg_NetworkNotification | | 695 | | | 696 ------------------------+-------------------------+-----------+--- 698 ----------- 699 State: Established Downstream MRS 700 ----------- 702 Condition Action State Note 703 ------------------------+-------------------------+-----------+--- 704 tg_SendMsg |tx_Data |Established|8) 705 |restart T_Inactive_QNode |Downstream | 706 | |MRS | 707 | | | 708 timeout T_Refresh_QNode |tx_Query |Established|9) 709 | |Downstream | 710 | |MRS | 711 | | | 712 (rx_Response)&& |Refresh MRS |Established|10) 713 (!NewPeer) |restart T_Inactive_QNode |Downstream | 714 | |MRS | 715 | | | 716 (rx_Response)|| |IF (MA is used) |Established|11) 717 (rx_Response(Mainfo)&& | (Delete MA)|| |Downstream | 718 (MAexist)))&&(NewPeer) | (Stop using shared MA)|MRS | 719 |Install MRS | | 720 |restart T_Inactive_QNode | | 721 |IF (RespCookie) | | 722 | tx_Confirm(RespCookie)| | 723 | | | 724 (rx_Response(MAinfo)&& |((Delete MA)|| |Wait MA |12) 725 (NewPeer)&&(!MA_exist)) |(Stop using shared MA)) |Establish. |* 726 |tg_Establish_MA | | 727 |(tx_Confirm) | | 728 | | | 729 ((tg_SendMsg)&&(Cmode)&&|tx_Query |Wait |13) 730 (!MAexist))|| |Queue NSLP data |Response | 731 (tg_MA_error)|| | | | 732 (tg_InvalidRoutingState)| | | 733 | | | 734 rx_Response(No_MRS_ |tx_Confirm(RespCookie) |Established|14) 735 installed)|tx_Data(Queued NSLP data)|Downstream | 736 | |MRS | 737 | | | 738 (timeout T_Inactive_ |Delete MRS |IDLE |15) 739 QNode)|||IF (MA is used) | | 740 (tg_SetStateLifetime(0))| (Delete MA)|| | | 741 | (Stop using shared MA)| | 742 |Tg_NetworkNotification | | 743 | | | 744 rx_Data |IF(CheckPeerInfo) |Established|7) 745 | tg_RecvMsg to Appl.|Downstream | 746 | |MRS | 747 | | | 748 Tg_ERROR |(Delete MRS) |IDLE | 749 |IF (MA is used) | | 750 | ((Delete MA)|| | | 751 | (Stop using shared MA))| | 752 |Tg_NetworkNotification | | 753 | | | 754 ------------------------+-------------------------+-----------+--- 756 ----------- 757 State: Wait MA Establishment 758 ----------- 760 Condition Action State Note 761 ------------------------+-------------------------+-----------+--- 762 tg_MA_Established |Install MRS |Established|16) 763 |(tx_Confirm) |Downstream |* 764 |tx_Data(Queued NSLP data)|MRS | 765 | | | 766 tg_MA_error |Delete MRS |IDLE |17) 767 |tg_MessageStatus | | 768 | | | 769 tg_SendMsg |Queue NSLP data |Wait MA |6) 770 | |Establish. | 771 | | | 772 Tg_ERROR |Delete MRS |IDLE | 773 |IF (MA is used) | | 774 | ((Delete MA)|| | | 775 | (Stop using shared MA))| | 776 |Tg_NetworkNotification | | 777 | | | 778 ------------------------+-------------------------+-----------+--- 780 Figure 4 782 A.2. State Machine for GIST responding node (Figure 3) 784 ----------- 785 State: IDLE 786 ----------- 788 Condition Action State Note 789 ------------------------+-------------------------+-----------+--- 790 rx_Query&& |tx_Response |Wait |1) 791 (ConfirmRequired) |start T_No_Confirm |Confirm | 792 |IF(NSLPdata) | | 793 | tg_RecvMsg(NSLPdata)| | 794 | to Appl.| | 795 | | | 796 rx_Query&& |tx_Response |Established|2) 797 (!ConfirmRequired) |Install MRS |Upstream | 798 |IF(NSLPdata) |MRS | 799 | tg_RecvMsg(NSLPdata)| | 800 | to Appl.| | 801 | | | 802 ------------------------+-------------------------+-----------+--- 804 ----------- 805 State: WAIT CONFIRM 806 ----------- 808 Condition Action State Note 809 ------------------------+-------------------------+-----------+--- 810 rx_Confirm |Install Upstream MRS |Established|3) 811 | |Upstream | 812 | |MRS | 813 | | | 815 rx_Query&& |tx_Response |Wait |4) 816 (ConfirmRequired) |start T_No_Confirm |Confirm | 817 |IF(NSLPdata) | | 818 | tg_RecvMsg(NSLPdata)| | 819 | to Appl.| | 820 | | | 821 rx_Data |tx_Error(No_MRS_ |Wait |5) 822 | installed)|Confirm | 823 | | | 824 timeout T_No_Confirm | |IDLE |6) 825 | | | 826 ------------------------+-------------------------+-----------+--- 828 ----------- 829 State: Established Upstream MRS 830 ----------- 832 Condition Action State Note 833 ------------------------+-------------------------+-----------+--- 834 tg_SendMsg |IF(!UpstreamPeerInfo) |Established|7) 835 | Queue NSLP data |Upstream | 836 |ELSE tx_Data |MRS | 837 | | | 838 rx_Data |IF(UpstreamPeerInfo) |Established|8) 839 | (tg_RecvMsg to Appl.)|Upstream | 840 | &&(restart_T_Expire_ |MRS | 841 | RNode)| | 842 |ELSE | | 843 | tx_Error(No_MRS_ | | 844 | installed)| | 845 | | | 846 rx_Query |IF (NewPeer) |Established|9) 847 | Update UpstreamPeerInfo|Upstream | 848 |tx_Response |MRS | 849 |restart T_Expire_RNode | | 850 | | | 851 (rx_Query)&& |Delete MRS |Wait | 852 (ConfirmRequired) |tx_Response |Confirm | 853 |start T_No_Confirm | | 854 |IF(MA is used) | | 855 | (Delete MA)|| | | 856 | (Stop using shared MA)| | 857 |IF(NSLPdata) | | 858 | tg_RecvMsg(NSLPdata) | | 859 | to Appl.| | 860 | | | 862 rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established|11) 863 (!ConfirmRequired) |restart T_Expire_RNode |Upstream | 864 |tx_Response(MAinfo) |MRS | 865 | | | 866 (timeout T_Expire_RNode)|Delete MRS |IDLE |12) 867 || |tg_NetworkNotification | | 868 (tg_SetStateLifetime(0))|IF(MA is used) | | 869 | (Delete MA)|| | | 870 | (Stop using shared MA)| | 871 | | | 872 rx_Confirm |Install UpstreamPeerInfo |Established|3) 873 |tx_Data(queued_NSLP_data)|Upstream | 874 | |MRS | 875 | | | 876 Tg_ERROR |(Delete MRS) |IDLE | 877 |IF (MA is used) | | 878 | ((Delete MA)|| | | 879 | (Stop using shared MA))| | 880 |Tg_NetworkNotification | | 881 | | | 882 ------------------------+-------------------------+-----------+--- 884 Figure 5 886 Authors' Addresses 888 Tseno Tsenov 889 Sofia, Bulgaria 891 Email: tseno.tsenov@mytum.de 893 Hannes Tschofenig 894 Nokia Siemens Networks 895 Linnoitustie 6 896 Espoo 02600 897 Finland 899 Email: Hannes.Tschofenig@nsn.com 901 Xiaoming Fu (Editor) 902 University of Goettingen 903 Computer Networks Group 904 Goldschmidtstr. 7 905 Goettingen 37077 906 Germany 908 Email: fu@cs.uni-goettingen.de 910 Cedric Aoun 911 Paris, France 913 Email: cedric@caoun.net 915 Elwyn B. Davies 916 Folly Consulting 917 Soham, Cambs, UK 919 Phone: +44 7889 488 335 920 Email: elwynd@dial.pipex.com