A single SNMP agent sometimes needs to support multiple instances of the same MIB module, and does so through the use of multiple SNMP contexts. This typically occurs because the technology has evolved to have extra dimension(s), i.e., one or more extra data and/or identifier values which are different in the different contexts, but were not defined in INDEX clause(s) of the original MIB module. In such cases, network management applications need to know the specific data/identifier values in each context, and this MIB module provides mapping tables which contain that information. Within a network there can be multiple Virtual Private Networks (VPNs) configured using Virtual Routing and Forwarding Instances (VRFs). Within a VPN there can be multiple topologies when Multi-topology Routing (MTR) is used. Also, Interior Gateway Protocols (IGPs) can have multiple protocol instances running on the device. A network can have multiple broadcast domains configured using Bridge Domain Identifiers. With MTR routing, VRFs, and Bridge domains, a router now needs to support multiple instances of several existing MIB modules, and this can be achieved if the router's SNMP agent provides access to each instance of the same MIB module via a different SNMP context (see Section 3.1.1 of RFC 3411). For MTR routing, VRFs, and Bridge domains, a different SNMP context is needed depending on one or more of the following: the VRF, the topology-identifier, the routing protocol instance, and the bridge domain identifier. In other words, the router's management information can be accessed through multiple SNMP contexts where each such context represents a specific VRF, a specific topology-identifier, a specific routing protocol instance and/or a bridge domain identifier. This MIB module provides a mapping of each such SNMP context to the corresponding VRF, the corresponding topology, the corresponding routing protocol instance, and the corresponding bridge domain identifier. Some SNMP contexts are independent of VRFs, independent of a topology, independent of a routing protocol instance, or independent of a bridge domain and in such a case, the mapping is to the zero length string. With the Cisco package licensing strategy, the features available in the image are grouped into multiple packages and each packages can be managed to operate at different feature levels based on the available license. This MIB module provides option to associate an SNMP context to a feature package group. This will allow manageability of license MIB objects specific to a feature package group. As technology evolves more we may need additional identifiers to identify the context. Then we would need to add those additional identifiers into the mapping.