RFC 6728
Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols
RFC 6728: Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols 🎀 (Part 1 of 25)
Okay bestie, here's the title block so you know who wrote this. It's an IETF Standards Track doc (ISSN 2070-1721) from October 2012. The authors are G. Muenz from TU Muenchen, and B. Claise and P. Aitken from Cisco Systems, Inc. ✨ The header has no Obsoletes or Updates line, so it doesn't replace or update any earlier RFC. 💅
Abstract
okay so this doc is a data model for IPFIX and PSAMP 💖 It's for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes on IPFIX- and PSAMP-compliant Monitoring Devices, using NETCONF. The model is drawn with UML class diagrams and formally specified in YANG, and the config data itself is encoded in XML. 🦋
Status of This Memo
This is an Internet Standards Track document. 🌸
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741. 🧚
Info about the current status of this doc, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6728. ⭐
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. 💅
This doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust the right to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🙈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . 4
1.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Structure of the Configuration Data Model . . . . . . . . . . 7
3.1. Metering Process Decomposition in Selection Process
and Cache . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. UML Representation . . . . . . . . . . . . . . . . . . . 10
3.3. Exporter Configuration . . . . . . . . . . . . . . . . . 15
3.4. Collector Configuration . . . . . . . . . . . . . . . . . 17
4. Configuration Parameters . . . . . . . . . . . . . . . . . . 18
4.1. ObservationPoint Class . . . . . . . . . . . . . . . . . 18
4.2. SelectionProcess Class . . . . . . . . . . . . . . . . . 20
4.2.1. Selector Class . . . . . . . . . . . . . . . . . . . 21
4.2.2. Sampler Classes . . . . . . . . . . . . . . . . . . . 22
4.2.3. Filter Classes . . . . . . . . . . . . . . . . . . . 23
4.3. Cache Class . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1. ImmediateCache Class . . . . . . . . . . . . . . . . 26
4.3.2. TimeoutCache, NaturalCache, and PermanentCache
Class . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.3. CacheLayout Class . . . . . . . . . . . . . . . . . . 29
4.4. ExportingProcess Class . . . . . . . . . . . . . . . . . 32
4.4.1. SctpExporter Class . . . . . . . . . . . . . . . . . 34
4.4.2. UdpExporter Class . . . . . . . . . . . . . . . . . . 36
4.4.3. TcpExporter Class . . . . . . . . . . . . . . . . . . 37
4.4.4. FileWriter Class . . . . . . . . . . . . . . . . . . 38
4.4.5. Options Class . . . . . . . . . . . . . . . . . . . . 39
4.5. CollectingProcess Class . . . . . . . . . . . . . . . . . 41
4.5.1. SctpCollector Class . . . . . . . . . . . . . . . . . 42
4.5.2. UdpCollector Class . . . . . . . . . . . . . . . . . 43
4.5.3. TcpCollector Class . . . . . . . . . . . . . . . . . 44
4.5.4. FileReader Class . . . . . . . . . . . . . . . . . . 45
4.6. Transport Layer Security Class . . . . . . . . . . . . . 46
4.7. Transport Session Class . . . . . . . . . . . . . . . . . 49
4.8. Template Class . . . . . . . . . . . . . . . . . . . . . 53
5. Adaptation to Device Capabilities . . . . . . . . . . . . . . 54
6. YANG Module of the IPFIX/PSAMP Configuration Data Model . . . 57
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.1. PSAMP Device . . . . . . . . . . . . . . . . . . . . . . 104
7.2. IPFIX Device . . . . . . . . . . . . . . . . . . . . . . 115
7.3. Export of Flow Records and Packet Reports . . . . . . . . 118
7.4. Collector and File Writer . . . . . . . . . . . . . . . . 121
7.5. Deviations . . . . . . . . . . . . . . . . . . . . . . . 122
8. Security Considerations . . . . . . . . . . . . . . . . . . . 122
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 125
11.1. Normative References . . . . . . . . . . . . . . . . . . 125
11.2. Informative References . . . . . . . . . . . . . . . . . 1261. Introduction ✨
Okay so IPFIX- and PSAMP-compliant Monitoring Devices (routers, switches, monitoring probes, Collectors, and so on) have lots of config options 🎀 That lets you tune network monitoring for what you actually care about, like accounting and charging, traffic analysis, performance monitoring, or security monitoring. Using one common vendor-independent config data model makes network management way easier, especially when devices from different implementers or manufacturers are running side by side 💅 On one hand, the model keeps config data for Monitoring Devices in a consistent format. On the other hand, you can use it for both local and remote configuration. 🦋
The whole point of this doc is to specify a vendor-independent config data model covering the commonly available config parameters of Selection Processes, Caches, Exporting Processes, and Collecting Processes 🧚 It also includes common state parameters of a Monitoring Device. The model is defined with UML class diagrams [UML], and the actual config data is encoded in XML [W3C.REC-xml-20081126]. An XML document that conforms to the model holds the config data for one Monitoring Device. 💖
The model is built to work with the NETCONF protocol [RFC6241] so you can configure remote Monitoring Devices 🌸 With NETCONF you can send over a complete set of config data to a Monitoring Device, query its current config and state parameters, and change specific parameter values in an existing config. 🫶
To make sure it's compatible with NETCONF [RFC6241], YANG [RFC6020] is used to formally specify the model 💜 If needed, the YANG spec can be converted into XML Schema language [W3C.REC-xmlschema-0-20041028] or DSDL (Document Schema Definition Languages) [RFC6110], for example with the pyang tool [YANG-WEB]. YANG also gives you ways to adapt the model to device-specific constraints and to augment it with extra device-specific or vendor-specific parameters. 👑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🔥
1.1. IPFIX Documents Overview
The IPFIX protocol [RFC5101] gives network administrators access to IP Flow information 🦋 The architecture for exporting measured IP Flow information from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], following the requirements in [RFC3917]. The IPFIX protocol [RFC5101] also specifies how IPFIX Data Records and Templates get carried over a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Process. ✨
IPFIX has a formal description of IPFIX Information Elements, covering their name, type, and extra semantic info, as specified in [RFC5102] 💅 [RFC6615] specifies the IPFIX Management Information Base, which consists of the IPFIX MIB module and the IPFIX SELECTOR MIB module. Finally, [RFC5472] describes what kinds of applications can use the IPFIX protocol and how they can use the info it provides. It also shows how the IPFIX framework relates to other architectures and frameworks 🧚
Methods for efficient export of bidirectional Flow information and common properties in Data Records are specified in [RFC5103] and [RFC5473], respectively 🌈 [RFC5610] covers exporting extended type info for enterprise-specific Information Elements. And the storage of IPFIX Messages in a file is specified in [RFC5655]. 🎀
1.2. PSAMP Documents Overview
The framework for packet selection and reporting [RFC5474] lets network elements select subsets of packets using statistical and other methods, then export a stream of reports on the selected packets to a Collector 💖 The set of packet selection techniques standardized by PSAMP (Sampling, Filtering, and hashing) is described in [RFC5475]. The PSAMP protocol [RFC5476] specifies how packet info gets exported from a PSAMP Exporting Process to a PSAMP Collector 🦋
Instead of exporting PSAMP Packet Reports, the stream of selected packets can also be the input for generating IPFIX Flow Records 🫶 Like IPFIX, PSAMP has a formal description of its Information Elements, covering their name, type, and extra semantic info. The PSAMP information model is defined in [RFC5477]. And [RFC6727] specifies the PSAMP MIB module as an extension of the IPFIX SELECTOR MIB module defined in [RFC6615]. 👑
2. Terminology ✨
Okay bestie, so this doc borrows its vocab from [RFC5101], [RFC5103], [RFC5655], and [RFC5476]. Every specific term gets a capital first letter when it shows up here, just like in those docs 💅. Here's where the terms you'll see a lot come from:
- Terms from [RFC5101]:
- Collection Process
- Collector
- Data Record
- Exporter
- Flow
- Flow Key
- Flow Record
- Information Element
- IPFIX Device
- IPFIX Message
- Observation Domain
- Observation Point
- (Options) Template
- Terms from [RFC5103]:
- Reverse Information Element
- Terms from [RFC5655]:
- File Reader
- File Writer
- Terms from [RFC5476]:
- Filtering
- Observed Packet Stream
- Packet Report
- PSAMP Device
- Sampling
- Selection Process
- Selection Sequence
- Selection Sequence Report Interpretation
- Selection Sequence Statistics Report Interpretation
- Selection State
- Selector, Primitive Selector, Composite Selector
- Selector Report Interpretation
Now the tea ☕. Metering Process and Exporting Process mean different things in [RFC5101] and [RFC5476], so for this doc we're using the definitions below, which cover both PSAMP Devices and IPFIX Devices 🦋.
Metering Process
The Metering Process makes IPFIX Flow Records or PSAMP Packet Reports, depending on whether it lives in an IPFIX Device or a PSAMP Device 🌸. It takes in packets seen at one or more Observation Points, plus info about how those packets get treated at those points. If it's making IPFIX Flow Records, the Metering Process MUST NOT aggregate packets observed at different Observation Domains in the same Flow. Not allowed, periodt 🙅♀️. Internally, the Metering Process is split into two functional blocks: the Selection Process and the Cache.
Exporting Process
Depending on whether it's part of an IPFIX Device or a PSAMP Device, the Exporting Process sends IPFIX Flow Records or PSAMP Packet Reports to one or more Collecting Processes 📤. Those Flow Records and Packet Reports come from one or more Metering Processes.
Beyond the existing IPFIX and PSAMP vocab, this doc defines a few more terms 💜:
Cache
The Cache is the functional block inside a Metering Process that builds IPFIX Flow Records or PSAMP Packet Reports out of a Selected Packet Stream, following its configuration. If it's building Flow Records, the Cache creates new records, updates existing ones, computes Flow statistics, derives extra Flow properties, detects Flow expiration, passes Flow Records to the Exporting Process, and deletes Flow Records. If it's building Packet Reports, the Cache pulls packet contents and derived packet properties out of the Selected Packet Stream, creates new records, and passes them to the Exporting Process as Packet Reports ✨.
Cache Layout
The Cache Layout is the superset of fields included in the Packet Reports or Flow Records the Cache keeps. Those fields are described by the matching Information Elements. Usually, the biggest possible subset of the specified fields gets filled in for each Packet Report or Flow Record. The more specific rules about which fields have to be included are in Section 4.3.3 🎀.
Monitoring Device
A Monitoring Device implements at least one of the functional blocks defined for IPFIX or PSAMP. The term covers Exporters, Collectors, IPFIX Devices, and PSAMP Devices, so it's basically the umbrella term 🧚.
Selected Packet Stream
The Selected Packet Stream is the full set of packets picked by a Selection Process 🌈.
3. Structure of the Configuration Data Model 🎀
Here's the big picture 🗺️. The IPFIX reference model in [RFC5470] describes Metering Processes, Exporting Processes, and Collecting Processes as functional blocks of IPFIX Devices. The PSAMP framework [RFC5474] gives the matching info for PSAMP Devices, and it brings in the Selection Process as a functional block inside Metering Processes. Section 2 of the document defines the Cache as another functional block inside Metering Processes. More on how the Selection Process and Cache relate is in Section 3.1. IPFIX File Reader and File Writer are defined as specific kinds of Exporting and Collecting Processes in [RFC5655] 📂.
Monitoring Device implementations usually keep their various functional blocks separate, though they don't always implement every one of them 🤷♀️. They also offer lots of config options, and some of those are marked as mandatory by the IPFIX protocol [RFC5101] or the PSAMP protocol [RFC5476] 🔧. The configuration data model lets you set commonly available parameters for Selection Processes, Caches, Exporting Processes, and Collecting Processes. It also lets you specify how functional blocks are put together inside a Monitoring Device configuration, and how they link up with Observation Points 🔗.
The parameters in this model are based on configuration issues discussed in the IPFIX and PSAMP documents [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475]. The structure and content of the IPFIX MIB module [RFC6615] and the PSAMP MIB module [RFC6727] were also taken into account 👀. Keeping the configuration data model consistent with the IPFIX and PSAMP MIB modules is an intentional goal, so parameters are named after their corresponding managed objects. A few IPFIX MIB objects that hold state data were adopted as state parameters in the configuration data model. State parameters can't be configured, but a network manager can query their values from the Monitoring Device 📊.
Section 3.2 explains how UML class diagrams are used to show the structure of the configuration data model 🖼️. After that, Section 3.3 and Section 3.4 cover the class diagrams for configuring Exporters and Collectors, respectively. Each class has specific configuration parameters, and those are spelled out in Section 4. Section 5 is a short intro to YANG concepts that let the configuration data model adapt to what a device can do 🧩. The formal YANG definition of the model is in Section 6, and Section 7 shows the model in use with example XML configurations 💻.
3.1. Metering Process Decomposition in Selection Process and Cache 🧩
In a Monitoring Device, the Metering Process is usually split into two halves 🍰. Packet Sampling and Filtering are done by Selection Processes, and the maintenance of Flow Records and Packet Reports is done by a Cache. Figure 1 shows this split using a basic Metering Process as the example.
+-----------------------------------+
| Metering Process |
| +-----------+ Selected |
Observed | | Selection | Packet +-------+ | Stream of
Packet -->| Process |---------->| Cache |--> Flow Records or
Stream | +-----------+ Stream +-------+ | Packet Reports
+-----------------------------------+Figure 1: Selection Process and Cache forming a Metering Process
The configuration data model keeps Selection Processes and Caches separate so you can configure and combine these blocks flexibly 🦋. As defined in [RFC5476], a Selection Process takes an Observed Packet Stream as input and selects a subset of it as output, which is the Selected Packet Stream. What the Selection Process does to a single packet is defined by either one Selector (called a Primitive Selector) or an ordered combo of several Selectors (called a Composite Selector). The Cache builds Flow Records or Packet Reports from the Selected Packet Stream, depending on how it's configured 🌸.
The configuration data model doesn't let you configure a Metering Process without a Selection Process sitting in front of the Cache 🙅♀️. If every packet in the Observed Packet Stream should be selected and passed to the Cache with no Filtering or Sampling, you still need a Selection Process configured with a Selector that selects all packets (the "SelectAll" class in Section 4.2.1).
The model also lets you configure a Selection Process that takes packets from multiple Observation Points as input. In that case, the Observed Packet Streams from each Observation Point are handled in independent Selection Sequences. As specified in [RFC5476], a separate set of Selector instances has to be kept for each Selection Sequence, so the Selection States and statistics stay separate 🧠.
With this model, you can also configure a Metering Process with more than one Selection Process whose output goes into a single Cache. Figure 2 shows that setup 💖.
+-------------------------------------+
| Metering Process |
| +-----------+ Selected |
Observed | | Selection | Packet |
Packet -->| Process |----------+ +-------+ |
Stream | +-----------+ Stream +->| | | Stream of
| ... | Cache |--> Flow Records or
| +-----------+ Selected +->| | | Packet Reports
Observed | | Selection | Packet | +-------+ |
Packet -->| Process |----------+ |
Stream | +-----------+ Stream |
+-------------------------------------+Figure 2: Metering Process with multiple Selection Processes
The Observed Packet Streams going into a Metering Process may come from Observation Points that belong to different Observation Domains 🌍. But by the definition of Observation Domain (see [RFC5101]), a Cache MUST NOT aggregate packets observed at different Observation Domains in the same Flow. So if the Cache is set up to generate Flow Records, it has to tell packets apart by their Observation Domains 🔍.
3.2. UML Representation 📐
We use UML class diagrams [UML] to explain the structure of the configuration data model 🎨. The classes' attributes are the configuration or state parameters. The configuration and state parameters for a given Monitoring Device are represented as objects of these classes, encoded in XML 💅.
Okay so, bestie, Figure 3 is the UML diagram for the SctpExporter class 🦋 It's the one specified in more detail in Section 4.4.1, and it's giving main character energy 💅
+------------------------------+
| SctpExporter |
+------------------------------+ 0..1 +------------------------+
| name |<>-------| TransportLayerSecurity |
| ipfixVersion = 10 | +------------------------+
| sourceIPAddress[0..*] |
| destinationIPAddress[1..*] | 0..1 +------------------------+
| destinationPort = 4739|4740 |<>-------| TransportSession |
| ifName/ifIndex[0..1] | +------------------------+
| sendBufferSize {opt.} |
| rateLimit[0..1] |
| timedReliability = 0 |
+------------------------------+
Figure 3: UML example: SctpExporter classThe top box holds the class name ✨ and the bottom box lists the attributes 📝 Every attribute lines up with a parameter in the configuration data model, so it's basically a cheat sheet 🌸
Behind an attribute's name, you might see a multiplicity indicator in brackets (aka between "[" and "]") 🎀 An attribute marked "[0..1]" is an OPTIONAL configuration parameter, which means it only shows up in the configuration data if the user actually sets it 🙈 The absence of an OPTIONAL parameter usually means something specific. For example, if you don't configure rateLimit on an SctpExporter object, no rate limiting gets applied to the exported data. Lowkey iconic 💀 In YANG, an OPTIONAL parameter is a "leaf" without a "mandatory true" substatement, and the "description" substatement spells out what happens when the parameter isn't set 🧚
The "[0..]" indicator means the parameter is OPTIONAL and MAY be configured multiple times with different values 💜 In the example, you can give a multihomed Exporting Process several source IP addresses (sourceIPAddress) 🌈 In YANG, a "[0..]" attribute turns into a "leaf-list".
The "[1..*]" indicator means the parameter MUST be configured at least once, and it MAY be configured multiple times with different values 😭 In the example, you need one or more destination IP addresses (destinationIPAddress) so the export knows where to go 🍓 In YANG, that's a "leaf-list" with a "min-elements 1" substatement. Also, attributes without this indicator MUST NOT appear more than once in each object of the class. No doubles, bestie 🙅♀️
Attributes without a multiplicity indicator can have a default value, shown after the equality symbol ("="). If a default exists, the user doesn't have to configure it explicitly 🫶 If the user doesn't configure the parameter, the Monitoring Device MUST use the specified default value for it. In the example, IPFIX version 10 gets used unless you configure a different ipfixVersion 🔥 In YANG, an attribute with a default becomes a "leaf" with a "default" substatement.
The destinationPort attribute has two default values, which is so extra 👑 They're the registered ports for IPFIX with and without transport layer security (DTLS or TLS), which are 4740 and 4739, respectively. The UML diagram separates the two defaults with a vertical bar ("|"). YANG can't formally express these conditional default alternatives, so they're described in the "description" substatement of the "leaf" instead 🌸
Other attribute properties go in braces (between "{" and "}") 💅 An attribute marked "{opt.}", like sendBufferSize in the SctpExporter class, is a parameter that MAY be configured by the user. If the user doesn't set it, the Monitoring Device MUST set an appropriate value for it at configuration time. So the parameter always exists in the configuration data, but the user isn't required to configure it 🎀 The device could use a static device-specific default, but it doesn't have to. That's why the user MUST NOT expect the device to always pick the same value for the same parameter 🙈 Whether the value was configured by the user or set by the device, the parameter value MUST NOT be changed by the device after configuration 🔒 YANG can't express this behavior formally, so it's written in the "description" substatement of the "leaf" 📝
A parameter's availability can depend on another parameter's value. The UML diagram shows these restrictions as attribute properties (for example, "{SCTP only}"). The given example doesn't include any of them. In YANG, availability is formally restricted with the "when" substatement of the "leaf" 🦋
Another property, not shown in the example, is "{readOnly}". It marks state parameters that can't be configured. In YANG, that's the "config false" substatement 🌷
Attributes with no multiplicity indicator, no default value, and no "{readOnly}" property are mandatory configuration parameters 😤 These MUST be configured by the user, unless an attribute property says the parameter isn't available. In YANG, a mandatory parameter is a "leaf" with a "mandatory true" substatement. In the example, the user MUST configure the name parameter 💖
If some parameters are related, it makes sense to group them into a subclass 🧩 This is especially useful when different subclasses represent choices between different parameter sets, or when a subclass's parameters can show up multiple times. For example, the SctpExporter class MAY contain the parameters of the TransportLayerSecurity subclass ✨
An object of a class is encoded as an XML element. To tell classes and objects apart, class names start with an uppercase character, while the matching XML elements start with a lowercase one 🌈 The parameters show up as XML elements nested inside the object's element. In XML, parameters can appear in any order, and they don't have to follow the order of the UML class diagram. Unless stated otherwise, the order doesn't mean anything 🙌 For example, an object of the SctpExporter class looks like one occurrence of this:
<sctpExporter>
<name>my-sctp-export</name>
...
</sctpExporter>There are several ways objects of classes can relate to each other 🦋 In this document we use two types of relationship: aggregation and unidirectional association. UML class diagrams show them with two different arrow types, as in Figure 4.
+---+ 0..* +---+ +---+ 0..* 1 +---+
| A |<>------| B | | A |-------->| B |
+---+ +---+ +---+ +---+
(a) Aggregation (b) Unidirectional association
Figure 4: Class relationships in UML class diagramsAggregation means one object is part of another 🧸 In Figure 4 (a), an object of class B is part of an object of class A. In XML, that's nested elements:
<a>
<b>
...
</b>
...
</a>In the example, the TransportLayerSecurity and TransportSession objects show up as nested XML elements <transportLayerSecurity> and <transportSession> inside the SctpExporter object <sctpExporter> 🎀
A unidirectional association is a reference to an object 🏹 In Figure 4(b), an object of class A holds a reference to an object of class B. In XML, that means separate elements that aren't nested. To tell different class B objects apart, class B needs a key 🔑 In the configuration data model, keys are string parameters called "name", which map to <name> XML elements. The names MUST be unique within the given XML subtree. A reference to a specific class B object is encoded with an XML element <b> that contains the object's name. If an object of class A refers to the object of class B named "foo", it looks like this:
<a>
...
<b>foo</b>
...
</a>
<b>
<name>foo</name>
...
</b>In Figure 4, the numbers show the multiplicity:
"1": one only
"0..*": zero or more
"1..*": one or moreFor aggregation, the multiplicity tells you how many objects of one class can be included in one object of the other class. In Figure 4(a), an object of class A can contain any number of class B objects 🧺 For unidirectional association, the multiplicity at the arrowhead says how many objects of a class can be referred to. The multiplicity at the arrow tail says how many different objects of one class can refer to a single object of the other class. In Figure 4(b), an object of class A refers to a single object of class B. One class B object can be referred to by any number of class A objects 🌟
Classes that are referenced in UML associations are similar to classes in aggregation relationships with a multiplicity greater than one. Those classes that hold configuration parameters must have a key, and that goes for both situations 🔐 The key is needed because every configuration parameter has to be addressable so it can be manipulated or deleted. The key values MUST be unique in the given XML subtree, meaning unique within the aggregating object. So if class B in Figure 4(a) holds a configuration parameter, all of the class B objects belonging to the same class A object need different key values. Again, the key shows up as an attribute called "name" in the relevant classes 💜
A class that holds state parameters but no configuration parameters doesn't need a key. The Template class (see Section 4.8) is one example. That's because state parameters can't be manipulated or deleted, so they don't need to be addressable 🫧
Keys have to be used this way because YANG [RFC6020] requires them, and it mandates a key for elements that appear in a list of configuration data 📜
The configuration data model for IPFIX and PSAMP uses unidirectional associations to define the data flow between functional blocks 🌊 For example, if a Selection Process's output gets processed by a Cache, that's an object of the SelectionProcess class containing a reference to an object of the Cache class. The model doesn't require such a reference for every functional block that has output. If the reference is missing, the output is dropped without any further processing. Such configurations are incomplete, but we don't consider them invalid, since they can happen temporarily when a Monitoring Device is configured in multiple steps. It can also be useful to pre-configure certain functions of a Monitoring Device so you can switch to a new configuration more quickly ⚡
3.3. Exporter Configuration
okay so this is where we set up the Exporter 🎀 Figure 5 shows the main classes that are involved in configuring an IPFIX or PSAMP Exporter. Here's the quick tea on each one:
- ObservationPoint: this is the spot (an interface or a linecard on the Monitoring Device) where packets get captured for traffic measurements 👀 One ObservationPoint can be linked to one or more SelectionProcess objects, which process the observed packets in parallel. ngl, if an ObservationPoint has no references to any SelectionProcess objects, its captured packets just get ignored by every Metering Process 💀
- SelectionProcess: this class holds the config and state parameters for a Selection Process 💖 It can be made of a single Selector (a Primitive Selector) or a whole sequence of them (a Composite Selector) 🧚 It picks packets from one or more Observed Packet Streams, and each stream comes from a different Observation Point. So a SelectionProcess object MAY be referred to from one or more ObservationPoint objects 💅 A Selection Process MAY also pass the Selected Packet Stream to a Cache. The SelectionProcess class has a reference to a Cache object for that. If there's no Cache reference, the selected packets don't get counted in any Packet Report or Flow Record 😭
- Cache: this one has the config and state parameters for a Cache 🌸 A Cache can take the output of one or more Selection Processes and keep the corresponding Packet Reports or Flow Records. That's why an object of the Cache class MAY be referred to from multiple SelectionProcess objects. The Cache config covers the size of the Cache, the Cache Layout, and expiration parameters if applicable. It also decides whether Packet Reports or Flow Records get generated 🦋 A Cache MAY pass its output to one or more Exporting Processes, so the Cache class lets you reference one or more ExportingProcess objects. If a Cache doesn't reference any ExportingProcess object, the Cache output just gets dropped 💀
- ExportingProcess: this class has the config and state parameters for an Exporting Process 🌈 It includes various transport-protocol-specific parameters and the export destinations. An object of the ExportingProcess class MAY be referred to from multiple objects of the Cache class. Also, an Exporting Process MAY be configured as a File Writer according to [RFC5655] 📂
+------------------+
| ObservationPoint |
+------------------+
0..* |
|
0..* V
+------------------+
| SelectionProcess |
+------------------+
0..* |
|
0..1 V
+------------------+
| Cache |
+------------------+
0..* |
|
0..* V
+------------------+
| ExportingProcess |
+------------------+
Figure 5: Class diagram of Exporter configuration3.4. Collector Configuration
Figure 6 shows the main classes that are involved in configuring a Collector 🫶 A CollectingProcess object specifies the local IP addresses, transport protocols, and port numbers of a Collecting Process. Alternatively, the Collecting Process MAY be configured as a File Reader according to [RFC5655] ✨
A CollectingProcess object may refer to one or more ExportingProcess objects that configure Exporting Processes which reexport the received data. For example, an Exporting Process can be set up as a File Writer so it saves the received IPFIX Messages in a file 🎀
+-------------------+
| CollectingProcess |
+-------------------+
0..* |
|
0..* V
+-------------------+
| ExportingProcess |
+-------------------+
Figure 6: Class diagram of Collector configuration4. Configuration Parameters 🍓
This section spells out the configuration and state parameters of the configuration data model, separately for each class 💜
4.1. ObservationPoint Class
+-------------------------------+
| ObservationPoint |
+-------------------------------+
| name |
| observationPointId {readOnly} |
| observationDomainId | 0..*
| ifName[0..*] |-------------+
| ifIndex[0..*] | | 0..*
| entPhysicalName[0..*] | V
| entPhysicalIndex[0..*] | +------------------+
| direction = "both" | | SelectionProcess |
+-------------------------------+ +------------------+
Figure 7: ObservationPoint classFigure 7 shows the ObservationPoint class, which specifies an Observation Point of the Monitoring Device 👀
As defined in [RFC5101], an Observation Point can be any location where packets are observed. A Monitoring Device can have more than one of these locations, and each ObservationPoint instance says which location it's tied to. To do that, interfaces and physical entities are identified by their names. You can also use index values from the ifTable (IF-MIB module [RFC2863]) or the entPhysicalTable (ENTITY-MIB module [RFC4133]) as identifiers. Heads up though, indices SHOULD only be used as identifiers if an SNMP agent on the same Monitoring Device enables access to the corresponding MIB tables 🙈
By its definition in [RFC5101], an Observation Point may be associated with a set of interfaces. So the configuration data model lets you configure multiple interfaces and physical entities for a single Observation Point 🧚
The Observation Point ID (the value of the Information Element observationPointId [IANA-IPFIX]) is assigned by the Monitoring Device. It shows up as a state parameter in the ObservationPoint class 💅
The configuration parameters of the Observation Point are:
observationDomainId: this defines the identifier of the Observation Domain that the Observation Point belongs to. Observation Points configured with the same Observation Domain ID belong to the same Observation Domain. Note that this parameter corresponds toipfixObservationPointObservationDomainIdin the IPFIX MIB module [RFC6615] 🌸ifName/ifIndex/entPhysicalName/entPhysicalIndex: these parameters identify the interfaces and physical entities (e.g., linecards) that are on the Monitoring Device and associated with the given Observation Point 🦋- An interface is identified either by its name (
ifName) or by theifIndexvalue of the corresponding object in the IF-MIB module [RFC2863].ifIndexSHOULD only be used if an SNMP agent enables access to the ifTable. - Likewise, a physical entity is identified either by its name (
entPhysicalName) or by theentPhysicalIndexvalue of the corresponding object in the ENTITY-MIB module [RFC4133].entPhysicalIndexSHOULD only be used if an SNMP agent enables access to the entPhysicalTable. - Note that the parameters
ifIndexandentPhysicalIndexcorrespond toipfixObservationPointPhysicalInterfaceandipfixObservationPointPhysicalEntityin the IPFIX MIB module [RFC6615] 💖
- An interface is identified either by its name (
direction: this says whether ingress traffic, egress traffic, or both get captured, using the values"ingress","egress", and"both"respectively 🌈 If it's not configured, ingress and egress traffic both get captured (the default is"both"). If it doesn't apply (like on a sniffing interface in promiscuous mode), the value of this parameter is ignored ✨
An ObservationPoint object MAY refer to one or more SelectionProcess objects configuring Selection Processes that process the observed packets in parallel 👑
4.2. SelectionProcess Class
+------------------+
| SelectionProcess |
+------------------+ 1..* +----------+
| name |<>------| Selector |
| | +----------+
| |
| | 0..* +--------------------------------+
| |<>------| SelectionSequence |
| | +--------------------------------+
| | | observationDomainId {readOnly} |
| | | selectionSequenceId {readOnly} |
| | +--------------------------------+
| |
| | 0..* 0..1 +-------+
| |----------->| Cache |
+------------------+ +-------+
Figure 8: SelectionProcess classFigure 8 shows the SelectionProcess class 🎀 It holds the config and state parameters of a Selection Process that selects packets from one or more Observed Packet Streams and spits out a Selected Packet Stream as its output. A non-empty ordered list defines a sequence of Selectors, and the actions defined by those Selectors get applied to the incoming packet stream in the specified order 💅
If the Selection Process receives packets from multiple Observation Points, the Observed Packet Streams need to be processed independently in separate Selection Sequences. Each Selection Sequence is identified by a Selection Sequence ID that's unique within the Observation Domain the Observation Point belongs to (see [RFC5477]). Selection Sequence IDs get assigned by the Monitoring Device. As state parameters, the SelectionProcess class contains a list of (observationDomainId, selectionSequenceId) tuples that specify the assigned Selection Sequence IDs and their corresponding Observation Domain IDs 🧚 With this info, you can associate Selection Sequence (Statistics) Report Interpretations exported according to the PSAMP protocol specification [RFC5476] with the matching object of the SelectionProcess class 🦋
A SelectionProcess object MAY include a reference to an object of the Cache class to generate Packet Reports or Flow Records from the Selected Packet Stream 🔥
4.2.1. Selector Class ✨
+--------------------------------------+
| Selector |
+--------------------------------------+ 1 +-----------------+
| name |<>------+ SelectAll/ |
| packetsObserved {readOnly} | | SampCountBased/ |
| packetsDropped {readOnly} | | SampTimeBased/ |
| selectorDiscontinuityTime {readOnly} | | SampRandOutOfN/ |
| | | SampUniProb/ |
| | | FilterMatch/ |
| | | FilterHash/ |
+--------------------------------------+ +-----------------+
Figure 9: Selector classokay so the Selector class in Figure 9 is where a Selector keeps its configuration and state parameters 💅 Standardized PSAMP Sampling and Filtering methods are described in [RFC5475], and their configuration parameters live in the classes SampCountBased, SampTimeBased, SampRandOutOfN, SampUniProb, FilterMatch, and FilterHash 🎀 There's also the SelectAll class, which has no parameters at all and is used for a Selector that selects every packet ✨ The Selector class includes exactly one of these sampler and filter classes, depending on which method is applied. no cap, it's giving very "pick one and only one" energy 🦋
As for the state parameters, the Selector class holds the Selector statistics packetsObserved and packetsDropped, plus selectorDiscontinuityTime. These correspond to the IPFIX MIB module objects ipfixSelectionProcessStatsPacketsObserved, ipfixSelectionProcessStatsPacketsDropped, and ipfixSelectionProcessStatsDiscontinuityTime, respectively [RFC6615] 📊
packetsObserved: This is the total number of packets observed at the input of the Selector. If this is the first Selector in the Selection Process, the counter corresponds to the total number of packets in all Observed Packet Streams at the input of the Selection Process. Otherwise, the counter corresponds to the total number of packets at the output of the preceding Selector. Discontinuities in this counter can happen at re-initialization of the management system, and at other times as indicated by selectorDiscontinuityTime 🌸
packetsDropped: This is the total number of packets discarded by the Selector. Discontinuities in this counter can happen at re-initialization of the management system, and at other times as indicated by selectorDiscontinuityTime 🙈
selectorDiscontinuityTime: This is the timestamp of the most recent occasion at which one or more of the Selector counters suffered a discontinuity. Unlike ipfixSelectionProcessStatsDiscontinuityTime, this time is absolute and not relative to sysUpTime ⏰
Note:packetsObservedandpacketsDroppedare aggregate statistics calculated over all Selection Sequences of the Selection Process. This is different from the counter values in the Selection Sequence Statistics Report Interpretation [RFC5476], which relate to a single Selection Sequence only. Don't mix them up, bestie 💀
4.2.2. Sampler Classes
+----------------+ +----------------+ +----------------+
| SampCountBased | | SampTimeBased | | SampRandOutOfN |
+----------------+ +----------------+ +----------------+
| packetInterval | | timeInterval | | population |
| packetSpace | | timeSpace | | size |
+----------------+ +----------------+ +----------------+
+----------------+
| SampUniProb |
+----------------+
| probability |
+----------------+
Figure 10: Sampler classesThe Sampler classes in Figure 10 hold the configuration parameters for specific Sampling algorithms, and they're giving pure organization queen energy 👑
packetInterval, packetSpace: For systematic count-based Sampling, packetInterval defines the number of packets that are consecutively sampled between gaps of length packetSpace. These parameters correspond to the Information Elements samplingPacketInterval and samplingPacketSpace [RFC5477], as well as to the PSAMP MIB objects psampSampCountBasedInterval and psampSampCountBasedSpace [RFC6727] 🍓
timeInterval, timeSpace: For systematic time-based Sampling, timeInterval defines the time interval during which all arriving packets are sampled. timeSpace is the gap between two Sampling intervals. These parameters correspond to the Information Elements samplingTimeInterval and samplingTimeSpace [RFC5477], as well as to the PSAMP MIB objects psampSampTimeBasedInterval and psampSampTimeBasedSpace [RFC6727]. The unit is microseconds ⏱️
size, population: For n-out-of-N random Sampling, size defines the number of elements taken from the parent population. population defines the number of elements in the parent population. These parameters correspond to the Information Elements samplingSize and samplingPopulation [RFC5477], as well as to the PSAMP MIB objects psampSampRandOutOfNSize and psampSampRandOutOfNPopulation [RFC6727] 🎲
probability: For uniform probabilistic Sampling, probability defines the Sampling probability. The probability is expressed as a value between 0 and 1. This parameter corresponds to the Information Element samplingProbability [RFC5477], as well as to the PSAMP MIB object psampSampUniProbProbability [RFC6727] 🌈
4.2.3. Filter Classes
+---------------------------+
| FilterMatch |
+---------------------------+
| ieId/ieName |
| ieEnterpriseNumber = 0 |
| value |
+---------------------------+
+---------------------------+
| FilterHash |
+---------------------------+ 1..* +---------------+
| hashFunction = "BOB" |<>-------| SelectedRange |
| initializerValue[0..1] | +---------------+
| ipPayloadOffset = 0 | | name |
| ipPayloadSize = 8 | | min |
| digestOutput = "false" | | max |
| outputRangeMin {readOnly} | +---------------+
| outputRangeMax {readOnly} |
+---------------------------+
Figure 11: Filter classesThe Filter classes in Figure 11 contain the configuration parameters of specific Filtering methods 🧚 Let's go through them.
For property match Filtering, the configuration parameters are:
ieId, ieName, ieEnterpriseNumber: The property to be matched is specified by either ieId or ieName, which give the identifier or name of the Information Element, respectively. If ieEnterpriseNumber is zero (which is the default), this Information Element is registered in the IANA registry of IPFIX Information Elements [IANA-IPFIX]. A non-zero value of ieEnterpriseNumber specifies an enterprise-specific Information Element [IANA-ENTERPRISE-NUMBERS] 🏢
value: The matching value 🎯
For hash-based Filtering, the configuration and state parameters are:
hashFunction: The hash function to be used. The following parameter values are defined by the configuration data model:
BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2IPSX: IP Shift-XOR (IPSX) Hash Function as specified in [RFC5475], Appendix A.1CRC: CRC-32 function as specified in [RFC1141]
The default value is "BOB". This parameter corresponds to the PSAMP MIB object psampFiltHashFunction [RFC6727] 🔮
initializerValue: The initializer value for the hash function. This parameter corresponds to the Information Element hashInitialiserValue [RFC5477], as well as to the PSAMP MIB object psampFiltHashInitializerValue [RFC6727]. If it's not configured by the user, the Monitoring Device arbitrarily chooses an initializer value 🎲
ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize configure the offset and the size of the payload section used as input to the hash function. The default values are 0 and 8, respectively, corresponding to the minimum configurable values according to [RFC5476], Section 6.5.2.6. These parameters correspond to the Information Elements hashIPPayloadOffset and hashIPPayloadSize [RFC5477], as well as to the PSAMP MIB objects psampFiltHashIpPayloadOffset and psampFiltHashIpPayloadSize [RFC6727] 📦
digestOutput: digestOutput enables or disables the inclusion of the packet digest in the resulting PSAMP Packet Report. This requires that the Cache Layout of the Cache generating the Packet Reports includes a digestHashValue field. This parameter corresponds to the Information Element hashDigestOutput [RFC5477] 🫶
outputRangeMin, outputRangeMax: The values of these two state parameters are the beginning and end of the hash function's potential output range. These parameters correspond to the Information Elements hashOutputRangeMin and hashOutputRangeMax [RFC5477], as well as to the PSAMP MIB objects psampFiltHashOutputRangeMin and psampFiltHashOutputRangeMax [RFC6727] 📈
One or more ranges of matching hash values are defined by the min and max parameters of the SelectedRange subclass. These parameters correspond to the Information Elements hashSelectedRangeMin and hashSelectedRangeMax [RFC5477], as well as to the PSAMP MIB objects psampFiltHashSelectedRangeMin and psampFiltHashSelectedRangeMax [RFC6727] 🌸
4.3. Cache Class ✨
okay bestie, the Cache class is where all the config and state parameters for a Cache live 🧚 Figure 12 gives you the whole picture:
+-----------------------------------+
| Cache |
+-----------------------------------+ 1 +------------------+
| name |<>--------| immediateCache/ |
| meteringProcessId {readOnly} | | timeoutCache/ |
| dataRecords {readOnly} | | naturalCache/ |
| cacheDiscontinuityTime {readOnly} | | permanentCache |
| | +------------------+
| |
| | 0..* +------------------+
| |--------->| ExportingProcess |
+-----------------------------------+ +------------------+Figure 12: Cache class
Most of these parameters depend on the type of Cache, so they live in the subclasses immediateCache, timeoutCache, naturalCache, and permanentCache, which we'll get to in Sections 4.3.1 and 4.3.2 💜. The following three state parameters are shared by all Caches, so they hang out in the Cache class itself:
meteringProcessId: The identifier of the Metering Process the Cache belongs to. This one lines up with the Information Element meteringProcessId [IANA-IPFIX] 🎀. Having it around helps match up Metering Process (Reliability) Statistics exported according to the IPFIX protocol specification [RFC5101] with the matching object of the MeteringProcess class 💅.
dataRecords: The number of Data Records generated by this Cache. The value of this counter can jump around (a discontinuity) when the management system gets re-initialized, and at other times too, as shown by the value of cacheDiscontinuityTime 🌸. Note that this parameter corresponds to ipfixMeteringProcessDataRecords in the IPFIX MIB module [RFC6615].
cacheDiscontinuityTime: Timestamp of the most recent occasion at which dataRecords suffered a discontinuity. Unlike ipfixMeteringProcessDiscontinuityTime, this time is absolute and not relative to sysUpTime ⏰. Note that this parameter functionally corresponds to ipfixMeteringProcessDiscontinuityTime in the IPFIX MIB module [RFC6615].
A Cache object MAY refer to one or more ExportingProcess objects, each configuring a different Exporting Process 🦋.
4.3.1. ImmediateCache Class
+-------------------------------+
| ImmediateCache |
+-------------------------------+ 1 +-------------+
| |<>-------| CacheLayout |
+-------------------------------+ +-------------+Figure 13: ImmediateCache class
The ImmediateCache class in Figure 13 is used to configure a Cache that generates a PSAMP Packet Report for each packet at its input 📦. The fields in the generated Data Records are defined in an object of the CacheLayout class, which is defined below in Section 4.3.3 🫶.
4.3.2. TimeoutCache, NaturalCache, and PermanentCache Class
+-------------------------------+
| TimeoutCache |
+-------------------------------+ 1 +-------------+
| maxFlows {opt.} |<>-------| CacheLayout |
| activeTimeout {opt.} | +-------------+
| idleTimeout {opt.} |
| activeFlows {readOnly} |
| unusedCacheEntries {readOnly} |
+-------------------------------+
+-------------------------------+
| NaturalCache |
+-------------------------------+ 1 +-------------+
| maxFlows {opt.} |<>-------| CacheLayout |
| activeTimeout {opt.} | +-------------+
| idleTimeout {opt.} |
| activeFlows {readOnly} |
| unusedCacheEntries {readOnly} |
+-------------------------------+
+-------------------------------+
| PermanentCache |
+-------------------------------+ 1 +-------------+
| maxFlows {opt.} |<>-------| CacheLayout |
| exportInterval {opt.} | +-------------+
| activeFlows {readOnly} |
| unusedCacheEntries {readOnly} |
+-------------------------------+Figure 14: TimeoutCache, NaturalCache, and PermanentCache class
Figure 14 shows the TimeoutCache, NaturalCache, and PermanentCache classes 👑. These are used to configure a Cache that aggregates the packets at its input and generates IPFIX Flow Records. The three classes differ in when Flows expire:
TimeoutCache: Flows expire after active or idle timeout.NaturalCache: Flows expire after active or idle timeout, or on natural termination (e.g., TCP FIN or TCP RST) of the Flow.PermanentCache: Flows never expire, but are periodically exported with the interval set byexportInterval.
The following configuration and state parameters are shared by all three classes:
maxFlows: This parameter configures the maximum number of entries in the Cache, which is the maximum number of Flows that can be measured at the same time 🧁. If this parameter is configured, the Monitoring Device MUST ensure that enough resources are available to store the configured maximum number of Flows. If the maximum number of Cache entries is in use, no additional Flows can be measured. Traffic for existing Flows can still be measured though 💖.
activeFlows: This state parameter indicates the number of Flows currently active in this Cache (i.e., the number of Cache entries currently in use). Note that this parameter corresponds to ipfixMeteringProcessCacheActiveFlows in the IPFIX MIB module [RFC6615].
unusedCacheEntries: The number of unused cache entries. Note that the sum of activeFlows and unusedCacheEntries equals maxFlows if maxFlows is configured 🧮. Note that this parameter corresponds to ipfixMeteringProcessCacheUnusedCacheEntries in the IPFIX MIB module [RFC6615].
The following timeout parameters are only available in the TimeoutCache and NaturalCache classes ⏳:
activeTimeout: This parameter configures the time in seconds after which a Flow is expired, even though packets matching this Flow are still being received by the Cache. The parameter value zero indicates infinity, meaning there is no active timeout. If not configured by the user, the Monitoring Device sets this parameter. Note that this parameter corresponds to ipfixMeteringProcessCacheActiveTimeout in the IPFIX MIB module [RFC6615].
idleTimeout: This parameter configures the time in seconds after which a Flow is expired if no more packets matching this Flow are received by the Cache. The parameter value zero indicates infinity, meaning there is no idle timeout. If not configured by the user, the Monitoring Device sets this parameter. Note that this parameter corresponds to ipfixMeteringProcessCacheIdleTimeout in the IPFIX MIB module [RFC6615].
The following interval parameter is only available in the PermanentCache class 🕰️:
exportInterval: This parameter configures the interval (in seconds) for periodical export of Flow Records. If not configured by the user, the Monitoring Device sets this parameter.
Every generated Flow Record MUST be associated with a single Observation Domain. So, even though a Cache MAY be configured to process packets observed at multiple Observation Domains, the Cache MUST NOT aggregate packets observed at different Observation Domains in the same Flow 🙈💅.
An object of the Cache class contains an object of the CacheLayout class that defines which fields are included in the Flow Records 🎀.
4.3.3. CacheLayout Class ✨
+--------------+
| CacheLayout |
+--------------+ 1..* +--------------------------------+
| |<>------| CacheField |
| | +--------------------------------+
| | | name |
| | | ieId/ieName |
| | | ieLength {opt.} |
| | | ieEnterpriseNumber = 0 |
| | | isFlowKey[0..1] {not used with |
| | | ImmediateCache class} |
+--------------+ +--------------------------------+
Figure 15: CacheLayout classOkay so a Cache is basically the thing that cooks up Packet Reports or Flow Records from the stream of incoming packets 💅. Using CacheField objects, the CacheLayout class lists the superset of fields that show up in those reports and records (see Figure 15) 🦋.
If Packet Reports are being generated (aka the ImmediateCache class is used to configure the Cache), every field specified by the Cache Layout MUST be included in the resulting Packet Report, unless the corresponding Information Element is not applicable or cannot be derived from the content or treatment of the incoming packet. Any other field specified by the Cache Layout MAY only be included in the Packet Report if it is obvious from the field value itself or from the values of other fields in the same Packet Report that the field value was not determined from the packet 🌸.
Example time 🧚: say a field is set up to hold the TCP source port (Information Element tcpSourcePort [IANA-IPFIX]). That field MUST be included in all Packet Reports related to TCP packets. The value can't be determined for non-TCP packets, but the field MAY still be included in those Packet Reports if another field contains the transport protocol identifier (Information Element protocolIdentifier [IANA-IPFIX]) 😭.
If Flow Records are being generated (aka the TimeoutCache, NaturalCache, or PermanentCache class is used to configure the Cache), the Cache Layout splits things up into Flow Key fields and non-key fields 👑. Every Flow Key field specified by the Cache Layout MUST be included as a Flow Key in the resulting Flow Record, unless the corresponding Information Element is not applicable or cannot be derived from the content or treatment of the incoming packet. Any other Flow Key field specified by the Cache Layout MAY only be included in the Flow Record if it is obvious from the field value itself or from the values of other Flow Key fields in the same Flow Record that the field value was not determined from the packet.
Two packets get accounted by the same Flow Record if none of their Flow Key fields differ. If a Flow Key field can be determined for one packet but not for the other, the two packets are accounted in different Flow Records. Lowkey the most important rule in this whole section 🔥.
Every non-key field specified by the Cache Layout MUST be included in the resulting Flow Record, unless the corresponding Information Element is not applicable or cannot be derived for the given Flow. Any other non-key field specified by the Cache Layout MAY only be included in the Flow Record if it is obvious from the field value itself or from the values of other fields in the same Flow Record that the field value was not determined from the packet. Packets that are accounted by the same Flow Record may differ in their non-key fields, or one or more of the non-key fields can be undetermined for all or some of the packets 🌈.
For example, if a non-key field specifies an Information Element whose value is determined by the first packet observed within a Flow (which is the default rule according to [RFC5102] unless specified differently in the description of the Information Element), this field MUST be included in the resulting Flow Record if it can be determined from the first packet of the Flow 💖.
The CacheLayout class does not have any parameters. The configuration parameters of the CacheField class are as follows:
ieId,ieName,ieEnterpriseNumber: These parameters specify a field by the combination of the Information Element identifier or name, and the Information Element enterprise number. EitherieIdorieNameMUST be specified. IfieEnterpriseNumberis zero (which is the default), this Information Element is registered in the IANA registry of IPFIX Information Elements [IANA-IPFIX]. A non-zero value ofieEnterpriseNumberspecifies an enterprise-specific Information Element [IANA-ENTERPRISE-NUMBERS]. If the enterprise number is set to 29305, this field contains a Reverse Information Element. In this case, the Cache MUST generate Data Records in accordance to [RFC5103].ieLength: This parameter specifies the length of the field in octets. A value of 65535 means that the field is encoded as a variable-length Information Element. For Information Elements of integer and float type, the field length MAY be set to a smaller value than the standard length of the abstract data type if the rules of reduced size encoding are fulfilled (see [RFC5101], Section 6.2). If not configured by the user, the field length is set by the Monitoring Device.isFlowKey: If present, this field is a Flow Key. If the field contains a Reverse Information Element, it MUST NOT be configured as Flow Key. This parameter is not available if the Cache is configured using the ImmediateCache class, since there is no distinction between Flow Key fields and non-key fields in Packet Reports.
Note that the use of Information Elements can be restricted to certain Cache types as well as to Flow Key or non-key fields. Such restrictions may result from Information Element definitions or from device-specific constraints. According to Section 5, the Monitoring Device MUST notify the user if a Cache field cannot be configured with the given Information Element 🙈.
4.4. ExportingProcess Class 🎀
+-------------------------------+
| ExportingProcess |
+-------------------------------+ 1..* +-------------+
| name |<>------| Destination |
| exportingProcessId {readOnly} | +-------------+
| exportMode = "parallel" | | name |<>-+
| | +-------------+ | 1
| | |
| | +---------------+
| | | SctpExporter/ |
| | | UdpExporter/ |
| | | TcpExporter/ |
| | | FileWriter |
| | +---------------+
| |
| | 0..* +------------------+
| |<>------| Options |
+-------------------------------+ +------------------+
Figure 16: ExportingProcess classThe ExportingProcess class in Figure 16 is where you list the destinations that the incoming Packet Reports and Flow Records get exported to, using objects of the Destination class 📬. The Destination class holds one object of the SctpExporter, UdpExporter, TcpExporter, or FileWriter class, which has further configuration parameters. These classes are described in Sections 4.4.1, 4.4.2, 4.4.3, and 4.4.4 ✨.
As a state parameter, the ExportingProcess class contains the identifier of the Exporting Process (exportingProcessId). This parameter corresponds to the Information Element exportingProcessId [IANA-IPFIX]. Having it helps associate Exporting Process Reliability Statistics exported according to the IPFIX protocol specification [RFC5101] with the correct object of the ExportingProcess class 🫶.
The order in which objects of the Destination class appear is defined by the user. However, the order only has a specific meaning if the exportMode parameter is set to "fallback". The exportMode parameter is defined as follows:
exportMode: This parameter determines to which configured destination(s) the incoming Data Records are exported. The following parameter values are specified by the configuration data model:parallel: every Data Record is exported to all configured destinations in parallelloadBalancing: every Data Record is exported to exactly one configured destination according to a device-specific load-balancing policyfallback: every Data Record is exported to exactly one configured destination according to the fallback policy described below
If exportMode is set to "fallback", the first object of the Destination class defines the primary destination, the second object of the Destination class defines the secondary destination, and so on. If the Exporting Process fails to export Data Records to the primary destination, it tries to export them to the secondary one. If the secondary destination fails as well, it continues with the tertiary, etc. "parallel" is the default value if exportMode is not configured 💜.
Note that the exportMode parameter is related to the ipfixExportMemberType object in [RFC6615]. If exportMode is "parallel", the ipfixExportMemberType values of the corresponding entries in ipfixExportTable are set to parallel(3). If exportMode is "loadBalancing", the ipfixExportMemberType values of the corresponding entries in ipfixExportTable are set to loadBalancing(4). If exportMode is "fallback", the ipfixExportMemberType value that refers to the primary destination is set to primary(1), and the ipfixExportMemberType values that refer to the remaining destinations need to be set to secondary(2). The IPFIX MIB module does not define any value for tertiary destination, etc. 🤓
The reporting of information with Options Templates is defined with objects of the Options class 🍓.
The Exporting Process may modify the Packet Reports and Flow Records to enable a more efficient transmission or storage, under the condition that no information is changed or suppressed. For example, the Exporting Process may shorten the length of a field according to the rules of reduced size encoding [RFC5101]. The Exporting Process may also export certain fields in a separate Data Record, as described in [RFC5476] 🌸.
4.4.1. SctpExporter Class ✨
Okay bestie, this one is the SCTP export destination 🦋 Figure 17 has the whole layout:
+------------------------------+
| SctpExporter |
+------------------------------+ 0..1 +------------------------+
| ipfixVersion = 10 |<>-------| TransportLayerSecurity |
| sourceIPAddress[0..*] | +------------------------+
| destinationIPAddress[1..*] |
| destinationPort = 4739|4740 | 0..1 +------------------------+
| ifName/ifIndex[0..1] |<>-------| TransportSession |
| sendBufferSize {opt.} | +------------------------+
| rateLimit[0..1] |
| timedReliability = 0 |
+------------------------------+
Figure 17: SctpExporter classThe SctpExporter class from Figure 17 holds the config parameters for an SCTP export destination 💖 Here's the rundown:
ipfixVersion: the version number of the IPFIX protocol being used. If you leave it out, the default is 10 (=0x000a) as specified in [RFC5101]. 🎀
sourceIPAddress: a list of source IP addresses the Exporting Process can use. If you set it, those addresses are the eligible local IP addresses of the multihomed SCTP endpoint. If you don't, every locally assigned IP address counts as eligible. 🌸
destinationIPAddress: one or more IP addresses of the Collecting Process that IPFIX Messages get sent to. The user has to make sure all the configured IP addresses belong to the same Collecting Process 🙈 The Exporting Process tries to set up an SCTP association with any of the configured destination IP addresses.
destinationPort: the destination port number to use. If it isn't configured, you get the standard port 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS). 🧚
ifIndex/ifName: either the index or the name of the interface that the Exporting Process uses to export IPFIX Messages to the given destination MAY be specified, matching the corresponding objects in the IF-MIB [RFC2863]. If it's omitted, the Exporting Process picks the outgoing interface based on a local routing decision and accepts return traffic, like transport-layer acknowledgments, on all available interfaces. 🦋
sendBufferSize: the size of the socket send buffer in bytes. If the user doesn't configure it, the Monitoring Device sets the buffer size. 💅
rateLimit: the maximum number of bytes per second the Exporting Process may export to the given destination, as required by [RFC5476]. The byte count gets calculated from the lengths of the IPFIX Messages exported. If this parameter isn't configured, no rate limiting is performed for that destination. 🍓
timedReliability: the lifetime in milliseconds until an IPFIX Message containing Data Sets only is "abandoned" because of the timed reliability mechanism of the Partial Reliability extension of SCTP (PR-SCTP) [RFC3758]. If this parameter is set to zero, reliable SCTP transport MUST be used for all Data Records. No matter what this value is, the Exporting Process MAY use reliable SCTP transport for Data Sets associated with certain Options Templates, such as the Data Record Reliability Options Template specified in [RFC6526]. 👑
Using the TransportLayerSecurity class described in Section 4.6, Datagram Transport Layer Security (DTLS) is enabled and configured for this export destination. 🫶
If a Transport Session is established to the configured destination, the SctpExporter class includes an object of the TransportSession class containing its state parameters. The TransportSession class is specified in Section 4.7. ✨
4.4.2. UdpExporter Class 🌈
Next up is UdpExporter, and it's giving a whole lot of configurable stuff 💜 Figure 18 is the blueprint:
+-------------------------------------+
| UdpExporter |
+-------------------------------------+ 0..1 +------------------+
| ipfixVersion = 10 |<>------| TransportLayer- |
| sourceIPAddress[0..1] | | Security |
| destinationIPAddress | +------------------+
| destinationPort = 4739|4740 |
| ifName/ifIndex[0..1] | 0..1 +------------------+
| sendBufferSize {opt.} |<>------| TransportSession |
| rateLimit[0..1] | +------------------+
| maxPacketSize {opt.} |
| templateRefreshTimeout = 600 |
| optionsTemplateRefreshTimeout = 600 |
| templateRefreshPacket[0..1] |
| optionsTemplateRefreshPacket[0..1] |
+-------------------------------------+
Figure 18: UdpExporter classThe UdpExporter class from Figure 18 holds the config parameters for a UDP export destination. The parameters ipfixVersion, destinationPort, ifName, ifIndex, sendBufferSize, and rateLimit mean the exact same thing as they do in the SctpExporter class (see Section 4.4.1). The remaining config parameters are:
sourceIPAddress: the source IP address the Exporting Process uses. If this parameter is omitted, the IP address assigned to the outgoing interface gets used as the source IP address. 🌸
destinationIPAddress: the destination IP address that IPFIX Messages get sent to, which is the IP address of the Collecting Process. 🎀
maxPacketSize: the maximum size of IP packets sent to the Collector. If it's set to zero, the Exporting Device MUST derive the maximum packet size from path MTU discovery mechanisms. If the user doesn't configure it, the Monitoring Device sets this parameter. 🧚
templateRefreshTimeout, optionsTemplateRefreshTimeout, templateRefreshPacket, optionsTemplateRefreshPacket: these parameters control when (Options) Templates get refreshed by the Exporting Process. 💖
templateRefreshTimeout and optionsTemplateRefreshTimeout are given in seconds between resendings of (Options) Templates. If they're omitted, the default value of 600 seconds (10 minutes) is used [RFC5101]. ⏰
templateRefreshPacket and optionsTemplateRefreshPacket specify the number of IPFIX Messages after which (Options) Templates get resent. If they're omitted, the (Options) Templates are only resent after the timeout. 🦋
Heads up: the values configured for templateRefreshTimeout and optionsTemplateRefreshTimeout MUST be adapted to the templateLifeTime and optionsTemplateLifeTime parameter settings at the receiving Collecting Process (see Section 4.5.2). 🚨
These parameters correspond to ipfixTransportSessionTemplateRefreshTimeout, ipfixTransportSessionOptionsTemplateRefreshTimeout, ipfixTransportSessionTemplateRefreshPacket, and ipfixTransportSessionOptionsTemplateRefreshPacket in the IPFIX MIB module [RFC6615]. 💅
Using the TransportLayerSecurity class described in Section 4.6, DTLS is enabled and configured for this export destination. 🫶
If a Transport Session is established to the configured destination, the UdpExporter class includes an object of the TransportSession class containing its state parameters. The TransportSession class is specified in Section 4.7. ✨
4.4.3. TcpExporter Class 🌷
TcpExporter is the TCP sibling 🎀 Here's Figure 19:
+------------------------------+
| TcpExporter |
+------------------------------+ 0..1 +------------------------+
| ipfixVersion = 10 |<>-------| TransportLayerSecurity |
| sourceIPAddress[0..1] | +------------------------+
| destinationIPAddress |
| destinationPort = 4739|4740 | 0..1 +------------------------+
| ifName/ifIndex[0..1] |<>-------| TransportSession |
| sendBufferSize {opt.} | +------------------------+
| rateLimit[0..1] |
+------------------------------+
Figure 19: TcpExporter classThe TcpExporter class from Figure 19 holds the config parameters for a TCP export destination. The parameters have the same meaning as in the UdpExporter class (see Section 4.4.2). 🦋
Using the TransportLayerSecurity class described in Section 4.6, Transport Layer Security (TLS) is enabled and configured for this export destination. 🔥
If a Transport Session is established to the configured destination, the TcpExporter class includes an object of the TransportSession class containing its state parameters. The TransportSession class is specified in Section 4.7. ✨
4.4.4. FileWriter Class 📁
Last but not least, FileWriter, which writes IPFIX Messages into a file instead of sending them over the wire 🌈 Check out Figure 20:
+-----------------------------------------+
| FileWriter |
+-----------------------------------------+ 0..* +----------+
| ipfixVersion = 10 |<>-------| Template |
| file | +----------+
| status {readOnly} |
| bytes {readOnly} |
| messages {readOnly} |
| discardedMessages {readOnly} |
| records {readOnly} |
| templates {readOnly} |
| optionsTemplates {readOnly} |
| fileWriterDiscontinuityTime {readOnly} |
+-----------------------------------------+
Figure 20: FileWriter classesIf an object of the FileWriter class is included in an object of the Destination class, IPFIX Messages get written into a file as specified in [RFC5655]. The FileWriter class has these config parameters:
ipfixVersion: the version number of the IPFIX protocol being used. If it's omitted, the default value is 10 (=0x000a) as specified in [RFC5101]. 💖
file: the file name and location, specified as a URI. 📄
The state parameters of the FileWriter class are:
bytes, messages, records, templates, optionsTemplates: the number of bytes, IPFIX Messages, Data Records, Template Records, and Options Template Records written by the File Writer. Discontinuities in the values of these counters can happen at re-initialization of the management system, and at other times as indicated by the value of fileWriterDiscontinuityTime. 🍓
discardedMessages: the number of IPFIX Messages that the File Writer couldn't write because of internal buffer overflows, limited storage capacity, and so on. Discontinuities in the value of this counter can happen at re-initialization of the management system, and at other times as indicated by the value of fileWriterDiscontinuityTime. 🙈
fileWriterDiscontinuityTime: the timestamp of the most recent occasion when one or more File Writer counters suffered a discontinuity. Unlike the discontinuity times in the IPFIX MIB module, this time is absolute and not relative to sysUpTime. ⏰
Each object of the FileWriter class includes a list of objects of the Template class, with information and statistics about the Templates written to the file. The Template class is specified in Section 4.8. 🦋
4.4.5. Options Class
+-----------------------+
| Options |
+-----------------------+
| name |
| optionsType |
| optionsTimeout {opt.} |
+-----------------------+
Figure 21: Options classokay so the Options class is where we decide what kind of info gets reported 🎀 like stats, flow keys, sampling and filtering settings, all of it. [RFC5101] and [RFC5476] already define a bunch of reporting info types that can be exported, and the configuration data model picks from them with these optionsType values:
meteringStatistics: Metering Process statistics, sent using the Metering Process Statistics Options Template [RFC5101] 📊meteringReliability: Metering Process reliability statistics, sent using the Metering Process Reliability Statistics Options Template [RFC5101] 🛡️exportingReliability: Exporting Process reliability statistics, sent using the Exporting Process Reliability Statistics Options Template [RFC5101] ✨flowKeys: the Flow Key specification, sent using the Flow Keys Options Template [RFC5101] 🔑selectionSequence: Selection Sequence Report Interpretation and Selector Report Interpretation [RFC5476] 🧚selectionStatistics: Selection Sequence Statistics Report Interpretation [RFC5476] 💜accuracy: Accuracy Report Interpretation [RFC5476] 🎯reducingRedundancy: turns on the use of Options Templates to cut down redundancy in the exported Data Records, following [RFC5473]. The Exporting Process decides when to apply these Options Templates 🍓extendedTypeInformation: extended type information for enterprise-specific Information Elements used in the exported Templates [RFC5610] 🌈
The Exporting Process MUST choose a Template definition according to the options type and available options data. That's the rule, bestie, no cap 💅
The optionsTimeout parameter is the reporting interval in milliseconds for periodic export of the option data. If it's set to zero, the option data isn't exported on a timer. Instead, it gets exported whenever the available option data changes. That zero setting is the typical one for the flowKeys, selectionSequence, accuracy, and reducingRedundancy types 🦋 And if somebody doesn't configure optionsTimeout, the Monitoring Device sets it for them 🫶
4.5. CollectingProcess Class
+-------------------+
| CollectingProcess |
+-------------------+
| name | 0..* +------------------+
| |<>----------| SctpCollector |
| | +------------------+
| |
| | 0..* +------------------+
| |<>----------| UdpCollector |
| | +------------------+
| |
| | 0..* +------------------+
| |<>----------| TcpCollector |
| | +------------------+
| |
| | 0..* +------------------+
| |<>----------| FileReader |
| | +------------------+
| |
| | 0..* 0..* +------------------+
| |----------->| ExportingProcess |
+-------------------+ +------------------+
Figure 22: CollectingProcess classFigure 22 shows the CollectingProcess class, which holds the configuration and state parameters of a Collecting Process 🌸 The SctpCollector, UdpCollector, and TcpCollector classes say how IPFIX Messages get received from remote Exporters 📥 The Collecting Process can also act as a File Reader using the FileReader class. All of these are covered in Sections 4.5.1, 4.5.2, 4.5.3, and 4.5.4.
A CollectingProcess object MAY refer to one or more ExportingProcess objects. Those configure Exporting Processes that pass the received data along, unmodified, to a file or to another Collector 🔁
4.5.1. SctpCollector Class
+--------------------------+
| SctpCollector |
+--------------------------+ 0..1 +------------------------+
| name |<>-------| TransportLayerSecurity |
| localIPAddress[0..*] | +------------------------+
| localPort = 4739|4740 |
| | 0..* +------------------------+
| |<>-------| TransportSession |
+--------------------------+ +------------------------+
Figure 23: SctpCollector classThe SctpCollector class holds the configuration parameters of a listening SCTP socket at a Collecting Process 🦢 Here's what's in it:
localIPAddress: a list of local IP addresses where the Collecting Process listens for IPFIX Messages. These addresses are the eligible local IP addresses of the multihomed SCTP endpoint [RFC4960]. If it's left out, the Collecting Process listens on all local IP addresses 🌐localPort: the local port number where the Collecting Process listens for IPFIX Messages. If it's left out, the standard port 4739 is used for IPFIX without TLS and DTLS, and port 4740 is used for IPFIX over TLS or DTLS 🎀
Using the TransportLayerSecurity class from Section 4.6, DTLS is enabled and configured for this receiving socket 🔐
As state data, the SctpCollector class keeps the list of currently established Transport Sessions that end at this SCTP socket of the Collecting Process. The TransportSession class is specified in Section 4.7 ✨
4.5.2. UdpCollector Class
+---------------------------------+
| UdpCollector |
+---------------------------------+ 0..1 +------------------------+
| name |<>------| TransportLayerSecurity |
| localIPAddress[0..*] | +------------------------+
| localPort = 4739|4740 |
| templateLifeTime = 1800 | 0..* +------------------------+
| optionsTemplateLifeTime = 1800 |<>------| TransportSession |
| templateLifePacket[0..*] | +------------------------+
| optionsTemplateLifePacket[0..*] |
+---------------------------------+
Figure 24: UdpCollector classThe UdpCollector class holds the configuration parameters of a listening UDP socket at a Collecting Process 💜 The localPort parameter means the same thing here as it does in the SctpCollector class (see Section 4.5.1). The rest of the parameters are:
localIPAddress: a list of local IP addresses where the Collecting Process listens for IPFIX Messages. If it's left out, the Collecting Process listens on all local IP addresses 🌍templateLifeTime,optionsTemplateLifeTime: (Options) Template lifetime in seconds for all UDP Transport Sessions that end at this UDP socket. (Options) Templates that aren't received again within the configured lifetime become invalid at the Collecting Process ⏳
As specified in [RFC5101], Section 10.3.7, the lifetime of Templates and Options Templates MUST be at least three times higher than the templateRefreshTimeout and optionTemplatesRefreshTimeout parameter values configured on the corresponding Exporting Processes 🧠
If it's not configured, the default value 1800 is used. That's three times the default (Options) Template refresh timeout (see Section 4.4.2) as specified in [RFC5101] 🍀
Note that these parameters correspond to ipfixTransportSessionTemplateRefreshTimeout and ipfixTransportSessionOptionsTemplateRefreshTimeout in the IPFIX MIB module [RFC6615] 📚
templateLifePacket,optionsTemplateLifePacket: IftemplateLifePacketis configured, Templates defined in a UDP Transport Session become invalid if they're neither included in a sequence of more than this number of IPFIX Messages nor received again within the period of time set bytemplateLifeTime. In the same way, ifoptionsTemplateLifePacketis configured, Options Templates become invalid if they're neither included in a sequence of more than this number of IPFIX Messages nor received again within the period of time set byoptionsTemplateLifeTime📦
If these aren't configured, Templates and Options Templates only become invalid according to templateLifeTime and optionsTemplateLifeTime, respectively.
Note that these parameters correspond to ipfixTransportSessionTemplateRefreshPacket and ipfixTransportSessionOptionsTemplateRefreshPacket in the IPFIX MIB module [RFC6615] 🦋
Using the TransportLayerSecurity class from Section 4.6, DTLS is enabled and configured for this receiving socket 🔐
As state data, the UdpCollector class keeps the list of currently established Transport Sessions that end at this UDP socket of the Collecting Process. The TransportSession class is specified in Section 4.7 🌷
4.5.3. TcpCollector Class
+--------------------------+
| TcpCollector |
+--------------------------+ 0..1 +------------------------+
| name |<>-------| TransportLayerSecurity |
| localIPAddress[0..*] | +------------------------+
| localPort = 4739|4740 |
| | 0..* +------------------------+
| |<>-------| TransportSession |
+--------------------------+ +------------------------+
Figure 25: TcpCollector classThe TcpCollector class holds the configuration parameters of a listening TCP socket at a Collecting Process 🩵 Its parameters mean the same thing as the ones in the UdpCollector class (see Section 4.5.2) 🫧
Using the TransportLayerSecurity class from Section 4.6, TLS is enabled and configured for this receiving socket 🔒
As state data, the TcpCollector class keeps the list of currently established Transport Sessions that end at this TCP socket of the Collecting Process. The TransportSession class is specified in Section 4.7 💖
4.5.4. FileReader Class 📂✨
+-----------------------------------------+
| FileReader |
+-----------------------------------------+ 0..* +----------+
| name |<>-------| Template |
| file | +----------+
| bytes {readOnly} |
| messages {readOnly} |
| records {readOnly} |
| templates {readOnly} |
| optionsTemplates {readOnly} |
| fileReaderDiscontinuityTime {readOnly} |
+-----------------------------------------+
Figure 26: FileReader classesOkay bestie, so the Collecting Process is allowed to import IPFIX Messages from a file, as laid out in [RFC5655]. 💅 The FileReader class has exactly one configuration parameter:
file: the file name and location, written as a URI 🌸
Now for the state parameters, which are the stats the FileReader keeps track of:
bytes,messages,records,templates,optionsTemplates: these count the bytes, IPFIX Messages, Data Records, Template Records, and Options Template Records that the File Reader has read. The counters can jump around (a discontinuity) when the management system gets re-initialized, and at other times too, which you can spot fromfileReaderDiscontinuityTime. 👀fileReaderDiscontinuityTime: the timestamp of the most recent moment when one or more File Reader counters had a discontinuity. Unlike the discontinuity times in the IPFIX MIB module, this one is absolute and not relative tosysUpTime. Main character timestamp energy 🕰️✨
Each FileReader object comes with a list of Template class objects, which hold info and stats about the Templates it read from the file. The Template class is covered in Section 4.8. 🧚
4.6. Transport Layer Security Class 🔐💜
+--------------------------------------+
| TransportLayerSecurity |
+--------------------------------------+
| localCertificationAuthorityDN[0..*] |
| localSubjectDN[0..*] |
| localSubjectFQDN[0..*] |
| remoteCertificationAuthorityDN[0..*] |
| remoteSubjectDN[0..*] |
| remoteSubjectFQDN[0..*] |
+--------------------------------------+
Figure 27: TransportLayerSecurity classThe TransportLayerSecurity class is the thing that turns on and configures TLS/DTLS for IPFIX. It's used by the Exporting Process's SctpExporter, UdpExporter, and TcpExporter classes, and by the Collecting Process's SctpCollector, UdpCollector, and TcpCollector classes. ✨ You can enable TLS/DTLS without setting any extra parameters at all. In that case the config just shows an empty XML element, <transportLayerSecurity />. 🫶 Once it's on, the endpoint must use DTLS [RFC6347] if the transport protocol is SCTP or UDP, and TLS [RFC5246] if it's TCP.
[RFC5101] sets the rules for strong mutual authentication between Exporting Processes and Collecting Processes. Heads up, this quote cites [RFC3280], which got obsoleted by [RFC5280] 📜
IPFIX Exporting Processes and IPFIX Collecting Processes are
identified by the fully qualified domain name (FQDN) of the
interface on which IPFIX Messages are sent or received, for
purposes of X.509 client and server certificates as in [RFC3280].
To prevent man-in-the-middle attacks from impostor Exporting or
Collecting Processes, the acceptance of data from an unauthorized
Exporting Process, or the export of data to an unauthorized
Collecting Process, strong mutual authentication via asymmetric
keys MUST be used for both TLS and DTLS. Each of the IPFIX
Exporting and Collecting Processes MUST verify the identity of its
peer against its authorized certificates, and MUST verify that the
peer's certificate matches its fully qualified domain name, or, in
the case of SCTP, the fully qualified domain name of one of its
endpoints.
The fully qualified domain name used to identify an IPFIX
Collecting Process or Exporting Process may be stored either in a
subjectAltName extension of type dNSName, or in the most specific
Common Name field of the Subject field of the X.509 certificate.
If both are present, the subjectAltName extension is given
preference.Okay so the vibe here is no impostors allowed 🚫😤. Both sides have to prove who they are with asymmetric keys for TLS and DTLS, and each side has to check its peer against its authorized certificates and confirm the cert matches its FQDN. For SCTP, the FQDN of any one of its endpoints works. The FQDN can live in a subjectAltName extension of type dNSName, or in the most specific Common Name in the certificate's Subject field. If both are there, subjectAltName wins. 💅
Before any of this works, the right certificates and keys have to already be installed on the Monitoring Devices. For security reasons, the configuration data model does not let you upload certificates or keys onto a Monitoring Device, so no sneaking them in 🙅♀️. And if TLS/DTLS is enabled on a Monitoring Device that doesn't have the right certificates and keys, the configuration MUST be rejected with an error. 🚨
The data model also lets you narrow down which remote endpoints get authorized, either by the certification authority that issued their cert or by specific FQDNs. It also lets you limit which certificates identify the local endpoint, which is super handy if the Monitoring Device has more than one cert for the same local endpoint 🧁
The configuration parameters are:
localCertificationAuthorityDN: this parameter MAY appear one or more times to restrict how the local endpoint gets identified during the TLS/DTLS handshake, using certs issued by the configured certification authorities. Each occurrence holds the distinguished name of one certification authority. To identify the local endpoint, the Exporting Process or Collecting Process MUST use a certificate issued by one of the configured certification authorities. Certificates issued by any other certification authority MUST NOT be sent to the remote peer during TLS/DTLS handshake. If none of the certificates installed on the Monitoring Device fulfills the specified restrictions, the configuration MUST be rejected with an error. IflocalCertificationAuthorityDNisn't configured, the choice of certificates identifying the local endpoint isn't restricted by the issuing certification authority. 🦋localSubjectDN,localSubjectFQDN: each of these parameters MAY appear one or more times to restrict how the local endpoint gets identified during the TLS/DTLS handshake, using certs issued for specific subjects or specific FQDNs. Each occurrence oflocalSubjectDNholds a distinguished name identifying the local endpoint. Each occurrence oflocalSubjectFQDNholds a FQDN assigned to the local endpoint. To identify the local endpoint, the Exporting Process or Collecting Process MUST use a certificate that contains either one of the configured distinguished names in the subject field, or at least one of the configured FQDNs in a dNSName component of the subject alternative extension field or in the most specific commonName component of the subject field. If none of the certificates installed on the Monitoring Device fulfills the specified restrictions, the configuration MUST be rejected with an error. If any of the parameterslocalSubjectDNandlocalSubjectFQDNis configured at the same time as thelocalCertificationAuthorityDNparameter, certificates MUST also fulfill the specified restrictions regarding the certification authority. IflocalSubjectDNandlocalSubjectFQDNaren't configured, the choice of certificates identifying the local endpoint isn't restricted by the subject's distinguished name or FQDN. 🌈remoteCertificationAuthorityDN: this parameter MAY appear one or more times to restrict how remote endpoints get authenticated during the TLS/DTLS handshake, using certs issued by the configured certification authorities. Each occurrence holds the distinguished name of one certification authority. To authenticate the remote endpoint, the remote Exporting Process or Collecting Process MUST provide a certificate issued by one of the configured certification authorities. Certificates issued by any other certification authority MUST be rejected during TLS/DTLS handshake. If the Monitoring Device isn't able to validate certificates issued by the configured certification authorities (for example, because of missing public keys), the configuration must be rejected with an error. IfremoteCertificationAuthorityDNisn't configured, the authorization of remote endpoints isn't restricted by the issuing certification authority of the delivered certificate. 🔍remoteSubjectDN,remoteSubjectFQDN: each of these parameters MAY appear one or more times to restrict how remote endpoints get authenticated during the TLS/DTLS handshake, using certs issued for specific subjects or specific FQDNs. Each occurrence ofremoteSubjectDNholds a distinguished name identifying a remote endpoint. Each occurrence ofremoteSubjectFQDNholds a FQDN assigned to a remote endpoint. To authenticate a remote endpoint, the remote Exporting Process or Collecting Process MUST provide a certificate that contains either one of the configured distinguished names in the subject field, or at least one of the configured FQDNs in a dNSName component of the subject alternative extension field or in the most specific commonName component of the subject field. Certificates not fulfilling this condition MUST be rejected during TLS/DTLS handshake. If any of the parametersremoteSubjectDNandremoteSubjectFQDNis configured at the same time as theremoteCertificationAuthorityDNparameter, certificates MUST also fulfill the specified restrictions regarding the certification authority in order to be accepted. IfremoteSubjectDNandremoteSubjectFQDNaren't configured, the authorization of remote endpoints isn't restricted by the subject's distinguished name or FQDN of the delivered certificate. 💜
4.7. Transport Session Class 🦋
+----------------------------------------------+
| TransportSession |
+----------------------------------------------+ 0..* +----------+
| ipfixVersion {readOnly} |<>-------| Template |
| sourceAddress {readOnly} | +----------+
| destinationAddress {readOnly} |
| sourcePort {readOnly} |
| destinationPort {readOnly} |
| sctpAssocId {readOnly} {SCTP only} |
| status {readOnly} |
| rate {readOnly} |
| bytes {readOnly} |
| messages {readOnly} |
| discardedMessages {readOnly} |
| records {readOnly} |
| templates {readOnly} |
| optionsTemplates {readOnly} |
| transportSessionStartTime {readOnly} |
| transportSessionDiscontinuityTime {readOnly} |
+----------------------------------------------+Figure 28: TransportSession class 🧚
okay bestie, the TransportSession class is basically the state diary for every Transport Session 📖. It holds the juicy details about Transport Sessions that either start at an Exporting Process or end up at a Collecting Process 💅. Mostly, the state parameters line up with the managed objects in the ipfixTransportSessionTable and ipfixTransportSessionStatsTable of the IPFIX MIB module [RFC6615] ✨. The one plot twist is how sourceAddress and destinationAddress work. If SCTP is the transport protocol, the Exporter or Collector MAY be multihomed SCTP endpoints (see [RFC4960], Section 6.4) and use more than one IP address 🌈. In the IPFIX MIB module, ipfixTransportSessionSctpAssocId is used instead of ipfixTransportSessionSourceAddress and ipfixTransportSessionDestinationAddress to point to an entry in the sctpAssocTable defined in the SCTP MIB module [RFC3871] 🫶. But we can't assume that an SNMP agent offering access to the SCTP MIB module exists on the Monitoring Device 💀, so the configuration data model can't rely on that parameter. So the state parameters sourceAddress and destinationAddress are used for SCTP too 🎀, holding one of the potentially many Exporter and Collector IP addresses in the SCTP association. Preferably, the IP addresses of the path that is usually selected by the Exporter to send IPFIX Messages to the Collector SHOULD be contained 🌸.
Several MIB objects of the ipfixTransportSessionTable are left out of the TransportSession class 🙈. The MIB object ipfixTransportSessionDeviceMode isn't included, because its value can be figured out from the context the TransportSession object lives in: exporting(1) if it belongs to an Exporting Process, collecting(2) if it belongs to a Collecting Process 🍓. Same vibe with the MIB object ipfixTransportSessionProtocol, since the transport protocol is already known from context ✨. The MIB objects ipfixTransportSessionTemplateRefreshTimeout, ipfixTransportSessionOptionsTemplateRefreshTimeout, ipfixTransportSessionTemplateRefreshPacket, and ipfixTransportSessionOptionsTemplateRefreshPacket are also not included, since they line up with configuration parameters of the UdpExporter class (templateRefreshTimeout, optionsTemplateRefreshTimeout, templateRefreshPacket, optionsTemplateRefreshPacket) and the UdpCollector class (templateLifeTime, optionsTemplateLifeTime, templateLifePacket, optionsTemplateLifePacket) 🦋.
ipfixVersion: For Exporting Processes, this one holds the version number of the IPFIX protocol the Exporter uses to export its data in this Transport Session 💖. So it's identical to the value of the configuration parameteripfixVersionof the outer SctpExporter, UdpExporter, or TcpExporter object 👑. For Collecting Processes, it holds the version number of the IPFIX protocol it receives for this Transport Session. If IPFIX Messages of different IPFIX protocol versions are received, this parameter holds the maximum version number 🔥. This state parameter is identical toipfixTransportSessionIpfixVersionin the IPFIX MIB module [RFC6615] 🌈.sourceAddress,destinationAddress: If TCP or UDP is the transport protocol,sourceAddressholds the IP address of the Exporter, anddestinationAddressholds the IP addresses of the Collector 💜. So these two have identical values toipfixTransportSessionSourceAddressandipfixTransportSessionDestinationAddressin the IPFIX MIB module [RFC6615] ✨. If SCTP is the transport protocol,sourceAddressholds one of the IP addresses of the Exporter, anddestinationAddressholds one of the IP addresses of the Collector 🫶. Preferably, the IP addresses of the path that is usually selected by the Exporter to send IPFIX Messages to the Collector SHOULD be contained 💅.sourcePort,destinationPort: These state parameters hold the transport-protocol port numbers of the Exporter and the Collector of the Transport Session 🎀. They're identical toipfixTransportSessionSourcePortandipfixTransportSessionDestinationPortin the IPFIX MIB module [RFC6615] 🦋.sctpAssocId: The association ID used for the SCTP session between the Exporter and the Collector of the Transport Session 🧚. It's equal to thesctpAssocIdentry in thesctpAssocTabledefined in the SCTP-MIB [RFC3871] 🌸. This parameter is only available if the transport protocol is SCTP and if an SNMP agent on the same Monitoring Device enables access to the corresponding MIB objects in thesctpAssocTable🙈. This state parameter is identical toipfixTransportSessionSctpAssocIdin the IPFIX MIB module [RFC6615] 🍓.status: The status of the Transport Session, which can be one of the following 🔥:inactive: Transport Session is established, but no IPFIX Messages are currently transferred (e.g., because this is a backup (secondary) session) 💤active: Transport Session is established and transfers IPFIX Messages ⭐unknown: Transport Session status cannot be determined 🤷
This state parameter is identical to ipfixTransportSessionStatus in the IPFIX MIB module [RFC6615] 💖.
rate: The number of bytes per second transmitted by the Exporting Process or received by the Collecting Process 🌈. This parameter is updated every second ⏱️. This state parameter is identical toipfixTransportSessionRatein the IPFIX MIB module [RFC6615] 💜.bytes,messages,records,templates,optionsTemplates: These count the bytes, IPFIX Messages, Data Records, Template Records, and Options Template Records transmitted by the Exporting Process or received by the Collecting Process 📊. Discontinuities in the values of these counters can happen at re-initialization of the management system, and at other times as indicated by the value oftransportSessionDiscontinuityTime🙃.discardedMessages: For Exporting Processes, this one counts the messages that couldn't be sent because of internal buffer overflows, network congestion, routing issues, etc. 😭. For Collecting Processes, it counts the received IPFIX Messages that are malformed, can't be decoded, arrive in the wrong order, or are missing according to the sequence number 🧐. Discontinuities in the value of this counter can happen at re-initialization of the management system, and at other times as indicated by the value oftransportSessionDiscontinuityTime💫.transportSessionStartTime: The timestamp of the start of the given Transport Session ⏰. This state parameter doesn't correspond to any object in the IPFIX MIB module 🌟.transportSessionDiscontinuityTime: The timestamp of the most recent occasion at which one or more of the Transport Session counters had a discontinuity 🕰️. UnlikeipfixTransportSessionDiscontinuityTime, this time is absolute and not relative tosysUpTime🎀.
Note that, if used for Exporting Processes, the values of the state parameters destinationAddress and destinationPort match the values of the configuration parameters destinationIPAddress and destinationPort of the outer SctpExporter, TcpExporter, and UdpExporter objects (in the case of SctpExporter, one of the configured destinationIPAddress values) 💅. If the transport protocol is UDP or SCTP, and the parameter sourceIPAddress is configured in the outer UdpExporter or SctpExporter object, then the value of sourceAddress equals the configured value or one of the configured values 🫶. For Collecting Processes, the value of destinationAddress equals the value (or one of the values) of the parameter localIPAddress if this parameter is configured in the outer UdpCollector, TcpCollector, or SctpCollector object, and destinationPort equals the value of the configuration parameter localPort 🦋.
Each object of the TransportSession class includes a list of objects of the Template class with information and statistics about the Templates transmitted or received on the given Transport Session 🧚. The Template class is specified in Section 4.8 🌈.
4.8. Template Class 🧩
+--------------------------------------+
| Template |
+--------------------------------------+
| observationDomainId {readOnly} |<>---+ 0..*
| templateId {readOnly} | |
| setId {readOnly} | |
| accessTime {readOnly} | |
| templateDataRecords {readOnly} | |
| templateDiscontinuityTime {readOnly} | |
+--------------------------------------+ |
|
+--------------------------------------+
| Field |
+--------------------------------------+
| ieId {readOnly} |
| ieLength {readOnly} |
| ieEnterpriseNumber {readOnly} |
| isFlowKey {readOnly} {non-Options |
| Template only} |
| isScope {readOnly} {Options Template |
| only} |
+--------------------------------------+
Figure 29: Template classokay so the Template class is where we keep the state data for Templates 💖 It's the stuff an Exporting Process is using, or that a Collecting Process received, inside one specific Transport Session. The Field class is the piece that describes one field of the Template 🎀 Lowkey the state parameters match up with the managed objects in ipfixTemplateTable, ipfixTemplateDefinitionTable, and ipfixTemplateStatsTable of the IPFIX MIB module [RFC6615] 🦋
observationDomainId: the ID of the Observation Domain this Template is defined for ✨templateId: the number that shows the Template ID in the IPFIX Message 🌸setId: the Set ID of the Template. Right now there are two values defined [RFC5101] 💅 The value 2 is for Sets containing Template definitions, and the value 3 is for Sets containing Options Template definitions 👑accessTime: for Exporting Processes, this is the time when this (Options) Template was last sent to the Collector or written to the file. For Collecting Processes, it's the time when this (Options) Template was last received from the Exporter or read from the file 🫶templateDataRecords: the number of Data Records transmitted or received that are defined by this (Options) Template, counted since the point in time indicated by templateDefinitionTime 🍓templateDiscontinuityTime: the timestamp of the most recent moment when the countertemplateDataRecordshad a discontinuity. UnlikeipfixTemplateDiscontinuityTime, this time is absolute and NOT relative to sysUpTime 🕰️ieId,ieLength,ieEnterpriseNumber: the Information Element identifier, length, and enterprise number of a field in the Template. If it isn't an enterprise-specific Information Element,ieEnterpriseNumberis zero 🧚 These state parameters are identical toipfixTemplateDefinitionIeId,ipfixTemplateDefinitionIeLength, andipfixTemplateDefinitionIeEnterpriseNumberin the IPFIX MIB module [RFC6615] 💜isFlowKey: if this state parameter is present, it's a Flow Key field. This one is only available for non-Options Templates (i.e., ifsetIdis 2) 🔑isFlowKey: if this state parameter is present, it's a scope field. This one is only available for Options Templates (i.e., ifsetIdis 3) 🌈
5. Adaptation to Device Capabilities ✨
okay so the configuration data model standardizes a superset of the common IPFIX and PSAMP configuration parameters 💖 A typical Monitoring Device isn't going to support the entire range of possible configurations, and that's totally fine 🫶 Some functions might not be supported at all, like a Collecting Process on a Monitoring Device that's only meant to be an Exporter 💀 Other functions might be limited by resources or functional restrictions. For example, the Cache size is usually limited by how much memory the device has 🧠 It's also possible that a Monitoring Device implementation needs extra parameters that aren't part of the configuration data model in order to work properly 🎀
YANG [RFC6020] gives us a few ways to restrict and adapt a configuration data model. The current version of YANG defines the concepts of features, deviations, and extensions 🦋
The feature concept lets the author of a configuration data model make parts of the model conditional, and the device is the one in control of that 👑 Devices don't have to support these conditional parts to conform to the model. If the NETCONF protocol is used, the features the device supports get announced in the <hello> message [RFC6241] 🌸
The configuration data model for IPFIX and PSAMP covers Exporters, Collectors, and devices that can act as both. Since Exporters and Collectors do different jobs, the matching parts of the model are conditional on the following features 💅
exporter: if this feature is supported, Exporting Processes can be configured 🍓collector: if this feature is supported, Collecting Processes can be configured 🧚
Exporters don't always implement Selection Processes, Caches, or even Observation Points, so the matching parts of the model are conditional on this feature 😭
meter: if this feature is supported, Observation Points, Selection Processes, and Caches can be configured 📊
There are also more features for the different PSAMP Sampling and Filtering methods, plus the supported types of Caches 🌈
psampSampCountBased: if this feature is supported, the Sampling method sampCountBased can be configured 🔥psampSampTimeBased: if this feature is supported, the Sampling method sampTimeBased can be configured ⭐psampSampRandOutOfN: if this feature is supported, the Sampling method sampRandOutOfN can be configured 💜psampSampUniProb: if this feature is supported, the Sampling method sampUniProb can be configured 🦋psampFilterMatch: if this feature is supported, the Filtering method filterMatch can be configured 🎀psampFilterHash: if this feature is supported, the Filtering method filterHash can be configured 🫶immediateCache: if this feature is supported, a Cache generating PSAMP Packet Reports can be configured using the ImmediateCache class 🌸timeoutCache: if this feature is supported, a Cache generating IPFIX Flow Records can be configured using the TimeoutCache class 🍓naturalCache: if this feature is supported, a Cache generating IPFIX Flow Records can be configured using the NaturalCache class 🧚permanentCache: if this feature is supported, a Cache generating IPFIX Flow Records can be configured using the PermanentCache class 👑
These next features are about support for UDP and TCP as transport protocols, and for File Readers and File Writers 💖
udpTransport: if this feature is supported, UDP can be used as the transport protocol by Exporting Processes and Collecting Processes 🌊tcpTransport: if this feature is supported, TCP can be used as the transport protocol by Exporting Processes and Collecting Processes ✨fileReader: if this feature is supported, File Readers can be configured as part of Collecting Processes 📁fileWriter: if this feature is supported, File Writers can be configured as part of Exporting Processes 💅
The deviation concept lets a device announce how it deviates from the standard model, using the "deviation" statement 🙈 For example, a device can restrict the value range of a specific parameter, or say that configuring a certain parameter isn't supported at all. So deviations are usually how you show limits from resource constraints or functional restrictions. Deviations are about existing parameters of the original configuration data model, and they are NOT the same thing as model extensions. Model extensions use the "augment" statement and add new parameters to the original configuration data model 🫧
If a device has constraints that can't be formally specified in YANG, they MUST be written in human-readable text using the "description" statement 🚨 That information MUST let the user define a configuration that's fully supported by the Monitoring Device. On the other hand, when a Monitoring Device gets configured, it MUST tell the user about any part of the configuration it doesn't support. The Monitoring Device MUST NOT silently accept configuration data that can't be completely enforced 😤 If the NETCONF protocol is used to send configuration data to the Monitoring Device, the error handling is specified in the NETCONF protocol specification [RFC6241] 🧯
Just like features, deviations and model extensions get announced in NETCONF's <hello> message 🎀 A usage example of deviations is given in Section 7.5 💜
6. YANG Module of the IPFIX/PSAMP Configuration Data Model 🧚
okay this part is the actual YANG module 🤩 The module spec for the configuration data model is listed below, and it uses the common YANG types from the modules urn:ietf:params:xml:ns:yang:ietf-yang-types and urn:ietf:params:xml:ns:yang:ietf-inet-types [RFC6021] 💖
<CODE BEGINS> file "ietf-ipfix-psamp@2012-09-05.yang"
module ietf-ipfix-psamp {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp";
prefix ipfix;
import ietf-yang-types { prefix yang; }
import ietf-inet-types { prefix inet; }
organization
"IETF IPFIX Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/ipfix/>
WG List: <ipfix@ietf.org>
WG Chair: Nevil Brownlee
<n.brownlee@auckland.ac.nz>
WG Chair: Juergen Quittek
<quittek@neclab.eu>
Editor: Gerhard Muenz
<muenz@net.in.tum.de>";
description
"IPFIX/PSAMP Configuration Data Model
Copyright (c) 2012 IETF Trust and the persons identified as
the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).";
revision 2012-09-05 {
description "Initial version";
reference "RFC 6728: Configuration Data Model for the IP Flow
Information Export (IPFIX) and Packet Sampling (PSAMP)
Protocols";
}
/*****************************************************************
* Features
*****************************************************************/
feature exporter {
description "If supported, the Monitoring Device can be used as
an Exporter. Exporting Processes can be configured.";
}
feature collector {
description "If supported, the Monitoring Device can be used as
a Collector. Collecting Processes can be configured.";
}okay the feature flags are giving toggle energy, so let's keep going 🎀
feature meter {
description "If supported, Observation Points, Selection
Processes, and Caches can be configured.";
}
feature psampSampCountBased {
description "If supported, the Monitoring Device supports
count-based Sampling. The Selector method sampCountBased can
be configured.";
}
feature psampSampTimeBased {
description "If supported, the Monitoring Device supports
time-based Sampling. The Selector method sampTimeBased can
be configured.";
}
feature psampSampRandOutOfN {
description "If supported, the Monitoring Device supports
random n-out-of-N Sampling. The Selector method
sampRandOutOfN can be configured.";
}
feature psampSampUniProb {
description "If supported, the Monitoring Device supports
uniform probabilistic Sampling. The Selector method
sampUniProb can be configured.";
}
feature psampFilterMatch {
description "If supported, the Monitoring Device supports
property match Filtering. The Selector method filterMatch
can be configured.";
}
feature psampFilterHash {
description "If supported, the Monitoring Device supports
hash-based Filtering. The Selector method filterHash can be
configured.";
}
feature immediateCache {
description "If supported, the Monitoring Device supports
Caches generating PSAMP Packet Reports by configuration with
immediateCache.";
}
feature timeoutCache {
description "If supported, the Monitoring Device supports
Caches generating IPFIX Flow Records by configuration with
timeoutCache.";
}
feature naturalCache {
description "If supported, the Monitoring Device supports
Caches generating IPFIX Flow Records by configuration with
naturalCache.";
}
feature permanentCache {
description "If supported, the Monitoring Device supports
Caches generating IPFIX Flow Records by configuration with
permanentCache.";
}
feature udpTransport {
description "If supported, the Monitoring Device supports UDP
as the transport protocol.";
}
feature tcpTransport {
description "If supported, the Monitoring Device supports TCP
as the transport protocol.";
}
feature fileReader {
description "If supported, the Monitoring Device supports the
configuration of Collecting Processes as File Readers.";
}
feature fileWriter {
description "If supported, the Monitoring Device supports the
configuration of Exporting Processes as File Writers.";
}
/*****************************************************************
* Identities
*****************************************************************/
/*** Hash function identities ***/
identity hashFunction {
description "Base identity for all hash functions used for
hash-based packet Filtering. Identities derived from
this base are used by the leaf
/ipfix/selectionProcess/selector/filterHash/hashFunction.";
}
identity BOB {
base "hashFunction";
description "BOB hash function";
reference "RFC 5475, Section 6.2.4.1.";
}
identity IPSX {
base "hashFunction";
description "IPSX hash function";
reference "RFC 5475, Section 6.2.4.1.";
}
identity CRC {
base "hashFunction";
description "CRC hash function";
reference "RFC 5475, Section 6.2.4.1.";
}
/*** Export mode identities ***/
identity exportMode {
description "Base identity for different usages of export
destinations configured for an Exporting Process.
Identities derived from this base are used by the leaf
/ipfix/exportingProcess/exportMode.";
}
identity parallel {
base "exportMode";
description "Parallel export of Data Records to all
destinations configured for the Exporting Process.";
}
identity loadBalancing {
base "exportMode";
description "Load-balancing between the different destinations
configured for the Exporting Process.";
}
identity fallback {
base "exportMode";
description "Export to the primary destination (i.e., the first
SCTP, UDP, TCP, or file destination configured for the
Exporting Process). If the export to the primary destination
fails, the Exporting Process tries to export to the secondary
destination. If the secondary destination fails as well, it
continues with the tertiary, etc.";
}
/*** Options type identities ***/
identity optionsType {
description "Base identity for report types exported with
options. Identities derived from this base are used by the leaf
/ipfix/exportingProcess/options/optionsType.";
}
identity meteringStatistics {
base "optionsType";
description "Metering Process Statistics.";
reference "RFC 5101, Section 4.1.";
}
identity meteringReliability {
base "optionsType";
description "Metering Process Reliability Statistics.";
reference "RFC 5101, Section 4.2.";
}
identity exportingReliability {
base "optionsType";
description "Exporting Process Reliability
Statistics.";
reference "RFC 5101, Section 4.3.";
}
identity flowKeys {
base "optionsType";
description "Flow Keys.";
reference "RFC 5101, Section 4.4.";
}
identity selectionSequence {
base "optionsType";
description "Selection Sequence and Selector Reports.";
reference "RFC 5476, Sections 6.5.1 and 6.5.2.";
}
identity selectionStatistics {
base "optionsType";
description "Selection Sequence Statistics Report.";
reference "RFC 5476, Sections 6.5.3.";
}
identity accuracy {
base "optionsType";
description "Accuracy Report.";
reference "RFC 5476, Section 6.5.4.";
}
identity reducingRedundancy {
base "optionsType";
description "Enables the utilization of Options Templates to
reduce redundancy in the exported Data Records.";
reference "RFC 5473.";
}
identity extendedTypeInformation {
base "optionsType";
description "Export of extended type information for
enterprise-specific Information Elements used in the
exported Templates.";
reference "RFC 5610.";
}
/*****************************************************************
* Type definitions
*****************************************************************/
typedef ieNameType {
type string {
length "1..max";
pattern "\S+";
}
description "Type for Information Element names. Whitespaces
are not allowed.";
}
typedef ieIdType {
type uint16 {
range "1..32767" {
description "Valid range of Information Element
identifiers.";
reference "RFC 5102, Section 4.";
}
}
description "Type for Information Element identifiers.";
}
typedef nameType {
type string {
length "1..max";
pattern "\S(.*\S)?";
}
description "Type for 'name' leafs, which are used to identify
specific instances within lists, etc.
Leading and trailing whitespaces are not allowed.";
}
typedef ifNameType {
type string {
length "1..255";
}
description "This corresponds to the DisplayString textual
convention of SNMPv2-TC, which is used for ifName in the IF
MIB module.";
reference "RFC 2863 (ifName).";
}
typedef direction {
type enumeration {
enum ingress {
description "This value is used for monitoring incoming
packets.";
}
enum egress {
description "This value is used for monitoring outgoing
packets.";
}
enum both {
description "This value is used for monitoring incoming and
outgoing packets.";
}
}
description "Direction of packets going through an interface or
linecard.";
}
typedef transportSessionStatus {
type enumeration {
enum inactive {
description "This value MUST be used for Transport Sessions
that are specified in the system but currently not active.
The value can be used for Transport Sessions that are
backup (secondary) sessions.";
}
enum active {
description "This value MUST be used for Transport Sessions
that are currently active and transmitting or receiving
data.";
}
enum unknown {
description "This value MUST be used if the status of the
Transport Sessions cannot be detected by the device. This
value should be avoided as far as possible.";
}
}
description "Status of a Transport Session.";
reference "RFC 6615, Section 8 (ipfixTransportSessionStatus).";
}
/*****************************************************************
* Groupings
*****************************************************************/
grouping observationPointParameters {
description "Interface as input to Observation Point.";
leaf observationPointId {
type uint32;
config false;
description "Observation Point ID (i.e., the value of the
Information Element observationPointId) assigned by the
Monitoring Device.";
reference "IANA registry for IPFIX Entities,
http://www.iana.org/assignments/ipfix.";
}
leaf observationDomainId {
🎀 okay bestie, we're still in the YANG module, and this part is all about the Observation Point and Selector settings. Let's gooo 💖
Observation Points get their own identity and interface bindings, and this is where we meet the ifIndex and entPhysicalIndex lists, which come with a little SHOULD 👀
type uint32;
mandatory true;
description "The Observation Domain ID associates the
Observation Point to an Observation Domain. Observation
Points with identical Observation Domain IDs belong to the
same Observation Domain.
Note that this parameter corresponds to
ipfixObservationPointObservationDomainId in the IPFIX MIB
module.";
reference "RFC 5101; RFC 6615, Section 8
(ipfixObservationPointObservationDomainId).";
}
leaf-list ifName {
type ifNameType;
description "List of names identifying interfaces of the
Monitoring Device. The Observation Point observes packets at
the specified interfaces.";
}
leaf-list ifIndex {
type uint32;
description "List of ifIndex values pointing to entries in the
ifTable of the IF-MIB module maintained by the Monitoring
Device. The Observation Point observes packets at the
specified interfaces.
This parameter SHOULD only be used if an SNMP agent enables
access to the ifTable.
Note that this parameter corresponds to
ipfixObservationPointPhysicalInterface in the IPFIX MIB
module.";
reference "RFC 2863; RFC 6615, Section 8
(ipfixObservationPointPhysicalInterface).";
}
leaf-list entPhysicalName {
type string;
description "List of names identifying physical entities of the
Monitoring Device. The Observation Point observes packets at
the specified entities.";
}
leaf-list entPhysicalIndex {
type uint32;
description "List of entPhysicalIndex values pointing to
entries in the entPhysicalTable of the ENTITY-MIB module
maintained by the Monitoring Device. The Observation Point
observes packets at the specified entities.
This parameter SHOULD only be used if an SNMP agent enables
access to the entPhysicalTable.
Note that this parameter corresponds to
ipfixObservationPointPhysicalEntity in the IPFIX MIB
module.";
reference "RFC 4133; RFC 6615, Section 8
(ipfixObservationPointPhysicalInterface).";
}
leaf direction {
type direction;
default both;
description "Direction of packets. If not applicable (e.g., in
the case of a sniffing interface in promiscuous mode), this
parameter is ignored.";
}
}
grouping sampCountBasedParameters {
description "Configuration parameters of a Selector applying
systematic count-based packet Sampling to the packet
stream.";
reference "RFC 5475, Section 5.1; RFC 5476, Section 6.5.2.1.";
leaf packetInterval {
type uint32;
units packets;
mandatory true;
description "The number of packets that are consecutively
sampled between gaps of length packetSpace.
This parameter corresponds to the Information Element
samplingPacketInterval and to psampSampCountBasedInterval
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.2.2; RFC 6727, Section 6
(psampSampCountBasedInterval).";
}
leaf packetSpace {
type uint32;
units packets;
mandatory true;
description "The number of unsampled packets between two
Sampling intervals.
This parameter corresponds to the Information Element
samplingPacketSpace and to psampSampCountBasedSpace
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.2.3; RFC 6727, Section 6
(psampSampCountBasedSpace).";
}
}
grouping sampTimeBasedParameters {
description "Configuration parameters of a Selector applying
systematic time-based packet Sampling to the packet
stream.";
reference "RFC 5475, Section 5.1; RFC 5476, Section 6.5.2.2.";
leaf timeInterval {
type uint32;
units microseconds;
mandatory true;
description "The time interval in microseconds during
which all arriving packets are sampled between gaps
of length timeSpace.
This parameter corresponds to the Information Element
samplingTimeInterval and to psampSampTimeBasedInterval
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.2.4; RFC 6727, Section 6
(psampSampTimeBasedInterval).";
}
leaf timeSpace {
type uint32;
units microseconds;
mandatory true;
description "The time interval in microseconds during
which no packets are sampled between two Sampling
intervals specified by timeInterval.
This parameter corresponds to the Information Element
samplingTimeInterval and to psampSampTimeBasedSpace
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.2.5; RFC 6727, Section 6
(psampSampTimeBasedSpace).";
}
}
grouping sampRandOutOfNParameters {
description "Configuration parameters of a Selector applying
n-out-of-N packet Sampling to the packet stream.";
reference "RFC 5475, Section 5.2.1; RFC 5476, Section 6.5.2.3.";
leaf size {
type uint32;
units packets;
mandatory true;
description "The number of elements taken from the parent
population.
This parameter corresponds to the Information Element
samplingSize and to psampSampRandOutOfNSize in the PSAMP
MIB module.";
reference "RFC 5477, Section 8.2.6; RFC 6727, Section 6
(psampSampRandOutOfNSize).";
}
leaf population {
type uint32;
units packets;
mandatory true;
description "The number of elements in the parent
population.
This parameter corresponds to the Information Element
samplingPopulation and to psampSampRandOutOfNPopulation
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.2.7; RFC 6727, Section 6
(psampSampRandOutOfNPopulation).";
}
}
grouping sampUniProbParameters {
description "Configuration parameters of a Selector applying
uniform probabilistic packet Sampling (with equal
probability per packet) to the packet stream.";
reference "RFC 5475, Section 5.2.2.1;
RFC 5476, Section 6.5.2.4.";
leaf probability {
type decimal64 {
fraction-digits 18;
range "0..1";
}
mandatory true;
description "Probability that a packet is sampled,
expressed as a value between 0 and 1. The probability
is equal for every packet.
This parameter corresponds to the Information Element
samplingProbability and to psampSampUniProbProbability
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.2.8; RFC 6727, Section 6
(psampSampUniProbProbability).";
}
}
grouping filterMatchParameters {
description "Configuration parameters of a Selector applying
property match Filtering to the packet stream.
The field to be matched is specified as an Information
Element.";
reference "RFC 5475, Section 6.1; RFC 5476, Section 6.5.2.5.";
choice nameOrId {
mandatory true;
description "The field to be matched is specified by
either the name or the identifier of the Information
Element.";
leaf ieName {
type ieNameType;
description "Name of the Information Element.";
}
leaf ieId {
type ieIdType;
description "Identifier of the Information Element.";
}
}
leaf ieEnterpriseNumber {
type uint32;
default 0;
description "If this parameter is zero, the Information
Element is registered in the IANA registry of IPFIX
Information Elements.
If this parameter is configured with a non-zero private
enterprise number, the Information Element is
enterprise-specific.";
reference "IANA registry for Private Enterprise Numbers,
http://www.iana.org/assignments/enterprise-numbers;
IANA registry for IPFIX Entities,
http://www.iana.org/assignments/ipfix.";
}
leaf value {
type string;
mandatory true;
description "Matching value of the Information Element.";
}
}
grouping filterHashParameters {
description "Configuration parameters of a Selector applying
hash-based Filtering to the packet stream.";
reference "RFC 5475, Section 6.2; RFC 5476, Section 6.5.2.6.";
leaf hashFunction {
type identityref {
base "hashFunction";
}
default BOB;
description "Hash function to be applied. According to
RFC 5475, Section 6.2.4.1, 'BOB' must be used in order to
be compliant with PSAMP.
This parameter functionally corresponds to
psampFiltHashFunction in the PSAMP MIB module.";
reference "RFC 6727, Section 6 (psampFiltHashFunction)";
}
leaf initializerValue {
type uint64;
description "Initializer value to the hash function.
If not configured by the user, the Monitoring Device
arbitrarily chooses an initializer value.
This parameter corresponds to the Information Element
hashInitialiserValue and to psampFiltHashInitializerValue
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.3.9; RFC 6727, Section 6
(psampFiltHashInitializerValue).";
}
leaf ipPayloadOffset {
type uint64;
units octets;
default 0;
description "IP payload offset indicating the position of
the first payload byte considered as input to the hash
function.
Default value 0 corresponds to the minimum offset that
must be configurable according to RFC 5476, Section
6.5.2.6.
This parameter corresponds to the Information Element
hashIPPayloadOffset and to psampFiltHashIpPayloadOffset
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.3.2; RFC 6727, Section 6
(psampFiltHashIpPayloadOffset).";
}
leaf ipPayloadSize {
type uint64;
units octets;
default 8;
description "Number of IP payload bytes used as input to
the hash function, counted from the payload offset.
If the IP payload is shorter than the payload range,
all available payload octets are used as input.
Default value 8 corresponds to the minimum IP payload
size that must be configurable according to RFC 5476,
Section 6.5.2.6.
This parameter corresponds to the Information Element
hashIPPayloadSize and to psampFiltHashIpPayloadSize
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.3.3; RFC 6727, Section 6
(psampFiltHashIpPayloadSize).";
}
leaf digestOutput {
type boolean;
default false;
description "If true, the output from this Selector is
included in the Packet Report as a packet digest.
Therefore, the configured Cache Layout needs to contain
a digestHashValue field.
This parameter corresponds to the Information Element
hashDigestOutput.";okay so we're still deep in the hash filter bit of the YANG module 🦋 the hash range leaves keep going, then the selector parameters show up with the whole menu of selection methods 💅
reference "RFC 5477, Section 8.3.8.";
}
leaf outputRangeMin {
type uint64;
config false;
description "Beginning of the hash function's potential
range.
This parameter corresponds to the Information Element
hashOutputRangeMin and to psampFiltHashOutputRangeMin
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.3.4; RFC 6727, Section 6
(psampFiltHashOutputRangeMin).";
}
leaf outputRangeMax {
type uint64;
config false;
description "End of the hash function's potential range.
This parameter corresponds to the Information Element
hashOutputRangeMax and to psampFiltHashOutputRangeMax
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.3.5; RFC 6727, Section 6
(psampFiltHashOutputRangeMax).";
}
list selectedRange {
key name;
min-elements 1;
description "List of hash function return ranges for
which packets are selected.";
leaf name {
type nameType;
description "Key of this list.";
}
leaf min {
type uint64;
description "Beginning of the hash function's selected
range.
This parameter corresponds to the Information Element
hashSelectedRangeMin and to psampFiltHashSelectedRangeMin
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.3.6; RFC 6727, Section 6
(psampFiltHashSelectedRangeMin).";
}
leaf max {
type uint64;
description "End of the hash function's selected range.
This parameter corresponds to the Information Element
hashSelectedRangeMax and to psampFiltHashSelectedRangeMax
in the PSAMP MIB module.";
reference "RFC 5477, Section 8.3.7; RFC 6727, Section 6
(psampFiltHashSelectedRangeMax).";
}
}
}
grouping selectorParameters {
description "Configuration and state parameters of a Selector.";
choice Method {
mandatory true;
description "Packet selection method applied by the Selector.";
leaf selectAll {
type empty;
description "Method that selects all packets.";
}
container sampCountBased {
if-feature psampSampCountBased;
description "Systematic count-based packet Sampling.";
uses sampCountBasedParameters;
}
container sampTimeBased {
if-feature psampSampTimeBased;
description "Systematic time-based packet Sampling.";
uses sampTimeBasedParameters;
}
container sampRandOutOfN {
if-feature psampSampRandOutOfN;
description "n-out-of-N packet Sampling.";
uses sampRandOutOfNParameters;
}
container sampUniProb {
if-feature psampSampUniProb;
description "Uniform probabilistic packet Sampling.";
uses sampUniProbParameters;
}
container filterMatch {
if-feature psampFilterMatch;
description "Property match Filtering.";
uses filterMatchParameters;
}
container filterHash {
if-feature psampFilterHash;
description "Hash-based Filtering.";
uses filterHashParameters;
}
}
leaf packetsObserved {
type yang:counter64;
config false;
description "The number of packets observed at the input of
the Selector.
If this is the first Selector in the Selection Process,
this counter corresponds to the total number of packets in
all Observed Packet Streams at the input of the Selection
Process. Otherwise, the counter corresponds to the total
number of packets at the output of the preceding Selector.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
selectorDiscontinuityTime.
Note that this parameter corresponds to
ipfixSelectorStatsPacketsObserved in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixSelectorStatsPacketsObserved).";
}
leaf packetsDropped {
type yang:counter64;
config false;
description "The total number of packets discarded by the
Selector.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
selectorDiscontinuityTime.
Note that this parameter corresponds to
ipfixSelectorStatsPacketsDropped in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixSelectorStatsPacketsDropped).";
}
leaf selectorDiscontinuityTime {
type yang:date-and-time;
config false;
description "Timestamp of the most recent occasion at which
one or more of the Selector counters suffered a
discontinuity.
Note that this parameter functionally corresponds to
ipfixSelectionProcessStatsDiscontinuityTime in the IPFIX
MIB module. In contrast to
ipfixSelectionProcessStatsDiscontinuityTime, the time is
absolute and not relative to sysUpTime.";
reference "RFC 6615, Section 8
(ipfixSelectionProcessStatsDiscontinuityTime).";
}
}the selector counters are all read-only (config false) 📊 and they tell you how many packets came in, how many got dropped, and when the counters last got a reset ✨ next up is the cache layout, which is basically the list of fields a cache is allowed to put in its records 🎀
grouping cacheLayoutParameters {
description "Cache Layout parameters used by immediateCache,
timeoutCache, naturalCache, and permanentCache.";
container cacheLayout {
description "Cache Layout parameters.";
list cacheField {
key name;
min-elements 1;
description "Superset of fields that are included in the
Packet Reports or Flow Records generated by the Cache.";
leaf name {
type nameType;
description "Key of this list.";
}
choice nameOrId {
mandatory true;
description "Name or identifier of the Information
Element.";
reference "RFC 5102, Section 2; IANA registry for IPFIX
Entities, http://www.iana.org/assignments/ipfix.";
leaf ieName {
type ieNameType;
description "Name of the Information Element.";
}
leaf ieId {
type ieIdType;
description "Identifier of the Information Element.";
}
}
leaf ieLength {
type uint16;
units octets;
description "Length of the field in which the Information
Element is encoded. A value of 65535 specifies a
variable-length Information Element. For Information
Elements of integer and float type, the field length MAY
be set to a smaller value than the standard length of
the abstract data type if the rules of reduced size
encoding are fulfilled.
If not configured by the user, this parameter is set by
the Monitoring Device.";
reference "RFC 5101, Section 6.2.";
}
leaf ieEnterpriseNumber {
type uint32;
default 0;
description "If this parameter is zero, the Information
Element is registered in the IANA registry of IPFIX
Information Elements.
If this parameter is configured with a non-zero private
enterprise number, the Information Element is
enterprise-specific.
If the enterprise number is set to 29305, this field
contains a Reverse Information Element. In this case,
the Cache MUST generate Data Records in accordance to
RFC 5103.";
reference "RFC 5101; RFC 5103;
IANA registry for Private Enterprise Numbers,
http://www.iana.org/assignments/enterprise-numbers;
IANA registry for IPFIX Entities,
http://www.iana.org/assignments/ipfix.";
}
leaf isFlowKey {
when "(name(../../..) != 'immediateCache')
and
((count(../ieEnterpriseNumber) = 0)
or
(../ieEnterpriseNumber != 29305))" {
description "This parameter is not available for
Reverse Information Elements (which have enterprise
number 29305). It is also not available for
immediateCache.";
}
type empty;
description "If present, this is a flow key.";
}
}
}
}last bit for this part: the flow cache grouping has started, and the first thing it configures is how many flows the cache can hold at once 🌈👑
grouping flowCacheParameters {
description "Configuration and state parameters of a Cache
generating Flow Records.";
leaf maxFlows {
type uint32;
units flows;
description "This parameter configures the maximum number of
Flows in the Cache, which is the maximum number of Flows
that can be measured simultaneously.
The Monitoring Device MUST ensure that sufficient resources
are available to store the configured maximum number of
Flows.
If the maximum number of Flows is measured, an additional
Flow can be measured only if an existing entry is removed.
However, traffic that pertains to existing Flows can
continue to be measured.";} leaf activeTimeout { when "(name(..) = 'timeoutCache') or (name(..) = 'naturalCache')" { description "This parameter is only available for timeoutCache and naturalCache."; } type uint32; units seconds; description "This parameter configures the time in seconds after which a Flow is expired even though packets matching this Flow are still received by the Cache. The parameter value zero indicates infinity, meaning that there is no active timeout. If not configured by the user, the Monitoring Device sets this parameter. Note that this parameter corresponds to ipfixMeteringProcessCacheActiveTimeout in the IPFIX MIB module."; reference "RFC 6615, Section 8 (ipfixMeteringProcessCacheActiveTimeout)."; } leaf idleTimeout { when "(name(..) = 'timeoutCache') or (name(..) = 'naturalCache')" { description "This parameter is only available for timeoutCache and naturalCache."; } type uint32; units seconds; description "This parameter configures the time in seconds after which a Flow is expired if no more packets matching this Flow are received by the Cache. The parameter value zero indicates infinity, meaning that there is no idle timeout. If not configured by the user, the Monitoring Device sets this parameter. Note that this parameter corresponds to ipfixMeteringProcessCacheIdleTimeout in the IPFIX MIB module."; reference "RFC 6615, Section 8 (ipfixMeteringProcessCacheIdleTimeout)."; } leaf exportInterval { when "name(..) = 'permanentCache'" { description "This parameter is only available for permanentCache."; } type uint32; units seconds; description "This parameter configures the interval (in seconds) for periodical export of Flow Records. If not configured by the user, the Monitoring Device sets this parameter."; } leaf activeFlows { type yang:gauge32; units flows; config false; description "The number of Flows currently active in this Cache. Note that this parameter corresponds to ipfixMeteringProcessCacheActiveFlows in the IPFIX MIB module."; reference "RFC 6615, Section 8 (ipfixMeteringProcessCacheActiveFlows)."; } leaf unusedCacheEntries { type yang:gauge32; units flows; config false; description "The number of unused Cache entries in this Cache. Note that this parameter corresponds to ipfixMeteringProcessCacheUnusedCacheEntries in the IPFIX MIB module."; reference "RFC 6615, Section 8 (ipfixMeteringProcessCacheUnusedCacheEntries)."; } }
grouping exportingProcessParameters { description "Parameters of an Exporting Process."; leaf exportingProcessId { type uint32; config false; description "The identifier of the Exporting Process. This parameter corresponds to the Information Element exportingProcessId. Its occurrence helps to associate Exporting Process parameters with Exporing Process statistics exported by the Monitoring Device using the Exporting Process Reliability Statistics Template as defined by the IPFIX protocol specification."; reference "RFC 5101, Section 4.3; IANA registry for IPFIX Entities, http://www.iana.org/assignments/ipfix."; } leaf exportMode { type identityref { base "exportMode"; } default parallel; description "This parameter determines to which configured destination(s) the incoming Data Records are exported."; } list destination { key name; min-elements 1; description "List of export destinations."; leaf name { type nameType; description "Key of this list."; } choice DestinationParameters { mandatory true; description "Configuration parameters depend on whether SCTP, UDP, or TCP is used as transport protocol, and whether the destination is a file."; container sctpExporter { description "SCTP parameters."; uses sctpExporterParameters; } container udpExporter { if-feature udpTransport; description "UDP parameters."; uses udpExporterParameters; } container tcpExporter { if-feature tcpTransport; description "TCP parameters."; uses tcpExporterParameters; } container fileWriter { if-feature fileWriter; description "File Writer parameters."; uses fileWriterParameters; } } } list options { key name; description "List of options reported by the Exporting Process."; leaf name { type nameType; description "Key of this list."; } uses optionsParameters; } }
grouping commonExporterParameters { description "Parameters of en export destination that are common to all transport protocols."; leaf ipfixVersion { type uint16; default 10; description "IPFIX version number."; reference "RFC 5101."; } leaf destinationPort { type inet:port-number; description "If not configured by the user, the Monitoring Device uses the default port number for IPFIX, which is 4739 without TLS or DTLS and 4740 if TLS or DTLS is activated."; } choice indexOrName { description "Index or name of the interface as stored in the ifTable of IF-MIB. If configured, the Exporting Process MUST use the given interface to export IPFIX Messages to the export destination. If omitted, the Exporting Process selects the outgoing interface based on local routing decision and accepts return traffic, such as transport-layer acknowledgments, on all available interfaces."; reference "RFC 2863."; leaf ifIndex { type uint32; description "Index of an interface as stored in the ifTable of IF-MIB."; reference "RFC 2863."; } leaf ifName { type string; description "Name of an interface as stored in the ifTable of IF-MIB."; reference "RFC 2863."; } } leaf sendBufferSize { type uint32; units bytes; description "Size of the socket send buffer. If not configured by the user, this parameter is set by the Monitoring Device."; } leaf rateLimit { type uint32; units "bytes per second"; description "Maximum number of bytes per second the Exporting Process may export to the given destination. The number of bytes is calculated from the lengths of the IPFIX Messages exported. If not configured, no rate limiting is performed."; reference "RFC 5476, Section 6.3."; } container transportLayerSecurity { presence "If transportLayerSecurity is present, DTLS is enabled if the transport protocol is SCTP or UDP, and TLS is enabled if the transport protocol is TCP."; description "TLS or DTLS configuration."; uses transportLayerSecurityParameters; } container transportSession { config false; description "State parameters of the Transport Session directed to the given destination."; uses transportSessionParameters; } }
grouping sctpExporterParameters { description "SCTP-specific export destination parameters."; uses commonExporterParameters; leaf-list sourceIPAddress { type inet:ip-address; description "List of source IP addresses used by the Exporting Process. If configured, the specified addresses are eligible local IP addresses of the multihomed SCTP endpoint. If not configured, all locally assigned IP addresses are eligible local IP addresses."; reference "RFC 4960, Section 6.4."; } leaf-list destinationIPAddress { type inet:ip-address; min-elements 1; description "One or more IP addresses of the Collecting Process to which IPFIX Messages are sent. The user MUST ensure that all configured IP addresses belong to the same Collecting Process. The Exporting Process tries to establish an SCTP association to any of the configured destination IP addresses."; reference "RFC 4960, Section 6.4."; } leaf timedReliability { type uint32; units milliseconds; default 0; description "Lifetime in milliseconds until an IPFIX Message containing Data Sets only is 'abandoned' due to the timed reliability mechanism of PR-SCTP. If this parameter is set to zero, reliable SCTP transport is used for all Data Records. Regardless of the value of this parameter, the Exporting Process MAY use reliable SCTP transport for Data Sets associated with Options Templates."; reference "RFC 3758; RFC 4960."; } }
grouping udpExporterParameters { description "Parameters of a UDP export destination."; uses commonExporterParameters; leaf sourceIPAddress { type inet:ip-address; description "Source IP address used by the Exporting Process. If not configured, the IP address assigned to the outgoing interface is used as source IP address."; } leaf destinationIPAddress { type inet:ip-address; mandatory true; description "IP address of the Collection Process to which IPFIX Messages are sent."; } leaf maxPacketSize { type uint16; units octets; description "This parameter specifies the maximum size of IP packets sent to the Collector. If set to zero, the Exporting Device MUST derive the maximum packet size from path MTU discovery mechanisms. If not configured by the user, this parameter is set by the Monitoring Device."; } leaf templateRefreshTimeout {
okay bestie, this is the refresh-timer and collector zone, and it's giving "set it and forget it" 💅🌸 Templates get resent on a timer or after a packet count, and the collector side has its own sockets and file readers 🦋
type uint32;
units seconds;
default 600;
description "Sets time after which Templates are resent in the
UDP Transport Session.
Note that the configured lifetime MUST be adapted to the
templateLifeTime parameter value at the receiving Collecting
Process.
Note that this parameter corresponds to
ipfixTransportSessionTemplateRefreshTimeout in the IPFIX
MIB module.";
reference "RFC 5101, Section 10.3.6; RFC 6615, Section 8
(ipfixTransportSessionTemplateRefreshTimeout).";
}
leaf optionsTemplateRefreshTimeout {
type uint32;
units seconds;
default 600;
description "Sets time after which Options Templates are
resent in the UDP Transport Session.
Note that the configured lifetime MUST be adapted to the
optionsTemplateLifeTime parameter value at the receiving
Collecting Process.
Note that this parameter corresponds to
ipfixTransportSessionOptionsTemplateRefreshTimeout in the
IPFIX MIB module.";
reference "RFC 5101, Section 10.3.6; RFC 6615, Section 8
(ipfixTransportSessionOptionsTemplateRefreshTimeout).";
}
leaf templateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Templates are resent in the UDP Transport Session.
Note that this parameter corresponds to
ipfixTransportSessionTemplateRefreshPacket in the IPFIX
MIB module.
If omitted, Templates are only resent after timeout.";
reference "RFC 5101, Section 10.3.6; RFC 6615, Section 8
(ipfixTransportSessionTemplateRefreshPacket).";
}
leaf optionsTemplateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Options Templates are resent in the UDP Transport Session
protocol.
Note that this parameter corresponds to
ipfixTransportSessionOptionsTemplateRefreshPacket in the
IPFIX MIB module.
If omitted, Templates are only resent after timeout.";
reference "RFC 5101, Section 10.3.6; RFC 6615, Section 8
(ipfixTransportSessionOptionsTemplateRefreshPacket).";
}
}
grouping tcpExporterParameters {
description "Parameters of a TCP export destination.";
uses commonExporterParameters;
leaf sourceIPAddress {
type inet:ip-address;
description "Source IP address used by the Exporting Process.
If not configured by the user, this parameter is set by
the Monitoring Device to an IP address assigned to the
outgoing interface.";
}
leaf destinationIPAddress {
type inet:ip-address;
mandatory true;
description "IP address of the Collection Process to which
IPFIX Messages are sent.";
}
}
grouping fileWriterParameters {
description "File Writer parameters.";
leaf ipfixVersion {
type uint16;
default 10;
description "IPFIX version number.";
reference "RFC 5101.";
}
leaf file {
type inet:uri;
mandatory true;
description "URI specifying the location of the file.";
}
leaf bytes {
type yang:counter64;
units octets;
config false;
description "The number of bytes written by the File Writer.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
fileWriterDiscontinuityTime.";
}
leaf messages {
type yang:counter64;
units "IPFIX Messages";
config false;
description "The number of IPFIX Messages written by the File
Writer.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
fileWriterDiscontinuityTime.";
}
leaf discardedMessages {
type yang:counter64;
units "IPFIX Messages";
config false;
description "The number of IPFIX Messages that could not be
written by the File Writer due to internal buffer
overflows, limited storage capacity, etc.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
fileWriterDiscontinuityTime.";
}
leaf records {
type yang:counter64;
units "Data Records";
config false;
description "The number of Data Records written by the File
Writer.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
fileWriterDiscontinuityTime.";
}
leaf templates {
type yang:counter32;
units "Templates";
config false;
description "The number of Template Records (excluding
Options Template Records) written by the File Writer.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
fileWriterDiscontinuityTime.";
}
leaf optionsTemplates {
type yang:counter32;
units "Options Templates";
config false;
description "The number of Options Template Records written
by the File Writer.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
fileWriterDiscontinuityTime.";
}
leaf fileWriterDiscontinuityTime {
type yang:date-and-time;
config false;
description "Timestamp of the most recent occasion at which
one or more File Writer counters suffered a discontinuity.
In contrast to discontinuity times in the IPFIX MIB module,
the time is absolute and not relative to sysUpTime.";
}
list template {
config false;
description "This list contains the Templates and Options
Templates that have been written by the File Reader.
Withdrawn or invalidated (Options) Templates MUST be removed
from this list.";
uses templateParameters;
}
}
grouping optionsParameters {
description "Parameters specifying the data export using an
Options Template.";
leaf optionsType {
type identityref {
base "optionsType";
}
mandatory true;
description "Type of the exported options data.";
}
leaf optionsTimeout {
type uint32;
units milliseconds;
description "Time interval for periodic export of the options
data. If set to zero, the export is triggered when the
options data has changed.
If not configured by the user, this parameter is set by the
Monitoring Device.";
}
}
grouping collectingProcessParameters {
description "Parameters of a Collecting Process.";
list sctpCollector {
key name;
description "List of SCTP receivers (sockets) on which the
Collecting Process receives IPFIX Messages.";
leaf name {
type nameType;
description "Key of this list.";
}
uses sctpCollectorParameters;
}
list udpCollector {
if-feature udpTransport;
key name;
description "List of UDP receivers (sockets) on which the
Collecting Process receives IPFIX Messages.";
leaf name {
type nameType;
description "Key of this list.";
}
uses udpCollectorParameters;
}
list tcpCollector {
if-feature tcpTransport;
key name;
description "List of TCP receivers (sockets) on which the
Collecting Process receives IPFIX Messages.";
leaf name {
type nameType;
description "Key of this list.";
}
uses tcpCollectorParameters;
}
list fileReader {
if-feature fileReader;
key name;
description "List of File Readers from which the Collecting
Process reads IPFIX Messages.";
leaf name {
type nameType;
description "Key of this list.";
}
uses fileReaderParameters;
}
}
grouping commonCollectorParameters {
description "Parameters of a Collecting Process that are
common to all transport protocols.";
leaf localPort {
type inet:port-number;
description "If not configured, the Monitoring Device uses the
default port number for IPFIX, which is 4739 without
TLS or DTLS and 4740 if TLS or DTLS is activated.";
}
container transportLayerSecurity {
presence "If transportLayerSecurity is present, DTLS is enabled
if the transport protocol is SCTP or UDP, and TLS is enabled
if the transport protocol is TCP.";
description "TLS or DTLS configuration.";
uses transportLayerSecurityParameters;
}
list transportSession {
config false;
description "This list contains the currently established
Transport Sessions terminating at the given socket.";
uses transportSessionParameters;
}
}
grouping sctpCollectorParameters {
description "Parameters of a listening SCTP socket at a
Collecting Process.";
uses commonCollectorParameters;
leaf-list localIPAddress {
type inet:ip-address;
description "List of local IP addresses on which the
Collecting Process listens for IPFIX Messages. The IP
addresses are used as eligible local IP addresses of the
multihomed SCTP endpoint.";
reference "RFC 4960, Section 6.4.";
}
}so the vibe check here is the timers are all about keeping templates fresh 🧚 and the file writer tracks every single counter it touches, like a little diary 📓 the collecting side is literally where the sockets live, so the listening bits go there 💜
grouping udpCollectorParameters { description "Parameters of a listening UDP socket at a Collecting Process."; uses commonCollectorParameters; leaf-list localIPAddress { type inet:ip-address; description "List of local IP addresses on which the Collecting Process listens for IPFIX Messages."; } leaf templateLifeTime { type uint32; units seconds; default 1800; description "Sets the lifetime of Templates for all UDP Transport Sessions terminating at this UDP socket. Templates that are not received again within the configured lifetime become invalid at the Collecting Process. As specified in RFC 5101, the Template lifetime MUST be at least three times higher than the templateRefreshTimeout parameter value configured on the corresponding Exporting Processes. Note that this parameter corresponds to ipfixTransportSessionTemplateRefreshTimeout in the IPFIX MIB module."; reference "RFC 5101, Section 10.3.7; RFC 6615, Section 8 (ipfixTransportSessionTemplateRefreshTimeout)."; } leaf optionsTemplateLifeTime { type uint32; units seconds; default 1800; description "Sets the lifetime of Options Templates for all UDP Transport Sessions terminating at this UDP socket. Options Templates that are not received again within the configured lifetime become invalid at the Collecting Process. As specified in RFC 5101, the Options Template lifetime MUST be at least three times higher than the optionsTemplateRefreshTimeout parameter value configured on the corresponding Exporting Processes. Note that this parameter corresponds to ipfixTransportSessionOptionsTemplateRefreshTimeout in the IPFIX MIB module."; reference "RFC 5101, Section 10.3.7; RFC 6615, Section 8 (ipfixTransportSessionOptionsTemplateRefreshTimeout)."; } leaf templateLifePacket { type uint32; units "IPFIX Messages"; description "If this parameter is configured, Templates defined in a UDP Transport Session become invalid if they are neither included in a sequence of more than this number of IPFIX Messages nor received again within the period of time specified by templateLifeTime. Note that this parameter corresponds to ipfixTransportSessionTemplateRefreshPacket in the IPFIX MIB module."; reference "RFC 5101, Section 10.3.7; RFC 6615, Section 8 (ipfixTransportSessionTemplateRefreshPacket).";
} leaf optionsTemplateLifePacket { type uint32; units "IPFIX Messages"; description "If this parameter is configured, Options Templates defined in a UDP Transport Session become invalid if they are neither included in a sequence of more than this number of IPFIX Messages nor received again within the period of time specified by optionsTemplateLifeTime. Note that this parameter corresponds to ipfixTransportSessionOptionsTemplateRefreshPacket in the IPFIX MIB module."; reference "RFC 5101, Section 10.3.7; RFC 6615, Section 8 (ipfixTransportSessionOptionsTemplateRefreshPacket)."; } }
grouping tcpCollectorParameters { description "Parameters of a listening TCP socket at a Collecting Process."; uses commonCollectorParameters; leaf-list localIPAddress { type inet:ip-address; description "List of local IP addresses on which the Collecting Process listens for IPFIX Messages."; } }
grouping fileReaderParameters { description "File Reader parameters."; leaf file { type inet:uri; mandatory true; description "URI specifying the location of the file."; } leaf bytes { type yang:counter64; units octets; config false; description "The number of bytes read by the File Reader. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of fileReaderDiscontinuityTime."; } leaf messages { type yang:counter64; units "IPFIX Messages"; config false; description "The number of IPFIX Messages read by the File Reader. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of fileReaderDiscontinuityTime."; } leaf records { type yang:counter64; units "Data Records"; config false; description "The number of Data Records read by the File Reader. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of fileReaderDiscontinuityTime."; } leaf templates { type yang:counter32; units "Templates"; config false; description "The number of Template Records (excluding Options Template Records) read by the File Reader. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of fileReaderDiscontinuityTime."; } leaf optionsTemplates { type yang:counter32; units "Options Templates"; config false; description "The number of Options Template Records read by the File Reader. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of fileReaderDiscontinuityTime."; } leaf fileReaderDiscontinuityTime { type yang:date-and-time; config false; description "Timestamp of the most recent occasion at which one or more File Reader counters suffered a discontinuity. In contrast to discontinuity times in the IPFIX MIB module, the time is absolute and not relative to sysUpTime."; } list template { config false; description "This list contains the Templates and Options Templates that have been read by the File Reader. Withdrawn or invalidated (Options) Template MUST be removed from this list."; uses templateParameters; } }
grouping transportLayerSecurityParameters { description "TLS or DTLS parameters."; leaf-list localCertificationAuthorityDN { type string; description "Distinguished names of certification authorities whose certificates may be used to identify the local endpoint."; reference "RFC 5280."; } leaf-list localSubjectDN { type string; description "Distinguished names that may be used in the certificates to identify the local endpoint."; reference "RFC 5280."; } leaf-list localSubjectFQDN { type inet:domain-name; description "Fully qualified domain names that may be used to in the certificates to identify the local endpoint."; reference "RFC 5280."; } leaf-list remoteCertificationAuthorityDN { type string; description "Distinguished names of certification authorities whose certificates are accepted to authorize remote endpoints."; reference "RFC 5280."; } leaf-list remoteSubjectDN { type string; description "Distinguished names which are accepted in certificates to authorize remote endpoints."; reference "RFC 5280."; } leaf-list remoteSubjectFQDN { type inet:domain-name; description "Fully qualified domain names that are accepted in certificates to authorize remote endpoints."; reference "RFC 5280."; } }
grouping templateParameters { description "State parameters of a Template used by an Exporting Process or received by a Collecting Process in a specific Transport Session. Parameter names and semantics correspond to the managed objects in IPFIX-MIB"; reference "RFC 5101; RFC 6615, Section 8 (ipfixTemplateEntry, ipfixTemplateDefinitionEntry, ipfixTemplateStatsEntry)"; leaf observationDomainId { type uint32; description "The ID of the Observation Domain for which this Template is defined. Note that this parameter corresponds to ipfixTemplateObservationDomainId in the IPFIX MIB module."; reference "RFC 6615, Section 8 (ipfixTemplateObservationDomainId)."; } leaf templateId { type uint16 { range "256..65535" { description "Valid range of Template IDs."; reference "RFC 5101"; } } description "This number indicates the Template ID in the IPFIX message. Note that this parameter corresponds to ipfixTemplateId in the IPFIX MIB module."; reference "RFC 6615, Section 8 (ipfixTemplateId)."; } leaf setId { type uint16; description "This number indicates the Set ID of the Template. Currently, there are two values defined. The value 2 is used for Sets containing Template definitions. The value 3 is used for Sets containing Options Template definitions. Note that this parameter corresponds to ipfixTemplateSetId in the IPFIX MIB module."; reference "RFC 6615, Section 8 (ipfixTemplateSetId)."; } leaf accessTime { type yang:date-and-time; description "Used for Exporting Processes, this parameter
okay the YANG grouping is where the transport session stuff lives, and it's giving main character energy 💅✨
contains the time when this (Options) Template was last
sent to the Collector(s) or written to the file.
Used for Collecting Processes, this parameter contains the
time when this (Options) Template was last received from the
Exporter or read from the file.
Note that this parameter corresponds to
ipfixTemplateAccessTime in the IPFIX MIB module.";
reference "RFC 6615, Section 8 (ipfixTemplateAccessTime).";
}
leaf templateDataRecords {
type yang:counter64;
description "The number of transmitted or received Data
Records defined by this (Options) Template.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
templateDiscontinuityTime.
Note that this parameter corresponds to
ipfixTemplateDataRecords in the IPFIX MIB module.";
reference "RFC 6615, Section 8 (ipfixTemplateDataRecords).";
}
leaf templateDiscontinuityTime {
type yang:date-and-time;
description "Timestamp of the most recent occasion at which
the counter templateDataRecords suffered a discontinuity.
Note that this parameter functionally corresponds to
ipfixTemplateDiscontinuityTime in the IPFIX MIB module.
In contrast to ipfixTemplateDiscontinuityTime, the time
is absolute and not relative to sysUpTime.";
reference "RFC 6615, Section 8
(ipfixTemplateDiscontinuityTime).";
}
list field {
description "This list contains the (Options) Template
fields of which the (Options) Template is defined.
The order of the list corresponds to the order of the fields
in the (Option) Template Record.";
leaf ieId {
type ieIdType;
description "This parameter indicates the Information
Element identifier of the field.
Note that this parameter corresponds to
ipfixTemplateDefinitionIeId in the IPFIX MIB module.";
reference "RFC 5101; RFC 6615, Section 8
(ipfixTemplateDefinitionIeId).";
}
leaf ieLength {
type uint16;
units octets;
description "This parameter indicates the length of the
Information Element of the field.
Note that this parameter corresponds to
ipfixTemplateDefinitionIeLength in the IPFIX MIB
module.";
reference "RFC 5101; RFC 6615, Section 8
(ipfixTemplateDefinitionIeLength).";
}
leaf ieEnterpriseNumber {
type uint32;
description "This parameter indicates the IANA enterprise
number of the authority defining the Information Element
identifier.
If the Information Element is not enterprise-specific,
this state parameter is zero.
Note that this parameter corresponds to
ipfixTemplateDefinitionIeEnterpriseNumber in the IPFIX
MIB module.";
reference "RFC 6615, Section 8
(ipfixTemplateDefinitionIeEnterpriseNumber);
IANA registry for Private Enterprise Numbers,
http://www.iana.org/assignments/enterprise-numbers.";
}
leaf isFlowKey {
when "../../setId = 2" {
description "This parameter is available for non-Options
Templates (Set ID is 2).";
}
type empty;
description "If present, this is a Flow Key field.
Note that this corresponds to flowKey(1) being set in
ipfixTemplateDefinitionFlags.";
reference "RFC 6615, Section 8
(ipfixTemplateDefinitionFlags).";
}
leaf isScope {
when "../../setId = 3" {
description "This parameter is available for Options
Templates (Set ID is 3).";
}
type empty;
description "If present, this is a scope field.
Note that this corresponds to scope(0) being set in
ipfixTemplateDefinitionFlags.";
reference "RFC 6615, Section 8
(ipfixTemplateDefinitionFlags).";
}
}
}
grouping transportSessionParameters {
description "State parameters of a Transport Session originating
from an Exporting Process or terminating at a Collecting
Process. Parameter names and semantics correspond to the
managed objects in IPFIX-MIB.";
reference "RFC 5101; RFC 6615, Section 8
(ipfixTransportSessionEntry,
ipfixTransportSessionStatsEntry).";
leaf ipfixVersion {
type uint16;
description "Used for Exporting Processes, this parameter
contains the version number of the IPFIX protocol that the
Exporter uses to export its data in this Transport Session.
Hence, it is identical to the value of the configuration
parameter ipfixVersion of the outer SctpExporter,
UdpExporter, or TcpExporter node.
Used for Collecting Processes, this parameter contains the
version number of the IPFIX protocol it receives for
this Transport Session. If IPFIX Messages of different
IPFIX protocol versions are received, this parameter
contains the maximum version number.
Note that this parameter corresponds to
ipfixTransportSessionIpfixVersion in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionIpfixVersion).";
}
leaf sourceAddress {
type inet:ip-address;
description "The source address of the Exporter of the
IPFIX Transport Session.
If the transport protocol is SCTP, this is one of the
potentially many IP addresses of the Exporter.
Preferably, the source IP address of the path that is
usually selected by the Exporter to send IPFIX Messages to
the Collector SHOULD be used.
Note that this parameter functionally corresponds to
ipfixTransportSessionSourceAddressType and
ipfixTransportSessionSourceAddress in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionSourceAddressType,
ipfixTransportSessionSourceAddress);
RFC 4960, Section 6.4.";
}
leaf destinationAddress {
type inet:ip-address;
description "The destination address of the Collector of
the IPFIX Transport Session.
If the transport protocol is SCTP, this is one of the
potentially many IP addresses of the Collector.
Preferably, the destination IP address of the path that is
usually selected by the Exporter to send IPFIX Messages to
the Collector SHOULD be used.
Note that this parameter functionally corresponds to
ipfixTransportSessionDestinationAddressType and
ipfixTransportSessionDestinationAddress in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionDestinationAddressType,
ipfixTransportSessionDestinationAddress);
RFC 4960, Section 6.4.";
}
leaf sourcePort {
type inet:port-number;
description "The transport-protocol port number of the
Exporter of the IPFIX Transport Session.
Note that this parameter corresponds to
ipfixTransportSessionSourcePort in the IPFIX MIB module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionSourcePort).";
}
leaf destinationPort {
type inet:port-number;
description "The transport-protocol port number of the
Collector of the IPFIX Transport Session.
Note that this parameter corresponds to
ipfixTransportSessionDestinationPort in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionDestinationPort).";
}
leaf sctpAssocId {
type uint32;
description "The association ID used for the SCTP session
between the Exporter and the Collector of the IPFIX
Transport Session. It is equal to the sctpAssocId entry
in the sctpAssocTable defined in the SCTP-MIB.
This parameter is only available if the transport protocol
is SCTP and if an SNMP agent on the same Monitoring Device
enables access to the corresponding MIB objects in the
sctpAssocTable.
Note that this parameter corresponds to
ipfixTransportSessionSctpAssocId in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionSctpAssocId);
RFC 3871";
}
leaf status {
type transportSessionStatus;
description "Status of the Transport Session.
Note that this parameter corresponds to
ipfixTransportSessionStatus in the IPFIX MIB module.";
reference "RFC 6615, Section 8 (ipfixTransportSessionStatus).";
}
leaf rate {
type yang:gauge32;
units "bytes per second";
description "The number of bytes per second transmitted by the
Exporting Process or received by the Collecting Process.
This parameter is updated every second.
Note that this parameter corresponds to
ipfixTransportSessionRate in the IPFIX MIB module.";
reference "RFC 6615, Section 8 (ipfixTransportSessionRate).";
}
leaf bytes {
type yang:counter64;
units bytes;
description "The number of bytes transmitted by the
Exporting Process or received by the Collecting Process.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
transportSessionDiscontinuityTime.
Note that this parameter corresponds to
ipfixTransportSessionBytes in the IPFIX MIB module.";
reference "RFC 6615, Section 8 (ipfixTransportSessionBytes).";
}
leaf messages {
type yang:counter64;
units "IPFIX Messages";
description "The number of messages transmitted by the
Exporting Process or received by the Collecting Process.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
transportSessionDiscontinuityTime.
Note that this parameter corresponds to
ipfixTransportSessionMessages in the IPFIX MIB module.";
reference "RFC 6615, Section 8 (ipfixTransportSessionMessages).";
}
leaf discardedMessages {
type yang:counter64;
units "IPFIX Messages";
description "Used for Exporting Processes, this parameter
indicates the number of messages that could not be sent due
to internal buffer overflows, network congestion, routing
issues, etc. Used for Collecting Process, this parameter
indicates the number of received IPFIX Message that are
malformed, cannot be decoded, are received in the wrong
order or are missing according to the sequence number.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
transportSessionDiscontinuityTime.
Note that this parameter corresponds to
ipfixTransportSessionDiscardedMessages in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionDiscardedMessages).";
}
leaf records {
type yang:counter64;
units "Data Records";
description "The number of Data Records transmitted by the
Exporting Process or received by the Collecting Process.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
transportSessionDiscontinuityTime.
Note that this parameter corresponds to
ipfixTransportSessionRecords in the IPFIX MIB module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionRecords).";
}
leaf templates {
type yang:counter32;
units "Templates";
description "The number of Templates transmitted by the
Exporting Process or received by the Collecting Process.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
transportSessionDiscontinuityTime.
Note that this parameter corresponds to
ipfixTransportSessionTemplates in the IPFIX MIB module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionTemplates).";
}
leaf optionsTemplates {
type yang:counter32;
units "Options Templates";
description "The number of Option Templates transmitted by the
Exporting Process or received by the Collecting Process.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
transportSessionDiscontinuityTime.
Note that this parameter corresponds to
ipfixTransportSessionOptionsTemplates in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixTransportSessionOptionsTemplates).";
}
leaf transportSessionStartTime {
type yang:date-and-time;
description "Timestamp of the start of the given Transport
Session.
This state parameter does not correspond to any object in
the IPFIX MIB module.";
}
leaf transportSessionDiscontinuityTime {
type yang:date-and-time;
description "Timestamp of the most recent occasion at which
one or more of the Transport Session counters suffered a
discontinuity.
Note that this parameter functionally corresponds to
ipfixTransportSessionDiscontinuityTime in the IPFIX MIB
module. In contrast to
ipfixTransportSessionDiscontinuityTime, the time is
absolute and not relative to sysUpTime.";
reference "RFC 6615, Section 8
(ipfixTransportSessionDiscontinuityTime).";
}
list template {
description "This list contains the Templates and Options
Templates that are transmitted by the Exporting Process
or received by the Collecting Process.
Withdrawn or invalidated (Options) Templates MUST be removed
from this list.";
uses templateParameters;
}
}
/*****************************************************************
* Main container
*****************************************************************/
container ipfix {
description "Top-level node of the IPFIX/PSAMP configuration
data model.";
list collectingProcess {
if-feature collector;
key name;
description "Collecting Process of the Monitoring Device.";
leaf name {
type nameType;
description "Key of this list.";
}
uses collectingProcessParameters;
leaf-list exportingProcess {
if-feature exporter;
type leafref { path "/ipfix/exportingProcess/name"; }
description "Export of received records without any
modifications. Records are processed by all Exporting
Processes in the list.";
}
}
list observationPoint {
if-feature meter;
key name;
description "Observation Point of the Monitoring Device.";
leaf name {
type nameType;
description "Key of this list.";
}
uses observationPointParameters;
leaf-list selectionProcess {
type leafref { path "/ipfix/selectionProcess/name"; }
description "Selection Processes in this list process
packets in parallel.";
}
}
list selectionProcess {
if-feature meter;
key name;
description "Selection Process of the Monitoring Device.";
leaf name {
type nameType;
description "Key of this list.";
}
list selector {
key name;
min-elements 1;
ordered-by user;
description "List of Selectors that define the action of the
Selection Process on a single packet. The Selectors are
serially invoked in the same order as they appear in this
list.";
leaf name {
type nameType;
description "Key of this list.";
}
uses selectorParameters;
}
list selectionSequence {
config false;
description "This list contains the Selection Sequence IDs
that are assigned by the Monitoring Device to distinguish
different Selection Sequences passing through the
Selection Process.
As Selection Sequence IDs are unique per Observation
Domain, the corresponding Observation Domain IDs are
included as well.
With this information, it is possible to associate
Selection Sequence (Statistics) Report Interpretations
exported according to the PSAMP protocol with a Selection
Process in the configuration data.";
reference "RFC 5476.";
leaf observationDomainId {
type uint32;
description "Observation Domain ID for which the
Selection Sequence ID is assigned.";
}
leaf selectionSequenceId {
type uint64;
description "Selection Sequence ID used in the Selection
Sequence (Statistics) Report Interpretation.";
}
}
leaf cache {
type leafref { path "/ipfix/cache/name"; }
description "Cache that receives the output of the
Selection Process.";
}
}
list cache {
if-feature meter;
key name;
description "Cache of the Monitoring Device.";
leaf name {
type nameType;
description "Key of this list.";
}
leaf meteringProcessId {
type uint32;
config false;
description "The identifier of the Metering Process this
Cache belongs to.
This parameter corresponds to the Information Element
meteringProcessId. Its occurrence helps to associate
Cache parameters with Metering Process statistics
exported by the Monitoring Device using the Metering
Process (Reliability) Statistics Template as
defined by the IPFIX protocol specification.";
reference "RFC 5101, Sections 4.1 and 4.2;
IANA registry for IPFIX Entities,
http://www.iana.org/assignments/ipfix.";
}
leaf dataRecords {
type yang:counter64;
units "Data Records";
config false;
description "The number of Data Records generated by this
Cache.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
cacheDiscontinuityTime.
Note that this parameter corresponds to
ipfixMeteringProcessDataRecords in the IPFIX MIB
module.";
reference "RFC 6615, Section 8
(ipfixMeteringProcessDataRecords).";
}
leaf cacheDiscontinuityTime {
type yang:date-and-time;
config false;
description "Timestamp of the most recent occasion at which
the counter dataRecords suffered a discontinuity.
Note that this parameter functionally corresponds to
ipfixMeteringProcessDiscontinuityTime in the IPFIX MIB
module. In contrast to
ipfixMeteringProcessDiscontinuityTime, the time is
absolute and not relative to sysUpTime.";
reference "RFC 6615, Section 8
(ipfixMeteringProcessDiscontinuityTime).";
}
choice CacheType {
mandatory true;
description "Type of Cache and specific parameters.";
container immediateCache {
if-feature immediateCache;
description "Flow expiration after the first packet;
generation of Packet Records.";
uses cacheLayoutParameters;
}
container timeoutCache {
if-feature timeoutCache;
description "Flow expiration after active and idle
timeout; generation of Flow Records.";
uses flowCacheParameters;
uses cacheLayoutParameters;
}
container naturalCache {
if-feature naturalCache;
description "Flow expiration after active and idle
timeout, or on natural termination (e.g., TCP FIN or
TCP RST) of the Flow; generation of Flow Records.";
uses flowCacheParameters;
uses cacheLayoutParameters;
}
container permanentCache {
if-feature permanentCache;
description "No flow expiration, periodical export with
time interval exportInterval; generation of Flow
Records.";
uses flowCacheParameters;
uses cacheLayoutParameters;
}
}
leaf-list exportingProcess {
if-feature exporter;
type leafref { path "/ipfix/exportingProcess/name"; }
description "Records are exported by all Exporting Processes
in the list.";
}
}
list exportingProcess {
if-feature exporter;
key name;
description "Exporting Process of the Monitoring Device.";
leaf name {
type nameType;
description "Key of this list.";
}
uses exportingProcessParameters;
}
}
}
<CODE ENDS>7. Examples ✨
Okay bestie, this section is all about example configurations 🎀 and they have to conform to the YANG module from Section 6 💅 so everything lines up with the model we just went through 🦋
7.1. PSAMP Device 🌸
Okay so this example config is giving main character energy 👑✨ We've got two Observation Points: one catching ingress traffic on eth0 and one catching all traffic on eth1 🦋. Both of those streams feed into two different Selection Processes. The first one is a Composite Selector that combines a UDP filter with a random sampler 🎀. The second one is a Primitive Selector that only filters for ICMP 🧚. Then the Selected Packet Streams from both of them land in the same Cache, which spits out a PSAMP Packet Report for every single selected packet 💅
The Exporting Process sends everything to a Collector using PR-SCTP and DTLS 🫶. The TLS/DTLS settings say the collector must supply a certificate for the FQDN collector.example.net. Valid certificates from any certification authority get accepted, so no drama there 🌸 Since the destination transport port isn't written down, it defaults to the standard IPFIX-over-DTLS port 4740. Iconic 💜
Now the Selection Processes' parameters get reported as Selection Sequence Report Interpretations and Selector Report Interpretations [RFC5476]. You get two Selection Sequence Report Interpretations per Selection Process, one for each Observation Point 🍓 And the Selection Sequence Statistics Report Interpretations get exported every 30 seconds (30000 milliseconds) ⏰
<ipfix xmlns="urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp">
<observationPoint>
<name>OP at eth0 (ingress)</name>
<observationDomainId>123</observationDomainId>
<ifName>eth0</ifName>
<direction>ingress</direction>
<selectionProcess>Sampled UDP packets</selectionProcess>
<selectionProcess>ICMP packets</selectionProcess>
</observationPoint>
<observationPoint>
<name>OP at eth1</name>
<observationDomainId>123</observationDomainId>
<ifName>eth1</ifName>
<selectionProcess>Sampled UDP packets</selectionProcess>
<selectionProcess>ICMP packets</selectionProcess>
</observationPoint>
<selectionProcess>
<name>Sampled UDP packets</name>
<selector>
<name>UDP filter</name>
<filterMatch>
<ieId>4</ieId>
<value>17</value>
</filterMatch>
</selector>
<selector>
<name>10-out-of-100 sampler</name>
<sampRandOutOfN>
<size>10</size>
<population>100</population>
</sampRandOutOfN>
</selector>
<cache>PSAMP cache</cache>
</selectionProcess>
<selectionProcess>
<name>ICMP packets</name>
<selector>
<name>ICMP filter</name>
<filterMatch>
<ieId>4</ieId>
<value>1</value>
</filterMatch>
</selector>
<cache>PSAMP cache</cache>
</selectionProcess>
<cache>
<name>PSAMP cache</name>
<immediateCache>
<cacheLayout>
<cacheField>
<name>Field 1: ipHeaderPacketSection</name>
<ieId>313</ieId>
<ieLength>64</ieLength>
</cacheField>
<cacheField>
<name>Field 2: observationTimeMilliseconds</name>
<ieId>322</ieId>
</cacheField>
</cacheLayout>
</immediateCache>
<exportingProcess>The only exporter</exportingProcess>
</cache>
<exportingProcess>
<name>The only exporter</name>
<destination>
<name>PR-SCTP collector</name>
<sctpExporter>
<destinationIPAddress>192.0.2.1</destinationIPAddress>
<rateLimit>1000000</rateLimit>
<timedReliability>500</timedReliability>
<transportLayerSecurity>
<remoteSubjectFQDN>coll-1.example.net</remoteSubjectFQDN>
</transportLayerSecurity>
</sctpExporter>
</destination>
<options>
<name>Options 1</name>
<optionsType>selectionSequence</optionsType>
<optionsTimeout>0</optionsTimeout>
</options>
<options>
<name>Options 2</name>
<optionsType>selectionStatistics</optionsType>
<optionsTimeout>30000</optionsTimeout>
</options>
</exportingProcess>
</ipfix>Soooo the whole config ends up with one Template and six Options Templates 🎀 For the rest of the example, we're going with Template ID 256 for the Template and Template IDs 257 to 262 for the Options Templates 🌈 The Template is what carries the Packet Reports, and it has these fields:
Template ID: 256
ipHeaderPacketSection (elementId = 313, length = 64)
observationTimeMilliseconds (elementId = 322, length = 8)Two Options Templates handle the Selection Sequence Report Interpretations 🧚 The first one has one selectorId field and is used for the Selection Process "ICMP packets". The second one has two selectorId fields, because it's describing the two selectors in the Selection Process "Sampled UDP packets" 😭
Template ID: 257
Scope: selectionSequenceId (elementId = 301, length = 8)
observationPointId (elementId = 138, length = 4)
selectorId (elementId = 302, length = 4)
Template ID: 258
Scope: selectionSequenceId (elementId = 301, length = 8)
observationPointId (elementId = 138, length = 4)
selectorId (elementId = 302, length = 4)
selectorId (elementId = 302, length = 4)Another Options Template carries the Property Match Filtering Selector Report Interpretation for the Selectors "UDP filter" and "ICMP filter" 💖
Template ID: 259
Scope: selectorId (elementId = 302, length = 4)
selectorAlgorithm (elementId = 304, length = 2)
protocolIdentifier (elementId = 4, length = 1)Yet another Options Template carries the Random n-out-of-N Sampling Selector Report Interpretation for the Selector "10-out-of-100 sampler" 🦋
Template ID: 260
Scope: selectorId (elementId = 302, length = 4)
selectorAlgorithm (elementId = 304, length = 2)
samplingSize (elementId = 319, length = 4)
samplingPopulation (elementId = 310, length = 4)The last two Options Templates carry the Selection Sequence Statistics Report Interpretation for the Selection Processes, one containing the statistics for one Selector and the other for two Selectors 📊✨
Template ID: 261
Scope: selectionSequenceId (elementId = 301, length = 8)
selectorIdTotalPktsObserved (elementId = 318, length = 8)
selectorIdTotalPktsSelected (elementId = 319, length = 8)
Template ID: 262
Scope: selectionSequenceId (elementId = 301, length = 8)
selectorIdTotalPktsObserved (elementId = 318, length = 8)
selectorIdTotalPktsSelected (elementId = 319, length = 8)
selectorIdTotalPktsObserved (elementId = 318, length = 8)
selectorIdTotalPktsSelected (elementId = 319, length = 8)Now for the runtime part 🌸 After a short while, 100 packets have been observed across the two Observation Points, including 20 UDP and 5 ICMP packets. 3 of those UDP packets get picked by the random sampler, which means the Cache ends up generating 8 Packet Reports in total 🎉 Under these circumstances, the complete configuration and state data of the PSAMP Device may look like this:
<ipfix xmlns="urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp">
<observationPoint>
<name>OP at eth0 (ingress)</name>
<observationPointId>1</observationPointId>
<observationDomainId>123</observationDomainId>
<ifName>eth0</ifName>
<direction>ingress</direction>
<selectionProcess>Sampled UDP packets</selectionProcess>
<selectionProcess>ICMP packets</selectionProcess>
</observationPoint>
<observationPoint>
<name>OP at eth1</name>
<observationPointId>2</observationPointId>
<observationDomainId>123</observationDomainId>
<ifName>eth1</ifName>
<direction>both</direction>
<selectionProcess>Sampled UDP packets</selectionProcess>
<selectionProcess>ICMP packets</selectionProcess>
</observationPoint>
<selectionProcess>
<name>Sampled UDP packets</name>
<selector>
<name>UDP filter</name>
<filterMatch>
<ieId>4</ieId>
<value>17</value>
</filterMatch>
<packetsObserved>100</packetsObserved>
<packetsDropped>80</packetsDropped>
<selectorDiscontinuityTime>2010-03-15T00:00:00.00Z
</selectorDiscontinuityTime>
</selector>
<selector>
<name>10-out-of-100 sampler</name>
<sampRandOutOfN>
<size>10</size>
<population>100</population>
</sampRandOutOfN>
<packetsObserved>20</packetsObserved>
<packetsDropped>17</packetsDropped>
<selectorDiscontinuityTime>2010-03-15T00:00:00.00Z
</selectorDiscontinuityTime>
</selector>
<selectionSequence>
<observationDomainId>123</observationDomainId>
<selectionSequenceId>1</selectionSequenceId>
</selectionSequence>
<selectionSequence>
<observationDomainId>123</observationDomainId>
<selectionSequenceId>2</selectionSequenceId>
</selectionSequence>
<cache>PSAMP cache</cache>
</selectionProcess>
<selectionProcess>
<name>ICMP packets</name>
<selector>
<name>ICMP filter</name>
<filterMatch>
<ieId>4</ieId>
<value>1</value>
</filterMatch>
<packetsObserved>100</packetsObserved>
<packetsDropped>95</packetsDropped>
<selectorDiscontinuityTime>2010-03-15T00:00:00.00Z
</selectorDiscontinuityTime>
</selector>
<selectionSequence>
<observationDomainId>123</observationDomainId>
<selectionSequenceId>3</selectionSequenceId>
</selectionSequence>
<selectionSequence>
<observationDomainId>123</observationDomainId>
<selectionSequenceId>4</selectionSequenceId>
</selectionSequence>
<cache>PSAMP cache</cache>
</selectionProcess>
<cache>
<name>PSAMP cache</name>
<meteringProcessId>1</meteringProcessId>
<immediateCache>
<cacheLayout>
<cacheField>
<name>Field 1: ipHeaderPacketSection</name>
<ieId>313</ieId>
<ieLength>64</ieLength>
</cacheField>
<cacheField>
<name>Field 2: observationTimeMilliseconds</name>
<ieId>322</ieId>
</cacheField>
</cacheLayout>
</immediateCache>
<dataRecords>8</dataRecords>
<cacheDiscontinuityTime>2010-03-15T00:00:00.00Z
</cacheDiscontinuityTime>
<exportingProcess>The only exporter</exportingProcess>
</cache>okay bestie, here's the whole exporting process example 🎀✨
<exportingProcess>
<name>The only exporter</name>
<exportingProcessId>1</exportingProcessId>
<exportMode>parallel</exportMode>
<destination>
<name>PR-SCTP collector</name>
<sctpExporter>
<ipfixVersion>10</ipfixVersion>
<destinationIPAddress>192.0.2.1</destinationIPAddress>
<destinationPort>4740</destinationPort>
<sendBufferSize>32768</sendBufferSize>
<rateLimit>1000000</rateLimit>
<timedReliability>500</timedReliability>
<transportLayerSecurity>
<remoteSubjectFQDN>coll-1.example.net</remoteSubjectFQDN>
</transportLayerSecurity>
<transportSession>
<ipfixVersion>10</ipfixVersion>
<sourceAddress>192.0.2.100</sourceAddress>
<destinationAddress>192.0.2.1</destinationAddress>
<sourcePort>45687</sourcePort>
<destinationPort>4740</destinationPort>
<sctpAssocId>1</sctpAssocId>
<status>active</status>
<rate>230</rate>
<bytes>978</bytes>
<messages>3</messages>
<records>19</records>
<templates>1</templates>
<optionsTemplates>6</optionsTemplates>
<transportSessionStartTime>2010-03-15T00:00:00.50Z
</transportSessionStartTime>
<template>
<observationDomainId>123</observationDomainId>
<templateId>256</templateId>
<setId>2</setId>
<accessTime>2010-03-15T00:00:02.15Z</accessTime>
<templateDataRecords>8</templateDataRecords>
<templateDiscontinuityTime>2010-03-15T00:00:01.10Z
</templateDiscontinuityTime>
<field>
<ieId>313</ieId>
<ieLength>64</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>154</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
</template>
<template>
<observationDomainId>123</observationDomainId>
<templateId>257</templateId>
<setId>3</setId>
<accessTime>2010-03-15T00:00:02.15Z</accessTime>
<templateDataRecords>2</templateDataRecords>
<templateDiscontinuityTime>2010-03-15T00:00:01.10Z
</templateDiscontinuityTime>
<field>
<ieId>301</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
<isScope/>
</field>
<field>
<ieId>138</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>302</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
</template>
<template>
<observationDomainId>123</observationDomainId>
<templateId>258</templateId>
<setId>3</setId>
<accessTime>2010-03-15T00:00:02.15Z</accessTime>
<templateDataRecords>2</templateDataRecords>
<templateDiscontinuityTime>2010-03-15T00:00:01.10Z
</templateDiscontinuityTime>
<field>
<ieId>301</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
<isScope/>
</field>
<field>
<ieId>138</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>302</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>302</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
</template>
<template>
<observationDomainId>123</observationDomainId>
<templateId>259</templateId>
<setId>3</setId>
<accessTime>2010-03-15T00:00:02.15Z</accessTime>
<templateDataRecords>2</templateDataRecords>
<templateDiscontinuityTime>2010-03-15T00:00:01.10Z
</templateDiscontinuityTime>
<field>
<ieId>302</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
<isScope/>
</field>
<field>
<ieId>304</ieId>
<ieLength>2</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>4</ieId>
<ieLength>1</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
</template>
<template>
<observationDomainId>123</observationDomainId>
<templateId>260</templateId>
<setId>3</setId>
<accessTime>2010-03-15T00:00:02.15Z</accessTime>
<templateDataRecords>1</templateDataRecords>
<templateDiscontinuityTime>2010-03-15T00:00:01.10Z
</templateDiscontinuityTime>
<field>
<ieId>302</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
<isScope/>
</field>
<field>
<ieId>304</ieId>
<ieLength>2</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>309</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>310</ieId>
<ieLength>4</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
</template>
<template>
<observationDomainId>123</observationDomainId>
<templateId>261</templateId>
<setId>3</setId>
<accessTime>2010-03-15T00:00:03.10Z</accessTime>
<templateDataRecords>2</templateDataRecords>
<templateDiscontinuityTime>2010-03-15T00:00:01.10Z
</templateDiscontinuityTime>
<field>
<ieId>301</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
<isScope/>
</field>
<field>
<ieId>318</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>319</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
</template>
<template>
<observationDomainId>123</observationDomainId>
<templateId>262</templateId>
<setId>3</setId>
<accessTime>2010-03-15T00:00:03.10Z</accessTime>
<templateDataRecords>2</templateDataRecords>
<templateDiscontinuityTime>2010-03-15T00:00:01.10Z
</templateDiscontinuityTime>
<field>
<ieId>301</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
<isScope/>
</field>
<field>
<ieId>318</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>319</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>318</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
<field>
<ieId>319</ieId>
<ieLength>8</ieLength>
<ieEnterpriseNumber>0</ieEnterpriseNumber>
</field>
</template>
</transportSession>
</sctpExporter>
</destination>
<options>
<name>Options 1</name>
<optionsType>selectionSequence</optionsType>
<optionsTimeout>0</optionsTimeout>
</options>
<options>
<name>Options 2</name>
<optionsType>selectionStatistics</optionsType>
<optionsTimeout>30000</optionsTimeout>
</options>
</exportingProcess>
</ipfix>7.2. IPFIX Device 💖
okay so this example is giving shared Cache energy 🧚✨ One Cache is holding Flow Records from two Observation Points that belong to different Observation Domains. Packets get selected in two different ways: count-based Sampling on the first Observation Point (eth0), and selecting all packets on the second one (eth1). The Exporting Process sends the Flow Records to a primary destination using SCTP, and a UDP Collector is set up as the secondary destination 🦋
Exporting Process reliability statistics [RFC5101] get exported every minute (60000 milliseconds) 🌸 Selection Sequence Report Interpretations and Selector Report Interpretations [RFC5476] only get exported once, after the Selection Processes are configured. There end up being two Selection Sequence Report Interpretations in total, one for each Selection Process 💅
<ipfix xmlns="urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp">
<observationPoint>
<name>OP at eth0 (ingress)</name>
<observationDomainId>123</observationDomainId>
<ifName>eth0</ifName>
<direction>ingress</direction>
<selectionProcess>Count-based packet selection</selectionProcess>
</observationPoint>
<observationPoint>
<name>OP at eth1</name>
<observationDomainId>456</observationDomainId>
<ifName>eth1</ifName>
<selectionProcess>All packet selection</selectionProcess>
</observationPoint>
<selectionProcess>
<name>Count-based packet selection</name>
<selector>
<name>Count-based sampler</name>
<sampCountBased>
<packetInterval>1</packetInterval>
<packetSpace>99</packetSpace>
</sampCountBased>
</selector>
<cache>Flow cache</cache>
</selectionProcess>
<selectionProcess>
<name>All packet selection</name>
<selector>
<name>Select all</name>
<selectAll/>
</selector>
<cache>Flow cache</cache>
</selectionProcess>
<cache>
<name>Flow cache</name>
<timeoutCache>
<maxFlows>4096</maxFlows>
<activeTimeout>5000</activeTimeout>
<idleTimeout>10000</idleTimeout>
<cacheLayout>
<cacheField>
<name>Field 1</name>
<ieName>sourceIPv4Address</ieName>
<isFlowKey/>
</cacheField>
<cacheField>
<name>Field 2</name>
<ieName>destinationIPv4Address</ieName>
<isFlowKey/>
</cacheField>
<cacheField>
<name>Field 3</name>
<ieName>protocolIdentifier</ieName>
<isFlowKey/>
</cacheField>
<cacheField>
<name>Field 4</name>
<ieName>sourceTransportPort</ieName>
<isFlowKey/>
</cacheField>
<cacheField>
<name>Field 5</name>
<ieName>destinationTransportPort</ieName>
<isFlowKey/>
</cacheField>
<cacheField>
<name>Field 6</name>
<ieName>flowStartMilliseconds</ieName>
</cacheField>
<cacheField>
<name>Field 7</name>
<ieName>flowEndSeconds</ieName>
</cacheField>
<cacheField>
<name>Field 8</name>
<ieName>octetDeltaCount</ieName>
</cacheField>
<cacheField>
<name>Field 9</name>
<ieName>packetDeltaCount</ieName>
</cacheField>
</cacheLayout>
</timeoutCache>
<exportingProcess>SCTP export with UDP backup</exportingProcess>
</cache>
<exportingProcess>
<name>SCTP export with UDP backup</name>
<exportMode>fallback</exportMode>
<destination>
<name>SCTP destination (primary)</name>
<sctpExporter>
<destinationPort>4739</destinationPort>
<destinationIPAddress>192.0.2.1</destinationIPAddress>
</sctpExporter>
</destination>
<destination>
<name>UDP destination (secondary)</name>
<udpExporter>
<destinationPort>4739</destinationPort>
<destinationIPAddress>192.0.2.2</destinationIPAddress>
<templateRefreshTimeout>300</templateRefreshTimeout>
<optionsTemplateRefreshTimeout>300
</optionsTemplateRefreshTimeout>
</udpExporter>
</destination>
<options>
<name>Options 1</name>
<optionsType>selectionSequence</optionsType>
<optionsTimeout>0</optionsTimeout>
</options>
<options>
<name>Options 2</name>
<optionsType>exportingReliability</optionsType>
<optionsTimeout>60000</optionsTimeout>
</options>
</exportingProcess>
</ipfix>7.3. Export of Flow Records and Packet Reports 🎀
this one is about combined export of Flow Records and Packet Reports for a single Observation Point 🍓 A Selection Process applies random Sampling to the Observed Packet Stream, and its output goes into a Cache that generates Flow Records. At the same time, the Observed Packet Stream goes into a second Selection Process that throws out every non-ICMP packet and passes the selected ones to a second Cache, which generates Packet Reports. Both Caches send their output to a single Collector over SCTP 🔥
<ipfix xmlns="urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp">
<observationPoint>
<name>OP at linecard 3</name>
<observationDomainId>9876</observationDomainId>
<ifIndex>4</ifIndex>
<direction>ingress</direction>
<selectionProcess>Sampling</selectionProcess>
<selectionProcess>ICMP</selectionProcess>
</observationPoint>
<selectionProcess>
<name>Sampling</name>
<selector>
<name>Random sampler</name>
<sampUniProb>
<probability>0.01</probability>
</sampUniProb>
</selector>
<cache>Flow cache</cache>
</selectionProcess>
<selectionProcess>
<name>ICMP</name>
<selector>
<name>ICMP filter</name>
<filterMatch>
<ieId>4</ieId>
<value>1</value>
</filterMatch>
</selector>
<cache>Packet reporting</cache>
</selectionProcess>
<cache>
<name>Flow cache</name>
<timeoutCache>
<maxFlows>4096</maxFlows>
<activeTimeout>5</activeTimeout>
<idleTimeout>10</idleTimeout>
<cacheLayout>
<cacheField>
<name>Field 1</name>
<ieName>sourceIPv4Address</ieName>
<isFlowKey/>
</cacheField>
<cacheField>
<name>Field 2</name>
<ieName>destinationIPv4Address</ieName>
<isFlowKey/>
</cacheField>
<cacheField>
<name>Field 6</name>
<ieName>flowStartMilliseconds</ieName>
</cacheField>
<cacheField>
<name>Field 7</name>
<ieName>flowEndSeconds</ieName>
</cacheField>
<cacheField>
<name>Field 8</name>
<ieName>octetDeltaCount</ieName>
</cacheField>
<cacheField>
<name>Field 9</name>
<ieName>packetDeltaCount</ieName>
</cacheField>
</cacheLayout>
</timeoutCache>
<exportingProcess>Export</exportingProcess>
</cache>
<cache>
<name>Packet reporting</name>
<immediateCache>
<cacheLayout>
<cacheField>
<name>Field 1</name>
<ieId>313</ieId>
<ieLength>64</ieLength>
</cacheField>
<cacheField>
<name>Field 2</name>
<ieId>154</ieId>
</cacheField>
</cacheLayout>
</immediateCache>
<exportingProcess>Export</exportingProcess>
</cache>
<exportingProcess>
<name>Export</name>
<destination>
<name>SCTP collector</name>
<sctpExporter>
<destinationIPAddress>192.0.2.1</destinationIPAddress>
<timedReliability>0</timedReliability>
</sctpExporter>
</destination>
<options>
<name>Options 1</name>
<optionsType>selectionSequence</optionsType>
<optionsTimeout>0</optionsTimeout>
</options>
</exportingProcess>
</ipfix>7.4. Collector and File Writer 🌈
this example sets up a Collector that writes whatever it receives into a file 📁✨
<ipfix xmlns="urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp">
<collectingProcess>
<name>SCTP collector</name>
<sctpCollector>
<name>Listening port 4739</name>
<localPort>4739</localPort>
<localIPAddress>192.0.2.1</localIPAddress>
</sctpCollector>
<exportingProcess>File writer</exportingProcess>
</collectingProcess>
<exportingProcess>
<name>File writer</name>
<destination>
<name>Write to /tmp folder</name>
<fileWriter>
<file>file://tmp/collected-records.ipfix</file>
</fileWriter>
</destination>
</exportingProcess>
</ipfix>7.5. Deviations 🦋
okay so picture a Monitoring Device that only has two interfaces, ifIndex=1 and ifIndex=2, and those are the only ones that can be set up as Observation Points 🙈 On top of that, the Observation Point ID is always the same number as the ifIndex. Lowkey the most literal relationship ever 💜
The YANG module below spells out these deviations 💅
module my-ipfix-psamp-deviation {
namespace "urn:my-company:xml:ns:ietf-ipfix-psamp";
prefix my;
import ietf-ipfix-psamp { prefix ipfix; }
deviation /ipfix:ipfix/ipfix:observationPoint/ipfix:entPhysicalIndex {
deviate not-supported;
}
deviation /ipfix:ipfix/ipfix:observationPoint/ipfix:entPhysicalName {
deviate not-supported;
}
deviation /ipfix:ipfix/ipfix:observationPoint/ipfix:ifName {
deviate not-supported;
}
deviation /ipfix:ipfix/ipfix:observationPoint {
deviate add {
must "ipfix:ifIndex=1 or ipfix:ifIndex=2";
}
}
deviation
/ipfix:ipfix/ipfix:observationPoint/ipfix:observationPointId {
deviate add {
must "current()=../ipfix:ifIndex";
}
}
}8. Security Considerations 🔒✨
okay bestie, security is where this gets seriously important 😭. This YANG module is meant to be used through NETCONF [RFC6241], and the bottom layer of NETCONF is the secure transport layer. The one that MUST be implemented is SSH [RFC6242]. Careful, the key words in this paragraph are not capitalised, so there's no requirement language here, just the mandatory-to-implement transport being named.
Heads up, there are a bunch of data nodes in this module that you can create, change, and delete (that's config true, which is the default 👀). In some network environments they can be sensitive or vulnerable. Write operations like edit-config on these nodes, done without proper protection, can seriously mess with network operations 💀. Here's the breakdown of which subtrees are sensitive and why:
/ipfix/observationPoint: this subtree says where packets get observed and which Selection Processes handle them. If someone can write to it, they can observe packets at arbitrary interfaces or linecards of the Monitoring Device, which could lead to sensitive traffic information being exported 😱./ipfix/selectionProcess: this subtree decides which packets get reported in Packet Reports or Flow Records. Write access lets someone change that subset of packets, which could also lead to sensitive traffic info being exported 👀./ipfix/cache: this subtree sets which fields go into Packet Reports or Flow Records. Write access lets someone add fields that might hold sensitive traffic info, like IP addresses or parts of the packet payload 🙈./ipfix/exportingProcess: this subtree controls which Collectors get the Packet Reports or Flow Records. Write access could send potentially sensitive traffic info to illegitimate Collectors 💔. On top of that, TLS/DTLS parameters can be changed, and that can affect the mutual authentication between Exporters and Collectors and the encrypted transport of the data 🔐./ipfix/collectingProcess: this subtree can say that collected Packet Reports and Flow Records get reexported to another Collector or written to a file. Write access could allow reexporting or storing sensitive traffic info 😬.
Read access matters too! Some of the readable data nodes in this module can be sensitive or vulnerable depending on the network, so it's important to control read access (through get, get-config, or notification) to them 🫶.
Here's the readable stuff to guard:
/ipfix/observationPoint: parameters here might be sensitive because they reveal info about the Monitoring Device itself and the network infrastructure 🧐./ipfix/selectionProcess: parameters here might be sensitive because they reveal info about the Monitoring Device and the observed traffic. For example, the counterspacketsObservedandpacketsDroppedlet someone infer how many packets were observed 🔢./ipfix/cache: parameters here might be sensitive for the same reasons, since they reveal info about the Monitoring Device and the observed traffic. For example, the countersactiveFlowsanddataRecordslet someone infer how many Flows or packets were measured 📊./ipfix/exportingProcess: parameters here might be sensitive because they reveal info about the network infrastructure and the outgoing IPFIX Transport Sessions. For example, they disclose the IP addresses of Collectors and the deployed TLS/DTLS configuration, which might make it easier to intercept outgoing IPFIX Messages 🕵️♀️./ipfix/collectingProcess: parameters here might be sensitive because they reveal info about the network infrastructure and the incoming IPFIX Transport Sessions. For example, they disclose the IP addresses of Exporters and the deployed TLS/DTLS configuration, which might make it easier to intercept incoming IPFIX Messages 🦋.
9. IANA Considerations 🗂️🌸
This document registers a URI in the IETF XML registry [RFC3688]. Following the format in RFC 3688, here's the registration being requested:
URI: urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp
Registrant Contact: The IPFIX WG of the IETF.
XML: N/A, the requested URI is an XML namespace.This document also registers a YANG module in the YANG Module Names registry [RFC6020]:
name: ietf-ipfix-psamp
namespace: urn:ietf:params:xml:ns:yang:ietf-ipfix-psamp
prefix: ipfix
reference: RFC 672810. Acknowledgements 🫶💜
The authors give a huge thank you to Martin Bjorklund, Andy Bierman, and Ladislav Lhotka for helping to specify the configuration data model in YANG 🙌. They also thank Atsushi Kobayashi, Andrew Johnson, Lothar Braun, and Brian Trammell for their valuable reviews of this document 🎀.
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC5101] Claise, B., "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.
- [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
- [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., Johnson, A., and J. Quittek, "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.
- [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
- [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
- [UML] Object Management Group, "OMG Unified Modeling Language (OMG UML), Superstructure, V2.2", OMG formal/2009-02-02, February 2009.
- [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
http://www.iana.org/assignments/ipfix.
11.2. Informative References ✨
okay bestie, these are the extra reads that back up the whole spec 📚🫶 every entry is kept exactly as written so nothing gets lost in translation 💅
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, January 1990.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
RFC 3917, October 2004.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
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.
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009.
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby,
"Exporting Type Information for IP Flow Information Export
(IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
Wagner, "Specification of the IP Flow Information Export
(IPFIX) File Format", RFC 5655, October 2009.
[RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition
Languages and Validating NETCONF Content", RFC 6110,
February 2011.
[RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP
Flow Information Export (IPFIX) Per Stream Control
Transmission Protocol (SCTP) Stream", RFC 6526,
March 2012.
[RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
"Definitions of Managed Objects for IP Flow Information
Export", RFC 6615, June 2012.
[W3C.REC-xml-20081126]
Sperberg-McQueen, C., Yergeau, F., Bray, T., Paoli, J.,
and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation
REC-xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xmlschema-0-20041028]
Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer
Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-0-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
[RFC6727] Dietz, T., Claise, B., and J. Quittek, "Definitions of
Managed Objects for Packet Sampling", RFC 6727, October
2012.
[YANG-WEB]
Bjoerklund, M., "YANG WebHome", March 2011,
<http://www.yang-central.org/>.
[IANA-ENTERPRISE-NUMBERS]
IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers>.Authors' Addresses 💖
and last but not least, the humans behind it 🧚 here's where you can find them 🌸
Gerhard Muenz
Technische Universitaet Muenchen
Department of Informatics
Chair for Network Architectures and Services (I8)
Boltzmannstr. 3
85748 Garching
Germany
EMail: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Commercial Street
Edinburgh EH6 6LX
United Kingdom
Phone: +44 131 561 3616
EMail: paitken@cisco.com📦 where this page comes from
- ietf: rfc6728 2012-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms