RFC 6728
Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols
4.5. CollectingProcess Class
+-------------------+ | CollectingProcess | +-------------------+ | name | 0..* +------------------+ | |<>----------| SctpCollector | | | +------------------+ | | | | 0..* +------------------+ | |<>----------| UdpCollector | | | +------------------+ | | | | 0..* +------------------+ | |<>----------| TcpCollector | | | +------------------+ | | | | 0..* +------------------+ | |<>----------| FileReader | | | +------------------+ | | | | 0..* 0..* +------------------+ | |----------->| ExportingProcess | +-------------------+ +------------------+ Figure 22: CollectingProcess class Figure 22 shows the CollectingProcess class that contains the configuration and state parameters of a Collecting Process. Objects of the SctpCollector, UdpCollector, and TcpCollector classes specify how IPFIX Messages are received from remote Exporters. The Collecting Process can also be configured as a File Reader using objects of the FileReader class. These classes are described in Sections 4.5.1, 4.5.2, 4.5.3, and 4.5.4. A CollectingProcess object MAY refer to one or more ExportingProcess objects configuring Exporting Processes that export the received data without modifications to a file or to another Collector.
4.5.1. SctpCollector Class
+--------------------------+ | SctpCollector | +--------------------------+ 0..1 +------------------------+ | name |<>-------| TransportLayerSecurity | | localIPAddress[0..*] | +------------------------+ | localPort = 4739|4740 | | | 0..* +------------------------+ | |<>-------| TransportSession | +--------------------------+ +------------------------+ Figure 23: SctpCollector class The SctpCollector class contains the configuration parameters of a listening SCTP socket at a Collecting Process. The parameters are: localIPAddress: List of local IP addresses on which the Collecting Process listens for IPFIX Messages. The IP addresses are used as eligible local IP addresses of the multihomed SCTP endpoint [RFC4960]. If omitted, the Collecting Process listens on all local IP addresses. localPort: Local port number on which the Collecting Process listens for IPFIX Messages. If omitted, standard port 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) is used. Using the TransportLayerSecurity class described in Section 4.6, DTLS is enabled and configured for this receiving socket. As state data, the SctpCollector class contains the list of currently established Transport Sessions that terminate at the given SCTP socket of the Collecting Process. The TransportSession class is specified in Section 4.7.
4.5.2. UdpCollector Class
+---------------------------------+ | UdpCollector | +---------------------------------+ 0..1 +------------------------+ | name |<>------| TransportLayerSecurity | | localIPAddress[0..*] | +------------------------+ | localPort = 4739|4740 | | templateLifeTime = 1800 | 0..* +------------------------+ | optionsTemplateLifeTime = 1800 |<>------| TransportSession | | templateLifePacket[0..*] | +------------------------+ | optionsTemplateLifePacket[0..*] | +---------------------------------+ Figure 24: UdpCollector class The UdpCollector class contains the configuration parameters of a listening UDP socket at a Collecting Process. The parameter localPort has the same meaning as in the SctpCollector class (see Section 4.5.1). The remaining parameters are: localIPAddress: List of local IP addresses on which the Collecting Process listens for IPFIX Messages. If omitted, the Collecting Process listens on all local IP addresses. templateLifeTime, optionsTemplateLifeTime: (Options) Template lifetime in seconds for all UDP Transport Sessions terminating at this UDP socket. (Options) Templates that are not received again within the configured lifetime become invalid at the Collecting Process. As specified in [RFC5101], Section 10.3.7, the lifetime of Templates and Options Templates MUST be at least three times higher than the templateRefreshTimeout and optionTemplatesRefreshTimeout parameter values configured on the corresponding Exporting Processes. If not configured, the default value 1800 is used, which is three times the default (Options) Template refresh timeout (see Section 4.4.2) as specified in [RFC5101]. Note that these parameters correspond to ipfixTransportSessionTemplateRefreshTimeout and ipfixTransportSessionOptionsTemplateRefreshTimeout in the IPFIX MIB module [RFC6615]. templateLifePacket, optionsTemplateLifePacket: If templateLifePacket is configured, Templates defined in a UDP Transport Session become invalid if they are neither included in a sequence of more than this number of IPFIX Messages nor received again within the period of time specified by templateLifeTime. Similarly, if
optionsTemplateLifePacket is configured, Options Templates become
invalid if they are neither included in a sequence of more than
this number of IPFIX Messages nor received again within the period
of time specified by optionsTemplateLifeTime.
If not configured, Templates and Options Templates only become
invalid according to the lifetimes specified by templateLifeTime
and optionsTemplateLifeTime, respectively.
Note that these parameters correspond to
ipfixTransportSessionTemplateRefreshPacket and
ipfixTransportSessionOptionsTemplateRefreshPacket in the IPFIX MIB
module [RFC6615].
Using the TransportLayerSecurity class described in Section 4.6, DTLS
is enabled and configured for this receiving socket.
As state data, the UdpCollector class contains the list of currently
established Transport Sessions that terminate at the given UDP socket
of the Collecting Process. The TransportSession class is specified
in Section 4.7.
4.5.3. TcpCollector Class
+--------------------------+
| TcpCollector |
+--------------------------+ 0..1 +------------------------+
| name |<>-------| TransportLayerSecurity |
| localIPAddress[0..*] | +------------------------+
| localPort = 4739|4740 |
| | 0..* +------------------------+
| |<>-------| TransportSession |
+--------------------------+ +------------------------+
Figure 25: TcpCollector class
The TcpCollector class contains the configuration parameters of a
listening TCP socket at a Collecting Process. The parameters have
the same meaning as in the UdpCollector class (see Section 4.5.2).
Using the TransportLayerSecurity class described in Section 4.6, TLS
is enabled and configured for this receiving socket.
As state data, the TcpCollector class contains the list of currently
established Transport Sessions that terminate at the given TCP socket
of the Collecting Process. The TransportSession class is specified
in Section 4.7.
4.5.4. FileReader Class
+-----------------------------------------+ | FileReader | +-----------------------------------------+ 0..* +----------+ | name |<>-------| Template | | file | +----------+ | bytes {readOnly} | | messages {readOnly} | | records {readOnly} | | templates {readOnly} | | optionsTemplates {readOnly} | | fileReaderDiscontinuityTime {readOnly} | +-----------------------------------------+ Figure 26: FileReader classes The Collecting Process may import IPFIX Messages from a file as specified in [RFC5655]. The FileReader class defines the following configuration parameter: file: File name and location specified as URI. The state parameters of the FileReader class are: bytes, messages, records, templates, optionsTemplates: The number of bytes, IPFIX Messages, Data Records, Template Records, and Options Template Records read by the File Reader. Discontinuities in the values of these counters can occur at re-initialization of the management system, and at other times as indicated by the value of fileReaderDiscontinuityTime. fileReaderDiscontinuityTime: Timestamp of the most recent occasion at which one or more File Reader counters suffered a discontinuity. In contrast to discontinuity times in the IPFIX MIB module, the time is absolute and not relative to sysUpTime. Each object of the FileReader class includes a list of objects of the Template class with information and statistics about the Templates read from the file. The Template class is specified in Section 4.8.
4.6. Transport Layer Security Class
+--------------------------------------+ | TransportLayerSecurity | +--------------------------------------+ | localCertificationAuthorityDN[0..*] | | localSubjectDN[0..*] | | localSubjectFQDN[0..*] | | remoteCertificationAuthorityDN[0..*] | | remoteSubjectDN[0..*] | | remoteSubjectFQDN[0..*] | +--------------------------------------+ Figure 27: TransportLayerSecurity class The TransportLayerSecurity class is used in the Exporting Process's SctpExporter, UdpExporter, and TcpExporter classes, and the Collecting Process's SctpCollector, UdpCollector, and TcpCollector classes to enable and configure TLS/DTLS for IPFIX. TLS/DTLS can be enabled without configuring any additional parameters. In this case, an empty XML element <transportLayerSecurity /> appears in the configuration. If TLS/DTLS is enabled, the endpoint must use DTLS [RFC6347] if the transport protocol is SCTP or UDP, and TLS [RFC5246] if the transport protocol is TCP. [RFC5101] mandates strong mutual authentication of Exporting Processes and Collecting Process as follows. Note this text cites [RFC3280], which was obsoleted by [RFC5280]. IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name (FQDN) of the interface on which IPFIX Messages are sent or received, for purposes of X.509 client and server certificates as in [RFC3280]. To prevent man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, strong mutual authentication via asymmetric keys MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name, or, in the case of SCTP, the fully qualified domain name of one of its endpoints. The fully qualified domain name used to identify an IPFIX Collecting Process or Exporting Process may be stored either in a subjectAltName extension of type dNSName, or in the most specific Common Name field of the Subject field of the X.509 certificate.
If both are present, the subjectAltName extension is given
preference.
In order to use TLS/DTLS, appropriate certificates and keys have to
be previously installed on the Monitoring Devices. For security
reasons, the configuration data model does not offer the possibility
to upload any certificates or keys on a Monitoring Device. If TLS/
DTLS is enabled on a Monitoring Device that does not dispose of
appropriate certificates and keys, the configuration MUST be rejected
with an error.
The configuration data model allows restricting the authorization of
remote endpoints to certificates issued by specific certification
authorities or identifying specific FQDNs for authorization.
Furthermore, the configuration data model allows restricting the
utilization of certificates identifying the local endpoint. This is
useful if the Monitoring Device disposes of more than one certificate
for the given local endpoint.
The configuration parameters are defined as follows:
localCertificationAuthorityDN: This parameter MAY appear one or more
times to restrict the identification of the local endpoint during
the TLS/DTLS handshake to certificates issued by the configured
certification authorities. Each occurrence of this parameter
contains the distinguished name of one certification authority.
To identify the local endpoint, the Exporting Process or
Collecting Process MUST use a certificate issued by one of the
configured certification authorities. Certificates issued by any
other certification authority MUST NOT be sent to the remote peer
during TLS/DTLS handshake. If none of the certificates installed
on the Monitoring Device fulfills the specified restrictions, the
configuration MUST be rejected with an error.
If localCertificationAuthorityDN is not configured, the choice of
certificates identifying the local endpoint is not restricted with
respect to the issuing certification authority.
localSubjectDN, localSubjectFQDN: Each of these parameters MAY
appear one or more times to restrict the identification of the
local endpoint during the TLS/DTLS handshake to certificates
issued for specific subjects or for specific FQDNs. Each
occurrence of localSubjectDN contains a distinguished name
identifying the local endpoint. Each occurrence of
localSubjectFQDN contains a FQDN which is assigned to the local
endpoint.
To identify the local endpoint, the Exporting Process or
Collecting Process MUST use a certificate that contains either one
of the configured distinguished names in the subject field or at
least one of the configured FQDNs in a dNSName component of the
subject alternative extension field or in the most specific
commonName component of the subject field. If none of the
certificates installed on the Monitoring Device fulfills the
specified restrictions, the configuration MUST be rejected with an
error.
If any of the parameters localSubjectDN and localSubjectFQDN is
configured at the same time as the localCertificationAuthorityDN
parameter, certificates MUST also fulfill the specified
restrictions regarding the certification authority.
If localSubjectDN and localSubjectFQDN are not configured, the
choice of certificates identifying the local endpoint is not
restricted with respect to the subject's distinguished name or
FQDN.
remoteCertificationAuthorityDN: This parameter MAY appear one or
more times to restrict the authentication of remote endpoints
during the TLS/DTLS handshake to certificates issued by the
configured certification authorities. Each occurrence of this
parameter contains the distinguished name of one certification
authority.
To authenticate the remote endpoint, the remote Exporting Process
or Collecting Process MUST provide a certificate issued by one of
the configured certification authorities. Certificates issued by
any other certification authority MUST be rejected during TLS/DTLS
handshake.
If the Monitoring Device is not able to validate certificates
issued by the configured certification authorities (e.g., because
of missing public keys), the configuration must be rejected with
an error.
If remoteCertificationAuthorityDN is not configured, the
authorization of remote endpoints is not restricted with respect
to the issuing certification authority of the delivered
certificate.
remoteSubjectDN, remoteSubjectFQDN: Each of these parameters MAY
appear one or more times to restrict the authentication of remote
endpoints during the TLS/DTLS handshake to certificates issued for
specific subjects or for specific FQDNs. Each occurrence of
remoteSubjectDN contains a distinguished name identifying a remote
endpoint. Each occurrence of remoteSubjectFQDN contains a FQDN
that is assigned to a remote endpoint.
To authenticate a remote endpoint, the remote Exporting Process or
Collecting Process MUST provide a certificate that contains either
one of the configured distinguished names in the subject field or
at least one of the configured FQDNs in a dNSName component of the
subject alternative extension field or in the most specific
commonName component of the subject field. Certificates not
fulfilling this condition MUST be rejected during TLS/DTLS
handshake.
If any of the parameters remoteSubjectDN and remoteSubjectFQDN is
configured at the same time as the remoteCertificationAuthorityDN
parameter, certificates MUST also fulfill the specified
restrictions regarding the certification authority in order to be
accepted.
If remoteSubjectDN and remoteSubjectFQDN are not configured, the
authorization of remote endpoints is not restricted with respect
to the subject's distinguished name or FQDN of the delivered
certificate.
4.7. Transport Session Class
+----------------------------------------------+
| TransportSession |
+----------------------------------------------+ 0..* +----------+
| ipfixVersion {readOnly} |<>-------| Template |
| sourceAddress {readOnly} | +----------+
| destinationAddress {readOnly} |
| sourcePort {readOnly} |
| destinationPort {readOnly} |
| sctpAssocId {readOnly} {SCTP only} |
| status {readOnly} |
| rate {readOnly} |
| bytes {readOnly} |
| messages {readOnly} |
| discardedMessages {readOnly} |
| records {readOnly} |
| templates {readOnly} |
| optionsTemplates {readOnly} |
| transportSessionStartTime {readOnly} |
| transportSessionDiscontinuityTime {readOnly} |
+----------------------------------------------+
Figure 28: TransportSession class
The TransportSession class contains state data about Transport
Sessions originating from an Exporting Process or terminating at a
Collecting Process. In general, the state parameters correspond to
the managed objects in the ipfixTransportSessionTable and
ipfixTransportSessionStatsTable of the IPFIX MIB module [RFC6615].
An exception is the usage of the parameters sourceAddress and
destinationAddress. If SCTP is the transport protocol, the Exporter
or Collector MAY be multihomed SCTP endpoints (see [RFC4960], Section
6.4) and use more than one IP address. In the IPFIX MIB module,
ipfixTransportSessionSctpAssocId is used instead of
ipfixTransportSessionSourceAddress and
ipfixTransportSessionDestinationAddress to point to an entry in the sctpAssocTable defined in the SCTP MIB module [RFC3871]. Since we cannot assume that an SNMP agent offering access to the SCTP MIB module exists on the Monitoring Device, the configuration data model cannot rely on this parameter. Therefore, the state parameters sourceAddress and destinationAddress are used for SCTP as well, containing one of the potentially many Exporter and Collector IP addresses in the SCTP association. Preferably, the IP addresses of the path that is usually selected by the Exporter to send IPFIX Messages to the Collector SHOULD be contained. Several MIB objects of the ipfixTransportSessionTable are omitted in the TransportSession class. The MIB object ipfixTransportSessionDeviceMode is not included because its value can be derived from the context in which a TransportSession object appears: exporting(1) if it belongs to an Exporting Process, collecting(2) if it belongs to a Collecting Process. Similarly, the MIB object ipfixTransportSessionProtocol is not included as the transport protocol is known from the context as well. The MIB objects ipfixTransportSessionTemplateRefreshTimeout, ipfixTransportSessionOptionsTemplateRefreshTimeout, ipfixTransportSessionTemplateRefreshPacket, and ipfixTransportSessionOptionsTemplateRefreshPacket are not included since they correspond to configuration parameters of the UdpExporter class (templateRefreshTimeout, optionsTemplateRefreshTimeout, templateRefreshPacket, optionsTemplateRefreshPacket) and the UdpCollector class (templateLifeTime, optionsTemplateLifeTime, templateLifePacket, optionsTemplateLifePacket). ipfixVersion: Used for Exporting Processes, this parameter contains the version number of the IPFIX protocol that the Exporter uses to export its data in this Transport Session. Hence, it is identical to the value of the configuration parameter ipfixVersion of the outer SctpExporter, UdpExporter, or TcpExporter object. Used for Collecting Processes, this parameter contains the version number of the IPFIX protocol it receives for this Transport Session. If IPFIX Messages of different IPFIX protocol versions are received, this parameter contains the maximum version number. This state parameter is identical to ipfixTransportSessionIpfixVersion in the IPFIX MIB module [RFC6615].
sourceAddress, destinationAddress: If TCP or UDP is the transport
protocol, sourceAddress contains the IP address of the Exporter,
and destinationAddress contains the IP addresses of the Collector.
Hence, the two parameters have identical values as
ipfixTransportSessionSourceAddress and
ipfixTransportSessionDestinationAddress in the IPFIX MIB module
[RFC6615].
If SCTP is the transport protocol, sourceAddress contains one of
the IP addresses of the Exporter and destinationAddress one of the
IP addresses of the Collector. Preferably, the IP addresses of
the path that is usually selected by the Exporter to send IPFIX
Messages to the Collector SHOULD be contained.
sourcePort, destinationPort: These state parameters contain the
transport-protocol port numbers of the Exporter and the Collector
of the Transport Session and thus are identical to
ipfixTransportSessionSourcePort and
ipfixTransportSessionDestinationPort in the IPFIX MIB module
[RFC6615].
sctpAssocId: The association ID used for the SCTP session between
the Exporter and the Collector of the Transport Session. It is
equal to the sctpAssocId entry in the sctpAssocTable defined in
the SCTP-MIB [RFC3871].
This parameter is only available if the transport protocol is SCTP
and if an SNMP agent on the same Monitoring Device enables access
to the corresponding MIB objects in the sctpAssocTable.
This state parameter is identical to
ipfixTransportSessionSctpAssocId in the IPFIX MIB module
[RFC6615].
status: Status of the Transport Session, which can be one of the
following:
* inactive: Transport Session is established, but no IPFIX
Messages are currently transferred (e.g., because this is a
backup (secondary) session)
* active: Transport Session is established and transfers IPFIX
Messages
* unknown: Transport Session status cannot be determined
This state parameter is identical to ipfixTransportSessionStatus
in the IPFIX MIB module [RFC6615].
rate: The number of bytes per second transmitted by the Exporting
Process or received by the Collecting Process. This parameter is
updated every second.
This state parameter is identical to ipfixTransportSessionRate in
the IPFIX MIB module [RFC6615].
bytes, messages, records, templates, optionsTemplates: The number of
bytes, IPFIX Messages, Data Records, Template Records, and Options
Template Records transmitted by the Exporting Process or received
by the Collecting Process. Discontinuities in the values of these
counters can occur at re-initialization of the management system,
and at other times as indicated by the value of
transportSessionDiscontinuityTime.
discardedMessages: Used for Exporting Processes, this parameter
indicates the number of messages that could not be sent due to
internal buffer overflows, network congestion, routing issues,
etc.
Used for Collecting Process, this parameter indicates the number
of received IPFIX Messages that are malformed, cannot be decoded,
are received in the wrong order or are missing according to the
sequence number.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times as
indicated by the value of transportSessionDiscontinuityTime.
transportSessionStartTime: Timestamp of the start of the given
Transport Session.
This state parameter does not correspond to any object in the
IPFIX MIB module.
transportSessionDiscontinuityTime: Timestamp of the most recent
occasion at which one or more of the Transport Session counters
suffered a discontinuity. In contrast to
ipfixTransportSessionDiscontinuityTime, the time is absolute and
not relative to sysUpTime.
Note that, if used for Exporting Processes, the values of the state
parameters destinationAddress and destinationPort match the values of
the configuration parameters destinationIPAddress and destinationPort
of the outer SctpExporter, TcpExporter, and UdpExporter objects (in
the case of SctpExporter, one of the configured destinationIPAddress
values); if the transport protocol is UDP or SCTP and if the
parameter sourceIPAddress is configured in the outer UdpExporter or
SctpExporter object, the value of sourceAddress equals the configured
value or one of the configured values. Used for Collecting
Processes, the value of destinationAddress equals the value (or one
of the values) of the parameter localIPAddress if this parameter is
configured in the outer UdpCollector, TcpCollector, or SctpCollector
object; destinationPort equals the value of the configuration
parameter localPort.
Each object of the TransportSession class includes a list of objects of the Template class with information and statistics about the Templates transmitted or received on the given Transport Session. The Template class is specified in Section 4.8.4.8. Template Class
+--------------------------------------+ | Template | +--------------------------------------+ | observationDomainId {readOnly} |<>---+ 0..* | templateId {readOnly} | | | setId {readOnly} | | | accessTime {readOnly} | | | templateDataRecords {readOnly} | | | templateDiscontinuityTime {readOnly} | | +--------------------------------------+ | | +--------------------------------------+ | Field | +--------------------------------------+ | ieId {readOnly} | | ieLength {readOnly} | | ieEnterpriseNumber {readOnly} | | isFlowKey {readOnly} {non-Options | | Template only} | | isScope {readOnly} {Options Template | | only} | +--------------------------------------+ Figure 29: Template class The Template class contains state data about Templates used by an Exporting Process or received by a Collecting Process in a specific Transport Session. The Field class defines one field of the Template. The names and semantics of the state parameters correspond to the managed objects in the ipfixTemplateTable, ipfixTemplateDefinitionTable, and ipfixTemplateStatsTable of the IPFIX MIB module [RFC6615]: observationDomainId: The ID of the Observation Domain for which this Template is defined. templateId: This number indicates the Template ID in the IPFIX Message.
setId: This number indicates the Set ID of the Template.
Currently, there are two values defined [RFC5101]. The value 2 is
used for Sets containing Template definitions. The value 3 is
used for Sets containing Options Template definitions.
accessTime: Used for Exporting Processes, this parameter contains
the time when this (Options) Template was last sent to the
Collector or written to the file.
Used for Collecting Processes, this parameter contains the time
when this (Options) Template was last received from the Exporter
or read from the file.
templateDataRecords: The number of transmitted or received Data
Records defined by this (Options) Template since the point in time
indicated by templateDefinitionTime.
templateDiscontinuityTime: Timestamp of the most recent occasion at
which the counter templateDataRecords suffered a discontinuity.
In contrast to ipfixTemplateDiscontinuityTime, the time is
absolute and not relative to sysUpTime.
ieId, ieLength, ieEnterpriseNumber: Information Element identifier,
length, and enterprise number of a field in the Template. If this
is not an enterprise-specific Information Element,
ieEnterpriseNumber is zero.
These state parameters are identical to
ipfixTemplateDefinitionIeId, ipfixTemplateDefinitionIeLength, and
ipfixTemplateDefinitionIeEnterpriseNumber in the IPFIX MIB module
[RFC6615].
isFlowKey: If this state parameter is present, this is a Flow Key
field.
This parameter is only available for non-Options Templates (i.e.,
if setId is 2).
isFlowKey: If this state parameter is present, this is a scope
field.
This parameter is only available for Options Templates (i.e., if
setId is 3).
5. Adaptation to Device Capabilities
The configuration data model standardizes a superset of common IPFIX
and PSAMP configuration parameters. A typical Monitoring Device
implementation will not support the entire range of possible
configurations. Certain functions may not be supported, such as the
Collecting Process that does not exist on a Monitoring Device that is
conceived as Exporter only. The configuration of other functions may
be subject to resource limitations or functional restrictions. For example, the Cache size is typically limited according to the available memory on the device. It is also possible that a Monitoring Device implementation requires the configuration of additional parameters that are not part of the configuration data model in order to function properly. YANG [RFC6020] offers several possibilities to restrict and adapt a configuration data model. The current version of YANG defines the concepts of features, deviations, and extensions. The feature concept allows the author of a configuration data model to make proportions of the model conditional in a manner that is controlled by the device. Devices do not have to support these conditional parts to conform to the model. If the NETCONF protocol is used, features which are supported by the device are announced in the <hello> message [RFC6241]. The configuration data model for IPFIX and PSAMP covers the configuration of Exporters, Collectors, and devices that may act as both. As Exporters and Collectors implement different functions, the corresponding proportions of the model are conditional on the following features: exporter: If this feature is supported, Exporting Processes can be configured. collector: If this feature is supported, Collecting Processes can be configured. Exporters do not necessarily implement any Selection Processes, Caches, or even Observation Points in particular cases. Therefore, the corresponding proportions of the model are conditional on the following feature: meter: If this feature is supported, Observation Points, Selection Processes, and Caches can be configured. Additional features refer to different PSAMP Sampling and Filtering methods as well as to the supported types of Caches: psampSampCountBased: If this feature is supported, Sampling method sampCountBased can be configured. psampSampTimeBased: If this feature is supported, Sampling method sampTimeBased can be configured.
psampSampRandOutOfN: If this feature is supported, Sampling method
sampRandOutOfN can be configured.
psampSampUniProb: If this feature is supported, Sampling method
sampUniProb can be configured.
psampFilterMatch: If this feature is supported, Filtering method
filterMatch can be configured.
psampFilterHash: If this feature is supported, Filtering method
filterHash can be configured.
immediateCache: If this feature is supported, a Cache generating
PSAMP Packet Reports can be configured using the ImmediateCache
class.
timeoutCache: If this feature is supported, a Cache generating IPFIX
Flow Records can be configured using the TimeoutCache class.
naturalCache: If this feature is supported, a Cache generating IPFIX
Flow Records can be configured using the NaturalCache class.
permanentCache: If this feature is supported, a Cache generating
IPFIX Flow Records can be configured using the PermanentCache
class.
The following features concern the support of UDP and TCP as
transport protocols and the support of File Readers and File Writers:
udpTransport: If this feature is supported, UDP can be used as
transport protocol by Exporting Processes and Collecting
Processes.
tcpTransport: If this feature is supported, TCP can be used as
transport protocol by Exporting Processes and Collecting
Processes.
fileReader: If this feature is supported, File Readers can be
configured as part of Collecting Processes.
fileWriter: If this feature is supported, File Writers can be
configured as part of Exporting Processes.
The deviation concept enables a device to announce deviations from
the standard model using the "deviation" statement. For example, it
is possible to restrict the value range of a specific parameter or to
define that the configuration of a certain parameter is not supported
at all. Hence, deviations are typically used to specify limitations
due to resource constraints or functional restrictions. Deviations concern existing parameters of the original configuration data model and must not be confused with model extensions. Model extensions are specified with the "augment" statement and allow adding new parameters to the original configuration data model. If certain device-specific constraints cannot be formally specified with YANG, they MUST be expressed with human-readable text using the "description" statement. The provided information MUST enable the user to define a configuration that is entirely supported by the Monitoring Device. On the other hand, if a Monitoring Device is configured, it MUST notify the user about any part of the configuration that is not supported. The Monitoring Device MUST NOT silently accept configuration data that cannot be completely enforced. If the NETCONF protocol is used to send configuration data to the Monitoring Device, the error handling is specified in the NETCONF protocol specification [RFC6241]. Just like features, deviations and model extensions are announced in NETCONF's <hello> message. A usage example of deviations is given in Section 7.5.
(page 57 continued on part 4)
