Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane
draft-ietf-detnet-ip-oam-12
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Greg Mirsky , Mach Chen , David L. Black | ||
| Last updated | 2024-02-14 (Latest revision 2024-02-08) | ||
| Replaces | draft-mirsky-detnet-ip-oam | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-10)
by Gyan Mishra
Ready w/nits
TSVART Last Call review
(of
-10)
by Bernard Aboba
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | János Farkas | ||
| Shepherd write-up | Show Last changed 2023-08-02 | ||
| IESG | IESG state | IESG Evaluation | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has enough positions to pass. |
||
| Responsible AD | Roman Danyliw | ||
| Send notices to | lberger@labn.net, janos.farkas@ericsson.com | ||
| IANA | IANA review state | IANA OK - No Actions Needed |
draft-ietf-detnet-ip-oam-12
DetNet Working Group G. Mirsky
Internet-Draft Ericsson
Intended status: Informational M. Chen
Expires: 11 August 2024 Huawei
D. Black
Dell EMC
8 February 2024
Operations, Administration and Maintenance (OAM) for Deterministic
Networks (DetNet) with IP Data Plane
draft-ietf-detnet-ip-oam-12
Abstract
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Mirsky, et al. Expires 11 August 2024 [Page 1]
Internet-Draft OAM for DetNet over IP February 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Active OAM for DetNet Networks with the IP Data Plane . . . . 3
3.1. Mapping Active OAM and IP DetNet flows . . . . . . . . . 4
3.2. Active OAM Using IP-in-UDP Encapsulation . . . . . . . . 5
3.3. Active OAM Using DetNet-in-UDP Encapsulation . . . . . . 5
3.4. Active OAM Using GRE-in-UDP Encapsulation . . . . . . . . 6
4. Active OAM for DetNet IP Interworking with OAM of non-IP DetNet
domains . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[RFC8655] introduces and explains Deterministic Networks (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 [RFC7799].
[I-D.ietf-detnet-oam-framework] 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.
Mirsky, et al. Expires 11 August 2024 [Page 2]
Internet-Draft OAM for DetNet over IP February 2024
This document discusses the use of existing IP OAM protocols and
mechanisms in DetNet networks that use the IP data plane.
2. Conventions used in this document
2.1. Terminology
The term "DetNet OAM" used in this document interchangeably with
longer version "set of OAM protocols, methods and tools for
Deterministic Networks".
DetNet: Deterministic Networks
DiffServ: Differentiated Services
OAM: Operations, Administration, and Maintenance
PREF: Packet Replication and Elimination Function
POF: Packet Ordering Function
RDI: Remote Defect Indication
ICMP: Internet Control Message Protocol
ACH: Associated Channel Header
Underlay Network or Underlay Layer: The network that provides
connectivity between DetNet nodes. MPLS networks providing LSP
connectivity between DetNet nodes are an example of the underlay
layer.
DetNet Node: a node that is an actor in the DetNet domain. DetNet
domain edge nodes and nodes that perform PREF within the domain are
examples of a DetNet node.
3. 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 supports OAM mechanisms and enables 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.
Mirsky, et al. Expires 11 August 2024 [Page 3]
Internet-Draft OAM for DetNet over IP February 2024
The DetNet data plane encapsulation in a transport network with IP
encapsulations specified in Section 6 of [RFC8939]. 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, source port number, destination port number. Active
IP OAM protocols like Bidirectional Forwarding Detection (BFD)
[RFC5880] or Simple Two-way Active Measurement Protocol (STAMP)
[RFC8762], use UDP transport and the well-known UDP port numbers as
the destination port. For BFD, the UDP destination port is specific
to the BFD variant, e.g., Multihop BFD uses port 4784 [RFC5883].
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
DSCP 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 protocol is used.
Most of on-demand failure detection and localization in IP networks
is being done by using the Internet Control Message Protocol (ICMP)
Echo Request, Echo Reply and the set of defined error messages, e.g.,
Destination Unreachable, with the more detailed information provided
through code points. [RFC0792] and [RFC4443] define the ICMP for
IPv4 and IPv6 networks, respectively. In order to use ICMP for these
purposes with DetNet, DetNet nodes must be able to associate ICMP
traffic between DetNet nodes with IP DetNet traffic, e.g., ensure
that such ICMP traffic uses the DetNet IP data plane in each node,
otherwise ICMP may be unable to detect and localize failures that are
specific to the DetNet IP data plane.
3.1. Mapping Active OAM and IP DetNet flows
IP OAM protocols are used to detect failures (e.g., BFD [RFC5880])
and performance degradation (e.g., STAMP [RFC8762]) that affect an IP
DetNet flow. When the UDP destination port number used by the OAM
protocol is assigned by IANA, then judicious selection of the UDP
source port may be able to achieve co-routedness of OAM with the
monitored IP DetNet flow in multipath environments, e.g., Link
Aggregation Group or Equal Cost Multipath, via 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. (That also applies to encapsulation
techniques described in Section 3.2 and Section 3.3.) To ensure the
accuracy of OAM results in detecting failures and monitoring the
Mirsky, et al. Expires 11 August 2024 [Page 4]
Internet-Draft OAM for DetNet over IP February 2024
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.,
[I-D.ietf-detnet-yang]). 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 grouping ip-header, defined in
[I-D.ietf-detnet-yang].
3.2. 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 ([RFC2003]). 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 the
DetNet domain for the test packet is seen as a single IP link in such
a case. As a result, transit DetNet IP nodes cannot be traced using
the usual traceroute procedure, and a modification of the traceroute
may be required.
3.3. Active OAM Using DetNet-in-UDP Encapsulation
Active OAM in IP DetNet can be realized using DetNet-in-UDP
encapsulation. Using 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
Section 4.1.2 of [RFC8655]) as the IP DetNet flow being monitored.
[I-D.ietf-detnet-mpls-over-ip-preof] describes how DetNet with MPLS
over UDP/IP data plane [RFC9025] can be used to support Packet
Replication, Elimination, and Ordering Functions 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 Figure 1 is used.
Mirsky, et al. Expires 11 August 2024 [Page 5]
Internet-Draft OAM for DetNet over IP February 2024
+---------------------------------+
| |
| 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 |
+---------------------------------+
Figure 1: DetNet Associated Channel Header Format
where DetNet ACH is the DetNet Associated Channel Header defined in
[I-D.ietf-detnet-mpls-oam].
3.4. Active OAM Using GRE-in-UDP Encapsulation
[RFC8086] 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 N-tuple.
Matching a GRE-in-UDP tunnel to the monitored IP DetNet flow enables
the use of Y.1731/G.8013 [ITU-T.1731] as a comprehensive toolset of
OAM. The Protocol Type field in GRE header must be set to 0x8902
assigned by IANA to IEEE 802.1ag Connectivity Fault Management (CFM)
Protocol / ITU-T Recommendation Y.1731. Y.1731/G.8013 supports
necessary for IP DetNet OAM functions, i.e., continuity check, one-
way packet loss and packet delay measurement.
4. Active OAM for DetNet IP Interworking with OAM of non-IP DetNet
domains
A domain in which IP data plane provides DetNet service could be used
in conjunction with a TSN and a DetNet domain with MPLS data plane to
deliver end-to-end service. In such scenarios, the ability to detect
defects and monitor performance using OAM is essential.
[I-D.ietf-detnet-mpls-oam] identified two OAM interworking models -
peering and tunneling. Interworking between DetNet domains with IP
and MPLS data planes analyzed in Section 6.2 of
Mirsky, et al. Expires 11 August 2024 [Page 6]
Internet-Draft OAM for DetNet over IP February 2024
[I-D.ietf-detnet-mpls-oam]. In addition, OAM interworking
requirements and recommendations that apply between a DetNet Domain
with the MPLS dataplane and an adjacent TSN network also apply
between a DetNet domain with the IP dataplane and an adjacent TSN
network.
5. IANA Considerations
This document does not have any requests for IANA allocation. This
section can be deleted before the publication of the draft.
6. 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 ones common to
networking or already documented in [RFC0792], [RFC4443], [RFC5880],
and [RFC8762] for the referenced DetNet and OAM protocols.
7. Acknowledgment
TBA
8. References
8.1. Normative References
[I-D.ietf-detnet-mpls-oam]
Mirsky, G., Chen, M., and B. Varga, "Operations,
Administration and Maintenance (OAM) for Deterministic
Networks (DetNet) with MPLS Data Plane", Work in Progress,
Internet-Draft, draft-ietf-detnet-mpls-oam-15, 12 January
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
detnet-mpls-oam-15>.
[I-D.ietf-detnet-yang]
Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li,
"Deterministic Networking (DetNet) YANG Model", Work in
Progress, Internet-Draft, draft-ietf-detnet-yang-19, 25
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-detnet-yang-19>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
Mirsky, et al. Expires 11 August 2024 [Page 7]
Internet-Draft OAM for DetNet over IP February 2024
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996,
<https://www.rfc-editor.org/info/rfc2003>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
March 2017, <https://www.rfc-editor.org/info/rfc8086>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>.
[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April
2021, <https://www.rfc-editor.org/info/rfc9025>.
8.2. Informational References
[I-D.ietf-detnet-mpls-over-ip-preof]
Varga, B., Farkas, J., and A. G. Malis, "Deterministic
Networking (DetNet): DetNet PREOF via MPLS over UDP/IP",
Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-
over-ip-preof-08, 7 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
mpls-over-ip-preof-08>.
[I-D.ietf-detnet-oam-framework]
Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos,
C. J., Varga, B., and J. Farkas, "Framework of Operations,
Administration and Maintenance (OAM) for Deterministic
Networking (DetNet)", Work in Progress, Internet-Draft,
draft-ietf-detnet-oam-framework-11, 8 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
oam-framework-11>.
Mirsky, et al. Expires 11 August 2024 [Page 8]
Internet-Draft OAM for DetNet over IP February 2024
[ITU-T.1731]
ITU-T, "Operations, administration and maintenance (OAM)
functions and mechanisms for Ethernet-based networks",
ITU-T G.8013/Y.1731, August 2015.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <https://www.rfc-editor.org/info/rfc5883>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
Authors' Addresses
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
David Black
Dell EMC
176 South Street
Hopkinton, MA, 01748
United States of America
Email: david.black@dell.com
Mirsky, et al. Expires 11 August 2024 [Page 9]