doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc5474.txt b/doc/rfc/rfc5474.txt
new file mode 100644
index 0000000..adca93d
--- /dev/null
+++ b/doc/rfc/rfc5474.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Network Working Group                                   N. Duffield, Ed.
+Request for Comments: 5474                          AT&T Labs - Research
+Category: Informational                                         D. Chiou
+                                                     University of Texas
+                                                               B. Claise
+                                                     Cisco Systems, Inc.
+                                                            A. Greenberg
+                                                               Microsoft
+                                                         M. Grossglauser
+                                                            EPFL & Nokia
+                                                              J. Rexford
+                                                    Princeton University
+                                                              March 2009
+
+
+            A Framework for Packet Selection and Reporting
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+Duffield, et al.             Informational                      [Page 1]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+Abstract
+
+   This document specifies a framework for the PSAMP (Packet SAMPling)
+   protocol.  The functions of this protocol are to select packets from
+   a stream according to a set of standardized Selectors, to form a
+   stream of reports on the selected packets, and to export the reports
+   to a Collector.  This framework details the components of this
+   architecture, then describes some generic requirements, motivated by
+   the dual aims of ubiquitous deployment and utility of the reports for
+   applications.  Detailed requirements for selection, reporting, and
+   exporting are described, along with configuration requirements of the
+   PSAMP functions.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. PSAMP Documents Overview ........................................4
+   3. Elements, Terminology, and High-Level Architecture ..............5
+      3.1. High-Level Description of the PSAMP Architecture ...........5
+      3.2. Observation Points, Packet Streams, and Packet Content .....5
+      3.3. Selection Process ..........................................6
+      3.4. Reporting ..................................................7
+      3.5. Metering Process ...........................................8
+      3.6. Exporting Process ..........................................8
+      3.7. PSAMP Device ...............................................9
+      3.8. Collector ..................................................9
+      3.9. Possible Configurations ....................................9
+   4. Generic Requirements for PSAMP .................................11
+      4.1. Generic Selection Process Requirements ....................11
+      4.2. Generic Reporting Requirements ............................12
+      4.3. Generic Exporting Process Requirements ....................12
+      4.4. Generic Configuration Requirements ........................13
+   5. Packet Selection ...............................................13
+      5.1. Two Types of Selectors ....................................13
+      5.2. PSAMP Packet Selectors ....................................14
+      5.3. Selection Fraction Terminology ............................17
+      5.4. Input Sequence Numbers for Primitive Selectors ............18
+      5.5. Composite Selectors .......................................19
+      5.6. Constraints on the Selection Fraction .....................19
+   6. Reporting ......................................................19
+      6.1. Mandatory Contents of Packet Reports: Basic Reports .......19
+      6.2. Extended Packet Reports ...................................20
+      6.3. Extended Packet Reports in the Presence of IPFIX ..........20
+      6.4. Report Interpretation .....................................21
+   7. Parallel Metering Processes ....................................22
+   8. Exporting Process ..............................................22
+      8.1. Use of IPFIX ..............................................22
+      8.2. Export Packets ............................................22
+
+
+
+Duffield, et al.             Informational                      [Page 2]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+      8.3. Congestion-Aware Unreliable Transport .....................22
+      8.4. Configurable Export Rate Limit ............................23
+      8.5. Limiting Delay for Export Packets .........................23
+      8.6. Export Packet Compression .................................24
+      8.7. Collector Destination .....................................25
+      8.8. Local Export ..............................................25
+   9. Configuration and Management ...................................25
+   10. Feasibility and Complexity ....................................26
+      10.1. Feasibility ..............................................26
+           10.1.1. Filtering .........................................26
+           10.1.2. Sampling ..........................................26
+           10.1.3. Hashing ...........................................26
+           10.1.4. Reporting .........................................27
+           10.1.5. Exporting .........................................27
+      10.2. Potential Hardware Complexity ............................27
+   11. Applications ..................................................28
+      11.1. Baseline Measurement and Drill Down ......................29
+      11.2. Trajectory Sampling ......................................29
+      11.3. Passive Performance Measurement ..........................30
+      11.4. Troubleshooting ..........................................30
+   12. Security Considerations .......................................31
+      12.1. Relation of PSAMP and IPFIX Security for
+            Exporting Process ........................................31
+      12.2. PSAMP Specific Privacy Considerations ....................31
+      12.3. Security Considerations for Hash-Based Selection .........32
+           12.3.1. Modes and Impact of Vulnerabilities ...............32
+           12.3.2. Use of Private Parameters in Hash Functions .......33
+           12.3.3. Strength of Hash Functions ........................33
+      12.4. Security Guidelines for Configuring PSAMP ................34
+   13. Contributors ..................................................34
+   14. Acknowledgments ...............................................34
+   15. References ....................................................34
+      15.1. Normative References .....................................34
+      15.2. Informative References ...................................35
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Duffield, et al.             Informational                      [Page 3]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+1. Introduction
+
+   This document describes the PSAMP framework for network elements to
+   select subsets of packets by statistical and other methods, and to
+   export a stream of reports on the selected packets to a Collector.
+
+   The motivation for the PSAMP standard comes from the need for
+   measurement-based support for network management and control across
+   multivendor domains.  This requires domain-wide consistency in the
+   types of selection schemes available, and the manner in which the
+   resulting measurements are presented and interpreted.
+
+   The motivation for specific packet selection operations comes from
+   the applications that they enable.  Development of the PSAMP standard
+   is open to influence by the requirements of standards in related IETF
+   Working Groups, for example, IP Performance Metrics (IPPM) [RFC2330]
+   and Internet Traffic Engineering (TEWG).
+
+   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.  But PSAMP
+   selection operations include random selection, deterministic
+   selection (Filtering), and deterministic approximations to random
+   selection (Hash-based Selection).
+
+2. PSAMP Documents Overview
+
+   This document is one out of a series of documents from the PSAMP
+   group.
+
+   RFC 5474 (this document): "A Framework for Packet Selection and
+   Reporting" describes the PSAMP framework for network elements to
+   select subsets of packets by statistical and other methods, and to
+   export a stream of reports on the selected packets to a Collector.
+   Definitions of terminology and the use of the terms "must", "should",
+   and "may" in this document are informational only.
+
+   [RFC5475]: "Sampling and Filtering Techniques for IP Packet
+   Selection" describes the set of packet selection techniques supported
+   by PSAMP.
+
+   [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications"
+   specifies the export of packet information from a PSAMP Exporting
+   Process to a PSAMP Collecting Process.
+
+   [RFC5477]: "Information Model for Packet Sampling Exports" defines an
+   information and data model for PSAMP.
+
+
+
+
+Duffield, et al.             Informational                      [Page 4]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+3.  Elements, Terminology, and High-Level Architecture
+
+3.1.  High-Level Description of the PSAMP Architecture
+
+   Here is an informal high-level description of the PSAMP protocol
+   operating in a PSAMP Device (all terms will be defined presently).  A
+   stream of packets is observed at an Observation Point.  A Selection
+   Process inspects each packet to determine whether or not it is to be
+   selected for reporting.  The Selection Process is part of the
+   Metering Process, which constructs a report on each selected packet,
+   using the Packet Content, and possibly other information such as the
+   packet treatment at the Observation Point or the arrival timestamp.
+   An Exporting Process sends the Packet Reports to a Collector,
+   together with any subsidiary information needed for their
+   interpretation.
+
+   The following figure indicates the sequence of the three processes
+   (Selection, Metering, and Exporting) within the PSAMP device.
+
+                +------------------+
+                | Metering Process |
+                | +-----------+    |     +-----------+
+      Observed  | | Selection |    |     | Exporting |
+      Packet--->| | Process   |--------->| Process   |--->Collector
+      Stream    | +-----------+    |     +-----------+
+                +------------------+
+
+   The following sections give detailed definitions of each of the
+   objects just named.
+
+3.2.  Observation Points, Packet Streams, and Packet Content
+
+   This section contains the definition of terms relevant to obtaining
+   the packet input to the Selection Process.
+
+   * 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 and that one Observation Point may be a
+      superset of several other Observation Points.  For
+
+
+
+
+
+Duffield, et al.             Informational                      [Page 5]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+      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.
+
+   * Observed Packet Stream
+
+      The Observed Packet Stream is the set of all packets observed at
+      the Observation Point.
+
+   * Packet Stream
+
+      A Packet Stream denotes a set of packets from the Observed Packet
+      Stream that flows past some specified point within the Metering
+      Process.  An example of a Packet Stream is the output of the
+      Selection Process.  Note that packets selected from a stream,
+      e.g., by Sampling, do not necessarily possess a property by which
+      they can be distinguished from packets that have not been
+      selected.  For this reason, the term "stream" is favored over
+      "flow", which is defined as a set of packets with common
+      properties [RFC3917].
+
+   * Packet Content
+
+      The Packet Content denotes the union of the packet header (which
+      includes link layer, network layer, and other encapsulation
+      headers) and the packet payload.
+
+3.3.  Selection Process
+
+   This section defines the Selection Process and related objects.
+
+   * Selection Process
+
+      A Selection Process takes the Observed Packet Stream as its input
+      and selects a subset of that stream as its output.
+
+   * Selection State
+
+      A Selection Process may maintain state information for use by the
+      Selection Process.  At a given time, the Selection State may
+      depend on packets observed at and before that time, and other
+      variables.  Examples include:
+
+         (i) sequence numbers of packets at the input of Selectors;
+
+        (ii) a timestamp of observation of the packet at the Observation
+             Point;
+
+
+
+
+Duffield, et al.             Informational                      [Page 6]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+       (iii) iterators for pseudorandom number generators;
+
+        (iv) hash values calculated during selection;
+
+         (v) indicators of whether the packet was selected by a given
+             Selector.
+
+      Selection Processes may change portions of the Selection State as
+      a result of processing a packet.  Selection State for a packet
+      reflects the state after processing the packet.
+
+      * Selector
+
+      A Selector defines the action of a Selection Process on a single
+      packet of its input.  If selected, the packet becomes an element
+      of the output Packet Stream.
+
+      The Selector can make use of the following information in
+      determining whether a packet is selected:
+
+         (i) the Packet Content;
+
+        (ii) information derived from the packet's treatment at the
+             Observation Point;
+
+       (iii) any Selection State that may be maintained by the Selection
+             Process.
+
+   * Composite Selector
+
+      A Composite Selector is an ordered composition of Selectors, in
+      which the output Packet Stream issuing from one Selector forms the
+      input Packet Stream to the succeeding Selector.
+
+   * Primitive Selector
+
+      A Selector is primitive if it is not a Composite Selector.
+
+3.4.  Reporting
+
+   * Packet Reports
+
+      Packet Reports comprise a configurable subset of a packet's input
+      to the Selection Process, including the Packet Content,
+      information relating to its treatment (for example, the output
+      interface), and its associated Selection State (for example, a
+      hash of the Packet Content).
+
+
+
+
+Duffield, et al.             Informational                      [Page 7]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   * Report Interpretation
+
+      Report Interpretation comprises subsidiary information, relating
+      to one or more packets, that is used for interpretation of their
+      Packet Reports.  Examples include configuration parameters of the
+      Selection Process.
+
+   * Report Stream
+
+      The Report Stream is the output of a Metering Process, comprising
+      two distinct types of information: Packet Reports and Report
+      Interpretation.
+
+3.5.  Metering Process
+
+   A Metering Process selects packets from the Observed Packet Stream
+   using a Selection Process, and produces as output a Report Stream
+   concerning the selected packets.
+
+   The PSAMP Metering Process can be viewed as analogous to the IPFIX
+   Metering Process [RFC5101], which produces Flow Records as its
+   output, with the difference that the PSAMP Metering Process always
+   contains a Selection Process.  The relationship between PSAMP and
+   IPFIX is further described in [RFC5477] and [RFC5474].
+
+3.6.  Exporting Process
+
+   * Exporting Process
+
+      An Exporting Process sends, in the form of Export Packets, the
+      output of one or more Metering Processes to one or more
+      Collectors.
+
+   * Export Packets
+
+      An Export Packet is a combination of Report Interpretation(s)
+      and/or one or more Packet Reports that are bundled by the
+      Exporting Process into an Export Packet for exporting to a
+      Collector.
+
+
+
+
+
+
+
+
+
+
+
+
+Duffield, et al.             Informational                      [Page 8]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+3.7.  PSAMP Device
+
+   A PSAMP Device is a device hosting at least an Observation Point, a
+   Metering Process (which includes a Selection Process), and an
+   Exporting Process.  Typically, corresponding Observation Point(s),
+   Metering Process(es), and Exporting Process(es) are co-located at
+   this device, for example, at a router.
+
+3.8.  Collector
+
+   A Collector receives a Report Stream exported by one or more
+   Exporting Processes.  In some cases, the host of the Metering and/or
+   Exporting Processes may also serve as the Collector.
+
+3.9.  Possible Configurations
+
+   Various possibilities for the high-level architecture of these
+   elements are as follows.
+
+      MP = Metering Process, EP = Exporting process
+
+       PSAMP Device
+      +---------------------+                 +------------------+
+      |Observation Point(s) |                 | Collector(1)     |
+      |MP(s)--->EP----------+---------------->|                  |
+      |MP(s)--->EP----------+-------+-------->|                  |
+      +---------------------+       |         +------------------+
+                                    |
+       PSAMP Device                 |
+      +---------------------+       |         +------------------+
+      |Observation Point(s) |       +-------->| Collector(2)     |
+      |MP(s)--->EP----------+---------------->|                  |
+      +---------------------+                 +------------------+
+
+       PSAMP Device
+      +---------------------+
+      |Observation Point(s) |
+      |MP(s)--->EP---+      |
+      |              |      |
+      |Collector(3)<-+      |
+      +---------------------+
+
+
+
+
+
+
+
+
+
+
+Duffield, et al.             Informational                      [Page 9]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+      The most simple Metering Process configuration is composed of:
+
+               +------------------------------------+
+               | +----------+                       |
+               | |Selection |                       |
+      Observed | |Process   |  Packet               |
+      Packet-->| |(Primitive|-> Stream ->           |--> Report Stream
+                   ^
+      Stream   | | Selector)|                       |
+                   ^
+               | +----------+                       |
+               |          Metering Process          |
+               +------------------------------------+
+
+      A Metering Process with a Composite Selector is composed of:
+
+               +--------------------------------------------------...
+               | +-----------------------------------+
+               | | +----------+         +----------+ |
+               | | |Selection |         |Selection | |
+      Observed | | |Process   |         |Process   | |
+      Packet-->| | |(Primitive|-Packet->|(Primitive|---> Packet ...
+                     ^                    ^
+      Stream   | | |Selector1)| Stream  |Selector2)| |   Stream
+                    ^                    ^
+               | | +----------+         +----------+ |
+               | |        Composite Selector         |
+               | +-----------------------------------+
+               |                   Metering Process
+               +--------------------------------------------------...
+
+                 ...-------------+
+                                 |
+                                 |
+                                 |
+                                 |
+                                 |---> Report Stream
+                                 |
+                                 |
+                                 |
+                                 |
+                                 |
+                 ...-------------+
+
+
+
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 10]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+4.  Generic Requirements for PSAMP
+
+   This section describes the generic requirements for the PSAMP
+   protocol.  A number of these are realized as specific requirements in
+   later sections.
+
+4.1.  Generic Selection Process Requirements
+
+   (a)  Ubiquity: The Selectors must be simple enough to be implemented
+        ubiquitously at maximal line rate.
+
+   (b)  Applicability: The set of Selectors must be rich enough to
+        support a range of existing and emerging measurement-based
+        applications and protocols.  This requires a workable trade-off
+        between the range of traffic engineering applications and
+        operational tasks it enables, and the complexity of the set of
+        capabilities.
+
+   (c)  Extensibility: The protocol must be able to accommodate
+        additional packet Selectors not currently defined.
+
+   (d)  Flexibility: The protocol must support selection of packets
+        using various network protocols or encapsulation layers,
+        including Internet Protocol Version 4 (IPv4) [RFC0791], Internet
+        Protocol Version 6 (IPv6) [RFC2460], and Multiprotocol Label
+        Switching (MPLS) [RFC3031].
+
+   (e)  Robust Selection: Packet selection must be robust against
+        attempts to craft an Observed Packet Stream from which packets
+        are selected disproportionately (e.g., to evade selection or
+        overload measurement systems).
+
+   (f)  Parallel Metering Processes: The protocol must support
+        simultaneous operation of multiple independent Metering
+        Processes at the same host.
+
+   (g)  Causality: The selection decision for each packet should depend
+        only weakly, if at all, upon future packets' arrivals.  This
+        promotes ubiquity by limiting the complexity of the selection
+        logic.
+
+   (h)  Encrypted Packets: Selectors that interpret packet fields must
+        be configurable to ignore (i.e., not select) encrypted packets,
+        when they are detected.
+
+   Specific Selectors are outlined in Section 5, and described in more
+   detail in the companion document [RFC5475].
+
+
+
+
+Duffield, et al.             Informational                     [Page 11]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+4.2.  Generic Reporting Requirements
+
+   (i)  Self-Defining: The Report Stream must be complete in the sense
+        that no additional information need be retrieved from the
+        Observation Point in order to interpret and analyze the reports.
+
+   (j)  Indication of Information Loss: The Report Stream must include
+        sufficient information to indicate or allow the detection of
+        loss occurring within the Selection, Metering, and/or Exporting
+        Processes, or in transport.  This may be achieved by the use of
+        sequence numbers.
+
+   (k)  Accuracy: The Report Stream must include information that
+        enables the accuracy of measurements to be determined.
+
+   (l)  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
+        Metering Process.
+
+   (m)  Privacy: Although selection of the content of Packet Reports
+        must be responsive to the needs of measurement applications, it
+        must also conform with [RFC2804].  In particular, full packet
+        capture of arbitrary Packet Streams is explicitly out of scope.
+
+   See Section 6 for further discussions on Reporting.
+
+4.3.  Generic Exporting Process Requirements
+
+   (n)  Timeliness: Configuration must allow for limiting of buffering
+        delays for the formation and transmission for Export Packets.
+        See Section 8.5 for further details.
+
+   (o)  Congestion Avoidance: Export of a Report Stream across a network
+        must be congestion avoiding in compliance with [RFC2914].  This
+        is discussed further in Section 8.3.
+
+   (p)  Secure Export
+
+         (i) confidentiality: The option to encrypt exported data must
+             be provided.
+
+        (ii) integrity: Alterations in transit to exported data must be
+             detectable at the Collector.
+
+       (iii) authenticity: Authenticity of exported data must be
+             verifiable by the Collector in order to detect forged data.
+
+
+
+
+Duffield, et al.             Informational                     [Page 12]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   The motivation here is the same as for security in IPFIX export; see
+   Sections 6.3 and 10 of [RFC3917].
+
+4.4.  Generic Configuration Requirements
+
+   (q)  Ease of Configuration: This applies to ease of configuration of
+        Sampling and export parameters, e.g., for automated remote
+        reconfiguration in response to collected reports.
+
+   (r)  Secure Configuration: The option to configure via protocols that
+        prevent unauthorized reconfiguration or eavesdropping on
+        configuration communications must be available.  Eavesdropping
+        on configuration might allow an attacker to gain knowledge that
+        would be helpful in crafting a Packet Stream to evade subversion
+        or overload the measurement infrastructure.
+
+   Configuration is discussed in Section 9.
+
+5.  Packet Selection
+
+   This section details specific requirements for the Selection Process,
+   motivated by the generic requirements of Section 3.3.
+
+5.1.  Two Types of Selectors
+
+   PSAMP categorizes Selectors into two types:
+
+   * Filtering: A filter is a Selector that selects a packet
+     deterministically based on the Packet Content, or its treatment, or
+     functions of these occurring in the Selection State.  Two examples
+     are:
+
+         (i) Property Match Filtering: A packet is selected if a
+             specific field in the packet equals a predefined value.
+
+        (ii) Hash-based Selection: A hash function is applied to the
+             Packet Content, and the packet is selected if the result
+             falls in a specified range.
+
+   * Sampling: A Selector that is not a filter is called a Sampling
+     operation.  This reflects the intuitive notion that if the
+     selection of a packet cannot be determined from its content alone,
+     there must be some type of Sampling taking place.
+
+   Sampling operations can be divided into two subtypes:
+
+         (i) Content-independent Sampling, which does not use Packet
+             Content in reaching Sampling decisions.  Examples include
+
+
+
+Duffield, et al.             Informational                     [Page 13]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+             systematic Sampling, and uniform pseudorandom Sampling
+             driven by a pseudorandom number whose generation is
+             independent of Packet Content.  Note that in content-
+             independent Sampling, it is not necessary to access the
+             Packet Content in order to make the selection decision.
+
+        (ii) Content-dependent Sampling, in which the Packet Content is
+             used in reaching selection decisions.  An application is
+             pseudorandom selection with a probability that depends on
+             the contents of a packet field, e.g., Sampling packets with
+             a probability dependent on their TCP/UDP port numbers.
+             Note that this is not a filter.
+
+5.2.  PSAMP Packet Selectors
+
+   A spectrum of packet Selectors is described in detail in [RFC5475].
+   Here we only briefly summarize the meanings for completeness.
+
+   A PSAMP Selection Process must support at least one of the following
+   Selectors.
+
+   * systematic count-based Sampling: Packet selection is triggered
+     periodically by packet count, a number of successive packets being
+     selected subsequent to each trigger.
+
+   * systematic time-based Sampling: This is similar to systematic
+     count-based Sampling except that selection is reckoned with respect
+     to time rather than count.  Packet selection is triggered at
+     periodic instants separated by a time called the spacing.  All
+     packets that arrive within a certain time of the trigger (called
+     the interval length) are selected.
+
+   * probabilistic n-out-of-N Sampling: From each count-based successive
+     block of N packets, n are selected at random.
+
+   * uniform probabilistic Sampling: Packets are selected independently
+     with fixed Sampling probability p.
+
+   * non-uniform probabilistic Sampling: Packets are selected
+     independently with probability p that depends on Packet Content.
+
+   * Property Match Filtering
+
+     With this Filtering method, a packet is selected if a specific
+     field within the packet and/or on properties of the router state
+     equal(s) a predefined value.  Possible filter fields are all IPFIX
+     Flow attributes specified in [RFC5102].  Further fields can be
+     defined by vendor-specific extensions.
+
+
+
+Duffield, et al.             Informational                     [Page 14]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+     A packet is selected if Field=Value.  Masks and ranges are only
+     supported to the extent to which [RFC5102] allows them, e.g., by
+     providing explicit fields like the netmasks for source and
+     destination addresses.
+
+     AND operations are possible by concatenating filters, thus
+     producing a composite selection operation.  In this case, the
+     ordering in which the Filtering happens is implicitly defined
+     (outer filters come after inner filters).  However, as long as the
+     concatenation is on filters only, the result of the cascaded filter
+     is independent from the order, 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 one single step.
+
+     OR operations are not supported with this basic model.  More
+     sophisticated filters (e.g., supporting bitmasks, ranges, or OR
+     operations) can be realized as vendor-specific schemes.
+
+     Property match operations should be available for different
+     protocol portions of the packet header:
+
+         (i) IP header (excluding options in IPv4, stacked headers in
+             IPv6)
+
+        (ii) transport header
+
+       (iii) encapsulation headers (e.g., the MPLS label stack, if
+             present)
+
+     When the PSAMP Device offers Property Match Filtering, and, in its
+     usual capacity other than in performing PSAMP functions, identifies
+     or processes information from IP, transport, or encapsulation
+     protocols, then the information should be made available for
+     Filtering.  For example, when a PSAMP Device is a router that
+     routes based on destination IP address, that field should be made
+     available for Filtering.  Conversely, a PSAMP Device that does not
+     route is not expected to be able to locate an IP address within a
+     packet, or make it available for Filtering, although it may do so.
+
+     Since packet encryption alters the meaning of encrypted fields,
+     Property Match Filtering must be configurable to ignore encrypted
+     packets when detected.
+
+     The Selection Process may support Filtering based on the properties
+     of the router state:
+
+
+
+
+Duffield, et al.             Informational                     [Page 15]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+         (i) Ingress interface at which packet arrives equals a
+             specified value
+
+        (ii) Egress interface to which packet is routed to equals a
+             specified value
+
+       (iii) Packet violated Access Control List (ACL) on the router
+
+        (iv) Failed Reverse Path Forwarding (RPF).  Packets that match
+             the Failed Reverse Path Forwarding (RPF) condition are
+             packets for which ingress Filtering failed as defined in
+             [RFC3704].
+
+         (v) Failed Resource Reservation Protocol (RSVP).  Packets that
+             match the Failed RSVP condition are packets that do not
+             fulfill the RSVP specification as defined in [RFC2205].
+
+        (vi) No route found for the packet
+
+       (vii) Origin Border Gateway Protocol (BGP) Autonomous System (AS)
+             [RFC4271] equals a specified value or lies within a given
+             range
+
+      (viii) Destination BGP AS equals a specified value or lies within
+             a given range
+
+     Router architectural considerations may preclude some information
+     concerning the packet treatment being available at line rate for
+     selection of packets.  For example, the Selection Process may not
+     be implemented in the fast path that is able to access router state
+     at line rate.  However, when Filtering follows Sampling (or some
+     other selection operation) in a Composite Selector, the rate of the
+     Packet Stream output from the sampler and input to the filter may
+     be sufficiently low that the filter could select based on router
+     state.
+
+   * Hash-based Selection:
+
+     Hash-based Selection will employ one or more hash functions to be
+     standardized.  A hash function is applied to a subset of Packet
+     Content, and the packet is selected if the resulting hash falls in
+     a specified range.  The stronger the hash function, the more
+     closely Hash-based Selection approximates uniform random Sampling.
+     Privacy of hash selection range and hash function parameters
+     obstructs subversion of the Selector by packets that are crafted
+
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 16]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+     either to avoid selection or to be selected.  Privacy of the hash
+     function is not required.  Robustness and security considerations
+     of Hash-based Selection are further discussed in [RFC5475].
+     Applications of hash-based Sampling are described in Section 11.
+
+5.3.  Selection Fraction Terminology
+
+   * 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 Population Size is the number of all packets in a Population.
+
+   * Sample Size
+
+      The Sample Size is the number of packets selected from the
+      Population by a Selector.
+
+   * Configured Selection Fraction
+
+      The Configured Selection Fraction is the expected ratio of the
+      Sample Size to the Population Size, as based on the configured
+      selection parameters.
+
+   * Attained Selection Fraction
+
+      The Attained Selection Fraction is the ratio of the actual Sample
+      Size to the Population Size.
+
+      For some Sampling methods, the Attained Selection Fraction can
+      differ from the Configured Selection Fraction due to, for example,
+      the inherent statistical variability in Sampling decisions of
+      probabilistic Sampling and Hash-based Selection.  Nevertheless,
+      for large Population Sizes and properly configured Selectors, the
+      Attained Selection Fraction usually approaches the Configured
+      Selection Fraction.
+
+      The notions of Configured/Attained Selection Fractions extend
+      beyond Selectors.  An illustrative example is the Configured
+      Selection Fraction of the composition of the Metering Process with
+      the Exporting Process.  Here the Population is the Observed Packet
+      Stream or a subset thereof.  The Configured Selection Fraction is
+      the fraction of the Population for which Packet Reports are
+
+
+
+Duffield, et al.             Informational                     [Page 17]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+      expected to reach the Collector.  This quantity may reflect
+      additional parameters, not necessarily described in the PSAMP
+      protocol, that determine the degree of loss suffered by Packet
+      Reports en route to the Collector, e.g., the transmission
+      bandwidth available to the Exporting Process.  In this example,
+      the Attained Selection Fraction is the fraction of Population
+      packets for which reports did actually reach the Collector, and
+      thus incorporates the effect of any loss of Packet Reports due,
+      e.g., to resource contention at the Observation Point or during
+      transmission.
+
+5.4.  Input Sequence Numbers for Primitive Selectors
+
+   Each instance of a Primitive Selector must maintain a count of
+   packets presented at its input.  The counter value is to be included
+   as a sequence number for selected packets.  The sequence numbers are
+   considered as part of the packet's Selection State.
+
+   Use of input sequence numbers enables applications to determine the
+   Attained Selection Fraction, and hence correctly normalize network
+   usage estimates regardless of loss of information, regardless of
+   whether this loss occurs because of discard of Packet Reports in the
+   Metering Process (e.g., due to resource contention in the host of
+   these processes), or loss of export packets in transmission or
+   collection.  See [RFC3176] for further details.
+
+   As an example, consider a set of n consecutive Packet Reports r1,
+   r2,... , rn, selected by a Sampling operation and received at a
+   Collector.  Let s1, s2,..., sn be the input sequence numbers reported
+   by the packets.  The Attained Selection Fraction for the composite of
+   the measurement and Exporting Processes, taking into account both
+   packet Sampling at the Observation Point and loss in transmission, is
+   computed as R = (n-1)/(sn-s1).  (Note that R would be 1 if all
+   packets were selected and there were no transmission loss.)
+
+   The Attained Selection Fraction can be used to estimate the number of
+   bytes present in a portion of the Observed Packet Stream.  Let b1,
+   b2,..., bn be the number of bytes reported in each of the packets
+   that reached the Collector, and set B = b1+b2+...+bn.  Then the total
+   bytes present in packets in the Observed Packet Stream whose input
+   sequence numbers lie between s1 and sn is estimated by B/R, i.e.,
+   scaling up the measured bytes through division by the Attained
+   Selection Fraction.
+
+   With Composite Selectors, an input sequence number must be reported
+   for each Selector in the composition.
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 18]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+5.5.  Composite Selectors
+
+   The ability to compose Selectors in a Selection Process should be
+   provided.  The following combinations appear to be most useful for
+   applications:
+
+   *  concatenation of Property Match Filters.  This is useful for
+      constructing the AND of the component filters.
+
+   *  Filtering followed by Sampling.
+
+   *  Sampling followed by Filtering.
+
+   Composite Selectors are useful for drill-down applications.  The
+   first component of a Composite Selector can be used to reduce the
+   load on the second component.  In this setting, the advantage to be
+   gained from a given ordering can depend on the composition of the
+   Packet Stream.
+
+5.6.  Constraints on the Selection Fraction
+
+   Sampling at full line rate, i.e., with probability 1, is not excluded
+   in principle, although resource constraints may not permit it in
+   practice.
+
+6.  Reporting
+
+   This section details specific requirements for reporting, motivated
+   by the generic requirements of Section 3.4.
+
+6.1.  Mandatory Contents of Packet Reports: Basic Reports
+
+   Packet Reports must include the following:
+
+         (i) the input sequence number(s) of any Selectors that acted on
+             the packet in the instance of a Metering Process that
+             produced the report.
+
+        (ii) the identifier of the Metering Process that produced the
+             selected packet.
+
+   The Metering Process must support inclusion of the following in each
+   Packet Report, as a configurable option:
+
+       (iii) a basic report on the packet, i.e., some number of
+             contiguous bytes from the start of the packet, including
+             the packet header (which includes network layer and any
+
+
+
+
+Duffield, et al.             Informational                     [Page 19]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+             encapsulation headers) and some subsequent bytes of the
+             packet payload.
+
+   Some devices may not have the resource capacity or functionality to
+   provide more detailed Packet Reports than those in (i), (ii), and
+   (iii) above.  Using this minimum required reporting functionality,
+   the Metering Process places the burden of interpretation on the
+   Collector or on applications that it supplies.  Some devices may have
+   the capability to provide extended Packet Reports, described in the
+   next section.
+
+6.2.  Extended Packet Reports
+
+   The Metering Process may support inclusion in Packet Reports of the
+   following information, inclusion of any or all being configurable as
+   an option.
+
+        (iv) fields relating to the following protocols used in the
+             packet: IPv4, IPV6, transport protocols, and encapsulation
+             protocols including MPLS.
+
+         (v) packet treatment, including:
+
+           - identifiers for any input and output interfaces of the
+             Observation Point that were traversed by the packet
+
+           - source and destination BGP AS
+
+        (vi) Selection State associated with the packet, including:
+
+           - the timestamp of observation of the packet at the
+             Observation Point.  The timestamp should be reported to
+             microsecond resolution.
+
+           - hash values, where calculated.
+
+   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 information in (iii) may not be exercised.
+
+6.3.  Extended Packet Reports in the Presence of IPFIX
+
+   If an IPFIX Metering Process is supported at the Observation Point,
+   then in order to be PSAMP compliant, Extended Packet Reports must be
+   able to include all fields required in the IPFIX information model
+   [RFC5102], with modifications appropriate to reporting on single
+   packets rather than Flows.
+
+
+
+
+Duffield, et al.             Informational                     [Page 20]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+6.4.  Report Interpretation
+
+   The Report Interpretation must include:
+
+         (i) configuration parameters of the Selectors of the packets
+             reported on;
+
+        (ii) format of the Packet Report;
+
+       (iii) indication of the inherent accuracy of the reported
+             quantities, e.g., of the packet timestamp.
+
+   The accuracy measure in (iii) is of fundamental importance for
+   estimating the likely error attached to estimates formed from the
+   Packet Reports by applications.
+
+   The requirements for robustness and transparency are motivations for
+   including Report Interpretation in the Report Stream: it makes the
+   Report Stream self-defining.  The PSAMP framework excludes reliance
+   on an alternative model in which interpretation is recovered out of
+   band.  This latter approach is not robust with respect to
+   undocumented changes in Selector configuration, and may give rise to
+   future architectural problems for network management systems to
+   coherently manage both configuration and data collection.
+
+   It is not envisaged that all Report Interpretation be included in
+   every Packet Report.  Many of the quantities listed above are
+   expected to be relatively static; they could be communicated
+   periodically, and upon change.
+
+7.  Parallel Metering Processes
+
+   Because of the increasing number of distinct measurement applications
+   with varying requirements, it is desirable to set up parallel
+   Metering Processes on a given Observed Packet Stream.  A device
+   capable of hosting a Metering Process should be able to support more
+   than one independently configurable Metering Process simultaneously.
+   Each such Metering Process should have the option of being equipped
+   with its own Exporting Process; otherwise, the parallel Metering
+   Processes may share the same Exporting Process.
+
+   Each of the parallel Metering Processes should be independent.
+   However, resource constraints may prevent complete reporting on a
+   packet selected by multiple Selection Processes.  In this case,
+   reporting for the packet must be complete for at least one Metering
+   Process; other Metering Processes need only record that they selected
+   the packet, e.g., by incrementing a counter.  The priority among
+   Metering Processes under resource contention should be configurable.
+
+
+
+Duffield, et al.             Informational                     [Page 21]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   It is not proposed to standardize the number of parallel Metering
+   Processes.
+
+8.  Exporting Process
+
+   This section details specific requirements for the Exporting Process,
+   motivated by the generic requirements of Section 3.6.
+
+8.1.  Use of IPFIX
+
+   PSAMP will use the IP Flow Information Export (IPFIX) protocol for
+   export of the Report Stream.  The IPFIX protocol is well suited for
+   this purpose, because the IPFIX architecture matches the PSAMP
+   architecture very well and the means provided by the IPFIX protocol
+   are sufficient for PSAMP purposes.  On the other hand, not all
+   features of the IPFIX protocol will need to be implemented by some
+   PSAMP Devices.  For example, a device that offers only content-
+   independent Sampling and basic PSAMP reporting has no need to support
+   IPFIX capabilities based on packet fields.
+
+8.2.  Export Packets
+
+   Export Packets may contain one or more Packet Reports, and/or Report
+   Interpretation.  Export Packets must also contain:
+
+         (i) an identifier for the Exporting Process
+
+        (ii) an Export Packet sequence number
+
+   An Export Packet sequence number enables the Collector to identify
+   loss of Export Packets in transit.  Note that some transport
+   protocols, e.g., UDP, do not provide sequence numbers.  Moreover,
+   having sequence numbers available at the application level enables
+   the Collector to calculate the packet loss rate for use, e.g., in
+   estimating original traffic volumes from Export Packets that reach
+   the Collector.
+
+8.3.  Congestion-Aware Unreliable Transport
+
+   The export of the Report Stream does not require reliable export.
+   Section 5.4 shows that the use of input sequence numbers in packet
+   Selectors means that the ability to estimate traffic rates is not
+   impaired by export loss.  Export Packet loss becomes another form of
+   Sampling, albeit a less desirable, and less controlled, form of
+   Sampling.
+
+   In distinction, retransmission of lost Export Packets consumes
+   additional network resources.  The requirement to store
+
+
+
+Duffield, et al.             Informational                     [Page 22]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   unacknowledged data is an impediment to having ubiquitous support for
+   PSAMP.
+
+   In order to jointly satisfy the timeliness and congestion avoidance
+   requirements of Section 4.3, a congestion-aware unreliable transport
+   protocol may be used.  IPFIX is compatible with this requirement,
+   since it mandates support of the Stream Control Transmission Protocol
+   (SCTP) [RFC4960] and the SCTP Partial Reliability Extension
+   [RFC3758].
+
+   IPFIX also allows the use of the User Datagram Protocol (UDP)
+   [RFC0768], although it is not a congestion-aware protocol.  However,
+   in this case, the Export Packets must remain wholly within the
+   administrative domains of the operators [RFC5101].  The PSAMP
+   Exporting Process is equipped with a configurable export rate limit
+   (see Section 8.4) that can be used to limit the export rate when a
+   congestion-aware transport protocol is not used.  The Collector, upon
+   detection of Export Packet loss through missing export sequence
+   numbers, may reconfigure the export rate limit downwards in order to
+   avoid congestion.
+
+8.4.  Configurable Export Rate Limit
+
+   The Exporting Process must have an export rate limit, configurable
+   per Exporting Process.  This is useful for two reasons:
+
+         (i) Even without network congestion, the rate of packet
+             selection may exceed the capacity of the Collector to
+             process reports, particularly when many Exporting Processes
+             feed a common Collector.  Use of an Export Rate Limit
+             allows control of the global input rate to the Collector.
+
+        (ii) IPFIX provides export using UDP as the transport protocol
+             in some circumstances.  An Export Rate Limit allows the
+             capping of the export rate to match both path link speeds
+             and the capacity of the Collector.
+
+8.5.  Limiting Delay for Export Packets
+
+   Low measurement latency allows the traffic monitoring system to be
+   more responsive to real-time network events, for example, in quickly
+   identifying sources of congestion.  Timeliness is generally a good
+   thing for devices performing the Sampling since it minimizes the
+   amount of memory needed to buffer samples.
+
+   Keeping the packet dispatching delay small has other benefits besides
+   limiting buffer requirements.  For many applications, a resolution of
+   1 second is sufficient.  Applications in this category would include
+
+
+
+Duffield, et al.             Informational                     [Page 23]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   identifying sources associated with congestion, tracing Denial-of-
+   Service (DoS) attacks through the network, and constructing traffic
+   matrices.  Furthermore, keeping dispatch delay within the resolution
+   required by applications eliminates the need for timestamping by
+   synchronized clocks at Observation Points, or for the Observation
+   Points and Collector to maintain bidirectional communication in order
+   to track clock offsets.  The Collector can simply process Packet
+   Reports in the order that they are received, using its own clock as a
+   "global" time base.  This avoids the complexity of buffering and
+   reordering samples.  See [DuGeGr02] for an example.
+
+   The delay between observation of a packet and transmission of an
+   Export Packet containing a report on that packet has several
+   components.  It is difficult to standardize a given numerical delay
+   requirement, since in practice the delay may be sensitive to
+   processor load at the Observation Point.  Therefore, PSAMP aims to
+   control that portion of the delay within the Observation Point that
+   is due to buffering in the formation and transmission of Export
+   Packets.
+
+   In order to limit delay in the formation of Export Packets, the
+   Exporting Process must provide the ability to close out and enqueue
+   for transmission any Export Packet during formation as soon as it
+   includes one Packet Report.
+
+   In order to limit the delay in the transmission of Export Packets, a
+   configurable upper bound to the delay of an Export Packet prior to
+   transmission must be provided.  If the bound is exceeded, the Export
+   Packet is dropped.  This functionality can be provided by the timed
+   reliability service of the SCTP Partial Reliability Extension
+   [RFC3758].
+
+   The Exporting Process may enqueue the Report Stream in order to
+   export multiple Packet Reports in a single Export Packet.  Any
+   consequent delay must still allow for timely availability of Packet
+   Reports as just described.  The timed reliability service of the SCTP
+   Partial Reliability Extension [RFC3758] allows the dropping of
+   packets from the export buffer once their age in the buffer exceeds a
+   configurable bound.  A suitable default value for the bound should be
+   used in order to avoid a low transmission rate due to
+   misconfiguration.
+
+8.6.  Export Packet Compression
+
+   To conserve network bandwidth and resources at the Collector, the
+   Export Packets may be compressed before export.  Compression is
+   expected to be quite effective since the selected packets may share
+   many fields in common, e.g., if a filter focuses on packets with
+
+
+
+Duffield, et al.             Informational                     [Page 24]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   certain values in particular header fields.  Using compression,
+   however, could impact the timeliness of Packet Reports.  Any
+   consequent delay must not violate the timeliness requirement for
+   availability of Packet Reports at the Collector.
+
+8.7.  Collector Destination
+
+   When exporting to a remote Collector, the Collector is identified by
+   IP address, transport protocol, and transport port number.
+
+8.8.  Local Export
+
+   The Report Stream may be directly exported to on-board measurement-
+   based applications, for example, those that form composite statistics
+   from more than one packet.  Local Export may be presented through an
+   interface directly to the higher-level applications, i.e., through an
+   API, rather than employing the transport used for off-board export.
+   Specification of such an API is outside the scope of the PSAMP
+   framework.
+
+   A possible example of Local Export could be that packets selected by
+   the PSAMP Metering Process serve as the input for the IPFIX protocol,
+   which then forms Flow Records out of the stream of selected packets.
+
+9.  Configuration and Management
+
+   A key requirement for PSAMP is the easy reconfiguration of the
+   parameters of the Metering Process, including those for selection and
+   Packet Reports, and of the Exporting Process.  An important example
+   is to support measurement-based applications that want to adaptively
+   drill-down on traffic detail in real time.
+
+   To facilitate retrieval and monitoring of parameters, they are to
+   reside in a Management Information Base (MIB).  Mandatory monitoring
+   objects will cover all mandatory PSAMP functionality.  Alarming of
+   specific parameters could be triggered with thresholding mechanisms
+   such as the RMON (Remote Network Monitoring) event and alarm
+   [RFC2819] or the event MIB [RFC2981].
+
+
+   For configuring parameters of the Metering Process, several
+   alternatives are available including a MIB module with writeable
+   objects, as well as other configuration protocols.  For configuring
+   parameters of the Exporting Process, the Packet Report, and the
+   Report Interpretation, which is an IFPIX task, the IPFIX
+   configuration method(s) should be used.
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 25]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   Although management and configuration of Collectors is out of scope,
+   a PSAMP Device, to the extent that it employs IPFIX as an export
+   protocol, inherits from IPFIX the capability to detect and recover
+   from Collector failure; see Section 8.2 of [RFC5470].
+
+10.  Feasibility and Complexity
+
+   In order for PSAMP to be supported across the entire spectrum of
+   networking equipment, it must be simple and inexpensive to implement.
+   One can envision easy-to-implement instances of the mechanisms
+   described within this document.  Thus, for that subset of instances,
+   it should be straightforward for virtually all system vendors to
+   include them within their products.  Indeed, Sampling and Filtering
+   operations are already realized in available equipment.
+
+   Here we give some specific arguments to demonstrate feasibility and
+   comment on the complexity of hardware implementations.  We stress
+   here that the point of these arguments is not to favor or recommend
+   any particular implementation, or to suggest a path for
+   standardization, but rather to demonstrate that the set of possible
+   implementations is not empty.
+
+10.1.  Feasibility
+
+10.1.1.  Filtering
+
+   Filtering consists of a small number of mask (bit-wise logical),
+   comparison, and range (greater than) operations.  Implementation of
+   at least a small number of such operations is straightforward.  For
+   example, filters for security Access Control Lists (ACLs) are widely
+   implemented.  This could be as simple as an exact match on certain
+   fields, or involve more complex comparisons and ranges.
+
+10.1.2.  Sampling
+
+   Sampling based on either counters (counter set, decrement, test for
+   equal to zero) or range matching on the hash of a packet (greater
+   than) is possible given a small number of Selectors, although there
+   may be some differences in ease of implementation for hardware vs.
+   software platforms.
+
+10.1.3.  Hashing
+
+   Hashing functions vary greatly in complexity.  Execution of a small
+   number of sufficiently simple hash functions is implementable at line
+   rate.  Concerning the input to the hash function, hop-invariant IP
+   header fields (IP address, IP identification) and TCP/UDP header
+   fields (port numbers, TCP sequence number) drawn from the first 40
+
+
+
+Duffield, et al.             Informational                     [Page 26]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   bytes of the packet have been found to possess a considerable
+   variability; see [DuGr01].
+
+10.1.4.  Reporting
+
+   The simplest Packet Report would duplicate the first n bytes of the
+   packet.  However, such an uncompressed format may tax the bandwidth
+   available to the Exporting Process for high Sampling rates; reporting
+   selected fields would save on this bandwidth.  Thus, there is a
+   trade-off between simplicity and bandwidth limitations.
+
+10.1.5.  Exporting
+
+   Ease of exporting Export Packets depends on the system architecture.
+   Most systems should be able to support export by insertion of Export
+   Packets, even through the software path.
+
+10.2.  Potential Hardware Complexity
+
+   Achieving low constants for performance while minimizing hardware
+   resources is, of course, a challenge, especially at very high clock
+   frequencies.  Most of the Selectors, however, are very basic and
+   their implementations very well understood; in fact, the average
+   Application-Specific Integrated Circuit (ASIC) designer simply uses
+   canned library instances of these operations rather than design them
+   from scratch.  In addition, networking equipment generally does not
+   need to run at the fastest clock rates, further reducing the effort
+   required to get reasonably efficient implementations.
+
+   Simple bit-wise logical operations are easy to implement in hardware.
+   Such operations (NAND/NOR/XNOR) directly translate to four-transistor
+   gates.  Each bit of a multiple-bit logical operation is completely
+   independent and thus can be performed in parallel incurring no
+   additional performance cost above a single-bit operation.
+
+   Comparisons (EQ/NEQ) take O(log(M)) stages of logic, where M is the
+   number of bits involved in the comparison.  The log(M) is required to
+   accumulate the result into a single bit.
+
+   Greater-than operations, as used to determine whether a hash falls in
+   a selection range, are a determination of the most significant
+   not-equivalent bit in the two operands.  The operand with that most-
+   significant-not-equal bit set to be one is greater than the other.
+
+   Thus, a greater-than operation is also an O(log(M)) stages-of-logic
+   operation.  Optimized implementations of arithmetic operations are
+   also O(log(M)) due to propagation of the carry bit.
+
+
+
+
+Duffield, et al.             Informational                     [Page 27]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   Setting a counter is simply loading a register with a state.  Such an
+   operation is simple and fast O(1).  Incrementing or decrementing a
+   counter is a read, followed by an arithmetic operation, followed by a
+   store.  Making the register dual-ported does take additional space,
+   but it is a well-understood technique.  Thus, the increment/decrement
+   is also an O(log(M)) operation.
+
+   Hashing functions come in a variety of forms.  The computation
+   involved in a standard Cyclic Redundancy Check (CRC), for example, is
+   essentially a set of XOR operations, where the intermediate result is
+   stored and XORed with the next chunk of data.  There are only O(1)
+   operations and no log complexity operations.  Thus, a simple hash
+   function, such as CRC or generalizations thereof, can be implemented
+   in hardware very efficiently.
+
+   At the other end of the range of complexity, the MD5 function uses a
+   large number of bit-wise conditional operations and arithmetic
+   operations.  The former are O(1) operations and the latter are
+   O(log(M)).  MD5 specifies 256 32 bit ADD operations per 16 bytes of
+   input processed.  Consider processing 10 Gb/sec at 100 MHz (this
+   processing rate appears to be currently available).  This requires
+   processing 12.5 bytes/cycle, and hence at least 200 adders, a
+   sizeable number.  Because of data dependencies within the MD5
+   algorithm, the adders cannot be simply run in parallel, thus
+   requiring either faster clock rates and/or more advanced
+   architectures.  Thus, selection hashing functions as complex as MD5
+   may be precluded for ubiquitous use at full line rate.  This
+   motivates exploring the use of selection hash functions with
+   complexity somewhere between that of MD5 and CRC.  In some
+   applications (see Section 11), a second hash may be calculated on
+   only selected packets; MD5 is feasible for this purpose if the rate
+   of production of selected packets is sufficiently low.
+
+11.  Applications
+
+   We first describe several representative operational applications
+   that require traffic measurements at various levels of temporal and
+   spatial granularity.  Some of the goals here appear similar to those
+   of IPFIX, at least in the broad classes of applications supported.
+   The major benefit of PSAMP is the support of new network management
+   applications, specifically, those enabled by the packet Selectors
+   that it supports.
+
+
+
+
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 28]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+11.1.  Baseline Measurement and Drill Down
+
+   Packet Sampling is ideally suited to determine the composition of the
+   traffic across a network.  The approach is to enable measurement on a
+   cut-set of the network links such that each packet entering the
+   network is seen at least once, for example, on all ingress links.
+   Unfiltered Sampling with a relatively low selection fraction
+   establishes baseline measurements of the network traffic.  Packet
+   Reports include packet attributes of common interest: source and
+   destination address and port numbers, prefix, protocol number, type
+   of service, etc.  Traffic matrices are indicated by reporting source
+   and destination AS matrices.  Absolute traffic volumes are estimated
+   by renormalizing the sampled traffic volumes through division by
+   either the Configured Selection Fraction or the Attained Selection
+   Fraction (as derived from input packet counters included in the
+   Report Stream).
+
+   Suppose an operator or a measurement-based application detects an
+   interesting subset of a Packet Stream, as identified by a particular
+   packet attribute.  Real-time drill down to that subset is achieved by
+   instantiating a new Metering Process on the same Observed Packet
+   Stream from which the subset was reported.  The Selection Process of
+   the new Metering Process filters according to the attribute of
+   interest, and composes with Sampling if necessary to manage the
+   attained fraction of packets selected.
+
+11.2.  Trajectory Sampling
+
+   The goal of trajectory Sampling is the selection of a subset of
+   packets at all enabled Observation Points at which these packets are
+   observed in a network domain.  Thus, the selection decisions are
+   consistent in the sense that each packet is selected either at all
+   enabled Observation Points or at none of them.  Trajectory Sampling
+   is realized by Hash-based Selection if all enabled Observation Points
+   apply a common hash function to a portion of the Packet Content that
+   is invariant along the packet path.  (Thus, fields such at TTL and
+   CRC are excluded.)
+
+   The trajectory followed by a packet is reconstructed from Packet
+   Reports on it that reach the Collector.  Reports on a given packet
+   are associated by matching either a label comprising the invariant
+   reported Packet Content or possibly some digest of it.  The
+   reconstruction of trajectories and methods for dealing with possible
+   ambiguities due to label collisions (identical labels reported by
+   different packets) and potential loss of reports in transmission are
+   dealt with in [DuGr01], [DuGeGr02], and [DuGr04].
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 29]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+11.3.  Passive Performance Measurement
+
+   Trajectory Sampling enables the tracking of the performance
+   experience by customer traffic, customers identified by a list of
+   source or destination prefixes, or by ingress or egress interfaces.
+   Operational uses include the verification of Service Level Agreements
+   (SLAs), and troubleshooting following a customer complaint.
+
+   In this application, trajectory Sampling is enabled at all network
+   ingress and egress interfaces.  Rates of loss in transit between
+   ingress and egress are estimated from the proportion of trajectories
+   for which no egress report is received.  Note that loss of customer
+   packets is distinguishable from loss of Packet Reports through use of
+   report sequence numbers.  Assuming synchronization of clocks between
+   different entities, delay of customer traffic across the network may
+   also be measured; see [Zs02].
+
+   Extending hash selection to all interfaces in the network would
+   enable attribution of poor performance to individual network links.
+
+11.4.  Troubleshooting
+
+   PSAMP Packet Reports can also be used to diagnose problems whose
+   occurrence is evident from aggregate statistics, per interface
+   utilization and packet loss statistics.  These statistics are
+   typically moving averages over relatively long time windows, e.g., 5
+   minutes, and serve as a coarse-grain indication of operational health
+   of the network.  The most common method of obtaining such
+   measurements is through the appropriate SNMP MIBs (MIB-II [RFC1213]
+   and vendor-specific MIBs).
+
+   Suppose an operator detects a link that is persistently overloaded
+   and experiences significant packet drop rates.  There is a wide range
+   of potential causes: routing parameters (e.g., OSPF link weights)
+   that are poorly adapted to the traffic matrix, e.g., because of a
+   shift in that matrix; a DoS attack, a flash crowd, or a routing
+   problem (link flapping).  In most cases, aggregate link statistics
+   are not sufficient to distinguish between such causes and to decide
+   on an appropriate corrective action.  For example, if routing over
+   two links is unstable, and the links flap between being overloaded
+   and inactive, this might be averaged out in a 5-minute window,
+   indicating moderate loads on both links.
+
+   Baseline PSAMP measurement of the congested link, as described in
+   Section 11.1, enables measurements that are fine grained in both
+   space and time.  The operator has to be able to determine how many
+   bytes/packets are generated for each source/destination address, port
+   number, and prefix, or other attributes, such as protocol number,
+
+
+
+Duffield, et al.             Informational                     [Page 30]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   MPLS forwarding equivalence class (FEC), type of service, etc.  This
+   allows the precise determination of the nature of the offending
+   traffic.  For example, in the case of a Distributed Denial of Service
+   (DDoS) attack, the operator would see a significant fraction of
+   traffic with an identical destination address.
+
+   In certain circumstances, precise information about the spatial flow
+   of traffic through the network domain is required to detect and
+   diagnose problems and verify correct network behavior.  In the case
+   of the overloaded link, it would be very helpful to know the precise
+   set of paths that packets traversing this link follow.  This would
+   readily reveal a routing problem such as a loop, or a link with a
+   misconfigured weight.  More generally, complex diagnosis scenarios
+   can benefit from measurement of traffic intensities (and other
+   attributes) over a set of paths that is constrained in some way.  For
+   example, if a multihomed customer complains about performance
+   problems on one of the access links from a particular source address
+   prefix, the operator should be able to examine in detail the traffic
+   from that source prefix that also traverses the specified access link
+   towards the customer.
+
+   While it is in principle possible to obtain the spatial flow of
+   traffic through auxiliary network state information, e.g., by
+   downloading routing and forwarding tables from routers, this
+   information is often unreliable, outdated, voluminous, and contingent
+   on a network model.  For operational purposes, a direct observation
+   of traffic flow provided by trajectory Sampling is more reliable, as
+   it does not depend on any such auxiliary information.  For example,
+   if there was a bug in a router's software, direct observation would
+   allow the diagnosis the effect of this bug, while an indirect method
+   would not.
+
+12.  Security Considerations
+
+12.1.  Relation of PSAMP and IPFIX Security for Exporting Process
+
+   As detailed in Section 4.3, PSAMP shares with IPFIX security
+   requirements for export, namely, confidentiality, integrity, and
+   authenticity of the exported data; see also Sections 6.3 and 10 of
+   [RFC3917].  Since PSAMP will use IPFIX for export, it can employ the
+   IPFIX protocol [RFC5101] to meet its requirements.
+
+12.2.  PSAMP Specific Privacy Considerations
+
+   In distinction with IPFIX, a PSAMP Device may, in some
+   configurations, report some number of initial bytes of the packet,
+   which may include some part of a packet payload.  This option is
+   conformant with the requirements of [RFC2804] since it does not
+
+
+
+Duffield, et al.             Informational                     [Page 31]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   mandate configurations that would enable capture of an entire Packet
+   Stream of a Flow: neither a unit Sampling rate (1 in 1 Sampling) nor
+   reporting a specific number of initial bytes is required by the PSAMP
+   protocol.
+
+   To preserve privacy of any users acting as sender or receiver of the
+   observed traffic, the contents of the Packet Reports must be able to
+   remain confidential in transit between the exporting PSAMP Device and
+   the Collector.  PSAMP will use IPFIX as the exporting protocol, and
+   the IPFIX protocol must provide mechanisms to ensure confidentiality
+   of the Exporting Process, for example, encryption of Export Packets
+   [RFC5101].
+
+12.3.  Security Considerations for Hash-Based Selection
+
+12.3.1.  Modes and Impact of Vulnerabilities
+
+   A concern for Hash-based Selection is whether some large set of
+   related packets could be disproportionately sampled, either
+
+         (i) through unanticipated behavior in the hash function, or
+
+        (ii) because the packets had been deliberately crafted to have
+             this property.
+
+   As detailed below, only cryptographic hash functions (e.g., one based
+   on MD5) employing a private parameter are sufficiently strong to
+   withstand the range of conceivable attacks.  However, implementation
+   considerations may preclude operating the strongest hash functions at
+   line rate.  For this reason, PSAMP is not expected to standardize
+   around a cryptographic hash function at the present time.  The
+   purpose of this section is to inform discussion of the
+   vulnerabilities and trade-offs associated with different hash
+   function choices.  Section 6.2.2 of [RFC5475] does this in more
+   detail.
+
+   An attacker able to predict packet Sampling outcomes could craft a
+   Packet Stream that could evade selection, or another that could
+   overwhelm the measurement infrastructure with all its packets being
+   selected.  An attacker may attempt to do this based on knowledge of
+   the hash function.  An attacker could employ knowledge of selection
+   outcomes of a known Packet Stream to reverse engineer parameters of
+   the hash function.  This knowledge could be gathered, e.g., from
+   billing information, reactions of intrusion detection systems, or
+   observation of a Report Stream.
+
+   Since Hash-based Selection is deterministic, it is vulnerable to
+   replay attacks.  Repetition of a single packet may be noticeable to
+
+
+
+Duffield, et al.             Informational                     [Page 32]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   other measurement methods if employed (e.g., collection of Flow
+   statistics), whereas a set of distinct packets that appears
+   statistically similar to regular traffic may be less noticeable.  The
+   impact of replay attacks on Hash-based Selection may be mitigated by
+   repeated changing of hash function parameters.
+
+12.3.2.  Use of Private Parameters in Hash Functions
+
+   Because hash functions for Hash-based Selection are to be
+   standardized and hence public, the packet selection decision must be
+   controlled by some private quantity associated with the Hash-based
+   Selection Selector.  Making private the range of hash values for
+   which packets are selected is not alone sufficient to prevent an
+   attacker crafting a stream of distinct packets that are
+   disproportionately selected.  A private parameter must be used within
+   the hash function, for example, a private modulus in a hash function,
+   or by concatenating the hash input with a private string prior to
+   hashing.
+
+12.3.3.  Strength of Hash Functions
+
+   The specific choice of hash function and its usage determines the
+   types of potential vulnerability:
+
+   * Cryptographic hash functions: when a private parameter is used,
+     future selection outcomes cannot be predicted even by an attacker
+     with knowledge of past selection outcomes.
+
+   * Non-cryptographic hash functions:
+
+     Using knowledge of past selection outcomes: some well-known hash
+     functions, e.g., CRC-32, are vulnerable to attacks, in the sense
+     that their private parameter can be determined with knowledge of
+     sufficiently many past selections, even when a private parameter is
+     used; see [GoRe07].
+
+     No knowledge of past selection outcomes: using a private parameter
+     hardened the hash function to classes of attacks that work when the
+     parameter is public, although vulnerability to future attacks is
+     not precluded.
+
+12.4.  Security Guidelines for Configuring PSAMP
+
+   Hash function parameters configured in a PSAMP Device are sensitive
+   information, which must be kept private.  As well as using probing
+   techniques to discover parameters of non-cryptographic hash functions
+   as described above, implementation and procedural weaknesses may lead
+
+
+
+
+Duffield, et al.             Informational                     [Page 33]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   to attackers discovering parameters, whatever class of hash function
+   is used.  The following measures may prevent this from occurring:
+
+   Hash function parameters must not be displayable in cleartext on
+   PSAMP Devices.  This reduces the chance for the parameters to be
+   discovered by unauthorized access to the PSAMP Device.
+
+   Hash function parameters must not be remotely set in cleartext over a
+   channel that may be eavesdropped.
+
+   Hash function parameters must be changed regularly.  Note that such
+   changes must be synchronized over all PSAMP Devices in a domain under
+   which trajectory Sampling is employed in order to maintain consistent
+   Sampling of packets over the domain.
+
+   Default hash function parameter values should be initialized
+   randomly, in order to avoid predictable values that attackers could
+   exploit.
+
+13.  Contributors
+
+   Sharon Goldberg contributed to Section 12.3 on security
+   considerations for Hash-based Selection.
+
+   Sharon Goldberg
+   Department of Electrical Engineering
+   Princeton University
+   F210-K EQuad
+   Princeton, NJ 08544
+   USA
+   EMail: goldbe@princeton.edu
+
+14.  Acknowledgments
+
+   The authors would like to thank Peram Marimuthu and Ganesh Sadasivan
+   for their input in early working drafts of this document.
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC5476]  Claise. B., Ed., "Packet Sampling (PSAMP) Protocol
+              Specifications", RFC 5476, March 2009.
+
+   [RFC5477]  Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
+              Carle, "Information Model for Packet Sampling Exports",
+              RFC 5477, March 2009.
+
+
+
+
+Duffield, et al.             Informational                     [Page 34]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   [RFC5101]  Claise, B., Ed., "Specification of the IP Flow Information
+              Export (IPFIX) Protocol for the Exchange of IP Traffic
+              Flow Information", RFC 5101, January 2008.
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
+              Meyer, "Information Model for IP Flow Information Export",
+              RFC 5102, January 2008.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, September 2007.
+
+   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+              Conrad, "Stream Control Transmission Protocol (SCTP)
+              Partial Reliability Extension", RFC 3758, May 2004.
+
+   [RFC5475]  Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
+              Raspall, " Sampling and Filtering Techniques for IP Packet
+              Selection", RFC 5475, March 2009.
+
+15.2.  Informative References
+
+   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+              Networks", BCP 84, RFC 3704, March 2004.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [DuGeGr02] N.G. Duffield, A. Gerber, M. Grossglauser, "Trajectory
+              Engine: A Backend for Trajectory Sampling", IEEE Network
+              Operations and Management Symposium 2002, Florence, Italy,
+              April 15-19, 2002.
+
+   [DuGr04]   N. G. Duffield and M. Grossglauser, "Trajectory Sampling
+              with Unreliable Reporting", Proc IEEE Infocom 2004, Hong
+              Kong, March 2004.
+
+   [DuGr08]   N. G. Duffield and M. Grossglauser, "Trajectory Sampling
+              with Unreliable Reporting", IEEE/ACM Trans. on Networking,
+              16(1), February 2008.
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 35]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41, RFC
+              2914, September 2000.
+
+   [GoRe07]   S. Goldberg, J. Rexford, "Security Vulnerabilities and
+              Solutions for Packet Sampling", IEEE Sarnoff Symposium,
+              Princeton, NJ, May 2007.
+
+   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May
+              2000.
+
+   [RFC2981]  Kavasseri, R., Ed., "Event MIB", RFC 2981, October 2000.
+
+   [RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
+              for Network Management of TCP/IP-based internets:MIB-II",
+              STD 17, RFC 1213, March 1991.
+
+   [RFC3176]  Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's
+              sFlow: A Method for Monitoring Traffic in Switched and
+              Routed Networks", RFC 3176, September 2001.
+
+   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+              "Framework for IP Performance Metrics", RFC 2330, May
+              1998.
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
+
+   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
+              "Requirements for IP Flow Information Export (IPFIX)", RFC
+              3917, October 2004.
+
+   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+              Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+              2006.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031, January 2001.
+
+   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
+              "Architecture for IP Flow Information Export", RFC 5470,
+              March 2009.
+
+   [RFC2819]  Waldbusser, S., "Remote Network Monitoring Management
+              Information Base", STD 59, RFC 2819, May 2000.
+
+
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 36]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   [Zs02]     T. Zseby, "Deployment of Sampling Methods for SLA
+              Validation with Non-Intrusive Measurements", Proceedings
+              of Passive and Active Measurement Workshop (PAM 2002),
+              Fort Collins, CO, USA, March 25-26, 2002.
+
+Authors' Addresses
+
+   Derek Chiou
+   Department of Electrical and Computer Engineering
+   University of Texas at Austin
+   1 University Station, Stop C0803, ENS Building room 135,
+   Austin TX, 78712
+   USA
+
+   Phone: +1 512 232 7722
+   EMail: Derek@ece.utexas.edu
+
+
+   Benoit Claise
+   Cisco Systems
+   De Kleetlaan 6a b1
+   1831 Diegem
+   Belgium
+
+   Phone: +32 2 704 5622
+   EMail: bclaise@cisco.com
+
+
+   Nick Duffield, Editor
+   AT&T Labs - Research
+   Room B139
+   180 Park Ave
+   Florham Park NJ 07932
+   USA
+
+   Phone: +1 973-360-8726
+   EMail: duffield@research.att.com
+
+
+   Albert Greenberg
+   One Microsoft Way
+   Redmond, WA 98052-6399
+   USA
+
+   Phone: +1 425-722-8870
+   EMail: albert@microsoft.com
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 37]
+
+RFC 5474             Packet Selection and Reporting           March 2009
+
+
+   Matthias Grossglauser
+   School of Computer and Communication Sciences
+   EPFL
+   1015 Lausanne
+   Switzerland
+
+   EMail: matthias.grossglauser@epfl.ch
+
+
+   Jennifer Rexford
+   Department of Computer Science
+   Princeton University
+   35 Olden Street
+   Princeton, NJ 08540-5233
+   USA
+
+   Phone: +1 609-258-5182
+   EMail: jrex@cs.princeton.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Duffield, et al.             Informational                     [Page 38]
+