Subject: [Capwap] CAPWAP Protocol Concerns Summary

From: "Richard Gwee" <[email-masked]>
Date: Wed, 22 Mar 2006 05:41:57 +0800

Dear All,

Below is a summary of the points that I have presented during the CAPWAP
session regarding the CAPWAP protocol concerns.

Issue 1: Change of State Machine.

There is a need to provide a clearer State Machine as some of the
transitions between states are not clearly indicated. For example, from
the DTLS-complete to the Configure State or Image Data State, there is
no clear explanation on the basis of how the transition should be
carried out. I have noticed from the Mailing list that there have been
proposals to change the State Machine. Similar issues have also been
listed on the issue trackers. We should take a close look into creating
a viable State Machine first.

Reference: 

Issue Tracker: Issue #85

Mailing List: Email by Sujay (" Addition to SM and Configure States")
dated 17 March 2006.

Issue 2: Load Balancing For WTP

Message element in WTP Manager (Section 5.2.4 and 5.2.5) only contains
IP addresses and WTP count. While I do not condone the use of WTP count,
I strongly believe that effective load balancing cannot be performed
just using these parameters. There is a need to include more parameters
such as Traffic loading, network congestion etc. Although Pat Calhoun
has mentioned that such parameters capture only a snapshot of the
network conditions, I believe that this problem can be resolved through
the use of periodic updating of capturing the network conditions.
Furthermore, what Pat has argued is mainly scenario specific under fast
mobility conditions. I will appreciate if Pat can clarify more on the
reason why my suggestion may not be practical enough. I welcome any
feedback.

I will appreciate if this can become an issue on the issue tracker.

Issue 3: General Statistics

There is a need to include general statistics for CAPWAP protocol. So
far, I have noticed only statistics that is technology-bind (in this
case 802.11) as stated in the draft.  There is a need to have statistics
that is applicable for the overall network such as congestion, traffic
loading, channel interferences etc. This type of information can be
piggy backed on regular messages exchange such as echo request. This
issue has been listed in the tracker.

Reference:

Issue Tracker: Issue #84, #45, 

Comparative Analysis Draft (Section 4.6.1)

Issue 4: Firmware Trigger

There is little clear indication on the State Machine of how firmware
trigger should be carried out in the running state. Firmware Management
has also been stated as optional in the draft specification. To ensure
consistent firmware version, we should made firmware management
mandatory and introduce proactive firmware trigger in the running state.
Pat has suggested the use of making firmware management mandatory for AC
and optional for WTP. I am ok with the suggestion.

Reference:

Issue Tracker: Issue #40

Comparative Analysis Draft (Section 4.1.5)

I appreciate any comments and feedback if I have missed out anything.

Thanks and regards

Richard Gwee.

Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near Woodlands MRT/Interchange)
. www.rp.sg . Fax: +65 6415-1310 . 

Republic Polytechnic, the first Institute of Higher Learning to fully adopt the Problem-Based Learning approach in Singapore, continues to strive towards best practices and maintain excellence in service standards with the following certifications: Singapore Innovation Class (SIC), Singapore Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, 14001 and OHSAS 18001)
--------------------------------------------------------------------------------
CONFIDENTIALITY CAUTION: This message is intended only for the use of the individual or entity to whom it is addressed and contains information that is privileged and confidential. If you, the reader of this message, are not the intended recipient, you should not disseminate, distribute or copy this communication. If you have received this communication in error, please notify us immediately by return email and delete the original message. Thank you.  

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

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

---

From: "R M" <[email-masked]>
Date: Wed, 22 Mar 2006 21:54:19 +0530

On AC, how can you tell if the packet is "CAPWAP Discovery Request" or
"DTLS Client Hello". If this is an issue and is not covered in any of the
ones listed below, please add this to the list.

If this is not an issue, I request someone to tell me how I can
differentiate the too. To me, I can see both the packets coming to AC in the
same state (due to retransmissions or the WTP getting reset or similar
scenarios).

Thanks.

On 3/22/06, Richard Gwee <[email-masked]> wrote:
> transitions between states are not clearly indicated. For example, from the
> DTLS-complete to the Configure State or Image Data State, there is no clear
> explanation on the basis of how the transition should be carried out. I have
> noticed from the Mailing list that there have been proposals to change the
> State Machine. Similar issues have also been listed on the issue trackers.
> We should take a close look into creating a viable State Machine first.
>
>
>
> Reference:
>
> Issue Tracker: Issue #85
>
> Message element in WTP Manager (Section 5.2.4 and 5.2.5) only contains IP
> addresses and WTP count. While I do not condone the use of WTP count, I
> strongly believe that effective load balancing cannot be performed just
> using these parameters. There is a need to include more parameters such as
> Traffic loading, network congestion etc. Although Pat Calhoun has mentioned
> that such parameters capture only a snapshot of the network conditions, I
> believe that this problem can be resolved through the use of periodic
> updating of capturing the network conditions. Furthermore, what Pat has
> argued is mainly scenario specific under fast mobility conditions. I will
> appreciate if Pat can clarify more on the reason why my suggestion may not
> be practical enough. I welcome any feedback.
>
>
>
> There is a need to include general statistics for CAPWAP protocol. So far,
> I have noticed only statistics that is technology-bind (in this case
> 802.11) as stated in the draft.  There is a need to have statistics that
> is applicable for the overall network such as congestion, traffic loading,
> channel interferences etc. This type of information can be piggy backed on
> regular messages exchange such as echo request. This issue has been listed
> in the tracker.
>
>
>
> Reference:
>
> trigger should be carried out in the running state. Firmware Management has
> also been stated as optional in the draft specification. To ensure
> consistent firmware version, we should made firmware management mandatory
> and introduce proactive firmware trigger in the running state. Pat has
> suggested the use of making firmware management mandatory for AC and
> optional for WTP. I am ok with the suggestion.
>
>
>
> Reference:
>
> Issue Tracker: Issue #40
>
> ------------------------------
>
> . *www.rp.sg* <http://www.rp.sg/> . Fax: +65 6415-1310 .
>
> *Republic Polytechnic, the first Institute of Higher Learning to fully
> adopt the Problem-Based Learning approach in Singapore, continues to strive
> towards best practices and maintain excellence in service standards with the
> following certifications: Singapore Innovation Class (SIC), Singapore
> Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, 14001
> and OHSAS 18001)*
> ------------------------------
>
>   CONFIDENTIALITY CAUTION: This message is intended only for the use of
> the individual or entity to whom it is addressed and contains information
> that is privileged and confidential. If you, the reader of this message, are
> not the intended recipient, you should not disseminate, distribute or copy
> this communication. If you have received this communication in error, please
> notify us immediately by return email and delete the original message. Thank
> you.
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Mar 2006 08:49:47 -0800

Hi Richard,
  Way back last summer I had posted an email on the typos in LWAPP, I do 
not know if your list contains those. Just in case I am attaching the 
email here (posted on August 3, 2005):
BR,
--behcet

All,
In Section 2.2 on LWAPP State Machine Definition, the transitions (or 
state transitions) have consistently been referred to as "state"s which 
is certainly wrong.
Here is an example:
Discovery to Discovery (b): This is the state the WTP uses to
     determine which AC it wishes to connect to.
b is certainly a transition not a state.

Section is repeated in referring to the section names as in:
section Section 5.2.3.

There is another one on page 89 (Section 11.1.1),
The WTP processes the probe request and responds with a
     corresponding probe response.  The problem request is then
     forwarded to the AC for optional processing.
Shouldn't the problem request be the probe request?
On page 92,
(see section Section 11.7.1.1. the paranthesis was not closed.
In Section 11.7.1.1 there is the following sentence:
An AC that wishes to update a
  mobile's policy on an WTP may be done by simply sending a new Add
  Mobile message element.

... (possibly some others).
 A note on the semantics, in Section 11.1 on Split MAC, two terms 
(verbs) that are used, forwards and tunnels with no clear definition in 
Section 3 on LWAPP transport. One possible interpretation is, for 
example, WTP sends an associate request frame as LWAPP Data Frame but AC 
replies with Add Mobile Request which is sent in a control frame.
 Is this correct interpretation? It seems not, because in some other 
parts, LWAPP data frame forwarding is referred to as tunneling.
 If a state machine for a few important aspects were defined, much of 
the ambiguity would be avoided.
 The other candidate protocols, time permitting, but for now, that's it.

Regards,

--behcet

Richard Gwee wrote:

> Dear All,
>
>  
>
> Below is a summary of the points that I have presented during the 
> CAPWAP session regarding the CAPWAP protocol concerns.
>
>  
>
> transitions between states are not clearly indicated. For example, 
> from the DTLS-complete to the Configure State or Image Data State, 
> there is no clear explanation on the basis of how the transition 
> should be carried out. I have noticed from the Mailing list that there 
> have been proposals to change the State Machine. Similar issues have 
> also been listed on the issue trackers. We should take a close look 
> into creating a viable State Machine first.
>
>  
>
> Reference:
>
> Issue Tracker: Issue #85
>
> IP addresses and WTP count. While I do not condone the use of WTP 
> count, I strongly believe that effective load balancing cannot be 
> performed just using these parameters. There is a need to include more 
> parameters such as Traffic loading, network congestion etc. Although 
> Pat Calhoun has mentioned that such parameters capture only a snapshot 
> of the network conditions, I believe that this problem can be resolved 
> through the use of periodic updating of capturing the network 
> conditions. Furthermore, what Pat has argued is mainly scenario 
> specific under fast mobility conditions. I will appreciate if Pat can 
> clarify more on the reason why my suggestion may not be practical 
> enough. I welcome any feedback.
>
>  
>
> case 802.11) as stated in the draft.  There is a need to have 
> statistics that is applicable for the overall network such as 
> congestion, traffic loading, channel interferences etc. This type of 
> information can be piggy backed on regular messages exchange such as 
> echo request. This issue has been listed in the tracker.
>
>  
>
> Reference:
>
> trigger should be carried out in the running state. Firmware 
> Management has also been stated as optional in the draft 
> specification. To ensure consistent firmware version, we should made 
> firmware management mandatory and introduce proactive firmware trigger 
> in the running state. Pat has suggested the use of making firmware 
> management mandatory for AC and optional for WTP. I am ok with the 
> suggestion.
>
>  
>
> Reference:
>
> Issue Tracker: Issue #40
>
> ------------------------------------------------------------------------
>
> . www.rp.sg <http://www.rp.sg> . Fax: +65 6415-1310 .
>
> Republic Polytechnic, the first Institute of Higher Learning to fully 
> adopt the Problem-Based Learning approach in Singapore, continues to 
> strive towards best practices and maintain excellence in service 
> standards with the following certifications: Singapore Innovation 
> Class (SIC), Singapore Quality Class (SQC), People Developer Standards 
> and QEHS (ISO 9001, 14001 and OHSAS 18001)
>
> ------------------------------------------------------------------------
> the individual or entity to whom it is addressed and contains 
> information that is privileged and confidential. If you, the reader of 
> this message, are not the intended recipient, you should not 
> disseminate, distribute or copy this communication. If you have 
> received this communication in error, please notify us immediately by 
> return email and delete the original message. Thank you.
>
>------------------------------------------------------------------------
>