Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IPEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comMalis Consultingagmalis@gmail.com
RTG
DetNetDetNetIP Data PlaneService sub-layerReplicationEliminationOrdering
This document describes how the DetNet IP data plane can support the Packet
Replication, Elimination, and Ordering Functions (PREOF) built on
the existing MPLS PREOF solution defined for the DetNet MPLS
data plane and the mechanisms defined by MPLS-over-UDP technology.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology
. Terms Used in This Document
. Abbreviations
. Requirements for Adding PREOF to DetNet IP
. Adding PREOF to DetNet IP
. Solution Basics
. Encapsulation
. Packet Processing
. Flow Aggregation
. PREOF Processing
. PREOF-Capable DetNet IP Domain
. Control and Management Plane Parameters
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction
The DetNet Working Group has defined Packet Replication (PRF), Packet
Elimination (PEF), and Packet Ordering (POF) Functions
(represented as PREOF) to provide
service protection by the DetNet service sub-layer
. The PREOF service protection method relies on
copies of the same packet sent over multiple maximally disjoint paths
and uses sequencing information to eliminate duplicates. A possible
implementation of PRF and PEF is described in
, and the related YANG data model is defined
in . A possible implementation of POF
is described in .
shows a DetNet flow on which PREOF
are applied during forwarding from the source to the destination.
PREOF Scenario in a DetNet Network
+------------+
+---------------E1---+ | |
+---+ | | +---R3---+ | +---+
|src|------R1 +---+ | E3----O----+dst|
+---+ | | E2-------+ +---+
+----------R2 |
+-----------------+
R: Replication Function (PRF)
E: Elimination Function (PEF)
O: Ordering Function (POF)
In general, the use of PREOF require sequencing information to
be included in the packets of a DetNet compound flow. This can be done
by adding a sequence number or timestamp as part of DetNet encapsulation.
Sequencing information is typically added once, at or close to the source.
The DetNet MPLS data plane specifies how
sequencing information is encoded in the MPLS header. However, the DetNet
IP data plane described in does not specify how
sequencing information can be encoded in the IP packet. This document
provides sequencing information to DetNet IP nodes, so it results
in an improved version of the DetNet IP data plane. As suggested by
, the solution uses existing standardized headers
and encapsulations. The improvement is achieved by reusing the DetNet
MPLS-over-UDP/IP data plane with the restriction
of using zero F-Labels.
TerminologyTerms Used in This Document
This document uses the terminology established in the DetNet architecture
, and it is assumed that the reader is
familiar with that document and its terminology.
Abbreviations
The following abbreviations are used in this document:
DetNet
Deterministic Networking
PEF
Packet Elimination Function
POF
Packet Ordering Function
PREOF
Packet Replication, Elimination, and Ordering Functions
PRF
Packet Replication Function
Requirements for Adding PREOF to DetNet IP
The requirements for adding PREOF to DetNet IP are:
to reuse existing DetNet data plane solutions (e.g.,
, ), and
to allow the DetNet service sub-layer for IP packet-switched
networks with minimal implementation effort.
The described solution leverages MPLS header fields without
requiring the support of the MPLS forwarding plane.
Adding PREOF to DetNet IPSolution Basics
The DetNet IP encapsulation supporting the DetNet service sub-layer is based
on the "UDP tunneling" concept. The solution creates a set of underlay
UDP/IP tunnels between an overlay set of DetNet relay nodes.
At the edge of a PREOF-capable DetNet IP
domain, the DetNet flow is encapsulated in a UDP packet containing the
sequence number used by PREOF within the domain. This solution
maintains the 6-tuple-based DetNet flow identification in DetNet transit
nodes, which operate at the DetNet forwarding sub-layer between the DetNet
service sub-layer nodes; therefore, it is compatible with
. shows how the
PREOF-capable DetNet IP data plane fits into the DetNet sub-layers.
PREOF-Capable DetNet IP Data Plane
DetNet IP
.
.
+------------+
| Service | d-CW, Service-ID (S-Label)
+------------+
| Forwarding | UDP/IP Header
+------------+
*d-CW: DetNet Control Word
Encapsulation
The PREOF-capable DetNet IP encapsulation builds on encapsulating
DetNet pseudowire (PW) directly over UDP. That is, it combines DetNet MPLS
with DetNet MPLS-in-UDP ,
without using any F-Labels, as shown in .
DetNet flows are identified at the receiving DetNet service sub-layer
processing node via the S-Label and/or the UDP/IP header information.
Sequencing information for PREOF is provided by the DetNet Control Word
(d-CW) per . The S-Label is used to identify
both the DetNet flow and the DetNet App-flow type. The UDP tunnel is used
to direct the packet across the DetNet domain to the next DetNet service
sub-layer processing node.
PREOF-Capable DetNet IP Encapsulation
+---------------------------------+
| |
| DetNet App-Flow |
| (Original IP) Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation
| UDP Header | |
+---------------------------------+ |
| IP Header | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Packet Processing
IP ingress and egress nodes of the PREOF-capable DetNet IP domain
add and remove a DetNet service-specific d-CW and Service-ID (i.e.,
S-Label). Relay nodes can change Service-ID values when processing a
DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow
can be different. Service-ID values are provisioned per DetNet
service via configuration, e.g., via the Controller Plane described in
. In some PREOF topologies, the node performing
replication sends the packets to multiple nodes performing, e.g., PEF or POF, and
the replication node can use different Service-ID values for the
different member flows for the same DetNet service.
Note that the Service-ID is a local ID on the receiver side that identifies
the DetNet flow at the downstream DetNet service sub-layer receiver.
Flow Aggregation
Two methods can be used for flow aggregation:
aggregation using same UDP tunnel, and
aggregation of DetNet flows as a new DetNet flow.
In the first method, the different DetNet pseudowires use the same UDP tunnel, so they
are treated as a single (aggregated) flow at the forwarding sub-layer. At the
service sub-layer, each flow uses a different Service-ID
(see ).
For the second method, an additional hierarchy is created by
adding an additional Service-ID and d-CW tuple to the encapsulation.
The Aggregate-ID is a special case of a Service-ID,
whose properties are known only at the aggregation and deaggregation
end points. It is a property of the Aggregate-ID that it is followed by a
d-CW followed by a Service-ID/d-CW tuple.
shows the encapsulation in the case of
aggregation.
Aggregating DetNet Flows as a New DetNet Flow
+---------------------------------+
| |
| DetNet App-Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation
| DetNet Control Word | |
+---------------------------------+ |
| Aggregate-ID (A-Label) | |
+---------------------------------+ |
| UDP Header | |
+---------------------------------+ |
| IP Header | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
The aggregation method is configured in the
aggregation/deaggregation nodes.
If several DetNet flows are aggregated in a single UDP tunnel, they all need
to follow the same path in the network.
PREOF Processing
A node operating on a received DetNet flow at the DetNet service sub-layer
uses the local context associated with a received Service-ID to determine
which local DetNet operation(s) are applied to the received packet. A unique Service-ID
can be allocated and can be used to identify a DetNet flow
regardless of which input interface or UDP tunnel receives the packet.
It is important to note that Service-ID values are driven by the receiver,
not the sender.
The DetNet forwarding sub-layer is supported by the UDP tunnel and is
responsible for providing resource allocation and explicit routes.
The outgoing PREOF encapsulation and processing can be implemented
via the provisioning of UDP and IP header information.
Note, when PRF is performed at the DetNet service sub-layer,
there are multiple member flows, and each member flow requires
its own Service-ID, UDP header information, and IP header information. The headers for
each outgoing packet are formatted according to the configuration
information, and the UDP Source Port value is set to uniquely identify
the DetNet flow. The packet is then handled as a PREOF-capable DetNet
IP packet.
The incoming PREOF processing can be implemented by assigning
a Service-ID to the received DetNet flow and processing the information in the UDP and IP headers. The
provisioned information is used to identify incoming App-flows based
on the combination of Service-ID and/or incoming encapsulation header
information.
PREOF-Capable DetNet IP Domain shows using PREOF in a PREOF-capable DetNet
IP network, where service protection is provided end to end, and not only
within sub-networks, as is depicted in Figure 4 of .
PREOF-Capable DetNet IP Domain
<---------- PREOF-capable DetNet IP --------------->
______
____ / \__
____ / \__/ \____________
+----+ __/ \____/ \ +----+
|src |_____/ \___| dst|
+----+ \_______ DetNet network __________/ +----+
\_______ _/
\ __ __/
\_______/ \___/
+------------+
+---------------E1---+ | |
+----+ | | +---R3---+ | +----+
|src |------R1 +---+ | E3----O----+ dst|
+----+ | | E2-------+ +----+
+----------R2 |
+-----------------+
Control and Management Plane Parameters
The information needed to identify individual and aggregated DetNet flows
is summarized as follows:
Service-ID information to be mapped to UDP/IP flows. Note that, for
example, a single Service-ID can map to multiple sets of UDP/IP
information when PREOF is used.
IPv4 or IPv6 Source Address field.
IPv4 or IPv6 source address prefix length, where a zero
(0) value effectively means that the address field is
ignored.
IPv4 or IPv6 Destination Address field.
IPv4 or IPv6 destination address prefix length, where a
zero (0) effectively means that the address field is
ignored.
IPv6 Flow Label field.
IPv4 Protocol field being equal to "UDP".
IPv6 (last) Next Header field being equal to "UDP".
For the IPv4 Type of Service and IPv6 Traffic Class
fields:
Whether or not the Differentiated Services Code Point (DSCP) field is used in flow identification,
as the use of the DSCP field for flow identification is optional.
If the DSCP field is used to identify a flow, then the flow
identification information (for that flow) includes a list of
DSCPs used by the given DetNet flow.
UDP Source Port. Support for both exact and wildcard matching is
required. Port ranges can optionally be used.
UDP Destination Port. Support for both exact and wildcard matching is
required. Port ranges can optionally be used.
For end systems, an optional maximum IP packet size
that should be used for that outgoing DetNet IP flow.
This information is provisioned per DetNet flow via
configuration, e.g., via the Controller Plane.
Ordering of the set of information used to identify an individual
DetNet flow can, for example, be used to
provide a DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service for the
aggregate of all other flows with that same UDP Destination Port value.
The minimum set of information for the configuration of the DetNet service
sub-layer is summarized as follows:
App-flow identification information
Sequence number length
Type of PREOF to be executed on the DetNet flow
Service-ID(s) used by the member flows
Associated forwarding sub-layer information
Service aggregation information
The minimum set of information for the configuration of the DetNet forwarding
sub-layer is summarized as follows:
UDP tunnel-specific information
Traffic parameters
These parameters are defined in the DetNet flow and service information model
and the DetNet YANG model.
Note: this document focuses on the use of MPLS-over-UDP/IP encapsulation throughout an
entire DetNet IP network, making MPLS-based DetNet Operations, Administration, and Maintenance (OAM) techniques applicable
.
Using the described encapsulation only for a portion of a DetNet IP network
that handles PREOF would complicate OAM.
Security Considerations
There are no new DetNet-related security considerations introduced by
this solution. Security considerations of DetNet MPLS and
DetNet MPLS over UDP/IP apply.
IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesDeterministic Networking ArchitectureThis document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.Deterministic Networking (DetNet) Data Plane FrameworkThis document provides an overall framework for the Deterministic Networking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well.Deterministic Networking (DetNet) Data Plane: IPThis document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).Deterministic Networking (DetNet) Data Plane: MPLSThis document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework.Flow and Service Information Model for Deterministic Networking (DetNet)This document describes the flow and service information model for Deterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes.Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IPThis document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology.Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data PlaneThis document defines format and usage principles of the Deterministic Networking (DetNet) service Associated Channel over a DetNet network with the MPLS data plane. The DetNet service Associated Channel can be used to carry test packets of active Operations, Administration, and Maintenance (OAM) protocols that are used to detect DetNet failures and measure performance metrics.Informative ReferencesIEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for ReliabilityIEEEIEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability - Amendment 1: Information Model, YANG Data Model, and Management Information Base ModuleIEEEAmendment to IEEE Std 802.1CB-2017Deterministic Networking (DetNet): Packet Ordering FunctionThe replication and elimination functions of the Deterministic Networking (DetNet) architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. The Packet Ordering Function (POF) algorithms described in this document enable restoration of the correct packet order when the replication and elimination functions are used in DetNet networks. The POF only provides ordering within the latency bound of a DetNet flow; it does not provide any additional reliability.Acknowledgements
Authors extend their appreciation to , , ,
, and for their insightful comments and productive
discussion that helped to improve the document.
Authors' AddressesEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comMalis Consultingagmalis@gmail.com