idnits 2.17.1 draft-ietf-nsis-ntlp-statemachine-02.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 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 988. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1004), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** 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 517 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 (June 23, 2006) is 6516 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. -------------------------------------------------------------------------------- 1 NSIS T. Tsenov 2 Internet-Draft H. Tschofenig 3 Expires: December 25, 2006 Siemens 4 X. Fu 5 Univ. Goettingen 6 C. Aoun 7 ZTE/ENST Paris 8 E. Davies 9 Folly Consulting 10 June 23, 2006 12 GIST State Machine 13 draft-ietf-nsis-ntlp-statemachine-02.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 December 25, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). All Rights Reserved. 44 Abstract 46 This document describes the state machines for the General Internet 47 Signaling Transport (GIST). The states of GIST nodes for a given flow 48 and their transitions are presented in order to illustrate how GIST 49 may be implemented. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Notational conventions used in state diagrams . . . . . . . 3 56 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 5 57 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 7 59 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 9 60 5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6. State machines . . . . . . . . . . . . . . . . . . . . . . . 12 62 6.1 Diagram notations . . . . . . . . . . . . . . . . . . . . 12 63 6.2 State machine for GIST querying node . . . . . . . . . . . 12 64 6.3 State machine for GIST responding node . . . . . . . . . . 13 65 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 66 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 67 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 11.1 Normative References . . . . . . . . . . . . . . . . . . 16 71 11.2 Informative References . . . . . . . . . . . . . . . . . 16 72 Appendix A. ASCII versions of the state diagrams . . . . . . . . 17 73 A.1 State machine for GIST querying node (Figure 2) . . . . 17 74 A.2 State Machine for GIST responding node (Figure 3) . . . 20 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 76 Intellectual Property and Copyright Statements . . . . . . . 24 78 1. Introduction 80 This document describes the state machines for GIST [1], trying to 81 show how GIST can be implemented to support its deployment. The 82 state machines described in this document are illustrative of how the 83 GIST protocol defined in [1] may be implemented for the GIST nodes in 84 different locations of a flow path. Where there are differences [1] 85 are authoritative. The state machines are informative only. 86 Implementations may achieve the same results using different methods. 88 There are two types of possible entities for GIST signaling: 90 - GIST querying node - GIST node that initiates the discovery of the 91 next peer; 93 - GIST responding node - GIST node that is the discovered next peer; 95 We describe a set of state machines for these entities to illustrate 96 how GIST may be implemented. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [2]. 104 3. Notational conventions used in state diagrams 106 The following text is reused from [3] and the state diagrams are 107 based on the conventions specified in [4], Section 8.2.1. Additional 108 state machine details are taken from [5]. 110 The complete text is reproduced here: 112 State diagrams are used to represent the operation of the protocol by 113 a number of cooperating state machines each comprising a group of 114 connected, mutually exclusive states. Only one state of each machine 115 can be active at any given time. 117 All permissible transitions between states are represented by arrows, 118 the arrowhead denoting the direction of the possible transition. 119 Labels attached to arrows denote the condition(s) that must be met in 120 order for the transition to take place. All conditions are 121 expressions that evaluate to TRUE or FALSE; if a condition evaluates 122 to TRUE, then the condition is met. The label UCT denotes an 123 unconditional transition (i.e., UCT always evaluates to TRUE). A 124 transition that is global in nature (i.e., a transition that occurs 125 from any of the possible states if the condition attached to the 126 arrow is met) is denoted by an open arrow; i.e., no specific state is 127 identified as the origin of the transition. When the condition 128 associated with a global transition is met, it supersedes all other 129 exit conditions including UCT. The special global condition BEGIN 130 supersedes all other global conditions, and once asserted remains 131 asserted until all state blocks have executed to the point that 132 variable assignments and other consequences of their execution remain 133 unchanged. 135 On entry to a state, the procedures defined for the state (if any) 136 are executed exactly once, in the order that they appear on the page. 137 Each action is deemed to be atomic; i.e., execution of a procedure 138 completes before the next sequential procedure starts to execute. No 139 procedures execute outside of a state block. The procedures in only 140 one state block execute at a time, even if the conditions for 141 execution of state blocks in different state machines are satisfied, 142 and all procedures in an executing state block complete execution 143 before the transition to and execution of any other state block 144 occurs, i.e., the execution of any state block appears to be atomic 145 with respect to the execution of any other state block and the 146 transition condition to that state from the previous state is TRUE 147 when execution commences. The order of execution of state blocks in 148 different state machines is undefined except as constrained by their 149 transition conditions. A variable that is set to a particular value 150 in a state block retains this value until a subsequent state block 151 executes a procedure that modifies the value. 153 On completion of all of the procedures within a state, all exit 154 conditions for the state (including all conditions associated with 155 global transitions) are evaluated continuously until one of the 156 conditions is met. The label ELSE denotes a transition that occurs 157 if none of the other conditions for transitions from the state are 158 met (i.e., ELSE evaluates to TRUE if all other possible exit 159 conditions from the state evaluate to FALSE). Where two or more exit 160 conditions with the same level of precedence become TRUE 161 simultaneously, the choice as to which exit condition causes the 162 state transition to take place is arbitrary. 164 In addition to the above notation, there are a couple of 165 clarifications specific to this document. First, all boolean 166 variables are initialized to FALSE before the state machine execution 167 begins. Second, the following notational shorthand is specific to 168 this document: 170 = | | ... 172 Execution of a statement of this form will result in 173 having a value of exactly one of the expressions. The logic for 174 which of those expressions gets executed is outside of the state 175 machine and could be environmental, configurable, or based on 176 another state machine such as that of the method. 178 4. State Machine Symbols 180 MA 181 Messaging Association 183 Upstream/Downstream MRS 184 Message Routing State with upstream/downstream peer state info 186 ( ) 187 Used to force the precedence of operators in Boolean expressions 188 and to delimit the argument(s) of actions within state boxes. 190 ; 191 Used as a terminating delimiter for actions within state boxes. 192 Where a state box contains multiple actions, the order of 193 execution follows the normal English language conventions for 194 reading text. 196 = 197 Assignment action. The value of the expression to the right of 198 the operator is assigned to the variable to the left of the 199 operator. Where this operator is used to define multiple 200 assignments, e.g., a = b = X the action causes the value of the 201 expression following the right-most assignment operator to be 202 assigned to all of the variables that appear to the left of the 203 right-most assignment operator. 205 ! 206 Logical NOT operator. 208 && 209 Logical AND operator. 211 || 212 Logical OR operator. 214 if...then... 215 Conditional action. If the Boolean expression following the if 216 evaluates to TRUE, then the action following the then is executed. 218 { statement 1, ... statement N } 219 Compound statement. Braces are used to group statements that are 220 executed together as if they were a single statement. 222 != 223 Inequality. Evaluates to TRUE if the expression to the left of 224 the operator is not equal in value to the expression to the right. 226 == 227 Equality. Evaluates to TRUE if the expression to the left of the 228 operator is equal in value to the expression to the right. 230 > 231 Greater than. Evaluates to TRUE if the value of the expression to 232 the left of the operator is greater than the value of the 233 expression to the right. 235 <= 236 Less than or equal to. Evaluates to TRUE if the value of the 237 expression to the left of the operator is either less than or 238 equal to the value of the expression to the right. 240 ++ 241 Increment the preceding integer operator by 1. 243 + 244 Arithmetic addition operator. 246 & 247 Bitwise AND operator. 249 5. Common Rules 251 Throughout the document we use terms defined in the [1], such as 252 Query, Response, Confirm. 254 State machine represents handling of GIST messages that match a 255 Message Routing State's MRI, NSLPID and SID and with no protocol 256 errors. Separate parallel instances of the state machines should 257 handle messages for different Message Routing States. 259 The state machine states represent the upstream/downstream peers 260 states of the Message Routing State. 262 For simplification not all objects included in a message are shown. 263 Only those that are significant for the case are shown. State 264 machines do not present handling of messages that are not significant 265 for management of the states. 267 Presented in this document state machines do not cover all functions 268 of a GIST node. Functionality of message forwarding, ROA processing, 269 transmission of NSLP data without MRS establishment and providing of 270 the received messages to the appropriate MRS, we refer as "Lower 271 level pre-processing" step. The interaction of this step with the 272 presented here state machines is defined as follows: 274 Pre-processing provides to the appropriate MRS FSM only the messages 275 which are matched against waiting Query/Response cookies, or 276 established MRS MRI+NSLPID primary key. This is presented by "rx_*" 277 events in the state machines. 279 5.1 Common Procedures 281 Tg_SendMsg: 282 NSLP/GIST API message that request transmission of a NSLP message. 284 Tg_SetStateLifetime(time_period): 285 NSLP/GIST API message providing info for the Lifetime of an RS, 286 required by the application. "Time_period = 0" represents the 287 cancellation of established RSs/MAs (invoked by NSLP application). 289 Tg_MessageDeliveryError: 290 NSLP/GIST API message informing NSLP application of unsuccessful 291 delivery of a message 293 Tg_RecvMsg: 294 NSLP/GIST API message that provides received message to the NSLP 296 Tg_NetworkNotification: 297 NSLP/GIST API message that informs NSLP for change in MRS 299 Tx_Query: 300 Transmit of Query message in Dmode 302 Tx_Response_Dmode: 303 Transmit of Response message in Dmode 305 Tx_Confirm_Dmode: 306 Transmit of Confirm message in Dmode 308 Rx_Query_Dmode: 309 Receive of Query message in Dmode 311 Rx_Response_Dmode: 312 Receive of Response message in Dmode 314 Rx_Confirm_Cmode: 315 Receive of Confirm message in Dmode 317 Tx_Response_Cmode: 319 Transmit of Response message in Cmode (via MA) 321 Tx_Confirm_Cmode: 322 Transmit of Confirm message in Cmode (via MA) 324 Rx_Response_Cmode: 325 Receive of Response message in Cmode (via MA) 327 Rx_Confirm_Cmode: 328 Receive of Confirm message in Cmode (via MA) 330 Queue NSLP msg info: 331 Save NLSP messages in a queue until a required MA association is 332 established 334 Tx_Msg_Cmode: 335 Transmit message in Cmode (via MA) 337 Rx_Msg_Cmode: 338 Receive message in Cmode (via MA) 340 Tx_Msg_Dmode: 341 Transmit message in Dmode 343 Rx_Msg_Dmode: 344 Receive message in Dmode 346 TIMEOUT_MRSlifetime: 347 Expiration of the lifetime timer of the upstream/downstream peer 348 state info of the Message Routing State. 350 TIMEOUT_Refresh: 351 Refresh interval timer expiration 353 TIMEOUT_WaitResponse: 354 Expiration of Timer for the waiting period for Response message. 356 TIMEOUT_WaitConfirm: 357 Expiration of Timer for the waiting period for Confirm message. 359 Install downstream/upstream MRS: 360 Install new Message Routing State and save the corespoding peer 361 state info (IP address and UDP port or pointer to the used MA) for 362 the current Message Routing State or update the coresponding peer 363 state info. 365 DELETE MRS: 366 Delete installed downstream/upstream peer's info for the current 367 Message Routing State and delete the Message Routing State if 368 required. 370 Establish MA: 371 Establish Message Association (MA) between current node and its 372 downstream peer 374 Established MA: 375 A Message Association (MA) is established between the current node 376 and its upstream peer. The initiator for the establishment is the 377 upstream peer. Re-use existing MA: An existing MA between the 378 current node and its peer is re-used. 380 DELETE MA: 381 Delete/disconnect used MA. 383 Stop using shared MA: 384 Stop using shared MA. If the shared MA is no more used by any 385 other MRSs, it depends on the local policy whether it is deleted 386 or kept. 388 REFRESH MRS: 389 Refreshes installed MRS. 391 Tg_MA_Error: 392 Error event with used MA. 394 Tg_PathChange: 395 External event for Path change detected. 397 Tg_Establish_MA: 398 Trigers establishment of MA. 400 Tg_MA_Established: 401 MA has been successfully established. 403 Tg_ERROR: 404 General Error event / system level error. 406 No_MRS_Installed: 407 Error response, send by the Responding node indicating lost 408 Confirm message. 410 5.2 Common Variables 412 It is assumed that the type of mode and destination info (which need 413 to be taken from the application parameters and local GIST policy)is 414 provided. This is represented by the common variables Dmode, Cmode, 415 MAinfo, MApresent and Refresh. 417 Cmode: 418 The message MUST be transmitted in Cmode. This is specified by 419 "Message transfer attributes" set to any of the following values: 421 "Reliability" is set to TRUE. 423 "Security" is set to values that request secure handling of a 424 message. 426 "Local processing" is set to values that require services offered 427 by Cmode (e.g., congestion control). [1] 429 Dmode: 430 The message MUST be transmitted in Dmode. This is specified by 431 local policy rules and in case that the "Message transfer 432 attributes" are not set to any of the following values: 434 "Reliability" is set to TRUE. 436 "Security" is set to values that request special security handling 437 of a message. 439 "Local processing" is set to values that require services offered 440 by Cmode [1] 442 MAinfo: 443 GIST message parameters describing the required MA or proposed MA 444 e.g. "Stack-proposal" and "Node-addressing". This list of GIST 445 parameters is not complete. A full mapping is left for future 446 version of the document. 448 NSLPdata: 449 NSLP application data. 451 RespCookie: 452 Responder Cookie that is being sent by the Responding node with 453 the Response message in case that its local policy requires a 454 confirmation from the querying node. 456 Refresh: 457 This variable specifies that the message is for refresh purposes. 459 ConfirmRequired: 460 TConfirm message is required by the local policy rule for 461 installation of the new MRS. 463 NewPeer: 464 Response message is received from new responding peer. 466 MAexist: 467 Existing MA will be reused. 469 CheckPeerInfo: 470 The sender of the received data message is matched against the 471 installed peer info in the MRS. 473 UpstreamPeerInstalled: 474 Upstream peer info is installed in the MRS. 476 5.3 Constants 477 6. State machines 479 The following section presents the state machine diagrams of GIST 480 peers. 482 6.1 Diagram notations 484 (see the .pdf version for missing diagram or 485 refer to Appendix A if reading the .txt version) 487 Figure 1: Diagram notations 489 6.2 State machine for GIST querying node 491 The following is a diagram of the GIST querying node state machine. 492 Also included is clarification of notation. 494 (see the .pdf version for missing diagram or 495 refer to Appendix A.1 if reading the .txt version) 497 Figure 1: GIST Querying Node State Machine 499 *) Response and Confirm messages might be send either in Dmode or 500 Cmode, before or after MA establishment depending on node's local 501 3-way handshake policy and the availability of MAs to be reused. 502 See draft for details. 503 **) Depending on the local policy NSLPdata might be send as payload 504 of Query and Confirm messages. (piggybacking) 505 1) Initial request from NSLP are received, which triggers Query 506 messages requesting either D_mode or C_mode. Dependign on local 507 policy of the node, NSLP data might be piggybacked in the Query 508 requesting D_mode. 509 2) Response message is received. If C_mode connections must be 510 established and there is no available MA to be reused, MA 511 establishment is initiated and waited to be completed. If D_mode 512 connection is requested or available MA can be reused if C_mode is 513 requested the MRS is established. 514 3) New MA is successfully established and MRS, which will use it, is 515 installed. 516 4) Path change detected events - local recovery procedure, where new 517 MA must be established for requested C_mode connection. THIS IS 518 VALID ONLY IF THE NODE IS CROSSOVER NODE. 519 5) Path change detected events - local recovery procedure, where 520 D_mode or C_mode with available MA must be established. THIS IS 521 VALID ONLY IF THE NODE IS CROSSOVER NODE. 522 6) NSLP data is queued, because downstream peer is not discovered or 523 required MA is still not established. 525 7) Received Data messages are checked if their sender matches the 526 installed downstream peer info in the MRS and then processed. 527 8) Received Data messages are checked if their sender matches the 528 installed downstream peer info in the MRS and then processed. In 529 WaitResponse state, this event might happen in the process of MA 530 upgrade, when the downstream peer is still not aware of 531 establishment of the new MA. 532 9) Depending on the requested transport from NSLP and currently 533 established D_mode or C_mode, NSLP message is sent D_mode if 534 D_mode is requested and C_mode if the features of the used MA 535 covers the required transport. ( e.g. used MA is reliable and NSLP 536 request reliable but not secure transport) 537 10) External event notifies for Path Change and discovery procedures 538 is restarted. THIS IS VALID ONLY IF THE NODE IS CROSSOVER NODE OR 539 NSLP requests C_mode transport that is not covered by currently 540 used D_mode or MA (case of MA upgrade) and discovery procedure is 541 restared but current downstream peer info is kept in order to be 542 able to receive messages from it during the upgrade process. 544 6.3 State machine for GIST responding node 546 The following is a diagram of the GIST responding node state machine. 547 Also included is clarification of notation. 549 (see the .pdf version for missing diagram or 550 refer to Appendix A.2 if reading the .txt version) 552 Figure 3: GIST Responding Node State Machine 554 *) Response and Confirm messages might be send either in Dmode or 555 Cmode depending on node's local 3-way handshake policy and the 556 availability of MAs to be reused. See draft for details. 557 **) Differentiation between WaitConfirm timer expiration of initial 558 MRS event or MA_upgrade event is based on the presence of 559 installed peer info in the MRS. If no peer info is installed this 560 is initial MRS establishment. 561 1) Initial Query messages requesting either D_mode or C_mode 562 connection. In both cases, explicit Confirm message is required 563 for MRS installation, based on the local policy. Query requesting 564 D_mode might carry piggybacked NSLP data. 565 2) Initial Query messages requesting either D_mode or C_mode 566 connection. In both cases, MRS is installed immediately, based on 567 the local policy. Query requesting D_mode might carry piggybacked 568 NSLP data. In the case of C_mode request, Confirm message is 569 required to confirm the establishment of the used MA. 570 3) In case of lost Confirm message, data messages might be received 571 from the upstream node (it is unaware of the lost Confirm 572 message). Response indicating the loss of the Confirm is sent 573 back to the upstream node. 574 4) Event of change of the upstream peer (e.g., path change) with 575 request of D_mode and non-paranoid local policy. 576 5) Event of request of change of the used connection mode (from 577 D_mode/C_mode to better C_mode), event of change of the upstream 578 peer (e.g., path change) with request for C_mode or D_mode 579 connection and paranoid local policy. 580 6) Confirm message is received which causes installation of the 581 complete MRS or just installation of the used MA as a upstream 582 peer info. 583 7) Differentiation between WaitConfirm timer expiration of initial 584 MRS event or MA upgrade/change event is based on the presence of 585 installed peer info in the MRS. If no peer info is installed this 586 is initial MRS establishment and installed MRS must be deleted. 587 8) Data messages are accepted only if complete MRS is installed, 588 e.g., there is installed upstream peer info. If not then Confirm 589 message is expected and data message will not be accepted but 590 Response indicating the loss of the Confirm is sent back to the 591 upstream node. 592 9) NSLP message can't be sent upstream if Confirm message is not 593 received and MA is not installed as upstream peer info. They are 594 queued. 596 8. Security Considerations 598 This document does not raise new security considerations. Any 599 security concerns with GIST are likely reflected in security related 600 NSIS work already (such as [1] or [6]). 602 For the time being, the state machines described in this document do 603 not consider the security aspect of GMIPS protocol itself. A future 604 versions of this document will add security relevant states and state 605 transitions. 607 9. Open Issues 609 We have left for further version of the document the following 610 issues: 612 1. The FSM that handles the management of a MA is considered in the 613 document (e.g., tg_Establish_MA, tg_MA_established events), but it 614 is not currently explicitely presented. It is left for future 615 version of the document. 616 2. Functionality of, as referred in the document "Lower level pre- 617 processing" (Section 5), namely message forwarding, RAO 618 processing, transmission of NSLP data without MRS establishment 619 and providing of the received messages to the appropriate MRS is 620 left for future version of the document. 622 3. Currently we use WaitConfirm state in the Responding node FSM, but 623 following the DoS prevention approaches for no state installation 624 in the Responding node before receiving of Confirm message, we 625 consider possible removing of this state. This issue requires 626 further investigations. 628 10. Contributors 630 Christian Dickmann contributed to refining of the state machine since 631 01 version. 633 11. Acknowledgments 635 The authors would like to thank Robert Hancock, Ingo Juchem, Andreas 636 Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd 637 Schloer for their insightful comments. 639 12. References 641 12.1. Normative References 643 [1] Schulzrinne, H., "GIST: General Internet Signaling 644 Transport", draft-ietf-nsis-ntlp-08 (work in progress), 645 February 646 2005. 648 [2] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, March 1997. 651 11.2. Informative References 653 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 654 "State Machines for Extensible Authentication Protocol 655 (EAP) Peer and Authenticator", draft-ietf-eap- 656 statemachine-06 (work in progress), December 2004. 658 [4] Institute of Electrical and Electronics Engineers, "DRAFT 659 Standard for Local and Metropolitan Area Networks: Port- 660 Based 661 Network Access Control (Revision)", IEEE 802-1X-REV/D11, 662 July 2004. 664 [5] Ohba, Y., "State Machines for Protocol for Carrying 665 Authentication for Network Access (PANA)", 666 draft-ohba-pana-statemachine-01 (work in progress), 667 February 2005. 669 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for 670 NSIS", draft-ietf-nsis-threats-06 (work in progress), 671 October 2004. 673 Appendix A. ASCII versions of state diagrams 675 This appendix contains the state diagrams in ASCII format. Please 676 use the PDF version whenever possible: it is much easier to 677 understand. 679 The notation is as follows: for each state there is a separate table 680 that lists in each row: 681 - an event that triggers a transition, 682 - actions taken as a result of the incoming event, 683 - and the new state at which the transitions ends. 685 A.1. State machine for GIST querying node (Figure 2) 687 ----------- 688 State: IDLE 689 ----------- 691 Condition Action State Note 692 ------------------------+-------------------------+-----------+--- 693 (tg_SendMsg)&&(Dmode) |Tx_Query |Wait |1) 694 |Queue_NSLP_msg_data |Response |** 695 | | | 696 (tg_SendMsg)&&(Cmode) |Tx_Query(MAinfo) |Wait |1) 697 |Queue_NSLP_msg_data |Response | 698 | | | 699 ------------------------+-------------------------+-----------+--- 701 ----------- 702 State: WaitResponse 703 ----------- 705 Condition Action State Note 706 ------------------------+-------------------------+-----------+--- 707 (rx_Response_Dmode)|| |Install MRS |Established|** 708 ((rx_Response_?mode( |If (RespCookie) |Downstream |2) 709 MAinfo)&&(MAexist))| tx_Confirm_?mode(Resp |MRS | 710 | Cookie)| | 711 |Tx_queued_Msg_?mode | | 712 | | | 713 (rx_Response_?mode( |Tg_Establish_MA |Wait MA |* 714 MAinfo)&&(!MA_exist))|(Tx_Confirm_?mode) |Establish. |2) 715 | | | 716 rx_Msg_?mode |IF(CheckPeerInfo) |Wait |8) 717 | Tg_RecvMsg to Appl.|Response | 718 | | | 720 tg_SendMsg |Queue NSLP msg data |Wait |6) 721 | |Response | 722 | | | 723 Timeout_WaitResponse |(Tx_Query(MAinfo)) || |Wait | 724 |(Tx_Query(NSLPdata))|| |Response | 725 |(Tx_Query) | | 726 | | | 727 (Timeout_WaitResponse) |Tg_MessageDeliveryError |IDLE | 728 &&(MaxRetry) | | | 729 | | | 730 Tg_ERROR |(Delete MRS) |IDLE | 731 |IF (MA is used) | | 732 | ((Delete MA)|| | | 733 | (Stop using shared MA))| | 734 |Tg_NetworkNotification | | 735 | | | 736 ------------------------+-------------------------+-----------+--- 738 ----------- 739 State: Established Downstream MRS 740 ----------- 742 Condition Action State Note 743 ------------------------+-------------------------+-----------+--- 744 rx_Msg_?mode |IF(CheckPeerInfo) |Established|7) 745 | Tg_RecvMsg to Appl.|Downstream | 746 | |MRS | 747 | | | 748 tg_SendMsg_?mode |IF(Cmode)&&(MAexist) |Established|9) 749 | Tx_Msg_Cmode |Downstream | 750 |IF(Dmode) Tx_Msg_Dmode |MRS | 751 | | | 752 ((tg_SendMsg)&&(Cmode)&&|Tx_Query(MAinfo) |Wait |10) 753 (!MAexist))|| |Queue NSLP msg data |Response | 754 (tg_MA_error)|| | | | 755 (tg_Path_Change) | | | 756 | | | 757 Timeout_refresh |Tx_Query(Refresh) |Established| 758 | |Downstream | 759 | |MRS | 760 | | | 761 (rx_Response)&& |Refresh MRS |Established| 762 (!NewPeer) | |Downstream | 763 | |MRS | 764 | | | 765 rx_Response(No_MRS |tx_Confirm(RespCookie) |Established| 766 _installed)|Tx_queued_Msg_Cmode |Downstream | 767 | |MRS | 768 | | | 769 (Timeout_MRSlifetime)|| |(Delete MRS) |IDLE | 770 (tg_SetStateLifetime(0))| | | 771 ||(Tg_ERROR) | | | 772 | | | 773 |Tg_NetworkNotification | | 774 | | | 775 (rx_Response_Dmode)|| |IF (MA is used) |Established|5) 776 (rx_Response_?mode( | ((Delete MA)|| |Downstream | 777 Mainfo)&&(NewPeer)&&| (Stop using shared MA))|MRS | 778 (MAexist) |Install MRS | | 779 |If (RespCookie) | | 780 | tx_Confirm_?mode(Resp | | 781 | Cookie)| | 782 | | | 783 (rx_Response_?mode( |((Delete MA)|| |Wait MA |* 784 MAinfo)&&(NewPeer)&&|(Stop using shared MA)) |Establish. |4) 785 (!MA_exist) |Tg_Establish_MA | | 786 |(Tx_Confirm_?mode) | | 787 | | | 788 | | | 789 | | | 790 | | | 791 | | | 792 ------------------------+-------------------------+-----------+--- 794 ----------- 795 State: Wait MA Establishment 796 ----------- 798 Condition Action State Note 799 ------------------------+-------------------------+-----------+--- 800 tg_SendMsg |Queue NSLP msg data |Wait MA |6) 801 | |Establish. | 802 | | | 803 Tg_MA_Established |Install MRS |Established|3) 804 |(Tx_Confirm_?mode) |Downstream |* 805 |(Tx_queued_Msg_Cmode) |MRS |** 806 | | | 807 Tg_MA_error |Delete MRS |IDLE | 808 |Tg_NetworkNotification | | 809 | | | 811 Tg_ERROR |(Delete MRS) |IDLE | 812 |IF (MA is used) | | 813 | ((Delete MA)|| | | 814 | (Stop using shared MA))| | 815 |Tg_NetworkNotification | | 816 | | | 817 ------------------------+-------------------------+-----------+--- 819 Figure 4 821 A.2. State Machine for GIST responding node (Figure 3) 823 ----------- 824 State: IDLE 825 ----------- 827 Condition Action State Note 828 ------------------------+-------------------------+-----------+--- 829 rx_Query(?) |Tx_Response_Dmode(Resp |Wait |1) 830 &&(ConfirmRequired) | Cookie)|Confirm | 831 |IF(NSLPdata) | | 832 |Tg_RecvMsg(NSLPdata) | | 833 | to Appl.| | 834 | | | 835 rx_Query(?) |Tx_Response_Dmode |Established|2) 836 &&(!ConfirmRequired) |Install MRS |Upstream | 837 |IF(NSLPdata) |MRS | 838 |Tg_RecvMsg(NSLPdata) | | 839 | to Appl.| | 840 | | | 841 rx_Query(MAinfo) |Tx_Response_?mode(Resp |Wait |* 842 &&(ConfirmRequired) | Cookie, MAinfo)|Confirm |1) 843 | | | 844 rx_Query(Mainfo) |Tx_Response_?mode(Resp |Established|* 845 &&(!ConfirmRequired) | Cookie, MAinfo)|Upstream |2) 846 |Set WaitConfirm timer |MRS | 847 |Install MRS | | 848 | | | 849 ------------------------+-------------------------+-----------+--- 851 ----------- 852 State: WAIT CONFIRM 853 ----------- 855 Condition Action State Note 856 ------------------------+-------------------------+-----------+--- 857 rx_Msg_?mode |Tx_Response(No_MRS_ |Wait |3) 858 | installed)|Confirm | 859 | | | 860 Rx_Confirm_?mode |Install Upstream MRS |Established|* 861 | |Upstream |6) 862 | |MRS | 863 | | | 864 Timeout_WaitConfirm | |IDLE | 865 | | | 866 ------------------------+-------------------------+-----------+--- 868 ----------- 869 State: Established Upstream MRS 870 ----------- 872 Condition Action State Note 873 ------------------------+-------------------------+-----------+--- 874 Rx_Confirm_?mode |Stop WaitConfirm timer |Established|6) 875 |Install MRS |Upstream | 876 |Tx_queued_Msg_Cmode |MRS | 877 | | | 878 (Timeout_WaitConfirm)&& |(Delete MRS) |IDLE |7) 879 (!UpstreamPeerInstalled)|IF (MA is used) | |** 880 | ((Delete MA)|| | | 881 | (Stop using shared MA))| | 882 |Tg_NetworkNotification | | 883 | | | 884 rx_Msg_?mode |IF(CheckPeerInfo) |Established|8) 885 | Tg_RecvMsg to Appl.|Upstream | 886 |ELSE |MRS | 887 |Tx_Response(No_MRS_ | | 888 | installed)| | 889 | | | 890 tg_SendMsg |IF(WaitConfirm timer set)|Established|9) 891 | Queue NSLP msg data|Upstream | 892 |ELSE Tx_Msg_?mode |MRS | 893 | | | 894 (Timeout_MRSlifetime)|| |(Delete MRS)&& |IDLE | 895 (tg_SetStateLifetime(0))|IF (MA is used) | | 896 | ((Delete MA)|| | | 897 | (Stop using shared MA))| | 898 |Tg_NetworkNotification | | 899 | | | 900 rx_Query(Refresh) |Refresh MRS |Established| 901 |Tx_Response(Refresh) |Upstream | 902 | |MRS | 903 | | | 904 (rx_Query(MAinfo))|| |Tx_Response_?mode(Resp |Established|* 905 ((rx_Query)&&(!MAinfo)&&| Cookie, MAinfo)|Upstream |5) 906 (ConfirmRequired))|Set WaitConfirm timer |MRS | 907 | | | 908 (rx_Query)&&(!MAinfo)&& |Install MRS |Established|4) 909 (!ConfirmRequired) |tx_Response |Upstream | 910 |IF (MA is used) |MRS | 911 | ((Delete MA)|| | | 912 | (Stop using shared MA))| | 913 |IF(NSLPdata) | | 914 |Tg_RecvMsg(NSLPdata) | | 915 | to Appl.| | 916 | | | 917 Tg_ERROR |(Delete MRS) |IDLE | 918 |IF (MA is used) | | 919 | ((Delete MA)|| | | 920 | (Stop using shared MA))| | 921 |Tg_NetworkNotification | | 922 | | | 923 ------------------------+-------------------------+-----------+--- 925 Figure 5 927 Authors' Addresses 929 Tseno Tsenov 930 Sofia, 931 Bulgaria 933 Email: tseno.tsenov@mytum.de 935 Hannes Tschofenig 936 Siemens 937 Otto-Hahn-Ring 6 938 Munich, Bayern 81739 939 Germany 941 Email: Hannes.Tschofenig@siemens.com 943 Xiaoming Fu 944 University of Goettingen 945 Telematics Group 946 Lotzestr. 16-18 947 Goettingen 37083 948 Germany 950 Email: fu@cs.uni-goettingen.de 952 Cedric Aoun 953 ZTE Corporation/ENST Paris 954 France 956 Email: aoun.cedric@zte.com.fr 958 Elwyn B. Davies 959 Folly Consulting 960 Soham, Cambs 961 UK 963 Phone: +44 7889 488 335 964 Email: elwynd@dial.pipex.com 966 Intellectual Property Statement 968 The IETF takes no position regarding the validity or scope of any 969 Intellectual Property Rights or other rights that might be claimed to 970 pertain to the implementation or use of the technology described in 971 this document or the extent to which any license under such rights 972 might or might not be available; nor does it represent that it has 973 made any independent effort to identify any such rights. Information 974 on the procedures with respect to rights in RFC documents can be 975 found in BCP 78 and BCP 79. 977 Copies of IPR disclosures made to the IETF Secretariat and any 978 assurances of licenses to be made available, or the result of an 979 attempt made to obtain a general license or permission for the use of 980 such proprietary rights by implementers or users of this 981 specification can be obtained from the IETF on-line IPR repository at 982 http://www.ietf.org/ipr. 984 The IETF invites any interested party to bring to its attention any 985 copyrights, patents or patent applications, or other proprietary 986 rights that may cover technology that may be required to implement 987 this standard. Please address the information to the IETF at ietf- 988 ipr@ietf.org. 990 Disclaimer of Validity 992 This document and the information contained herein are provided on an 993 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 994 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 995 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 996 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 997 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 998 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1000 Copyright Statement 1002 Copyright (C) The Internet Society (2006). This document is subject 1003 to the rights, licenses and restrictions contained in BCP 78, and 1004 except as set forth therein, the authors retain all their rights. 1006 Acknowledgement 1008 Funding for the RFC Editor function is currently provided by the 1009 Internet Society.