1 / 9

RMONMIB WG 56th IETF San Francisco, California March 17, 2003

RMONMIB WG 56th IETF San Francisco, California March 17, 2003. Discussion: rmonmib@ietf.org Admin: http://www.ietf.org/mailman/listinfo/rmonmib. RMONMIB WG Agenda -- I-Ds. (A) draft-ietf-rmonmib-raqmon-framework-01.txt (B) draft-ietf-rmonmib-raqmon-pdu-01.txt

terra
Télécharger la présentation

RMONMIB WG 56th IETF San Francisco, California March 17, 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RMONMIB WG56th IETFSan Francisco, CaliforniaMarch 17, 2003 Discussion: rmonmib@ietf.orgAdmin: http://www.ietf.org/mailman/listinfo/rmonmib

  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

  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

  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

  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

  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

  7. timeFilterMode Details • MIB object basics timeFilterMode OBJECT-TYPE SYNTAX INTEGER { stopAfterOne(1), stopAfterAll(2) } MAX-ACCESS read-write • Conformance section OBJECT timeFilterMode MIN-ACCESS read-only DESCRIPTION “Write access is not required.”

  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.

  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 }

More Related