Hi Margaret,
On Tue 8/4/09 8:53 PM, "Margaret Wasserman" <m...@lilacglade.org> wrote: > > Hi Byzek, > > On Jul 30, 2009, at 8:31 PM, byzek wrote: >> >> It's not about performance; a large percentage of the currently- >> deployed >> hardware can¹t do UDP checksum calculations during encapsulation >> because it >> doesn¹t have access to the entire packet. Most hardware is >> streamlined to >> only provide the first n bytes of a packet to the forwarding engine, >> where >> typically n < 128. > > This is one of the primary reasons, as I understood it, why UDP-Lite > was defined the way it was -- to allow for a transport-layer checksum, > including an IP pseudo-header checksum, in IPv6, without the need to > traverse the entire packet. In the LISP case, all of the bytes that > would need to be "checksummed" for UDP-Lite would be bytes that were > _added to the packet_ by the LISP encapsulating router. > > When an IPv4/UDP header is pre-pended by a LISP router, the lisp ETR > needs to calculate the IP header checksum over 20 bytes (the IP header). > > If an IPv6/UDP-Lite header were pre-pended by a LISP router, the ETR > would need to calculate an IP header checksum over 48 bytes (the IP > pseudo-header and the UDP header). I think you mean xTR, correct? ITR does it on ingress, ETR does it on egress. As long as we don't have to go deeper in the packet than that, most hardware that would be performing encap/decap is at least capable of doing this, yes. -J > > While I understand that 48 bytes is larger than 20 bytes, we aren't > really talking about a major difference when the checksum algorithm is > well-optimized and all of the pre-pended header bytes are already in > memory. > > Margaret > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
