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

From: "Dorothy Stanley" <[email-masked]>
Date: Mon, 5 Feb 2007 09:29:21 -0800

Pat,

I don't see the need for requiring even/odd number assignment.
Shouldn't the required behavior be indicated in the operational
description of message processing, without requiring overloading
the message number. This seems overly constrained.

Dorothy Stanley

On 1/26/07, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
> 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
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 5 Feb 2007 15:03:40 -0800

I believe you may have been absent during this discussion. The reason
for the
even/odd pairing was to allow a device that receives something it does
not
understand to respond. If it were to drop the packet, and the packet was
a
request, it would cause the underlying reliable protocol to fail and the

connection would be dropped.
 
So the agreement was if you receive a request you do not understand,
bump the command by one, and include a Result Code stating you have
no idea what the peer is asking for. If you receive a response, then you
drop the packet.
 
One alternative that was proposed was to include a new bit in the header
that indicated whether the packet was a request or a response. In this
scheme, the request/response would share the same command code,
so receiving a request you do not understand requires you to set the bit
and return the packet with the Result Code indicating the error.
 
The group felt that the former was a better approach.

Pat Calhoun

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Monday, February 05, 2007 9:29 AM
	To: Pat Calhoun (pacalhou)
	Cc: [email-masked]
	Subject: Re: [Capwap] issue 239: Protocol Header and command
Extensibility

	Pat,

	Dorothy Stanley

		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
		[...]
		
		   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
	
_________________________________________________________________
		To unsubscribe or modify your subscription options,
please visit:
		http://lists.frascone.com/mailman/listinfo/capwap

---

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 7 Feb 2007 08:22:44 -0800

Pat,

It seems odd (no pun intended) that the underlying reliable
protocol depends on/requires a specific numbering of the messages.
If a reply/response is expected, then the sender should retransmit the
request message
if a response is not received within a given time - 4.6.11 ResponseTimeout
and
4.6.12Retransmit Interval seem to be sufficient for the error case
described.

A WTP or AC receives a message that it does not understand - let's say it
cannot determine the type of message that was received - the message type is
invalid.
The message should just be dropped.

Dorothy

On 2/5/07, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
>  I believe you may have been absent during this discussion. The reason for
> the
> even/odd pairing was to allow a device that receives something it does not
> understand to respond. If it were to drop the packet, and the packet was a
>  ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Monday, February 05, 2007 9:29 AM
> *To:* Pat Calhoun (pacalhou)
> *Cc:* [email-masked]
> *Subject:* Re: [Capwap] issue 239: Protocol Header and command
> Extensibility
>
> Pat,
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 7 Feb 2007 10:32:41 -0800

Right, agree, but if a message is dropped, the CAPWAP link can be
dropped - using the timers you listed.

Pat Calhoun

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Wednesday, February 07, 2007 8:23 AM
	To: Pat Calhoun (pacalhou)
	Cc: [email-masked]
	Subject: Re: [Capwap] issue 239: Protocol Header and command
Extensibility

	Pat,
	
	It seems odd (no pun intended) that the underlying reliable
	protocol depends on/requires a specific numbering of the
messages.
	If a reply/response is expected, then the sender should
retransmit the request message
	if a response is not received within a given time - 4.6.11
ResponseTimeout and
	4.6.12Retransmit Interval seem to be sufficient for the error
case described.
	
	A WTP or AC receives a message that it does not understand -
let's say it
	cannot determine the type of message that was received - the
message type is invalid.
	The message should just be dropped. 
	
	Dorothy

		I believe you may have been absent during this
discussion. The reason for the
		even/odd pairing was to allow a device that receives
something it does not
		understand to respond. If it were to drop the packet,
and the packet was a
		request, it would cause the underlying reliable protocol
to fail and the 
		connection would be dropped.
		 
		So the agreement was if you receive a request you do not
understand,
		bump the command by one, and include a Result Code
stating you have
		no idea what the peer is asking for. If you receive a
response, then you
		drop the packet.
		 
		One alternative that was proposed was to include a new
bit in the header
		that indicated whether the packet was a request or a
response. In this
		scheme, the request/response would share the same
command code,
		so receiving a request you do not understand requires
you to set the bit
		and return the packet with the Result Code indicating
the error.

			From: Dorothy Stanley
[mailto:[email-masked]] 
			Sent: Monday, February 05, 2007 9:29 AM
			To: Pat Calhoun (pacalhou)
			Cc: [email-masked]
			Subject: Re: [Capwap] issue 239: Protocol Header
and command Extensibility

			Pat,
			
			I don't see the need for requiring even/odd
number assignment.
			Shouldn't the required behavior be indicated in
the operational
			description of message processing, without
requiring overloading
			the message number. This seems overly
constrained.
			
			Dorothy Stanley

			On 1/26/07, Pat Calhoun (pacalhou)
<[email-masked]> wrote: 

				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
				[...]
				
				   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
	
_________________________________________________________________
				To unsubscribe or modify your
subscription options, please visit:

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

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 7 Feb 2007 13:24:41 -0800 (PST)

HI,

You can't "just drop a message", since it will result in
session termination.

Regards,
/david t. perkins

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 16 Feb 2007 16:09:29 -0800

Are there any other comments/issues on this particular issue? Dorothy,
have David and I addressed your concerns?

Pat Calhoun

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, February 07, 2007 1:25 PM
> To: Dorothy Stanley
> Cc: Pat Calhoun (pacalhou); [email-masked]
> protocol 
> > depends on/requires a specific numbering of the messages.
> retransmit the 
> > request message if a response is not received within a given time - 
> > 4.6.11 ResponseTimeout and 4.6.12Retransmit Interval seem to be 
> > sufficient for the error case described.
> >
> > A WTP or AC receives a message that it does not understand 
> - let's say 
> > it cannot determine the type of message that was received - the 
> > message type is invalid.
> >>  I believe you may have been absent during this discussion. The 
> >> reason for  the  even/odd pairing was to allow a device 
> that receives 
> >> something it does not  understand to respond. If it were 
> to drop the 
> >> packet, and the packet was a  request, it would cause the 
> underlying 
> >> reliable protocol to fail and the  connection would be dropped.
> >>
> response, then 
> >> you  drop the packet.
> >>  One alternative that was proposed was to include a new bit in the 
> >> header  that indicated whether the packet was a request or a 
> >> response. In this  scheme, the request/response would 
> share the same 
> >> command code,  so receiving a request you do not 
> understand requires 
> >> you to set the bit  and return the packet with the Result 
> Code indicating the error.
> >>
> >>  CTO, Wireless Networking Business Unit  Cisco Systems
> >> 
> >>

---

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 20 Feb 2007 10:16:38 -0800

Pat, David,

If an unrecognized message is dropped, then the sender will retransmit it.
If the sender is repeatedly transmitting an unrecognized - and dropped-
message, then I agree,
the link could be dropped. So there is value in the receiver sending an
indication of
the message type that was received back to the sender - since it is one that
the
receiver does not know - e.g. message number 155 - or some other undefined
value
in the current specification.

(a) The configuration messages today do not conform to the request/response
model, as a 3-message exchange is defined:
Configuration Status - WTP to AC
Configuration Status Response - AC to WTP
Configuration Status Acknowledge - WTP to AC

Need to fix this. Could
(i) Delete the Configuration Status message, leaving 2 messages, and
requiring the AC to initiate the exchange,
rename Cnfig Status Response to "Request".  Seems simplest, no race
conditions with both WTP and AC
sending config-related Request messages at the same time.
(ii) Add a separate response to Configuration Status, perhaps renaming
Configuration Status to Configuration Report, adding Configuration Report
Acknowledge
from AC to WTP, also
rename Config Status Response to Configuration Status Request.

(b) If we have a Request/Response message structure, then
we could double the message id space by using a mechanism
other than one bit of the message type to indicate request/response,
and go from 128 "types", e.g. Discovery, Join, etc to the full 255.
Suggest using one of the flags field bits for this. Then, instead of
even/odd,
we just toggle the flags bit.  Separately, in the layout of the control
message format,
suggest that the flags field follow the seq num, allowing the Msg Element
Length
field to be on a 16-bit boundary.

Thanks,

Dorothy

On 2/7/07, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
>  Right, agree, but if a message is dropped, the CAPWAP link can be dropped
> - using the timers you listed.
>
>
> Pat Calhoun
> *Sent:* Wednesday, February 07, 2007 8:23 AM
> cannot determine the type of message that was received - the message type
> is invalid.
> > *Sent: * Monday, February 05, 2007 9:29 AM

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 20 Feb 2007 13:50:44 -0800

> If the sender is repeatedly transmitting an unrecognized - and
dropped-  message, then I agree,
> the link could be dropped. So there is value in the receiver sending
an indication of
> the message type that was received back to the sender - since it is
one that the 
> receiver does not know - e.g. message number 155 - or some other
undefined value
> Configuration Status to Configuration Report, adding Configuration
Report Acknowledge
> rename Config Status Response to Configuration Status Request.

Actually, what you are referring to is no longer the case. The addition
of the Ack never should have happened, because the Change State Event
Request provides that purpose. The ACK was proposed by Michael, but was
subsequently removed when we agreed that there was already a framework
in place for this (and it was even part of the state machine). The -04
draft still had the actual text block for this message, but all
references to it had been removed. The -05 will no longer have that text
because it is no longer necessary.

even/odd,
> we just toggle the flags bit.  Separately, in the layout of the
control message format,
> suggest that the flags field follow the seq num, allowing the Msg
Element Length
> field to be on a 16-bit boundary.
We also talked about this option at the interim meeting, because this
was essentially David Perkin's proposal. However, during this discussion
the team agreed that adding one to the Message Type is in fact no
different than setting a bit (odd vs. even). Further, the team felt that
the proposed plan of request+1=response, created the least amount of
change to the spec.

Pat Calhoun