Darren.Reed at Sun.COM writes: > > The Solaris and HPUX implementations of DLPI, however, have > > historically never included the data-link header as being part of the > > DLSDU. > > > I wonder if it is "The Mentat implementation of DLPI never included the > data-link header as being part of the DLSDU" - IP on Solaris and HPUX > has the same origin. > > But everything else aside, that looks like as good as it'll get.
I think it's actually better than that. First of all, the term "service data unit" (SDU) is defined like this: http://www.its.bldrdoc.gov/fs-1037/dir-032/_4793.htm service data unit (SDU): In layered systems, a set of data that is sent by a user of the services of a given layer, and is transmitted to a peer service user semantically unchanged. In other words, it's the blob-o-bytes that IP sends to the DLPI provider. By reporting a maximum SDU size to the DLPI client, that provider is saying that IP can't send messages larger than this limit and still get the unchanged message to any peer IP implementation. The provider intentionally says nothing about its own overhead on messages. This is quite different from a PDU, which is a message that has the given layer's overhead plus the data from above. In other words, a given layer takes SDUs from above, pastes addresses on the front to construct a PDU, and sends the result off to the next layer below. (Where that's treated as an SDU by the next layer.) Secondly, having the datalink layer report the raw underlying SDU (its own maximum PDU size, including overhead) would lead to architectural trouble. This would mean that IP would somehow need to know how much overhead each dl_mac_type actually has, so that it can figure its own MTU. It's already bad enough that IP has to know about per-MAC-type SAPs; having per-MAC-type overhead would be a crime scene. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
