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.