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