idnits 2.17.00 (12 Aug 2021) /tmp/idnits4040/draft-ietf-nsis-ntlp-statemachine-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 == Line 545 has weird spacing: '... ooooo oooo...' == Line 547 has weird spacing: '... ooooo oooo...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 24, 2010) is 4403 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 Summary: 0 errors (**), 0 flaws (~~), 4 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: October 24, 2010 X. Fu (Ed.) 6 Univ. Goettingen 7 C. Aoun 8 E. Davies 9 Folly Consulting 10 April 24, 2010 12 GIST State Machine 13 draft-ietf-nsis-ntlp-statemachine-10.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 August 10, 2010. 38 Copyright Notice 40 Copyright (c) 2010 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 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Abstract 67 This document describes state machines for the General Internet 68 Signaling Transport (GIST). The states of GIST nodes for a given flow 69 and their transitions are presented in order to illustrate how GIST 70 may be implemented. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Notational conventions used in state diagrams . . . . . . . 4 77 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 6 78 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8 80 5.2 Common Events . . . . . . . . . . . . . . . . . . . . . . 9 81 5.3 Common Variables . . . . . . . . . . . . . . . . . . . . . 10 82 6. State machines . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 12 84 6.2 State machine for GIST querying node . . . . . . . . . . . 12 85 6.3 State machine for GIST responding node . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 10.1 Normative References . . . . . . . . . . . . . . . . . . 19 91 10.2 Informative References . . . . . . . . . . . . . . . . . 19 92 Appendix A. State transition tables . . . . . . . . . . . . . . 20 93 A.1 State transition tables for GIST querying node . . . . . 20 94 A.2 State transition tables for GIST responding node . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 The state machines described in this document are illustrative of how 100 the GIST protocol defined in [1] may be implemented for the GIST 101 nodes in different locations of a flow path. Where there are 102 differences - [1] is authoritative. The state machines are 103 informative only. Implementations may achieve the same results using 104 different methods. 106 There are two types of possible entities for GIST signaling: 108 - GIST querying node - GIST node that initiates the discovery of the 109 next peer; 111 - GIST responding node - GIST node that is the discovered next peer; 113 We describe a set of state machines for these entities to illustrate 114 how GIST may be implemented. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [2]. 122 3. Notational conventions used in state diagrams 124 The following text is reused from [3] and the state diagrams are 125 based on the conventions specified in [4], Section 8.2.1. Additional 126 state machine details are taken from [5]. 128 The complete text is reproduced here: 130 State diagrams are used to represent the operation of the protocol by 131 a number of cooperating state machines each comprising a group of 132 connected, mutually exclusive states. Only one state of each machine 133 can be active at any given time. 135 All permissible transitions between states are represented by arrows, 136 the arrowhead denoting the direction of the possible transition. 137 Labels attached to arrows denote the condition(s) that must be met in 138 order for the transition to take place. All conditions are 139 expressions that evaluate to TRUE or FALSE; if a condition evaluates 140 to TRUE, then the condition is met. The label UCT denotes an 141 unconditional transition (i.e., UCT always evaluates to TRUE). A 142 transition that is global in nature (i.e., a transition that occurs 143 from any of the possible states if the condition attached to the 144 arrow is met) is denoted by an open arrow; i.e., no specific state is 145 identified as the origin of the transition. When the condition 146 associated with a global transition is met, it supersedes all other 147 exit conditions including UCT. The special global condition BEGIN 148 supersedes all other global conditions, and once asserted remains 149 asserted until all state blocks have executed to the point that 150 variable assignments and other consequences of their execution remain 151 unchanged. 153 On entry to a state, the procedures defined for the state (if any) 154 are executed exactly once, in the order that they appear on the page. 155 Each action is deemed to be atomic; i.e., execution of a procedure 156 completes before the next sequential procedure starts to execute. No 157 procedures execute outside of a state block. The procedures in only 158 one state block execute at a time, even if the conditions for 159 execution of state blocks in different state machines are satisfied, 160 and all procedures in an executing state block complete execution 161 before the transition to and execution of any other state block 162 occurs, i.e., the execution of any state block appears to be atomic 163 with respect to the execution of any other state block and the 164 transition condition to that state from the previous state is TRUE 165 when execution commences. The order of execution of state blocks in 166 different state machines is undefined except as constrained by their 167 transition conditions. A variable that is set to a particular value 168 in a state block retains this value until a subsequent state block 169 executes a procedure that modifies the value. 171 On completion of all of the procedures within a state, all exit 172 conditions for the state (including all conditions associated with 173 global transitions) are evaluated continuously until one of the 174 conditions is met. The label ELSE denotes a transition that occurs 175 if none of the other conditions for transitions from the state are 176 met (i.e., ELSE evaluates to TRUE if all other possible exit 177 conditions from the state evaluate to FALSE). Where two or more exit 178 conditions with the same level of precedence become TRUE 179 simultaneously, the choice as to which exit condition causes the 180 state transition to take place is arbitrary. 182 In addition to the above notation, there are a couple of 183 clarifications specific to this document. First, all boolean 184 variables are initialized to FALSE before the state machine execution 185 begins. Second, the following notational shorthand is specific to 186 this document: 188 = | | ... 190 Execution of a statement of this form will result in 191 having a value of exactly one of the expressions. The logic for 192 which of those expressions gets executed is outside of the state 193 machine and could be environmental, configurable, or based on 194 another state machine such as that of the method. 196 4. State Machine Symbols 198 ( ) 199 Used to force the precedence of operators in Boolean expressions 200 and to delimit the argument(s) of actions within state boxes. 202 ; 203 Used as a terminating delimiter for actions within state boxes. 204 Where a state box contains multiple actions, the order of 205 execution follows the normal English language conventions for 206 reading text. 208 = 209 Assignment action. The value of the expression to the right of 210 the operator is assigned to the variable to the left of the 211 operator. Where this operator is used to define multiple 212 assignments, e.g., a = b = X the action causes the value of the 213 expression following the right-most assignment operator to be 214 assigned to all of the variables that appear to the left of the 215 right-most assignment operator. 217 ! 218 Logical NOT operator. 220 && 221 Logical AND operator. 223 || 224 Logical OR operator. 226 if...then... 227 Conditional action. If the Boolean expression following the if 228 evaluates to TRUE, then the action following the then is executed. 230 { statement 1, ... statement N } 231 Compound statement. Braces are used to group statements that are 232 executed together as if they were a single statement. 234 != 235 Inequality. Evaluates to TRUE if the expression to the left of 236 the operator is not equal in value to the expression to the right. 238 == 239 Equality. Evaluates to TRUE if the expression to the left of the 240 operator is equal in value to the expression to the right. 242 > 243 Greater than. Evaluates to TRUE if the value of the expression to 244 the left of the operator is greater than the value of the 245 expression to the right. 247 <= 248 Less than or equal to. Evaluates to TRUE if the value of the 249 expression to the left of the operator is either less than or 250 equal to the value of the expression to the right. 252 ++ 253 Increment the preceding integer operator by 1. 255 + 256 Arithmetic addition operator. 258 & 259 Bitwise AND operator. 261 5. Common Rules 263 Throughout the document we use terms defined in the [1], such as 264 Query, Response, Confirm. 266 State machine represents handling of GIST messages that match a 267 Message Routing State's MRI, NSLPID and SID and with no protocol 268 errors. Separate parallel instances of the state machines should 269 handle messages for different Message Routing States. 271 The state machine states represent the upstream/downstream peers 272 states of the Message Routing State. 274 For simplification not all objects included in a message are shown. 275 Only those that are significant for the case are shown. State 276 machines do not present handling of messages that are not significant 277 for management of the states. 279 The state machines presented in this document do not cover all 280 functions of a GIST node. Functionality of message forwarding, 281 transmission of NSLP data without MRS establishment and providing of 282 the received messages to the appropriate MRS, we refer as "Lower 283 level pre-processing" step. Pre-processing provides to the 284 appropriate MRS state machine only the messages which are matched 285 against waiting Query/Response cookies, or established MRS 286 MRI+NSLPID+SID primary key. This is presented by "rx_*" events in the 287 state machines. 289 Management of Messaging Associations (MA) is considered in the 290 document via procedures, events and variables, which describe MA 291 interaction with the MRS state machines. A state machine for MA 292 management is not explicitly presented. 294 5.1 Common Procedures 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 Tx_Data: 306 Transmit of Data message 308 Tg_MessageStatus: 309 NSLP/GIST API message informing NSLP application for unsuccessful 310 delivery of a message 312 Tg_RecvMsg: 313 NSLP/GIST API message that provides received message to the NSLP 314 application 316 Tg_NetworkNotification: 317 NSLP/GIST API message that informs NSLP application for change in 318 MRS 320 Install downstream/upstream MRS: 321 Install new Message Routing State and save the corespoding peer 322 state info (IP address and UDP port or pointer to the used MA) for 323 the current Message Routing State or update the coresponding peer 324 state info. 326 Delete MRS: 327 Delete installed downstream/upstream peer's info for the current 328 Message Routing State and delete the Message Routing State if 329 required. 331 Refresh MRS: 332 Refreshes installed MRS. 334 Queue NSLP info: 335 Save NLSP messages in a queue until conditions for their sending 336 are present, e.g. a required MA association is established. 338 CheckPeerInfo: 339 The sender of the received data message is matched against the 340 installed peer info in the MRS. 342 Delete MA: 343 Delete/disconnect used MA. 345 Stop using shared MA: 346 Stop using shared MA. If the shared MA is no more used by any 347 other MRSs, it depends on the local policy whether it is deleted 348 or kept. 350 Tg_Establish_MA: 351 Trigers establishment of a new MA. 353 Start/Restart a timer variable (Section 5.3): 354 Start/Restart of a certain timer. 356 Install/Update/Delete UpstreamPeerInfo variable (Section 5.3): 357 Management of upstream peer info in responding node state machine. 359 5.2 Common Events 361 Rx_Query: 362 Receive of Query message 364 Rx_Response: 365 Receive of Response message 367 Rx_Confirm: 368 Receive of Confirm message 370 Rx_Data: 371 Receive of Data message 373 Tg_SendMsg: 374 NSLP/GIST API message from NSLP application that requests 375 transmission of a NSLP message. 377 Tg_SetStateLifetime(time_period): 378 NSLP/GIST API message providing info for the lifetime of a Routing 379 State (RS), required by the application. "Time_period = 0" 380 represents the cancellation of established RSs/MAs, invoked by the 381 NSLP application. 383 Tg_InvalidRoutingState: 384 NSLP/GIST API notification from NSLP application for path change. 386 Tg_ERROR: 387 General Error event / system level error. 389 Tg_MA_Established: 390 A new MA has been successfully established. 392 Tg_MA_Error: 393 Error event with used MA. 395 Timeout a timer variable (Section 5.3): 396 Timeout of a certain timer. 398 5.3 Common Variables 400 Variables listed in this section are defined as: 402 - Specific information carried in the received messages. 404 - Conditions that are results of processes not defined in the state 405 machine model. 407 State machine logic is based on these general conditions and message 408 parameters. 410 The type of mode and destination info is determined by NSLP 411 application parameters and local GIST policy. Here it is represented 412 by the common variables Dmode, Cmode and MAinfo. 414 Cmode: 415 The message MUST be transmitted in Cmode. This is specified by 416 "Message transfer attributes" set by NSLP application to any of 417 the following values: 419 "Reliability" is set to TRUE. 421 "Security" is set to values that request secure handling of a 422 message. 424 "Local processing" is set to values that require services offered 425 by Cmode (e.g., congestion control). [1] 427 Dmode: 428 The message MUST be transmitted in Dmode. This is specified by 429 local policy rules and in case that the "Message transfer 430 attributes" are not set by NSLP application to any of the 431 following values: 433 "Reliability" is set to TRUE. 435 "Security" is set to values that request special security handling 436 of a message. 438 "Local processing" is set to values that require services offered 439 by Cmode [1] 441 MAinfo: 442 GIST message parameters describing the required MA or proposed MA, 443 e.g., "Stack-proposal" and "Stack-Configuration-Data" [1]. 445 NSLPdata: 446 NSLP application data. 448 RespCookie: 449 Responder Cookie that is being sent by the responding node with 450 the Response message in case that its local policy requires a 451 confirmation from the querying node. 453 ConfirmRequired: 454 Indicator that a Confirm message is required by the local policy 455 rule for installation of a new MRS. 457 NewPeer: 458 Indicator that a Response message is received from new responding 459 peer. 461 MAexist: 462 Indicator that an existing MA will be reused in data transfer 463 between peers. 465 UpstreamPeerInfo: 466 Upstream peer info that is saved in an established MRS. 468 T_Inactive_QNode: 469 Message Routing State lifetime timer in querying node 471 T_Expired_RNode: 472 Message Routing State lifetime timer in responding node 474 T_Refresh_QNode: 475 Message Routing State refresh timer in querying node 477 T_No_Response: 478 Timer for the waiting period for Response message in querying node 480 T_No_Confirm: 481 Timer for the waiting period for Confirm message in responding 482 node 484 No_MRS_Installed: 485 Data sent by responding node via a Response message that indicates 486 loss of Confirm message. 488 6. State machines 490 The following section presents the state machine diagrams of GIST 491 peers. The document is issued in two formats - .pdf and .txt. 493 In the .pdf document, the state machine diagrams are depicted in 494 details in this section. All state machine information (triggering 495 event, action taken and variables status) is visualized on the 496 diagrams. 498 In the .txt document, state machine diagrams depict only transition 499 numbers. Following each diagram is a list of state transition 500 descriptions. Complete transition details (triggering event, action 501 taken and variables status) are given in state transition tables in 502 Appendix A. 504 Please use the .pdf version whenever possible. It is the clearer 505 representation of the state machine. In case of a difference between 506 the two documents, please refer to the .pdf version. 508 6.1 Diagram notations 510 +--------------------------------+ 511 | STATE | 512 +--------------+-----------------+ 513 | 514 | 515 ooooo 516 o N o Transition N 517 ooooo 518 | 519 v 520 +--------------------------------+ 521 | STATE | 522 +--------------------------------+ 524 Figure 1: Diagram notations 526 6.2 State machine for GIST querying node 528 GIST querying node state machine diagram is depicted below. 529 Transition descriptions follow. 531 For .txt version, please refer to Appendix A.1 for complete 532 transition details (triggering event, action taken and variables 533 status). 535 +-----------+ ooooo 536 | Any State +----------o 18 o 537 +-----------+ ooooo 538 | 539 v 540 +-----------------------------------------------------------------+ 541 | IDLE | 542 +--+--------------------------------------------------------------+ 543 | ^ ^ ^ 544 | | | | 545 ooooo ooooo ooooo ooooo ooooo | | 546 o 1 o o 2 o +o 3 o+ +o 4 o+ +o 5 o+ | | 547 ooooo ooooo | ooooo | | ooooo | | ooooo | | | 548 | | | | | | | | | | 549 v | | v | v | v | | 550 +-----------+-----+----------+----------+--------+ | | 551 | Wait Response | | | 552 +--+-------------------------------------+-------+ | | 553 | ^ | | | 554 | | | | | 555 ooooo | ooooo ooooo ooooo | 556 o 6 o | +o 5 o+ o 7 o o 8 o | 557 ooooo | | ooooo | ooooo ooooo | 558 | | | | | | | 559 | | | v v | | 560 | | +----+-------------------------------+---+ | 561 | | | Wait MA Establishment | | 562 | | +------------------------------+---------+ | 563 | | ^ | | 564 | | | | | 565 | ooooo ooooo ooooo ooooo ooooo 566 | o 9 o o 11 o +o 13 o+ o 12 o o 10 o 567 | ooooo ooooo | ooooo | ooooo ooooo 568 | | | | | | | 569 v | | | v v | 570 +----------+----------+--------+------------------------------+---+ 571 | Established Downstream MRS | 572 +--+-----------+-----------+-----------+-----------+--------------+ 573 | ^ | ^ | ^ | ^ | ^ 574 | | | | | | | | | | 575 | ooooo | | ooooo | | ooooo | | ooooo | | ooooo | 576 +o 16 o+ +o 14 o+ +o 15 o+ +o 4 o+ +o 17 o+ 577 ooooo ooooo ooooo ooooo ooooo 578 Figure 2: GIST Querying Node State Machine 580 1**) Initial request from NSLP application is received, which 581 triggers Query messages requesting either Dmode or Cmode. 582 Depending on nodes local policy NSLP data might be piggybacked in 583 the Query requesting Dmode. Query may carry MAinfo if Cmode 584 transport is needed. 585 2) T_No_Response timer expires and maximum number of retries has been 586 reached. NSLP application is notified for the GIST peer discovery 587 failure. 588 3) T_No_Response timer expires. Query is resent. 589 4) Data message is received. It is checked if its sender matches the 590 installed downstream peer info in the MRS and then processed. In 591 WaitResponse state, this event might happen in the process of MA 592 upgrade, when the downstream peer is still not aware of 593 establishment of the new MA. 594 5) NSLP application provides data for sending. NSLP data is queued, 595 because downstream peer is not discovered or required MA is still 596 not established. 597 6) Response message is received. If Dmode connection is requested or 598 available MA can be reused for requested Cmode, the MRS is 599 established. 600 7*) Response message is received. If Cmode connection must be 601 established and there is no available MA to be reused, MA 602 establishment is initiated and waited to be completed. 603 8) A MA establishment fails. NSLP application is notified for 604 unsuccessful message delivery. 605 9) NSLP application provides data for sending and requested transport 606 parameters require upgrade of established MRS from Dmode/Cmode to 607 Cmode. Or NSLP application notifies GIST for path change. As a 608 result downstream GIST peer discovery is initiated. 609 10) MRS lifetime expires or NSLP application notifies that MRS is no 610 longer needed. MRS is deleted. If not needed, MA is deleted, too. 611 NSLP application is notified for MRS change. 612 11*) Path change detected as a Response message from a new downstream 613 GIST peer is received. A new MA must be established for requested 614 Cmode. 615 12*) A new MA is established. MRS is installed. Queued NSLP data is 616 sent. 617 13) T_Refresh_QNode timer expires. Query message is sent. 618 14) NSLP application provides data for sending. It is sent via Data 619 message towards downstream GIST peer. 620 15) Response message from the downstream GIST peer is received. The 621 peer is not changed. MRS is refreshed (T_Refresh_QNode timer is 622 restarted). 623 16) Path change detected as a Response message from a new downstream 624 GIST peer is received. Dmode is requested or existing MA can be 625 reused for requested Cmode. 627 17) Responding peer indicates that it has not received a Confirm 628 message and it has no established upstream MRS. Confirm message is 629 resent. 630 18) General error or system level error occurs. MRS is deleted. If 631 not needed, MA is deleted, too. NSLP application is notified for 632 the MRS change. 634 Remarks: 635 *) Response and Confirm messages might be sent either in Dmode or 636 Cmode, before or after MA establishment depending on nodes local 637 3-way handshake policy and the availability of MAs to be reused. See 638 [1] for details. 639 **) Depending on GIST local policy, NSLPdata might be send as payload 640 of Query and Confirm messages (piggybacking). 642 6.3 State machine for GIST responding node 644 GIST responding node state machine diagram is depicted below. 645 Transition descriptions follow. 647 For .txt version, please refer to Appendix A.2 for complete 648 transition details (triggering event, action taken and variables 649 status). 651 +-----------+ ooooo 652 | Any State +----------o 14 o 653 +-----------+ ooooo 654 | 655 v 656 +-----------------------------------------------------------------+ 657 | IDLE | 658 +--+-------------------------------+------------------------------+ 659 | ^ | ^ 660 | | | | 661 ooooo | ooooo ooooo ooooo 662 o 1 o | o 2 o +o 4 o+ o 3 o 663 ooooo | ooooo | ooooo | ooooo 664 | | | | | | 665 | | v | v | 666 | | +--------------------+---------------+---+ 667 | | | Wait Confirm | 668 | | +---------+------------------+-----------+ 669 | | | ^ | ^ 670 | | | | | | 671 | ooooo ooooo ooooo ooooo | ooooo | 672 | +o 13 o+ o 8 o o 5 o o 7 o +o 6 o+ 673 | | ooooo | ooooo ooooo ooooo ooooo 674 | | | | | | 675 v | v | v | 676 +------+-------------+------------------------+-------------------+ 677 | Established Upstream MRS | 678 +------+-------------+-------------+------------+-----------------+ 679 | ^ | ^ | ^ | ^ 680 | | | | | | | | 681 | ooooo | | ooooo | | ooooo | | ooooo | 682 +o 9 o+ +o 11 o+ +o 12 o+ +o 10 o+ 683 ooooo ooooo ooooo ooooo 685 Figure 3: GIST Responding Node State Machine 687 1) A Query message is received. MRS is installed immediately, because 688 local policy permits it. Query message might carry piggybacked 689 NSLP data which is provided to the NSLP application. 690 2) A Query message is received. Local policy requires explicit 691 Confirm message for MRS installation. Query message might carry 692 piggybacked NSLP data which is provided to the NSLP application. 693 3) T_No_Confirm timer expires. Note that all cases of lost handshake 694 GIST messages are handled only by GIST querying node via resend of 695 Query message. 696 4) A Query message is received again. This means that sent Response 697 message has not been received by upstream GIST peer. Response 698 message is resent. 700 5) A Confirm message is received which causes installation of the 701 upstream MRS. 702 6) In case of lost Confirm message, data messages might be received 703 from the upstream GIST node (it is unaware of the lost Confirm 704 message). Response indicating the loss of the Confirm is sent back 705 to the upstream GIST node. 706 7) A Query message is received with request for change of the used 707 connection mode (from Dmode/Cmode to better Cmode) or from new 708 upstream GIST node. Local policy requires explicit Confirm message 709 for MRS installation. 710 8) MRS lifetime expires or NSLP application notifies that MRS is no 711 longer needed. MRS is deleted. If used and not needed, MA is 712 deleted, too. NSLP application is notified for MRS change. 713 9) NSLP application provides data for sending. NSLP data is sent if 714 discovery process is successfully accomplished or it is queued if 715 Confirm message is still expected to confirm establishment of a 716 MA. 717 10) A Query message is received. If it is sent from a new upstream 718 GIST node then there is a path change. Local policy does not need 719 explicit Confirm message for MRS installation. MRS data is 720 updated. 721 11) A Query message is received with request for change of the used 722 connection mode (from Dmode/Cmode to better Cmode). Local policy 723 does not need explicit Confirm message for MRS installation. MRS 724 data is updated. 725 12) A Data message is received. Data messages are accepted only if 726 complete MRS is installed, e.g., there is installed upstream peer 727 info. If not, then Confirm message is expected and Data message is 728 not accepted. Response indicating the loss of the Confirm is sent 729 back to the upstream GIST node. 730 13) A Confirm message is received. It accomplishes assignment of an 731 existing MA (or establishment of a new MA) needed for data 732 transferring between peers. The information for the used MA is 733 installed as upstream peer info. 734 14) General error or system level error occurs. MRS is deleted. If 735 not needed, MA is deleted, too. NSLP application is notified for 736 MRS change. 738 7. Security Considerations 740 This document does not raise new security considerations. Security 741 considerations are addressed in GIST specification [1] and in [6]. 743 8. IANA Considerations 745 This document has no actions for IANA. 747 9. Acknowledgments 749 The authors would like to thank Christian Dickmann who contributed to 750 refining of the state machine. 752 The authors would like to thank Robert Hancock, Ingo Juchem, Andreas 753 Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd 754 Schloer for their insightful comments. 756 10. References 758 10.1. Normative References 760 [1] Schulzrinne, H., "GIST: General Internet Signaling 761 Transport", draft-ietf-nsis-ntlp-20 (work in progress), 762 December 2009. 764 [2] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, March 1997. 767 10.2. Informative References 769 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 770 "State Machines for Extensible Authentication Protocol 771 (EAP) Peer and Authenticator", RFC4137, August 2005. 773 [4] Institute of Electrical and Electronics Engineers, 774 "Standard for Local and Metropolitan Area Networks: Port- 775 Based Network Access Control", IEEE 802-1X-2004, December 776 2004. 778 [5] Fajardo, V., Ohba, Y. and R. Marin-Lopez, "State Machines 779 for Protocol for Carrying Authentication for Network 780 Access (PANA)", RFC 5609, August 2009. 782 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for 783 NSIS", RFC 4081, June 2005. 785 Appendix A. State transition tables 787 State transition tables given below represent the state diagrams in 788 ASCII format. Please use the .pdf version whenever possible. It is 789 the clearer representation of the state machine. 791 For each state there is a separate table that lists in each row: 792 - an event that triggers a transition, 793 - actions taken as a result of the incoming event, 794 - and the new state at which the transitions ends. 796 A.1. State transition tables for GIST querying node 798 Please refer to state machine diagram on Figure 2. 800 ----------- 801 State: IDLE 802 ----------- 804 +Transition 805 | |Condition |Action |State 806 V--+------------------------+-------------------------+----------- 807 1) |tg_SendMsg |tx_Query |Wait 808 ** | |start T_No_Response |Response 809 | |Queue NSLP data | 810 | | | 811 18)|Tg_ERROR |Delete MRS |IDLE 812 | |IF (MA is used) | 813 | | ((Delete MA)|| | 814 | | (Stop using shared MA))| 815 | |Tg_NetworkNotification | 816 | | | 817 ---+------------------------+-------------------------+----------- 819 ----------- 820 State: WaitResponse 821 ----------- 823 +Transition 824 | |Condition |Action |State 825 V--+------------------------+-------------------------+----------- 826 2) |(timeout T_No_Response) |tg_MessageStatus |IDLE 827 |&&(MaxRetry) | | 828 | | | 829 3) |(timeout T_No_Response) |Tx_Query |Wait 830 |&&(!MaxRetry) |restart T_No_Response |Response 831 | | | 833 4) |rx_Data |IF(CheckPeerInfo) |Wait 834 | | tg_RecvMsg to Appl.|Response 835 | | | 836 5) |tg_SendMsg |Queue NSLP data |Wait 837 | | |Response 838 | | | 839 6) |rx_Response)|| |Install MRS |Established 840 |(rx_Response(MAinfo)&& |IF (RespCookie) |Downstream 841 |(MAexist)) | tx_Confirm(RespCookie)|MRS 842 | |tx_Data(Queued NSLP data)| 843 | | | 844 7) |rx_Response(MAinfo)&& |tg_Establish_MA |Wait MA 845 * |(!MAexist) |(tx_Confirm) |Establish. 846 | | | 847 | | | 848 18)|Tg_ERROR |(Delete MRS) |IDLE 849 | |IF (MA is used) | 850 | | ((Delete MA)|| | 851 | | (Stop using shared MA))| 852 | |Tg_NetworkNotification | 853 | | | 854 ---+------------------------+-------------------------+----------- 856 ----------- 857 State: Established Downstream MRS 858 ----------- 860 +Transition 861 | |Condition |Action |State 862 V--+------------------------+-------------------------+----------- 863 4) |rx_Data |IF(CheckPeerInfo) |Established 864 | | tg_RecvMsg to Appl.|Downstream 865 | | |MRS 866 | | | 867 9) |((tg_SendMsg)&&(Cmode)&&|tx_Query |Wait 868 |(!MAexist))|| |Queue NSLP data |Response 869 |(tg_MA_error)|| | | 870 |(tg_InvalidRoutingState)| | 871 | | | 872 10)|(timeout T_Inactive_ |Delete MRS |IDLE 873 | QNode)|||IF (MA is used) | 874 |(tg_SetStateLifetime(0))| (Delete MA)|| | 875 | | (Stop using shared MA)| 876 | |Tg_NetworkNotification | 877 | | | 879 11)|(rx_Response(MAinfo)&& |((Delete MA)|| |Wait MA 880 * |(NewPeer)&&(!MA_exist)) |(Stop using shared MA)) |Establish. 881 | |tg_Establish_MA | 882 | |(tx_Confirm) | 883 | | | 884 13)|timeout T_Refresh_QNode |tx_Query |Established 885 | | |Downstream 886 | | |MRS 887 | | | 888 14)|tg_SendMsg |tx_Data |Established 889 | |restart T_Inactive_QNode |Downstream 890 | | |MRS 891 | | | 892 15)|(rx_Response)&& |Refresh MRS |Established 893 |(!NewPeer) |restart T_Inactive_QNode |Downstream 894 | | |MRS 895 | | | 896 16)|(rx_Response)|| |IF (MA is used) |Established 897 |(rx_Response(Mainfo)&& | (Delete MA)|| |Downstream 898 |(MAexist)))&&(NewPeer) | (Stop using shared MA)|MRS 899 | |Install MRS | 900 | |restart T_Inactive_QNode | 901 | |IF (RespCookie) | 902 | | tx_Confirm(RespCookie)| 903 | | | 904 17)|rx_Response(No_MRS_ |tx_Confirm(RespCookie) |Established 905 | installed)|tx_Data(Queued NSLP data)|Downstream 906 | | |MRS 907 | | | 908 18)|Tg_ERROR |(Delete MRS) |IDLE 909 | |IF (MA is used) | 910 | | ((Delete MA)|| | 911 | | (Stop using shared MA))| 912 | |Tg_NetworkNotification | 913 | | | 914 ---+------------------------+-------------------------+----------- 916 ----------- 917 State: Wait MA Establishment 918 ----------- 920 +Transition 921 | |Condition |Action |State 922 V--+------------------------+-------------------------+----------- 923 5) |tg_SendMsg |Queue NSLP data |Wait MA 924 | | |Establish. 925 | | | 927 8) |tg_MA_error |Delete MRS |IDLE 928 | |tg_MessageStatus | 929 | | | 930 12)|tg_MA_Established |Install MRS |Established 931 * | |(tx_Confirm) |Downstream 932 | |tx_Data(Queued NSLP data)|MRS 933 | | | 934 18)|Tg_ERROR |Delete MRS |IDLE 935 | |IF (MA is used) | 936 | | ((Delete MA)|| | 937 | | (Stop using shared MA))| 938 | |Tg_NetworkNotification | 939 | | | 940 ---+------------------------+-------------------------+----------- 942 A.2. State transition tables for GIST responding node 944 Please refer to state machine diagram on Figure 3. 946 ----------- 947 State: IDLE 948 ----------- 950 +Transition 951 | |Condition |Action |State 952 v--+------------------------+-------------------------+----------- 953 1) |rx_Query&& |tx_Response |Established 954 |(!ConfirmRequired) |Install MRS |Upstream 955 | |IF(NSLPdata) |MRS 956 | | tg_RecvMsg(NSLPdata)| 957 | | to Appl.| 958 | | | 959 2) |rx_Query&& |tx_Response |Wait 960 |(ConfirmRequired) |start T_No_Confirm |Confirm 961 | |IF(NSLPdata) | 962 | | tg_RecvMsg(NSLPdata)| 963 | | to Appl.| 964 | | | 965 ---+------------------------+-------------------------+----------- 967 ----------- 968 State: WAIT CONFIRM 969 ----------- 971 +Transition 972 | |Condition |Action |State 973 v--+------------------------+-------------------------+----------- 974 3) |timeout T_No_Confirm | |IDLE 975 | | | 976 4) |rx_Query&& |tx_Response |Wait 977 |(ConfirmRequired) |start T_No_Confirm |Confirm 978 | |IF(NSLPdata) | 979 | | tg_RecvMsg(NSLPdata)| 980 | | to Appl.| 981 | | | 982 5) |rx_Confirm |Install Upstream MRS |Established 983 | | |Upstream 984 | | |MRS 985 | | | 986 6) |rx_Data |tx_Response(No_MRS_ |Wait 987 | | installed)|Confirm 988 | | | 989 14)|(Tg_ERROR)|| |(Delete MRS) |IDLE 990 |(Tg_MA_Error) |IF (MA is used) | 991 | | ((Delete MA)|| | 992 | | (Stop using shared MA))| 993 | |Tg_NetworkNotification | 994 | | | 995 ---+------------------------+-------------------------+----------- 997 ----------- 998 State: Established Upstream MRS 999 ----------- 1001 +Transition 1002 | |Condition |Action |State 1003 v--+------------------------+-------------------------+----------- 1004 7) |(rx_Query)&& |Delete MRS |Wait 1005 |(ConfirmRequired) |tx_Response |Confirm 1006 | |start T_No_Confirm | 1007 | |IF(MA is used) | 1008 | | (Delete MA)|| | 1009 | | (Stop using shared MA)| 1010 | |IF(NSLPdata) | 1011 | | tg_RecvMsg(NSLPdata) | 1012 | | to Appl.| 1013 | | | 1014 8) |(timeout T_Expire_RNode)|Delete MRS |IDLE 1015 ||| |tg_NetworkNotification | 1016 |(tg_SetStateLifetime(0))|IF(MA is used) | 1017 | | (Delete MA)|| | 1018 | | (Stop using shared MA)| 1019 | | | 1020 9) |tg_SendMsg |IF(!UpstreamPeerInfo) |Established 1021 | | Queue NSLP data |Upstream 1022 | |ELSE tx_Data |MRS 1023 | | | 1024 10)|rx_Query |IF (NewPeer) |Established 1025 | | Update UpstreamPeerInfo|Upstream 1026 | |tx_Response |MRS 1027 | |restart T_Expire_RNode | 1028 | | | 1029 11)|rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established 1030 |(!ConfirmRequired) |restart T_Expire_RNode |Upstream 1031 | |tx_Response(MAinfo) |MRS 1032 | | | 1033 12)|rx_Data |IF(UpstreamPeerInfo) |Established 1034 | | (tg_RecvMsg to Appl.)|Upstream 1035 | | &&(restart_T_Expire_ |MRS 1036 | | RNode)| 1037 | |ELSE | 1038 | | tx_Error(No_MRS_ | 1039 | | installed)| 1040 | | | 1041 13)|rx_Confirm |Install UpstreamPeerInfo |Established 1042 | |tx_Data(queued_NSLP_data)|Upstream 1043 | | |MRS 1044 | | | 1045 14)|(Tg_ERROR)|| |(Delete MRS) |IDLE 1046 |(Tg_MA_Error) |IF (MA is used) | 1047 | | ((Delete MA)|| | 1048 | | (Stop using shared MA))| 1049 | |Tg_NetworkNotification | 1050 | | | 1051 ---+------------------------+-------------------------+----------- 1052 Authors' Addresses 1054 Tseno Tsenov 1055 Sofia, Bulgaria 1057 Email: tseno.tsenov@mytum.de 1059 Hannes Tschofenig 1060 Nokia Siemens Networks 1061 Linnoitustie 6 1062 Espoo 02600 1063 Finland 1065 Email: Hannes.Tschofenig@nsn.com 1067 Xiaoming Fu (editor) 1068 University of Goettingen 1069 Computer Networks Group 1070 Goldschmidtstr. 7 1071 Goettingen 37077 1072 Germany 1074 Email: fu@cs.uni-goettingen.de 1076 Cedric Aoun 1077 Paris, France 1079 Email: cedric@caoun.net 1081 Elwyn B. Davies 1082 Folly Consulting 1083 Soham, Cambs, UK 1085 Phone: +44 7889 488 335 1086 Email: elwynd@dial.pipex.com