Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP

Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP Ericsson

Magyar Tudosok krt. 11. Budapest Hungary 1117 balazs.a.varga@ericsson.com

Ericsson

Magyar Tudosok krt. 11. Budapest Hungary 1117 janos.farkas@ericsson.com

Malis Consulting

agmalis@gmail.com

RTG DetNet DetNet IP Data Plane Service sub-layer Replication Elimination Ordering 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.

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 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.

Terminology

Terms 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 IP

Solution 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

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.

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.

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 ______ ____ / \__ ____ / \__/ \____________ +----+ __/ \____/ \ +----+ |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.

References Normative References Informative References IEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability IEEE IEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability - Amendment 1: Information Model, YANG Data Model, and Management Information Base Module IEEE Amendment to IEEE Std 802.1CB-2017

Acknowledgements Authors extend their appreciation to , , , , and for their insightful comments and productive discussion that helped to improve the document.