fyi
From: Dennis
Edwards [mailto:dedwards@cococorp.com]
Sent: Tuesday, May 20, 2008 10:14
AM
To: Gupta, Vivek
G
Subject: MIH fragmentation
recommendation
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.
h
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:
- Most significant two bytes could be the
fragment offset into the original message
- The next most significant byte could be
a fragment number
- The least significant byte could be a
flags field, one bit of which is set to indicate more fragments
remain.
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
CoCo
Communications
999 3rd
Avenue
Suite
3700
Seattle, Washington 98104
(206) 812-5723