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

From: young <[email-masked]>
Date: Tue, 07 Oct 2008 16:40:48 +0800

HI, 

The new version of MIB drafts will use the method suggested by David to
close the issue :

How to handle data type difference of Mac Type and tunnel mode in the MIBs

  　　The description of question and answer to it are as followed.

          Regards

          RIchard

-----邮件原件-----
发件人: David Harrington [mailto:[email-masked]] 
发送时间: 2008年10月6日 22:26
收件人: 'young'; [email-masked]
抄送: 'Yong Zhang'; [email-masked]
主题: RE: kindly give some suggestion for this question

Hi,

My advice remains the same.

If you know the enumeration in the protocol is not likely to change in the
future, and my impression is that it will not, then you can represent the
enumerated values in a BITS type in the MIB, so you can gain the benefit of
consistent types for the MAC type and tunnel modes.

dbh

  _____  

From: young [mailto:[email-masked]] 
Sent: Monday, October 06, 2008 3:34 AM
To: 'David Harrington'; [email-masked]
Cc: 'Yong Zhang'; [email-masked]
Subject: kindly give some suggestion for this question

     Hi, kindly give some suggestion for this question: How to handle data
type difference of Mac Type and tunnel mode in the MIBs

     I gave more explain about my question in my previous email ( it is
below)

I want to close this issue in the new version.

     For new version, we have done lots of changes for readability and
minimize the gap between MIB drafts and Protocol.

     It already passes the tools of Nits, spell and smilint. We plan to
publish them within this week.

     Regards

     Richard

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

       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

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

Use different type.

How to handle this case in the MIB?

Please give some suggestion.

-----邮件原件-----
发件人: 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, 

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