Capwap Mailing List: Re: Issue 151: MTU discovery doesn't look right

[Pat Calhoun (pacalhou) (pcalhoun]

Given the lack of comments, or objections, to the proposed text since
July 28th, I will consider this issue closed. Fixed in
draft-ietf-capwap-protocol-specification-12.txt 

PatC
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Monday, July 28, 2008 12:43 PM
To: capwap [at] frascone.com
Cc: Pasi.Eronen [at] nokia.com
Subject: [Capwap] Issue 151: MTU discovery doesn't look right

Pasi's comment was:

   3.5 seems to assume that after the WTP has discovered the AC it
wishes to 
   communicate with, RFC 1191/1981/4821 would provide it with the MTU,
and then 
   the WTP would establish the CAPWAP session.  But those RFCs don't
specify e.g. 
   what packets would be used for probing for the MTU.

I have taken a look at the RFCs, and he is correct. It looks like we had
removed from functionality from the CAPWAP protocol prematurely some
time ago. So I re-instated the MTU Discovery Padding message element
(glad we had only commented out the text :).

Here is the new text:

<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.  One
   recommendation for performing PMTU discovery is to have the WTP
   transmit Discovery Request (see Section 5.1) messages, and include
   the MTU Discovery Padding message element (see Section 4.6.33).  The
   actual procedures used for PMTU discovery are described in [RFC1191],
   for IPv4, or for IPv6 [RFC1981] SHOULD be used.  Alternatively,
   implementers MAY use the procedures defined in [RFC4821].  The WTP
   SHOULD also periodically re-evaluate the PMTU using the guidelines
   provided in these two RFCs, using the Primary Discovery Request (see
   Section 5.3) along with the MTU Discovery Padding message element
   (see Section 4.6.33).  When the MTU is initially known, or updated in
   the case where an existing session already exists, the discovered
   PMTU 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.

4.6.  CAPWAP Protocol Message Elements
[...]
   MTU Discovery Padding                                52

4.6.33.  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:   52 for MTU Discovery Padding

   Length:   variable

   Pad:   A variable length pad, filled with the value 0xFF.

5.1.  Discovery Request Message
[...]
   The following message elements MAY be included in the Discovery
   Request message:

   o  MTU Discovery Padding, see Section 4.6.33

5.3.  Primary Discovery Request Message

   The Primary Discovery Request message is sent by the WTP to determine
   whether its preferred (or primary) AC is available or to performa a
   Path MTU Discovery (see section Section 3.5.
[...]
   The following message elements MAY be included in the Primary
   Discovery Request message:

   o  MTU Discovery Padding, see Section 4.6.33 </text>

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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