idnits 2.17.1 draft-fu-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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 822. ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 318: '...ode: The message MUST be transmitted i...' RFC 2119 keyword, line 325: '...ode: The message MUST be transmitted i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 508 has weird spacing: '... C_mode conne...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- 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 (May 17, 2005) is 6919 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-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: November 18, 2005 Siemens 5 X. Fu 6 Univ. Goettingen 7 C. Aoun 8 Nortel 9 E. Davies 10 Folly Consulting 11 May 17, 2005 13 GIMPS State Machine 14 draft-fu-nsis-ntlp-statemachine-02.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 November 18, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document describes the state machines for the General Internet 48 Messaging Protocol for Signaling (GIMPS). The states of GIMPS nodes 49 for a given signaling flow and their transitions are presented in 50 order to illustrate how GIMPS 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 . . . . . . . . . . . . . . . . . . . . 6 60 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 8 61 5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. State machine for GIMPS querying node . . . . . . . . . . . 9 63 7. State machine for GIMPS responding node . . . . . . . . . . 13 64 8. Security Considerations . . . . . . . . . . . . . . . . . . 16 65 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 16 66 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 67 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 12.1 Normative References . . . . . . . . . . . . . . . . . . 17 70 12.2 Informative References . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 72 Intellectual Property and Copyright Statements . . . . . . . 19 74 1. Introduction 76 This document describes the state machines for GIMPS [1], trying to 77 show how GIMPS can be implemented to support its deployment. The 78 state machines described in this document are illustrative of how the 79 GIMPS protocol defined in [1] may be implemented for the GIMPS nodes 80 in different locations of a flow path. Where there are differences 81 [1] are authoritative. The state machines are informative only. 82 Implementations may achieve the same results using different methods. 84 There are two types of possible entities for GIMPS signaling: 85 GIMPS querying node - GIMPS node that initiates the discovery of 86 the next peer; 87 GIMPS responding node - GIMPS node that is the discovered next 88 peer; 90 We describe a set of state machines for these entities to illustrate 91 how GIMPS may be implemented. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [2]. 99 3. Notational conventions used in state diagrams 101 The following text is reused from [3] and the state diagrams are 102 based on the conventions specified in [4], Section 8.2.1. Additional 103 state machine details are taken from [5]. 105 The complete text is reproduced here: 107 State diagrams are used to represent the operation of the protocol 108 by a number of cooperating state machines each comprising a group 109 of connected, mutually exclusive states. Only one state of each 110 machine can be active at any given time. 112 All permissible transitions between states are represented by 113 arrows, the arrowhead denoting the direction of the possible 114 transition. Labels attached to arrows denote the condition(s) 115 that must be met in order for the transition to take place. All 116 conditions are expressions that evaluate to TRUE or FALSE; if a 117 condition evaluates to TRUE, then the condition is met. The label 118 UCT denotes an unconditional transition (i.e., UCT always 119 evaluates to TRUE). A transition that is global in nature (i.e., 120 a transition that occurs from any of the possible states if the 121 condition attached to the arrow is met) is denoted by an open 122 arrow; i.e., no specific state is identified as the origin of the 123 transition. When the condition associated with a global 124 transition is met, it supersedes all other exit conditions 125 including UCT. The special global condition BEGIN supersedes all 126 other global conditions, and once asserted remains asserted until 127 all state blocks have executed to the point that variable 128 assignments and other consequences of their execution remain 129 unchanged. 131 On entry to a state, the procedures defined for the state (if any) 132 are executed exactly once, in the order that they appear on the 133 page. Each action is deemed to be atomic; i.e., execution of a 134 procedure completes before the next sequential procedure starts to 135 execute. No procedures execute outside of a state block. The 136 procedures in only one state block execute at a time, even if the 137 conditions for execution of state blocks in different state 138 machines are satisfied, and all procedures in an executing state 139 block complete execution before the transition to and execution of 140 any other state block occurs, i.e., the execution of any state 141 block appears to be atomic with respect to the execution of any 142 other state block and the transition condition to that state from 143 the previous state is TRUE when execution commences. The order of 144 execution of state blocks in different state machines is undefined 145 except as constrained by their transition conditions. A variable 146 that is set to a particular value in a state block retains this 147 value until a subsequent state block executes a procedure that 148 modifies the value. 150 On completion of all of the procedures within a state, all exit 151 conditions for the state (including all conditions associated with 152 global transitions) are evaluated continuously until one of the 153 conditions is met. The label ELSE denotes a transition that 154 occurs if none of the other conditions for transitions from the 155 state are met (i.e., ELSE evaluates to TRUE if all other possible 156 exit conditions from the state evaluate to FALSE). Where two or 157 more exit conditions with the same level of precedence become TRUE 158 simultaneously, the choice as to which exit condition causes the 159 state transition to take place is arbitrary. 161 In addition to the above notation, there are a couple of 162 clarifications specific to this document. First, all boolean 163 variables are initialized to FALSE before the state machine execution 164 begins. Second, the following notational shorthand is specific to 165 this document: 167 = | | ... 168 Execution of a statement of this form will result in 169 having a value of exactly one of the expressions. The logic for 170 which of those expressions gets executed is outside of the state 171 machine and could be environmental, configurable, or based on 172 another state machine such as that of the method. 174 4. State Machine Symbols 176 MA means "Messaging Association" 177 Upstream/Downstream MRS: means "Message Routing State with upstream/ 178 downstream peer state info" 179 ( ) Used to force the precedence of operators in Boolean expressions 180 and to delimit the argument(s) of actions within state boxes. 181 ; Used as a terminating delimiter for actions within state boxes. 182 Where a state box contains multiple actions, the order of 183 execution follows the normal language conventions for reading 184 text. 185 = Assignment action. The value of the expression to the right of 186 the operator is assigned to the variable to the left of the 187 operator. Where this operator is used to define multiple 188 assignments, e.g., a = b = X the action causes the value of the 189 expression following the right-most assignment operator to be 190 assigned to all of the variables that appear to the left of the 191 right-most assignment operator. 192 ! Logical NOT operator. 193 && Logical AND operator. 194 || Logical OR operator. 195 if...then... Conditional action. If the Boolean expression following 196 the if evaluates to TRUE, then the action following the then is 197 executed. 198 \{ statement 1, ... statement N \} Compound statement. Braces are 199 used to group statements that are executed together as if they 200 were a single statement. 201 != Inequality. Evaluates to TRUE if the expression to the left of 202 the operator is not equal in value to the expression to the right. 203 == Equality. Evaluates to TRUE if the expression to the left of the 204 operator is equal in value to the expression to the right. 205 > Greater than. Evaluates to TRUE if the value of the expression to 206 the left of the operator is greater than the value of the 207 expression to the right. 208 <= Less than or equal to. Evaluates to TRUE if the value of the 209 expression to the left of the operator is either less than or 210 equal to the value of the expression to the right. 212 ++ Increment the preceding integer operator by 1. 214 5. Common Rules 216 Throughout the document we use terms defined in the [1], such as 217 Query, Response, Confirm. 219 State machine represents handling of GIMPS messages that match a 220 Message Routing State's MRI and NSLPID and with no protocol errors. 221 Separate parallel instances of the state machines should handle 222 messages for different Message Routing States. 224 The state machine states represent the upstream/downstream peers 225 states of the Message Routing State. 227 For simplification not all objects included in a message are shown. 228 Only those that are significant for the case are shown. State 229 machines do not present handling of messages that are not significant 230 for management of the states. 232 Presented in this document state machines do not cover all functions 233 of a GIMPS node. Functionality of message forwarding, ROA 234 processing, transmission of NSLP data without MRS establishment and 235 providing of the received messages to the appropriate MRS, we refer 236 as "Lower level pre-processing" step. The interaction of this step 237 with the presented here state machines is defined as follows: 239 Pre-processing provides to the appropriate MRS FSM only the messages 240 which are matched against waiting Query/Response cookies, or 241 established MRS MRI+NSLPID primary key. This is presented by "rx_*" 242 events in the state machines. 244 5.1 Common Procedures 246 Tg_SendMsg: NSLP/GIMPS API message that request transmission of a 247 NSLP message 248 Tg_SetStateLifetime(time_period): NSLP/GIMPS API message providing 249 info for the Lifetime of an RS, required by the application. 250 "Time_period = 0" represents the cancellation of established RSs/ 251 MAs (invoked by NSLP application). 252 Tg_MessageDeliveryError: NSLP/GIMPS API message informing NSLP 253 application of unsuccessful delivery of a message 254 Tg_RecvMsg: NSLP/GIMPS API message that provides received message to 255 the NSLP 257 Tg_NetworkNotification: NSLP/GIMPS API message that informs NSLP for 258 change in MRS 259 Tx_Query_Dmode: Transmit of Query message in Dmode 260 Tx_Response_Dmode: Transmit of Response message in Dmode 261 Tx_Confirm_Dmode: Transmit of Confirm message in Dmode 262 Rx_Query_Dmode: Receive of Query message in Dmode 263 Rx_Response_Dmode: Receive of Response message in Dmode 264 Rx_Confirm_Cmode: Receive of Confirm message in Dmode 265 Tx_Response_Cmode: Transmit of Response message in Cmode (via MA) 266 Tx_Confirm_Cmode: Transmit of Confirm message in Cmode (via MA) 267 Rx_Response_Cmode: Receive of Response message in Cmode (via MA) 268 Rx_Confirm_Cmode: Receive of Confirm message in Cmode (via MA) 269 Queue NSLP msg info: Save NLSP messages in a queue until a required 270 MA association is established 271 Tx_Msg_Cmode: Transmit message in Cmode (via MA) 272 Rx_Msg_Cmode: Receive message in Cmode (via MA) 273 Tx_Msg_Dmode: Transmit message in Dmode 274 Rx_Msg_Dmode: Receive message in Dmode 275 TIMEOUT_MRSlifetime: Expiration of the lifetime timer of the 276 upstream/downstream peer state info of the Message Routing State. 277 TIMEOUT_MRS+MA_lifetime: Expiration of the lifetime timer of the 278 upstream/downstream peer state info of the Message Routing State, 279 where MA is used. 280 TIMEOUT_Refresh: Refresh interval timer expiration 281 TIMEOUT_WaitResponse: Expiration of Timer for the waiting period for 282 Response message 283 TIMEOUT_WaitConfirm: Expiration of Timer for the waiting period for 284 Confirm message 285 Install downstream/upstream MRS: Install new Message Routing State 286 and save the corespoding peer state info (IP address and UDP port 287 or pointer to the used MA) for the current Message Routing State 288 or update the coresponding peer state info. 289 DELETE MRS: Delete installed downstream/upstream peer's info for 290 the current Message Routing State and delete the Message Routing 291 State if required. 292 Establish MA: Establish Message Association (MA) between current 293 node and its downstream peer 294 Established MA: A Message Association (MA) is established between the 295 current node and its upstream peer. The initiator for the 296 establishment is the upstream peer. Re-use existing MA: An 297 existing MA between the current node and its peer is re-used 298 DELETE MA: Delete/disconnect used MA 299 Stop using shared MA: Stop using shared MA. If the shared MA is no 300 more used by any other MRSs, it depends on the local policy 301 whether it is deleted or kept. 303 REFRESH MRS: Refreshes installed MRS. 304 Tg_MA_Error: Error event with used MA. 305 Tg_PathChange: External event for Path change detected. 306 Tg_Establish_MA: Trigers establishment of MA. 307 Tg_MA_Established: MA has been successfully established. 308 Tg_ERROR: General Error event / system level error. 309 No_MRS_Installed: Error response, send by the Responding node 310 indicating lost Confirm message. 312 5.2 Common Variables 314 It is assumed that the type of mode and destination info (which need 315 to be taken from the application parameters and local GIMPS policy) 316 is provided. This is represented by the common variables Dmode, 317 Cmode, MAinfo, MApresent and Refresh. 318 Dmode: The message MUST be transmitted in Dmode. This is specified 319 by "Message transfer attributes" set to the following values: 320 Reliability: is set to FALSE 321 Security: is set to values that do not request special security 322 handling of a message. 323 Local processing: is set to values that do not require services 324 offered by Cmode [1] 325 Cmode: The message MUST be transmitted in Cmode. This is specified 326 by "Message transfer attributes" set to any of the following 327 values: 328 Reliability: is set to TRUE 329 Security: is set to values that request secure handling of a 330 message. 331 Local processing: is set to values that require services offered 332 by Cmode (e.g., congestion control) [1] 333 MAinfo: GIMPS message parameters describing the required MA or 334 proposed MA e.g. "Stack-proposal" and "Node-addressing". This 335 list of GIMPS parameters is not complete. A full mapping is left 336 for future version of the document. 337 NSLPdata: NSLP application data. 338 RespCookie: Responder Cookie that is being sent by the Responding 339 node with the Response message in case that its local policy 340 requires a confirmation from the querying node. 341 Refresh: This variable specifies that the message is for refresh 342 purposes 343 ConfirmRequired: TConfirm message is required by the local policy 344 rule for installation of the new MRS. 345 NewPeer: Response message is received from new responding peer. 346 MAexist: Existing MA will be reused. 348 CheckPeerInfo: The sender of the received data message is matched 349 against the installed peer info in the MRS. 350 UpstreamPeerInstalled: Upstream peer info is installed in the MRS. 352 5.3 Constants 354 6. State machine for GIMPS querying node 356 ----------- 357 State: IDLE 358 ----------- 360 Condition Action State Note 361 ------------------------+-------------------------+-----------+--- 362 (tg_SendMsg)&&(Dmode) |Tx_Query |Wait |1) 363 |Queue_NSLP_msg_data |Response |** 364 | | | 365 (tg_SendMsg)&&(Cmode) |Tx_Query(MAinfo) |Wait |1) 366 |Queue_NSLP_msg_data |Response | 367 | | | 368 ------------------------+-------------------------+-----------+--- 370 ------------------- 371 State: WaitResponse 372 ------------------- 374 Condition Action State Note 375 ------------------------+-------------------------+-----------+--- 376 (rx_Response_Dmode)|| |Install MRS |Established|** 377 ((rx_Response_?mode( |If (RespCookie) |Downstream |2) 378 MAinfo)&&(MAexist))| tx_Confirm_?mode(Resp |MRS | 379 | Cookie)| | 380 |Tx_queued_Msg_?mode | | 381 | | | 382 (rx_Response_?mode( |Tg_Establish_MA |Wait MA |* 383 MAinfo)&&(!MA_exist))|(Tx_Confirm_?mode) |Establish. |2) 384 | | | 385 rx_Msg_?mode |IF(CheckPeerInfo) |Wait |8) 386 | Tg_RecvMsg to Appl.|Response | 387 | | | 388 tg_SendMsg |Queue NSLP msg data |Wait |6) 389 | |Response | 390 | | | 392 Timeout_WaitResponse |(Tx_Query(MAinfo)) || |Wait | 393 |(Tx_Query(NSLPdata))|| |Response | 394 |(Tx_Query) | | 395 | | | 396 (Timeout_WaitResponse) |Tg_MessageDeliveryError |IDLE | 397 &&(MaxRetry) | | | 398 | | | 399 Tg_ERROR |(Delete MRS) |IDLE | 400 |IF (MA is used) | | 401 | ((Delete MA)|| | | 402 | (Stop using shared MA))| | 403 |Tg_NetworkNotification | | 404 | | | 405 ------------------------+-------------------------+-----------+--- 407 --------------------------------- 408 State: Established Downstream MRS 409 --------------------------------- 411 Condition Action State Note 412 ------------------------+-------------------------+-----------+--- 413 rx_Msg_?mode |IF(CheckPeerInfo) |Established|7) 414 | Tg_RecvMsg to Appl.|Downstream | 415 | |MRS | 416 | | | 417 tg_SendMsg_?mode |IF(Cmode)&&(MAexist) |Established|9) 418 | Tx_Msg_Cmode |Downstream | 419 |IF(Dmode) Tx_Msg_Dmode |MRS | 420 | | | 421 ((tg_SendMsg)&&(Cmode)&&|Tx_Query(MAinfo) |Wait |10) 422 (!MAexist))|| |Queue NSLP msg data |Response | 423 (tg_MA_error)|| | | | 424 (tg_Path_Change) | | | 425 | | | 426 Timeout_refresh |Tx_Query(Refresh) |Established| 427 | |Downstream | 428 | |MRS | 429 | | | 430 rx_Response(No_MRS |tx_Confirm(RespCookie) |Established| 431 _installed)|Tx_queued_Msg_Cmode |Downstream | 432 | |MRS | 433 | | | 434 (Timeout_MRSlifetime)|| |(Delete MRS) |IDLE | 435 (tg_SetStateLifetime(0))| | | 436 ||(Tg_ERROR) | | | 437 | | | 438 |Tg_NetworkNotification | | 439 | | | 440 (rx_Response_Dmode)|| |IF (MA is used) |Established|5) 441 (rx_Response_?mode( | ((Delete MA)|| |Downstream | 442 Mainfo)&&(NewPeer)&&| (Stop using shared MA))|MRS | 443 (MAexist) |Install MRS | | 444 |If (RespCookie) | | 445 | tx_Confirm_?mode(Resp | | 446 | Cookie)| | 447 | | | 448 (rx_Response_?mode( |((Delete MA)|| |Wait MA |* 449 MAinfo)&&(NewPeer)&&|(Stop using shared MA)) |Establish. |4) 450 (!MA_exist) |Tg_Establish_MA | | 451 |(Tx_Confirm_?mode) | | 452 | | | 453 | | | 454 | | | 455 | | | 456 | | | 457 ------------------------+-------------------------+-----------+--- 459 ---------------------------- 460 State: Wait MA Establishment 461 ---------------------------- 463 Condition Action State Note 464 ------------------------+-------------------------+-----------+--- 465 tg_SendMsg |Queue NSLP msg data |Wait MA |6) 466 | |Establish. | 467 | | | 468 Tg_MA_Established |Install MRS |Established|3) 469 |(Tx_Confirm_?mode) |Downstream |* 470 |(Tx_queued_Msg_Cmode) |MRS |** 471 | | | 472 Tg_MA_error |Delete MRS |IDLE | 473 |Tg_NetworkNotification | | 474 | | | 475 Tg_ERROR |(Delete MRS) |IDLE | 476 |IF (MA is used) | | 477 | ((Delete MA)|| | | 478 | (Stop using shared MA))| | 479 |Tg_NetworkNotification | | 480 | | | 481 ------------------------+-------------------------+-----------+--- 483 NOTE: 485 *) Response and Confirm messages might be send either in Dmode or 486 Cmode, before or after MA establishment depending on node's 487 local 3-way handshake policy and the availability of MAs to be 488 reused.See draft for details. 490 **) Depending on the local policy NSLPdata might be send as 491 payload of Query and Confirm messages. (piggybacking) 493 1) Initial request from NSLP are received, which triggers Query 494 messages requesting either D_mode or C_mode. Dependign on local 495 policy of the node, NSLP data might be piggybacked in the Query 496 requesting D_mode. 497 2) Response message is received. If C_mode connections must be 498 established and there is no available MA to be reused, MA 499 establishment is initiated and waited to be completed. If D_mode 500 connection is requested or available MA can be reused if C_mode is 501 requested the MRS is established. 502 3) New MA is successfully established and MRS, which will use it, is 503 installed. 504 4) Path change detected events - local recovery procedure, where 505 D_mode or C_mode with available MA must be established. THIS IS 506 VALID ONLY IF THE NODE IS CROSSOVER NODE 507 5) Path change detected events - local recovery procedure, where new 508 MA must be established for requested C_mode connection. THIS IS 509 VALID ONLY IF THE NODE IS CROSSOVER NODE 510 6) NSLP data is queued, because downstream peer is not discovered or 511 required MA is still not established. 512 7) Received Data messages are checked if their sender matches the 513 installed downstream peer info in the MRS and then processed. 514 8) Received Data messages are checked if their sender matches the 515 installed downstream peer info in the MRS and then processed. In 516 WaitResponse state, this event might happen in the process of MA 517 upgrade, when the downstream peer is still not aware of 518 establishment of the new MA. 519 9) Depending on the requested transport from NSLP and currently 520 established D_mode or C_mode, NSLP message is sent D_mode if 521 D_mode is requested and C_mode if the features of the used MA 522 covers the required transport ( e.g. used MA is reliable and NSLP 523 request reliable but not secure transport) 524 10) External event notifies for Path Change and discovery procedures 525 is restarted. THIS IS VALID ONLY IF THE NODE IS CROSSOVER NODE OR 526 NSLP requests C_mode transport that is not covered by currently 527 used D_mode or MA (case of MA upgrade) and discovery procedure is 528 restared but current downstream peer info is kept in order to be 529 able to receive messages from it during the upgrade process. 531 7. State machine for GIMPS responding node 533 ----------- 534 State: IDLE 535 ----------- 537 Condition Action State Note 538 ------------------------+-------------------------+-----------+--- 539 rx_Query(?) |Tx_Response_Dmode(Resp |Wait |1) 540 &&(ConfirmRequired) | Cookie)|Confirm | 541 |IF(NSLPdata) | | 542 |Tg_RecvMsg(NSLPdata) | | 543 | to Appl.| | 544 | | | 545 rx_Query(?) |Tx_Response_Dmode |Established|2) 546 &&(!ConfirmRequired) |Install MRS |Upstream | 547 |IF(NSLPdata) |MRS | 548 |Tg_RecvMsg(NSLPdata) | | 549 | to Appl.| | 550 | | | 551 rx_Query(MAinfo) |Tx_Response_?mode(Resp |Wait |* 552 &&(ConfirmRequired) | Cookie, MAinfo)|Confirm |1) 553 | | | 554 rx_Query(Mainfo) |Tx_Response_?mode(Resp |Established|* 555 &&(!ConfirmRequired) | Cookie, MAinfo)|Upstream |2) 556 |Set WaitConfirm timer |MRS | 557 |Install MRS | | 558 | | | 559 ------------------------+-------------------------+-----------+--- 561 ------------------- 562 State: WAIT CONFIRM 563 ------------------- 565 Condition Action State Note 566 ------------------------+-------------------------+-----------+--- 567 rx_Msg_?mode |Tx_Response(No_MRS_ |Wait |3) 568 | installed)|Confirm | 569 | | | 570 Rx_Confirm_?mode |Install Upstream MRS |Established|* 571 | |Upstream |6) 572 | |MRS | 573 | | | 574 Timeout_WaitConfirm | |IDLE | 575 | | | 576 ------------------------+-------------------------+-----------+--- 578 ------------------------------- 579 State: Established Upstream MRS 580 ------------------------------- 582 Condition Action State Note 583 ------------------------+-------------------------+-----------+--- 584 Rx_Confirm_?mode |Stop WaitConfirm timer |Established|6) 585 |Install MRS |Upstream | 586 |Tx_queued_Msg_Cmode |MRS | 587 | | | 588 (Timeout_WaitConfirm)&& |(Delete MRS) |IDLE |7) 589 (!UpstreamPeerInstalled)|IF (MA is used) | |** 590 | ((Delete MA)|| | | 591 | (Stop using shared MA))| | 592 |Tg_NetworkNotification | | 593 | | | 594 rx_Msg_?mode |IF(CheckPeerInfo) |Established|8) 595 | Tg_RecvMsg to Appl.|Upstream | 596 |ELSE |MRS | 597 |Tx_Response(No_MRS_ | | 598 | installed)| | 599 | | | 600 tg_SendMsg |IF(WaitConfirm timer set)|Established|9) 601 | Queue NSLP msg data|Upstream | 602 |ELSE Tx_Msg_?mode |MRS | 603 | | | 604 (Timeout_MRSlifetime)|| |(Delete MRS)&& |IDLE | 605 (tg_SetStateLifetime(0))|IF (MA is used) | | 606 | ((Delete MA)|| | | 607 | (Stop using shared MA))| | 608 |Tg_NetworkNotification | | 609 | | | 610 rx_Query(Refresh) |Refresh MRS |Established| 611 |Tx_Response(Refresh) |Upstream | 612 | |MRS | 613 | | | 614 (rx_Query(MAinfo))|| |Tx_Response_?mode(Resp |Established|* 615 ((rx_Query)&&(!MAinfo)&&| Cookie, MAinfo)|Upstream |5) 616 (ConfirmRequired))|Set WaitConfirm timer |MRS | 617 | | | 618 (rx_Query)&&(!MAinfo)&& |Install MRS |Established|4) 619 (!ConfirmRequired) |tx_Response |Upstream | 620 |IF (MA is used) |MRS | 621 | ((Delete MA)|| | | 622 | (Stop using shared MA))| | 623 |IF(NSLPdata) | | 624 |Tg_RecvMsg(NSLPdata) | | 625 | to Appl.| | 626 | | | 627 Tg_ERROR |(Delete MRS) |IDLE | 628 |IF (MA is used) | | 629 | ((Delete MA)|| | | 630 | (Stop using shared MA))| | 631 |Tg_NetworkNotification | | 632 | | | 633 ------------------------+-------------------------+-----------+--- 635 NOTE: 636 *) Response and Confirm messages might be send either in Dmode or 637 Cmode depending on node's local 3-way handshake policy and the 638 availability of MAs to be reused. See draft for details. 640 **) Differentiation between WaitConfirm timer expiration of 641 initial MRS event or MA_upgrade event is based on the presence 642 of installed peer info in the MRS. If no peer info is installed 643 this is initial MRS establishment. 645 1) Initial Query messages requesting either D_mode or C_mode 646 connection. In both cases, explicit Confirm message is required 647 for MRS installation, based on the local policy. Query requesting 648 D_mode might carry piggybacked NSLP data. 649 2) Initial Query messages requesting either D_mode or C_mode 650 connection. In both cases, MRS is installed immediately, based on 651 the local policy. Query requesting D_mode might carry piggybacked 652 NSLP data. In the case of C_mode request, Confirm message is 653 required to confirm the establishment of the used MA. 654 3) In case of lost Confirm message, data messages might be received 655 from the upstream node (it is unaware of the lost Confirm 656 message). Response indicating the loss of the Confirm is sent 657 back to the upstream node. 658 4) Event of change of the upstream peer (e.g., path change) with 659 request of D_mode and non-paranoid local policy. 660 5) Event of request of change of the used connection mode (from 661 D_mode/C_mode to better C_mode), event of change of the upstream 662 peer (e.g., path change) with request for C_mode or D_mode 663 connection and paranoid local policy. 665 6) Confirm message is received which causes installation of the 666 complete MRS or just installation of the used MA as a upstream 667 peer info. 668 7) Differentiation between WaitConfirm timer expiration of initial 669 MRS event or MA upgrade/change event is based on the presence of 670 installed peer info in the MRS. If no peer info is installed this 671 is initial MRS establishment and installed MRS must be deleted. 672 8) Data messages are accepted only if complete MRS is installed, 673 e.g., there is installed upstream peer info. If not then Confirm 674 message is expected and data message will not be accepted but 675 Response indicating the loss of the Confirm is sent back to the 676 upstream node. 677 9) NSLP message can't be sent upstream if Confirm message is not 678 received and MA is not installed as upstream peer info. They are 679 queued. 681 8. Security Considerations 683 This document does not raise new security considerations. Any 684 security concerns with GIMPS are likely reflected in security related 685 NSIS work already (such as [1] or [6]). 687 For the time being, the state machines described in this document do 688 not consider the security aspect of GMIPS protocol itself. A future 689 versions of this document will add security relevant states and state 690 transitions. 692 9. Open Issues 694 We have left for further version of the document the following 695 issues: 697 1. Route change and local repair mechanisms are not covered 698 completely. Currently we provide procedures for local repair in 699 the crossover node. Procedures for identifying the crossover node 700 are left for further study. 701 2. The FSM that handles the management of a MA is considered in the 702 document (e.g., tg_Establish_MA, tg_MA_established events), but it 703 is not currently explicitely presented. It is left for future 704 version of the document. 705 3. Functionality of, as referred in the document "Lower level pre- 706 processing" (Section 5), namely message forwarding, RAO 707 processing, transmission of NSLP data without MRS establishment 708 and providing of the received messages to the appropriate MRS is 709 left for future version of the document. 711 4. Currently we use WaitConfirm state in the Responding node FSM, but 712 following the DoS prevention approaches for no state installation 713 in the Responding node before receiving of Confirm message, we 714 consider possible removing of this state. This issue requires 715 further investigations. 717 10. Contributors 719 Christian Dickmann contributed to refining of the state machine since 720 01 version. 722 11. Acknowledgments 724 The authors would like to thank Robert Hancock, Ingo Juchem, Andreas 725 Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd 726 Schloer for their insightful comments. 728 12. References 730 12.1 Normative References 732 [1] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for 733 Signaling", draft-ietf-nsis-ntlp-05 (work in progress), 734 February 2005. 736 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 737 Levels", March 1997. 739 12.2 Informative References 741 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State 742 Machines for Extensible Authentication Protocol (EAP) Peer and 743 Authenticator", draft-ietf-eap-statemachine-06 (work in 744 progress), December 2004. 746 [4] Institute of Electrical and Electronics Engineers, "DRAFT 747 Standard for Local and Metropolitan Area Networks: Port-Based 748 Network Access Control (Revision)", IEEE 802-1X-REV/D9, 749 January 2004. 751 [5] Ohba, Y., "State Machines for Protocol for Carrying 752 Authentication for Network Access (PANA)", 753 draft-ohba-pana-statemachine-01 (work in progress), 754 February 2005. 756 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 757 draft-ietf-nsis-threats-06 (work in progress), October 2004. 759 Authors' Addresses 761 Tseno Tsenov 762 Siemens 763 Otto-Hahn-Ring 6 764 Munich, Bayern 81739 765 Germany 767 Email: tseno.tsenov@mytum.de 769 Hannes Tschofenig 770 Siemens 771 Otto-Hahn-Ring 6 772 Munich, Bayern 81739 773 Germany 775 Email: Hannes.Tschofenig@siemens.com 777 Xiaoming Fu 778 University of Goettingen 779 Telematics Group 780 Lotzestr. 16-18 781 Goettingen 37083 782 Germany 784 Email: fu@cs.uni-goettingen.de 786 Cedric Aoun 787 Nortel 788 France 790 Email: cedric.aoun@nortel.com 792 Elwyn B. Davies 793 Folly Consulting 794 Soham, Cambs 795 UK 797 Phone: +44 7889 488 335 798 Email: elwynd@dial.pipex.com 800 Intellectual Property Statement 802 The IETF takes no position regarding the validity or scope of any 803 Intellectual Property Rights or other rights that might be claimed to 804 pertain to the implementation or use of the technology described in 805 this document or the extent to which any license under such rights 806 might or might not be available; nor does it represent that it has 807 made any independent effort to identify any such rights. Information 808 on the procedures with respect to rights in RFC documents can be 809 found in BCP 78 and BCP 79. 811 Copies of IPR disclosures made to the IETF Secretariat and any 812 assurances of licenses to be made available, or the result of an 813 attempt made to obtain a general license or permission for the use of 814 such proprietary rights by implementers or users of this 815 specification can be obtained from the IETF on-line IPR repository at 816 http://www.ietf.org/ipr. 818 The IETF invites any interested party to bring to its attention any 819 copyrights, patents or patent applications, or other proprietary 820 rights that may cover technology that may be required to implement 821 this standard. Please address the information to the IETF at 822 ietf-ipr@ietf.org. 824 Disclaimer of Validity 826 This document and the information contained herein are provided on an 827 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 828 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 829 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 830 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 831 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 832 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 834 Copyright Statement 836 Copyright (C) The Internet Society (2005). This document is subject 837 to the rights, licenses and restrictions contained in BCP 78, and 838 except as set forth therein, the authors retain all their rights. 840 Acknowledgment 842 Funding for the RFC Editor function is currently provided by the 843 Internet Society.