[Tsvwg] draft-ietf-tsvwg-udp-lite and link CRC requirements

[Dr G Fairhurst <[e-mail]>]

I read draft-ietf-tsvwg-udp-lite last night, just to check I understood
exactly what were the implications of using UDPLite.

On page 5, in the section marked lower layer considerations, the current
draft says:

"Link layers that do not support partial checksums SHOULD detect errors
in the entire frame".

"In general, lower layers SHOULD detect errors at least in the 
sensitive part of the frame using strong error detection mechanisms,
but do need not do so for the insensitive part."

- Two points struck me:

(i) Shouldn't this be more precise in exactly what should be covered.
I think it shoudl be: IP header (including any options/extension headers)
plus UDP Checksum Coverage - is that correct?

(ii) This seems a VERY weak recommendation to use link CRC's to
protect the protocol headers. I think this is a philosophically
bad point to take. We know the UDP checksum is weak against certain
patterns of errors and we do expect errors (otherwise why add UDPLite
support to the link?), so why not at least say it MUST provide adequate
protection (e.g., comparable to CRC-16 - or whatever).

The link document from PILC made stronger recommendations:
http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-12.txt 

So.... was there a conscious decision to relax the link 
CRC requirement for UDPLite? 

If so, can it be explicitly expressed somewhere?


Gorry Fairhurst

----


Section 8.3 of draft-ietf-pilc-link-design said (pasted here for convienence):

   "The TCP [RFC793], UDP [RFC768], ICMP, and IPv4 [RFC791] protocols all
   use the same simple 16-bit 1's complement checksum algorithm to
   detect corrupted packets.  The IPv4 checksum protects only the IPv4
   header, while the TCP, ICMP, and UDP checksums provide end-to-end
   error detection for both the transport pseudo header (including
   network and transport layer information) and the transport payload
   data. Protection of the data is optional for applications using UDP
   [RFC768].

   The Internet checksum is not very strong from a coding theory
   standpoint, but it is easy to compute in software, and various
   proposals to replace the Internet checksums with stronger checksums
   have failed.  However, it is known that undetected errors can and do
   occur in packets received by end hosts [SP2000].

   To reduce processing costs, IPv6 has no IP header checksum.  The
   destination host detects "important" errors in the IP header such as
   the delivery of the packet to the wrong destination. This is done by
   including the IP source and destination addresses (pseudo header) in
   the computation of the checksum in the TCP or UDP header, a practice
   already performed in IPv4.  Errors in other IPv6 header fields may go
   undetected within the network; this was considered a reasonable price
   to pay for a considerable reduction in the processing required by
   each router, and it was assumed that subnetworks would use a strong
   link CRC.

   One way to provide additional protection for an IPv4 or IPv6 header
   is by the authentication and packet integrity services of the IP
   Security (IPSEC) protocol [RFC2401]. However, this may not be a
   choice available to the subnetwork designer.

   Most subnetworks implement error detection just above the physical
   layer. Packets corrupted in transmission are detected and discarded
   before delivery to the IP layer.  A 16-bit cyclic redundancy check
   (CRC) is usually the minimum. This is significantly more robust
   against most patterns of errors than the 16-bit Internet checksum.
   The Point-to-Point Protocol [RFC1662] requires support of a 16-bit
   CRC for each link frame, with a 32-bit CRC as an option.  (PPP is
   often used in conjunction with a dialup modem, which provides its own
   error control). Other subnetworks, including 802.3/Ethernet,
   AAL5/ATM, FDDI, Token Ring and PPP over SONET/SDH all use a 32-bit
   CRC.  Many subnetworks can also use other mechanisms to enhance the
   error detection capability of the link CRC (e.g., FEC in dialup
   modems, mobile radio and satellite channels).

   Any new subnetwork designed to carry IP should therefore provide
   error detection for each IP packet that is at least as strong as the
   32-bit CRC specified in [ISO3309].  While this will achieve a very
   low undetected packet error rate due to transmission errors, it will
   not (and need not) achieve a very low packet loss rate as the
   Internet protocols are better suited to dealing with lost packets
   than with corrupted packets [SRC81]."
_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg