idnits 2.17.00 (12 Aug 2021) /tmp/idnits46366/draft-fu-nsis-qos-nslp-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 981. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 987. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1003), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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 485 has weird spacing: '...pstream nodes...' == Line 486 has weird spacing: '...he next peer....' == Line 489 has weird spacing: '...e local polic...' == Line 492 has weird spacing: '... is not the c...' == Line 493 has weird spacing: '...nt from mergi...' == (1 more instance...) -- 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 25, 2006) is 5809 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: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '1') == Outdated reference: draft-ietf-eap-statemachine has been published as RFC 4137 == Outdated reference: draft-ietf-nsis-threats has been published as RFC 4081 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS X. Fu 2 B. Schloer 3 Internet-Draft Univ. Goettingen 4 Expiration Date: December 2006 H. Tschofenig 5 T. Tsenov 6 Siemens 7 June 25, 2006 9 QoS NSLP State Machine 10 draft-fu-nsis-qos-nslp-statemachine-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 25, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). All Rights Reserved. 41 Abstract 43 This document describes a state machine for the NSIS Signaling Layer 44 Protocol for Quality-of-Service signaling (QoS NSLP). A combined 45 state machine for QoS NSLP entities at different locations of a flow 46 path is presented in order to illustrate how QoS NSLP may be 47 implemented. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Notational conventions used in state diagrams . . . . . . . 3 54 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 4 55 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 6 57 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 7 58 5.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. State Machine for QoS NSLP nodes . . . . . . . . . . . . . . 8 61 6.1 State ST_IDLE . . . . . . . . . . . . . . . . . . . . . . 9 62 6.2 State ST_WR1 . . . . . . . . . . . . . . . . . . . . . . 11 63 6.3 State ST_WR2 . . . . . . . . . . . . . . . . . . . . . . 12 64 6.4 State ST_INST . . . . . . . . . . . . . . . . . . . . . . 14 65 7. Security Considerations . . . . . . . . . . . . . . . . . . 15 66 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 15 67 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 15 68 9.1 Changes in Version -01 . . . . . . . . . . . . . . . . . 15 69 9.2 Changes in Version -02 . . . . . . . . . . . . . . . . . 15 70 9.3 Changes in Version -03 . . . . . . . . . . . . . . . . . 16 71 9.3 Changes in Version -04 . . . . . . . . . . . . . . . . . 16 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 11.1 Normative References . . . . . . . . . . . . . . . . . . 16 75 11.2 Informative References . . . . . . . . . . . . . . . . . 16 76 Appendix A. ASCII versions of the state diagrams . . . . . . . . 17 77 A.1 State ST_IDLE . . . . . . . . . . . . . . . . . . . . . 17 78 A.2 State ST_WR1 . . . . . . . . . . . . . . . . . . . . . 18 79 A.3 State ST_WR2 . . . . . . . . . . . . . . . . . . . . . 19 80 A.4 State ST_INST . . . . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 82 Intellectual Property and Copyright Statements . . . . . . . 22 84 1. Introduction 86 This document describes a state machine for QoS NSLP [1], trying to 87 show how QoS NSLP can be implemented to support its deployment. The 88 state machine described in this document is illustrative of how the 89 QoS NSLP protocol defined in [1] may be implemented for QoS NSLP 90 nodes in the flow path. Where there are differences [1] are 91 authoritative. The state machine diagrams are informative only. 92 Implementations may achieve the same results using different methods. 94 According to [1], there are several possibilities for QoS NSLP 95 signaling, at least including the following: - end-to-end signaling 96 vs. scoped signaling - sender-initiated signaling vs. receiver- 97 initiated signaling. 99 The messages used in the QoS NSLP protocol can be summarized as 100 follows: 102 Requesting message Responding message 103 ------------------------+--------------------------- 104 RESERVE |None or RESERVE or RESPONSE 105 QUERY |RESERVE or RESPONSE 106 RESPONSE |NONE 107 NOTIFY |NONE 108 ------------------------+--------------------------- 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [2]. 116 3. Notational conventions used in state diagrams 118 The following text is reused from [3] and the state diagrams are 119 based on the conventions specified in [4], Section 8.2.1. Additional 120 state machine details are taken from [5]. 122 The complete text is reproduced here: 124 State diagrams are used to represent the operation of the protocol by 125 a number of cooperating state machines each comprising a group of 126 connected, mutually exclusive states. Only one state of each machine 127 can be active at any given time. 129 All permissible transitions between states are represented by arrows, 130 the arrowhead denoting the direction of the possible transition. 131 Labels attached to arrows denote the condition(s) that must be met in 132 order for the transition to take place. All conditions are 133 expressions that evaluate to TRUE or FALSE; if a condition evaluates 134 to TRUE, then the condition is met. The label UCT denotes an 135 unconditional transition (i.e., UCT always evaluates to TRUE). A 136 transition that is global in nature (i.e., a transition that occurs 137 from any of the possible states if the condition attached to the 138 arrow is met) is denoted by an open arrow; i.e., no specific state is 139 identified as the origin of the transition. When the condition 140 associated with a global transition is met, it supersedes all other 141 exit conditions including UCT. The special global condition BEGIN 142 supersedes all other global conditions, and once asserted remains 143 asserted until all state blocks have executed to the point that 144 variable assignments and other consequences of their execution remain 145 unchanged. 147 On entry to a state, the procedures defined for the state (if any) 148 are executed exactly once, in the order that they appear on the page. 149 Each action is deemed to be atomic; i.e., execution of a procedure 150 completes before the next sequential procedure starts to execute. No 151 procedures execute outside of a state block. The procedures in only 152 one state block execute at a time, even if the conditions for 153 execution of state blocks in different state machines are satisfied, 154 and all procedures in an executing state block complete execution 155 before the transition to and execution of any other state block 156 occurs, i.e., the execution of any state block appears to be atomic 157 with respect to the execution of any other state block and the 158 transition condition to that state from the previous state is TRUE 159 when execution commences. The order of execution of state blocks in 160 different state machines is undefined except as constrained by their 161 transition conditions. A variable that is set to a particular value 162 in a state block retains this value until a subsequent state block 163 executes a procedure that modifies the value. 165 On completion of all of the procedures within a state, all exit 166 conditions for the state (including all conditions associated with 167 global transitions) are evaluated continuously until one of the 168 conditions is met. The label ELSE denotes a transition that occurs 169 if none of the other conditions for transitions from the state are 170 met (i.e., ELSE evaluates to TRUE if all other possible exit 171 conditions from the state evaluate to FALSE). Where two or more exit 172 conditions with the same level of precedence become TRUE 173 simultaneously, the choice as to which exit condition causes the 174 state transition to take place is arbitrary. 176 In addition to the above notation, there are a couple of 177 clarifications specific to this document. First, all boolean 178 variables are initialized to FALSE before the state machine execution 179 begins. Second, the following notational shorthand is specific to 180 this document: 182 = | | ... 184 Execution of a statement of this form will result in 185 having a value of exactly one of the expressions. The logic for 186 which of those expressions gets executed is outside of the state 187 machine and could be environmental, configurable, or based on 188 another state machine such as that of the method. 190 4. State Machine Symbols 192 ( ) 193 Used to force the precedence of operators in Boolean expressions 194 and to delimit the argument(s) of actions within state boxes. 196 ; 197 Used as a terminating delimiter for actions within state boxes. 198 Where a state box contains multiple actions, the order of 199 execution follows the normal English language conventions for 200 reading text. 202 = 203 Assignment action. The value of the expression to the right of 204 the operator is assigned to the variable to the left of the 205 operator. Where this operator is used to define multiple 206 assignments, e.g., a = b = X the action causes the value of the 207 expression following the right-most assignment operator to be 208 assigned to all of the variables that appear to the left of the 209 right-most assignment operator. 211 ! 212 Logical NOT operator. 214 && 215 Logical AND operator. 217 || 218 Logical OR operator. 220 if...then... 221 Conditional action. If the Boolean expression following the if 222 evaluates to TRUE, then the action following the then is executed. 224 { statement 1, ... statement N } 225 Compound statement. Braces are used to group statements that are 226 executed together as if they were a single statement. 228 != 229 Inequality. Evaluates to TRUE if the expression to the left of 230 the operator is not equal in value to the expression to the right. 232 == 233 Equality. Evaluates to TRUE if the expression to the left of the 234 operator is equal in value to the expression to the right. 236 > 237 Greater than. Evaluates to TRUE if the value of the expression to 238 the left of the operator is greater than the value of the 239 expression to the right. 241 <= 242 Less than or equal to. Evaluates to TRUE if the value of the 243 expression to the left of the operator is either less than or 244 equal to the value of the expression to the right. 246 ++ 247 Increment the preceding integer operator by 1. 249 + 250 Arithmetic addition operator. 252 & 253 Bitwise AND operator. 255 5. Common Rules 257 Throughout the document we use terms defined in the [1], such as flow 258 sender, flow receiver, QUERY, RESERVE or RESPONSE. 260 5.1 Common Procedures 262 tx_reserve(): 263 Transmit RESERVE message 265 tx_response(): 266 Transmit RESPONSE message 268 tx_query(): 269 Transmit QUERY message 271 tx_notify(): 272 Transmit NOTIFY message 274 install_qos_state(): 275 Install the local QoS state. 277 delete_qos_state(): 278 Delete the local QoS state. 280 send_info_to_app(): 281 Report information to the application. 283 RMF(): 284 Performs Resource Management Function and returns the following 285 values{AVAIL, NO_AVAIL}. 287 is_local(RII): 288 Checks the RII object of received RESPONSE message if it is 289 requested by current node or other upstream node. Returns values 290 {true, false}. 292 is_local(RSN): 293 Checks The RSN object of the received RESPONSE message if it is 294 requested by current node. Returns values {true, false}. 296 process_query(): 297 Processes a Query message and provides the requested info 299 5.2 Common Variables 301 RII: 303 Request Identification Information (RII) object. 305 RSN: 306 Reservation Sequence Number (RSN) object. 308 INFO: 309 Info_Spec object. Takes values: 310 - 0x02 - Success values 311 - 0x04 - Transient Failure values 313 QSPEC: 314 QoS specification object. 316 T-Flag: 317 Tear-Flag. Indicates to tear down reservation state. 319 A-Flag: 320 Acknowledgement-Flag of common message header. Takes values 321 {true, false}. 323 R-Flag: 324 Reserve-Init. Indicates a Receiver Initiated Reservation request 325 in a QUERY message. 327 S-Flag: 328 Scoping flag of common message header. Takes values 329 {true="Next_hop", false="Whole_path"}. 331 setRII: 332 If set a RII object will be included into the message. Takes 333 values {true, false}. 335 setACK: 336 If set a RSN object will be included into the message. Takes 337 values {true, false}. 339 ReducedRefresh: 340 Keeps information if Reduced refresh method may be used for 341 refreshing a installed QoS state. Takes value {"On","Off"}. 343 FlowID: 344 Flow ID kept by the installed QoS state. 346 Replace: 347 Replace flag of common message header. Takes values {"On","Off"}. 349 nodepos: 350 Position of the QoS NSLP node. Takes values {"QNI", "QNE", "QNR"}. 352 TOGGLE: 353 Flag to indicate whether the direction of a new message has to be 354 changed compared to the direction of a received one. Takes values 355 {true, false}. 357 DIRECTION: 358 Direction, in which the message has to be sent. Takes values 359 {DOWNSTREAM, UPSTREAM}. 361 SII: 362 Source Identification Information entry. Takes values: 363 - CurrSII - SII entry stored for current installed QoS state. 364 (Assumed to be the one for the direction where the message comes 365 from e.g.Upstream/Downstream) 366 - newSII - SII of the received message is different from the SII 367 stored for the current installed QoS state. 369 5.3 Events 371 EV_TIMEOUT_STATE_LIFETIME: 372 State lifetime timer expiration 374 EV_TIMEOUT_REFRESH: 375 Refresh interval timer expiration 377 EV_TIMEOUT_REFRESH: 378 Wait-Response interval timer expiration 380 EV_TG_QUERY: 381 External trigger to send a QUERY message (typically triggered by 382 the application). 384 EV_TG_RESERVE: 385 External trigger to send a RESERVE message. 387 EV_TG_TEARDOWN: 388 External trigger to clear previously established QoS state 389 (typically triggered by the application). It is translated to a 390 tx_RESERVE(T-Flag) message. 392 EV_RX_RESPONSE: 393 RESPONSE message received 395 EV_RX_QUERY: 396 QUERY message received 398 EV_RX_RESERVE: 399 RESERVE message received 401 EV_RX_NOTIFY: 402 NOTIFY message received 404 5.4 Assumptions 406 - For simplification not all included objects in a message are 407 shown. Only those that are significant for the case are showed. 408 State machines do not present handling of messages that are not 409 significant for management of the states such as certain NOTIFY 410 and QUERY messages. 411 - State machines represent handling of messages of the same Session 412 ID and with no protocol errors. Separate parallel instances of 413 the state machines should handle messages for different Session 414 IDs. 415 - Default message handling should be defined for messages with 416 different Session IDs that have impact on current session state 417 and error messages. This is not included in the current version. 419 6. State machine 421 The following section presents the state machine diagrams of QoS NSLP 423 6.1 State ST_IDLE 425 (see the .pdf version for missing diagram or 426 refer to Appendix A.1 if reading the .txt version) 428 Figure 1: State ST_IDLE 430 (see the .pdf version for missing diagram or 431 refer to Appendix A.1 if reading the .txt version) 433 Figure 2: State ST_IDLE 435 6.2 State ST_WR1 437 (see the .pdf version for missing diagram or 438 refer to Appendix A.2 if reading the .txt version) 440 Figure 3: State ST_WR1 442 6.3 State ST_WR2 444 (see the .pdf version for missing diagram or 445 refer to Appendix A.2 if reading the .txt version) 447 Figure 4: State ST_WR2 449 (see the .pdf version for missing diagram or 450 refer to Appendix A.2 if reading the .txt version) 452 Figure 5: State ST_WR2 454 6.4 State ST_INST 456 (see the .pdf version for missing diagram or 457 refer to Appendix A.3 if reading the .txt version) 459 Figure 6: State ST_INST 461 7. Security Considerations 463 This document does not raise new security considerations. Any 464 security concerns with QoS NSLP are likely reflected in security 465 related NSIS work already (such as [1] or [6]). 467 For the time being, the state machines described in this document do 468 not consider the security aspect of QoS NSLP protocol itself. A 469 future versions of this document will add security relevant states 470 and state transitions. 472 8. Open Issues 474 This document tries to describe possible states and transitions for 475 QoS NSLP according to its current specification [1], Section 5. We 476 found some issues during the development of the state machines. 478 1. Bi-directional reservation is difficult to support as the state 479 machine becomes quite complex (note at one particular point in 480 time the protocol state engine can be only in one state). 481 2. How to signal unsuccessful reservation for Receiver initiated 482 reservation (No RII included; a resulting Response(RSN) cannot be 483 forwarded further than the next peer). We use NOTIFY message. 484 3. The case of unsuccessful reservation at a QNE node and no RII 485 specified by upstream nodes. According to the spec RESPONSE(RSN) 486 should not be forwarded further than the next peer. Currently we 487 use NOTIFY(RSN) that is sent further to the upstream nodes. 488 4. We assume that handling of QoS state lifetime expiration event is 489 based on the local policy of the node. NOTIFY/Reserve(Ton) 490 messages might be sent to other peers. 491 5. The draft states that RESERVE message MUST be sent only towards 492 the QNR. This is not the case when re-routing procedure is done 493 and RESERVE(Ton) message should be sent from merging QNE node for 494 deleting the old branch. We believe this is towards the QNI. 495 6. Re-routing functionality described in this document is not 496 complete and need further consideration. 498 9. Change History 500 9.1 Changes in Version -01 502 1. Notation of the nodes changed to QNI, QNE and QNR. 503 2. Description of soft state refresh functionality. 504 3. Support of ACK flag in the common header. 505 4. Include of QoS NSLP objects, flags from the common header and 506 entries stored with the installed QoS state in a node: ACK, 507 Replace, RSN, Error_SPEC, QSPEQ, FlowID, SII. 508 5. Initial description of Re-routing functionality. 509 6. For support of all listed changes, some notations are changed. 511 9.2 Changes in Version -02 513 1. Switch to .pdf format of the draft and include graphic diagrams. 514 2. Update notation from "Summary refresh" to "Reduced refresh" 515 3. Description of QoS reservation update/upgrade 517 9.3 Changes in Version -03 519 1. Deep review of the state machine archtitecure 521 9.4 Changes in Version -04 523 1. Reduced the three state machines of QNI, QNE and QNR to one for 524 all nodes. 525 2. Introduced new flags to have a finer control of the direction of 526 the message to be sent. 528 10. Acknowledgments 530 The authors would like to thank Sven Van den Bosch for his feedback. 532 11. References 534 11.1. Normative References 536 [1] Manner, J., Karagiannis, G. and McDonald, A., "NSLP for 537 Quality-of-Service Signaling", Internet draft, draft- 538 ietf-nsis-qos-nslp-09, March 2006. 540 [2] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 11.2. Informative References 545 [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 546 "State Machines for Extensible Authentication Protocol 547 (EAP) Peer and Authenticator", draft-ietf-eap- 548 statemachine-06 (work in progress), December 2004. 550 [4] Institute of Electrical and Electronics Engineers, "DRAFT 551 Standard for Local and Metropolitan Area Networks: Port- 552 Based 553 Network Access Control (Revision)", IEEE 802-1X-REV/D11, 554 July 2004. 556 [5] Ohba, Y., "State Machines for Protocol for Carrying 557 Authentication for Network Access (PANA)", 558 draft-ohba-pana-statemachine-01 (work in progress), 559 February 2005. 561 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for 562 NSIS", draft-ietf-nsis-threats-06 (work in progress), 563 October 2004. 565 Appendix A. ASCII versions of state diagrams 567 This appendix contains the state diagrams in ASCII format. Please 568 use the PDF version whenever possible: it is much easier to 569 understand. 571 The notation is as follows: for each state there is a separate table 572 that lists in each row: 573 - an event that triggers a transition, 574 - actions taken as a result of the incoming event, 575 - and the new state at which the transitions ends. 577 A.1. State ST_IDLE 579 Condition: EV_RX_QUERY 580 +-------------------------------------------------------+-----------+ 581 | Action | new State | 582 +-------------------------------------------------------+-----------+ 583 | | | 584 | If(!R-Flag) { | ST_IDLE | 585 | if((nodepos==QNE) && (!S-Flag)) { | | 586 | tx_query(TOGGLE=false); | | 587 | } else { | | 588 | process_query(); | | 589 | tx_response(RII, INFO, QSPEC, UPSTREAM); | | 590 | } | | 591 | } | | 592 | | | 593 +-------------------------------------------------------+-----------+ 594 | | | 595 | If(R-Flag && (nodepos==QNI) && (RMF()==NO_AVAIL)) { | ST_IDLE | 596 | send_info_to_app(); | | 597 | } | | 598 | | | 599 +-------------------------------------------------------+-----------+ 600 | | | 601 | If((R-Flag && (nodepos==QNI) && (RMF==AVAIL)) { | ST_WR2 | 602 | if(setRII==true) { | | 603 | tx_reserve(RSN, RII, QSPEC, UPSTREAM); | | 604 | } else if (setACK==true) { | | 605 | tx_reserve(RSN, QSPEC, UPSTREAM); | | 606 | } | | 607 | } | | 608 | | | 609 +-------------------------------------------------------+-----------+ 610 | | | 611 | If((R-Flag && (nodepos==QNI) && (RMF==AVAIL) && | ST_INST | 612 | (setRII==false) && (setACK==false)) { | | 613 | tx_reserve(RSN, QSPEC, UPSTREAM); | | 614 | } | | 615 | | | 616 +-------------------------------------------------------+-----------+ 618 Condition: EV_TG_RESERVE 619 +-------------------------------------------------------+-----------+ 620 | Action | new State | 621 +-------------------------------------------------------+-----------+ 622 | | | 623 | If(RMF()==NO_AVAIL) { | ST_IDLE | 624 | send_info_to_app(); | | 625 | } | | 626 | | | 627 +-------------------------------------------------------+-----------+ 628 | | | 629 | If(RMF()==AVAIL) { | ST_WR2 | 630 | if (setRII==true) { | | 631 | tx_reserve(RSN, RII, QSPEC, TOGGLE=false); | | 632 | } else if(setACK==true) { | | 633 | tx_reserve(RSN, QSPEC, TOGGLE=false); | | 634 | } | | 635 | } | | 636 | | | 637 +-------------------------------------------------------+-----------+ 638 | | | 639 | If((RMF()==AVAIL) && (setACK==false) && | ST_INST | 640 | (setRII==false)) { | | 641 | tx_reserve(RSN, QSPEC, TOGGLE=false); | | 642 | } | | 643 | | | 644 +-------------------------------------------------------+-----------+ 646 Condition: EV_RX_RESPONSE 647 +-------------------------------------------------------+-----------+ 648 | Action | new State | 649 +-------------------------------------------------------+-----------+ 650 | | | 651 | If(nodepos==QNE) { | ST_IDLE | 652 | tx_response(TOGGLE=false); | | 653 | } | | 654 | | | 655 +-------------------------------------------------------+-----------+ 656 Condition: EV_RX_RESERVE 657 +-------------------------------------------------------+-----------+ 658 | Action | new State | 659 +-------------------------------------------------------+-----------+ 660 | | | 661 | If(RMF()==NO_AVAIL) { | ST_IDLE | 662 | tx_response(info=0x04, TOGGLE=true); | | 663 | } | | 664 | | | 665 +-------------------------------------------------------+-----------+ 666 | | | 667 | If(RMF()==AVAIL) { | | 668 | If((nodepos==QNE) && (S-Flag==false)) { | | 669 | tx_reserve(TOGGLE=false); | | 670 | } | | 671 | If(A-Flag) { | | 672 | tx_response(RSN, info=0x02, TOGGLE=true); | | 673 | } | | 674 | If(RII && ((nodepos==QNR) || ((nodepos==QNE) && | | 675 | (S-Flag==true))) { | | 676 | tx_response(RII, info=0x02, TOGGLE=true); | | 677 | } | | 678 | } | | 679 | | | 680 +-------------------------------------------------------+-----------+ 681 | | | 682 | If((nodepos==QNE) && (RMF()==AVAIL)) { | ST_WR2 | 683 | if(setRII==true) start_response_timer(RII); | | 684 | if(setACK==true) start_response_timer(RSN); | | 685 | } | | 686 | | | 687 +-------------------------------------------------------+-----------+ 688 | | | 689 | If((nodepos==QNE) && (RMF()==AVAIL) && | ST_INST | 690 | (setRII==false) && (setACK==false)) | | 691 | | | 692 +-------------------------------------------------------+-----------+ 694 Condition: EV_TG_QUERY 695 +-------------------------------------------------------+-----------+ 696 | Action | new State | 697 +-------------------------------------------------------+-----------+ 698 | | | 699 | If((nodepos==QNR) && (R-Flag)) { | ST_WR1 | 700 | tx_query(R-Flag, QSPEC, DOWNSTREAM); | | 701 | start_response_timer(); | | 702 | } else { | | 703 | tx_query(RII, QSPEC, DOWNSTREAM); | | 704 | start_response_timer(RII); | | 705 | } | | 706 | | | 707 +-------------------------------------------------------+-----------+ 709 Figure 7 711 A.2. State ST_WR1 713 Condition: EV_RX_RESPONSE 714 +-------------------------------------------------------+-----------+ 715 | Action | new State | 716 +-------------------------------------------------------+-----------+ 717 | | | 718 | If(nodepos==QNE) { | | 719 | tx_response(TOGGLE=false); | | 720 | } | | 721 | If(is_local(RII)==true) { | | 722 | stop_response_timer(RII); | | 723 | } | | 724 | If(is_local(RSN)==true) { | | 725 | stop_response_timer(RSN); | | 726 | } | | 727 | | | 728 +-------------------------------------------------------+-----------+ 729 | | | 730 | If(TIMER_PENDING==true) | ST_WR1 | 731 | | | 732 +-------------------------------------------------------+-----------+ 733 | | | 734 | If(TIMER_PENDING==false) | ST_IDLE | 735 | | | 736 +-------------------------------------------------------+-----------+ 738 Condition: EV_TIMEOUT_RESPONSE 739 +-------------------------------------------------------+-----------+ 740 | Action | new State | 741 +-------------------------------------------------------+-----------+ 742 | | | 743 | If((MAX_RETRY==true) && (TIMER_PENDING==false)) | ST_IDLE | 744 | | | 745 +-------------------------------------------------------+-----------+ 746 | | | 747 | If((MAX_RETRY==true) && (TIMER_PENDING==true)) | ST_WR1 | 748 | | | 749 +-------------------------------------------------------+-----------+ 750 | | | 751 | If(MAX_RETRY==false) { | ST_WR1 | 752 | tx_query(DIRECTION); | | 753 | restart_response_timer(); | | 754 | } | | 755 | | | 756 +-------------------------------------------------------+-----------+ 758 Condition: EV_RX_RESERVE 759 +-------------------------------------------------------+-----------+ 760 | Action | new State | 761 +-------------------------------------------------------+-----------+ 762 | | | 763 | if((nodepos==QNR) && (A-Flag)) { | ST_WR2 | 764 | tx_response(RSN, TOGGLE=true); | | 765 | } | | 766 | | | 767 +-------------------------------------------------------+-----------+ 768 | | | 769 | If((nodepos==QNR) && RII)) { | ST_WR2 | 770 | tx_response(RII, TOGGLE=true); | | 771 | } | | 772 | | | 773 +-------------------------------------------------------+-----------+ 774 | | | 775 | If((nodepos==QNR) && (!RII) && (!A-Flag)) | ST_INST | 776 | | | 777 +-------------------------------------------------------+-----------+ 778 Figure 8 780 A.3. State ST_WR2 782 Condition: EV_RX_RESPONSE 783 +-------------------------------------------------------+-----------+ 784 | Action | new State | 785 +-------------------------------------------------------+-----------+ 786 | | | 787 | If(is_local(RII)==true) { | | 788 | stop_response_timer(RII); | | 789 | } | | 790 | If(is_local(RSN)==true) { | | 791 | stop_response_timer(RSN); | | 792 | } | | 793 | | | 794 | If((info==0x02) && (TIMER_PENDING==false)) { | ST_INST | 795 | start_refresh_timer(); | | 796 | } | | 797 | | | 798 +-------------------------------------------------------+-----------+ 799 | | | 800 | If((info==0x02) && (TIMER_PENDING==true)) | ST_WR2 | 801 | | | 802 +-------------------------------------------------------+-----------+ 803 | | | 804 | If(info==0x04) { | ST_IDLE | 805 | delete_qos_state(); | | 806 | stop_timers() | | 807 | } | | 808 | | | 809 +-------------------------------------------------------+-----------+ 811 Condition: EV_RX_RESERVE 812 +-------------------------------------------------------+-----------+ 813 | Action | new State | 814 +-------------------------------------------------------+-----------+ 815 | | | 816 | If((nodepos==QNE) && (S-Flag==false)) { | | 817 | tx_reserve(TOGGLE=false); | | 818 | } | | 819 | | | 820 | If(T-Flag==true) { | ST_IDLE | 821 | delete_qos_state(); | | 822 | stop_timers(); | | 823 | } | | 824 | | | 825 +-------------------------------------------------------+-----------+ 826 | | | 827 | If(T-Flag==false) { | ST_WR2 | 828 | tx_response(RII, RSN, TOGGLE=true); | | 829 | restart_refresh_timer(); | | 830 | } | | 831 | | | 832 +-------------------------------------------------------+-----------+ 834 Condition: EV_TIMEOUT_RESPONSE 835 +-------------------------------------------------------+-----------+ 836 | Action | new State | 837 +-------------------------------------------------------+-----------+ 838 | | | 839 | If((MAX_RETRY==true) && (TIMER_PENDING==false)) { | ST_IDLE | 840 | stop_state_timer(); | | 841 | } | | 842 | | | 843 +-------------------------------------------------------+-----------+ 844 | | | 845 | If((MAX_RETRY==true) && (TIMER_PENDING==true)) | ST_WR2 | 846 | | | 847 +-------------------------------------------------------+-----------+ 848 | | | 849 | If(MAX_RETRY==false) { | ST_WR2 | 850 | tx_reserve(DIRECTION); | | 851 | restart_response_timer(); | | 852 | } | | 853 | | | 854 +-------------------------------------------------------+-----------+ 856 Condition: EV_TIMEOUT_REFRESH 857 +-------------------------------------------------------+-----------+ 858 | Action | new State | 859 +-------------------------------------------------------+-----------+ 860 | | | 861 | tx_reserve(RSN, A-Flag, S-Flag, DIRECTION); | ST_WR2 | 862 | start_response_timer(); | | 863 | | | 864 +-------------------------------------------------------+-----------+ 866 Condition: EV_TIMEOUT_STATELIFETIME 867 +-------------------------------------------------------+-----------+ 868 | Action | new State | 869 +-------------------------------------------------------+-----------+ 870 | | | 871 | stop_timers(); | ST_IDLE | 872 | delete_qos_state(); | | 873 | If(nodepos != QNR) { | | 874 | tx_reserve(T-Flag, DIRECTION); | | 875 | } | | 876 | | | 877 +-------------------------------------------------------+-----------+ 878 Figure 9 880 A.4. State ST_INST 882 Condition: EV_RX_RESERVE 883 +-------------------------------------------------------+-----------+ 884 | Action | new State | 885 +-------------------------------------------------------+-----------+ 886 | | | 887 | If((nodepos==QNE) && (S-Flag==false)) { | | 888 | tx_reserve(TOGGLE=false); | | 889 | } | | 890 | | | 891 +-------------------------------------------------------+-----------+ 892 | | | 893 | If(T-Flag==true) { | ST_IDLE | 894 | delete_qos_state(); | | 895 | stop_timers(); | | 896 | } | | 897 | | | 898 | If(T-Flag==false) { | ST_WR2 | 899 | tx_response(RII, RSN, TOGGLE=true); | | 900 | restart_refresh_timer(); | | 901 | } | | 902 | | | 903 +-------------------------------------------------------+-----------+ 905 Condition: EV_TIMEOUT_STATELIFETIME 906 +-------------------------------------------------------+-----------+ 907 | Action | new State | 908 +-------------------------------------------------------+-----------+ 909 | | | 910 | stop_timers(); | ST_IDLE | 911 | delete_qos_state(); | | 912 | If(nodepos != QNR) { | | 913 | tx_reserve(T-Flag, DIRECTION); | | 914 | } | | 915 | | | 916 +-------------------------------------------------------+-----------+ 918 Condition: EV_TIMEOUT_REFRESH 919 +-------------------------------------------------------+-----------+ 920 | Action | new State | 921 +-------------------------------------------------------+-----------+ 922 | | | 923 | tx_reserve(RSN, A-Flag, S-Flag, DIRECTION); | ST_WR2 | 924 | start_response_timer(); | | 925 | | | 926 +-------------------------------------------------------+-----------+ 927 Figure 10 929 Authors' Addresses 931 Xiaoming Fu 932 University of Goettingen 933 Telematics Group 934 Lotzestr. 16-18 935 Goettingen 37083 936 Germany 938 Email: fu@cs.uni-goettingen.de 940 Hannes Tschofenig 941 Siemens 942 Otto-Hahn-Ring 6 943 Munich, Bayern 81739 944 Germany 946 Email: Hannes.Tschofenig@siemens.com 948 Tseno Tsenov 949 Siemens 950 Otto-Hahn-Ring 6 951 Munich, Bayern 81739 952 Germany 954 Email: tseno.tsenov@mytum.de 956 Bernd Schloer 957 University of Goettingen 958 Telematics Group 959 Lotzestr. 16-18 960 Goettingen 37083 961 Germany 963 Email: bschloer@cs.uni-goettingen.de 965 Intellectual Property Statement 967 The IETF takes no position regarding the validity or scope of any 968 Intellectual Property Rights or other rights that might be claimed to 969 pertain to the implementation or use of the technology described in 970 this document or the extent to which any license under such rights 971 might or might not be available; nor does it represent that it has 972 made any independent effort to identify any such rights. Information 973 on the procedures with respect to rights in RFC documents can be 974 found in BCP 78 and BCP 79. 976 Copies of IPR disclosures made to the IETF Secretariat and any 977 assurances of licenses to be made available, or the result of an 978 attempt made to obtain a general license or permission for the use of 979 such proprietary rights by implementers or users of this 980 specification can be obtained from the IETF on-line IPR repository at 981 http://www.ietf.org/ipr. 983 The IETF invites any interested party to bring to its attention any 984 copyrights, patents or patent applications, or other proprietary 985 rights that may cover technology that may be required to implement 986 this standard. Please address the information to the IETF at ietf- 987 ipr@ietf.org. 989 Disclaimer of Validity 991 This document and the information contained herein are provided on an 992 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 993 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 994 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 995 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 996 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 997 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 999 Copyright Statement 1001 Copyright (C) The Internet Society (2006). This document is subject 1002 to the rights, licenses and restrictions contained in BCP 78, and 1003 except as set forth therein, the authors retain all their rights. 1005 Acknowledgement 1007 Funding for the RFC Editor function is currently provided by the 1008 Internet Society.