tech-invite   World Map     

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

RFC 6728

 
 
 

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

Part 3 of 6, p. 41 to 57
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 41 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part