Capwap Mailing List: Re: Issue 3: MTU Discovery Requirement

[Pat Calhoun (pacalhou) (pcalhoun]

The agreement during today's CAPWAP meeting there was agreement that the
resolution to issue 3 was acceptable, with the addition to a reference
to RFC 4821 as being an optional mechanism for MTU discovery. This issue
will be considered closed, and I am changing the Tracker entry
accordingly.

<text>
3.5.  MTU Discovery

   Once a WTP has discovered the AC it wishes to establish a CAPWAP
   session with, it SHOULD perform a Path MTU (PMTU) discovery.  The MTU
   discovered is used to configure the DTLS component (see
   Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit
   the MTU, defined in Section 3.4.  The procedures described in [14],
   for IPv4, or [15], for IPv6 SHOULD be used.  Alternatively,
   implementers MAY use the procedures defined in [12].  The WTP SHOULD
   also periodically re-evaluate the MTU using the guidelines provided
   in these two RFCs.

17.1.  Normative References
[...] 
   [12]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
         Discovery", RFC 4821, March 2007.
</text>

PatC 
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Friday, November 16, 2007 2:09 PM
To: Pat Calhoun (pacalhou); Margaret Wasserman
Cc: capwap [at] frascone.com
Subject: RE: [Capwap] Issue 3: MTU Discovery Requirement

Here is the text to support this issue:

<text>
2.  Protocol Overview
[...]

   When the WTP and AC have completed the version and provision exchange
   and the WTP is enabled, the CAPWAP protocol is used to encapsulate
   the wireless data frames sent between the WTP and AC.  The CAPWAP
   protocol will fragment the L2 frames if the size of the encapsulated
   wireless user data (Data) or protocol control (Management) frames
   causes the resulting CAPWAP protocol packet to exceed the MTU
   supported between the WTP and AC.  Fragmented CAPWAP packets are
   reassembled to reconstitute the original encapsulated payload.  MTU
   Discovery and Fragmentation is described in section 3. 

2.3.2.1.  CAPWAP to DTLS Commands
[...]
   o  DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU
      size used by the DTLS component.  See Section 3.5 for more
      information on MTU Discovery.  The default size is 1468 bytes.

2.4.3.  DTLS Error Handling
[...]
   There is currently only one encapsulation error defined: MTU
   exceeded.  As part of DTLS session establishment, the CAPWAP
   component informs the DTLS component of the MTU size.  This may be
   dynamically modified at any time when the CAPWAP component sends the
   DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1).
   The value provided to the DTLS stack is the result of the MTU
   Discovery process, which is described in Section 3.5.  The DTLS
   component returns this notification to the CAPWAP component whenever
   a transmission request will result in a packet which exceeds the MTU.

3.5.  MTU Discovery

   Once a WTP has discovered the AC it wishes to establish a CAPWAP
   session with, it SHOULD perform a Path MTU (PMTU) discovery.  The MTU
   discovered is used to configure the DTLS component (see Section
   2.3.2.1), while non-DTLS frames need to be fragmented to fit
   the MTU, defined in Section 3.4.  The procedures described in
   [14], for IPv4, or [15], for IPv6 SHOULD be used.  The WTP SHOULD
   also periodically re-evaluate the MTU using the guidelines provided
   in these two RFCs.

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 SHOULD perform an MTU discovery, using the
   process described in Section 3.5.

14.  Transport Considerations
[...]
   It is necessary for the WTP and AC to configure their MTU based on
   the capabilities of the path.  See Section 3.5 for more
   information.
</text>

PatC
-----Original Message-----
From: Pat Calhoun (pacalhou)
Sent: Sunday, October 21, 2007 4:24 PM
To: Margaret Wasserman
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] Issue 3: MTU Discovery Requirement

My apologies. I sould have said RFC 1191 and 1981, which specify
ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. 

PatC

-----Original Message-----
From: Margaret Wasserman [mailto:margaret [at] thingmagic.com]
Sent: Wednesday, October 17, 2007 6:50 AM
To: Pat Calhoun (pacalhou)
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] Issue 3: MTU Discovery Requirement


What would it mean to state that MTU discovery must be performed using
ICMP?  Is there a particular mechanism we'd reference?

Margaret

On Oct 12, 2007, at 2:40 PM, Pat Calhoun (pacalhou) wrote:

> This issue argues that CAPWAP needs to adopt an MTU discovery 
> mechanism, similar to that described in RFC 4821. Is it not acceptable

> to include text that simply states that MTU discovery must be 
> performed using ICMP?
>
> PatC
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap