Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6728

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

Pages: 129
Proposed Standard
Errata
Part 3 of 6 – Pages 41 to 57
First   Prev   Next

Top   ToC   RFC6728 - Page 41   prevText

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.
Top   ToC   RFC6728 - Page 42

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.
Top   ToC   RFC6728 - Page 43

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
Top   ToC   RFC6728 - Page 44
      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.
Top   ToC   RFC6728 - Page 45

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.
Top   ToC   RFC6728 - Page 46

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.
Top   ToC   RFC6728 - Page 47
      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
Top   ToC   RFC6728 - Page 48
      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
Top   ToC   RFC6728 - Page 49
      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
Top   ToC   RFC6728 - Page 50
   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].
Top   ToC   RFC6728 - Page 51
   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].
Top   ToC   RFC6728 - Page 52
   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.
Top   ToC   RFC6728 - Page 53
   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.
Top   ToC   RFC6728 - Page 54
   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
Top   ToC   RFC6728 - Page 55
   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.
Top   ToC   RFC6728 - Page 56
   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
Top   ToC   RFC6728 - Page 57
   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)

Next Section