Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IPEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comLabN Consulting, L.L.C.lberger@labn.netMalis Consultingagmalis@gmail.comFuturewei Technologiessb@stewartbryant.comDetNet
This 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.
Status of This Memo
This is an Internet Standards Track document.
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). Further
information on Internet Standards is available in 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) 2021 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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Terminology
. Terms Used in This Document
. Abbreviations
. Requirements Language
. DetNet MPLS Operation over DetNet IP PSNs
. DetNet Data Plane Procedures
. Management and Control Information Summary
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
Introduction
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 Operations, Administration, and
Maintenance (OAM) packets from DetNet data packets.
A method for carrying queuing 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) using UDP encapsulation . It maps the MPLS data plane encapsulation described in
to the DetNet IP data plane
defined in .
specifies that "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 constraint does apply to the use of RFC 7510 in a
DetNet network because DetNet is constrained to operate within a
single administrative control or within a closed group of
administrative control.
TerminologyTerms Used in This Document
This document uses the terminology established in the DetNet architecture
; the reader is assumed
to be familiar with that document and its terminology.
Abbreviations
The following abbreviations are used in this document:
d-CW
A DetNet Control Word (d-CW) is used for sequencing and identifying duplicate packets of a DetNet flow at the DetNet service
sub-layer.
DetNet
Deterministic Networking
DSCP
Differentiated Services Code Point
A-Label
A special case of an S-Label, whose properties are known only at
the aggregation and deaggregation endpoints.
F-Label
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.
MPLS
Multiprotocol Label Switching
OAM
Operations, Administration, and Maintenance
PEF
Packet Elimination Function
POF
Packet Ordering Function
PREOF
Packet Replication, Elimination, and Ordering Functions
PRF
Packet Replication Function
PSN
Packet Switched Network
S-Label
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 the DetNet service sub-layer.
Requirements Language
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.
DetNet MPLS Operation over DetNet IP PSNs
This document builds on the specification of MPLS over UDP defined
in . It may partly or entirely replace 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-Labels
between the S-Label and the UDP header.
Note that this encapsulation works equally well with IPv4, IPv6, and
IPv6-based Segment Routing .
S-Labels, A-Labels (when present), d-CW, and zero or more F-Labels are used as defined in and are not modified by this document.
DetNet Data Plane Procedures
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 the 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.
Management and Control Information Summary
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 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
both aggregated and individual flows.
Security Considerations
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-over-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 document does not have additional security
considerations.
IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Encapsulating MPLS in UDPThis document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.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.Informative ReferencesDeterministic Networking (DetNet) Security ConsiderationsWork in ProgressDeterministic 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.IPv6 Segment Routing Header (SRH)Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.Acknowledgements
The authors wish to thank ,
, , , , , , , ,
, , and for their various contributions to this work.
Contributors
This document is derived from an earlier draft that was edited by (jouni.nospam@gmail.com), and as such, he
contributed to and authored text in this document.
Authors' AddressesEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comLabN Consulting, L.L.C.lberger@labn.netMalis Consultingagmalis@gmail.comFuturewei Technologiessb@stewartbryant.com