.pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Kanada, et al. .ds RF PUTFFHERE[Page %] .ds CF .ds LH draft-kanada-diffserv-qospifmib-00.txt .ds RH November 1999 .ds CH .hy 0 .ad l .ta 8 16 24 32 40 48 56 64 .nf 0 Internet Draft Y. Kanada Expiration Date: April 2000 M. Ikezawa File: draft-kanada-diffserv-qospifmib-00.txt S. Miyake Y. Atarashi Hitachi, Ltd. October 1999 .ce SNMP-based QoS Programming Interface MIB for Routers .ce .ti 0 Status of this Memo .fi .in 3 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. .ti 0 Copyright Notice .fi .in 3 Copyright (C) The Internet Society (1999). All Rights Reserved. .ti 0 Abstract .fi .in 3 This document describes a QoS PIF MIB (Quality-of-Service Programming-Interface Management-Information-Base) to be used as an SNMP-based programming interface for routers. This MIB is intended to be a programming interface for router QoS functions, especially DiffServ-related [RFC2475] functions including packet scheduling (queuing), dropping, and metering that must be modular and concisely described. Traffic-conditioning rules and metering rules for DiffServ-related functions are defined modularly by using "virtual flow labels" and exclusive conditions in rules, and new classifications for packet-scheduling and packet-dropping functions are introduced. This document focuses on satisfying the requirements on programming interfaces or programming languages for router control. Thus, the focus is different from that of DiffServ MIB [DSMIB] or QoS PIB [QoSPIB]. .ti 0 1. Glossary .in 3 .nf AF Assured Service. API Applications Programming Interface. BA Classifier Basic Aggregate Classifier. CBQ Class-Based Queuing. COPS Common Open Policy Services. DED Deterministic Early Drop. DiffServ Differentiated Services. DS Field Differentiated Services Field. DSCP Differentiated Services Code Point. FIFO First-In First-Out. MF Classifier Multi-Field Classifier. MIB Management Information Base. PDP Policy Definition Point. PHB Per-Hop Behavior. PIB Policy Information Base. PRC Policy Rule Class. QoS Quality of Services. QoS PIF MIB QoS Programming-Interface MIB. RED Random Early Drop. SLA Service Level Agreements. SMI Structure of Management Information. SNMP Simple Network Management Protocol. TCB Traffic Control Block. VFL Virtual Flow Label. WDED Weighted Deterministic Early Drop. WFQ Weighted Fair Queuing. WRED Weighted Random Early Drop. .ti 0 2. Introduction .fi .in 3 Routers and other network nodes are becoming more customizable and programmable; thus, they will be used as the nodes of "Active Networks" [IWAN99]. Routers, especially QoS-ready routers, will be controlled by a set of if-then rules (or policy rules, such as traffic-conditioning rules or metering rules), that is actually a type of computer program. Although the function of a rule sets is currently restricted to QoS-related functions, the rule set can be expanded to a general-purpose computer program. The rule set is similar to a "production system" used for modeling human cognition in Artificial Intelligence or as expert systems in Knowledge Engineering, although it differs in that the policy-rule programs are mostly stateless. The program can be expressed using a (programming) language such as a command language, or using an API (applications programming interface). It can also be expressed using conventional network management interfaces such as MIB with SNMP, or using PIB with COPS [COPS]. Although each language has its own limitations, the nature of the programming interface does not strongly depend on the language. This document describes a programming interface using SNMP-MIB. A programming interface that uses an API will be proposed to both IETF and IEEE P1520 Working Group. A preliminary version of the API is available [IP-009]. This document makes the following two contributions. .in 6 First, means to make policy rules modular are proposed. For a programming interface, modularity is an important property for rules to have, because they are often added, modified, or removed while the router is running. This is quite different from conventional programs (but is similar to learning AI programs). The following two means are used. One means is use of a "virtual flow label" (VFL). The VFL is introduced to make the rules, especially metering rules, modular. A VFL is something like a virtual DSCP (Differentiated Services Code Point). However, the number of available labels, which is only 64 in the case of DSCP, is almost unlimited. By using VFL, <> links (pointers), such as those used in DiffServ MIB [DSMIB] are replaced by VFLs, which are data, and the program is decomposed into modular rules. The other mean is exclusive (i.e., disjoint) conditions in rules. Conventional "policy rules" are not necessarily modular, because they have "if-then-else" semantics. For example, if rule C is added between rules A and B, the condition of rule C is changed because of the interference between rules B and C. This dependence can be avoided if the conditions (the "if" part) of rules are exclusive. So the language for defining the conditions must be sufficiently powerful to describe exclusive conditions, and exclusiveness should be required by the programming interface. If conditions are made exclusive, parallel evaluation of rules also becomes possible. Second, new classifications for packet-scheduling and packet-dropping algorithms are introduced. Packet-dropping methods and queueing methods are specified using these algorithms, and are specified separately from actions on packets. Thus, there is no need to specify identical dropping or queuing methods more than once. .in 3 The purpose of QoS PIF MIB is different from that of DiffServ MIB [DSMIB] or QoS PIB [QoSPIB]. DiffServ MIB is a lower-level model of routers and it relies on conventional network management framework (See Section 3). QoS PIB focuses on QoS policy provisioning using COPS. QoS PIF MIB is intended to be a programming interface, so we focus on solving diffitulties in <> routers. Thus, they have different focuses, although they are closely related. This MIB is presented in a closed form, i.e., in a form of a single MIB without any direct relationship to previously proposed MIBs or PIBs, because we believe we can best express our ideas clearly and concisely in this single MIB. .ti 0 3. The SNMP Management Framework .fi .in 3 The SNMP Management Framework presently consists of five major components: 1) An overall architecture, described in RFC 2571 [RFC2571]. 2) Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in RFC 1155 [RFC1155], RFC 1212 [RFC1212], and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in RFC 2578 [RFC2578], RFC 2579 [RFC2579], and RFC 2580 [RFC2580]. 3) Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in RFC 1157 [RFC1157]. The second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [RFC1906], RFC 2572 [RFC2572], and RFC 2574 [RFC2574]. 4) Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. 5) A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. 6) A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. 7) Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. .ti 0 4. Conceptual Model of QoS-ready Routers A conceptual model of QoS-ready routers (Figure 1) is explained here to provide a context for the overall structure of the MIB explained in the following sections. This model is similar to those described in the DiffServ router model draft [DSModel] or in the DiffServ MIB draft [DSMIB], but the scheduling and dropping functions are different. In this conceptual model, a router consists of a switch fabric (and/or routing processor) and two or more network interfaces. The interfaces are connected to the switch fabric and one or more lines, and each interface consists of an inbound unit (called an ingress component in the draft of the DiffServ router model [DSModel]) and an outbound unit (called an egress component in the draft [DSModel]). +-----------------------------------------------------------+ | Router | | | | Logical interface Switch fabric Logical interface | | +-----------------+(Routing processor)+-----------------+ | | | | +-------+ | | | | | +-------------+ | |\\ /| | +-------------+ | | ------>|Inbound unit |------>| \\ / |<------|Inbound unit |<------ | | +-------------+ | | \\ / | | +-------------+ | | | | | | X | | | | | | +-------------+ | | / \\ | | +-------------+ | | <------|Outbound unit|<------| / \\ |------>|Outbound unit|------> | | +-------------+ | |/ \\| | +-------------+ | | | | | +-------+ | | | | +-----------------+ +-----------------+ | | | +-----------------------------------------------------------+ Figure 1 Conceptual model of a QoS-ready router An interface may be a physical port, or a logical interface. Logical interfaces may share a single physical port, i.e., a physical port may be partitioned into two or more logical interfaces, but resources that relate to each logical interface must be controlled by the logical interface. Two logical interfaces bound to a physical port may have different resource states, such as queuing algorithms or classifiers. Routers are often categorized into ingress, core and egress routers. However, no such distinction exists in this model. Instead, logical interfaces can be categorized into exterior or interior interfaces. An exterior interface is connected to an end point, a router, or another type of network device in another domain. An interior interface is connected to another router or another type of network device in the same domain. Each inbound/outbound unit has three subunits: a control unit, a condition unit, and an action unit (Figure 2). The control unit contains lists of if-then rules (policy rules), which are programs to control the condition and action units. Rules are classified into three classes, i.e., classifier, metering, and action rule classes, in this MIB. The policy-rule storage may be shared between inbound and outbound units, or by all the interfaces. All the policy-rule storage components in a router are assumed to have the same set of rules and a control unit uses a subset of these rules. +-----------------------------------------------------------+ | Inbound/outbound unit | | +---------------+ | | +--------------------+ | Policy rule | | | | Control unit |--| storage | | | +--------------------+ |(if-then rules)| | | | | +---------------+ | | | v | | | +---------------------------+ | | v | Action unit | | | +-------------------------+ | (Traffic control block) | | | | Condition unit | | +--------+ | | | | | | +-->|Droppers|<---+ | | | | +-----------+ +------+ | | | +--------+ | | | ------>|Classifiers|->|Meters|-----+ | | | | | +-----------+ +------+ | | | +-------+ +---------+ | | | | | | +->|Markers|->|Scheduler|------> | +-------------------------+ | +-------+ +---------+ | | | | (Queues) | | | +---------------------------+ | | | +-----------------------------------------------------------+ Figure 2 The structure of an inbound/outbound unit of the router The condition unit contains classifiers and meters. The classifiers classify packets according to the classifier rules supplied by the control unit, and assign a VFL that indicates the packet class. The classifiers classify packets by the protocol, source address and port, destination address and port, DSCP [RFC2474], and so on, which are in the packet header. A VFL is similar to a DSCP. However, it is internal to a router, and the number of VFLs can be much more than the number of DSCPs, i.e., 64. The meters work on a virtual flow (a virtual stream) of packets. Each meter contains a flow condition that applies to a stream of packets, each of which belongs to a class defined by a classifier or another meter. The meter counts the number of packets or the number of bytes (bandwidth) in a queue, or tests conformity with a leaky/token bucket condition, or other conditions on a stream. If the condition supplied by the meter meets (or does not meet), a VFL that indicates the conformity (or violation) is assigned to the packet. The action unit, which can also be called the traffic-control block (TCB), consists of markers, droppers, and a scheduler that contains queues. A marker rewrites the DSCP according to the condition outputted by the condition unit. A dropper drops packets when a metering condition is violated or when the scheduler decides to drop packets. The scheduler buffers packets, and outputs them to the line using queues. The scheduler drops a packet that overflows from the queue, if the VFL of the packet meets an early drop condition. For example, if assured-forwarding per-hop behaviors (AF PHBs) [RFC2597] of the differential services model are implemented on the router, a queue must support multiple drop conditions. Early drop conditions enable this. Both deterministic drop and random early drop (RED) methods [RFC2309] are supported by this MIB. .ti 0 5. Structure of QoS PIF MIB .fi .in 3 The QoS PIF MIB consists of four parts: the QoS-capability part, the queue-setting part, the packet-dropping-method part, and policy-rule-definition part. The first three are defined for whole router, and the last one is defined for each logical interface. .in 3 1) QoS-capability part .in 6 This part specifies the QoS-related capability of the router. It advertises possible queuing algorithms, packet dropping algorithms, and so on to the manager. A manager, such as a policy server, may use the information from this part to determine the ability of the router. This part corresponds to a policy-rule-class (PRC) support table in the QoS PIB [QoSPIB]. However, the description level of this part is lower than the PRC table and the descriptions are independent of specific policy management systems. .in 3 2) Queue-setting part .in 6 This part specifies the QoS-related settings of the scheduler and the scheduling queues in the logical interfaces of the router. If an algorithm or value that is not allowed in the QoS capability part is specified, an error is returned. .in 3 3) Packet-dropping-method part .in 6 This part specifies methods of dropping packets in the event of congestion. Deterministic or random early drop, or no early drop, may be specified. These methods are used in action rules that are specified in the policy-rule part. This part does not directly specify dropping actions. That packet-dropping methods are specified separately from both the rule actions and the queuing method is a distinct feature of this MIB. .in 3 4) Policy-rule part .in 6 This part defines policy rules for each router interface. Classifier, meter, and action rules are separately specified. If a dropping method that is not allowed in the packet-dropping-method part is specified, an error is returned. .ti 0 6. QoS Capability .fi .in 3 Various routers have been developed by many vendors. The capability related to QoS control also varies. Thus, the manager of this MIB, or PIB that is converted from of this MIB (see Section 10), i.e., a policy server or PDP in COPS [COPS], must know the QoS-related capability of the router. The QoS-capability part of this MIB defines it. This part contains the set of queuing methods and packet-dropping methods that the router has. The available scheduling algorithms are explained in Section 7, and the available dropping methods are explained in Section 8. The relationship between the content of this part of the MIB and the information to be transmitted to the policy server is discussed in Section 10. .ti 0 7. Scheduling Methods .fi .in 3 The scheduling-methods table consists of method definitions for scheduling packets. A scheduling method contains a scheduling algorithm, selected from the algorithms defined in the QoS-capability part of this MIB, and parameters for the algorithm. This table makes it unnecessary to specify identical scheduling methods more than once. The available scheduling algorithms are as follows. .in 3 1) First-in first-out (FIFO) scheduling .in 6 All packets are enqueued into a single queue in this algorithm. The order of dequeuing packets is exactly the same as the order of enqueuing them. .in 3 2) Priority scheduling .in 6 Packets are enqueued into two or more queues according to their priority classes represented by the VFL. Higher priority packets are always dequeued earlier. .in 3 3) Packet-fair scheduling .in 6 Packets are enqueued into two or more queues according to their VFLs. This scheduling algorithm is fair for each queue in terms of packets. Weights can be defined for each queue, if the weighted packet-fair scheduling flag is turned on in the QoS-capability part. For example, packets may be dequeued according to a (weighted) packet-by-packet round-robin algorithm when this algorithm is used. .in 3 4) Byte-fair scheduling .in 6 Packets are enqueued into two or more queues according to their VFLs. The scheduling algorithm is fair for each queue in terms of packet lengths. Weights can be defined for each queue, if the weighted byte-fair scheduling flag is turned on in the QoS capability part. For example, packet-fair scheduling is used in the fair-queuing or weighted-fair-queuing (WFQ) algorithm. .in 3 5) Bounded byte-fair scheduling .in 6 Packets are enqueued into two or more queues according to their VFLs. The scheduling algorithm is fair for each queue in terms of packet lengths. However, the bandwidth is limited for each queue. The sum of the specified bandwidths must be equal to or smaller than the bandwidth of the line. If the sum is less than the bandwidth of the line, or one or more queues do not fully use their specified bandwidth, the rest of the bandwidth may be reshared among the queues, or may be occupied by the highest-priority queue. The algorithm for using the remaining bandwidth is implementation-dependent. (The detailed algorithm may be specified in a vendor-specific MIB.) For example, bounded byte-fair scheduling will be used for implementing or simulating the class-based queuing (CBQ) [Floyd95]. .in 3 If the router has two or more scheduling methods that belong to the same category above, they can be distinguished by setting a non-zero value to qosDropSubAlgorithm. Queuing methods, such as CBQ or WFQ, cannot be directly specified in the scheduling-method part of the MIB, because such methods are regarded as a combination of a scheduling algorithm and higher-level control that will be implemented using other functions defined in this MIB. It is difficult to specify a specific high-level queuing algorithm in a standardized MIB, because a very wide variety of queuing algorithms have been, and will probably continue to be, implemented in routers. Thus, high-level queuing algorithms should be implemented or simulated using this MIB. .ti 0 8. Packet-dropping methods .fi .in 3 The dropping-method table consists of method definitions for dropping packets. A dropping method contains a dropping algorithm, which is selected from the algorithms defined in the QoS-capability part of this MIB, and parameters for the algorithm. This table makes it unnecessary to specify the identical dropping methods more than once. Available dropping algorithms are as follows. .in 3 1) Dropping all .in 6 All the packets in the virtual flow are dropped. For example, this algorithm is used when the flow is without service-level agreements (SLA) or violates an SLA. This algorithm is a special case for the deterministic early dropping (4). .in 3 2) Tail dropping (non-early dropping) .in 6 Packets are dropped only when the queue is filled. This is the default algorithm and all routers must support this. Thus, no capability flag exists for this algorithm in the QoS-capability part. This algorithm is also a special case for the deterministic early dropping (4). .in 3 3) Random early dropping (RED/WRED) .in 6 Packets are dropped when a specified proportion of the queue is filled. The packets to be dropped are selected at random. The proportion at which some packets start to be dropped, and the minimum proportion above which all incoming packets are dropped are specified as parameters. .in 3 4) Deterministic early dropping (DED/WDED) .in 6 Packets are dropped when a specified proportion of the queue is filled. All the packets are dropped in this case, or the packets to be dropped are selected by a deterministic method. The same parameters as for RED are used in this method. .in 3 The parameters for RED and DED are defined as a value between 0 and 1000 per mil. If a parameter is not specified, its value is 1000. The dropping-method table contains a list of dropping methods available from the policy rules. Each policy rule may specify a dropping method as an action. AF PHBs can be implemented using weighted DED or RED. .ti 0 9. Policy Rules .fi .in 3 Policy rules are defined using three conceptual tables: the classifier table, the metering-rule table, and the action table. Policy rules are expressed using these three separate rule tables because policy rules, including metering conditions, should be expressed as a collection of disjoint if-then rules. Policy rules must be modular, so the order of rules should be insignificant. This means that rules must be easy to add or remove from a policy, i.e., a set of policy rules. Although a decision-tree, such as one in the DiffServ MIB [DSMIB], is easier to implement in a software router in which a von-Neumann-type CPU meters traffics, it may not be necessarily easier in a hardware router, and a decision-tree does not meet the modularity requirements. The policy rule architecture is shown in Figure 3. A classifier defined in the classifier table assigns a VFL to a packet flow. Meters defined in the metering-rule table and actions defined in the action table work only on a flow specified by the VFL in the rules. A meter replaces the VFL when the metering rule condition holds. If no meter is needed, the output of a classifier can be input to an action, and if more than one meters are needed, an output from a meter can be input to another meter. (The box "others" in Figure 3 actually does nothing.) Another example, using two-stage meters is shown in Figure 4. The flow is classified to VFL1 by Classifier 1. If no metering condition is met in the first stage, VFL1 is not changed by "others", and Action 1 is applied. If a metering condition is met, the flows are marked by labels VFL11 to VFL1N, and all the flows are again tested by the metering conditions. The same set of meters is applied. If no more metering conditions are met in this second stage, the VFL is not changed by "others", and an action from Action 11 to Action 1N is applied to each flow. If a metering condition meets, the flow is marked by one of labels VFL21 to VFL2M, and an action from Action 21 to Action 2M is applied. +-----------------------------------------------------------+ | Policy rule 1 | | + - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | : +-----------+ VFL1 +---------+VFL11+----------+ : | | +-->|Classifier1|--+-->| Meter11 |---->| Action11 |--+ : | | | : +-----------+ | +---------+ +----------+ | : | | | : | +---------+VFL12+----------+ | : | | | : +-->| Meter12 |---->| Action12 |--+ : | | | : | +---------+ +----------+ | : | | | : | ... ... | : | | | : | +---------+VFL1 +----------+ | : | | | : +-->| others |---->| Action1 |--+ : | | | : +---------+ +----------+ | : | | | + - - - - - - - - - - - - - - - - - - - - - - - - -|-+ | | | | | ----->| ... ... ... +------> | | | | | | Policy rule N | | | | + - - - - - - - - - - - - - - - - - - - - - - - - -|-+ | | | : +-----------+ VFLN +---------+VFLN1+----------+ | : | | +-->|ClassifierN|--+-->| MeterN1 |---->| ActionN1 |--+ : | | : +-----------+ | +---------+ +----------+ | : | | : | +---------+VFLN2+----------+ | : | | : +-->| MeterN2 |---->| ActionN2 |--+ : | | : | +---------+ +----------+ | : | | : | ... ... | : | | : | +---------+VFLN +----------+ | : | | : +-->| others |---->| ActionN |--+ : | | : +---------+ +----------+ : | | + - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | | +-----------------------------------------------------------+ Figure 3 Policy-rule architecture In these three tables, one or several unit conditions must be left unspecified in most cases. However, in SMI [SMIv2], in contrast to the original ASN.1 notation [ASN.1], no selection structure can be expressed. Thus, a unified unspecified value, -1, was used as the default value for most of the conditions. For example, the default value of the protocol, the DSCP, and the minimum and maximum packet length in the classifier rules is -1, and that of the queue precedence, the dropping method, and the updated DSCP in the action rules is also -1. However, the IP addresses and their masks cannot have a value of -1, so their "unspecified" and default values are different, because negative numbers are not allowed in IpAddress, which is a predefined textual convention. A policy, i.e., a list of policy rules, is assgined to each role-combination, instead of to each logical interface, in the policy framework [Policy]. A role-combination can be represented by a policy table in this MIB. When a packet arrives at a logical interface, only the conditions in the classifiers linked from the rule-list table of the interface are tested. +-----------------------------------------------------------+ | +-----------+ | ----->|Classifier1| | | +-----------+ | | |VFL1 | | | | | | +--------+VFL11 +--------+VFL111+---------+ | | +-->|Meter11 |---+-->|Meter111|----->|Action111|--+ | | | +--------+ | +--------+ +---------+ | | | | | ... ... | | | | | +--------+VFL11M+---------+ | | | | +-->|Meter11M|----->|Action11M|--+ | | | | +--------+ +---------+ | | | | | +--------+VFL11 +---------+ | | | | +-->| Others |----->|Action11 |--+ | | | +--------+ +---------+ | | | | ... | | | | | | | | +--------+VFL1N +--------+VFL1N1+---------+ | | | +-->|Meter1N |---+-->|Meter1N1|----->|Action1N1|--+ | | | +--------+ | +--------+ +---------+ | | | | | ... ... | | | | | +--------+VFL1NL+---------+ | | | | +-->|Meter1NL|----->|Action1NL|--+ | | | | +--------+ +---------+ | | | | | +--------+VFL1N +---------+ | | | | +-->| Others |----->|Action1N |--+ | | | +--------+ +---------+ | | | | | | | | +--------+VFL1 VFL1 +---------+ | | | +-->| Others |---------------------->|Action1 |--+-----> | +--------+ +---------+ | | | | ... | | | +-----------------------------------------------------------+ Figure 4 Example of an architecture with two-stage meters .ti 0 9.1 Classifier table .fi .in 3 The classifier table consists of classifiers that can test data in an IP header or another part of the packet. If the test condition is for the protocol, the source IP address and/or port, or the destination IP address and/or port, the classifier is called a multi-field (MF) classifier. If the test condition is only for the DS field, the classifier is called a basic aggregate (BA) classifier. An MF classifier can also test the DS field. MF and BA classifiers are put in the same table, unlike with the DiffServ MIB, because the order of the classifiers is sometimes significant, and because the simplest way to express the classifier order is by the order in the table. When a flow can be matched to both an MF and a BA classifiers, the flow is matched to whichever classifier is first in the table. Classifier examples are shown: C1: if (source_ip == 192.168.1.*) VFL = 1000; C2: if (DSCP == 64) VFL = 64; A classifier assigns a VFL to a microflow or an aggregated flow. Two or more classifiers may assign the same VFL. Then, the conditions represented by these classifiers are "or"ed. For example, classifier C3, which cannot be expressed directly in this MIB, can be expressed by classifiers C31 and C32: C3: if (source_ip == 192.168.1.* || source_ip == 192.168.3.*) VFL = 1000; // Caonnot be expressed. C31: if (source_ip == 192.168.1.*) VFL = 1000; .br C32: if (source_ip == 192.168.3.*) VFL = 1000; This notation simplifies the representation of disjunctive conditions expressed by the SMI [SMIv2]. There is only one classifier table in a router. The classifiers are selected and ordered for each logical interface by the policy table. .ti 0 9.2 Metering-rule table .fi .in 3 The metering rule-table consists of metering rules that apply to a virtual flow defined by a classifier or another metering rule, and assigns a new VFL to a virtual flow that consists of packets matching the metering condition. The VFL of packets that do not match the metering condition is not changed. All the entries of the metering-rule table in which the same VFL is specified are applied sequentially (in logic) to the flow that has the VFL. For example, the following classifier and metering rules are given. C1: if (source_ip = 192.168.1.*) VFL = 1000; .br M1: if (VFL == 1000 && 2 Mbps < committed_rate) VFL = 1500; .br M2: if (VFL == 1000 && 1 Mbps < committed_rate && committed_rate <= 2 Mbp) VFL = 1501; The meaning of the above set of rules is equivalent to the following program. .nf if (source_ip = 192.168.1.*) { VFL = 1000; if (VFL == 1000 && bandwidth > 2 Mbps) { VFL = 1500; ... (1) }; if (VFL == 1000 && 1 Mbps < committed_rate && committed_rate <= 2 Mbps) { VFL = 1501; ... (2) }; ... (3) }; .fi However, the order of rules M1 and M2 is not significant, and the conditions of the meters on the same VFL must be disjoint. The conditions of the metering rules are conjunctive. If the VFL is not rewritten, all the metering rules for the same VFL are tested sequentially or in parallel. If the VFL is updated by a metering rule, the metering rules for the updated VFL are applied. Thus, if there are metering rules for VFL = 1500, they are tested at (1) in the above program. .ti 0 9.3 Action table .fi .in 3 The action table consists of actions that are applied to packets that have a specified VFL. An action can be one of the following actions or a combination of them. .in 3 1) Set a DSCP. .in 6 The DSCP value that is to be set to the packet is specified. .in 3 2) Set a scheduling method and a queue number. .in 6 The precedence of the queue (or the queue number) in which the packet is to be put is specified. .in 3 3) Set a dropping method. .in 6 The dropping method to be used for the packet is specified. .in 3 If no action is specified for a VFL, no action is taken for a flow labeled by the VFL. Because the queue number and the dropping method in an action can be defined separately, different dropping methods may be specified for the same queue. If it is not possible to implement this, the SNMP agent must return an error (and may raise a trap). Examples of actions are given. A1: if (VFL == 64) DSCP = 64; .br A2: if (VFL == 1000) { queuing_method = 3; // an index into the queuing method table. queue_number = 1; dropping_method = 2; // an index into the dropping method table. }; .ti 0 9.4 Policy table and Policy-to-interface mapping table .fi .in 3 A policy is a list of policy rules that are represented by classifiers. Thus, the policy table contains classifier rule identifiers, i.e., indices for the classifier rule table. A policy is assigned to a logical interface using the policy-to-interface mapping table. In the policy framework [Policy], roles are assigned to policy targets, logical interfaces in this case, and interfaces that have the same role-combination will have the same policy. Thus, a policy table represents a role-combination. However, in this MIB, a policy (i.e., a list of policy rules) must be defined before assigning a role-combination to a logical interface; otherwise, the table structure will be too complicated to express using SMI [RFC2578]. .ti 0 10. Relation to PIB .fi .in 3 When the COPS protocol [COPS] is used to control a router, the control information is conveyed using a PIB. The PIB can be expressed using a form very close to that of an MIB [QoSPIB]. In the QoS PIB draft [QoSPIB], the difference and conversion rules between a PIB and a MIB are discussed. However, another point needs to be considered. The user of this MIB, i.e., a PDP, must know what information is in other MIBs. For example, it must know the maximum number of logical interfaces (the ifNumber in the interface MIB), the bandwidth of the interface, and the types of network interfaces, such as ATM, frame relay, or Ethernet. This information can be obtained from the interface MIB [RFC2233]. Because such information is not included in this MIB, it must be obtained and passed on to the policy server when a COPS interface is used. If this MIB is converted to a PIB, information that is missing from the MIB may have to be added to the PIB. .ti 0 11. QoS PIF MIB Definitions .nf .in 3 Qos-PIF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress, Integer32, Gauge32, Counter32, Gauge32 FROM SNMPv2-SMI mib-2 FROM RFC1213-MIB; qos MODULE-IDENTITY LAST-UPDATED "199910201500JST" ORGANIZATION "Hitachi Ltd." CONTACT-INFO "Yasusi Kanada and Mitsuru Ikezawa, Central Research Laboratory, Hitachi Ltd. 1-280, Higashi-Koigakubo, Kokubunji Tokyo 185-8601, Japan {kanada,ikezawa}@crl.hitachi.co.jp" DESCRIPTION "The router-architecture-independent MIB module for controlling the QoS function of a router." ::= { mib-2 xx } qosCapability OBJECT IDENTIFIER ::= { qos 1 } -- QoS capability of the router qosScheduleMethods OBJECT IDENTIFIER ::= { qos 2 } -- List of packet scheduling methods for the router qosDroppingMethods OBJECT IDENTIFIER ::= { qos 3 } -- List of packet dropping methods for the router qosPolicyRules OBJECT IDENTIFIER ::= { qos 4 } -- QoS policy rules for IP packets ------------------------------------------------- -- Textual conventions ------------------------------------------------- Dscp ::= TEXTUAL-CONVENTION SYNTAX INTEGER (0..63) STATUS current DESCTIPTION "The DiffServ code point." DscpOrUndef ::= TEXTUAL-CONVENTION SYNTAX INTEGER (-1 | 0..63) STATUS current DESCTIPTION "The DiffServ code point, or -1 when undefined." Gauge32OrUndef ::= TEXTUAL-CONVENTION SYNTAX INTEGER (-1 | 0..4294967295) STATUS current DESCTIPTION "Gage32 value, or -1 when undefined." PermilOrUndef ::= TEXTUAL-CONVENTION SYNTAX INTEGER (-1 | 0..1000) STATUS current DESCTIPTION "Permil value (1000 permil = 1), or -1 when undefined." ------------------------------------------------- -- QoS capability of the router ------------------------------------------------- -- This part defines the QoS capability of the router. -- [Note] This MIB does not contain information available from other -- MIBs, e.g., the interface MIB in RFC2233. To map this MIB to PIB, -- this type of information must be added. It includes -- 1. The maximum number of logical interfaces (ifNumber in the -- interface MIB). -- 2. The bandwidth of the interface. -- ... -- -- Capability table qosIfCapabilityTable OBJECT-TYPE SYNTAX SEQUENCE OF qosIfCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains QoS-related capability of logical interfaces of the router. The interface index corresponds to ifIndex in the interface MIB in MIB-2. Is is asserted that each logical interface has a unique ifIndex. Phisical ports may have ifIndexes (which is different from any logical interface index)." ::= { qosCapability 1 } qosIfCapabilityEntry OBJECT-TYPE SYNTAX QosIfCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The QoS-related capability of an interface." INDEX { qosIfIndex } ::= { qosCapabilityTable 1 } QosIfCapabilityEntry ::= SEQUENCE { qosIfIndex Gauge32, qosIfPortNumber Gauge32, qosIfQueueSupported BITS, qosIfDropSupported BITS, qosIfStatus RowStatus } qosIfIndex OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logical interface index (identification number). This index corresponds to ifIndex in the interface MIB in MIB-2. There may be interfaces that no QoS information can be associated with." ::= { qosIfCapabilityEntry 1 } -- Logical interface and phisical port (interface) mapping: qosIfPortNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The phisical port number that corresponds to the logical interface. This represents the correspondence between logical interfaces and phisical ports. Multiple logical interfaces may correspond to a single phisical port. All the resources defined in this MIB are asserted to be specified for each logical interface. The logical interface index corresponds to ifIndex in the interface MIB in MIB-2." ::= { qosIfCapabilityEntry 2 } -- Packet scheduling algorithm support: qosIfQueueSupported OBJECT-TYPE SYNTAX BITS { qosIfFifoSchedule(1), -- This flag is set when FIFO scheduling is supported -- (i.e., at least one queue is available.) qosIfPrioritySchedule(2), -- This flag is set when priority scheduling is -- supported. qosIfPacketFairSchedule(3), -- This flag is set when packet-fair scheduling -- function is supported. qosIfByteFairSchedule(4), -- This flag is set when byte-fair scheduling -- (fair queuing) function is supported. qosIfWeightedPacketFairSchedule(16), -- This flag is set when weights can be specified -- for weighted packet-fair scheduling. qosIfWeightedByteFairSchedule(17), -- This flag is set when weights can be specified -- for weighted byte-fair scheduling. qosIfBoundedByteFairSchedule(24) -- This flag is set when bandwidth limit can be -- specified for weighted byte-fair scheduling. } MAX-ACCESS read-only STATUS current DESCRIPTION "A bit list of supported packet scheduling algorithms." ::= { qosIfCapabilityEntry 3 } -- Packet dropping algorithm support qosIfDropSupported OBJECT-TYPE SYNTAX BITS { qosIfDropAll(1), -- This flag is set when function of dropping all -- packets is supported. qosIfEarlyDrop(3), -- This flag is set when (deterministic) early drop -- function is supported. qosIfRandomEarlyDropByPacket(4), -- This flag is set when random early drop (RED) -- function measured by packet is supported. qosIfRandomEarlyDropByByte(5), -- This flag is set when random early drop (RED) -- function measured by byte is supported. } MAX-ACCESS read-only STATUS current DESCRIPTION "A bit list of supported packet dropping algorithms." ::= { qosIfCapabilityEntry 4 } qosIfStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the interface capability table entry." DEFVAL { active } ::= { qosIfCapabilityEntry 5 } ------------------------------------------------- -- Scheduling methods for the router ------------------------------------------------- -- This part defines the packet scheduling and queuing methods -- for the router. qosSchedulingMethodTable OBJECT-TYPE SYNTAX SEQUENCE OF qosSchedulingMethodEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of settings of the packet scheduling queues in logical interfaces. The logical interface index corresponds to ifIndex in the interface MIB in MIB-2." ::= { qosScheduleMethods 1 } qosSchedulingMethodEntry OBJECT-TYPE SYNTAX qosSchedulingMethodEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The settings of packet scheduling queues in a logical interface." INDEX { qosQueueIfIndex } ::= { qosSchedulingMethodTable 1 } qosSchedulingMethodEntry ::= SEQUENCE { qosSchedulingMethodIndex Gauge32, qosSchedulingAlgorithm INTEGER, qosSchedulingNumberQueues Gauge32, qosSchedulingQueueLength Gauge32, qosSchedulingQueueStatus RowStatus } qosSchedulingMethodIndex OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the scheduling method." ::= { qosSchedulingMethodEntry 1 } qosSchedulingAlgorithm OBJECT-TYPE SYNTAX INTEGER { qosQueueNoQueue(0), qosQueueFifo(1), qosQueuePriority(2), qosQueuePacketFair(3), qosQueueByteFair(4), qosQueueBoundedByteFair(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "A packet queuing algorithm. The default value is implementation-dependent." ::= { qosSchedulingMethodEntry 2 } qosSchedulingNumberQueues OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of (simulated) packet scheduling queues, in the abstracted router. If the number of queues in the real router is less than that in the abstracted router, the same queue may be used for different queue precedences. If the same precedenceis specified in two or more rules, packets that match to these rules are put into the same queue, and the order of the packets are preserved. The default value is implementation-dependent." ::= { qosSchedulingMethodEntry 3 } qosSchedulingQueueLength OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The length of the queue by number of packets. The default value is implementation-dependent." ::= { qosSchedulingMethodEntry 4 } qosSchedulingQueueStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the queue setting table entry." DEFVAL { active } ::= { qosSchedulingMethodEntry 5 } -- -- Queue settings for each QUEUE qosQueueSettingTable OBJECT-TYPE SYNTAX SEQUENCE OF qosQueueSettingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The settings of all the queues for all the scheduling methods. This is a two-dimensional conceptual table." ::= { qosScheduleMethods 2 } qosQueueSettingEntry OBJECT-TYPE SYNTAX qosQueueSettingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The settings of a queue for the This entry is associated with each queue in each logical interface." INDEX { qosQueueSchedulingMethodIndex, qosQueueIndex } ::= { qosQueueSettingTable 1 } qosQueueSettingEntry ::= SEQUENCE { qosQueueSchedulingMethodIndex Gauge32, qosQueueNumber Gauge32, qosQueueWeight Gauge32, qosQueueSettingStatus RowStatus } qosQueueSchedulingMethodIndex OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the scheduling method." ::= { qosQueueSettingEntry 1} qosQueueNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The queue number. The range is 1 to qosSchedulingNumberQueues in the corresponding qosSchedulingMethodEntry. If this value is larger, the precedence is higher, in the case of priority scheduling." ::= { qosQueueSettingEntry 2 } qosQueueWeight OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The weight of the abstracted router queue used for weighted round robin or other weighted queuing algorithms. The summation of weights of all the queues in a scheduler must not greater than 2^32-1." DEFVAL { 100 } ::= { qosQueueSettingEntry 3 } qosQueueSettingStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the queue interface setting table entry." DEFVAL { active } ::= { qosQueueSettingEntry 4 } ------------------------------------------------- -- Packet dropping methods ------------------------------------------------- qosDroppingMethodTable OBJECT-TYPE SYNTAX SEQUENCE OF qosDroppingMethodEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains packet dropping methods." ::= { qosDroppingMethods 1 } qosDroppingMethodEntry OBJECT-TYPE SYNTAX QosDroppingMethodEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A packet dropping method. qosDropRatioPermil, qosDropMinThresholdPermil, and qosDropMaxThresholdPermil specify RED parameters." ::= { qosDroppingMethodTable 1 } QosDroppingMethodEntry ::= SEQUENCE { qosDropIndex Gauge32, qosDropAlgorithm INTEGER, qosDromSubAlgorithm Gauge32, qosDropRatioPermil PermilOrUndef, qosDropMinThresholdPermil PermilOrUndef, qosDropMaxThresholdPermil PermilOrUndef, qosDropStatus RowStatus } qosDropIndex OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A packet dropping method identifier." ::= { qosDroppingMethodEntry 1 } qosDropAlgorithm OBJECT-TYPE SYNTAX INTEGER { qosDropAll(1), -- All the packets are dropped. qosNoEarlyDrop(2), -- The packet is dropped only when the queue is -- filled. qosEarlyDrop(3), -- The packet may (deterministically) dropped -- earlier than the queue is filled. qosRandomEarlyDropByPacket(4), -- Random early dropping measured by packet. qosRandomEarlyDropByByte(5), -- Random early dropping measured by byte. } MAX-ACCESS read-write STATUS current DESCRIPTION "The current queuing algorithm. The default value is implementation-dependent." DEFVAL { qosNoEarlyDrop } ::= { qosDroppingMethodEntry 2 } qosDropSubAlgorithm OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The subcode of queuing algorithm. If the router has two or more queuing algorithms that are categorized into the same value of qosDropAlgorithm, they will be distinguished using this object." DEFVAL { 0 } ::= { qosDroppingMethodEntry 3 } qosDropRatioPermil OBJECT-TYPE SYNTAX PermilOrUndef MAX-ACCESS read-only STATUS current DESCRIPTION "The ratio of packet drop when the queue is filled till qosDropMinThresholdPermil." DEFVAL { 1000 } ::= { qosDroppingMethodEntry 4 } qosDropMinThresholdPermil OBJECT-TYPE SYNTAX PermilOrUndef MAX-ACCESS read-only STATUS current DESCRIPTION "The permil of filled part of the queue when packets begin to drop." DEFVAL { 1000 } ::= { qosDroppingMethodEntry 5 } qosDropMaxThresholdPermil OBJECT-TYPE SYNTAX PermilOrUndef MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum permil of filled part of the queue when all the packets drop. If this value is equal to qosDropMinThresholdPermil, either all packets are forwarded or dropped (no choice)." DEFVAL { 1000 } ::= { qosDroppingMethodEntry 6 } qosDropStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the packet dropping method table entry." DEFVAL { active } ::= { qosDroppingMethodEntry 7 } ------------------------------------------------- -- Classifiers, its subrules, and actions ------------------------------------------------- -- This part defines policy rules (both Multi-Field (MF) and Basic -- Aggregate (BA) classifiers. The rules are defined using the -- classifier table, aggregated, and assigned to logical interfaces -- using the policy and the policy-to-interface mapping table. -- -- Classifier table qosClassifierTable OBJECT-TYPE SYNTAX SEQUENCE OF qosClassifierEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of multi-field and basic aggregate classifiers." ::= { qosPolicyRules 1 } qosClassifierEntry OBJECT-TYPE SYNTAX QosClassifierEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A classifier entry." INDEX { qosClassifierId } ::= { qosRuleTable 1 } QosClassifierEntry ::= SEQUENCE { qosClassifierId Gauge32, -- Single packet conditions qosClassifierProtocol INTEGER (-1 | 0..255), qosClassifierIpPacketLengthMin Unsigned32OrUndef, qosClassifierIpPacketLengthMax Unsigned32OrUndef, qosClassifierSourceAddress IpAddress, qosClassifierSourceMasks IpAddress, qosClassifierDestAddress IpAddress, qosClassifierDestMasks IpAddress, qosClassifierSourcePortMin INTEGER (0..65535), qosClassifierSourcePortMax INTEGER (0..65535), qosClassifierDestPortMin INTEGER (0..65535), qosClassifierDestPortMax INTEGER (0..65535), qosClassifierDscp DscpOrUndef, -- Labeling action qosClassifierOutLabel Gauge32, qosClassifierStatus RowStatus } qosClassifierId OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The classifier ID." ::= { qosClassifierEntry 1 } qosClassifierProtocol OBJECT-TYPE SYNTAX INTEGER (-1 | 0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The protocol number of the IP packet." DEFVAL { -1 } ::= { qosClassifierEntry 2 } qosClassifierIpPacketLengthMin OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The lower bound of IP packet data length." DEFVAL { -1 } ::= { qosClassifierEntry 3 } qosClassifierIpPacketLengthMax OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The upper bound of IP packet data length." DEFVAL { -1 } ::= { qosClassifierEntry 4 } qosClassifierSourceAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP source address." DEFVAL { '00000000'H } ::= { qosClassifierEntry 5 } qosClassifierSourceMasks OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The source address mask." DEFVAL { '00000000'H } ::= { qosClassifierEntry 6 } qosClassifierDestAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP destination address." DEFVAL { '00000000'H } ::= { qosClassifierEntry 7 } qosClassifierDestMasks OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The destination address mask." DEFVAL { '00000000'H } ::= { qosClassifierEntry 8 } qosClassifierSourcePortMin OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The lower bound of the source port number." DEFVAL { 0 } ::= { qosClassifierEntry 9 } qosClassifierSourcePortMax OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The upper bound of the source port number." DEFVAL { 65535 } ::= { qosClassifierEntry 10 } qosClassifierDestPortMin OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The lower bound of the destination port number." DEFVAL { 0 } ::= { qosClassifierEntry 11 } qosClassifierDestPortMax OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The upper bound of the destination port number." DEFVAL { 65535 } ::= { qosClassifierEntry 12 } qosClassifierDscp OBJECT-TYPE SYNTAX DscpOrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The DSCP to be tested." DEFVAL { -1 } ::= { qosClassifierEntry 13 } qosClassifierOutLabel OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The virtual label to be put when the MF conditions meet." ::= { qosClassifierEntry 14 } qosClassifierStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the flow rule table entry." DEFVAL { active } ::= { qosClassifierEntry 15 } -- -- Metering subrule table qosMeteringRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF qosMeteringRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of policing rules." multi-field packet flow classifier rule." ::= { qosPolicyRules 2 } qosMeteringRuleEntry OBJECT-TYPE SYNTAX qosMeteringRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A policing subrule that works on an (aggregated) flow with a specific virtual label value." INDEX { qosMeteringInLabel, qosMeteringRuleId } ::= { qosMeteringRuleTable 1 } QosMeteringRuleEntry ::= SEQUENCE { qosMeteringRuleId Gauge32, -- Leaky/token bucket metering conditions qosMeteringInLabel Gauge32, qosMeteringCommittedRateMin Unsigned32OrUndef, qosMeteringCommittedRateMax Unsigned32OrUndef, qosMeteringPeakRate Unsigned32OrUndef, qosMeteringBucketSize Unsigned32OrUndef, -- Labeling qosMeteringOutLabel Gauge32, qosMeteringSTATUS RowStatus } qosMeteringRuleId OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The rule ID." ::= { qosMeteringRuleEntry 1 } qosMeteringInLabel OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The virtual flow label for this rule." ::= { qosMeteringRuleEntry 2 } qosMeteringCommittedRateMin OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum value of committed bit rate that causes the specified action." DEFVAL { -1 } ::= { qosMeteringRuleEntry 3 } qosMeteringCommittedRateMax OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum value of committed bit rate that causes the specified action." DEFVAL { -1 } ::= { qosMeteringRuleEntry 4 } qosMeteringPeakRate OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The peak bit rate that might not cause the specified action. If this value is not -1 nor the same as qosMeteringCommittedRateMin, a leaky bucket is used. If this value is larger than qosMeteringCommittedRateMin, a token bucket is used." DEFVAL { -1 } ::= { qosMeteringRuleEntry 5 } qosMeteringBucketSize OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The leaky/token bucket size." DEFVAL { -1 } ::= { qosMeteringRuleEntry 6 } qosMeteringOutLabel OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The virtual label to be put when the MF conditions meet." ::= { qosMeteringRuleEntry 7 } qosMeteringStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the policing rule table entry." DEFVAL { active } ::= { qosMeteringRuleEntry 8 } -- -- Action table qosActionTable OBJECT-TYPE SYNTAX SEQUENCE OF qosActionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of multi-field packet flow classification conditions." ::= { qosPolicyRules 3 } qosActionEntry OBJECT-TYPE SYNTAX QosActinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A packet flow action entry." INDEX { qosActionInLabel } ::= { qosActionTable 1 } QosActionEntry ::= SEQUENCE { qosActionInLabel Gauge32, qosActionSchedulingMethod Unsigned32OrUndef, qosActionQueueNumber Unsigned32OrUndef, qosActionDroppingMethod Unsigned32OrUndef, qosActionOutDscp DscpOrUndef, qosActionOutIfIndex Unsigned32OrUndef, qosActionStatus RowStatus } qosActionInLabel OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The virtual flow label for this action." ::= { qosActionEntry 1 } qosActionSchedulingMethod OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "An index into the scheduling method table. This specifies the scheduling method to be taken. If this value is -1, no scheduling method is specified." DEFVAL { -1 } ::= { qosActionEntry 2 } qosActionQueueNumber OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The queue number to be selected when the conditions is satisfied. If the number of queues in the real router is less than that in the abstracted router, the same queue may be used for different queue numbers. However, if two rules in the same logical interface specifies the same queue number, the packet order is preserved between the rules. This value is effective only when qosActionSchedulingMethod is not -1." ::= { qosActionEntry 3 } qosActionDroppingMethod OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "An index into the packet dropping method table. This specifies the dropping method to be taken. If this value is -1, no dropping method is specified." DEFVAL { -1 } ::= { qosActionEntry 4 } qosActionOutDscp OBJECT-TYPE SYNTAX DscpOrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The new DSCP to be assigned when the single packet conditions are satisfied. If this value is -1, the DSCP is not updated." DEFVAL { -1 } ::= { qosActionEntry 5 } qosActionOutIfIndex OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The logical interface to be sent the packet. If this value is set, the action is a tag switching." ::= { qosActionEntry 6 } qosActionStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the action table entry." DEFVAL { active } ::= { qosActionEntry 7 } -- -- Policy table (rule list table) qosPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF qosPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains policies. A policy in this table may be assigned to only one logical interface, or to multiple interfaces. A policy table may correspond to a role combination, i.e., each policy table can be assigned to a role combination. The router resource shortage may be avoided by sharing a policy by multiple interfaces." INDEX { qosPolicyId, qosPolicyEntryIndex } ::= { qosPolicyRules 6 } qosPolicyEntry OBJECT-TYPE SYNTAX QosPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A policy (an ordered list of policy rules)." ::= { qosPolicyTable 1 } QosPolicyEntry ::= SEQUENCE { qosPolicyId Gauge32, qosPolicyEntryIndex Gauge32, qosPolicyClassifierId Gauge32, qosPolicyStatus RowStatus } qosPolicyId OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index into the policy table." ::= { qosPolicyEntry 1 } qosPolicyEntryIndex OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the policy entry." ::= { qosPolicyEntry 2 } qosPolicyClassifierId OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "An identification number of the classifier." ::= { qosPolicyEntry 3 } qosPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the policy table entry." DEFVAL { active } ::= { qosPolicyEntry 4 } -- -- Policy-to-interface mapping table qosPolicyIfTable OBJECT-TYPE SYNTAX SEQUENCE OF qosPolicyIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents a mapping from the logical interfaces to policies, where each policy may corresponds to a role combination. The logical interface index (qosPolicyIfIndex) corresponds to ifIndex in the interface MIB in MIB-2." INDEX { qosPolicyIfIndex } ::= { qosPolicyRules 7 } qosPolicyIfEntry OBJECT-TYPE SYNTAX QosPolicyIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A mapping table entry that assigns a policy to a logical interface." ::= { qosPolicyIfTable 1 } QosPolicyIfEntry ::= SEQUENCE { qosPolicyIfIndex Gauge32, qosPolicyIdInbound Unsigned32OrUndef, qosPolicyIdOutbound Unsigned32OrUndef, qosPolicyMappingStatus RowStatus } qosPolicyIfIndex OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logical interface index." ::= { qosPolicyIfEntry 1 } qosPolicyIdInbound OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The policy identification number for the in-bound port of the interface." DEFVAL { -1 } ::= { qosPolicyIfEntry 2 } qosPolicyIdOutbound OBJECT-TYPE SYNTAX Unsigned32OrUndef MAX-ACCESS read-write STATUS current DESCRIPTION "The policy identification number for the out-bound port of the interface." DEFVAL { -1 } ::= { qosPolicyIfEntry 3 } qosPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the role combination table entry." DEFVAL { active } ::= { qosPolicyIfEntry 4 } END .ti 0 12. Implementation Note .fi .in 3 A VFL may not be a real entity in a router. Thus, to implement this MIB in some hardware routers such as Hitachi's GR2000, a classifier, an action, and metering rules (if necessary) must be combined into a hardware-level if-then rule. .ti 0 13. Security Considerations .fi .in 3 A set of policy rules in this MIB is not merely data, but is a type of computer program. Although the function of the program is currently restricted to traffic control, downloading a malicious program could harm mission-critical tasks performed through the network. In addition, it is possible to extend the function of the program to routing, switching, or application-specific tasks by extending this MIB or by combining it with other MIBs. Thus, the security of communication through an SNMP is important. SNMPv3 [RFC2570] should be used, instead of earlier versions of SNMP. .ti 0 14. References .fi .in 3 [ASN.1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. Sastry, "The COPS (Common Open Policy Service) Protocol", draft-ietf-rap-cops-07.txt, Internet-Draft, August 1999. [DSMIB] F. Baker, "Management Information Base for the Differentiated Services Architecture", draft-ietf-diffserv-mib- 00.txt, Internet Draft, July 1999. [DSModel] Y. Bernet, A. Smith, and S. Blake, "A Conceptual Model for Diffserv Routers", draft-ietf-diffserv-model-00.txt, Internet Draft, June 1999. [Floyd95] S. Floyd, and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995. [IP-009] S. Yoshizawa, and A. Karlcut, "L-Interface for IP Router Flow & Output Queue Resource Abstraction and Its Application to Differentiated Services", IEEE P1520/TS/IP-009, June 1999. [IWAN99] S. Covaci, ed., "Active Networks", Lecture Notes in Computer Science, Springer-Verlag, June 1999. [QoSPIB] M. Fine, K. McCloghrie, S. Hahn, K. Chan, and A. Smith, "An Initial Quality of Service Policy Information Base", draft-mfine-cops-pib-01.txt, Internet Draft, June 1999. [Policy] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, and J. Wheeler, "Policy Framework", draft-ietf-policy-framework-00.txt, Internet Draft, September 1999. [RFC1155] M. Rose, and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, STD 16, May 1990. [RFC1157] J. Case, M. Fedor, M. Schoffstall, and J. Davin, "Simple Network Management Protocol", RFC 1157, STD 15, May 1990. [RFC1212] M. Rose, and K. McCloghrie, "Concise MIB Definitions", RFC 1212, STD 16, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1901] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1905] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2233] K. McCloghrie, and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [RFC2571] D. Harrington, R. Presuhn, and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers." RFC 2474, December 1998. [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, "An Architecture for Differentiated Service." RFC 2475, December 1998. [RFC2570] J. Case, R. Mundy, D. Partain, and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2572] J. Case, D. Harrington, R. Presuhn, and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2573] D. Levi, P. Meyer, and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] B. Wijnen, R. Presuhn, and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] K. McCloghrie, D. Perkins, and J. Schoenwaelder, ed., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. [RFC2579] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose, and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 58, April 1999. [RFC2580] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose, and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999. [RFC2597] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. .ti 0 15. Authors' Addresses .nf Yasusi Kanada Hitachi, Ltd. Central Research Laboratory 1-280 Higashi-Koigakubo Kokubunji-shi, Tokyo 185-8601 JAPAN Phone: +81 42 323 1111 Email: kanada@crl.hitachi.co.jp Mitsuru Ikezawa Hitachi, Ltd. Central Research Laboratory 1-280 Higashi-Koigakubo Kokubunji-shi, Tokyo 185-8601 JAPAN Phone: +81 42 323 1111 Email: Mitsuru-crl.Ikezawa@c-net3.crl.hitachi.co.jp Shigeru Miyake Hitachi, Ltd. System Development Laboratory 292 Yoshida-cho, Totsuka-ku, Yokohama, Kanagawa 244-0817 JAPAN Phone: +81 45 860 3080 Email: yake@sdl.hitachi.co.jp Yoshifumi Atarashi Hitachi, Ltd. Enterprise Server Division 810 Imaizumi, Ebina, Kanagawa 243-0435 JAPAN Phone: +81 462 32 2111 Email: atarashi@ebina.hitachi.co.jp