| NVO3 | D. Worley |
| Internet-Draft | Ariadne |
| Intended status: Informational | April 6, 2018 |
| Expires: October 8, 2018 |
Geneve Extensions
draft-worley-nvo3-geneve-misc-00
TBD
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 October 8, 2018.
Copyright (c) 2018 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.
+---------------+
| Ethernet |
+---------------+
| IP |
+---------------+
| UDP |
+---------------+
| Geneve |
+---------------+
| Ethernet |
+---------------+
| Layer 3 |
| ... |
+---------------+
+---------------+
| Ethernet |
+---------------+
| Geneve |
+---------------+
| Ethernet |
+---------------+
| Layer 3 |
| ... |
+---------------+
+---------------+
| Ethernet |
+---------------+
| IP |
+---------------+
| Geneve |
+---------------+
| UDP |
+---------------+
| application |
| data ... |
+---------------+
This document concerns expanding the Geneve encapsulation header to the function of a generalized encapsulation. The current Geneve proposal[I-D.ietf-nvo3-geneve] is highly extensible regarding the information that can be carried in the Geneve header, but it envisions that the encapsulated payload will be either Ethernet or a layer 3 protocol and will be carried over UDP within an IPv4 or IPv6 packet:
The most important requirement for the concept of Geneve as a generalized encapsulation technique is assigning suitable protocol numbers so that Geneve can be demultiplexed at various layers of the protocol stack.[number-assignments-msg]
When Geneve is used over layer 4, UDP, then there needs to be an assigned UDP destination port to specify that the UDP payload is demultiplexed as Geneve. IANA has assigned 6081 as the port number.[I-D.ietf-nvo3-geneve]
When Geneve is used over layer 3, IP, it needs a protocol/next header value. Protocol values are only 8 bits, but only a bit over half of the protocol values have been allocated in 30 years, so it seems that there's not a lot of pressure on the number-space, and it is reasonable to request a protocol number assignment for Geneve. Currently, the next unused IP Protocol value is 143.[protocol-numbers]
When Geneve is used over layer 2, Ethernet, it needs an Ethertype assignment. An Ethertype assignment could be obtained from IEEE,[ieee-ethertype-reg] but it might be more expedient to obtain a SNAP Protocol Number from IANA.[RFC7042] Currently, the next unused SNAP Protocol Number is 0x0009, yielding the five-octet SNAP extension header 00-00-5E-00-09.[snap-protocol-numbers] The SNAP extension header appears in the Ethernet frame after the primary Ethernet header when the Ethertype in the Ethernet header is the OUI Extended EtherType, 0x88B7.
[IEEE_802-2014] clause 9.2.4 notes
Geneve satisfies this desideratum through (1) using the first two bits of the Geneve header as a version identifier, and (2) carrying most of its data in an extensible set of options.
The Geneve header contains a protocol type field which identifies the protocol of the payload of the Geneve header, i.e., the overlying protocol. The protocol type field is defined to be an Ethertype. To allow the Geneve payload to be other than layer 3 protocols (with a few layer 2 protocols specifiable through "encapsulated" Ethertypes), encodings are needed for a larger space of protocol identifers.
When layer 2 is used over Geneve, the protocol type is 0x6558 (encapsulated Ethernet).
When layer 3 is used over Geneve, the protocol type is 0800 (IPv4) or 86DD (IPv6).
When layer 4 is used over Geneve, Geneve must be extended, because there's no defined way of representing an IP protocol/next header value directly as an Ethertype, and few or no protocols that can be represented as such a value have assigned Ethertypes.
One approach for carrying layer 4 protocols depends on the fact that all Ethertypes must have values of 0x0600 or higher ([IEEE_802-2014] clause 9.2.1). That is because Ethertypes are carried in a two-octet field in the Ethernet header, and values of that field smaller than 0x0600 are defined to specify the length of the Ethernet frame, not its Ethertype. This implies that values of the Geneve protocol type field with a first octet of 0x00 to 0x05 are not actually allocated at present and can be redefined for other uses.
This suggests extending the protocol type field so that if the first octet is 0x00, then the second octet is an IP protocol number describing the payload protocol.
An additional case is when there is no payload, i.e., the Geneve header contains all of the information content of the packet. In this situation, we can take use the next-header value 59, which means "no next header".[RFC8200] Given the encoding for IP protocol numbers, "no next header" is encoded by a Geneve protocol type of 0x003B.
TBD
But things get messier if Geneve directly encapsulates a protocol which has a SNAP protocol number, because Geneve only reserves two octets for the protocol type field. Likely the best solution[extended-msg] is allocate (1) the first octet of the protocol type field is an indicator value, 0x02, (2) the second octet of the protocol type field is the first octet of the OUI of the SNAP protocol number, and (3) as the first four octets of the Geneve payload, place the final two octets of the OUI and the two octets of the protocol identifier:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | 0x01 | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-
| Payload ...
+-+-+-+-+-+-+-+-+-
This solution allows the format of the Geneve header to remain unchanged, and the payload of the inner protocol remains aligned on a four-octet boundary. It does introduce an irregular word between the Geneve header and the payload proper, but this is upward-compatible with the current Geneve specification: a processor that does not understand the SNAP payload convention sees an Ethertype starting with 0x02 (which it does not recognize) and a payload that is four octets longer than the actual payload (which it knows it does not know how to process).
(The value 0x02 is chosen as the indicator because numerous Ethertypes with high byte 0x01 are listed in the IEEE's registration database for "Xerox (Experimental)", despite that they are not acceptable as Ethertypes.)
"Alternate packet marking" encompasses a number of methods of inserting one or more "marking" bits in packets when they are transmitted, and when they are received, measuring the arrival times of packets with specific markings to determine flow statistics, including delay and jitter.[I-D.fmm-nvo3-pm-alt-mark][I-D.mizrahi-ippm-compact-alternate-marking]
Alternate marking is mentioned here because even if compact marking is used, one of the reserved flag bits needs to be allocated for marking.
For some applications, there may be no need for a Virtual Network Identifier. It may be reasonable to allocate one of the header flag bits to mean "short", in that the second word of the header is suppressed. Thus, when S = 1, the format of the Geneve header is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C|S| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Options |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
My memory is that the question of "TCAM support" was raised a couple of IETFs ago. I take that to mean the question of whether a Geneve header can be classified as to whether it conforms to a particular "profile" or not by using a ternary-content-addressed memory, that is, by examining a fixed set of bits at fixed locations to see if they have certain fixed values. If the profile in question is the presence of a particular set of options with particular lengths, the classification is possible using TCAM.
A problem arises if we want to support profiles that allow further options beyond the specified set. It is straightforward to verify that the required option class/type values appear in the expected locations relative to the Geneve header. The problem is that there's no way to verify that the apparent options are actually within the Geneve header -- to do that would require that the Option Length field is greater than or equal to a specified constant, and that test can't be done via TCAM.
One solution is embed in the Geneve header fixed part, and each option, a flag telling whether there is a further option in the Geneve header.[tcam-msg] Then a Geneve header can be verified to have at least N options (when N > 1) when the another-option flag is true in the header fixed part and in the first N-1 options.
(Effectively, the another-option flags represent the number of options in the Geneve header in uniary, and using TCAM it is possible to compare a number to be greater than a constant if the number is represented in unary.)
The Geneve format reserves eight bits in the first word for flag bits. Accumulating all of these proposals, there are five allocation flag bits:
One application of these extensions is described in the draft [I-D.xiang-nvo3-geneve-packet-spray] in section 5.3, in which it is desirable to put the layer 4 header (TCP or UDP) directly after the Geneve header (which carries the "Flow Group ID" and "Sequencing Number" in an option). In these cases, the Geneve protocol type field will be 0x0006 (for TCP) or 0x0011 (for UDP).
Within this framework, an attractive application is implementing the proposed OOAM header as a Geneve header. The current header proposal[I-D.ooamdt-rtgwg-ooam-header] exhibits some of the properties that Geneve was designed to avoid, in particular, specification of various functions by means of a limited number of flag bits in a fixed order. These limitations can be avoided by reformatting the fields of the OOAM header as a Geneve header.
The OOAM header has three parts: a fixed part, the data blocks specified by the Flags field, and an OOAM control message.
The (potentially) sixteen flags that indicate the data blocks can be replaced by sixteen Geneve options, each of which carries as its data the data block of the corresponding flag. This has the disadvantage that if a number of flags would be specified in the current format, the Geneve header would contain the same number of words to introduce the data blocks. This can be compressed by allocating a group of 2^16 Geneve option class/type values, each of which encodes a subset of the flags, and which has as option data the sequence of data blocks for those flags:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class |F|F F F F F F F F|C|F F F F F F F|R|R|R| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data blocks for the set flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This approach does consume 2^16 of the available 2^23 option class/type values, but that is less than 1% of the available number space.
Using the S (short header) bit, the Geneve header is no longer than the current OOAM header format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Msg Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Next Prot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OOAM data blocks ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| Opt Len |O|C|B| Rsvd. | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class |F|F F F F F F F F|C|F F F F F F F|R|R|R| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Data blocks for the set flags ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The major limitation of using a Geneve header is that it is limited to a 63 words (252 octets) of options.
The OOAM control message could be carried within a Geneve option, although that would limit it to 31 words (124 octets). The option specifies the control message type:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Msg Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Next Prot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OOAM control message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| Opt Len |O|C|B| Rsvd. | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class | Type |R|R|R| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OOAM control message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alternative approach that allows longer OOAM control messages is to place it after the Geneve header itself and before the Geneve header's payload. The option for the OOAM control message would contain only one word of data, carrying the message type and length:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Msg Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Next Prot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OOAM control message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| Opt Len |O|C|B| Rsvd. | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class | Type |R|R|R| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Further Geneve options ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OOAM control message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Geneve payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In all of these forms, advantage can be taken of Geneve's more easily generalized "next protocol" fieldSection 3 and the abililty to allocate additional Geneve option class/type values for later extensibility.
However, what does not change with this approach is the fundamental work of defining the semantics of the OOAM facilities and control messages.
[Note to RFC Editor: Please remove this entire section upon publication as an RFC.]
TBD
| [extended-msg] | Worley, D., "OUI Extended Ethertypes as next-protocol", IETF NVO3 mailing list msg06235, August 2017. |
| [I-D.ooamdt-rtgwg-ooam-header] | Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L. and D. Dolson, "OAM Header for use in Overlay Networks", Internet-Draft draft-ooamdt-rtgwg-ooam-header-04, March 2018. |
| [I-D.xiang-nvo3-geneve-packet-spray] | Xiang, H., Yu, Y., Congdon, P. and J. Wang, "Packet Spraying in Geneve Overlay Network", Internet-Draft draft-xiang-nvo3-geneve-packet-spray-00, March 2018. |
| [ieee-ethertype-reg] | IEEE Standards Association, "IEEE-SA - Registration Authority Ethertype", January 2018. |
| [IEEE_802-2014] | IEEE Computer Society, "802 - IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", June 2014. |
| [number-assignments-msg] | Worley, D., "Number assignments", IETF NVO3 mailing list msg06219, July 2017. |
| [tcam-msg] | Worley, D., "TCAM compatibility for Geneve", IETF NVO3 mailing list msg06142, Jun 2017. |
Donald Eastlake suggested the use of a SNAP protocol number.