Deterministic Networking (DetNet) Data Plane: IP
Extracted elements (19)
DetNet IP flow aggregation uses wildcards, masks, lists, prefixes, and ranges on any 6-tuple field (optionally also Flow Label), allowing a DetNet node to identify aggregate flows and allocate resources on an aggregate basis rather than per-component-flow, improving scaling by reducing per-hop state.
No DetNet-specific encapsulation is defined for IP flows; instead, existing IP-layer and higher-layer protocol header information is reused for flow identification. This limits the data plane to forwarding sub-layer functions only, as the service sub-layer (PREOF) requires additional header fields not present in plain IP.
Service protection (PRF and PEF) cannot be provided end-to-end in the DetNet IP data plane due to the lack of unified end-to-end sequencing information. Instead, service protection can only be provided on a per-link or per-sub-network basis using technologies such as MPLS or IEEE 802.1 TSN.
DetNet IP flow identification using 6-tuples is not fully applicable to all protocols. For ICMP, IPsec, and ESP, port information is unavailable, requiring use of fewer fields (e.g., 3-tuple or 2-tuple). ICMP type is excluded from the DetNet flow definition.
IP fragmentation must be avoided for DetNet flows because fragments do not include transport headers or port information, making full 6-tuple flow identification impossible on fragments. Applications and end systems should use Path MTU Discovery or Controller Plane guidance to determine the maximum packet size.
Non-DetNet and DetNet IP packets have identical protocol header formats on the wire; the only difference is the presence of flow-associated DetNet state on each DetNet node. Standard DSCP field modification per RFC 2474 is not precluded.
All DetNet implementations MUST identify individual DetNet flows based on the set of IP-layer and higher-layer protocol header information specified in Section 5.1. The configuration used to identify flows MUST be ordered, and implementations MUST identify a DetNet flow by the first matching set of flow information.
DetNet-aware applications and end systems SHOULD NOT mix DetNet and non-DetNet traffic within a single 5-tuple, to enable simpler 5-tuple filters at DetNet domain edges.
Flow identification information and flow-specific resources MUST be provisioned per DetNet flow via configuration (Controller Plane or management plane). An implementation MUST support ordering of the set of information used to identify an individual DetNet flow.
For IPsec AH and ESP flows, implementations MUST support flow identification based on an exact value of the Security Parameters Index (SPI) field, and SHOULD allow the field to be ignored for a specific DetNet flow.
Implementations MUST support DetNet flow identification based on TCP and UDP Source Port and Destination Port fields, including exact value matching and the ability to ignore the field. Implementations SHOULD support range-based port matching.
Implementations SHALL use management and control information to select outgoing interfaces and next hops for DetNet flow packets. The use of ECMP for a single DetNet flow is NOT RECOMMENDED; ECMP MAY be used for non-DetNet flows within a DetNet domain.
Implementations SHOULD support identification of DetNet flows based on the IPv6 Flow Label field. Implementations that support this field MUST allow it to be ignored, and MAY exclude the IPv6 Next Header field when the Flow Label is used for flow identification.
Network nodes of a DetNet network MUST ensure that no DetNet-allocated resource (e.g., queue or shaper) is used by flows associated with an incomplete reservation. Methods include treating such packets as non-DetNet, discarding them, or re-marking the DSCP field.
The DetNet Controller Plane MUST ensure that non-congestion-responsive DetNet traffic is not forwarded outside a DetNet domain.
DetNet IP flow identification for IPsec AH (RFC 4302) and ESP (RFC 4303) uses the Security Parameters Index (SPI) field, which has a common format in both protocols. ICMP flow identification uses only the protocol number in the IP header; ICMP type is not included.
DetNet IP flow identification uses a 6-tuple: destination address, source address, IP protocol, source port, destination port, and DSCP. This is the same 6-tuple defined in RFC 3290, optionally extended with the IPv6 Flow Label field.
The primary security consideration is maintaining data integrity and DetNet service delivery. Since no DetNet-specific fields are added, integrity and confidentiality can be protected using underlying mechanisms such as IPsec for IP flows or MACsec for Layer 2. Per-flow identification at the Controller Plane may expose additional information about data flows to Controller Plane attackers.
To protect against DoS attacks, excess traffic from malicious or malfunctioning devices can be mitigated through policing and shaping at the DetNet domain input or within an edge IEEE 802.1 TSN domain. Man-in-the-middle delay attacks can be mitigated through authentication and authorization of devices within the DetNet domain.