Subject: [Capwap] How to handle data type difference of Mac Type and tunnel mode in the MIBs?

From: young <[email-masked]>
Date: Thu, 25 Sep 2008 10:02:51 +0800

Hi, 

the Mac Type and tunnel mode is defined in the base protocol. 

And the dot11 binding protocol use it for a WLAN network.

Currently, Base MIB defines TCs for Mac Type and tunnel mode as followed,
and Dot11 MIB

IMPORTs them and define objects based on them for a WLAN network.

I think this way is valid. If each binding MIBs separately defines TC of MAC
and

tunnel mode, it is not aright way. The should use a common TC.

But in the base protocol and dot11 binding protocol, The Mac Type and tunnel
mode

Use different type.

Base protocol use BITS, while binding MIB is enumerated.

How to handle this case in the MIB?

Please give some suggestion.

In the Base MIB it defines TCs for them:

CapwapBaseWtpTunnelMode ::= TEXTUAL-CONVENTION

    STATUS      current

    DESCRIPTION

        "Represents the tunneling modes of operation that are

         supported by the WTP.

         The possible value could be:

          unused(0)        - This bit is unused

          localBridging(1) - Local Bridging Mode,

          dot3Tunnel(2)    - 802.3 Frame Tunnel Mode,

          nativeTunnel(3)  - Native Frame Tunnel Mode."

    REFERENCE

        "Section 4.6.42. of CAPWAP Protocol Specification, RFC xxx."

    SYNTAX      BITS { unused(0),

                       localBridging(1),

                       dot3Tunnel(2),

                       nativeTunnel(3) }

CapwapBaseWtpMacType ::= TEXTUAL-CONVENTION

    STATUS      current

    DESCRIPTION

        "Represents the MAC mode of operation supported by the WTP.

         The possible value could be:

          localMAC(0) - Local-MAC Mode,

          splitMAC(1) - Split-MAC Mode."

          both(2)     - Both Local-MAC and Split-MAC."

    REFERENCE

        "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx."

    SYNTAX      INTEGER { localMAC(0), splitMAC(1), both(2) }

In the dot11 MIB, defines objects based on the TCs.

capwapDot11WtpMacType OBJECT-TYPE

    SYNTAX      CapwapWtpMacType

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

        "Represents whether the WTP should run the WLAN in

         Local or Split MAC modes."

    REFERENCE

        "Section 6.1. of CAPWAP Protocol Binding for IEEE 802.11,

         RFC xxx."

    ::= { capwapDot11WlanConfigEntry 3 }

capwapDot11WtpTunnelMode OBJECT-TYPE

    SYNTAX      CapwapWtpTunnelMode

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

        "Represents the frame tunneling type to be used for 802.11 data

         frames from all stations associated with the WLAN."

    REFERENCE

        "Section 6.1. of CAPWAP Protocol Binding for IEEE 802.11,

         RFC xxx."

    ::= { capwapDot11WlanConfigEntry 4 }

Regards

Richard

_________________________________________________________________
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 Harrington" <[email-masked]>
Date: Thu, 25 Sep 2008 10:33:22 +0300

Hi,
 
If I understand the issue properly, your voncern is the difference in
types, and changing the type of one of these would solev the problem.
 
A BITS type could be used to represent the MacType. This BITS type
could represent local or split by setting only one bit, and it can be
used to represent "both" by setting two bits.
 
I will note that the tunnelmode is extensible - new BITs can be added
to support new types, and multiple types can be supported on a device.
In comparison, MacType can never be expanded beyond local and
split-mic modes the way it is currently defined. I don't know that
anybody will ever invent an alternative to local and split, but if
they do, your enumeration will not be able to represent it very easily
(to add a new mode "foo", you would need to define foo(4),
foo+local(5), foo+split(6), foo+local+split(7). And then if you define
a new mode bar(n), you would need to grow your enumerations
combinatorially. Using BITS means adding one BIT definition.
 
dbh

  _____  

From: young [mailto:[email-masked]] 
Sent: Thursday, September 25, 2008 5:03 AM
To: [email-masked]
Cc: [email-masked]; 'Yong Zhang'
Subject: [Capwap] How to handle data type difference of Mac Type and
tunnel mode in the MIBs?

Hi, 

Currently, Base MIB defines TCs for Mac Type and tunnel mode as
followed, and Dot11 MIB

I think this way is valid. If each binding MIBs separately defines TC
of MAC and

But in the base protocol and dot11 binding protocol, The Mac Type and
tunnel mode

Use different type.

    STATUS      current

    DESCRIPTION

         supported by the WTP.

    REFERENCE

    SYNTAX      BITS { unused(0),

                       localBridging(1),

                       dot3Tunnel(2),

                       nativeTunnel(3) }

    STATUS      current

    DESCRIPTION

    REFERENCE

    SYNTAX      CapwapWtpMacType

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

    REFERENCE

         RFC xxx."

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

        "Represents the frame tunneling type to be used for 802.11
data

    REFERENCE

         RFC xxx."

Regards

Richard

---

From: young <[email-masked]>
Date: Sat, 27 Sep 2008 09:58:31 +0800

Hi,

      Sorry, I have not made my questions clear. 

      The problem is caused by difference between base and 802.11 binding
protocol, not by MIBs themselves. 

In them, The Mac Type and tunnel mode use different type:Base protocol use
BITS, while binding protocol is enumerated.

       For MIB design, I think the valid design is to define TCs for MAC
type and tunnel mode in the Base MIBs.

      When 802.11 binding MIB defines MIB objects of MAC type and tunnel
Mode for a specific WLAN network,

      These objects will be defined by  those TCs defined in the Base MIBs,

      But How to handle the data type difference cause by protocols (base
and 802.11 binding protocol)

     Regards

     Richard

mode for a 

Use different type.

 

-----邮件原件-----
发件人: David Harrington [mailto:[email-masked]] 
发送时间: 2008年9月25日 15:33
收件人: 'young'; [email-masked]
抄送: [email-masked]; 'Yong Zhang'
主题: RE: [Capwap] How to handle data type difference of Mac Type and tunnel
mode in the MIBs?

Hi,

If I understand the issue properly, your voncern is the difference in types,
and changing the type of one of these would solev the problem.

A BITS type could be used to represent the MacType. This BITS type could
represent local or split by setting only one bit, and it can be used to
represent "both" by setting two bits.

I will note that the tunnelmode is extensible - new BITs can be added to
support new types, and multiple types can be supported on a device. In
comparison, MacType can never be expanded beyond local and split-mic modes
the way it is currently defined. I don't know that anybody will ever invent
an alternative to local and split, but if they do, your enumeration will not
be able to represent it very easily (to add a new mode "foo", you would need
to define foo(4), foo+local(5), foo+split(6), foo+local+split(7). And then
if you define a new mode bar(n), you would need to grow your enumerations
combinatorially. Using BITS means adding one BIT definition.

dbh

  _____  

From: young [mailto:[email-masked]] 
Sent: Thursday, September 25, 2008 5:03 AM
To: [email-masked]
Cc: [email-masked]; 'Yong Zhang'
Subject: [Capwap] How to handle data type difference of Mac Type and tunnel
mode in the MIBs?

Hi, 

Use different type.

    STATUS      current

    DESCRIPTION

         supported by the WTP.

    REFERENCE

    SYNTAX      BITS { unused(0),

                       localBridging(1),

                       dot3Tunnel(2),

                       nativeTunnel(3) }

    STATUS      current

    DESCRIPTION

    REFERENCE

    SYNTAX      CapwapWtpMacType

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

    REFERENCE

         RFC xxx."

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

    REFERENCE

         RFC xxx."

Regards

Richard