OAM for use in GENEVE
draft-mmbb-nvo3-geneve-oam-01

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 July 9, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of 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. OAM Protocols Encapsulation in Geneve Networks
• 2.1. OAM Encapsulation in Geneve
• 3. Associated Channel in Geneve Networks
• 4. Associate Channel Header in Geneve
• 4.1. Use of the Geneve ACh Header in Active OAM
• 5. Echo Request and Echo Reply in Geneve Tunnel
• 6. IANA Considerations
• 6.1. Geneve Associated Channel Protocol Types
• 7. Security Considerations
• 8. Acknowledgment
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• 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 one encapsulation method and providing

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

G-ACh Generic Associated Channel Header

Geneve Generic Network Virtualization Encapsulation

NVO3 Network Virtualization Overlays

OAM Operations, Administration, and Maintenance

ACh Associated 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. OAM Protocols Encapsulation 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.
• 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. 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 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 adds to processing of OAM message, further disassociates 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.

Another option is to use the Protocol Type field to demultiplex an 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 (G-ACh) 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.

Lastly, an associated channel 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 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.

3. Associated Channel in Geneve Networks

An associated channel 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 associated channel (ACh) in the Geneve network ensures that packets of active OAM protocols carried in the ACh are in-band with user traffic.

4. Associate Channel Header in Geneve

    
 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

ACh Header immediately follows the Geneve header defined in [I-D.ietf-nvo3-geneve] and identifies the type of message carried over the Geneve ACh. The format of the Geneve ACh Header is:

The ACh Header consists of the following fields:

• V - two bits long field indicates the current version of the ACh 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;

4.1. Use of the Geneve ACh 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              | ACh
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------
~                    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 Geneve network presented in Figure 2.

5. Echo Request and Echo Reply in Geneve Tunnel

[Ed.note] Will be expanded in the future versions.

6. IANA Considerations

IANA is requested to create a new registry called "Geneve Associated Channel".

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

7. Security Considerations

TBD

8. Acknowledgment

TBD

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses