Cisco Class-Based QoS MIB
        
**********************************
            Overview
**********************************
This MIB provides read access to Quality of Service (QoS) 
configuration and statistics information for Cisco 
platforms that support the Modular Quality of Service 
Command-line Interface (Modular QoS CLI).  We recommend 
users of this MIB to review the user documentation of 
MQC based QoS features.
        
Configuration information available through this MIB includes
all ClassMap, PolicyMap, Match Statements, and Feature 
Actions configuration parameters. The definitions of each
objects mentioned above are explained in the QoS objects
section.
        
Statistics available through this MIB include summary
counts/rates by traffic class before and after any configured
QoS policies are enforced.  In addition, detailed
feature-specific statistics are available for select
PolicyMap features.
        
Contact your Cisco representative to determine on which
platforms the MIB is currently supported.
        
**********************************
           QoS  Acronyms
**********************************
BECN: Frame Relay Backward Explicit Congestion Notification
CIR : Committed Information Rate
DSCP: Differentiated Service Code Point
EB  : Estimate Bandwidth
ECN : Explicite Congestion Notification
FECN: Frame Relay Forward Explicit Congestion Notification
IPHC: Internet Protocol Header Compression 
IPSLAs: IP Service Level Agreement Technologies
PIR : Peak Information Rate
PREC: Precedence
QoS : Quality Of Services
RED : Random Early Detect
SRP : Spatial Reuse Protocol
WRED: Weighted Random Early Detect
C3PL: Cisco Common Classification Programming Language
        
**********************************
            MIB Objects
**********************************
This MIB consists of the following object groups:
1 :  cbQosServicePolicy
2 :  cbQosInterfacePolicy
3 :  cbQosFrameRelayVCPolicy
4 :  cbQosATMPVCPolicy
5 :  cbQosObjects
6 :  cbQosPolicyMapCfg
7 :  cbQosClassMapCfg
8 :  cbQosMatchStmtCfg
9 :  cbQosQueueingCfg
10:  cbQosREDCfg
11:  cbQosREDClassCfg
12:  cbQosPoliceCfg
13:  cbQosTSCfg
14:  cbQosSetCfg
15:  cbQosClassMapStats
16:  cbQosMatchStmtStats
17:  cbQosPoliceStats
18:  cbQosQueueingStats
19:  cbQosTSStats
20:  cbQosREDClassStats
21:  cbQosPoliceActionCfg
22:  cbQosIPHCCfg
23:  cbQosIPHCStats
24:  cbQosSetStats
25:  cbQosPoliceColorStats
26:  cbQosTableMapCfg
27:  cbQosTableMapValueCfg
28:  cbQosTableMapSetCfg
29:  cbQosEBCfg
30:  cbQosEBStats
31:  cbQosMeasureIPSLACfg
32:  cbQosC3plAccountCfg
33:  cbQosC3plAccountStats
        
**********************************
          Definitions
**********************************
A logical interface in the context of this MIB is either
a main-interface, a sub-interface, a Frame Relay DLCI,
an ATM virtual circuit or the control-plane on the router.
        
The (aggregate) control-plane on the router is defined as 
a collection of processes running at process level on the
platform (route) processor. This includes the functions 
related to networking control capabilities such as routing,
signaling, provisioning, as well as resource and service 
discovery. Also includes process switched traffic on the
device. 
        
The term distributed control plane, in the context of 
this mib, represents the control-plane functionality at
the level of individual linecards. This is only
applicable for the case of distributed platforms.
        
**********************************
           QoS Objects
**********************************
To understand Class-Based QoS features and how to navigate 
the MIB tables above, the key element is to comprehend the 
relationships among the different QoS objects. QoS objects 
consist of ClassMaps, Match Statements and PolicyMaps, 
and each Feature Actions. 
        
Match Statement - The specific match criteria to identify
packets for classification purposes.
        
ClassMap - A user-defined traffic class that contains
one or many match statements used to classify packets into
different categories.
        
Feature Action - An action is a QoS feature. Features 
include police, traffic-shaping, queueing, random detect 
and packet marking(set). After the traffic is being 
classified, based on the traffic classification, we can 
apply these action to each traffic class.
        
PolicyMap - A user-defined policy that associates each QoS 
action to the user-defined traffic class (ClassMap).
        
Service Policy - Service policy is a policymap
that is being attached to a logical interface. Because a
policymap can also be a part of the hierarchical structure 
(inside a classmap), only a policymap that is directly 
attached to a logical interface is considered a service 
policy.  Each service policy is uniquely identified by an 
index called cbQosPolicyIndex. This number is usually 
identical to its cbQosObjectsIndex as a policymap.
        
*****************************************
Runtime Instance vs Configuration objects
*****************************************
        
Each QoS objects have 2 sets of behaviours : 
1: A configuration instance
- Each QoS objects has it's configuration portion of
  information attached to it. This information does
  not change whether this object is attached on multiple
  logical interfaces and used multiple times. We
  uniquely identify each QoS object with identical
  configuration with the same index - cbQosConfigIndex.
  This index is used in all configuration related
  tables. 
        
2: A runtime instance
- Each QoS objects has it's statistical portion of
  information attached to it. This information changes
  when this object is attached on multiple logical 
  interfaces and used in various different places. We
  uniquely identify each QoS runtime object instance 
  with an index that is unique across multiple 
  instances of the identical object - cbQosObjectsIndex.
  This index is used in all statistical related tables. 
        
In summary, a QoS object has 2 indexes associated with it:
cbQosConfigIndex is used to identify it's configuration, 
which does not change regardless of number of times and
where it is being used; and cbQosObjectsIndex is used 
to identify it's runtime statistics, depending on which
logical interface and where in a given PolicyMap hierarchy
this object is used, it may have multiple unique 
identifiers to distinguish each unique usage (instance) of
the same object.
        
**********************************
            Navigation
**********************************
The recommended method of navigating through all of the MIB 
tables is to start by learning the cbQosServicePolicyTable 
and cbQosObjectsTable MIB tables. In particular, Cisco 
Systems recommends understanding the cbQosObjectsIndex and 
cbQosParentObjectsIndex of each QoS feature.
        
The cbQosPolicyIndex and cbQosObjectsIndex are 
system-assigned numbers that identify each unique instance 
of a QoS feature. These indexes are never reused between 
router reboots, even when changes are made to the QoS 
configuration. The cbQosPolicyIndex is designed to identify 
the service policies attached to logical interfaces, while 
the cbQosObjectsIndex is designed to identify each QoS 
feature on a specified device.
        
The cbQosParentObjectsIndex is designed to show the 
hierarchical relationship of each QoS feature. 
        
**********************************
        cbQosServicePolicyTable
**********************************
Accessing cbQosServicePolicyTable requires 
cbQosPolicyIndex. This index is a system-assigned number 
to uniquely identify each service policy hanging off of
each logical interface. Given cbQosPolicyIndex the tables
provide the type of logical interface/media type on which
this policy is applied, the direction in which this policy
is enforced, and the SNMP interface index and/or the entity
index of the underlying interface/entity. In the case of a
policy being applied on a Frame Relay DLCI, the cbQosFrDLCI
gives you the Frame Relay DLCI number to which this policy
is attached. In the case of policy being attached to an ATM
VC, cbQosAtmVPI and cbQosAtmVCI display the VPI and VCI of 
the ATM interface respectively.
        
**********************************
        cbQosObjectsTable
**********************************
Accessing cbQosObjectsTable requires two indexes, 
cbQosPolicyIndex and cbQosObjectsIndex. 
        
Given a particular service policy on a given logical 
interface, there could be PolicyMaps, ClassMaps, Match 
Statements and Feature Actions being used. Each instance 
of these objects is uniquely identified by
cbQosObjectsIndex.
        
Users need to decide which QoS object is interesting 
and use the cbQosPolicyIndex and cbQosObjectsIndex to
locate the right element of interest. This tables provides 
cbQosObjectsType, cbQosConfigIndex, and 
cbQosParentObjectsIndex. 
        
To understand the relationship of cbQosObjectsIndex, 
cbQosParentObjectsIndex and the hierarchical relationship 
of the QoS objects, consider the following QoS 
configuration example:
        
Interface ethernet 0/1
Input Service Policy cntlWebTraffic
        ClassMap http
                match ip http
                set ip precedence 5
        
Output Service Policy cntlSNMP_Telnet
        ClassMap snmp
                match ip snmp
                shape average 8000 32 32
        ClassMap Telnet
                match ip telnet
                shape average 10000 32 32
        
Interface ethernet 0/2
Input Service Policy cntlWebTraffic
        ClassMap http
                match ip http
                set ip precedence 5
        
Output Service Policy cntlSNMP_Telnet
        ClassMap snmp
                match ip snmp
                shape average 8000 32 32
        ClassMap Telnet
                match ip telnet
                shape average 10000 32 32
        
*** In Ethernet 0/1 ***
Assume the router assigned a cbQosConfigIndex=1024 and 
cbQosObjectsIndex=1084 to Policy cntlWebTraffic. 
Because it is attached to an interface, it has no parent 
QoS object, and thus cbQosParentObjectsIndex=0. 
In addition, because cntlWebTraffic is also the service 
policy of the interface, it has a unique cbQosPolicyIndex 
assigned to it. In most cases, it would be the same as 
the cbQosObjectsIndex, which is 1084 in this case. 
Therefore, the indexes are:
cbQosPolicyIndex = 1084
cbQosObjectsIndex = 1084
cbQosConfigIndex = 1024
        
Assuming the router assigned a cbQosObjectsIndex=1085 
and cbQosConfigIndex=1025 to ClassMap http, it is 
directly being used by Policy cntlWebTraffic, and therefore
the cbQosParentObjectsIndex of ClassMap http will be 1084. 
        
Assuming the router assigned a cbQosConfigIndex=1026 and
cbQosObjectsIndex=1086 to match ip http, it is directly 
used by ClassMap http, therefore the 
cbQosParentObjectsIndex of match ip http will be 1085.
        
Assuming the router assigned a cbQosConfigIndex=1027 and
cbQosObjectsIndex=1087 to set ip precedence 5, it is 
directly used by ClassMap http, therefore the 
cbQosParentObjectsIndex of match ip http will be 1085.
        
Assuming the router assigned a cbQosConfigIndex=1028 and 
cbQosObjectsIndex=1088 to Policy cntlSNMP_Telnet. 
Because it is attached to an interface, it has no parent 
QoS object, and thus cbQosParentObjectsIndex=0. 
In addition, because cntlSNMP_Telnet is also the service 
policy of the interface, it has a unique cbQosPolicyIndex 
assigned to it. In most cases, it would be the same as 
the cbQosObjectsIndex, which is 1088 in this case.
        
Assuming the router assigned a cbQosConfigIndex=1029 and
cbQosObjectsIndex=1089 to ClassMap snmp, it is 
directly being used by Policy cntlSNMP_Telnet, and 
therefore the cbQosParentObjectsIndex of ClassMap snmp 
will be 1088. 
        
Assuming the router assigned a cbQosConfigIndex=1030 and
cbQosObjectsIndex=1090 to match ip snmp, it is directly 
used by ClassMap snmp, and therefore the 
cbQosParentObjectsIndex of match ip snmp will be 1089.
        
Assuming the router assigned a cbQosConfigIndex=1031 and
cbQosObjectsIndex=1091 to shape average 8000 32 32, 
it is directly used by ClassMap snmp, therefore the 
cbQosParentObjectsIndex of match ip snmp will be 1089.
        
Assuming the router assigned a cbQosConfigIndex=1032 and
cbQosObjectsIndex=1092 to ClassMap Telnet, it is 
directly being used by Policy cntlSNMP_Telnet, and 
therefore the cbQosParentObjectsIndex of 
ClassMap Telnet will be 1088. 
        
Assuming the router assigned a cbQosConfigIndex=1033 and
cbQosObjectsIndex=1093 to match ip telnet, it is 
directly used by ClassMap Telnet, and therefore the 
cbQosParentObjectsIndex of match ip telnet will be 1092.
        
Assuming the router assigned a cbQosConfigIndex=1034 and
cbQosObjectsIndex=1094 to shape 10000 32 32, it is 
directly used by ClassMap telnet, therefore the 
cbQosParentObjectsIndex of match ip telnet will be 1092.
        
*** In Ethernet 0/2 ***
Every objects will have a unique combination of
cbQosPolicyIndex and cbQosObjectsIndex, but
cbQosConfigIndex will be shared across the same
objects that are applied in different places.
        
**********************************
         All Config Tables
**********************************
Accessing config related tables requires the same index 
- cbQosConfigIndex.  (Per precedence based tables requires 
a second index, which is IP precedence value) Users 
should have already gone through the cbQosObjectsTable 
at this point and understood each cbQosConfigIndex and the 
corresponding QoS objects.  Users can uniquely identify 
each QoS object defined on the router and query the 
entries in each stats table on a per QoS object basis.  
        
**********************************
         All Stats Tables
**********************************
Accessing all stats related tables requires the same 
2 indexes. They are cbQosPolicyIndex and cbQosObjectsIndex.
(Per precedence based tables requires a third index, which 
is IP precedence value) Users should have already gone 
through the cbQosObjectsTable at this point and understood 
the relationship of each cbQosPolicyIndex and 
cbQosObjectsIndex pair and the corresponding QoS objects. 
Users can uniquely identify each QoS object defined on the 
router and query the entries in each stats table on a per 
QoS object basis.