1 / 6

RMONMIB WG 61st IETF Washington, DC USA November 11, 2004

RMONMIB WG 61st IETF Washington, DC USA November 11, 2004. Discussion: rmonmib@ietf.org Admin: http://www.ietf.org/mailman/listinfo/rmonmib. RMONMIB WG Agenda -- I-Ds. (A) RAQMON Framework draft-ietf-rmonmib-raqmon-framework-07.txt (B) RAQMON PDU

angellar
Télécharger la présentation

RMONMIB WG 61st IETF Washington, DC USA November 11, 2004

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 WG61st IETFWashington, DC USANovember 11, 2004 Discussion: rmonmib@ietf.orgAdmin: http://www.ietf.org/mailman/listinfo/rmonmib

  2. RMONMIB WG Agenda -- I-Ds • (A) RAQMON Framework • draft-ietf-rmonmib-raqmon-framework-07.txt • (B) RAQMON PDU • draft-ietf-rmonmib-raqmon-pdu-07.txt • (C) RAQMON MIB • draft-ietf-rmonmib-raqmon-mib-05.txt • (D) TPM-MIB • draft-ietf-rmonmib-tpm-mib-14.txt • (E) SSPM-MIB • draft-ietf-rmonmib-sspm-mib-12.txt • (F) RMON2-MIB (Version 2) • draft-ietf-rmonmib-rmon2-v2-02.txt

  3. RMONMIB WG Agenda 1) WG Status (15 minutes) Status of documents in the publication pipeline (D - F) 2) Real-time Application Quality of Service Monitoring (135 min) - Discussion of the RAQMON Framework (A) - Discussion of the RAQMON PDU (B) - Discussion of the RAQMON MIB (C)

  4. Status of completed documents (1/2) • Advancement of RFC 2613 to DS (SMON MIB) • Waiting for advancement to Draft Standard of RFC 2021 • Advancement of RFC 2021 to DS (RMON2-MIB) • In “AD Evaluation:AD Followup” state; • AD comments now fully addressed • Boilerplate up-to-date • TimeFilter bugs should be fixed • TPM-MIB • draft-ietf-rmonmib-tpm-mib-14 in “RFC Ed Queue” state • Done • SSPM-MIB • draft-ietf-rmonmib-sspm-mib-12 in “RFC Ed Queue” state • Done

  5. TimeFilter Issues (1/2) • Mangled text needs to be fixed • Sec 11, num 1, para 3: • OLD: • The TimeFilter is a boolean filtering function applied in • internal Get* PDU processing. If the 'last-change-time' of the • specified instance is less than the particular TimeFilter • INDEX value, then the instance is considered 'not-present' • (skipped for GetNext and GetBulk PDUs; 'noSuchInstance' or • returned to the requester. • NEW: • The TimeFilter is a boolean filtering function applied in • internal Get* PDU processing. If the 'last-change-time' of the • specified instance is less than the particular TimeFilter • INDEX value, then the instance is considered 'not-present', • and it is skipped for GetNext and GetBulk PDUs, or a 'noSuchInstance' • exception is returned for Get PDUs.

  6. TimeFilter Issues (2/2) • Misleading text regarding agent implementation: only 1 timestamp per row is needed, not one timestamp per counter • 1.1) Agent Implementation of a Time-Filtered Table • In implementation, the time-filtered rows (one for each tick • of sysUpTime) are only conceptual. The agent simply filters a • real table based on: • * the current value of sysUpTime • * the TimeFilter value passed in the varbind • * the last-update timestamp of each requested counter • (agent implementation requirement) • For example, to implement a time-filtered counter, an agent • maintains a timestamp in a 32-bit storage location, • initialized to zero. This is in addition to whatever • instrumentation is needed for the counter. • Each time the counter is updated, the current value of • sysUpTime is recorded in the associated timestamp. If this is • not possible or practical, then a background polling process • must 'refresh' the timestamp by sampling counter values and • comparing them to recorded samples. The timestamp update must • occur within 5 seconds of the actual change event.

More Related