Subject: [Capwap] suggest to take more effort in CAPWAP base protocol

From: young <[email-masked]>
Date: Tue, 29 Aug 2006 16:04:07 +0530

Hi, Dorothy Stanley and Pat Calhoun：

I think it is great to separate the specification of the CAPWAP base
protocol and the 802.11-specific binding. I inclined to think the way will
push the mailing list to take more effort to keep loose couple between the
base protocol and any wireless implement binding.
I think that CAPWAP base protocol should be a framework for any wireless
implement. I suggest CAPWAP protocol draft take more effort on the base
protocol section. It is core of the protocol.
Based on my understanding, and some suggestion from other guy in the mail
list, I have following suggestion for base protocol.
Before I try to make it clear, I must declare: In order to give a whole
suggestion, I have to put other guy’s question (suggestion) here, but I
will mention who gave the suggestion in the mailing list.
In summary, I thought the draft could take more effort for:
1) The Packet format
2) The abstract glossary
3) Add more common TLV in the section 4.4
4) The configuration process framework
5) The clear suggestion of error
I try to make them clear one by one. Here only try to draw a big picture,
more effort need to be done. 

For The Packet format:
David T. Perkins provides a suggestion for packet format. Based on my
understanding, the common packet header logical (for example, fragment) is
independent of the logical of wireless tunnel. I thought David suggestion
will make packet format clearer. Why not mailing list take time to discuss
David T. Perkins 's proposal for CAPWAP Packet Format.

For the abstract glossary
The idea is to define some abstract glossary to make them to support any
wireless implement. I think it is important, and clear and abstract glossary
will
Help future wireless implement keep consistent of conception.
For example:
Issue 161: The term "Mobile" is not really accurate.
I think we should define an abstract glossary for it. For example, as per
RFC 3344, mobile IP use "mobile node". As IP is every where, so how about we
use 
"Mobile node"?
Issue # 204,  "More general wireless support" to track this.
I raised this issue. There I mentioned: For "11.9.1. IEEE 802.11 Add WLAN",
we could rename "WLAN" as wireless service? By this way, we could achieve
abstract while make it work for most wireless technology.

Add more common TLV in the section 4.4
I just mentioned "wireless service", some TLV like add, update, delete
"wireless service" could be added in the section 4.4. For mobile (I don't
know what is its future name), it is similar.
Issue # 204, "More general wireless support" to track this.
I raised this issue. There I mentioned: For "11.9.22.  IEEE 802.11 WTP
Quality of Service", we could also define " WTP Quality of Service" in the
section 4.4.
Definitely, the "wireless service" and  " WTP Quality of Service" should
only keep some common TLV in the section 4.4. Any wireless implant will add
new TLV for them.
#206, "Common MIB Statistics"
I raised this issue. I suggest we could refer to RFC1213 (and other MIBs) to
put some common MIB Statistics in the section 4.4.
Any way, I think the base protocol part should add more common and abstract
TLV.

The configuration process framework
I think that very complex part of base protocol is configuration process.
I suggest that the base protocol could provide a clear and abstract
framework for configuration process (draw main process), while any
wirelesses implement binding just put its domain TLV.
I suggest we could define some abstract conception for configuration, for
example, we could call that radio related configuration is "radio policy",
wlan as "wireless service", configuration for WTP as "WTP template", Qos
configuration as "Qos policy".
Then the main process for configuration of wireless network will be:  WTP
template->radio policy-> wireless service->Qos policy. Beside these, some
specific parameter, for example, for radio type, should also be organized in
some way. (Maybe we could name all these conception as "xxx policy".
By this way, a base protocol provides a clear and abstract framework for
configuration process.
For define any wireless implement binding, they could easily under the main
configuration process, and they just put their new TLV is ok.

The clear suggestion of error
I think that clear suggestion of error is very important. AC as an
intelligent controller will make control and manage became easy, but AC need
a way to clearly know what configuration error happened.
Draft 03 provides "4.4.28.  Result Code", I think it is too less, more
reason about configuration error should be provided. 

Regard

Richard

----------------------------------------------------------------------

Message: 1
Date: Mon, 28 Aug 2006 09:36:51 -0700
From: "Dorothy Stanley" <[email-masked]>
Subject: [Capwap] Proposed Resolution for Issue #201: Clean Separation
	Between Base and Binding/was Re: CAPWAP and RFID
To: "Mani, Mahalingam (Mani)" <[email-masked]>
Cc: [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

All,

The proposed resolution for Issue #201, listed below is to separate the
specification of the CAPWAP base protocol and the 802.11-specific binding
into two documents:
 (a) draft-ietf-capwap-protocol-specification and
(b) draft-ietf-capwap-wlan-binding-specification (or similar name).

This will
- enable easy reference to each component separately
- ensure a clean separation between the protocol and the initial
802.11/subsequent
bindings
- provide focus on what is essential for the CAPWAP protocol vs the bindings

If agreed, this coulld be accomplished In the next editing cycle by
producing
 draft-ietf-capwap-protocol-specification-03 and
draft-ietf-capwap-wlan-binding-specification-00

At a first cut, the binding specification document would include -02 text:
- Duplicated Section 1, with modifications to indicate that this is the
binding document, and reference the CAPWAP protocol spec
- Section 11, with updates per issue resolution
- Additional sections, per list agreement

Comments please.

Thanks,

Dorothy Stanley

Issue 201:

(2) Clean separation between CAPWAP "base" protocol and 802.11-
specific control messages.  Ideally, we'd like to see the CAPWAP base
protocol and the 802.11-specific controls in separate documents, but
it would also be possible for us to reference a portion of a
monolithic document, as long as the base protocol is cleanly-enough
separated from the 802.11-specific portions to allow us to
unambiguously and normatively reference the base protocol.

On 7/14/06, Dorothy Stanley <[email-masked]> wrote:
>
> All,
>
> Issues
>
> #200 - Trickle Firmware Download
> #201 - Clean Separation between base and binding
>
> are now created in the issue database to track these items.
>
>
> Dorothy Stanley
>
>
> On 7/13/06, Mani, Mahalingam (Mani) <[email-masked]> wrote:
> >
> > <!chair>
> > The WG should consider The #1 as a bug-level issue given that there will
> > be usage models and applications that require scheduling of firmware
> > updates (provisioning/lifecycle management action) separated from reboot
> >
> > (operational management action) to switch to the new firmware.
> >
> > Requiring reboot to be synchronous with a firmware update is
> > restrictive.
> >
> > Above may have implications of having room in stable-store for at least
> > two images (a best practice followed by all well-designed embedded
> > systems anyway) - hopefully a non-issue nowadays even on thin WTPs.
> > </!chair>
> >
> > The second request is on first providing logical separation more than
> > physically separate documents, as I read it. The WG & editors have done
> > a good job on that beginning with the base protocol.
> >
> > The persuasion to consider the physically split the document becomes
> > more appealing when an additional media binding becomes a reality. The
> > latter needs to be preceded by a re-charter at the minimum, as I
> > understand it, given the current charter. (One of the charter goals has
> > been extensibility, however).
> >
> > Any inputs towards improving logical separation is welcome; and the WG
> > and editors can make a choice on adopting them based on issue-priorities
> > in queue. That could serve us well now and for a physical separation at
> > a later time (whenever it may be).
> >
> > Thanks,
> > -mani
> > -----Original Message-----
> > From: Margaret Wasserman [mailto:[email-masked]]
> > Sent: Wednesday, July 12, 2006 11:44 AM
> > To: [email-masked]
> > Subject: [Capwap] CAPWAP and RFID
> >
> >
> > Hi All,
> >
> > For background on why I'm raising the next few issues, please see the
> > slides (in the proceedings for IETF 66) that I did not get a chance
> > to present in the WG meeting.  The primary point of those slides was
> > that the Reader Operations WG of the EPCglobal standards body (an
> > RFID industry standards body) is considering reusing the base
> > protocol portions of CAPWAP as a discovery and control protocol for
> > RFID systems.  Bob O'Hara and I are both active in that group, and
> > we've been asked to communicate some requirements from that group to
> > the CAPWAP WG.
> >
> > NOTE:  We are not talking about adding RFID-specific control messages
> > to CAPWAP.  In fact, the group is not currently planning to use
> > CAPWAP as the control channel.  So, these are not RFID-specific
> > requirements.
> >
> > In our scenario, an RFID controller (or "client") would act in the
> > role of a WTP, and RFID readers would act in the AP role.
> >
> > The two requirements we've been asked to communicate are:
> >
> > (1) Trickle firmware download with separate reboot.  In other words,
> > we need to be able to download the firmware while our CAPWAP
> > connection remains in the running state, and later be able to trigger
> > a reboot, which will result in a switch to the new firmware.  It
> > seems very likely that some 802.11 systems will require this feature,
> > as well.  In fact, it is my understanding that some systems already
> > do it this way.  But, the current state diagram and CAPWAP text don't
> > seem to support this -- you leave the running state to move to the
> > firmware download state and can only exit the firmware download state
> > through the reboot state.
> >
> > (2) Clean separation between CAPWAP "base" protocol and 802.11-
> > specific control messages.  Ideally, we'd like to see the CAPWAP base
> > protocol and the 802.11-specific controls in separate documents, but
> > it would also be possible for us to reference a portion of a
> > monolithic document, as long as the base protocol is cleanly-enough
> > separated from the 802.11-specific portions to allow us to
> > unambiguously and normatively reference the base protocol.
> >
> > Would the CAPWAP WG support making these changes so that the
> > EPCglobal RO WG can reuse this technology?
> >
> > Thanks,
> > Margaret
> >
> > Margaret Wasserman
> > Vice President
> > ThingMagic
> > [email-masked]
> > _________________________________________________________________
> > 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.frascone.com/pipermail/capwap/attachments/20060828/1b39c07a/att
achment.htm 

------------------------------

Message: 2
Date: Mon, 28 Aug 2006 10:13:35 -0700
From: "James Kempf" <[email-masked]>
Subject: Re: [Capwap] Proposed Resolution for Issue #201: Clean
	SeparationBetween Base and Binding/was Re: CAPWAP and RFID
To: "Dorothy Stanley" <[email-masked]>,	"Mani, Mahalingam
	(Mani)" <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original

I support this change. Though it is not so important, I would suggest 
calling the 802.11 binding something like 
draft-ietf-capwap-protocol-802dot11-binding.txt.

            jak

----- Original Message ----- 
From: "Dorothy Stanley" <[email-masked]>
To: "Mani, Mahalingam (Mani)" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 28, 2006 9:36 AM
Subject: [Capwap] Proposed Resolution for Issue #201: Clean 
SeparationBetween Base and Binding/was Re: CAPWAP and RFID

> All,
>
> The proposed resolution for Issue #201, listed below is to separate the
> specification of the CAPWAP base protocol and the 802.11-specific binding
> into two documents:
> (a) draft-ietf-capwap-protocol-specification and
> (b) draft-ietf-capwap-wlan-binding-specification (or similar name).
>
> This will
> - enable easy reference to each component separately
> - ensure a clean separation between the protocol and the initial
> 802.11/subsequent
> bindings
> - provide focus on what is essential for the CAPWAP protocol vs the 
> bindings
>
> If agreed, this coulld be accomplished In the next editing cycle by
> producing
> draft-ietf-capwap-protocol-specification-03 and
> draft-ietf-capwap-wlan-binding-specification-00
>
> At a first cut, the binding specification document would include -02 text:
> - Duplicated Section 1, with modifications to indicate that this is the
> binding document, and reference the CAPWAP protocol spec
> - Section 11, with updates per issue resolution
> - Additional sections, per list agreement
>
> Comments please.
>
> Thanks,
>
> Dorothy Stanley
>
> Issue 201:
>
> (2) Clean separation between CAPWAP "base" protocol and 802.11-
> specific control messages.  Ideally, we'd like to see the CAPWAP base
> protocol and the 802.11-specific controls in separate documents, but
> it would also be possible for us to reference a portion of a
> monolithic document, as long as the base protocol is cleanly-enough
> separated from the 802.11-specific portions to allow us to
> unambiguously and normatively reference the base protocol.
>
>
>
>
> On 7/14/06, Dorothy Stanley <[email-masked]> wrote:
>>
>> All,
>>
>> Issues
>>
>> #200 - Trickle Firmware Download
>> #201 - Clean Separation between base and binding
>>
>> are now created in the issue database to track these items.
>>
>>
>> Dorothy Stanley
>>
>>
>> On 7/13/06, Mani, Mahalingam (Mani) <[email-masked]> wrote:
>> >
>> > <!chair>
>> > The WG should consider The #1 as a bug-level issue given that there 
>> > will
>> > be usage models and applications that require scheduling of firmware
>> > updates (provisioning/lifecycle management action) separated from 
>> > reboot
>> >
>> > (operational management action) to switch to the new firmware.
>> >
>> > Requiring reboot to be synchronous with a firmware update is
>> > restrictive.
>> >
>> > Above may have implications of having room in stable-store for at least
>> > two images (a best practice followed by all well-designed embedded
>> > systems anyway) - hopefully a non-issue nowadays even on thin WTPs.
>> > </!chair>
>> >
>> > The second request is on first providing logical separation more than
>> > physically separate documents, as I read it. The WG & editors have done
>> > a good job on that beginning with the base protocol.
>> >
>> > The persuasion to consider the physically split the document becomes
>> > more appealing when an additional media binding becomes a reality. The
>> > latter needs to be preceded by a re-charter at the minimum, as I
>> > understand it, given the current charter. (One of the charter goals has
>> > been extensibility, however).
>> >
>> > Any inputs towards improving logical separation is welcome; and the WG
>> > and editors can make a choice on adopting them based on 
>> > issue-priorities
>> > in queue. That could serve us well now and for a physical separation at
>> > a later time (whenever it may be).
>> >
>> > Thanks,
>> > -mani
>> > -----Original Message-----
>> > From: Margaret Wasserman [mailto:[email-masked]]
>> > Sent: Wednesday, July 12, 2006 11:44 AM
>> > To: [email-masked]
>> > Subject: [Capwap] CAPWAP and RFID
>> >
>> >
>> > Hi All,
>> >
>> > For background on why I'm raising the next few issues, please see the
>> > slides (in the proceedings for IETF 66) that I did not get a chance
>> > to present in the WG meeting.  The primary point of those slides was
>> > that the Reader Operations WG of the EPCglobal standards body (an
>> > RFID industry standards body) is considering reusing the base
>> > protocol portions of CAPWAP as a discovery and control protocol for
>> > RFID systems.  Bob O'Hara and I are both active in that group, and
>> > we've been asked to communicate some requirements from that group to
>> > the CAPWAP WG.
>> >
>> > NOTE:  We are not talking about adding RFID-specific control messages
>> > to CAPWAP.  In fact, the group is not currently planning to use
>> > CAPWAP as the control channel.  So, these are not RFID-specific
>> > requirements.
>> >
>> > In our scenario, an RFID controller (or "client") would act in the
>> > role of a WTP, and RFID readers would act in the AP role.
>> >
>> > The two requirements we've been asked to communicate are:
>> >
>> > (1) Trickle firmware download with separate reboot.  In other words,
>> > we need to be able to download the firmware while our CAPWAP
>> > connection remains in the running state, and later be able to trigger
>> > a reboot, which will result in a switch to the new firmware.  It
>> > seems very likely that some 802.11 systems will require this feature,
>> > as well.  In fact, it is my understanding that some systems already
>> > do it this way.  But, the current state diagram and CAPWAP text don't
>> > seem to support this -- you leave the running state to move to the
>> > firmware download state and can only exit the firmware download state
>> > through the reboot state.
>> >
>> > (2) Clean separation between CAPWAP "base" protocol and 802.11-
>> > specific control messages.  Ideally, we'd like to see the CAPWAP base
>> > protocol and the 802.11-specific controls in separate documents, but
>> > it would also be possible for us to reference a portion of a
>> > monolithic document, as long as the base protocol is cleanly-enough
>> > separated from the 802.11-specific portions to allow us to
>> > unambiguously and normatively reference the base protocol.
>> >
>> > Would the CAPWAP WG support making these changes so that the
>> > EPCglobal RO WG can reuse this technology?
>> >
>> > Thanks,
>> > Margaret
>> >
>> > Margaret Wasserman
>> > Vice President
>> > ThingMagic
>> > [email-masked]
>> > _________________________________________________________________
>> > 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
>> >
>>
>>
>

----------------------------------------------------------------------------
----

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

------------------------------

Message: 3
Date: Mon, 28 Aug 2006 10:30:42 -0700
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: Re: [Capwap] Reserved bits and fields
To: "Bob O'Hara (boohara)" <[email-masked]>, <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Bob, based on the thread, do you still feel there are changes required
to the document?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Bob O'Hara (boohara) 
> Sent: Monday, August 14, 2006 9:03 AM
> To: [email-masked]
> Subject: [Capwap] Reserved bits and fields
> 
> I believe that we are overspecifying the use of the reserved 
> bits and fields in the draft.  For example, we place a 
> requirement on the transmitter that these bits and fields 
> MUST be zero ("All implementations complying with version 
> zero of this protocol MUST set these bits to zero.").  
> However, we do not specify any behavior by the receiver.  I 
> believe this is backwards.
> 
> Because the version field is available to all receivers of a 
> CAPWAP packet and that version field will unambiguously 
> identify all the reserved bits and fields, I believe we 
> should change the requirement to be that the receiver MUST 
> ignore any value received in a reserved bit or field.  This 
> way, should a noncompliant transmitter send something in 
> these fields, the receiver will not be confused by it.
> 
>  -Bob
> 
> Bob O'Hara
> Cisco Systems - WNBU
> 
> Phone:  +1 408 853 5513
> Mobile: +1 408 218 4025
>  
> _________________________________________________________________
> 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

End of Capwap Digest, Vol 10, Issue 24
**************************************

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

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