On Tue, Sep 20, 2016 at 10:35 AM, Joe Touch <[email protected]> wrote: > > > On 9/20/2016 10:29 AM, Tom Herbert wrote: >> On Tue, Sep 20, 2016 at 10:07 AM, Joe Touch <[email protected]> wrote: >>> Hi, Tom, >>> >>> >>> On 9/20/2016 9:13 AM, Tom Herbert wrote: >>>> ... >>>> For new encapsulation protocols please consider the effects of IP >>>> header alignment in the presence of Ethernet encapsulation. Defining >>>> Ethernet encapsulation with the two byte padding like in ETHERIP may >>>> help a lot to make implementation of Ethernet encapsulation feasible >>>> on CPU HW. >>> IMO, alignment needs to be handled within each encapsulation layer >>> independently. I don't think it's useful to expect new encapsulation >>> layers to have to make sure every layer of an encapsulated packet is >>> aligned - just the first one ought to be sufficient. The rest is the >>> responsibility of whomever added the other layers already in place. >>> >>> So yes, it's useful to make sure the encapsulated packet starts on a >>> boundary that is 4-byte aligned, but the rest *needs to be* someone >>> else's problem. >>> >> It's the Ethernet payload that we need to be four byte aligned not the >> Ethernet header. Just aligning Ethernet header to four bytes is not >> useful; that means the Ethernet payload, e.g. an IP packet, won't have >> four byte alignment and hence the misery of trying to process the >> packet. For the cost of two bytes ETHERIP gets things right in this >> regard! > If you've been handed Ethernet to encapsulate, then that is the header > whose alignment you should be optimizing. > > As you point out, you can't align both IP and Ethernet to 4-byte > boundaries at the same time.
You can if you insert a two byte pad before the encapsulated Ethernet header like ETHERIP (RFC3378 does). Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
