Integrated Operation, Administration, and Maintenance
draft-mmm-rtgwg-integrated-oam-00
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 "Expired".
|
|
|---|---|---|---|
| Authors | Greg Mirsky , Xiao Min , Gyan Mishra | ||
| Last updated | 2021-02-18 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mmm-rtgwg-integrated-oam-00
RTGWG Working Group G. Mirsky
Internet-Draft X. Min
Intended status: Standards Track ZTE Corp.
Expires: August 22, 2021 G. Mishra
Verizon Inc.
February 18, 2021
Integrated Operation, Administration, and Maintenance
draft-mmm-rtgwg-integrated-oam-00
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 August 22, 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
Mirsky, et al. Expires August 22, 2021 [Page 1]
Internet-Draft Integrated OAM February 2021
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Integrated OAM Control Message . . . . . . . . . . . . . . . 4
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 . . . 11
5.5. Lightweight Authentication . . . . . . . . . . . . . . . 13
5.5.1. Lightweight Authentication Mode Negotiation . . . . . 13
5.5.2. Using Lightweight Authentication . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. IntOAM Message Types . . . . . . . . . . . . . . . . . . 16
6.2. Lightweight Authentication Modes . . . . . . . . . . . . 16
6.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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
Mirsky, et al. Expires August 22, 2021 [Page 2]
Internet-Draft Integrated OAM February 2021
lightweight capabilities. It uses informational elements defined in
[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.
Mirsky, et al. Expires August 22, 2021 [Page 3]
Internet-Draft Integrated OAM February 2021
3. Integrated OAM Control Message
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:
o 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.
o 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.
o 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.
o 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.
o 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 August 22, 2021 [Page 4]
Internet-Draft Integrated OAM February 2021
o 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.
o 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.
o Reserved - seventeen-bit field that can be defined in the future.
It MUST be zeroed on transmission and ignored on receipt.
o 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.
o Length - two-octet field equal to the length of the IntOAM Control
message in octets.
o 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.
o 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.
o 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.
o 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.
o 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?]
o 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 August 22, 2021 [Page 5]
Internet-Draft Integrated OAM February 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:
o Type - one-octet field that characterizes the interpretation of
the Value field. Type values are allocated according to
Section 6.1.
o Reserved - one-octet field. The value of the Type field
determines its interpretation and encoding.
o Length - two-octet field equal to the length of the Value field in
octets.
o 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.
In a point-to-point (p2p) IntOAM session, the value of the Your
Discriminator field is used to demultiplex IntOAM sessions. An
Mirsky, et al. Expires August 22, 2021 [Page 6]
Internet-Draft Integrated OAM February 2021
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 August 22, 2021 [Page 7]
Internet-Draft Integrated OAM February 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:
o Capability - one-octet field. Its value (TBA2) allocated by IANA
in Section 6
o Reserved - one-octet field. It MUST be zeroed on the transmit and
ignored on the receipt.
o 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.
o 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.
o 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.
o 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
if the node can perform PMTUD/PMTUM using periodically transmitted
Mirsky, et al. Expires August 22, 2021 [Page 8]
Internet-Draft Integrated OAM February 2021
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.
o Unassigned - 26-bit field. It MUST be zeroed on transmission and
ignored on receipt
o (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.
o 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 August 22, 2021 [Page 9]
Internet-Draft Integrated OAM February 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:
o Padding - one-octet field. Its value (TBA1) allocated by IANA in
Section 6
o Reserved - one-octet field. MUST be zeroed on the transmit and
ignored on the receipt.
o Length - two-octet field equals length on the Padding TLV in
octets. The value of the Length field MUST be a multiple of 4.
o 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.
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.
Mirsky, et al. Expires August 22, 2021 [Page 10]
Internet-Draft Integrated OAM February 2021
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:
o Diagnostic - one-octet field.Its value (TBA6) allocated by IANA in
Section 6.
o Reserved - one-octet field. MUST be zeroed on the transmit and
ignored on the receipt.
o Length - tw-octet field. Its value MUST be set to eight.
o Return Code - eight-bit field. The responding IntOAM system can
set it to one of the values defined in Section 6.3.
o Reserved - 24 bits-long field. MUST be zeroed on transmit and
ignored on receipt.
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.
Mirsky, et al. Expires August 22, 2021 [Page 11]
Internet-Draft Integrated OAM February 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
o 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
o Reserved - one-octet field. MUST be zeroed on the transmit and
ignored on the receipt.
o 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.
o Value - various performance metrics measured either directly or
using synthetic methods accordingly using the messages defined in
Sections 3.1 through 3.3 [RFC6374].
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.
Mirsky, et al. Expires August 22, 2021 [Page 12]
Internet-Draft Integrated OAM February 2021
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.
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:
Mirsky, et al. Expires August 22, 2021 [Page 13]
Internet-Draft Integrated OAM February 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | AuthL | Authentication Mode ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Lightweight Authentication Capability Field Format
where fields are defined as the following:
o 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.
o 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.
o 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
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
Mirsky, et al. Expires August 22, 2021 [Page 14]
Internet-Draft Integrated OAM February 2021
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:
o Lightweight Authentication - one-octet field.It value (TBA8)
allocated by IANA in Section 6
o Reserved - one-octet field. MUST be zeroed on the transmit and
ignored on the receipt.
o 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.
o 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.
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.
Mirsky, et al. Expires August 22, 2021 [Page 15]
Internet-Draft Integrated OAM February 2021
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:
+-------+---------------------------------+---------------+
| 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].
Mirsky, et al. Expires August 22, 2021 [Page 16]
Internet-Draft Integrated OAM February 2021
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
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
Mirsky, et al. Expires August 22, 2021 [Page 17]
Internet-Draft Integrated OAM February 2021
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.
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>.
Mirsky, et al. Expires August 22, 2021 [Page 18]
Internet-Draft Integrated OAM February 2021
[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
[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
Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Mirsky, et al. Expires August 22, 2021 [Page 19]