NVO3 Working Group G. Mirsky
Internet-Draft X. Min
Intended status: Standards Track ZTE Corp.
Expires: January 14, 2021 S. Boutros
Ciena
D. Black
Dell EMC
S. Pallagatti, Ed.
VMware
July 13, 2020
OAM for use in GENEVE
draft-mmbb-nvo3-geneve-oam-03
Abstract
This document defines encapsulation for active Operations,
Administration, and Maintenance protocols in Geneve protocol. Also,
the format and operation of the Echo Request and Echo Reply mechanism
in Geneve are defined.
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 January 14, 2021.
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
Mirsky, et al. Expires January 14, 2021 [Page 1]
Internet-Draft OAM in GENEVE July 2020
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
1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. Active OAM Protocols in Geneve Networks . . . . . . . . . . . 3
2.1. A Control Channel in the Geneve Network . . . . . . . . . 4
2.2. OAM Encapsulation in Geneve . . . . . . . . . . . . . . . 4
2.3. Associated Control Channel in Geneve Networks . . . . . . 5
2.3.1. Use of the Geneve ACC Header in Active OAM . . . . . 6
3. Echo Request and Echo Reply in Geneve Tunnel . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Geneve Associated Channel Protocol Types . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Additional Considerations for OAM Encapsulation
Method in Geneve . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Geneve [I-D.ietf-nvo3-geneve] is intended to support various
scenarios of network virtualization. In addition to carrying multi-
protocol payload, e.g., Ethernet, IPv4/IPv6, the Geneve message
includes metadata. Operations, Administration, and Maintenance (OAM)
protocols support fault management and performance monitoring
functions necessary for comprehensive network operation. Active OAM
protocols, as defined in [RFC7799], use specially constructed
packets, that are injected into the network. To ensure that the
measured performance metric or the detected failure of the transport
layer are related to the particular Geneve flow, it is critical that
these test packets share fate with overlay data packets when
traversing the underlay network.
This document describes several options for encapsulation of active
OAM protocols in Geneve. These are intended to facilitate the
discussion among experts and all interested in both OAM and Geneve
subjects. The goal of such analysis is the selection of a practical
Mirsky, et al. Expires January 14, 2021 [Page 2]
Internet-Draft OAM in GENEVE July 2020
number of encapsulation methods and providing definitions of any
introduced constructs.
Also, a set of generic requirements for active OAM protocols in
Geneve overlay network introduced in this document. These should be
used in selecting the most suitable encapsulation for active OAM in
Geneve.
1.1. Conventions used in this document
1.1.1. Terminology
CC Continuity Check
CV Connectivity Verification
FM Fault Management
GAL Generic Associated Channel Label
Geneve Generic Network Virtualization Encapsulation
NVO3 Network Virtualization Overlays
OAM Operations, Administration, and Maintenance
ACC Associated Control Channel
1.1.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.
2. Active OAM Protocols in Geneve Networks
OAM protocols, whether it is part of fault management or performance
monitoring, intended to provide reliable information that can be used
to detect a failure, identify the defect, localize it, thus helping
to apply corrective actions to minimize the negative impact on
service. Several OAM protocols will be used to perform these
functions, protocols that require demultiplexing at the receiving
instance of Geneve. To improve the accuracy of the correlation
between the condition experienced by the monitored Geneve tunnel and
the state of the OAM protocol the OAM encapsulation is required to
comply with the following requirements:
Mirsky, et al. Expires January 14, 2021 [Page 3]
Internet-Draft OAM in GENEVE July 2020
REQ#1: Geneve OAM packets SHOULD share the fate with data traffic
of the monitored Geneve tunnel, i.e., be in-band with the
monitored traffic, follow precisely the same overlay and transport
path as packets with data payload, in the forward direction, i.e.
from ingress toward egress endpoint(s) of the OAM test.
REQ#2: Encapsulation of OAM control message and data packets in
underlay network MUST be indistinguishable from the underlay
network forwarding point of view.
REQ#3: Presence of OAM control message in Geneve packet MUST be
unambiguously identifiable.
A test packet generated by an active OAM protocol either for a defect
detection or performance measurement MUST be fate-sharing with the
data flow being monitored In an environment where multiple paths
through the domain are available transient nodes can be programmed to
use characteristic information to balance the load across available
paths. It is essential that a test packet follows the same route,
i.e., traverses the same set of nodes and links, as a data packet of
the monitored flow. Thus, the following requirement to support OAM
packet fate-sharing with the data flow:
REQ#4: It MUST be possible to express entropy for underlay Equal
Cost Multipath in Geneve encapsulation to avoid using data packet
content by underlay transient nodes.
2.1. A Control Channel in the Geneve Network
There's a need for a general control channel between Geneve tunnel
endpoints for OAM protocols that can be used for fault detection,
diagnostics, maintenance, and other functions. Such a control tunnel
is dedicated to carrying only control and management data between
tunnel endpoints. Thus, the control channel of a Geneve tunnel
SHOULD NOT carry tenant data. As no tenants are connected using the
control channel, a system that supports this specification, SHOULD
NOT forward a packet received over the control channel. Virtual
Network Identifier (VNI) is used to identify the control channel.
The value that is associated with this function is referred to as
Management VNI. It is RECOMMENDED that the value 1 be used as the
default value of Management VNI.
2.2. OAM Encapsulation in Geneve
One of the options is to use IP/UDP encapsulation for active OAM. In
this case, OAM protocols are identified by the destination UDP port
number. This approach is well-known and has been used, for example,
in MPLS networks. To use IP/UDP encapsulation for an active OAM
Mirsky, et al. Expires January 14, 2021 [Page 4]
Internet-Draft OAM in GENEVE July 2020
protocol the Protocol Type field of the Geneve header MUST be set to
IPv4 (0x0800) or IPv6 (0x86DD) value. But extra IP/UDP headers that
immediately follow the Geneve header add to processing of OAM
message, further disassociating OAM message from the Geneve header,
all of which may cause false negative or positive failure reports.
Also, the additional IP/UDP header adds noticeable overhead,
especially if the underlay is the IPv6 network.
2.3. Associated Control Channel in Geneve Networks
An associated control channel (ACC) in the Geneve network is the
channel that, by using the same encapsulation as user traffic,
follows the same path through the underlay network as user traffic.
In other words, the associated channel is in-band with user traffic.
Creating the notion of the ACC in the Geneve network ensures that
packets of active OAM protocols carried in the ACC are in-band with
user traffic.
An ACC can be defined directly for a Geneve tunnel. This document
defines the shim for Geneve is presented in Figure 1 to demultiplex
Geneve OAM protocols without much of the overhead. The value of the
Protocol Type MAY be set to 0x8902, the value assigned to the IEEE
802.1ag Connectivity Fault Management protocol as part of
[IEEE.8021Q] and shared by ITU-T G.8013/Y.1731 OAM functions and
mechanisms for Ethernet-based networks [ITU-T.1731]. Alternatively,
the new value MAY be requested from the Ether Types registry.
ACC Header immediately follows the Geneve header defined in
[I-D.ietf-nvo3-geneve] and identifies the type of message carried
over the Geneve ACC. The format of the Geneve ACC Header is:
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 | Msg Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the Associated Channel Header in Geneve Network
The ACC Header consists of the following fields:
o V - two bits long field indicates the current version of the ACC
Header. The current value is 0b00;
o Msg Type - 14 bits long field identifies a protocol. In the case
of active OAM, these could be Echo Request/Reply, BFD, Performance
Measurement;
Mirsky, et al. Expires January 14, 2021 [Page 5]
Internet-Draft OAM in GENEVE July 2020
o Length - two octets long field that is the length of the packet in
octets;
2.3.1. Use of the Geneve ACC Header in Active OAM
Active OAM methods, whether used for fault management or performance
monitoring, generate dedicated test packets [RFC7799]. Format of an
OAM test packet in the Geneve network presented in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Underlay network encapsulation ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Geneve
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Variable Length Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------
| V | Msg Type | Length | ACC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------
~ Active OAM message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Geneve OAM Header in Active OAM Packet
3. Echo Request and Echo Reply in Geneve Tunnel
[Ed.note] Will be expanded in future versions.
4. IANA Considerations
IANA is requested to create a new registry called "Geneve Associated
Channel".
4.1. Geneve Associated Channel Protocol Types
IANA is requested to create new sub-registry called "Geneve
Associated Channel Protocol Types" in the "Geneve Associated Channel"
registry. All code points in the range 1 through 15615 in this
registry shall be allocated according to the "IETF Review" procedure
as specified in [RFC8126]. Remaining code points are allocated
according to Table 1:
Mirsky, et al. Expires January 14, 2021 [Page 6]
Internet-Draft OAM in GENEVE July 2020
+---------------+--------------+-------------------------+
| Value | Description | Reference |
+---------------+--------------+-------------------------+
| 0 | Reserved | |
| 1 - 15615 | Unassigned | IETF Review |
| 15616 - 16127 | Unassigned | First Come First Served |
| 16128 - 16143 | Experimental | This document |
| 16144 - 16382 | Private Use | This document |
| 16383 | Reserved | This document |
+---------------+--------------+-------------------------+
Table 1: Geneve OAM Protocol type
5. Security Considerations
As part of a Geneve network, active OAM inherits the security
considerations discussed in [I-D.ietf-nvo3-geneve]. Additionally, a
system MUST provide a control to limit the rate of Geneve OAM packets
punted for to the Geneve control plane for processing.
6. Acknowledgment
TBD
7. References
7.1. Normative References
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-16 (work in progress), March 2020.
[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>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
Mirsky, et al. Expires January 14, 2021 [Page 7]
Internet-Draft OAM in GENEVE July 2020
[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>.
7.2. Informative References
[IEEE.8021Q]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks", IEEE Std
802.1Q, December 2014.
[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.
[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>.
[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>.
Appendix A. Additional Considerations for OAM Encapsulation Method in
Geneve
Several other options of OAM encapsulation were considered. Those
are listed in the Appendix solely for the informational purpose.
A Protocol Type field might be used to demultiplex active OAM
protocols directly. Such method avoids the use of additional
intermediate header but requires that each active OAM protocol be
assigned unique identifier from the Ether Types registry maintained
by IANA.
The alternative to using the Protocol Type directly is to use a shim
that, in turn, identifies the OAM Protocol and, optionally, includes
additional information. [RFC5586] defines how the Generic Associated
Channel Label (GAL) can be used to identify that the Associated
Channel Header (ACH), defined in [RFC4385], immediately follows the
Bottom-of-the-Stack label. Thus the MPLS Generic Associated Channel
can be identified, and protocols are demultiplexed based on the value
of the Channel Type field. Number of channel types, e.g., for
continuity check and performance monitoring, already have been
defined and are listed in IANA MPLS Generalized Associated Channel
Types (including Pseudowire Associated Channel Types) registry. To
Mirsky, et al. Expires January 14, 2021 [Page 8]
Internet-Draft OAM in GENEVE July 2020
use this approach, the value of the Protocol Type field in the Geneve
header MUST be set to MPLS. The Geneve header MUST be immediately
followed by the GAL label with the S flag set to indicate that GAL is
the Bottom-of-the-stack label. Then ACH MUST follow the GAL label
and the value of the Channel Type identifies which of active OAM
protocols being encapsulated in the packet.
Authors' Addresses
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn
Sami Boutros
Ciena
Email: sboutros@ciena.com
David Black
Dell EMC
176 South Street
Hopkinton, MA 01748
United States of America
Email: david.black@dell.com
Santosh Pallagatti (editor)
VMware
Email: santosh.pallagatti@gmail.com
Mirsky, et al. Expires January 14, 2021 [Page 9]