Subject: Re: [Capwap] Ver 4 or CAPWAP packet syntax

From: "Cheng Hong" <[email-masked]>
Date: Thu, 3 Aug 2006 11:53:15 +0800

Hi David,

<snip>
> > 1.)
> > In Wireless Specific Information: Wireless ID field is already 
> > captured in the WBID field in the Data header.
> > 
> > Do we repeat it on purpose?
> I believe that this is needed because it tells you the BSSID 
> of the radio when you are doing 802.3 encapsulation.
 
According to the defintion:

>Wireless ID: The wireless binding identifier.  The following
>values are defined:
>1 - : IEEE 802.11

Could you elaborate a bit more on how this provides the information
about BSSID?

cheers

Cheng

> > 2.)
> > About the "F" bit in control header;
> > If a message-type is not understood, the node should not reply back 
> > else reply with a msg type indicating 'msg not understood'
> > how does this bit help in there?
> > 
> > If the only purpose it serves is when new message types are send a 
> > reply is ensured.
> > better still to upgrade the wtp image to one that understands.
> Each operation has one ID. It is used for both the request 
> and response (or report and acknowledgement). In CAPWAP-XX 
> spec, different values are used for the ID or the request and 
> response (most are N and N+1). If a "request operation" 
> (with, say ID=103) is received, and it is not known, then the 
> response would have ID=103, and a message element indicating 
> that the operation is unknown. With CAPWAP-XX, there is 
> nothing that the receiver can do when it receives an unknown 
> message ID.
> 
> > 3.)
> > About the Retry#, I am not clear as to why we need this count to be 
> > carried in the packet body, Can we not use the msg id for dual 
> > purpose, first to pair request-response, second for sequencing and 
> > order control?
> See the example timing diagrams. It is primarily used to 
> update the value of the time it takes to perform an 
> operation, and thus dynamically update the timeout value.
> 
> > 
> > 
> > Regds,
> > Sujay G
> 
> Regards,
> /david t. perkins
> 
> _________________________________________________________________
> 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

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 3 Aug 2006 09:43:25 -0700 (PDT)

HI,

Sorry, I misread the original question and described the
field "Radio MAC address".

Please note that I just "cut and pasted" (and did a little
bit of clarification) of text from the CAPWAP-01 (and
CAPWAP-02) documents.

As to the justification, there was email that motivated
the change from the packet formats described in the CAPWAP-00
document.

I sorry, that I don't have the time this morning to dig
up the emails justifying the change. I do share your
concerns that the header CAPWAP data PDUs looks a little
complex. 

In looking at the CAPWAP data header, the first question
is why does this need to be present in every packet? If
the format is determined at by the configuration, isn't
it enough the know the WTP and RadioID, or do you also
need to know the BSSID? The second question is can
encoding of the CAPWAP data header be made simplier?
There are dependencies between the values of the
"WBID" and "T" fields (and "W" field). Also, what
is valid depends on the direction of the CAPWAP
data PDU (certainly the data going to a WTP should
not specify "wireless specific info" (which is  RSSI,
SNR, and Data rate)). It does appear to me that the
"T" field could be removed, and that a value of,
say 0, for the WBID mean 802.3 frame format.

So, I apologize for not having the time this morning to
dig out the emails, and hope that Pat or someone else
can provide an explaination. Maybe you could describe
what you believe the fields mean, and/or describe
what you would like to see in CAPWAP data header.

Regards,
/david t. perkins