4.  Specific Reporting Requirements

   Some specific Options Templates and Options Template Records are
   necessary to provide extra information about the Flow Records and
   about the Metering Process.

   The Option Template and Options Template Records defined in these
   subsections, which impose some constraints on the Metering Process
   and Exporting Process implementations, MAY be implemented.  If
   implemented, the specific Option Templates SHOULD be implemented as
   specified in these subsections.

   The minimum set of Information Elements is always specified in these
   Specific IPFIX Options Templates.  Nevertheless, extra Information
   Elements may be used in these specific Options Templates.

4.1.  The Metering Process Statistics Option Template

   The Metering Process Statistics Option Template specifies the
   structure of a Data Record for reporting Metering Process statistics.
   It SHOULD contain the following Information Elements that are defined
   in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

   exportedMessageTotalCount
                           The total number of IPFIX Messages that the
                           Exporting Process successfully sent to the
                           Collecting Process since the Exporting
                           Process re-initialization.

   exportedFlowTotalCount
                           The total number of Flow Records that the
                           Exporting Process successfully sent to the
                           Collecting Process since the Exporting
                           Process re-initialization.

   exportedOctetTotalCount
                           The total number of octets that the Exporting
                           Process successfully sent to the Collecting
                           Process since the Exporting Process re-
                           initialization.

   The Exporting Process SHOULD export the Data Record specified by the
   Metering Process Statistics Option Template on a regular basis or
   based on some export policy.  This periodicity or export policy
   SHOULD be configurable.

   Note that if several Metering Processes are available on the Exporter
   Observation Domain, the Information Element meteringProcessId MUST be
   specified as an additional Scope Field.

4.2.  The Metering Process Reliability Statistics Option Template

   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

   The Exporting Process SHOULD export the Data Record specified by the
   Metering Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.

   Note that if several Metering Processes are available on the Exporter
   Observation Domain, the Information Element meteringProcessId MUST be
   specified as an additional Scope Field.

4.3.  The Exporting Process Reliability Statistics Option Template

   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or

                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.

4.4.  The Flow Keys Option Template

   The Flow Keys Option Template specifies the structure of a Data
   Record for reporting the Flow Keys of reported Flows.  A Flow Keys

   Data Record extends a particular Template Record that is referenced
   by its templateId identifier.  The Template Record is extended by
   specifying which of the Information Elements contained in the
   corresponding Data Records describe Flow properties that serve as
   Flow Keys of the reported Flow.

   The Flow Keys Option Template SHOULD contain the following
   Information Elements that are defined in [RFC5102]:

   templateId              An identifier of a Template.  This
                           Information Element MUST be defined as a
                           Scope Field.

   flowKeyIndicator        Bitmap with the positions of the Flow Keys in
                           the Data Records.

5.  IPFIX Message Header "Export Time" and Flow Record Time

   The IPFIX Message Header "Export Time" field is the time in seconds
   since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves
   the Exporter.  The time-related Information Elements specified in
   [RFC5102] MAY use this "Export Time" as base time and specify an
   offset relative to it, instead of using a common base time, such as
   0000 UTC Jan 1, 1970.  All Information Elements that do not have
   their base time defined by their data type MUST have the base time
   clearly specified in their description.

   For example, Data Records requiring a microsecond precision can
   export the flow start and end times with the flowStartMicroseconds
   and flowEndMicroseconds Information Elements [RFC5102], containing
   the time since 0000 UTC Jan 1, 1970.  An alternate solution is to
   export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
   Information Elements [RFC5102] in the Data Record, which respectively
   report the flow start and end time offsets compared to the IPFIX
   Message Header "Export Time".  The latter solution lowers the export
   bandwidth requirement while it increases the load on the Exporter, as
   the Exporting Process must calculate the flowStartDeltaMicroseconds
   and flowEndDeltaMicroseconds of every single Data Record before
   exporting the IPFIX Message.

   It must be noted that using time-related Information Elements with
   offset times, compared to the IPFIX Message Header "Export Time",
   imposes some time constraints on the Data Records contained in the
   IPFIX Message.  In the example of flowStartDeltaMicroseconds and
   flowEndDeltaMicroseconds Information Elements [RFC5102], the Data
   Record must be exported within a maximum of 71 minutes after its
   creation.  Otherwise, the 32-bit counter would not be sufficient to
   contain the flow start time offset.

6.  Linkage with the Information Model

   The Information Elements [RFC5102] MUST be sent in canonical format
   in network-byte order (also known as the big-endian byte ordering).

6.1.  Encoding of IPFIX Data Types

   The following sections will define the encoding of the data types
   specified in [RFC5102].

6.1.1.  Integral Data Types

   Integral data types -- octet, signed8, unsigned16, signed16,
   unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded
   using the default canonical format in network-byte order.  Signed
   Integral data types are represented in two's complement notation.

6.1.2.  Address Types

   Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be
   encoded the same way as the integral data types.  The macAddress is
   treated as a 6-octet integer, the ipv4Address as a 4-octet integer,
   and the ipv6Address as a 16-octet integer.

6.1.3.  float32

   The float32 data type MUST be encoded as an IEEE single-precision
   32-bit floating point-type, as specified in [IEEE.754.1985].

6.1.4.  float64

   The float64 data type MUST be encoded as an IEEE double-precision
   64-bit floating point-type, as specified in [IEEE.754.1985].

6.1.5.  boolean

   The boolean data type is specified according to the TruthValue in
   [RFC2579]: it is an integer with the value 1 for true and a value 2
   for false.  Every other value is undefined.  The boolean data type
   MUST be encoded in a single octet.

6.1.6.  string and octetarray

   The data type string represents a finite length string of valid
   characters of the Unicode character encoding set.  The string data
   type MUST be encoded in UTF-8 format.  The string is sent as an array
   of octets using an Information Element of fixed or variable length.

   The length of the Information Element specifies the length of the
   octetarray.

6.1.7.  dateTimeSeconds

   The data type dateTimeseconds represents a time value in units of
   seconds normalized to the GMT timezone.  It MUST be encoded in a
   32-bit integer containing the number of seconds since 0000 UTC Jan 1,
   1970.  The 32-bit integer allows the time encoding up to 136 years.

6.1.8.  dateTimeMilliseconds

   The data type dateTimeMilliseconds represents a time value in units
   of milliseconds normalized to the GMT timezone.  It MUST be encoded
   in a 64-bit integer containing the number of milliseconds since 0000
   UTC Jan 1, 1970.

6.1.9.  dateTimeMicroseconds

   The data type dateTimeMicroseconds represents a time value in units
   of microseconds normalized to the GMT timezone.  It MUST be encoded
   in a 64-bit integer, according to the NTP format given in [RFC1305].

6.1.10.  dateTimeNanoseconds

   The data type of dateTimeNanoseconds represents a time value in units
   of nanoseconds normalized to the GMT time zone.  It MUST be encoded
   in a 64-bit integer, according to the NTP format given in [RFC1305].

6.2.  Reduced Size Encoding of Integer and Float Types

   Information Elements containing integer, string, float, and
   octetarray types in the information model MAY be encoded using fewer
   octets than those implied by their type in the information model
   definition [RFC5102], based on the assumption that the smaller size
   is sufficient to carry any value the Exporter may need to deliver.
   This reduces the network bandwidth requirement between the Exporter
   and the Collector.  Note that the Information Element definitions
   [RFC5102] will always define the maximum encoding size.

   For instance, the information model [RFC5102] defines byteCount as an
   unsigned64 type, which would require 64 bits.  However, if the
   Exporter will never locally encounter the need to send a value larger
   than 4294967295, it may chose to send the value instead as an
   unsigned32.  For example, a core router would require an unsigned64
   byteCount, while an unsigned32 might be sufficient for an access
   router.

   This behavior is indicated by the Exporter by specifying a type size
   with a smaller length than that associated with the assigned type of
   the Information Element.  In the example above, the Exporter would
   place a length of 4 versus 8 in the Template.

   If reduced sizing is used, it MUST only be applied to the following
   integer types: unsigned64, signed64, unsigned32, signed32,
   unsigned16, and signed16.  The signed versus unsigned property of the
   reported value MUST be preserved.  The reduction in size can be to
   any number of octets smaller than the original type if the data value
   still fits, i.e., so that only leading zeroes are dropped.  For
   example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or
   1 octet(s).

   Reduced sizing can also be used to reduce float64 to float32.  The
   float32 not only has a reduced number range, but due to the smaller
   mantissa, is also less precise.

   The reduced size encoding MUST NOT be applied to dateTimeMicroseconds
   or to dateTimeNanoseconds because these represent an inherent
   structure that would be destroyed by using less than the original
   number of bytes.

7.  Variable-Length Information Element

   The IPFIX Template mechanism is optimized for fixed-length
   Information Elements [RFC5102].  Where an Information Element has a
   variable length, the following mechanism MUST be used to carry the
   length information for both the IETF and proprietary Information
   Elements.

   In the Template Set, the Information Element Field Length is recorded
   as 65535.  This reserved length value notifies the Collecting Process
   that length of the Information Element will be carried in the
   Information Element content itself.

   In most cases, the length of the Information Element will be less
   than 255 octets.  The following length-encoding mechanism optimizes
   the overhead of carrying the Information Element length in this
   majority case.  The length is carried in the octet before the
   Information Element, as shown in Figure R.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length (< 255)|          Information Element                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      ... continuing as needed                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure R: Variable-Length Information Element (length < 255 octets)

   If the length of the Information Element is greater than or equal to
   255 octets, the length is encoded into 3 octets before the
   Information Element.  The first octet is 255, and the length is
   carried in the second and third octets, as shown in Figure S.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      255      |      Length (0 to 65535)      |       IE      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      ... continuing as needed                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure S: Variable-Length Information Element (length 0 to 65535
   octets)

   The octets carrying the length (either the first or the first three
   octets) MUST NOT be included in the length of the Information
   Element.

8.  Template Management

   This section describes Template Management when using SCTP and
   PR-SCTP as the transport protocol.  Any necessary changes to Template
   Management specifically related to TCP or UDP transport protocols are
   specified in Section 10.

   The Exporting Process assigns and maintains the Template IDs per SCTP
   association for the Exporter's Observation Domains.  A newly created
   Template Record is assigned an unused Template ID by the Exporting
   Process.

   If a specific Information Element is required by a Template, but is
   not available in observed packets, the Exporting Process MAY choose
   to export Flow Records without this Information Element in a Data
   Record defined by a new Template.

   If an Information Element is required more than once in a Template,
   the different occurrences of this Information Element SHOULD follow
   the logical order of their treatments by the Metering Process.  For
   example, if a selected packet goes through two hash functions, and if
   the two hash values are sent within a single Template, the first
   occurrence of the hash value should belong to the first hash function
   in the Metering Process.  For example, when exporting the two source
   IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address
   Information Element occurrence should be the IPv4 address of the
   outer header, while the second occurrence should be the inner header
   one.

   Template Sets and Options Template Sets may be sent on any SCTP
   stream.  Template Sets and Options Template Sets MUST be sent
   reliably, using SCTP-ordered delivery.  As such, the Collecting
   Process MUST store the Template Record information for the duration
   of the SCTP association so that it can interpret the corresponding
   Data Records that are received in subsequent Data Sets.

   The Exporting Process SHOULD transmit the Template Set and Options
   Template Set in advance of any Data Sets that use that (Options)
   Template ID, to help ensure that the Collector has the Template
   Record before receiving the first Data Record.  Data Records that
   correspond to a Template Record MAY appear in the same and/or
   subsequent IPFIX Message(s).

   Different Observation Domains from the same SCTP association may use
   the same Template ID value to refer to different Templates.

   The Templates that are not used anymore SHOULD be deleted.  Before
   reusing a Template ID, the Template MUST be deleted.  In order to
   delete an allocated Template, the Template is withdrawn through the
   use of a Template Withdrawal Message.

   The Template Withdrawal Message MUST NOT be sent until sufficient
   time has elapsed to allow the Collecting Process to receive and
   process the last Data Record using this Template information.  This
   time MUST be configurable.  A suitable default value is 5 seconds
   after the last Data Record has been sent.

   The Template ID from a withdrawn Template MUST NOT be reused until
   sufficient time has elapsed to allow for the Collecting Process to
   receive and process the Template Withdrawal Message.

   A Template Withdrawal Message is a Template Record for that Template
   ID with a Field Count of 0.  The format of the Template Withdrawal
   Message is shown in Figure T.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Set ID = (2 or 3)       |          Length = 16          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Template ID N        |        Field Count = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Template ID ...      |        Field Count = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Template ID M        |        Field Count = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure T: Template Withdrawal Message Format

   The Set ID field MUST contain the value 2 for Template Set Withdrawal
   and the value 3 for Options Template Set Withdrawal.  Multiple
   Template IDs MAY be withdrawn with a single Template Withdrawal
   Message, in that case, padding MAY be used.

   The Template Withdrawal Message withdraws the Template IDs for the
   Observation Domain ID specified in the IPFIX Message Header.

   The Template Withdrawal Message may be sent on any SCTP stream.  The
   Template Withdrawal Message MUST be sent reliably, using SCTP-ordered
   delivery.

   The Template Withdrawal Message MUST NOT contain new Template or
   Options Template Records.

   If the measurement parameters change such that a new Template is
   required, the Template MUST be withdrawn (using a Template Withdraw
   Message and a new Template definition) or an unused Template ID MUST
   be used.  Examples of the measurement changes are: a new sampling
   rate, a new Flow expiration process, a new filtering definition, etc.

   When the SCTP association shuts down or the Exporting Process
   restarts, all Template assignments are lost and Template IDs MUST be
   reassigned.

   If the Metering Process restarts, the Exporting Process MUST either
   reuse the previously assigned Template ID for each Template, or it
   MUST withdraw the previously issued Template IDs by sending Template
   Withdraw Message(s) before reusing them.

   A Template Withdrawal Message to withdraw all Templates for the
   Observation Domain ID specified in the IPFIX Message Header MAY be
   used.  Its format is shown in Figure U.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Set ID = 2        |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Template ID = 2       |        Field Count = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure U: All Data Templates Withdrawal Message Format

   A Template Withdrawal Message to withdraw all Options Templates for
   the Observation Domain ID specified in the IPFIX Message Header MAY
   be used.  Its format is shown in Figure V.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Set ID = 3        |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Template ID = 3       |        Field Count = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure V: All Options Templates Withdrawal Message Format

   When the SCTP association restarts, the Exporting Process MUST resend
   all the Template Records.

9.  The Collecting Process's Side

   This section describes the Collecting Process when using SCTP and
   PR-SCTP as the transport protocol.  Any necessary changes to the
   Collecting Process specifically related to TCP or UDP transport
   protocols are specified in Section 10.

   The Collecting Process SHOULD listen for a new association request
   from the Exporting Process.  The Exporting Process will request a
   number of streams to use for export.  An Exporting Process MAY
   request and support more than one stream per SCTP association.

   If the Collecting Process receives a malformed IPFIX Message, it MUST
   reset the SCTP association, discard the IPFIX Message, and SHOULD log
   the error.  Note that non-zero Set padding does not constitute a
   malformed IPFIX Message.

   Template Sets and Option Template Sets are only sent once.  The
   Collecting Process MUST store the Template Record information for the
   duration of the association so that it can interpret the
   corresponding Data Records that are received in subsequent Data Sets.

   Template IDs are unique per SCTP association and per Observation
   Domain.  If the Collecting Process receives a Template that has
   already been received but that has not previously been withdrawn
   (i.e., a Template Record from the same Exporter Observation Domain
   with the same Template ID received on the SCTP association), then the
   Collecting Process MUST shut down the association.

   When an SCTP association is closed, the Collecting Process MUST
   discard all Templates received over that association and stop
   decoding IPFIX Messages that use those Templates.

   The Collecting Process normally receives Template Records from the
   Exporting Process before receiving Data Records.  The Data Records
   are then decoded and stored by the Collector.  If the Template
   Records have not been received at the time Data Records are received,
   the Collecting Process MAY store the Data Records for a short period
   of time and decode them after the Template Records are received.  A
   Collecting Process MUST NOT assume that the Data Set and the
   associated Template Set (or Options Template Set) are exported in the
   same IPFIX Message.

   The Collecting Process MUST note the Information Element identifier
   of any Information Element that it does not understand and MAY
   discard that Information Element from the Flow Record.

   The Collector MUST accept padding in Data Records and Template
   Records.  The padding size is the Set Length minus the size of the
   Set Header (4 octets for the Set ID and the Set Length), modulo the
   Record size deduced from the Template Record.

   The IPFIX protocol has a Sequence Number field in the Export header
   that increases with the number of IPFIX Data Records in the IPFIX
   Message.  A Collector may detect out-of-sequence, dropped, or
   duplicate IPFIX Messages by tracking the Sequence Number.  A
   Collector SHOULD provide a logging mechanism for tracking
   out-of-sequence IPFIX Messages.  Such out-of-sequence IPFIX Messages
   may be due to Exporter resource exhaustion where it cannot transmit
   messages at their creation rate, an Exporting Process reset,
   congestion on the network link between the Exporter and Collector,
   Collector resource exhaustion where it cannot process the IPFIX
   Messages at their arrival rate, out-of-order packet reception,
   duplicate packet reception, or an attacker injecting false messages.

   If a Collecting Process receives a Template Withdrawal Message, the
   Collecting Process MUST delete the corresponding Template Records
   associated with the specific SCTP association and specific
   Observation Domain, and stop decoding IPFIX Messages that use the
   withdrawn Templates.

   If the Collecting Process receives a Template Withdraw message for a
   Template Record it has not received before on this SCTP association,
   it MUST reset the SCTP association, discard the IPFIX Message, and
   SHOULD log the error as it does for malformed IPFIX Messages.

   A Collecting Process that receives IPFIX Messages from several
   Observation Domains on the same Transport Session MUST be aware that
   the uniqueness of the Template ID is not guaranteed across
   Observation Domains.

   The Collector MUST support the use of Templates containing multiple
   occurrences of the similar Information Elements.

10.  Transport Protocol

   The IPFIX Protocol Specification has been designed to be transport
   protocol independent.  Note that the Exporter can export to multiple
   Collecting Processes using independent transport protocols.

   The IPFIX Message Header 16-bit Length field limits the length of an
   IPFIX Message to 65535 octets, including the header.  A Collecting
   Process MUST be able to handle IPFIX Message lengths of up to 65535
   octets.

10.1.  Transport Compliance and Transport Usage

   We need to differentiate between what must be implemented (so that
   operators can interoperably deploy compliant implementations from
   different vendors) and what should or could be used in various
   operational environments.  We must also make sure that ALL
   implementations can operate in a congestion-aware and
   congestion-avoidance mode.

   SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758]
   MUST be implemented by all compliant implementations.  UDP [UDP] MAY
   also be implemented by compliant implementations.  TCP [TCP] MAY also
   be implemented by compliant implementations.

   PR-SCTP SHOULD be used in deployments where Exporters and Collectors
   are communicating over links that are susceptible to congestion.
   PR-SCTP is capable of providing any required degree of reliability.

   TCP MAY be used in deployments where Exporters and Collectors
   communicate over links that are susceptible to congestion, but
   PR-SCTP is preferred due to its ability to limit back pressure on
   Exporters and its message versus stream orientation.

   UDP MAY be used, although it is not a congestion-aware protocol.
   However, the IPFIX traffic between Exporter and Collector MUST run in
   an environment where IPFIX traffic has been provisioned for, or is
   contained through some other means.

10.2.  SCTP

   This section describes how IPFIX can be transported over SCTP
   [RFC4960] using the PR-SCTP [RFC3758] extension.

10.2.1.  Congestion Avoidance

   The SCTP transport protocol provides the required level of congestion
   avoidance by design.

   SCTP will detect congestion in the end-to-end path between the IPFIX
   Exporting Process and the IPFIX Collecting Process, and limit the
   transfer rate accordingly.  When an IPFIX Exporting Process has
   records to export, but detects that transmission by SCTP is
   temporarily impossible, it can either wait until sending is possible
   again, or it can decide to drop the record.  In the latter case, the
   dropped export data MUST be accounted for, so that the amount of
   dropped export data can be reported.

10.2.2.  Reliability

   The SCTP transport protocol is by default reliable, but has the
   capability to deliver messages with partial reliability  [RFC3758].

   Using reliable SCTP messages for the IPFIX export is not in itself a
   guarantee that all Data Records will be delivered.  If there is
   congestion on the link from the Exporting Process to the Collecting
   Process, or if a significant number of retransmissions are required,
   the send queues on the Exporting Process may fill up; the Exporting
   Process MAY either suspend, export, or discard the IPFIX Messages.
   If Data Records are discarded the IPFIX Sequence Numbers used for
   export MUST reflect the loss of data.

10.2.3.  MTU

   SCTP provides the required IPFIX Message fragmentation service based
   on path MTU discovery.

10.2.4.  Exporting Process

10.2.4.1.  Association Establishment

   The IPFIX Exporting Process SHOULD initiate an SCTP association with
   the IPFIX Collecting Process.  By default, the Collecting Process
   listens for connections on SCTP port 4739.  By default, the
   Collecting Process listens for secure connections on SCTP port 4740
   (refer to the Security Considerations section).  By default, the
   Exporting Process tries to connect to one of these ports.  It MUST be
   possible to configure both the Exporting and Collecting Processes to
   use a different SCTP port.

   The Exporting Process MAY establish more than one association
   (connection "bundle" in SCTP terminology) to the Collecting Process.

   An Exporting Process MAY support more than one active association to
   different Collecting Processes (including the case of different
   Collecting Processes on the same host).

10.2.4.2.   Association Shutdown

   When an Exporting Process is shut down, it SHOULD shut down the SCTP
   association.

   When a Collecting Process no longer wants to receive IPFIX Messages,
   it SHOULD shut down its end of the association.  The Collecting
   Process SHOULD continue to receive and process IPFIX Messages until
   the Exporting Process has closed its end of the association.

   When a Collecting Process detects that the SCTP association has been
   abnormally terminated, it MUST continue to listen for a new
   association establishment.

   When an Exporting Process detects that the SCTP association to the
   Collecting Process is abnormally terminated, it SHOULD try to
   re-establish the association.

   Association timeouts SHOULD be configurable.

10.2.4.3.  Stream

   An Exporting Process MAY request more than one SCTP stream per
   association.  Each of these streams may be used for the transmission
   of IPFIX Messages containing Data Sets, Template Sets, and/or Options
   Template Sets.

   Depending on the requirements of the application, the Exporting
   Process may send Data Sets with full or partial reliability, using
   ordered or out-of-order delivery, over any SCTP stream established
   during SCTP Association setup.

   An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as
   per Section 4 of the PR-SCTP [RFC3758] specification when using
   partial reliability to transmit IPFIX Messages containing only Data
   Sets.

   However, Exporting Processes SHOULD mark such IPFIX Messages for
   retransmission for as long as resource or other constraints allow.

10.2.4.4.  Template Management

   When the transport protocol is SCTP, the default Template Management
   described in Section 8 is used.

10.2.5.  Collecting Process

   When the transport protocol is SCTP, the default Collector processing
   described in Section 9 is used.

10.2.6.  Failover

   If the Collecting Process does not acknowledge the attempt by the
   Exporting Process to establish an association, the Exporting Process
   should retry using the SCTP exponential backoff feature.  The
   Exporter MAY log an alarm if the time to establish the association
   exceeds a specified threshold, configurable on the Exporter.

   If Collecting Process failover is supported by the Exporting Process,
   a second SCTP association MAY be opened in advance.

10.3.  UDP

   This section describes how IPFIX can be transported over UDP [UDP].

10.3.1.  Congestion Avoidance

   UDP has no integral congestion-avoidance mechanism.  Its use over
   congestion-sensitive network paths is therefore not recommended.  UDP
   MAY be used in deployments where Exporters and Collectors always
   communicate over dedicated links that are not susceptible to
   congestion, i.e., over provisioned links compared to the maximum
   export rate from the Exporters.

10.3.2.  Reliability

   UDP is not a reliable transport protocol, and cannot guarantee
   delivery of messages.  IPFIX Messages sent from the Exporting Process
   to the Collecting Process using UDP may therefore be lost.  UDP MUST
   NOT be used unless the application can tolerate some loss of IPFIX
   Messages.

   The Collecting Process SHOULD deduce the loss and reordering of IPFIX
   Data Records by looking at the discontinuities in the IPFIX Sequence
   Number.  In the case of UDP, the IPFIX Sequence Number contains the
   total number of IPFIX Data Records sent for the UDP Transport Session
   prior to the receipt of this IPFIX Message, modulo 2^32.  A Collector
   SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages
   by tracking the Sequence Number.  Templates sent from the Exporting
   Process to the Collecting Process using UDP as a transport MUST be
   re-sent at regular intervals, in case previous copies were lost.

10.3.3.  MTU

   The maximum size of exported messages MUST be configured such that
   the total packet size does not exceed the path MTU.  If the path MTU
   is unknown, a maximum packet size of 512 octets SHOULD be used.

10.3.4.  Port Numbers

   By default, the Collecting Process listens on the UDP port 4739.  By
   default, the Collecting Process listens for secure connections on UDP
   port 4740 (refer to the "Security Considerations" section).  By
   default, the Exporting Process tries to connect to one of these
   ports.  It MUST be possible to configure both the Exporting and
   Collecting Processes to use a different UDP port.

10.3.5.  Exporting Process

   The Exporting Process MAY duplicate the IPFIX Message to the several
   Collecting Processes.

10.3.6.  Template Management

   When IPFIX uses UDP as the transport protocol, Template Sets and
   Option Template Sets MUST be re-sent at regular intervals.  The
   frequency of the (Options) Template transmission MUST be
   configurable.  The default value for the frequency of the (Options)
   Template transmission is 10 minutes.  The Exporting Process SHOULD
   transmit the Template Set and Options Template Set in advance of any
   Data Sets that use that (Options) Template ID to help ensure that the

   Collector has the Template Record before receiving the first Data
   Record.

   In the event of configuration changes, the Exporting Process SHOULD
   send multiple copies of the new Template definitions, in different
   IPFIX Messages, at an accelerated rate.  In such a case, it SHOULD
   transmit the changed Template Record(s) and Options Template
   Record(s), without any data, in advance to help ensure that the
   Collector will have the correct Template information before receiving
   the first data.

   If the Option Template scope is defined in another Template, then
   both Templates SHOULD be sent in the same IPFIX Message.  For
   example, if a Flow Key Option Template (see Section 4.4) is sent in
   an Option Template, then the associated Template SHOULD be sent in
   the same IPFIX Message.

   Following a configuration change that can modify the interpretation
   of the Data Records (for example, a sampling rate change) a new
   Template ID MUST be used, and the old Template ID MUST NOT be reused
   until its lifetime (see Section 10.3.7) has expired.

   If UDP is selected as the transport protocol, the Template Withdraw
   Messages MUST NOT be used, as this method is inefficient due to the
   unreliable nature of UDP.

10.3.7.  Collecting Process

   The Collecting Process MUST associate a lifetime with each Template
   (or another definition of an identifier considered unique within the
   Transport Session) received via UDP.  Templates (and similar
   definitions) not refreshed by the Exporting Process within the
   lifetime are expired at the Collecting Process.  If the Template (or
   other definition) is not refreshed before that lifetime has expired,
   the Collecting Process MUST discard that definition and any current
   and future associated Data Records.  In which case, an alarm MUST be
   logged.  The Collecting Process MUST NOT decode any further Data
   Records that are associated with the expired Template.  If a Template
   is refreshed with a Template Record that differs from the previously
   received Template Record, the Collecting Process SHOULD log a warning
   and replace the previously received Template Record with the new one.
   The Template lifetime at the Collecting Process MUST be at least 3
   times higher than the Template refresh timeout configured on the
   Exporting Process.

   Template IDs are unique per UDP session and per Observation Domain.
   At any given time, the Collecting Process SHOULD maintain the
   following for all the current Template Records and Options Template

   Records: <IPFIX Device, Exporter source UDP port, Observation Domain
   ID, Template ID, Template Definition, Last Received>.

   The Collecting Process SHOULD accept Data Records without the
   associated Template Record (or other definitions) required to decode
   the Data Record.  If the Template Records (or other definitions such
   as Common Properties) have not been received at the time Data Records
   are received, the Collecting Process SHOULD store the Data Records
   for a short period of time and decode them after the Template Records
   (or other definitions) are received.  The short period of time MUST
   be lower than the lifetime of definitions associated with identifiers
   considered unique within the UDP session.

   If the Collecting Process receives a malformed IPFIX Message, it MUST
   discard the IPFIX Message and SHOULD log the error.

10.3.8.  Failover

   Because UDP is not a connection-oriented protocol, the Exporting
   Process is unable to determine from the transport protocol that the
   Collecting Process is no longer able to receive the IPFIX Messages.
   Therefore, it cannot invoke a failover mechanism.  However, the
   Exporting Process MAY duplicate the IPFIX Message to several
   Collecting Processes.

10.4.  TCP

   This section describes how IPFIX can be transported over TCP [TCP].

10.4.1.  Connection Management

10.4.1.1.  Connection Establishment

   The IPFIX Exporting Process initiates a TCP connection to the
   Collecting Process.  By default, the Collecting Process listens for
   connections on TCP port 4739.  By default, the Collecting Process
   listens for secure connections on TCP port 4740 (refer to the
   Security Considerations section).  By default, the Exporting Process
   tries to connect to one of these ports.  It MUST be possible to
   configure both the Exporting Process and the Collecting Process to
   use a different TCP port.

   An Exporting Process MAY support more than one active connection to
   different Collecting Processes (including the case of different
   Collecting Processes on the same host).

   The Exporter MAY log an alarm if the time to establish the connection
   exceeds a specified threshold, configurable on the Exporter.

10.4.1.2.  Graceful Connection Release

   When an Exporting Process is shut down, it SHOULD shut down the TCP
   connection.

   When a Collecting Process no longer wants to receive IPFIX Messages,
   it SHOULD close its end of the connection.  The Collecting Process
   SHOULD continue to read IPFIX Messages until the Exporting Process
   has closed its end.

10.4.1.3.  Restarting Interrupted Connections

   When a Collecting Process detects that the TCP connection to the
   Exporting Process has terminated abnormally, it MUST continue to
   listen for a new connection.

   When an Exporting Process detects that the TCP connection to the
   Collecting Process has terminated abnormally, it SHOULD try to
   re-establish the connection.  Connection timeouts and retry schedules
   SHOULD be configurable.  In the default configuration, an Exporting
   Process MUST NOT attempt to establish a connection more frequently
   than once per minute.

10.4.1.4.  Failover

   If the Collecting Process does not acknowledge the attempt by the
   Exporting Process to establish a connection, it will retry using the
   TCP exponential backoff feature.

   If Collecting Process failover is supported by the Exporting Process,
   a second TCP connection MAY be opened in advance.

10.4.2.  Data Transmission

   Once a TCP connection is established, the Exporting Process starts
   sending IPFIX Messages to the Collecting Process.

10.4.2.1.  IPFIX Message Encoding

   IPFIX Messages are sent over the TCP connection without any special
   encoding.  The Length field in the IPFIX Message Header defines the
   end of each IPFIX Message and thus the start of the next IPFIX
   Message.  This means that IPFIX Messages cannot be interleaved.

   In the case of TCP, the IPFIX Sequence Number contains the total
   number of IPFIX Data Records sent from this TCP connection, from the
   current Observation Domain by the Exporting Process, prior to the
   receipt of this IPFIX Message, modulo 2^32.

   If an Exporting Process exports data from multiple Observation
   Domains, it should be careful to choose IPFIX Message lengths
   appropriately to minimize head-of-line blocking between different
   Observation Domains.  Multiple TCP connections MAY be used to avoid
   head-of-line between different Observation Domains.

10.4.2.2.  Template Management

   For each Template, the Exporting Process MUST send the Template
   Record before exporting Data Records that refer to that Template.

   Template IDs are unique per TCP connection and per Observation
   Domain.  A Collecting Process MUST record all Template and Options
   Template Records for the duration of the connection, as an Exporting
   Process is not required to re-export Template Records.

   When the TCP connection restarts, the Exporting Process MUST resend
   all the Template Records.

   When a TCP connection is closed, the Collecting Process MUST discard
   all Templates received over that connection and stop decoding IPFIX
   Messages that use those Templates.

   The Templates that are not used anymore SHOULD be deleted.  Before
   reusing a Template ID, the Template MUST be deleted.  In order to
   delete an allocated Template, the Template is withdrawn through the
   use of a Template Withdrawal Message over the TCP connection.

   If the Collecting Process receives a malformed IPFIX Message, it MUST
   reset the TCP connection, discard the IPFIX Message, and SHOULD log
   the error.

10.4.2.3.  Congestion Handling and Reliability

   TCP ensures reliable delivery of data from the Exporting Process to
   the Collecting Process.  TCP also controls the rate at which data can
   be sent from the Exporting Process to the Collecting Process, using a
   mechanism that takes into account both congestion in the network and
   the capabilities of the receiver.

   Therefore, an IPFIX Exporting Process may not be able to send IPFIX
   Messages at the rate that the Metering Process generates it, either
   because of congestion in the network or because the Collecting
   Process cannot handle IPFIX Messages fast enough.  As long as
   congestion is transient, the Exporting Process can buffer IPFIX
   Messages for transmission.  But such buffering is necessarily
   limited, both because of resource limitations and because of

   timeliness requirements, so ongoing and/or severe congestion may lead
   to a situation where the Exporting Process is blocked.

   When an Exporting Process has Data Records to export but the
   transmission buffer is full, and it wants to avoid blocking, it can
   decide to drop some Data Records.  The dropped Data Records MUST be
   accounted for, so that the amount can later be exported.

   When an Exporting Process finds that the rate at which records should
   be exported is consistently higher than the rate at which TCP sending
   permits, it should provide back pressure to the Metering Processes.
   The Metering Process could then adapt by temporarily reducing the
   amount of data it generates, for example, using sampling or
   aggregation.

10.4.3.  Collecting Process

   The Collecting Process SHOULD listen for a new TCP connection from
   the Exporting Process.

   If the Collecting Process receives a malformed IPFIX Message, it MUST
   reset the TCP connection, discard the IPFIX Message, and SHOULD log
   the error.  Note that non-zero Set padding does not constitute a
   malformed IPFIX Message.

   Template Sets and Option Template Sets are only sent once.  The
   Collecting Process MUST store the Template Record information for the
   duration of the connection so that it can interpret the corresponding
   Data Records that are received in subsequent Data Sets.

   Template IDs are unique per TCP connection and per Observation
   Domain.  If the Collecting Process receives a Template that has
   already been received but that has not previously been withdrawn
   (i.e., a Template Record from the same Exporter Observation Domain
   with the same Template ID received on the TCP connection), then the
   Collecting Process MUST shut down the connection.

   When a TCP connection is closed, the Collecting Process MUST discard
   all Templates received over that connection and stop decoding IPFIX
   Messages that use those Templates.

   If a Collecting Process receives a Template Withdrawal Message, the
   Collecting Process MUST delete the corresponding Template Records
   associated with the specific TCP connection and specific Observation
   Domain, and stop decoding IPFIX Messages that use the withdrawn
   Templates.

   If the Collecting Process receives a Template Withdrawal Message for
   a Template Record it has not received before on this TCP connection,
   it MUST reset the TCP association, discard the IPFIX Message, and
   SHOULD log the error as it does for malformed IPFIX Messages.