NVO3 Working Group G. Mirsky
Internet-Draft X. Min
Intended status: Standards Track ZTE Corp.
Expires: January 6, 2020 S. Boutros
VmWare, Inc.
D. Black
Dell EMC
July 5, 2019

OAM for use in GENEVE


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 6, 2020.

Copyright Notice

Copyright (c) 2019 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

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:

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:

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:

Geneve OAM Protocol type
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

7. Security Considerations


8. Acknowledgment


9. References

9.1. Normative References

[I-D.ietf-nvo3-geneve] Gross, J., Ganga, I. and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", Internet-Draft draft-ietf-nvo3-geneve-13, March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[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.
[RFC5586] Bocci, M., Vigoureux, M. and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

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

Authors' Addresses

Greg Mirsky ZTE Corp. EMail: gregimirsky@gmail.com
Xiao Min ZTE Corp. EMail: xiao.min2@zte.com.cn
Sami Boutros VmWare, Inc. EMail: sboutros@vmware.com
David Black Dell EMC 176 South Street Hopkinton, MA, 01748 United States of America EMail: david.black@dell.com