One document matched: draft-schoenw-nmrg-snmp-trace-definitions-01.txt
Differences from draft-schoenw-nmrg-snmp-trace-definitions-00.txt
NMRG J. van den Broek
Internet-Draft University of Twente
Intended status: Informational J. Schoenwaelder
Expires: August 28, 2008 Jacobs University Bremen
A. Pras
University of Twente
M. Harvan
ETH Zurich
February 25, 2008
SNMP Trace Analysis Definitions
draft-schoenw-nmrg-snmp-trace-definitions-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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.
This Internet-Draft will expire on August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
van den Broek, et al. Expires August 28, 2008 [Page 1]
Internet-Draft SNMP Trace Analysis Definitions February 2008
Abstract
The Network Management Research Group (NMRG) started an activity to
collect traces of the Simple Network Management Protocol (SNMP) from
operational networks. To analyze these traces, it is necessary to
split potentially large traces into more manageable pieces that make
it easier to deal with large data sets and simplify the analysis of
the data.
This document provides some common definitions that have been found
useful for implementing tools to support trace analysis. This
document mainly serves as a reference for the definitions underlying
these tools and it is not meant to explain all the motivation and
reasoning behind the definitions. Some of this background
information can be found in other research papers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Slices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Slice Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Slice Type . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Walks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
van den Broek, et al. Expires August 28, 2008 [Page 2]
Internet-Draft SNMP Trace Analysis Definitions February 2008
1. Introduction
The Simple Network Management Protocol (SMMP) was introduced in the
late 1980s. Since then, several protocol changes have taken place,
which have eventually led to what is known today as the SNMP version
3 framework (SNMPv3) [RFC3410][RFC3411]. Extensive use of SNMP has
led to significant practical experience by both network operators and
researchers. However, up until now only little research has been
done on characterizing and modeling SNMP traffic.
Since recently, network researchers are in the possession of network
traces, including SNMP traces captured on operational networks. The
availability of SNMP traces enables research on characterizing and
modeling real world SNMP traffic. However, experience with SNMP
traces has shown that the traces must be large enough in order to
make proper observations. A more detailed motivation for collecting
SNMP traces and guidelines how to capture SNMP traces can be found in
[ID-IRTF-NMRG-SNMP-MEASURE].
Unfortunately, the analysis of large SNMP traces can take a large
amount of processing time. Therefore, it is often desirable to focus
the analysis on smaller, relevant sections of a trace. This in turn
requires a proper way to identify these smaller sections of a trace.
This document describes a number of identifiable sections within a
trace which make specific research on these smaller sections more
practical. The following figure shows the various sections of traces
and how they relate to each other.
+---------+ 0..* 1 +-------+ 1 0..* +------+
| Message |------------->| Trace |----------->| Flow |
+---------+ belongs_to +-------+ contains +------+
| 1
|
| contains
|
v 0..*
+------------+ 1 0..* +-------+
| Slice Type |<----------| Slice |
+------------+ of_type +-------+
^ 1
|
| is_a
|
| 0..1
+-------+
| Walk |
+-------+
van den Broek, et al. Expires August 28, 2008 [Page 3]
Internet-Draft SNMP Trace Analysis Definitions February 2008
This document defines the various entities (boxes) shown in the above
figure. These definitions can be implemented by tools that can split
SNMP traces into smaller sections for further analysis.
The most central entity in the figure above is an SNMP trace,
consisting of a potentially large set of SNMP messages. An SNMP
trace is the result of recording SNMP traffic on a specific network
for a specific time duration. Such a trace may, depending on the
number of hosts in the respective network, contain SNMP messages
exchanged between possibly many different SNMP engines. The messages
contained in a trace may be represented in different formats. For
the purpose of this document, the simple comma separated values (CSV)
format defined in [ID-IRTF-NMRG-SNMP-MEASURE] contains sufficient
information to split a trace into smaller sections.
The SNMP messages belonging to an SNMP trace may have been exchanged
between many different SNMP engines running on different hosts.
Therefore, a first obvious way of separating a trace into smaller
sets of SNMP messages is the separation of a trace into flows. Each
flow contains only those SNMP messages of an SNMP trace that have
been exchanged between two network endpoints. Such a separation may
be necessary in case one wants to analyze specific SNMP traffic
characteristics (e.g., number of agents managed by a management
station) and wants to rule out network endpoint specific behaviour
(e.g., different SNMP management stations may have different polling
configurations).
Flows within traces can still be quite large in terms of the number
of messages they contain. Therefore, it may be necessary to split a
flow into even smaller sections called slices. A slice contains all
SNMP messages of a given flow that are related to each other in time
and referenced information. Splitting a flow into slices makes it
possible to separate SNMP messages within traces that belong to each
other, like for example all messages that belong to a single polling
instance involving a single manager and a single agent.
A slice may contain, for instance, the exchanged SNMP messages
between an agent and a manager, which polls that agent in a single
polling instance. The manager may be configured to poll that agent
every once in a while. If the requested information from the agent
remains unchanged, then the respective slices of SNMP traffic
occurring between this manager and agent will be highly comparable.
In such a case the slices will be of the same slice type. Similar
slices will thus be considered of the same slice type and
incomparable slices will not be of the same slice type.
Besides the fact that each slice is of specific slice type, slices
can also be of a specific form with respect to the messages
van den Broek, et al. Expires August 28, 2008 [Page 4]
Internet-Draft SNMP Trace Analysis Definitions February 2008
encompassing a slice. For example, slices containing a sequence of
linked GetNext or GetBulk requests are commonly called an SNMP walk.
Note that only a subset of all slices will be walks.
van den Broek, et al. Expires August 28, 2008 [Page 5]
Internet-Draft SNMP Trace Analysis Definitions February 2008
2. Messages
SNMP messages carry PDUs associated with well defined specific
protocol operations [RFC3416]. The PDUs can be used to classify SNMP
messages. Following are a number of definitions that help to
classify SNMP messages based on the PDU contained in them. These
definitions will be used later on in this document.
Notation: Let M be an SNMP message. We denote the properties of M as
follows:
M.type = operation type of message M (get, getnext, ...)
M.class = class of message M (according to RFC 3411)
M.tsrc = transport layer source endpoint of message M
M.tdst = transport layer destination endpoint of message M
M.nsrc = network layer source endpoint of message M
M.ndst = network layer destination endpoint of message M
M.reqid = request identifier of message M
M.time = capture timestamp of message M
M.oids = OIDs listed in varbind list of message M
M.values = values listed in varbind list of message M
Note that the properties of a message can be easily extracted from
the exchange formats defined in RFC XXXX [ID-IRTF-NMRG-SNMP-MEASURE].
Definition (read request message): A read request message is a
message M containing a PDU of type GetRequest, GetNextRequest, or
GetBulkRequest.
Definition (write request message): A write request message is a
message M containing a PDU of type SetRequest.
Definition (notification request message): A notification request
message is a message M containing a PDU of type InformRequest.
Definition (notification message): A notification message is a
message M containing a PDU of type Trap or InformRequest.
Definition (request message): A request message is a message M which
is either a read request message, a write request message, or a
notification request message.
Definition (response message): A response message is a message M
containing a PDU of type Response or of type Report.
Note that Report messages are treated like Response messages since
the SNMPv3 specifications currently use Report messages only as an
error reporting mechanism, always triggered by the processing of some
van den Broek, et al. Expires August 28, 2008 [Page 6]
Internet-Draft SNMP Trace Analysis Definitions February 2008
request messages. In case future SNMP versions or extensions use
Report messages without having a request triggering the generation of
Report messages, we may have to revisit the definition above.
Definition (non-response message): A non-response message is a
message M which is either a read request message, a write request
message, or a notification message.
Definition (command message): A command message is a message M which
is either a read request message or a write request message.
Definition (command group messages): A set of command group messages
consists of all messages M satisfying either of the following two
conditions:
(C1) M is a command message
(C2) M is a response message and there exists a command message C
such that the following holds:
M.reqid = C.reqid
M.tdst = C.tsrc
M.tsrc = C.tdst
(M.time - C.time) < t
The parameter t defines a maximum timeout for response messages.
This definition requires that the response message originates from
the transport endpoint over which the request message has been
received. This is not strictly required by SNMP transport mappings
and in particular the UDP transport mapping allows to send responses
from different transport endpoints. While sending response messages
from a different transport endpoint is legal, it is also considered
bad practice causing interoperability problems since several
management systems do not accept such messages.
It was decided to require matching transport endpoints since doing so
significantly simplifies the procedures below and avoids accidentally
confusing requests and responses. Implementations responding from
different transport endpoints will lead to (a) a larger number of
requests without related responses (and likely no retries) and (b) a
similarly large number of response messages without a matching
request. If such behavior can be detected, the traces should be
investigated and if needed the transport endpoints corrected.
Definition (notification group messages): A set of notification group
messages consists of all messages M satisfying either of the
following two conditions:
van den Broek, et al. Expires August 28, 2008 [Page 7]
Internet-Draft SNMP Trace Analysis Definitions February 2008
(N1) M is a notification message
(N2) M is a response message and there exists a notification
request message N such that the following holds:
M.reqid = N.reqid
M.tdst = N.tsrc
M.tsrc = N.tdst
(M.time - N.time) < t
The parameter t defines a maximum timeout for response messages.
We again require that the transport endpoints match for notification
group messages.
van den Broek, et al. Expires August 28, 2008 [Page 8]
Internet-Draft SNMP Trace Analysis Definitions February 2008
3. Traces
Traces are (large) sets of SNMP messages that are the result of
recording SNMP traffic using a single traffic recording unit (e.g.,
using tcpdump) on a network segment carrying traffic of one or more
managers and agents. Traces being used in the remainder of this
document may be altered as a result of anonymization, which may
result in some message information loss.
Definition (trace): An SNMP trace (or short trace) T is an ordered
set of zero or more SNMP messages M. All messages M in T are
chronologically ordered according to the capture time stamp M.time.
van den Broek, et al. Expires August 28, 2008 [Page 9]
Internet-Draft SNMP Trace Analysis Definitions February 2008
4. Flows
Definition (flow): A flow F is the set of messages of an SNMP trace T
with the following properties:
(F1) All response messages originate from a single network
endpoint.
(F2) All non-response messages originate from a single network
endpoint.
(F3) All messages are either command group messages or notification
group messages.
Subsequently, we call flows containing only command group messages
command flows. Similarly, we call flows containing only notification
group messages notification flows.
Note that it is possible that response messages of a trace cannot be
classified to belong to any flow. This can happen if request
messages triggering the response messages were not recorded (for
example due to asymmetric routing) or because response messages were
originating from transport endpoints different from the endpoint used
to receive the associated request message.
Definition (flow initiator): A flow initiator is the network endpoint
of the two endpoints involved in a flow, which is responsible for
sending the first non-response message.
Notation: Let F be a flow as defined above. We denote the properties
of F as follows:
F.type = type of the flow F (command/notification)
F.nsrc = network layer source endpoint of F
F.ndst = network layer destination endpoint of F
F.start = time stamp of the first message in F
F.end = time stamp of the last message in F
This definition of a flow is mostly consistent with the definition of
a flow used in [SPHSM07]. The difference is that the tool used to
generate the data reported in [SPHSM07] did only require that the
network layer source endpoint of the response messages matches the
destination network layer endpoint of the associated request
messages.
van den Broek, et al. Expires August 28, 2008 [Page 10]
Internet-Draft SNMP Trace Analysis Definitions February 2008
5. Slices
Flows are made up of smaller sets of messages that are related to
each other. Such a subset of messages from a single flow will be
considered a slice of a flow.
Definition (slice): A slice S is a subset of messages in a flow F for
which the following properties hold:
(S1) All messages are exchanged between the same two transport
endpoints (a single transport endpoint pair).
(S2) All non-response messages must have a PDU of the same type.
(S3) All messages with a PDU of type Get, Set, Trap, or Inform must
contain the same set of OIDs.
(S4) Each GetNext or GetBulk message must either contain the same
set of OIDs or they must be linked to the chronologically last
response of the previous request, that is the request must
contain at least one OID that has been contained in the
(repeater) varbind list of the chronologically last response
message of a previous request message.
(S5) All Response messages must follow a previous request message
that is part of the same slice.
(S6) For any two subsequent request messages Q1 and Q2 with Q1.time
< Q2.time, the following condition must hold:
(Q2.time - Q1.time) < e
The parameter e defines the maximum time between two non-response
messages that belong to a slice. This parameter should be chosen
such that unrelated requests within a flow are not considered to be
of the same slice. Unrelated requests are those that, for instance,
belong to different polling instances. The parameter e should
therefore be larger than the retransmission interval in order to keep
retransmissions within a slice and smaller than the polling interval
used by the slice initiator.
Definition (slice initiator): A slice initiator is one of the two
transport endpoints involved in a slice, which is responsible for
sending the chronologically first non-response class message.
Notation: A slice S has several properties. We introduce the
following notation:
van den Broek, et al. Expires August 28, 2008 [Page 11]
Internet-Draft SNMP Trace Analysis Definitions February 2008
S.type = type of non-response messages in S
S.tsrc = transport layer endpoint of initiator of S
S.tdst = transport layer endpoint of non-initiator of S
S.start = time stamp of the chronologically first message in S
S.end = time stamp of the chronologically last message in S
S.prefix = prefix of S (see below)
Definition (concurrency): Two slides A and B of a given flow F are
concurrent at time t if A.start <= t <= A.end and B.start <= t <=
B.end. The concurrency level F.clevel(t) of a flow F at time t is
given by the number of concurrent slices of F at time t. The
concurrency level of a manager identified by the network address addr
at time t is given by the sum of the flow currency levels F.clevel(t)
for all flows originating from addr, that is F.nsrc = addr.
Definition (delta time serial): Two slides A and B of a given flow F
are called delta time serial if (B.start - A.end) < delta.
van den Broek, et al. Expires August 28, 2008 [Page 12]
Internet-Draft SNMP Trace Analysis Definitions February 2008
6. Slice Prefix
As noted in the beginning of this document, it is desired that slices
can be tested for equality/comparability. This is where the slice
prefix comes in. The slice prefix has as a sole purpose to provide
one of the means to compare slices. Using the slice prefix and a few
other parameters (which will be discussed later on in this document)
of a number of slices, one can determine which slices should be
considered 'equal' and which of them are incomparable. This will
assist in the process of finding potentially other relations.
The slice prefix is a set of OIDs. This set is constructed based on
the messages that make up a single slice. So, for example, a slice
that is the result of a manager requesting the contents of a
particular table (with OID alpha) on an agent using a simple single
varbind GetNext walk, starting at the table OID alpha, shall yield a
slice prefix which consists of the OID alpha.
Because the aim is to compare various slices using the slice prefix
(along some other characteristics of a slice), this implicitly
suggests the need to know whether a number of slices are the result
of the same behaviour (i.e., specific configuration) of the
initiating party of these slices. For example, one may want to know
whether a number slices that involve a single manager and a single
agent were the result of just one specific configuration of that
manager. Multiple slices, that may all be initiated by that same
manager and each slice possibly occurred in different polling
instances, may in fact be the result of the same specific
configuration of that particular manager. So, since in this case the
specific configuration of the manager is only relevant for
determining the behaviour, the slice prefix should be constructed
based on OIDs in messages originating from that manager only. More
generally, only the messages within slices that are sent by the
initiating party (the non-response messages) are considered for the
determination of the respective slice prefix of a slice.
The resulting set of OID prefixes will represent the behaviour of the
respective initiating party of that slice. This allows us to compare
different slices.
Following is a short introductory example which depicts what a slice
could consist of and how one could determine the slice prefix in such
a general case.
Consider the case of a single manager A polling a specific agent B.
More specifically, the manager A is configured to retrieve the
complete contents of two columns alpha and beta of a some table. The
resulting slice may contain the following messages:
van den Broek, et al. Expires August 28, 2008 [Page 13]
Internet-Draft SNMP Trace Analysis Definitions February 2008
-------------------------------------------------------------------
Message | Direction | PDU type | OIDs
-------------------------------------------------------------------
0 A -> B GetNext Request alpha, beta
1 B -> A Response alpha.0, beta.0
2 A -> B GetNext Request alpha.0, beta.0
3 B -> A Response alpha.1, beta.1
4 A -> B GetNext Request alpha.1, beta.1
5 B -> A Response gamma.0, delta.0
-------------------------------------------------------------------
The manager starts with a GetNext request referencing two OIDs, alpha
and beta. The agent B replies in message 1 with the first items of
each of the referenced columns. The manager in turn goes on
obtaining data from these two columns until it receives message 5,
which indicates that the manager has received all of the data from
the two columns.
It can be easily concluded that the manager was configured to
retrieve the contents of the two columns alpha and beta (the slice
prefix). A different slice involving the same manager and agent and
that is again the result of the same configuration of the manager,
should be considered 'equal' to this one because the two slices are
the result of the same behaviour. It should however be mentioned
that such a second slice might contain a different number of
messages, since the contents of the tables on the agent side might
have changed over time. This underlines the previously made remark
that only the messages originating from the initiating party should
be considered in this process, because they will (in such a scenario)
always illustrate the same behaviour of the initiating party.
The previous example now makes it possible to give a more formal
definition of a slice prefix.
Assume the following: Mnon_resp1 and Mnon_resp2 are two consecutive
non-response messages of a slice (which have unequal request
identifiers) and that Mresp1 and Mresp2 represent any response
message to each of the respective non-response messages.
Definition (slice prefix): A slice prefix P is a set of OID prefixes
derived from the OIDs contained in the non-response messages of a
single slice. This set P consists of the following OIDs:
(SP1) Each OID x in Mnon_resp2 of a slice that is not in any
response Mresp1 to the previous non-response message
Mnon_resp1 (where Mresp1.time < Mnon_resp2.time for each of
these response messages in Mnon_resp1) and x is not already
in P and there exists no OID in P that makes up a part
van den Broek, et al. Expires August 28, 2008 [Page 14]
Internet-Draft SNMP Trace Analysis Definitions February 2008
(starting from the beginning) of x.
TODO: The definition is not precise enough. Gijs posted a proposal
for a better definition, however it also has some issues. This needs
further discussion. Ideally, we would find a way to define this
which allows us to get rid of the pseudo code.
This definition states that all OIDs in the first non-response
message are considered part of the resulting slice prefix P. In
addition to that, P also contains those OIDs that have been newly
introduced in non-response messages (that occurred later than the
first one). Newly introduced OIDs are considered as such if they
were not included in any of the responses (that occurred before the
non-response message in consideration) to the chronologically last
preceding non-response message.
The following outlines a few lines of pseudo-code in which the
algorithm for determining the slice prefix of a particular slice is
summarized.
/*
* compute the prefix of a given slice
*/
getPrefix(Slice S)
{
Prefix p = {}; // prefix for this slice, initially empty
Message prevNonRespMsg; // previous non-response message
Message R[];
foreach Message M in S {
if (M.type == Response || M.type == Report) continue;
R = getLinkedPreviousResponseMessages(M, prevNonRespMsg);
foreach OID o in M.oids {
if (o NOT IN ANY R) { // test whether o is in any of
// the selected response messages
// to the previous non-response
// message
addPrefix(p, o);
}
}
prevNonRespMsg = M;
}
van den Broek, et al. Expires August 28, 2008 [Page 15]
Internet-Draft SNMP Trace Analysis Definitions February 2008
return p;
}
/*
* Retrieves the linked response message(s) to the previous non-response
* message (if any)
*/
getLinkedPreviousResponseMessages(Slice S, Message M,
Message prevNonRespMsg)
{
Message R[] = {}; // set of previous response messages
if (prevNonRespMsg) {
foreach Message M2 in S {
if (M2.time < M.time
&& M2.time > prevNonRespMsg.time
&& M2.reqid == prevNonRespMsg.reqid
&& M2.type == Response) R.add(M2);
}
}
return R;
}
/*
* add OID oto the prefix p if not yet present in the prefix p
*/
addPrefix(Prefix p, OID o)
{
foreach OID x in p {
if (x == o) return;
}
p.add(o);
}
Following is an example to illustrate the algorithm just described:
Consider the case that a single manager A polling an agent B. More
specifically, the manager A is programmed to retrieve the complete
contents of two single column tables alpha and beta. Besides that,
the manager now also requests the sysUpTime in the first request the
manager sends to B. A resulting slice may contain the following
messages:
van den Broek, et al. Expires August 28, 2008 [Page 16]
Internet-Draft SNMP Trace Analysis Definitions February 2008
-------------------------------------------------------------------
Message | Direction | PDU type | OIDs
-------------------------------------------------------------------
0 A -> B GetNext Request sysUpTime, alpha, beta
1 B -> A Response sysUpTime.0, alpha.0, beta.0
2 A -> B GetNext Request alpha.0, beta.0
3 B -> A Response alpha.1, beta.1
4 A -> B GetNext Request alpha.1, beta.1
5 B -> A Response gamma.0, delta.0
-------------------------------------------------------------------
Determining the slice prefix for this slice goes as follows:
At the start, the slice prefix P is empty. The algorithm starts
looking for the first non-response message, which is message 0.
Then, it tests the OIDs contained in message 0 for equality with any
OIDs in P. Since no matching OIDs can be found in P and the three
referenced OIDs in message 0 are all different, the algorithm adds
the three OIDs of message 0 to P.
The algorithm then goes on with the message 1, which is a response.
So it proceeds to look at message 2. Since message 2 contains only
OIDs that can be found in message 1 (a response to the previous non-
response), the algorithm will not consider the OIDs in message 2 any
further. The same goes for the remainder of the non-response
messages in this slice.
This example slice would therefore result in a slice prefix
consisting of the OID prefixes sysUpTime, alpha, beta.
Following is a more elaborate slice for which the slice prefix is
determined. Consider again the case that a single manager A is set
to poll a specific agent B. Manager A is programmed to retrieve some
values from B. However, in this case the referenced tables do not
have an equal length. Besides that, the manager also requests the
sysUpTime in every few requests the manager sends to B. The resulting
set of messages within a single slice of this flow may contain the
following messages:
van den Broek, et al. Expires August 28, 2008 [Page 17]
Internet-Draft SNMP Trace Analysis Definitions February 2008
-------------------------------------------------------------------
Message | Direction | PDU type | OIDs
-------------------------------------------------------------------
0 A -> B GetNext Request alpha, beta
1 B -> A Response alpha.0, beta.0
2 A -> B GetNext Request alpha, beta
3 B -> A Response alpha.0, beta.1
4 A -> B GetNext Request beta.1, alpha.0,
sysUpTime
5 B -> A Response gamma.0, alpha.1
sysUpTime.0
6 A -> B GetNext Request alpha.1
7 B -> A Response delta.0
-------------------------------------------------------------------
Determining the slice prefix for this slice goes as follows:
At the start, the slice prefix P is empty. Just as in the previous
example, the algorithm analyses the first non-response message
(message 0) first. Since P is empty at this point and the two OIDs
alpha and beta are different, the OIDs alpha and beta will be added
to P.
The second non-response message (message 2) contains two OIDs that
cannot be found in the response to the first non-response; they may
therefore be added to P. However, P already contains both OIDs, so
they will not be added. It should be noted here that this non-
response message is probably a retransmission of the first one.
Also, it appears that the response to this non-response yields a
different result compared to the response to the initial non-response
message. This may be caused by a change in the data at the agent
side.
Message 4 is the next non-response message. It contains three OIDs,
of which two are exactly the same compared to the previous response
message (message 3), even though the order is different. A third OID
(sysUpTime) in this message cannot be found in message 3, neither can
it be found in P. Hence, OID sysUpTime is added to P.
Message 6 is the last non-response message and contains just a single
OID that can also be found in message 5, the response to the previous
non-response message. Therefore, the single OID in message 6 is not
considered any further. It should be noted here that the data
retrieval process has apparently reached the end of the table with
OID beta, which has resulted in a response containing the
lexicographically next data item gamma.0.
After message 6 have all non-response messages been considered in
van den Broek, et al. Expires August 28, 2008 [Page 18]
Internet-Draft SNMP Trace Analysis Definitions February 2008
this slice. Even though the order of comparable OIDs within a
certain non-response and the previous response may be different (like
in non-response message 4 and response message 3), the listed
messages still comprise a single slice. The slice also shows the
possibility of a manager (A) referencing OIDs that are new compared
to a previous response message (like the sysUpTime OID in message 4).
This example slice therefore has a slice prefix P consisting of the
OIDs alpha, beta and sysUpTime.
van den Broek, et al. Expires August 28, 2008 [Page 19]
Internet-Draft SNMP Trace Analysis Definitions February 2008
7. Slice Type
As described previously, the slice type allows for comparing slices.
This means that any number of slices that are of the same slice type
may be considered an equivalence class and may therefore be
considered to be the result of the same behaviour of the slice
initiator.
Definition (slice equivalence): Two slices A and B satisfy the binary
slice equivalence relation A ~ B if the following properties hold:
(EQ1) All messages in A and B have been exchanged between the same
network endpoints.
(EQ2) All read request messages, write request messages, and
notification messages in A and B originate from the same
network endpoint.
(EQ3) All non-response messages in A and B are of the same type.
(EQ4) The slices A and B have the same prefix, that is A.prefix =
B.prefix.
It can be easily seen that the relation ~ is reflexive, symmetric,
and transitive and thus forms an equivalence relation between slices.
Definition (slice type): Let S be a set of slices, then all slices in
the equivalence class [A] = {s in S | s ~ A} with A in S, are of the
same slice type.
van den Broek, et al. Expires August 28, 2008 [Page 20]
Internet-Draft SNMP Trace Analysis Definitions February 2008
8. Walks
Definition (walk): A walk W is a slice S with the following
properties:
(W1) The type of the slice S is either get-next-request or get-
bulk-request.
(W2) At least one object identifier in the sequence of requests at
the same varbind index must be increasing lexicographically
while all object identifiers at the same varbind index have to
be non-decreasing.
Definition (strict walk): A walk W is a strict walk if all object
identifiers in the sequence of requests at the same varbind index are
strictly increasing lexicographically. Furthermore, the object
identifiers at the same index of a response and a subsequent request
must be identical.
Definition (prefix constrained walk): A walk W is a prefix
constrained walk if all object identifiers at the same index have the
same object identifier prefix. This prefix is established by the
first request within the walk.
van den Broek, et al. Expires August 28, 2008 [Page 21]
Internet-Draft SNMP Trace Analysis Definitions February 2008
9. Security Considerations
This document provides definitions for the analysis of SNMP traces
and does not impact the security of the Internet.
van den Broek, et al. Expires August 28, 2008 [Page 22]
Internet-Draft SNMP Trace Analysis Definitions February 2008
10. IANA Considerations
This document has no actions for IANA.
van den Broek, et al. Expires August 28, 2008 [Page 23]
Internet-Draft SNMP Trace Analysis Definitions February 2008
11. Acknowledgements
This document was influenced by discussions within the Network
Management Research Group (NMRG).
Part of this work was funded by the European Commission under grant
FP6-2004-IST-4-EMANICS-026854-NOE.
van den Broek, et al. Expires August 28, 2008 [Page 24]
Internet-Draft SNMP Trace Analysis Definitions February 2008
12. References
12.1. Normative References
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", RFC 3411,
December 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", RFC 3416,
December 2002.
12.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework", RFC 3410, December 2002.
[ID-IRTF-NMRG-SNMP-MEASURE]
Schoenwaelder, J., "SNMP Traffic Measurements and Trace
Exchange Formats", ID draft-irtf-nmrg-snmp-measure-03.txt,
February 2008.
[SPHSM07] Schoenwaelder, J., Pras, A., Harvan, M., Schippers, J.,
and R. van de Meent, "SNMP Traffic Analysis: Approaches,
Tools, and First Results", IFIP/IEEE Integrated
Management IM 2007, May 2007.
van den Broek, et al. Expires August 28, 2008 [Page 25]
Internet-Draft SNMP Trace Analysis Definitions February 2008
Authors' Addresses
Gijs van den Broek
University of Twente
P.O. BOX 217
7500 AE Enschede
Netherlands
Phone: +31 6 13506591
Email: j.g.vandenbroek@student.utwente.nl
Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
28725 Bremen
Germany
Phone: +49 421 200-3587
Email: j.schoenwaelder@jacobs-university.de
Aiko Pras
University of Twente
P.O. BOX 217
7500 AE Enschede
Netherlands
Phone: +31 53 4893778
Email: a.pras@cs.utwente.nl
Matus Harvan
ETH Zurich
ETH Zentrum
8092 Zurich
Switzerland
Phone: +41 44 632 68 76
Email: mharvan@inf.ethz.ch
van den Broek, et al. Expires August 28, 2008 [Page 26]
Internet-Draft SNMP Trace Analysis Definitions February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
van den Broek, et al. Expires August 28, 2008 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-24 06:08:38 |