Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Joe Touch <[e-mail]>]

On 1/27/2014 9:16 AM, Stewart Bryant wrote:
>
> Sorry, are you talking the same h/w that does IP c/s?

It's been trivial to implement this for TCP checksums for a long time. 
18 years ago I showed how to do it for what was then $40 at 1Gbps (RFC 
1936).

They're done in hardware in many network interface cards on end systems, 
and it's been necessary for routers that use TCP tunnels as well.

Splitting headers from packet body for high-throughput routing has been 
known and done for a long time too (e.g., S. Walton, A. Hutton, and J. 
Touch, “High-Speed Data Paths in Host-Based Routers,” IEEE Computer, 
Nov. 1998, pp. 46-52.); during body transfer, the contents can easily be 
summed, and that sum can be combined with the header sum easily too.

Joe

> That h/w can only see the IP header.
>
> S
>
>
> On 27/01/2014 16:48, Joe Touch wrote:
>> Those same mechanisms have provided hardware checksum support for a
>> very long time.
>>
>> Joe
>>
>>> On Jan 27, 2014, at 8:40 AM, Stewart Bryant <[e-mail]> wrote:
>>>
>>>> On 24/01/2014 19:15, Joe Touch wrote:
>>>>
>>>>> This eliminates the "expands the reach of MPLS argument".
>>>>>
>>>>> First UDP checksums:
>>>>>
>>>>>    The UDP checksum is at the beginning of the payload.  Please see
>>>>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html
>>>>>    This makes filling in a new UDP checksum infeasible on most high
>>>>> end
>>>>>    hardware.
>>>> That argument would make sense if most hardware wasn't
>>>> store-and-forward on a per-packet basis.
>>> They may be store and forward, but most of the high end designs
>>> use multiple grades of memory putting the packet in "slow memory"
>>> and providing a snapshot of the header in "fast memory" to the
>>> forwarder. Thus although the whole packet is in the system, it
>>> it is not accessible to the engine that would need to calculate the
>>> c/s.
>>>
>>> Stewart
>> .
>>
>
>