SS

Figure 66—DSA message flow—BS-initiated

6.2.13.7.2.3 Dynamic service flow modification and deletion

In addition to the methods presented above for creating service flows, protocols are defined for modifying and deleting service flows; see 6.2.13.8.4 and 6.2.13.8.5.

Both provisioned and dynamically created Service flows are modified with the DSC message, which can change the Admitted and Active QoS Parameter sets of the flow.

A successful DSC transaction changes a service flow’s QoS parameters by replacing both the Admitted and Active QoS parameter sets. If the message contains only the Admitted set, the Active set is set to null and the flow is deactivated. If the message contains neither set (“000” value used for QoS Parameter Set type, see 11.4.8.5), then both sets are set to null and the flow is deadmitted. When the message contains both QoS parameter sets, the Admitted set is checked first, and if admission control succeeds, the Active set in the message is checked against the Admitted set in the message to ensure that it is a subset. If all checks are successful, the QoS parameter sets in the message become the new Admitted and Active QoS parameter sets for the service flow. If either of the checks fails, the DSC transaction fails and the service flow QoS parameter sets are unchanged.

6.2.13.8 Dynamic service

6.2.13.8.1 Connection establishment

Service flows may be created, changed, or deleted. This is accomplished through a series of MAC management Messages referred to as Dynamic Service Addition (DSA), Dynamic Service Change (DSC), and Dynamic Service Deletion (DSD). The DSA Messages create a new service flow. The DSC Messages change an existing service flow. The DSD Messages delete an existing service flow. This is illustrated in Figure 67.

DSC

DSD

Figure 67—Dynamic service flow overview

The Null state implies that no service flow exists that matches the SFID and/or Transaction ID in a Message. Once the service flow exists, it is operational and has an assigned SFID. In steady state operation, a service flow resides in a Nominal state. When Dynamic Service messaging is occurring, the service flow may transition through other states, but remains operational. Since multiple service flows may exist, there may be multiple state machines active, one for every service flow. Dynamic Service Messages only affect those state machines that match the SFID and/or Transaction ID. If privacy is enabled, both the SS and BS shall verify the HMAC digest on all dynamic service Messages before processing them, and discard any Messages that fail.

Transaction IDs are unique per transaction and are selected by the initiating device (SS or BS). To help prevent ambiguity and provide simple checking, the Transaction ID number space is split between the SS and BS. The SS shall select its Transaction IDs from the first half of the number space (0x0000 to 0x7FFF). The BS shall select its Transaction IDs from the second half of the number space (0x8000 to 0xFFFF).

Each dynamic service Message sequence is a unique transaction with an associated unique transaction identifier. The DSA/DSC transactions consist of a request/response/acknowledge sequence. The DSD transactions consist of a request/response sequence. The response Messages shall return a confirmation code of OK unless some exception condition was detected. The acknowledge Messages shall return the confirmation code in the response unless a new exception condition arises. A more detailed state diagram, including transition states, is shown below. The detailed actions for each transaction shall be given in the following subclauses.

6.2.13.8.2 Dynamic service flow state transitions

The Dynamic Service Flow State Transition Diagram (Figure 68) is the top-level state diagram and controls the general service flow state. As needed, it creates transactions, each represented by a Transaction state transition diagram, to provide the DSA, DSC, and DSD signaling. Each Transaction state transition diagram communicates only with the parent Dynamic Service Flow State Transition Diagram. The top-level state transition diagram filters Dynamic Service Messages and passes them to the appropriate transaction based on SFID, Service Flow Reference number, and Transaction ID.

There are six different types of transactions: locally initiated or remotely initiated for each of the DSA, DSC, and DSD Messages (Figure 69–Figure 74). Most transactions have three basic states: pending, holding, and deleting. The pending state is typically entered after creation and is where the transaction is waiting for a reply. The holding state is typically entered once the reply is received. The purpose of this state is to allow for retransmissions in case of a lost Message, even though the local entity has perceived that the transaction has completed. The deleting state is only entered if the service flow is being deleted while a transaction is being processed.

The flow diagrams provide a detailed representation of each of the states in the Transaction state transition diagrams. All valid transitions are shown. Any inputs not shown should be handled as a severe error condition.

With one exception, these state diagrams apply equally to the BS and SS. In the Dynamic Service Flow Changing-Local state, there is a subtle difference in the SS and BS behaviors. This is called out in the state transition and detailed flow diagrams.

NOTE—The ‘Num Xacts’ variable in the Dynamic Service Flow State Transition Diagram is incremented every time the top-level state diagram creates a transaction and is decremented every time a transaction terminates. A Dynamic Service Flow shall not return to the Null state until it’s deleted and all transactions have terminated.

The inputs for the state diagrams are identified below.

Dynamic Service Flow State Transition Diagram inputs from unspecified local, higher-level entities:

a)Add

b)Change

c)Delete

Dynamic Service Flow State Transition Diagram inputs from DSx Transaction State Transition diagrams:

a)DSA Succeeded

b)DSA Failed

c)DSA ACK Lost

d)DSA Erred

e)DSA Ended

a)DSC Succeeded

b)DSC Failed

c)DSC ACK Lost

d)DSC Erred

e)DSC Ended

a)DSD Succeeded

b)DSD Erred

c)DSD Ended

DSx Transaction State Transition diagram inputs from the Dynamic Service Flow State Transition Diagram:

a)SF Add

b)SF Change

c)SF Delete

a)SF Abort Add

b)SF Change-Remote

c)SF Delete-Local

d)SF Delete-Remote

a)SF DSA-ACK Lost

b)SF DSC-REQ Lost

c)SF DSC-ACK Lost

d)SF DSC-REQ Lost

a)SF Changed

b)SF Deleted

The creation of DSx Transactions by the Dynamic Service Flow State Transition Diagram is indicated by the notation:

DSx-[ Local | Remote ] ( initial_input )

where initial_input may be SF Add, DSA-REQ, SF Change, DSC-REQ, SF Delete, or DSD-REQ, depending on the transaction type and initiator.

Null

DSD Succeeded / SF Deleted

Deleted

Figure 68—Dynamic service flow state transition diagram

Begin

Figure 69—DSA—Locally initiated transaction state transition diagram

( Timeout T8 / DSA Ended )

( SF Changed / DSA Ended )

( SF Deleted / DSA Ended )

( SF Change-Remote / DSA Ended )

( Timeout T10 / DSA Ended )

( SF Deleted / DSA Ended )

( SF Delete-Remote / DSA Ended )

End

Figure 70—DSA—Remotely initiated transaction state transition diagram

Begin

SF Change / DSC-REQ

((Timeout T7 || Timeout T14) && Retries Exhausted /)

( DSC-RSP / DSC Succeeded, DSC-ACK )

( DSC-RSP / DSC Failed, DSC-ACK )

DSC-RSP /

DSC ACK Lost

( SF Delete-Remote / DSC Ended ) End

Figure 71—DSC—Locally initiated transaction state transition diagram

Begin

Figure 72—DSC—Remotely initiated transaction state transition diagram

Begin

SF Delete / DSD-REQ

( Timeout T7 && Retries Available / DSD-REQ ) DSD-RSP ( SF DSD-REQ Lost && Retries Available / DSC-REQ )

( SF DSD-REQ Lost && Retries Exhausted / )

Pending

( DSC-RSP / DSD Succeeded ) ( SF Delete-Remote /)

Timeout T7 / DSD Ended

End

Figure 73—DSD—Locally initiated transaction state transition diagram