9. Signalling
The traffic flow establishment procedure consists of two phases.
9.1 First
Phase
The node that originates the traffic flow, called sender, conveys the admission request to the final destination node, called receiver, through a PATH message, which is relayed by the intermediate nodes along the path.
The sender is required to select the Flow ID of any new flow in such a way that the triple 〈sender, receiver, flow ID〉 uniquely identifies the traffic flow in the network.
Figure 9.1 – Simple flow.
During this phase, call admission control, called CAC, is performed but resources are not actually reserved, so that PATH messages are not forwarded to downstream nodes if resources are currently not available on any intermediate link.
blocked. This happens when the resources that are busy during the PATH phase would become available during the RSV phase, which is not even initiated. However, the probability of this event is negligible with realistic durations of traffic flows, whose typical values are orders of magnitude greater than the expected reservation process latency.
9.2
Second Phase
The receiver sends back to the sender an RSV message. The latter is routed through the same path that has been covered by the PATH message. This is achieved by using the list of intermediate node IDs included in the PATH message. Each node performs the CAC to check that enough resources are available both in the link towards the receiver, called downstream link and that from the sender, called upstream link.
PATH PATH PATH PATH RESV RESV RESV RESV CNF S A B C R Message directed to Message overheard by CAC
Figure 9.3 – Second phase.
As for the CAC performed during the PATH phase, the check on the upstream link is not strictly necessary, since resources are only reserved by nodes in downstream. However, this avoids resources to be unnecessarily booked on one link when its subsequent link will fail admission. The CAC procedure and exact definition of “resource allocation” are detailed in the next section.
9.3 Confirmation
Due to the broadcast nature of the control messages, there is no need for explicitly notifying the CAC success/failure to the downstream node. In fact, each downstream node can implicitly infer the CAC status by overhearing the RSV message transmitted by its upstream node. Clearly, the only exception is represented by the sender which must explicitly notify its downstream node of the CAC success through the CNF message.
9.4 Timeouts
Two timers are used by nodes during the setup phase of the traffic flow to detect traffic flow termination due to CAC failure. Both these timers need be configured appropriately to detect a possible CAC failure as early as possible, thus freeing the allocated resources promptly.
Resource allocation decreases the capacity that can be exploited in each link for the establishment of subsequent traffic flows. Resources remain allocated until the traffic flow is dropped, which happens if nodes do not receive packets belonging to that flow for a specified amount of time, called TF (timeout flow), which is a system parameter.
Figure 9.4 – Timeout.
The timer values are:
• TS = timerlocal_ * h( prevhop ) * 2
• TE = ( ( nhop - 1 )* h( prevhop ) * 2 ) + ( nhop * packet_period_ * timerinstall_ )
• TF = ( timerflow_ * packet_period_ )
Where:
• timerlocal_: system parameter. • timerinstall_: system parameter. • timerflow_: system parameter.
• h( prevhop ): interval between two consecutive turns to transmit an MSH-DSCH message for the previous hop.
• nhop: number of hop between current node and sender. • packet_period_: packet periodicity.
Figure 9.5 shows the session startup. 0 1 2 3 Sender Receiver PATH 1. Compute Admission Control Downstream 2. Send PATH 1. Compute Admission Control Downstream 2. Send PATH PATH PATH 1. Compute Admission Control Upstream 2. Find free minislots in upstream 3. Ask to bwmanger start frame 4. Install temporary state 5. Allocate minislots in upstream 6. Create RSV and send it upstream 7. Start TS 1. Compute Admission Control Downstream 2. Compute Admission Control Upstream 3. Install state in Downstream 4. Allocate minislots in Downstream 5. Find free minislots in upstream 6. Ask to bwmanger start frame 7. Install temporary state 8. Allocate minislots in upstream 9. Create RSV and send it upstream 10. Start TS 1. Compute Admission Control Downstream 2. Send PATH RSV
Sender Receiver 1. Compute Admission Control Downstream 2. Compute Admission Control Upstream 3. Install state in Downstream 4. Allocate minislots in Downstream 5. Find free minislots in upstream 6. Ask to bwmanger start frame 7. Install temporary state 8. Allocate minislots in upstream 9. Create RSV and send it upstream 10. Start TS RSV 1. Confirm temporary state 2. Install state 3. Allocate minislots in upstream 4.Stop TS 5.Start TE RSV RSV 1. Confirm temporary state 2. Install state 3. Allocate slot in upstream 4.Stop TS 5.Start TE 1. Compute Admission Control Downstream 2. Install state in Downstream 3.Send CNF in Downstream 4. Start TD CNF RSV 1.Stop TS 2.Start TE 3. Install state in Upstream DATA_P KT 1.Stop TE 2.Start TF 1.Stop TE 2.Start TF 1.Stop TE 2.Start TF DAT A_PKT DAT A_PKT
9.5 Dummy
Packets
Some applications may generate packets with an ON/OFF pattern. This is especially the case of interactive multimedia applications, such as Voice over IP, videoconference streaming, and gaming. Therefore, in order to prevent premature termination of the traffic flow during an OFF period, the originator generates dummy packets to guarantee a constant refresh of the established traffic flow state on each node in the path. Dummy packets are special messages, which only contain the information about the traffic flow to which they belong, and are silently discarded by recipient’s MAC layer. The generation interval of dummy packets is a system parameter, which must be smaller than TF; this amount of time is called timeout dummy.
The value of timeout dummy is:
• TD = ( timerflow_ * packet_period_ ) / timerdummy_
Where:
• timerflow_: system parameter. • timerdummy_: system parameter. • packet_period_: packet periodicity.
