[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mirsky-detnet-oam) 00 01 02

DetNet  Working Group                                          G. Mirsky
Internet-Draft                                                 ZTE Corp.
Intended status: Informational                                   M. Chen
Expires: September 24, 2020                                       Huawei
                                                                D. Black
                                                                Dell EMC
                                                          March 23, 2020


   Operations, Administration and Maintenance (OAM) for Deterministic
                  Networks (DetNet) with IP Data Plane
                     draft-mirsky-detnet-ip-oam-02

Abstract

   This document defines the principals for using Operations,
   Administration, and Maintenance protocols and mechanisms in the
   Deterministic Networking networks with 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 September 24, 2020.

Copyright Notice

   Copyright (c) 2020 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
   (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 Simplified BSD License text as described in Section 4.e of



Mirsky, et al.         Expires September 24, 2020               [Page 1]


Internet-Draft           OAM for DetNet over IP               March 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Active OAM for DetNet Networks with IP Data Plane . . . . . .   3
     3.1.  Active OAM Using DetNet-in-UDP Encapsulation  . . . . . .   4
     3.2.  Mapping Active OAM and IP DetNet flows  . . . . . . . . .   4
     3.3.  Active OAM Using GRE-in-UDP Encapsulation . . . . . . . .   5
   4.  Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informational References  . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [RFC8655] introduces and explains Deterministic Networks (DetNet)
   architecture.

   Operations, Administration and Maintenance (OAM) protocols are used
   to detect, localize defects in the network, and monitor network
   performance.  Some OAM functions, e.g., failure detection, work in
   the network proactively, while others, e.g., defect localization,
   usually performed on-demand.  These tasks achieved by a combination
   of active and hybrid, as defined in [RFC7799], OAM methods.

   [I-D.mirsky-detnet-mpls-oam] lists the functional requirements toward
   OAM for DetNet domain.  The list can further be used for gap analysis
   of available OAM tools to identify possible enhancements of existing
   or whether new OAM tools are required to support proactive and on-
   demand path monitoring and service validation.  Also, the document
   defines the OAM use principals for the DetNet networks with IP data
   plane.

2.  Conventions used in this document








Mirsky, et al.         Expires September 24, 2020               [Page 2]


Internet-Draft           OAM for DetNet over IP               March 2020


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

   Underlay Network or Underlay Layer: The network that provides
   connectivity between the DetNet nodes.  MPLS network providing LSP
   connectivity between DetNet nodes is an example of the underlay
   layer.

   DetNet Node - a node that is an actor in the DetNet domain.  DetNet
   domain edge node and node that performs PREF within the domain are
   examples of DetNet node.

2.2.  Keywords

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Active OAM for DetNet Networks with IP Data Plane

   OAM protocols and mechanisms act within the data plane of the
   particular networking layer.  And thus it is critical that the data
   plane encapsulation supports OAM mechanisms in such a way that DetNet
   OAM packets are in-band with a DetNet flow being monitored, i.e.,
   DetNet OAM test packets follow precisely the same path as DetNet data
   plane traffic both for unidirectional and bi-directional DetNet
   paths.





Mirsky, et al.         Expires September 24, 2020               [Page 3]


Internet-Draft           OAM for DetNet over IP               March 2020


   The DetNet data plane encapsulation in a transport network with IP
   encapsulations specified in Section 6 of [I-D.ietf-detnet-ip].  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 STAMP [RFC8762], use UDP transport and
   the well-known UDP port numbers as the destination port.  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.

   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.  Because ICMP is another IP
   protocol like, for example, UDP, a DetNet node MUST able to associate
   an ICMP packet generated by the specified IP DetNet node and
   addressed to the another IP DetnNet node with an IP DetNet flow
   between this pair of endpoints.

3.1.  Active OAM Using DetNet-in-UDP Encapsulation

   Active OAM in IP DetNet can be realized using DetNet-in-UDP
   encapsulation [Ed.note: Do we define it in this document or start a
   new one?].  Using DetNet-in-UDP tunnel between IP DetNet nodes
   ensures that active OAM test packets are fate-sharing with the
   packets of the being monitored IP DetNet flow.  As a result, a test
   packet shares the tunnel with IP DetNet flow and shares the fate,
   statistically speaking, of the IP DetNet flow being monitored.

3.2.  Mapping Active OAM and IP DetNet flows

   IP OAM protocols that use UDP transport, e.g., BFD and STAMP, can be
   used to detect failures or performance degradation that affects an IP
   DetNet flow.  When the UDP destination port number used by the OAM
   protocol is one of the assigned by IANA, then the UDP source port can
   be used to achieve co-routedness of OAM, and the monitored IP DetNet
   flow in the multipath environments, e.g., LAG or ECMP.  To maximize
   the accuracy of OAM results in detecting failures and monitoring
   performance of IP DetNet, test packets should receive the same
   treatment by the nodes as experienced by the IP DetNet packet.
   Hence, the DSCP value used for a test packet MUST be mapped to
   DetNet.





Mirsky, et al.         Expires September 24, 2020               [Page 4]


Internet-Draft           OAM for DetNet over IP               March 2020


3.3.  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.  Use of Hybrid OAM in DetNet

   Hybrid OAM methods are used in performance monitoring and defined in
   [RFC7799] as:

      Hybrid Methods are Methods of Measurement that use a combination
      of Active Methods and Passive Methods.

   A hybrid measurement method may produce metrics as close to passive,
   but it still alters something in a data packet even if that is the
   value of a designated field in the packet encapsulation.  One example
   of such a hybrid measurement method is the Alternate Marking method
   (AMM) described in [RFC8321].  One of the advantages of the use of
   AMM in a DetNet domain with IP data plane is that the marking is
   applied to a data flow, thus ensuring that a measured metrics are
   directly applicable to the DetNet flow.

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, and does not
   raise any security concerns or issues in addition to ones common to
   networking or already documented for the referenced DetNet and OAM
   protocols.








Mirsky, et al.         Expires September 24, 2020               [Page 5]


Internet-Draft           OAM for DetNet over IP               March 2020


7.  Acknowledgment

   TBA

8.  References

8.1.  Normative References

   [I-D.ietf-detnet-ip]
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-
              ip-05 (work in progress), February 2020.

   [I-D.mirsky-detnet-mpls-oam]
              Mirsky, G. and M. Chen, "Operations, Administration and
              Maintenance (OAM) for Deterministic Networks (DetNet) with
              MPLS Data Plane", draft-mirsky-detnet-mpls-oam-01 (work in
              progress), January 2020.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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





Mirsky, et al.         Expires September 24, 2020               [Page 6]


Internet-Draft           OAM for DetNet over IP               March 2020


8.2.  Informational References

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

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

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <https://www.rfc-editor.org/info/rfc8321>.

   [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
   ZTE Corp.

   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 September 24, 2020               [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/