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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



...and UDP Lite just covering the L3 and L4 headers, but not the full payload a la UDP,
 is still possible when the full payload is not visible.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces@xxxxxxxx] On Behalf Of Joe Touch [touch@xxxxxxx]
Sent: 27 January 2014 16:48
To: stbryant@xxxxxxxxx
Cc: mpls@xxxxxxxx; IETF discussion list; curtis@xxxxxxxxxxxxxx
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Those same mechanisms have provided hardware checksum support for a very long time.

Joe

> On Jan 27, 2014, at 8:40 AM, Stewart Bryant <stbryant@xxxxxxxxx> 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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]