Text Contribution for P802.1Qdq
24 th of September 2021
Satoko Itaya, Toru Osuga, Takeshi Matsumura (NICT),
Akio Hasegawa (ATR),
Hiroki Nakano (CAHI Corporation)

What do we propose to update?
• Base proposal• https://www.ieee802.org/1/files/public/docs2021/dq-itaya-castext-contribution-0721-v1.pdf
1. Figure Y-1 “An example of network structure under consideration”• To clarify what we explain, we propose to replace Y-1 with a
new figure that is simpler than the original one.
2. Clause Y.3.2 “Dynamic Reservation…”• Generalize discussion rather than SRP-specific logic.
• Refer to “802.1Qdq Reservation Logic” introduced in Figure Y-1’

1. Review of Figure Y-1• There are many contents mixed in a one figure.
• Relation between “Application” and “Talker” is illustrated in Figure
Y-1’, so it is not required here.
Remove because Figure
Y-1’ also explains thisin separate appliances
Application

Application

Traffic
Talker shaping(Bursty)

Talker(Bursty)

Traffic
shaping

Listener
BridgeBridgeBridgeTalker(Continuous)

BridgeBridgeListener

BridgeBridgeBridgein an appliance

BridgeBridgeBridge

Listener

TSN Network3

Proposal of New Figure Y-1• P802.1Q clause 3 defines Talker as “The end station that is the source orproducer of a stream.” Nevertheless, we use “Talker End Station” in thisfigure to clarify it is an end station, not a bridge.
• We focus on latency between measuring points in Talker and Listener.

42. Rewriting concept of Clause Y.3.2
Original Y.3.2 on the contribution in July

Proposal in this contribution
General discussion
In case of manual calculation
In case of SRP

SRP

Refer to “802.1Qdq Reservation Logic”
according to Figure Y-1’
Can add other cases if necessary5

Rewrite Y.3.2

Add general discussion

Add Remove• Y.3.2 Dynamic Reservation with SRPGenerally speaking, a process establishing a reservation often
consists of multiple steps. A common case is that a path issearched first and then that some calculations and configurations
are made according to the path. As mentioned in the previous
clause, Accumulated Latency depends on a path from Talker toListener, therefore, it is obtained after the path is determined. Ofcourse, it shall be obtained prior to calculation.

In case of manual calculation, this principle is also applicable, thatis, the TSN network planner/administrator determines a path fora reservation first, and then calculate the parameters of thereservation, e.g. bandwidth.
Add manual case6

Rewrite Y.3.2 (cont.)

SRP case, Refer to “802.1Qdq ReservationLogic” according to Figure Y-1’

• Y.3.2 Dynamic Reservation with SRP
Add Remove…(continued from the last slide)In case of SRP (IEEE Std 802.1Qcc-2018, Clause 35), a Talker Advertise message searches paths and thecorresponding Listener Ready message confirms the reservation. The Listener Ready message also
carries information of the path to the Talker, including Accumulated Latency. The UNI (User NetworkInterface) is used to exchange information related to Accumulated Latency information between
802.1Qdq Reservation Logic (Figure Y-1’)Talker and the corresponding Talker function. The 802.1Qdq
Reservation LogicThe application uses the MaxLatency element of the UserToNetworkRequirements group(IEEE Std 802.1Qcc-2018, Clause 46.2.3.6.2) and the AccumulatedLatency group (IEEE Std 802.1Qcc2018, Clause 46.2.5.2) in order to obtain accumulatedLatency from the Talker via UNI. The UNI
specification requires the Talker to send a Talker Advertise message and to collect Listener Readymessagesrequest joining a target stream. Once a Listener Ready message reaches Talker, the path of thereservation is determined and accumulatedLatency is reported via UNI to the 802.1Qdq Reservation Logic.
However, SRP is not capable to update parameters of the reservation confirmed by the Listener Readymessage. To work with SRP, the reservation is dropped first and then a new reservation with newparameters shall be requested via UNI from the 802.1Qdq Reservation Logic. That is, the Talker cannot
obtain the information before requesting to join a stream. Therefore, the Talker has to request to join astream first with a tentative TSpec. The tentative parameters of the first Talker Advertise are TSpec isderived assuming the accumulatedLatency which can be set by implementer’s choice, such asdetermining by the network administrator, and adopting a value of zero as simple recommendation. the802.1Qdq Reservation LogicTalker requests to join again with the amount obtained by the first request.
The first calculated reservation and the second one is not guaranteed to return the same values of theaccumulatedLatency and the 802.1Qdq Reservation LogicTalker will try to join with different
parametersTSpec and MaxLatency based on the previously obtained accumulatedLatency repeatedly until
successful joining the target stream. This method can be applied to the Stream Reservation Protocol.
(IEEE Std 802.1Qcc-2018, Clause 35).

7

Any comment?

8Backup9802.1Qdq Reservation Logic flow

Determine path with tentative parameters

Obtain/compute accumulated latency

Compute required bandwidth/parameters

Confirm reservation with computed parameters10802.1Qdq Reservation Logic flow with SRP

Determine/reserve path with tentative parameters

Obtain/compute accumulated latency
Drop reservation
Compute required bandwidth/parameters

enough efficient?

Confirm reservation with computed parameters11