PSAMP working group Internet Draft EDITOR: B. Claise draft-ietf-psamp-protocol-02.txt Cisco Systems Expires: April 2006 October 2005 Packet Sampling (PSAMP) Protocol Specifications 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 April 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Colleting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The Claise, et. al Standard Track [Page 1]
PSAMP Protocol Specifications October 2005 document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Points of Discussion........................................3 1.1 Open Issues................................................3 1.2 Action Items...............................................4 2. Introduction................................................5 3. PSAMP Documents Overview....................................5 4. Terminology.................................................6 4.1 IPFIX Terminology..........................................6 4.2 PSAMP Terminology.........................................10 4.2.1 Observation Points, Packet Streams and Packet Content11 4.2.2 Selection Process....................................11 4.2.3 Reporting Process....................................13 4.2.4 Measurement Process..................................13 4.2.5 Exporting Process....................................14 4.2.6 PSAMP Device.........................................14 4.2.7 Selection Methods....................................14 4.3 IPFIX and PSMAP Terminology Comparison....................16 4.3.1 PSAMP and IPFIX Processes............................16 4.3.2 Packet Report, Packet Interpretation, and Data Record17 5. Differences between PSAMP and IPFIX........................17 5.1 Architecture Point of View................................17 5.2 Protocol Point of View....................................19 5.3 Information Model Point of View...........................19 6. PSAMP Requirements versus the IPFIX Solution...............20 6.1 IPFIX Solution for the PSAMP Requirements.................20 6.2 High Level View of the Integration........................22 7. Using the IPFIX Protocol for PSAMP.........................23 7.1 Selector ID...............................................23 7.2 The Associations..........................................23 7.3 Packet Reports............................................23 7.3.1 Basic Packet Reports.................................23 7.3.2 Extended Packet Reports..............................25 7.4 Report Interpretation.....................................26 7.4.1 Associations Report Interpretation...................26 7.4.2 Selector Report Interpretation.......................29 7.4.2.1 Systematic Count-Based Sampling......................29 7.4.2.2 Systematic Time-Based Sampling.......................30 7.4.2.3 Random n-out-of-N Sampling...........................31 7.4.2.4 Uniform Probabilistic Sampling.......................33 Claise, et. al Standard Track [Page 2]
PSAMP Protocol Specifications October 2005 7.4.2.5 Non-uniform Probabilistic Sampling...................33 7.4.2.6 Non-uniform Flow State Sampling......................33 7.4.2.7 Match Based Filtering and Router State Filtering.....33 7.4.2.8 Hash Based Filtering.................................35 7.4.3 Associations Statistics Report Interpretation........35 7.4.4 Accuracy Report Interpretation.......................37 7.4.5 Observation Point Report Interpretation..............37 8. Security Considerations....................................37 9. IANA Considerations........................................38 10. References................................................38 10.1 Normative References.....................................38 10.2 Informative References...................................38 11. Acknowledgments...........................................38 1. Points of Discussion 1.1 Open Issues This section covers the open issues, still to be resolved/updated in this draft: PROTO-01 [PSAMP-FMWK] mentions the optional Export Packets compression (see section 8.5) Should we mention this in this document? PROTO-02 From a protocol point of view, there a no differences between the Field Match Filtering and the Router State Filtering as defined in [PSAMP-TECH]. The only difference concerns the I.E. on which we do the filtering... part of the packet in one case, not part of the packet in the other case. Proposal: merge the 2 methods in [PSAMP-TECH] PROTO-03 The second open issue is concerned with reporting the sequential order of sampling and filtering. => order of the scope. We spot a new problem: we could export twice the hash value. How to distinguish them? How to know that the hash value 1 corresponds to a specific definition specified in an Option Template. PROTO-04 Should probably have a separate section for the examples? PROTO-05 Transport protocol: SCTP and/or UDP and/or TCP. Nothing is mentioned at this stage. [PSAMP-FMWK] and PSAMP charter specifically mention UDP. PROTO-06 Even if the notion of Associations ID is mentioned in [PSAMP-TECH], maybe a term such as SelectionPath or PathID would be more appropriate. Claise, et. al Standard Track [Page 3]
PSAMP Protocol Specifications October 2005 PROTO-07 Even if [PSAMP-TECH] section 7.1 and 7.2 describes that "The ASSOCIATIONS field describes the Observation Point and optionally the IPFIX processes to which the packet Selector is associated. Values: <STREAM ID, IPFIX Metering process ID, IPFIX Exporting process ID, IDs of other associated processes>", we can't see an example where the IPFIX process(es) ID would be required. Don't we have enough with the list of Selector IDs? PROTO-08 Instead of sending the input sequence number for each selector ID, a counter64 value, associated with every packet, the working group should discuss the possibility to send the information on regular basis with an option template record. Specifically in the case of Composite Selector, we would send multiple times a 64-bit counter in each packet. PROTO-09 "The algorithm specific Information Elements, defining configuration parameters for match-based and router state filtering, are taken from the full range of available IPFIX Information Elements [IPFIX-INFO]". What about the ones from [PSAMP-INFO]? In other words, are they I.E.s in [PSAMP-INFO] that we could use for the match-based and router state filtering? PROTO-10 We probably don't need the section 6.2 named "High Level view of the integration", as this section was an intermediate step in an interim version of the draft. To be discussed. PROTO-11 Discuss how to implement the accuracy report interpretation PROTO-12 Discuss how to implement the observation point report interpretation (if we need one) PROTO-13 The solution in this document is based on the fact that https://psg.com/lists/psamp/psamp.2005/msg00050.html is taken into account. That means: no range for the filtering 1.2 Action Items PROTO-101 See EDITOR'S NOTE PROTO-102 insert double spaces after the end of each sentence. PROTO-103 Should briefly discuss the fact that PSAMP is OK with IPFIX requirements in terms of time (uSec precision) PROTO-104 Fix the terminology sections, as a last step before publication Claise, et. al Standard Track [Page 4]
PSAMP Protocol Specifications October 2005 PROTO-105 Section 6 about "PSAMP requirements": check if any changes with the version 5 of [PSAMP-FMWK]. This draft is based on ietf- psamp-framework-04.txt. PROTO-106 Extend security considerations by a discussion on exported Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both is/are the place(s). PROTO-107 All the examples in section 7 should contain the Information Element ID instead of the Information Element name. Example: Option 3 = samp.PacketSpace Corrected Example: Option 3 = 305 2. Introduction The name PSAMP is a contraction of the phrase Packet SAMPling. The word "sampling" captures the idea that only a subset of all packets passing a network element will be selected for reporting. PSAMP selection operations include random selection, deterministic selection (filtering), and deterministic approximations to random selection (hash-based selection). The IP Flow information export (IPFIX) protocol specified in [IPFIX- PROTO] exports IP traffic information [IPFIX-INFO] observed at network devices. This matches the general protocol requirements outlined in the PSAMP framework [PSAMP-FMWK]. However, there are some architectural differences between IPFIX and PSAMP in the requirements for an export protocol. While the IPFIX architecture [IPFIX-ARCH] is focused on gathering and exporting IP traffic flow information, the focus of the PSAMP framework [PSAMP-FMWK] is on exporting information on individual packets. This basic difference and a set of derived differences in protocol requirements are outlined in Section 5. Despite these differences, the IPFIX protocol is well suited as PSAMP protocol. Section 5 specifies how the IPFIX protocol is used for the export of packet samples. Required extensions of the IPFIX information model are specified in the PSAMP information model [PSAMP-INFO]. 3. PSAMP Documents Overview [PSAMP-FMWK]: "A Framework for Packet Selection and Reporting", describes the PSAMP framework for network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a collector. Claise, et. al Standard Track [Page 5]
PSAMP Protocol Specifications October 2005 [PSAMP-TECH]: "Sampling and Filtering Techniques for IP Packet Selection", describes the set of packet selection techniques supported by PSAMP. [PSAMP-PROTO]: "Packet Sampling (PSAMP) Protocol Specifications" (this document), specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Colleting Process [PSAMP-INFO]: "Information Model for Packet Sampling Exports" defines an information and data model for PSAMP. [PSAMP-MIB]: "Definitions of Managed Objects for Packet Sampling" describes the PSAMP Management Information Base 4. Terminology As the IPFIX export protocol is used to export the PSAMP information, the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in this document. The terminology summary table in section 4.1 gives a quick overview of the relationships between the different IPFIX terms. The PSAMP terminology defined here is fully consistent with all terms listed in [PSAMP-TECH] and [PSAMP-FMWK] but only definitions that are only relevant to the PSAMP protocol appear here. The section 5.4 applies the PSAMP terminology to the IPFIX protocol terminology. 4.1 IPFIX Terminology EDITOR'S NOTE: The terminology has been entirely copied over from [IPFIX-PROTO]. Before publication, we should evaluate which terms should be kept, if not all. The ones required for sure so far are: Flow Record, Flow, Information Element, Metering Process, Collector, Scope, Set, Template Record, Data Record, Data Set, Template Set, Template Record(s), Options Template Set, Options Template Record. Note: the IPFIX Exporting Process was not used, as the PSAMP Exporting Process is more specific. Observation Point An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. Note that every Observation Point is associated with an Observation Domain (defined below), and that one Observation Point may be a Claise, et. al Standard Track [Page 6]
PSAMP Protocol Specifications October 2005 superset of several other Observation Points. For example one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces. Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. Each Observation Domain presents itself using a unique ID to the Collecting Process to identify the IPFIX Messages it generates. For example, a router line card may be an observation domain if it is composed of several interfaces, each of which is an Observation Point. Every Observation Point is associated with an Observation Domain. IP Traffic Flow or Flow There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition: A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1. one or more packet header field (e.g. destination IP address), transport header field (e.g. destination port number), or application header field (e.g. RTP header fields [RFC1889]) 2. one or more characteristics of the packet itself (e.g. number of MPLS labels, etc...) 3. one or more of fields derived from packet treatment (e.g. next hop IP address, the output interface, etc...) A packet is defined to belong to a Flow if it completely satisfies all the defined properties of the Flow. This definition covers the range from a Flow containing all packets observed at a network interface to a Flow consisting of just a single packet between two applications. It includes packets selected by a sampling mechanism. Flow Key Each of the fields which Claise, et. al Standard Track [Page 7]
PSAMP Protocol Specifications October 2005 1. Belong to the packet header (e.g. destination IP address) 2. Are a property of the packet itself (e.g. packet length) 3. Are derived from packet treatment (e.g. AS number) and which are used to define a Flow are termed Flow Keys. Flow Record A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g. the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g. source IP address). Metering Process The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example the selected output interface). The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. Exporter A device which hosts one or more Exporting Processes is termed an Exporter. IPFIX Device An IPFIX Device hosts at least one Observation Point, a Metering Process and an Exporting Process. Collecting Process A Collecting Process receives Flow Records from one or more Exporting Processes. The Collecting Process might process or store received Flow Records, but such actions are out of scope for this document. Collector Claise, et. al Standard Track [Page 8]
PSAMP Protocol Specifications October 2005 A device which hosts one or more Collecting Processes is termed a Collector. Template Template is an ordered sequence of <type, length> pairs, used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID. IPFIX Message An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer. Message Header The Message Header is the first part of an IPFIX Message, which provides basic information about the message such as the IPFIX version, length of the message, message sequence number, etc. Template Record A Template Record defines the structure and interpretation of fields in a Data Record. Data Record A Data Record is a record that contains values of the parameters corresponding to a Template Record. Options Template Record An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record. Set Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header. There are three different types of Sets: Template Set, Options Template Set, and Data Set. Claise, et. al Standard Track [Page 9]
PSAMP Protocol Specifications October 2005 Template Set A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message. Options Template Set An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message. Data Set A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record. Information Element An Information Element is a protocol and encoding independent description of an attribute which may appear in an IPFIX Record. The IPFIX information model [IPFIX-INFO] defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX. +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template | Record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ Figure A: Terminology Summary Table 4.2 PSAMP Terminology EDITOR'S NOTE: The terminology has been entirely copied over from [PSAMP-TECH], except for some (almost) similar terms where only the IPFIX terms were kept (for example, observation point). Before publication, we should evaluate which terms should be kept. The ones required for sure so far are: Selector, Composite Selector, Packet Claise, et. al Standard Track [Page 10]
PSAMP Protocol Specifications October 2005 Reports, Packet Interpretation, PSAMP device, Collector, Filtering, Sampling. Note that the terms Selector ID and Association ID, coming from [PSAMP-FMWK], has been added in the Selection Process section. 4.2.1 Observation Points, Packet Streams and Packet Content Observed Packet Stream The Observed Packet Stream is the set of all packets observed at the Observation Point. Packet Stream A packet stream denotes a subset of the Observed Packet Stream that flows past some specified point within the measurement process. An example of a Packet Stream is the output of the selection process. Packet Content The packet content denotes the union of the packet header (which includes link layer, network layer and other encapsulation headers) and the packet payload. 4.2.2 Selection Process Selection Process A Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output. Selection State A Selection Process may maintain state information for use by the Selection Process and/or the reporting process. At a given time, the Selection State may depend on packets observed at and before that time, and other variables. Examples include: (i) sequence numbers of packets at the input of Selectors; (ii) a timestamp of observation of the packet at the Observation Point; (iii) iterators for pseudorandom number generators; (iv) hash values calculated during selection; Claise, et. al Standard Track [Page 11]
PSAMP Protocol Specifications October 2005 (v) indicators of whether the packet was selected by a given Selector; Selection Processes may change portions of the Selection State as a result of processing a packet. Selection state for a packet is to reflect the state after processing the packet. Selector A Selector defines the action of a Selection Process on a single packet of its input. If selected, the packet becomes an element of the output Packet Stream. The Selector can make use of the following information in determining whether a packet is selected: (i) the packet's content; (ii) information derived from the packet's treatment at the Observation Point; (iii) any selection state that may be maintained by the Selection Process. Composite Selector A Composite Selector is an ordered composition of Selectors, in which the output Packet Stream issuing from one Selector forms the input Packet Stream to the succeeding Selector. Primitive Selector A Selector is primitive if it is not a Composite Selector. Selector ID The Selector ID is the unique ID identifying a Primitive Selector. Associations ID From all the packets observed at an Observation Point, only a few packets are selected by one or more Selectors. The Associations ID is a unique value describing the Observation Point and the Selector IDs through which the packets are selected. The Associations ID is represented by the associationsID Information Element [PSAMP-INFO]. Claise, et. al Standard Track [Page 12]
PSAMP Protocol Specifications October 2005 4.2.3 Reporting Process Reporting Process A Reporting Process creates a Report Stream on packets selected by a Selection Process, in preparation for export. The input to the Reporting Process comprises that information available to the Selection Process per selected packet, specifically: (i) the selected packet's content; (ii) information derived from the selected packet's treatment at the Observation Point; (iii) any Selection State maintained by the inputting Selection Process, reflecting any modifications to the Selection State made during selection of the packet. Packet Reports Packet Reports comprise a configurable subset of a packet's input to the reporting process, including the packet's content, information relating to its treatment (for example, the output interface), and its associated selection state (for example, a hash of the packet's content) Report Interpretation: Report Interpretation comprises subsidiary information, relating to one or more packets, that is used for interpretation of their packet reports. Examples include configuration parameters of the Selection Process and of the Reporting Process. Report Stream: The Report Stream is the output of a Reporting Process, comprising two distinguished types of information: Packet Reports, and Report Interpretation. 4.2.4 Measurement Process Measurement Process A Measurement Process is the composition of a Selection Process that takes the Observed Packet Stream as its input, followed by a Reporting Process. Claise, et. al Standard Track [Page 13]
PSAMP Protocol Specifications October 2005 4.2.5 Exporting Process Exporting Process: An Exporting Process sends, in the form of Export Packet, the output of one or more Measurement Processes to one or more Collectors. Export Packet: An Export Packet is a combination of Report Interpretation and/or one or more Packet Reports are bundled by the Exporting Process into a Export Packet for exporting to a Collector. 4.2.6 PSAMP Device PSAMP Device A PSAMP Device is a device hosting at least an Observation Point, a Measurement Process and an Exporting Process. Typically, corresponding Observation Point(s), Measurement Process(es) and Exporting Process(es) are co-located at this device, for example at a router. 4.2.7 Selection Methods Filtering A filter is a Selector that selects a packet deterministically based on the Packet Content, or its treatment, or functions of these occurring in the Selection State. Examples include field match Filtering, and Hash-based Selection. Sampling A Selector that is not a filter is called a Sampling operation. This reflects the intuitive notion that if the selection of a packet cannot be determined from its content alone, there must be some type of Sampling taking place. Content-independent Sampling A Sampling operation that does not use Packet Content (or quantities derived from it) as the basis for selection is called a Content- independent Sampling operation. Examples include systematic Sampling, and uniform pseudorandom Sampling driven by a pseudorandom number whose generation is independent of Packet Content. Note that Claise, et. al Standard Track [Page 14]
PSAMP Protocol Specifications October 2005 in Content-independent Sampling it is not necessary to access the Packet Content in order to make the selection decision. Content-dependent Sampling A Sampling operation where selection is dependent on Packet Content is called a Content-dependent Sampling operation. Examples include pseudorandom selection according to a probability that depends on the contents of a packet field. Note that this is not a filter, because the selection is not deterministic. Hash Domain A subset of the Packet Content and the packet treatment, viewed as an N-bit string for some positive integer N. Hash Range A set of M-bit strings for some positive integer M that define the range of values the result of the hash operation can take. Hash Function A deterministic map from the Hash Domain into the Hash Range. Hash Selection Range A subset of the Hash Range. The packet is selected if the action of the Hash Function on the Hash Domain for the packet yields a result in the Hash Selection Range. Hash-based Selection Filtering specified by a Hash Domain, a Hash Function, and Hash Range and a Hash Selection Range. Approximative Selection Selectors in any of the above categories may be approximated by operations in the same or another category for the purposes of implementation. For example, uniform pseudorandom Sampling may be approximated by Hash-based Selection, using a suitable Hash Function and Hash Domain. In this case, the closeness of the approximation depends on the choice of Hash Function and Hash Domain. Population A Population is a Packet Stream, or a subset of a Packet Stream. A Population can be considered as a base set from which packets are Claise, et. al Standard Track [Page 15]
PSAMP Protocol Specifications October 2005 selected. An example is all packets in the Observed Packet Stream that are observed within some specified time interval. Population Size The Population Size is the number of all packets in the Population. Sample Size The number of packets selected from the Population by a Selector. Configured Selection Fraction The Configured Selection Fraction is the ratio of the number of packets selected by a Selector from an input Population, to the Population Size, as based on the configured selection parameters. Attained Selection Fraction The Attained Selection Fraction is the actual ratio of the number of packets selected by a Selector from an input Population, to the Population Size. For some sampling methods the Attained Selection Fraction can differ from the Configured Selection Fraction due to, for example, the inherent statistical variability in sampling decisions of probabilistic Sampling and Hash-based Selection. Nevertheless, for large Population Sizes and properly configured Selectors, the Attained Selection Fraction usually approaches the Configured Selection Fraction. 4.3 IPFIX and PSMAP Terminology Comparison EDITOR'S NOTE: Some terms between IPFIX and PSAMP were almost similar but not quite: - observation point. I kept the one from IPFIX. However, if the PSAMP/IPFIX definitons would be aligned, it would better. - exporting process. I kept the one from PSAMP - Collector: I kept the one from IPFIX, which implies that I used the Collecting Process defined in IPFIX (it speaks about flows, but there is no PSAMP Collecting Process definition) The PSAMP terminology has been specified with an IPFIX background, as PSAMP and IPFIX have similar terms. However, this section explains a couple of non compatible terms between IPFIX and PSAMP. 4.3.1 PSAMP and IPFIX Processes Claise, et. al Standard Track [Page 16]
PSAMP Protocol Specifications October 2005 The figure B indicates the sequence of the three processes (selection, reporting, and exporting) within the PSAMP Device. The composition of the Selection Process followed by the Reporting Process is known as the Measurement Process. +---------+ +---------+ +---------+ Observed |Selection| |Reporting| |Exporting| Packet--->|Process |--->|Process |--->|Process |--->Collector Stream +---------+ +---------+ +---------+ \----Measurement Process-----/ Figure B: PSAMP Processes The PSAMP Measurement Process can be viewed as analogous to the IPFIX Metering Process. The PSAMP Measurement Process takes an Observed Packet Stream as its input, and produces Packet Reports as its output. The IPFIX Metering Process produces Flow Records as its output. The distinct name "Measurement Process" has been retained in PSAMP in order to avoid potential confusion in settings where IPFIX and PSAMP coexist, and in order to avoid the implicit requirement that the PSAMP version satisfy the requirements of an IPFIX Metering Process. 4.3.2 Packet Report, Packet Interpretation, and Data Record The PSAMP terminology speaks of Packet Report and Packet Interpretation, while the IPFIX terminology speaks of Data Record and (Option) Template Record. The Packet Report, which comprises information about the observed packet, can be viewed as analogous to the Data Record defined by a Template Record. The Packet Interpretation, which comprises subsidiary information used for the interpretation of the packet reports, can be viewed as analogous to the Data Record defined by an Option Template Record. 5. Differences between PSAMP and IPFIX The output of the IPFIX working group relevant for this draft is structured into three documents: - IP Flow information architecture [IPFIX-ARCH] - IPFIX Protocol Specifications [IPFIX-PROTO] - IP Flow information export information model [IPFIX-INFO] 5.1 Architecture Point of View Traffic Flow measurement as described in the IPFIX requirements [RFC3917] and the IPFIX architecture [IPFIX-ARCH] can be separated into two stages: packet processing and Flow processing. The figure C illustrates these stages. Claise, et. al Standard Track [Page 17]
PSAMP Protocol Specifications October 2005 On stage 1, all processing steps act on packets. Packets are captured, time stamped, selected by one or more selection steps and finally forwarded to packet classification that maps packets to Flows. The packets selection steps may include filtering and sampling functions. On stage 2, all processing steps act on Flows. After packets are classified (mapped to Flows), Flows are generated, or updated if they exist already. Flow generation and update steps may be performed repeatedly for aggregating Flows. Finally, Flows are exported. Packet sampling as described in the PSAMP framework [PSAMP-FMWK] covers only stage 1 of the IPFIX architecture with the packet classification replaced by packet record export. IPFIX architecture PSAMP framework packet header packet header capturing \ capturing | | | timestamping | timestamping | | | v | v +------>+ | stage 1: +------>+ | | > packet | | | packet | processing | packet | selection | | selection | | | | | +-------+ | +-------+ | | | v | v packet / packet record classification \ export | | v | +------>+ | | | | | Flow generation | | and update | stage 2: | | > Flow | v | processing | Flow | | selection | | | | +-------+ | | | v | Claise, et. al Standard Track [Page 18]
PSAMP Protocol Specifications October 2005 Flow Record / export Figure C: Comparison of IPFIX architecture and PSAMP framework 5.2 Protocol Point of View Concerning the protocol, the major difference between IPFIX and PSAMP is that the IPFIX protocol exports Flow Records while the PSAMP protocol exports packet records. From a pure export point of view, IPFIX will not distinguish a Flow Record composed of several packets aggregated together, from a Flow Record composed of a single packet. So the PSAMP export can be seen as special IPFIX Flow Record containing information about a single packet. All extensions of the IPFIX protocol that are required to satisfy the PSAMP requirements, have already been incorporated in the IPFIX protocol [IPFIX-PROTO], which was developed in parallel with the PSAMP protocol. An example is the need of a data type for protocol fields that have flexible length, such as an octet array. This was added to the IPFIX protocol specification in order to meet the requirement of the PSAMP protocol to report content of captured packets, for example the first octets of a packet. 5.3 Information Model Point of View From the information model point of view, the overlap between both the IPFIX and PSAMP protocols is quite large. Most of the data fields in the IPFIX protocol are also relevant for exporting packet information, for example all fields reporting packet header properties. Only a few fields, such as flowCount, packetCount (whose value will always be 1 for PSAMP) etc., cannot be used in a meaningful way by the PSAMP protocol. Also, IPFIX protocol requirements concerning stage 2 of figure C do not apply to the PSAMP metering process. Further required extensions apply to the information model. Even if the IPFIX charter speaks of sampling, no sampling related Information Elements are specified in [IPFIX-INFO]. The task of specifying them was intentionally left for the PSAMP information model. A set of several additional fields is required for satisfying the requirements for the PSAMP information model [PSAMP-TECH]. Additional required extensions of the information model concern packet filtering, and the field reporting content of a packet using the flexible length data type mentioned above. Claise, et. al Standard Track [Page 19]
PSAMP Protocol Specifications October 2005 Exploiting the extensibility of the IPFIX information model, the required extension is covered by the PSAMP information model specified in [PSAMP-INFO]. 6. PSAMP Requirements versus the IPFIX Solution [PSAMP-FMWK] describes some requirements that affect directly the export protocol. Refer to the following sections: . section 3.2 "Reporting Process Requirements" . section 3.3 "Exporting Process Requirements" . section 5 "Reporting Process" [PSAMP-FMWK] also describes in the section 3.1 one requirement that, if not directly related to the export protocol, will put some constraints on it: Selection Process Requirements: - Parallel Measurements: multiple independent measurement processes at the same entity." [PSAMP-FMWK] finally describes in the section 5 some requirements regarding the reporting process. This series of requirements specifies the different Information Elements that MUST and SHOULD reported to the Collector. Nevertheless IPFIX, being a generic export protocol, can export any Information Elements as long as there are described in the information model. So these requirements are mainly targeted for the [PSAMP-INFO] document. 6.1 IPFIX Solution for the PSAMP Requirements Let's address the PSAMP requirements one by one. * Parallel Measurements: multiple independent measurement processes at the same entity. Refer to [PSAMP-FMWK] section 3.1 "Selection Process Requirements". This requirement is addressed by exporting the Associations ID Information Element in every packet report. Note that without this requirement, exporting the Selector ID in a Scope part of every single packet report could have been sufficient. * Transparency: allow transparent interpretation of measurements as communicated by PSAMP reporting, without any need to obtain additional information concerning the observed packet stream. Refer to [PSAMP-FMWK] section 3.2 "Reporting Process Requirements". This requirement is addressed by exporting the Associations ID Information Element in every Packet Report (a Data Record specified in Template Record) and exporting the associated selection algorithm Claise, et. al Standard Track [Page 20]
PSAMP Protocol Specifications October 2005 and selection parameters Information Elements in the Packet Interpretation (a Data Record specified in Options Template Record). * Robustness to Information Loss: allow robust interpretation of measurements with respect to reports missing due to data loss, e.g. in transport, or within the measurement, reporting or Exporting Processes. Inclusion in reporting of information that enables the accuracy of measurements to be determined. Refer to [PSAMP-FMWK] section 3.2 "Reporting Process Requirements". An Options Template, with updated statistics, MUST be sent on regular basis. This Options Template contains for example the total number of packet report exported from the PSAMP device, the total number of packet observed, etc... Thus the Collector can compare the number of packet report received per selector ID with the number actually metered and/or sent. In case of discrepancy, a new sampling rate could be computed. * Faithfulness: all reported quantities that relate to the packet treatment MUST reflect the router state and configuration encountered by the packet at the time it is received by the measurement process. Refer to [PSAMP-FMWK] section 3.2 "Reporting Process Requirements". This requirement doesn't concern the export protocol itself but the Metering Process, even if described in the "Reporting Process Requirements" section. * Privacy: selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804. Full packet capture of arbitrary packet streams is explicitly out of scope. Refer to [PSAMP-FMWK] section 3.2 "Reporting Process Requirements". This requirement doesn't concern the export protocol itself, even if described in the "Reporting Process Requirements" section. * Timeliness: reports on selected packets MUST be made available to the Collector quickly enough to support near real time applications. Specifically, any report on a packet MUST be dispatched within 1 second of the time of receipt of the packet by the measurement process. Refer to [PSAMP-FMWK] section 3.3 "Export Process Requirements". EDITOR'S NOTE: the term "dispatched" is not clear. Does it mean sent from the Metering Processing to the Exporting Process? Or put into a packet by the Exporting Process? Or written on the wire? Claise, et. al Standard Track [Page 21]
PSAMP Protocol Specifications October 2005 The IPFIX protocol specifications [IPFIX-PROTO] describe an inactivity timeout for the Flow expiration. This inactivity timeout is configurable, with a minimum value of 0 for immediate expiration. Note that this minimum value of 0 will force every single Data Record to contain information about a single packet and not an aggregation of packets. * Congestion Avoidance: export of a report stream across a network MUST be congestion avoiding in compliance with RFC 2914. Refer to [PSAMP-FMWK] section 3.3 "Export Process Requirements". IPFIX, by its charter, MUST also respect this requirement. * Secure Export: - confidentiality: the option to encrypt exported data MUST be provided. - integrity: alterations in transit to exported data MUST be detectable at the Collector - authenticity: authenticity of exported data MUST be verifiable by the Collector in order to detect forged data. The motivation here is the same as for security in IPFIX export. Refer to [PSAMP-FMWK] section 3.3 "Export Process Requirements". 6.2 High Level View of the Integration The Template Record in the Template Set is used to describe the different PSAMP Information Elements that will be exported to the Collector. The Collector decodes the Template Record in the Template Set and knows which Information Elements to expect when it receives the Data Records in the Data Set, i.e. the PSAMP Packet Reports. Typically, in the base level of the PSAMP functionality, the Template Set will contain the input sequence number, the packet fragment (some number of contiguous bytes from the start of the packet) and the Associations ID. The Options Template Record in the Options Template Set is used to describe the different PSAMP Information Elements that concern the Metering Process itself: sampling and/or filtering functions, plus the associated parameters. The Collector decodes the Options Template Records in the Option Template Set and knows which Information Elements to expect when it receives the Data Records in the Data Set, i.e. the PSAMP Report Interpretation. Typically, the Options Template would contain the Associations ID, the sampling or filtering functions, and the sampling or filtering associated parameters. PSAMP requires all the different possibilities of the IPFIX protocol specifications [IPFIX-PROTO]. That is the 3 types of Set (Data Set, Template Set and Options Templates Set) with the 2 types of Templates Claise, et. al Standard Track [Page 22]
PSAMP Protocol Specifications October 2005 Records (Template Record and Options Template Record), as described in the figure A. As a consequence, PSAMP can't rely on a subset of the IPFIX protocol specifications are described in [IPFIX-PROTO]. The entire IPFIX protocol specifications [IPFIX-PROTO] MUST be implemented for the PSAMP export. 7. Using the IPFIX Protocol for PSAMP 7.1 Selector ID The Selector ID is the unique ID identifying a Primitive Selector. Each Primitive Selector MUST have a unique ID within the Observation Domain. 7.2 The Associations From all the packets observed at an Observation Point, a subset of packets is selected by one or more Selectors. The Associations ID is a unique value describing the Observation Point and the Selector IDs through which the packets are selected. The Associations ID is represented by the associationsId Information Element [PSAMP-INFO]. Optionally, the IPFIX processes to which the packets are MAY be added to the Associations ID. Example of IPFIX processes are IPFIX Metering Process ID and IPFIX Exporting Process ID. EDITOR'S NOTE: Even if [PSAMP-TECH] section 7.1 and 7.2 describes that "The ASSOCIATIONS field describes the Observation Point and optionally the IPFIX processes to which the packet Selector is associated. Values: <STREAM ID, IPFIX Metering process ID, IPFIX Exporting process ID, IDs of other associated processes>", we can't see an example where the IPFIX process(es) ID would be required. Don't we have enough with the list of Selector IDs? 7.3 Packet Reports For each Assocations, for each select packet, a Packet Report MUST be created. The format of the Packet Report is specified in a Template Record contained in a Template Set. There are two types of Packet Report, as described in [PSAMP-FWMK]: the basic Packet Report and the extended Packet Report. 7.3.1 Basic Packet Reports For each selected packet, the Packet Report MUST contain the following information: - The associationsId Information Element Claise, et. al Standard Track [Page 23]
PSAMP Protocol Specifications October 2005 - Some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the packet payload. The Layer2PacketSection and ipPacketSection PSAMP elements are available for this use. The Information Element can be provided either with a fixed length field or with a variable sized field - the input sequence number(s) of any Selectors that acted on the packet EDITOR'S NOTE: We should probably list all the possible Information Elements from [PSAMP-INFO]: Layer2PacketSection, ipPacketSection, etc... EDITOR'S NOTE: instead of sending the input sequence number for each selector ID, a counter64 value, associated with every packet, the working group should discuss the possibility to send the information on regular basis with an option template record. Specifically in the case of Composite Selector, we would send multiple times a 64-bit counter in each packet. The example below doesn't contain the input sequence number. Here is an example of a basic Packet Report, with an AssociationsId value of 9 (will be explained later on) and a fixed ipPacketSection field of 12 bytes: IPFIX Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 260 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE ID = AssociationsId | IE Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE ID = ipPacketSection | IE Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 260 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: AssociationsId = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Claise, et. al Standard Track [Page 24]
PSAMP Protocol Specifications October 2005 | Record 1: ipPacketSection = 0x4500 005B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...continued = 0xA174 0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...continued = 0xFF11 832E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D: Example of a Basic Packet Report 7.3.2 Extended Packet Reports Alternatively to the basic Packet Report, the extended Packet Report MAY contain extra information related to the protocols used in the packet (such as source and destination IP addresses), related to the packet treatment (such as output interface, destination BGP autonomous system), related to the Selection State associated with the packet (such as timestamps, hash values). Using the IPFIX Information Elements [IPFIX-INFO], the extra information is added to the Template Record. It is envisaged that selection of fields for Extended Packet Reporting may be used to reduce reporting bandwidth, in which case the option to report some number of contiguous bytes from the start of the packet, mandatory in the basic Packet Report, may not be exercised. Example of a detailed Extended Packet Report: IPFIX Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 261 | Field Count = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE ID = associationsId | IE Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE ID = sourceIPv4Address | IE Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE ID = destinationIPv4Address| IE Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE ID = totalLengthIPv4 | IE Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE ID = tcpSourcePort | IE Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Claise, et. al Standard Track [Page 25]
PSAMP Protocol Specifications October 2005 | IE ID = tcpDestinationPort | IE Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 261 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: AssociationsId = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: sourceIPv4Address = 10.0.0.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: destinationIPv4Address = 10.0.1.106 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rec. 1: totalLengthIPv4 = 72 | Rec. 1: tcpSourcePort = 1372 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rec. 1: tcpDestinationPort=80| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure E: Example of an Extended Packet Report 7.4 Report Interpretation To make full sense of the Packet Reports there are a number of additional pieces of information that must be communicated to the Collector: - The details about which Selectors and Observation Points are being used within an Associations MUST be provided using the Associations Report Interpretation. - The configuration details of each Selector MUST be provided using the Selector Report Interpretation. - The Selector ID statistics MUST be provided using the AssociationsStatistics Report Interpretation. - The accuracies of the reported fields MUST be provided using the Accuracy Report Interpretation. - Further information about each Observation Point MAY be provided using the Observation Point Report Interpretation. 7.4.1 Associations Report Interpretation Each Packet Report contains an associationsId Information Element that identifies the particular combination of Observation Point and Selectors used for its selection. For every associationsId Information Element in use, the PSAMP Device MUST export an Claise, et. al Standard Track [Page 26]
PSAMP Protocol Specifications October 2005 Associations Report Interpretation using an Options Template with the following Information Element: Scope: associationsId Non-Scope: observationPointId selectorId (one or more) If the packets are selected by a Composite Selector, the Associations ID field is composed of several Primitive Selectors. In such a case, the Associations Report Interpretation MUST contain the list of all the Primitive Selector IDs in the Associations ID. If multiple Selectors are contained in the Associations Report Interpretation, the Selectors ID MUST be identified in the order they are used. Optionally, the Associations Report Interpretation MAY contain the following Information Non-Scope: meteringProcessId exportingProcessId The observationPointID SHOULD be first Information Element and the optional processes SHOULD be last ones so that the path of the selected Packet is provided in the logical order. EDITOR'S NOTE: Even if [PSAMP-TECH] section 7.1 and 7.2 describes that "The ASSOCIATIONS field describes the Observation Point and optionally the IPFIX processes to which the packet Selector is associated. Values: <STREAM ID, IPFIX Metering process ID, IPFIX Exporting process ID, IDs of other associated processes>", we can't see an example where the IPFIX process(es) ID would be required. Don't we have enough with the list of Selector IDs? If we don't need the IPFIX Process ID, the following examples must be updated. Example of a Two Associations ID: Selection Path 7 (Filter->Sampling): observationPointID 1 (Interface 5), selectorId 5 (Filter, match IPV4SourceAddress 10.0.0.1), selectorId 10 (Sampler, Random 1 out-of ten), meteringProcessID 15 (IPFIX Metering Process) Selection Path 9 (Sampling->Filtering): observationPointID 1 (Interface 5), selectorId 10 (Sampler, Random 1 out-of ten), selectorId 5 (Filter, match IPV4SourceAddress 10.0.0.1), meteringProcessID 15 (IPFIX Metering Process) IPFIX Options Template Record: 0 1 2 3 Claise, et. al Standard Track [Page 27]
PSAMP Protocol Specifications October 2005 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 262 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 4 | Scope 1 = AssociationsId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 | Option 1 = ObservationPointId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Length = 4 | Option 2 = selectorId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 2 Length = 4 | Option 4 = selectorId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 3 Length = 4 | Option 5 = MeteringProcessId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 4 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 262 | Length = 44 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: AssociationsId = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: ObservationPointId = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: selectorId = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: selectorId = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: MeteringProcessId = 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: AssociationsId = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: Obs.PointId = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: selectorId = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: selectorId = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: MeteringProcessId = 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure F: Example of an Associations Report Interpretation Claise, et. al Standard Track [Page 28]
PSAMP Protocol Specifications October 2005 Notes: * There are two Records here in the same Data Set. Each record defines a different Selection Path. * If a different Selection Path used three Selectors then a different Options Template would have to be used. 7.4.2 Selector Report Interpretation An IPFIX Data Record, defined by an Option Template Record, MUST be used to send the configuration details of every Selector in use. The Option Template Record MUST contain the selectorId as the Scope field and the SelectorAlgorithm followed by some type specific configuration fields as the data: Scope: selectorId Non-scope: selectorAlgorithm algorithm specific Information Elements The algorithm specific Information Elements are specified in the following subsections, depending on the selection method represented by the value of the selectorAlgorithm. The Associations statistics MUST be exported periodically. 7.4.2.1 Systematic Count-Based Sampling In systematic count-based Sampling, the start and stop triggers for the Sampling interval are defined in accordance to the spatial packet position (packet count) [PSAMP-TECH]. The algorithm specific Information Elements in case of systematic count-based Sampling are: samplingPacketInterval: number of packets selected in a row samplingPacketSpace: number of packets between selections Example of a simple 1 out-of 10 systematic count-based Selector definition, where the samplingPacketInterval is 1 and the samplingPacketSpace is 9. IPFIX Options Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Claise, et. al Standard Track [Page 29]
PSAMP Protocol Specifications October 2005 | Template ID = 263 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 | Scope 1 = selectorId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 | Option 1 = selectorAlgorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Length = 1 | Option 2 = samp.Pack.Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 2 Length = 1 | Option 3 = samp.PacketSpace | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 3 Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 263 | Length = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | selectorId (scope) = 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .Algorithm= 1 | .Interval= 1 | .Space = 09 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure G: Example of the Selector Report Interpretation, For Systematic Count-Based Sampling Notes: * A samplingAlgorithm value of 1 represents systematic count-based Sampling. * samplingPacketInterval and samplingPacketSpace are of type unsigned32 but are compressed down to one octet here. 7.4.2.2 Systematic Time-Based Sampling In systematic time-based Sampling, the start and stop triggers are used to define the Sampling intervals [PSAMP-TECH]. The algorithm specific Information Elements in case of systematic time-based Sampling are: samplingTimeInterval: time (in ms) when packets are selected samplingTimeSpace: time (in ms) between selections Example of a 100 ms out-of 1000 ms systematic time-based Selector definition, where the samplingTimeInterval is 100 and the Claise, et. al Standard Track [Page 30]
PSAMP Protocol Specifications October 2005 samplingTimeSpace is 900 IPFIX Options Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 264 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 | Scope 1 = selectorId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 | Option 1 = selectorAlgorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Length = 1 | Option 2 = samp.TimeInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 2 Length = 1 | Option 3 = samp.TimeSpace | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 3 Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 264 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | selectorId (scope) = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .Algorithm= 2 | .Interval=100 | samplingTimeSpace = 900 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure H: Example of the Selector Report Interpretation, For Systematic Time-Based Sampling Notes: * A samplingAlgorithm value of 2 represents systematic time-based Sampling. * samplingTimeInterval and samplingTimeSpace are of type unsigned32 but are compressed down here. 7.4.2.3 Random n-out-of-N Sampling In random n-out-of-N Sampling, n elements are selected out of the parent population that consists of N elements [PSAMP-TECH]. The Claise, et. al Standard Track [Page 31]
PSAMP Protocol Specifications October 2005 algorithm specific Information Elements in case of random n-out-of-N Sampling are: samplingSize: number of packets selected samplingPopulation: number of packets in selection population Example of a 1 out-of 10 random n-out-of-N sampling Selector: IPFIX Options Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 265 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 | Scope 1 = selectorId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 | Option 1 = selectorAlgorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Length = 1 | Option 2 = samplingSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 2 Length = 1 | Option 3 = samplingPopulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 3 Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 265 | Length = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | selectorId (scope) = 17 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .Algorithm= 1 | .samp.Size= 1 | samp.Pop = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure I: Example of the Selector Report Interpretation, For Random n-out-of-N Sampling Notes: * A samplingAlgorithm value of 3 represents Random n-out-of-N sampling. * samplingSize and samplingPopulation are of type unsigned32 but are compressed down to one octet here. Claise, et. al Standard Track [Page 32]
PSAMP Protocol Specifications October 2005 7.4.2.4 Uniform Probabilistic Sampling EDITOR'S NOTE: to be completed 7.4.2.5 Non-uniform Probabilistic Sampling EDITOR'S NOTE: to be completed 7.4.2.6 Non-uniform Flow State Sampling EDITOR'S NOTE: to be completed 7.4.2.7 Match Based Filtering and Router State Filtering This classification includes match(es) on field(s) within a packet and match(es) on properties of the router state. With this method, a packet is selected if a specific field in the packet equals a predefined value. The algorithm specific Information Elements, defining configuration parameters for match-based and router state filtering, are taken from the full range of available IPFIX Information Elements [IPFIX-INFO]. Further Information Elements MAY be defined by proprietary Information Elements [IPFIX-PROTO] When multiple different Information Elements are defined, the filter acts as a logical AND. Note that the logical OR is not covered by these PSAMP specifications. The match based filtering and router state filtering Options Template Record MUST NOT have multiple identical Information Elements. The result of the filter is independent from the order of the Information Elements in the Option Template Record, but the order may be important for implementation purposes, as the first filter will have to work at a higher rate. In any case, an implementation is not constrained to respect the filter ordering, as long as the result is the same, and it may even implement the composite filtering in filtering in one single step. EDITOR'S NOTE: "The algorithm specific Information Elements, defining configuration parameters for match-based and router state filtering, are taken from the full range of available IPFIX Information Elements [IPFIX-INFO] ". What about the ones from [PSAMP-INFO]? In other words, are they I.E.s in [PSAMP-INFO] that we could use for the match-based and router state filtering? Example of a match based filter Selector, whose rules are: IPv4 Source Address = 10.0.0.1 Claise, et. al Standard Track [Page 33]
PSAMP Protocol Specifications October 2005 IPv4 Next-Hop Address = 10.0.1.1 IPFIX Options Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 266 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 | Scope 1 = selectorId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 | Option 1 = selectorAlgorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Length = 1 | Option 2 = sourceIPv4Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 2 Length = 4 | Option 3 =ipNextHopIPv4Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 3 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 266 | Length = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | selectorId (scope) = 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .Algorithm= 1 | sourceIPv4Address = 10.0.0 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... .1 | ipNextHopIPv4Address = 10.0.1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... .1 | +-+-+-+-+-+-+-+-+ Figure J: Example of the Selector Report Interpretation, For match based and router state Filtering Notes: * A samplingAlgorithm value of 7 represents match based filtering. * In this filter there is a mix of information from the packet and information from the router. Claise, et. al Standard Track [Page 34]
PSAMP Protocol Specifications October 2005 7.4.2.8 Hash Based Filtering EDITOR'S NOTE: to be completed 7.4.3 Associations Statistics Report Interpretation A Selector MAY be used in multiple Associations. However, each use of a Selector must be independent, so each separate logical instances of a Selector MUST maintain its separate Selection State and statistics. The Associations Statistics Report Interpretation MUST include the number of packets seen (Population Size) and the number of packets selected (Sample Size) by each instance of its Primitive Selector. Within an Association composed of several Primitive Selectors, the number of packets selected for one Selector is equal to the number of packets seen by the next Selector. The order of the Selectors in the Associations Statistics Report Interpretation MUST match the order of the Selectors in the Association, as defined in the Associations Report Interpretation. The Associations Statistics Report Interpretation MUST also contain the number of packets observed at the Observation. For every Associations ID, the PSAMP Device MUST export an Associations statistics Report Interpretation using an Options Template with the following Information Element: Scope: AssociationsId Non-scope: packetsObserved packetsSelected (one or more) The packetsObserved Information Element contains the number of packets seen at the Observation Point, and as a consequence passed to the first Selector in the Association. The packetsSelected Information Element contains the number of packets selected by the various Selectors in the Associations. The Attained Selection Fraction can be calculated for each Selector by dividing the number of packets selected for that Selector by the previous value. The statistics for the whole sequence SHOULD be taken at a single logical point in time, the input value for a Selector MUST equal the output value of the previous selector. Example of Associations Statistics Report Interpretation: Associations set 7 (Filter->Sampling): Claise, et. al Standard Track [Page 35]
PSAMP Protocol Specifications October 2005 Observed 100 (observationPointID 1, Interface 5) Selected 50 (selectorId 5, match IPV4SourceAddress 10.0.0.1) Selected 6 (selectorId 10, Sampler: Random one out-of ten) Associations set 9 (Sampling->Filtering): Observed 100 (observationPointID 1, Interface 5) Selected 10 (selectorId 10, Sampler: Random one out-of ten) Selected 3 (selectorId 5, match IPV4SourceAddress 10.0.0.1) IPFIX Options Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 267 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 | Scope 1 = AssociationsId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 | Option 1 = packetsObserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Length = 4 | Option 2 = packetsSelected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 2 Length = 4 | Option 4 = packetsSelected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 3 Length = 4 | Option 5 = packetsSelected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 4 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The associate IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 267 | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: AssociationsId = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: packetsObserved = 100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: packetsSelected = 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1: packetsSelected = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Claise, et. al Standard Track [Page 36]
PSAMP Protocol Specifications October 2005 | Record 2: AssociationsId = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: packetsObserved = 100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: packetsSelected = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2: packetsSelected = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure K: Example of the Association Statistics Report Interpretation Notes: * The Attained Packet Fractions for the first set of Associations are: Filter 10: 50/100 Sampler 5: 6/50 Number of samples sent to Metering Process: 6 * The Attained Packet Fractions for the second set of Associations are: Sampler 5: 10/100 Filter 10: 3/10 Number of samples sent to Metering Process: 3 7.4.4 Accuracy Report Interpretation The inherent accuracy of the Information Elements in the Packet Report MUST be reported in order to enable the Collector to determine the accuracy of the measurements. EDITOR'S NOTE: to be completed 7.4.5 Observation Point Report Interpretation For each Observation Point, an Observation Option Report Interpretation MAY be sent. EDITOR'S NOTE: to be completed 8. Security Considerations As IPFIX has been selected as the PSAMP export protocol and as the PSAMP security requirements are not stricter than the IPFIX security requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security considerations. Claise, et. al Standard Track [Page 37]
PSAMP Protocol Specifications October 2005 9. IANA Considerations The only IANA considerations in this document concern the extension of Information Elements, Set ID and Scope. Refer to the IANA considerations section in [IPFIX-PROTO] where those possible new assignments are specified. 10. References 10.1 Normative References [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection" draft-ietf-psamp-sample-tech-07.txt [PSAMP-MIB] T. Dietz, B. Claise "Definitions of Managed Objects for Packet Sampling" draft-ietf-psamp-mib-04.txt [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, "Information Model for Packet Sampling Exports", draft-ietf-psamp-info-02.txt [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek, "Architecture Model for IP Flow Information Export" draft-ietf-ipfix- arch-08.txt" [IPFIX-INFO] J. Quittek, S. Bryant, B. Claise, J. Meyer, "Information Model for IP Flow Information Export" draft-ietf-ipfix-info-11 [IPFIX-PROTO] B. Claise (Editor) "IPFIX Protocol Specifications", draft-ietf-ipfix-protocol-19.txt [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. 10.2 Informative References [PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenberg, M. Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan, "A Framework for Passive Packet Measurement" draft-ietf-psamp-framework-10.txt [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004 11. Acknowledgments The authors would like to thank the PSAMP group, especially Paul Aitken for fruitful discussions and for proofreading the document. Claise, et. al Standard Track [Page 38]
PSAMP Protocol Specifications October 2005 Authors' Addresses Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 E-mail: bclaise@cisco.com Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-15 Email: quittek@ccrle.nec.de Andrew Johnson Cisco Systems 96 Commercial Quay Edinburgh EH6 6LX Scotland Phone: +44 131 561 3641 Email: andrjohn@cisco.com Intellectual Property Statement 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 Claise, et. al Standard Track [Page 39]
PSAMP Protocol Specifications October 2005 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society Claise, et. al Standard Track [Page 40]
