idnits 2.17.1 draft-ietf-nsis-ntlp-statemachine-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 991. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1007), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 518 has weird spacing: '... C_mode conne...' -- 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 (October 21, 2005) is 6752 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') Summary: 6 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 Expires: April 25, 2006 Siemens 5 X. Fu 6 Univ. Goettingen 7 C. Aoun 8 ZTE/ENST Paris 9 E. Davies 10 Folly Consulting 11 October 21, 2005 13 GIST State Machine 14 draft-ietf-nsis-ntlp-statemachine-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 25, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 47 This document describes the state machines for the General Internet 48 Signaling Transport (GIST). The states of GIST nodes for a given flow 49 and their transitions are presented in order to illustrate how GIST 50 may be implemented. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Notational conventions used in state diagrams . . . . . . . 3 57 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 5 58 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 7 60 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 9 61 5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 11 62 6. State machines . . . . . . . . . . . . . . . . . . . . . . . 12 63 6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 12 64 6.2 State machine for GIST querying node . . . . . . . . . . . 12 65 6.3 State machine for GIST responding node . . . . . . . . . . 13 66 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 67 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 68 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 11.1 Normative References . . . . . . . . . . . . . . . . . . 16 72 11.2 Informative References . . . . . . . . . . . . . . . . . 16 73 Appendix A. ASCII versions of the state diagrams . . . . . . . . 17 74 A.1 State machine for GIST querying node (Figure 2) . . . . 17 75 A.2 State Machine for GIST responding node (Figure 3) . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 77 Intellectual Property and Copyright Statements . . . . . . . 24 79 1. Introduction 81 This document describes the state machines for GIST [1], trying to 82 show how GIST can be implemented to support its deployment. The 83 state machines described in this document are illustrative of how the 84 GIST protocol defined in [1] may be implemented for the GIST nodes in 85 different locations of a flow path. Where there are differences [1] 86 are authoritative. The state machines are informative only. 87 Implementations may achieve the same results using different methods. 89 There are two types of possible entities for GIST signaling: 91 - GIST querying node - GIST node that initiates the discovery of the 92 next peer; 94 - GIST responding node - GIST node that is the discovered next peer; 96 We describe a set of state machines for these entities to illustrate 97 how GIST may be implemented. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [2]. 105 3. Notational conventions used in state diagrams 107 The following text is reused from [3] and the state diagrams are 108 based on the conventions specified in [4], Section 8.2.1. Additional 109 state machine details are taken from [5]. 111 The complete text is reproduced here: 113 State diagrams are used to represent the operation of the protocol by 114 a number of cooperating state machines each comprising a group of 115 connected, mutually exclusive states. Only one state of each machine 116 can be active at any given time. 118 All permissible transitions between states are represented by arrows, 119 the arrowhead denoting the direction of the possible transition. 120 Labels attached to arrows denote the condition(s) that must be met in 121 order for the transition to take place. All conditions are 122 expressions that evaluate to TRUE or FALSE; if a condition evaluates 123 to TRUE, then the condition is met. The label UCT denotes an 124 unconditional transition (i.e., UCT always evaluates to TRUE). A 125 transition that is global in nature (i.e., a transition that occurs 126 from any of the possible states if the condition attached to the 127 arrow is met) is denoted by an open arrow; i.e., no specific state is 128 identified as the origin of the transition. When the condition 129 associated with a global transition is met, it supersedes all other 130 exit conditions including UCT. The special global condition BEGIN 131 supersedes all other global conditions, and once asserted remains 132 asserted until all state blocks have executed to the point that 133 variable assignments and other consequences of their execution remain 134 unchanged. 136 On entry to a state, the procedures defined for the state (if any) 137 are executed exactly once, in the order that they appear on the page. 138 Each action is deemed to be atomic; i.e., execution of a procedure 139 completes before the next sequential procedure starts to execute. No 140 procedures execute outside of a state block. The procedures in only 141 one state block execute at a time, even if the conditions for 142 execution of state blocks in different state machines are satisfied, 143 and all procedures in an executing state block complete execution 144 before the transition to and execution of any other state block 145 occurs, i.e., the execution of any state block appears to be atomic 146 with respect to the execution of any other state block and the 147 transition condition to that state from the previous state is TRUE 148 when execution commences. The order of execution of state blocks in 149 different state machines is undefined except as constrained by their 150 transition conditions. A variable that is set to a particular value 151 in a state block retains this value until a subsequent state block 152 executes a procedure that modifies the value. 154 On completion of all of the procedures within a state, all exit 155 conditions for the state (including all conditions associated with 156 global transitions) are evaluated continuously until one of the 157 conditions is met. The label ELSE denotes a transition that occurs 158 if none of the other conditions for transitions from the state are 159 met (i.e., ELSE evaluates to TRUE if all other possible exit 160 conditions from the state evaluate to FALSE). Where two or more exit 161 conditions with the same level of precedence become TRUE 162 simultaneously, the choice as to which exit condition causes the 163 state transition to take place is arbitrary. 165 In addition to the above notation, there are a couple of 166 clarifications specific to this document. First, all boolean 167 variables are initialized to FALSE before the state machine execution 168 begins. Second, the following notational shorthand is specific to 169 this document: 171 = | | ... 173 Execution of a statement of this form will result in 174 having a value of exactly one of the expressions. The logic for 175 which of those expressions gets executed is outside of the state 176 machine and could be environmental, configurable, or based on 177 another state machine such as that of the method. 179 4. State Machine Symbols 181 MA 182 Messaging Association 184 Upstream/Downstream MRS 185 Message Routing State with upstream/downstream peer state info 187 ( ) 188 Used to force the precedence of operators in Boolean expressions 189 and to delimit the argument(s) of actions within state boxes. 191 ; 192 Used as a terminating delimiter for actions within state boxes. 193 Where a state box contains multiple actions, the order of 194 execution follows the normal English language conventions for 195 reading text. 197 = 198 Assignment action. The value of the expression to the right of 199 the operator is assigned to the variable to the left of the 200 operator. Where this operator is used to define multiple 201 assignments, e.g., a = b = X the action causes the value of the 202 expression following the right-most assignment operator to be 203 assigned to all of the variables that appear to the left of the 204 right-most assignment operator. 206 ! 207 Logical NOT operator. 209 && 210 Logical AND operator. 212 || 213 Logical OR operator. 215 if...then... 216 Conditional action. If the Boolean expression following the if 217 evaluates to TRUE, then the action following the then is executed. 219 { statement 1, ... statement N } 220 Compound statement. Braces are used to group statements that are 221 executed together as if they were a single statement. 223 != 224 Inequality. Evaluates to TRUE if the expression to the left of 225 the operator is not equal in value to the expression to the right. 227 == 228 Equality. Evaluates to TRUE if the expression to the left of the 229 operator is equal in value to the expression to the right. 231 > 232 Greater than. Evaluates to TRUE if the value of the expression to 233 the left of the operator is greater than the value of the 234 expression to the right. 236 <= 237 Less than or equal to. Evaluates to TRUE if the value of the 238 expression to the left of the operator is either less than or 239 equal to the value of the expression to the right. 241 ++ 242 Increment the preceding integer operator by 1. 244 + 245 Arithmetic addition operator. 247 & 248 Bitwise AND operator. 250 5. Common Rules 252 Throughout the document we use terms defined in the [1], such as 253 Query, Response, Confirm. 255 State machine represents handling of GIST messages that match a 256 Message Routing State's MRI, NSLPID and SID and with no protocol 257 errors. Separate parallel instances of the state machines should 258 handle messages for different Message Routing States. 260 The state machine states represent the upstream/downstream peers 261 states of the Message Routing State. 263 For simplification not all objects included in a message are shown. 264 Only those that are significant for the case are shown. State 265 machines do not present handling of messages that are not significant 266 for management of the states. 268 Presented in this document state machines do not cover all functions 269 of a GIST node. Functionality of message forwarding, ROA processing, 270 transmission of NSLP data without MRS establishment and providing of 271 the received messages to the appropriate MRS, we refer as "Lower 272 level pre-processing" step. The interaction of this step with the 273 presented here state machines is defined as follows: 275 Pre-processing provides to the appropriate MRS FSM only the messages 276 which are matched against waiting Query/Response cookies, or 277 established MRS MRI+NSLPID primary key. This is presented by "rx_*" 278 events in the state machines. 280 5.1 Common Procedures 282 Tg_SendMsg: 283 NSLP/GIST API message that request transmission of a NSLP message. 285 Tg_SetStateLifetime(time_period): 286 NSLP/GIST API message providing info for the Lifetime of an RS, 287 required by the application. "Time_period = 0" represents the 288 cancellation of established RSs/MAs (invoked by NSLP application). 290 Tg_MessageDeliveryError: 291 NSLP/GIST API message informing NSLP application of unsuccessful 292 delivery of a message 294 Tg_RecvMsg: 295 NSLP/GIST API message that provides received message to the NSLP 297 Tg_NetworkNotification: 298 NSLP/GIST API message that informs NSLP for change in MRS 300 Tx_Query: 301 Transmit of Query message in Dmode 303 Tx_Response_Dmode: 304 Transmit of Response message in Dmode 306 Tx_Confirm_Dmode: 307 Transmit of Confirm message in Dmode 309 Rx_Query_Dmode: 310 Receive of Query message in Dmode 312 Rx_Response_Dmode: 313 Receive of Response message in Dmode 315 Rx_Confirm_Cmode: 316 Receive of Confirm message in Dmode 318 Tx_Response_Cmode: 320 Transmit of Response message in Cmode (via MA) 322 Tx_Confirm_Cmode: 323 Transmit of Confirm message in Cmode (via MA) 325 Rx_Response_Cmode: 326 Receive of Response message in Cmode (via MA) 328 Rx_Confirm_Cmode: 329 Receive of Confirm message in Cmode (via MA) 331 Queue NSLP msg info: 332 Save NLSP messages in a queue until a required MA association is 333 established 335 Tx_Msg_Cmode: 336 Transmit message in Cmode (via MA) 338 Rx_Msg_Cmode: 339 Receive message in Cmode (via MA) 341 Tx_Msg_Dmode: 342 Transmit message in Dmode 344 Rx_Msg_Dmode: 345 Receive message in Dmode 347 TIMEOUT_MRSlifetime: 348 Expiration of the lifetime timer of the upstream/downstream peer 349 state info of the Message Routing State. 351 TIMEOUT_Refresh: 352 Refresh interval timer expiration 354 TIMEOUT_WaitResponse: 355 Expiration of Timer for the waiting period for Response message. 357 TIMEOUT_WaitConfirm: 358 Expiration of Timer for the waiting period for Confirm message. 360 Install downstream/upstream MRS: 361 Install new Message Routing State and save the corespoding peer 362 state info (IP address and UDP port or pointer to the used MA) for 363 the current Message Routing State or update the coresponding peer 364 state info. 366 DELETE MRS: 367 Delete installed downstream/upstream peer's info for the current 368 Message Routing State and delete the Message Routing State if 369 required. 371 Establish MA: 372 Establish Message Association (MA) between current node and its 373 downstream peer 375 Established MA: 376 A Message Association (MA) is established between the current node 377 and its upstream peer. The initiator for the establishment is the 378 upstream peer. Re-use existing MA: An existing MA between the 379 current node and its peer is re-used. 381 DELETE MA: 382 Delete/disconnect used MA. 384 Stop using shared MA: 385 Stop using shared MA. If the shared MA is no more used by any 386 other MRSs, it depends on the local policy whether it is deleted 387 or kept. 389 REFRESH MRS: 390 Refreshes installed MRS. 392 Tg_MA_Error: 393 Error event with used MA. 395 Tg_PathChange: 396 External event for Path change detected. 398 Tg_Establish_MA: 399 Trigers establishment of MA. 401 Tg_MA_Established: 402 MA has been successfully established. 404 Tg_ERROR: 405 General Error event / system level error. 407 No_MRS_Installed: 408 Error response, send by the Responding node indicating lost 409 Confirm message. 411 5.2 Common Variables 413 It is assumed that the type of mode and destination info (which need 414 to be taken from the application parameters and local GIST policy)is 415 provided. This is represented by the common variables Dmode, Cmode, 416 MAinfo, MApresent and Refresh. 418 Cmode: 419 The message MUST be transmitted in Cmode. This is specified by 420 "Message transfer attributes" set to any of the following values: 422 "Reliability" is set to TRUE. 424 "Security" is set to values that request secure handling of a 425 message. 427 "Local processing" is set to values that require services offered 428 by Cmode (e.g., congestion control). [1] 430 Dmode: 431 The message MUST be transmitted in Dmode. This is specified by 432 local policy rules and in case that the "Message transfer 433 attributes" are not set to any of the following values: 435 "Reliability" is set to TRUE. 437 "Security" is set to values that request special security handling 438 of a message. 440 "Local processing" is set to values that require services offered 441 by Cmode [1] 443 MAinfo: 444 GIST message parameters describing the required MA or proposed MA 445 e.g. "Stack-proposal" and "Node-addressing". This list of GIST 446 parameters is not complete. A full mapping is left for future 447 version of the document. 449 NSLPdata: 450 NSLP application data. 452 RespCookie: 453 Responder Cookie that is being sent by the Responding node with 454 the Response message in case that its local policy requires a 455 confirmation from the querying node. 457 Refresh: 458 This variable specifies that the message is for refresh purposes. 460 ConfirmRequired: 461 TConfirm message is required by the local policy rule for 462 installation of the new MRS. 464 NewPeer: 465 Response message is received from new responding peer. 467 MAexist: 468 Existing MA will be reused. 470 CheckPeerInfo: 471 The sender of the received data message is matched against the 472 installed peer info in the MRS. 474 UpstreamPeerInstalled: 475 Upstream peer info is installed in the MRS. 477 5.3 Constants 478 6. State machines 480 The following section presents the state machine diagrams of GIST 481 peers. 483 6.1 Diagram notations 485 (see the .pdf version for missing diagram or 486 refer to Appendix A if reading the .txt version) 488 Figure 1: Diagram notations 490 6.2 State machine for GIST querying node 492 The following is a diagram of the GIST querying node state machine. 493 Also included is clarification of notation. 495 (see the .pdf version for missing diagram or 496 refer to Appendix A.1 if reading the .txt version) 498 Figure 1: GIST Querying Node State Machine 500 *) Response and Confirm messages might be send either in Dmode or 501 Cmode, before or after MA establishment depending on node's local 502 3-way handshake policy and the availability of MAs to be reused. 503 See draft for details. 504 **) Depending on the local policy NSLPdata might be send as payload 505 of Query and Confirm messages. (piggybacking) 506 1) Initial request from NSLP are received, which triggers Query 507 messages requesting either D_mode or C_mode. Dependign on local 508 policy of the node, NSLP data might be piggybacked in the Query 509 requesting D_mode. 510 2) Response message is received. If C_mode connections must be 511 established and there is no available MA to be reused, MA 512 establishment is initiated and waited to be completed. If D_mode 513 connection is requested or available MA can be reused if C_mode is 514 requested the MRS is established. 515 3) New MA is successfully established and MRS, which will use it, is 516 installed. 517 4) Path change detected events - local recovery procedure, where new 518 MA must be established for requested C_mode connection. THIS IS 519 VALID ONLY IF THE NODE IS CROSSOVER NODE. 520 5) Path change detected events - local recovery procedure, where 521 D_mode or C_mode with available MA must be established. THIS IS 522 VALID ONLY IF THE NODE IS CROSSOVER NODE. 523 6) NSLP data is queued, because downstream peer is not discovered or 524 required MA is still not established. 526 7) Received Data messages are checked if their sender matches the 527 installed downstream peer info in the MRS and then processed. 528 8) Received Data messages are checked if their sender matches the 529 installed downstream peer info in the MRS and then processed. In 530 WaitResponse state, this event might happen in the process of MA 531 upgrade, when the downstream peer is still not aware of 532 establishment of the new MA. 533 9) Depending on the requested transport from NSLP and currently 534 established D_mode or C_mode, NSLP message is sent D_mode if 535 D_mode is requested and C_mode if the features of the used MA 536 covers the required transport. ( e.g. used MA is reliable and NSLP 537 request reliable but not secure transport) 538 10) External event notifies for Path Change and discovery procedures 539 is restarted. THIS IS VALID ONLY IF THE NODE IS CROSSOVER NODE OR 540 NSLP requests C_mode transport that is not covered by currently 541 used D_mode or MA (case of MA upgrade) and discovery procedure is 542 restared but current downstream peer info is kept in order to be 543 able to receive messages from it during the upgrade process. 545 6.3 State machine for GIST responding node 547 The following is a diagram of the GIST responding node state machine. 548 Also included is clarification of notation. 550 (see the .pdf version for missing diagram or 551 refer to Appendix A.2 if reading the .txt version) 553 Figure 3: GIST Responding Node State Machine 555 *) Response and Confirm messages might be send either in Dmode or 556 Cmode depending on node's local 3-way handshake policy and the 557 availability of MAs to be reused. See draft for details. 558 **) Differentiation between WaitConfirm timer expiration of initial 559 MRS event or MA_upgrade event is based on the presence of 560 installed peer info in the MRS. If no peer info is installed this 561 is initial MRS establishment. 562 1) Initial Query messages requesting either D_mode or C_mode 563 connection. In both cases, explicit Confirm message is required 564 for MRS installation, based on the local policy. Query requesting 565 D_mode might carry piggybacked NSLP data. 566 2) Initial Query messages requesting either D_mode or C_mode 567 connection. In both cases, MRS is installed immediately, based on 568 the local policy. Query requesting D_mode might carry piggybacked 569 NSLP data. In the case of C_mode request, Confirm message is 570 required to confirm the establishment of the used MA. 571 3) In case of lost Confirm message, data messages might be received 572 from the upstream node (it is unaware of the lost Confirm 573 message). Response indicating the loss of the Confirm is sent 574 back to the upstream node. 575 4) Event of change of the upstream peer (e.g., path change) with 576 request of D_mode and non-paranoid local policy. 577 5) Event of request of change of the used connection mode (from 578 D_mode/C_mode to better C_mode), event of change of the upstream 579 peer (e.g., path change) with request for C_mode or D_mode 580 connection and paranoid local policy. 581 6) Confirm message is received which causes installation of the 582 complete MRS or just installation of the used MA as a upstream 583 peer info. 584 7) Differentiation between WaitConfirm timer expiration of initial 585 MRS event or MA upgrade/change event is based on the presence of 586 installed peer info in the MRS. If no peer info is installed this 587 is initial MRS establishment and installed MRS must be deleted. 588 8) Data messages are accepted only if complete MRS is installed, 589 e.g., there is installed upstream peer info. If not then Confirm 590 message is expected and data message will not be accepted but 591 Response indicating the loss of the Confirm is sent back to the 592 upstream node. 593 9) NSLP message can't be sent upstream if Confirm message is not 594 received and MA is not installed as upstream peer info. They are 595 queued. 597 8. Security Considerations 599 This document does not raise new security considerations. Any 600 security concerns with GIST are likely reflected in security related 601 NSIS work already (such as [1] or [6]). 603 For the time being, the state machines described in this document do 604 not consider the security aspect of GMIPS protocol itself. A future 605 versions of this document will add security relevant states and state 606 transitions. 608 9. Open Issues 610 We have left for further version of the document the following 611 issues: 613 1. The FSM that handles the management of a MA is considered in the 614 document (e.g., tg_Establish_MA, tg_MA_established events), but it 615 is not currently explicitely presented. It is left for future 616 version of the document. 617 2. Functionality of, as referred in the document "Lower level pre- 618 processing" (Section 5), namely message forwarding, RAO 619 processing, transmission of NSLP data without MRS establishment 620 and providing of the received messages to the appropriate MRS is 621 left for future version of the document. 623 3. Currently we use WaitConfirm state in the Responding node FSM, but 624 following the DoS prevention approaches for no state installation 625 in the Responding node before receiving of Confirm message, we 626 consider possible removing of this state. This issue requires 627 further investigations. 629 10. Contributors 631 Christian Dickmann contributed to refining of the state machine since 632 01 version. 634 11. Acknowledgments 636 The authors would like to thank Robert Hancock, Ingo Juchem, Andreas 637 Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd 638 Schloer for their insightful comments. 640 12. References 642 12.1. Normative References 644 [1] Schulzrinne, H., "GIST: General Internet Signaling 645 Transport", draft-ietf-nsis-ntlp-08 (work in progress), 646 February 647 2005. 649 [2] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, March 1997. 652 11.2. Informative References 654 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 655 "State Machines for Extensible Authentication Protocol 656 (EAP) Peer and Authenticator", draft-ietf-eap- 657 statemachine-06 (work in progress), December 2004. 659 [4] Institute of Electrical and Electronics Engineers, "DRAFT 660 Standard for Local and Metropolitan Area Networks: Port- 661 Based 662 Network Access Control (Revision)", IEEE 802-1X-REV/D11, 663 July 2004. 665 [5] Ohba, Y., "State Machines for Protocol for Carrying 666 Authentication for Network Access (PANA)", 667 draft-ohba-pana-statemachine-01 (work in progress), 668 February 2005. 670 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for 671 NSIS", draft-ietf-nsis-threats-06 (work in progress), 672 October 2004. 674 Appendix A. ASCII versions of state diagrams 676 This appendix contains the state diagrams in ASCII format. Please 677 use the PDF version whenever possible: it is much easier to 678 understand. 680 The notation is as follows: for each state there is a separate table 681 that lists in each row: 682 - an event that triggers a transition, 683 - actions taken as a result of the incoming event, 684 - and the new state at which the transitions ends. 686 A.1. State machine for GIST querying node (Figure 2) 688 ----------- 689 State: IDLE 690 ----------- 692 Condition Action State Note 693 ------------------------+-------------------------+-----------+--- 694 (tg_SendMsg)&&(Dmode) |Tx_Query |Wait |1) 695 |Queue_NSLP_msg_data |Response |** 696 | | | 697 (tg_SendMsg)&&(Cmode) |Tx_Query(MAinfo) |Wait |1) 698 |Queue_NSLP_msg_data |Response | 699 | | | 700 ------------------------+-------------------------+-----------+--- 702 ----------- 703 State: WaitResponse 704 ----------- 706 Condition Action State Note 707 ------------------------+-------------------------+-----------+--- 708 (rx_Response_Dmode)|| |Install MRS |Established|** 709 ((rx_Response_?mode( |If (RespCookie) |Downstream |2) 710 MAinfo)&&(MAexist))| tx_Confirm_?mode(Resp |MRS | 711 | Cookie)| | 712 |Tx_queued_Msg_?mode | | 713 | | | 714 (rx_Response_?mode( |Tg_Establish_MA |Wait MA |* 715 MAinfo)&&(!MA_exist))|(Tx_Confirm_?mode) |Establish. |2) 716 | | | 717 rx_Msg_?mode |IF(CheckPeerInfo) |Wait |8) 718 | Tg_RecvMsg to Appl.|Response | 719 | | | 721 tg_SendMsg |Queue NSLP msg data |Wait |6) 722 | |Response | 723 | | | 724 Timeout_WaitResponse |(Tx_Query(MAinfo)) || |Wait | 725 |(Tx_Query(NSLPdata))|| |Response | 726 |(Tx_Query) | | 727 | | | 728 (Timeout_WaitResponse) |Tg_MessageDeliveryError |IDLE | 729 &&(MaxRetry) | | | 730 | | | 731 Tg_ERROR |(Delete MRS) |IDLE | 732 |IF (MA is used) | | 733 | ((Delete MA)|| | | 734 | (Stop using shared MA))| | 735 |Tg_NetworkNotification | | 736 | | | 737 ------------------------+-------------------------+-----------+--- 739 ----------- 740 State: Established Downstream MRS 741 ----------- 743 Condition Action State Note 744 ------------------------+-------------------------+-----------+--- 745 rx_Msg_?mode |IF(CheckPeerInfo) |Established|7) 746 | Tg_RecvMsg to Appl.|Downstream | 747 | |MRS | 748 | | | 749 tg_SendMsg_?mode |IF(Cmode)&&(MAexist) |Established|9) 750 | Tx_Msg_Cmode |Downstream | 751 |IF(Dmode) Tx_Msg_Dmode |MRS | 752 | | | 753 ((tg_SendMsg)&&(Cmode)&&|Tx_Query(MAinfo) |Wait |10) 754 (!MAexist))|| |Queue NSLP msg data |Response | 755 (tg_MA_error)|| | | | 756 (tg_Path_Change) | | | 757 | | | 758 Timeout_refresh |Tx_Query(Refresh) |Established| 759 | |Downstream | 760 | |MRS | 761 | | | 762 (rx_Response)&& |Refresh MRS |Established| 763 (!NewPeer) | |Downstream | 764 | |MRS | 765 | | | 766 rx_Response(No_MRS |tx_Confirm(RespCookie) |Established| 767 _installed)|Tx_queued_Msg_Cmode |Downstream | 768 | |MRS | 769 | | | 770 (Timeout_MRSlifetime)|| |(Delete MRS) |IDLE | 771 (tg_SetStateLifetime(0))| | | 772 ||(Tg_ERROR) | | | 773 | | | 774 |Tg_NetworkNotification | | 775 | | | 776 (rx_Response_Dmode)|| |IF (MA is used) |Established|5) 777 (rx_Response_?mode( | ((Delete MA)|| |Downstream | 778 Mainfo)&&(NewPeer)&&| (Stop using shared MA))|MRS | 779 (MAexist) |Install MRS | | 780 |If (RespCookie) | | 781 | tx_Confirm_?mode(Resp | | 782 | Cookie)| | 783 | | | 784 (rx_Response_?mode( |((Delete MA)|| |Wait MA |* 785 MAinfo)&&(NewPeer)&&|(Stop using shared MA)) |Establish. |4) 786 (!MA_exist) |Tg_Establish_MA | | 787 |(Tx_Confirm_?mode) | | 788 | | | 789 | | | 790 | | | 791 | | | 792 | | | 793 ------------------------+-------------------------+-----------+--- 795 ----------- 796 State: Wait MA Establishment 797 ----------- 799 Condition Action State Note 800 ------------------------+-------------------------+-----------+--- 801 tg_SendMsg |Queue NSLP msg data |Wait MA |6) 802 | |Establish. | 803 | | | 804 Tg_MA_Established |Install MRS |Established|3) 805 |(Tx_Confirm_?mode) |Downstream |* 806 |(Tx_queued_Msg_Cmode) |MRS |** 807 | | | 808 Tg_MA_error |Delete MRS |IDLE | 809 |Tg_NetworkNotification | | 810 | | | 812 Tg_ERROR |(Delete MRS) |IDLE | 813 |IF (MA is used) | | 814 | ((Delete MA)|| | | 815 | (Stop using shared MA))| | 816 |Tg_NetworkNotification | | 817 | | | 818 ------------------------+-------------------------+-----------+--- 820 Figure 4 822 A.2. State Machine for GIST responding node (Figure 3) 824 ----------- 825 State: IDLE 826 ----------- 828 Condition Action State Note 829 ------------------------+-------------------------+-----------+--- 830 rx_Query(?) |Tx_Response_Dmode(Resp |Wait |1) 831 &&(ConfirmRequired) | Cookie)|Confirm | 832 |IF(NSLPdata) | | 833 |Tg_RecvMsg(NSLPdata) | | 834 | to Appl.| | 835 | | | 836 rx_Query(?) |Tx_Response_Dmode |Established|2) 837 &&(!ConfirmRequired) |Install MRS |Upstream | 838 |IF(NSLPdata) |MRS | 839 |Tg_RecvMsg(NSLPdata) | | 840 | to Appl.| | 841 | | | 842 rx_Query(MAinfo) |Tx_Response_?mode(Resp |Wait |* 843 &&(ConfirmRequired) | Cookie, MAinfo)|Confirm |1) 844 | | | 845 rx_Query(Mainfo) |Tx_Response_?mode(Resp |Established|* 846 &&(!ConfirmRequired) | Cookie, MAinfo)|Upstream |2) 847 |Set WaitConfirm timer |MRS | 848 |Install MRS | | 849 | | | 850 ------------------------+-------------------------+-----------+--- 852 ----------- 853 State: WAIT CONFIRM 854 ----------- 856 Condition Action State Note 857 ------------------------+-------------------------+-----------+--- 858 rx_Msg_?mode |Tx_Response(No_MRS_ |Wait |3) 859 | installed)|Confirm | 860 | | | 861 Rx_Confirm_?mode |Install Upstream MRS |Established|* 862 | |Upstream |6) 863 | |MRS | 864 | | | 865 Timeout_WaitConfirm | |IDLE | 866 | | | 867 ------------------------+-------------------------+-----------+--- 869 ----------- 870 State: Established Upstream MRS 871 ----------- 873 Condition Action State Note 874 ------------------------+-------------------------+-----------+--- 875 Rx_Confirm_?mode |Stop WaitConfirm timer |Established|6) 876 |Install MRS |Upstream | 877 |Tx_queued_Msg_Cmode |MRS | 878 | | | 879 (Timeout_WaitConfirm)&& |(Delete MRS) |IDLE |7) 880 (!UpstreamPeerInstalled)|IF (MA is used) | |** 881 | ((Delete MA)|| | | 882 | (Stop using shared MA))| | 883 |Tg_NetworkNotification | | 884 | | | 885 rx_Msg_?mode |IF(CheckPeerInfo) |Established|8) 886 | Tg_RecvMsg to Appl.|Upstream | 887 |ELSE |MRS | 888 |Tx_Response(No_MRS_ | | 889 | installed)| | 890 | | | 891 tg_SendMsg |IF(WaitConfirm timer set)|Established|9) 892 | Queue NSLP msg data|Upstream | 893 |ELSE Tx_Msg_?mode |MRS | 894 | | | 895 (Timeout_MRSlifetime)|| |(Delete MRS)&& |IDLE | 896 (tg_SetStateLifetime(0))|IF (MA is used) | | 897 | ((Delete MA)|| | | 898 | (Stop using shared MA))| | 899 |Tg_NetworkNotification | | 900 | | | 901 rx_Query(Refresh) |Refresh MRS |Established| 902 |Tx_Response(Refresh) |Upstream | 903 | |MRS | 904 | | | 905 (rx_Query(MAinfo))|| |Tx_Response_?mode(Resp |Established|* 906 ((rx_Query)&&(!MAinfo)&&| Cookie, MAinfo)|Upstream |5) 907 (ConfirmRequired))|Set WaitConfirm timer |MRS | 908 | | | 909 (rx_Query)&&(!MAinfo)&& |Install MRS |Established|4) 910 (!ConfirmRequired) |tx_Response |Upstream | 911 |IF (MA is used) |MRS | 912 | ((Delete MA)|| | | 913 | (Stop using shared MA))| | 914 |IF(NSLPdata) | | 915 |Tg_RecvMsg(NSLPdata) | | 916 | to Appl.| | 917 | | | 918 Tg_ERROR |(Delete MRS) |IDLE | 919 |IF (MA is used) | | 920 | ((Delete MA)|| | | 921 | (Stop using shared MA))| | 922 |Tg_NetworkNotification | | 923 | | | 924 ------------------------+-------------------------+-----------+--- 926 Figure 5 928 Authors' Addresses 930 Tseno Tsenov 931 Siemens 932 Otto-Hahn-Ring 6 933 Munich, Bayern 81739 934 Germany 936 Email: tseno.tsenov@mytum.de 938 Hannes Tschofenig 939 Siemens 940 Otto-Hahn-Ring 6 941 Munich, Bayern 81739 942 Germany 944 Email: Hannes.Tschofenig@siemens.com 946 Xiaoming Fu 947 University of Goettingen 948 Telematics Group 949 Lotzestr. 16-18 950 Goettingen 37083 951 Germany 953 Email: fu@cs.uni-goettingen.de 955 Cedric Aoun 956 ZTE Corporation/ENST Paris 957 France 959 Email: aoun.cedric@zte.com.fr 961 Elwyn B. Davies 962 Folly Consulting 963 Soham, Cambs 964 UK 966 Phone: +44 7889 488 335 967 Email: elwynd@dial.pipex.com 969 Intellectual Property Statement 971 The IETF takes no position regarding the validity or scope of any 972 Intellectual Property Rights or other rights that might be claimed to 973 pertain to the implementation or use of the technology described in 974 this document or the extent to which any license under such rights 975 might or might not be available; nor does it represent that it has 976 made any independent effort to identify any such rights. Information 977 on the procedures with respect to rights in RFC documents can be 978 found in BCP 78 and BCP 79. 980 Copies of IPR disclosures made to the IETF Secretariat and any 981 assurances of licenses to be made available, or the result of an 982 attempt made to obtain a general license or permission for the use of 983 such proprietary rights by implementers or users of this 984 specification can be obtained from the IETF on-line IPR repository at 985 http://www.ietf.org/ipr. 987 The IETF invites any interested party to bring to its attention any 988 copyrights, patents or patent applications, or other proprietary 989 rights that may cover technology that may be required to implement 990 this standard. Please address the information to the IETF at ietf- 991 ipr@ietf.org. 993 Disclaimer of Validity 995 This document and the information contained herein are provided on an 996 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 997 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 998 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 999 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1000 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1001 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1003 Copyright Statement 1005 Copyright (C) The Internet Society (2005). This document is subject 1006 to the rights, licenses and restrictions contained in BCP 78, and 1007 except as set forth therein, the authors retain all their rights. 1009 Acknowledgement 1011 Funding for the RFC Editor function is currently provided by the 1012 Internet Society.