DetNet Flow Information ModelEricssonMagyar tudosok korutja 11BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar tudosok korutja 11BudapestHungary1117janos.farkas@ericsson.comNational Instruments11500 N. Mopac ExpwyBldg. CAustin, TXUSA78759-3504rodney.cummings@ni.comHuawei Technologies Co., Ltd.Bantian, Longgang districtShenzhenChina518129jiangyuanlong@huawei.comLabN Consulting, L.L.C.dfedyk@labn.net
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 planes
Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and concepts
of DetNet can be found in .
This document describes the Detnet Flow and Service Information Model.
For reference describes the rational behind Information
Models in general. This document describes the Flow and Service information
models for operators and users to understand Detnet services, and for implementors
as a guide to the functionality required by Detnet services.
The DetNet Architecture treats the DetNet related data plane functions
decomposed into two sub-layers: a service sub-layer and a forwarding
sub-layer. The service sub-layer is used to provide DetNet service
protection and reordering. The forwarding sub-layer provides
resource allocation (to ensure low loss, assured latency, and limited
out-of-order delivery) and leverages Traffic Engineering mechanisms.
In the IETF DetNet service utilizes 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 .
IEEE 802.1 Time Sensitive Networking (TSN) utilizes Ethernet and
is defined over Ethernet networks. A DetNet flow includes one or more
App-flow(s) as payload. App-flows can be Ethernet, MPLS, or IP flows,
which impacts which header fields are utilized to identify a flow.
DetNet flows are identified by the DetNet encapsulation of App-flow(s) (e.g.,
MPLS labels, IP 6-tuple 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 be distinguished:
Flow models that 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 that 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 that describe in detail the settings required on
network nodes to provide a data flow proper service.
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
DetNet flow and service information models described in this document
are based on . In addition to
the TSN data model, also specifies
configuration of TSN features (e.g., traffic scheduling specified by
). The common architecture and flow
model, allow configured features to be consistent in certain deployment
scenarios, e.g., when the network that provides the DetNet service
includes both L3 and L2 network segments.
As 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. This is beneficial for
several reasons, e.g., in order to simplify implementations and
maintain consistency across diverse networks. The flow and service
information models are also aligned for those reasons. Therefore, the
DetNet flow and service information models described in this document
are based on , which is an amendment to
.
This document specifies flow and service information models only.
This document does not specify flow data models or
DetNet configuration. Therefore, the goals of this document
differ from the goals of , which also
specifies the TSN data model and configuration of certain TSN features.
This document uses the terminology established in the DetNet architecture
and 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 in accordance with :
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 the start of a DetNet flow. Networking
technology specific encapsulation may be added here to the served
App-flow(s).
Reference point for the termination of a DetNet flow. 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.
Descriptive names are used.Names start with uppercase letters.
Composed names 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. Example composed names are SourceMacAddress and
DestinationIPv6Address.
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
has reference points termed DN Ingress (where a DetNet flow starts) and DN
Egress (where a DetNet flow 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 parameters: these describe the App-flow
characteristics (e.g., identification, encapsulation, traffic
specification, endpoints, status, etc.) and the App-flow
service expectations (e.g., delay, loss, etc.).
DetNet flow related parameters: these describe the DetNet flow
characteristics (e.g., identification, format, traffic
specification, endpoints, rank, etc.).
DetNet service related parameters: these 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 (aggregated) App-flows
(N:1 mapping). During DetNet aggregation the aggregated DetNet flows
are treated simply as App-flows and the aggregate is the DetNet flow, which
provides N:1 mapping. Similarly, there is an aggregated many to one relationship for
the DetNet flow(s) to the DetNet Service.
When Deterministic service is required by time/loss sensitive
application(s) running on an end system during communication with its
peer(s), the resulting data exchange has various requirements on delay
and/or loss parameters.
App-flow characteristics are described by the following parameters:
FlowID: 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: set by the encapsulation format of the flow.
It can be Ethernet (TSN), MPLS, or IP.DataFlowSpecification: a flow descriptor, defining which packets
belongs to a flow, using specific packet header fields such as
src-addr, dst-addr, label, VLAN-ID, etc.TrafficSpecification: a flow descriptor, defining traffic
parameters such as packet size, transmission time
interval, and maximum packets per time interval.FlowEndpoints: delineate the start and termination reference
points of the App-flow by pointing to the source
interface/node and destination interface(s)/node(s).FlowStatus: indicates the status of the App-flow with respect to
the establishment of the flow by the connected network, e.g.,
ready, failed, etc.FlowRank: indicates the rank of this flow relative to other
flows in the connected network.
Note: When defining the N:1 mapping of App-flows to a DetNet flow,
the App-flows must have the same FlowType and different
DataFlowSpecification parameters
App-flow requirements are described by the following parameters:
FlowRequirements: defines the attributes of the App-flow regarding
bandwidth, latency, latency variation, loss, and misordering tolerance.FlowBiDir: defines the data path requirement of the App-flow
whether it must share the same data path and physical
path for both directions through the network, e.g., to
provide congruent paths in the two directions.
The 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 applied for flows using DetNet service.
Latency and loss parameters are correlated because the effect of late
delivery can result in data loss for an application. However, not all
applications require hard limits on both latency and loss.
For example, some real-time applications allow graceful degradation if
loss happens (e.g., sample-based data processing, media distribution). Some
other applications may require high-bandwidth connections that make use of
packet replication techniques which are economically challenging or even
impossible. Some applications may not tolerate loss, but are not
delay sensitive (e.g., bufferless sensors). Time or loss sensitive
applications may have somewhat special requirements especially for loss
(e.g., no loss over 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 by DnFlowID. It can be used to define the many to one
mapping of DetNet flows to a DetNet service.The DnPayloadType attribute is set according to the encapsulated App-flow format.
The attribute can be Ethernet, MPLS, or IP.The DnFlowFormat attribute is set according to the 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.
The identification of DetNet MPLS flows within the DetNet domain is
based on the MPLS context in the service information model. The
attributes are specific to the MPLS forwarding paradigm within the
DetNet domain . DetNet MPLS
flows can be identified and specified by the following attributes:
SLabelFLabelStackDetNet IP flows can be identified and specified by the following attributes
:
SourceIpAddressDestinationIpAddressIPv6FlowLabelDscp (attribute)ProtocolSourcePortDestinationPortIPSecSpiThe IP 6-tuple that is used for DetNet IP flow identification consists
of items a, b, d, e, f, and g. Items c and h are additional attributes
that can be used for DetNet flow identification in addition to the 6-tuple.
Using wild cards for these attributes are specified in
.
DnTrafficSpecification 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 is specified.
MaxPacketsPerInterval: the maximum number of packets that the
Ingress will transmit in one Interval.
MaxPayloadSize: the maximum payload size that the Ingress
will transmit.
MinPayloadSize: the minimum payload size that the Ingress
will transmit.
MinPacketsPerInterval: the minimum number of packets that the
Ingress will transmit in one Interval.
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. Intervals are specified as an integer
number of nanoseconds. PayloadSizes are specified in octets per
second.
When MinPayloadSize and MinPacketsPerInterval parameters are used,
then all packets less than the MinPayloadSize will be counted as
being of the size MinPayloadSize during packet processing when
packet size matters, e.g., when policing; and all flows having less
than MinPacketsPerInterval will be counted as having
MinPacketsPerInterval when the number of packets per interval
matters, e.g., during resource reservation. However, flows having
less than MinPacketsPerInterval may result in a different network
behavior than the DetNet network has been engineered for.
MinPayloadSize and MinPacketsPerInterval parameters, for example,
may be used when engineering the latency bounds of a DetNet flow
when POF is applied to the given DetNet flow.
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
delay-and-loss sensitive). Possible options how to extend
DnTrafficSpecification attributes is for further discussion.
The 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 example, for App-flows with MPLS
encapsulation defining an ingress node is more common when per platform
label space is used.
The DnFlowRank attribute 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
bumped (i.e., removed from node configuration thereby releasing its
resources) if for example a port of a node becomes oversubscribed (e.g.,
due to network re-configuration). DnFlowRank value 0 is the highest priority.
DnFlowStatus provides the status of the DetNet flow with respect to the
establishment of the flow by the DetNet domain. The DnFlowStatus includes 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: All Egresses are administratively blocked.
FailureCode: A non-zero code that specifies the error
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).
Defining FailureCodes for DetNet is out-of-scope in this document.
Table 46-1 of describes TSN failure codes.
DnFlowRequirements specifies requirements to ensure the service level
desired for the DetNet flow.
The DnFlowRequirements includes the following attributes:
MinBandwidth()MaxLatency()MaxLatencyVariation()MaxLoss()MaxConsecutiveLossTolerance()MaxMisordering()
MinBandwidth is the minimum bandwidth that has to be guaranteed for
the DetNet flow. MinBandwidth is specified in octets per second.
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. MaxLatencyVariation is specified as an
integer number of nanoseconds.
MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
the DetNet flow between the Ingress and Egress(es) and the loss
measurement interval.
Some applications have special loss requirement, such as
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 value zero for the maximum
allowed misordering indicates that in order delivery is required,
misordering cannot be tolerated.
The maximum allowed misordering can be measured for example based
on sequence number. The difference of sequence number values in
consecutive packets at the Egress cannot be bigger than
"MaxMisordering + 1".
DnFlowBiDir attribute defines the requirement that the flow and
the corresponding reverse direction flow must share the same path
(links and nodes) through the routed or switch network in the DetNet
domain, e.g., to provide congruent paths in the two directions that
share fate and path characteristics.
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 for each DetNet service within
the DetNet domain. It can be used to define the many to one
mapping of DetNet flows to a DetNet service.
The 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:
MinBandwidth()MaxLatency()MaxLatencyVariation()MaxLoss()MaxConsecutiveLossTolerance()MaxMisordering()
MinBandwidth is the minimum bandwidth that has to be guaranteed for
the DetNet service. MinBandwidth is specified in octets per second
and excludes additional DetNet header (if any).
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. MaxLatencyVariation is specified
as an integer number of nanoseconds.
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, such as
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 may be created by
a forwarding function (e.g., p2mp LSP). (Note: from service
perspective mp2mp connectivity can be treated as a superposition of
p2mp connections.)
The DnServiceBiDir attribute defines the requirement that the flow and
the corresponding reverse direction flow must share the same path
(links and nodes) through the routed or switch network in the DetNet
domain, e.g., to provide congruent paths in the two directions that
share fate and path characteristics.
The 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. DnServiceRank value 0 is the highest priority.
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 includes 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 error 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).
Defining DnServiceFailureCodes for DetNet service is out-of-scope
in this document. 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 are included within
the DnIngress or DnEgress information group. For the join operation,
the DnServiceRequirements groups can be included.
For the leave operation, the DnFlowSpecification and DnFlowEndpoint are
included within the DnIngress or DnEgress information group.For the modify operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint,
and DnTrafficSpecification are included within the DnIngress or DnEgress
information group. For the join operation, the DnServiceRequirements groups
can be included.
The 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 initiation of 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
while 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. By using 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 the DetNet flow information model and the service
information model for DetNet IP networks and DetNet MPLS networks.
These models are used as input for creating the DetNet specific
YANG model.
N/A.
The external interfaces of the DetNet domain need to be subject to
appropriate confidentiality. Additionally, knowledge of which flows/services
are provided to a customer or delivered by a network operator may supply
information that can be used in a variety of security attacks.
Security considerations for DetNet are described in detail in
. General security considerations
are described in .
This document discusses modeling the information, not how it is
exchanged.
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 Association