idnits 2.17.00 (12 Aug 2021) /tmp/idnits50777/draft-fu-nsis-qos-nslp-statemachine-00.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 702. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 10, 2004) is 6401 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') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: draft-ietf-eap-statemachine has been published as RFC 4137 == Outdated reference: A later version (-01) exists of draft-ohba-pana-statemachine-00 == Outdated reference: draft-ietf-nsis-threats has been published as RFC 4081 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS X. Fu 2 Internet-Draft Univ. Goettingen 3 Expires: May 11, 2005 H. Tschofenig 4 T. Tsenov 5 Siemens 6 November 10, 2004 8 QoS NSLP State Machine 9 draft-fu-nsis-qos-nslp-statemachine-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 11, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document describes the state machines for the NSIS Signaling 45 Layer Protocol for Quality-of-Service signaling (QoS NSLP). A set of 46 state machines for QoS NSLP entities at different locations of a flow 47 path are presented in order to illustrate how QoS NSLP may be 48 implemented. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Notational conventions used in state diagrams . . . . . . . . 5 55 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . . 7 56 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8 58 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 8 59 5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 60 6. State machine for first QoS NSLP node in the flow path . . . . 10 61 7. State machine for intermediate QoS NSLP nodes . . . . . . . . 13 62 8. State machine for last QoS NSLP node in the flow path . . . . 17 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 64 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 20 65 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 67 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 68 12.2 Informative References . . . . . . . . . . . . . . . . . . . 22 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 70 Intellectual Property and Copyright Statements . . . . . . . . 24 72 1. Introduction 74 This document describes the state machines for QoS NSLP [1], trying 75 to show how QoS NSLP can be implemented to support its deployment. 76 The state machines described in this document are illustrative of how 77 the QoS NSLP protocol defined in [1] may be implemented for the first 78 QoS NSLP node in the flow path, intermediate QoS NSLP nodes, and the 79 last QoS NSLP node in the flow path. Where there are differences [1] 80 are authoritative. The state machines are informative only. 81 Implementations may achieve the same results using different methods. 83 According to [1], there are several possibilities for QoS NSLP 84 signaling, at least including the following: 85 end-to-end signaling vs. scoped signaling 86 sender-initiated signaling vs. receiver-initiated signaling 87 (which need to be incorporated into use scenarios when describing 88 state machine. Note they are represented by way of certain 89 objects/flags in Reserve and Query messages.) 91 The messages used in the QoS NSLP protocol can be summarized as 92 follows: 94 Requesting message Responding message 95 ------------------------+--------------------------- 96 RESERVE |None or RESERVE or RESPONSE 97 QUERY |RESERVE or RESPONSE 98 RESPONSE |NONE 99 NOTIFY |NONE 100 ------------------------+--------------------------- 102 We describe a set of state machines for different roles of entities 103 running QoS NSLP to illustrate how QoS NSLP may be implemented. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [2]. 111 3. Notational conventions used in state diagrams 113 The following text is reused from [3] and the state diagrams are 114 based on the conventions specified in [4], Section 8.2.1. Additional 115 state machine details are taken from [5]. 117 The complete text is reproduced here: 119 State diagrams are used to represent the operation of the protocol 120 by a number of cooperating state machines each comprising a group 121 of connected, mutually exclusive states. Only one state of each 122 machine can be active at any given time. 124 All permissible transitions between states are represented by 125 arrows, the arrowhead denoting the direction of the possible 126 transition. Labels attached to arrows denote the condition(s) 127 that must be met in order for the transition to take place. All 128 conditions are expressions that evaluate to TRUE or FALSE; if a 129 condition evaluates to TRUE, then the condition is met. The label 130 UCT denotes an unconditional transition (i.e., UCT always 131 evaluates to TRUE). A transition that is global in nature (i.e., 132 a transition that occurs from any of the possible states if the 133 condition attached to the arrow is met) is denoted by an open 134 arrow; i.e., no specific state is identified as the origin of the 135 transition. When the condition associated with a global 136 transition is met, it supersedes all other exit conditions 137 including UCT. The special global condition BEGIN supersedes all 138 other global conditions, and once asserted remains asserted until 139 all state blocks have executed to the point that variable 140 assignments and other consequences of their execution remain 141 unchanged. 143 On entry to a state, the procedures defined for the state (if any) 144 are executed exactly once, in the order that they appear on the 145 page. Each action is deemed to be atomic; i.e., execution of a 146 procedure completes before the next sequential procedure starts to 147 execute. No procedures execute outside of a state block. The 148 procedures in only one state block execute at a time, even if the 149 conditions for execution of state blocks in different state 150 machines are satisfied, and all procedures in an executing state 151 block complete execution before the transition to and execution of 152 any other state block occurs, i.e., the execution of any state 153 block appears to be atomic with respect to the execution of any 154 other state block and the transition condition to that state from 155 the previous state is TRUE when execution commences. The order of 156 execution of state blocks in different state machines is undefined 157 except as constrained by their transition conditions. A variable 158 that is set to a particular value in a state block retains this 159 value until a subsequent state block executes a procedure that 160 modifies the value. 162 On completion of all of the procedures within a state, all exit 163 conditions for the state (including all conditions associated with 164 global transitions) are evaluated continuously until one of the 165 conditions is met. The label ELSE denotes a transition that 166 occurs if none of the other conditions for transitions from the 167 state are met (i.e., ELSE evaluates to TRUE if all other possible 168 exit conditions from the state evaluate to FALSE). Where two or 169 more exit conditions with the same level of precedence become TRUE 170 simultaneously, the choice as to which exit condition causes the 171 state transition to take place is arbitrary. 173 In addition to the above notation, there are a couple of 174 clarifications specific to this document. First, all boolean 175 variables are initialized to FALSE before the state machine execution 176 begins. Second, the following notational shorthand is specific to 177 this document: 179 = | | ... 180 Execution of a statement of this form will result in 181 having a value of exactly one of the expressions. The logic for 182 which of those expressions gets executed is outside of the state 183 machine and could be environmental, configurable, or based on 184 another state machine such as that of the method. 186 4. State Machine Symbols 188 ( ) Used to force the precedence of operators in Boolean expressions 189 and to delimit the argument(s) of actions within state boxes. 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 language conventions for reading 193 text. 194 = Assignment action. The value of the expression to the right of 195 the operator is assigned to the variable to the left of the 196 operator. Where this operator is used to define multiple 197 assignments, e.g., a = b = X the action causes the value of the 198 expression following the right-most assignment operator to be 199 assigned to all of the variables that appear to the left of the 200 right-most assignment operator. 201 ! Logical NOT operator. 202 && Logical AND operator. 203 || Logical OR operator. 204 if...then... Conditional action. If the Boolean expression 205 following the if evaluates to TRUE, then the action following the 206 then is executed. 207 \{ statement 1, ... statement N \} Compound statement. Braces are 208 used to group statements that are executed together as if they 209 were a single statement. 210 != Inequality. Evaluates to TRUE if the expression to the left of 211 the operator is not equal in value to the expression to the right. 212 == Equality. Evaluates to TRUE if the expression to the left of the 213 operator is equal in value to the expression to the right. 214 > Greater than. Evaluates to TRUE if the value of the expression to 215 the left of the operator is greater than the value of the 216 expression to the right. 217 <= Less than or equal to. Evaluates to TRUE if the value of the 218 expression to the left of the operator is either less than or 219 equal to the value of the expression to the right. 220 ++ Increment the preceding integer operator by 1. 222 5. Common Rules 224 Throughout the document we use terms defined in the [1], such as flow 225 sender, flow receiver, QUERY, RESERVE or RESPONSE. 227 5.1 Common Procedures 229 tx_RESERVE(Toff): Transmit RESERVE message with 'Teardown' bit off 230 tx_RESERVE(Ton): Transmit RESERVE message with 'Teardown' bit on 231 tx_RESPONSE(): Transmit RESPONSE message 232 tx_QUERY(w/RII): Transmit QUERY message with Request Identification 233 Information (RII) object 234 tx_QUERY(w/oRII): Transmit QUERY message without RII object 235 rx_RESPONSE(): Receive RESPONSE message 236 rx_QUERY(): Receive QUERY message 237 rx_RESERVE(): Receive RESERVE message 238 TIMEOUT_State: State lifetime timer expiration 239 TIMEOUT_Refresh: Refresh interval timer expiration 240 tg_QUERY: External trigger to send a QUERY message (typically 241 triggered by the application). 242 tg_RESERVE: External trigger to send a RESERVE message. 243 tg_TEARDOWN: External trigger to clear previously established QoS 244 state (typically triggered by the application). It is translated 245 to a tx_RESERVE(Ton) message. 246 Set QoS state: establish the local QoS state. 247 Refresh QoS state: refresh the local QoS state. 248 Clear QoS state: delete the local QoS state. 249 Send info to Application: report information to the application. 250 RMF: Performs Resource Management Function and returns the following 251 values{AVAIL, NO_AVAIL}. 252 SetRII: Sets the RII object of the messages e.g. the node requests 253 explicit response to the message being sent. Returns values 254 {0,1}. 255 CheckRII: Checks the RII object of received RESPONSE message if it is 256 requested by current node or other upstream node. Returns values 257 {LOCAL, NO_LOCAL}. 258 Result: Processes the information of the RESPONSE messages and 259 provides information. It tells whether the reservation is 260 successful or not (if it is a response to a reserve message), or 261 the information carried in the response message (if it is a 262 response to a query message), or an error has occurred. Returns 263 values {INFO, SUCCESSFUL, ERROR}. 265 5.2 Common Variables 266 RII: Request Identification Information (RII) object. Logical 267 variable representing if the RII is set or not. Takes values 268 {0,1}. 269 SCOPING: Scoping flag of common message header. Takes values 270 {"Next_hop","Whole_path"}. 272 5.3 Constants 273 6. State machine for first QoS NSLP node in the flow path 275 ----------- 276 State: INIT 277 ----------- 279 Condition Action State 280 ------------------------+-------------------------+------------ 281 UCT | initialize variables |IDLE 282 ------------------------+-------------------------+------------ 284 ----------- 285 State: IDLE 286 ----------- 288 Condition Action State Note 289 ------------------------+-------------------------+-----------+--- 290 (rx_QUERY) && (!RII) && |tx_NOTIFY(ERROR) |IDLE |1) 291 (RMF="NO_AVAIL") | | |2) 292 | | | 293 (rx_QUERY) && (RII) |tx_RESPONSE(w/RII) |IDLE | 294 | | | 295 (tg_RESERVE) && |Send info to Application |IDLE | 296 (RMF="NO_AVAIL") | | | 297 | | | 298 (tg_QUERY) && (setRII) |tx_QUERY(w/RII) |WAITRESP1 | 299 | | | 300 (tg_RESERVE) && (RII) &&|tx_RESERVE(w/RII) |WAITRESP2 | 301 (RMF="AVAIL") | | | 302 | | | 303 (rx_QUERY) && (!RII) && |tx_RESERVE(w/RII) |WAITRESP2 |2) 304 (setRII) && | | | 305 (RMF="AVAIL") | | | 306 | | | 307 (rx_QUERY) && (!RII) && |tx_RESERVE(w/oRII), |ESTABLISHED|2) 308 (!setRII) && | Set QoS state, | | 309 (RMF="AVAIL") | Send info to Application| | 310 | | | 311 (tg_RESERVE) && |tx_RESERVE(w/oRII), |ESTABLISHED| 312 (!setRII) && | Set QoS state, | | 313 (RMF="AVAIL") | Send info to Application| | 314 ------------------------+-------------------------+-----------+--- 316 Note: 1) tx_NOTIFY(ERROR) is transmitted when an ERROR event must 317 be announced to other downstream nodes which do not expect 318 a RESPONSE message for this action. E.g., there is no provided 319 RII which will be included in a RESPONSE message; 320 2) Relevant for Receiver-initiated reservation. 322 ---------------- 323 State: WAITRESP1 324 ---------------- 326 Condition Action State 327 ------------------------+-------------------------+------------ 328 (TIMEOUT_Refresh) && |tx_RESERVE(w/RII) |WAITRESP1 329 (!MaxRetry) | | 330 | | 331 (TIMEOUT_Refresh) && |Send info to Application |IDLE 332 (MaxRetry) | | 333 | | 334 rx_RESPONSE |Send info to Application |IDLE 335 ------------------------+-------------------------+------------ 337 ------------------ 338 State: ESTABLISHED 339 ------------------ 341 Condition Action State 342 ------------------------+-------------------------+------------ 343 TIMEOUT_Refresh |tx_RESERVE |ESTABLISHED 344 | | 345 tg_TEARDOWN |tx_RESERVE(Ton), |IDLE 346 | Clear QoS state | 347 ------------------------+-------------------------+------------ 348 ---------------- 349 State: WAITRESP2 350 ---------------- 352 Condition Action State 353 ------------------------+-------------------------+------------ 354 (TIMEOUT_Refresh) && |tx_RESERVE(w/RII) |WAITRESP2 355 (!MaxRetry) | | 356 | | 357 (TIMEOUT_Refresh) && |Send info to Application |IDLE 358 (MaxRetry) | | 359 | | 360 (rx_RESPONSE) && |Send info to Application |IDLE 361 (Result="ERROR") | | 362 | | 363 (rx_RESPONSE) && |Set QoS state, |ESTABLISHED 364 (Result="SUCCESS")&& | Send info to Application| 365 (RMF="AVAIL") | | 366 ------------------------+-------------------------+------------ 368 7. State machine for intermediate QoS NSLP nodes 370 ----------- 371 State: INIT 372 ----------- 374 Condition Action State 375 ------------------------+-------------------------+------------ 376 UCT | initialize variables |IDLE 377 ------------------------+-------------------------+------------ 379 ----------- 380 State: IDLE 381 ----------- 383 Condition Action State Note 384 ------------------------+-------------------------+-----------+--- 385 (rx_RESERVE)&& !((RII)&&|Set QoS state, |ESTABLISHED|1a) 386 (setRII)) && | tx_RESERVE(w/oRII) | | 387 (RMF="AVAIL") | | | 388 | | | 389 (rx_RESERVE) && (RII) &&|Set QoS state, |ESTABLISHED|1b) 390 (RMF="AVAIL") && | tx_RESPONSE(w/RII) | | 391 (SCOPING="Next_hop") | | | 392 | | | 393 (rx_RESERVE) && (!RII)&&|Set QoS state |ESTABLISHED|1b) 394 (RMF="AVAIL") && | | | 395 (SCOPING="Next_hop") | | | 396 | | | 397 (rx_QUERY) && (!RII) |tx_QUERY(w/oRII) |IDLE |2) 398 | | | 399 (rx_QUERY) && |tx_QUERY(w/RII) |IDLE | 400 (SCOPING="Next_hop") | | | 401 | | | 402 (rx_RESERVE) && (RII)&& |tx_RESPONSE(RII, ERROR) |IDLE |3) 403 (RMF="NO_AVAIL") | | | 404 | | | 405 (rx_RESERVE) && (!RII)&&|tx_NOTIFY(ERROR) |IDLE |3) 406 (RMF="NO_AVAIL") | | | 407 | | | 408 (rx_RESERVE) && ((RII)|||tx_RESERVE(w/RII) |WAITRESP1 |4) 409 (setRII)) && | | | 410 (RMF="AVAIL") | | | 411 | | | 412 (rx_QUERY) && (RII) |tx_QUERY(w/RII) |WAITRESP2 |5) 413 | | | 415 (tg_QUERY) && (setRII) |tx_QUERY(w/RII) |WAITRESP2 |5) 416 ------------------------+-------------------------+-----------+--- 418 ------------------ 419 State: ESTABLISHED 420 ------------------ 422 Condition Action State 423 ------------------------+-------------------------+------------ 424 rx_RESERVE(Ton) |tx_RESERVE(Ton), |IDLE 425 | clear QoS state | 426 | | 427 TIMEOUT_Refresh |Refresh QoS state; |ESTABLISHED 428 | if state changes, | 429 | tx_RESERVE(w/RII) | 430 | | 431 TIMEOUT_State |Clear QoS state |IDLE 432 ------------------------+-------------------------+------------ 433 ---------------- 434 State: WAITRESP1 435 ---------------- 437 Condition Action State 438 ------------------------+-------------------------+------------ 439 (TIMEOUT_Refresh) && |tx_RESERVE(w/RII) |WAITRESP1 440 (!MaxRetry) | Send info to Application| 441 | | 442 (TIMEOUT_Refresh) && |tx_NOTIFY(ERROR), | 443 (MaxRetry) && | Send info to Application|IDLE 444 (CheckRII="LOCAL") | | 445 | | 446 (TIMEOUT_Refresh) && |tx_RESPONSE(w/RII,Result=| 447 (MaxRetry) && | "ERROR") |IDLE 448 (CheckRII="NO_LOCAL")| | 449 | | 450 (rx_RESPONSE) && |Set QoS state |ESTABLISHED 451 (CheckRII="LOCAL")&& | | 452 (Result="SUCCESS") | | 453 | | 454 (rx_RESPONSE) && |Set QoS state, |ESTABLISHED 455 (CheckRII="NO_LOCAL")| tx_RESPONSE(RII) | 456 &&(Result="SUCCESS") | | 457 | | 458 (rx_RESPONSE) && |tx_NOTIFY(ERROR), |IDLE 459 (CheckRII="LOCAL")&& | send info to Application| 460 (Result="ERROR") | | 461 | | 462 (rx_RESPONSE) && |tx_RESPONSE(w/RII) |IDLE 463 (CheckRII="NO_LOCAL")| | 464 &&(Result="ERROR") | | 465 ------------------------+-------------------------+------------- 466 ---------------- 467 State: WAITRESP2 468 ---------------- 470 Condition Action State 471 ------------------------+-------------------------+------------ 472 (TIMEOUT_Refresh) && |tx_QUERY(w/RII) |WAITRESP2 473 (!MaxRetry) | | 474 | | 475 (TIMEOUT_Refresh) && |Send info to Application |IDLE 476 (MaxRetry) && | | 477 (CheckRII="LOCAL") | | 478 | | 479 (TIMEOUT_Refresh) && |tx_RESPONSE(Result= |IDLE 480 (MaxRetry) && | "ERROR") | 481 (CheckRII="NO_LOCAL")| | 482 | | 483 (rx_RESPONSE) && |Send info to Application |IDLE 484 (CheckRII="LOCAL") | | 485 | | 486 (rx_RESPONSE) && |tx_RESPONSE(w/RII) |IDLE 487 (CheckRII="NO_LOCAL")| | 488 ------------------------+-------------------------+------------- 490 Note: 1) Successful reservation with response request (1a) and 491 with Scoping (1b); 492 2) Processing of Query msg for Receiver initiated 493 reservation; 494 3) Unsuccessful reservation for Receiver initiated 495 reservation, with/without request for response from the flow 496 sender side. Tx_NOTIFY(ERROR) is sent to the upstream nodes to 497 indicate failure of the reservation in the case when no RESPONSE 498 is required by them; 499 4) Reservation requests with RII set in the upstream nodes 500 or in this node; 501 5) Processing of Query message received from a neighboring 502 node or triggered by the application layer. 504 8. State machine for last QoS NSLP node in the flow path 506 ----------- 507 State: INIT 508 ----------- 510 Condition Action State 511 ------------------------+-------------------------+------------ 512 UCT | initialize variables |IDLE 513 ------------------------+-------------------------+------------ 515 ----------- 516 State: IDLE 517 ----------- 519 Condition Action State Note 520 ------------------------+-------------------------+-----------+--- 521 (tg_QUERY) && |tx_QUERY(w/RII) |WAITRESV |1) 522 (!setRII) | | | 523 | | | 524 (rx_RESERVE) && (RII) &&|Set QoS state, |ESTABLISHED|2a) 525 (RMF="AVAIL") | tx_RESPONSE(w/RII) | | 526 | | | 527 (rx_RESERVE) && (!RII)&&|Set QoS state |ESTABLISHED|2b) 528 (RMF="AVAIL") | | | 529 | | | 530 (tg_RESERVE) && |Send info to Application |IDLE |3) 531 (RMF="NO_AVAIL") | | | 532 | | | 533 (rx_RESPONSE) && (RII)&&|tx_RESPONSE(RII, ERROR) |IDLE | 534 (RMF="NO_AVAIL") | | | 535 | | | 536 (rx_QUERY) && (RII) && |tx_QUERY(w/RII) |IDLE | 537 ------------------------+-------------------------+-----------+--- 539 ------------------ 540 State: ESTABLISHED 541 ------------------ 543 Condition Action State 544 ------------------------+-------------------------+------------ 545 rx_RESERVE |Refresh QoS state |ESTABLISHED 546 | | 547 TIMEOUT_State |Clear QoS state |IDLE 548 ------------------------+-------------------------+------------ 549 --------------- 550 State: WAITRESV 551 --------------- 553 Condition Action State Note 554 ------------------------+-------------------------+-----------+--- 555 (rx_RESPONSE) && |Send info to Application |IDLE | 556 (Result="ERROR") | | | 557 | | | 558 (rx_RESERVE) && (!RII)&&|Set QoS state |ESTABLISHED|2) 559 (RMF="AVAIL") | | | 560 | | | 561 (rx_RESERVE) && (RII)&& |Set QoS state, |ESTABLISHED|2) 562 (RMF="AVAIL") | tx_RESPONSE(w/RII) | | 563 (rx_RESERVE) && (RII) &&|tx_NOTIFY(ERROR), |IDLE |4) 564 (RMF="NO_AVAIL") | Send info to Application| | 565 | | | 566 (rx_RESERVE) && (!RII)&&|tx_RESPONSE(RII,ERROR), |IDLE |4) 567 (RMF="NO_AVAIL") | Send info to Application| | 568 ------------------------+-------------------------+-----------+--- 570 Note: 1) Initiation of receiver-side reservation; 571 2) Successful reservation with&without response request from 572 sender side; 573 3) In case of no response requested (RII not present in 574 RESERVE message), NOTIFY(ERROR) message is sent back to the 575 upstream nodes in order to clear already established QoS state; 576 4) Unsuccessful reservation with&without response request 577 from sender side; 579 9. Security Considerations 581 This document does not raise new security considerations. Any 582 security concerns with the QoS NSLP are likely reflected in security 583 related NSIS work already (such as [1] or [6]). 585 For the time being, the state machines described in this document do 586 not consider the security aspect of QoS NSLP protocol itself. A 587 future versions of this document will add security relevant states 588 and state transitions. 590 10. Open Issues 592 This document tries to describe possible states and transitions for 593 QoS NSLP according to its current specification [1], Section 5. We 594 found some issues during the development of the state machines. For 595 example, for receiver-initiated reservation, it is unclear who 596 triggers a teardown; bi-directional reservation is difficult to 597 support as the state machine becomes quite complex (note at one 598 particular point in time the protocol state engine can be only in one 599 state). Another example is, it is often ignored for the 600 functionality of abort operation after a defined MaxRetry number of 601 retries. Results of this type of transitions are dependent on the 602 parameter RII (e.g., if it is locally set or not). 604 There are further unclear issues with processing rules and message 605 definition, e.g., soft state handling and how to process notification 606 messages, which will be described in more detail in a future version 607 of this document. 609 To avoid confusions in state machines, instead of QNI, QNE and QNR, 610 in this document we use the notations of "first QoS NSLP node in the 611 flow path" (the closest one to the flow sender or the flow sender 612 itself), "intermediate QoS NSLP nodes" and "last QoS NSLP node in the 613 flow path" (the closest one to the flow receiver or the flow receiver 614 itself). 616 Default rules and common state transitions in case of reception of 617 certain messages as Notify, and Query(w/RII), will be described in a 618 future version of this document. 620 11. Acknowledgments 622 The authors would like to thank Sven Van den Bosch for his feedback. 624 12. References 626 12.1 Normative References 628 [1] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 629 Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04 (work 630 in progress), July 2004. 632 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 633 Levels", March 1997. 635 12.2 Informative References 637 [3] Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, "State 638 Machines for Extensible Authentication Protocol (EAP) Peer and 639 Authenticator", draft-ietf-eap-statemachine-05 (work in 640 progress), September 2004. 642 [4] Institute of Electrical and Electronics Engineers, "DRAFT 643 Standard for Local and Metropolitan Area Networks: Port-Based 644 Network Access Control (Revision)", IEEE 802-1X-REV/D9, January 645 2004. 647 [5] Ohba, Y., "State Machines for Protocol for Carrying 648 Authentication for Network Access (PANA)", 649 draft-ohba-pana-statemachine-00 (work in progress), July 2004. 651 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 652 draft-ietf-nsis-threats-06 (work in progress), October 2004. 654 Authors' Addresses 656 Xiaoming Fu 657 University of Goettingen 658 Telematics Group 659 Lotzestr. 16-18 660 Goettingen 37083 661 Germany 663 EMail: fu@cs.uni-goettingen.de 664 Hannes Tschofenig 665 Siemens 666 Otto-Hahn-Ring 6 667 Munich, Bayern 81739 668 Germany 670 EMail: Hannes.Tschofenig@siemens.com 672 Tseno Tsenov 673 Siemens 674 Otto-Hahn-Ring 6 675 Munich, Bayern 81739 676 Germany 678 EMail: tseno.tsenov@mytum.de 680 Intellectual Property Statement 682 The IETF takes no position regarding the validity or scope of any 683 Intellectual Property Rights or other rights that might be claimed to 684 pertain to the implementation or use of the technology described in 685 this document or the extent to which any license under such rights 686 might or might not be available; nor does it represent that it has 687 made any independent effort to identify any such rights. Information 688 on the procedures with respect to rights in RFC documents can be 689 found in BCP 78 and BCP 79. 691 Copies of IPR disclosures made to the IETF Secretariat and any 692 assurances of licenses to be made available, or the result of an 693 attempt made to obtain a general license or permission for the use of 694 such proprietary rights by implementers or users of this 695 specification can be obtained from the IETF on-line IPR repository at 696 http://www.ietf.org/ipr. 698 The IETF invites any interested party to bring to its attention any 699 copyrights, patents or patent applications, or other proprietary 700 rights that may cover technology that may be required to implement 701 this standard. Please address the information to the IETF at 702 ietf-ipr@ietf.org. 704 Disclaimer of Validity 706 This document and the information contained herein are provided on an 707 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 708 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 709 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 710 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 711 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 712 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 714 Copyright Statement 716 Copyright (C) The Internet Society (2004). This document is subject 717 to the rights, licenses and restrictions contained in BCP 78, and 718 except as set forth therein, the authors retain all their rights. 720 Acknowledgment 722 Funding for the RFC Editor function is currently provided by the 723 Internet Society.