Deterministic Networking Architecture
Extracted elements (29)
DetNet focuses exclusively on worst-case values for end-to-end latency, jitter, and packet misordering rather than average or typical values. Average latency values are of little interest because they do not affect the ability of a real-time system to perform its tasks; a trivial priority-based scheme will give better average latency but unacceptable worst-case latency.
DetNet is constrained to operate within a single administrative domain (or a closed group of administrative domains such as campus networks and private WANs) and is explicitly not intended for large groups of domains such as the Internet. This constraint simplifies security and resource-allocation assumptions.
Explicit routes are used in DetNet so that the path of a DetNet flow does not change immediately in response to network topology events, avoiding even very brief losses of connectivity caused by routing/bridging protocol convergence. This is distinct from service protection, which handles failures on those fixed paths.
Resource reservation before the application starts is unavoidable in DetNet: a network cannot deliver finite latency and practically zero packet loss to an arbitrarily high offered load, and achieving near-zero packet loss requires dedicating buffer resources to specific flows or flow classes.
The DetNet service sub-layer and forwarding sub-layer separation is helpful for exploring combinations of data-plane solutions but is not a formal requirement; some technologies may violate strict sub-layer boundaries and still deliver a DetNet service. Service examples include PW/UDP/GRE for the service sub-layer and IPv4/IPv6/MPLS-TE/MPLS-SR for the forwarding sub-layer.
DetNet can deliver service over lower-layer sub-network technologies including MPLS TE, IEEE 802.1 TSN, and OTN. Multilayer DetNet is also possible, where one DetNet instance appears as a sub-network providing service to a higher-layer DetNet system. TSN-specific terms (Talker, Listener, Stream, Relay system) map directly to DetNet source, destination, flow, and intermediate node.
DetNet flow aggregation is required for scaling to larger networks, as per-flow state at each DetNet node becomes prohibitive for large numbers of flows. Aggregated flows can be treated largely as individual DetNet flows by the Data Plane; example aggregation techniques include MPLS hierarchy and IP DiffServ Code Points (DSCPs).
If DetNet-unaware intermediate nodes or subnets exist along a path, extra buffering must be allocated at the first downstream DetNet transit node to absorb the induced latency variations. This may increase worst-case latency and jitter for the flow.
When DetNet flows cross technology domain boundaries (e.g., IP-to-Ethernet or MPLS-to-Ethernet), a domain-specific Flow-ID must be pushed so that lower-layer nodes can perform per-flow queuing and shaping without deep packet inspection. The means for encoding sequence number information must similarly be mapped or exported when the flow identification method changes.
Filters and policers should be used in a DetNet network to detect if DetNet packets are received on the wrong interface, at the wrong time, or in too great a volume, and can take action to discard offending packets, shut down the offending flow, or shut down the offending interface.
PRF-generated DetNet member flows must be treated as not using transport-layer congestion control, even if the original App-flow supports it, because PREOF (specifically PEF) can remove congestion indications such as drops, ECN markings, and increased latency, hiding them from end systems.
Rate limiting (traffic policing) and shaping functions at the ingress of the DetNet domain must be applied. This is needed both for meeting DetNet flow QoS requirements and for protecting non-DetNet traffic from potentially misbehaving DetNet traffic sources.
Sending DetNet traffic into networks that have not been provisioned in advance to handle that traffic must be treated as a fault. Egress traffic filters or equivalent mechanisms are strongly recommended at the edges of DetNet networks to prevent this.
Starvation of non-DetNet traffic must be avoided, for example by traffic policing and shaping functions. The net effect of DetNet flows on non-DetNet flows is primarily a reduction in available bandwidth, not complete exclusion.
The source is required not to exceed the contracted limits (maximum packet size, observation interval, maximum transmissions) in order to obtain DetNet service. Unused resources may be made available to non-DetNet packets as long as all guarantees are fulfilled.
DetNet QoS markings allow an attacker to correlate flows or select particular types of flow for more detailed inspection. The requirement for every (or nearly every) node along the path to identify DetNet flows may present an additional attack surface for privacy, particularly if DetNet is adopted in broader environments beyond single-administrative-domain networks.
Asynchronous DetNet flows are characterized by three parameters: a maximum packet size, an observation interval, and a maximum number of transmissions during that interval. Together with protocol header sizes, these define the bandwidth that must be reserved for the flow.
DetNet architecture comprises three planes: the Application Plane (User Agent, Flow Management Entity, TSpec abstractions, Northbound Service Interface), the Controller Plane (Controller Plane Functions including PCE and NME, computes deterministic paths), and the Network Plane (DetNet nodes, NICs, Southbound Interface). This mirrors SDN layering from RFC 7426.
DetNet defines four flow types based on end-system awareness: App-flow (no DetNet attributes, for unaware end systems), DetNet-f-flow (requires forwarding sub-layer only), DetNet-s-flow (requires service sub-layer only), and DetNet-sf-flow (requires both sub-layers). These types have different requirements on DetNet nodes.
DetNet defines three node roles: DetNet edge node (source/destination at service sub-layer, analogous to LER/PE), DetNet relay node (interconnects different forwarding sub-layer paths, participates in service sub-layer), and DetNet transit node (operates at forwarding sub-layer only, e.g., MPLS LSR). Edge nodes may proxy service for DetNet-unaware end systems.
DetNet functionality is implemented in two adjacent sub-layers: the DetNet service sub-layer (providing service protection, packet sequencing, replication, elimination) and the DetNet forwarding sub-layer (providing explicit routes and resource allocation). Not all sub-layers are required for any given application or network.
End systems are categorized by DetNet awareness: DetNet-unaware (classic case, requires service proxies), DetNet-f-aware (knows forwarding sub-layer, e.g., TSN reservation, but not service protection), DetNet-s-aware (supplies sequence numbers but not resource allocation), and DetNet-sf-aware (fully functional, same forwarding paradigm as the DetNet domain).
PREOF is the collective name for three DetNet service sub-layer functions: the Packet Replication Function (PRF), which replicates DetNet flow packets to multiple next hops; the Packet Elimination Function (PEF), which removes duplicate packets based on sequencing information; and the Packet Ordering Function (POF), which reorders out-of-order packets. These can be implemented at DetNet edge nodes, relay nodes, or end systems.
The DetNet service sub-layer on the source side includes packet sequencing, flow replication, and packet encoding; on the destination side it includes duplicate elimination, flow merging, and packet decoding. The forwarding sub-layer at both ends provides resource allocation and explicit routes.
The DetNet-UNI (User-to-Network Interface) is a packet-based reference point that may provide encapsulation, resource availability status, synchronization services, and signaling for placing reservations. It is the boundary between end systems and the DetNet domain.
Authentication and authorization must be used to secure the request and control of DetNet resources, especially for network controller devices. Centralized control should follow ACTN security considerations (RFC 8453 Section 9); distributed control relies on the security properties of the control protocols in use.
Because DetNet mechanisms may make heavy use of precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic is found in RFC 7384.
DoS attacks on DetNet QoS availability can be mitigated via traffic admission control at DetNet domain ingress (Section 3.2.1) and fault-mitigation methods (Section 3.3.2). Delay attacks by external entities can be countered by authentication and authorization of devices within the DetNet domain.
Per-flow identification in DetNet provides attackers with additional information about data flows compared to networks without per-flow identification. This is an inherent property of DetNet that has security implications that should be considered when determining suitability for a given use case.