DetNet Flow Information ModelEricssonMagyar tudosok korutja 11BudapestHungary1117janos.farkas@ericsson.comEricssonMagyar tudosok korutja 11BudapestHungary1117balazs.a.varga@ericsson.comNational Instruments11500 N. Mopac ExpwyBldg. CAustin, TXUSA78759-3504rodney.cummings@ni.comHuawei Technologies Co., Ltd.Bantian, Longgang districtShenzhenChina518129jiangyuanlong@huawei.com
Routing
DetNetDetNet, Flow Information ModelThis document describes flow and service information model for Deterministic Networking (DetNet).
These models are defined for IP and MPLS DetNet data planesA Deterministic Networking (DetNet) service provides a capability to carry a unicast or a multicast data flow for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency. DetNet and TSN have common architecture as expressed in and . The DetNet service is provided for DetNet flows via the DetNet service and forwarding sub-layers.
DetNet service is IP or MPLS and DetNet is currently defined for IP and
MPLS networks as shown in Figure 1 based on Figure 2 and Figure 3 of
. A DetNet flow includes
one or more App-flow(s) as payload. App-flows can be Ethernet, MPLS, or IP
flows, which impacts what header fields are use in order to identify a flow.
DetNet flows are created by DetNet encapsulation of App-flow(s) (e.g., with
added MPLS labels, etc.). In some scenarios App-flow and DetNet flow look
similar on the wire (e.g., L3 App-flow over a DetNet IP network).
As shown in as per
a DetNet flow can be treated as an application level flow (App-flow) e.g.,
at DetNet flow aggregation or in a sub-network that interconnects DetNet nodes.
The DetNet flow and service information model provided by this document contains both DetNet flow and App-flow specific information in an integrated fashion.
In a given network scenario three information models can distinguished:
Flow models describe characteristics of data flows. These models describe in detail all relevant aspects of a flow that are needed to support the flow properly by the network between the source and the destination(s). Service models describe characteristics of services being provided for data flows over a network. These models can be treated as a network operator independent information model. Configuration models describe in detail the settings required on network nodes to serve a data flow properly. Service and flow information models are used between the user and the network operator. Configuration information models are used between the management/control plane entity of the network and the network nodes. They are shown in .
DetNet flow and service information model is based on and on the concept of data model specified by . Furthermore, the starting point of the DetNet flow information model was the flow identification possibilities described in , which is used by as well. In addition to TSN data model, also specifies configuration of TSN features (e.g., traffic scheduling specified by ). Due to the common architecture and flow model, configuration features can be leveraged in certain deployment scenarios, e.g., when the network that provides the DetNet service includes both L3 and L2 network segments.
As it is expressed in the Charter , the DetNet WG collaborates with IEEE 802.1 TSN in order to define a common architecture for both Layer 2 and Layer 3, which is beneficial for various reasons, e.g., in order to simplify implementations. The flow and service information models should be also aligned along those lines. Therefore, the DetNet flow and service information models described in this document are based on , which is an amendment to .This document intends to specify flow and service information models only.This document (this revision) does not intend to specify either flow data model or DetNet configuration. From these aspects, the goals of this document differ from the goals of , which also specifies data model and configuration of certain TSN features.
This document uses the terminology established in the DetNet
architecture and the
the DetNet Data Plane Framework . The reader is
assumed to be familiar with these documents and any terminology
defined therein.
The DetNet <=> TSN dictionary of
is used to perform translation from to this document.
The following terminology is used according to :
The payload (data) carried over a DetNet service.
A DetNet flow is a sequence of packets which conform uniquely
to a flow identifier, and to which the DetNet service is to
be provided. It includes any DetNet headers added to support
the DetNet service and forwarding sub-layers.
The following terminology is introduced in this document:
Reference point for an App-flow, where the flow starts.
Reference point for an App-flow, where the flow terminates.
Reference point for DetNet flow, where it starts. Networking technology specific encapsulation may be added here to the served App-flow(s).
Reference point for DetNet flow, where it terminates. Networking technology specific encapsulation may be removed here from the served App-flow(s).
The following abbreviations are used in this document:
Deterministic Networking.DetNet.Multiprotocol Label Switching.Packet Switched Network.Time-Sensitive Networking.The following naming conventions were used for naming information model components in this document. It is recommended that extensions of the model use the same conventions.
Names SHOULD be descriptive.Names MUST start with uppercase letters.Composed names MUST use capital letters for the first letter of each component. All other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as IPv6. Examples are SourceMacAddress and DestinationIPv6Address.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 when, and
only when, they appear in all capitals, as shown here.
The DetNet service can be defined as a service that provides a capability to carry a unicast or a multicast data flow for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency.
Figure 5. and Figure 8. in show the DetNet service related reference points and main components.
From service design perspective a fundamental question is the location of the service/flow endpoints, i.e., where the service/flow starts and ends.
App-flow specific reference points are the Source (where it starts) and the Destination (where it terminates). Similarly a DetNet flow have reference points named as DN Ingress (where it starts) and DN Egress (where it ends). These reference points may coexist in the same node (e.g., in a DetNet IP end system). DN Ingress and DN Egress reference points are intermediate reference points for a served App-flow.
All reference points are assumed in this document to be packet-based reference points. A DN Ingress may add and a DN Egress may remove networking technology specific encapsulation to/from the served App-flow(s) (e.g., MPLS label(s), UDP and IP headers).
The DetNet flow information model and the service model relies on three groups of information elements:
App-flow related paramaters: they describe the App-flow characteristics (e.g., identification, encapsulation, traffic specification, endpoints, status, etc.) and the App-flow requirements (e.g., delay, loss, etc.).DetNet flow related parameters: they describe the DetNet flow characteristics (e.g., identification, format, traffic specification, endpoints, rank, etc.).DetNet service related parameters: they describe the expected service characteristics (e.g., delivery type, connectivity delay/loss, status, rank, etc.). In the information model
a DetNet flow contains one or more App-flows (N:1 mapping). During DetNet
aggregation the aggregated DetNet flows are
treated as App-flows and the aggregate is the DetNet flow, which provides
N:1 mapping. Similarly, there is a M:1 relationship of DetNet flow(s) and a DetNet
Service.
Deterministic service is required by time/loss sensitive application(s)
running on an end system during communication with its peer(s). Such a data
exchange has various requirements on delay and/or loss parameters.App-flow characteristics are described with the following parameters:
FlowID: it is a unique (management) identifier of the App-flow.
It can be used to define the N:1 mapping of App-flows to a DetNet flow.FlowType: it is set according to the encapsulation format of the flow.
It can be Ethernet (TSN), MPLS, or IP.DataFlowSpecification: it is a flow descriptor, defining which packets
belongs to a flow using, e.g., FlowType specific packet header fields like
src-addr, dst-addr, label, VLAN-ID, etc.TrafficSpecification: it is a flow descriptor, defining traffic parameters
like packet size, interval, and max. packets per interval.FlowEndpoints: it defines the start and termination reference points
of the App-flow by pointing to the source interface/node and destination
interface(s)/node(s).FlowStatus: it provides the status of the App-flow with respect to
the establishment of the flow by the network, e.g., ready, failed, etc.FlowRank: it provides the rank of this flow relative to other flows
in the network.App-flow requirements are described with the following parameters:
FlowRequirements: it defines the requirement of the App-flow regarding
bandwidth, latency, latency variation, loss, and misorder tolerance.FlowBiDir: it defines the requirement of the App-flow whether it
has to be routed together with other App-flow(s) through the network,
e.g., to provide congruent paths in the two directions. Data model specified by describes
data flows using TSN service as periodic flows with fix packet size (i.e.,
Constant Bit Rate (CBR) flows) or with variable packet size. The same concept
is applyed for flows using DetNet service.Latency and loss parameters are correlated because the effect of late delivery
can result data loss for an application. However, not all applications require
hard limits on both parameters (latency and loss). For example, some real-time
applications allow graceful degradation if loss happens (e.g., sample-based
processing, media distribution). Some others may require high-bandwidth connections
that make the usage of techniques like packet replication economically challenging
or even impossible. Some applications may not tolerate loss, but are not latency
sensitive (e.g., bufferless sensors). Time/loss sensitive applications may have
somewhat special requirements especially for loss (e.g., no loss in two
consecutive communication cycles; very low outage time, etc.).DetNet flows have the following attributes:
DnFlowID ()DnPayloadType ()DnFlowFormat ()DnFlowSpecification ()DnTrafficSpecification ()DnFlowEndpoints ()DnFlowRank ()DnFlowStatus ()DetNet flows have the following requirement attributes:
DnFlowRequirements ()DnFlowBiDir ()Flow attributes are described in the following sections.A unique (management) identifier is needed for each DetNet flow within the
DetNet domain. It is specified in DnFlowID. It can be used to define the M:1
mapping of DetNet flows to a DetNet service.DnPayloadType attribute is set according to encapsulated App-flow format.
The attribute can be Ethernet, MPLS, or IP.DnFlowFormat attribute is set according to DetNet PSN technology.
The attribute can be MPLS or IP.Identification options for DetNet flows at the Ingress/Egress and within the DetNet
domain are specified as follows; see for
DetNet MPLS flows and for DetNetw IP flows.Identification of DetNet MPLS flows within the DetNet domain are used in
the service information model. The attributes are specific to the MPLS forwarding
paradigm within the DetNet domain .
DetNetwork MPLS flows can be identified and specified by the following attributes:
SLabelFLabelStackDetNet IP flows can be identified and specified by the following attributes
(6-tuple) :
SourceIpAddressDestinationIpAddressIPv6FlowLabelDscpProtocolSourcePortDestinationPortDnTrafficSpecification attributes specify how the DN Ingress transmits packets for the DetNet flow.
This is effectively the promise/request of the DN Ingress to the network. The network uses
this traffic specification to allocate resources and adjust queue parameters in network
nodes.TrafficSpecification has the following attributes:
Interval: the period of time in which the traffic specification cannot be exceeded.MaxPacketsPerInterval: the maximum number of packets that the Ingress will transmit in one Interval.MaxPayloadSize: the maximum payload size that the Ingress will transmit. These attributes can
be used to describe any type of traffic (e.g., CBR, VBR, etc.) and can be used
during resource allocation to represent worst case scenarios.
[[Editor's note (to be removed from a future revision): Further optional
attributes can be considered to achieve more efficient resource allocation.
Such optional attributes might be worth for flows with soft requirements (i.e.,
the flow is only loss sensitive or only delay sensitive, but not both d
elay-and-loss sensitive). Possible options how to extend DnTrafficSpecification
attributes is for further discussion. ]]
DnFlowEndpoints attribute defines the starting and termination reference points
of the DetNet flow by pointing to the ingress interface/node and egress
interface(s)/node(s). Depending on the network scenario it defines an interface
or a node. Interface can be defined for example if the App-flow is a TSN Stream
and it is received over a well defined UNI interface. For exampe for App-flows
with MPLS encapsulation defining an ingress node is more common when per platform
label space is used. DnFlowRank provides the rank of this flow relative to other flows in the DetNet domain.
Rank (range: 0-255) is used by the DetNet domain to decide which flows can and cannot exist when network
resources reach their limit. Rank is used to help to determine which flows can be
dropped (i.e., removed from node configuration) if for example a port of a node becomes
oversubscribed (e.g., due to network re-configuration).DnFlowStatus provides the status of the DetNet flow with respect to the
establishment of the flow by the DetNet domain. The DnFlowStatus SHALL include the following attributes:
DnIngressStatus is an enumeration for the status of the flow´s Ingress reference point:
None: no Ingress.Ready: Ingress is ready.Failed: Ingress failed.OutOfService: Administratively blocked.DnEgressStatus is an enumeration for the status of the flow´s Egress reference points:
None: no Egress.Ready: all Egresses are ready.PartialFailed: One or more Egress ready, and one or more Egress failed.
The DetNet flow can be used if the Ingress is Ready.Failed: All Egresses failed.OutOfService: Administratively blocked.FailureCode: A non-zero code that specifies the problem if the DetNet flow
encounters a failure (e.g., packet replication and elimination is requested
but not possible, or DnIngressStatus is Failed, or DnEgressStatus is Failed, or
DnEgressStatus is PartialFailed).[[Editor's note (to be removed from a future revision): FailureCodes to be defined
for DetNet. Table 46-1 of describes TSN failure codes.]]
DnFlowRequirements specifies requirements to ensure proper serving of
the DetNet flow.The DnFlowRequirements includes the following attributes:
MinBandwidthMaxLatencyMaxLatencyVariationMaxLossMaxConsecutiveLossToleranceMaxMisorderingMinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet
flow.MaxLatency is the maximum latency from Ingress to Egress(es) for a single
packet of the DetNet flow. MaxLatency is specified as an integer number of
nanoseconds.
MaxLatencyVariation is the difference between the minimum and the maximum
end-to-end one-way latency.MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for the DetNet
flow between the Ingress and Egress(es).Some applications have special loss requirement, like MaxConsecutiveLossTolerance.
The maximum consecutive loss tolerance parameter describes the maximum number
of consecutive packets whose loss can be tolerated. The maximum consecutive
loss tolerance can be measured for example based on sequence number.MaxMisordering describes the tolerable maximum number of packets that can
be received out of order. The maximum allowed misordering can be measured
for example based on sequence number. The value zero for the maximum allowed
misordering indicates that in order delivery is required, misordering cannot
be tolerated.DnFlowBiDir attribute defines the requirement whether the served packets have to be
routed together with packets of other flows through the DetNet domain, e.g.,
to provide congruent paths in the two directions. DetNet service have the following attributes:
DnServiceID ()DnServiceDeliveryType ()DnServiceDeliveryProfile ()DNServiceConnectivity ()DnServiceBiDir ()DnServiceRank ()DnServiceStatus ()Service attributes are described in the following sections.A unique (management) identifier is needed for each DetNet service within the
DetNet domain. It is specified in DnServiceID. It can be used to define the M:1
mapping of DetNet flows to a DetNet service.DnServiceDeliveryType attribute is set according to the payload of the served
DetNet flow (i.e., the encapsulated App-flow format). The attribute can be
Ethernet, MPLS, or IP.DnServiceDeliveryProfile specifies delivery profile to ensure proper serving of
the DetNet flow.The DnServiceDeliveryProfile includes the following attributes:
MinBandwidthMaxLatencyMaxLatencyVariationMaxLossMaxConsecutiveLossToleranceMaxMisorderingMinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet
service.MaxLatency is the maximum latency from Ingress to Egress(es) for a single
packet of the DetNet flow. MaxLatency is specified as an integer number of
nanoseconds.
MaxLatencyVariation is the difference between the minimum and the maximum
end-to-end one-way latency.MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the DetNet
service between the Ingress and Egress(es) of the DetNet domain.Some applications have special loss requirement, like MaxConsecutiveLossTolerance.
The maximum consecutive loss tolerance parameter describes the maximum number
of consecutive packets whose loss can be tolerated. The maximum consecutive
loss tolerance can be measured for example based on sequence number.MaxMisordering describes the tolerable maximum number of packets that can
be received out of order. The maximum allowed misordering can be measured
for example based on sequence number. The value zero for the maximum allowed
misordering indicates that in order delivery is required, misordering cannot
be tolerated.Two connectivity types are distinguished: point-to-point (p2p) and
point-to-multipoint (p2mp). Connectivity type p2mp is created by a transport
layer function (e.g., p2mp LSP). (Note: mp2mp connectivity is a superposition
of p2mp connections.)DnServiceBiDir attribute defines the requirement whether the served packets have to be
routed together with packets of other service instances through the DetNet
domain, e.g., to provide congruent paths in the two directions. DnServiceRank attribute provides the rank of a service instance relative to other
services in the DetNet domain. DnServiceRank (range: 0-255) is used by the
network in case of network resource limitation scenarios.DnServiceStatus information group includes elements that specify the
status of the service specific state of the DetNet domain. This information
group informs the user whether or not the service is ready for use.The DnServiceStatus SHALL include the following attributes:
DnServiceIngressStatus is an enumeration for the status of the service´s Ingress:
None: no Ingress.Ready: Ingress is ready.Failed: Ingress failed.OutOfService: Administratively blocked.DnServiceEgressStatus is an enumeration for the status of the service´s Egress:
None: no Egress.Ready: all Egresses are ready.PartialFailed: One or more Egress ready, and one or more Egress failed.
The DetNet flow can be used if the Ingress is Ready.Failed: All Egresses failed.OutOfService: Administratively blocked.DnServiceFailureCode: A non-zero code that specifies the problem if the DetNet service
encounters a failure (e.g., packet replication and elimination is requested
but not possible, or DnServiceIngressStatus is Failed, or DnServiceEgressStatus is Failed, or
DnServiceEgressStatus is PartialFailed).[[Editor's note (to be removed from a future revision): DnServiceFailureCodes to be defined
for DetNet service. Table 46-1 of describes TSN failure codes.]]
The DetNet flow information model relies on three high level information groups:
DnIngress: The DnIngress information group includes elements that specify the source for a single DetNet flow. This information group is applied from the user of the DetNet service to the network.DnEgress: The DnEgress information group includes elements that specify the destination for a single DetNet flow. This information group is applied from the user of the DetNet service to the network.DnFlowStatus: The status information group includes elements that specify the status of the flow in the network. This information group is applied from the network to the user of the DetNet service. This information group informs the user whether or not the DetNet flow is ready for use.There are three possible operations for each DetNet flow with respect to its DetNet service at a DN Ingress or a DN Egress (similarly to App-flows at a Source or a Destination):
Join: DN Ingress/DN Egress intends to join the flow.Leave: DN Ingress/DN Egress intends to leave the flow.Modify: DN Ingress/DN Egress intends to change the flow.For the join operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint,
and DnTrafficSpecification SHALL be included within the DnIngress or DnEgress
information group. For the join operation, the DnServiceRequirements groups
MAY be included.For the leave operation, the DnFlowSpecification and DnFlowEndpoint SHALL
be included within the DnIngress or DnEgress information group.For the modify operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint,
and DnTrafficSpecification SHALL be included within the DnIngress or DnEgress
information group. For the join operation, the DnServiceRequirements groups
MAY be included.
Modify operation can be considered to address cases when a flow is slightly
changed, e.g., only MaxPayloadSize () has been
changed. The advantage of having a Modify is that it allows to initiate a change
of flow spec while leaving the current flow is operating until the change is
accepted. If there is no linkage between the Join and the Leave, then in figuring
out whether the new flow spec can be supported, the controller entity has to assume
that the resources committed to the current flow are in use. Via Modify the controller
entity knows that the resources supporting the current flow can be available for
supporting the altered flow. Modify is considered to be an optional operation due
to possible controller plane limitations.
This document describes DetNet flow information model and service information model for DetNet IP networks and DetNet MPLS networks. N/A.N/A.IETF Deterministic Networking (DetNet) Working GroupIETFIEEE Std 802.1Q-2018 IEEE Standard for Local and metropolitan area networks - Bridges and Bridged NetworksIEEE Standards AssociationIEEE Std 802.1Qbv-2015 IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled TrafficIEEE Standards AssociationIEEE Std 802.1Qcc-2018: IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance ImprovementsIEEE Standards AssociationIEEE Std 802.1CB-2017 IEEE Standard for Local and metropolitan area networks - Frame Replication and Elimination for ReliabilityIEEE Standards AssociationIEEE 802.1 Time-Sensitive Networking (TSN) Task GroupIEEE 802.1