idnits 2.17.1 draft-ietf-nsis-ntlp-statemachine-06.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 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 950. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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 (November 02, 2008) is 5626 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-16 == Outdated reference: A later version (-13) exists of draft-ietf-pana-statemachine-07 Summary: 2 errors (**), 0 flaws (~~), 4 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 Intended status: Informational Nokia Siemens Networks 5 Expires: May 06, 2009 X. Fu 6 Univ. Goettingen 7 C. Aoun 8 E. Davies 9 Folly Consulting 10 November 02, 2008 12 GIST State Machine 13 draft-ietf-nsis-ntlp-statemachine-06.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 May 06, 2009. 40 Abstract 42 This document describes the state machines for the General Internet 43 Signaling Transport (GIST). The states of GIST nodes for a given flow 44 and their transitions are presented in order to illustrate how GIST 45 may be implemented. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Notational conventions used in state diagrams . . . . . . . 3 52 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 5 53 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 54 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 7 55 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 9 56 6. State machines . . . . . . . . . . . . . . . . . . . . . . . 10 57 6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 10 58 6.2 State machine for GIST querying node . . . . . . . . . . . 11 59 6.3 State machine for GIST responding node . . . . . . . . . . 12 60 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 61 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 10.1 Normative References . . . . . . . . . . . . . . . . . . 14 65 10.2 Informative References . . . . . . . . . . . . . . . . . 14 66 Appendix A. ASCII versions of the state diagrams . . . . . . . . 15 67 A.1 State machine for GIST querying node (Figure 2) . . . . 15 68 A.2 State Machine for GIST responding node (Figure 3) . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 70 Intellectual Property and Copyright Statements . . . . . . . 22 72 1. Introduction 74 The state machines described in this document are illustrative of how 75 the GIST protocol defined in [1] may be implemented for the GIST 76 nodes in different locations of a flow path. Where there are 77 differences - [1] is authoritative. The state machines are 78 informative only. Implementations may achieve the same results using 79 different methods. 81 There are two types of possible entities for GIST signaling: 83 - GIST querying node - GIST node that initiates the discovery of the 84 next peer; 86 - GIST responding node - GIST node that is the discovered next peer; 88 We describe a set of state machines for these entities to illustrate 89 how GIST may be implemented. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [2]. 97 3. Notational conventions used in state diagrams 99 The following text is reused from [3] and the state diagrams are 100 based on the conventions specified in [4], Section 8.2.1. Additional 101 state machine details are taken from [5]. 103 The complete text is reproduced here: 105 State diagrams are used to represent the operation of the protocol by 106 a number of cooperating state machines each comprising a group of 107 connected, mutually exclusive states. Only one state of each machine 108 can be active at any given time. 110 All permissible transitions between states are represented by arrows, 111 the arrowhead denoting the direction of the possible transition. 112 Labels attached to arrows denote the condition(s) that must be met in 113 order for the transition to take place. All conditions are 114 expressions that evaluate to TRUE or FALSE; if a condition evaluates 115 to TRUE, then the condition is met. The label UCT denotes an 116 unconditional transition (i.e., UCT always evaluates to TRUE). A 117 transition that is global in nature (i.e., a transition that occurs 118 from any of the possible states if the condition attached to the 119 arrow is met) is denoted by an open arrow; i.e., no specific state is 120 identified as the origin of the transition. When the condition 121 associated with a global transition is met, it supersedes all other 122 exit conditions including UCT. The special global condition BEGIN 123 supersedes all other global conditions, and once asserted remains 124 asserted until all state blocks have executed to the point that 125 variable assignments and other consequences of their execution remain 126 unchanged. 128 On entry to a state, the procedures defined for the state (if any) 129 are executed exactly once, in the order that they appear on the page. 130 Each action is deemed to be atomic; i.e., execution of a procedure 131 completes before the next sequential procedure starts to execute. No 132 procedures execute outside of a state block. The procedures in only 133 one state block execute at a time, even if the conditions for 134 execution of state blocks in different state machines are satisfied, 135 and all procedures in an executing state block complete execution 136 before the transition to and execution of any other state block 137 occurs, i.e., the execution of any state block appears to be atomic 138 with respect to the execution of any other state block and the 139 transition condition to that state from the previous state is TRUE 140 when execution commences. The order of execution of state blocks in 141 different state machines is undefined except as constrained by their 142 transition conditions. A variable that is set to a particular value 143 in a state block retains this value until a subsequent state block 144 executes a procedure that modifies the value. 146 On completion of all of the procedures within a state, all exit 147 conditions for the state (including all conditions associated with 148 global transitions) are evaluated continuously until one of the 149 conditions is met. The label ELSE denotes a transition that occurs 150 if none of the other conditions for transitions from the state are 151 met (i.e., ELSE evaluates to TRUE if all other possible exit 152 conditions from the state evaluate to FALSE). Where two or more exit 153 conditions with the same level of precedence become TRUE 154 simultaneously, the choice as to which exit condition causes the 155 state transition to take place is arbitrary. 157 In addition to the above notation, there are a couple of 158 clarifications specific to this document. First, all boolean 159 variables are initialized to FALSE before the state machine execution 160 begins. Second, the following notational shorthand is specific to 161 this document: 163 = | | ... 165 Execution of a statement of this form will result in 166 having a value of exactly one of the expressions. The logic for 167 which of those expressions gets executed is outside of the state 168 machine and could be environmental, configurable, or based on 169 another state machine such as that of the method. 171 4. State Machine Symbols 173 ( ) 174 Used to force the precedence of operators in Boolean expressions 175 and to delimit the argument(s) of actions within state boxes. 177 ; 178 Used as a terminating delimiter for actions within state boxes. 179 Where a state box contains multiple actions, the order of 180 execution follows the normal English language conventions for 181 reading text. 183 = 184 Assignment action. The value of the expression to the right of 185 the operator is assigned to the variable to the left of the 186 operator. Where this operator is used to define multiple 187 assignments, e.g., a = b = X the action causes the value of the 188 expression following the right-most assignment operator to be 189 assigned to all of the variables that appear to the left of the 190 right-most assignment operator. 192 ! 193 Logical NOT operator. 195 && 196 Logical AND operator. 198 || 199 Logical OR operator. 201 if...then... 202 Conditional action. If the Boolean expression following the if 203 evaluates to TRUE, then the action following the then is executed. 205 { statement 1, ... statement N } 206 Compound statement. Braces are used to group statements that are 207 executed together as if they were a single statement. 209 != 210 Inequality. Evaluates to TRUE if the expression to the left of 211 the operator is not equal in value to the expression to the right. 213 == 214 Equality. Evaluates to TRUE if the expression to the left of the 215 operator is equal in value to the expression to the right. 217 > 218 Greater than. Evaluates to TRUE if the value of the expression to 219 the left of the operator is greater than the value of the 220 expression to the right. 222 <= 223 Less than or equal to. Evaluates to TRUE if the value of the 224 expression to the left of the operator is either less than or 225 equal to the value of the expression to the right. 227 ++ 228 Increment the preceding integer operator by 1. 230 + 231 Arithmetic addition operator. 233 & 234 Bitwise AND operator. 236 5. Common Rules 238 Throughout the document we use terms defined in the [1], such as 239 Query, Response, Confirm. 241 State machine represents handling of GIST messages that match a 242 Message Routing State's MRI, NSLPID and SID and with no protocol 243 errors. Separate parallel instances of the state machines should 244 handle messages for different Message Routing States. 246 The state machine states represent the upstream/downstream peers 247 states of the Message Routing State. 249 For simplification not all objects included in a message are shown. 250 Only those that are significant for the case are shown. State 251 machines do not present handling of messages that are not significant 252 for management of the states. 254 Presented in this document state machines do not cover all functions 255 of a GIST node. Functionality of message forwarding, transmission of 256 NSLP data without MRS establishment and providing of the received 257 messages to the appropriate MRS, we refer as "Lower level pre- 258 processing" step. Pre-processing provides to the appropriate MRS FSM 259 only the messages which are matched against waiting Query/Response 260 cookies, or established MRS MRI+NSLPID+SID primary key. This is 261 presented by "rx_*" events in the state machines. 263 Management of a MA is considered in the document (e.g., 264 tg_Establish_MA, tg_MA_established events), but its FSM is not 265 explicitly presented. 267 5.1 Common Procedures 269 Tg_SendMsg: 270 NSLP/GIST API message that request transmission of a NSLP message. 272 Tg_SetStateLifetime(time_period): 273 NSLP/GIST API message providing info for the Lifetime of an RS, 274 required by the application. "Time_period = 0" represents the 275 cancellation of established RSs/MAs (invoked by NSLP application). 277 Tg_MessageStatus: 278 NSLP/GIST API message informing NSLP application of unsuccessful 279 delivery of a message 281 Tg_RecvMsg: 282 NSLP/GIST API message that provides received message to the NSLP 284 Tg_NetworkNotification: 285 NSLP/GIST API message that informs NSLP for change in MRS 287 Tx_Query: 288 Transmit of Query message 290 Tx_Response: 291 Transmit of Response message 293 Tx_Confirm: 294 Transmit of Confirm message 296 Rx_Query: 297 Receive of Query message 299 Rx_Response: 300 Receive of Response message 302 Rx_Confirm: 303 Receive of Confirm message 305 Tx_Error: 306 Transmit of Error message 308 Rx_Error: 309 Receive of Error message 311 Queue NSLP info: 312 Save NLSP messages in a queue until a required MA association is 313 established 315 Tx_Data: 316 Transmit of Data message 318 Rx_Data: 319 Receive of Data message 321 T_Inactive_QNode: 322 Message Routing State lifetime timer in Querying Node 324 T_Expired_RNode: 325 Message Routing State lifetime timer in Responding Node 327 T_Refresh_QNode: 328 Message Routing State refresh timer in Querying Node 330 T_No_Response: 331 Timer for the waiting period for Response message in Querying Node 333 T_No_Confirm: 334 Timer for the waiting period for Confirm message in Responding 335 Node 337 Install downstream/upstream MRS: 338 Install new Message Routing State and save the corespoding peer 339 state info (IP address and UDP port or pointer to the used MA) for 340 the current Message Routing State or update the coresponding peer 341 state info. 343 DELETE MRS: 344 Delete installed downstream/upstream peer's info for the current 345 Message Routing State and delete the Message Routing State if 346 required. 348 Established MA: 349 A Message Association (MA) is established between the current node 350 and its upstream peer. The initiator for the establishment is the 351 upstream peer. 353 Re-use existing MA: 354 An existing MA between the current node and its peer is re-used. 356 DELETE MA: 357 Delete/disconnect used MA. 359 Stop using shared MA: 360 Stop using shared MA. If the shared MA is no more used by any 361 other MRSs, it depends on the local policy whether it is deleted 362 or kept. 364 REFRESH MRS: 365 Refreshes installed MRS. 367 Tg_MA_Error: 368 Error event with used MA. 370 Tg_InvalidRoutingState: 371 Notification from NSLP application for path change 373 Tg_Establish_MA: 374 Trigers establishment of MA. 376 Tg_MA_Established: 377 MA has been successfully established. 379 Tg_ERROR: 380 General Error event / system level error. 382 No_MRS_Installed: 383 Error response, send by the Responding node indicating lost 384 Confirm message. 386 5.2 Common Variables 388 It is assumed that the type of mode and destination info (which need 389 to be taken from the application parameters and local GIST policy)is 390 provided. This is represented by the common variables Dmode, Cmode, 391 MAinfo, MApresent and Refresh. 393 Cmode: 394 The message MUST be transmitted in Cmode. This is specified by 395 "Message transfer attributes" set to any of the following values: 397 "Reliability" is set to TRUE. 399 "Security" is set to values that request secure handling of a 400 message. 402 "Local processing" is set to values that require services offered 403 by Cmode (e.g., congestion control). [1] 405 Dmode: 406 The message MUST be transmitted in Dmode. This is specified by 407 local policy rules and in case that the "Message transfer 408 attributes" are not set to any of the following values: 410 "Reliability" is set to TRUE. 412 "Security" is set to values that request special security handling 413 of a message. 415 "Local processing" is set to values that require services offered 416 by Cmode [1] 418 MAinfo: 419 GIST message parameters describing the required MA or proposed MA 420 e.g. "Stack-proposal" and "Stack-Configuration-Data". 422 NSLPdata: 423 NSLP application data. 425 RespCookie: 426 Responder Cookie that is being sent by the Responding node with 427 the Response message in case that its local policy requires a 428 confirmation from the querying node. 430 ConfirmRequired: 431 Confirm message is required by the local policy rule for 432 installation of the new MRS. 434 NewPeer: 435 Response message is received from new responding peer. 437 MAexist: 438 Existing MA will be reused. 440 CheckPeerInfo: 441 The sender of the received data message is matched against the 442 installed peer info in the MRS. 444 UpstreamPeerInstalled: 445 Upstream peer info is installed in the MRS. 447 6. State machines 449 The following section presents the state machine diagrams of GIST 450 peers. 452 6.1 Diagram notations 454 (see the .pdf version for missing diagram or 455 refer to Appendix A if reading the .txt version) 456 Figure 1: Diagram notations 458 6.2 State machine for GIST querying node 460 The following is a diagram of the GIST querying node state machine. 461 Also included is clarification of notation. 463 (see the .pdf version for missing diagram or 464 refer to Appendix A.1 if reading the .txt version) 466 Figure 1: GIST Querying Node State Machine 468 *) Response and Comfirm messages might be send either in Dmode or 469 Cmode, before or after MA establishment depending on node s local 470 3-way handshake policy and the availability of MAs to be reused. 471 See draft for details. 472 **) Depending on the local policy NSLPdata might be send as payload 473 of Query and Confirm messages. (piggybacking) 474 1) Initial request from NSLP is received, which triggers Query 475 messages requesting either D_mode or C_mode. Depending on node s 476 local policy NSLP data might be piggybacked in the Query 477 requesting D_mode. Query may carry Mainfo if C_mode transport is 478 needed. 479 2) Response message is received. If C_mode connection must be 480 established and there is no available MA to be reused, MA 481 establishment is initiated and waited to be completed. 482 3) Response message is received. If D_mode connection is requested or 483 available MA can be reused for requested C_mode, the MRS is 484 established. 485 4) No_Response timer expires. Query is resent. 486 5) No_Response timer expires and maximum number of retries has been 487 reached. NSLP application is notified for the GIST peer discovery 488 failure. 489 6) NSLP data is queued, because downstream peer is not discovered or 490 required MA is still not established. 491 7) Data message is received. It is checked if its sender matches the 492 installed downstream peer info in the MRS and then processed. In 493 WaitResponse state, this event might happen in the process of MA 494 upgrade, when the downstream peer is still not aware of 495 establishment of the new MA. 496 8) Provided NSLP data is sent via Data message towards downstream 497 GIST peer. 498 9) Refresh_QNode timer expires. Query message is sent. 499 10) Response message from the downstream GIST peer is received. The 500 peer is not changed. MRS is refreshed (Refresh_QNode timer is 501 restarted). 502 11) Path change detected. Response message from a new downstream GIST 503 peer is received. D_mode is requested or existing MA can be reused 504 for requested C_mode. 505 12) Path change detected. Response message from a new downstream GIST 506 peer is received. A new MA must be established for requested 507 C_mode. 508 13) Requested by NSLP application transport parameters requires 509 upgrade of established MRS from D_mode/C_mode to C_mode. NSLP 510 application notifies GIST for path change. Downstream GIST peer 511 discovery is initiated. 512 14) Sent Confirm message has not been received by downstream GIST 513 peer. Confirm message is resent. 514 15) MRS lifetime expires. Notification by NSLP application that MRS 515 is no longer needed. 516 16) MA is established. 517 17) MA establishment failure. 519 6.3 State machine for GIST responding node 521 The following is a diagram of the GIST responding node state machine. 522 Also included is clarification of notation. 524 (see the .pdf version for missing diagram or 525 refer to Appendix A.2 if reading the .txt version) 527 Figure 3: GIST Responding Node State Machine 529 1) A Query message is received. Explicit Confirm message is required 530 for MRS installation, based on the local policy. Query message 531 might carry piggybacked NSLP data which is provided to the NSLP 532 application. 533 2) A Query message is received. MRS is installed immediately, based 534 on the local policy. Query message might carry piggybacked NSLP 535 data which is provided to the NSLP application. 536 3) Confirm message is received which causes installation of the 537 complete MRS or just installation of the used MA as a upstream 538 peer info. 539 4) Sent Response message has not been received by upstream GIST peer. 540 Response message is resent. 541 5) In case of lost Confirm message, data messages might be received 542 from the upstream GIST node (it is unaware of the lost Confirm 543 message). Response indicating the loss of the Confirm is sent back 544 to the upstream GIST node. 545 6) No_Confirm timer expires. Note that all cases of lost handshake 546 GIST messages are handled only by GIST querying node via resend of 547 Query message. 548 7) NSLP data is sent if discovery process is successfully 549 accomplished or is queued if Confirm message is still expected to 550 confirm establishment of MA. 551 8) Data messages are accepted only if complete MRS is installed, 552 e.g., there is installed upstream peer info. If not, then Confirm 553 message is expected and data message won t be accepted. Response 554 indicating the loss of the Confirm is sent back to the upstream 555 GIST node. 556 9) Change of the upstream GIST node (e.g., path change). Local policy 557 does not need explicit Confirm message for MRS installation. MRS 558 data is updated. 559 10) Change of the upstream GIST node or request for change of the 560 used connection mode (from D_mode/C_mode to better C_mode). Local 561 policy requires explicit Confirm message for MRS installation. 562 11) Request for change of the used connection mode (from 563 D_mode/C_mode to better C_mode). Local policy does not need 564 explicit Confirm message for MRS installation. MRS data is 565 updated. 566 12) MRS lifetime expires. Notification by NSLP application that MRS 567 is no longer needed. 569 7. Security Considerations 571 This document does not raise new security considerations. Any 572 security concerns with GIST are likely reflected in security related 573 NSIS work already (such as [1] or [6]). 575 8. Contributors 577 Christian Dickmann contributed to refining of the state machine since 578 01 version. 580 9. Acknowledgments 582 The authors would like to thank Robert Hancock, Ingo Juchem, Andreas 583 Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd 584 Schloer for their insightful comments. 586 10. References 588 10.1. Normative References 590 [1] Schulzrinne, H., "GIST: General Internet Signaling 591 Transport", draft-ietf-nsis-ntlp-16 (work in progress), 592 July 2008. 594 [2] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 10.2. Informative References 599 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 600 "State Machines for Extensible Authentication Protocol 601 (EAP) Peer and Authenticator", RFC4137, August 2005. 603 [4] Institute of Electrical and Electronics Engineers, 604 "Standard for Local and Metropolitan Area Networks: Port- 605 Based 606 Network Access Control", IEEE 802-1X-2004, December 607 2004. 609 [5] Fajardo, V., Ohba, Y. and R. Lopez, "State Machines for 610 Protocol for Carrying Authentication for Network Access 611 (PANA)", 612 draft-ietf-pana-statemachine-07 (work in progress), 613 April 2008. 615 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for 616 NSIS", RFC 4081, June 2005. 618 Appendix A. ASCII versions of state diagrams 620 This appendix contains the state diagrams in ASCII format. Please 621 use the PDF version whenever possible: it is much easier to 622 understand. 624 For each state there is a separate table that lists in each row: 625 - an event that triggers a transition, 626 - actions taken as a result of the incoming event, 627 - and the new state at which the transitions ends. 629 A.1. State machine for GIST querying node (Figure 2) 631 ----------- 632 State: IDLE 633 ----------- 635 Condition Action State Note 636 ------------------------+-------------------------+-----------+--- 637 tg_SendMsg |tx_Query |Wait |1) 638 |start T_No_Response |Response |** 639 |Queue NSLP data | | 640 | | | 641 Tg_ERROR |Delete MRS |IDLE | 642 |IF (MA is used) | | 643 | ((Delete MA)|| | | 644 | (Stop using shared MA))| | 645 |Tg_NetworkNotification | | 646 | | | 647 ------------------------+-------------------------+-----------+--- 649 ----------- 650 State: WaitResponse 651 ----------- 653 Condition Action State Note 654 ------------------------+-------------------------+-----------+--- 655 rx_Response(MAinfo)&& |tg_Establish_MA |Wait MA |* 656 (!MAexist) |(tx_Confirm) |Establish. |2) 657 | | | 658 | | | 659 rx_Response)|| |Install MRS |Established|3) 660 (rx_Response(MAinfo)&& |IF (RespCookie) |Downstream | 661 (MAexist)) | tx_Confirm(RespCookie)|MRS | 662 |tx_Data(Queued NSLP data)| | 663 | | | 665 (timeout T_No_Response) |Tx_Query |Wait |4) 666 &&(!MaxRetry) |restart T_No_Response |Response | 667 | | | 668 (timeout T_No_Response) |tg_MessageStatus |IDLE |5) 669 &&(MaxRetry) | | | 670 | | | 671 tg_SendMsg |Queue NSLP data |Wait |6) 672 | |Response | 673 | | | 674 rx_Data |IF(CheckPeerInfo) |Wait |7) 675 | tg_RecvMsg to Appl.|Response | 676 | | | 677 Tg_ERROR |(Delete MRS) |IDLE | 678 |IF (MA is used) | | 679 | ((Delete MA)|| | | 680 | (Stop using shared MA))| | 681 |Tg_NetworkNotification | | 682 | | | 683 ------------------------+-------------------------+-----------+--- 685 ----------- 686 State: Established Downstream MRS 687 ----------- 689 Condition Action State Note 690 ------------------------+-------------------------+-----------+--- 691 tg_SendMsg |tx_Data |Established|8) 692 |restart T_Inactive_QNode |Downstream | 693 | |MRS | 694 | | | 695 timeout T_Refresh_QNode |tx_Query |Established|9) 696 | |Downstream | 697 | |MRS | 698 | | | 699 (rx_Response)&& |Refresh MRS |Established|10) 700 (!NewPeer) |restart T_Inactive_QNode |Downstream | 701 | |MRS | 702 | | | 703 (rx_Response)|| |IF (MA is used) |Established|11) 704 (rx_Response(Mainfo)&& | (Delete MA)|| |Downstream | 705 (MAexist)))&&(NewPeer) | (Stop using shared MA)|MRS | 706 |Install MRS | | 707 |restart T_Inactive_QNode | | 708 |IF (RespCookie) | | 709 | tx_Confirm(RespCookie)| | 710 | | | 711 (rx_Response(MAinfo)&& |((Delete MA)|| |Wait MA |12) 712 (NewPeer)&&(!MA_exist)) |(Stop using shared MA)) |Establish. |* 713 |tg_Establish_MA | | 714 |(tx_Confirm) | | 715 | | | 716 ((tg_SendMsg)&&(Cmode)&&|tx_Query |Wait |13) 717 (!MAexist))|| |Queue NSLP data |Response | 718 (tg_MA_error)|| | | | 719 (tg_InvalidRoutingState)| | | 720 | | | 721 rx_Response(No_MRS_ |tx_Confirm(RespCookie) |Established|14) 722 installed)|tx_Data(Queued NSLP data)|Downstream | 723 | |MRS | 724 | | | 725 (timeout T_Inactive_ |Delete MRS |IDLE |15) 726 QNode)|||IF (MA is used) | | 727 (tg_SetStateLifetime(0))| (Delete MA)|| | | 728 | (Stop using shared MA)| | 729 |Tg_NetworkNotification | | 730 | | | 731 rx_Data |IF(CheckPeerInfo) |Established|7) 732 | tg_RecvMsg to Appl.|Downstream | 733 | |MRS | 734 | | | 735 Tg_ERROR |(Delete MRS) |IDLE | 736 |IF (MA is used) | | 737 | ((Delete MA)|| | | 738 | (Stop using shared MA))| | 739 |Tg_NetworkNotification | | 740 | | | 741 ------------------------+-------------------------+-----------+--- 743 ----------- 744 State: Wait MA Establishment 745 ----------- 747 Condition Action State Note 748 ------------------------+-------------------------+-----------+--- 749 tg_MA_Established |Install MRS |Established|16) 750 |(tx_Confirm) |Downstream |* 751 |tx_Data(Queued NSLP data)|MRS | 752 | | | 753 tg_MA_error |Delete MRS |IDLE |17) 754 |tg_MessageStatus | | 755 | | | 756 tg_SendMsg |Queue NSLP data |Wait MA |6) 757 | |Establish. | 758 | | | 759 Tg_ERROR |Delete MRS |IDLE | 760 |IF (MA is used) | | 761 | ((Delete MA)|| | | 762 | (Stop using shared MA))| | 763 |Tg_NetworkNotification | | 764 | | | 765 ------------------------+-------------------------+-----------+--- 767 Figure 4 769 A.2. State Machine for GIST responding node (Figure 3) 771 ----------- 772 State: IDLE 773 ----------- 775 Condition Action State Note 776 ------------------------+-------------------------+-----------+--- 777 rx_Query&& |tx_Response |Wait |1) 778 (ConfirmRequired) |start T_No_Confirm |Confirm | 779 |IF(NSLPdata) | | 780 | tg_RecvMsg(NSLPdata)| | 781 | to Appl.| | 782 | | | 783 rx_Query&& |tx_Response |Established|2) 784 (!ConfirmRequired) |Install MRS |Upstream | 785 |IF(NSLPdata) |MRS | 786 | tg_RecvMsg(NSLPdata)| | 787 | to Appl.| | 788 | | | 789 ------------------------+-------------------------+-----------+--- 791 ----------- 792 State: WAIT CONFIRM 793 ----------- 795 Condition Action State Note 796 ------------------------+-------------------------+-----------+--- 797 rx_Confirm |Install Upstream MRS |Established|3) 798 | |Upstream | 799 | |MRS | 800 | | | 802 rx_Query&& |tx_Response |Wait |4) 803 (ConfirmRequired) |start T_No_Confirm |Confirm | 804 |IF(NSLPdata) | | 805 | tg_RecvMsg(NSLPdata)| | 806 | to Appl.| | 807 | | | 808 rx_Data |tx_Error(No_MRS_ |Wait |5) 809 | installed)|Confirm | 810 | | | 811 timeout T_No_Confirm | |IDLE |6) 812 | | | 813 ------------------------+-------------------------+-----------+--- 815 ----------- 816 State: Established Upstream MRS 817 ----------- 819 Condition Action State Note 820 ------------------------+-------------------------+-----------+--- 821 tg_SendMsg |IF(!UpstreamPeerInfo) |Established|7) 822 | Queue NSLP data |Upstream | 823 |ELSE tx_Data |MRS | 824 | | | 825 rx_Data |IF(UpstreamPeerInfo) |Established|8) 826 | (tg_RecvMsg to Appl.)|Upstream | 827 | &&(restart_T_Expire_ |MRS | 828 | RNode)| | 829 |ELSE | | 830 | tx_Error(No_MRS_ | | 831 | installed)| | 832 | | | 833 rx_Query |IF (NewPeer) |Established|9) 834 | Update UpstreamPeerInfo|Upstream | 835 |tx_Response |MRS | 836 |restart T_Expire_RNode | | 837 | | | 838 (rx_Query)&& |Delete MRS |Wait | 839 (ConfirmRequired) |tx_Response |Confirm | 840 |start T_No_Confirm | | 841 |IF(MA is used) | | 842 | (Delete MA)|| | | 843 | (Stop using shared MA)| | 844 |IF(NSLPdata) | | 845 | tg_RecvMsg(NSLPdata) | | 846 | to Appl.| | 847 | | | 849 rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established|11) 850 (!ConfirmRequired) |restart T_Expire_RNode |Upstream | 851 |tx_Response(MAinfo) |MRS | 852 | | | 853 (timeout T_Expire_RNode)|Delete MRS |IDLE |12) 854 || |tg_NetworkNotification | | 855 (tg_SetStateLifetime(0))|IF(MA is used) | | 856 | (Delete MA)|| | | 857 | (Stop using shared MA)| | 858 | | | 859 rx_Confirm |Install UpstreamPeerInfo |Established|3) 860 |tx_Data(queued_NSLP_data)|Upstream | 861 | |MRS | 862 | | | 863 Tg_ERROR |(Delete MRS) |IDLE | 864 |IF (MA is used) | | 865 | ((Delete MA)|| | | 866 | (Stop using shared MA))| | 867 |Tg_NetworkNotification | | 868 | | | 869 ------------------------+-------------------------+-----------+--- 871 Figure 5 873 Authors' Addresses 875 Tseno Tsenov 876 Sofia, 877 Bulgaria 879 Email: tseno.tsenov@mytum.de 881 Hannes Tschofenig 882 Nokia Siemens Networks 883 Linnoitustie 6 884 Espoo 02600 885 Finland 887 Email: Hannes.Tschofenig@nsn.com 889 Xiaoming Fu 890 University of Goettingen 891 Computer Networks Group 892 Goldschmidtstr. 7 893 Goettingen 37077 894 Germany 896 Email: fu@cs.uni-goettingen.de 898 Cedric Aoun 899 Paris 900 France 902 Email: cedric@caoun.net 904 Elwyn B. Davies 905 Folly Consulting 906 Soham, Cambs 907 UK 909 Phone: +44 7889 488 335 910 Email: elwynd@dial.pipex.com 912 Full Copyright Statement 914 Copyright (C) The IETF Trust (2008). 916 This document is subject to the rights, licenses and restrictions 917 contained in BCP 78, and except as set forth therein, the authors 918 retain all their rights. 920 This document and the information contained herein are provided on an 921 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 922 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 923 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 924 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 925 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 926 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 928 Intellectual Property 930 The IETF takes no position regarding the validity or scope of any 931 Intellectual Property Rights or other rights that might be claimed to 932 pertain to the implementation or use of the technology described in 933 this document or the extent to which any license under such rights 934 might or might not be available; nor does it represent that it has 935 made any independent effort to identify any such rights. Information 936 on the procedures with respect to rights in RFC documents can be 937 found in BCP 78 and BCP 79. 939 Copies of IPR disclosures made to the IETF Secretariat and any 940 assurances of licenses to be made available, or the result of an 941 attempt made to obtain a general license or permission for the use of 942 such proprietary rights by implementers or users of this 943 specification can be obtained from the IETF on-line IPR repository at 944 http://www.ietf.org/ipr. 946 The IETF invites any interested party to bring to its attention any 947 copyrights, patents or patent applications, or other proprietary 948 rights that may cover technology that may be required to implement 949 this standard. Please address the information to the IETF at ietf- 950 ipr@ietf.org.