Subject: [Capwap] Index issue of the station table

From: young <[email-masked]>
Date: Tue, 22 Dec 2009 14:07:16 +0800

Hi, Bert:

I discuss with Yong today. Please check our opinion to the Index.
The index design of  apwapBaseStationEntry could be simplified.

The capwapBaseStationEntry is to display station 
which is associated with the specific radio on the WTP.
I used to concern the roaming case (A station association with 
Two AP at same time), so give a very complex design of the indexes.

Since the roaming time is very short, it is valid to use capwapBaseStationId
As one and only index.
It is also good for the performance.
Also, I suggest to add a note to explain the roaming case:
       Notes that in the some cases such as roaming that a station may
associate
         with two WTPs at a certain time, the MIB implementation MUST
         ensure there is only one entry for a specific station. 

Base on it, the change would be:
capwapBaseStationTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF CapwapBaseStationEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of objects that display stations which are accessing
         the wireless service provided by the AC."
    REFERENCE
        "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtps 5 }

capwapBaseStationEntry OBJECT-TYPE
    SYNTAX      CapwapBaseStationEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A set of objects that display a station which is
         associated with the specific radio on the WTP.
      Notes that in the some cases such as roaming that a station may
associate
         with two WTPs at a certain time, the MIB implementation MUST
         ensure there is only one entry for a specific station. " 

    INDEX { capwapBaseStationId }
    ::= { capwapBaseStationTable 1 }

CapwapBaseStationEntry ::= SEQUENCE {
      capwapBaseStationId            CapwapBaseStationIdTC, 
      capwapBaseStationWtpId         CapwapBaseWtpIdTC,
      capwapBaseStationWtpRadioId    CapwapBaseRadioIdTC,
      capwapBaseStationAddedTime     DateAndTime,
      capwapBaseStationVlanName      SnmpAdminString
    }
    
capwapBaseStationId OBJECT-TYPE
    SYNTAX      CapwapBaseStationIdTC
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Represents the unique identifier of the station."
    REFERENCE
        "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseStationEntry 1 }
    
capwapBaseStationWtpId OBJECT-TYPE
    SYNTAX      CapwapBaseWtpIdTC
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Represents the unique identifier of a WTP in running state."
    ::= { capwapBaseStationEntry 2 }
    
capwapBaseStationWtpRadioId OBJECT-TYPE
    SYNTAX      CapwapBaseRadioIdTC
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Represents the identifier of a PHY radio on a WTP, which
         is required to be unique on a WTP.
         For example, WTP A and WTP B use a same value of
         capwapBaseWirelessBindingRadioId for their first radio."
    REFERENCE
        "Section 4.3. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseStationEntry 3 }

capwapBaseStationAddedTime OBJECT-TYPE
    SYNTAX      DateAndTime
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the time when the station is added."
    REFERENCE
        "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseStationEntry 4 }

capwapBaseStationVlanName OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE(0..32))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents VLAN name to which the station is associated."
    REFERENCE
        "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseStationEntry 5 }

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: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 22 Dec 2009 09:02:17 +0100

I suspect we need help from CAPWAP experts here. I have not followed CAPWAP
work for 3-4 years now... so I am not up to speed on it.

I have some comments inline anyways, but pls do not consider them 
necessarily valid.

>          ensure there is only one entry for a specific station. 
The indexing is indeed (much) simpler... but...
If there is a possibility of two associations, how do we answer these 
questions:
- which of the two entries should be shown in the MIB?
- what if (because of some problem) the situation exists for a longer 
time (maybe forever?)
  that would probably be a bug, but if so, that is something one would 
like to be able
  to detect with querying the MIB, no?

>     MAX-ACCESS  not-accessible
since this is no longer an INDEX object, it should probably be read-only!!

>     MAX-ACCESS  not-accessible

since this is no longer an INDEX object, it should probably be read-only!!