idnits 2.17.00 (12 Aug 2021) /tmp/idnits46137/draft-fu-nsis-qos-nslp-statemachine-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 861. ** 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.) ** 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 755: '... RESERVE message MUST be sent only tow...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** 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 (February 21, 2005) is 6298 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: draft-ietf-nsis-threats has been published as RFC 4081 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS X. Fu 3 Internet-Draft Univ. Goettingen 4 Expires: August 25, 2005 H. Tschofenig 5 T. Tsenov 6 Siemens 7 February 21, 2005 9 QoS NSLP State Machine 10 draft-fu-nsis-qos-nslp-statemachine-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 25, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document describes the state machines for the NSIS Signaling 46 Layer Protocol for Quality-of-Service signaling (QoS NSLP). A set of 47 state machines for QoS NSLP entities at different locations of a flow 48 path are presented in order to illustrate how QoS NSLP may be 49 implemented. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Notational conventions used in state diagrams . . . . . . . 5 56 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 7 57 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8 59 5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 8 60 5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. State machine for QNI QoS NSLP node . . . . . . . . . . . . 10 63 7. State machine for QNE QoS NSLP nodes . . . . . . . . . . . . 13 64 8. State machine for QNR QoS NSLP node . . . . . . . . . . . . 17 65 9. Security Considerations . . . . . . . . . . . . . . . . . . 20 66 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 21 67 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 22 68 11.1 Changes in Version -01 . . . . . . . . . . . . . . . . . 22 69 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 71 13.1 Normative References . . . . . . . . . . . . . . . . . . 24 72 13.2 Informative References . . . . . . . . . . . . . . . . . 24 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 74 Intellectual Property and Copyright Statements . . . . . . . 26 76 1. Introduction 78 This document describes the state machines for QoS NSLP [1], trying 79 to show how QoS NSLP can be implemented to support its deployment. 80 The state machines described in this document are illustrative of how 81 the QoS NSLP protocol defined in [1] may be implemented for the QNI 82 QoS NSLP node, QNE QoS NSLP nodes, and QNR QoS NSLP node in the flow 83 path. Where there are differences [1] are authoritative. The state 84 machines are informative only. Implementations may achieve the same 85 results using different methods. 87 According to [1], there are several possibilities for QoS NSLP 88 signaling, at least including the following: 89 end-to-end signaling vs. scoped signaling 90 sender-initiated signaling vs. receiver-initiated signaling 91 (which need to be incorporated into use scenarios when describing 92 state machine. Note they are represented by way of certain 93 objects/flags in Reserve and Query messages.) 95 The messages used in the QoS NSLP protocol can be summarized as 96 follows: 98 Requesting message Responding message 99 ------------------------+--------------------------- 100 RESERVE |None or RESERVE or RESPONSE 101 QUERY |RESERVE or RESPONSE 102 RESPONSE |NONE 103 NOTIFY |NONE 104 ------------------------+--------------------------- 106 We describe a set of state machines for different roles of entities 107 running QoS NSLP to illustrate how QoS NSLP may be implemented. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [2]. 115 3. Notational conventions used in state diagrams 117 The following text is reused from [3] and the state diagrams are 118 based on the conventions specified in [4], Section 8.2.1. Additional 119 state machine details are taken from [5]. 121 The complete text is reproduced here: 123 State diagrams are used to represent the operation of the protocol 124 by a number of cooperating state machines each comprising a group 125 of connected, mutually exclusive states. Only one state of each 126 machine can be active at any given time. 128 All permissible transitions between states are represented by 129 arrows, the arrowhead denoting the direction of the possible 130 transition. Labels attached to arrows denote the condition(s) 131 that must be met in order for the transition to take place. All 132 conditions are expressions that evaluate to TRUE or FALSE; if a 133 condition evaluates to TRUE, then the condition is met. The label 134 UCT denotes an unconditional transition (i.e., UCT always 135 evaluates to TRUE). A transition that is global in nature (i.e., 136 a transition that occurs from any of the possible states if the 137 condition attached to the arrow is met) is denoted by an open 138 arrow; i.e., no specific state is identified as the origin of the 139 transition. When the condition associated with a global 140 transition is met, it supersedes all other exit conditions 141 including UCT. The special global condition BEGIN supersedes all 142 other global conditions, and once asserted remains asserted until 143 all state blocks have executed to the point that variable 144 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 149 page. Each action is deemed to be atomic; i.e., execution of a 150 procedure completes before the next sequential procedure starts to 151 execute. No procedures execute outside of a state block. The 152 procedures in only one state block execute at a time, even if the 153 conditions for execution of state blocks in different state 154 machines are satisfied, and all procedures in an executing state 155 block complete execution before the transition to and execution of 156 any other state block occurs, i.e., the execution of any state 157 block appears to be atomic with respect to the execution of any 158 other state block and the transition condition to that state from 159 the previous state is TRUE when execution commences. The order of 160 execution of state blocks in different state machines is undefined 161 except as constrained by their transition conditions. A variable 162 that is set to a particular value in a state block retains this 163 value until a subsequent state block executes a procedure that 164 modifies the value. 166 On completion of all of the procedures within a state, all exit 167 conditions for the state (including all conditions associated with 168 global transitions) are evaluated continuously until one of the 169 conditions is met. The label ELSE denotes a transition that 170 occurs if none of the other conditions for transitions from the 171 state are met (i.e., ELSE evaluates to TRUE if all other possible 172 exit conditions from the state evaluate to FALSE). Where two or 173 more exit conditions with the same level of precedence become TRUE 174 simultaneously, the choice as to which exit condition causes the 175 state transition to take place is arbitrary. 177 In addition to the above notation, there are a couple of 178 clarifications specific to this document. First, all boolean 179 variables are initialized to FALSE before the state machine execution 180 begins. Second, the following notational shorthand is specific to 181 this document: 183 = | | ... 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 ( ) Used to force the precedence of operators in Boolean expressions 193 and to delimit the argument(s) of actions within state boxes. 194 ; Used as a terminating delimiter for actions within state boxes. 195 Where a state box contains multiple actions, the order of 196 execution follows the normal language conventions for reading 197 text. 198 = Assignment action. The value of the expression to the right of 199 the operator is assigned to the variable to the left of the 200 operator. Where this operator is used to define multiple 201 assignments, e.g., a = b = X the action causes the value of the 202 expression following the right-most assignment operator to be 203 assigned to all of the variables that appear to the left of the 204 right-most assignment operator. 205 ! Logical NOT operator. 206 && Logical AND operator. 207 || Logical OR operator. 208 if...then... Conditional action. If the Boolean expression 209 following the if evaluates to TRUE, then the action following the 210 then is executed. 211 \{ statement 1, ... statement N \} Compound statement. Braces are 212 used to group statements that are executed together as if they 213 were a single statement. 214 != Inequality. Evaluates to TRUE if the expression to the left of 215 the operator is not equal in value to the expression to the right. 216 == Equality. Evaluates to TRUE if the expression to the left of the 217 operator is equal in value to the expression to the right. 218 > Greater than. Evaluates to TRUE if the value of the expression to 219 the left of the operator is greater than the value of the 220 expression to the right. 221 <= Less than or equal to. Evaluates to TRUE if the value of the 222 expression to the left of the operator is either less than or 223 equal to the value of the expression to the right. 224 ++ Increment the preceding integer operator by 1. 226 5. Common Rules 228 Throughout the document we use terms defined in the [1], such as flow 229 sender, flow receiver, QUERY, RESERVE or RESPONSE. 231 5.1 Common Procedures 233 tx_RESERVE(Toff): Transmit RESERVE message with 'Teardown' bit off 234 tx_RESERVE(Ton): Transmit RESERVE message with 'Teardown' bit on 235 tx_RESPONSE(): Transmit RESPONSE message 236 tx_QUERY(): Transmit QUERY message with 237 tx_QUERY(w/o): Transmit QUERY message without 238 tx_NOTIFY(): Transmit NOTIFY message 239 rx_RESPONSE(): Receive RESPONSE message 240 rx_QUERY(): Receive QUERY message 241 rx_RESERVE(): Receive RESERVE message 242 rx_NOTIFY(): Transmit NOTIFY message 243 TIMEOUT_StateLifetime: State lifetime timer expiration 244 TIMEOUT_Refresh: Refresh interval timer expiration 245 TIMEOUT_Refresh: Wait-Response interval timer expiration 246 tg_QUERY: External trigger to send a QUERY message (typically 247 triggered by the application). 248 tg_RESERVE: External trigger to send a RESERVE message. 249 tg_TEARDOWN: External trigger to clear previously established QoS 250 state (typically triggered by the application). It is translated 251 to a tx_RESERVE(Ton) message. 252 Install QoS state: Install the local QoS state. 253 Refresh QoS state: Refresh the local QoS state. 254 Delete QoS state: Delete the local QoS state. 255 Send info to Application: Report information to the application. 256 RMF: Performs Resource Management Function and returns the following 257 values{AVAIL, NO_AVAIL}. 258 SetRII: Sets the RII object of the messages e.g. the node requests 259 explicit response to the message being sent. Returns values 260 {0,1}. 261 CheckRII: Checks the RII object of received RESPONSE message if it is 262 requested by current node or other upstream node. Returns values 263 {LOCAL, NO_LOCAL}. 264 ProcessQUERY: Processes a Query message and provides the requested 265 info 267 5.2 Common Variables 269 RII: Request Identification Information (RII) object. Logical 270 variable representing if the RII is set or not. Takes values 271 {0,1}. 273 SCOPING: Scoping flag of common message header. Takes values 274 {"Next_hop","Whole_path"}. 275 RSN: Reservation Sequence Number object. Takes values: 276 - recRSN - RSN object of the received message 277 - currRSN - Current stored RSN value for installed QoS state. 278 (Assumed to be the one for the direction where the message comes 279 from e.g.Upstream/Downstream) 280 ACK: Acknowledgement flag of common message header. Takes values 281 {"On","Off"}. 282 SummaryRefresh: Keeps information if Summary refresh method may be 283 used for refreshing a installed QoS state. Takes value 284 {"On","Off"}. 285 E_SPEC: Error_Spec object. Takes values: 286 - 0x02? - Success values 287 - 0x04? - Transient Failure values 288 - ERROR - Not specified in the QoS NSLP draft, but used 289 here.(Section 10) 290 QSPEC: QoS specification object. 291 FlowID: Flow ID kept by the installed QoS state. 292 Replace: Replace flag of common message header. Takes values 293 {"On","Off"}. 294 SII: Source Identification Information entry. Takes values: 295 - CurrSII - SII entry stored for current installed QoS state. 296 (Assumed to be the one for the direction where the message comes 297 from e.g.Upstream/Downstream) 298 - newSII - SII of the received message is different from the SII 299 stored for the current installed QoS state. 301 5.3 Constants 303 5.4 Assumptions 305 o For simplification not all included objects in a message are 306 showed. Only those that are significant for the case are showed. 307 State machines do not present handling of messages that are not 308 significant for management of the states such as certain NOTIFY 309 and QUERY messages. 310 o State machines represent handling of messages of the same Session 311 ID and with no protocol errors. Separate parallel instances of 312 the state machines should handle messages for different Session 313 IDs. 314 o Default message handling should be defined for messages with 315 different Session IDs that have impact on current session state 316 and error messages. This is not included in the current version. 317 o ACK flag in the common header is set "On" by default. 318 o Direction of receiving and sending messages is not specified. We 319 assume it is implicit from the context. 321 6. State machine for QNI QoS NSLP node 323 ----------- 324 State: INIT 325 ----------- 327 Condition Action State 328 ------------------------+-------------------------+------------ 329 UCT | initialize variables |IDLE 330 ------------------------+-------------------------+------------ 332 ----------- 333 State: IDLE 334 ----------- 336 Condition Action State Note 337 ------------------------+-------------------------+-----------+--- 338 rx_QUERY(RII) |ProcessQUERY |IDLE | 339 |tx_RESPONSE(RII) | | 340 | | | 341 (tg_RESERVE) && |Send info to Application |IDLE | 342 (RMF="NO_AVAIL") | | | 343 | | | 344 (tg_RESERVE) && (!RII) |tx_RESERVE(w/oRII), |QoS state | 345 && (!setRII) && | Install QoS state, |Installed | 346 (RMF="AVAIL") | Send info to Application| | 347 | | | 348 (tg_RESERVE) && (setRII)|Install QoS state, |QoS state | 349 &&(RMF="AVAIL") | tx_RESERVE(RII) |Installed +| 350 | |WAITRESP2 | 351 | | | 352 (rx_QUERY)&&(!RII)&& |Tx_RESPONSE(RSN, |IDLE |1) 353 (RMF="NO_AVAIL") | E_SPEC="ERROR") | |2) 354 | | | 355 (rx_QUERY) && (!RII) && |tx_RESERVE(w/oRII), |QoS state |2) 356 (!setRII) && | Install QoS state, |Installed | 357 (RMF="AVAIL") | Send info to Application| | 358 | | | 359 (rx_QUERY) && (!RII) && |Install QoS state, |QoS state |2) 360 (setRII) && |tx_RESERVE( RII) |Installed +| 361 (RMF="AVAIL") | |WAITRESP2 | 362 | | | 363 (tg_QUERY) && (setRII) |tx_QUERY(RII) |WAITRESP1 | 364 | | | 365 ------------------------+-------------------------+-----------+--- 366 Note: 367 1) How to signal unsuccessful reservation for Receiver initiated 368 reservation (No RII included; sent Response(RSN) should not be 369 forwarded further than the next peer). No Error_SPEC value 370 specified for this case. 371 2) Relevant for Receiver-initiated reservation. 373 ---------------- 374 State: WAITRESP1 375 ---------------- 377 Condition Action State 378 ------------------------+-------------------------+------------ 379 (TIMEOUT_WaitResp) && |tx_QUERY(RII) |WAITRESP1 380 (!MaxRetry) | | 381 | | 382 (TIMEOUT_WaitResp) && |Send info to Application |IDLE 383 (MaxRetry) | | 384 | | 385 rx_RESPONSE |Send info to Application |IDLE 386 ------------------------+-------------------------+------------ 388 -------------------------------------- 389 State: QoS state installed + WAITRESP2 390 -------------------------------------- 392 Condition Action State 393 ------------------------+-------------------------+------------ 394 (TIMEOUT_WaitResp) && |tx_RESERVE(RII) |QoS state 395 (!MaxRetry) | |installed + 396 | |WAITRESP2 397 | | 398 | | 399 (TIMEOUT_WaitResp) && |Delete QoS state |IDLE 400 (MaxRetry) |Send info to Application | 401 | | 402 rx_RESPONSE(RII, |Delete QoS state |IDLE 403 E_SPEC="0x04?") |Send info to Application | 404 | | 405 | | 406 rx_RESPONSE(RII, |Send info to Application |QoS state 407 E_SPEC="0x02?") |SummaryRefresh="On" |installed 408 ------------------------+-------------------------+------------ 409 -------------------------- 410 State: QoS state installed 411 -------------------------- 413 Condition Action State Note 414 ------------------------+-------------------------+-----------+--- 415 TIMEOUT_Refresh |If (SummaryRefresh="On") |QoS state | 416 | (Tx_RESERVE(RSN)) && |installed | 417 | (SummaryRefresh="Off") | | 418 |Else | | 419 | Tx_RESERVE(RSN,QSPEC); | | 420 | | | 421 rx_RESPONSE(RSN, |SummaryRefresh="On" |QoS state | 422 E_SPEC="0x02?") | |installed | 423 | | | 424 TIMEOUT_StateLifetime |Delete QoS state |IDLE |1) 425 |Send info to Application | | 426 | | | 427 tg_TEARDOWN |Delete QoS state, |IDLE | 428 | tx_RESERVE(Ton) | | 429 | | | 430 rx_NOTIFY(RSN, |Delete QoS state |IDLE | 431 E_SPEC="0x04?") |Send info to Application | | 432 ------------------------+-------------------------+-----------+--- 434 Note: 435 1) If QoS state lifetime expires in QNI, should RESERVE(Ton) 436 be sent downstream the path? 438 7. State machine for QNE QoS NSLP nodes 440 ----------- 441 State: INIT 442 ----------- 444 Condition Action State 445 ------------------------+-------------------------+------------ 446 UCT | initialize variables |IDLE 447 ------------------------+-------------------------+------------ 449 ----------- 450 State: IDLE 451 ----------- 453 Condition Action State Note 454 ------------------------+-------------------------+-----------+--- 455 (rx_QUERY) && (!RII) |tx_QUERY(w/oRII) |IDLE |2) 456 | | | 457 (rx_QUERY(RII, |ProcessQUERY, |IDLE |7) 458 SCOPING="Next_hop") |Tx_RESPONSE(RII) | | 459 | | | 460 (rx_QUERY) && (RII) |tx_QUERY(w/RII) |IDLE |7) 461 | | | 462 (rx_RESERVE(RII)) && |Tx_RESPONSE(RII, |IDLE |3) 463 (RMF="NO_AVAIL") | E_SPEC="0x04?") | | 464 | | | 465 (rx_RESERVE) && (!RII)&&|Tx_RESPONSE(RSN, |IDLE |3) 466 (RMF="NO_AVAIL") | E_SPEC="0x04?") | | 467 | | | 468 (rx_RESPONSE(RII)) && |Tx_RESPONSE(RII) |IDLE | 469 (CheckRII="Not_LOCAL")| | | 470 | | | 471 (rx_RESERVE)&& !(setRII)|Install QoS state, |QoS State |1a) 472 && (RMF="AVAIL") |If(ACK="On") |Installed | 473 | Tx_RESPONSE(RSN, | | 474 | E_SPEC="0x02?");| | 475 |If(RII) Tx_RESPONSE(RII) | | 476 |Else Tx_RESPONSE(w/oRII)| | 477 | | | 478 (rx_RESERVE(SCOPING= |Install QoS state, |QoS State |1b) 479 "Next_hop")) && |If(RII) Tx_RESPONSE(RII, |Installed | 480 (RMF="AVAIL") | E_SPEC="0x02?") | | 481 |Else Tx_RESPONSE(RSN, | | 482 | E_SPEC="0x02?") | | 483 | | | 485 (rx_RESERVE) && (setRII)|Install QoS state, |QoS State |4) 486 && (RMF="AVAIL") |Tx_RESPONSE(RII), |Installed +| 487 |If(ACK="On") |WAITRESP1 | 488 | Tx_RESPONSE(RSN, | | 489 | E_SPEC="0x02?");| | 490 | | | 491 (tg_QUERY) && (setRII) |tx_QUERY(RII) |WAITRESP2 |5) 492 ------------------------+-------------------------+-----------+--- 494 ---------------- 495 State: QoS State Installed + WAITRESP1 496 ---------------- 498 Condition Action State Note 499 ------------------------+-------------------------+-----------+--- 500 (TIMEOUT_WaitResp) && |tx_RESERVE(RII) |WAITRESP1 | 501 (!MaxRetry) | | | 502 | | | 503 (TIMEOUT_WaitResp) && |Delete QoS State, | | 504 (MaxRetry) && |tx_NOTIFY(RSN, |IDLE | 505 | E_SPEC="0x04?") | | 506 |Send info to Application | | 507 | | | 508 (rx_RESPONSE(RII, |Delete QoS State, |IDLE |4) 509 E_SPEC="0x04?")) |tx_NOTIFY(RSN, | | 510 &&(CheckRII="LOCAL") | E_SPEC="0x04?") | | 511 |Send info to Application | | 512 | | | 513 (rx_RESPONSE(RII, |Send info to Application |QoS State | 514 E_SPEC="0x02?")) |SummaryRefresh="On" |Installed | 515 &&(CheckRII="LOCAL") | | | 516 ------------------------+-------------------------+-----------+--- 518 ---------------- 519 State: WAITRESP2 520 ---------------- 522 Condition Action State Note 523 ------------------------+-------------------------+-----------+--- 524 (TIMEOUT_WaitResp) && |tx_QUERY(RII) |WAITRESP2 | 525 (!MaxRetry) | | | 526 | | | 527 (TIMEOUT_WaitResp) && |Send info to Application |IDLE | 528 (MaxRetry) | | | 529 | | | 530 (rx_RESPONSE) && |Send info to Application |IDLE | 531 (CheckRII="LOCAL") | | | 532 ------------------------+-------------------------+-----------+--- 534 ------------------ 535 State: QoS State Installed 536 ------------------ 538 Condition Action State Note 539 ------------------------+-------------------------+-----------+--- 540 rx_RESERVE(Ton) |tx_RESERVE(Ton), |IDLE | 541 |Delete QoS state | | 542 | | | 543 rx_RESERVE |Refresh QoS state |QoS State |6) 544 |If(ACK="On") |Installed | 545 |Tx_RESPONSE(RSN, | | 546 | E_SPEC="0x02?") | | 547 | | | 548 rx_RESPONSE(RSN, |SummaryRefresh="On" |QoS State |6) 549 E_SPEC="0x02?") | |Installed | 550 | | | 551 TIMEOUT_Refresh |If (SummaryRefresh="On") |QoS State |6) 552 | (Tx_RESERVE(RSN)) |Installed | 553 | &&(SummaryRefresh="Off")| | 554 |Else | | 555 | Tx_RESERVE(RSN,QSPEC) | | 556 | | | 557 (rx_RESPONSE(RII, |SummaryRefresh="On" |QoS State | 558 E_SPEC="0x02?")) |Tx_RESPONSE(RII, |Installed | 559 &&(ChechRII="NOT_LOCAL")| E_SPEC="0x02?") | | 560 | | | 561 | | | 562 (TIMEOUT_StateLifetime) |Delete QoS state |IDLE |8) 563 | | | 564 (rx_RESPONSE(RII, | | | 565 E_SPEC="0x04?")) |Delete QoS state |IDLE | 566 &&(ChechRII="NOT_LOCAL")|rx_RESPONSE(RII, | | 567 | E_SPEC="0x04?") | | 568 | | | 569 rx_RESPONSE(RSN, |Delete QoS state |IDLE | 570 E_SPEC="0x04?") |rx_NOTIFY(RSN, | | 571 | E_SPEC="0x04?") | | 572 | | | 573 rx_NOTIFY(RSN, |Delete QoS state |IDLE | 574 E_SPEC="0x04?") |rx_NOTIFY(RSN, | | 575 | E_SPEC="0x04?") | | 576 | | | 577 | | | 579 (Rx_RESERVE)&&(currSII) |Update QoS state |QoS State |9) 580 &&(Replace="On") |If (RII) |Installed | 581 &&(RMF="AVAIL") | Tx_RESERVE(RII,QSPEC)| | 582 &&((recRSN>=currRSN) |else | | 583 ||(newFlowID)) | Tx_RESERVE(RSN,QSPEC);| | 584 |If (ACK="On")&&(!RII) | | 585 | tx_RESPONSE(RSN, | | 586 | E_SPEC="0x02?");| | 587 | | | 588 | | | 589 (Rx_RESERVE)&&(newSII) |Update QoS state |QoS State |9) 590 &&(RMF="AVAIL") |If (RII) |Installed | 591 &&((recRSN>=currRSN) | Tx_RESERVE(RII,QSPEC)| | 592 ||(newFlowID)) |else | | 593 | Tx_RESERVE(RSN,QSPEC);| | 594 |If (ACK="On")&&(!RII) | | 595 | tx_RESPONSE(RSN, | | 596 | E_SPEC="0x02?");| | 597 |If (Replace="On") | | 598 | tx_Reserve(Ton) | | 599 | to currSII | | 600 ------------------------+-------------------------+-----------+--- 602 NOTE: 603 1) Successful reservation without Response request (1a) and with 604 Scoping (1b). 605 2) Processing of Query msg for Receiver initiated reservation 606 3) Unsuccessful reservation with/without request for response 607 from previous node in the path. 608 4) Unsuccessful reservation. RII requested at the local node. 609 NOTIFY(RSN) is sent further to the upstream nodes. 610 5) Processing of Query msg triggered by the application layer. 611 6) QoS State refresh procedures 612 7) Processing of Query msg received from an upstream node. 613 8) We assume that handling of QoS state lifetime expiration 614 event is based on the local policy of the node. 615 NOTIFY/Reserve(Ton) messages might be sent to other peers. 616 These issues are not described in the QoS NSLP draft. 617 9) Update QoS state and Re-route functionality 619 8. State machine for QNR QoS NSLP node 621 ----------- 622 State: INIT 623 ----------- 625 Condition Action State 626 ------------------------+-------------------------+------------ 627 UCT | initialize variables |IDLE 628 ------------------------+-------------------------+------------ 630 ----------- 631 State: IDLE 632 ----------- 634 Condition Action State Note 635 ------------------------+-------------------------+-----------+--- 636 rx_QUERY(RII) |tx_RESPONSE(RII) |IDLE | 637 | | | 638 (rx_RESERVE)&&(!RII) |Tx_RESPONSE(RSN, |IDLE | 639 && (RMF="NO_A") | E_SPEC="0x04?") | | 640 | | | 641 | | | 642 (rx_RESERVE(RII)) |Tx_RESPONSE(RII, |IDLE | 643 && (RMF="NO_A") | E_SPEC="0x04?") | | 644 | | | 645 (tg_QUERY) && |tx_QUERY(w/oRII) |WAITRESV |1) 646 (!setRII) | | | 647 | | | 648 | | | 649 (rx_RESERVE(RII)) |Install QoS state |QoS state |2) 650 && (RMF="AVAIL") |Tx_RESPONSE(RII, |installed | 651 | E_SPEC="0x02?") | | 652 | | | 653 (rx_RESERVE)&&(!RII) |Install QoS state |QoS state |2) 654 && (RMF="AVAIL") |Tx_RESPONSE(RSN, |installed | 655 E_SPEC="0x02?") | | 656 ------------------------+-------------------------+-----------+--- 657 --------------- 658 State: WAITRESV 659 --------------- 661 Condition Action State Note 662 ------------------------+-------------------------+-----------+--- 663 TIMEOUT_WaitResp |Tx_QUERY(w/oRII) |WAITRESV | 664 | | | 665 (TIMEOUT_WaitResp) |Send info to Appl. |IDLE | 666 && (MaxRetry) | | | 667 | | | 668 (rx_RESERVE)&&(!RII) |tx_RESPONSE(RSN, |IDLE |3) 669 && (RMF="Not_AVAIL") | E_SPEC="0x04?") | | 670 |Send info to Appl. | | 671 | | | 672 (rx_RESERVE(RII)) |tx_RESPONSE(RII, |IDLE |3) 673 && (RMF="Not_AVAIL") | E_SPEC="0x04?") | | 674 |Send info to Appl. | | 675 | | | 676 rx_RESPONSE(E_SPEC= |Send info to Appl. |IDLE |4) 677 "ERROR")| | | 678 | | | 679 | | | 680 (rx_RESERVE)&&(!RII) |Install QoS state |QoS state | 681 && (RMF="AVAIL") |Tx_RESPONSE(RSN, |installed | 682 | E_SPEC="0x02?") | | 683 | | | 684 (rx_RESERVE(RII)) |Install QoS State |QoS state | 685 && (RMF="AVAIL") |Tx_RESPONSE(RII) |installed | 686 | | | 687 ------------------------+-------------------------+-----------+--- 688 ------------------ 689 State: QoS state installed 690 ------------------ 692 Condition Action State Note 693 ------------------------+-------------------------+-----------+--- 694 rx_RESERVE |Refresh QoS state |QoS state | 695 |If(ACK="On") |installed | 696 | Tx_RESPONSE(RSN, | | 697 | E_SPEC="0x02?")| | 698 | | | 699 TIMEOUT_StateLifetime |Delete QoS state |IDLE |5) 700 | | | 701 rx_RESERVE(Ton) |Delete QoS state |IDLE | 702 | | | 703 ------------------------+-------------------------+------------ 705 Note: 706 1) Initiation of Receiver-side reservation 707 2) Successful Reservation with& without response request from the 708 QNI side 709 3) Unsuccessful Reservation with & without response request from 710 the QNI side. 711 4) How to signal unsuccessful reservation for Receiver initiated 712 reservation(No RII is included, received Response(RSN) should 713 not be forwarded. 714 5) We assume that handling of QoS state lifetime expiration event 715 is based on the local policy of the node. NOTIFY/Reserve(Ton) 716 messages might be sent to other peers. These issues are not 717 described in the QoS NSLP draft. 719 9. Security Considerations 721 This document does not raise new security considerations. Any 722 security concerns with the QoS NSLP are likely reflected in security 723 related NSIS work already (such as [1] or [6]). 725 For the time being, the state machines described in this document do 726 not consider the security aspect of QoS NSLP protocol itself. A 727 future versions of this document will add security relevant states 728 and state transitions. 730 10. Open Issues 732 This document tries to describe possible states and transitions for 733 QoS NSLP according to its current specification [1], Section 5. We 734 found some issues during the development of the state machines. 736 o For receiver-initiated reservation, it is unclear who triggers a 737 teardown. 738 o Bi-directional reservation is difficult to support as the state 739 machine becomes quite complex (note at one particular point in 740 time the protocol state engine can be only in one state). 741 o How to signal unsuccessful reservation for Receiver initiated 742 reservation (No RII included; a resulting Response(RSN) cannot be 743 forwarded further than the next peer). No Error_SPEC value 744 specified for this case. 745 o If QoS state lifetime expires in QNI, should RESERVE(Ton) be sent 746 downstream the path? 747 o The case of unsuccessful reservation at a QNE node and no RII 748 specified by upstream nodes. According to the spec RESPONSE(RSN) 749 should not be forwarded further than the next peer. Currently we 750 use NOTIFY(RSN) that is sent further to the upstream nodes. 751 o We assume that handling of QoS state lifetime expiration event is 752 based on the local policy of the node. NOTIFY/Reserve(Ton) 753 messages might be sent to other peers. These issues are not 754 described in the QoS NSLP draft. 755 o The draft states that RESERVE message MUST be sent only towards 756 the QNR. This is not the case when re-routing procedure is done 757 and RESERVE(Ton) message should be sent from merging QNE node for 758 deleting the old branch. We believe this is towards the QNI. 759 o Re-routing functionality described in this document is not 760 complete and need further consideration. 762 11. Change History 764 11.1 Changes in Version -01 766 Version -01 covers more functionalities of the QoS NSLP. This 767 requires addition and changes of the notations. The main details are 768 as follows: 770 1. Notation of the nodes changed to QNI, QNE and QNR. 771 2. Description of soft state refresh functionality. 772 3. Support of ACK flag in the common header. 773 4. Include of QoS NSLP objects, flags from the common header and 774 entries stored with the installed QoS state in a node: ACK, 775 Replace, RSN, Error_SPEC, QSPEQ, FlowID, SII. 776 5. Initial description of Re-routing functionality (Section 10). 777 6. For support of all listed changes, some notations are changed. 779 12. Acknowledgments 781 The authors would like to thank Sven Van den Bosch for his feedback. 783 13. References 785 13.1 Normative References 787 [1] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 788 Quality-of-Service signaling", 789 Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004. 791 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 792 Levels", March 1997. 794 13.2 Informative References 796 [3] Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, "State 797 Machines for Extensible Authentication Protocol (EAP) Peer and 798 Authenticator", Internet-Draft draft-ietf-eap-statemachine-06, 799 December 2004. 801 [4] Institute of Electrical and Electronics Engineers, "DRAFT 802 Standard for Local and Metropolitan Area Networks: Port-Based 803 Network Access Control (Revision)", IEEE 802-1X-REV/D9, January 804 2004. 806 [5] Ohba, Y., "State Machines for Protocol for Carrying 807 Authentication for Network Access (PANA)", 808 Internet-Draft draft-ohba-pana-statemachine-01, February 2005. 810 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 811 Internet-Draft draft-ietf-nsis-threats-06, October 2004. 813 Authors' Addresses 815 Xiaoming Fu 816 University of Goettingen 817 Telematics Group 818 Lotzestr. 16-18 819 Goettingen 37083 820 Germany 822 Email: fu@cs.uni-goettingen.de 823 Hannes Tschofenig 824 Siemens 825 Otto-Hahn-Ring 6 826 Munich, Bayern 81739 827 Germany 829 Email: Hannes.Tschofenig@siemens.com 831 Tseno Tsenov 832 Siemens 833 Otto-Hahn-Ring 6 834 Munich, Bayern 81739 835 Germany 837 Email: tseno.tsenov@mytum.de 839 Intellectual Property Statement 841 The IETF takes no position regarding the validity or scope of any 842 Intellectual Property Rights or other rights that might be claimed to 843 pertain to the implementation or use of the technology described in 844 this document or the extent to which any license under such rights 845 might or might not be available; nor does it represent that it has 846 made any independent effort to identify any such rights. Information 847 on the procedures with respect to rights in RFC documents can be 848 found in BCP 78 and BCP 79. 850 Copies of IPR disclosures made to the IETF Secretariat and any 851 assurances of licenses to be made available, or the result of an 852 attempt made to obtain a general license or permission for the use of 853 such proprietary rights by implementers or users of this 854 specification can be obtained from the IETF on-line IPR repository at 855 http://www.ietf.org/ipr. 857 The IETF invites any interested party to bring to its attention any 858 copyrights, patents or patent applications, or other proprietary 859 rights that may cover technology that may be required to implement 860 this standard. Please address the information to the IETF at 861 ietf-ipr@ietf.org. 863 Disclaimer of Validity 865 This document and the information contained herein are provided on an 866 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 867 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 868 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 869 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 870 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 871 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 873 Copyright Statement 875 Copyright (C) The Internet Society (2005). This document is subject 876 to the rights, licenses and restrictions contained in BCP 78, and 877 except as set forth therein, the authors retain all their rights. 879 Acknowledgment 881 Funding for the RFC Editor function is currently provided by the 882 Internet Society.