Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6728

Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols

Pages: 129
Proposed Standard
Errata
Part 1 of 6 – Pages 1 to 18
None   None   Next

Top   ToC   RFC6728 - Page 1
Internet Engineering Task Force (IETF)                          G. Muenz
Request for Comments: 6728                                   TU Muenchen
Category: Standards Track                                      B. Claise
ISSN: 2070-1721                                                P. Aitken
                                                     Cisco Systems, Inc.
                                                            October 2012


  Configuration Data Model for the IP Flow Information Export (IPFIX)
                 and Packet Sampling (PSAMP) Protocols

Abstract

This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF). The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6728. Copyright Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
Top   ToC   RFC6728 - Page 2
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . 4 1.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Structure of the Configuration Data Model . . . . . . . . . . 7 3.1. Metering Process Decomposition in Selection Process and Cache . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. UML Representation . . . . . . . . . . . . . . . . . . . 10 3.3. Exporter Configuration . . . . . . . . . . . . . . . . . 15 3.4. Collector Configuration . . . . . . . . . . . . . . . . . 17 4. Configuration Parameters . . . . . . . . . . . . . . . . . . 18 4.1. ObservationPoint Class . . . . . . . . . . . . . . . . . 18 4.2. SelectionProcess Class . . . . . . . . . . . . . . . . . 20 4.2.1. Selector Class . . . . . . . . . . . . . . . . . . . 21 4.2.2. Sampler Classes . . . . . . . . . . . . . . . . . . . 22 4.2.3. Filter Classes . . . . . . . . . . . . . . . . . . . 23 4.3. Cache Class . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1. ImmediateCache Class . . . . . . . . . . . . . . . . 26 4.3.2. TimeoutCache, NaturalCache, and PermanentCache Class . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.3. CacheLayout Class . . . . . . . . . . . . . . . . . . 29 4.4. ExportingProcess Class . . . . . . . . . . . . . . . . . 32 4.4.1. SctpExporter Class . . . . . . . . . . . . . . . . . 34 4.4.2. UdpExporter Class . . . . . . . . . . . . . . . . . . 36 4.4.3. TcpExporter Class . . . . . . . . . . . . . . . . . . 37 4.4.4. FileWriter Class . . . . . . . . . . . . . . . . . . 38 4.4.5. Options Class . . . . . . . . . . . . . . . . . . . . 39 4.5. CollectingProcess Class . . . . . . . . . . . . . . . . . 41 4.5.1. SctpCollector Class . . . . . . . . . . . . . . . . . 42 4.5.2. UdpCollector Class . . . . . . . . . . . . . . . . . 43
Top   ToC   RFC6728 - Page 3
       4.5.3.  TcpCollector Class  . . . . . . . . . . . . . . . . .  44
       4.5.4.  FileReader Class  . . . . . . . . . . . . . . . . . .  45
     4.6.  Transport Layer Security Class  . . . . . . . . . . . . .  46
     4.7.  Transport Session Class . . . . . . . . . . . . . . . . .  49
     4.8.  Template Class  . . . . . . . . . . . . . . . . . . . . .  53
   5.  Adaptation to Device Capabilities . . . . . . . . . . . . . .  54
   6.  YANG Module of the IPFIX/PSAMP Configuration Data Model . . .  57
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . 104
     7.1.  PSAMP Device  . . . . . . . . . . . . . . . . . . . . . . 104
     7.2.  IPFIX Device  . . . . . . . . . . . . . . . . . . . . . . 115
     7.3.  Export of Flow Records and Packet Reports . . . . . . . . 118
     7.4.  Collector and File Writer . . . . . . . . . . . . . . . . 121
     7.5.  Deviations  . . . . . . . . . . . . . . . . . . . . . . . 122
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . 122
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 125
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 125
     11.1. Normative References  . . . . . . . . . . . . . . . . . . 125
     11.2. Informative References  . . . . . . . . . . . . . . . . . 126

1. Introduction

IPFIX- and PSAMP-compliant Monitoring Devices (routers, switches, monitoring probes, Collectors, etc.) offer various configuration possibilities that allow adapting network monitoring to the goals and purposes of the application, such as accounting and charging, traffic analysis, performance monitoring, and security monitoring. The use of a common vendor-independent configuration data model for IPFIX- and PSAMP-compliant Monitoring Devices facilitates network management and configuration, especially if Monitoring Devices of different implementers or manufacturers are deployed simultaneously. On the one hand, a vendor-independent configuration data model helps to store and manage the configuration data of Monitoring Devices in a consistent format. On the other hand, it can be used for local and remote configuration of Monitoring Devices. The purpose of this document is the specification of a vendor- independent configuration data model that covers the commonly available configuration parameters of Selection Processes, Caches, Exporting Processes, and Collecting Processes. In addition, it includes common states parameters of a Monitoring Device. The configuration data model is defined using UML (Unified Modeling Language) class diagrams [UML], while the actual configuration data is encoded in Extensible Markup Language (XML) [W3C.REC-xml-20081126]. An XML document conforming to the configuration data model contains the configuration data of one Monitoring Device.
Top   ToC   RFC6728 - Page 4
   The configuration data model is designed for use with the NETCONF
   protocol [RFC6241] in order to configure remote Monitoring Devices.
   With the NETCONF protocol, it is possible to transfer a complete set
   of configuration data to a Monitoring Device, to query the current
   configuration and state parameters of a Monitoring Device, and to
   change specific parameter values of an existing Monitoring Device
   configuration.

   In order to ensure compatibility with the NETCONF protocol [RFC6241],
   YANG [RFC6020] is used to formally specify the configuration data
   model.  If required, the YANG specification of the configuration data
   model can be converted into XML Schema language
   [W3C.REC-xmlschema-0-20041028] or DSDL (Document Schema Definition
   Languages) [RFC6110], for example, by using the pyang tool
   [YANG-WEB].  YANG provides mechanisms to adapt the configuration data
   model to device-specific constraints and to augment the model with
   additional device-specific or vendor-specific parameters.

   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 [RFC2119].

1.1. IPFIX Documents Overview

The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how IPFIX Data Records and Templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Process. IPFIX has a formal description of IPFIX Information Elements, their name, type, and additional semantic information, as specified in [RFC5102]. [RFC6615] specifies the IPFIX Management Information Base, consisting of the IPFIX MIB module and the IPFIX SELECTOR MIB module. Finally, [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. Methods for efficient export of bidirectional Flow information and common properties in Data Records are specified in [RFC5103] and [RFC5473], respectively. [RFC5610] addresses the export of extended type information for enterprise-specific Information Elements. The storage of IPFIX Messages in a file is specified in [RFC5655].
Top   ToC   RFC6728 - Page 5

1.2. PSAMP Documents Overview

The framework for packet selection and reporting [RFC5474] enables 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 set of packet selection techniques (Sampling, Filtering, and hashing) standardized by PSAMP is described in [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collector. Instead of exporting PSAMP Packet Reports, the stream of selected packets may also serve as input to the generation of IPFIX Flow Records. Like IPFIX, PSAMP has a formal description of its Information Elements, their name, type, and additional semantic information. The PSAMP information model is defined in [RFC5477]. [RFC6727] specifies the PSAMP MIB module as an extension of the IPFIX SELECTOR MIB module defined in [RFC6615].

2. Terminology

This document adopts the terminologies used in [RFC5101], [RFC5103], [RFC5655], and [RFC5476]. As in these documents, all specific terms have the first letter of a word capitalized when used in this document. The following listing indicates in which references the definitions of those terms that are commonly used throughout this document can be found: o Definitions adopted from [RFC5101]: * Collection Process * Collector * Data Record * Exporter * Flow * Flow Key * Flow Record * Information Element * IPFIX Device * IPFIX Message * Observation Domain * Observation Point * (Options) Template o Definitions adopted from [RFC5103]: * Reverse Information Element o Definitions adopted from [RFC5655]: * File Reader * File Writer
Top   ToC   RFC6728 - Page 6
   o  Definitions adopted from [RFC5476]:
      *  Filtering
      *  Observed Packet Stream
      *  Packet Report
      *  PSAMP Device
      *  Sampling
      *  Selection Process
      *  Selection Sequence
      *  Selection Sequence Report Interpretation
      *  Selection Sequence Statistics Report Interpretation
      *  Selection State
      *  Selector, Primitive Selector, Composite Selector
      *  Selector Report Interpretation

   The terms Metering Process and Exporting Process have different
   definitions in [RFC5101] and [RFC5476].  In the scope of this
   document, these terms are used according to the following
   definitions, which cover the deployment in both PSAMP Devices and
   IPFIX Devices:

   Metering Process

      The Metering Process generates IPFIX Flow Records or PSAMP Packet
      Reports, depending on its deployment as part of an IPFIX Device or
      PSAMP Device.  Inputs to the process are packets observed at one
      or more Observation Points, as well as characteristics describing
      the packet treatment at these Observation Points.  If IPFIX Flow
      Records are generated, the Metering Process MUST NOT aggregate
      packets observed at different Observation Domains in the same
      Flow.  The function of the Metering Process is split into two
      functional blocks: Selection Process and Cache.

   Exporting Process

      Depending on its deployment as part of an IPFIX Device or PSAMP
      Device, the Exporting Process sends IPFIX Flow Records or PSAMP
      Packet Reports to one or more Collecting Processes.  The IPFIX
      Flow Records or PSAMP Packet Reports are generated by one or more
      Metering Processes.

   In addition to the existing IPFIX and PSAMP terminology, the
   following terms are defined:

   Cache

      The Cache is a functional block in a Metering Process that
      generates IPFIX Flow Records or PSAMP Packet Reports from a
      Selected Packet Stream, in accordance with its configuration.  If
Top   ToC   RFC6728 - Page 7
      Flow Records are generated, the Cache performs tasks like creating
      new records, updating existing ones, computing Flow statistics,
      deriving further Flow properties, detecting Flow expiration,
      passing Flow Records to the Exporting Process, and deleting Flow
      Records.  If Packet Reports are generated, the Cache performs
      tasks like extracting packet contents and derived packet
      properties from the Selected Packet Stream, creating new records,
      and passing them as Packet Reports to the Exporting Process.

   Cache Layout

      The Cache Layout defines the superset of fields that are included
      in the Packet Reports or Flow Records maintained by the Cache.
      The fields are specified by the corresponding Information
      Elements.  In general, the largest possible subset of the
      specified fields is derived for every Packet Report or Flow
      Record.  More specific rules about which fields must be included
      are given in Section 4.3.3.

   Monitoring Device

      A Monitoring Device implements at least one of the functional
      blocks specified in the context of IPFIX or PSAMP.  In particular,
      the term Monitoring Device encompasses Exporters, Collectors,
      IPFIX Devices, and PSAMP Devices.

   Selected Packet Stream

      The Selected Packet Stream is the set of all packets selected by a
      Selection Process.

3. Structure of the Configuration Data Model

The IPFIX reference model in [RFC5470] describes Metering Processes, Exporting Processes, and Collecting Processes as functional blocks of IPFIX Devices. The PSAMP framework [RFC5474] provides the corresponding information for PSAMP Devices and introduces the Selection Process as a functional block within Metering Processes. In Section 2 of the document, the Cache is defined as another functional block within Metering Processes. Further explanations about the relationship between Selection Process and Cache are given in Section 3.1. IPFIX File Reader and File Writer are defined as specific kinds of Exporting and Collecting Processes in [RFC5655]. Monitoring Device implementations usually maintain the separation of various functional blocks, although they do not necessarily implement all of them. Furthermore, they provide various configuration possibilities; some of them are specified as mandatory by the IPFIX
Top   ToC   RFC6728 - Page 8
   protocol [RFC5101] or PSAMP protocol [RFC5476].  The configuration
   data model enables the setting of commonly available configuration
   parameters for Selection Processes, Caches, Exporting Processes, and
   Collecting Processes.  In addition, it allows specifying the
   composition of functional blocks within a Monitoring Device
   configuration and their linkage with Observation Points.

   The selection of parameters in the configuration data model is based
   on configuration issues discussed in the IPFIX and PSAMP documents
   [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475].
   Furthermore, the structure and content of the IPFIX MIB module
   [RFC6615] and the PSAMP MIB module [RFC6727] have been taken into
   consideration.  Consistency between the configuration data model and
   the IPFIX and PSAMP MIB modules is an intended goal.  Therefore,
   parameters in the configuration data model are named according to
   corresponding managed objects.  Certain IPFIX MIB objects containing
   state data have been adopted as state parameters in the configuration
   data model.  State parameters cannot be configured, yet their values
   can be queried from the Monitoring Device by a network manager.

   Section 3.2 explains how UML class diagrams are deployed to
   illustrate the structure of the configuration data model.
   Thereafter, Section 3.3 and Section 3.4 explain the class diagrams
   for the configuration of Exporters and Collectors, respectively.
   Each of the presented classes contains specific configuration
   parameters that are specified in Section 4.  Section 5 gives a short
   introduction to YANG concepts that allow adapting the configuration
   data model to the capabilities of a device.  The formal definition of
   the configuration data model in YANG is given in Section 6.
   Section 7 illustrates the usage of the model with example
   configurations in XML.

3.1. Metering Process Decomposition in Selection Process and Cache

In a Monitoring Device implementation, the functionality of the Metering Process is commonly split into packet Sampling and Filtering functions performed by Selection Processes, and the maintenance of Flow Records and Packet Reports is performed by a Cache. Figure 1 illustrates this separation with the example of a basic Metering Process.
Top   ToC   RFC6728 - Page 9
               +-----------------------------------+
               | Metering Process                  |
               | +-----------+ Selected            |
      Observed | | Selection | Packet    +-------+ |  Stream of
      Packet  -->| Process   |---------->| Cache |--> Flow Records or
      Stream   | +-----------+ Stream    +-------+ |  Packet Reports
               +-----------------------------------+

     Figure 1: Selection Process and Cache forming a Metering Process

   The configuration data model adopts the separation of Selection
   Processes and Caches in order to support the flexible configuration
   and combination of these functional blocks.  As defined in [RFC5476],
   the Selection Process takes an Observed Packet Stream as its input
   and selects a subset of that stream as its output (Selected Packet
   Stream).  The action of the Selection Process on a single packet of
   its input is defined by one Selector (called a Primitive Selector) or
   an ordered composition of multiple Selectors (called a Composite
   Selector).  The Cache generates Flow Records or Packet Reports from
   the Selected Packet Stream, depending on its configuration.

   The configuration data model does not allow configuring a Metering
   Process without any Selection Process in front of the Cache.  If all
   packets in the Observed Packet Stream shall be selected and passed to
   the Cache without any Filtering or Sampling, a Selection Process
   needs to be configured with a Selector that selects all packets
   ("SelectAll" class in Section 4.2.1).

   The configuration data model enables the configuration of a Selection
   Process that receives packets from multiple Observation Points as its
   input.  In this case, the Observed Packet Streams of the Observation
   Points are processed in independent Selection Sequences.  As
   specified in [RFC5476], a distinct set of Selector instances needs to
   be maintained per Selection Sequence in order to keep the Selection
   States and statistics separate.

   With the configuration data model, it is possible to configure a
   Metering Process with more than one Selection Processes whose output
   is processed by a single Cache.  This is illustrated in Figure 2.
Top   ToC   RFC6728 - Page 10
              +-------------------------------------+
              | Metering Process                    |
              | +-----------+ Selected              |
     Observed | | Selection | Packet                |
     Packet  -->| Process   |----------+  +-------+ |
     Stream   | +-----------+ Stream   +->|       | |  Stream of
              |      ...                  | Cache |--> Flow Records or
              | +-----------+ Selected +->|       | |  Packet Reports
     Observed | | Selection | Packet   |  +-------+ |
     Packet  -->| Process   |----------+            |
     Stream   | +-----------+ Stream                |
              +-------------------------------------+

       Figure 2: Metering Process with multiple Selection Processes

   The Observed Packet Streams at the input of a Metering Process may
   originate from Observation Points belonging to different Observation
   Domains.  By definition of the Observation Domain (see [RFC5101]),
   however, a Cache MUST NOT aggregate packets observed at different
   Observation Domains in the same Flow.  Hence, if the Cache is
   configured to generate Flow Records, it needs to distinguish packets
   according to their Observation Domains.

3.2. UML Representation

We use UML class diagrams [UML] to explain the structure of the configuration data model. The attributes of the classes are the configuration or state parameters. The configuration and state parameters of a given Monitoring Device are represented as objects of these classes encoded in XML. +------------------------------+ | SctpExporter | +------------------------------+ 0..1 +------------------------+ | name |<>-------| TransportLayerSecurity | | ipfixVersion = 10 | +------------------------+ | sourceIPAddress[0..*] | | destinationIPAddress[1..*] | 0..1 +------------------------+ | destinationPort = 4739|4740 |<>-------| TransportSession | | ifName/ifIndex[0..1] | +------------------------+ | sendBufferSize {opt.} | | rateLimit[0..1] | | timedReliability = 0 | +------------------------------+ Figure 3: UML example: SctpExporter class
Top   ToC   RFC6728 - Page 11
   As an example, Figure 3 shows the UML diagram of the SctpExporter
   class, which is specified in more detail in Section 4.4.1.  The upper
   box contains the name of the class.  The lower box lists the
   attributes of the class.  Each attribute corresponds to a parameter
   of the configuration data model.

   Behind an attribute's name, there may appear a multiplicity indicator
   in brackets (i.e., between "[" and "]").  An attribute with
   multiplicity indicator "[0..1]" represents an OPTIONAL configuration
   parameter that is only included in the configuration data if the user
   configures it.  Typically, the absence of an OPTIONAL parameter has a
   specific meaning.  For example, not configuring rateLimit in an
   object of the SctpExporter class means that no rate limiting will be
   applied to the exported data.  In YANG, an OPTIONAL parameter is
   specified as a "leaf" without "mandatory true" substatement.  The
   "description" substatement specifies the behavior for the case that
   the parameter is not configured.

   The multiplicity indicator "[0..*]" means that this parameter is
   OPTIONAL and MAY be configured multiple times with different values.
   In the example, multiple source IP addresses (sourceIPAddress) may be
   configured for a multihomed Exporting Process.  In YANG, an attribute
   with multiplicity indicator "[0..*]" corresponds to a "leaf-list".

   The multiplicity indicator "[1..*]" means that this parameter MUST be
   configured at least once and MAY be configured multiple times with
   different values.  In the example, one or more destination IP
   addresses (destinationIPAddress) must be configured to specify the
   export destination.  In YANG, an attribute with multiplicity
   indicator "[1..*]" corresponds to a "leaf-list" with "min-elements 1"
   substatement.  Note that attributes without this multiplicity
   indicator MUST NOT appear more than once in each object of the class.

   Attributes without multiplicity indicator may be endued with a
   default value that is indicated behind the equality symbol ("=").  If
   a default value exists, the parameter does not have to be explicitly
   configured by the user.  If the parameter is not configured by the
   user, the Monitoring Device MUST use the specified default value for
   the given parameter.  In the example, IPFIX version 10 must be used
   unless a different value is configured for ipfixVersion.  In YANG, an
   attribute with default value corresponds to a "leaf" with "default"
   substatement.

   In the example, there exist two default values for the destination
   port (destinationPort) -- namely, the registered ports for IPFIX with
   and without transport layer security (i.e., DTLS or TLS), which are
   4740 and 4739, respectively.  In the UML diagram, the two default
   values are separated by a vertical bar ("|").  In YANG, such
Top   ToC   RFC6728 - Page 12
   conditional default value alternatives cannot be specified formally.
   Instead, they are defined in the "description" substatement of the
   "leaf".

   Further attribute properties are denoted in braces (i.e., between "{"
   and "}").  An attribute with property "{opt.}", such as
   sendBufferSize in the SctpExporter class, represents a parameter that
   MAY be configured by the user.  If not configured by the user, the
   Monitoring Device MUST set an appropriate value for this parameter at
   configuration time.  As a result, the parameter will always exist in
   the configuration data, yet it is not mandatory for the user to
   configure it.  This behavior can be implemented as a static device-
   specific default value, but does not have to be.  Therefore, the user
   MUST NOT expect that the device always sets the same values for the
   same parameter.  Regardless of whether the parameter value has been
   configured by the user or set by the device, the parameter value MUST
   NOT be changed by the device after configuration.  Since this
   behavior cannot be specified formally in YANG, it is specified in the
   "description" substatement of the "leaf".

   The availability of a parameter may depend on another parameter
   value.  In the UML diagram, such restrictions are indicated as
   attribute properties (e.g., "{SCTP only}").  The given example does
   not show such restrictions.  In YANG, the availability of a parameter
   is formally restricted with the "when" substatement of the "leaf".

   Another attribute property not shown in the example is "{readOnly}",
   which specifies state parameters that cannot be configured.  In YANG,
   this corresponds to the "config false" substatement.

   Attributes without multiplicity indicator, without default value, and
   without "{readOnly}" property are mandatory configuration parameters.
   These parameters MUST be configured by the user unless an attribute
   property determines that the parameter is not available.  In YANG, a
   mandatory parameter corresponds to a "leaf" with "mandatory true"
   substatement.  In the example, the user MUST configure the name
   parameter.

   If some parameters are related to each other, it makes sense to group
   these parameters in a subclass.  This is especially useful if
   different subclasses represent choices of different parameter sets,
   or if the parameters of a subclass may appear multiple times.  For
   example, the SctpExporter class MAY contain the parameters of the
   TransportLayerSecurity subclass.

   An object of a class is encoded as an XML element.  In order to
   distinguish between classes and objects, class names start with an
   uppercase character while the associated XML elements start with
Top   ToC   RFC6728 - Page 13
   lowercase characters.  Parameters appear as XML elements that are
   nested in the XML element of the object.  In XML, the parameters of
   an object can appear in any order and do not have to follow the order
   in the UML class diagram.  Unless specified differently, the order in
   which parameters appear does not have a meaning.  As an example, an
   object of the SctpExporter class corresponds to one occurrence of

     <sctpExporter>
       <name>my-sctp-export</name>
       ...
     </sctpExporter>

   There are various possibilities how objects of classes can be related
   to each other.  In the scope of this document, we use two different
   types of relationship between objects: aggregation and unidirectional
   association.  In UML class diagrams, two different arrow types are
   used as shown in Figure 4.

            +---+   0..* +---+         +---+ 0..*  1 +---+
            | A |<>------| B |         | A |-------->| B |
            +---+        +---+         +---+         +---+
             (a) Aggregation     (b) Unidirectional association

            Figure 4: Class relationships in UML class diagrams

   Aggregation means that one object is part of the other object.  In
   Figure 4 (a), an object of class B is part of an object of class A.
   This corresponds to nested XML elements:

     <a>
       <b>
         ...
       </b>
       ...
     </a>

   In the example, objects of the TransportLayerSecurity class and the
   TransportSession class appear as nested XML elements
   <transportLayerSecurity> and <transportSession> within an object of
   the SctpExporter class <sctpExporter>.

   A unidirectional association is a reference to an object.  In
   Figure 4(b), an object of class A contains a reference to an object
   of class B.  This corresponds to separate XML elements that are not
   nested.  To distinguish different objects of class B, class B must
   have a key.  In the configuration data model, keys are string
   parameters called "name", corresponding to XML elements <name>.  The
   names MUST be unique within the given XML subtree.  The reference to
Top   ToC   RFC6728 - Page 14
   a specific object of class B is encoded with an XML element <b>,
   which contains the name of an object.  If an object of class A refers
   to the object of class B with name "foo", this looks as follows:

     <a>
       ...
       <b>foo</b>
       ...
     </a>

     <b>
       <name>foo</name>
       ...
     </b>

   In Figure 4, the indicated numbers define the multiplicity:

      "1": one only
      "0..*": zero or more
      "1..*": one or more

   In the case of aggregation, the multiplicity indicates how many
   objects of one class may be included in one object of the other
   class.  In Figure 4(a), an object of class A may contain an arbitrary
   number of objects of class B.  In the case of unidirectional
   association, the multiplicity at the arrowhead specifies the number
   of objects of a given class that may be referred to.  The
   multiplicity at the arrow tail specifies how many different objects
   of one class may refer to a single object of the other class.  In
   Figure 4(b), an object of class A refers to single object of class B.
    One object of class B can be referred to from an arbitrary number of
   objects of class A.

   Similar to classes that are referenced in UML associations, classes
   that contain configuration parameters and that occur in an
   aggregation relationship with multiplicity greater than one must have
   a key.  This key is necessary because every configuration parameter
   must be addressable in order to manipulate or delete it.  The key
   values MUST be unique in the given XML subtree (i.e., unique within
   the aggregating object).  Hence, if class B in Figure 4(a) contains a
   configuration parameter, all objects of class B belonging to the same
   object of class A must have different key values.  Again, the key
   appears as an attribute called "name" in the concerned classes.

   A class that contains state parameters but no configuration
   parameters, such as the Template class (see Section 4.8), does not
   have a key.  This is because state parameters cannot be manipulated
   or deleted, and therefore do not need to be addressable.
Top   ToC   RFC6728 - Page 15
   Note that the usage of keys as described above is required by YANG
   [RFC6020], which mandates the existence of a key for elements that
   appear in a list of configuration data.

   The configuration data model for IPFIX and PSAMP makes use of
   unidirectional associations to specify the data flow between
   different functional blocks.  For example, if the output of a
   Selection Process is processed by a Cache, this corresponds to an
   object of the SelectionProcess class that contains a reference to an
   object of the Cache class.  The configuration data model does not
   mandate that such a reference exists for every functional block that
   has an output.  If such a reference is absent, the output is dropped
   without any further processing.  Although such configurations are
   incomplete, we do not consider them invalid as they may temporarily
   occur if a Monitoring Device is configured in multiple steps.  Also,
   it might be useful to pre-configure certain functions of a Monitoring
   Device in order to be able to switch to a new configuration more
   quickly.

3.3. Exporter Configuration

Figure 5 below shows the main classes of the configuration data model that are involved in the configuration of an IPFIX or PSAMP Exporter. The role of the classes can be briefly summarized as follows: o The ObservationPoint class specifies an Observation Point (i.e., an interface or linecard) of the Monitoring Device at which packets are captured for traffic measurements. An object of the ObservationPoint class may be associated with one or more objects of the SelectionProcess class configuring Selection Processes that process the observed packets in parallel. As long as an ObservationPoint object is specified without any references to SelectionProcess objects, the captured packets are not considered by any Metering Process. o The SelectionProcess class contains the configuration and state parameters of a Selection Process. The Selection Process may be composed of a single Selector or a sequence of Selectors, defining a Primitive or Composite Selector, respectively. The Selection Process selects packets from one or more Observed Packet Streams, each originating from a different Observation Point. Therefore, a SelectionProcess object MAY be referred to from one or more ObservationPoint objects.
Top   ToC   RFC6728 - Page 16
      A Selection Process MAY pass the Selected Packet Stream to a
      Cache.  Therefore, the SelectionProcess class contains a reference
      to an object of the Cache class.  If a Selection Process is
      configured without any reference to a Cache, the selected packets
      are not accounted in any Packet Report or Flow Record.

   o  The Cache class contains configuration and state parameters of a
      Cache.  A Cache may receive the output of one or more Selection
      Processes and maintains corresponding Packet Reports or Flow
      Records.  Therefore, an object of the Cache class MAY be referred
      to from multiple SelectionProcess objects.

      Configuration parameters of the Cache class specify the size of
      the Cache, the Cache Layout, and expiration parameters if
      applicable.  The Cache configuration also determines whether
      Packet Reports or Flow Records are generated.

      A Cache MAY pass its output to one or more Exporting Processes.
      Therefore, the Cache class enables references to one or more
      objects of the ExportingProcess class.  If a Cache object does not
      specify any reference to an ExportingProcess object, the Cache
      output is dropped.

   o  The ExportingProcess class contains configuration and state
      parameters of an Exporting Process.  It includes various
      transport-protocol-specific parameters and the export
      destinations.  An object of the ExportingProcess class MAY be
      referred to from multiple objects of the Cache class.

      An Exporting Process MAY be configured as a File Writer according
      to [RFC5655].
Top   ToC   RFC6728 - Page 17
                            +------------------+
                            | ObservationPoint |
                            +------------------+
                                 0..* |
                                      |
                                 0..* V
                            +------------------+
                            | SelectionProcess |
                            +------------------+
                                 0..* |
                                      |
                                 0..1 V
                            +------------------+
                            | Cache            |
                            +------------------+
                                 0..* |
                                      |
                                 0..* V
                            +------------------+
                            | ExportingProcess |
                            +------------------+

             Figure 5: Class diagram of Exporter configuration

3.4. Collector Configuration

Figure 6 below shows the main classes of the configuration data model that are involved in the configuration of a Collector. An object of the CollectingProcess class specifies the local IP addresses, transport protocols, and port numbers of a Collecting Process. Alternatively, the Collecting Process MAY be configured as a File Reader according to [RFC5655]. An object of the CollectingProcess class may refer to one or more ExportingProcess objects configuring Exporting Processes that reexport the received data. As an example, an Exporting Process can be configured as a File Writer in order to save the received IPFIX Messages in a file.
Top   ToC   RFC6728 - Page 18
                           +-------------------+
                           | CollectingProcess |
                           +-------------------+
                                0..* |
                                     |
                                0..* V
                           +-------------------+
                           | ExportingProcess  |
                           +-------------------+

            Figure 6: Class diagram of Collector configuration



(page 18 continued on part 2)

Next Section