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]