As I stated in my other e-mail, LWAPP based devices have
been available
for nearly three years, and we have many million such
devices deployed
today. These are deployed in campuses, branch offices, home
offices.
They connect through private and public networks, using
Frame Relay,
PPPoE, Ethernet, WiMAX, etc. To date, the only time we ran
into problems
was with a PPPoE deployment, which forced us to reduce our
MTU size. I
agree that a dynamic MTU discovery method makes sense, but
disagree that
a default of 512 is necessary.
The original comment did mention that CAPWAP includes some
padding
capabilities, which is correct and I include here for
informative
purposes:
<text>
4.6.30. MTU Discovery Padding
The MTU Discovery Padding message element is used as
padding to
perform MTU discovery, and MUST contain octets of value
0xFF, of any
length.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Padding...
+-+-+-+-+-+-+-+-
Type: 30 for MTU Discovery Padding
Length: variable
Pad: A variable length pad.
</text>
What is missing in the current specification is guidance on
how it
should be used. To that end, I propose adding some new text,
which
follow the first sentence of the paragraph below:
<text>
5.1. Discovery Request Message
[...]
Upon receiving a Discovery Request message, the AC will
respond with
a Discovery Response message sent to the address in the
source
address of the received Discovery Request message. Once
a Discovery
Response has been received, if the WTP decides to
establish a session
with the responding AC, it MAY use the Discovery
Request/Response
messages for the purposes of MTU Discovery. In this
instance, the
Discovery messages are used for probing purposes, as
defined in [12],
and use the MTU Discovery Padding message element (see
Section
4.6.30) for
padding purposes.
</text>
PatC
-----Original Message-----
From: Margaret Wasserman [mailto:margaret thingmagic.com]
Sent: Wednesday, July 18, 2007 7:36 AM
To: capwap
Subject: [Capwap] Issue #3: MTU Discovery Requirement
Lars Eggert and Magnus Westerlund raised an issue with the
WG regarding
the lack of a Path MTU Discovery mechanism in CAPWAP. We
can either
introduce this type of mechanism (to avoid fragmentation) or
we can
limit our message size to the minimum MTU (512 bytes for
IPv4, 1280
bytes for IPv6).
> Specifically, I remember a discussion that >
concluded that CAPWAP
would need to have a mechanism to decide what MTU > to
use and would
need to default to a minimum MTU size (512
bytes?) when
> no other information was available, in order to avoid
fragmentation.
Is > that still a concern regarding the CAPWAP protocol?
If so, do you
(or > Dave or Lars) have any advice about how we might
address it?
Yes, you likely need to have a MTU discovery mechanism to be
avoid
needing to use very conservative packet sizes. But there
should be
possible to implement something like the MTU discovery
method described
in RFC 4821 in the CAPWAP protocol.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
htt
p://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lis
ts.frascone.com/pipermail/capwap
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
htt
p://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lis
ts.frascone.com/pipermail/capwap
|
