Subject: [Capwap] Issue 219: Insufficient description of WTPs during discovery

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 24 Jan 2007 08:06:21 -0800

> Sorry for the long email, but I think this issue requires some
background 
> discussion, as well as the proposal to address the issue I am raising.

> In the Discovery Request there is a WTP Descriptor to provide the AC
with 
> information about the WTP.  This descriptor provides insufficient
information 
> to the AC, if the type of WTP is not know in advance.  If the WTP is
not 
> supporting 802.11, this descriptor does not provide enough information
to the 
> AC for it to make that determination and there is insufficient space
in the 
> WTP Radio Information element to make up for this lack.

> If we are to produce a protocol that is able to support several
different 
> types of existing wireless protocols, there needs to be a clearly
articulated 
> way to describe the protocols supported on the WTP, during the
discovery 
> process.  It is quite possible that an AC will not support all
wireless 
> protocols, as CAPWAP is applied to these other protocols in the
future.  The 
> WTP needs to be able to clearly specify what wireless protocol(s) it
supports 
> to the AC in the Discovery Request and the AC needs to be able to
indicate to 
> the WTP that it does, or does not, support the specified protocols.

> This could be done in several ways.  I propose that the WTP Radio
Information 
> element be extended to include a 16-bit protocol ID field that
contains a 
> single value from an enumeration (probably eventually managed by IANA)
of the 
> protocols for which a binding document has been published by the IETF.

> Because it is conceivable that a WTP might support more than one
wireless 
> protocol (say 802.16 and 802.11), I propose that the protocol ID field
be 
> repeated in the descriptor, with a count field preceding it, as often
as is 
> needed to list all the protocols in the WTP.

I would like to propose the following change to the WTP Descriptor:

<text>
4.5.37.  WTP Descriptor

   The WTP descriptor message element is used by a WTP to communicate
   it's current hardware/firmware configuration.  The value contains the
   following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Max Radios  | Radios in use |    Encryption Capabilities    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Num of Binding |    Reserved   | Wireless Binding Supported... |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=0                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=1                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=2                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]

   Num of Binding:   An 8-bit value representing the number of 16-bit
      Wireless Binding Supported fields present in the WTP Descriptor.

   Reserved:  A set of reserved bits for future use.  All
      implementations complying with this protocol MUST set to zero any
      bits that are reserved in the version of the protocol supported by
      that implementation.  Receivers MUST ignore all bits not defined
      for the version of the protocol they support.

   Wireless Binding Supported:   One or more 16-bit value representing
      the CAPWAP binding supported by the WTP.  The following values are
      supported:

      1 - IEEE 802.11:   The IEEE 802.11 CAPWAP binding (see [12]).

      2 - IEEE 802.16:   The IEEE 802.16 CAPWAP binding.

      3 - EPCGlobal:   The EPCGlobal CAPWAP binding.
</text>

> I also propose that the protocol ID field be added to the WTP Radio 
> Information element and that this element be repeated in the Discovery
Request 
> as needed to provide information about all the radios for each
protocol in the 
> WTP.

Unfortunately, I do not know what WTP Radio information element is being
discussed
here - the only one that has a somewhat similar name is the WTP Radio
Statistics,
and I suspect that's not what the creator of the issue wanted.

> Finally, I propose that the Discovery Response message include a new
message 
> element, the Supported Protocols element, to indicate to the WTP which
of the 
> WTP's wireless protocols are supported by the AC.  This information
can be 
> used by the WTP to determine the AC to which it will subsequently send
the 
> Join Request.  The Supported Protocols message element will include
the list 
> of protocol ID supported by the AC.  

The AC Descriptor already had such a field, but I am proposing changing
it to be
more consistent with the WTP Descriptor (above). The new text reads:

<text>
4.5.1.  AC Descriptor

   The AC payload message element is used by the AC to communicate it's
   current state.  The value contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Stations           |             Limit             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Active WTPs          |            Max WTPs           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Security   |  R-MAC Field  |   Reserved1   |  DTLS Policy  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Num of Binding |    Reserved   | Wireless Binding Supported... |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=4                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=5                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Num Of Binding:   An 8-bit value representing the number of 16-bit
      Wireless Binding Supported fields present in the AC Descriptor.

   Reserved:  A set of reserved bits for future use.  All
      implementations complying with this protocol MUST set to zero any
      bits that are reserved in the version of the protocol supported by
      that implementation.  Receivers MUST ignore all bits not defined
      for the version of the protocol they support.

   Wireless Binding Supported:   One or more 16-bit value representing
      the CAPWAP binding supported by the AC.  The following values are
      supported:

      1 - IEEE 802.11:   The IEEE 802.11 CAPWAP binding (see [12]).

      2 - IEEE 802.16:   The IEEE 802.16 CAPWAP binding.

      3 - EPCGlobal:   The EPCGlobal CAPWAP binding.
</text>

> This Supported Protocols element could be constructed by the AC in two

> different ways.  One way would be to construct the list statically, at
compile 
> time, and always return this entire list.  Constructed in this
fashion, the 
> list would always have at least one entry.  The WTP would then scan
this list 
> on receipt and determine if one or more of the protocols for which it
needs 
> support are present.  

> An alternate way to construct this element would be for the AC to put
only 
> those protocols indicated by the WTP in the Discovery Request for
which the AC 
> provides support into the list.  Constructed in this fashion, the list
might 
> be empty, if there are not matching protocols shared between the AC
and WTP.  
> The WTP would still scan the list on receipt to determine if one or
more 
> protocols for which it needs support are present in the list.

> Regardless of how the AC constructs the list of supported protocols,
the WTP 
> still makes the decision as to which AC it will join.  In the Join
Request, 
> the WTP MUST send only those protocols  in the WTP descriptor that
have been 
> indicated to be supported by the AC to which the Join Request is sent.
In 
> this way, a WTP that supports multiple wireless protocols might be
supported 
> by more than one AC. 
I have made changes in various sections to help make this clearer.

<text>
3.2.  AC Discovery
   The AC Discovery phase allows the WTP to determine which ACs are
   available, and chose the best AC to establish a CAPWAP session with.
   The discovery phase occurs when the WTP enters the Discovery state,
   which is optional.  A WTP does not need to perform the AC discovery
   if it has a pre-configured AC which it wishes to utilize.  This
   section details the mechanism used by the WTP to dynamically
   discovery candidate ACs.

   A WTP and an AC will frequently not reside in the same IP subnet
   (broadcast domain).  When this occurs, the WTP must be capable of
   discovering the AC, without requiring that multicast services are
   enabled in the network.
[...]
   Once the WTP has received Discovery Responses from the candidate ACs,
   it MAY use other factors in determining which is the preferred AC.
   For instance, the AC Descriptor, present in the Discovery Response,
   provides the list of CAPWAP bindings supported by the AC.  A WTP MAY
   decide to connect to an AC based on the supported bindings
   advertised.

4.5.31.  Result Code
[...]
   Result Code:   The following values are defined:
[...]
      9  Join Failure (Binding Not Supported)

5.1.  Discovery Request Message
[...]
   The WTP Descriptor included in the Discovery Request includes the
   CAPWAP bindings supported by the WTP.

5.2.  Discovery Response Message
[...]
   The AC Descriptor included in the Discovery Request includes the
   CAPWAP bindings supported by the AC.  The AC MAY include only the
   bindings it shares in common with the WTP, known through the WTP
   Descriptor received in the Discovery Request, or it MAY include all
   of the bindings supported.  The WTP MAY use the supported bindings in
   its AC decision process.  Note that if it uses an AC that does not
   support a specific CAPWAP binding, service for that binding MUST NOT
   be provided to stations.

6.1.  Join Request
[...]
   The WTP Descriptor included in the Join Request includes only the
   CAPWAP bindings supported by the AC that the WTP expects to utilize.
   Including a binding that is unsupported by the AC will result in a
   failed Join Response.

6.2.  Join Response
[...]
   If the WTP Descriptor in the Join Request included a binding that is
   not supported by the AC, the AC sets the Result Code message element
   to "Binding Not Supported".

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

---

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

All,

Unfortunately, it appears as if Dorothy had made some initial changes
to the specifications in -04/-01, which I somehow missed. Therefore,
some
of the changes that I proposed are not valid. Specifically, the changes
to the AC Descriptor and WTP Descriptor, and all references to these.
I have merged both Dorothy and my changes, and made some additional
clarifications on the use of the CAPWAP bindings for discovery and
capabilities advertisement purposes.

Please find the complete proposed text for issue 219 below.
<text>
draft-ietf-capwap-protocol-specification-05:
2.1.  Wireless Binding Definition

   The CAPWAP protocol is independent of a specific WTP radio
   technology.  Elements of the CAPWAP protocol are designed to
   accommodate the specific needs of each wireless technology in a
   standard way.  Implementation of the CAPWAP protocol for a particular
   wireless technology must follow the binding requirements defined for
   that technology.

   When defining a binding for wireless technologies, the authors MUST
   include any necessary definitions for technology-specific messages
   and all technology-specific message elements for those messages.  At
   a minimum, a binding MUST provide:

   1 -   The definition for a binding-specific Statistics message
      element, carried in the WTP Event Request message

   2 -   A message element carried in the Station Configure Request to
      configure STA information on the WTP

   3 -   A WTP Radio Information message element carried in the
      Discovery and Primary Discovery messages as well as in the Join
      messages, indicating the binding specific radio types supported at
      the WTP and AC.

   If technology specific message elements are required for any of the
   existing CAPWAP messages defined in this specification, they MUST
   also be defined in the technology binding document.

   The naming of binding-specific message elements MUST begin with the
   name of the technology type, e.g., the binding for IEEE 802.11,
   provided in [13], begins with "IEEE 802.11"."

   The CAPWAP binding concept is also used in any future specifications
   that add functionality to either the base CAPWAP protocol
   specification, or any published CAPWAP binding specification.  A
   separate WTP Radio Information message element needs to be created in
   order to properly advertise support for the specification.  This
   mechanism allows for future protocol extensibility, while providing
   the necessary capabilities advertisement, through the WTP Radio
   Information message element, to ensure WTP/AC interoperability.

3.2.  AC Discovery
[...]
   Once the WTP has received Discovery Responses from the candidate ACs,
   it MAY use other factors in determining which is the preferred AC.
   For instance, each binding defines a WTP Radio Information message
   element (see Section 2.1), which the AC includes in the Discovery
   Responses.  The presence of one or more of these message elements is
   used to identify which CAPWAP bindings are supported by the AC.  A
   WTP MAY decide to connect to an AC based on the supported bindings
   advertised.

5.1.  Discovery Request Message
[...]
   The binding specific WTP Radio Information message element (see
   Section 2.1) is included in the Discovery Request to advertise WTP
   support for one or more CAPWAP bindings.

   The following message elements MUST be included in the Discovery
   Request message:
[...]

   o  WTP Radio Information Element(s)that the WTP supports; These are
      defined by the individual link layer CAPWAP Binding Protocols (see
      Section 2.1 for more information).

5.2.  Discovery Response Message
[...]
   One or more binding specific WTP Radio Information message elements
   (see Section 2.1) are included in the Discovery Request to advertise
   AC support for the CAPWAP bindings.  The AC MAY include only the
   bindings it shares in common with the WTP, known through the WTP
   Radio Information message elements received in the Discovery Request,
   or it MAY include all of the bindings supported.  The WTP MAY use the
   supported bindings in its AC decision process.  Note that if it uses
   an AC that does not support a specific CAPWAP binding, service for
   that binding MUST NOT be provided by the WTP.

   The following message elements MUST be included in the Discovery
   Response Message:
[...]

   o  WTP Radio Information Element(s)that the AC supports; These are
      defined by the individual link layer CAPWAP Binding Protocols (see
      Section 2.1 for more information).

5.3.  Primary Discovery Request Message
[...]
   The following message elements MUST be included in the Primary
   Discovery Request message.
[...]

   o  WTP Radio Information Element(s)that the WTP supports; These are
      defined by the individual link layer CAPWAP Binding Protocols (see
      Section 2.1 for more information).

5.4.  Primary Discovery Response
[...]
   The following message elements MUST be included in the Primary
   Discovery Response message.
[...]

   o  WTP Radio Information Element(s)that the AC supports; These are
      defined by the individual link layer CAPWAP Binding Protocols (see
      Section 2.1 for more information).

6.1.  Join Request
[...]
   One or more WTP Radio Information message elements (see Section 2.1)
   are included in the Join Request to request service for the CAPWAP
   bindings by the AC.  Including a binding that is unsupported by the
   AC will result in a failed Join Response.
[...]

   The following message elements MUST be included in the Join Request
   message.
[...]
   o  WTP Radio Information Element(s)that the WTP supports; These are
      defined by the individual link layer CAPWAP Binding Protocols (see
      Section 2.1 for more information).

6.2.  Join Response
[...]
   If one of the WTP Radio Information message elements (see
   Section 2.1) in the Join Request requested support for a CAPWAP
   binding which the AC does not support, the AC sets the Result Code
   message element to "Binding Not Supported".
[...]
   The following message element MUST be included in the Join Response
   message.
[...]
   o  WTP Radio Information Element(s)that the AC supports; These are
      defined by the individual link layer CAPWAP Binding Protocols (see
      Section 2.1 for more information).

draft-ietf-capwap-protocol-binding-ieee80211-02:

5.  CAPWAP Control Message bindings

   This section describes the IEEE 802.11 specific message elements
   included in CAPWAP Control Messages.

   The following IEEE 802.11 specific message element MUST be included
   in the CAPWAP Discovery Request Message.

   o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
      802.11 WTP Radio Information message element MUST be present for
      every radio in the WTP.

   The following IEEE 802.11 specific message element MUST be included
   in the CAPWAP Discovery Response Message.

   o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
      802.11 WTP Radio Information message element MUST be present for
      every radio in the WTP.

5.3.  Primary Discovery Request Message

   The following IEEE 802.11 specific message element MUST be included
   in the CAPWAP Primary Discovery Request Message.

   o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
      802.11 WTP Radio Information message element MUST be present for
      every radio in the WTP.

5.4.  Primary Discovery Response Message

   The following IEEE 802.11 specific message element MUST be included
   in the CAPWAP Primary Discovery Response Message.

   o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
      802.11 WTP Radio Information message element MUST be present for
      every radio in the WTP.

5.5.  Join Request Message

   The following IEEE 802.11 specific message element MUST be included
   in the CAPWAP Join Request Message.

   o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
      802.11 WTP Radio Information message element MUST be present for
      every radio in the WTP.

5.6.  Join Response Message

   The following IEEE 802.11 specific message element MUST be included
   in the CAPWAP Join Response Message.

   o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
      802.11 WTP Radio Information message element MUST be present for
      every radio in the WTP.

[...]
6.25.  IEEE 802.11 WTP Radio Information

   The IEEE 802.11 WTP Radio Information message element is used to
   communicate the radio information for each IEEE 802.11 radio in the
   WTP.  The Discovery Request message, Primary Discovery Request
   message and Join Request message MUST include one such message
   element per radio in the WTP.  The Radio-Type field is used by the AC
   in order to determine which IEEE 802.11 technology specific binding
   is to be used with the WTP.

   The message element contains two fields, as shown below.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |           Radio Type                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Radio Type    |
     +-+-+-+-+-+-+-+-+

   Type:   1048 for IEEE 802.11 WTP Radio Information

   Length:   5

   Radio ID:   The Radio Identifier, which typically refers to an
      interface index on the WTP

   Radio Type:   The type of radio present.  Note this bitfield can be
      used to specify support for more than a single type of PHY/MAC.
      The following values are supported:

      1 - 802.11b:   An IEEE 802.11b radio.

      2 - 802.11a:   An IEEE 802.11a radio.

      4 - 802.11g:   An IEEE 802.11g radio.

      8 - 802.11n:   An IEEE 802.11n radio.

      0xOF - 802.11b, 802.11a, 802.11g and 802.11n:   The 4 radio types
         indicated are supported in the WTP.
</text>

Pat Calhoun