
-- *******************************************************************
-- CISCO-LWAPP-MOBILITY-MIB.my
-- June 2006, Bharat Biswal

-- Copyright (c) 2005-2006 by Cisco Systems, Inc.
-- All rights reserved.
-- *******************************************************************

CISCO-LWAPP-MOBILITY-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY,
    OBJECT-TYPE,
    NOTIFICATION-TYPE,
    Unsigned32,
    Integer32
        FROM SNMPv2-SMI
    MODULE-COMPLIANCE,
    OBJECT-GROUP,
    NOTIFICATION-GROUP
        FROM SNMPv2-CONF
    DisplayString,
    TruthValue,
    RowStatus
        FROM SNMPv2-TC
    InetAddressType,
    InetAddress
        FROM INET-ADDRESS-MIB
    ciscoMgmt
        FROM CISCO-SMI;

-- ********************************************************************
-- *  MODULE IDENTITY
-- ********************************************************************

ciscoLwappMobilityMIB MODULE-IDENTITY
    LAST-UPDATED    "200607190000Z"
    ORGANIZATION    "Cisco Systems Inc."
    CONTACT-INFO
            "Cisco Systems,
            Customer Service

            Postal: 170 West Tasman Drive
            San Jose, CA  95134
            USA

            Tel: +1 800 553-NETS

            Email: cs-snmp@cisco.com"
    DESCRIPTION
            "This MIB is intended to be implemented on all those
            devices operating as Central Controllers (CC) that

            terminate the Light Weight Access Point Protocol

            tunnel from Light-weight LWAPP Access Points.


            This MIB provides configuration and status information

            about the 802.11 WLAN mobility.                 


            The relationship between CC and the LWAPP APs

            can be depicted as follows:


            +......+     +......+     +......+           +......+

            +      +     +      +     +      +           +      +

            +  CC  +     +  CC  +     +  CC  +           +  CC  +

            +      +     +      +     +      +           +      +

            +......+     +......+     +......+           +......+

            ..            .             .                 .

            ..            .             .                 .

            .  .            .             .                 .

            .    .            .             .                 .

            .      .            .             .                 .

            .        .            .             .                 .

            +......+ +......+     +......+      +......+         
            +......+

            +      + +      +     +      +      +      +          +     
            +

            +  AP  + +  AP  +     +  AP  +      +  AP  +          +  AP 
            +

            +      + +      +     +      +      +      +          +     
            +

            +......+ +......+     +......+      +......+         
            +......+

            .              .             .                 .

            .  .              .             .                 .

            .    .              .             .                 .

            .      .              .             .                 .

            .        .              .             .                 .

            +......+ +......+     +......+      +......+         
            +......+

            +      + +      +     +      +      +      +          +     
            +

            +  MN  + +  MN  +     +  MN  +      +  MN  +          +  MN 
            +

            +      + +      +     +      +      +      +          +     
            +

            +......+ +......+     +......+      +......+         
            +......+



            The LWAPP tunnel exists between the controller and

            the APs.  The MNs communicate with the APs through

            the protocol defined by the 802.11 standard.


            LWAPP APs, upon bootup, discover and join one of the

            controllers and the controller pushes the configuration,

            that includes the WLAN parameters, to the LWAPP APs.

            The APs then encapsulate all the 802.11 frames from

            wireless clients inside LWAPP frames and forward

            the LWAPP frames to the controller.


                               GLOSSARY


            Access Point ( AP )


            An entity that contains an 802.11 medium access

            control ( MAC ) and physical layer ( PHY ) interface

            and provides access to the distribution services via

            the wireless medium for associated clients.  


            LWAPP APs encapsulate all the 802.11 frames in

            LWAPP frames and sends it to the controller to which

            it is logically connected.


            Basic Service Set Identifier (BSSID)


            The identifier for the service set comprising of

            all the 802.11 stations under the control of

            one coordinating Access Point.  This identifier

            happens to be the MAC address of the dot11 radio

            interface of the Access Point.  The wireless

            clients that associate with the Access Point

            get the wired uplink through this particular 

            dot11 interface. 


            Central Controller ( CC )


            The central entity that terminates the LWAPP protocol

            tunnel from the LWAPP APs.  Throughout this MIB,

            this entity also referred to as 'controller'. 


            Light Weight Access Point Protocol ( LWAPP ) 


            This is a generic protocol that defines the 

            communication between the Access Points and the

            Central Controller. 


            Mobile Node ( MN )


            A roaming 802.11 wireless device in a wireless

            network associated with an access point. 


            Mobility 


            Concept by which a Mobile Node can roam from one 

            Access Point to another Access Point, across multiple

            Central Controllers, without need for repeated 

            authentication. 


            Mobility Group


            A set of Central Controllers which exchange Mobile 

            Node's authentication information, so that the Mobile

            Node upon roaming need not re-authenticate.  


            Mobility Anchor


            When a Central Controller in the Mobility Group is 

            designated as Mobility Anchor, then all the Mobile 

            Node's traffic is tunnelled to it by other

            Controllers in the Mobility Group.


            Guest Tunneling (GT)


            The concept of designating a Central Controller in 

            the Mobility Group as Mobility Anchor, so that all

            the Mobile Node's traffic is tunnelled to it by other

            Controllers in the Mobility Group.              


            Station Management (SMT)


            This term refers to the internal management of the

            802.11 protocol operations by the AP to work

            cooperatively with the other APs and 802.11

            devices in the network.


            Ethernet over Internet Protocol (EoIP)


            Ethernet over IP (EoIP) is a protocol that creates 

            an Ethernet tunnel between two routers on top of an

            IP connection. The EoIP interface appears as an 

            Ethernet interface.


            Reverse path filtering (RPF) 


            Reverse path filtering (RPF) is a feature provided

            by most modern Internet Protocol routers, which may

            be used to reduce the risk of customers attacking

            other internet hosts. One of the problems network

            service providers face today is hackers generating

            packets with fake source IP addresses, a technique

            known as spoofing. This is often done in order to

            initiate a denial-of-service attack against another

            internet host or network.

            Since the source IP addresses of the incoming packets

            change, often randomly, and for every packet, the

            target of such an attack can't easily filter out the

            attacking packets. However, the source of the attack,

            i.e. the network service provider of the attacking 

            host, has a simple way to stop such packets from ever

            leaving its network. A router always knows which 

            networks are reachable via any of its interfaces. 

            By checking the source IP address of all packets 

            coming in via an interface against the networks known

            to be behind that interface, the router can simply 

            drop packets that aren't supposed to come from there.

            Hence, reverse path filtering filters packets 

            according to the 'reverse path' to their source 

            address. If the path back to the source address 

            does not match the path the packet is coming from,

            it is dropped.




            REFERENCE


            [1] Part 11 Wireless LAN Medium Access Control ( MAC )

            and Physical Layer ( PHY ) Specifications.


            [2] Draft-obara-capwap-lwapp-00.txt, IETF Light 

            Weight Access Point Protocol. "
    REVISION        "200607190000Z"
    DESCRIPTION
            "Initial version of this MIB module."
          ::= { ciscoMgmt 576 }


ciscoLwappMobilityMIBNotifs  OBJECT IDENTIFIER
    ::= { ciscoLwappMobilityMIB 0 }

ciscoLwappMobilityMIBObjects  OBJECT IDENTIFIER
    ::= { ciscoLwappMobilityMIB 1 }

ciscoLwappMobilityMIBConform  OBJECT IDENTIFIER
    ::= { ciscoLwappMobilityMIB 2 }

-- *******************************************************************
-- Per WLAN, anchors table
-- *******************************************************************

cLMobilityAnchorTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF CLMobilityAnchorEntry 
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
            "This table represents the information about the
            802.11 LWAPP Mobility Anchors on individual WLANs.  


               +...............+   
               +               +   
               +    ROUTER     +   
               +   10.16.1.1   +   
               +...............+   
                      .. 
                    .    .
                  .        .
                .            .
              .                .
            .                    .
            10.16.109.112        10.16.105.39
            +......+   <<-------->>   +......+    
            +      +  [3]CC2 tunnels  +      +    
            +  CC1 +   MN1's traffic  +  CC2 +    
            +      +   to Anchor CC1  +      +    
            +......+   using EoIP     +......+    
            .                        .
            . Anchor        Foreign  .
            .                        .
            +......+                  +......+          
            +      +                  +      +          
            +  AP1 +                  +  AP2 +          
            +      +                  +      +          
            +......+                  +......+          
            'typhoon'   .                        ^   'typhoon'
            .                          |
            .           [2] associates  |
            .              with AP2/CC2  |
            .                             |
            +......+   [1]              +......+
            +      +  moves to region   +      +
            +  MN1 +  ---------->>>     +  MN1 +
            +      +  serviced by AP2   +      +
            +......+                    +......+
            10.16.109.199               10.16.109.199

            In the above diagram, Central Controllers CC1 and CC2 have
            been configure in a Mobility Group.

            Currently the Mobile Node 'MN1' obtains its IP from the 
            Central Controller 'CC1' with which it first associates 
            via WLAN 'typhoon' through Access Point 'AP1'. 'CC1' 
            obtains DHCP address, say 10.16.109.199 for client 'MN1'.
            Now the client 'MN1' is identified by 10.16.109.199 for 
            furthure communication with the network and the 
            communication happens via 'CC1'. 

            Since, 'CC1' and 'CC2' are in same mobility group, 'CC1' 
            sends the authentication block of 'MN1' to 'CC2'.


            Central Controller 'CC2' has an associated Access Point 
            'AP2' which beams WLAN 'typhoon' and uses 10.16.105.0 / 
            255.255.255.0 subnet instead.         

            Next, the Mobile Node 'MN1' moves out of range of 'AP1'
            and gets in to proximity with 'AP2' and continues to use
            WLAN 'typhoon'. 'CC2' locally authenticates 'MN1' against
            authentication block shared from 'CC1'. 'CC2' forwards all
            traffic from 'MN1' to router. This is called WLAN mobility.        

            But hold on, 'CC2' uses 10.16.105.0 / 255.255.255.0 subnet 
            for WLAN 'typhoon'. So we have two problems here :    

            a> Traffic of 10.16.109.0 / 255.255.255.0 subnet has to be
            accessible from 10.16.105.0 / 255.255.255.0 subnet.

            b> Unneccessary overloading of 10.16.105.0 / 255.255.255.0 
            subnet by traffic from 10.16.109.0 / 255.255.255.0 subnet.

            How do we address these issues ??           

            If an EoIP tunnel can be established between 'CC1' and 'CC2'
            and 'CC1' sends all traffic bound to 'MN1', 10.16.109.199,
            on this tunnel to 'CC2', which in turn forwards it to 'MN1',
            then, above two subnet-problems are resolved. This is called
            Mobility Anchoring. 'CC1' is the Mobility Anchor and 'CC2' is
            the 'Foreign' for WLAN 'typhoon'.

            As per the configuration, user creates a MobilityAnchor entry
            in 'CC2' for WLAN 'typhoon' with IP address as 'CC1', i.e. 
            10.16.109.112. So, when 'MN1' connects to WLAN 'typhoon' via 
            'AP2', then 'CC2' establishes EoIP tunnel with 10.16.109.112
            and forwards the packets to 'MN1'.

            Given the above example, the cLMobilityAnchorEntry on 'CC2'
            looks like :    

            ------------------------------------------------------------------
            |      MIB - ATTRIBUTES           |       ROW#1        |  ROW#2  |       
            ------------------------------------------------------------------
            | cLMobilityAnchorWlanSsid        |     typhoon        |         |
            ------------------------------------------------------------------
            | cLMobilityAnchorSwitchIPAddress |    10.16.109.112   |         |
            ------------------------------------------------------------------
            | cLMobilityAnchorStatus          |        up(4)       |         |
            ------------------------------------------------------------------
            | cLMobilityAnchorRowStatus       |      active(1)     |         |
            ------------------------------------------------------------------

            This feature has advantages for both security and load 
            balancing.  It can be used to restrict a WLAN to a single
            subnet, regardless of the MN's entry point into the network.
            A 'public' or guest WLAN can thus be accessed throughout an
            enterprise, but still is restricted to a specific subnet.  
            It can also be used to provide some geographic load balancing,
            since the WLANs can represent a particular section of a 
            building (ie., engineering, marketing).  Those groups can be 
            'anchored' on a particular subnet/switch rather than on the 
            CC of first occurrence (ie., the switch controlling the APs 
            by the front door).

            "
    ::= { ciscoLwappMobilityMIBObjects 1 }

cLMobilityAnchorEntry OBJECT-TYPE
    SYNTAX          CLMobilityAnchorEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
            "Each entry in this table provides information about
            one 802.11 LWAPP Mobility Anchor configured on a WLAN
            on this controller."
    INDEX           {
                        cLMobilityAnchorWlanSsid,
                        cLMobilityAnchorSwitchAddressType,
                        cLMobilityAnchorSwitchAddress
                    } 
    ::= { cLMobilityAnchorTable 1 }

CLMobilityAnchorEntry ::= SEQUENCE {
        cLMobilityAnchorWlanSsid          DisplayString,
        cLMobilityAnchorSwitchAddressType InetAddressType,
        cLMobilityAnchorSwitchAddress     InetAddress,
        cLMobilityAnchorStatus            BITS,
        cLMobilityAnchorRowStatus         RowStatus
}

cLMobilityAnchorWlanSsid OBJECT-TYPE
    SYNTAX          DisplayString (SIZE  (1..32))
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION     "Local wlan-ssid to connect to Guest/Anchor switch" 
    ::= { cLMobilityAnchorEntry 1 }

cLMobilityAnchorSwitchAddressType OBJECT-TYPE
    SYNTAX          InetAddressType
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION     "Guest/Anchor switch Address type." 
    ::= { cLMobilityAnchorEntry 2 }

cLMobilityAnchorSwitchAddress OBJECT-TYPE
    SYNTAX          InetAddress
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
            "Guest/Anchor switch Address.
            The IP Address is limited to IPv4 and IPv6." 
    ::= { cLMobilityAnchorEntry 3 }

cLMobilityAnchorStatus OBJECT-TYPE
    SYNTAX          BITS {
                        controlpath(0),
                        datapath(1)
                    }
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
            "Operational and Connectivity status of the
            Mobility Anchor.            

            controlpath:
                    When bit is '0', this means successive
                    ICMP pings to the anchor have failed. 
                    When is '1', this means anchor is
                    reachable and responding to ICMP pings.

            datapath:
                    When bit is '0', this means successive 
                    EoIP pings to the anchor have failed.
                    When bit is '1', this means anchor is 
                    reachable and responding to EoIP pings.  
            " 
    ::= { cLMobilityAnchorEntry 4 }

cLMobilityAnchorRowStatus OBJECT-TYPE
    SYNTAX          RowStatus
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION     "Row Status" 
    ::= { cLMobilityAnchorEntry 5 }
 

-- ********************************************************************
-- *  Global Dot11 Mobility Anchor Configuration
-- ********************************************************************
cLMobilityAnchorGlobalDot11Config  OBJECT IDENTIFIER
    ::= { ciscoLwappMobilityMIBObjects 2 }


cLMobilityAnchorGroupKeepAliveNumber OBJECT-TYPE
    SYNTAX          Integer32 (3..20 )
    MAX-ACCESS      read-write
    STATUS          current
    DESCRIPTION
            "This parameter determines how many successive
            ping attempts to the anchor should fail before
            the anchor is declared DOWN."
    DEFVAL          { 3 } 
    ::= { cLMobilityAnchorGlobalDot11Config 1 }

cLMobilityAnchorGroupKeepAliveInterval OBJECT-TYPE
    SYNTAX          Integer32 (1..30 )
    MAX-ACCESS      read-write
    STATUS          current
    DESCRIPTION
            "This parameter determines the time interval
            (in seconds) between two consecutive ping attempts
            to an anchor."
    DEFVAL          { 10 } 
    ::= { cLMobilityAnchorGlobalDot11Config 2 }

cLMobilityAnchorSmtStatus OBJECT-TYPE
    SYNTAX          TruthValue
    MAX-ACCESS      read-write
    STATUS          current
    DESCRIPTION
            "This object  allows user to enable or disable
            Symmetric mobility tunneling for the controller.

            The controller provides inter-subnet mobility 
            for clients roaming from one AP to another within
            a Wireless LAN. This mobility is asymmetric in 
            nature where the client traffic to the wired 
            network is routed out directly via the 'foreign'
            controller. See the diagram above. This mechanism
            breaks when an upstream router has RPF enabled. 
            In this case the client traffic will be dropped 
            at the router because the RPF check ensures that
            the path back to the source address matches the 
            path the packet is coming from. 

            This attribute is aimed at addressing this issue. 

            It will allow enabling 'Symmetric Mobility
            Tunneling' or 'Bi-directional Tunneling'
            for mobile clients such that all the client
            traffic is sent to the 'anchor' controller and
            go successfully through RPF check. 

            When set to 'true', Symmetric Mobility Tunneling 
            will be enabled on the Controller on next reset. 

            When set to 'false', Symmetric Mobility Tunneling 
            will be disabled on the Controller on next reset.

            After setting this attribute to the desired value,
            user should reset the Controller for the change to
            take effect.

            " 
    ::= { cLMobilityAnchorGlobalDot11Config 3 }

cLMobilityAnchorCurrentSmt OBJECT-TYPE
    SYNTAX          TruthValue
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
            "This object  represents the current state of
            Symmetric mobility tunneling for the controller.

            When value is 'true', this means Symmetric Mobility
            Tunneling is currently enabled on the Controller. 

            When value is 'false', this means Symmetric Mobility
            Tunneling is currently disabled on the Controller." 
    ::= { cLMobilityAnchorGlobalDot11Config 4 }
-- *******************************************************************
-- *    DEFINITION OF OBJECTS ACCESSIBLE FOR NOTIFICATIONS ONLY
-- *******************************************************************
cLMobilityTrapVariables  OBJECT IDENTIFIER
    ::= { ciscoLwappMobilityMIBObjects 3 }


cLMobilityAnchorWlanId OBJECT-TYPE
    SYNTAX          Unsigned32
    MAX-ACCESS      accessible-for-notify
    STATUS          current
    DESCRIPTION
            "This object uniquely identifies one instance of
            a WLAN on the controller." 
    ::= { cLMobilityTrapVariables 1 }

cLMobilityAnchorAddressType OBJECT-TYPE
    SYNTAX          InetAddressType
    MAX-ACCESS      accessible-for-notify
    STATUS          current
    DESCRIPTION     "Guest/Anchor switch Address type." 
    ::= { cLMobilityTrapVariables 2 }

cLMobilityAnchorAddress OBJECT-TYPE
    SYNTAX          InetAddress
    MAX-ACCESS      accessible-for-notify
    STATUS          current
    DESCRIPTION
            "Guest/Anchor switch Address.
            The IP Address is limited to IPv4 and IPv6" 
    ::= { cLMobilityTrapVariables 3 }
-- *******************************************************************
-- * END OF - DEFINITION OF OBJECTS ACCESSIBLE FOR NOTIFICATIONS ONLY
-- *******************************************************************


-- *******************************************************************
-- *    NOTIFICATIONS
-- *******************************************************************


ciscoLwappMobilityAnchorControlPathDown NOTIFICATION-TYPE
    OBJECTS         {
                        cLMobilityAnchorAddressType,
                        cLMobilityAnchorAddress
                    }
    STATUS          current
    DESCRIPTION
            "This trap will be declared by the Controller when,
            successive ICMP ping attempts to the anchor fails 
            and the anchor is conclusively down. 
            Variable cLMobilityAnchorIPAddress denotes the
            IP Address of the anchor."
   ::= { ciscoLwappMobilityMIBNotifs 1 }


ciscoLwappMobilityAnchorControlPathUp NOTIFICATION-TYPE
    OBJECTS         {
                        cLMobilityAnchorAddressType,
                        cLMobilityAnchorAddress
                    }
    STATUS          current
    DESCRIPTION
            "This trap will be declared by the Controller when,
            ICMP ping to the anchor is restored and anchor is 
            conclusively up. 
            Variable cLMobilityAnchorIPAddress denotes the
            IP Address of the anchor."
   ::= { ciscoLwappMobilityMIBNotifs 2 }


ciscoLwappMobilityAnchorDataPathDown NOTIFICATION-TYPE
    OBJECTS         {
                        cLMobilityAnchorAddressType,
                        cLMobilityAnchorAddress
                    }
    STATUS          current
    DESCRIPTION
            "This trap will be declared by the Controller when,
            successive EoIP ping attempts to the anchor fails
            and the anchor is conclusively down. 
            Variable cLMobilityAnchorIPAddress denotes the
            IP Address of the anchor."
   ::= { ciscoLwappMobilityMIBNotifs 3 }


ciscoLwappMobilityAnchorDataPathUp NOTIFICATION-TYPE
    OBJECTS         {
                        cLMobilityAnchorAddressType,
                        cLMobilityAnchorAddress
                    }
    STATUS          current
    DESCRIPTION
            "This trap will be declared by the Controller when,
            EoIP ping to the anchor is restored and anchor is 
            conclusively up. 
            Variable cLMobilityAnchorIPAddress denotes the
            IP Address of the anchor."
   ::= { ciscoLwappMobilityMIBNotifs 4 }


ciscoLwappMobilityAllAnchorsOnWlanDown NOTIFICATION-TYPE
    OBJECTS         { cLMobilityAnchorWlanId }
    STATUS          current
    DESCRIPTION
            "This trap will be declared by the Controller when,
            successive EoIP ping attempts to all the anchors on
            WLAN, denoted by cLMobilityAnchorWlanId, fails and 
            all the anchors are conclusively down."
   ::= { ciscoLwappMobilityMIBNotifs 5 }


ciscoLwappMobilityOneAnchorOnWlanUp NOTIFICATION-TYPE
    OBJECTS         { cLMobilityAnchorWlanId }
    STATUS          current
    DESCRIPTION
            "This trap will be declared by the Controller when,
            successive EoIP and UDP ping to atleast one anchor 
            on the WLAN, denoted by cLMobilityAnchorWlanId, is 
            restored and anchor is conclusively up."
   ::= { ciscoLwappMobilityMIBNotifs 6 }
-- *******************************************************************
-- *   END OF -  NOTIFICATIONS
-- *******************************************************************

-- *******************************************************************
-- *    Compliance statements
-- *******************************************************************
ciscoLwappMobilityMIBCompliances  OBJECT IDENTIFIER
    ::= { ciscoLwappMobilityMIBConform 1 }

ciscoLwappMobilityMIBGroups  OBJECT IDENTIFIER
    ::= { ciscoLwappMobilityMIBConform 2 }


ciscoLwappMobilityMIBCompliance MODULE-COMPLIANCE
    STATUS          current
    DESCRIPTION
            "The compliance statement for the SNMP entities that
            implement the ciscoLwappMobilityMIB module."
    MODULE          -- this module
    MANDATORY-GROUPS {
                        cLNplus1RedundancyRev01ConfigGroup,
                        cLNplus1RedundancyRev01StatusGroup,
                        cLNplus1RedundancyRev01NotifsGroup,
                        cLSymmetricTunnelingRev01ConfigGroup,
                        cLSymmetricTunnelingRev01StatusGroup
                    }
    ::= { ciscoLwappMobilityMIBCompliances 1 }

-- *******************************************************************
-- *    Units of conformance
-- *******************************************************************
cLNplus1RedundancyRev01ConfigGroup OBJECT-GROUP
    OBJECTS         {
                        cLMobilityAnchorGroupKeepAliveNumber,
                        cLMobilityAnchorGroupKeepAliveInterval
                    }
    STATUS          current
    DESCRIPTION
            "This is a collection of objects which can
            configured to control functional parameters 
            of Guest Tunneling N+1 Redundancy feature in 
            CISCO 4400 / 2006 series of WLAN controllers."
    ::= { ciscoLwappMobilityMIBGroups 1 }

cLNplus1RedundancyRev01StatusGroup OBJECT-GROUP
    OBJECTS         {
                        cLMobilityAnchorStatus,
                        cLMobilityAnchorRowStatus,
                        cLMobilityAnchorWlanId,
                        cLMobilityAnchorAddressType,
                        cLMobilityAnchorAddress
                    }
    STATUS          current
    DESCRIPTION
            "This collection of objects represents the information
            about the general status attributes of Guest Tunneling 
            N+1 Redundancy in CISCO 4400 / 2006 series of WLAN 
            controllers."
    ::= { ciscoLwappMobilityMIBGroups 2 }

cLNplus1RedundancyRev01NotifsGroup NOTIFICATION-GROUP
   NOTIFICATIONS    {
                        ciscoLwappMobilityAnchorControlPathDown,
                        ciscoLwappMobilityAnchorControlPathUp,
                        ciscoLwappMobilityAnchorDataPathDown,
                        ciscoLwappMobilityAnchorDataPathUp,
                        ciscoLwappMobilityAllAnchorsOnWlanDown,
                        ciscoLwappMobilityOneAnchorOnWlanUp
                    }
    STATUS          current
    DESCRIPTION
            "This is a collection of notifications about the
            general functional behavior of Guest Tunneling 
            N+1 Redundancy in CISCO 4400 / 2006 series of 
            WLAN controllers."
    ::= { ciscoLwappMobilityMIBGroups 3 }

cLSymmetricTunnelingRev01ConfigGroup OBJECT-GROUP
    OBJECTS         { cLMobilityAnchorSmtStatus }
    STATUS          current
    DESCRIPTION
            "This is a collection of objects which can be
            configured to control functional parameters 
            of Symmetric Mobility Tunneling feature in 
            CISCO 4400 / 2006 series of WLAN controllers."
    ::= { ciscoLwappMobilityMIBGroups 4 }

cLSymmetricTunnelingRev01StatusGroup OBJECT-GROUP
    OBJECTS         { cLMobilityAnchorCurrentSmt }
    STATUS          current
    DESCRIPTION
            "This collection of objects represents the
            information about the general status attributes 
            of Symmetric Mobility Tunneling feature in 
            CISCO 4400 / 2006 series of WLAN controllers."
    ::= { ciscoLwappMobilityMIBGroups 5 }

END



