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
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
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.
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].
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
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
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
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.
+-----------------------------------+ | 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.
+-------------------------------------+ | 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
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
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
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
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.
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.
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].
+------------------+ | 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.
+-------------------+ | CollectingProcess | +-------------------+ 0..* | | 0..* V +-------------------+ | ExportingProcess | +-------------------+ Figure 6: Class diagram of Collector configuration
(page 18 continued on part 2)
