Yes that would. But this also means that there is a delay in
the AP
joining the controller as it first needs to find the MTU.
Maybe we could
assume a default low MTU and go ahead with join and then
increase the
MTU after the discovery is complete.
Thanks
smitha
-----Original Message-----
From: Pat Calhoun (pacalhou)
Sent: Monday, July 30, 2007 9:01 AM
To: Smitha Smitha (ssmitha); 'Margaret Wasserman'; 'capwap'
Subject: RE: [Capwap] Issue #3: MTU Discovery Requirement
I suppose a sentence stating that the response needs to be
padded to
ensure it is the same size as the request. Would that work?
PatC
-----Original Message-----
From: Smitha Smitha (ssmitha)
Sent: Monday, July 23, 2007 5:36 PM
To: Pat Calhoun (pacalhou); Margaret Wasserman; capwap
Subject: RE: [Capwap] Issue #3: MTU Discovery Requirement
Pat,
So, when the WTP receives a discovery response and decides
that it needs
to initiate a DTLS session with the AC on a certain 'Control
IPv4
interface', it would send a discovery request destined to
that interface
- and this could be for MTU discovery?
Also, the AC would need to know the MTU to the WTP, so do we
simply
assume that it is the same as that between the WTP and AC?
If not, we
need to define how to use the MTU discovery padding in the
reverse
direction too.
If we do not have a low default MTU - we would need to wait
till the MTU
has been found out for the WTP to join the AC - this could
lead to
delays in join.
Thanks
smitha
-----Original Message-----
From: Pat Calhoun (pacalhou)
Sent: Tuesday, July 24, 2007 3:00 AM
To: Margaret Wasserman; capwap
Subject: Re: [Capwap] Issue #3: MTU Discovery Requirement
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
____________________________________________________________
_____
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
|
