On Thu, May 25, 2017 at 11:33 AM, Joe Touch <[email protected]> wrote: > > > On 5/25/2017 11:27 AM, Tom Herbert wrote: >> On Thu, May 25, 2017 at 10:44 AM, Joe Touch <[email protected]> wrote: >>> Hi, Tom, >>> >>> On 5/25/2017 9:00 AM, Tom Herbert wrote: >>>> IPv4 and IPv6 can be directly encapsulated since they have a protocol >>>> number (can be encapsulated by version 0). >>>> >>>> As I mentioned previously, Ethernet could be directly encapsulated via >>>> EtherIP that has a 4 bit version number at the beginning of its >>>> header. The way this would work is to set a version 1 pattern to >>>> indicate EtherIP. For example, we could specify that 0101 would be >>>> EtherIP. When GUE receives such a packet it will notice it's version >>>> one and then see that it is EtherIP (differentiated from IPv4 0100 and >>>> IPv6 0110 values). The first four bits are then overwritten by 0011 to >>>> make it a valid EtherIP header and then the packet is resubmitted to >>>> the stack as EtherIP. >>> If you use the first 4 bits as the type identifier (which I think you >>> should, as noted below), then you could easily support a bunch of >>> encapsulations without needing the 4-byte overhead. >>> >>> E.g.: >>> 0000 = GUE control (your "Version 0") >>> 0100 = IPv4 >>> 0101 = IPv6 >>> >>> That leaves 13 other codes you can use for other protocols (including >>> MPLS, Ethernet, etc.), as long as you burn at least those 4 bits. >>> >> Right, although even with 00 for version zero there's still enough for >> ten other codes which is a lot. > > Yes, but there's very little benefit in looking at 2 bits vs 4. That > would matter only for serial processing and saves far too little to be > worthwhile IMO. It also complicates the way the protocol is described (I > personally find it confusing; it's a lot more obvious to just say that > you use IPv0 for control, IPv1 for encapsulation, and other IP versions > are included without overriding headers). > >> >>> EtherIP effectively burns 2 bytes rather than 4 bits, but has the same >>> net effect. >>> >>>> Transport protocols (TCP, UDP, SCTP) might also be nice to support >>>> with direct encapsulation in version 1, but unfortunately since they >>>> start with a variable port number there's no way to do that. >>> That works the same way as EtherIP - burn at least 4 bits indicating the >>> transport. >> EtherIP begins with a fixed version number, for the transport >> protocols we would be overwriting the source port with no way to >> recover the bits. > You can't put bare Ethernet inside GUE. You need to use EtherIP - > exactly because it has a 16-bit field, of which only the first 4 bits > are (already) defined. > > My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16 > bits allow it to be mapped to one of the IP versions (you picked IPv5). > The same trick works for UDP and TCP - just pick a different 16 bit > pattern for each one. > Inserting two bytes before the TCP header breaks four byte alignment of the header which is a bigger hit than the benefit of saving two bytes. A nice side effect of the two byte header in EtherIP is that it aligns the Ethernet payload (e.g. an IP header) to four bytes. Maintaining this four byte alignment is still important to some CPU architectures most notably Sparc, but can even be problematic to x86 under certain circumstances.
Tom > The catch is that EtherIP and these corresponding tricks for UDP and TCP > end up burning 16 bits more than the bare packet would, but that's still > less than the GUE encapsulation header burns. > > Joe >> >>> Joe >>> >>> ------ >>> From my previous post: >>> >>> When we look at the first 2 bits of a GUE packet, we see: >>> 00 = GUE version 0 >>> 01 = IPv4 or IPv6 >>> 10 = undefined >>> 11 = undefined >>> >>> That's nearly the same as looking at the first 4 bits as simply the IP >>> version number, and defining some of the unused IP versions as control: >>> 0000 (IPv0) = GUE control >>> 0001 (IPv1) = GUE control >>> 0010 (IPv2) = GUE encapsulation using the GUE header >>> 0011 (IPv3) = GUE encapsulation using the GUE header >>> 0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE >>> header >>> 0101 (IPv5) = direct encapsulation of IPv5 (ST), with no interveni >>> GUE header >>> 0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE >>> header >>> 0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no >>> intervening GUE header >>> 1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no >>> intervening GUE header >>> 1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no >>> intervening GUE header >>> 1010 (IPv10) = direct encapsulation of IPv10, when assigned >>> 1010 (IPv11) = direct encapsulation of IPv11, when assigned >>> 1010 (IPv12) = direct encapsulation of IPv12, when assigned >>> 1010 (IPv13) = direct encapsulation of IPv13, when assigned >>> 1010 (IPv14) = direct encapsulation of IPv14, when assigned >>> 1010 (IPv15) = direct encapsulation of IPv15, when assigned >>> >>> I.e., all you're basically doing is defining the first four version >>> numbers of IP as your control plane. Unless we come back and assign them >>> in the future, any mechanism that encapsulates IP packets (which should, >>> IMO, be able to handle ALL IP versions, by definition) should be able to >>> include GUE-style signaling. >>> >> Right, this scheme could work to generally encapsulate different IP >> versions. There is a caveat though: AFAIK there is no IP protocol >> number to encapsulate any IP protocols other then IPv4 (IPIP 94) and >> IPv6 (IPv6 encapsulates 41). GUE encapsulates IP protocols which means >> they need a protocol number. Version 1 is header compression for >> version 0 so the there must be a way to encapsulate the protocol using >> version 0. What would resolve that is a new IP protocol number for >> encapsulating a packet of any IP version and use the IP version itself >> to differentiate. >> >> Tom >> >>> IMO, it's simpler to explain this all using this fixed-field >>> demultiplexer - in which case, you could even use just the IPv0 pattern >>> for control and the IPv1 pattern for encapsulation using the GUE header, >>> leaving the IPv2 and IPv3 equivalent patterns for future expansion. >>> >>> Joe >>> >>> > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
