Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
Benoit Claise <bclaise@cisco.com> Wed, 29 September 2010 08:44 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC103A6C7F for <ipfix@core3.amsl.com>; Wed, 29 Sep 2010 01:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L7jHrCDL5uf for <ipfix@core3.amsl.com>; Wed, 29 Sep 2010 01:44:13 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A2D893A6C77 for <ipfix@ietf.org>; Wed, 29 Sep 2010 01:44:11 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o8T898vv027086; Wed, 29 Sep 2010 10:09:08 +0200 (CEST)
Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o8T892xh012156; Wed, 29 Sep 2010 10:09:03 +0200 (CEST)
Message-ID: <4CA2F41E.7020900@cisco.com>
Date: Wed, 29 Sep 2010 10:09:02 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Gerhard Muenz <muenz@net.in.tum.de>
References: <4C4E996E.2000300@net.in.tum.de>
In-Reply-To: <4C4E996E.2000300@net.in.tum.de>
Content-Type: multipart/alternative; boundary="------------050908040500090809020808"
Cc: "ipfix@ietf.org" <ipfix@ietf.org>
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2010 08:44:13 -0000
Gerhard,
> Dear Benoit, all,
>
> Here is my review of draft-ietf-ipfix-structured-data-02. It mainly
> consists of suggestions and comments regarding the comprehensibility and
> language.
>
> There is one suggestion about the specification itself. I think that it
> would be easier to understand if the meaning of the semantic of
> subTemplateList and subTemplateMultiList would be the same, namely that
> it specifies the semantic among the Data Records. At the moment, the
> draft specifies (although not very clearly) that the semantic refers to
> goups of Data Records associated to different Templates in the case of
> the subTemplateMultiList. I do not see a use-case for this. Also, no
> useful example is provided. On the contrary, it is always said that the
> semantic of subTemplateMultiList is not sufficient.
>
> Regards,
> Gerhard
>
>
>> Abstract
>>
>> This document specifies an extension to the IP Flow Information
>> eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX
>> information model specified in [RFC5102] to support hierarchical
>> structured data and lists (sequences) of Information Elements in
>> data records. This extension allows definition of complex data
>> structures such as variable-length lists and specification of
>> hierarchical containment relationships between Templates.
> Maybe add some words about semantics?
Done.
>> 1. Overview
>>
>> 1.1. IPFIX Documents Overview
>>
>> The IPFIX Protocol [RFC5101] provides network administrators with
>> access to IP Flow information.
>>
>> The architecture for the export of measured IP Flow information
>> out of an IPFIX Exporting Process to a Collecting Process is
>> defined in the IPFIX Architecture [RFC5470], per the requirements
>> defined in RFC 3917 [RFC3917].
>>
>> The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records
>> and Templates are carried via a congestion-aware transport
>> protocol from IPFIX Exporting Processes to IPFIX Collecting
>> Processes.
>>
>> IPFIX has a formal description of IPFIX Information Elements,
>> their name, type and additional semantic information, as specified
>> in the IPFIX information model [RFC5102].
>>
>> In order to gain a level of confidence in the IPFIX
>> implementation, probe the conformity and robustness, and allow
>> interoperability, the Guidelines for IPFIX Testing [RFC5471]
>> presents a list of tests for implementers of compliant Exporting
>> Processes and Collecting Processes.
>>
>> The Bidirectional Flow Export [RFC5103] specifies a method for
>> exporting bidirectional flow (biflow) information using the IP
>> Flow Information Export (IPFIX) protocol, representing each Biflow
>> using a single Flow Record.
>>
>> The "Reducing Redundancy in IP Flow Information Export (IPFIX) and
>> Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth
>> saving method for exporting Flow or packet information, by
>> separating information common to several Flow Records from
>> information specific to an individual Flow Record: common Flow
>> information is exported only once.
>>
>>
>> 1.2. Relationship between IPFIX and PSAMP
>>
>> The specification in this document applies to the IPFIX protocol
>> specifications [RFC5101]. All specifications from [RFC5101] apply
>> unless specified otherwise in this document.
>>
>> The Packet Sampling (PSAMP) protocol [RFC5476] specifies the
>> export of packet information from a PSAMP Exporting Process to a
>> PSAMP Collecting Process. Like IPFIX, PSAMP has a formal
>> description of its information elements, their name, type and
>> additional semantic information. The PSAMP information model is
>> defined in [RFC5477].
>>
>> As the PSAMP protocol specifications [RFC5476] are based on the
>> IPFIX protocol specifications, the specifications in this document
>> are also valid for the PSAMP protocol.
>>
>> Indeed, the major difference between IPFIX and PSAMP is that the
>> IPFIX protocol exports Flow Records while the PSAMP protocol
>> exports Packet Reports. From a pure export point of view, IPFIX
>> will not distinguish a Flow Record composed of several packets
>> aggregated together, from a Flow Record composed of a single
>> packet. So the PSAMP export can be seen as a special IPFIX Flow
>> Record containing information about a single packet.
>>
>>
>> 2. Terminology
>>
>> IPFIX-specific terminology used in this document is defined in
>> Section 2 of the IPFIX protocol specification [RFC5101] and
>> Section 3 of PSAMP protocol specification [RFC5476]. As in
>> [RFC5101], these IPFIX-specific terms have the first letter of a
>> word capitalized when used in this document.
>>
>>
>> 2.1. New Terminology
>>
>> Structured Data Information Element
>>
>> One of the Information Elements supporting structured data,
>> i.e., the basicList, subTemplateList, or subTemplateMultiList
>> Information Elements specified in section 4.3.
>>
>>
>> 3. Introduction
>>
>> While collecting the interface counters every five minutes has
>> proven to be useful in the past, more and more granular
>> information is required from network elements for a series of
>> applications: performance assurance, capacity planning, security,
>> billing, or simply monitoring. However, the amount of information
>> has become so important that, when dealing with highly granular
>> information such as Flow information, a push mechanism (as opposed
>> to a pull mechanism, such as SNMP) is the only solution for
>> routers whose primary function is to route packets. Indeed,
>> polling short-live Flows via SNMP is not an option: high end
>> routers can support hundreds of thousands of Flows simultaneously.
>> Furthermore, in order to reduce the export bandwidth requirements,
>> the network elements have to integrate mediation functions to
>> aggregate the collected information, both in space and time.
>>
>> Typically, it would be beneficial if access routers could export
>> Flow Records, composed of the counters before and after the WAN
>> optimization mechanism, instead of exporting two Flow Records with
>> identical tuple information.
> It is not clear what "the WAN optimization mechanism" is.
Done.
>> In terms of aggregation in time, let us imagine that, for
>> performance assurance, the network management application must
>> receive the performance metrics associated with a specific flow,
>> every millisecond. Since the performance metrics will be
>> constantly changing, there is a new dimension to the Flow
>> definition: we are not dealing anymore with a single Flow lasting
>> a few seconds or a few minutes, but with a multitude of one
>> millisecond sub flows for which the performance metrics are
>> reported.
>>
>> Which current protocol is suitable for these requirements: push
>> mechanism, highly granular information, and huge number of similar
>> records? IPFIX, as specified in RFC5101 would give part of the
>> solution.
>>
>>
>> 3.1. The IPFIX Track
>>
>> The IPFIX working group has specified a protocol to export IP Flow
>> information [RFC5101]. This protocol is designed to export
>> information about IP traffic Flows and related measurement data,
>> where a Flow is defined by a set of key attributes (e.g. source
>> and destination IP address, source and destination port, etc.).
>>
>> The IPFIX protocol specification [RFC5101] specifies that IP
>> traffic measurements for Flows are exported using a TLV (type,
>> length, value) format. The information is exported using a
>> Template Record that is sent once to export the {type, length}
>> pairs that define the data format for the Information Elements in
>> a Flow. The Data Records specify values for each Flow.
>>
>> Based on the Requirements for IP Flow Information Export (IPFIX)
>> [RFC3917], the IPFIX protocol has been optimized to export Flow
>> related information. However, thanks to its Template mechanism,
>> the IPFIX protocol can export any type of information, as long as
>> the relevant Information Element is specified in the IPFIX
>> information model [RFC5102], registered with IANA [IANA-IPFIX], or
>> specified as an enterprise-specific Information Element. For each
>> Information Element, the IPFIX information model [RFC5102] defines
>> a numeric identifier, an abstract data type, an encoding mechanism
>> for the data type, and any semantic constraints. Only basic,
>> single-valued data types, e.g., numbers, strings, and network
>> addresses are currently supported.
>>
>>
>> 3.2. The IPFIX Limitations
>>
>> The IPFIX protocol specification [RFC5101] does not support the
>> encoding of hierarchical structured data and arbitrary-length
>> lists (sequences) of Information Elements as fields within a
>> Template Record. As it is currently specified, a Data Record is a
>> "flat" list of single-valued attributes. However, it is a common
>> data modeling requirement to compose complex hierarchies of data
>> types, with multiple occurrences, e.g., 0..* cardinality allowed
>> for instances of each Information Element in the hierarchy.
>>
>> A typical example is the MPLS label stack entries model. An early
>> NetFlow implementation used two Information Elements to represent
>> the MPLS label stack entry: a "label stack entry position"
>> followed by a "label stack value". However, several drawbacks
>> were discovered. Firstly, the Information Elements in the
>> Template Record had to be imposed so that the position would
>> always precede the value. However, some encoding optimizations
>> are based on the permutation of Information Element order.
>> Secondly, a new semantic intelligence, not described in the
>> information model, had to be hardcoded in the Collecting Process:
>> the label value at the position "X" in the stack is contained in
>> the "label stack value" Information Element following by a "label
>> stack entry position" Information Element containing the value
>> "X". Therefore, this model was abandoned.
>>
>> The selected solution in the IPFIX information model [RFC5102] is
>> a long series of Information Elements: mplsTopLabelStackSection,
>> mplsLabelStackSection2, mplsLabelStackSection3,
>> mplsLabelStackSection4, mplsLabelStackSection5,
>> mplsLabelStackSection6, mplsLabelStackSection7,
>> mplsLabelStackSection8, mplsLabelStackSection9,
>> mplsLabelStackSection10. While this model removes any ambiguity,
>> it overloads the IPFIX information model with repetitive
>> information. Furthermore, if mplsLabelStackSection11 is required,
>> IANA [IANA-IPFIX] will not be able to assign the new Information
>> Element next to the other ones in the registry, which might cause
>> some confusion.
>>
>> Clearly a real structured data type composed of ("label stack
>> entry position", "label stack value") pairs, potentially repeated
>> multiple times in Flow Records would be more efficient from an
>> information model point of view.
>>
>> Some more examples enter the same category: how to encode the list
>> of output interfaces in a multicast Flow, how to encode the list
>> of BGP Autonomous Systems (AS) in a BGP Flow, how to encode the
>> BGP communities in a BGP Flow, etc?
>>
>> The one-way delay passive measurement, which is described in the
>> IPFIX Applicability [RFC5472], is yet another example that would
>> benefit from a structured data encoding. Assuming synchronized
>> clocks, the Collector can deduce the one-way delay from the
>> following two Information Elements, collected from two different
>> Observation Points:
>> - Packet arrival time: observationTimeMicroseconds [RFC5477]
>> - Packet ID: digestHashValue [RFC5477]
>> Ideally, the measurement at the second Observation Point should
>> start a little bit later than at the first Observation Point,
>> allowing the packets to arrive at the destination.
> I do not understand this sentence. How does the measurement affect
> packet forwarding? How can the measurement allow packets to arrive
> somewhere?
This is confusing. Removed.
>> In practice,
>> this implies that many pairs of (observationTimeMicroseconds,
>> digestHashValue) must be exported for each Observation Point, even
>> if some optimization based on Hash-Based Filtering [RFC5475] is
>> used.
> What can be "optimized" by HBF?
>
> Maybe: "...even if Hash-Based Filtering is used."
>
Done
>> Instead of exporting repetitive information as part of
>> every single Flow Record (for example, the 5 tuple), an optimized
> I suggest to remove all occurrences of "optimize", "optimization" etc.
> unless there is a metric based on which you optimize and unless you can
> tell whether you reach a global optimum or a local optimum.
Done.
>> flow record composed of a structured data type such as the
>> following would save a lot of bandwidth:
>>
>> 5 tuple
> It would be good to explain what "5 tuple" means.
Done.
source IP address, destination IP address, protocol, source port,
destination port
{ observationTimeMicroseconds 1, digestHashValue 1 }
{ observationTimeMicroseconds 2, digestHashValue 2 }
{ observationTimeMicroseconds 3, digestHashValue 3 }
{ ... , ... }
>> { observationTimeMicroseconds 1, digestHashValue 1 }
>> { observationTimeMicroseconds 2, digestHashValue 2 }
>> { observationTimeMicroseconds 3, digestHashValue 3 }
>> { ... , ... }
> The example has remaind unclear to me until I understood what you
> describe here. In particular, it is not obvious to me that OWD
> measurements are exported in Flow Records together with the 5 tuple.
>
> If you perform OWD measurements, isn't it sufficient to just export
> digestHashValue and observationTimeMicroseconds?
If you just care about the OWD between point A and B, yes.
However, in practice we need the application performance metrics, and a
very basic way to classify the application is with the 5 tuple, i.e.
source IP address, destination IP address, protocol, source port,
destination port
> Also, if you talk about Flow Records here, you actually mean PSAMP
> Packet Report (i.e. one packet Flow), right? This is not explained.
The distinction between a Flow Record and a Packet Report is not that
clear between we export 5 tuple and packet related information
>> As a last example, here is a more complex case of hierarchical
>> structured data encoding. Consider the example scenario of an IPS
>> (Intrusion Prevention System) alert data structure containing
>> multiple participants, where each participant contains multiple
>> attackers and multiple targets, with each target potentially
>> composed of multiple applications, as depicted below:
>>
>> alert
>> signatureId
>> protocolIdentifier
>> riskRating
>> participant 1
>> attacker 1
>> sourceIPv4Address
>> applicationId
>> ...
>> attacker N
>> sourceIPv4Address
>> applicationId
>> target 1
>> destinationIPv4Address
>> applicationId 1
>> ...
>> applicationId n
>> ...
>> target N
>> destinationIPv4Address
>> applicationId 1
>> ...
>> applicationId n
>> participant 2
>> ...
>>
>> To export this information in IPFIX, the data would need to be
>> flattened (thus losing the hierarchical relationships) and a new
>> IPFIX Template created for each alert, according to the number of
>> applicationID elements in each target, the number of targets and
>> attackers in each participant, and the number of participants in
>> each alert. Clearly each Template will be unique to each alert,
>> and a large amount of CPU, memory and export bandwidth will be
>> wasted creating, exporting, maintaining, and withdrawing the
>> Templates. See Appendix C for a specific example related to this
>> case study.
>>
>>
>> 3.3. The Proposal
>>
>> This document specifies an IPFIX extension to support hierarchical
>> structured data and variable-length lists by defining three new
>> Information Elements and three corresponding new abstract data
>> types called basicList, subTemplateList, and subTemplateMultiList.
>>
>> These are defined in Section 4.1. The three list Information
>> Elements carry some semantic information so that the Collecting
>> Process can understand the relationship between the different list
>> elements.
>>
>> It is important to note that whereas the Information Elements and
>> abstract data types defined in the IPFIX information model
>> [RFC5102] represent single values, these new abstract data types
>> are structural in nature and primarily contain references to other
>> Information Elements and to Templates. By referencing other
>> Information Elements and Templates from an Information Element's
>> data content, it is possible to define complex data structures
>> such as variable-length lists and to specify hierarchical
>> containment relationships between Templates. Therefore, this
>> document prefers the more generic "Data Record" term to the "Flow
>> Record" term.
>>
>> This document specifies three new abstract data types, which are
>> basic blocks to represent structured data. However, this document
>> does not comment on all possible combinations of basicList,
>> subTemplateList, and subTemplateMultiList. Neither, does it limit
>> the possible combinations.
>>
>> 4. Linkage with the Information Model
>>
>> As in the IPFIX Protocol specification [RFC5101], the new
>> Information Elements specified in Section 4.3. below MUST be sent
>> in canonical format in network-byte order (also known as the big-
>> endian byte ordering).
>>
>>
>> 4.1. New Abstract Data Types
>>
>> This document specifies three new abstract data types, as
>> described below.
>>
>>
>> 4.1.1. basicList
>>
>> The type "basicList" represents a list of zero or more instances
>> of any single Information Element, primarily used for single-
>> valued data types. For example, a list of port numbers, a list of
>> interface indexes, a list of AS in a BGP AS-PATH, etc.
>>
>>
>> 4.1.2. subTemplateList
>>
>> The type "subTemplateList" represents a list of zero or more
>> instances of a structured data type, where the data type of each
>> list element is the same and corresponds with a single Template
>> Record. For example, a structured data type composed of multiple
>> pairs of ("MPLS label stack entry position", "MPLS label stack
>> value"), a structured data type composed of performance metrics, a
>> structured data type composed of multiple pairs of IP address,
>> etc.
>>
>>
>> 4.1.3. subTemplateMultiList
>>
>> The type "subTemplateMultiList" represents a list of zero or more
>> instances of a structured data type, where the data type of each
>> list element can be different and corresponds with different
>> template definitions. For example, a structured data type
>> composed of multiple access-list entries, where entries can be
>> composed of different criteria types.
>>
>>
>> 4.2. New Data Type Semantic
>>
>> This document specifies a new data type semantic, as described
>> below.
>>
>>
>> 4.2.1. List
>>
>> A list represents an arbitrary-length sequence of zero or more
>> structured data elements, either composed of regular Information
>> Elements or composed of data conforming to a Template Record.
>>
>> 4.3. New Information Elements
>>
>> This document specifies three new Information Elements, as
>> described below.
>>
>>
>> 4.3.1. basicList
>>
>> A basicList specifies a generic Information Element with a
>> basicList abstract data type as defined in Section 4.1.1. and list
>> semantics as defined in Section 4.2.1. For example, a list of
>> port numbers, a list of interface indexes, etc.
>>
>> EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this
>> new Information Element identifier, the value XXX is used in all
>> the examples and in the XML in Appendix A.
>>
>> 4.3.2. subTemplateList
>>
>> A subTemplateList specifies a generic Information Element with a
>> subTemplateList abstract data type as defined in Section 4.1.2.
>> and list semantics as defined in Section 4.2.1.
>>
>> EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this
>> new Information Element identifier, the value YYY is used in all
>> the examples.
>>
>>
>> 4.3.3. subTemplateMultiList
>>
>> A subTemplateMultiList specifies a generic Information Element
>> with a subTemplateMultiList abstract data type as defined in
>> Section 4.1.3. and list semantics as defined in Section 4.2.1.
>>
>> EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this
>> new Information Element identifier, the value ZZZ is used in all
>> the examples.
>>
>> 4.4. New Structured Data Type Semantics
>>
>> Structured Data type semantics are provided in order to express
> Structured _d_ata type
done.
>> the relationship among multiple list elements in a Structured Data
>> Information Element. These Structured Data type semantics require
> _s_tructured _d_ata (is not a term!)
>
> Please check all further occurrences below! The usage of capital letters
> is inconsistent.
Good catch. There were many of them, corrected now.
>> a new IPFIX subregistry, as specified in the "IANA Considerations"
>> section. The semantics are specified in the next following
>> sections.
>>
>> 4.4.1. undefined
>>
>> The "undefined" Structured Data type semantic specifies that the
>> semantic of list elements is not specified, and that, if a
>> semantic exists, then it is up to the Collecting Process to draw
>> its own conclusions. The "undefined" structured data type
>> semantic is the default Structured Data type semantic.
>>
>> 4.4.2. noneOf
>>
>> The "noneOf" Structured Data type semantic specifies that none of
>> the elements are actual properties of the Data Record.
>>
>> For example, a mediator might want to report to a Collector that a
>> specific Flow is suspicious, but that it checked already that this
>> Flow does not belong to the attack type 1, attack type 2, and
>> attack type 3. So this Flow might need some further inspection.
>> In such a case, the mediator would report the Flow Record with a
>> basicList composed of (attack type 1, attack type 2, attack type
>> 3) and the respective Structured Data type semantic of "noneOf".
>>
>> Another example is a router that monitors some specific BGP AS-
>> PATHs and reports if a Flow belongs to any of them. If the router
>> wants to export that a Flow does not belong to any of the
>> monitored BGP AS-PATHs, the router reports a Data Record with a
>> basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH
>> 3) and the respective Structured Data type semantic of "noneOf".
>>
>>
>> 4.4.3. exactlyOneOf
>>
>> The "exactlyOneOf" Structured Data type semantic specifies that
>> only a single element from the Structured Data is an actual
>> property of the Data Record. This is equivalent to a logical XOR
>> operation.
>>
>> For example, if a Flow record contains a basicList of outgoing
>> interfaces with the "exactlyOneOf" semantic, then it implies that
>> the reported Flow only egressed from a single interface, although
>> the Flow Record lists all of the possible outgoing interfaces.
>> This is a typical example of a per destination load-balanced Flow
>> IPFIX encoding.
> What does the last sentence mean? How can structured data be typical if
> it has not even been standardized?
Last sentence changed to "This is a typical example of a per destination
load-balancing."
>> For example, a mediator must report an aggregated observation
> "Another example is a mediator which must..."
>
> You should explain what an "aggregate observation point" is.
Change to
"Another example is a mediator that must..."
>> point, composed of multiple Template Records:
> Unclear. The information about OPs is exported in Data Records, not in
> Template Records.
>
Good catch.
"specified by different Template Records"
>>
>> Template Record 1: exporterIPaddress
>> This reports a specific exporter
>>
>> Template Record 2: exporterIPaddress, basicList of interfaces
>> This reports a series of interfaces from an exporter
>>
>> Template Record 3: exporterIPaddress, line card
>> This reports a specific line card from an exporter
>>
>> If these three Template Records are exported with a
>> subTemplateMultiList with the semantic "exactlyOneOf", then it
> You only export Data Records in a subTemplateMultiList, not Template
> Records!
>
Right.
>> implies that the Flow Observation Point is reported with the
> "Flow's Observation Point"?
>
>> values of either Template Record 1, Template Record 2, or Template
>> Record 3 but not more than one Template Record.
> I would rewrite it in two sentences, e.g.:
>
> "The Flow Record exported by the mediator contains a
> subTemplateMultiList field with semantic "exactlyOneOf" containing one
> Data Record for each of the Template Records described above. This
> implies that the Flow was observed at exactly one of the Observation
> Points reported."
I completely rewrote this section.
>> 4.4.4. oneOrMoreOf
>>
>> The "oneOrMoreOf" Structured Data type semantic specifies that one
>> or more element(s) from the list in the Structured Data is/are
> I do not like (s) and "/" alternatives.
>
> "elements .... are"
>
Done.
>> actual propertie(s) of the Data Record. This is equivalent to a
> "properties"
Done.
>> logical OR operation.
>>
>> For example, a mediator must report an aggregated Flow (for
>> example aggregated from IP addresses to IP prefixes), with an
> "(for ...)" => "(e.g. aggregating IP addresses with common IP prefixes)"
Done.
>> aggregated observation point, composed of multiple Template
>> Records:
>>
>>
>> Template Record 1: exporterIPaddress
>> This reports a specific exporter
>>
>> Template Record 2: exporterIPaddress, basicList of interfaces
>> This reports a series of interfaces from an exporter
>>
>> Template Record 3: exporterIPaddress, line card
>> This reports a specific line card from an exporter
>>
>> If these three Template Records are exported with a
>> subTemplateMultiList with the semantic "oneOrMoreOf", then the
> Same comments as in section 4.4.3.
Rewrote this section with the same style as Section 4.4.3
>> aggregated Flow has been observed on at least one of the
>> individual Observation Points reported with the values of a
>> specific Template Record, and potentially on multiple Observation
>> Points.
>>
>>
>> 4.4.5. allOf
>>
>> The "allOf" structured data type semantic specifies that all of
>> the list elements from the Structured Data are actual properties
>> of the Data Record.
>>
>> For example, if a Record contains a basicList of outgoing
>> interfaces with the "allOf" semantic, then the observed Flow is
>> typically a multicast Flow where each packet in the Flow has been
>> replicated to each outgoing interface in the basicList.
>>
>>
>> 4.4.6. ordered
>>
>> The "ordered" Structured Data type semantic specifies that
>> elements from the list in the Structured Data are ordered.
>>
>> For example, an Exporter might want to export the AS10 AS20 AS30
>> AS40 BGP AS-PATH. In such a case, the Exporter would report a
>> basicList composed of (AS10, AS20, AS30, AS40) and the respective
>> Structured Data type semantic of "ordered".
>>
>>
>> 4.5. Encoding of IPFIX Data Types
>>
>> The following sections define the encoding of the data types
> abstract data types ?
Added abstract keyword.
>> defined in Section 4.1. above.
>>
>> When the encoding of a Structured Data Information Element has a
>> fixed length (because, for example, it contains the same number of
>> fixed-length elements, or if the permutations of elements in the
>> list always produces the same total length), the element length
>> can be encoded in the corresponding Template Record. However,
>> when representing variable-length data, hierarchical data, and
>> repeated data with variable element counts, we RECOMMEND these are
> "...RECOMMEND that these..."
Done.
>> encoded as a Variable-Length Information Element as described in
> _v_ariable-_l_ength
Thanks for pointing this out, corrected in several places.
>> Section 7 of [RFC5101], with the length carried in one or three
>> octets before the Structured Data Information Element encoding.
>>
>>
>> 4.5.1. basicList
>>
>> The basicList Information Element defined in Section 4.3.1.
>> represents a list of zero or more instances of an Information
>> Element and is encoded as follows:
>>
>> 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
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Semantic |0| Field ID | Element... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ...Length | BasicList Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure A: basicList Information Element Encoding
>>
>>
>> Semantic
>>
>> The Semantic indicates the semantic of the list elements,
> remove "The" at the beginning of the sentence or write "The Semantic
> field..."?
>
Changed to "The Semantic field" as per your suggestion, several instances corrected.
>> i.e., the relationship among the different Information Element
>> values within this Structured Data.
> _s_tructured _d_ata
Instances of Structured Data changed to structured data changed where applicable.
>>
>>
>> Field ID
>>
>> The Field ID is the Information Element identifier of the
> remove "The" at the beginning of the sentence or add "field"?
Field Id Field seems confusing; so removed "The" at the beginning, this will be Field Id, several instances corrected.
>> Information Element(s) contained in the list.
>>
>>
>> Element Length
>>
>> The Element Length indicates the length of each list element
> remove "The" at the beginning of the sentence or add "field"?
Changed to "The Element Length Field", several instances.
>> specified by the Field ID, or contains the value 0xFFFF if the
>> length is encoded as a variable-length Information Element at
>> the start of the BasicList Content.
>>
>> The Element Length field is effectively part of a header, so
>> even in the case of a zero-element list with no Enterprise
>> Number, it MUST NOT be omitted.
> why "with no Enterprise Number"?
>
> I would remove the last paragraph. "header" is confusing. And you repeat
> this requirement below.
Removed the reference to Enterprise Number. But we want to emphasize that the length field should be included even if the list has zero elements. So left this in there.
>>
>>
>> BasicList Content
>>
>> A Collection Process decodes list elements from the BasicList
>> Content until no further data remains. A field count is not
>> included but can be derived when the Information Element is
>> decoded.
>>
>> Note that in the diagram above, the Field ID is shown with the
> maybe "..., Field ID...," or "..., the Field ID field ..." ?
done.
>> Enterprise bit (most significant bit) set to 0. If instead the
>> Enterprise bit is set to 1, a four-byte Enterprise Number MUST be
>> encoded immediately after the Element Length as shown below. See
>> the "Field Specifier Format" section in the IPFIX Protocol
>> [RFC5101] for additional information.
>>
>> 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
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Semantic |1| Field ID | Element... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ...Length | Enterprise Number ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | BasicList Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>> Figure B: basicList Encoding with Enterprise Number
>>
>>
>> Also note that, if a basicList has zero elements, the encoded data
>> contains the Semantic, Field ID, the Element Length and the four-
>> byte Enterprise Number (if present), while the BasicList Content
>> is empty.
>>
>> If the basicList is encoded as a Variable-Length Information
> variable-length (also appears multiple times below)
>
done.
>> Element in less than 255 octets, it is encoded with the Length per
> "Length" => "Length field" (multiple times below)
done.
>> Section 7 of [RFC5101] as follows:
>>
>> 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)| basicList Content |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... continuing as needed |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure C: Variable-Length basicList Information Element Encoding
>> (Length< 255 octets)
>>
>>
>> If the basicList is encoded as a Variable-Length Information
>> Element in 255 or more octets, it is encoded with the Length per
>> Section 7 of [RFC5101] as follows:
>>
>> 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) | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | basicList Content |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure D: Variable-Length basicList Information Element Encoding
>> (Length 0 to 65535 octets)
>>
>>
>> 4.5.2. subTemplateList
>>
>> The subTemplateList Information Element represents a list of zero
>> or more instances of Template data. Because the Template Record
> what do you mean by "instances of Template data" ?
>
> This would be clearer: "Data Records associated to one specific
> (Options) Template"
>
> Or do you think that the term "Data Record" should not be used here?
> Yet, you also use it below in this context...
Changed this to 'Data Records corresponding to a specific Template'
>> referenced by a subTemplateList Information Element can itself
>> contain other subTemplateList Information Elements, and because
>> these Template Record references are part of the Information
>> Elements content in the Data Record, it is possible to represent
>> complex hierarchical data structures. The following diagram shows
>> how a subTemplateList Information Element is encoded within a Data
>> Record:
>>
>> 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
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Semantic | Template ID | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | SubTemplateList Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure E: subTemplateList Encoding
>>
>>
>> Semantic
>>
>> The Semantic indicates the semantic of the list elements, i.e.
> remove "The" at the beginning of the sentence? Or "The Semantic field"?
done.
>> the relationship among the different Data Records within this
>> Structured Data.
>>
>> Template ID
>>
>> The Template ID is the ID of the template used to encode and
> This sentence is confusing because Template ID is an IPFIX term! So, it
> sound like a redefinition.
>
> Better: "The Template ID field contains the ID of the ...."
done.
>> decode the SubTemplateList Content.
>>
>> SubTemplateList Content
>>
>> The SubTemplateList Content consists of zero or more instances
>> of Data Records corresponding to the Template ID. A
> "...Template ID specified in the Template ID field." ?
>
> Well, it's pedantic and I would not insist on this change :)
done.
>> Collecting Process decodes the Data Records until no further
>> data remains. A record count is not included but can be
>> derived when the subTemplateList is decoded. Encoding and
>> decoding are performed recursively if the specified Template
>> itself contains Structured Data Information Elements as
>> described here.
>>
>>
>> Note that, if a subTemplateList has zero elements, the encoded
>> data contains only the Semantic and the Template ID, while the
>> SubTemplateList Content is empty.
>>
>> If the subTemplateList is encoded as a Variable-Length Information
> variable-length (same below)
>
done.
>> Element in less than 255 octets, it is encoded with the Length per
> Length field (same below)
done.
>> Section 7 of [RFC5101] as follows:
>>
>>
>> 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)| subTemplateList Content |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... continuing as needed |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure F: Variable-Length subTemplateList Information Element
>> Encoding (Length< 255 octets)
>>
>>
>> If the subTemplateList is encoded as a Variable-Length Information
>> Element in 255 or more octets, it is encoded with the Length per
>> Section 7 of [RFC5101] as follows:
>>
>> 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) | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... SubTemplateList Content |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure G: Variable-Length subTemplateList Information Element
>> Encoding (Length 0 to 65535 octets)
>>
>>
>> 4.5.3. subTemplateMultiList
>>
>> Whereas each top-level element in a subTemplateList Information
> what is meant by "top-level"? It means that there are levels below. Remove?
Done. Removed 'top-level'
>> Element corresponds with a single Template ID and therefore has
> "corresponds to"
>
>> the same data type, sometimes it is useful for a list to contain
> Why "same data type"? Each element is a Data Record associated to the
> same (Options) Template.
>
> ", sometimes it..." => "..., it is sometimes useful..."
done.
>> elements of more than one data type. To support this case, each
> Why "data type"? You talk about Templates.
Removed references to data types.
>> top-level element in a subTemplateMultiList Information Element
>> carries a Template ID, Length and zero or more Data Records
>> corresponding to the Template ID. The following diagram shows how
>> a subTemplateMultiList Information Element is encoded within a
>> Data Record. Note that the subTemplateMultiList encoding is
>> consistent with Set Header specified in [RFC5101], once the
> "with Set Header" => "with the Set Header" ?
done.
>> Semantic field has been decoded.
> well, not only after decoding Semantic, also after encoding it :)
>
> Better:
> "Note that the encoding following the Semantic field is consistent with
> the Set Header specified in [RFC5101]."
done.
>>
>> 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
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Semantic | Template ID X |Data Records...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... Length X | Data Record X.1 Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Data Record X.2 Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Data Record X.L Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Template ID Y |Data Records...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... Length Y | Data Record Y.1 Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Data Record Y.2 Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Data Record Y.M Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Template ID Z |Data Records...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... Length Z | Data Record Z.1 Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Data Record Z.2 Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Data Record Z.N Content ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+
>>
>> Figure H: subTemplateMultiList Encoding
>>
>> Semantic
>>
>> The Semantic indicates the top level semantic among Template
> Remove "The" or "Semantic field"?
done.
> remove "top level"
will be part of a bigger change about the top level semantic
> "among the Data Records"?
will be part of a bigger change about the top level semantic
> Comment added later: Now as I have read section 5.4, I understand that
> you want to restrict to the semantic among sequences of Data Records
> belonging to different Templates. This does not become clear. Wouldn't
> it be simpler to say that Semantic defines the semantic among all Data
> Records, regardless of the Template?
Defer this comment for later; revisit after Semantic has been rewritten.
>> Records, i.e. the relationship among the series of Data
>> Records from the different Template Records within this
> "from" => "associated with"
Defer this comment for later; revisit after Semantic has been rewritten.
>> Structured Data.
> _s_tructured _d_ata
done.
>>
>> Note: if a semantic is required to describe the relationship
>> among the different Data Records corresponding to a single
>> Template ID within the subTemplateMultiList, then an encoding
>> based on a basicList of subTemplateLists should be used. Refer
> I would remove "basicList" because it does not support Templates. So, it
> is not a general alternative.
Defer this comment for later; revisit after Semantic has been rewritten.
>> to Section 5.6 for more information.
>>
>> Template ID
>>
>> Unlike the subTemplateList Information Element, each list
>> element contains a Template ID which specifies the encoding of
> "each element of subTemplateMultiList contains..."
done.
>> the following Data Records.
>>
>> Data Records Length
>>
>> The total length of the Data Records encoding for the Template
>> ID previously specified, including the 2 bytes for the
>> Template ID and the 2 bytes for the Data Records Length field
>> itself.
>>
>> Data Record X.M
>>
>> The Data Record X.M consists of the Mth Data Record of the
>> Template Record X. A Collecting Process decodes the Data
>> Records until no further data remains, according to the Data
>> Records Length. A record count is not included but can be
>> derived when the Element Content is decoded. Encoding and
>> decoding are performed recursively if the specified Template
>> itself contains Structured Data Information Elements as
>> described here.
>>
>> In the exceptional case of zero instances in the
>> subTemplateMultiList, no data is encoded and the Data Record
>> Length is set to zero.
>>
>> If the subTemplateMultiList is encoded as a Variable-Length
> variable-length
done.
>> Information Element in less than 255 octets, it is encoded with
>> the Length per Section 7 of [RFC5101] as follows:
> Length field
done.
>>
>> 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)| subTemplateMultiList Information Element |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... continuing as needed |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure I: Variable-Length subTemplateMultiList Information Element
>> Encoding (Length< 255 octets)
>>
>>
>> If the subTemplateMultiList is encoded as a Variable-Length
>> Information Element in 255 or more octets, it is encoded with the
>> Length per Section 7 of [RFC5101] as follows:
> same comments as above
done.
>>
>> 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 J: Variable-Length subTemplateMultiList Information
>> Element Encoding (Length 0 to 65535 octets)
>>
>>
>> 5. Structured Data Format
>>
>>
>> 5.1. Length Encoding Considerations
>>
>> The new Structured Data Information Elements represent a list that
>> potentially carries complex hierarchical and repeated data. In
>> the normal case where the number and length of elements can vary
>> from record to record, these Information Elements are encoded as
>> variable-length Information Elements as described in Section 7 of
>> [RFC5101].
>>
>> Because of the complex and repeated nature of the data, it is
>> potentially difficult for the Exporting Process to efficiently
>> know in advance the exact encoding size.
> I would replace the following
>
>> As a result, data may be
>> recursively encoded starting at a fixed offset, with the final
>> length only known and filled in afterwards.
>>
>> Therefore, the three-byte length encoding is RECOMMENDED for
>> variable-length information elements in all Template Records
>> containing a Structured Data Information Element, even if the
>> encoded length can be less than 255 bytes, because the starting
>> offset of the data is known in advance.
> by:
> "In this case, the Exporting Process may encode the available data and
> fill in the final length afterwards. Therefore, it may be convenient to
> always use the three-byte long encoding of the Length field of the
> variable-length Structured Data Information Element (even if the final
> length is less than 255 bytes) to allow the data encoding to start at a
> fixed offset."
Actually, we like the RECOMMENDED keyword.
We have adapted the text like this:
In this case, the Exporting Process may encode the available data
starting at a fixed offset and fill in the final length afterwards.
Therefore, the three-byte length encoding is RECOMMENDED for
variable-length information elements in all Template Records
containing a Structured Data Information Element, even if the
encoded length can be less than 255 bytes, because the starting
offset of the data is known in advance.
>>
>> An Exporting Process MUST take care when encoding such data to not
>> exceed the maximum allowed length of an IPFIX Message, 65535
>> bytes, respecting the IPFIX specifications [RFC5101] that imposes:
>> "The IPFIX Message Header 16-bit Length field limits the length of
>> an IPFIX Message to 65535 octets, including the header".
> I do not think that a quotation is necessary.
>
> "When encoding such data, an Exporting Process MUST take care to not
> exceed the maximum allowed IPFIX Message length of 65535 bytes which is
> specified in [RFC5101]."
done.
>>
>>
>> 5.2. Recursive Structured Data
>>
>> It is possible to define recursive relationships between IPFIX
>> structured data instances, for example when representing a tree
>> structure. The simplest case of this might be a basicList where
>> each element is itself a basicList, or a subTemplateList where one
>> of the fields of the referenced template is itself a
>> subTemplateList referencing the same Template. When such a
>> recursive relationship exists, variable-length encoding as
>> described in Section 7 of [RFC5101] MUST be used. Also, the
>> Exporting Process MUST take care when encoding recursively-defined
>> structured data, not to exceed the maximum allowed length of an
>> IPFIX Message (as noted in Length Encoding Considerations).
>>
>>
>> 5.3. Structured Data Information Elements Applicability in Options
>> Template Sets
>>
>> Structured Data Information Elements MAY be used in Options
>> Template Sets.
>>
>> As an example, consider a mediation function that must aggregate
>> Data Records from multiple Observation Point types:
>>
>> Router 1, (interface 1)
>> Router 2, (line card A)
>> Router 3, (line card B)
>> Router 4, (line card C, interface 2)
>>
>> In order to encode the PSAMP Selection Sequence Report
>> Interpretation [RFC5476], the mediation function must express this
>> combination of Observation Points as a single new Observation
>> Point. Recall from [RFC5476] that the PSAMP Selection Sequence
>> Report Interpretation consists of the following fields:
>>
>> Scope: selectionSequenceId
>> Non-Scope: one Information Element mapping the Observation Point
>> selectorId (one or more)
>>
>> Without structured data, there is clearly no way to express the
>> complex aggregated Observation Point as "one Information Element
>> mapping the Observation Point". However, the desired result may
>> be easily achieved using the structured data types. Refer to
>> Section 8.5. for an encoding example related to this case study.
>>
>> Regarding the scope in the Options Template Record, the IPFIX
>> specification [RFC5101] mentions that "The IPFIX protocol doesn't
>> prevent the use of any Information Elements for scope".
>> Therefore, a Structured Data Information Element MAY be used as
>> scope in an Options Template Set.
>>
>> Extending the previous example, the mediation function could
>> export a given name for this complex aggregated Observation Point:
>>
>> Scope: Aggregated Observation Point (Structured Data)
>> Non-Scope: a new Information Element containing the name
>>
>>
>> 5.4. Usage Guidelines for Equivalent Data Representations
>>
>> Because basicList, subTemplateList, and subTemplateMultiList are
>> all lists, in several cases there is more than one way to
>> represent what is effectively the same data structure. However,
>> in some cases, one approach has an advantage over the other e.g.
>> more compact, uses fewer resources, etc., and is therefore
>> preferred over an alternate representation.
>>
>> A subTemplateList can represent the same simple list of single-
>> value Information Elements as a basicList, if the Template
>> referenced by the subTemplateList contains only one single-valued
>> Information Element. Although the encoding is more compact than a
>> basicList by two bytes, using a subTemplateList in this case
>> requires a new Template per Information Element. The basicList
>> requires no additional Template and is therefore RECOMMENDED in
>> this case.
>>
>> Although a subTemplateMultiList with one Element can represent the
>> contents of a subTemplateList, the subTemplateMultiList carries
>> two additional bytes (Element Length). It is also potentially
>> useful to a Collecting Process to know in advance that a
>> subTemplateList directly indicates that list element types are
>> consistent. The subTemplateList Information Element is therefore
>> RECOMMENDED in this case.
>>
>> The Semantic in a subTemplateMultiList indicates the top level
> Semantic field
done.
>> semantic among Template Records, i.e. the relationship among the
> Template Records => Data Records ?
>
> See comment above in section 4.5.3.
Part of a bigger change about the semantic
>> series of Data Records from the different Template Records, within
>> this Structured Data. If a semantic is required to describe the
>> relationship among the different Data Records corresponding to a
>> single Template ID within the subTemplateMultiList, then an
>> encoding based on a basicList of subTemplateLists should be used.
>>
>> Note that the referenced Information Element(s) in the Structured
>> Data Information Elements can be taken from the IPFIX information
>> model [RFC5102], the PSAMP information model [RFC5477], or any of
>> the Information Elements defined in the IANA IPFIX registry [IANA-
>> IPFIX].
> Hm, what about enterprise-specific IEs?
Done, Added enterprise-specific IEs.
>>
>>
>> 5.5. Padding
>>
>> The Exporting Process MAY insert some padding octets in structured
>> data field values in a Data Record by including the
>> 'paddingOctets' Information Element as described in [RFC5101]
>> Section 3.3.1. The paddingOctets Information Element can be
>> included in a Template Record referenced by Structured Data
>> Information Element for this purpose.
> Do we need this section? If you keep it, provide an example where
> padding might be useful in the context of structured data.
We don't have a perfect example for now, but I would like to keep the
MAY statement.
>>
>>
>> 5.6. Semantic
>>
>> Semantic interpretations of received Data Records at or beyond the
>> Collecting Process remain explicitly undefined, unless that data
>> is transmitted using this extension with explicit Structured Data
>> type semantic information.
> Do we need this sentence? It seems to define an unnecessary restriction.
> Maybe we specify further mechanisms for IPFIX semantics in another RFC
> which could conflict with this sentence.
I believe that we need this sentence: it just says: if you don't use the
explicit Structured Data type semantic information, you should might be
wrong if your try to interprete the semantic. I don't see this as a
restriction.
>> The Exporter SHOULD NOT check all semantically meaningless
>> combinations before exporting the Data Record.
> I do not understand.
> SHOULD NOT => SHOULD
> or
> SHOULD NOT => "does not have to"
does not have to.
In IPFIX structured data, we can express some complex (or stupid)
semantic. It's not the responsibility of the exporter to check if what
is encoded makes sense from a semantic point of view.
>> Most forms of Structured Data type semantics are possible, without
>> necessarily specifying new semantic values.
> Is there a proof for this statement?
>
> Otherwise:
> "More complex semantics can be expressed as a combination of the
> Semantic Data Information Elements specified in this document."
done.
>> For example, the export of the AS10 AS20 AS30 AS40 {AS50,AS60} BGP
>> AS-PATH would be reported as a basicList of two elements, each
>> element being a basicList of BGP AS, with the top level Structured
>> Data type semantic of "ordered". The first element would contain
>> a basicList composed of (AS10,AS20,AS30,AS40) and the respective
>> Structured Data type semantic of "ordered", while the second
>> element would contain a basicList composed of (AS50, AS60) and the
>> respective Structured Data type semantic of "exactlyOneOf". A
>> high level Data Record diagram would be represented as:
>>
>> (basicList, ordered,
>>
>> (basicList, ordered, AS10,AS20,AS30,AS40),
>>
>> (basicList, exactlyOneOf, AS50, AS60)
>>
>> )
>>
>> Note that the subTemplateMultiList Structured Data type semantic
>> provides the top level semantic among Template Records, i.e. the
>> relationship among the series of Data Records from the different
>> Template Records within this Structured Data, and not the
>> relationships of the different Data Records corresponding to a
>> single Template ID within the subTemplateMultiList. If this is
>> required, semantic information needs to be exported for every
>> Template ID, in other words a basicList of subTemplateLists should
>> be used.
> Remove this paragraph as it is repeated from section 5.4.
done.
>> The following case studies show the advantage of a basicList of
>> subTemplateLists over a subTemplateMultiList.
>>
>> Case study 1:
>>
>> In this example, an Exporter monitoring security attacks must
>> export a list of attackers and targets. For the sake of the
>> example, consider attackers A1 or A2 may attack targets T1 and T2.
> "consider" => "imagine that"
done.
>> The first case uses a subTemplateMultiList composed of two
>> Template Records, one representing the attacker and one
>> representing the target, each of them containing an IP address and
>> a port.
>>
>> Attacker Template Record = (src IP address, src port)
>> Target Template Record = (dst IP address, dst port)
>>
>> A high level Data Record diagram would be represented as:
>>
>> (subTemplateMultiList, allOf,
>>
>> (Attacker Template Record, A1, A2),
>>
>> (Target Template Record, T1, T2)
>>
>> )
>>
>> The Collecting Process can only conclude that all of the attackers
>> A1, A2 and the targets T1, T2 are present, without knowing the
>> relationship amongst attackers and targets. The Exporting Process
>> would have to explicitly call out the relationship amongst
>> attackers and targets and the top level semantic offered by the
> second "and" => "as" ?
done.
>> subTemplateMultiList isn't sufficient.
>>
>> The only proper encoding for the previous semantic (i.e. attacker
>> A1 or A2 may attack target T1 and T2) uses a basicList of
>> subTemplateLists and is represented as follows:
>>
>> Attacker Template Record = (src IP address, src port)
>>
>> Target Template Record = (dst IP address, dst port)
>>
>> (basicList, allof,
>>
>> (subTemplateList, exactlyOneOf, attacker A1, A2)
>>
>> (subTemplateList, allOf, target T1, T2)
>>
>> )
>>
>>
>>
>> Case study 2:
>>
>> In this example, an Exporter monitoring security attacks must
>> export a list of attackers and targets. For the sake of the
>> example, attackers A1 or A2 may attack targets T1, attacker A3 is
> "targets" => "target"
done.
>> attacking targets T2 and T3. The first case uses a
>> subTemplateMultiList composed of two Template Records, one
> "Data Records associated to two different Templates"
done.
>> representing the attacker and one representing the target, each of
>> them containing an IP address and a port.
>>
>> Attacker Template Record = (src IP address, src port)
>>
>> Target Template Record = (dst IP address, dst port)
>>
>> A high level Data Record diagram would be represented as:
>>
>> (subTemplateMultiList, allOf,
>>
>> (Attacker Template Record, A1, A2, A3),
>>
>> (Target Template Record, T1, T2, T3)
>>
>> )
>>
>> The Collecting Process can only conclude that all of the attackers
>> A1, A2, A3 and the targets T1, T2, T3 are present, without knowing
>> the relationship amongst attackers and targets.
>>
>> The second case could use a Data Record definition composed of the
>> following:
>>
>> (subTemplateMultiList, allOf,
>>
>> (Attacker Template Record, A1, A2),
>>
>> (Target Template Record, T1),
>>
>> (Attacker Template Record, A3),
>>
>> (Target Template Record, T2, T3)
>>
>> )
>>
>> With the above representation, the Collecting Process can possibly
>> deduce that some relationship exists among (A1, A2, T1) and (A3,
>> T2, T3) but cannot understand what it is exactly. So, there is a
>> need for the Exporting Process to explicitly define the
>> relationship between the attackers and targets and the top level
>> semantic of the subTemplateMultiList is not sufficient.
>>
>> The only proper encoding for the previous semantic (i.e. attacker
>> A1 or A2 attack target T1, attacker A3 attacks targets T2 and T3)
>> uses a basicList of subTemplateLists and is represented as
>> follows:
>>
>> Attacker Template Record = (src IP address, src port)
>>
>> Target Template Record = (dst IP address, dst port)
> I would not repeat these Template Records here because you do not show
> the Participant and Alarm Templates either.
>
removed.
>> Participant P1:
>>
>> (basicList, allOf,
>>
>> (subTemplateList, exactlyOneOf, attacker A1, A2)
>>
>> (subTemplateList, undefined, target T1)
>>
>> )
>>
>> Participant P2:
>>
>> (basicList, allOf,
>>
>> (subTemplateList, undefined, attacker A3,
>>
>> (subTemplateList, allOf, targets T2, T3)
>>
>> )
>>
>> The security alert is represented as a subTemplateList of
>> participants.
>>
>> Alert
>>
>> (subTemplateList, allOf, Participant P1, Participant P2)
>>
>> Note that, in the particular case of a single element in a
>> Structured Data Information Element, the semantic field is
>> actually not very useful since it specifies the relationship among
>> multiple elements. Any choice of allOf, exactlyOneOr, or
>> OneOrMoreOf would provide the same result semantically.
>> Therefore, in case of a single element in a Structured Data
>> Information Element, the default "undefined" semantic SHOULD be
>> used.
>>
>>
>> 6. Template Management
>>
>> This section introduces some more specific Template Management and
> _m_anagement
done.
>> Template Withdrawal Message-related specifications compared to the
>> IPFIX protocol specification [RFC5101].
>>
>> First of all, the Template ID uniqueness is unchanged compared to
>> [RFC5101]; the uniqueness is local to the Transport Session and
>> Observation Domain that generated the Template ID. In other
>> words, the Set ID used to export the Template Record does not
>> influence the Template ID uniqueness.
>>
>> While [RFC5101] mentions that: "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.", this rule MAY not be
>> followed for the Structured Data Information Elements.
>>
>> As specified in [RFC5101], 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.
> You might clarify that deleting a Template implies that it may not be
> used within subTemplateList and subTemplateMultiList any more.
As specified in [RFC5101], Templates that are not used anymore SHOULD be
deleted. Deleting a Template implies that it may not be used within
subTemplateList and subTemplateMultiList any more. 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.
>>
>>
>> 7. The Collecting Process's Side
>>
>> This section introduces some more specific specifications to the
>> Collection Process compared to Section 9 in the IPFIX Protocol
>> [RFC5101].
>>
>> As described in [RFC5101], a 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. Therefore a Collection Process that does not
>> support the extension specified in this document can ignore the
>> Structured Data Information Elements in a Data Record, or it can
>> ignore Data Records containing these new Structured Data
>> Information Elements while continuing to process other Data
>> Records.
>>
>> If the Structured Data contains the "undefined" Structured Data
>> type semantic, the Collecting Process MAY attempt to draw its own
>> conclusion in terms of the semantic contained in the Data Record,
>> exactly as it would have done before the introduction of this
>> specification.
> Maybe remove "exactly as..." because without this specification, you
> cannot nest Data Records anyway, so the CP never has the problem to
> interpret nested Data Records.
removed
>>
>> 8. Structured Data Encoding Examples
>>
>> The following examples are created solely for the purpose of
>> illustrating how the extensions proposed in this document are
>> encoded.
>>
>>
>> 8.1. Encoding a Multicast Data Record with BasicList
>>
>> Consider encoding a multicast Data Record containing the following
>> data:
>>
>> ---------------------------------------------------------------
>> Ingress If | Source IP | Destination IP | Egress Interfaces
>> ---------------------------------------------------------------
>> 9 192.0.2.201 233.252.0.1 1, 4, 8
>> ---------------------------------------------------------------
>>
>> Template Record for the multicast Flows, with the Template ID 256:
>>
>> 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 = 24 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 256 | Field Count = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| ingressInterface = 10 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceIPv4Address = 8 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| DestinationIPv4Address = 12 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| basicList = XXX | Field Length = 0xFFFF |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure K: Encoding basicList, Template Record
>>
>>
>> The list of outgoing interfaces is represented as a basicList with
>> semantic allOf, and the Length of the list is chosen to be encoded
>> in three bytes even though it may be less than 255 octets.
>>
>> The Data Set is represented as follows:
>>
>>
>> 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 = 256 | Length = 36 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ingressInterface = 9 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceIPv4Address = 192.0.2.201 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | DestinationIPv4Address = 233.252.0.1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 255 | List Length = 17 | semantic=allOf|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface FieldId = 14 |egressInterface Field Length=4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface value 1 = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface value 2 = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface value 3 = 8 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure L: Encoding basicList, Data Record, Semantic allOf
>>
>> In the example above, the BasicList contains fixed-length
>> elements. To illustrate how variable-length elements would be
>> encoded, the same example is shown below with variable-length
>> interface names in the BasicList instead:
>>
>>
>> 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 = 256 | Length = 44 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ingressInterface = 9 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceIPv4Address = 192.0.2.201 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | DestinationIPv4Address = 233.252.0.1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 255 | List Length = 25 | semantic=allOf|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| InterfaceName FieldId = 82 | InterfaceName Field Len=0xFFFF|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Length = 5 | 'F' | 'E' | '0' |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | '/' | '0' | Length = 7 | 'F' |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 'E' | '1' | '0' | '/' |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | '1' | '0' | Length = 5 | 'F' |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 'E' | '2' | '/' | '2' |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure M: Encoding basicList, Data Record with Variable-Length
>> Elements, Semantic allOf
>>
>>
>> 8.2. Encoding a Load-balanced Data Record with a BasicList
>>
>> Consider encoding a load-balanced Data Record containing the
>> following data:
>>
>> ---------------------------------------------------------------
>> Ingress If | Source IP | Destination IP | Egress Interfaces
>> ---------------------------------------------------------------
>> 9 192.0.2.201 233.252.0.1 1, 4, 8
>> ---------------------------------------------------------------
>>
>>
>> So the Data Record egressed from either interface 1, 4, or 8. The
>> Data Set is represented as follows:
>>
>> 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 = 256 | Length = 36 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ingressInterface = 9 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceIPv4Address = 192.0.2.201 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | DestinationIPv4Address = 233.252.0.1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 255 | List Length = 17 |sem=exactlyOne |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface FieldId = 14 |egressInterface Field Length=4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface value 1 = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface value 2 = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | egressInterface value 3 = 8 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure N: Encoding basicList, Data Record, Semantic ExactlyOneOf
>>
>>
>> 8.3. Encoding subTemplateList
>>
>> As explained in Section 3.2. , multiple pairs of
>> (observationTimeMicroseconds, digestHashValue) must be collected
>> from two different Observation Points to passively compute the
>> one-way delay across the network. This data can be exported with
>> an optimized Data Record that consists of the following
>> attributes:
>>
>> 5 tuple
>> { observationTimeMicroseconds 1, digestHashValue 1 }
>> { observationTimeMicroseconds 2, digestHashValue 2 }
>> { observationTimeMicroseconds 3, digestHashValue 3 }
>> { ... , ... }
>>
>>
>> A subTemplateList is best suited for exporting the list of
>> (observationTimeMicroseconds, digestHashValue). For illustration
>> purposes, the number of elements in the list is 5; in practice, it
>> could be more.
>>
>> ------------------------------------------------------------------
>> srcIP | dstIP | src | dst |proto| one-way delay
>> | | Port | Port | | metrics
>> ------------------------------------------------------------------
>> 192.0.2.1 192.0.2.105 1025 80 6 Time1, 0x0x91230613
>> Time2, 0x0x91230650
>> Time3, 0x0x91230725
>> Time4, 0x0x91230844
>> Time5, 0x0x91230978
>> ------------------------------------------------------------------
>>
>> The following Template is defined for exporting the one-way delay
>> metrics:
>>
>> 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 = 16 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 257 | Field Count = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| observationTimeMicroSec=324 | Field Length = 8 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| digestHashValue = 326 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure O: Encoding subTemplateList, Template for One-Way Delay
>> Metrics
>>
>>
>> The Template Record for the Optimized Data Record is as follows:
>>
>> 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 = 32 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 258 | Field Count = 6 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceIPv4Address = 8 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| destinationIPv4Address = 12 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceTransportPort = 7 | Field Length = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| destinationTransportPort= 11| Field Length = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| protocolIdentifier = 4 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| subTemplateList = YYY | Field Length = 0xFFFF |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure P: Encoding subTemplateList, Template Record
>>
>> The list of (observationTimeMicroseconds, digestHashValue) is
>> exported as a subTemplateList with semantic allOf. The Length of
>> the subTemplatelist is chosen to be encoded in three bytes even
>> though it may be less than 255 octets.
>>
>> The Data Record is represented as follows:
>>
>> 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 = 258 | Length = 83 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceIPv4Address = 192.0.2.1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | destinationIPV4Address = 192.0.2.105 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceTransportPort = 1025 | destinationTransportPort = 80 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Protocol = 6 | 255 | one-way metrics list len = 63 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | semantic=allOf| TemplateID = 257 | TimeValue1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 2-5 of TimeValue1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 6-8 of TimeValue1 |digestHashVal1=|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 0x0x91230613 | TimeValue2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 2-5 of TimeValue2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 6-8 of TimeValue2 |digestHashVal2=|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 0x0x91230650 | TimeValue3 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 2-5 of TimeValue3 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 6-8 of TimeValue3 |digestHashVal3=|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 0x0x91230725 | TimeValue4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 2-5 of TimeValue4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 6-8 of TimeValue4 |digestHashVal4=|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 0x0x91230844 | TimeValue5 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 2-5 of TimeValue5 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... octets 6-8 of TimeValue5 |digestHashVal5=|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 0x0x91230978 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>> Figure Q: Encoding subTemplateList, Data Set
>>
>>
>> 8.4. Encoding subTemplateMultiList
>>
>> As explained in Section 4.4.3., a subTemplateMultiList is used to
>> export a list of mixed-type content where each top level element
>> corresponds to a different Template Record.
>>
>> To illustrate this, consider the Data Record with the following
>> attributes:
>>
>>
>> 5 tuple (Flow Keys), octetCount, packetCount
>> attributes for classification
>> selectorId,
>> selectorAlgorithm
>> attributes for sampling
>> selectorId,
>> selectorAlgorithm,
>> samplingPacketInterval,
>> samplingPacketSpace
>>
>> This example demonstrates that the Selector Report Interpretation
>> [RFC5476] can be encoded with the subTemplateMultiList. More
>> specifically, the example describes Property Match Filtering
>> Selector Report Interpretation [RFC5476] used for classification
> IMO, "classification" can be misunderstood.
> Why do not use the word "filtering"? Or "selection"?
Done, changed all classification to filtering.
>> purposes, and the Systemic Count-Based Sampling as described in
>> Section 6.5.2.1 of [RFC5476]. Some traffic will be filtered
>> according to match properties configured, some will be sampled,
>> some will be filtered and sampled, and some will not be filtered or
>> be sampled.
>>
>> A subTemplateMultiList is best suited for exporting this variable
>> data. A Template is defined for classification attributes and
> Again, I would say: filtering attributes.
done.
>> another Template is defined for sampling attributes. A Data Record
>> can contain data corresponding to either of the Templates, both of
>> them, or neither of them.
>>
>>
>> Consider the example below where the following Data Record contains
>> both classification and sampling attributes.
>>
>> Key attributes of the Data Record:
>>
>> ------------------------------------------------------------------
>> srcIP | dstIP | src | dst | proto | octetCount | packet
>> | | Port | Port | | | Count
>> ------------------------------------------------------------------
>> 192.0.2.1 192.0.2.105 1025 80 6 108000 120
>> ------------------------------------------------------------------
>>
>>
>> Classification attributes:
>>
>> -------------------------------------------
>> selectorId | selectorAlgorithm
>> -------------------------------------------
>> 100 5 (Property Match Filtering)
>> -------------------------------------------
>>
>>
>> Sampling attributes:
>>
>> For Systemic Count-Based Sampling as defined in Section 6.5.2.1 of
>> [RFC5476] the required algorithm-specific Information Elements are:
>>
>> samplingPacketInterval: number of packets selected in a row
>> samplingPacketSpace: number of packets between selections
>>
>> Example of a simple 1 out-of 100 systematic count-based Selector
>> definition, where the samplingPacketInterval is 1 and the
>> samplingPacketSpace is 99.
>>
>> --------------------------------------------------------------
>> selectorId | selectorAlgorithm | sampling | sampling
>> | | Packet | Packet
>> | | Interval | Space
>> --------------------------------------------------------------
>> 15 1 (Count-Based Sampling) 1 99
>> --------------------------------------------------------------
>>
>>
>> To represent the Data Record, the following Template Records are
>> defined:
>>
>> Template for classification attributes: 259
>> Template for sampling attributes: 260
>> Template for Flow Record: 261
>>
>> Flow record (261)
>> | (sourceIPv4Address)
>> | (destinationIPv4Address)
>> | (sourceTransportPort)
>> | (destinationTransportPort)
>> | (protocolIdentifier)
>> | (octetTotalCount)
>> | (packetTotalCount)
>> |
>> +------ classification attributes (259)
>> | (selectorId)
>> | (selectorAlgorithm)
>> |
>> +------ sampling attributes (260)
>> | (selectorId)
>> | (selectorAlgorithm)
>> | (samplingPacketInterval)
>> | (samplingPacketSpace)
>>
>>
>> The following Template Record is defined for classification
>> attributes:
>>
>> 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 = 16 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 259 | Field Count = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| selectorId = 302 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| selectorAlgorithm = 304 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure R: Encoding subTemplateMultiList, Template for
>> Classification Attributes
>>
>> The Template for sampling attributes is defined as follows:
>>
>>
>> 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 = 24 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 260 | Field Count = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| selectorId = 302 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| selectorAlgorithm = 304 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| samplingPacketInteval = 305 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| samplingPacketSpace = 306 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure S: Encoding subTemplateMultiList, Template for Sampling
>> Attributes
>>
>>
>> Note that while selectorId is defined as unsigned64, it is
> Actually, selectorId is unsigned32 (at least according to WG consensus)
done.
>> compressed down to 4 octet here as allowed by Reduced Size
>> Encoding in Section 6.2 of the IPFIX protocol specifications
>> [RFC5101].
>>
>> Note that while selectorAlgorithm is defined as unsigned16, and
>> samplingPacketInterval and samplingPacketSpace are defined as
>> unsigned32, they are compressed down to 1 octet here as allowed
>> by Reduced Size Encoding in Section 6.2 of the IPFIX protocol
>> specifications [RFC5101].
>>
>>
>> Template for the Flow Record is defined as shown below:
>>
>> 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 = 40 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 261 | Field Count = 8 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceIPv4Address = 8 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| destinationIPv4Address = 12 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceTransportPort = 7 | Field Length = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| destinationTransportPort=11 | Field Length = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| protocolIdentifier = 4 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| octetTotalCount = 85 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| packetTotalCount = 86 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| subTemplateMultiList = ZZZ | Field Length = 0XFFFF |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure T: Encoding subTemplateMultiList, Template for Flow Record
>>
>>
>> A subTemplateMultiList with semantic allOf is used to export the
>> classification and sampling attributes. The Length of the
>> subTemplateMultilist is chosen to be encoded in three bytes even
>> though it may be less than 255 octets.
>>
>> The Data Record is encoded as follows:
>>
>> 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 = 261 | Length = 49 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceIPv4Address = 192.0.2.1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | destinationIPv4Address = 192.0.2.105 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceTransportPort = 1025 | destinationTransportPort = 80 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | protocol = 6 | octetTotalCount = 108000 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | packetTotalCount = 120 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | 255 | Attributes List Length = 21 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |semantic=allOf | Classif. Template ID = 259 | Classif. Attr |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ...Length = 9 | selectorId = ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 100 |selectorAlg = 5| Sampling Template ID = 260 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Sampling Attributes Length=11 | selectorId = ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 15 |selectorAlg = 1| Interval = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Space = 99 |
>> +-+-+-+-+-+-+-+-+
>>
>> Figure U: Encoding subTemplateMultiList, Data Set
>>
>>
>> 8.5. Encoding an Options Template Set using Structured Data
>>
>> As described in Section 5.3. , consider a mediation function that
>> must aggregate Data Records from multiple different Observation
>> Points.
>>
>> Say Observation Point 1 consists of one or more interfaces,
>> Observation Points 2 and 3 consist of one or more line cards, and
>> Observation Point 4 consists of one or more interfaces and one or
>> more line cards. Without structured data, a template would have
>> to be defined for every possible combination to interpret the data
>> corresponding to each of the Observation Points. However, with
>> structured data, a basicList can be used to encode the list of
>> interfaces and another basicList can be used to encode the list of
>> line cards.
>>
>> For the sake of simplicity, each Observation Point shown below has
>> an<interface> or<linecard> or<line card and interface>. This
>> can very well be extended to include a list of interfaces and a
>> list of linecards using basicLists as explained above.
>>
>> Observation Point 1: Router 1, (interface 1)
>> Observation Point 2: Router 2, (line card A)
>> Observation Point 3: Router 3, (line card B)
>> Observation Point 4: Router 4, (line card C, interface 2)
>>
>>
>> The mediation function wishes to express this as a single
>> Observation Point, in order to encode the PSAMP Selection Sequence
>> Report Interpretation (SSRI). Recall from [RFC5476] that the
>> PSAMP Selection Sequence Report Interpretation consists of the
>> following fields:
>>
>> Scope: selectionSequenceId
>> Non-Scope: one Information Element mapping the Observation Point
>> selectorId (one or more)
>>
>> For example, the Observation Point detailed above may be encoded
>> in a PSAMP Selection Sequence Report Interpretation as shown
>> below:
>>
>> Selection Sequence 7 (Filter->Sampling):
>> observation point: subTemplateMultiList.
>> Router 1, (interface 1)
>> Router 2, (line card A)
>> Router 3, (line card B)
>> Router 4, (line card C, interface 2)
>> selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1)
>> selectorId: 10 (Sampler, Random 1 out-of ten)
>>
>> The following Templates are defined to represent the PSAMP SSRI:
>> Template for representing PSAMP SSRI: 262
>> Template for representing interface: 263
>> Template for representing linecard: 264
>> Template for representing linecard and interface: 265
>>
>>
>> PSAMP SSRI (262)
>> | (SelectionSequenceId)
>> |
>> +--- Observation Point 1 (263)
>> | (Interface Id)
>> |
>> +--- Observation Point 2 and 3 (264)
>> | (line card)
>> |
>> +--- Observation Point 4 (265)
>> | (line card)
>> | (Interface Id)
>> |
>> | (selectorId 1)
>> | (selectorId 2)
>>
>>
>> Figure V: PSAMP SSRI to be encoded
>>
>> 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 = 26 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 262 | Field Count = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Scope Field Count = 1 |0| selectionSequenceId = 301 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Scope 1 Length = 4 |0| subTemplateMultiList = ZZZ |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Field Length = 0xFFFF |0| selectorId = 302 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Field Length = 4 |0| selectorId = 302 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure W: Options Template Record for PSAMP SSRI using
>> subTemplateMultiList
>>
>> A subTemplateMultiList with semantic allOf is used to encode the
>> list of Observation Points.
>>
>> 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 = 12 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 263 | Field Count = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| ingressInterface = 10 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure X: PSAMP SSRI, Template Record for interface
>>
>>
>> 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 = 12 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 264 | Field Count = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| lineCardId = 141 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure Y: PSAMP SSRI, Template Record for linecard
>>
>>
>> 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 = 16 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 265 | Field Count = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| lineCardId = 141 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| ingressInterface = 10 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure Z: PSAMP SSRI, Template Record for linecard and interface
>>
>>
>> The PSAMP SSRI Data Set is represented as follows:
>>
>> 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 = 262 | Length = 52 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | selectionSequenceId = 7 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 255 | Observation Point List Len=33 |semantic=allOf |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP1 Template ID = 263 | OP1 Length = 8 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP1 ingressInterface = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP2&3 Template ID = 264 | OP2&3 Length = 12 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP2 lineCardId = A |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP3 lineCardId = B |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP4 Template ID = 265 | OP4 Length = 12 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP4 lineCardId = C |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | OP4 ingressInterface = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | selectorId = 5 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | selectorId = 10 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure ZA: Example of a PSAMP SSRI Data Record, Encoded using a
>> subTemplateMultiList
>>
>> Note that the Data Record above contains multiple instances of
>> Template 264 to represent Observation Point 2 (line card A) and
>> Observation Point 3 (line card B). Instead, if a single
>> Observation Point had both line card A and line card B, a
>> basicList would be used to represent the list of line cards.
>>
>>
>>
>> 9. Relationship with the Other IFPIX Documents
>>
>> 9.1. Relationship with Reducing Redundancy
>>
>> "Reducing Redundancy in IP Flow Information Export (IPFIX) and
>> Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth
>> saving method for exporting Flow or packet information using the
>> IP Flow Information eXport (IPFIX) protocol.
>>
>> It defines the commonPropertiesID Information Element for
>> exporting Common Properties.
>>
>>
>>
>> 9.1.1. Encoding Structured Data Element using Common Properties.
>>
>> When Structured Data Information Elements contain repeated
>> elements, these elements may be replaced with a
>> commonPropertiesID Information Element as specified in
>> [RFC5473]. The replaced elements may include the basicList,
>> subTemplateList and subTemplateMultiList Information Elements.
>>
>> This technique might help reducing the bandwidth requirements
>> for the export. However, a detailed analysis of the gain has
>> not been done; refer to Section 8.3 of [RFC5473] for further
>> considerations.
>>
>>
>>
>> 9.1.2. Encoding Common Properties elements With Structured Data
>> Element.
>>
>> Structured Data Information Element MAY be used to define a list
>> of commonPropertiesID, as a replacement for the specifications
>> in [RFC5473].
>>
>> Indeed, the example in figures 1 and 2 of [RFC5473] can be
>> encoded with the specifications in this document.
>>
>>
>> +----------------+-------------+---------------------------+
>> | sourceAddressA | sourcePortA |<Flow1 information> |
>> +----------------+-------------+---------------------------+
>> | sourceAddressA | sourcePortA |<Flow2 information> |
>> +----------------+-------------+---------------------------+
>> | sourceAddressA | sourcePortA |<Flow3 information> |
>> +----------------+-------------+---------------------------+
>> | sourceAddressA | sourcePortA |<Flow4 information> |
>> +----------------+-------------+---------------------------+
>> | ... | ... | ... |
>> +----------------+-------------+---------------------------+
>>
>> Figure ZB: Common and Specific Properties Exported Together
>> [RFC5473]
>>
>> +------------------------+-----------------+-------------+
>> | index for properties A | sourceAddressA | sourcePortA |
>> +------------------------+-----------------+-------------+
>> | ... | ... | ... |
>> +------------------------+-----------------+-------------+
>>
>>
>> +------------------------+---------------------------+
>> | index for properties A |<Flow1 information> |
>> +------------------------+---------------------------+
>> | index for properties A |<Flow2 information> |
>> +------------------------+---------------------------+
>> | index for properties A |<Flow3 information> |
>> +------------------------+---------------------------+
>> | index for properties A |<Flow4 information> |
>> +------------------------+---------------------------+
>>
>> Figure ZC: Common and Specific Properties Exported Separately
>> according to [RFC5473]
>>
>> +----------------+-------------+---------------------------+
>> | sourceAddressA | sourcePortA |<Flow1 information> |
>> +----------------+-------------+---------------------------+
>> |<Flow2 information> |
>> +---------------------------+
>> |<Flow3 information> |
>> +---------------------------+
>> |<Flow4 information> |
>> +---------------------------+
>> | ... |
>> +---------------------------+
>>
>> Figure ZD: Common and Specific Properties Exported with
>> Structured Data Information Element
>>
>>
>> The example in figure ZC could be encoded with a basicList if
> Isn't it in figure ZD?
yes, done.
>> the<Flow information> represents a single Information Element,
>> with a subTemplateList if the<Flow information> represents a
>> Template Record, or with a subTemplateMultiList if the<Flow
>> information> is composed of different Template Records.
>>
>> Using Structured Data Information Elements as a replacement for
>> the techniques specified in "Reducing Redundancy in IP Flow
>> Information Export (IPFIX) and Packet Sampling (PSAMP) Reports"
>> [RFC5473] offers the advantage that a single Template Record is
>> defined. Hence the Collectors job is simplified in terms of
>> Template management and combining Template/Options Template
>> Records.
>>
>> However, it must be noted that using Structured Data Information
>> Elements as a replacement for the techniques specified in
>> "Reducing Redundancy in IP Flow Information Export (IPFIX) and
>> Packet Sampling (PSAMP) Reports" only applies to simplified
>> cases. For example, the "Multiple Data Reduction" (Section 7.1
>> [RFC5473]) might be too complex to encode with Structured Data
>> Information Elements.
>>
>>
>>
>> 9.2. Relationship with Guidelines for IPFIX Testing
>>
>> [RFC5471] presents a list of tests for implementers of IP Flow
>> Information eXport (IPFIX) compliant Exporting Processes and
>> Collecting Processes.
>>
>> Although [RFC5471] doesn't define any structured data element
>> specific tests, the Structured Data Information Elements can be
>> used in many of the [RFC5471] tests.
>>
>> The [RFC5471] series of test could be useful because the
>> document specifies that every Information Element type should be
>> tested. However, not all cases from this document are tested in
>> [RFC5471].
>>
>> The following sections are especially noteworthy:
>>
>> . 3.2.1. Transmission of Template with fixed size
>> Information Elements
>>
>> - each data type should be used in at least one test.
>> The new data types specified in Section 4.1. should
>> be included in this test.
>>
>> . 3.2.2. Transmission of Template with variable length
>> Information Elements
>>
>> - this test should be expanded to include Data Records
>> containing variable length basicList,
>> subTemplateList, and subTemplateMultiList Information
>> Elements.
>>
>> . 3.3.1. Enterprise-specific Information Elements
>> - this test should include the export of basicList,
>> subTemplateList, and subTemplateMultiList Information
>> Elements containing Enterprise-specific Information
>> Elements. e.g., see the example in figure B.
>>
>> . 3.3.3. Multiple instances of the same Information Element
>> in one Template
>>
>> - this test should verify that multiple instances of the
>> basicList, subTemplateList and subTemplateMultiList
>> Information Elements are accepted.
>>
>> . 3.5 Stress/Load tests
>>
>> - since the structured data types defined here allow
>> modeling of complex data structures, they may be
>> useful for stress testing both Exporting Processes
>> and Collecting Processes.
>>
>>
>>
>> 9.3. Relationship with Bidirectional Flow Export
>>
>> [RFC5103] describes a method for exporting bidirectional flow
>> information, and defines the biflowDirection Information Element
>> for this purpose.
>>
>> [RFC5103] Biflows may be encoded in a subTemplateList or
>> subTemplateMultiList. The basicList requires recurrence of a
>> single element, so is not suitable for Biflows.
>>
>> Encoding Biflows with subTemplateList or subTemplateMultiList
>> provides a more logical division of the information in both
>> directions, although this encoding incurs a small additional
>> bandwidth penalty.
>>
>> An example of Biflow encoding using Structure Data Information
>> Elements and comparison with the [RFC5103] Biflow encoding is
>> shown in Appendix B.
>>
>>
>> 9.4. Relationship with IPFIX Mediation Function
>>
>> The Structured Data Information Elements would be beneficial for
>> the export of aggregated Data Records in mediation function, as
>> was demonstrated with the example of the aggregated Observation
>> Point in Section 5.3.
>>
>>
>> 10. IANA Considerations
>>
>> This document specifies several new IPFIX abstract data types, a
>> new IPFIX Data Type Semantic, and several new Information
>> Elements.
>>
>> These require the creation of two new IPFIX registries and
>> updating the existing IPFIX Information Element registry as
>> detailed below.
>>
>>
>> 10.1. New Abstract Data Types
>>
>> Section 4.1. of this document specifies several new IPFIX abstract
>> data types. Per Section 6 of the IPFIX information model
>> [RFC5102], new abstract data types can be added to the IPFIX
>> information model. This requires creation of a new IPFIX
>> "abstract data types" registry at
>> http://www.iana.org/assignments/ipfix. This registry should
>> include all the abstract data types from Section 3.1 of [RFC5102].
>>
>> Abstract data types to be added to the IPFIX "abstract data types"
>> registry are listed below.
>>
>>
>> 10.1.1. basicList
>>
>> The type "basicList" represents a list of any Information Element
>> used for single-valued data types.
>>
>>
>> 10.1.2. subTemplateList
>>
>> The type "subTemplateList" represents a list of a structured data
>> type, where the data type of each list element is the same and
>> corresponds with a single Template Record.
>>
>>
>> 10.1.3. subTemplateMultiList
>>
>> The type "subTemplateMultiList" represents a list of structured
>> data types, where the data types of the list elements can be
>> different and correspond with different template definitions.
>>
>>
>> 10.2. New Data Type Semantics
>>
>> Section 4.2. of this document specifies a new IPFIX Data Type
>> Semantic. Per Section 3.2 of the IPFIX information model
>> [RFC5102], new data type semantics can be added to the IPFIX
>> information model. Therefore, the IANA IPFIX
>> informationElementSemantics registry [IANA-IPFIX], which contains
>> all the data type semantics from Section 3.2 of [RFC5102], must be
>> augmented with the "list" value below.
>>
>>
>> 10.2.1. list
>>
>> A list is a structured data type, being composed of a sequence of
>> elements e.g. Information Element, Template Record, etc.
>>
>>
>> 10.3. New Information Elements
>>
>> Section 4.3. of this document specifies several new Information
>> Elements which are to be created in the IPFIX Information Element
>> registry [IANA-IPFIX].
>>
>> New Information Elements to be added to the IPFIX Information
>> Element registry are listed below.
>>
>> EDITOR'S NOTE: the XML specification in Appendix A must be updated
>> with the elementID values allocated below.
>>
>> 10.3.1. basicList
>>
>> Name: basicList
>> Description:
>> Specifies a generic Information Element with a basicList abstract
>> data type. For example, a list of port numbers, a list of
>> interface indexes, etc.
>> Abstract Data Type: basicList
>> Data Type Semantics: list
>> ElementId: XXX (to be specified by IANA)
>> Status: current
>>
>> 10.3.2. subTemplateList
>>
>> Name: subTemplateList
>> Description:
>> Specifies a generic Information Element with a subTemplateList
>> abstract data type.
>> Abstract Data Type: subTemplateList
>> Data Type Semantics: list
>> ElementId: YYY (to be specified by IANA)
>> Status: current
>>
>> 10.3.3. subTemplateMultiList
>>
>> Name: subTemplateMultiList
>> Description:
>> Specifies a generic Information Element with a
>> subTemplateMultiList abstract data type.
>> Abstract Data Type: subTemplateMultiList
>> Data Type Semantics: list
>> ElementId: ZZZ (to be specified by IANA)
>> Status: current
>>
>> 10.4. New Structured Data Semantics
>>
>> Section 4.4. of this document specifies a series of new IPFIX
>> structured data type semantics, which is expressed as an 8-bit
>> value. This requires the creation of a new IPFIX "structured data
>> types semantics" IPFIX subregistry [IANA-IPFIX].
>>
>> Entries may be added to this subregistry subject to a Standards
>> Action [RFC5226]. Initially, this registry should include all the
>> structured data type semantics listed below.
>>
>>
>> 10.4.1. undefined
>>
>> A list is a structured data type, being composed of a sequence of
>> elements e.g. Information Element, Template Record, etc.
>> Value: 0xFF
>> Description: undefined
>> Reference:<this future RFC>
>>
>>
>> 10.4.2. noneOf
>>
>> A list is a structured data type, being composed of a sequence of
>> elements e.g. Information Element, Template Record, etc.
>> Value: 0x00
>> Description: noneOf
>> Reference:<this future RFC>
>>
>>
>> 10.4.3. exactlyOneOf
>>
>> A list is a structured data type, being composed of a sequence of
>> elements e.g. Information Element, Template Record, etc.
>> Value: 0x01
>> Description: exactlyOneOf
>> Reference:<this future RFC>
>>
>>
>> 10.4.4. oneOrMoreOf
>>
>> A list is a structured data type, being composed of a sequence of
>> elements e.g. Information Element, Template Record, etc.
>> Value: 0x02
>> Description: oneOrMoreOf
>> Reference:<this future RFC>
>>
>> 10.4.5. allOf
>>
>> A list is a structured data type, being composed of a sequence of
>> elements e.g. Information Element, Template Record, etc.
>> Value: 0x03
>> Description: allOf
>> Reference:<this future RFC>
>>
>>
>> 10.4.6. ordered
>>
>> A list is a structured data type, being composed of a sequence of
>> elements e.g. Information Element, Template Record, etc.
>> Value: 0x04
>> Description: ordered
>> Reference:<this future RFC>
>>
>>
>> 11. Security Considerations
>>
>> The same security considerations as for the IPFIX Protocol
>> [RFC5101] apply.
>>
>>
>> 12. References
>>
>> 12.1. Normative References
>>
>> [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
>> Requirement Levels, BCP 14, RFC 2119, March 1997.
>>
>> [RFC5101] Claise, B., Ed., "Specification of the IP Flow
>> Information Export (IPFIX) Protocol for the Exchange of
>> IP Traffic Flow Information", RFC 5101, January 2008.
>>
>> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and
>> J. Meyer, "Information Model for IP Flow Information
>> Export", RFC 5102, January 2008.
>>
>> [RFC5226] T. Narten, T., Alverstrand, H. , "Guidelines for
>> Writing an IANA Considerations Section in RFCs",
>> RFC5226, May 2008.
>>
>>
>> 12.2. Informative References
>>
>>
>> [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
>> Requirements for IP Flow Information Export, RFC 3917,
>> October 2004.
>>
>> [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow
>> Export Using IP Flow Information Export (IPFIX)", RFC
>> 5103, January 2008.
>>
>> [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J.
>> Quittek, "Architecture for IP Flow Information Export",
>> RFC 5470, March 2009.
>>
>> [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines
>> for IP Flow Information Export (IPFIX) Testing", RFC
>> 5471, March 2009.
>>
>> [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
>> "IP Flow Information Export (IPFIX) Applicability", RFC
>> 5472, March 2009.
>>
>> [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing
>> Redundancy in IP Flow Information Export (IPFIX) and
>> Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
>>
>> [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S.,
>> and F. Raspall, "Sampling and Filtering Techniques for
>> IP Packet Selection", RFC 5475, March 2009.
>>
>> [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol
>> Specifications", RFC 5476, March 2009.
>>
>> [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and
>> G. Carle, "Information Model for Packet Sampling
>> Exports", RFC 5477, March 2009.
>>
>> [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml
>>
>>
>> 13. Acknowledgement
>>
>> The authors would like to thank Zhipu Jin, Nagaraj Varadharajan,
>> Brian Trammel, and Atsushi Kobayashi for their feedback.
>>
>>
>> 14. Authors' Addresses
>>
>>
>> Benoit Claise
>> Cisco Systems Inc.
>> De Kleetlaan 6a b1
>> Diegem 1813
>> Belgium
>>
>> Phone: +32 2 704 5622
>> EMail: bclaise@cisco.com
>>
>>
>> Gowri Dhandapani
>> Cisco Systems Inc.
>> 13615 Dulles Technology Drive
>> Herndon, Virigina 20171
>> United States
>>
>> Phone: +1 408 853 0480
>> EMail: gowri@cisco.com
>>
>>
>> Stan Yates
>> Cisco Systems Inc.
>> 7100-8 Kit Creek Road
>> PO Box 14987
>> Research Triangle Park
>> North Carolina, 27709-4987
>> United States
>>
>> Phone: +1 919 392 8044
>> EMail: syates@cisco.com
>>
>>
>>
>> Paul Aitken
>> Cisco Systems (Scotland) Ltd.
>> 96 Commercial Quay
>> Commercial Street
>> Edinburgh, EH6 6LX, United Kingdom
>>
>> Phone: +44 131 561 3616
>> EMail: paitken@cisco.com
>>
>>
>>
>> Appendix A. Additions to XML Specification of IPFIX Information
>> Elements and Abstract Data Types
>>
>> This appendix contains additions to the machine-readable
>> description of the IPFIX information model coded in XML in
>> Appendix A and Appendix B in [RFC5102]. Note that this appendix
>> is of informational nature, while the text in section 4.
>> (generated from this appendix) is normative.
>>
>> The following field definitions are appended to the IPFIX
>> information model in Appendix A of [RFC5102].
>>
>> <field name="basicList"
>> dataType="basicList"
>> group="structured-data"
>> dataTypeSemantics="List"
>> elementId="XXX" applicability="all" status="current">
>> <description>
>> <paragraph>
>> Represents a list of zero or more instances of
>> any single Information Element, primarily used for
>> single-valued data types. For example, a list of port
>> numbers, list of interface indexes, list of AS in a
>> BGP AS-PATH, etc.
>> </paragraph>
>> </description>
>> </field>
>>
>> <field name="subTemplateList"
>> dataType="subTemplateList"
>> group="structured-data"
>> dataTypeSemantics="List"
>> elementId="XXX" applicability="all" status="current">
>> <description>
>> <paragraph>
>> Represents a list of zero or more instances of a
>> structured data type, where the data type of each list
>> element is the same and corresponds with a single
>> Template Record. For example, a structured data type
>> composed of multiple pairs of ("MPLS label stack entry
>> position", "MPLS label stack value"), a structured data
>> type composed of performance metrics, a structured data
>> type composed of multiple pairs of IP address, etc.
>> </paragraph>
>> </description>
>> </field>
>>
>> <field name="subTemplateMultiList"
>> dataType="subTemplateMultiList"
>> group="structured-data"
>> dataTypeSemantics="List"
>> elementId="XXX" applicability="all" status="current">
>> <description>
>> <paragraph>
>> Represents a list of zero or more instances of
>> structured data types, where the data type of each list
>> element can be different and corresponds with
>> different template definitions. For example, a
>> structured data type composed of multiple access-list
>> entries, where entries can be composed of different
>> criteria types.
>> </paragraph>
>> </description>
>> </field>
>>
>>
>> The following structured data type semantic definitions are
>> appended to the the IPFIX information model in Appendix A of
>> [RFC5102].
>>
>>
>> <structuredDataTypeSemantics>
>> <structuredDataTypeSemantic name="undefined" value="255">
>> <description>
>> <paragraph>
>> Specifies that the semantic of list elements is not
>> specified, and that, if a semantic exists, then it is up
>> to
>> the Collecting Process to draw its own conclusions. The
>> "undefined" structured data type semantic is the default
>> Structured Data type semantic.
>> </paragraph>
>> </description>
>> </structuredDataTypeSemantic>
>>
>> <structuredDataTypeSemantic name="noneOf" value="0">
>> <description>
>> <paragraph>
>> Specifies that none of the elements are actual
>> properties
>> of the Data Record.
>> </paragraph>
>> </description>
>> </structuredDataTypeSemantic>
>>
>> <structuredDataTypeSemantic name="exactlyOneOf" value="1">
>> <description>
>> <paragraph>
>> Specifies that only a single element from the
>> Structured Data is an actual property of the Data
>> Record. This is equivalent to a logical XOR operation.
>> </paragraph>
>> </description>
>> </structuredDataTypeSemantic>
>>
>> <structuredDataTypeSemantic name="oneOrMoreOf" value="2">
>> <description>
>> <paragraph>
>> Specifies that one or more element(s) from the list in
>> the Structured Data is/are actual propertie(s) of the
>> Data Record. This is equivalent to a logical OR
>> operation.
>> </paragraph>
>> </description>
>> </structuredDataTypeSemantic>
>>
>> <structuredDataTypeSemantic name="allOf" value="3">
>> <description>
>> <paragraph>
>> Specifies that all of the list elements from the
>> Structured Data are actual properties of the Data
>> Record.
>> </paragraph>
>> </description>
>> </structuredDataTypeSemantic>
>>
>> <structuredDataTypeSemantic name="ordered" value="4">
>> <description>
>> <paragraph>
>> Specifies that elements from the list in the
>> Structured Data are ordered.
>> </paragraph>
>> </description>
>> </structuredDataTypeSemantic>
>> </structuredDataTypeSemantics>
>>
>>
>> The following schema definitions are appended to the abstract data
>> types defined in Appendix B of [RFC5102].
>>
>>
>> <simpleType name="dataType">
>> <restriction base="string">
>> <enumeration value="basicList">
>> <annotation>
>> <documentation>
>> Represents a list of zero or more instances of
>> any single Information Element, primarily used for
>> single-valued data types. For example, a list of port
>> numbers, list of interface indexes, list of AS in a
>> BGP AS-PATH, etc.
>> </documentation>
>> </annotation>
>> </enumeration>
>> <enumeration value="subTemplateList">
>> <annotation>
>> <documentation>
>> Represents a list of zero or more instances of a
>> structured data type, where the data type of each list
>> element is the same and corresponds with a single
>> Template Record. For example, a structured data type
>> composed of multiple pairs of ("MPLS label stack entry
>> position", "MPLS label stack value"), a structured
>> data type composed of performance metrics, a
>> structured data type composed of multiple pairs of IP
>> address, etc.
>> </documentation>
>> </annotation>
>> </enumeration>
>> <enumeration value="subTemplateMultiList">
>> <annotation>
>> <documentation>
>> Represents a list of zero or more instances of
>> structured data types, where the data type of each
>> list element can be different and corresponds with
>> different template definitions. For example, a
>> structured data type composed of multiple
>> access-list entries, where entries can be
>> composed of different criteria types.
>> </documentation>
>> </annotation>
>> </enumeration>
>> </restriction>
>> </simpleType>
>>
>> <simpleType name="dataTypeSemantics">
>> <restriction base="string">
>> <enumeration value="List">
>> <annotation>
>> <documentation>
>> Represents an arbitrary-length sequence of structured
>> data elements, either composed of regular Information
>> Elements or composed of data conforming to a Template
>> Record.
>> </documentation>
>> </annotation>
>> </enumeration>
>> </restriction>
>> </simpleType>
>>
>> <complexType name="structuredDataTypeSemantics">
>> <sequence>
>> <element name="structuredDataTypeSemantic"
>> minOccurs="1" maxOccurs="unbounded">
>> <complexType>
>> <sequence>
>> <element name="description" type="text"/>
>> </sequence>
>> <attribute name="name" type="string" use="required"/>
>> <attribute name="value" type="unsignedByte"
>> use="required"/>
>> </complexType>
>> </element>
>> </sequence>
>> </complexType>
>>
>> <element name="structuredDataTypeSemantics"
>> type="structuredDataTypeSemantics">
>> <annotation>
>> <documentation>
>> Structured Data type semantics express the relationship
>> among multiple list elements in a Structured Data
>> Information Element.
>> </documentation>
>> </annotation>
>> </element>
>>
>>
>>
>> Appendix B. Example of Biflow Encoding using Structured Data
>> Information Elements
>>
>> Referring to [RFC5103] figure 1, a Biflow consists of two parts:
>> some "key" fields such as src/dst information (IP addresses,
>> ports), followed by a set of forward/reverse pairs.
>>
>> Then looking at [RFC5103] figure 7, we see that the Reverse PEN
>> is repeated many times to indicate fields which were observed in
>> the reverse direction. Clearly that repetition is wasteful.
> You mean that it is wasteful if such a Template is used in a Structured
> Data Information Element?
> Or in general? In this case, I do not think that the PEN is a problem.
> The Template is exported only once.
Correct. We removed "Clearly that repetition is wasteful. "
>>
>> Looking back at [RFC5103] figure 1, it's clear that the encoding
>> can use a Template Record consisting of the Flow Keys followed
>> by a subTemplateList consisting of two elements: one for the
>> forward direction, the other for the reverse direction.
>>
>> The subTemplateList uses a single Template Record to describe
>> the fields in both lists since they are a set of forward/reverse
>> pairs.
>>
>>
>> Uniflow Uniflow
>> +-------+-------+-----------------+ +-------+-------+-----------------+
>> | src A | dst B | counters/values | | src B | dst A | counters/values |
>> +-------+-------+-----------------+ +-------+-------+-----------------+
>> | | | |
>> V V V V
>> +-------+-------+---------------------+---------------------+
>> | src A | dst B | fwd counters/values | rev counters/values |
>> +-------+-------+---------------------+---------------------+
>> | | |
>> V V V
>> key fields fwd element rev element
>>
>> Figure B0: Using a subTemplateList to represent a Biflow.
> You should show where the subTemplateList is.
Uniflow Uniflow
+-------+-------+-----------------+ +-------+-------+-----------------+
| src A | dst B | counters/values | | src B | dst A | counters/values |
+-------+-------+-----------------+ +-------+-------+-----------------+
| | | |
V V V V
<---------- subTemplateList -------------->
+-------+-------+---------------------+---------------------+
| src A | dst B | fwd counters/values | rev counters/values |
+-------+-------+---------------------+---------------------+
| | |
V V V
key fields fwd element rev element
>>
>> The following example shows the example from Appendix A of
>> [RFC5103] encoded using a subTemplateList:
>>
>>
>> 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 = 24 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 266 | Field Count = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| flowDirection 61 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| flowStartSeconds 150 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| octetTotalCount 85 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| packetTotalCount 86 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure B1: Template for the Biflow Fields
>>
>>
>> 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 = 32 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 267 | Field Count = 6 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceIPv4Address 8 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| destinationIPv4Address 12 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceTransportPort 7 | Field Length = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| destinationTransportPort 11 | Field Length = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| protocolIdentifier 4 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| subTemplateList = YYY | Field Length = 29 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure B2: Template for the Key Fields
>>
>> The Template Record includes a subTemplateList with semantic allOf
>> for encoding the BiFlow fields for the forward and reverse
>> direction. Note that the subTemplateList is encoded using Fixed
>> Length, as shown in the above template definition.
> _f_ixed _l_ength, _T_emplate
done.
>>
>>
>> Also, note that the overall template size is 24 + 32 = 56 octets,
>> compared with 64 octets in the [RFC5103] example - so a small
>> saving is achieved.
> Is the Template length actually relevant? The Template is exported only
> once.
Correct.
>>
>>
>>
>> 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 = 267 | Length = 46 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceIPv4Address = 192.0.2.2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | destinationIPv4Address = 192.0.2.3 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | sourceTransportPort = 32770 | destinationTransportPort = 80 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | protocol = 6 |semantic=allOf | Template ID = 266 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | dir = forward | flowStartSeconds = 2006-02-01 17:00:00 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | octetTotalCount = 18000 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | packetTotalCount = 65 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | dir = reverse | flowStartSeconds = ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 2006-02-01 17:00:01 | octetTotalCount = 128000 ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | packetTotalCount = 110 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure B3: Biflow Data Set Encoded using Structured Data
>>
>>
>> Note that the Data Set length is 46, compared with 41 in RFC5103.
>> The five additional octets are due to the inclusion of the 8-bit
>> semantic, 16-bit Template ID and two, 8-bit direction indicators.
>>
>> Clearly structured data offers an alternative way to encode
>> Biflows. Although this may not be best suited if the number of
>> elements is small as in this example, it does offer a more robust
>> and scalable solution if multiple elements need to be encoded.
> I do not understand. The Data Record will always be larger than in the
> RFC5103 case. So, where is a scalability advantage? And where is a
> robustness advantage? In both cases, the flow information is included in
> one Data Record.
Text changed.
Clearly structured data offers an alternative way to encode
Biflows, without the private Reverse PEN specified in [RFC5103].
>> Appendix C. Encoding IPS Alert using Structured Data Information
>> Elements
>>
>> In this section, an IPS alert example is used to demonstrate how
>> complex data and multiple levels of hierarchy can be encoded using
>> Structured Data Information Elements. Also, this example
>> demonstrates how a basicList of subTemplateLists can be used to
>> represent semantics at multiple levels in the hierarchy.
>>
>> An IPS alert consists of the following mandatory attributes:
>> signatureId, protocolIdentifier and riskRating. It can also
>> contain zero or more participants, each participant can contain
>> zero or more attackers and zero or more targets. An attacker
>> contains the attributes sourceIPv4Address and applicationId, and
>> a target contains the attributes destinationIPv4Address and
>> applicationId.
>>
>> Note that the signatureId and riskRating Information Element
>> fields are created for these examples only; the Field IDs are
>> shown as N/A. The signatureId helps to uniquely identify the IPS
>> signature that triggered the alert. The riskRating identifies the
>> potential risk, on a scale of 0-100 (100 being most serious), of
>> the traffic that triggered the alert.
>>
>> Consider the example described in case study 2 of Section 5.6. The
>> IPS alert contains participants encoded as a subTemplateList with
>> semantic allOf. Each participant uses a basicList of
>> subTemplateLists to represent attackers and targets. For the sake
>> of simplicity, the alert has two participants P1 and P2. In
>> participant P1, attacker A1 or A2 attack target T1. In
>> participant P2, attacker A3 attacks targets T2 and T3.
>>
>> Participant P1:
>>
>> (basicList, allof,
>>
>> (subTemplateList, exactlyOneOf, attacker A1, A2)
>>
>> (subTemplateList, undefined, target T1)
>>
>> )
>>
>> Participant P2:
>>
>> (basicList, allOf,
>>
>> (subTemplateList, undefined, attacker A3,
>> (subTemplateList, allOf, targets T2, T3)
>>
>> )
>>
>> Alert :
>>
>> (subTemplateList, allOf, Participant P1, Participant P2)
>>
>>
>> ------------------------------------------------------------------
>> | | | participant
>> sigId |protocol| risk | attacker | target
>> | Id | Rating | IP | appId | IP | appId
>> ------------------------------------------------------------------
>> 1003 17 10 192.0.2.3 103 192.0.2.103 3001
>> 192.0.2.4 104
>>
>> 192.0.2.5 105 192.0.2.104 4001
>> 192.0.2.105 5001
>> ------------------------------------------------------------------
>>
>> Participant P1 contains:
>> Attacker A1: (IP, appID)=(192.0.2.3, 103)
>> Attacker A2: (IP, appID)=(192.0.2.4, 104)
>> Target T1: (IP, appID)= (192.0.2.103, 3001)
>>
>> Participant P2 contains:
>> Attacker A3: (IP, appID) = (192.0.2.5, 105)
>> Target T2: (IP, appID)= (192.0.2.104, 4001)
>> Target T3: (IP, appID)= (192.0.2.105, 5001)
>>
>>
>> To represent an alert, the following Templates are defined:
>> Template for target (268)
>> Template for attacker (269)
>> Template for participant (270)
>> Template for alert (271)
>>
>> alert (271)
>> | (signatureId)
>> | (protocolIdentifier)
>> | (riskRating)
>> |
>> +------- participant (270)
>> |
>> +------- attacker (269)
>> | (sourceIPv4Address)
>> | (applicationId)
>> |
>> +------- target (268)
>> | (destinationIPv4Address)
>> | (applicationId)
>>
>> Note that the attackers are always composed of a single
>> applicationId, while the targets typically have multiple
>> applicationId, for the sake of simplicity this example shows only
>> one applicationId in the target.
>>
>> Template Record for target, with the Template ID 268:
>>
>> 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 = 16 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 268 | Field Count = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| destinationIPv4Address = 12 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| applicationId = 95 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure C0: Encoding IPS Alert, Template for Target
>>
>>
>> Template Record for attacker, with the Template ID 269:
>>
>> 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 = 16 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 269 | Field Count = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| sourceIPv4Address = 8 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| applicationId = 95 | Field Length = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure C1: Encoding IPS Alert, Template for Attacker
>>
>>
>> Template Record for participant, with the Template ID 270:
>>
>>
>> 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 = 12 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 270 | Field Count = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| basicList = XXX | Field Length = 0xFFFF |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure C2: Encoding IPS Alert, Template for Participant
>>
>>
>> The Template Record for the participant has one basicList
>> Information Element, which is a list of subTemplateLists of
>> attackers and targets.
>>
>> Template Record for IPS alert, with the Template ID 271:
>>
>> 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 = 24 octets |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Template ID = 271 | Field Count = 4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| signatureId = N/A | Field Length = 2 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| protocolIdentifier = 4 | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| riskRating = N/A | Field Length = 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |0| subTemplateList = YYY | Field Length = 0xFFFF |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure C3: Encoding IPS Alert, Template for IPS Alert
>>
>> The subTemplateList in the alert Template Record contains a list
>> of participants.
>>
>> The Length of basicList and subTemplateList are encoded in three
>> bytes even though they may be less than 255 octets.
>>
>>
>> The Data Set is represented as follows:
>>
>> 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 = 271 | Length = 102 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | signatureId = 1003 | protocolId=17 | riskRating=10 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 255 |participant List Length = 91 |semantic=allOf |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | participant Template ID = 270 | 255 | P1 List Len = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 41 | semantic=allOf| P1 List Field ID = YYY |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P1 List Field ID Len = 0xFFFF | 255 |P1 attacker ...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | List Len = 19 |sem=exactlyOne | P1 attacker Template ID = 269 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P1 attacker A1 sourceIPv4Address = 192.0.2.3 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P1 attacker A1 applicationId = 103 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P1 attacker A2 sourceIPv4Address = 192.0.2.4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P1 attacker A2 applicationId = 104 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 255 | P1 target List Len = 11 | sem=undefined |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P1 target Template ID = 268 | P1 target T1 destinationIPv4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... Address = 192.0.2.103 |P1 target T1 applicationId =...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 3001 | 255 | P2 List Len = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 41 | semantic=allOf| P2 List Field ID = YYY |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P2 List Field ID Len = 0xFFFF | 255 |P2 attacker ...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | List Len = 11 | sem=undefined | P2 attacker Template ID = 269 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P2 attacker A3 sourceIPv4Address = 192.0.2.5 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P2 attacker A3 applicationId = 105 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | 255 | P2 target List Len = 19 |semantic=allOf |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | P2 target Template ID = 268 | P2 target T2 destinationIPv4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... Address = 192.0.2.104 |P2 target T2 applicationId =...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 4001 | P2 target T3 destinationIPv4 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... Address = 192.0.2.105 |P2 target T3 applicationId =...|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... 5001 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Figure C4: Encoding IPS Alert, Data Set
>>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Benoit Claise
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Brian Trammell
- [IPFIX] Review: draft-ietf-ipfix-structured-data-… Gerhard Muenz
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Benoit Claise
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Benoit Claise
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Hadriel Kaplan
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Benoit Claise
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Gerhard Muenz
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Benoit Claise
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Gerhard Muenz
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Benoit Claise
- Re: [IPFIX] Review: draft-ietf-ipfix-structured-d… Paul Aitken