Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data PlaneEricssongregimirsky@gmail.comHuaweimach.chen@huawei.comDell EMC176 South StreetHopkintonMA01748United States of Americadavid.black@dell.com
RTG
detnetDetNetOAM
This document discusses the use of existing IP Operations,
Administration, and Maintenance protocols and mechanisms in
Deterministic Networking networks that use the IP data plane.
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
. Conventions Used in This Document
. Terminology
. Active OAM for DetNet Networks with the IP Data Plane
. Mapping Active OAM and IP DetNet Flows
. Active OAM Using IP-in-UDP Encapsulation
. Active OAM Using DetNet-in-UDP Encapsulation
. The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation
. Active OAM for DetNet IP Interworking with OAM for Non-IP DetNet Domains
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Authors' Addresses
Introduction introduces and explains the Deterministic Networking (DetNet)
architecture.
Operations, Administration, and Maintenance (OAM) protocols are used
to detect and localize defects in the network as well as to monitor network
performance. Some OAM functions (e.g., failure detection) work in
the network proactively, while others (e.g., defect localization) are
usually performed on demand. These tasks are achieved by a combination
of active and hybrid OAM methods, as defined in .
lists the OAM functional requirements
for DetNet and defines the principles for OAM use within DetNet
networks utilizing the IP data plane. The functional requirements
can be compared against current OAM tools to identify gaps and
potential enhancements required to enable proactive and on-demand
path monitoring and service validation.
This document discusses the use of existing IP OAM protocols and mechanisms in
DetNet networks that use the IP data plane.
Conventions Used in This DocumentTerminology
The term "DetNet OAM" as used in this document means "a set of OAM protocols, methods, and tools for Deterministic Networking".
DetNet:
Deterministic Networking
OAM:
Operations, Administration, and Maintenance
ICMP:
Internet Control Message Protocol
Underlay Network or Underlay Layer:
The network that provides
connectivity between DetNet nodes. MPLS networks providing Label Switched Path (LSP)
connectivity between DetNet nodes are an example of the DetNet IP network underlay
layer.
DetNet Node:
A node that is an actor in the DetNet domain. DetNet
domain edge nodes and nodes that perform the Packet Replication, Elimination, and Ordering Functions within the domain are
examples of a DetNet node.
Active OAM for DetNet Networks with the IP Data Plane
OAM protocols and mechanisms act within the data plane of the particular networking layer.
Thus, it is critical that the data plane encapsulation support OAM mechanisms and enable them to be
configured so that DetNet OAM packets follow the same path
(unidirectional or bidirectional) through the network and receive
the same forwarding treatment in the DetNet forwarding sub-layer
as the DetNet flow being monitored.
The DetNet data plane encapsulation in a transport network with IP encapsulations is specified
in .
For the IP underlay network, DetNet flows are identified
by the ordered match to the provisioned information set that, among other elements, includes the IP protocol type, source port number, and
destination port number. Active IP OAM
protocols like Bidirectional Forwarding Detection (BFD) or the
Simple Two-way Active Measurement Protocol (STAMP)
use UDP transport and the well-known UDP port numbers as the respective destination ports.
For BFD, the UDP destination port is specific to the BFD variant,
e.g., multihop BFD uses port 4784 .
Thus, a DetNet node must be
able to associate an IP DetNet flow with the particular test session to ensure that test packets experience the
same treatment as the DetNet flow packets. For example, in a network where path selection and DetNet functionality
are based on 3-tuples (destination and source IP addresses
in combination with the Differentiated Services Code Point value), that association can be achieved
by having the OAM traffic use the same 3-tuple as the monitored
IP DetNet flow.
In such a scenario, an IP OAM session between the same pair of IP nodes would share the network treatment
with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMP is used.
In IP networks, the majority of on-demand failure detection and localization is achieved through the use
of ICMP, utilizing Echo Request and Echo Reply messages,
along with a set of defined error messages such as Destination Unreachable, which provide detailed information through assigned code points.
and define ICMP for IPv4 and IPv6 networks, respectively.
To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association
of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuring that such
ICMP traffic traverses the same interfaces and receives QoS treatment that is identical to the monitored DetNet IP flow.
Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane.
Mapping Active OAM and IP DetNet Flows
IP OAM protocols are used to detect failures (e.g., BFD )
and performance degradation (e.g., STAMP ) that affect an IP DetNet flow.
For active OAM to be useful, it is essential to ensure that
specially constructed OAM packets traverse the same set of nodes and
links and receive the same network QoS treatment as the monitored
data flow, e.g., a DetNet flow.
When the UDP destination port
number used by the OAM protocol is assigned by IANA, judicious
selection of the UDP source port may help achieve co-routedness
of OAM with the monitored IP DetNet flow in multipath environments,
e.g., Link Aggregation Group or Equal Cost Multipath, via the use of a
UDP source port value that results in the OAM traffic and the
monitored IP DetNet flow hashing to the same path based on the packet
header hashes used for path selection. This does assume that forwarding
equipment along the multipath makes consistent hashing decisions, which
might not always be true in a heterogeneous environment.
(That also applies to the encapsulation techniques described in
Sections and .)
To ensure the accuracy of OAM results in detecting failures and
monitoring the performance of IP DetNet, it is essential that test packets not only traverse the same path as the monitored IP DetNet flow
but also receive the same treatment by the nodes, e.g., shaping, filtering, policing, and availability of the pre-allocated resources,
as experienced by the IP DetNet packet. That correlation between the particular IP OAM session and the monitored IP DetNet flow
can be achieved by using DetNet provisioning information (e.g., ). Each IP OAM protocol session
is presented as a DetNet application with related service and forwarding sub-layers. The forwarding sub-layer of the IP OAM session
is identical to the forwarding sub-layer of the monitored IP DetNet flow, except for information
in the "ip-header" grouping item as defined in .
Active OAM Using IP-in-UDP Encapsulation
As described above, active IP OAM is realized through several protocols. Some protocols use UDP transport,
while ICMP is a network-layer protocol. The amount of operational work mapping IP OAM protocols
to the monitored DetNet flow can be reduced by using an IP/UDP tunnel to carry IP test packets.
Then, to ensure that OAM packets traverse the same set of nodes and links, the IP/UDP tunnel
must be mapped to the monitored DetNet flow. Note that in such a case, the DetNet domain for the test packet
is seen as a single IP link. As a result, transit DetNet IP nodes cannot be traced
using the usual traceroute procedure, and a modification of the traceroute may be required.
Active OAM Using DetNet-in-UDP Encapsulation
Active OAM in IP DetNet can be realized using DetNet-in-UDP encapsulation.
Using a DetNet-in-UDP tunnel between IP DetNet nodes ensures that active OAM test packets follow the same path through
the network as the monitored IP DetNet flow packets and receive
the same forwarding treatment in the DetNet forwarding sub-layer
(see )
as the IP DetNet flow
being monitored.
describes how DetNet with the MPLS-over-UDP/IP data plane can be used
to support Packet Replication, Elimination, and Ordering Functions (PREOF) to potentially lower packet loss, improve the probability of on-time packet delivery,
and ensure in-order packet delivery in IP DetNet's service sub-layer. To ensure that an active OAM test packet follows the path of the monitored
DetNet flow in the DetNet service sub-layer, the encapsulation shown in is used.
DetNet Associated Channel Header Format +---------------------------------+
| |
| DetNet App-Flow |
| (original IP) Packet |
| |
+---------------------------------+ <--\
| DetNet ACH | |
+---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation
| UDP Header | |
+---------------------------------+ |
| IP Header | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
DetNet ACH - the DetNet Associated Channel Header as defined in .
PREOF - Packet Replication, Elimination, and Ordering Functions used in the DetNet service sub-layer as defined in .
The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation has defined the method of encapsulating GRE (Generic Routing Encapsulation) headers
in UDP. GRE-in-UDP encapsulation can be used for IP DetNet OAM, as it eases the task of mapping an OAM test session
to a particular IP DetNet flow that is identified by an N-tuple. Matching a GRE-in-UDP tunnel to the monitored IP DetNet flow
enables the use of Y.1731/G.8013 as a comprehensive toolset of OAM. The Protocol Type field
in the GRE header must be set to 0x8902, assigned by IANA to the IEEE 802.1ag Connectivity Fault Management (CFM) protocol / ITU-T Recommendation Y.1731.
Y.1731/G.8013 supports the necessary functions required for IP DetNet OAM, i.e., continuity checks, one-way packet loss, and packet delay measurements.
Active OAM for DetNet IP Interworking with OAM for Non-IP DetNet Domains
A domain in which the IP data plane provides DetNet service could be used
in conjunction with a Time-Sensitive Networking (TSN) network and a DetNet domain with the MPLS data plane to deliver end-to-end service.
In such scenarios, the ability to detect defects and monitor performance using OAM is essential.
identifies two OAM interworking models -- peering and tunneling.
Interworking between DetNet domains with IP and MPLS data planes is analyzed in
.
In addition, OAM interworking requirements and recommendations that apply
between a DetNet domain with the MPLS data plane and an adjacent TSN
network also apply between a DetNet domain with the IP data plane and
an adjacent TSN network.
IANA Considerations
This document has no IANA actions.
Security Considerations
This document describes the applicability of the existing Fault Management and
Performance Monitoring IP OAM protocols.
It does not raise any security concerns or issues in addition to those common to networking or
already documented in , , ,
and for the referenced DetNet and OAM protocols.
ReferencesNormative ReferencesInternet Control Message ProtocolIP Encapsulation within IPThis document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) SpecificationThis document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]GRE-in-UDP EncapsulationThis document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.Deterministic 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: 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: 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.Deterministic Networking (DetNet) YANG Data ModelHuawei TechnologiesETRILabN Consulting, L.L.C.EquinixChina MobileInformative ReferencesOperation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networksITU-TBidirectional Forwarding Detection (BFD)This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]Bidirectional Forwarding Detection (BFD) for Multihop PathsThis document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]Active and Passive Metrics and Methods (with Hybrid Types In-Between)This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.Simple Two-Way Active Measurement ProtocolThis document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow.Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IPThis 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.Authors' AddressesEricssongregimirsky@gmail.comHuaweimach.chen@huawei.comDell EMC176 South StreetHopkintonMA01748United States of Americadavid.black@dell.com