DetNet Data Plane: MPLS over UDP/IP

Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end delivery latency. General background and concepts of DetNet can be found in . To carry DetNet MPLS flows with full functionality at the DetNet layer over an IP network, the following components are required (these are a subset of the requirements for MPLS encapsulation listed in ): A method for identifying DetNet flows to the processing element. A method for carrying the DetNet sequence number. A method for distinguishing DetNet OAM packets from DetNet data packets. A method for carrying queueing and forwarding indication. These requirements are satisfied by the DetNet over MPLS Encapsulation described in and they are partly satisfied (i.e., IP flows can be identified however no DetNet sequence number is carried) by the DetNet IP data plane defined in This document specifies use of the MPLS DetNet encapsulation over an IP network. The approach is modeled on the operation of MPLS over an IP Packet Switched Network (PSN) . It maps the MPLS data plane encapsulation described in to the DetNet IP data plane defined in . As specified in : "MPLS-in-UDP MUST NOT be used over the general Internet, or over non-cooperating network operators, to carry traffic that is not congestion controlled." This does apply to DetNet networks as this document focuses on solutions for networks that are under a single administrative control or within a closed group of administrative control.

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: A DetNet Control Word (d-CW) is used for sequencing and identifying duplicate packets of a DetNet flow at the DetNet service sub-layer. Deterministic Networking. A special case of an S-Label, whose properties are known only at the aggregation and deaggregation end-points. A Detnet "forwarding" label that identifies the LSP used to forward a DetNet flow across an MPLS PSN, e.g., a hop-by-hop label used between label switching routers. Multiprotocol Label Switching. Operations, Administration, and Maintenance. Packet Elimination Function. Packet Ordering Function. Packet Replication, Elimination and Ordering Functions. Packet Replication Function. Packet Switched Network. A DetNet "service" label that is used between DetNet nodes that also implement the DetNet service sub-layer functions. An S-Label is also used to identify a DetNet flow at DetNet service sub-layer.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document builds on the specification of MPLS over UDP defined in . It may replace partly or entirely the F-Label(s) used in with UDP and IP headers. The UDP and IP header information is used to identify DetNet flows, including member flows, per . The resulting encapsulation is shown in . There may be zero or more F-label(s) between the S-label and the UDP header. Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing .

To support outgoing DetNet MPLS over UDP encapsulation, an implementation MUST support the provisioning of UDP and IP header information in addition to or in place of F-Label(s). Note, when PRF is performed at the MPLS service sub-layer, there will be multiple member flows, and each member flow will require the provisioning of their own UDP and IP header information. The headers for each outgoing packet MUST be formatted according to the configuration information and as defined in , and the UDP Source Port value MUST be set to uniquely identify the DetNet flow. The packet MUST then be handled as a DetNet IP packet, per . This includes QoS related traffic treatment. To support the receive processing defined in this document, an implementation MUST also support the provisioning of received UDP and IP header information. The provisioned information MUST be used to identify incoming app-flows based on the combination of S-Label and incoming encapsulation header information. Normal receive processing as defined in , including PEF and POF, can then take place.

The following summarizes the minimum set of information that is needed to configure DetNet MPLS over UDP/IP: Label information (A-labels, S-labels and F-labels) to be mapped to UDP/IP flows. Note that for example, a single S-Label can map to multiple sets of UDP/IP information when PREOF is used. IPv4 or IPv6 source address field. IPv4 or IPv6 destination address field. DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class Fields. UDP Source Port. UDP Destination Port. Use/non-use of UDP checksum. This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller or management plane. Not using the UDP checksum has to be evaluated on a case-by-case basis for a given network scenario based on the exception criteria's defined in , particularly when IPv6 is used. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific resources needed to provide the traffic treatment needed to meet each flow's service requirements. This applies for aggregated and individual flows. Note: In the presence of network (and port) address translation devices/functions it would be up to the controller plane to determine the appropriate information to ensure proper mapping at the sender/receiver.

The solution defined in this document reuses mechanisms specified in other documents, and the security considerations in those documents apply equally to this document. Of particular note is , as this document is primarily an application of MPLS-in-UDP. Additionally, the security considerations of DetNet in general are discussed in and . Finally, MPLS and IP specific security considerations are described in and . This draft does not have additional security considerations.

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.

This document is derived from an earlier draft that was edited by Jouni Korhonen (jouni.nospam@gmail.com) and as such, he contributed to and authored text in this document.