Subject: Re: [Capwap] Proposed resolution to issue 173 - message element exceedframe length.

From: "Michael Montemurro" <[email-masked]>
Date: Mon, 8 Jan 2007 17:06:01 -0500

I have not heard any responses to this issue. Therefore I will mark it closed.

On 10/9/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
> I agree with Mike's assessment.
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
> ________________________________
> From: Michael Montemurro [mailto:[email-masked]]
> Sent: Saturday, September 23, 2006 12:09 PM
> To: capwap
> Subject: [Capwap] Proposed resolution to issue 173 - message element
> exceedframe length.
>
>
> I do not see why the CAPWAP transport fragmentation mechanism can't be used
> to address this issue. I propose that we close it with no updates to the
> draft, unless someone is willing to describe what changes need to be made.
>
> Cheers,
>
> Mike
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 8 Jan 2007 15:08:33 -0800 (PST)

HI,

Issue 173 say "a single control frame". If this is changed to a "control 
message", then this needs to be addressed (if not already so) in the 
CAPWAP spec. I'm not sure if can occur, but if so, it needs to be 
addressed.

Regards,
/david t. perkins

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 14 Jan 2007 07:57:46 -0800

The CAPWAP header already allows for fragmentation/reassembly. I guess I
don't understand what problem you are referring to. Could you provide
some clarity on the issue.

Pat Calhoun

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Monday, January 08, 2007 3:09 PM
> To: Michael Montemurro
> Cc: Pat Calhoun (pacalhou); capwap
> Subject: Re: [Capwap] Proposed resolution to issue 173 - 
> message element exceedframe length.
> 
> HI,
> 
> Issue 173 say "a single control frame". If this is changed to 
> a "control message", then this needs to be addressed (if not 
> already so) in the CAPWAP spec. I'm not sure if can occur, 
> but if so, it needs to be addressed.
> 
> Regards,
> /david t. perkins
> 
> >> CTO, Wireless Networking Business Unit Cisco Systems
> >>
> >>

---

From: "David T. Perkins" <[email-masked]>
Date: Sun, 14 Jan 2007 17:24:45 -0800 (PST)

HI,

What if the response to a request is greater than the maximum message
size. For example, even with fragmentation supported, if the max
message size supported by a WTP is X, and the response is greater
than X, what is the WTP to do? Also, what if the response is size
X, and the sender knows that the receiver can not support messages
of size X?

Regards,
/david t. perkins

---

From: "Michael Montemurro" <[email-masked]>
Date: Mon, 15 Jan 2007 04:12:13 -0500

I don't see the problem. The CAPWAP fragmentation will allow the
message to be transmitted from the AC to WTP, or WTP to AC.

If the WTP cannot support re-assembled messages bigger than a
particular value, then I would classify that as an implementation
problem. Not a protocol problem.

Thanks,

Mike