One document matched: draft-schoenw-nmrg-snmp-trace-definitions-00.txt
NMRG G. van den Broek
Internet-Draft University of Twente
Intended status: Informational J. Schoenwaelder
Expires: July 11, 2008 Jacobs University Bremen
A. Pras
University of Twente
M. Harvan
ETH Zurich
January 8, 2008
SNMP Trace Analysis Definitions
draft-schoenw-nmrg-snmp-trace-definitions-00.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 July 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
van den Broek, et al. Expires July 11, 2008 [Page 1]
Internet-Draft SNMP Trace Analysis Definitions January 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 - (more thoughts needed) . . . . . . . . . . . . 13
7. Slice Sets - (more thoughts needed) . . . . . . . . . . . . . 19
8. Walks - (more thoughts needed) . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
van den Broek, et al. Expires July 11, 2008 [Page 2]
Internet-Draft SNMP Trace Analysis Definitions January 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.
+----------------+ 1 1..* +-----------+
| Slice Set Type |------------| Slice Set |
+----------------+ <of_type +-----------+
| 1
|
| ^belongs_to
|
| 1..*
+-------+ 1 0..* +------+ 1 0..* +-------+
| Trace |------------| Flow |------------| Slice |
+-------+ contains> +------+ contains> +-------+
| 1 ^
| |
| ^belongs_to | ^is_a
| |
| 0..* |
+---------+ +-------+
| Message | | Walk |
+---------+ +-------+
van den Broek, et al. Expires July 11, 2008 [Page 3]
Internet-Draft SNMP Trace Analysis Definitions January 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 is 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 multiple
agents on a periodic basis. Therefore, multiple slices, which are
possibly part of multiple flows, may all be related to each other,
because they comprise a single polling instance, initiated by a
single manager. The combined set of these related slices form slice
sets.
The described manager might poll the same agent(s) on a periodic
basis (e.g., every few minutes). This would result in multiple
slices sets that are very similar to each other. In such a case,
van den Broek, et al. Expires July 11, 2008 [Page 4]
Internet-Draft SNMP Trace Analysis Definitions January 2008
these slice sets will be considered to be of the same slice set type.
Slices can be of a specific form. 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 July 11, 2008 [Page 5]
Internet-Draft SNMP Trace Analysis Definitions January 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 a 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 July 11, 2008 [Page 6]
Internet-Draft SNMP Trace Analysis Definitions January 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.
Note that 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 group notification
messages consists of all messages M satisfying either of the
following two conditions:
van den Broek, et al. Expires July 11, 2008 [Page 7]
Internet-Draft SNMP Trace Analysis Definitions January 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.
Note that we again require that the transport endpoints match for
notification group messages.
van den Broek, et al. Expires July 11, 2008 [Page 8]
Internet-Draft SNMP Trace Analysis Definitions January 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 for which the following holds:
(T1) Each messages M in T is either a non-response message or a
response message.
(T2) All messages M in T are chronologically ordered according to
the capture time stamp M.time.
van den Broek, et al. Expires July 11, 2008 [Page 9]
Internet-Draft SNMP Trace Analysis Definitions January 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 July 11, 2008 [Page 10]
Internet-Draft SNMP Trace Analysis Definitions January 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 be 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 a maximum time between two request messages
that belong to a slice. This parameter should be chosen such that
unrelated requests within a flow are considered to be of the same
slice. This might, for example, be the case where an agent never
responds to requests from a manager that is set to poll that agent on
a periodic basis.
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 July 11, 2008 [Page 11]
Internet-Draft SNMP Trace Analysis Definitions January 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 July 11, 2008 [Page 12]
Internet-Draft SNMP Trace Analysis Definitions January 2008
6. Slice Prefix - (more thoughts needed)
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
us 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, we can determine which slices should
be considered 'equal' and which of them are incomparable. This will
assist in the process of finding other relations later on.
The slice prefix will represent a set of referenced OID prefixes.
Such a 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 (alpha) on an agent
using a simple GetNext walk starting at the table node alpha, shall
yield a slice prefix which consists of just alpha.
Because we want to compare different slices using the slice prefix
(along some other characteristics of a slice), we implicitly want to
know whether a number of slices are the result of the same behaviour
from the initiating party of these slices. For example, we want to
know whether a slice initiated by a specific manager is the result of
a specific configuration of that manager which polls one or more
agents. As a result multiple slices, that may all be initiated by
that same manager and possibly in different polling instances, may in
fact be the result of the same programmed behaviour of that
particular manager. Hence, we only consider the messages within
slices that are sent by the initiating party: the non-response
messages. Subsequently, these non-response messages shall be
analyzed in order to determine the proper resulting set of common OID
prefixes for that slice.
The resulting set of OID prefixes will represent the purpose of that
slice, allowing us to compare different slices for equality/
comparability.
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
slice. This set P consists of the following OIDs:
van den Broek, et al. Expires July 11, 2008 [Page 13]
Internet-Draft SNMP Trace Analysis Definitions January 2008
(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
(starting from the beginning) of x.
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) { // XXX clarify this?
reducePrefix(p, o);
addPrefix(p, o);
}
}
prevNonRespMsg = M;
}
return p;
}
/*
* Retrieves the linked response message(s) to the previous non-response
* message (if any)
*/
getLinkedPreviousResponseMessages(Slice S, Message M,
Message prevNonRespMsg)
{
van den Broek, et al. Expires July 11, 2008 [Page 14]
Internet-Draft SNMP Trace Analysis Definitions January 2008
Message R[] = {}; // set of previous response messages
if (prevNonRespMsg) {
foreach Message M2 in S {
if (M2.time < M.time
&& M2.time > prevNonResponse.time
&& M2.reqid == prevNonResponse.reqid
&& M2.type == Response) R.add(M2);
}
}
return R;
}
/*
* reduce prefix p given a new prefix OID o
*/
reducePrefix(Prefix p, OID o)
{
foreach OID x in p {
if (|o| < |x| && o[i] == x[i] for i=1,...,|o|) {
p.remove(x);
}
}
}
/*
* add new prefix OID o if not yet present in the prefix p
*/
addPrefix(Prefix p, OID o)
{
foreach OID x in p {
if (|x| < |o| && x[i] == o[i] for i=1,...,|x|) return;
}
p.add(o);
}
Following is an example to illustrate the algorithm just described:
Consider the case that a single manager A is set to poll a specific
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 also requests the sysUpTime in the first
request 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 July 11, 2008 [Page 15]
Internet-Draft SNMP Trace Analysis Definitions January 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
-------------------------------------------------------------------
These six messages make up a single slice. Determining the slice
prefix for this slice goes as follows:
At the start the set of found common OID prefixes P is still empty.
The algorithm starts looking for the first non-response message,
which is message 0. It then attempts to find the response messages
that happened before message 0, that are the result of the previous
non-response message. At this stage, no other response can be found,
because message 0 is the first request of this slice. Then, the
algorithm attempts to find larger OIDs in P that can also be found in
message 0 (like for instance 1.3.6.1 is larger than 1.3.6). This is
not the case, so it carries on with testing the OIDs in P for
equality with any of the OIDs in message 0. No matching OIDs can be
found, which in turn results in the algorithm adding the three OIDs
of message 0 to P.
The algorithm then goes on with the second message, which is a
response, so it goes to the third message. Since this message
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 July 11, 2008 [Page 16]
Internet-Draft SNMP Trace Analysis Definitions January 2008
-------------------------------------------------------------------
Message | Direction | PDU type | OIDs
-------------------------------------------------------------------
0 A -> B GetNext Request alpha.1, beta.1
1 B -> A Response alpha.1.0, beta.1.0
2 A -> B GetNext Request alpha, beta.1.0
3 B -> A Response alpha.0.0, beta.1.1
4 A -> B GetNext Request beta.1.1, alpha.0.0,
sysUpTime
5 B -> A Response beta.1.2, alpha.1.0,
sysUpTime.0
6 A -> B GetNext Request beta.1.2
7 B -> A Response delta.0
-------------------------------------------------------------------
These eight messages make up a single slice. Determining the slice
prefix for this slice goes as follows:
At the start the set of found common OID prefixes P is still empty.
Just as in the previous example, the algorithm analyses the first
non-response (message 0) first. Since P is empty at this point and
earlier response messages cannot be found that occurred before
message 0, the two OIDs of message 0 will be added to P.
The second non-response message (message 2) contains one OID
(beta.1.0) That can also be found in the response to the first
request; it is therefore not considered any further. The other OID
in message 2 is newly introduced. Also, this OID is a prefix of an
already listed OID in P: alpha.1. As a result, alpha.1 will be
removed from P and OID alpha will be inserted into P. So, after the
algorithm has completed considering message 2, P will contain the
common OID prefixes alpha and beta.1.
Message 4 is the next non-response message. This message contains
three OIDs, of which two are exactly the same, even though the order
is different, compared to the previous response message (message 3).
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.
After message 6 have all non-response messages been considered in
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
van den Broek, et al. Expires July 11, 2008 [Page 17]
Internet-Draft SNMP Trace Analysis Definitions January 2008
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 would therefore result a slice prefix P consisting
of the OID prefixes alpha, beta.1 and sysUpTime.
van den Broek, et al. Expires July 11, 2008 [Page 18]
Internet-Draft SNMP Trace Analysis Definitions January 2008
7. Slice Sets - (more thoughts needed)
Definition (slice type): A slice type is a type mark identifying
slices that share the following properties:
(ST1) All messages have been exchanged between the same transport
endpoints.
(ST2) All read request messages, write request messages, and
notification messages originate from the same transport
endpoint.
(ST3) All non-response messages are of the same type
[TODO: Should this be an equivalence relation so that slice sets turn
into equivalent classes?]
Definition (slice set): A slice set is a set of slices that have the
following properties:
(SS1) All READ, WRITE, NOTIFY messages originate from the same
transport endpoint. (really transport???)
(SS2) ???
(SS3) All messages occurred within a specific time frame of each
other. (what does this mean??? do we need delta serial for
messages???)
van den Broek, et al. Expires July 11, 2008 [Page 19]
Internet-Draft SNMP Trace Analysis Definitions January 2008
8. Walks - (more thoughts needed)
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 prefix constrained
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 July 11, 2008 [Page 20]
Internet-Draft SNMP Trace Analysis Definitions January 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 July 11, 2008 [Page 21]
Internet-Draft SNMP Trace Analysis Definitions January 2008
10. IANA Considerations
This document has no actions for IANA.
van den Broek, et al. Expires July 11, 2008 [Page 22]
Internet-Draft SNMP Trace Analysis Definitions January 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 July 11, 2008 [Page 23]
Internet-Draft SNMP Trace Analysis Definitions January 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-02.txt,
December 2007.
[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 July 11, 2008 [Page 24]
Internet-Draft SNMP Trace Analysis Definitions January 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 July 11, 2008 [Page 25]
Internet-Draft SNMP Trace Analysis Definitions January 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 July 11, 2008 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-24 06:08:48 |