Subject: [Capwap] issue 239: Protocol Header and command Extensibility

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 26 Jan 2007 12:56:28 -0800

During the interim meeting, the group discussed what happens if a device

receives a command it does not recognize. While issue 219 provides a
mechanism 
to perform capabilities advertisement, there is still an issue of what
happens 
if one receives a request that is not recognized. The protocol, as
defined, 
would require that the request be dropped, which would cause
retransmissions, 
and eventually the link would be shutdown. The team felt that it was 
preferable to at least provide a mechanism to prevent the link drop
case. 

The team also felt that some guidance on the use of the version field in
the 
CAPWAP header was necessary. Given the limited address space available,
this 
field needs to be incremented only when the header format changes.

Here is the proposed text for the above requests:
<text>
4.2.  CAPWAP Header
[...]
   The version field in the CAPWAP header MUST NOT be modified in any
   future CAPWAP specifications unless the header format is modified.
   The version number is intended to be used in order to identify how to

4.4.1.1.  Message Type
[...]
   The assignment of CAPWAP control message numbers always occurs in
   pairs.  The first being a request and the second being a response.
   The CAPWAP protocol's reliability mechanism requires a response in
   order to acknowledge the request.  This means that all requests are
   odd numbered, while responses are even.  Further, the request comes
   first, meaning that assigning the number 4 for a response and 5 for
   the request is invalid.

   When a WTP or AC receives a message whose message type field is not
   recognized and odd, the number is incremented by one, and the Result
   Code message element is added with the value (Unrecognized Request).
   If the unknown message type is even, the message is simply ignored.

14.  IANA Considerations
[...]
14.1.  CAPWAP Message Types

   The Message Type field in the CAPWAP header Section 4.4.1.1 is used
   to identify the operation associated with the message.  There are
   multiple namespaces, which is identified via the first three octets
   of the field containing the IANA Enterprise Number [12].  When the
   Enterprise Number is set to zero, the message types are reserved for
use
   by the base CAPWAP specification which are controlled and maintained
   by IANA.

   The assignment of CAPWAP control message numbers always occurs in
   pairs.  The first being a request and the second being a response.
   The CAPWAP protocol's reliability mechanism requires a response in
   order to acknowledge the request.  This means that all requests are
   odd numbered, while responses are even.  Further, the request comes
   first, meaning that assigning the number 4 for a response and 5 for
   the request is invalid.
</text> 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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