Internet DRAFT - draft-eckert-detnet-criteria-assessment
draft-eckert-detnet-criteria-assessment
DETNET T. Eckert
Internet-Draft Futurewei Technologies USA
Intended status: Informational 6 March 2023
Expires: 7 September 2023
Criteria and Assessment for DetNet Services Forwarding Plane Methods
draft-eckert-detnet-criteria-assessment-00
Abstract
This memo proposes methods to define, document and assess common
criteria for the evaluation of forwarding plane mechanisms intended
to be used within the DetNet WG as well as by implementers, operators
and vendors that need to compare and select such mechanisms.
This document is not intended to become an RFC but does at this point
in time soslely intend to help the process of documentation,
assessment and comparison. The goals of this memo may change in
later revisions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Eckert Expires 7 September 2023 [Page 1]
Internet-Draft detnet-criteria March 2023
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Assessment Criteria . . . . . . . . . . . . . . . . . . . . . 3
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Service Characteristics . . . . . . . . . . . . . . . . . 4
3.2.1. Latency . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. Jitter . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Network Applicability . . . . . . . . . . . . . . . . . . 5
3.4. Node Clocking . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Traffic Model . . . . . . . . . . . . . . . . . . . . . . 6
3.6. Per-hop Processing State . . . . . . . . . . . . . . . . 7
3.7. Calculus . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Packetization . . . . . . . . . . . . . . . . . . . . . . 10
4. Example Assessment: TCQF . . . . . . . . . . . . . . . . . . 11
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Name of the Mechanism: Tagged Cyclic Queuing and
Forwarding (TCQF) . . . . . . . . . . . . . . . . . . 11
4.2. Reference: I-D.eckert-detnet-tcqf . . . . . . . . . . . . 12
4.3. Service Characteristics . . . . . . . . . . . . . . . . . 12
4.3.1. Latency guarantee: Bounded (deterministic) . . . . . 12
4.3.2. Jitter: on-time (2* cycle-time T) . . . . . . . . . . 12
4.4. Network Applicability . . . . . . . . . . . . . . . . . . 12
4.4.1. Intended for IP, IPv6 and MPLS networks . . . . . . . 12
4.4.2. Intended for 100Gbps networks and faster . . . . . . 12
4.4.3. Latency requirements for links: arbitrary . . . . . . 12
4.4.4. Wireline Jitter: supported (at the cost of higher
per-hop latency) . . . . . . . . . . . . . . . . . . 12
4.4.5. Radio Jitter: NO / TBD . . . . . . . . . . . . . . . 12
4.5. Node Clocking . . . . . . . . . . . . . . . . . . . . . . 13
4.5.1. Asynchronous: No . . . . . . . . . . . . . . . . . . 13
4.5.2. MTIE impact on jitter and bounded latency . . . . . . 13
4.6. Traffic Model . . . . . . . . . . . . . . . . . . . . . . 13
4.6.1. Traffic Model Per-Hop, Per-Flow Parameters . . . . . 13
4.7. Per-hop Processing State . . . . . . . . . . . . . . . . 13
4.7.1. (per-hop, per-flow) Stateful: No . . . . . . . . . . 13
4.8. Algorithm parameters and mechanisms . . . . . . . . . . . 13
4.9. Calculus . . . . . . . . . . . . . . . . . . . . . . . . 14
4.9.1. Published per-hop calculus: Yes . . . . . . . . . . . 14
4.9.2. Published linear per-hop, per-flow calculus: Yes . . 14
4.9.3. Hop-by-hop jitter bounds: on-time . . . . . . . . . . 14
4.10. Packetization . . . . . . . . . . . . . . . . . . . . . . 14
Eckert Expires 7 September 2023 [Page 2]
Internet-Draft detnet-criteria March 2023
4.10.1. Per-flow compatibility with per-hop source-routing:
Yes . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.10.2. End-to-end packet header requirements . . . . . . . 14
4.10.3. Hop-by-hop packet header requirements . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Informative References . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
[I-D.ietf-detnet-scaling-requirements] defines a range of
requirements in support of scaling DetNet deployment along various
parameters including the size of the network and the number of DetNet
flows to be supported. Understanding how the variety of currently
existing as well as new, proposed forwarding mechanisms do match
these requirements does require to start defining quantifyable
criteria and assess how each specific mechanism does meet the
criteria. This document proposes how to do this.
2. Goals
The criteria should be descriptive so that operators can assess the
feasibility and benefits of an assessed method without necessarily
having to understand the exact behavior of the mechanism. This
implies that some duplication of assessments may be appropriate such
as using benefits and challenges as criteria, even if they are
coupled because of the ame underlying root cause.
The criteria should be descriptive so that vendors of network and
controller plane equipment can assess the feasibility and challenges
of mechanisms for implementation, especially with respect to on-chip
cost as well as scale aspects - speed of network links, latency/
jitter of links, total number of flows to be supported, and so on.
These criteria tend to require more detail assessment as hopefully
necessary for operators.
One of the meta goals of assessments is to find the minimum number of
higher-level criteria sufficient for operators, but currently this is
not possible. For example, the authors consider it to be impossible
to specify agreeable criteria for an assessment such as "can be
supported in 400Gbps ++ switches/routers without additional device
cost". But more explicit detail criteria which do add up to such
assessments can be specified.
3. Assessment Criteria
Eckert Expires 7 September 2023 [Page 3]
Internet-Draft detnet-criteria March 2023
3.1. General
Criteria: Name (/version/instances)
Description: Summary of the methods benefits and goals.
Criteria: Reference(s)
3.2. Service Characteristics
3.2.1. Latency
Criteria: Latency guarantee: NA / Bounded or Heuristic
Explanation: If the method assessed supports deterministically
bounded latency, then this criteria is "Bounded". Else it is "NA" or
"Heuristic".
Example: [I-D.stein-srtsn] proposes a method resulting in heuristic
latency guarantees. the maximum latency can not 100% be guaranteed by
the proposed forwarding mechanisms, but only with a very high
probability (depending on traffic characteristics).
3.2.2. Jitter
Criteria: Hop-by-hop jitter bounds: in-time / on-time / <other>
Explanation: This criteria assesses coarsly the jitter behavior of
the method. An on-time method does not delay packets on a per-hop
basis to reduce jitter of packets across the hop. In the absence of
competing traffic, packets of a flow that do not exceed the flows
permitted traffic model parameters are forwarded without any delay.
On-time methods have the largest possible jitter, but the shortest
possible delay in no-load situations. On-time methods do reduce per-
hop jitter through buffering. They have the lowest "possible"
jitter, but a latency (mostly) independent on load. If neither in-
time no on-time sufficiently characterizes the jitter behavior, new
"<other>" classification terms should be introduced. If easily
possible, the explanation should provide some numeric description of
the jitter behavior.
Eckert Expires 7 September 2023 [Page 4]
Internet-Draft detnet-criteria March 2023
Discussion: This criteria specifically asks for the hop-by-hop
behavior, because every on-time mechanism can be converted into an
in-time mechanism by add-on mechanisms such as receiver endpoint
playout buffers using sender generated timestamps to delay processing
up to the known bounded latency time. But such ad-on mechanisms
would introduce for example the need for end-to-end clock
synchronization and may hence negate benefits of the choosen method -
and should therefore the evaluated separately.
Example: In [UBS], hop-by-hop jitter is on-time, and minimum latency
is likely the minimum latency possible for any algorithm with linear
hop-by-hop calculus. In [CQF] and [I-D.eckert-detnet-tcqf], jitter
is in the order of the cycle time T and hence minimal, and latency
therefore close to the bounded latency.
3.3. Network Applicability
Criteria: Intended / applicable for IP / IPv6 / MPLS (subset)
Criteria: Intended for 100Gbps networks and faster (Yes/No)
Criteria: Requires new on-the-wire packet header fields (Yes/No/
Optional)
Criteria: Latency requirements for links
Description: This assessment is to specify and describe the latency
requirements for links. Some methods can only support links with
tight latency limits, such as [CQF].
Criteria: Jitter requirements/impact for wireline links
Description: Link jitter on wireline links may occur because of
packet loss and recovery by FEC (such as on ATM links), or link
length variation, such as "hanging" links on poles (up to 30% between
noon and midnight in observed cases). This criteria should describe
the impact of such known wireline jitter impacts (and their
feasibility) on the method.
Criteria: Jitter requirements/impact for radio links
Description: Radio links typically are subject to high, unpredictable
loss and he use of link-layer retransmissions which cause higher
latency for such retransmitted packets. While these behaviors do
typically not impact the assessed mechanism itself, they can impact
the necessary parameters and limit of applicability of the method for
such radio links. This criteria is meant to describe this.
Eckert Expires 7 September 2023 [Page 5]
Internet-Draft detnet-criteria March 2023
Discussion: The distinction between wireline and radio links is
somewhat artificial in so far as that all jitter mitigation
techniques are applicable across transmission media, but practically,
this distinction helps to keep the wireline descriptions simpler, and
given how DetNet services over radio links is laregly less well
understood, this distinction matches also the difference in
likelyhood of initial adoption/relevance.
3.4. Node Clocking
Criteria: Asynchronous: Yes / No (No =~ Asynchronuous)
Explanation: A forwarding mechanism can claim to be asynchronuous if
it can support unlimited "Maximum Time Interval Error" (MTIE) towards
neighboring nodes. In other words, the clocks between adjacent nodes
may drift/wander over time unlimited. If this is not the case, then
the method should be called synchronous for this criteria.
TSN [ATS] is an example of an asynchronuous mechanism. TSN [CQF] is
an example of a synchronuous mechanism.
Criteria: MTIE impact on jitter and bounded latency
Explanation: The MTIE of adjacent clock has a quantifyable impact on
the achievable per-hop bounded latency and jitter. This criteria is
intended to provide a characterization of this impact. At this point
in time it is unclear what the most easily feasible absolute
metric(s) are to perform this characterization, so this memo proposes
an informal description, including absolute comparisons to the impact
on pre-existing reference methods. Hopefully it will be possible to
derive at more well defined metrics in later versions of this
document.
Note: The MTIE will not be the only parameter of importance here, but
also the frequency of of clock variation within the MTI. The
appropriate metric for this is also TBD.
For easier assessment, it can be helpfull to provide minimum MTIE/
drift-speed requirements for a 1 Gbps network vs. a 100 Gbps network
to make it easy to compare numbers across mechanisms for these real-
world numbers.
3.5. Traffic Model
Criteria: Traffic Model Per-Hop, Per-Flow Parameters
Eckert Expires 7 September 2023 [Page 6]
Internet-Draft detnet-criteria March 2023
Explanation: Explanation for the parameters of the traffic model of
the packets of one DetNet flow when being processed of the assessed
mechanism. The mechanism may support more than one set of traffic
model parameters.
Example: The [UBS] mechanism, as used in for example TSN [ATS]
defines two possible traffic models: The Token Bucket model (TBE -
Token Bucket Emulation), and the simpler Length Rate Quotient (LRQ)
model, which could be ignored for assessment because it provides only
a subset of functionality of TBE. For TBE, a flow (i) has two
parameters, a "leak rate" r(i) (bits/sec) and a burstyness b(i)
(bits).
Example 2: In [RFC2210], the traffic model incurs a richer set of
parameters compared to [UBS] (if definition here is desired: TBD),
resulting in a higher processing complexity, but also more fine-
grained options to differentiate the per-hop latency of flows
compared to UBS.
3.6. Per-hop Processing State
Criteria: (per-hop, per-flow) Stateful: Yes / No (No =~ stateless)
Explanation: Assume a DetNet service with ingres/egres nodes called
PE(i), i=1..N, A forwarding plane flow flow(i,j) is the totality of
packets from one PE(i) to one PE(j) where the DetNet services,
especially bounded latency and/or jitter will experience the same
treatment. Such a flow can be a single DetNet flow, or it can be an
aggregate of multiple DetNet flows that will be treated the same.
Consider two or more forwarding plane flows flow(i1,j) and flow(i2,j)
that arrive from different input interfaces onto the same router on
the path towards PE(j). If this router can process these packets
without having to distinguish i1 and i2, then this criteria calls
this method stateless, else stateful.
TSN [ATS] is an example of a stateful mechanism, TSN [CQF] is an
example of a stateless mechanism.
Criteria: algorithm parameters and mechanisms
Explanation: This criteria describes the on-node state and processing
mechanisms required by the method for the processing of packets.
The so-called "lookup-state" is the set of keys from a packet
required to look up the so-called "on-node per-flow processing state"
state required to process a packet. In addition, packets may also
carry other "per-packet processing parameters"
Eckert Expires 7 September 2023 [Page 7]
Internet-Draft detnet-criteria March 2023
In a stateful mechanism, the lookup state consists of the keys of a
DetNet flow, depending on the DetNets forwarding plane (IP 5/6 tuple
or MPLS label stack elements) or from the underlying L2 solution used
to implemented the mechanism, such as ethernet header fields for IEEE
mechanisms.
Discussion: The [UBS] algorithm as used in TSN methods relies on
ethernet header lookup-state, but could equally rely on DetNet flow
parameters as lookup state. Hence the lookup-state for stateful
methods is not an important comparison criteria and is therefore
defined here explicitly to allow focussing on the processing state.
Example 1: In [UBS], the processing state for a flow(i) consists of
the traffic models per-flow parameters r(i) and b(i) as well as the
processing parameters parameters level(i), timestamp(i) and a
priority p(i). p(i) can be different on every hop and impacts the
per-hop latency experienced by packets of flow(i).
Processing a packet consists of performing calculations over those
five parameters as well as updating level(i) and timestamp(i) in time
before another packet of flow(i) arrives, so that that following
packets processing can take the updated parameters into account.
Scheduling of the packet is determined by a calculation of these
parameters and the presence of competing packets. The mechanisms
propsed to support the scheduling of packets are a combination of
"interleaved regulators" and "strict priority queueing".
Example 2: In [CQF], there is no (per-flow) lookup state. Instead,
the arrival timestamp of packets is used to determine the scheduling
of the packet into the appropriate cyclic queue.
Example 3: in [I-D.eckert-detnet-tcqf], there is no (per-flow) lookup
state. Instead, a per-packet processing parameter called the cycle
identifier 'c' is used to indicate the cycle into which the packet is
to be enqueued.
3.7. Calculus
Criteria: Published per-hop calculus: Yes/No
Eckert Expires 7 September 2023 [Page 8]
Internet-Draft detnet-criteria March 2023
Explanation: For this criteria to be assessed yes, there needs to be
a published description for how to calculate in less than NP complete
complexity whether a given set of flows with a given set of traffic
model parameters and a required set of latency and (if offered)
jitter requirement can fit onto an individual interface/link with a
given set of parameters, speed, latency, buffers and resulting in a
specific per-hop behavior: latency, jitter. If sufficiently easily
feasible, the explanation of the assessed criteria should contain a
summary of the calculus.
Description: It is hopefully sufficient that all methods of interest
will allow to break down the resource consumption vs. achieved
latency/jitter on a per-hop basis, so that the end-to-end
characteristics can be calculated in linear time across the hops of a
path.
Criteria: Published linear per-hop, per-flow calculus: Yes/No
Explanation: For this criteria to be assessed as yes, the prior
requirement is extended by requiring for a calculus to add/delete an
individual flow from the set of current flows and to require for this
calculus to have no more than linear complexity with the number of
flows utilizing the link.
Description: The prior calculus criteria is assumed to be sufficient
to permit admission of a set of flows during longer-term planning/
provisioning, by allowing for the calculus to have significant
complexity. Especially when the network has significantly more
resources than required for DetNet services, it may only be necessary
to calculate the overall DetNet resources, but not to quickly and
dynamically reserve resources for new flows or release them. This
criteria instead is written to support exactly this. Whether
admission happens in an offline controller-plane, or on-path - both
options are known to be easily supportable if this criteria can be
met by a method.
Criteria: Hop-by-hop jitter bounds: in-time / on-time / <other>
Explanation: This criteria assesses coarsly the jitter behavior of
the method. An on-time method does not delay packets on a per-hop
basis to reduce jitter of packets across the hop. In the absence of
competing traffic, packets of a flow that do not exceed the flows
permitted traffic model parameters are forwarded without any delay.
On-time methods have the largest possible jitter, but the shortest
possible delay in no-load situations. On-time methods do reduce per-
hop jitter through buffering. They have the lowest "possible"
jitter, but a latency (mostly) independent on load. If neither in-
time no on-time sufficiently characterizes the jitter behavior, new
Eckert Expires 7 September 2023 [Page 9]
Internet-Draft detnet-criteria March 2023
"<other>" classification terms should be introduced. If easily
possible, the explanation should provide some numeric description of
the jitter behavior.
Discussion: This criteria specifically asks for the hop-by-hop
behavior, because every on-time mechanism can be converted into an
in-time mechanism by add-on mechanisms such as receiver endpoint
playout buffers using sender generated timestamps to delay processing
up to the known bounded latency time. But such ad-on mechanisms
would introduce for example the need for end-to-end clock
synchronization and may hence negate benefits of the choosen method -
and should therefore the evaluated separately.
Example: In [UBS], hop-by-hop jitter is on-time, and minimum latency
is likely the minimum latency possible for any algorithm with linear
hop-by-hop calculus. In [CQF] and [I-D.eckert-detnet-tcqf], jitter
is in the order of the cycle time T and hence minimal, and latency
therefore close to the bounded latency.
3.8. Packetization
Criteria: Per-flow compatibility with per-hop source-routing: Yes /
No (SR-MPLS, SRv6, BIER-TE,...)
Explanation: In a network deployment using source-routing, path
selection is done not hop-by-hop through a distribued routing
protocol, but decided by a packet header inserted by the ingres
router / LSR into a domain. This is meant to reduce overall
operations and signaling complexity and eliminating the need to
update per-hop routing / forwarding state. Compatibility with this
for DetNet services implies that the assessed mechanism does also
provide the ability to perform the DetNet service (especially per-hop
latency/jitter guarantees) purely through in-packet headers as
opposed to per-hop,per-flow state in support of these services.
Discussion: This document is only aware of mechanisms meeting this
critera if they also are meeting the stateless criteria from earlier
in this document. Neverthless, this criteria is listed separate to
not make the assumption that this is always necessary. In addition,
stateless mechanisms for DetNet services may also be desirable in
non-stateless routing deployments, Such as especially when using
stateless multicast with non source-routing for unicast. In such
deployments, the compatibility with per-hop source-routing is
irrelevant to the operator.
Criteria: End-to-end packet header requirements (~N bits/bytes)
Eckert Expires 7 September 2023 [Page 10]
Internet-Draft detnet-criteria March 2023
Description: This criteria assesses the end-to-end packet header
requirements to support the assessed mechanism. This may depend on
other packet encapsulation aspects such ass whether IP or MPLS are
being used, in this case multiple assessments can be provided, one
for each context. If this is not applicable, then "none" should be
used. This criteria should not include assessment of packet header
requirements that are per-hop, including any possible end-to-end
overheader for a per-hop header.
Example: In most stateful mechanisms such as [UBS], this criteria is
"none", because the only packet header requirement is the flow-key
headers, e.g.: DetNet flow identification. In a method such as TQF
[I-D.eckert-detnet-tcqf] it is a small number such as 3 bits.
Criteria: Hop-by-hop packet header requirements (M + N/per-hop bits/
bytes)
Description: This criteria assesses the packet header requirements if
the mechanism needs or supports per-hop in-packet header parameters.
M should be the static overhead independent of the number of hops, N
the per-hop cost. Descriptive text shoud be used as necessary to
explain/refine the assessment.
Example: A mechanism such as [I-D.stein-srtsn] proposes per-hop
latency deadline values in the packet header. Thus the per-hop
header requirement is the number of bits required to represent these
deadlines. If possible instances of such a mechanism might need
different size header fields depending on size or speed of the
network, it could be assessed using example 1Gbps and 100Gbps
networks.
4. Example Assessment: TCQF
4.1. General
4.1.1. Name of the Mechanism: Tagged Cyclic Queuing and Forwarding
(TCQF)
TCQF is a derivation of [CQF]. In CQF, the arrival time of a packet
determines the cycle in which it is forwarded. This limits
applicability of CQF to links/networks with short propagation
latencies. TCQF replaces this meth with an in-packet cycle indicator
and the use of 3 or more cycles to support arbitrary link latencies
and link jitter. Due to the use of only few bits to indicate the
cycle in a packet header TCQF could be implemented for IP and MPLS
without change of packet headers by using DSCP or TC fields.
Eckert Expires 7 September 2023 [Page 11]
Internet-Draft detnet-criteria March 2023
4.2. Reference: [I-D.eckert-detnet-tcqf]
4.3. Service Characteristics
4.3.1. Latency guarantee: Bounded (deterministic)
4.3.2. Jitter: on-time (2* cycle-time T)
End-to-end jitter with TCQF is at most 2 times the cycle-time T. In
a wireline 100 Gbps network, this cycle time could for example be
20...100 usec, resulting in a maximum end-to-end jitter of 40...200
usec.
4.4. Network Applicability
4.4.1. Intended for IP, IPv6 and MPLS networks
As mentioned in General section.
4.4.2. Intended for 100Gbps networks and faster
The faster the network, the shorter the cycle time can be, and hence
the per-hop latency introduced by cyle forwarding. This method may
not be a useful enhancement in those slower 1..10 Gbps networks where
[CQF] can work well.
4.4.3. Latency requirements for links: arbitrary
4.4.4. Wireline Jitter: supported (at the cost of higher per-hop
latency)
When links may incur jitter in propagation latency, the number N of
cycles needs to be configured so that jitter < T * (N - 3). In other
words, in addition to the 3 cycles required to support arbitrary
latencies, an additional (N - 3) cycles are required so that the
cycle time T * (N -3) exceeds the jitter: These additional cycles
serve as a type of "per-hop" playout buffer converting the jitter
into latency - and maintaining the end-to-end maximum Jitter of 2*T.
4.4.5. Radio Jitter: NO / TBD
Considerations of Jitter beyond those explained for Wireline are TBD.
Eckert Expires 7 September 2023 [Page 12]
Internet-Draft detnet-criteria March 2023
4.5. Node Clocking
4.5.1. Asynchronous: No
4.5.2. MTIE impact on jitter and bounded latency
TCQF requires a known upper limit of the MTIE for cycles to not run
out of synchronization. The impact of MTIE on the configuration of
MTIE is like the impact of link jitter: Higher MTIE can be
compensated for with larger cycle time / number of cycles. This
allows to reduce MTIE requirements compared to [CQF] by a factor of
20 or more, thereby reducing the implementation cost and/or allowing
to support faster links without increase of clock synchronization
accuracy (which could otherwise be prohibitive at speeds >= 100
Gbps)..
4.6. Traffic Model
4.6.1. Traffic Model Per-Hop, Per-Flow Parameters
The per-hop traffic model for an end-to-end flow is the maximum
number of bits in a cycle time. On ingres to a TCQF path, flows with
other traffic models (such a Token Bucked models as in [UBS]) have to
be shaped accordingly.
4.7. Per-hop Processing State
4.7.1. (per-hop, per-flow) Stateful: No
TCQF nodes only need to buffer packets in per-egres cycle buffers
independent of flows. Therefore an arbitrary number of ingres to
egres flows especially from different ingres can share the same
buffers. On an ingres-node, per-flow state may be necessary if the
aforementioned shaping of flows is required. If a trusted
application sender supports TCQF directly, no network node needs to
have any per-flow state.
4.8. Algorithm parameters and mechanisms
TCQF only requires a mapping table on each egres interface:
(input-interface, ingres-cycle) -> (egres-cycle / egres-cycle-buffer)
Eckert Expires 7 September 2023 [Page 13]
Internet-Draft detnet-criteria March 2023
4.9. Calculus
4.9.1. Published per-hop calculus: Yes
As per TCQF reference. See next critera for explanation.
4.9.2. Published linear per-hop, per-flow calculus: Yes
As per TCQF reference
Bandwidth admission calculus is pretty much simply keeping track of
the number of bits required for each flow on every hops cycle buffers
in e.g.: an offline admission controller.
Latency calculus is simply adding up the per-hop cycle delay based on
the number of cycles configured for each hop.
4.9.3. Hop-by-hop jitter bounds: on-time
The per-hop jitter as observed between enqueing from the sending hop
cycle queue to serving the next-hop cycle queue is as the end-to-end
jitter 2 * T. Note that this may be lower than the jitter of
propagation latency across the traversed link, e.g.: the mechanism is
compensating for that jitter as explained earlier.
4.10. Packetization
4.10.1. Per-flow compatibility with per-hop source-routing: Yes
TCQF can support SR-MPLS, SRv6, BIER and BIER-TE by use of the DSCP
and/or TOS fields of the IP/IPv6 or MPLS header. This is explained
in the TCQF reference.
Note that for MPLS, the number of possible values is less than 3
bits, so the amount of MTIE or link jitter than can be compensated
will be limited
4.10.2. End-to-end packet header requirements
Basic TCQF can operrte with three header values (less than 2 bits in
a header). Depending on number of cycles needs 3 bits or more may be
beneficial.
4.10.3. Hop-by-hop packet header requirements
TCQF does not propose any hop-by-hop headers in addition to the per-
hop rewritten end-to-end header carrying the cycle identifier.
Eckert Expires 7 September 2023 [Page 14]
Internet-Draft detnet-criteria March 2023
5. Security Considerations
TBD.
6. IANA Considerations
This document has no IANA considerations.
7. Changelog
[RFC-editor: please remove]
Initial draft name: draft-eckert-detnet-criteria-assessment-00
8. Informative References
[ATS] Specht, J., "P802.1Qcr – Bridges and Bridged Networks
Amendment: Asynchronous Traffic Shaping", IEEE , 9 July
2020, <https://1.ieee802.org/tsn/802-1qcr/>.
[CQF] IEEE Time-Sensitive Networking (TSN) Task Group., "IEEE
Std 802.1Qch-2017: IEEE Standard for Local and
Metropolitan Area Networks — Bridges and Bridged Networks
— Amendment 29: Cyclic Queuing and Forwarding", 2017.
[I-D.eckert-detnet-tcqf]
Eckert, T. T., Bryant, S., Malis, A. G., and G. Li,
"Deterministic Networking (DetNet) Data Plane - Tagged
Cyclic Queuing and Forwarding (TCQF) for bounded latency
with low jitter in large scale DetNets", Work in Progress,
Internet-Draft, draft-eckert-detnet-tcqf-01, 6 November
2022, <https://datatracker.ietf.org/doc/html/draft-eckert-
detnet-tcqf-01>.
[I-D.ietf-detnet-scaling-requirements]
Liu, P., Li, Y., Eckert, T. T., Xiong, Q., Ryoo, J.,
zhushiyin, and X. Geng, "Requirements for Scaling
Deterministic Networks", Work in Progress, Internet-Draft,
draft-ietf-detnet-scaling-requirements-01, 1 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
scaling-requirements-01>.
[I-D.stein-srtsn]
Stein, Y. J., "Segment Routed Time Sensitive Networking",
Work in Progress, Internet-Draft, draft-stein-srtsn-01, 29
August 2021, <https://datatracker.ietf.org/doc/html/draft-
stein-srtsn-01>.
Eckert Expires 7 September 2023 [Page 15]
Internet-Draft detnet-criteria March 2023
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, DOI 10.17487/RFC2210, September 1997,
<https://www.rfc-editor.org/info/rfc2210>.
[UBS] Specht, J. and S. Samii, "Urgency-Based Scheduler for
Time-Sensitive Switched Ethernet Networks", IEEE 28th
Euromicro Conference on Real-Time Systems (ECRTS), 2016.
Author's Address
Toerless Eckert
Futurewei Technologies USA
2220 Central Expressway
Santa Clara, CA 95050
United States of America
Email: tte@cs.fau.de
Eckert Expires 7 September 2023 [Page 16]
