Hi Lloyd: Seems to me we are converging. I'm confident that now you have a clear image on what ISA100.11a is doing though you might still be missing a bit of the rationale behind. At this point, there is no solid|new issue against ISA100.11a transport and I do thank you for this review.
>> <Carsten> >> Obviously, if an end system does not want protection from UDP (and it >> shouldn't want it in the ISA100 case), it should say so by setting >> the checksum to zero. > > No. It should either: > a. Use UDP-Lite, to avoid checksum coverage of its payload, and still > get a pseudoheader check from UDP. > b. Implement its own transport protocol, in parallel with UDP/TCP/ > SCTP, with its own pseudoheader check, doing payload coverage however > it likes. ISA100.11a transport is clearly b. It has both the pseudoheader check and the payload coverage. On top of that it has authentication and optional encryption though IPSec/IKE was not affordable. The rationale is tightly linked to the very constrained environment ISA100.11a operates in. >ISA100.11a should be sitting parallel to TCP/UDP/SCTP, not on top of UDP. The only difference is the pretence thing. To my best knowledge, ISA100.11a transport has all the right properties that IETF mandates. >Still, never mind; it is, of course, late to change the ISA100 design >(but, oddly, not too late to change RFCs 2460 and 4346?) . Feel free to >ignore me. ISA100.11a does not want to revinvent the wheel, this is why the group made all efforts to comply to IETF whenever possible, including IPv6, 6loWPAN, TSVWG recommendations, etc... The real question now is whether we can get that bit in 6loWPAN HC. >Wait a bit, you'll probably want that reserved bit for something more >useful in a while. (I am reminded of the furore over reusing the three >MPLS experimental bits - that kept Stewart Bryant flying round the >world for months.) That's the valid point. You need to look at Jonathan's draft; there's a plethora of bits in the NHC in the UDP case (4 left after we define one for UDP checksum conpression): http://tools.ietf.org/html/draft-hui-6lowpan-hc-00#page-9 " 3.2. LOWPAN_UDP Header Compression This document defines a compression format for UDP headers using LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 7. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |ID | S | D | C | rsv | +---+---+---+---+---+---+---+---+ Figure 7: Compressed IPv6 Multicast Address Encoding " Now, I think we might want to revisit this so that UDP is NOT the ID bit 0. Other transports might need more bits than UDP does. This is something that should be discussed as we progress draft-hui-6lowpan-hc-00 ... Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
