Page 35 - ITUJournal Future and evolving technologies Volume 2 (2021), Issue 1

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 1

1. At each egress port (Port Identi ier, PID), the TSN 4.1 Core components
switch maintains a local stream registration table
that includes information, such as low ID, gateway This section outlines the main components required to
(i.e., the irst bridge that a talker is connected to), successfully implement stream admission control and re‑
destination address(es), the traf ic injection rate per source reservation within switches that support the TAS
GCL cycle time, and the calculated port bandwidth traf ic shaper in a distributed fashion. Fig. 4 illustrates the
requirement. The traf ic injection rate is not com‑ typical registration/reservation procedure for all streams
puted, rather the traf ic injection rate is reported within the TSN domain.
by the source (talker) to the network devices. It
mainly indicates the bandwidth requirements of a 4.1.1 Admission control
stream. Bandwidth for a bridge egress port needed The admission control element extracts the necessary in‑
for a stream is computed using the ST injection rate formation from the CDT packet and forwards the infor‑
(or ST rate), the average packet size, and the bridge mation according to the CDT type. The switch forward‑
TAS timing con iguration (e.g., the CT and current ing mechanism applies several steps to accurately decide
traf ic class slot time). This information is carried whether to accept or reject the stream transmission re‑
and communicated between bridges using the CDT quest. Note that the stream transmission request cor‑
packet type identi ier (or message type).
responds to a CDT request. The switch consults the re‑
source manager module to check if enough resources
2. A source (talker) can send a stream transmission re‑
quest, i.e., a CDT message of type Stream Transmis‑ (bandwidth) is available for the new stream. In particular,
sion Request, to register its stream and to use the a given stream’s bandwidth requirement is calculated by
TSN service for ST. multiplying the ST injection rate with the average packet
size and dividing by the current ST slot size. Note that
3. Each switch maintains a resource manager mod‑ the traf ic class TAS slot time is the time during which the
ule for each port. If the newly incoming stream TAS gate is open to transmit frames belonging to the con‑
is accepted (due to available resources and TAS sidered class. Also note that all GCEs are executed dur‑
slot space). The TAS slot size for a speci ic traf‑ ing each CT. If the CT is smaller than the aggregate of the
ic class is governed by the CT and traf ic class gat‑ GCEs, then we need to either increase the CT or reject
ing ratio (in time). The TAS ST slot can be con ig‑ streams that cause the exceedance of the CT.
ured/recon igured according to stream requests and
terminations. The stream registration message is 4.1.2 Flow scheduling
then propagated towards the next switch, and a map
is maintained for the stream (and any other streams) This element currently takes the Time‑Aware Shaper
pending approval. into consideration. Due to the TAS’s requirements
on time synchronization between network components
4. If accepted by the last switch, then the stream reg‑ (switches, hosts, etc.), all switches/hosts follow the TAS
istration record is added to the local stream registra‑ GCL timescale cycle time (e.g., 50 s). Depending on the
tion table, and bandwidth resources are allocated for number of supported traf ic classes, the TAS cycle time
the stream and TAS slot space is modi ied (if neces‑ can be divided into appropriate slots for each traf ic class
sary) on the reverse path. The main reason for allo‑ load. The TASCT is dividedamong all the traf ic classes (in
cating the resources in the reverse path is as follows. our evaluation model, we consider two traf ic classes, BE
If we allocate the resources in the forward direction and ST). Currently, in our evaluations, the CT is initially
but a switch in the next hop rejects the stream (due prede ined to 50 microseconds. Note that the CT could
to lack of resources), then we have to release the re‑ be changed/con igured dynamically. The dynamic adap‑
sources reserved earlier for the stream. Therefore, tation of the CT with respect to new stream additions, ap‑
we avoid the allocation until all hops provide assur‑ plication speci ications, or other events is a topic for fu‑
ance that the stream will be accommodated. ture research.

5. Each switch receiving the pending registration mes‑ 4.1.3 Stream registration table
sage adds the stream record to its local table, al‑
locates the necessary resources and TAS slot reser‑ In our evaluations, stream creation follows a Poisson pro‑
vation, and propagates the registration message to‑ cess with a prescribed stream generation rate . Different
wards the source gateway. scenarios with varying mean stream lifetimes (durations)
enable analysis of how recon iguration works in multiple
6. The source gateway receives the pending stream settings. The stream registration table contains the char‑
registration message and similarly allocates the re‑ acteristics of the source streams that are established for
sources and inally sends an approval granted mes‑ the corresponding bridge egress port. Each record gets
sage towards the source, which prompts the source populated (if accepted) on the reverse path taken by the
to start sending data in the next available TAS cycle. stream’s registration message (after reaching the destina‑

© International Telecommunication Union, 2021 19