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 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
• 1.1. Conventions used in this document
• 1.1.1. Terminology
• 1.1.2. Requirements Language
• 2. Active OAM Protocols in Geneve Networks
• 2.1. A Control Channel in the Geneve Network
• 2.2. OAM Encapsulation in Geneve
• 2.3. Associated Control Channel in Geneve Networks
• 2.3.1. Use of the Geneve ACC Header in Active OAM
• 3. Echo Request and Echo Reply in Geneve Tunnel
• 4. IANA Considerations
• 4.1. Geneve Associated Channel Protocol Types
• 5. Security Considerations
• 6. Acknowledgment
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Additional Considerations for OAM Encapsulation Method in Geneve
• Authors' Addresses

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

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

    
 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

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:

The ACC Header consists of the following fields:

• V - two bits long field indicates the current version of the ACC Header. The current value is 0b00;
• Msg Type - 14 bits long field identifies a protocol. In the case of active OAM, these could be Echo Request/Reply, BFD, Performance Measurement;
• 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

    
 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

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.

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:

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

7.2. Informative References

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