PSAMP working group
   Internet Draft                                EDITOR:     B. Claise
   draft-ietf-psamp-protocol-01.txt
   draft-ietf-psamp-protocol-02.txt                       Cisco Systems
   Expires: August 2004                                   February 2004 April 2006                                     October 2005

              Packet Sampling (PSAMP) Protocol Specifications

 Status of this Memo

   This document
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is an Internet-Draft aware
   have been or will be disclosed, and is any of which he or she becomes
   aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 6 of RFC2026. 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 obsolete 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." 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.
   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. The IPFIX protocol is well suited for this purpose, because used, as both the IPFIX architecture matches the and PSAMP architecture match very well
   and the means provided by the IPFIX protocol are sufficient. The
   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. Open Issues..................................................2 Points of Discussion........................................3
      1.1 Open Issues................................................2 Issues................................................3
      1.2 Action Items...............................................3 Items...............................................4
     2. Introduction.................................................3 Introduction................................................5
     3. Terminology..................................................4 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..........................4
      4.1 IPFIX........................17
      5.1 Architecture Point of View.................................4
      4.2 View................................17
      5.2 Protocol Point of View.....................................6
      4.3 View....................................19
      5.3 Information Model Point of View............................6
     5. Using IPFIX for PSAMP........................................7
      5.1 High Level View of the Integration.........................7
      5.2 Partial or Entire IPFIX Protocol Specifications Support....7 View...........................19
     6. PSAMP Requirements versus the IPFIX Solution.................8 Solution...............20
      6.1 IPFIX Solution for the PSAMP Requirements..................8
     7. Low Requirements.................20
      6.2 High Level View of the Integration...........................11 Integration........................22
     7. Using the IPFIX Protocol for PSAMP.........................23
      7.1 Sampling Case, PSAMP Base Level of Functionality..........11
       7.1.1   Example..............................................11 Selector ID...............................................23
      7.2 Sampling Case.............................................12
       7.2.1   Example..............................................13 The Associations..........................................23
      7.3 Filtering Case............................................13 Packet Reports............................................23
     7.3.1   Example..............................................13   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
     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.....................................13 Considerations....................................37
     9. IANA Considerations.........................................13 Considerations........................................38
     10. References.................................................13 References................................................38
      10.1 Normative References.....................................13 References.....................................38
      10.2 Informative References...................................14 References...................................38
     11. Acknowledgments............................................14 Acknowledgments...........................................38

 1.
   Open Issues
    Points of Discussion

 1.1
     Open Issues

   This section covers the open issues, still to be resolved/updated in
   this draft:

   PROTO-01 Do [PSAMP-FMWK] mentions the optional Export Packets
   compression (see section 8.5) Should we want to distinguish an IPFIX Flow Record export with
   one packet from a PSAMP export?
   PROTO-02 Need to fill mention this in this
   document?

   PROTO-02 From a protocol point of view, there a no differences
   between the examples section 7.1.1, 7.1.2 Field Match Filtering and 7.1.3
   PROTO-03 the Router State Filtering as
   defined in packet interpretation.
          Options Template FlowSet (SELECTOR_ID, SAMPLING_ALGO, SAMPLING
          PARAM, TIMESTAMP, OBSERVATION POINT) [PSAMP-TECH]. The packet reports MUST contain:
          - only difference concerns the input sequence number(s), denoted I.E. on
   which we do the SEQUENCE-NUMBER in
          [PSAMP-INFO]
          - some number filtering... part of contiguous bytes from the start packet in one case, not part
   of the
          packet, denoted the PACKET-SAMPLE packet in [PSAMP-INFO]
          - the destination BGP AS , denoted destinationAS in [IPFIX-
          INFO]
          - other case. Proposal: merge the input interface, denoted ingressPort 2 methods in [IPFIX-INFO]
          THIS IS NOT A GOOD EXAMPLE
   PROTO-04 Extend security considerations by a discussion on exported
   payload

 1.2
    Action Items

   This section covers
   [PSAMP-TECH]

   PROTO-03 The second open issue is concerned with reporting the action items for this draft

   ACTION-01 For section 6 "PSAMP requirements versus
   sequential order of sampling and filtering. => order of the IPFIX
   solution", check if there are any other requirements in scope.
   We spot a new problem: we could export twice the [PSAMP-
   FRAMEWORK].
   ACTION-02 Update hash value. How to
   distinguish them? How to know that the terminology section
   ACTION-03 A new hash value 1 corresponds to a
   specific definition specified in an Option Template.

   PROTO-04 Should probably have a separate section about for the terminology comparison between
   [PSAMP-PROTO] (hence [IPFIX-PROTO]) and [PSAMP-FRAMEWORK]
      - Flow Data Records sent in Data FlowSet = packet report in
      [PSAMP-FRAMEWORK]
      - Options Data Record sent in Data FlowSet = packet interpretation
      n [PSAMP-FRAMEWORK]
      Exporting Process in IPFIX = Reporting Process in [PSAMP-
      FRAMEWORK]
      Note1: 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 somehow explained mentioned in
   [PSAMP-TECH], maybe a term such as SelectionPath or PathID would be
   more appropriate.

   PROTO-07 Even if [PSAMP-TECH] section 5.1
   ACTION-04 Should briefly discuss the fact 7.1 and 7.2 describes that PSAMP "The
   ASSOCIATIONS field describes the Observation Point and optionally the
   IPFIX processes to which the packet Selector is OK with associated. Values:
   <STREAM ID, IPFIX requirements in terms Metering process ID, IPFIX Exporting process ID,
   IDs of time (uSec precision)
   ACTION-05 Check for other associated processes>", we can't see an example where
   the existence of IPFIX process(es) ID would be required. Don't we have enough with
   the Information Elements
   defined here in [PSAMP-INFO] and modify if appropriate. Example: list of Selector IDs?

   PROTO-08 Instead of sending the input sequence number for each
   selector ID, packet-sample, sampling-algorithm, hash-value, etc…
   For example, a counter64 value, associated with every packet, the section 7.1
   ACTION-06 In section 6.1 ‘‘An Options Templates MUST be sent
   working group should discuss the possibility to send the information
   on regular basis.’’ -> make the link basis with Metering Process Stats
   currently discussed an option template record. Specifically in the IPFIX mailing list and
   case of Composite Selector, we would send multiple times a 64-bit
   counter in [IPFIX-PROTO]
   ACTION-07 Some text explanation each packet.

   PROTO-09 "The algorithm specific Information Elements, defining
   configuration parameters for match-based and router state filtering,
   are taken from the encoding full range of the new available IPFIX Information
   Elements. For example, the ‘‘packet-fragment’’ will use Elements
   [IPFIX-INFO]". What about the Variable
   Length Data Type as described in [IPFIX-PROTO]
   ACTION-08 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
   PROTO-105 Section 6 about ‘‘PSAMP requirements’’: "PSAMP requirements": check if any changes
   with the version 5 of [PSAMP-FRAMEWORK] [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] and [IPFIX-INFO] exports IP traffic information [IPFIX-INFO] observed at
   network devices. This matches the general protocol requirements
   outlined in the Packet SAMPling (PSAMP) PSAMP framework [PSAMP-FMWK]. However, there are some
   architectural differences between IPFIX and PSAMP and in the requirements
   for an export protocol. While in the IPFIX architecture [IPFIX-ARCH] packet sampling is just one out of
   many components considered, it is
   focused on gathering and exporting IP traffic flow information, the
   focus of the PSAMP framework
   [PSAMP-FMWK]. [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 4. 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.
   Terminology

   EDITOR’S NOTE:
   - To be copied in from [PSAMP-FRAMEWORK].
   - From [IPFIX-PROTO]:
       - need Flow Record, Flow, Information Element, Metering Process,
       Exporting Process, Collector, Scope
       - need all terms from the table in section 5.2. That is:
       FlowSet, Template Record, Data Record, Flow Data Record, Data
       FlowSet, Options Data Record, Template FlowSet, Template
       Record(s), Options Template FlowSet, Options Template Record
       - need
   PSAMP device
   - All Documents Overview

   [PSAMP-FMWK]: "A Framework for Packet Selection and Reporting",
   describes the terms will have their initial letter in upper case

 4.
   Differences between PSAMP framework for network elements to select subsets
   of packets by statistical and IPFIX

   The output other methods, and to export a stream
   of reports on the IPFIX working group relevant selected packets to a collector.

   [PSAMP-TECH]: "Sampling and Filtering Techniques for this draft, is
   structured into three documents:
      - IP Flow information architecture [IPFIX-ARCH]
      - IPFIX Packet
   Selection", describes the set of packet selection techniques
   supported by PSAMP.

   [PSAMP-PROTO]: "Packet Sampling (PSAMP) Protocol Specifications [IPFIX-PROTO]
      - IP Flow information 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 [IPFIX-INFO]

 4.1
     Architecture Point for PSAMP.

   [PSAMP-MIB]: "Definitions of View

   Traffic Flow measurement as described in Managed Objects for Packet Sampling"
   describes the PSAMP Management Information Base

 4.
   Terminology

   As the IPFIX requirements
   [IPFIX-REQ] and export protocol is used to export the PSAMP information,
   the relevant IPFIX architecture [IPFIX-ARCH] can be separated
   into two stages: packet processing and Flow processing. terminology from [IPFIX-PROTO] is copied over in
   this document. The figure below illustrates these stages.

   On stage 1, 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 processing steps act on packets. Packets are
   captured, time stamped, selected by one or more selection steps terms listed in [PSAMP-TECH] and
   finally forwarded to packet classification [PSAMP-FMWK] but only
   definitions that maps packets are only relevant to
   Flows. the PSAMP protocol appear here.
   The packets selection steps may include filtering and
   sampling functions.

   On stage 2, all processing steps act on Flows. After packets are
   classified (mapped section 5.4 applies the PSAMP terminology to Flows), Flows are generated or updated if they
   exist already. Flow generation and update steps may be performed
   repeatedly 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 aggregating Flows. Finally, Flows are exported.

   Packet sampling 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 described in the PSAMP framework [PSAMP-FMWK]
   covers only stage 1
   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
   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 architecture 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 packet
   classification replaced term 'flow' being used by packet record export. the
   Internet community.  Within the context of IPFIX architecture                       PSAMP framework 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                           packet field (e.g. destination IP address),
      transport header
           capturing     \                         capturing
              |          |                            |
         timestamping    |                       timestamping
              |          |                            |
              v          |                            v
      +------>+          |  stage 1:          +------>+
      |       |           > packet            |       |
      |    packet        |  processing        |    packet
      |   selection      |                    |   selection
      |       |          |                    |       |
      +-------+          |                    +-------+
              |          |                            |
              v          |                            v
           packet       / field (e.g. destination port number), or
      application header field (e.g. RTP header fields [RFC1889])

      2. one or more characteristics of the packet record
        classification  \                          export
              |          |
              v          |
      +------>+          |
      |       |          |
      | Flow generation  |
      |   and update     |  stage 2:
      |       |           > Flow
      |       v          |  processing
      |     Flow         |
      |   selection      |
      |       |          |
      +-------+          |
              |          |
              v          |
         Flow Record    /
           export
           Comparison itself (e.g. number
      of IPFIX architecture and PSAMP framework

 4.2
     Protocol Point MPLS labels, etc...)

      3. one or more of View

   Concerning the protocol, fields derived from packet treatment (e.g. next
      hop IP address, the major difference between IPFIX and
   PSAMP output interface, etc...)

   A packet is that the IPFIX protocol exports defined to belong to a Flow Records while if it completely satisfies
   all the
   PSAMP protocol exports packet records. From a pure export point defined properties of
   view, IPFIX will not distinguish the Flow.

   This definition covers the range from a Flow Record composed of several containing all packets aggregated together, from
   observed at a network interface to a Flow Record composed consisting of just a single
   packet. So the PSAMP export can be seen as special IPFIX Flow Record
   containing information about
   packet between two applications.  It includes packets selected by a single packet.
   EDITOR’S NOTE: maybe we want to distinguish an IPFIX
   sampling mechanism.

   Flow Record
   export with one Key

   Each of the fields which
   1.  Belong to the packet from header (e.g. destination IP address)
   2.  Are a PSAMP export?

   Extensions property of the IPFIX protocol needed by PSAMP 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 rather limited. termed Flow Keys.

   Flow Record

   A basic one is the need of Flow Record contains information about a data type for protocol fields specific Flow that has
   flexible length, such as was
   observed at an octet array. This is needed by the PSAMP
   protocol for reporting content Observation Point.  A Flow Record contains measured
   properties of captured packets, for example the
   first 40 octets of a packet.

 4.3
     Information Model Point of View

   However, Flow (e.g. the overlap between both protocols is still quite large.
   Most total number of the data fields in the IPFIX protocol also apply to PSAMP, bytes for example all fields reporting packet header fields. Only a few
   fields, such as flowCount, packetCount (whose value will always be
   one) etc., cannot be used in a meaningful way by the PSAMP protocol.
   Also, IPFIX protocol requirements concerning stage 2 do not apply to
   the PSAMP protocol.

   Further required extensions apply to
   Flow's packets) and usually characteristic properties of the information model. Flow
   (e.g. source IP address).

   Metering Process

   The
   IPFIX information model is rather poor concerning sampling. Just two
   fields, one for Metering Process generates Flow Records.  Inputs to the sampling method process
   are packet headers and one for characteristics observed at an Observation
   Point, and packet treatment at the sampling rate,
   are not sufficient, as shown in [PSAMP-SLCT]. A set of several
   additional fields is required for satisfying Observation Point (for example the requirements for
   selected output interface).

   The Metering Process consists of a
   PSAMP information model. Additional required extensions set of the
   information model concern functions that includes
   packet filtering, header capturing, timestamping, sampling, classifying, and the a field
   reporting content
   maintaining Flow Records.

   The maintenance of a packet using the flexible length data type
   mentioned above.

   Exploiting 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 extensibility of the IPFIX information model, the
   required extension Exporting Process, and deleting Flow Records.

   Exporter

   A device which hosts one or more Exporting Processes is covered by the PSAMP information model
   specified in [PSAMP-INFO].

 5.
   Using termed an
   Exporter.

   IPFIX for PSAMP

 5.1
    High Level View of the Integration 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
   A device which hosts one or more Collecting Processes is termed a
   Collector.

   Template Record in the

   Template FlowSet is an ordered sequence of <type, length> pairs, used to describe
   completely specify the
   different PSAMP Information Elements structure and semantics of a particular set of
   information that will needs to be exported communicated from an IPFIX Device to the a
   Collector. The Collector decodes the  Each Template FlowSet and knows
   which Information Elements to expect when it receives is uniquely identifiable by means of a
   Template ID.

   IPFIX Message

   An IPFIX Message is a message originating at the Flow Data
   Records in Exporting Process
   that carries the Data FlowSet, i.e. IPFIX records of this Exporting Process and whose
   destination is a Collecting Process.  An IPFIX Message is
   encapsulated at the PSAMP Packet Reports.
   Typically, in transport layer.

   Message Header

   The Message Header is the base level first part of an IPFIX Message, which
   provides basic information about the PSAMP functionality, message such as the
   Template FlowSet will contain IPFIX
   version, length of the input message, message sequence number, etc.

   Template Record

   A Template Record defines the packet
   fragment (some number structure and interpretation of contiguous bytes from the start fields
   in a Data Record.

   Data Record

   A Data Record is a record that contains values of the
   packet) and the selector ID.

   The parameters
   corresponding to a Template Record.

   Options Template Record in the

   An Options Template FlowSet Record is used
   to describe the different PSAMP Information Elements a Template Record that concern defines the Metering Process itself: sampling and/or filtering functions,
   plus the associated parameters. The Collector decodes the Options
   Template FlowSet
   structure and knows which Information Elements interpretation of fields in a Data Record, including
   defining how to expect when
   it receives scope the Options Data Records in applicability of the Data FlowSet, i.e. the
   PSAMP Report Interpretation. Typically, 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 would
   contain the Selector ID, the sampling or filtering functions, Set, and
   the sampling or filtering associated parameters.

 5.2
    Partial Data Set.

   Template Set

   A Template Set is a collection of one or Entire more Template Records that
   have been grouped together in an IPFIX Protocol Specifications Support

   The "High level view Message.

   Options Template Set

   An Options Template Set is a collection of the integration" section 5.1 concludes one or more Options
   Template Records that
   PSAMP requires all the different possibilities 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 protocol
   specifications [IPFIX-PROTO]. That Message.  Each Data Record is the 3 types of FlowSet (Data
   FlowSet, previously
   defined by a Template FlowSet and Options Templates FlowSet), the 2
   types of Templates Records (Template Record and or an Options Template
   Record), Record.

   Information Element

   An Information Element is a protocol and the 2 types encoding independent
   description of Data Record (Flow Data Record, Options
   Data Record), as described again an attribute which may appear in an IPFIX Record.  The
   IPFIX information model [IPFIX-INFO] defines the table below. 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                    |
    |                  +--------------------+------------------------+
    |     FlowSet       Set        |      Template  Record      |    Data         Record         |
    +------------------+--------------------+------------------------+
    |                  |                    |  Flow Data Record(s)   |
    |   Data FlowSet Set       |          /         |          or            |
    |                  |                    | Options     Data Record(s)     |
    +------------------+--------------------+------------------------+
    |   Template FlowSet Set   | Template Record(s) |           /            |
    +------------------+--------------------+------------------------+
    | Options Template | Options Template   |           /            |
    | FlowSet       Set        | Record(s)          |                        |
    +------------------+--------------------+------------------------+

   As a consequence,

               Figure A: Terminology Summary Table

 4.2
     PSAMP can't rely on a subset of the IPFIX protocol
   specifications are described in [IPFIX-PROTO]. Terminology

   EDITOR'S NOTE: The entire terminology has been entirely copied over from
   [PSAMP-TECH], except for some (almost) similar terms where only the
   IPFIX
   protocol specifications MUST terms were kept (for example, observation point). Before
   publication, we should evaluate which terms should be implemented kept. The ones
   required for the PSAMP export.

 6. sure so far are: Selector, Composite Selector, Packet
   Reports, Packet Interpretation, PSAMP Requirements versus the IPFIX Solution

   [PSAMP-FRAMEWORK] describes some requirements device, Collector, Filtering,
   Sampling. Note 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-FRAMEWORK] also describes terms Selector ID and Association ID, coming
   from [PSAMP-FMWK], has been added 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 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 same entity."

   [PSAMP-FRAMEWORK] finally describes in
   Observation Point.

   Packet Stream

   A packet stream denotes a subset of the section 5 Observed Packet Stream that
   flows past some
   requirements regarding specified point within the reporting measurement process. This series An
   example of
   requirements specifies a Packet Stream is the different Information Elements that MUST 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 SHOULD reported to the collector. Nevertheless IPFIX, being a
   generic export protocol, can export any Information Elements packet payload.

 4.2.2   Selection Process

   Selection Process

   A Selection Process takes the Observed Packet Stream as long its input and
   selects a subset of that stream as there are described in the its output.

   Selection State

   A Selection Process may maintain state information model. So these
   requirements are mainly targeted for use by the [PSAMP-INFO] document.

 6.1
    IPFIX Solution for
   Selection Process and/or the PSAMP Requirements

   Let's address reporting process. At a given time, the PSAMP requirements one by one.

   * Parallel Measurements: multiple independent measurement processes
   Selection State may depend on packets observed at and before that
   time, and other variables. Examples include:

       (i)   sequence numbers of packets at the same entity. Refer to [PSAMP-FRAMEWORK] section 3.1 "Selection
   Process Requirements".

   This requirement is addressed by exporting input of Selectors;

       (ii)  a timestamp of observation of the Selector ID
   Information Element in every packet report, so part of every Flow
   Data Records. Note that without this requirement, exporting at the Scope
   part
             Observation Point;

       (iii) iterators for pseudorandom number generators;

       (iv)  hash values calculated during selection;
       (v)   indicators of every single whether the packet report could have been sufficient.

   * Transparency: allow transparent interpretation of measurements as
   communicated was selected by PSAMP reporting, without any need to obtain
   additional information concerning a
             given Selector;

   Selection Processes may change portions of the observed Selection State as a
   result of processing a packet. Selection state for a packet stream. Refer is to [PSAMP-FRAMEWORK] section 3.2 "Reporting
   reflect the state after processing the packet.

   Selector

   A Selector defines the action of a Selection Process Requirements".

   This requirement is addressed by exporting on a single
   packet of its input. If selected, the packet becomes an element of
   the output Packet Stream.

   The Selector ID
   Information Element in every Flow Data Records (packet report) and
   exporting can make use of the associated SAMPLING_ALGORITHM and SAMPLING PARAMETERS
   Information Elements following information in determining
   whether a packet is selected:

       (i)  the Options Data Record (packet
   interpretation). So packet's content;

       (ii) information derived from the all packet's treatment at the Metering Process parameters are
   linked to
            Observation Point;

       (iii) any selection state that may be maintained by the Flow Data Records.

   * Robustness to Information Loss: allow robust interpretation
             Selection Process.

   Composite Selector

   A Composite Selector is an ordered composition of
   measurements with respect to reports missing due to data loss, e.g. Selectors, in transport, or within which
   the measurement, reporting or Exporting
   Processes. Inclusion in reporting of information that enables output Packet Stream issuing from one Selector forms the
   accuracy of measurements to be determined. Refer input
   Packet Stream to [PSAMP-FRAMEWORK]
   section 3.2 "Reporting Process Requirements".

   An Options Templates 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 succeeding Selector.

   Primitive Selector

   A Selector is primitive if it is not a Composite Selector.

   Selector ID with

   The Selector ID is the number actually metered and/or
   sent. In case of discrepancy, unique ID identifying a new sampling rate could be computed.

   * Faithfulness: Primitive Selector.

   Associations ID

   From all reported quantities that relate to the packet
   treatment MUST reflect 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 router state Observation Point and configuration encountered
   by the packet at Selector IDs
   through which the time it packets are selected. The Associations ID is received
   represented by the measurement process.
   Refer associationsID Information Element [PSAMP-INFO].

 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 [PSAMP-FRAMEWORK] section 3.2 "Reporting the
   Reporting Process
   Requirements".

   This requirement doesn't concern comprises that information available to the export protocol itself but
   Selection Process per selected packet, specifically:

       (i)   the
   Metering 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, even if described in reflecting any modifications to the "Reporting Process
   Requirements" section.

   * Privacy:
             Selection State made during selection of the content of packet reports will be
   cognizant packet.

   Packet Reports

   Packet Reports comprise a configurable subset of privacy and anonymity issues while being responsive a packet's input to
   the needs of measurement applications, reporting process, including the packet's content, information
   relating to its treatment (for example, the output interface), and in accordance with RFC
   2804. Full packet capture
   its associated selection state (for example, a hash of arbitrary packet streams the packet's
   content)

   Report Interpretation:

   Report Interpretation comprises subsidiary information, relating to
   one or more packets, that is explicitly
   out used for interpretation of scope. Refer to [PSAMP-FRAMEWORK] section 3.2 "Reporting their packet
   reports. Examples include configuration parameters of the Selection
   Process Requirements".

   This requirement doesn't concern and of the export protocol itself, even if
   described in Reporting Process.

   Report Stream:

   The Report Stream is the "Reporting output of a Reporting Process, comprising
   two distinguished types of information: Packet Reports, and Report
   Interpretation.

 4.2.4   Measurement Process Requirements" section.

   * Timeliness: reports on selected packets MUST be made available to

   Measurement Process

   A Measurement Process is the collector quickly enough to support near real time applications.
   Specifically, any report on composition of a packet MUST be dispatched within 1
   second Selection Process that
   takes the Observed Packet Stream as its input, followed by a
   Reporting Process.

 4.2.5   Exporting Process

   Exporting Process:

   An Exporting Process sends, in the form of Export Packet, the time output
   of receipt one or more Measurement Processes to one or more Collectors.

   Export Packet:

   An Export Packet is a combination of the packet Report Interpretation and/or one
   or more Packet Reports are bundled by the measurement
   process. Refer Exporting Process into a
   Export Packet for exporting to [PSAMP-FRAMEWORK] section 3.3 "Export a Collector.

 4.2.6   PSAMP Device

   PSAMP Device

   A PSAMP Device is a device hosting at least an Observation Point, a
   Measurement Process
   Requirements".

   The IPFIX protocol specifications [IPFIX-PROTO] describe and an
   inactivity timeout Exporting Process. Typically,
   corresponding Observation Point(s), Measurement Process(es) and
   Exporting Process(es) are co-located at this device, for the Flow expiration. This inactivity timeout example at a
   router.

 4.2.7   Selection Methods

   Filtering

   A filter is configurable, with a minimum value of 0 for immediate expiration.
   Note Selector that this minimum value of 0 will force every single Flow Data
   Record to contain information about selects a single 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 an
   aggregation a filter is called a Sampling operation. This
   reflects the intuitive notion that if the selection of packets.

   * Congestion Avoidance: export 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 report stream across Content-
   independent Sampling operation.  Examples include systematic
   Sampling, and uniform pseudorandom Sampling driven by a network
   MUST be congestion avoiding pseudorandom
   number whose generation is independent of Packet Content. Note that
   in compliance with RFC 2914. Refer Content-independent Sampling it is not necessary to
   [PSAMP-FRAMEWORK] section 3.3 "Export Process Requirements".

   IPFIX, by its charter, MUST also respect this requirement.

   * Secure Export:
       - confidentiality: access the option to encrypt exported data MUST be
       provided.
       - integrity: alterations
   Packet Content in transit order to exported data MUST be
       detectable at make the collector
       - authenticity: authenticity 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 exported data MUST be verifiable
       by a packet field. Note that this is not a filter, because
   the collector in order to detect forged data.

   The motivation here selection is not deterministic.

   Hash Domain

   A subset of the same Packet Content and the packet treatment, viewed as an
   N-bit string for security in IPFIX export.
   Refer to [PSAMP-FRAMEWORK] section 3.3 "Export Process
   Requirements".

 7.
   Low Level View some positive integer N.

   Hash Range

   A set of M-bit strings for some positive integer M that define the Integration

 7.1
    Sampling Case, PSAMP Base Level
   range of Functionality

   EDITOR’S NOTE: LET'S ASSUME THAT THE [PSAMP-INFO] DEFINES THE
   FOLLOWING DATA TYPES
        SEQUENCE-NUMBER: values the input sequence number,
        PACKET-SAMPLE: some number result of contiguous bytes the hash operation can take.

   Hash Function

   A deterministic map from the start Hash Domain into the Hash Range.

   Hash Selection Range

   A subset of the Hash Range. The packet
        SELECTOR-ID:
        SAMPLING-ALGORITHM:
        SAMPLING-PARAMETER1, SAMPLING-PARAMETERS2, ETC...

   As described in is selected if the section 5.1 "Mandatory Contents of Packet
   Reports" action of [PSAMP-FRAMEWORK],
   the packet reports must contain:
   - Hash Function on the input sequence number(s), denoted Hash Domain for the SEQUENCE-NUMBER packet yields a result
   in
   [PSAMP-INFO]
   - some number of contiguous bytes from the start of the packet,
   denoted 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 PACKET-SAMPLE above categories may be approximated by
   operations in [PSAMP-INFO].
   Thus the Template FlowSet defines same or another category for the purposes of
   implementation. For example, uniform pseudorandom Sampling may be
   approximated by Hash-based Selection, using a Template Record composed suitable Hash Function
   and Hash Domain. In this case, the closeness of the approximation
   depends on the choice of
   SEQUENCE-NUMBER, PACKET-SAMPLE Hash Function and SELECTOR-ID. 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
   selected. An example is all packets in the Observed Packet Stream
   that are observed within some specified time interval.

   Population Size

   The report interpretation must contain:
   - Population Size is the sampling algorithm, denoted SAMPLING-ALGORITHM number of all packets in [PSAMP-INFO]
   - the sampling parameters denoted SAMPLING-PARAMETER1, SAMPLING-
   PARAMETER2, etc... in [PSAMP-INFO] Population.

   Sample Size

   The Options Template FlowSet defines a Options Template Record
   composed number of SELECTOR-ID, SAMPLING-ALGORITHM, SAMPLING-PARAMETERS.

   Finally packets selected from the Data FlowSet Population by a Selector.

   Configured Selection Fraction

   The Configured Selection Fraction is used to export the Flow Data Record(s)
   containing ratio of the real values number of SEQUENCE-NUMBER, PACKET-SAMPLE and
   SELECTOR-ID. The Data FlowSet is also used
   packets selected by a Selector from an input Population, to export the  Options
   Data Record(s) containing
   Population Size, as based on the real values configured selection parameters.

   Attained Selection Fraction

   The Attained Selection Fraction is the actual ratio of SELECTOR-ID, SAMPLING-
   ALGORITHM, SAMPLING-PARAMETERS.

   By means the
   number of packets selected by a Selector from an input
   Population, to the SELECTOR-ID, Population Size.
   For some sampling methods the Collector Attained Selection Fraction can link any Flow Data
   Record to differ
   from the corresponding Options Data Record. That is, any Flow
   Data 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
   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.

   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          |
         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.

   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
   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?
   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
   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
   - 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  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 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
   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
    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
   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 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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
   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
   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.

 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
      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.

 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):

      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  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record 2: AssociationsId =                                9  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record 2: packetsObserved  =                            100  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record to the Metering Process function and parameters.

 7.1.1 2: packetsSelected =                              10  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record 2: packetsSelected =                               3  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure K: Example

   EDITOR’S THIS MUST BE A FULL EXAMPLE LIKE IN SECTION 13 OF [IPFIX-
   PROTO].
   THE [PSAMP-INFO] MUST BE FIRST PUBLISHED.

 7.2
    Sampling Case

   The PSAMP reporting process SHOULD also report fields relating to
   the protocols used in the packets, to the packet treatment and to
   the selection state associated with of the packet, as specified in
   [PSAMP-FRAMEWORK] section 5.2 "Recommended Contents for Association Statistics Report
                 Interpretation

   Notes:
   * The Attained Packet
   Reports".

   Let's take the same example as in the section 7.1, but let's add Fractions for the
   export first set of the destination BGP Autonomous System (AS) [1771] and Associations
   are:
            Filter 10: 50/100
            Sampler 5: 6/50
            Number of
   the input interface samples sent to Metering Process: 6
   * The packet reports MUST contain:
   - the input sequence number(s), denoted the SEQUENCE-NUMBER in
   [PSAMP-INFO]
   - some number of contiguous bytes from Attained Packet Fractions for the start second set of the packet,
   denoted the PACKET-SAMPLE in [PSAMP-INFO]
   - the destination BGP AS , denoted destinationAS in [IPFIX-INFO]
   - the input interface, denoted ingressPort in [IPFIX-INFO]
   Thus the Template FlowSet defines a Template Record composed Associations
   are:
            Sampler 5: 10/100
            Filter 10: 3/10
            Number of
   SEQUENCE-NUMBER, PACKET-SAMPLE and SELECTOR-ID, destinationAS and
   ingressPort. samples sent to Metering Process: 3

 7.4.4   Accuracy Report Interpretation

   The report interpretation will remain unchanged and must contain:
   - inherent accuracy of the sampling algorithm, denoted SAMPLING-ALGORITHM Information Elements in [PSAMP-INFO]
   - the sampling parameters denoted SAMPLING-PARAMETER1, SAMPLING-
   PARAMETER2, etc... Packet
   Report MUST be reported in [PSAMP-INFO]
   The Options Template FlowSet is used to define this template
   composed of SELECTOR-ID, SAMPLING-ALGORITHM, SAMPLING-PARAMETERS.

   Finally Data FlowSet is used to export the Flow Data Record(s)
   containing the real values of SEQUENCE-NUMBER, PACKET-SAMPLE and
   SELECTOR-ID, destinationAS and ingressPort. The Data FlowSet is also
   used order to export the Options Data Record(s) containing the real values
   of SELECTOR-ID, SAMPLING-ALGORITHM, SAMPLING-PARAMETERS.

   As a consequence, enable the collector can link any Flow Data Record Collector to determine
   the
   sampling algorithm and sampling parameters, by means of the
   SELECTOR-ID value.

 7.2.1    Example

   EDITOR’S NOTE: THIS MUST BE A FULL EXAMPLE LIKE IN SECTION 13 OF
   [IPFIX-PROTO]. THE [PSAMP-INFO] MUST BE FIRST PUBLISHED.

 7.3
    Filtering Case

   EDITOR’S NOTE: ACTUALLY THE EXAMPLE WILL BE QUITE SIMILAR TO 7.1 AND
   7.2 BUT WILL DEPEND A LOT ON HOW WE WILL DEFINE THE FILTERING IN
   [IPFIX-INFO].

 7.3.1    Example

   EDITOR’S accuracy of the measurements.

   EDITOR'S NOTE: THIS MUST BE A FULL EXAMPLE LIKE IN SECTION 13 OF
   [IPFIX-PROTO]. THE [PSAMP-INFO] MUST BE FIRST PUBLISHED. 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.

 9.
   IANA Considerations

   The only IANA considerations in this document concerns concern the extension
   of Information Elements, FlowSet 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-SAMPLE-TECH]

   [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F.
   Raspall, N. Duffield "Sampling and Filtering Techniques for IP Packet Selection" draft-
   ietf-psamp-sample-tech-01.txt
   draft-ietf-psamp-sample-tech-07.txt

   [PSAMP-MIB] T. Dietz, D. Romascanu, B. Claise "Definitions of Managed Objects for
   Packet Sampling" draft-ietf-psamp-mib-01.txt 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-00.txt draft-ietf-psamp-info-02.txt

   [IPFIX-ARCH] G. Sadasivan, N. Brownlee Brownlee, B. Claise, J. Quittek,
   "Architecture Model for IP Flow Information Export" draft-ietf-ipfix-arch-02.txt", June 2003 draft-ietf-ipfix-
   arch-08.txt"

   [IPFIX-INFO] P. Calato, J. Meyer, J. Quittek, S. Bryant, B. Claise, J. Meyer, "Information
   Model for IP Flow Information Export" draft-ietf-ipfix-info-02, August 2003 draft-ietf-ipfix-info-11

   [IPFIX-PROTO] B. Claise, M. Fullmer, P. Calato, R. Penno, Claise (Editor) "IPFIX Protocol Specifications", draft-ietf-ipfix-protocol-02.txt, June
   2003
   draft-ietf-ipfix-protocol-19.txt

   [RFC1771]   Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-
   4)", (BGP-4)",
   RFC 1771, March 1995.

 10.2
     Informative References

   [PSAMP-FRAMEWORK] N. Duffield,

   [PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenber, Greenberg, M.
   Grossglauser
   Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan,  "A Framework
   for Passive Packet Measurement" draft-
   ietf-psamp-framework-04.txt

   [IPFIX-REQ] draft-ietf-psamp-framework-10.txt

   [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, "Requirements
   for IP Flow Information Export" draft-ietf-ipfix-reqs-
   10.txt, June 2003 Export", RFC 3917, October 2004

 11.
    Acknowledgments

   To be completed.

   Author’s

   The authors would like to thank the PSAMP group, especially Paul
   Aitken for fruitful discussions and for proofreading the document.

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