DetNet Data Plane FrameworkEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comLabN Consulting, L.L.C.lberger@labn.netLabN Consulting, L.L.C.dfedyk@labn.netIndependentagmalis@gmail.comFuturewei Technologiesstewart.bryant@gmail.comjouni.nospam@gmail.comDetNet
This document provides an overall framework for the Deterministic
Networking data plane. It covers concepts and considerations that
are generally common to any Deterministic Networking data plane
specification.
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 concepts needed by any DetNet data plane specification
and provides considerations for any corresponding implementation.
It covers the building blocks that provide the DetNet service, the
DetNet service sub-layer and the DetNet forwarding sub-layer functions
as described in the DetNet Architecture.
The DetNet Architecture models 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 is used to provide
congestion protection (low loss, assured latency, and limited
out-of-order delivery) and leverages Traffic Engineering mechanisms.
As part of the service sub-layer functions, this document describes
typical DetNet node data plane operation. It describes the function
and operation of the Packet Replication (PRF) Packet Elimination
(PEF) and the Packet Ordering (POF) functions within the service
sub-layer. It also describes the forwarding sub-layer that is used to eliminate
(or reduce) contention loss and provide bounded latency for DetNet
flows.
DetNet flows may be carried over network technologies that can provide
the DetNet required service characteristics. For example, DetNet MPLS flows
can be carried over IEEE 802.1 Time Sensitive Network (TSN) sub-networks. However, IEEE 802.1 TSN
support is not required and some of the DetNet benefits can be gained
by running over a data link layer that has not been specifically
enhanced to support TSN.
Different traffic types, or application flows, can be mapped on top of
DetNet. DetNet can optionally reuse header information provided by, or
shared with, applications. An example of shared header fields can be
found in .
This document also covers
concepts related to the controller plane and Operations,
Administration, and Maintenance (OAM) functions related to the
control plane. Data plane OAM specifics are out of scope for this docuement.
This document uses the terminology established in the DetNet
architecture ,
and the reader is assumed to be familiar with that document
and its terminology.
The following abbreviations are used in this document:
Control Word.Deterministic Networking.Generic Routing Encapsulation.IP Security.Layer 2.Label Switching Router.Multiprotocol Label Switching.Multiprotocol Label Switching - Traffic Engineering.Operations, Administration, and Maintenance.Packet Elimination Function.Packet Replication Function.Packet Replication, Elimination and Ordering Functions.Packet Ordering Function.Packet Switched Network.PseudoWire.Quality of Service.Time-Sensitive Network.
This document describes how application flows, or app-flows, are
carried over DetNet networks. The DetNet Architecture, , models the DetNet
related data plane functions decomposed into two sub-layers: a service
sub-layer and a forwarding sub-layer.
reproduced from the ,shows a logical DetNet service with the two
sub-layers.
The DetNet forwarding sub-layer may be directly provided by the DetNet
service sub-layer, for example by IP tunnels or MPLS.
Alternatively, an overlay approach
may be used in which the packet is natively carried between key nodes
within the DetNet network (say between PREOF nodes) and a sub-layer is
used to provide the information needed to reach the next hop in the
overlay.
The forwarding sub-layer provides the quality underpin needed by the
DetNet flow. It may do this directly through the use of
queuing techniques and traffic engineering methods, or it may do this
through the assistance of its underlying connectivity. For example it
may call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN
.
The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer. An example
of this is Packet Replication, Elimination, and Ordering (PREOF)
functions see .
The method of instantiating each of the layers is specific to the
particular DetNet data plane method. There may be more than one approach
that is applicable to a given bearer network type.
There are two major characteristics to the data plane:
Data plane technology: The DetNet data plane is provided by the DetNet
service and forwarding sub layers. The DetNet service sub-layer
generally provides its functions for the DetNet application flows by using or applying
existing standardized headers and/or encapsulations. The Detnet
forwarding sub-layer may provide capabilities leveraging that same
header or encapsulation technology e.g. or it
may be achieved by other technologies e.g. .
DetNet is currently defined for operation over packet switched (IP)
networks or label switched (MPLS) networks.
Encapsulation format: DetNet encodes specific flow attributes
(namely flow identity and sequence number) in packets.
For example, in DetNet IP,
zero encapsulation may be used and no sequence number
is available, and in DetNet MPLS, DetNet specific information may be added
explicitly to the packets in the format of S-label and d-CW.
The encapsulation of the DetNet flows allows them to be sent over a
data plane technology other than their native type. Encapsulation is
essential if, for example, it is required to send Ethernet TSN
stream as a DetNet Application over a data plane such as MPLS.
illustrates some relationships
between the components.
The use of encapsulation is also required if additional information
(meta-data) is needed by the DetNet data plane and there is either
no ability to include it in the client data packet, or the
specification of the client data plane does not permit the
modification of the packet to include additional data. An example of
such meta-data is the inclusion of a sequence number required by the
PREOF function.
Encapsulation may also be used to carry or aggregate flows for equipment with limited
DetNet capability.
The DetNet data plane can provide or carry meta-data:
Flow-ID
Sequence Number
Both of these metadata are required for DetNet service
sub-layer specific functions (e.g., PREOF). DetNet forwarding
sub-layer related functions require only Flow-ID.
Metadata can be a useful way of identifying packets that need to be
treated as a flow or flow aggregate. It is also useful as a way of
including a sequence number the packet for use by the PREOF function
or as a place to carry OAM indications or OAM information to
instrument DetNet data plane operation.
Explicit inclusion of metadata is possible through the use of
IP options or IP extension headers. New IP options are almost impossible
to get standardized or to deploy in an operational network and will
not be discussed further in this text. IPv6 extensions headers are
finding popularity in current IPv6 development work, particularly
in connection with Segment Routing of IPv6 (SRv6) and IP OAM. The design
of a new IPv6 extension header or the modification of an existing one is
a technique available in the tool box of the DetNet IP data plane designer.
Explicit inclusion of metadata in an IP packet is also possible
through the inclusion of an MPLS label stack and the MPLS DetNet
Control Word using one of the methods for carrying MPLS over IP . This is described in more
detail in .
Implicit metadata in IP can be included through the use of the network
programming paradigm in which the
suffix of an IPv6 address is used to encode additional information
for use by the network of the receiving host.
Some MPLS examples of implicit metadata include the sequence number for use by
the PREOF function, or even all the essential information being
included into the DetNet over MPLS label stack (the DetNet Control
Word and the DetNet Service label).
An IP data plane may operate natively or through the use of an
encapsulation.
Many types of IP encapsulation can satisfy DetNet requirements
and it is anticipated that more than one encapsulation
may be deployed for example GRE, IPSec etc.
One method of operating an IP DetNet data plane without encapsulation
is to use "6-tuple" based flow identification, where "6-tuple" refers
to information carried in IP and higher layer protocol headers.
General background on the use of IP headers, and "6-tuples", to
identify flows and support Quality of Service (QoS) can be found in
. also provides
useful background on the delivery differentiated services (DiffServ)
and "tuple" based flow identification. DetNet flow aggregation may
be enabled via the use of wildcards, masks, prefixes and ranges. The
operation of this method is described in detail in .
The DetNet forwarding plane may use explicit route capabilities and
traffic engineering capabilities to provide a forwarding sub-layer
that is responsible for providing resource allocation and explicit
routes. It is possible to include such information in a native IP packet
explicitly, or implicitly.
MPLS provides the ability to forward traffic over implicit
and explicit paths to the point in the network where the next
DetNet service sub-layer action needs to take place. It does this
through the use of a stack of one or more labels with various
forwarding semantics.
MPLS also provides the ability to identify a service instance
that is used to process the packet through the use of a label that
maps the packet to a service instance.
In cases where metadata is needed to process an MPLS encapsulated
packet at the service sub-layer, a shim layer also called a control
word (CW) can be used. Although such CWs
are frequently 32 bits long, there is no architectural constraint on
its size of this structure, only the requirement that it is fully
understood by all parties operating on it in the DetNet service
sub-layer. The operation of this method is described in detail in
.
This section provides informative considerations related to
providing DetNet service to flows which are identified
based on their header information. At a high level, the
following are provided on a per flow basis:
Reservation of resources can allocate resources to specific DetNet
flows. This can eliminate packet contention and loss for DetNet
traffic. This also can reduce jitter for the DetNet traffic. DetNet
flows are assumed to behave with respect to the reserved traffic
profile. If other traffic shares the link resources, the use of
(queuing, policing, shaping) policies can be used to ensure that the
allocation of resources reserved for DetNet is met. Queuing and shaping
of DetNet traffic could be required to ensure that DetNet traffic does
not exceed its reserved profile but this would impact the DetNet
service characteristics.
Use of a specific path for a flow. This allows control of the network
delay by steering the packet with the ability to influence the physical
path. Explicit routes complement reservation by ensuring that a
consistent path can be associated with its resources for the duration
of that path. Coupled with the traffic mechanism, this limits
misordering and bounds latency. Explicit route computation can
encompass a wide set of constraints and optimize the path for a certain
characteristic e.g. highest bandwidth or lowest jitter. In these cases
the "best" path for any set of characteristics may not be a shortest
path. The selection of path can take into account multiple network
metrics. Some of these metrics are measured and distributed by the
routing system as traffic engineering metrics.
Use of multiple packet streams using multiple paths, for example 1+1 or
1:1 linear protection. For DetNet this primarily relates to packet
replication and elimination capabilities.
MPLS offers a number of protection schemes.
MPLS hitless protection can be used to switch traffic to an already established path
in order to restore delivery rapidly after a failure.
Path changes, even in the case of failure recovery, can lead to the out of
order delivery of data requiring packet ordering functions either
within the DetNet service or at a high layer in the application
traffic. Establishment of new paths after a failure is out of scope
for DetNet services.
Network Coding, not to be confused with network programming,
comprises
several techniques where multiple data flows are encoded. These
resulting flows can then be sent on different paths. The encoding
operation can combine flows and error recovery information. When the
encoded flows are decoded and recombined the original flows can be
recovered. Note that Network coding uses an alternative to packet by
packet PREOF. Therefore, for certain network topologies and traffic
loads, Network Coding can be used to improve a network's throughput,
efficiency, latency, and scalability, as well as resilience to
partition, attacks, and eavesdropping, as compared to traditional
methods. DetNet could utilized Network coding as an alternative to
other protection means. Network coding is often applied in wireless
networks and is being explored for other network types.
Use of packet by packet distribution of the same DetNet flow over
multiple paths is not recommended except for the cases listed above
where PREOF is utilized to improve protection of traffic and maintain order.
Packet by packet load sharing, e.g., via ECMP or UCMP, impacts ordering and
possibly jitter.
Since Detnet leverages many different forwarding sub-layers, those
technologies also support a number of tools to troubleshoot connectivity
for example, to support identification of misbehaving flows. At the service layer
again there are existing mechanisms to troubleshoot or monitor flows.
Many of these mechanisms exist for IP and MPLS networks.
A client of a DetNet service can introduce any monitoring applications
which can detect and monitor delay and loss.
To a large degree this follows the logic in the previous section.
Analytics can be inherited from the two sub-layers. At the DetNet service
edge packet and bit counters e.g. sent, received, dropped, and out of
sequence are maintained.
The provider of a DetNet service may allow other capabilities to monitor flows
such as more detail loss statistics and time stamping of events. The details
of these capabilities are currently out of scope for this document.
Several of these capabilities are expanded upon in more detail below.
Service protection allow DetNet services to increase reliability and
maintain a DetNet Service Assurance in the case of network congestion or
some failures. Detnet relies on the underlying technology capabilities
for various protection schemes. Protection schemes enable partial or
complete coverage of the network paths and active protection with
combinations of PRF, PRE, and POF.
An example DetNet MPLS network fragment and packet flow is illustrated in
.
In the numbers are used to identify the
instance of a packet. Packet 1 is the original packet, and packets 1.1, and
1.2 are two first generation copies of packet 1. Packet 1.2.1 is a second
generation copy of packet 1.2 etc. Note that these numbers never appear in
the packet, and are not to be confused with sequence numbers, labels or any
other identifier that appears in the packet. They simply indicate the
generation number of the original packet so that its passage through the
network fragment can be identified to the reader.
Customer Equipment CE1 sends a packet into the DetNet enabled network. This
is packet (1). Edge Node EN1 encapsulates the packet as a DetNet Packet and
sends it to Relay node R1 (packet 1.1). EN1 makes a copy of the packet
(1.2), encapsulates it and sends this copy to Relay node R4.
Note that along the path from EN1 to R1 there may be zero or more nodes
which, for clarity, are not shown. The same is true for any other path
between two DetNet entities shown in .
Relay node R4 has been configured to send one copy of the packet to Relay
Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 1.2.2).
R2 receives packet copy 1.2.1 before packet copy 1.1 arrives, and, having
been configured to perform packet elimination on this DetNet flow, forwards
packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of no further use and so
is discarded by R2.
Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives packet
copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips any DetNet
encapsulation from packet copy 1.2.2 and forwards the packet to CE2. When
EN2 receives the later packet copy 1.2.1 this is discarded.
The above is of course illustrative of many network scenarios that can be
configured.
This example also illustrates 1:1 protection scheme meaning there is
traffic and path for each segment of the end to end path. Local DetNet
relay nodes determine which packets are eliminated and which packets are
forwarded. A 1+1 scheme where only one path is used for traffic at a
time, could use the same topology. In this case there is no PRF function
and traffic is switched upon detection of failure. An OAM scheme that
monitors the paths detects the loss of path or traffic is required to
initiate the switch. A POF may still be used in this case to
prevent misordering of packets. In both cases the protection paths are
established and maintained for the duration of the DetNet service.
Ring protection may also be supported if the underlying technology
supports it. Many of the same concepts apply however Rings are normally
1+1 protection for data efficiency reasons. is an
example of MPLS-TP data plane that supports Ring protection.
The DetNet data plane also allows for the aggregation of DetNet flows, to
improved scaling by reducing the state per hop. How this is accomplished is data
plane or control plane dependent. When DetNet flows are aggregated, transit
nodes provide service to the aggregate and not on a per-DetNet flow basis.
When aggregating DetNet flows the flows should be compatible i.e. the same or
very similar QoS and CoS characteristics. In this case, nodes performing
aggregation will ensure that per-flow service requirements are achieved.
If bandwidth reservations are used, the sum of the reservations should be the
sum of all the individual reservations, in other words, the reservations
should not create an over subscription of bandwidth reservation. If maximum
delay bounds are used the system should ensure that the aggregate does not
exceed the delay bounds of the individual flows.
DetNet encapsulation is a data plane mechanism that can be used to aggregate
traffic. Encapsulation can either be in the same service type or in a
different service type see for example. When
an encapsulation is used the choice of reserving a maximum resource level and
then tracking the services in the aggregated service or adjusting the
aggregated resources as the services are added is implementation and
technology specific.
DetNet flows at edges must be able to handle rejection to an aggregation
group due to lack of resources as well as conditions where general
requirements are not satisfied.
IP aggregation has both data plane and controller plane aspects. For the
data plane flows may be aggregated for treatment based on shared
characteristics such as 6-tuple. Alternatively, an IP encapsulation may be
used to tunnel an aggregate number of DetNet Flows between relay nodes.
MPLS aggregation similarly has data plane and controller plane aspects. In the case of MPLS
flows are often tunneled in a forwarding sub-layer and reservation is associated with that MPLS tunnel.
Data-flows requiring DetNet service are generated and terminated on
end-systems. Encapsulation depends on the application and its
preferences. For example, a DetNet MPLS domain the DN functions use the d-CWs,
S-Labels and F-Labels to provide DetNet services. However, an
application may exchange further flow related parameters (e.g.,
time-stamp), which are not provided by DN functions.
As a general rule, DetNet domains are capable of forwarding any
DetNet flows and the DetNet domain does not mandate the
end-system or edge system encapsulation format. Unless there is a
proxy of some form present, end-systems peer with similar end-systems
using the same application encapsulation format. For example, as
shown in , IP applications peer with
IP applications and Ethernet applications peer with Ethernet
applications.
Any of the DetNet service types may be transported by another
DetNet service. MPLS nodes may interconnected by different sub-network
technologies, which may include point-to-point links. Each of these
sub-network technologies need to provide appropriate service to DetNet
flows. In some cases, e.g., on dedicated point-to-point links or TDM
technologies, all that is required is for a DetNet node to appropriately
queue its output traffic. In other cases, DetNet nodes will need to map
DetNet flows to the flow semantics (i.e., identifiers) and mechanisms used
by an underlying sub-network technology. shows several examples of header
formats that can be used to carry DetNet MPLS flows over different
sub-network technologies. L2 represent a generic layer-2 encapsulation
that might be used on a point-to-point link. TSN represents the
encapsulation used on an IEEE 802.1 TSN network, as described in . UDP/IP represents the encapsulation
used on a DetNet IP PSN, as described in .
While the definition of controller plane for DetNet is out of
the scope of this document, there are particular
considerations and requirements for such that result from the
unique characteristics of the DetNet architecture and data plane as
defined herein.
The primary requirements of the DetNet controller plane are
that it must be able to:
Instantiate DetNet flows in a DetNet domain (which may
include some or all of explicit path determination, link
bandwidth reservations, restricting flows to IEEE 802.1 TSN
links, node buffer and other resource reservations,
specification of required queuing disciplines along the
path, ability to manage bidirectional flows, etc.) as needed
for a flow.
In the case of MPLS, manage DetNet S-Label and F-Label allocation
and distribution, where the DetNet MPLS encapsulation is in use see
.
Support DetNet flow aggregation.
Advertise static and dynamic node and link resources such
as capabilities and adjacencies to other network nodes (for
dynamic signaling approaches) or to network controllers (for
centralized approaches).
Scale to handle the number of DetNet flows expected in a
domain (which may require per-flow signaling or
provisioning).
Provision flow identification information at each of the nodes
along the path. Flow identification may differ depending on the
location in the network and the DetNet functionality (e.g. transit
node vs. relay node).
These requirements, as stated earlier, could be satisfied using
distributed control protocol signaling (such as RSVP-TE),
centralized network management provisioning mechanisms (such as
BGP, PCEP, YANG , etc.) or hybrid
combinations of the two, and could also make use of MPLS-based
segment routing.
In the abstract, the results of either distributed signaling
or centralized provisioning are equivalent from a DetNet data
plane perspective - flows are instantiated, explicit routes
are determined, resources are reserved, and packets are
forwarded through the domain using the DetNet data plane.
However, from a practical and implementation standpoint, they are not
equivalent at all. Some approaches are more scalable than others in
terms of signaling load on the network. Some can take advantage of
global tracking of resources in the DetNet domain for better overall
network resource optimization. Some are more resilient than others if
link, node, or management equipment failures occur. While a detailed
analysis of the control plane alternatives is out of the scope of this
document, the requirements from this document can be used as the basis
of a later analysis of the alternatives.
This section covers control plane considerations that are
independent of the data plane technology used for DetNet service
delivery.
While management plane and control planes are traditionally
considered separately, from the Data Plane perspective there is no
practical difference based on the origin of flow provisioning
information, and the DetNet architecture refers to these collectively
as the 'Controller Plane'. This document therefore does not
distinguish between information provided by distributed control
plane protocols, e.g., RSVP-TE and , or by centralized network management mechanisms,
e.g., RestConf , YANG , and the Path Computation Element Communication
Protocol (PCEP) or any
combination thereof. Specific considerations and requirements for
the DetNet Controller Plane are discussed in .
Each respective data plane document also covers the control plane considerations
for that technology. For example covers IP
control plane normative considerations and covers MPLS control plane
normative considerations.
Flow aggregation includes aggregation accomplished through the use of
hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and TSN,
all of which aggregate multiple DetNet flows into a single new DetNet
flow. Aggregation can also be grouping of IP flows that share
6-tuple attributes or flow identifiers at the DetNet sub-layer.
Control of aggregation involves a set of procedures listed here.
Aggregation may use some or all of these capabilities and the order may vary:
Traffic engineering resource collection and distribution:
Available resources are tracked through control plane or
management plane databases and distributed amongst controllers
or nodes that can manage resources.
Path computation and resource allocation:
When DetNet services are provisioned or requested one or more
paths meeting the requirements are selected and the resources
verified and recorded.
Resource assignment and data plane co-ordination:
The assignment of resources along the path depends on the technology and it
includes assignment of specific links and coordination of the
queuing and other traffic management capabilities such as policing and shaping.
Assigned Resource recording and updating:
Depending on the specific technology the assigned resources are
updated and distributed in the databases preventing over subscription.
Explicit routes are used to ensure that packets are routed through the
resources that have been reserved for them, and hence provide the
DetNet application with the required service. A requirement for the
DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that has
been assigned the required nodal resources. This provides the
appropriate traffic treatment for the flow and also includes particular
links as a part of the path that are able to support the DetNet flow.
For example, by using IEEE 802.1 TSN links (as discussed in
) DetNet parameters can be maintained.
Further considerations and requirements for the DetNet Controller Plane
are discussed in .
Whether configuring, calculating and instantiating these
routes is a single-stage or multi-stage process, or in a
centralized or distributed manner, is out of scope of this
document.
There are several approaches that could be used to provide
explicit routes and resource allocation in the DetNet
forwarding sub-layer. For example:
The path could be explicitly set up by a controller which
calculates the path and explicitly configures each node along that
path with the appropriate forwarding and resource allocation
information.
The path could use a distributed control plane such as
RSVP or RSVP-TE extended to support DetNet IP flows.
The path could be implemented using IPv6-based segment
routing when extended to support resource allocation.
See for
further discussion of these alternatives. In addition, contains useful background information on
QoS-based routing, and discusses a
specific mechanism used by BGP for traffic flow specification
and policy-based routing.
As discussed in , this document does
not specify the mechanisms needed to eliminate packet contention, packet loss
or reduce jitter for DetNet flows at the DetNet forwarding
sub-layer. The ability to manage node and link resources to
be able to provide these functions is a necessary part of
the DetNet controller plane. It is also necessary to be
able to control the required queuing mechanisms used to
provide these functions along a flow's path through the
network. See and for further
discussion of these requirements.
DetNet applications typically generate bidirectional traffic. IP and
MPLS typically treat each direction separately and do not force
interdependence of each direction. MPLS has considered bidirectional
traffic requirements and the MPLS definitions from are useful to illustrate terms such as
associated bidirectional flows and co-routed bidirectional flows. MPLS
defines a point-to-point associated bidirectional LSP as consisting of
two unidirectional point-to-point LSPs, one from A to B and the other
from B to A, which are regarded as providing a single logical
bidirectional forwarding path. This is analogous to standard IP
routing. MPLS defines a point-to-point co-routed bidirectional LSP as
an associated bidirectional LSP which satisfies the additional
constraint that its two unidirectional component LSPs follow the same
path (in terms of both nodes and links) in both directions. An
important property of co-routed bidirectional LSPs is that their
unidirectional component LSPs share fate. In both types of
bidirectional LSPs, resource reservations may differ in each direction.
The concepts of associated bidirectional flows and co-routed
bidirectional flows can also be applied to DetNet IP flows.
While the DetNet IP data plane must support bidirectional
DetNet flows, there are no special bidirectional features with
respect to the data plane other than the need for the two
directions of a co-routed bidirectional flow to take the same
path. That is to say that bidirectional DetNet flows are
solely represented at the management and control plane levels,
without specific support or knowledge within the DetNet data
plane. Fate sharing and associated or co-routed
bidirectional flows, can be managed at the control level.
DetNet's use of PREOF may increase the complexity of using co-routing
bidirectional flows, since if PREOF is used, then the replication
points in one direction would have to match the elimination points in
the other direction, and vice versa, and the optimal points for these
functions in one direction may not match the optimal points in the
other subsequent to the network and traffic constraints.
Furthermore, due to the per packet service protection nature,
bidirectional forwarding per packet may not be ensured.
The first packet of received member flows is selected by the
elimination function independently of which path it has taken
through the network.
Control and management mechanisms need to support bidirectional flows,
but the specification of such mechanisms are out of scope of this
document. An example control plane solution for MPLS can be found in , and . These requirements are included in .
The controller plane protocol solution required for managing the
PREOF processing is outside the scope of this document. That
said, it should be noted that the ability to determine, for a
particular flow, optimal packet replication and elimination
points in the DetNet domain requires explicit support. There may
be capabilities that can be used, or extended, for example GMPLS
end-to-end recovery and GMPLS segment
recovery .
Security considerations for DetNet are described in detail in
. General security considerations
are described in . This section
considers general security considerations applicable to all data planes.
Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
The primary considerations for the data plane is to maintain
integrity of data and delivery of the associated DetNet service traversing
the DetNet network.
Application flows can be protected through whatever means is
provided by the underlying technology. For example, encryption may be
used, such as that provided by IPSec for IP
flows and/or by an underlying sub-net using MACSec
for Ethernet (Layer-2) flows.
From a data plane perspective DetNet does not add or modify any
header information.
At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane
attackers with additional information about the data flows (when
compared to controller planes that do not include per-flow identification).
This is an inherent property of DetNet which has security
implications that should be considered when determining if DetNet is
a suitable technology for any given use case.
To provide uninterrupted availability of the DetNet
service, provisions can be made against DOS attacks and delay
attacks. To protect against DOS attacks, excess traffic due to
malicious or malfunctioning devices can be prevented or mitigated,
for example through the use of existing mechanism such as policing and shaping applied at
the input of a DetNet domain. To prevent DetNet packets from
being delayed by an entity external to a DetNet domain, DetNet
technology definition can allow for the mitigation of
Man-In-The-Middle attacks, for example through use of
authentication and authorization of devices within the DetNet domain.
This document makes no IANA requests.
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David
Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig
Gunther, George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their
various contributions to this work.
IEEE 802.1 Time-Sensitive Networking Task GroupIEEE Standards AssociationIEEE Std 802.1AE-2018 MAC Security (MACsec)IEEE Standards Association