RTGWG Working Group                                            G. Mirsky
Internet-Draft                                                    X. Min
Intended status: Standards Track                               ZTE Corp.
Expires: 30 September 2021                                     G. Mishra
                                                            Verizon Inc.
                                                           29 March 2021


         Integrated Operation, Administration, and Maintenance
                   draft-mmm-rtgwg-integrated-oam-01

Abstract

   This document describes the Integrated Operation, Administration, and
   Maintenance (IntOAM) protocol.  IntOAM is based on the lightweight
   capabilities of Bidirectional Forwarding Detection defined in RFC
   5880 Bidirectional Forwarding Detection, and the RFC 6374 Packet Loss
   and Delay Measurement for MPLS Networks to measure performance
   metrics like packet loss and packet delay.  Also, a method to perform
   lightweight on-demand authentication is defined in this
   specification.

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 30 September 2021.

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 (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



Mirsky, et al.          Expires 30 September 2021               [Page 1]


Internet-Draft               Integrated OAM                   March 2021


   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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Integrated OAM Control Message  . . . . . . . . . . . . . . .   3
   4.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Use of Discriminators . . . . . . . . . . . . . . . . . .   6
     4.2.  Modes of IntOAM . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Echo Function . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Using TLVs in the IntOAM  . . . . . . . . . . . . . . . . . .   7
     5.1.  Integrated OAM Capability Negotiation . . . . . . . . . .   7
       5.1.1.  Timer Negotiation for Performance Monitoring  . . . .   9
     5.2.  Padding TLV . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Diagnostic TLV  . . . . . . . . . . . . . . . . . . . . .  11
     5.4.  Performance Measurement with IntOAM Control Message . . .  12
     5.5.  Lightweight Authentication  . . . . . . . . . . . . . . .  13
       5.5.1.  Lightweight Authentication Mode Negotiation . . . . .  14
       5.5.2.  Using Lightweight Authentication  . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  IntOAM Message Types  . . . . . . . . . . . . . . . . . .  16
     6.2.  Lightweight Authentication Modes  . . . . . . . . . . . .  17
     6.3.  Return Codes  . . . . . . . . . . . . . . . . . . . . . .  18
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   [RFC5880] has provided the base specification of Bidirectional
   Forwarding Detection (BFD) as the light-weight mechanism to monitor a
   path continuity between two systems and detect a failure in the data-
   plane.  Since its introduction, BFD has been broadly deployed.  There
   were several attempts to introduce new capabilities in the protocol,
   some more successful than others.  One of the obstacles to extending
   BFD capabilities may be seen in the compact format of the BFD control
   message.  This document introduces the Integrated Operation,
   Administration, and Maintenance (IntOAM) protocol based on BFD's
   lightweight capabilities.  It uses informational elements defined in



Mirsky, et al.          Expires 30 September 2021               [Page 2]


Internet-Draft               Integrated OAM                   March 2021


   [RFC6374] to measure various performance metrics, e.g., synthetic
   packet loss or packet delay.  Combination of both Fault Management
   (FM) Performance Monitoring (PM) OAM functions in the IntOAM protocol
   is beneficial in some networks.  For example, in a Deterministic
   Networking (DetNet) domain [RFC8655], it is easier to ensure that an
   IntOAM's test packet is fate-sharing with data packets rather than
   mapping several FM and PM OAM protocols to that DetNet data flow.

2.  Conventions used in this document

2.1.  Acronyms

   BFD: Bidirectional Forwarding Detection

   G-ACh Generic Associated Channel

   IntOAM Integrated OAM

   HMAC Hashed Message Authentication Code

   MTU Maximum Transmission Unit

   PMTUD Path MTU Discovery

   PMTUM Path MTU Monitoring

   p2p: Point-to-Point

   TLV Type, Length, Value

   OAM Operations, Administration, and Maintenance

   FM Fault Management

   PM Performance Monitoring

   DetNet Deterministic Networking

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

3.  Integrated OAM Control Message




Mirsky, et al.          Expires 30 September 2021               [Page 3]


Internet-Draft               Integrated OAM                   March 2021


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | V |  Diag   |Sta|P|F|D|M|               Reserved              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Detect Mult          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       My Discriminator                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Your Discriminator                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Desired Min TX Interval                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Required Min RX Interval                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Required Min Echo RX Interval                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                      TLVs   (variable)                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: Integrated OAM Control Message Format

   where fields are defined as the following:

   *  Version (V) - two-bit field.  The definition of the field, its
      interpretation, use in the protocol operation, and assigned values
      are as defined in [RFC5880] for the Version field.

   *  Diagnostic (Diag) - five-bit field.  The definition of the field,
      its interpretation, use in the protocol operation, and assigned
      values are as defined in [RFC5880] for the Diagnostic field.

   *  Status (Sta) - two-bit field.  The definition of the field, its
      interpretation, use in the protocol operation, and assigned values
      are as defined in [RFC5880] for the Status field.

   *  Poll (P) - one-bit field The definition of the field, its
      interpretation, use in the protocol operation, and assigned values
      are as defined in [RFC5880] for the Poll field.

   *  Final (F) - one-bit field.  The definition of the field, its
      interpretation, use in the protocol operation, and assigned values
      are as defined in [RFC5880] for the Final field.






Mirsky, et al.          Expires 30 September 2021               [Page 4]


Internet-Draft               Integrated OAM                   March 2021


   *  Demand (D) - one-bit field.  The definition of the field, its
      interpretation, use in the protocol operation, and assigned values
      are as defined in [RFC5880] for the Demand field.

   *  Multipoint (M) - one-bit field.  The definition of the field, its
      interpretation, and its use in the protocol operation are as
      defined in [RFC5880] for the Multipoint field.

   *  Reserved - seventeen-bit field that can be defined in the future.
      It MUST be zeroed on transmission and ignored on receipt.

   *  Detect Mult - two-octet field.  The definition of the field, its
      interpretation, and its use in the protocol operation are as
      defined in [RFC5880] for the Detect Mult field.

   *  Length - two-octet field equal to the length of the IntOAM Control
      message in octets.

   *  My Discriminator - four-octet field.  The definition of the field,
      its interpretation, use in the protocol operation, and assigned
      values are as defined in [RFC5880] for the My Discriminator field.

   *  Your Discriminator - four-octet field.  The definition of the
      field, its interpretation, and its use in the protocol operation
      are as defined in [RFC5880] for the Your Discriminator field.

   *  Desired Min TX Interval - four-octet field.  The definition of the
      field, its interpretation, and its use in the protocol operation
      are as defined in [RFC5880] for the Desired Min TX Interval field.
      Additional use cases for the Desired Min TX Interval field
      described in Section 5.1.1.

   *  Required Min RX Interval - four-octet field.  The definition of
      the field, its interpretation, and its use in the protocol
      operation are as defined in [RFC5880] for the Required Min RX
      Interval field.  Additional use cases for the Required Min RX
      Interval field described in Section 5.1.1.

   *  Required Min Echo RX Interval - four-octet field.  [Ed.note: In
      BFD, as I understand, it serves several purposes - indicate
      support of Echo (zero value - non-support), and throttle rate the
      remote will send its Echo.  But that only works if the Echo can be
      sent when the session is Up.  There's now a proposal to send Echo
      regardless of the state of a session.  Hence the question - is it
      still a good use of four bytes?]

   *  TLVs - is a variable-length field that contains commands and/or
      data encoded as type-length-value (TLV) shown in Figure 2.



Mirsky, et al.          Expires 30 September 2021               [Page 5]


Internet-Draft               Integrated OAM                   March 2021


   TLV is a variable-length field.  Multiple TLVs MAY be placed in an
   IntOAM Control message.  Additional TLVs may be enclosed within a
   given TLV, subject to the semantics of the (outer) TLV in question.
   If more than one TLV is to be included, the value of the Type field
   of the outmost outer TLV MUST be set to Multiple TLVs Used (TBA0), as
   assigned by IANA according to Section 6.1.  Figure 2 displays the TLV
   format in an IntOAM protocol.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |    Reserved   |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                            Value                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: General Type-Length-Value Encoding

   where fields are defined as the following:

   *  Type - one-octet field that characterizes the interpretation of
      the Value field.  Type values are allocated according to
      Section 6.1.

   *  Reserved - one-octet field.  The value of the Type field
      determines its interpretation and encoding.

   *  Length - two-octet field equal to the length of the Value field in
      octets.

   *  Value - a variable-length field.  The value of the Type field
      determines its interpretation and encoding.

4.  Theory of Operation

   [Ed.note: Should the document reference Asynchronous and Demand modes
   in RFC 5880?]

4.1.  Use of Discriminators

   A discriminator is defined in the IntOAM as an unsigned 32-bit long
   integer that identifies a particular IntOAM session.  An IntOAM
   system MAY locally assign a discriminator for the given IntOAM
   session.  Also, a discriminator MAY be distributed by the control
   plane or management plane.





Mirsky, et al.          Expires 30 September 2021               [Page 6]


Internet-Draft               Integrated OAM                   March 2021


   In a point-to-point (p2p) IntOAM session, the value of the Your
   Discriminator field is used to demultiplex IntOAM sessions.  An
   IntOAM system has to learn the value of discriminator that the remote
   IntOAM system associates with the IntOAM session between these two
   systems.  The IntOAM system MAY use a three-way handshake mechanism
   to learn of discriminator of the remote system.  Besides, the control
   or management plane MAY be used to associate discriminator values
   with the specific IntOAM session.  In other scenarios, e.g., point-
   to-multipoint (p2mp) IntOAM session, the Your Discriminator's value
   could be left undefined for some nodes.  In that case, such a node
   uses the My Discriminator field's value in combination with
   information that identifies the sender of the IntOAM Control message
   and the path identifier.

4.2.  Modes of IntOAM

   IntOAM has two operational modes that provide for proactive defect
   detection in a network- Asynchronous and Demand.  An IntOAM
   implementation MUST be capable of operating in either of them.  In
   the Asynchronous mode, an IntOAM system periodically transmits IntOAM
   Control messages.  When an IntOAM system is in the Demand mode, it
   does not periodically transmit IntOAM Control messages.  An IntOAM
   system in the Demand mode MAY transmit a Control message as a part of
   the Poll sequence.  A system MAY be set into the Demand mode at any
   time during the IntOAM session.

4.3.  Echo Function

   The Echo function in IntOAM can be used in networks when an operator
   has ensured that the sender's test packet will first reach the
   intended target before being returned to the sender.  The target node
   is not required to support IntOAM as the IntOAM packet is expected to
   be looped back by the data plane without the need to inspect the test
   packet itself.  The IntOAM Control message and IntOAM TLVs MAY be
   used as the test packet by the IntOAM Echo function.

5.  Using TLVs in the IntOAM

5.1.  Integrated OAM Capability Negotiation

   An IntOAM system, also referred to as a node in this document, that
   supports IntOAM first MUST discover the extent to which other nodes
   in the given session support the Integrated OAM.  The node MUST send
   an IntOAM Control message initiating the Poll Sequence as defined in
   [RFC5880].  If the remote system fails to respond with the IntOAM
   Control message and the Final flag set, then the initiator node MUST
   conclude that the peer does not support the use of the IntOAM Control
   messages.



Mirsky, et al.          Expires 30 September 2021               [Page 7]


Internet-Draft               Integrated OAM                   March 2021


   The first IntOAM Control message initiating the Poll Sequence SHOULD
   include the Capability TLV that lists capabilities that may be used
   at some time during the lifetime of the IntOAM session.  Until the
   node negotiated the use of PM capabilities of the IntOAM, the node
   MUST NOT include any TLVs in the IntOAM Control message, other than
   the Capability TLV.  The format of the Capability TLV is presented in
   Figure 3.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Capability  |   Reserved    |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | L | D | M |                    Unassigned                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Authentication    ... |          Padding           ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3: Capability TLV Format

   where fields are defined as the following:

   *  Capability - one-octet field.  Its value (TBA2) allocated by IANA
      in Section 6

   *  Reserved - one-octet field.  It MUST be zeroed on the transmit and
      ignored on the receipt.

   *  Length - two-octet field.  The value equals length on the
      Capability TLV in octets.  The value of the Length field MUST be a
      multiple of 4.

   *  Loss - two-bit field.  The least significant of the two bits is
      set if the node can measure packet loss using a periodically
      transmitted IntOAM control message.  The most significant of the
      two bits is set if the node is capable of measuring packet loss
      using the Poll Sequence with IntOAM Control message.

   *  Delay - two-bit field.  The least significant of the two bits is
      set if the node can measure packet delay using a periodically
      transmitted IntOAM control message.  The most significant of the
      two bits is set if the node is capable of measuring packet delay
      using the Poll Sequence with IntOAM Control message.

   *  MTU - two-bits field.  Set if the node is capable of using the
      IntOAM Control message in Path MTU Discovery (PMTUD).  or PMTU
      Monitoring (PMTUM).  The least significant of the two bits is set



Mirsky, et al.          Expires 30 September 2021               [Page 8]


Internet-Draft               Integrated OAM                   March 2021


      if the node can perform PMTUD/PMTUM using periodically transmitted
      IntOAM control message.  The most significant of the two bits is
      set if the node is capable of PMTUD/PMTUM using the Poll Sequence
      with IntOAM Control message.

   *  Unassigned - 26-bit field.  It MUST be zeroed on transmission and
      ignored on receipt

   *  (Lightweight) Authentication - variable-length field.  An IntOAM
      system uses the Authentication field for advertising its
      lightweight authentication capabilities.  The format and the use
      of the Authentication field are defined in Section 5.5.1.

   *  Padding - variable-length field.  It MUST be zeroed on
      transmission and ignored on receipt.  The Padding field aligns the
      length of the Capability TLV to a four-octet boundary.

   The remote IntOAM node that supports this specification MUST respond
   to the Capability TLV with the IntOAM Control message, includeding
   the Capability TLV listing capabilities the responder supports.  The
   responder MUST set the Final flag in the IntOAM Control message.

5.1.1.  Timer Negotiation for Performance Monitoring

   IntOAM allows for the negotiation of time intervals at which an
   IntOAM system transmits and receives IntOAM Control packets.  That
   equally applies to packets used for performance monitoring, whether
   it measures packet delay or packet loss, using TLVs defined in
   Section 5.4.  An IntOAM system sets its timer values in an IntOAM
   Control packet that includes the Capabilities TLV.  The negotiation
   process is similar to the one described in [RFC5880].  A local IntOAM
   system advertises its shortest interval for transmitting IntOAM
   packets to measure the indicated metrics and the shortest interval
   that is it capable of receiving PM IntOAM packets.  Suppose a system
   does not support the given metric measurement, i.e., packet loss or
   packet delay.  In that case, it MUST set the value of the Required
   Min RX Interval to zero when transmitting the IntOAM Control message
   with the Capability TLV.  If an IntOAM system does not support one of
   the modes, periodic or on-demand, for the given performance metric,
   it MUST zero the appropriate bit in the field that describes the
   metric.  The timer values apply to all PM modes that have their
   respective bits set in the Capacity TLV.  If an operator wants to use
   a different time intervals for different performance metrics
   measurements, then separate Poll sequences with the Capabilities TLV
   included MAY be used.  Thus IntOAM allows negotiating different time
   intervals for packet loss and packet delay measurements.





Mirsky, et al.          Expires 30 September 2021               [Page 9]


Internet-Draft               Integrated OAM                   March 2021


5.2.  Padding TLV

   Padding TLV MAY be used to generate IntOAM Control messages of the
   desired length.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Padding    |    Reserved   |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                            Padding                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: Padding TLV Format

   where fields are defined as the following:

   *  Padding - one-octet field.  Its value (TBA1) allocated by IANA in
      Section 6

   *  Reserved - one-octet field.  MUST be zeroed on the transmit and
      ignored on the receipt.

   *  Length - two-octet field equals length on the Padding TLV in
      octets.  The value of the Length field MUST be a multiple of 4.

   *  Padding - variable-length field.  It MUST be zeroed on transmit
      and ignored on receipt.

   Padding TLV MAY be used to generate IntOAM Control messages of
   different lengths.  That capability is necessary to perform PMTUD,
   PMTUM, and measure synthetic packet loss and/or packet delay.  When
   Padding TLV is used in combination with one of the performance
   measurement messages carried in Performance Metric TLVs as defined in
   Section 5.4, Padding TLV MUST follow the Performance Metric TLV.













Mirsky, et al.          Expires 30 September 2021              [Page 10]


Internet-Draft               Integrated OAM                   March 2021


   Padding TLV MAY be used in PMTUM as part of periodically sent IntOAM
   Control messages.  In this case, the number of consecutive messages
   that include Padding TLV MUST be not lesser than Detect Multiplier to
   ensure that the remote IntOAM peer will detect loss of messages with
   the Padding TLV.  Also, Padding TLV MAY be present in an IntOAM
   Control message with the Poll flag set.  If the remote IntOAM peer
   that supports this specification receives an IntOAM Control message
   with Padding TLV, it MUST include the Padding TLV with the Padding
   field of the same length as in the received packet and set the Final
   flag.

5.3.  Diagnostic TLV

   Diagnostic TLV MAY be used to characterize the result of the last
   requested operation.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Diagnostic  |    Reserved   |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Return Code  |                  Reserved                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5: Diagnostic TLV Format

   where fields are defined as the following:

   *  Diagnostic - one-octet field.Its value (TBA6) allocated by IANA in
      Section 6.

   *  Reserved - one-octet field.  MUST be zeroed on the transmit and
      ignored on the receipt.

   *  Length - tw-octet field.  Its value MUST be set to eight.

   *  Return Code - eight-bit field.  The responding IntOAM system can
      set it to one of the values defined in Section 6.3.

   *  Reserved - 24 bits-long field.  MUST be zeroed on transmit and
      ignored on receipt.









Mirsky, et al.          Expires 30 September 2021              [Page 11]


Internet-Draft               Integrated OAM                   March 2021


5.4.  Performance Measurement with IntOAM Control Message

   Loss measurement, delay measurement, and loss/delay measurement
   messages can be used in the IntOAM Control message to obtain
   respective one-way and round-trip metrics.  All the messages are
   encapsulated as TLVs with Type values allocated by IANA, Section 6.

   The sender MAY use the Performance Metric TLV (presented in Figure 6)
   to measure performance metrics and obtain the measurement report from
   the receiver.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Perf. Metric |    Reserved   |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Loss Measurement Message,                  |
      ~               Delay Measurement Message, or                   ~
      |              Combined Loss/Delay Measurement Message          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: Performance Metric TLV Format

   where fields are defined as the following:

   *  Performance Metric - one-octet field.  Valid vaues are TBA3
      through TBA5 allocated by IANA in Section 6 as follows:

      -  TBA3 - Loss Measurement Type;

      -  TBA4 - Delay Measurement Type;

      -  TBA5 - Combined Loss/Delay Measurement Type

   *  Reserved - one-octet field.  MUST be zeroed on the transmit and
      ignored on the receipt.

   *  Length - two-octet field equals length on the Performance Metric
      TLV in octets.  The value of the Length field MUST be a multiple
      of 4.

   *  Value - various performance metrics measured either directly or
      using synthetic methods accordingly using the messages defined in
      Sections 3.1 through 3.3 [RFC6374].






Mirsky, et al.          Expires 30 September 2021              [Page 12]


Internet-Draft               Integrated OAM                   March 2021


   To perform one-way loss and/or delay measurement, the IntOAM node MAY
   periodically transmit the IntOAM message with one of the TLVs listed
   above in Asynchronous mode.  To perform synthetic loss measurement,
   the sender MUST monotonically increment the counter of transmitted
   test packets.  When using Performance Metric TLV for synthetic
   measurement, an IntOAM Control message MAY also include Padding TLV.
   In that case, the Padding TLV MUST immediately follow Performance
   Metric TLV.  Also, direct-mode loss measurement, as described in
   [RFC6374], is supported.  Procedures to negotiate and manipulate
   transmission intervals defined in Sections 6.8.2 and 6.8.3 in
   [RFC5880] SHOULD be used to control the performance impact of using
   the IntOAM for performance measurement in the particular IntOAM
   session.

   To measure the round-trip loss and/or delay metrics, an IntOAM node
   transmits the IntOAM Control message with the Performance Metric TLV
   with the Poll flag set.  Before transmitting the IntOAM Control
   message with the Performance Metric TLV, the receiver MUST clear the
   Poll flag and set the Final flag.

5.5.  Lightweight Authentication

   Using IntOAM without any security measures, such as exchanging IntOAM
   Control messages without authentication, increases the risk of an
   attack, especially over multiple nodes.  Thus, using IntOAM without
   security measures may cause false positive or false negative defect
   detection situations.  In the former, an attacker may spoof IntOAM
   Control messages pretending to be a remote peer and can thus view the
   IntOAM session operation even though the real path had failed.  In
   the latter, the attacker may spoof an altered IntOAM control message
   indicating that the IntOAM session is un-operational even though the
   path and the remote IntOAM peer operate normally.

   BFD [RFC5880] allows for optional authentication protection of BFD
   Control messages to minimize the chances of attacks in a networking
   system.  However, at least some of the supported authentication
   protocols do not provide sufficient protection in modern networks.
   Also, the current BFD technology requires authentication of each BFD
   Control message.  Such an authentication requirement can put a
   computational burden on networking devices, especially in the
   Asynchronous mode, at least because authenticating each BFD Control
   message can require substantial computing resources to support packet
   exchange at high rates.

   This specification defines a lightweight on-demand mode of
   authentication for an IntOAM session.  The lightweight authentication
   is an optional mode.  The mechanism includes negotiation
   (Section 5.5.1) and on-demand authentication (Section 5.5.2) phases.



Mirsky, et al.          Expires 30 September 2021              [Page 13]


Internet-Draft               Integrated OAM                   March 2021


   During the former, IntOAM peers advertise supported authentication
   capabilities and independently select the commonly supported mode of
   the authentication.  In the authentication phase, each IntOAM system
   transmits, at certain events or periodically, authenticated IntOAM
   Control messages in Poll Sequence.

5.5.1.  Lightweight Authentication Mode Negotiation

   Figure 7 displays the format of the Authentication field that is part
   of the Capability Encoding:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Len  | AuthL |    Authentication Mode         ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 7: Lightweight Authentication Capability Field Format

   where fields are defined as the following:

   *  Len (Length) - four-bit field.  The value of the Length field is
      equal to the length of the Authentication field, including the
      Length, in octets.

   *  AuthL (Authentication Length) - four-bit field.  The value of the
      field is, in four octets long words, the longest authentication
      signature the IntOAM system is capable of supporting for any of
      the methods advertised in the AuthMode field.

   *  Authentication Mode - variable-length field.  It is a bit-coded
      field that an IntOAM system uses to list modes of lightweight
      authentication it supports.

   An IntOAM system uses Capability TLV, defined in Section 5.1, to
   discover the commonly supported mode of the Lightweight
   Authentication.  The system sets the values in the Authentication
   field according to properly reflect its authentication capabilities.
   The IntOAM system transmits the IntOAM Control message with
   Capability TLV as the first in a Poll Sequence.  The remote IntOAM
   system that supports this specification receives the IntOAM Control
   message with the advertised Lightweight Authentication modes and
   stores information locally.  The system responds with the
   advertisement of its Lightweight Authentication capabilities in the
   IntOAM Control message with the Final flag set.  Each IntOAM system
   uses local and received information about Lightweight Authentication
   capabilities to deduce the commonly supported modes and selects from



Mirsky, et al.          Expires 30 September 2021              [Page 14]


Internet-Draft               Integrated OAM                   March 2021


   that set to use the strongest authentication with the longest
   signature.  If the common set is empty, i.e., none of supported by
   one IntOAM system authentication method is supported by another, an
   implementation MUST reflect this in its operational state and SHOULD
   notify an operator.

5.5.2.  Using Lightweight Authentication

   After IntOAM peers select an authentication mode for use in
   Lightweight Authentication each IntOAM system MUST use it to
   authenticate each IntOAM Control message transmitted as part of a
   Poll Sequence using Lightweight Authentication TLV presented in
   Figure 8.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Authentication|    Reserved   |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                             HMAC                              ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 8: Lightweight Authentication TLV Format

   where fields are defined as the following:

   *  Lightweight Authentication - one-octet field.It value (TBA8)
      allocated by IANA in Section 6

   *  Reserved - one-octet field.  MUST be zeroed on the transmit and
      ignored on the receipt.

   *  Length - two-octet long field.  The value equals length on the
      Lightweight Authentication TLV field in octets.  The value of the
      Length field MUST be a multiple of 4.

   *  HMAC (Hashed Message Authentication Code) - variable-length field.
      The value is the hash value calculated on the entire preceding
      IntOAM Control message data.

   The Lightweight Authentication TLV MUST be the last in an IntOAM
   Control message.  Padding TLV (Section 5.2) MAY be used to align the
   length of the IntOAM Control message, excluding the Lightweight
   Authentication TLV, at multiple of 16 boundary.




Mirsky, et al.          Expires 30 September 2021              [Page 15]


Internet-Draft               Integrated OAM                   March 2021


   The IntOAM system that receives the IntOAM Control message with the
   Lightweight Authentication TLV MUST first validate the
   .authentication by calculating the hash over the IntOAM Control
   message.  If the validation succeeds, the receiver MUST transmit the
   IntOAM Control message with the Final flag set and the value of the
   Return code field in Diagnostic TLV set to None value (Table 5).  If
   the validation of the lightweight authentication fails, then the
   IntOAM system MUST transmit the IntOAM Control message with the Final
   flag set and the value of the Return Code field of the Diagnostic TLV
   set to Lightweight Authentication failed value (Table 5).  The IntOAM
   system MUST have a control policy that defines actions when the
   system receives the Lightweight Authentication failed return code.

6.  IANA Considerations

6.1.  IntOAM Message Types

   IANA is requested to create the IntOAM TLV Type registry.  All code
   points in the range 1 through 175 in this registry shall be allocated
   according to the "IETF Review" procedure specified in [RFC8126].
   Code points in the range 176 through 239 in this registry shall be
   allocated according to the "First Come First Served" procedure
   specified in [RFC8126].  The remaining code points are allocated
   according to Table 1:

               +===========+==============+===============+
               | Value     | Description  | Reference     |
               +===========+==============+===============+
               | 0         |   Reserved   | This document |
               +-----------+--------------+---------------+
               | 1- 175    |  Unassigned  | This document |
               +-----------+--------------+---------------+
               | 176 - 239 |  Unassigned  | This document |
               +-----------+--------------+---------------+
               | 240 - 251 | Experimental | This document |
               +-----------+--------------+---------------+
               | 252 - 254 | Private Use  | This document |
               +-----------+--------------+---------------+
               | 255       |   Reserved   | This document |
               +-----------+--------------+---------------+

                      Table 1: IntOAM Type Registry

   This document defines the following new values in IntOAM Type
   registry:






Mirsky, et al.          Expires 30 September 2021              [Page 16]


Internet-Draft               Integrated OAM                   March 2021


        +=======+=================================+===============+
        | Value |           Description           | Reference     |
        +=======+=================================+===============+
        | TBA0  |        Multiple TLVs Used       | This document |
        +-------+---------------------------------+---------------+
        | TBA1  |             Padding             | This document |
        +-------+---------------------------------+---------------+
        | TBA2  |            Capability           | This document |
        +-------+---------------------------------+---------------+
        | TBA3  |         Loss Measurement        | This document |
        +-------+---------------------------------+---------------+
        | TBA4  |        Delay Measurement        | This document |
        +-------+---------------------------------+---------------+
        | TBA5  | Combined Loss/Delay Measurement | This document |
        +-------+---------------------------------+---------------+
        | TBA6  |            Diagnostic           | This document |
        +-------+---------------------------------+---------------+
        | TBA8  |    Lightweight Authentication   | This document |
        +-------+---------------------------------+---------------+

                           Table 2: IntOAM Types

6.2.  Lightweight Authentication Modes

   IANA is requested to create a Lightweight Authentication Modes
   registry.  All code points in this registry shall be allocated
   according to the "IETF Review" procedure as specified in [RFC8126].

   This document defines the following new values in the Lightweight
   Authentication Modes registry:

     +==============+=======+========================+===============+
     | Bit Position | Value |      Description       | Reference     |
     +==============+=======+========================+===============+
     | 0            | 0x1   |      Keyed SHA-1       | This document |
     +--------------+-------+------------------------+---------------+
     | 1            | 0x2   | Meticulous Keyed SHA-1 | This document |
     +--------------+-------+------------------------+---------------+
     | 2            | 0x4   |        SHA-256         | This document |
     +--------------+-------+------------------------+---------------+

                 Table 3: Lightweight Authentication Modes









Mirsky, et al.          Expires 30 September 2021              [Page 17]


Internet-Draft               Integrated OAM                   March 2021


6.3.  Return Codes

   IANA is requested to create the IntOAM Return Codes registry.  All
   code points in the range 1 through 250 in this registry shall be
   allocated according to the "IETF Review" procedure as specified in
   [RFC8126].  The remaining code points are allocated according to
   Table 4:

                +=========+==============+===============+
                | Value   | Description  | Reference     |
                +=========+==============+===============+
                | 0       |   Reserved   | This document |
                +---------+--------------+---------------+
                | 1- 250  |  Unassigned  | IETF Review   |
                +---------+--------------+---------------+
                | 251-253 | Experimental | This document |
                +---------+--------------+---------------+
                | 254     | Private Use  | This document |
                +---------+--------------+---------------+
                | 255     |   Reserved   | This document |
                +---------+--------------+---------------+

                  Table 4: IntOAM Return Codes Registry

   This document defines the following new values in IntOAM Return Codes
   registry:

      +=======+=====================================+===============+
      | Value |             Description             | Reference     |
      +=======+=====================================+===============+
      | 0     |                 None                | This document |
      +-------+-------------------------------------+---------------+
      | 1     | One or more TLVs was not understood | This document |
      +-------+-------------------------------------+---------------+
      | 2     |  Lightweight Authentication failed  | This document |
      +-------+-------------------------------------+---------------+

                        Table 5: IntOAM Return Codes

7.  Security Considerations

   The same security considerations as those described in [RFC5880],
   [RFC6374], and [RFC8562]. apply to this document.  Additionally,
   implementations that use distribution of discriminators over the
   control or management plane MUST use secure channels to protect
   systems from an infinite number of IntOAM sessions being created.





Mirsky, et al.          Expires 30 September 2021              [Page 18]


Internet-Draft               Integrated OAM                   March 2021


   In some environments, an IntoOAM session can be instantiated using a
   bootstrapping mechanism supported by the control or management plane.
   As a result, the three-way handshaking mechanism between IntOAM
   systems is bypassed.  That could cause the situation where one of the
   systems uses overaggressive transmission intervals that are not
   acceptable to the remote IntOAM system.  As a result, IntOAM Control
   messages could be dropped, and the remote IntOAM system concludes the
   IntOAM session failed.  The environment that does not use the three-
   way handshake mechanism to instantiate an IntOAM session MUST support
   means to balance resources used by the IntOAM.

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

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

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

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

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

   [RFC8562]  Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
              Ed., "Bidirectional Forwarding Detection (BFD) for
              Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,
              April 2019, <https://www.rfc-editor.org/info/rfc8562>.

9.2.  Informative References



Mirsky, et al.          Expires 30 September 2021              [Page 19]


Internet-Draft               Integrated OAM                   March 2021


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

Authors' Addresses

   Greg Mirsky
   ZTE Corp.

   Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com


   Xiao Min
   ZTE Corp.

   Email: xiao.min2@zte.com.cn


   Gyan Mishra
   Verizon Inc.

   Email: gyan.s.mishra@verizon.com




























Mirsky, et al.          Expires 30 September 2021              [Page 20]