[ovs-dev] [PATCH 0/1] RFC: Add support for pre-tunnel to the datapath
Jesse Gross
jesse at nicira.com
Wed Dec 12 02:08:45 UTC 2012
On Tue, Dec 11, 2012 at 12:45 PM, Kyle Mestery (kmestery)
<kmestery at cisco.com> wrote:
> On Dec 10, 2012, at 11:27 AM, Jesse Gross <jesse at nicira.com> wrote:
>> On Sat, Dec 8, 2012 at 5:35 AM, Kyle Mestery (kmestery)
>> <kmestery at cisco.com> wrote:
>>> On Dec 7, 2012, at 10:15 PM, Jesse Gross <jesse at nicira.com> wrote:
>>>> On Fri, Dec 7, 2012 at 1:47 PM, Kyle Mestery <kmestery at cisco.com> wrote:
>>>>> Some tunneling protocols require manipulation of the packet before the outer
>>>>> IP header is placed on the packet. An example of a tunneling protocol with
>>>>> this attribute is LISP. For these protocols, a way to manipulate the packet
>>>>> (for example, remove the MAC header) is provided.
>>>>
>>>> How does this work on the receiving side when you get a packet with
>>>> the MAC header removed? I understand that it makes sense in the
>>>> context of a router but currently OVS expects full Ethernet frames.
>>>
>>> Well, one thought I had was we could add the MAC header back in the vport
>>> driver's receive function. Since the flow is extracted from the packet here,
>>> the existing flow extraction and matching code would work ok front his point
>>> on. What do you think?
>
> Was on PTO yesterday, sorry for the delayed response.
>
>> If I'm not mistaken, we'll have completely thrown away the original
>> MAC header on transmit, right? So we'll either have to fill in zeros,
>> use a set of static addresses, or do some kind of resolution.
>>
> Ideally we would want to do ARP resolution at this point. Alternatively, we thought
> another way to deal this may be to to use a modify action to replace an all zero
> MAC address with the actual MAC address.
>
>> I've also wondered whether we can make OVS less Ethernet specific.
>> Particularly for the basic match-and-forward functionality there isn't
>> a lot that is protocol dependent. People have asked about Infiniband
>> before and potentially this could apply to raw IP as well. There's a
>> good chance that as a practical matter it complicates things more than
>> it is worth though.
>
> This is something interesting. Have you progressed past wondering by any
> chance?
I was afraid that you were going to say that you wanted to do ARP
resolution. That's definitely something that I'd like to keep out of
the tunneling code (at least on the data plane).
I haven't really thought that much more about being less Ethernet
specific but on the kernel side it would mostly just involve taking
into account the port type when determining where to start parsing and
adding some checks before doing anything Ethernet specific. Since the
kernel is just a hash table there isn't really a reason why you have
to include Ethernet headers in the lookup. The same is true for the
classifier parts of userspace, although obviously much of the fixed
function code assumes Ethernet (as does OpenFlow currently).
Once you relax that assumption, you could add push/pop MAC header
actions where the former would be driven by an ARP stack in userspace.
I think it's doable but is probably a fair amount of work.
More information about the dev
mailing list