| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
fyi From: Dennis Edwards
[mailto:dedwards@cococorp.com] Any
fragmentation mechanism depends on a packet fragmentation threshold. If the packet
size is not greater than the fragmentation threshold then the packet is not
fragmented, otherwise it is. The fragmentation threshold can be set to the Path
Maximum Transport Unit (PMTU) by a dynamic discovery mechanism (e.g.: RFC 1191, RFC 1981, RFC 4821); can be arbitrarily
established as part of a protocol definition (e.g., IEEE 802.11-2007); or it
can be set through some management interface (e.g., IEEE 802.11-2007). The
options are not mutually exclusive. Some
protocols, such as IPv6, require all links to support a minimum MTU. Limiting
the maximum MIH message to 1492 bytes (1500 bytes – 8 bytes for the MIH
protocol header) will make it compatible with transparent bridging (c.f., RFC 3580
[section D.3.10, IEEE 802.1X-2004]). The MIH protocol could, similarly to
IPv6, require that all links provide for a minimum 1500 byte payload and admit
lack of support for links such as those described in RFC 3150. For
the remainder of this discussion I assume that the steps in the preceding
paragraph have been taken and both the minimum and maximum MIH payload are thus
each fixed at 1500 bytes: This would eliminate the need for any MTU negotiation
or configuration to determine the maximum response size limit of a participant
in an MIH transaction. If
the method in section 6.5.3 of D10.0 can be can be used to limit the query
response size of all MIH messages then the maximum size of any indivisible MIH
protocol element would be 1492 bytes. If such a limit is enforced by the
specification then fragmentation is not needed to support the MIH protocol. If
such a limit cannot be enforced then fragmentation and reassembly are required
and the fragmentation threshold is established at 1500 bytes. The
rest of my comment assumes that fragmentation is, indeed, required. In
version four of the TCP/IP protocol suite, TCP packets may be transparently
fragmented by IP. This is known to be variously problematic (c.f., Christopher
A. Kent, Jeffrey C. Mogul, Fragmentation
Considered Harmful). If such problems are acceptable in light of the
expected application of the MIH protocol then no changes are needed to the MIH
protocol state machines in order to support fragmentation and reassembly of MIH
protocol messages. The fragmentation mechanism can be selectively established
as part of any NET_SAP for which the underlying media does not already provide
a fragmentation service. MsgInAvail would only be signaled, via
MIH_TP_Data.indication, following successful reassembly of a fragmented
packet. When Transmit() signals an MIH_TP_Data.request then the MIH
payload would be transparently fragmented and encapsulated appropriately
according to the underlying media requirements. The
leftmost reserved bit in the MIH header could be used to signal the presence of
an MIH fragmentation option, similarly to IPv6. Only a NET_SAP would ever see
this header option. There are many ways the fragmentation option field could be
defined. One possibility is to make the option field 4 bytes wide and to define
the following sub-fields:
By
defining the MIH fragmentation service in this way, we are allowed significant
freedom in its specification. We could, for instance, utilize an existing
fragmentation mechanism that has already been well specified, established and
tested and so provides a minimal risk to the MIH standard approval and
subsequent implementations. One such option is the IPv4 fragmentation service.
We could rely on the procedure defined in section 2.3 of the IPv4 protocol
specification (RFC 791) for outgoing
message fragmentation while relying on RFC 815, IP Datagrams Reassembly Algorithms,
for fragmented message reassembly. An
Analysis of Fragmentation Attacks could serve as a reminder of some
implementation details to consider. Dennis Edwards Platforms Architect
(206) 812-5723 |