tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6728

 Errata 
Proposed STD
Pages: 129
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IPFIX

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

Part 1 of 6, p. 1 to 18
None       Next RFC Part

 


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

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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       Page 18 
                           +-------------------+
                           | CollectingProcess |
                           +-------------------+
                                0..* |
                                     |
                                0..* V
                           +-------------------+
                           | ExportingProcess  |
                           +-------------------+

            Figure 6: Class diagram of Collector configuration



(page 18 continued on part 2)

Next RFC Part