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 | +----------------+ +------+ 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]