abierman-rmonwg-17mar03 1

RMONMIB WG56th IETF

San Francisco, CaliforniaMarch 17, 2003

Discussion:

rmonmib@ietf.orgAdmin:

http://www.ietf.org/mailman/listinfo/rmonmib

abierman-rmonwg-17mar03 2

RMONMIB WG Agenda -- I-Ds

(A) draft-ietf-rmonmib-raqmon-framework-01.txt (B) draft-ietf-rmonmib-raqmon-pdu-01.txt (C) draft-ietf-rmonmib-raqmon-mib-00.txt

abierman-rmonwg-17mar03 3

RMONMIB WG Agenda (1/2)

WG Status (5 minutes)» Status of completed documents

Protocol Identifier Macros (10 minutes)» Request from IPPM WG to update PI Macros RFC

Fixing the TimeFilter TC and updating RFC 2021 (15 minutes)» discussion of email proposal (2/3/03) to create new

timeFilterMode MIB object

abierman-rmonwg-17mar03 4

RMONMIB WG Agenda (2/2)

Real-time Application Quality of Service Monitoring (90 min)» Discussion of the RAQMON Framework (A)

– Determine if the framework is complete– Should the framework provide extensibility and allow for future PDU

types and/or delivery mechanisms

» Discussion of the RAQMON PDU (B)– Discuss congestion awareness requirements– Determine if the PDU contains all appropriate fields– Should there be different high-level conformance level to allow devices

to subset the PDU fields in a consistent manner?

» Discussion of the RAQMON MIB (C)– Determine (if possible) if the MIB is complete for:

configuration reported attributes collected from RAQMON PDU

abierman-rmonwg-17mar03 5

Status of completed documents Advancement of RFC 2074 and RFC 2613

» Waiting IESG action for advancement to Draft Standard APM-MIB

» AD review completed December 2002» draft-ietf-rmonmib-apm-mib-08.txt published March 2002» WG needs to decide if another WG Last Call needed

TPM-MIB» AD review completed February 2003» Waiting for authors to publish an update

SSPM-MIB» AD review completed February 2003» Waiting for authors to publish an update

Introduction to RMON Family of MIBs» WG Last Call completed February 2003» Waiting for AD review

abierman-rmonwg-17mar03 6

TimeFilter update Problem

» TimeFilter behavior causes excessive data to be returned in mibwalks and getBulk PDUs

Solution Proposal» timeFilterMode MIB object indicates if the agent

conforms to existing RFC 2021 semantics (stopAfterAll) or if it performs data reduction and eliminates redundant rows (stopAfterOne)

Issues» Is this the best way to solve the problem?» How to package (new MIB group, RMON-2 update)» Conformance requirements

abierman-rmonwg-17mar03 7

timeFilterMode Details MIB object basics

timeFilterMode OBJECT-TYPE

SYNTAX INTEGER {

stopAfterOne(1),

stopAfterAll(2)

}

MAX-ACCESS read-write

Conformance sectionOBJECT timeFilterMode

MIN-ACCESS read-only

DESCRIPTION

“Write access is not required.”

abierman-rmonwg-17mar03 8

timeFilterMode Fine Print (1/2)"This object controls the way the SNMP agent implements the

getnext operation for tables with a TimeFilter index, such as those found in the RMON2-MIB module.

If this object has the value `stopAfterOne(1)', then a GetNext or GetBulk operation will provide one pass through a given table, i.e., the agent will continue to the next object or table, instead of incrementing a TimeMark INDEX value, even if there exists higher TimeMark values which are valid for the same conceptual row.

This mode is not strictly compliant with the TimeFilter textual convention definition, because potentially many conceptual rows will be skipped instead of returned in a GetNext or GetBulk operation. Such rows are identical t each other, except for the returned TimeMark INDEX value. This mode is intended only for testing purposes, however it may also be useful if an NMS wishes to utilize the GetBulk PDU. This mode will prevent the GetBulk responses from containing duplicate rows due to the TimeFilter mechanism.

abierman-rmonwg-17mar03 9

timeFilterMode Fine Print (2/2)If this object has the value `stopAfterAll(2)', then a getNext or getBulk

MIB walk will repeat through the same MIB table until the TimeMark for the most-recently changed entry is reached. Note that as long as traffic occurs on the monitored interface, it is possible a highest value of the TimeFilter INDEX may never be reached. This mode is strictly compliant with the TimeFilter textual convention definition. Note that GetBulk PDU responses in this mode will likely contain multiple copies of the same MIB instances, differing only in the TimeMark INDEX value.

As an example, consider row 'fooEntry' which was last updated at 'time 1000'. An NMS may use any TimeMark INDEX value in the range '0' to '1000', and the current (i.e., time of get request) counter values for the 'fooEntry' will be returned by agent. In the 'stopAfterOne' mode, the agent will not increment the fooEntry TimeMark index under any conditions. In the 'stopAfterAll' mode, the agent will increment any fooEntry TimeMark INDEX value in the range '0' to '999', up until the TimeMark value of '1000' is reached.“

DEFVAL { stopAfterAll }